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.

Search through previous powershell commands with grep

 

It can be really difficult trying to remember that command you used a few weeks ago in Powershell.  Here’s an easy way to search through your previous commands to find the right one and jog your memory. First, run

(Get-PSReadlineOption).HistorySavePath C:\Users\username\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Then you can cat the output to look for the command

cat C:\Users\username\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Or just open it in notepad

notepad C:\Users\username\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

If you want to search for a specific command within your history you can use findstr as follows

cat C:\Users\username\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt | findstr -i get-azureadgr

Or if you’re more comfortable with the UNIX/Linux commands like myself you can use grep in Powershell by creating an alias as follows

new-alias grep findstr

And search for the command as before, but this time using grep 😊

cat C:\Users\username\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt | grep -i get-azureadgr

Configuring log-on scripts to run via powershell from the "Run" key in Windows registry

 

If you’ve tried to add a powershell script to a registry run key, you’ve probably discovered that it doesn’t run with powershell.  Instead, Windows just opens the script in Notepad and leaves it sitting there all naked and exposed!  So in order to launch the powershell scripts we’re going to need to use a .bat or .cmd file launched from the run key in the registry.  So we’re going to add a string (REG_SZ) to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

When you create the key you can call it whatever you like but the value has to be exactly right – and point to the script you want to launch.  In my case this is:

Cloudwyse Scripts REG_SZ cmd /c START /MIN "Cloudwyse Env Execution" cmd /c "C:\Cloudwyse\Scripts\lch_powershell.cmd"

So I’m telling windows to launch a minimised command prompt, and then I’m passing the command I want running within that command prompt which means that users won’t have a big black box pop up on their screen everytime they log in.  Within that .cmd script, I need to launch Powershell but if I just go ahead and use the “powershell -File” command then I will hit issues with the execution policy within Windows which is disabled by default.  So we need the scripts to bypass the Powershell execution policy, but we don’t necessarily want to change the execution policy for the whole server for good.  So we can use this within the .cmd file:

@ECHO OFF SET CloudwyseScriptsDIR=C:\Cloudwyse\Scripts\ SET PSScriptPath=%CloudwyseScriptsDIR%wrapper.ps1 PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PSScriptPath%""' -WindowStyle Hidden}";

So we’re asking Windows to launch powershell, temporarily bypassing the execution policy for the context of this command only.  Then we pass the command which also bypasses the execution policy, but this time within the context of the file we’re about to launch which is “wrapper.ps1”. So now we have our Powershell wrapper script running automatically everytime a user logs in.  We can now nest within that script all the other powershell scripts we would also like to run by doing the following:

$ScriptPath = Split-Path $MyInvocation.MyCommand.Path . "$ScriptPath\date_check.ps1" . "$ScriptPath\vmcheck.ps1" . "$ScriptPath\IE_ESC.ps1"

Simply add a new line to this script for every logon script you want to run for users. And if you’re wondering why the “$MyInvocation” variable doesn’t seem to be used anywhere, that’s because it’s an automatic variable.  There’s a great article on it here if you’re interested in learning more.