Cisco ASA 5500 Series Configuration Guide using ASDM, 6.4 and 6.6
Configuring AAA Servers and the Local Database
Downloads: This chapterpdf (PDF - 345.0KB) The complete bookPDF (PDF - 26.27MB) | Feedback

Configuring AAA Servers and the Local Database

Table Of Contents

Configuring AAA Servers and the Local Database

Information About AAA

Information About Authentication

Information About Authorization

Information About Accounting

Summary of Server Support

RADIUS Server Support

Authentication Methods

Attribute Support

RADIUS Authorization Functions

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

HTTP Forms Authentication for Clientless SSL VPN

Local Database Support, Including as a Falback Method

How Fallback Works with Multiple Servers in a Group

Using Certificates and User Login Credentials

Using User Login Credentials

Using Certificates

Licensing Requirements for AAA Servers

Guidelines and Limitations

Configuring AAA

Task Flow for Configuring AAA

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

HTTP Form Server Fields

Configuring LDAP Attribute Maps          

Adding a User Account to the Local Database   

Guidelines

Limitations

Adding a User

Configuring VPN Policy Attributes for a User

Adding an Authentication Prompt

Managing User Passwords

Changing User Passwords

Authenticating Users with a Public Key for SSH

Testing Server Authentication and Authorization

Monitoring AAA Servers

Additional References

RFCs

Feature History for AAA Servers


Configuring AAA Servers and the Local Database


This chapter describes support for authentication, authorization, and accounting (AAA, pronounced "triple A"), and how to configure AAA servers and the local database.

The chapter includes the following sections:

Information About AAA

Licensing Requirements for AAA Servers

Guidelines and Limitations

Configuring AAA

Testing Server Authentication and Authorization

Monitoring AAA Servers

Additional References

Feature History for AAA Servers

Information About AAA

AAA enables the ASA to determine who the user is (authentication), what the user can do (authorization), and what the user did (accounting).

AAA provides an extra level of protection and control for user access than using access lists alone. For example, you can create an access list allowing all outside users to access Telnet on a server on the DMZ network. If you want only some users to access the server and you might not always know IP addresses of these users, you can enable AAA to allow only authenticated and/or authorized users to connect through the ASA. (The Telnet server enforces authentication, too; the ASA prevents unauthorized users from attempting to access the server.)

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 Falback Method

How Fallback Works with Multiple Servers in a Group

Using Certificates and User Login Credentials

Task Flow for Configuring AAA

Information About Authentication

Authentication controls access by requiring valid user credentials, which are usually a username and password. 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

Information About Authorization

Authorization controls access per user after users are authenticated. You can configure the ASA to authorize the following items:

Management commands

Network access

VPN access

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. For example, you can authenticate inside users who try to access any server on the outside network and then limit the outside servers that a particular user can access using authorization.

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

Information About Accounting

Accounting tracks traffic that passes through the ASA, 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 for the session, the service used, and the duration of each session.

Summary of Server Support

Table 38-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 38-1 Summary of AAA Support 

AAA Service
Database Type
Local
RADIUS
TACACS+
SDI (RSA)
NT
Kerberos
LDAP
HTTP Form
Authentication of...

VPN users1

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes2

Firewall sessions

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Administrators

Yes

Yes

Yes

Yes3

Yes

Yes

Yes

No

Authorization of...

VPN users

Yes

Yes

No

No

No

No

Yes

No

Firewall sessions

No

Yes4

Yes

No

No

No

No

No

Administrators

Yes5

No

Yes

No

No

No

No

No

Accounting of...

VPN connections

No

Yes

Yes

No

No

No

No

No

Firewall sessions

No

Yes

Yes

No

No

No

No

No

Administrators

No

Yes6

Yes

No

No

No

No

No

1 For SSL VPN connections, either PAP or MS-CHAPv2 can be used.

2 HTTP Form protocol supports both authentication and single sign-on operations for clientless SSL VPN users sessions only.

3 RSA/SDI is supported for ASDM HTTP administrative access with ASA 5500 software version 8.2(1) or later.

4 For firewall sessions, RADIUS authorization is supported with user-specific access lists only, which are received or specified in a RADIUS authentication response.

5 Local command authorization is supported by privilege level only.

6 Command accounting is available for TACACS+ only.



Note In addition to the native protocol authentication listed in Table 38-1, the ASA supports proxying authentication. For example, the ASA can proxy to an RSA/SDI and/or LDAP server via a RADIUS server. Authentication via digital certificates and/or digital certificates with the AAA combinations listed in the table are also supported.


RADIUS Server Support

The ASA 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 supports the following authentication methods with RADIUS:

PAP—For all connection types.

CHAP and MS-CHAPv1—For L2TP-over-IPsec connections.

MS-CHAPv2—For L2TP-over-IPsec connections, and for regular IPsec remote access connections when the password management feature is enabled. You can also use MS-CHAPv2 with clientless connections.

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


Note To enable MS-CHAPv2 as the protocol used between the ASA and the RADIUS server for a VPN connection, password management must be enabled in the tunnel group general attributes. Enabling password management generates an MS-CHAPv2 authentication request from the ASA to the RADIUS server. See the description of the password-management command for details.

If you use double authentication and enable password management in the tunnel group, then the primary and secondary authentication requests include MS-CHAPv2 request attributes. If a RADIUS server does not support MS-CHAPv2, then you can configure that server to send a non-MS-CHAPv2 authentication request by using the no mschapv2-capable command.


Attribute Support

The ASA 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.

Cisco VPN-related VSAs, identified by RADIUS vendor ID 3076.

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.

A list of attributes is available at the following URL: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/ref_extserver.html#wp1605508

RADIUS Authorization Functions

The ASA can use RADIUS servers for user authorization of VPN remote access and firewall cut-through-proxy sessions using dynamic access lists or access list names per user. To implement dynamic access lists, you must configure the RADIUS server to support it. When the user authenticates, the RADIUS server sends a downloadable access list or access list name to the ASA. Access to a given service is either permitted or denied by the access list. The ASA deletes the access list when the authentication session expires.

In addtition to access lists, the ASA supports many other attributes for authorization and setting of permissions for VPN remote access and firewall cut-through proxy sessions. For a complete list of authorization attributes, see the following URL: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/ref_extserver.html#wp1605508

TACACS+ Server Support

The ASA 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 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 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 ASAs using the same authentication servers simultaneously. After a successful username lock, the ASA sends the passcode.

RSA/SDI Primary and Replica Servers

The ASA obtains the server list when the first user authenticates to the configured server, which can be either a primary or a replica. The ASA 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 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 supports 3DES, DES, and RC4 encryption types.


Note The ASA does not support changing user passwords during tunnel negotiation. To avoid this situation happening inadvertently, disable password expiration on the Kerberos/Active Directory server for users connecting to the ASA.


LDAP Server Support

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

Authentication with LDAP

LDAP Server Types

Authentication with LDAP

During authentication, the ASA 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 passes authentication parameters, usually a username and password, to the LDAP server in plain text.

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

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

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

You can configure the ASA and LDAP server to support any combination of these SASL mechanisms. If you configure multiple mechanisms, the ASA 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 and the server. For example, if both the LDAP server and the ASA support both mechanisms, the ASA selects Kerberos, the stronger of the mechanisms.

When user LDAP authentication has succeeded, the LDAP server returns the attributes for the authenticated user. For VPN authentication, these attributes generally include authorization data that is applied to the VPN session. Thus, using LDAP accomplishes authentication and authorization in a single step.

LDAP Server Types

The ASA 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 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 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 does not support password management with Novell, OpenLDAP, and other LDAPv3 directory servers.

The ASA uses the Login Distinguished Name (DN) and Login Password to establish a trust relationship (bind) with an LDAP server. For more information, see the "Binding the ASA to the LDAP Server" section.

HTTP Forms Authentication for Clientless SSL VPN

The ASA can use the HTTP Form protocol for both authentication and single sign-on (SSO) operations of Clientless SSL VPN user sessions only.

Local Database Support, Including as a Falback Method

The ASA 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.

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.

Using Certificates and User Login Credentials

The following section describes the different methods of using certificates and user login credentials (username and password) for authentication and authorization. These methods apply to IPsec, AnyConnect, and Clientless SSL VPN.

In all cases, LDAP authorization does not use the password as a credential. RADIUS authorization uses either a common password for all users or the username as a password.

This section includes the following topics:

Using User Login Credentials

Using Certificates

Using User Login Credentials

The default method for authentication and authorization uses the user login credentials.

Authentication

Enabled by the authentication server group setting in the tunnel group (also called ASDM Connection Profile)

Uses the username and password as credentials

Authorization

Enabled by the authorization server group setting in the tunnel group (also called ASDM Connection Profile)

Uses the username as a credential

Using Certificates

If user digital certificates are configured, the ASA first validates the certificate. It does not, however, use any of the DNs from certificates as a username for the authentication.

If both authentication and authorization are enabled, the ASA uses the user login credentials for both user authentication and authorization.

Authentication

Enabled by the authentication server group setting

Uses the username and password as credentials

Authorization

Enabled by the authorization server group setting

Uses the username as a credential

If authentication is disabled and authorization is enabled, the ASA uses the primary DN field for authorization.

Authentication

DISABLED (set to None) by the authentication server group setting

No credentials used

Authorization

Enabled by the authorization server group setting

Uses the username value of the certificate primary DN field as a credential


Note If the primary DN field is not present in the certificate, the ASA uses the secondary DN field value as the username for the authorization request.


For example, consider a user certificate that includes the following Subject DN fields and values:

Cn=anyuser,OU=sales;O=XYZCorporation;L=boston;S=mass;C=us;ea=anyuser@example.com
 
   

If the Primary DN = EA (E-mail Address) and the Secondary DN = CN (Common Name), then the username used in the authorization request would be anyuser@example.com.

Licensing Requirements for AAA Servers

Model
License Requirement

All models

Base License.


Guidelines and Limitations

This section includes the guidelines and limitations for this feature.

Context Mode Guidelines

Supported in single and multiple context mode.

Firewall Mode Guidelines

Supported in routed and transparent firewall mode.

IPv6 Guidelines

Supports IPv6.

Additional Guidelines

The username command has two versions: one for 8.4(3) and earlier and one for 8.4(4.1) and later. See the command reference for more information.

Configuring AAA

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

Managing User Passwords

Changing User Passwords

Authenticating Users with a Public Key for SSH

Task Flow for Configuring AAA


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 For an administrator, specify the password policy attributes for users. See the "Managing User Passwords" section.

Step 7 (Optional) Users can change their own passwords. See the "Changing User Passwords" section.

Step 8 (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 in single mode or 4 server groups per context in multiple mode.

Each group can have up to 16 servers in single mode or 4 servers in multiple mode.

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 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 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

HTTP Form

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 sends accounting data to only one server.

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


Note This option is not available for the following protocols: HTTP Form, 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 (Optional) If you are adding a RADIUS server type, perform the following steps:

a. Check the Enable interim accounting update check box if you want to enable multi-session accounting for clientless SSL and AnyConnect sessions.

b. Check the Enable Active Directory Agent Mode check box to specify the shared secret between the ASA and the AD agent and indicate that a RADIUS server group includes AD agents that are not full-function RADIUS servers. Only a RADIUS server group that has been configured using this option can be associated with user identity.

c. Click the VPN3K Compatibility Option down arrow to expand the list, and click one of the following radio buttons to specify whether or not a downloadable ACL received from a RADIUS packet should be merged with a Cisco AV pair ACL:

Do not merge

Place the downloadable ACL after Cisco AV-pair ACL

Place the downloadable ACL before Cisco AV-pair ACL

Step 10 Click OK.

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

Step 11 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 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 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

HTTP Form 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

HTTP Form 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 to handle netmasks received in downloadable access lists.

Detect automatically: The ASA attempts to determine the type of netmask expression used. If the ASA detects a wildcard netmask expression, the ASA 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 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 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. 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.

Microsoft CHAPv2 Capable

If you use double authentication and enable password management in the tunnel group, then the primary and secondary authentication requests include MS-CHAPv2 request attributes. If a RADIUS server does not support MS-CHAPv2, then you can configure that server to send a non-MS-CHAPv2 authentication request by unchecking this check box.

Retry Interval

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

Server Accounting Port

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

Server Authentication Port

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

Server Secret Key

The shared secret key used to authenticate the RADIUS server to the ASA. The server secret that you configure here 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. 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 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 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 communicates with the Kerberos server.

Retry Interval

The duration of time, 1 to 10 seconds, that the ASA 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 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 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. Only Microsoft AD and Sun LDAP servers additionally provide a VPN remote access password management capability, which requires LDAP-S.

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 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 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 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. For VPN password management operations, the Login DN needs elevated privileges and must be part of the Account Operators AD group.

The following is an example of a Login DN:

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

The ASA 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 does not support anonymous authentication.

Login Password

The password for the Login DN user account. The characters that 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 and the LDAP server.

SASL Kerberos authentication

When checked, the Kerberos mechanism of the SASL secures authentication communications between the ASA 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 the 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 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.


HTTP Form Server Fields

This area appears only when the selected server group uses HTTP Form, and only the server group name and the protocol are visible. Other fields are not available when using HTTP Form.

If you do not know what the following parameters are, use an HTTP header analyzer to extract the data from the HTTP GET and POST exchanges when logging into the authenticating web server directly, not through the ASA.

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

Field
Description

Start URL

The complete URL of the authenticating web server location where a pre-login cookie can be retrieved. This parameter must be configured only when the authenticating web server loads a pre-login cookie with the login page. A drop-down list offers both HTTP and HTTPS. The maximum number of characters is 1024, and there is no minimum.

Action URI

The complete Uniform Resource Identifier for the authentication program on the authorizing web server. The maximum number of characters for the complete URI is 2048 characters.

Username

The name of a username parameter—not a specific username—that must be submitted as part of the HTTP form used for SSO authentication. The maximum number of characters is 128, and there is no minimum.

Password

The name of a user password parameter—not a specific password value—that must be submitted as part of the HTTP form used for SSO authentication. The maximum number of characters is 128, and there is no minimum.

Hidden Values

The hidden parameters for the HTTP POST request submitted to the authenticating web server for SSO authentication. This parameter is necessary only when it is expected by the authenticating web server as indicated by its presence in the HTTP POST request. The maximum number of characters is 2048.

Authentication Cookie Name

(Optional) The name of the cookie that is set by the server on successful login and that contains the authentication information. It is used to assign a meaningful name to the authentication cookie to help distinguish it from other cookies that the web server may pass back. The maximum number of characters is 128, and there is no minimum.


Configuring LDAP Attribute Maps          

The ASA can use an LDAP directory for authenticating VPN remote access users or firewall network access/cut-thru-proxy sessions and/or for setting policy permissions (also called authorization attributes), such as ACLs, bookmark lists, DNS or WINS settings, session timers, and so on. That is, you can set the key attributes that exist in a local group policy externally through an LDAP server.

The authorization process is accomplished by means of LDAP attribute maps (similar to a RADIUS dictionary that defines vendor-specific attributes), which translate the native LDAP user attributes to Cisco ASA attribute names. You can then bind these attribute maps to LDAP servers or remove them, as needed. You can also show or clear attribute maps.

Guidelines

The ldap-attribute-map has a limitation with multi-valued attributes. For example, if a user is a memberOf of several AD groups and the ldap attribute map matches on more than one of them, the mapped value is chosen based on the alphabetization of the matched entries.

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. For more information about LDAP attribute maps, see the "Active Directory/LDAP VPN Remote Access Authorization Examples" section.

The names of frequently mapped Cisco LDAP attributes and the type of user-defined attributes that they would commonly be mapped to include the following:

IETF-Radius-Class (Group_Policy in ASA version 8.2 and later)—Sets the group policy based on the directory's department or user group (for example, Microsoft Active Directory memberOf) attribute value. The group-policy attribute replaced the IETF-Radius-Class attribute with ASDM version 6.2/ASA version 8.2 or later.

IETF-Radius-Filter-Id—An access control list or ACL applied to VPN clients, IPsec, and SSL.

IETF-Radius-Framed-IP-Address—Assigns a static IP address assigned to a VPN remote access client, IPsec, and SSL.

Banner1—Displays a text banner when the VPN remote access user logs in.

Tunneling-Protocols—Allows or denies the VPN remote access session based on the access type.


Note A single ldapattribute map may contain one or many attributes. You can only assign one ldap attribute to a specific LDAP server.


To map LDAP features correctly, perform the following steps:

Detailed Steps


Step 1 Choose Configuration > Remote Access VPN > AAA Local Users > LDAP Attribute Map, 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 and includes the following topics:

Adding a User

Configuring VPN Policy Attributes for a User

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

Limitations

You cannot use the local database for network access authorization.

Adding a User

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

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 To enable MS-CHAP authentication, check the User authenticated using MSCHAP check box.

This option specifies that the password is converted to Unicode and hashed using MD4 after you enter it. Use this feature if users are authenticated using MS-CHAPv1 or MS-CHAPv2.

Step 6 To specify the VPN groups that the user belongs to, enter a group name in the Member of field, and click Add.

To delete a VPN group, choose the group in the window, and click Delete.

Step 7 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 8 If you want to configure VPN policy attributes for this user, see the "Configuring VPN Policy Attributes for a User" section.

Step 9 Click Apply.

The user is added to the local ASA 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.



Configuring VPN Policy Attributes for a User

By default, each user inherits the settings set in the VPN policy.

To override the settings, you can customize VPN attributes by performing the following steps:

Detailed Steps


Step 1 If you have not already added a user according to the "Adding a User" section, from the Configuration > Device Management > Users/AAA > User Accounts pane, click Add.

The Add User Account-Identity dialog box appears.

Step 2 In the left-hand pane, click VPN Policy.

By default, the Inherit check box is checked for each option, which means the user account inherits the settings from the VPN policy. To override each setting, uncheck the Inherit check box, and enter a new value:

a. Choose a group policy from the list.

b. Specify which tunneling protocols are available for use, or whether the value is inherited from the group policy. Check the desired Tunneling Protocols check boxes to choose the VPN tunneling protocols that are available for use. Only the selected protocols are available for use. The choices are as follows:

IPsec provides the most complete architecture for VPN tunnels, and it is perceived as the most secure protocol. Both LAN-to-LAN (peer-to-peer) connections and client-to-LAN connections can use IPsec.

VPN via SSL/TLS (Clientless SSL VPN) uses a web browser to establish a secure remote-access tunnel to a VPN Concentrator; requires neither a software nor hardware client. Clientless SSL VPN can provide easy access to a broad range of enterprise resources, including corporate websites, web-enabled applications, NT/AD file shares (web-enabled), e-mail, and other TCP-based applications from almost any computer that can reach HTTPS Internet sites.

The SSL VPN Client lets users connect after downloading the Cisco AnyConnect Client application. Users use a clientless SSL VPN connection to download this application the first time. Client updates then occur automatically as needed whenever the user connects.

L2TP over IPsec allows remote users with VPN clients provided with several common PC and mobile PC operating systems to establish secure connections over the public IP network to the ASA and private corporate networks.


Note If no protocol is selected, an error message appears.


c. Specify which filter (IPv4 or IPv6) to use, or whether to inherit the value from the group policy. Filters consist of rules that determine whether to allow or reject tunneled data packets coming through the ASA, based on criteria such as source address, destination address, and protocol. To configure filters and rules, choose Configuration > VPN > VPN General > Group Policy.

d. Click Manage to display the ACL Manager pane, on which you can add, edit, and delete ACLs and ACEs.

e. Specify whether to inherit the tunnel group lock or to use the selected tunnel group lock, if any. Selecting a specific lock restricts users to remote access through this group only. Tunnel Group Lock restricts users by checking if the group configured in the VPN client is the same as the users assigned group. If it is not, the ASA prevents the user from connecting. If the Inherit check box is not checked, the default value is None.

f. Specify whether to inherit the Store Password on Client System setting from the group. Uncheck the Inherit check box to activate the Yes and No radio buttons. Click Yes to store the login password on the client system (potentially a less-secure option). Click No (the default) to require the user to enter the password with each connection. For maximum security, we recommend that you not allow password storage. This parameter has no effect on interactive hardware client authentication or individual user authentication for a VPN 3002.

Step 3 To change Connection Settings, uncheck the Inherit check box, and enter a new value:

a. If the Inherit check box is not checked, you can select the name of an existing access hours policy, if any, to apply to this user or create a new access hours policy. The default value is Inherit, or, if the Inherit check box is not checked, the default value is Unrestricted.

b. Click New to open the Add Time Range dialog box, in which you can specify a new set of access hours.

c. If the Inherit check box is not checked, the Simultaneous Logins parameter specifies the maximum number of simultaneous logins allowed for this user. The default value is 3. The minimum value is 0, which disables login and prevents user access.


Note While there is no maximum limit, allowing several simultaneous connections could compromise security and affect performance.


d. If the Inherit check box is not checked, the Maximum Connect Time parameter specifies the maximum user connection time in minutes. At the end of this time, the system terminates the connection. The minimum is 1 minute, and the maximum is 2147483647 minutes (over 4000 years). To allow unlimited connection time, check the Unlimited check box (the default).

e. If the Inherit check box is not checked, the Idle Timeout parameter specifies the idle timeout period in minutes of this user. If there is no communication activity on the connection of this user in this period, the system terminates the connection. The minimum time is 1 minute, and the maximum time is 10080 minutes. This value does not apply to users of clientless SSL VPN connections.

Step 4 To set a dedicated IP address for this user, enter an IP address and subnet mask in the Dedicated IP Address (Optional) area.

Step 5 To configure clientless SSL settings, in the left-hand pane, click Clientless SSL VPN. To override each setting, uncheck the Inherit check box, and enter a new value.

Step 6 Click Apply.

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 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 displays the User accepted message text, if specified, to the user; otherwise, the ASA 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.


Managing User Passwords

The ASA enables administrators with the necessary privileges to modify password policy for users in the current context.

User passwords have the following guidelines:

A maximum lifetime of 0 to 65536 days.

A minimum length of 3 to 64 characters.

A minimum number of changed characters for updates of 0 to 64 characters.

They may include lower case characters.

They may include upper case characters.

They may include numbers.

They may include special characters.

To specify password policy for users, perform the following steps:


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

Enter the minimum length for passwords. Valid values range from 3 to 64 characters. The recommended minimum password length is 8 characters. If the minimum length is less than the value of any of the other minimum values (lower case, numeric, special, and upper case), an error message appears and the minimum length is not changed.

Step 2 Enter the minimum number of changed characters for password updates. Valid values range from 0 to 64 characters. The default value is 0.

Step 3 Enter the password lifetime in days. Valid values range from 0 to 65536 days. A zero value indicates that there is no minimum password lifetime.

Step 4 Enter the minimum number of lower case characters for passwords. Valid values range from 0 to 64 characters. A zero value indicates there is no minimum number of lower case characters for passwords.

Step 5 Enter the minimum number of upper case characters for passwords. Valid values range from 0 to 64 characters. A zero value indicates there is no minimum number of upper case characters for passwords.

Step 6 Enter the minimum number of special characters for passwords. Valid values range from 0 to 64 characters. Special characters include the following: !, @, #, $, %, ^, &, *, '(` and `)'. A zero value indicates that there is no minimum number of special characters for passwords.

Step 7 (Optional) Check the Authentication Enable check box to prevent users from modifying their own user account. If authentication is enabled, users cannot change their own password or delete their own account with the username command or with the clear configure username command.

Step 8 To reset the password policy to the default ASA policy value, click Reset to Default.

Step 9 Click Apply to save the configuration settings.


Changing User Passwords

The ASA enables administrators with the necessary privileges to modify passwords for users in the current context. Users must authenticate with their current passwords before they are allowed to change passwords. However, authentication is not required when an administrator is changing a user password.

To enable users to change their own account passwords, peform the following steps:


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

Step 2 Enter your old password.

Step 3 Enter your new password.

Step 4 Confirm your new password.

Step 5 Click Make Change.

Step 6 Click the Save icon to save your changes to the running configuration.


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.


Testing Server Authentication and Authorization

To determine whether the ASA 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 sends an authentication or authorization test message to the server. If the test fails, ASDM displays an error message.


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.

Choose Tools > Command Line Interface, enter the show running-config [all] password policy command, then press Send.

Shows the password policy for the current context.


Additional References

For additional information related to implementing LDAP mapping, see the "RFCs" 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 Servers

Table 38-2 lists each feature change and the platform release in which it was implemented. ASDM is backwards-compatible with multiple platform releases, so the specific ASDM release in which support was added is not listed.

Table 38-2 Feature History for AAA Servers

Feature Name
Platform Releases
Feature Information

AAA Servers

7.0(1)

AAA Servers describe support for AAA and how to configure AAA servers and the local database.

We introduced the following screens:

Configuration > Device Management > Users/AAA > AAA Server Groups
Configuration > Remote Access VPN > AAA Local Users > LDAP Attribute Map
Configuration > Device Management > Users/AAA > User Accounts
Configuration > Device Management > Users/AAA > Authentication Prompt

Key vendor-specific attributes (VSAs) sent in RADIUS access request and accounting request packets from the ASA

8.4(3)

Four New VSAs—Tunnel Group Name (146) and Client Type (150) are sent in RADIUS access request packets from the ASA. Session Type (151) and Session Subtype (152) are sent in RADIUS accounting request packets from the ASA. All four attributes are sent for all accounting request packet types: Start, Interim-Update, and Stop. The RADIUS server (for example, ACS and ISE) can then enforce authorization and policy attributes or use them for accounting and billing purposes.

Common Criteria certification and FIPS support for password policy, password change, and SSH public key authentication

8.4(4.1)

We introduced the following screens: Configuration > Device Management > Users/AAA > Password Policy
Configuration > Device Management > Users/AAA > Change Password
Configuration > Device Management > Users/AAA > User Accounts > Edit User Account > Public Key Authentication.