• Technologies

  • Instructors

  • How to Add RADIUS to Your Cisco Logins

    As a follow-up to my previous blog on the topic of the aaa new-model command, I wanted to add another piece to the puzzle – that of RADIUS authentication. In the previous blog, I showed the result of adding to your configuration the aaa new-model command. In this blog, let’s explore one of the additional options that this configuration provides. I have the same Windows 7 client, but I have now added a Windows Server 2003 domain controller and configured it to be a RADIUS authenticating server. I have a Cisco router in the middle filling the role of the RADIUS client.

    For instructor-led Cisco training classes, see our Cisco Course Schedule

    Here is the topology:


    Figure 1

    I have issued the aaa new-model command already, but there is a bit more that must be done before we can test it. Let’s examine the rest of the config. The next step is to specify aaa authentication. The question mark is your friend, so let’s examine the options.


    Figure 2

    That’s the one I seek – login options. Walking ourselves through with the question mark…


    Figure 3

    We could create an authentication list, but let’s keep it simple and use the default option here.


    Figure 4

    Since we already know in this blog we are using RADIUS, that is the group we will specify. But note an important keyword option before we hit Enter:


    Figure 5

    I am not required to add ‘local’ to the end of the command, but it is a good idea to do so. Why? Because if you do not, and your RADIUS authenticating server is unreachable, you will be unable to gain access to your device. So it is like the net under the trapeze. This does not mean that if a user reaches the server yet fails authentication, that a locally configured user name will succeed. Locally configured user names will only succeed if for some reason the RADIUS server is unreachable; say for instance that it is offline, or the network is experiencing connection issues. In such a case, a user will still be able to access the device if the ‘local’ keyword has been specified.

    You may also like:  Get your CCNA R&S – it’s getting a makeover CCNA v3.0

    But wait! There’s more! (Insert your pocket fisherman here.)


    Figure 6

    It is wise to specify from what source the authentication message will originate, and it is necessary to specify the IP address of the authenticating server as well as the shared secret key that will pass between the client and the server. Note that this is not the same (or should not be the same) as the password of a valid user account. The valid user name and password are now stored on the Domain Controller in Active Directory. Since I have already configured the Server 2003 box, I should be done with the configuration piece. I will attempt to use Putty from my Windows 7 box to access the Cisco router. The Cisco device should not be performing authentication locally – it should be handing that off to the 2003 box. If authentication is successful, I will have a remote connection to my Cisco device. Let’s try:


    Figure 7

    Just for kicks, I enabled debug radius authentication on the router. Figure 7 shows successful connection, but let’s look at the debug output:


    Figure 8

    There is a bit more output, but not all would fit in one screen. Yet this is sufficient to show that the user name ‘netadmin’ was attempting to access the device and that RADIUS was being used as the authentication method. Note the password is NOT showing in clear text – a benefit one would expect from a secure authentication method. One other verification step can be done here. Since we have just seen that the authenticating server is accessible, let’s kill our connection and attempt to log in using a known valid LOCAL user name and password. This should fail, but it is nice to know in advance when to expect failure as a sign of success! Here is the local information:

    You may also like:  A Cisco solution that’s perfectly NAT-ural


    Figure 9

    And here is the attempt to access the device using those credentials (with a reachable RADIUS server):


    Figure 10

    So there it is – RADIUS authentication working successfully, and a known good set of credentials failing when the RADIUS server is online. There are more tweaks and options by far than I have covered here, but this does serve as an introduction to the process – just in case you get your CCNA R&S and your new company’s network is using RADIUS authentication. Also note that if this happens to you, you too can lab it up in GNS3 and practice at home so you don’t look inept at work. Just my two cents.

    If you have questions or comments, please feel free to post them!

    Until next time…

    Mark Jacob
    Cisco and CompTIA Network + Instructor – Interface Technical Training
    Phoenix, AZ

    See what people are saying...

    1. Pingback: How to add TACACS+ to your Cisco logins

    Share your thoughts...

    Please fill out the comment form below to post a reply.