AAA on the Cisco ASA

From my experience as a Network Security Engineer, I have worked on many Cisco projects involving AAA on the routers but not so many that involve AAA on the Cisco ASA. I find that a bit weird considering that the Cisco ASA is the real security device. I wonder if the slightly different configuration on the Cisco ASA is responsible for this.

Note: AAA stands for Authentication (who a user is), Authorization (what a user can do), and Accounting (what a user did).

When speaking about AAA, there are generally two areas in which AAA is applied: Device administration and Network access. Device administration has to do with the management of devices (e.g. SSH access to a device) while Network access deals will granting users access to network resources (e.g. VPN user accessing a local server).

Note: Sometimes, Cisco differentiates Network Access from VPN access but we can use the broad phrase “Network Access” here to mean both.

The statement I made above about AAA on the Cisco ASA not being as common as AAA on other devices like Cisco routers is actually only true for AAA when used for Device administration. When it comes to Network access, AAA on the Cisco ASA is as common as (or even more common than) AAA on other Cisco IOS devices.

Therefore, what we will do in this article is to explore AAA on the Cisco ASA as used for Device administration. We will discuss the different AAA components as relevant to the Cisco ASA, identify the AAA servers that can be used with the Cisco ASA, and then look at a lab of how these features can be applied on the Cisco ASA especially in comparison to other Cisco IOS devices.

AAA on the Cisco ASA

Generally speaking, AAA provides an extra level of protection instead of using a blanket security policy for everyone. For example, you can filter access to a device using an access list (ACL). However, if different groups of users will be accessing that device to perform different functions, then your ACL cannot provide that level of protection. Using AAA, you can turn on user-level security functions such that network managers have full access to the device while support staff can only perform monitoring, for example.

Let’s now explore the three AAA functions as applicable to the Cisco ASA.

Authentication

In terms of Authentication, the ASA can be configured to authenticate the following:

• Management access e.g. SSH, Telnet, ASDM (HTTPS), Enable
• Network access e.g. configure the ASA to authenticate users that need to access an FTP server
• VPN access e.g. AnyConnect VPN

Authorization

For authorization to be configured on the ASA, authentication must also be configured. The ASA can be configured to authorize the following:

• Commands authorization e.g. a user can perform show commands but cannot use the configure command
• Network access e.g. user-specific downloadable ACLs
• VPN access e.g. what time of day a user can login to a VPN

Accounting

Accounting is more about logging information about traffic passing through the ASA, information such as service used, duration of session, username, etc. Accounting information can be tracked per user (if authentication is also configured) or per IP address (if authentication is not configured).

AAA Server Support on the Cisco ASA

Like other Cisco devices, the Cisco ASA supports a variety of AAA servers which can be divided into internal and external AAA servers. The only internal AAA server is the ASA’s Local Database. External AAA servers supported by the ASA include RADIUS, TACACS+, LDAP, RSA SecurID, Kerberos, etc.

To give a typical example: Many organizations use Microsoft Active Directory (AD) which is a type of LDAP server to authenticate users and also enforce organization-wide policies for devices. The ASA can be configured to also use this AD to authenticate/authorize users for the various functions already described above.

It is also important to note that there are some AAA functions that certain AAA servers do not support. For example, only RADIUS and TACACS+ servers support the accounting function. You can check the features supported by the various AAA servers here.

Lab: Authentication for Device Administration

In this section of the article, we will configure a lab on the Cisco ASA where we will focus on AAA for device administration i.e. management access. As we go along, we will point out differences between this configuration and how it is on Cisco IOS routers.

The Lab setup in GNS3 is as shown below. I am using ASAv version 9.8(1).

Scenario #1: Telnet

By default, you can open a telnet connection to a Cisco IOS router as long as a password is configured on the VTY lines using the password command. The Cisco ASA behaves similarly except that the command is different (passwd) and this command is a global configuration command versus a line configuration as it is on the Cisco IOS routers.

So let’s test this. We will open a telnet connection from our host to the ASA.

Tip: The ASA does not allow Telnet to the lowest security interface except that telnet connection is over a VPN tunnel.

As you can see, the telnet connection failed. This is because we did not specify the IP addresses that can connect to the ASA using Telnet. We do this using the telnet command, along with the interface on which those addresses can connect from. This is another difference between the Cisco ASA and Cisco IOS routers. The Cisco ASA takes a deny-all approach to security and you must explicitly allow what you want.

Also, we need to configure a Telnet login password using the passwd command. There used to be a default password on Cisco ASAs of “cisco” but this has been removed from ASA version 9.0(2).

passwd ciscotelnet
telnet 192.168.105.0 255.255.255.0 inside

Let’s test again.

As you can see, we are connected to the ASA and placed at User EXEC mode (privilege level 1).

However, what we have done has nothing to do with AAA (as we are familiar with it from Cisco IOS routers). This is just basic telnet access authentication and it cannot be used to differentiate between users. To configure the ASA to authenticate based on username/password, we have to configure AAA Telnet authentication.

aaa authentication telnet console LOCAL

Note: Cisco’s terminology for this is quite confusing. The consider using the passwd command “no authentication” but using AAA as “authentication”.

With this configuration, the ASA will check the LOCAL database to perform user authentication. We can also create an AAA server group (e.g. RADIUS) and used it for authentication. In the same way, you can also use the ASA’s local database as a fallback AAA server, just like we do on Cisco IOS routers.

Notice that unlike the Cisco IOS router, we do not need to turn on AAA on the Cisco ASA using the aaa new-model command. In fact, there is no aaa new-model command on the ASA. However, just like the Cisco IOS router, if you will be using the local database for authentication, you should populate the database with usernames/passwords.

For our example, let’s create three users with different privilege levels. If you don’t specify a privilege level for a user, the default is 2.

username cisco1 password cisco1 privilege 1
username cisco2 password cisco2
username cisco15 password cisco15 privilege 15

Note: If you want to configure a privilege level for a user on the Cisco IOS router, you must make sure you configure it before the password/secret because the router interprets the entire string after the password/secret option as the password. In the ASA, you can do it in any order.

Let’s test again.

Notice now that it asks for a username and password and that user (cisco1) is placed at user EXEC mode with a privilege level of 1. Let’s test the other usernames.

Notice that irrespective of the user’s privilege level, they are all placed at privilege level 1. We will talk about how to change this behavior later on in this article.

Note: On Cisco IOS routers, we could use the login local command to ensure that users are placed at their configured privilege level upon login. This feature is not available on the Cisco ASA without using AAA.

Scenario #2: SSH

SSH requires a username and password to successfully open a connection. As such, you need to use AAA to authenticate SSH connections, either using the LOCAL database or an external AAA server.

Note: This is a bit different from the Cisco IOS router where you can use the login local command under the VTY lines to allow authentication using the local database even without enabling AAA.

Our configuration for SSH authentication is as follows:

ssh 192.168.105.0 255.255.255.0 inside
aaa authentication ssh console LOCAL

Note: The ASA comes with a default RSA key so I don’t need to generate one explicitly.

Let’s test.

As you can see, the user successfully connected and was also placed at user EXEC mode. If we try using the cisco15 user, the result will be the same:

Tip: I use the -oKexAlgorithms option in my SSH command to specify which key exchange method to use.

Scenario #3: Privileged EXEC Mode

So how do we gain access to privileged EXEC mode on the ASA. Just like we have several ways on the Cisco IOS routers, there are also several ways on the Cisco ASA, the easiest way being to use the enable command.

Note: The default enable password on the Cisco ASA is blank, so once you get the prompt for password, just hit Enter. This is different from Cisco IOS routers where without an enable password/secret, you cannot get access to the privileged EXEC mode (with some exemptions like login local).

Before we continue, let’s change our enable password to “ciscoenable”.

enable password ciscoenable

However, there is a slight problem. If you look closely at the username after we enter the enable password, it has changed to “enable_15” which means that we have lost track of the user that initially opened the remote session.

One way to overcome this issue (and also gain access to the privileged EXEC mode) is to use the login command instead of enable. With this, the ASA will ask for the username/password again, check the privilege level of the user, and grant the appropriate privilege level.

Let’s test this.

Notice that users cisco2 and cisco15 were given access to privileged EXEC mode but cisco1 was not because we configured that user with a privilege level of 1. This is a note of caution: any user not on privilege level 1 will be given access to privileged EXEC mode. The default privilege level for any user configured using the username command is level 2.

The third way to access privileged EXEC mode is to configure AAA enable authentication. The method also preserves the username of the user when they use the enable command.

aaa authentication enable console LOCAL

Let’s test this with user cisco1.

As you can see, it asks for the password (of user1 not the previous enable password we configured) and when the password was entered, the user was told they don’t have admin rights to the console.

Let’s test for the other users.

As a bonus, one more way to allow users gain access to the privileged EXEC mode is to configure EXEC authorization along with the auto-enable option:

aaa authorization exec LOCAL auto-enable

With this option, users will automatically be placed in the appropriate privilege level upon login. Note that this option was introduced in ASA version 9.2(1).

Conclusion

The Cisco ASA is a security device and as such, some things are different on it compared to other devices like the Cisco IOS devices. One of such differences is in how AAA is implemented.

While there are many similarities between AAA on the Cisco ASA and AAA on Cisco IOS devices, there are also quite a number of differences including:

• You must explicitly configure the users that can manage the ASA. This is similar to using the access-class command under a VTY line.
• You do not need to manually enable AAA on the Cisco ASA using the aaa new-model command.
• There is no equivalent of the login local command without using AAA on the Cisco ASA
• Remote access users (irrespective of configured privilege level) can access the privileged EXEC mode even when an enable password is not configured. I wonder why they chose this route considering the ASA is a security device.

There are still a lot of features we have not considered on the ASA like ASDM and Console (Serial) authentication but this article should give you an idea of how they work. We have also not considered command authorization which can be used to specify which commands different users/privilege levels have access to. Command authorization can be tricky though.

To learn more about AAA on the Cisco ASA, you can visit the Cisco guide here and here.