Cisco ASA 1000V ASDM Configuration Guide, 6.7
Configuring AAA for Management Access
Downloads: This chapterpdf (PDF - 374.0KB) The complete bookPDF (PDF - 11.09MB) | Feedback

Configuring AAA for Management Access

Table Of Contents

Configuring AAA for Management Access

Information About AAA for Management Access

Information About Authentication

Information About Authorization

Information About Accounting

Information About Management Authentication

Comparing CLI Access with and without Authentication

Comparing ASDM Access with and without Authentication

Information About Command Authorization

Supported Command Authorization Methods

About Preserving User Credentials

Summary of Server Support

RADIUS Server Support

Authentication Methods

Attribute Support

TACACS+ Server Support

RSA/SDI Server Support

RSA/SDI Version Support

Two-step Authentication Process

RSA/SDI Primary and Replica Servers

NT Server Support

Kerberos Server Support

LDAP Server Support

Authentication with LDAP

LDAP Server Types

Local Database Support, Including as a Fallback Method

How Fallback Works with Multiple Servers in a Group

Prerequisites

Default Settings

Configuring AAA Servers and Local Users

Task Flow for Configuring AAA Servers

Configuring AAA Server Groups      

Adding a Server to a Group   

Configuring AAA Server Parameters

RADIUS Server Fields

TACACS+ Server Fields

SDI Server Fields

Windows NT Domain Server Fields

Kerberos Server Fields

LDAP Server Fields

Configuring LDAP Attribute Maps          

Adding a User Account to the Local Database   

Adding an Authentication Prompt

Testing Server Authentication and Authorization

Authenticating Users with a Public Key for SSH

Configuring AAA for Management Access

Configuring Authentication for CLI, ASDM, and enable command Access

Limiting User CLI and ASDM Access with Management Authorization

Configuring Command Authorization

Configuring Local Command Authorization

Viewing Local Command Privilege Levels

Configuring Commands on the TACACS+ Server

Configuring TACACS+ Command Authorization

Configuring Management Access Accounting

Recovering from a Lockout

Monitoring AAA for Management Access

Monitoring AAA Servers

Monitoring Authenticated Users

Viewing the Currently Logged-In User

Additional References

RFCs

Feature History for AAA for Management Access


Configuring AAA for Management Access


This chapter describes how to authenticate and authorize users for management access. The chapter includes the following sections:

Information About AAA for Management Access

Configuring AAA Servers and Local Users

Configuring AAA for Management Access

Monitoring AAA for Management Access

Additional References

Feature History for AAA for Management Access


Note For Telnet, SSH, or ASDM access, first complete the procedures in Chapter 19 "Configuring Management Access."


Information About AAA for Management Access

AAA enables the ASA 1000V to determine who the user is (authentication), what the user can do (authorization), and what the user did (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.

This section includes the following topics:

Information About Authentication

Information About Authorization

Information About Accounting

Summary of Server Support

RADIUS Server Support

TACACS+ Server Support

RSA/SDI Server Support

NT Server Support

Kerberos Server Support

LDAP Server Support

Local Database Support, Including as a Fallback Method

How Fallback Works with Multiple Servers in a Group

Prerequisites

Task Flow for Configuring AAA Servers

Information About Authentication

Authentication controls access by requiring valid user credentials, which are usually a username and password. You can configure the ASA 1000V to authenticate the following items:

All administrative connections to the ASA 1000V, including the following sessions:

Telnet

SSH

Serial console

ASDM using HTTPS

The enable command

Information About Authorization

Authorization controls access per user after users are authenticated.

Authorization controls the services and commands that are available to each authenticated user. If you did not enable authorization, authentication alone would provide the same access to services for all authenticated users.

If you need the control that authorization provides, you can configure a broad authentication rule, and then have a detailed authorization configuration.

The ASA 1000V caches the first 16 authorization requests per user, so if the user accesses the same services during the current authentication session, the ASA 1000V does not resend the request to the authorization server.

Information About Accounting

Accounting tracks traffic that passes through the ASA 1000V, enabling you to have a record of user activity. If you enable authentication for that traffic, you can account for traffic per user. If you do not authenticate the traffic, you can account for traffic per IP address. Accounting information includes session start and stop times, username, the number of bytes that pass through the ASA 1000V for the session, the service used, and the duration of each session.

Information About Management Authentication

This section describes authentication for management access and includes the following topics:

Comparing CLI Access with and without Authentication

Comparing ASDM Access with and without Authentication

Comparing CLI Access with and without Authentication

How you log into the ASA 1000V depends on whether or not you enable authentication:

If you do not enable any authentication for Telnet, you do not enter a username; you enter the login password. For SSH, you enter the username and the login password. You access user EXEC mode.

If you enable Telnet or SSH authentication according to this section, you enter the username and password as defined on the AAA server or local user database. You access user EXEC mode.

To enter privileged EXEC mode after logging in, enter the enable command. How enable works depends on whether or not you enable authentication:

If you do not configure enable authentication, enter the system enable password when you enter the enable command. However, if you do not use enable authentication, after you enter the enable command, you are no longer logged in as a particular user. To maintain your username, use enable authentication.

If you configure enable authentication, the ASA 1000V prompts you for your username and password again. This feature is particularly useful when you perform command authorization, in which usernames are important in determining the commands that a user can enter.

For enable authentication using the local database, you can use the login command instead of the enable command. login maintains the username but requires no configuration to turn on authentication.

Comparing ASDM Access with and without Authentication

By default, you can log into ASDM with a blank username and the enable password. Note that if you enter a username and password at the login screen (instead of leaving the username blank), ASDM checks the local database for a match.

If you configure HTTP authentication, you can no longer use ASDM with a blank username and the enable password.

Information About Command Authorization

This section describes command authorization and includes the following topics:

Supported Command Authorization Methods

About Preserving User Credentials

Supported Command Authorization Methods

You can use one of two command authorization methods:

Local privilege levels—Configure the command privilege levels on the ASA 1000V. When a local, RADIUS, or LDAP (if you map LDAP attributes to RADIUS attributes) user authenticates for CLI access, the ASA 1000V places that user in the privilege level that is defined by the local database, RADIUS, or LDAP server. The user can access commands at the assigned privilege level and below. Note that all users access user EXEC mode when they first log in (commands at level 0 or 1). The user needs to authenticate again with the enable command to access privileged EXEC mode (commands at level 2 or higher), or they can log in with the login command (local database only).


Note You can use local command authorization without any users in the local database and without CLI or enable authentication. Instead, when you enter the enable command, you enter the system enable password, and the ASA 1000V places you in level 15. You can then create enable passwords for every level, so that when you enter enable n (2 to 15), the ASA 1000V places you in level n. These levels are not used unless you enable local command authorization (see the "Configuring Local Command Authorization" section). (See the command reference for more information about the enable command.)


TACACS+ server privilege levels—On the TACACS+ server, configure the commands that a user or group can use after authenticating for CLI access. Every command that a user enters at the CLI is validated with the TACACS+ server.

About Preserving User Credentials

When a user logs into the ASA 1000V, that user is required to provide a username and password for authentication. The ASA 1000V retains these session credentials in case further authentication is needed later in the session.

When the following configurations are in place, a user needs only to authenticate with the local server for login. Subsequent serial authorization uses the saved credentials. The user is also prompted for the privilege level 15 password. When exiting privileged mode, the user is authenticated again. User credentials are not retained in privileged mode.

The local server is configured to authenticate user access.

Privilege level 15 command access is configured to require a password.

The user account is configured for serial-only authorization (no access to console or ASDM).

The user account is configured for privilege level 15 command access.

The following table shows how credentials are used in this case by the ASA 1000V.

Credentials required
Username and Password Authentication
Serial
Authorization
Privileged Mode Command Authorization
Privileged
Mode Exit Authorization

Username

Yes

No

No

Yes

Password

Yes

No

No

Yes

Privileged Mode Password

No

No

Yes

No


Summary of Server Support

Table 20-1 summarizes the support for each AAA service by each AAA server type, including the local database. For more information about support for a specific AAA server type, see the topics following the table.

Table 20-1 Summary of AAA Support 

AAA Service
Database Type
Local
RADIUS
TACACS+
SDI (RSA)
NT
Kerberos
LDAP

Authentication

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Authorization

Yes1

No

Yes

No

No

No

No

Accounting

No

Yes2

Yes

No

No

No

No

1 Local command authorization is supported by privilege level only.

2 Command accounting is available for TACACS+ only.



Note In addition to the native protocol authentication listed in Table 20-1, the ASA 1000V supports proxying authentication. For example, the ASA 1000V can proxy to an RSA/SDI and/or LDAP server via a RADIUS server.


RADIUS Server Support

The ASA 1000V supports the following RFC-compliant RADIUS servers for AAA:

Cisco Secure ACS 3.2, 4.0, 4.1, 4.2, and 5.x

Cisco Identity Services Engine (ISE)

RSA RADIUS in RSA Authentication Manager 5.2, 6.1, and 7.x

Microsoft

Authentication Methods

The ASA 1000V supports the following authentication methods with RADIUS:

PAP—For all connection types.

Authentication Proxy modes—Including RADIUS to Active Directory, RADIUS to RSA/SDI, RADIUS to Token-server, and RSA/SDI to RADIUS connections,

Attribute Support

The ASA 1000V supports the following sets of RADIUS attributes:

Authentication attributes defined in RFC 2138.

Accounting attributes defined in RFC 2139.

RADIUS attributes for tunneled protocol support, defined in RFC 2868.

Cisco IOS Vendor-Specific Attributes (VSAs), identified by RADIUS vendor ID 9.

Microsoft VSAs, defined in RFC 2548.

Cisco VSA (Cisco-Priv-Level), which provides a standard 0-15 numeric ranking of privileges, with 1 being the lowest level and 15 being the highest level. A zero level indicates no privileges. The first level (login) allows privileged EXEC access for the commands available at this level. The second level (enable) allows CLI configuration privileges.

TACACS+ Server Support

The ASA 1000V supports TACACS+ authentication with ASCII, PAP, CHAP, and MS-CHAPv1.

RSA/SDI Server Support

The RSA SecureID servers are also known as SDI servers.

This section includes the following topics:

RSA/SDI Version Support

Two-step Authentication Process

RSA/SDI Primary and Replica Servers

RSA/SDI Version Support

The ASA 1000V supports SDI Versions 5.x, 6.x, and 7.x. SDI uses the concepts of an SDI primary and SDI replica servers. Each primary and its replicas share a single node secret file. The node secret file has its name based on the hexadecimal value of the ACE or Server IP address, with .sdi appended.

A version 5.x, 6.x, or 7.x SDI server that you configure on the ASA 1000V can be either the primary or any one of the replicas. See the "RSA/SDI Primary and Replica Servers" section for information about how the SDI agent selects servers to authenticate users.

Two-step Authentication Process

SDI Versions 5.x, 6.x, or 7.x use a two-step process to prevent an intruder from capturing information from an RSA SecurID authentication request and using it to authenticate to another server. The agent first sends a lock request to the SecurID server before sending the user authentication request. The server locks the username, preventing another (replica) server from accepting it. This actions means that the same user cannot authenticate to two ASA 1000Vs using the same authentication servers simultaneously. After a successful username lock, the ASA 1000V sends the passcode.

RSA/SDI Primary and Replica Servers

The ASA 1000V obtains the server list when the first user authenticates to the configured server, which can be either a primary or a replica. The ASA 1000V then assigns priorities to each of the servers on the list, and subsequent server selection is derived at random from those assigned priorities. The highest priority servers have a higher likelihood of being selected.

NT Server Support

The ASA 1000V supports Microsoft Windows server operating systems that support NTLM Version 1, collectively referred to as NT servers.


Note NT servers have a maximum length of 14 characters for user passwords. Longer passwords are truncated, which is a limitation of NTLM Version 1.


Kerberos Server Support

The ASA 1000V supports 3DES, DES, and RC4 encryption types.

LDAP Server Support

The ASA 1000V supports LDAP. This section includes the following topics:

Authentication with LDAP

LDAP Server Types

Authentication with LDAP

During authentication, the ASA 1000V acts as a client proxy to the LDAP server for the user, and authenticates to the LDAP server in either plain text or by using the SASL protocol. By default, the ASA 1000V passes authentication parameters, usually a username and password, to the LDAP server in plain text.

The ASA 1000V supports the following SASL mechanisms, listed in order of increasing strength:

Digest-MD5—The ASA 1000V responds to the LDAP server with an MD5 value computed from the username and password.

Kerberos—The ASA 1000V responds to the LDAP server by sending the username and realm using the GSSAPI Kerberos mechanism.

You can configure the ASA 1000V and LDAP server to support any combination of these SASL mechanisms. If you configure multiple mechanisms, the ASA 1000V retrieves the list of SASL mechanisms that are configured on the server and sets the authentication mechanism to the strongest mechanism configured on both the ASA 1000V and the server. For example, if both the LDAP server and the ASA 1000V support both mechanisms, the ASA 1000V selects Kerberos, the stronger of the mechanisms.

When user LDAP authentication has succeeded, the LDAP server returns the attributes for the authenticated user.

LDAP Server Types

The ASA 1000V supports LDAP version 3 and is compatible with the Sun Microsystems JAVA System Directory Server (formerly named the Sun ONE Directory Server), the Microsoft Active Directory, Novell, OpenLDAP, and other LDAPv3 directory servers.

By default, the ASA 1000V auto-detects whether it is connected to Microsoft Active Directory, Sun LDAP, Novell, OpenLDAP, or a generic LDAPv3 directory server. However, if auto-detection fails to determine the LDAP server type, and you know the server is either a Microsoft, Sun or generic LDAP server, you can manually configure the server type.

When configuring the server type, note the following guidelines:

The DN configured on the ASA 1000V to access a Sun directory server must be able to access the default password policy on that server. We recommend using the directory administrator, or a user with directory administrator privileges, as the DN. Alternatively, you can place an ACL on the default password policy.

You must configure LDAP over SSL to enable password management with Microsoft Active Directory and Sun servers.

The ASA 1000V does not support password management with Novell, OpenLDAP, and other LDAPv3 directory servers.

The ASA 1000V uses the Login Distinguished Name (DN) and Login Password to establish a trust relationship (bind) with an LDAP server.

Local Database Support, Including as a Fallback Method

The ASA 1000V maintains a local database that you can populate with user profiles.

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 1000V.

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 1000V 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.

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 1000V. 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 1000V attempts to authenticate to server 1.

If server 1 responds with an authentication failure (such as user not found), the ASA 1000V 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 1000V tries server 2.

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

Prerequisites

Prerequisites for Management Authentication

Before the ASA 1000V can authenticate a Telnet, SSH, or HTTP user, you must identify the IP addresses that are allowed to communicate with the ASA 1000V. For more information, see the "Configuring ASA 1000V Access for ASDM, Telnet, or SSH" section.

Prerequisites for Local Command Authorization

Configure enable authentication. (See the "Configuring Authentication for CLI, ASDM, and enable command Access" section.)

enable authentication is essential for maintaining the username after the user accesses the enable command.

Alternatively, you can use the login command (which is the same as the enable command with authentication; for the local database only), which requires no configuration. We do not recommend this option because it is not as secure as enable authentication.

You can also use CLI authentication, but it is not required.

See the following prerequisites for each user type:

Local database users—Configure each user in the local database at a privilege level from 0 to 15.

RADIUS users—Configure the user with Cisco VSA CVPN3000-Privilege-Level with a value between 0 and 15.

LDAP users—Configure the user with a privilege level between 0 and 15, and then map the LDAP attribute to Cisco VSA CVPN3000-Privilege-Level.

Prerequisites for TACACS+ Command Authorization

Configure CLI and enable authentication (see the "Configuring Authentication for CLI, ASDM, and enable command Access" section).

Prerequisites for Management Accounting

Configure CLI and enable authentication (see the "Configuring Authentication for CLI, ASDM, and enable command Access" section).

Default Settings

By default, the following commands are assigned to privilege level 0. All other commands are assigned to privilege level 15.

show checksum

show curpriv

enable

help

show history

login

logout

pager

show pager

clear pager

quit

show version

If you move any configure mode commands to a lower level than 15, be sure to move the configure command to that level as well, otherwise, the user will not be able to enter configuration mode.

To view all privilege levels, see the "Viewing Local Command Privilege Levels" section.

Configuring AAA Servers and Local Users

This section includes the following topics:

Configuring AAA Server Groups

Adding a Server to a Group

Configuring AAA Server Parameters

Configuring LDAP Attribute Maps

Adding a User Account to the Local Database

Adding an Authentication Prompt

Testing Server Authentication and Authorization

Authenticating Users with a Public Key for SSH

Task Flow for Configuring AAA Servers


Step 1 Do one or both of the following:

Add a AAA server group. See the "Configuring AAA Server Groups" section.

Add a user to the local database. See the "Adding a User Account to the Local Database" section.

Step 2 For a server group, add a server to the group. See the "Adding a Server to a Group" section.

Step 3 For a server group, configure server parameters. See the "Configuring AAA Server Parameters" section.

Step 4 For an LDAP server, configure LDAP attribute maps. See the "Configuring LDAP Attribute Maps" section.

Step 5 (Optional) Specify text to display to the user during the AAA authentication challenge process. See the "Adding an Authentication Prompt" section.

Step 6 (Optional) Users can authenticate with a public key. See the "Authenticating Users with a Public Key for SSH" section.


Configuring AAA Server Groups      

If you want to use an external AAA server for authentication, authorization, or accounting, you must first create at least one AAA server group per AAA protocol and add one or more servers to each group. You identify AAA server groups by name. Each server group is specific to one type of server: Kerberos, LDAP, NT, RADIUS, SDI, or TACACS+.

Guidelines

You can have up to 100 server groups.

Each group can have up to 16 servers.

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

Detailed Steps

To add a server group, perform the following steps:


Step 1 Choose Configuration > Device Management > Users/AAA > AAA Server Groups.

Step 2 In the AAA Server Groups area, click Add.

The Add AAA Server Group dialog box appears.

Step 3 In the Server Group field, enter a name for the group.

Step 4 From the Protocol drop-down list, choose the server type:

RADIUS

TACACS+

SDI

NT Domain

Kerberos

LDAP

Step 5 In the Accounting Mode field, click the radio button for the mode you want to use (Simultaneous or Single).

In Single mode, the ASA 1000V sends accounting data to only one server.

In Simultaneous mode, the ASA 1000V sends accounting data to all servers in the group.


Note This option is not available for the following protocols: SDI, NT, Kerberos, and LDAP.


Step 6 In the Reactivation Mode field, click the radio button for the mode you want to use (Depletion or Timed).

In Depletion mode, failed servers are reactivated only after all of the servers in the group are inactive.

In Timed mode, failed servers are reactivated after 30 seconds of down time.

Step 7 If you chose the Depletion reactivation mode, enter a time interval in the Dead Time field.

The Dead Time is the duration of time, in minutes, that elapses between the disabling of the last server in a group and the subsequent reenabling of all servers.

Step 8 In the Max Failed Attempts field, add the number of failed attempts allowed.

This option sets the number of failed connection attempts allowed before declaring a nonresponsive server to be inactive.

Step 9 Click OK.

The Add AAA Server Group dialog box closes, and the new server group is added to the AAA Server Groups table.

Step 10 In the AAA Server Groups dialog box, click Apply to save the changes.

The changes are saved to the running configuration.


Adding a Server to a Group   

To add a AAA server to a group, perform the following steps.

Detailed Steps


Step 1 Choose Configuration > Device Management > Users/AAA > AAA Server Groups, and in the AAA Server Groups area, click the server group to which you want to add a server.

The row is highlighted in the table.

Step 2 In the Servers in the Selected Group area (lower pane), click Add.

The Add AAA Server Group dialog box appears for the server group.

Step 3 From the Interface Name drop-down list, choose the Ethernet interface name on which the authentication server resides.

Step 4 In the Server Name or IP Address field, add either a server name or IP address for the server that you are adding to the group.

Step 5 In the Timeout field, either add a timeout value or keep the default. The timeout is the duration of time, in seconds, that the ASA 1000V waits for a response from the primary server before sending the request to the backup server.

Step 6 The other parameters available depend on the server type. See the following sections for parameters that are unique to each server type:

RADIUS Server Fields

TACACS+ Server Fields

SDI Server Fields

Windows NT Domain Server Fields

Kerberos Server Fields

LDAP Server Fields

Step 7 Click OK.

The Add AAA Server Group dialog box closes, and the AAA server is added to the AAA server group.

Step 8 In the AAA Server Groups pane, click Apply to save the changes.

The changes are saved to the running configuration.


Configuring AAA Server Parameters

This section lists the unique fields for each server type when you add a server to a server group and includes the following topics:

RADIUS Server Fields

TACACS+ Server Fields

SDI Server Fields

Windows NT Domain Server Fields

Kerberos Server Fields

LDAP Server Fields

For more information, see the "Adding a Server to a Group" section.

RADIUS Server Fields

The following table describes the unique fields for configuring RADIUS servers, for use with the "Adding a Server to a Group" section.

Field
Description

ACL Netmask Convert

How you want the ASA 1000V to handle netmasks received in downloadable access lists.

Detect automatically: The ASA 1000V attempts to determine the type of netmask expression used. If the ASA 1000V detects a wildcard netmask expression, the ASA 1000V converts it to a standard netmask expression.


Note Because some wildcard expressions are difficult to detect clearly, this setting may misinterpret a wildcard netmask expression as a standard netmask expression.


Standard: The ASA 1000V assumes downloadable access lists received from the RADIUS server contain only standard netmask expressions. No translation from wildcard netmask expressions is performed.

Wildcard: The ASA 1000V assumes downloadable access lists received from the RADIUS server contain only wildcard netmask expressions, and it converts them all to standard netmask expressions when the access lists are downloaded.

Common Password

A case-sensitive password that is common among users who access this RADIUS authorization server through this ASA 1000V. Be sure to provide this information to your RADIUS server administrator.

Note For an authentication RADIUS server (rather than authorization), do not configure a common password.

If you leave this field blank, the user username is the password for accessing this RADIUS authorization server.

Never use a RADIUS authorization server for authentication. Common passwords or usernames as passwords are less secure than assigning unique user passwords.

Note Although the password is required by the RADIUS protocol and the RADIUS server, users do not need to know it.

Retry Interval

The duration of time, 1 to 10 seconds, that the ASA 1000V waits between attempts to contact the server.

Server Accounting Port

The server port to be used for user accounting. The default port is 1646.

Server Authentication Port

The server port to be used for user authentication. The default port is 1645.

Server Secret Key

The shared secret key used to authenticate the RADIUS server to the ASA 1000V. The server secret that you configure should match the one configured on the RADIUS server. If you do not know the server secret, ask the RADIUS server administrator. The maximum field length is 64 characters.


TACACS+ Server Fields

The following table describes the unique fields for configuring TACACS+ servers, for use with the "Adding a Server to a Group" section.

Field
Description

Server Port

The port to be used for this server.

Server Secret Key

The shared secret key used to authenticate the TACACS+ server to the ASA 1000V. The server secret that you configure here should match the one that is configured on the TACACS+ server. If you do not know the server secret, ask the RADIUS server administrator. The maximum field length is 64 characters.


SDI Server Fields

The following table describes the unique fields for configuring SDI servers, for use with the "Adding a Server to a Group" section.

Field
Description

Server Port

The TCP port number by which this server is accessed.

Retry Interval

The duration of time, 1 to 10 seconds, that the ASA 1000V waits between attempts to contact the server.


Windows NT Domain Server Fields

The following table describes the unique fields for configuring Windows NT Domain servers, for use with the "Adding a Server to a Group" section.

Field
Description

Server Port

Port number 139, or the TCP port number used by the ASA 1000V to communicate with the Windows NT server.

Domain Controller

The host name (no more than 15 characters) of the NT Primary Domain Controller for this server (for example, PDC01). You must enter a name, and it must be the correct host name for the server whose IP address you added in the field, Authentication Server Address. If the name is incorrect, authentication fails.


Kerberos Server Fields

The following table describes the unique fields for configuring Kerberos servers, for use with the "Adding a Server to a Group" section.

Field
Description

Server Port

Server port number 88, or the UDP port number over which the ASA 1000V communicates with the Kerberos server.

Retry Interval

The duration of time, 1 to 10 seconds, that the ASA 1000V waits between attempts to contact the server.

Realm

The name of the Kerberos realm. For example:

EXAMPLE.COM

EXAMPLE.NET

EXAMPLE.ORG


Note Most Kerberos servers require the realm to be all uppercase for authentication to succeed.


The maximum length is 64 characters. The following types of servers require that you enter the realm name in all uppercase letters:

Windows 2000

Windows XP

Windows.NET

You must enter the correct realm name for the server whose IP address you entered in the Server IP Address field.


LDAP Server Fields

The following table describes the unique fields for configuring LDAP servers, for use with the "Adding a Server to a Group" section.

Field
Description

Enable LDAP over SSL check box

When checked, SSL secures communications between the ASA 1000V and the LDAP server. Also called secure LDAP (LDAP-S).

Note If you do not configure the SASL protocol, we strongly recommend that you secure LDAP communications with SSL.

Server Port

TCP port number 389, the port which the ASA 1000V uses to access the LDAP server for simple (non-secure) authentication, or TCP port 636 for secure authentication (LDAP-S).

All LDAP servers support authentication and authorization.

Server Type

A drop-down list for choosing one of the following LDAP server types:

Detect Automatically/Use Generic Type

Microsoft

Novell

OpenLDAP

Sun

Base DN

The Base Distinguished Name, or location in the LDAP hierarchy where the server should begin searching when it receives an LDAP request (for example, OU=people, dc=cisco, dc=com).

Scope

The extent of the search the server should make in the LDAP hierarchy when it receives an authorization request. The available options are:

One Level—Searches only one level beneath the Base DN. This option is quicker.

All Levels—Searches all levels beneath the Base DN (that is, searches the entire subtree hierarchy). This option takes more time.

Naming Attribute(s)

The Relative Distinguished Name attribute (or attributes) that uniquely identifies an entry on the LDAP server. Common naming attributes are Common Name (CN), sAMAccountName, userPrincipalName, and User ID (uid).

Login DN

The ASA 1000V uses the Login Distinguished Name (DN) and Login Password to establish trust (bind) with an LDAP server. The Login DN represents a user record in the LDAP server that the administrator uses for binding.

When binding, the ASA 1000V authenticates to the server using the Login DN and the Login password. When performing a Microsoft Active Directory read-only operation (such as authentication, authorization, or group-search), the ASA 1000V can bind with a Login DN with fewer privileges. For example, the Login DN can be a user whose AD "Member Of" designation is part of Domain Users.

The following is an example of a Login DN:

cn=Binduser1,ou=Admins,ou=Users,dc=company_A,dc=com
 
        

The ASA 1000V supports:

Simple LDAP authentication with an unencrypted password on port 389

Secure LDAP (LDAP-S) on port 636

Simple Authentication and Security Layer (SASL) MD5

SASL Kerberos

The ASA 1000V does not support anonymous authentication.

Login Password

The password for the Login DN user account. The characters you type are replaced with asterisks.

LDAP Attribute Map

The LDAP attribute maps that you can apply to LDAP server. Used to map Cisco attribute names to user-defined attribute names and values. For more information, see the "Adding an Authentication Prompt" section.

SASL MD5 authentication check box

When checked, the MD5 mechanism of the SASL authenticates communications between the ASA 1000V and the LDAP server.

SASL Kerberos authentication

When checked, the Kerberos mechanism of the SASL secures authentication communications between the ASA 1000V and the LDAP server.

Kerberos Server Group

The Kerberos server or server group used for authentication. The Kerberos Server group option is disabled by default and is enabled only when SASL Kerberos authentication is chosen.

Group Base DN

Used only for Active Directory servers using LDAP protocol. This DN specifies the location in the LDAP hierarchy to begin searching for the AD groups (that is, the list of memberOf enumerations). If this field is not configured, the ASA 1000V uses the Base DN for AD group retrieval.

ASDM uses the list of retrieved AD groups to define AAA selection criteria for dynamic access policies. For more information, see the show ad-groups command.

Group Search Timeout

Specifies the maximum time to wait for a response from an AD server that was queried for available groups.


Configuring LDAP Attribute Maps          

The ASA 1000V can use an LDAP directory for authenticating management users.

Guidelines

To use the attribute mapping features correctly, you need to understand Cisco LDAP attribute names and values, as well as the user-defined attribute names and values.

Detailed Steps


Step 1 Choose Configuration > Device Management > Users/AAA > AAA Server Groups, click the LDAP Attribute Map section heading, and then click Add.

The Add LDAP Attribute Map dialog box appears with the Map Name tab active.

Step 2 In the Name field, add a name for the map.

Step 3 In the Customer Name field, add the name of the corresponding attribute of your organization.

Step 4 From the Cisco Name drop-down list, choose an attribute.

Step 5 Click Add.

Step 6 To add more names, repeat Steps 1 through 5.

Step 7 To map the customer names, click the Map Value tab.

Step 8 Click Add.

The Add LDAP Attributes Map Value dialog box appears.

Step 9 Choose the attribute from the Customer Name drop-down list.

Step 10 In the Customer Value field, add the value for this attribute.

Step 11 In the Cisco Value field, add the Cisco value to which the value specified in the previous step maps.

Step 12 Click Add.

The values are mapped.

Step 13 To map more names, repeat Steps 8 through 12.

Step 14 Click OK to return to the Map Value tab, and then click OK again to close the dialog box.

Step 15 In the LDAP Attribute Map pane, click Apply.

The value mappings are saved to the running configuration.


Adding a User Account to the Local Database   

This section describes how to manage users in the local database.

Guidelines

The local database is used for the following features:

ASDM per-user access

By default, you can log into ASDM with a blank username and the enable password (see the "Configuring the Hostname, Domain Name, and Passwords" section). However, if you enter a username and password at the login screen (instead of leaving the username blank), ASDM checks the local database for a match.

Console authentication

Telnet and SSH authentication.

enable command authentication

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

Command authorization

If you turn on command authorization using the local database, then the ASA 1000V 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.

Detailed Steps


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

The Add User Account-Identity dialog box appears.

Step 2 In the Username field, enter a username from 4 to 64 characters long.

Step 3 In the Password field, enter a password between 3 and 32 characters. Passwords are case-sensitive. The field displays only asterisks. To protect security, we recommend a password length of at least 8 characters.


Note To configure the enable password from the User Accounts pane (see the "Configuring the Hostname, Domain Name, and Passwords" section), 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 In the Confirm Password field, reenter the password.

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

Step 5 In the Access Restriction area, set the management access level for a user. 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 (see the "Configuring Authentication for CLI, ASDM, and enable command Access" section), 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—Selects the privilege level for this user to use with local command authorization. The range is 0 (lowest) to 15 (highest). See the "Configuring Command Authorization" section for more information.

CLI login prompt for SSH, Telnet and console (no ASDM access)—If you configure authentication for management access using the local database (see the "Configuring Authentication for CLI, ASDM, and enable command Access" section), 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 (see the "Configuring Authentication for CLI, ASDM, and enable command Access" section), 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 6 Click Apply.

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


Adding an Authentication Prompt

You can specify text to display to the user during the AAA authentication challenge process. You can specify the AAA challenge text for HTTP, FTP, and Telnet access through the ASA 1000V when requiring user authentication from TACACS+ or RADIUS servers. This text is primarily for cosmetic purposes and appears above the username and password prompts that users see when they log in.

If you do not specify an authentication prompt, users see the following when authenticating with a RADIUS or TACACS+ server:

Connection Type
Default Prompt

FTP

FTP authentication

HTTP

HTTP Authentication

Telnet

None


To add an authentication prompt, perform the following steps:


Step 1 From the Configuration > Device Management > Users/AAA > Authentication Prompt pane, enter text in the Prompt field to add as a message to appear above the username and password prompts that users see when they log in.

The following table shows the allowed character limits for authentication prompts:

Application
Character Limit for Authentication Prompt

Microsoft Internet Explorer

37

Telnet

235

FTP

235


Step 2 In the Messages area, add messages in the User accepted message and User rejected message fields.

If the user authentication occurs from Telnet, you can use the User accepted message and User rejected message options to display different status prompts to indicate that the authentication attempt is accepted or rejected by the AAA server.

If the AAA server authenticates the user, the ASA 1000V displays the User accepted message text, if specified, to the user; otherwise, the ASA 1000V displays the User rejected message text, if specified. Authentication of HTTP and FTP sessions displays only the challenge text at the prompt. The User accepted message and User rejected message text are not displayed.

Step 3 Click Apply.

The changes are saved to the running configuration.


Testing Server Authentication and Authorization

To determine whether the ASA 1000V can contact an AAA server and authenticate or authorize a user, perform the following steps:


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.

The row is highlighted in the table.

Step 2 From the Servers in the Selected Group table, click the server that you want to test.

The row is highlighted in the 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 In the Username field, enter a username.

Step 6 If you are testing authentication, in the Password field, enter the password for the username.

Step 7 Click OK.

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


Authenticating Users with a Public Key for SSH

Users can authenticate with a public key for SSH. The public key can be hashed or not hashed.

To authenticate with a public key for SSH, perform the following steps:


Step 1 In the ASDM main application window, choose Configuration > Device Management > Users/AAA > User Accounts.

Step 2 Select a user from the list, then click Edit.

The Edit User Account dialog box appears.

Step 3 Click Public Key Authentication in the navigation pane.

Step 4 If you want to hash the public key, check the Key is hashed check box. To not have the public key hashed, leave this check box unchecked.

If the public key is hashed, the value of the public key must have been previously hashed with SHA-256 and be 32 bytes long, with each byte separated by a colon (for parsing purposes).

If the public key is not hashed, the value of the key must be a Base 64 encoded public key that is generated by SSH key generation software that can generate SSH-RSA raw keys (that is, with no certificates). After you submit the Base 64 encoded public key, that key is then hashed via SHA-256 and the corresponding 32-byte hash is used for all further comparisons.

Step 5 Enter the public key.

Step 6 Click OK.

Step 7 Click Apply to save the configuration changes.


Configuring AAA for Management Access

Configuring Authentication for CLI, ASDM, and enable command Access

Limiting User CLI and ASDM Access with Management Authorization

Configuring Command Authorization

Configuring Management Access Accounting

Viewing the Currently Logged-In User

Recovering from a Lockout

Configuring Authentication for CLI, ASDM, and enable command Access

To configure management authentication, perform the following steps:

Detailed Steps


Step 1 To authenticate users who use the enable command, choose Configuration > Device Management > Users/AAA > AAA Access > Authentication, and configure the following settings:

a. Check the Enable check box.

b. From the Server Group drop-down list, choose a server group name or the LOCAL database.

c. (Optional) If you chose a AAA server, you can configure the ASA 1000V to use the local database as a fallback method if the AAA server is unavailable. Click the Use LOCAL when server group fails check box. We recommend that you use the same username and password in the local database as the AAA server, because the ASA 1000V prompt does not give any indication of which method is being used.

Step 2 To authenticate users who access the CLI or ASDM, choose Configuration > Device Management > Users/AAA > AAA Access > Authentication, and configure the following settings:

a. Check one or more of the following check boxes:

HTTP/ASDM—Authenticates the ASDM client that accesses the ASA 1000V using HTTPS. HTTP management authentication does not support the SDI protocol for a AAA server group.

Serial—Authenticates users who access the ASA 1000V using the console port.

SSH—Authenticates users who access the ASA 1000V using SSH.

Telnet—Authenticates users who access the ASA 1000V using Telnet.

b. For each service that you checked, from the Server Group drop-down list, choose a server group name or the LOCAL database.

c. (Optional) If you chose a AAA server, you can configure the ASA 1000V to use the local database as a fallback method if the AAA server is unavailable. Click the Use LOCAL when server group fails check box. We recommend that you use the same username and password in the local database as the AAA server because the ASA 1000V prompt does not give any indication of which method is being used.

Step 3 Click Apply.


Limiting User CLI and ASDM Access with Management Authorization

If you configure CLI or enable authentication, you can limit a local user, RADIUS, TACACS+, or LDAP user (if you map LDAP attributes to RADIUS attributes) from accessing the CLI, ASDM, or the enable command.


Note Serial access is not included in management authorization, so if you enable the Authentication > Serial option, then any user who authenticates can access the console port.


Detailed Steps


Step 1 To enable management authorization, choose Configuration > Device Management > Users/AAA > AAA Access > Authorization, and check the Perform authorization for exec shell access > Enable check box.

This option also enables support of administrative user privilege levels from RADIUS, which can be used in conjunction with local command privilege levels for command authorization. See the "Configuring Local Command Authorization" section for more information.

Step 2 To configure the user for management authorization, see the following requirements for each AAA server type or local user:

RADIUS or LDAP (mapped) users—Use the IETF RADIUS numeric Service-Type attribute, which maps to one of the following values:

Service-Type 6 (Administrative)—Allows full access to any services specified by the Authentication tab options

Service-Type 7 (NAS prompt)—Allows access to the CLI when you configure the Telnet or SSH authentication options, but denies ASDM configuration access if you configure the HTTP option. ASDM monitoring access is allowed. If you configure enable authentication with the Enable option, the user cannot access privileged EXEC mode using the enable command.

Service-Type 5 (Outbound)—Denies management access. The user cannot use any services specified by the Authentication tab options (excluding the Serial option; serial access is allowed). IPsec users can still authenticate and terminate their site-to-site sessions.

TACACS+ users—Request authorization with the "service=shell" entry, and the server responds with PASS or FAIL.

PASS, privilege level 1—Allows full access to any services specified by the Authentication tab options.

PASS, privilege level 2 and higher—Allows access to the CLI when you configure the Telnet or SSH authentication options, but denies ASDM configuration access if you configure the HTTP option. ASDM monitoring access is allowed. If you configure enable authentication with the Enable option, the user cannot access privileged EXEC mode using the enable command.

FAIL—Denies management access. The user cannot use any services specified by the Authentication tab options (excluding the Serial option; serial access is allowed).

Local users—Configure the Access Restriction option. By default, the access restriction is Full Access, which allows full access to any services specified by the Authentication tab options. For more information, see the "Adding a User Account to the Local Database" section.


Configuring Command Authorization

If you want to control access to commands, the ASA 1000V lets you configure command authorization, where you can determine which commands that are available to a user. By default when you log in, you can access user EXEC mode, which offers only minimal commands. When you enter the enable command (or the login command when you use the local database), you can access privileged EXEC mode and advanced commands, including configuration commands.

You can use one of two command authorization methods:

Local privilege levels

TACACS+ server privilege levels

For more information about command authorization, see the "Information About Command Authorization" section.

This section includes the following topics:

Configuring Local Command Authorization

Viewing Local Command Privilege Levels

Configuring Commands on the TACACS+ Server

Configuring TACACS+ Command Authorization

Configuring Local Command Authorization

Local command authorization lets you assign commands to one of 16 privilege levels (0 to 15). By default, each command is assigned either to privilege level 0 or 15. You can define each user to be at a specific privilege level, and each user can enter any command at the assigned privilege level or below. The ASA 1000V supports user privilege levels defined in the local database, a RADIUS server, or an LDAP server (if you map LDAP attributes to RADIUS attributes. See the "Prerequisites" section.)

To configure local command authorization, perform the following steps:

Detailed Steps


Step 1 To enable command authorization, choose Configuration > Device Management > Users/AAA > AAA Access > Authorization, and check the Enable authorization for command access > Enable check box.

Step 2 From the Server Group drop-down list, choose LOCAL.

Step 3 When you enable local command authorization, you have the option of manually assigning privilege levels to individual commands or groups of commands or enabling the predefined user account privileges.

To use predefined user account privileges, click Set ASDM Defined User Roles.

The ASDM Defined User Roles Setup dialog box shows the commands and their levels. Click Yes to use the predefined user account privileges: Admin (privilege level 15, with full access to all CLI commands; Read Only (privilege level 5, with read-only access); and Monitor Only (privilege level 3, with access to the Monitoring section only).

To manually configure command levels, click Configure Command Privileges.

The Command Privileges Setup dialog box appears. You can view all commands by choosing --All Modes-- from the Command Mode drop-down list, or you can choose a configuration mode to view the commands available in that mode. If a command can be entered in user EXEC or privileged EXEC mode as well as configuration mode, and the command performs different actions in each mode, you can set the privilege level for these modes separately.

The Variant column displays show, clear, or cmd. You can set the privilege only for the show, clear, or configure form of the command. The configure form of the command is typically the form that causes a configuration change, either as the unmodified command (without the show or clear prefix) or as the no form.

To change the level of a command, double-click it or click Edit. You can set the level between 0 and 15. You can only configure the privilege level of the main command. For example, you can configure the level of all aaa commands, but not the level of the aaa authentication command and the aaa authorization command separately.

To change the level of all commands that appear, click Select All and then Edit.

Click OK to accept your changes.

Step 4 To support administrative user privilege levels from RADIUS, check the Perform authorization for exec shell access > Enable check box.

Without this option, the ASA 1000V only supports privilege levels for local database users and defaults all other types of users to level 15.

This option also enables management authorization for local, RADIUS, LDAP (mapped), and TACACS+ users. See the "Limiting User CLI and ASDM Access with Management Authorization" section for more information.

Step 5 Click Apply.

The authorization settings are assigned, and the changes are saved to the running configuration.


Viewing Local Command Privilege Levels

The following commands when entered in the Tools > Command Line Interface tool, let you view privilege levels for commands.

Examples

For the show running-config all privilege all command, the ASA 1000V displays the current assignment of each CLI command to a privilege level. The following is sample output from this command:

Enter the following command in the Tools > Command Line Interface tool:

show running-config all privilege all
privilege show level 15 command aaa
privilege clear level 15 command aaa
privilege configure level 15 command aaa
privilege show level 15 command aaa-server
privilege clear level 15 command aaa-server
privilege configure level 15 command aaa-server
privilege show level 15 command access-group
privilege clear level 15 command access-group
privilege configure level 15 command access-group
privilege show level 15 command access-list
privilege clear level 15 command access-list
privilege configure level 15 command access-list
....
 
   

The following example displays the command assignments for privilege level 10:

show running-config privilege level 10
privilege show level 10 command aaa
 
   

The following example displays the command assignments for the access-list command:

show running-config privilege command access-list
privilege show level 15 command access-list
privilege clear level 15 command access-list
privilege configure level 15 command access-list

Configuring Commands on the TACACS+ Server

You can configure commands on a Cisco Secure Access Control Server (ACS) TACACS+ server as a shared profile component, for a group, or for individual users. For third-party TACACS+ servers, see your server documentation for more information about command authorization support.

See the following guidelines for configuring commands in Cisco Secure ACS Version 3.1; many of these guidelines also apply to third-party servers:

The ASA 1000V sends the commands to be authorized as shell commands, so configure the commands on the TACACS+ server as shell commands.


Note Cisco Secure ACS might include a command type called "pix-shell." Do not use this type for ASA 1000V command authorization.


The first word of the command is considered to be the main command. All additional words are considered to be arguments, which need to be preceded by permit or deny.

For example, to allow the show running-configuration aaa-server command, add show running-configuration to the command field, and type permit aaa-server in the arguments field.

You can permit all arguments of a command that you do not explicitly deny by checking the Permit Unmatched Args check box.

For example, you can configure just the show command, and then all the show commands are allowed. We recommend using this method so that you do not have to anticipate every variant of a command, including abbreviations and a question mark, which shows CLI usage (see Figure 20-1).

Figure 20-1 Permitting All Related Commands

For commands that are a single word, you must permit unmatched arguments, even if there are no arguments for the command, for example enable or help (see Figure 20-2).

Figure 20-2 Permitting Single Word Commands

To disallow some arguments, enter the arguments preceded by deny.

For example, to allow enable, but not enable password, enter enable in the commands field, and deny password in the arguments field. Be sure to check the Permit Unmatched Args check box so that enable alone is still allowed (see Figure 20-3).

Figure 20-3 Disallowing Arguments

When you abbreviate a command at the command line, the ASA 1000V expands the prefix and main command to the full text, but it sends additional arguments to the TACACS+ server as you enter them.

For example, if you enter sh log, then the ASA 1000V sends the entire command to the TACACS+ server, show logging. However, if you enter sh log mess, then the ASA 1000V sends show logging mess to the TACACS+ server, and not the expanded command show logging message. You can configure multiple spellings of the same argument to anticipate abbreviations (see Figure 20-4).

Figure 20-4 Specifying Abbreviations

We recommend that you allow the following basic commands for all users:

show checksum

show curpriv

enable

help

show history

login

logout

pager

show pager

clear pager

quit

show version

Configuring TACACS+ Command Authorization

If you enable TACACS+ command authorization, and a user enters a command at the CLI, the ASA 1000V sends the command and username to the TACACS+ server to determine if the command is authorized.

Before you enable TACACS+ command authorization, be sure that you are logged into the ASA 1000V as a user that is defined on the TACACS+ server, and that you have the necessary command authorization to continue configuring the ASA 1000V. For example, you should log in as an admin user with all commands authorized. Otherwise, you could become unintentionally locked out.

Do not save your configuration until you are sure that it works the way you want. If you get locked out because of a mistake, you can usually recover access by restarting the ASA 1000V. If you still get locked out, see the "Recovering from a Lockout" section.

Be sure that your TACACS+ system is completely stable and reliable. The necessary level of reliability typically requires that you have a fully redundant TACACS+ server system and fully redundant connectivity to the ASA 1000V. For example, in your TACACS+ server pool, include one server connected to interface 1, and another to interface 2. You can also configure local command authorization as a fallback method if the TACACS+ server is unavailable. In this case, you need to configure local users and command privilege levels according to procedures listed in the "Configuring Command Authorization" section.

To configure TACACS+ command authorization, perform the following steps:

Detailed Steps


Step 1 To perform command authorization using a TACACS+ server, choose Configuration > Device Management > Users/AAA > AAA Access > Authorization, and check the Enable authorization for command access > Enable check box.

Step 2 From the Server Group drop-down list, choose a AAA server group name.

Step 3 (Optional) you can configure the ASA 1000V to use the local database as a fallback method if the AAA server is unavailable. To do so, check the Use LOCAL when server group fails check box. We recommend that you use the same username and password in the local database as the AAA server, because the ASA 1000V prompt does not give any indication which method is being used. Be sure to configure users in the local database (see the "Adding a User Account to the Local Database" section) and command privilege levels (see the "Configuring Local Command Authorization" section).

Step 4 Click Apply.

The command authorization settings are assigned, and the changes are saved to the running configuration.


Configuring Management Access Accounting

You can configure accounting when users log in, when they enter the enable command, or when they issue commands.

For command accounting, you can only use TACACS+ servers.

To configure management access and enable command accounting, perform the following steps:

Detailed Steps


Step 1 To enable accounting of users when they enter the enable command, perform the following steps:

a. Choose Configuration > Device Management > Users/AAA > AAA Access > Accounting, and check the Require accounting to allow accounting of user activity > Enable check box.

b. From the Server Group drop-down list, choose a RADIUS or TACACS+ server group name.

Step 2 To enable accounting of users when they access the ASA 1000V using Telnet, SSH, or the serial console, perform the following steps:

a. Under the Require accounting for the following types of connections area, check the check boxes for Serial, SSH, and/or Telnet.

b. For each connection type, from the Server Group drop-down list, choose a RADIUS or TACACS+ server group name.

Step 3 To configure command accounting, perform the following steps:

a. Under the Require command accounting area, check the Enable check box.

b. From the Server Group drop-down list, choose a TACACS+ server group name. RADIUS is not supported.

You can send accounting messages to the TACACS+ accounting server when you enter any command other than show commands at the CLI.

c. If you customize the command privilege level using the Command Privilege Setup dialog box, you can limit which commands the ASA 1000V accounts for by specifying a minimum privilege level in the Privilege level drop-down list. The ASA 1000V does not account for commands that are below the minimum privilege level.

Step 4 Click Apply.

The accounting settings are assigned, and the changes are saved to the running configuration.


Recovering from a Lockout

In some circumstances, when you turn on command authorization or CLI authentication, you can be locked out of the ASA 1000V CLI. You can usually recover access by restarting the ASA 1000V. However, if you already saved your configuration, you might be locked out. Table 20-2 lists the common lockout conditions and how you might recover from them.

Table 20-2 CLI Authentication and Command Authorization Lockout Scenarios 

Feature
Lockout Condition
Description
Workaround

Local CLI authentication

No users in the local database

If you have no users in the local database, you cannot log in, and you cannot add any users.

Log in and reset the passwords and aaa commands.

TACACS+ command authorization

TACACS+ CLI authentication

RADIUS CLI authentication

Server down or unreachable and you do not have the fallback method configured

If the server is unreachable, then you cannot log in or enter any commands.

1. Log in and reset the passwords and AAA commands.

2. Configure the local database as a fallback method so you do not get locked out when the server is down.

TACACS+ command authorization

You are logged in as a user without enough privileges or as a user that does not exist

You enable command authorization, but then find that the user cannot enter any more commands.

Fix the TACACS+ server user account.

If you do not have access to the TACACS+ server and you need to configure the ASA 1000V immediately, then log into the maintenance partition and reset the passwords and aaa commands.

Local command authorization

You are logged in as a user without enough privileges

You enable command authorization, but then find that the user cannot enter any more commands.

Log in and reset the passwords and aaa commands.


Monitoring AAA for Management Access

Monitoring AAA Servers

Monitoring Authenticated Users

Viewing the Currently Logged-In User

Monitoring AAA Servers

To monitor AAA servers, see the following panes:

Path
Purpose

Monitoring > Properties > AAA Servers

Shows the configured AAA server statistics.

 

Monitoring > Properties > AAA Servers

Shows the AAA server running configuration.

 

Choose Tools > Command Line Interface, enter the show running-config all ldap attribute-map command, then press Send.

Shows all LDAP attribute maps in the running configuration.

 

Choose Tools > Command Line Interface, enter the show running-config zonelabs-integrity command, then press Send.

Shows the Zone Labs Integrity server configuration.

 

Choose Tools > Command Line Interface, enter the show ad-groups name [filter string] command, then press Send.

Applies only to AD servers using LDAP, and shows groups that are listed on an AD server.


Monitoring Authenticated Users

Path
Purpose

Monitoring > Properties > Device Access > Authenticated Users

Lists the usernames, IP addresses, dynamic ACLs, inactivity timeouts (if any), and absolute timeouts for users who were authenticated by AAA servers.

Monitoring > Properties > Device Access > AAA Local Locked Out Users

Lists the usernames of locked-out AAA local users, the number of failed attempts to authenticate, and the times that users were locked out. To clear a specific user who has been locked out, click Clear Selected Lockout. To clear all users who have been locked out, click Clear All Lockouts.


Viewing the Currently Logged-In User

To view the current logged-in user, enter the following command in the Tools > Command Line Interface tool:

show curpriv
 
   

The following is sample output from the show curpriv command:

show curpriv
Username: admin
Current privilege level: 15
Current Mode/s: P_PRIV
 
   

Table 20-3 describes the show curpriv command output.

Table 20-3 show curpriv Command Output Description

Field
Description

Username

Username. If you are logged in as the default user, the name is enable_1 (user EXEC mode) or enable_15 (privileged EXEC mode).

Current privilege level

Levels range from 0 to 15. Unless you configure local command authorization and assign commands to intermediate privilege levels, levels 0 and 15 are the only levels that are used.

Current Modes

The available access modes are the following:

P_UNPR—User EXEC mode (levels 0 and 1)

P_PRIV—Privileged EXEC mode (levels 2 to 15)

P_CONF—Configuration mode


Additional References

For additional information related to implementing LDAP mapping, see the next section.

RFCs

RFC
Title

2138

Remote Authentication Dial In User Service (RADIUS)

2139

RADIUS Accounting

2548

Microsoft Vendor-specific RADIUS Attributes

2868

RADIUS Attributes for Tunnel Protocol Support


Feature History for AAA for Management Access

Table 20-4 lists the feature history.

Table 20-4 Feature History for AAA for Management Access

Feature Name
Platform Releases
Feature Information

AAA for management access

8.7(1)

For RADIUS or LDAP (mapped) users using the IETF RADIUS Service-Type 5 (Outbound) attribute, remote access (SSL) users are not supported.