Windows 10 NLA Public vs Private profiles - what's the difference?

In a recent post I described how I used Powershell to configure a dual-homed Radius server where I wanted to firewall everything on the DMZ interface but not affect the production interface.  I did this using a Windows feature known as NLA – Network Location Awareness – which has been around in one form or another since Windows XP, although many people still know very little about it.
NLA in Windows 10 uses 3 different network profiles: Domain, Public and Private.  Windows assigns the network connection to one of these profiles when a new network is discovered.  It’s important to know the differences because this actually provides us with a really powerful tool to lock down our machines using the built in Windows Firewall.

How the appropriate location is determined

Domain

Microsoft explain that Windows checks the connection specific DNS name against “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” (although on my test machine this was an empty key but “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\MachineDomain” contained the domain DNS name).  If this matches and the machine is able to go on and contact a Domain Controller via LDAP, then you are assigned the Domain profile.

Public vs Private

This is the bit most people get confused about and it is a distinction which appeared from Windows Vista onwards (in XP the profiles were Domain and Standard).  The way that the location is determined is via the prompt that you receive when connecting to a new network ie “Do you want to allow your PC to be discoverable by other PCs and devices on this network?”.  Selecting “Yes” assigns the Private profile whilst “No” assigns the Public profile.

It’s useful to know of this distinction as it will allow you to configure specific rules on the firewall which will behave differently depending on whether you are connected to a trusted or untrusted network.

Disable inbound advanced firewall rules on public interface only with Powershell for a Windows Radius/NPS server

 

Recently I built an NPS server for Radius authentication, and had to dual home it with one NIC in the DMZ and one on the production network.  I wanted to firewall everything on the DMZ interface but not affect the production interface.  That way I could then allow the traffic I wanted to enable on the DMZ interface port by port.  Assuming windows has correctly detected the profile on the two interfaces as “Domain” and “Public”, which it should based on the resources visible on each network, you can run the following script to disable traffic just on the public interface.

$LogFilePath = $env:LOCALAPPDATA + "\Cloudwyse\Logs\adv_firewall" + $(get-date -Format ddMMyy_HHmmss) + ".log" Start-Transcript -Path $LogFilePath -NoClobber   $rules = Get-NetFirewallRule $total = 0 foreach ($rule in $rules) { if (($rule.Profile -like "any" -or $rule.Profile -match "public") -and $rule.enabled -like "True" -and $rule.direction -like "Inbound") { if ($rule.Profile -like "any") {   Set-NetFirewallRule -Name $rule.Name -Profile "Domain, Private"   write-host "Setting" $rule.DisplayName "Domain, Private" } elseif ($rule.Profile -match "Domain" -and $rule.Profile -match "private" -and  $rule.Profile -match "public" ) {   Set-NetFirewallRule -Name $rule.Name -Profile "Domain, Private"   write-host "Setting" $rule.DisplayName "Domain, Private" } elseif ($rule.Profile -match "Domain" -and  $rule.Profile -match "public" ) {   Set-NetFirewallRule -Name $rule.Name -Profile "Domain"   write-host "Setting" $rule.DisplayName "Domain" } elseif ($rule.Profile -match "Private" -and  $rule.Profile -match "public" ) {   Set-NetFirewallRule -Name $rule.Name -Profile "Private"   write-host "Setting" $rule.DisplayName "Private" } elseif ($rule.Profile -like "public" ) {   Disable-NetFirewallRule -Name $rule.Name   write-host "Disabling" $rule.DisplayName } else {write-host -ForegroundColor Red "Error - check logs"} $total = $total +1  }} write-host -ForegroundColor Yellow "$total rules processed"   stop-transcript

 

Very Simple Powershell Ping test or IP scanner script

 

This simple Powershell script will carry out a quick check against each IP in a 24 bit subnet and return a value of true or false dependent on whether or not it receives a reply.  It’s similar to using an IP scanner or a ping script.

$subnet = "10.20.6." 1..254 | Foreach-Object {write-host "$Subnet$_..." (Test-Connection -ComputerName "$Subnet$_" -Quiet -Count 1 ) }

It’s simple and does the job as it is however you could obviously make it more fancy by exporting to csv or an array or emailing the output etc etc.

 

How to install and configure Hyper-V Host (core) for remote administration

 

It's possible to configure a Hyper-V host running core to be fully managed remotely.  I have read various suggestions on the web saying it’s better and more secure to leave the Hyper-V host in a workgroup, but the effort required when doing that just doesn’t make it worth it in my opinion. And we actually want 1st and 2nd line technicians to be able to do as much troubleshooting as possible before escalating, rather than adding complexity.   OK if you haven’t already run the following on the core server do it now:

Enable-PSRemoting

If you don’t know the hostname, run the command now.

hostname

All being well, that should be the last time we need to run commands locally on the core server.  The machine you use to administer the core server must have the required Remote Server Administration Tools installed and, for ease of access, be a member of the domain.   So let’s connect to the host (obviously switch “oobehostname” for whatever the hostname of your machine is).

Enter-PSSession <oobehostname>

Next, rename it specifying your credentials

Rename-Computer -NewName "contosohv012" -DomainCredential contoso\admdel.griffith -Restart

Once the server has restarted, reconnect.  Then you can either do

Enter-PSSession contosohv012 Install-WindowsFeature -Name Hyper-V -Restart

Or to execute the command remotely

Install-WindowsFeature -Name Hyper-V -ComputerName “contosohv012” -Restart

If you aren’t sure whether Hyper-V is installed or not, you can run

Get-WindowsFeature -Name Hyper-V -ComputerName “contosohv012”

Next comes the firewall settings.  This Microsoft document explains that to enable remote management of a 2016 core server you should run:

Enable-NetFirewallRule -DisplayGroup "Remote Administration"

But this group was removed starting with Windows Server 2012.  So instead I ran:

Get-NetFirewallRule | select-object -expand DisplayGroup

to find the names of the services I needed.   To allow access for each follow these steps:   Windows Firewall with Advanced Security (I preferred just setting this on the Domain profile so I edited the rule first)

Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Profile Domain Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management"

Services

Enable-NetFirewallRule -DisplayGroup "Remote Service Management"

Event Viewer

Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management"

Shared Folders

Enable-NetFirewallRule -DisplayGroup "File and Printer Sharing"

Performance Logs and Alerts There are rules on each of the different profiles, so just the regular -DisplayGroup won’t cut the mustard here

Get-NetFirewallRule | Where {$_.DisplayGroup -eq "Performance Logs and Alerts" -and $_.Profile -eq "Domain"} | Enable-NetFirewallRule

Disk Management Disk Management is also a little more complicated.  First run this on the remote machine:

Enable-NetFirewallRule -DisplayGroup "Remote Volume Management"

Then run the same command on the local machine.  Next, we need to start the virtual disk service.

Set-Service -Name vds -StartupType Automatic Set-Service -Name vds -Status Running -PassThru

Now you should be able to connect computer management, and all other required mmc consoles by right clicking and choosing “Connect to another computer”.