This is the last article on AAA. In the last 2 articles, we began an introduction on AAA and configured authentication method lists using a remote AAA server – the Cisco Secure ACS. In the last article, we only configured this using the RADIUS protocol. In this post, we will see how to configure AAA using TACACS+ and the Cisco Configuration Professional (CCP) tool. We will also touch on authorization and accounting method lists.

Our network diagram remains the same as before:

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

Using CCP to configure AAA with the TACACS+ protocol

In the previous article, we configured a method list for authentication using the ‘group radius’ and ‘local’ methods for authentication. A snippet of this configuration is shown below as a reminder:

We then attached this list to the VTY lines. What we wanted to achieve was that users who were connecting remotely (Telnet and SSH) would be authenticated using this method list. If for any reason the remote AAA server was unavailable, we wanted to fall back to the local database.

Now let’s look at the same authentication method list but using the TACACS+ protocol (with a local database fall back). We will configure this through the CCP. To begin configuration, navigate to Configure » Router » AAA.

Let’s explore the options in this tab before going into our TACACS+ configuration.

  • AAA Summary: This gives us a summary of our AAA configuration including configured AAA servers and groups and a count of AAA method lists. As you will notice, it contains a summary list of all other options you can configure.

  • AAA Servers and Groups: This folder contains options to view, edit and delete AAA servers and groups. The figure below shows the servers we have configured on our router.

  • Authentication, Authorization and Accounting Policies: These allow you to configure method lists for the different aspects of AAA. CCP may only allow you to configure a limited number of processes, e.g. login, 802.1X and NAC for authentication.

Since we are configuring TACACS+, it may be better for us if we begin all TACACS+ configurations fresh. In that case, I will delete the TACACS+ server we already have configured and we can walk through adding it.

First thing to do will be to add the TACACS+ server. We add a server by navigating to Configure » Router » AAA » AAA Servers and Groups » Servers and clicking on the Add button.

Our AAA server is located on IP address 192.168.0.100. Also notice that you don’t have to specify a key when adding an AAA server. This is because you can configure a global key that all servers should use, like if you have more than one server and you want to use the same shared secret key.

You may get an informational message about negating TACACS+ source-interface and timeout commands. Keep note of this if it needs to be part of your configuration. If you have “preview commands” enabled, you will get a dialog like the one below. As you will notice, the command is similar to the one for adding a RADIUS server.

The TACACS+ server which we configured now appears in the AAA servers list.

We can then go ahead and create our authentication method list. Let’s create another list to be applied to the VTY lines but that would use TACACS+ and the local database as its method. We do this by navigating to Configure » Router » AAA » Authentication Policies » Login and clicking on the Add button.

You can either leave the name as “Default” which will be applied across all lines, or “User Defined”. We’ll leave it as “Default” for this example. Use the Add button to specify the methods (up to four) to use. You can use the CTRL or SHIFT keys to select more than one method at once.

Click OK when done. The command to be delivered to the router is shown below. The differences between this configuration and the one we did for RADIUS in the last article are the name and the methods.

That’s it on the router side. I will go ahead and add this router to the Cisco Secure ACS, specifying TACACS+ as the protocol for communication. The steps are similar. Please refer to the previous article if you need more guidance on this.

So how do we test this? Remember that we already have the “VTY-AAA” method list on all VTY lines and that the one we just created (default) applies to all lines that don’t have a user-defined method list – all lines including the console line. This means that by creating a default method list, I have implicitly overridden the exception of username/password being required for console access.

Let’s see what I mean in action. I will remove that command we just configured and try to access the console to see the way it behaves initially.

I hit the Enter key and immediately I have console access.

The reason this happened is that previously (in the last article), we configured a user-defined AAA method list and applied it only to the VTY lines. Remember that we mentioned in the last article that when AAA is enabled, “local authentication (authentication using the local database) is automatically applied to all lines on the router (except the console line)“. Therefore, the console has some exception policy applied to it. Now, let’s put our TACACS+ method list back and logout and log back in.

As you can see from above, the console now requires that I enter a username and this is because of the ‘default’ authentication method list that is applied to all lines except those with user-defined method lists.

I can show you the ‘Passed Authentications’ list on the Cisco Secure ACS to show that the remote AAA server is in fact being used.

You may want console access to be unrestricted especially if it’s a practice router. You can do this by creating a console specific method list and specifying the method as “none” or “local” for example.

That should be enough with authentication. Let’s move on to authorization.

Configuring authorization method lists

Authorization allows you control what a user can do when connected to the device or to the network. The configuration format for authorization method lists is similar to that for authentication. Let’s view the options:

The one we are concerned with in this article is “exec” because it has to do with opening a shell on the router. A CLI session is an example of a shell. We will create an authorization method list to ensure that remote users are placed in appropriate privilege levels when they log in.

The above configuration tells the router to authorize EXEC sessions using the TACACS+ protocol and falls back to the local database if the TACACS+ server(s) is not available. We will apply this method list to the VTY lines now using authorization exec <method-list>.

Without further configuration, let’s open a remote connection and see what happens.

I will run a debug session on the console while trying to login so we can see the messages generated.

A screenshot of the debug messages are shown below:

Because we are authorizing exec sessions, you will notice the “AV service=shell” in the figure above. AV stands for Attribute-Value. To keep this simple, I will not go into details about these attributes and services. However, we need to configure the ‘shell’ settings for the user in the Cisco Secure ACS database. The authorization configuration varies between TACACS+ and RADIUS. This is because TACACS+ separates each AAA process into individual processes unlike RADIUS which binds authentication and authorization together. Also, the configuration settings are different depending on the ACS version you are using.

I would also like to point something out here: by default, even if you create a default authorization method list, authorization is not applied to console access. You have to specify the aaa authorization console command to override this behaviour.

For those who may have previous ACS versions (before 5.x), you need to enable shell authorization in the TACACS+ Settings section under the user configuration. The one we are interested in is the ‘Privilege level’ setting. I will give the ‘intenseschool’ user a privilege level of 7.

Let’s try to login again.

Now we have access. Let’s show our privilege level also.

Before we leave this section, let’s see the authorization debug packets generated on the router.

As can be seen above, the AV pair for privilege level is “priv-lvl”. There are numerous other AV pairs like those used for authorization and in this article, we have barely scratched the surface but it’s okay for the CCNA series.

Configuring accounting method lists

Accounting does not get as much attention as the other two processes of AAA but it can be quite useful for keeping track of activities. Let’s take a look at the options available under an accounting method list:

The easiest one for us to test is ‘exec’ since we are doing authorization. Accounting for authentication logins is already viewable under ‘Passed authentications’ and/or ‘Failed attempts’.

Two things to note: ‘start-stop’ will record both the beginning and end of the sessions; the other options are ‘none’ and ‘stop-only’. Also, there is no local database option for accounting, only servers or server groups. Below is a screenshot from the TACACS+ Accounting page.

Summary

In this article, we have concluded on AAA by configuring authorization and accounting method lists. We have also seen how to use the CCP tool to configure these settings through a user interface. While this article has used the Cisco Secure ACS version 4.2, the exam expects the candidate to be familiar with version 5.x. The underlying concepts of remote AAA servers are however the same.

In the next article, which will probably be the concluding article of this series, we will discuss Cisco IPS. I hope this has been helpful to you and till next time, success in your studies.

Reference and Further Reading