[LAB] AAA concepts

Taken from the exam blueprint, the goals for this lab are the following:

2.2.b Configure administrative access on a Cisco router using TACACS+
2.2.c Verify connectivity on a Cisco router to a TACACS+ server

For this lab session I’ll be using:

Ubuntu 19.04 host (10.0.0.15)
Ubuntu 18.04 LTS server running tac_plus (10.0.0.11)
7200 series Router (10.0.0.1)

Configuration

To setup the TACACS+ server I followed this guide by Keeran Marquis. His guide is for Ubuntu 14.04 LTS but I can confirm it worked fine for 18.04 LTS.

Below is the server configuration file. The first line is where the accounting logs are stored. Next is the encryption key that’s used between the Router and the TACACS+ server. They have to be identical on both. Following that I’ve created two users. Will and test. Will is a member of the admin group. As TACACS+ implicitly denies all commands I’ve had to add the command ‘default service = permit’. Along with setting a privilege level of 15 this will give whoever is a member of the admin group access to do anything. The test user is a member of the read-only group. Even though whoever is in this group has a privilege level of 15 what they can do with it is very restricted.

After verifying that the TACACS+ server is operational and it’s able to reach the Router it’s time to configure the Router.

Router configuration

In the event that the TACACS+ server is unreachable I still need to be able to get onto the device. Below are two users that are setup locally on the Router.

After thoroughly testing local access enable AAA globally with the following command:

R1(config)# aaa new-model

Configure the TACACS server settings:

R1(config)# tacacs server tacsrv
R1(config-server-tacacs)# address ipv4 10.0.0.11
R1(config-server-tacacs)# single-connection
R1(config-server-tacacs)# key testing123
R1(config-server-tacacs)# exit

* the single-connection command will maintain a single TCP connection for the duration of the session.

Configure the first part of AAA, Authentication.

R1(config)# aaa authentication login default group tacacs+ local-case
R1(config)# aaa authentication login NOAUTH none
R1(config)# aaa authentication login httpAUTH group tacacs+ local-case
R1(config)# line con 0
R1(config)# login authentication NOAUTH
R1(config)# exit
R1(config)# ip http authentication aaa login-authentication httpAUTH

The first three commands are defining 3 different method lists. The first one being default. The default list is automatically applied to all login attempts (console, vty, aux, and http sessions) unless explicitly stated. I’ve provided an example below. You can see the VTY lines have not been given a login authentication method list so the default is used.

If you’re connecting to the Router via its console port the authentication method list is NOAUTH which has a value of none, meaning no authentication required. The last method list is specifically for ip http. So say for example you were attempting to use CCP on port 80, the custom method list of httpAUTH would be requested in that instance.

In the event that the TACACS+ server isn’t reachable the fall-back option is local-case. That will use case-sensitive local access for authentication.

That’s authentication complete, next up authorisation. Before enabling authorisation ensure that you have a local user that has full access rights otherwise you’ll lock yourself out!

R1(config)# aaa authorization exec SRVEXEC group tacacs+ local
R1(config)# aaa authorization commands 15 SRVCMD group tacacs+ local
R1(config)# aaa authorization config-commands
R1(config)# line vty 0 1869
R1(config-line)# authorization exec SRVEXEC
R1(config-line)# authorization commands 15 SRVCMD

The above commands add authorisation for access to the EXEC shell (the CLI) and authorisation for access to privilege level 15 and global configuration commands. Both authorisation lists are then applied to the vty lines. Similarly to the authentication method lists if the TACACS+ server isn’t reachable it will fall back to the local database.

Finally onto accounting. AAA accounting offers the following services that can be kept track of:

system tracks system-level events such as reloads.
network tracks network-related service requests.
exec tracks EXEC shell sessions.
commands tracks all commands at the specified privilege level.

R1(config)# aaa accounting exec ACCEXEC start-stop group tacacs+
R1(config)# aaa accounting commands 15 ACCCMDS stop-only group tacacs+
R1(config)# line vty 0 1869
R1(config-line)# accounting exec ACCEXEC
R1(config-line)# accounting commands 15 ACCCMDS

The first command will send an accounting record at the start of an administrative access session to the device’s EXEC process, and another accounting record to be sent at the end of the session. A second command is added that causes an accounting record to be sent for every privilege level 15 command and every configuration mode command that is entered by the user. Both accounting lists are then applied to the vty lines.

Testing and verification.

On the TACACS+ server I setup two users. will and test. Both are using the same password lab123 (the first is hashed using des and the second is hashed and salted using MD5). Using the following commands we can test both:

R1#test aaa group tacacs+ will lab123 legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

R1#test aaa group tacacs+ test lab123 legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

Below is a screenshot highlighting the successful SSH connections using both will and test user accounts. It also shows the accounting log file that confirms the successful connection and disconnection from both users and how long they were connected for.

Here’s an example of the user test attempting to run some show commands that it’s not authorised to use:

Next I’m now logged in as an administrator that’s making changes. Here’s the output of the accounting log file showing changes that have been made:

For debugging purposes the following commands are very useful.

R1# debug aaa authentication
R1# debug aaa authorization
R1# debug aaa accounting
R1# debug tacacs

Conclusion

Having the ability to centrally manage users, limit access and also view any changes that have been made really highlights the benefits of having AAA. This was a fun lab to complete.

 

Leave a Reply

Your email address will not be published. Required fields are marked *