Authenticate Cisco Devices Against Microsoft NPS Using Wildcards
In many deployments we do as consultants, our customers may not have all of the pieces of the puzzle that we need to finish our project. One of those missing pieces is frequently a RADIUS/TACACS+ server. We’ll skip the RADIUS vs. TACACS+ discussion for now, and assume we’re setting up a Microsoft Server with the NPS role. Since a lot of customers are a Microsoft shop already, and NPS is part of the OS, the customer doesn’t have to shell out the cash for Cisco ACS.
One of the things that I would always find annoying (but not annoying enough to spend the time to research – until now of course) is that you had to specify each RADIUS client that you wanted to authenticate. When there’s 5 or 10 devices, that’s not a big deal, but when you have hundreds of devices, it gets old quickly. Here’s a way (I’m sure there are others, but this is how I solved the issue), to use NPS to authenticate any number of devices without having to manually specify each client individually.
We’ll assume that you have already added the NPS role to the server. (If not, click here) The first step is to add a RADIUS client. In our case, we’ll be adding subnets instead of a specific client IP. Adding a specific subnet works well if your customer has a dedicated management vlan or a consistent addressing scheme, but this customer did not, so we had to include all of the RFC 1918 address space.
Open the NPS console, and expand “RADIUS Clients and Servers” then right click “RADIUS Clients” and choose “New.”
The friendly name doesn’t matter…I used the subnet as the name. The IP address of the client in this case, will also be the subnet. Enter the shared secret and click OK. This will cause the NPS server to process requests from any device originating in the 10.0.0.0/8 subnet. I also added 172.16.0.0/12 and 192.168.0.0/16 as “RADIUS Clients” as well. Here’s the results:
Now that we have our RADIUS clients identified, we need to create a Connection Request Policy. So expand “Policies” then right click “Connection Request Policies” and then “New”
- Policy name: Whatever you want to call it. I chose to call mine “Accept Request From Any Device” Leave the type of network access server as default
- Add a condition: Scroll down about halfway and add “Client IPv4 Address” – here’s the import part…in the address field, specify *.*.*.* which is the wildcard for any IPv4 address.
- Accept the defaults for the rest of the wizard.
Here’s what we end up with:
Now we need to tell NPS who should be able to log into these devices. For this, we need to add a network policy. Right click “Network Policies” and create a new one. I called mine “Network Admins.”
- Type of access server – leave as unspecified. Click Next.
- Add a condition: Windows Groups – then choose the AD group where your admin user accounts live. Click Next.
- Leave as “Access Granted” under the “Specify Access Permission” screen
- IMPORTANT: On the “Configure Authentication Methods” screen, we need to check “Unencrypted authentication (PAP,SPAP)” – Click Next
- Accept the defaults for the rest of the prompts.
So now we have created a configuration that will authenticate any network device (that has the correct shared secret, of course) against an AD group of your choosing. In our case, any AD user that was in the group had access to the devices. We didn’t differentiate between privilege levels or anything like that.
You can read more about regex matching in NPS over here: Using Regular Expressions in NPS
NOTES: A follow up tweet from @verbosemode indicates that there is a cap on the number of Radius clients (50) that Windows Server 2008 R2 Standard supports. Also, apparently you have to have Enterprise Edition to use CIDR ranges. More info can be found here: http://technet.microsoft.com/en-us/library/dd365355(v=WS.10).aspx