Wednesday, 20 November 2019
SOLVED! RADIUS Authentication Failed (MSCHAP error: "E=649" R=0 V=3)
Wednesday, 19 December 2018
Windows 10 NLA Public vs Private profiles - what's the difference?
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.
Friday, 30 November 2018
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
|
|
|
Thursday, 28 June 2018
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”.
|

