AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2
I thought I would cover a quick post to demonstrate setting up Active Directory authentication for a Cisco router or switch IOS login. This will be using AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2 to authenticate users in Active Directory on Cisco IOS devices.
As with all my labs a picture paints a thousand words so here is the GNS3 Network topology we will be using, this is also being used for 802.1x which will be covered in later post:
So here is quick run down on the gear we will be using just for this lab:
R1: Cisco IOS (C7200-ADVENTERPRISEk9-M), Version 15.2(4)S4
Server 2012 DC: Windows Server 2012 R2 ( Active Directory Domain Services and Network Policy Server role.
Just to demonstrate a lab as simple as the below could also be used to test this:
Active Directory Configuration:
I will be assuming that AD and the NPS role have already been installed. Prior to jumping into the NPS configuration you will need to create an AD group for the users that will be logging into the Cisco equipment, add a couple of test users to this group. In my case I have simply created a group called ‘Radius’ and have added the user ‘Adam’.
Open the NPS console.
Right click on the NPS(Local) tree node and select ‘Register server in Active Directory’:
Now create the Radius clients, in our this case this is R1:
Now we need to configure the Network policy:
Add our ‘Radius’ AD group. You can tighten the control here by specifying further conditions such as the ‘friendly name’ (R1) or the local IPV4 address of the radius client, in a production environment you would want to lock this down further for now we are just going to add the the user group to authenticate:
Grant Access for this group:
Configure the appropriate authentication methods:
Change the Standard Radius Attributes by removing ‘Framed-Protocol – PPP’. Edit the ‘Service-Type’ value to ‘Login’:
Add a Vendor specific attribute, this allows the radius server to pass the privilege level though the cisco router which we shall see later in the debugging. The value needs to read ‘shell:priv-lvl=15′.
You can create several policies for the different privilege levels. For example you could create a group in AD called ‘Cisco Users Priv 1’, associate this group to a policy and in the below option use the value ‘shell:priv-lvl=1′. When that user logs in the policy will match that user and the NPS use the matched policy passing privilege level 1 through to the router or switch.
Cisco IOS configuration
Create a a user with privilege level 15, we wil use this as our fall back should the router not be able to contact the radius server it will use the local AAA database.
R1(config)#username Admin privilege 15 secret cisco12345
Now we will setup the main parts to the radius configuration, tell the switch we would like to use radius and the group RAD_SERVERS:
R1(config)#aaa group server radius RAD_SERVERS
Specify the radius server that we would like to use in our case 10.0.0.2 is our NPS, the auth and acc ports and also the secure key we used:
R1(config-sg-radius)#server-private 10.0.0.2 auth-port 1812 acct-port 1813 key cisco R1(config-sg-radius)#exit
Specify that for the default login for authentication an authorization that we want to use the group called RAD_SERVERS that we have just created and if that fails we use the local database. This is particularly important so we do not lock ourselves out on the router:
R1(config)#aaa authentication login default group RAD_SERVERS local R1(config)#aaa authorization exec default group RAD_SERVERS local if-authenticated
All together this looks like the below:
R1(config)#aaa group server radius RAD_SERVERS R1(config-sg-radius)#server-private 10.0.0.2 auth-port 1812 acct-port 1813 key cisco R1(config-sg-radius)#exit R1(config)#aaa authentication login default group RAD_SERVERS local R1(config)#aaa authorization exec default group RAD_SERVERS local if-authenticated R1(config)#aaa authorization console
We can test simply by logging out and back in.
It obviously goes without saying you need to test the authentication to the Radius server, exit right out of the console and log back in using your AD credentials.
If all has been configured correctly you should be able to login. its also worth testing the fall back option configured for local AAA authentication. We can do this just simply stopping the NPS service then try the local credentials, again all being configured correctly you should be able to login.
There are a few useful debugging commands we can use to monitor and troubleshoot the authentication these being:
R1#debug aaa authentication AAA Authentication debugging is on R1#debug aaa authorization AAA Authorization debugging is on R1#debug radius Radius protocol debugging is on Radius protocol brief debugging is off Radius protocol verbose debugging is off Radius packet hex dump debugging is off Radius packet protocol debugging is on Radius elog debugging debugging is off Radius packet retransmission debugging is off Radius server fail-over debugging is off Radius elog debugging debugging is off R1#
This time when we login we can see the debug information for an attempted login, it should look similar to this, note the highlighted area’s:
I hope this has been informative.