We are gradually coming to the end of this series. In the previous post, we saw an introduction to AAA and implemented some form of AAA on the router using its local database. We also introduced the two main protocols used to connect to remote AA servers: RADIUS and TACACS+. In this article, we will discuss and implement AAA for remote authentication servers (Cisco Secure ACS). We will continue using our network diagram from the previous article:

For the authentication server, I have the Cisco Secure ACS 4.2 installed on a Windows server 2003 virtual machine. Please note that for your CCNA exam, you should be familiar with later versions (5.x) of the Cisco Secure ACS though the concept is fairly the same.

CCNA Training – Resources (Intense)

To configure AAA, there are two parts we have to consider: on the router (or network device) side and on the remote AAA side. We will begin with the router side before we move over to the Cisco Secure ACS.

Configuring AAA on the router

From here onwards, be aware that AAA should be configured with care because a wrong configuration can mean being locked out of your router. We will see how this can happen as we continue. To configure AAA on a Cisco IOS device (and Cisco ASA), the steps are listed below:

Enable AAA

Before enabling AAA, you want to make sure that your console access is not entirely restricted, thus creating some form of a backdoor. It is usually a wise choice to have a username and password configured on the local database of your router. But even this is not enough since AAA relies on the configured method lists to make its decision of whether to authenticate a user. I’m jumping the gun a bit here but all these will become clear soon enough.

By default, AAA is not enabled on the Cisco router as you can see from the configuration snippet below.

In the last post, we configured the router VTY lines to use the local database for authentication.

At this point, I’d like to take us back to the default setting of “login” so that we can know what exactly AAA does when it is enabled.

I will confirm that it is back to normal by opening a Telnet connection to the router. I should only be asked to provide a password (the one configured on the line).

So we are back to normal. Now, let us enable AAA using the aaa new-model command.

For the sake of curiosity, let’s open a Telnet connection to the router again:

Now it’s asking me for a username! The reason is this: once you enable AAA on the router, local authentication (authentication using the local database) is automatically applied to all lines on the router (except the console line). So imagine you were configuring a router via a remote session and you enable AAA, and then for some reason you lose connection and have to login again: you will be required to provide a username and password. If you don’t have any configured on your router’s local database, you will have to go to the device physically and connect via console! This is why I mentioned at the beginning that you should always configure a backup username and password first before enabling AAA.

Configure AAA servers

If you intend to use the local database for all AAA functions, then you may skip this step. At the same time, if you wanted to use only the local database, you may as well not have enabled AAA in the first place as we saw in the previous article. If you enable AAA, you must probably want to perform authentication using remote AAA servers.

You may configure either one individual server or multiple servers in a group, if for example you have 3 Cisco ACS Servers and you want to have redundancy. The protocol used to connect to the server must also be specified. To configure an AAA server you use the radius-server (for RADIUS servers) or tacacs-server (for TACACS+ servers) command.

In the above configuration, I have configured both a RADIUS and a TACACS+ server identified by its IP address at 192.168.0.100 and a password used to connect between the router and that AAA server. To define servers in a group, you must first specify the server in the global configuration as we have just done and then create a server group using the aaa groupserver command. For example:

Method lists

Method lists are ways to apply controls for the different parts of AAA – Authentication, Authorisation, and Accounting – to the various parts of a network device. For example, you may want all users accessing the console to be authenticated using the local database of the router while all those who are logging in via a remote connection to be authenticated using a TACACS+ server.

Before enabling AAA, the AAA commands are not available to you. I’ll disable AAA and show you what I mean:

Notice that the only option available is new-model. Once you enable AAA however, you have a list of aaa commands.

So if you try to configure a method list and the command fails, you may want to check that you have first enabled AAA. The general format for configuring method lists is:

aaa [authentication | authorization | accounting] <process> {<list name> |default} <method>

As we will see, <process> can have different options depending on what AAA feature we are implementing. The <list name> is the name of the method list and can be defined as whatever you want. A defined method list must be applied to a line for it to be used. This is unlike the ‘default’ method list which is applied to all lines except those lines that have defined method lists. The last portion <method> is used to specify what method should be used for AAA, i.e. “local” for local database, “group radius” for RADIUS servers and “none” for no restriction.

Let’s use an example to make things clearer. Assume we want all users logging in via remote session to be authenticated using a RADIUS server; we can configure thus:

In the above configuration, we can then attach the method list called “VTY-AAA” to the VTY lines. Notice that we have used “login” as the <process>. This is used for authentication like console, VTY lines and AUX ports. Other options for <process> when configuring an aaa authentication method list are highlighted below:

The most commonly used ones are login, enable and ppp. The diagram below shows the possible list of <method> that can be used with aaa authentication method lists.

Note also that you can specify more than one <method> (up to 4 methods). These methods will be tried in the order in which they are listed. For example:

The above configuration tells the router to use “group radius” for the authentication logins for the VTY-AAA list and if the radius server(s) is not available, then it should fall back to the local database.

It is important to understand what “is not available” means. If a user wants to login and send his username/password to the router, the router tries to contact the RADIUS server. If for some reason the RADIUS server is offline (or does not respond), the router will use the next configured method which is the local database in this case. If however the RADIUS server responds and says that the credentials the user presented are not valid, then the router rejects the login; it does not check the next method. Remember this.

To reduce information overload, let’s focus on authentication method lists for this article. We will configure authorisation and accounting method lists in the next article.

Apply the method list

As we have said earlier, if you create a method list using the name “default”, this method list is applied to all lines of the device except those that have been explicitly configured with named method lists.

In our example, we have configured a named method list called “VTY-AAA”. We have said that we want all users who connect remotely to authenticate using a remote RADIUS server. We updated the policy to include a local database fall back option. To enable this list, we need to attach it to the VTY lines. We do this by using the login authentication command under the line configuration.

Notice from the above that we do not have “login local” as an option anymore. This is one of the things about the aaa new-model command – it disables OLD forms of authentication and enables NEW ones. Let’s view the entire configuration we have added:

Notice how the radius-server configuration now includes an auth-port and acct-port option. These are the default ports used to communicate with the RADIUS servers. Below shows the listening ports on my Windows Server 2003 (using the netstat –a command in command prompt):

Those are the RADIUS ports. If you change these ports on your server for example, remember to change them in your router configuration.

Cool. What happens if a user tries to login remotely now since we have not configured our Cisco Secure ACS? I will enable debugging on the router, open a remote connection using Telnet and we will see what happens.

Now I open the remote connection and I am presented with the username prompt.

Once the connection is open, the first debug message on the router is shown below:

So we see that it is using our ‘VTY-AAA’ method list. The user then enters the username and presses ENTER.

The RADIUS authentication debugging shows that the router now asks for a password.

Once the user enters the password, the router now has all the information needed to send an ACCESS-REQUEST packet to the RADIUS server. This packet will contain the information necessary to authenticate the user including his username and password.

Notice that other parts of the packet are in clear text except for the password. This is because RADIUS encrypts only the password portion of the Access-Request packet. However, we have not configured our RADIUS server so it won’t be able to connect. It tries to retransmit the packet three times:

All the while, the user trying to connect is still waiting and it seems as though his telnet session is frozen at the login screen. After three retransmissions and still no response, this is the message we get:

An error code of ‘FAIL’ is returned and the router falls back to the next configured method, if any. If no other method is configured, the remote user will NOT be able to login. In our case, it will fall back to the local database and the user gets a prompt as shown below:

No, not to worry, you are not supposed to know this level of debugging for the CCNA exam but remember that these articles are meant to be more about imparting knowledge than about just passing the exam.

Configuring the Cisco Secure ACS

Like I said at the beginning of this article, you are meant to be familiar with Cisco Secure ACS version 5.x. Since I have version 4.2, I will not walk you through the ACS interface; I will only show the steps needed to get AAA between the router and ACS. The steps required are listed below:

There are other settings that you may require especially for users, but these steps will do for now as we are only dealing with authentication. Before we proceed, I want to show you what was happening on the ACS when the router was trying to send authentication requests to it. This is a snapshot of the Failed Attempts log file:

This means the packets were getting there quite alright but because there’s no configured communication between the ACS and the Router, the ACS sees it as “Unknown NAS”. Now, let’s configure that communication.

Create Network Device Groups

Network Device Groups help you group similar network devices in a logical manner so that you can apply a similar policy on them. For version 5.x, navigate to Network Resources » Network Device Groups » Device Type and click on Create. In previous versions like mine, go to Network Configuration and then click on Add Entry.

I will use the default ‘Not Assigned’ NDG for my configuration since that’s where my AAA server is already configured for.

Add AAA Clients

In version 5.x, this is done by navigating to Network Resources » Network Devices and AAA Clients and then clicking on Create. In my version, I will select the NDG, and click the Add Entry button which shows a page similar to the one shown below. Fill in the required details and keep in mind that we want to use RADIUS protocol first.

Notice that the Shared secret must match the one configured on the router. Another thing you may want to consider is the IP address. If your router has several interfaces and can route traffic through several of these interfaces, you can specify the source interface it should use for RADIUS or TACACS packets (using ip [radius | tacacs] source-interface) and that this is the IP address you should configure here. Now, the router and ACS are set to communicate but we must add the user to the ACS database first so that users can login.

Add users to the ACS database

You can create user groups and assign individual users to these groups. In version 5.x, you create groups by navigating to Users and Identity Stores » Identity Groups. You add users by navigating to Users and Identity Stores » Internal Identity Stores » Users. In version 4.x, you create users under User Setup.

I will create this user with a password of cisco. Since we are using the local database for fall back, it is important that the username/password combinations on the external AAA server are replicated on the local database, else it is pointless. So let’s create this user on our router also.

And there you have it! AAA is configured and the router is synced with the Cisco Secure ACS. We can test our AAA configuration from the router using the test aaa command.

If it is successful, we will get a message such as the one below:

If it fails, we will get a message similar to the one below:

Before we wrap up this article, let’s open that Telnet session again and see the debugging now that a RADIUS server is available.

Notice the Access-Accept packet, meaning that the authentication was successful. If it was unsuccessful, we will have gotten an Access-Reject packet as shown below:

Summary

In this article, we have configured AAA on a Cisco router to connect with a Cisco Secure ACS server. We have seen and implemented the steps required on both the router and the external AAA server. We have also seen a shortcut of testing our AAA configuration from the router. In the next article, we will configure AAA settings for use with TACACS+ using the CCP Tool. We will also look at authorisation and accounting method lists.

Reference and Further Reading