Controlling Logons to Cisco Devices with Active Directory

Something I see quite often is local passwords being used to authenticate network administrators onto switches and routers. While this is fine for smaller organisations with a small IT team and few network devices, it can quickly become a headache when trying to update the password across all devices or add a new user. There are two great solutions around this, TACACS and RADIUS.

TACACS (Terminal Access Controller Access Control System) was originally developed by Cisco however is now an open standard used to provide AAA (Authentication, Authorisation and Accounting). TACACS offers benefits over RADIUS (Remote Authentication Dial-In User Service) such as the use of TCP (RADIUS uses UDP) and encryption of the whole AAA information while in transit (RADIUS only encrypts the password). TACACS also offers  granular command specific authorisation whereas RADIUS does not. In this post however I’ll be only focusing on RADIUS given its prevalence in many organisations.

To enable a basic level of authentication from a Cisco device to a RADIUS server you need to firstly setup the RADIUS server to accept the connection. To do this, setup a RADIUS client (in this example I’m using a Windows NPS role) with an associated key. Assuming you’ve left the default Connection Request Policy intact you’ll need to create a Network Policy to define who is able to log into the device. In my lab I’ve used the below settings:

Don’t be put off by the “Unencrypted authentication (PAP, SPAP)” as RADIUS will still encrypt the password in transit.

You may have also noticed I’ve added the RADIUS attributes “Vendor-Specific: shell:priv-lvl=1” and “Service-Type: Login” in the above Network Policy. Without these options the device will allow users who pass the conditions of the policy full privileged access, while these options specify a matching user is only permitted to carry out the most basic user functions on the device. Replacing the Vendor-Specific attribute with “shell:priv-lvl=15” allows full control over the devices functions.

This is a brilliant way to rapidly grant a new network admin access to the infrastructure estate while simultaneously controlling who has access to what.

On the Cisco device only a few commands are needed:

aaa new-model
aaa authentication login LabRadius local group radius
aaa authorization exec default local group radius
radius-server host 172.16.0.20
radius-server key CiscoLab

And on the vty lines:

login authentication LabRadius

If a user who’s been given only level 1 access successfully logs in using their AD credentials and then tries to enter Privileged Exec mode by typing “enable” they’ll be presented with either “% Error in authentication.” if no enable password is set locally on the device, otherwise a password prompt will be displayed.