I thought I knew a lot about Network Policy Server (NPS). The last few months have taught me differently. It started with my mad grab to enable AD authentication on any network device that supports it. Next, I got the joyful job of wading into the world of wireless. Alliteration aside, this led to a complete overhaul of our wireless infrastructure. By using NPS, our environment now uses a single SSID that dynamically VLANs objects based on how they authenticate.*
Both of these projects had their fair share of problems to overcome. Let’s talk about two tricks today; one learned from each project. The first makes NPS easier to manage by simplifying clients. The second makes NPS easier to manage by increasing redundancy.
Trick 1: RADIUS Client Subnets
Many network administrators group devices by their type and IP. For example, all network switches in at a site might be in a dedicated range or a specific portion of a subnet. When creating RADIUS clients, think about how the clients can be grouped. In the screenshot below, you can see two clients. The first IP address is actually a range. My 10.94 IP range actually a /20 at that site. All of my switches though are located in the first 254 addresses. The second IP address show how clients used to be managed – one IP at a time.
I now use the single RADIUS client IP of 10.94.0.0/24 to allow authentication to all of my switches at that site. If I add a new switch at that location, I don’t have to remember to also create a RADIUS client for it because it is automatically included.
If another type of device happens to be in that range, no big deal. For any kind of a security risk, that device would have to be:
- Attempting to authenticate against my network policy server
- have the correct shared secret for this RADIUS client
Using IP ranges instead of single IP addresses makes RADIUS client management so much easier!
Trick 2: Syncing Network Policy Server Settings Between Two Servers
Having all of this fancy authentication is of little good if your Network Policy Server is offline. To be redundant, you need a second server running NPS with your RADIUS clients configured to contact it as a backup service. For switches, this is as simple as adding a separate radius-server host command in your configuration. HP Switches, at least, contact RADIUS servers in a top – bottom order in their configuration. Other devices typically allow you to specify multiple RADIUS entries in their web interface.
The next step is to keep your servers in sync with each other.** PowerShell makes this incredibly easy. Copy the below script, written by JGrote, and save it on your secondary Network Policy Server. Be sure to configure the two variables under the ###Variables section.
###Network Policy Server Synchronization Script
#This script copies the configuration from the NPS Master Server and imports it on this server.
#The Account that this script runs under must have Local Administrator rights to the NPS Master.
#This was designed to be run as a scheduled task on the NPS Secondary Servers on an hourly,daily, or as-needed basis.
#Last Modified 01 Dec 2009 by JGrote <jgrote AT enpointe NOSPAM-DOTCOM>
###Variables
#NPSMaster - Your Primary Network Policy Server you want to copy the config from.
$NPSMaster = "NPS1.Test.local"
#NPSConfigTempFile - A temporary location to store the XML config. Use a UNC path so that the primary can save the XML file across the network. Be sure to set secure permissions on this folder, as the configuration including pre-shared keys is temporarily stored here during the import process.
$NPSConfigTempFile = "\\NPS1.Test.local\C$\NPSConfig-$NPSMaster.xml"
#Create an NPS Sync Event Source if it doesn't already exist
if (!(get-eventlog -logname "System" -source "NPS-Sync")) {new-eventlog -logname "System" -source "NPS-Sync"}
#Write an error and exit the script if an exception is ever thrown
trap {write-eventlog -logname "System" -eventID 1 -source "NPS-Sync" -EntryType "Error" -Message "An Error occured during NPS Sync: $_. Script run from $($MyInvocation.MyCommand.Definition)"; exit}
#Connect to NPS Master and export configuration
$configExportResult = invoke-command -ComputerName $NPSMaster -ArgumentList $NPSConfigTempFile -scriptBlock {param ($NPSConfigTempFile) netsh nps export filename = $NPSConfigTempFile exportPSK = yes}
#Verify that the import XML file was created. If it is not there, it will throw an exception caught by the trap above that will exit the script.
$NPSConfigTest = Get-Item $NPSConfigTempFile
#Clear existing configuration and import new NPS config
$configClearResult = netsh nps reset config
$configImportResult = netsh nps import filename = $NPSConfigTempFile
#Delete Temporary File
remove-item -path $NPSConfigTempFile
#Compose and Write Success Event
$successText = "Network Policy Server Configuration successfully synchronized from $NPSMaster.
Export Results: $configExportResult
Import Results: $configImportResult
Script was run from $($MyInvocation.MyCommand.Definition)"
write-eventlog -logname "System" -eventID 1 -source "NPS-Sync" -EntryType "Information" -Message $successText
Create a scheduled task on your secondary server that calls powershell.exe with this script as a parameter. The screenshot below shows the syntax for this action. Set the task to run on a regular schedule. Our environment syncs once per day.
The account running this task needs Modify/Read permissions to the NPSConfigTempFile variable location as well as the ability to read the primary Network Policy Server configuration. Once setup, run the task and ensure that your primary configuration syncs to your secondary server.
Your environment now has a secondary server running NPS that will authenticate any client created on your primary server! Do you have any other tips for managing NPS?
*My goal with any article is to help the most amount of people possible. This means I don’t often write about specific technologies or products. If anyone would like more information about this, just leave a comment or shoot me an email.
**I wanted to make a boy band joke here so bad. Any suggestions?