AAA and the Local Database

This chapter describes authentication, authorization, and accounting (AAA, pronounced “triple A”). AAA is a a set of services for controlling access to computer resources, enforcing policies, assessing usage, and providing the information necessary to bill for services. These processes are considered important for effective network management and security.

This chapter also describes how to configure the local database for AAA functionality. For external AAA servers, see the chapter for your server type.

About AAA and the Local Database

This section describes AAA and the local database.

Authentication

Authentication provides a way to identify a user, typically by having the user enter a valid username and valid password before access is granted. The AAA server compares a user's authentication credentials with other user credentials stored in a database. If the credentials match, the user is permitted access to the network. If the credentials do not match, authentication fails and network access is denied.

You can configure the ASA to authenticate the following items:

  • All administrative connections to the ASA, including the following sessions:

    • Telnet

    • SSH

    • Serial console

    • ASDM using HTTPS

    • VPN management access

  • The enable command

  • Network access

  • VPN access

Authorization

Authorization is the process of enforcing policies: determining what types of activities, resources, or services a user is permitted to access. After a user is authenticated, that user may be authorized for different types of access or activity.

You can configure the ASA to authorize the following items:

  • Management commands

  • Network access

  • VPN access

Accounting

Accounting measures the resources a user consumes during access, which may include the amount of system time or the amount of data that a user has sent or received during a session. Accounting is carried out through the logging of session statistics and usage information, which is used for authorization control, billing, trend analysis, resource utilization, and capacity planning activities.

Interaction Between Authentication, Authorization, and Accounting

You can use authentication alone or with authorization and accounting. Authorization always requires a user to be authenticated first. You can use accounting alone, or with authentication and authorization.

AAA Servers and Server Groups

The AAA server is a network server that is used for access control. Authentication identifies the user. Authorization implements policies that determine which resources and services an authenticated user may access. Accounting keeps track of time and data resources that are used for billing and analysis.

If you want to use an external AAA server, you must first create a AAA server group for the protocol that the external server uses, and add the server to the group. You can create more than one group per protocol, and separate groups for all protocols that you want to use. Each server group is specific to one type of server or service.

See the following topics for details on how to create the groups:

See the VPN configuration guide for more information on using HTTP Form.


Note

From ASA 9.22.1, the Kerberos protocol is not supported. You can no longer use Kerberos for AAA services. We recommend that you to use other supported servers listed in the below table.

The following table summarizes the supported types of server and their uses, including the local database.

Table 1. Supported Services for AAA Servers

Server Type and Service

Authentication

Authorization

Accounting

Local Database
  • Administrators

Yes

Yes

No
  • VPN Users

Yes

No

No
  • Firewall Sessions (AAA rules)

Yes

Yes

No

RADIUS
  • Administrators

Yes

Yes

Yes
  • VPN Users

Yes

Yes

Yes
  • Firewall Sessions (AAA rules)

Yes

Yes

Yes

TACACS+
  • Administrators

Yes

Yes

Yes
  • VPN Users

Yes

No

Yes
  • Firewall Sessions (AAA rules)

Yes

Yes

Yes

LDAP
  • Administrators

Yes

No

No
  • VPN Users

Yes

Yes

No
  • Firewall Sessions (AAA rules)

Yes

No

No

SDI (RSA SecurID)
  • Administrators

Yes

No

No
  • VPN Users

Yes

No

No
  • Firewall Sessions (AAA rules)

Yes

No

No

HTTP Form
  • Administrators

No

No

No
  • VPN Users

Yes

No

No
  • Firewall Sessions (AAA rules)

No

No

No

Notes

  • RADIUS—Accounting for administrators does not include command accounting.

  • RADIUS—Authorization for firewall sessions is supported with user-specific access lists only, which are received or specified in a RADIUS authentication response.

  • TACACS+—Accounting for administrators includes command accounting.

  • HTTP Form—Authentication and SSO operations for clientless SSL VPN user sessions only.

About the Local Database

The ASA maintains a local database that you can populate with user profiles. You can use a local database instead of AAA servers to provide user authentication, authorization, and accounting.

You can use the local database for the following functions:

  • ASDM per-user access

  • Console authentication

  • Telnet and SSH authentication

  • enable command authentication

    This setting is for CLI-access only and does not affect the Cisco ASDM login.

  • Command authorization

    If you turn on command authorization using the local database, then the ASA refers to the user privilege level to determine which commands are available. Otherwise, the privilege level is not generally used. By default, all commands are either privilege level 0 or level 15. ASDM allows you to enable three predefined privilege levels, with commands assigned to level 15 (Admin), level 5 (Read Only), and level 3 (Monitor Only). If you use the predefined levels, then assign users to one of these three privilege levels.

  • Network access authentication

  • VPN client authentication

For multiple context mode, you can configure usernames in the system execution space to provide individual logins at the CLI using the login command; however, you cannot configure any AAA rules that use the local database in the system execution space.


Note

You cannot use the local database for network access authorization.

Fallback Support

The local database can act as a fallback method for several functions. This behavior is designed to help you prevent accidental lockout from the ASA.

When a user logs in, the servers in the group are accessed one at a time, starting with the first server that you specify in the configuration, until a server responds. If all servers in the group are unavailable, the ASA tries the local database if you have configured it as a fallback method (for management authentication and authorization only). If you do not have a fallback method, the ASA continues to try the AAA servers.

For users who need fallback support, we recommend that their usernames and passwords in the local database match their usernames and passwords on the AAA servers. This practice provides transparent fallback support. Because the user cannot determine whether a AAA server or the local database is providing the service, using usernames and passwords on AAA servers that are different than the usernames and passwords in the local database means that the user cannot be certain which username and password should be given.

The local database supports the following fallback functions:

  • Console and enable password authentication—If the servers in the group are all unavailable, the ASA uses the local database to authenticate administrative access, which can also include enable password authentication.

  • Command authorization—If the TACACS+ servers in the group are all unavailable, the local database is used to authorize commands based on privilege levels.

  • VPN authentication and authorization—VPN authentication and authorization are supported to enable remote access to the ASA if AAA servers that normally support these VPN services are unavailable. When a VPN client of an administrator specifies a tunnel group configured to fallback to the local database, the VPN tunnel can be established even if the AAA server group is unavailable, provided that the local database is configured with the necessary attributes.

How Fallback Works with Multiple Servers in a Group

If you configure multiple servers in a server group and you enable fallback to the local database for the server group, fallback occurs when no server in the group responds to the authentication request from the ASA. To illustrate, consider this scenario:

You configure an LDAP server group with two Active Directory servers, server 1 and server 2, in that order. When the remote user logs in, the ASA attempts to authenticate to server 1.

If server 1 responds with an authentication failure (such as user not found), the ASA does not attempt to authenticate to server 2.

If server 1 does not respond within the timeout period (or the number of authentication attempts exceeds the configured maximum), the ASA tries server 2.

If both servers in the group do not respond, and the ASA is configured to fall back to the local database, the ASA tries to authenticate to the local database.

Guidelines for the Local Database

Make sure that you prevent a lockout from the ASA when using the local database for authentication or authorization.

Add a User Account to the Local Database

To add a user to the local database, perform the following steps:

Procedure

Step 1

Choose Configuration > Device Management > Users/AAA > User Accounts, then click Add.

The Add User Account-Identity dialog box appears.

Step 2

Enter a username from 4 to 64 characters long.

Step 3

(Optional) Enter a password between 8 and 127 characters.

Passwords are case-sensitive. It can be any combination of ASCII printable characters (character codes 32-126), with the following exceptions:

  • No spaces

  • No question marks

  • You cannot use three or more consecutive sequential or repetitive ASCII characters. For example, the following passwords will be rejected:

    • abcuser1

    • user543

    • useraaaa

    • user2666

The field displays only asterisks. You might want to create a username without a password if you are using SSH public key authentication, for example.

Note

 

To configure the enable password from the User Accounts pane, change the password for the enable_15 user. The enable_15 user is always present in the User Accounts pane, and represents the default username. This method of configuring the enable password is the only method available in ASDM for the system configuration. If you configured other enable level passwords at the CLI (enable password 10, for example), then those users are listed as enable_10, and so on.

Step 4

Reenter the password.

For security purposes, only asterisks appear in the password fields.

Step 5

Check the User authenticated using MSCHAP check box if you are using MSCHAP for authentication.

Step 6

Set the management access level for a user in the Access Restriction area. You must first enable management authorization by clicking the Perform authorization for exec shell access option on the Configuration > Device Management > Users/AAA > AAA Access > Authorization tab.

Choose one of the following options:

  • Full Access (ASDM, Telnet, SSH and console)—If you configure authentication for management access using the local database, then this option lets the user use ASDM, SSH, Telnet, and the console port. If you also enable authentication, then the user can access global configuration mode.

    • Privilege Level—Sets the privilege level for ASDM and local command authorization. The range is 0 (lowest) to 15 (highest). Specify 15 to grant unrestricted admin access. The predefined ASDM roles use 15 for Admin, 5 for Read Only, and 3 for Monitor Only (which restricts the user to the Home and Monitoring panes).

  • CLI login prompt for SSH, Telnet and console (no ASDM access)—If you configure authentication for management access using the local database, then this option lets the user use SSH, Telnet, and the console port. The user cannot use ASDM for configuration (if you configure HTTP authentication). ASDM monitoring is allowed. If you also configure enable authentication, then the user cannot access global configuration mode.

  • No ASDM, SSH, Telnet, or console access—If you configure authentication for management access using the local database, then this option disallows the user from accessing any management access method for which you configured authentication (excluding the Serial option; serial access is allowed).

Step 7

(Optional) To enable public key authentication for SSH connections to the ASA on a per-user basis, see Configure HTTPS Access for ASDM, Other Clients.

Step 8

Click VPN Policy to configure VPN policy attributes for this user. See the VPN configuration guide.

Step 9

Click Apply.

The user is added to the local database, and the changes are saved to the running configuration.

Tip

 

You can search for specific text in each column of the Configuration > Device Management > Users/AAA > User Accounts pane. Enter the specific text that you want to locate in the Find box, then click the Up or Down arrow. You can also use the asterisk (“*”) and question mark (“?”) as wild card characters in the text search.

Test Local Database Authentication and Authorization

To determine whether the ASA can contact a local database and authenticate or authorize a user, perform the following steps:

Procedure

Step 1

From the Configuration > Device Management > Users/AAA > AAA Server Groups > AAA Server Groups table, click the server group in which the server resides.

Step 2

Click the server that you want to test from the Servers in the Selected Group table.

Step 3

Click Test.

The Test AAA Server dialog box appears for the selected server.

Step 4

Click the type of test that you want to perform—Authentication or Authorization.

Step 5

Enter a username.

Step 6

If you are testing authentication, enter the password for the username.

Step 7

Click OK.

The ASA sends an authentication or authorization test message to the server. If the test fails, ASDM displays an error message.

Monitoring the Local Database

See the following commands for monitoring the local database:

  • Monitoring > Properties > AAA Servers

    This pane shows AAA server statistics.

  • Tools > Command Line Interface

    This pane allows you to issue various non-interactive commands and view results.

History for the Local Database

Table 2. History for the Local Database

Feature Name

Platform Releases

Description

Local database configuration for AAA

7.0(1)

Describes how to configure the local database for AAA use.

We introduced the following screens:

Configuration > Device Management > Users/AAA > AAA Server Groups
Configuration > Device Management > Users/AAA > User Accounts.

Support for SSH public key authentication

9.1(2)

You can now enable public key authentication for SSH connections to the ASA on a per-user basis. You can specify a public key file (PKF) formatted key or a Base64 key. The PKF key can be up to 4096 bits. Use PKF format for keys that are too large to for the ASA support of the Base64 format (up to 2048 bits).

We introduced the following screens:

Configuration > Device Management > Users/AAA > User Accounts > Edit User Account > Public Key Authentication
Configuration > Device Management > Users/AAA > User Accounts > Edit User Account > Public Key Using PKF

Also available in 8.4(4.1); PKF key format support is only in 9.1(2).

Longer password support for local username and enable passwords (up to 127 characters)

9.6(1)

You can now create local username and enable passwords up to 127 characters (the former limit was 32). When you create a password longer than 32 characters, it is stored in the configuration using a PBKDF2 (Password-Based Key Derivation Function 2) hash. Shorter passwords continue to use the MD5-based hashing method.

We modified the following screens:

Configuration > Device Setup > Device Name/Password > Enable Password

Configuration > Device Management > Users/AAA > User Accounts > Add/Edit User Account > Identity

SSH public key authentication improvements

9.6(2)

In earlier releases, you could enable SSH public key authentication without also enabling AAA SSH authentication with the Local user database . The configuration is now fixed so that you must explicitly enable AAA SSH authentication. To disallow users from using a password instead of the private key, you can now create a username without any password defined.

We modifed the following screens:

Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH

Configuration > Device Management > Users/AAA > User Accounts > Add/Edit User Account

PBKDF2 hashing for all local username and enable passwords

9.7(1)

Local username and enable passwords of all lengths are stored in the configuration using a PBKDF2 (Password-Based Key Derivation Function 2) hash. Previously, passwords 32 characters and shorter used the MD5-based hashing method. Already existing passwords continue to use the MD5-based hash unless you enter a new password. See the "Software and Configurations" chapter in the General Operations Configuration Guide for downgrading guidelines.

We modified the following screens:

Configuration > Device Setup > Device Name/Password > Enable Password

Configuration > Device Management > Users/AAA > User Accounts > Add/Edit User Account > Identity

Separate authentication for users with SSH public key authentication and users with passwords

9.6(3)/9.8(1)

In releases prior to 9.6(2), you could enable SSH public key authentication (ssh authentication ) without also explicitly enabling AAA SSH authentication with the Local user database (aaa authentication ssh console LOCAL ). In 9.6(2), the ASA required you to explicitly enable AAA SSH authentication. In this release, you no longer have to explicitly enable AAA SSH authentication; when you configure the ssh authentication command for a user, local authentication is enabled by default for users with this type of authentication. Moreover, when you explicitly configure AAA SSH authentication, this configuration only applies for for usernames with passwords, and you can use any AAA server type (aaa authentication ssh console radius_1 , for example). For example, some users can use public key authentication using the local database, and other users can use passwords with RADIUS.

We did not modify any screens.

Stronger local user and enable password requirements

9.17(1)

For local users and the enable password, the following password requirements were added:

  • Password length—Minimum 8 characters. Formerly, the minimum was 3 characters.

  • Repetitive and sequential characters—Three or more consecutive sequential or repetitive ASCII characters are disallowed. For example, the following passwords will be rejected:

    • abcuser1

    • user543

    • useraaaa

    • user2666

New/Modified screens:

  • Configuration > Device Management > Users/AAA > User Accounts

  • Configuration > Device Setup > Device Name/Password

Local user lockout changes

9.17(1)

The ASA can lock out local users after a configurable number of failed login attempts. This feature did not apply to users with privilege level 15. Also, a user would be locked out indefinitely until an admin unlocked their account. Now, users will be unlocked after 10 minutes unless an admin uses the clear aaa local user lockout command before then. Privilege level 15 users are also now affected by the lockout setting.

New/Modified commands: aaa local authentication attempts max-fail , show aaa local user

SSH and Telnet password change prompt

9.17(1)

The first time a local user logs into the ASA using SSH or Telnet, they are prompted to change their password. They will also be prompted for the first login after an admin changes their password. If the ASA reloads, however, users will not be prompted even if it is their first login.

New/Modified commands: show aaa local user