This is the 6th article in the series. In the previous articles, we have discussed and implemented some Cisco firewall technologies such as the Cisco IOS Zone-based Policy Firewall and the Cisco Adaptive Security Appliance. We have also looked at securing the Cisco IOS management, control and data planes. In this article, we will be discussing AAA.

What is AAA?

AAA (pronounced ‘triple A’) stands for Authentication, Authorisation and Accounting. When Bob walks into the premises of his organisation, the security guard at the desk asks for and verifies his identity card. This is Authentication. As Bob goes about his daily activities, he decides to snoop around to the top floor where secret level research is being done. When he gets to the access door and swipes his access card, he is denied access because he is not authorised to get into that part of the building. Later that day, Bob gets called into the CSO’s office because after the logs have been reviewed, it was found that Bob tried to access a secure location in an unauthorised manner. Accounting gave Bob away. Bob is fired.

CCNA Training – Resources (Intense)

From the story above, we can define some terms: Authentication is verifying that someone or something is who they say they are; Authorisation is determining what the person or thing can do once they are authenticated; and Accounting is keeping track of what the person or thing did while authenticated.

In several articles in the past, we have come across these three parts in one form or another, the most famous being the use of usernames and passwords. This username/password combination deals with the authentication part of AAA. We may also be familiar with privilege levels. These levels implement authorisation because they permit or restrict what a user can do. What we may not be familiar with is the accounting aspect. Accounting is more or less logging; for example, user1 logged into the network on Monday, 21st of March at 12:00 noon.

However, AAA is not restricted to traffic terminating on the network device alone, such as SSH or Telnet. AAA can be configured for the network as a whole. For example if you have ever worked in an organisation where all systems belong to a domain and users have to be logged in to access the network, then there’s some form of AAA being implemented there. From this we can see that AAA is not a product; it’s more of a process.

Before we get into configuration, let’s review some basic terminologies and protocols that make up AAA.

AAA Server Types

With respect to Cisco IOS devices, there are basically two types of AAA servers: Local AAA server and Remote AAA server. Keep in mind that these are not standard terminologies that are used by Cisco, but I will make use of them for the sake of understanding. The local AAA server is also called the local database of the network device. When you configure usernames and passwords on a router, you are in effect using the local database of that router.

However, relying on the router for full AAA functionality can be very limiting. Remember we said that AAA is not restricted to traffic terminating on the network device alone. If you have a network of 500 users, your router or firewall may not be able to handle that. Also, having a central database used to manage users is beneficial as you only need to make one change on the central database and then all devices can retrieve the relevant details when necessary. This is one of the reasons for using remote AAA servers.

There are two basic protocols that are of interest to us when configuring remote AAA servers: RADIUS (Remote Authentication Dial-In User Service) and TACACS+ (Terminal Access Controller Access-Control System Plus). We will look at these in more detail soon but let’s first understand the naming conventions used in AAA when connecting to remote servers

When a user wants to connect to the network for example, the device with which the user connects is called the client. The router or firewall that forms a boundary between the network and external access is the Authenticator. Finally, the authentication server is the device to which the router/firewall sends the credentials of the user for verification.

Think about it like this: You have an appointment with the CEO of a company. When you get to the reception, the receptionist asks for your name. Since the receptionist doesn’t know you, she calls the CEO and says “Sir, Matt is here to see you“. The CEO verifies that he is expecting a Matt and tells the receptionist to send you up. In this scenario, you are the client, the receptionist is the authenticator, and the CEO is the authentication server.

The Cisco Secure Access Control Server (ACS) is an example of a remote AAA server that can handle all three aspects of AAA and supports multiple protocol connection from the network devices including RADIUS and TACACS+.


These are the two main protocols that the routers (and other Cisco network devices) use to communicate with the Cisco Secure ACS. RADIUS is an open standard protocol while TACACS+ is Cisco proprietary. The table below shows a comparison of the two protocols:



Open Standard Cisco-proprietary
Uses UDP Uses TCP
Does not support protocols like NetBIOS and AppleTalk Multi-protocol support
Encrypts only the password portion of the packet Encrypts the entire body of the packet (except the TACACS+ header)
Combines Authentication and Authorisation Separates AAA into individual parts

If you have non-Cisco devices on your network, you will have to use RADIUS, although you can combine both protocols on the Cisco Secure ACS as required by the network device. Also, because RADIUS combines the authentication and authorisation part of AAA, it does not offer as much granularity for command authorisation the way TACACS+ does.

Configuring AAA

Now that we have seen the basic aspects of AAA, we can begin configuration. The AAA that we’ll configure in this article series will be AAA for access to the network device itself and not for transit traffic (such as for 802.1X). We will use the network diagram below:

We will begin with a recap of how normal authentication occurs on the router without AAA and also how we can use username and password combinations for login.

Remember that by default, the VTY lines do not have a password configured on them but the “login” command is specified under the configuration. This means that if you try to connect remotely to a router with the default configuration, you will get the follow message:

You can issue the “no login” command under the VTY lines configuration and the router will allow login without requiring a password. But let’s configure a password under the VTY lines and try to login again using Telnet.

Now we will login from the management host.

As you can see, after logging in we are placed in user EXEC mode. You will also notice that unlike the ASA (that we saw in the previous post), if there is no enable password or enable secret configured, the user will not be able to get into privileged EXEC mode. A few ways to get around that are to either configure the enable password or assign the VTY lines with a privilege level of 15, for example. You can read about these here:

Taking it a step further towards AAA, we could configure username/password login and use the local database of the router for identity verification.

Now if we login from the management host again, we get a username and password prompt:

Notice how we are immediately placed in the privileged EXEC mode. This is because of the privilege level we configured for the user ‘adeolu’ above. Until this point, what we have basically done is authentication. We have touched a bit on authorisation by chance (the privilege level).

So how do we use authorisation with the local database of the router? Let’s assume there’s a user named Bob and because of his job description, he should only be able to monitor the interfaces and also enable/disable interfaces. This is an example of command authorisation because we want to specify what commands a user can use.

We can first configure the username and decide what privilege level to assign to him.

To configure the command authorisation, we need to think about where these commands will be performed. Let’s take it step by step:

  • Show interface status: The “show” commands are performed at exec mode (e.g. the router prompt will be like Router#). Therefore, we will specify the “show” command at the exec mode.
  • Enable/Disable interfaces: This is done in the interface configuration mode (e.g. Router(config-if)#). But think further, how do you get to the interface configuration mode? You must first be in the global configuration mode (e.g. Router(config)#). It means the user has to be able to enter the configure terminal command before he can even get to interface configuration mode.

This is what the running configuration looks like:

Notice that even though I didn’t explicitly specify “privilege exec level 1 configure“, it was added for me because I specified a much longer match of “privilege exec level 1 configure terminal“. I doubt that you need to understand command authorisation for your CCNA exam but I have to add it here for completeness’ sake.

Now let’s login with the username of novice-bob and see our command authorisation kick in.

Notice that we now have configure in the user EXEC mode. Also notice that there are a lot more commands than the ones we configured. These are the commands already in privilege level 1. We may decide to move commands between levels if we wish.

This kind of prompt (Router(config)>) may be unfamiliar to you because configure mode usually has the # sign. This is due to command authorisation.

This is a much stripped down version of what you get under the interface configuration but it is what command authorisation helps us achieve: it enables us to give the user only the commands necessary to perform his duties.

As we will see in the next article where we configure RADIUS and TACACS+, this command authorisation can be configured on remote AAA servers too. In fact, we can configure these servers to even specify what privilege level a user should be placed. These configurations can get really granular.

You have seen how even the local database of the router can be used to configure authentication and authorisation. Let’s leave AAA here for now but before we end this article, let’s play around with the Cisco Configuration Professional (CCP) tool a bit.

For the topic of this article, the parts that are of concern to us can be found under Configure » Router. Router Access and AAA are the folders we will be considering.

Let’s configure a user named ‘alice’ with a privilege level of 7. We navigate to Configure » Router» Router Access » User Accounts/View. On this screen, you will notice the users already configured on the router. We can Add, Edit or Delete users.

When we click on the Add button, we are presented with a pop-up screen where we can configure the attributes of the user. Notice the “Encrypt password using MD5 hash algorithm” checkbox: that is like saying username alice secret **** instead of username alice password ****.

You can click the OK button. Notice that while the CLI allows you to configure a password of less than 6 characters, the CCP tool requires that passwords be at least 6 characters in length. If you have the preview commands settings ticked, you will see a screen such as the one below:

Once the commands have been delivered, the user “alice” shows up in the user list.


This has been an introduction to AAA. In the next article, we will see the real power of AAA when we configure remote AAA servers using RADIUS and TACACS+ protocols. I hope you have found this article helpful and till next time, success in your studies.

Reference and Further Reading