CH A P T E R 12

Configuring AAA Servers and the Local Database

This chapter describes support for AAA (pronounced “triple A”) and how to configure AAA servers and
the local database.
This chapter contains the following sections:
• AAA Overview, page 12-1
• AAA Server and Local Database Support, page 12-3
• Configuring the Local Database, page 12-7
• Identifying AAA Server Groups and Servers, page 12-9
• Configuring an LDAP Server, page 12-12
• Using Certificates and User Login Credentials, page 12-16
• Supporting a Zone Labs Integrity Server, page 12-17
• Differentiating User Roles Using AAA, page 12-19

AAA Overview
AAA enables the security appliance 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 make it
through the security appliance. (The Telnet server enforces authentication, too; the security appliance
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:
• About Authentication, page 12-2
• About Authorization, page 12-2
• About Accounting, page 12-2

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-1
 Chapter 12 Configuring AAA Servers and the Local Database
AAA Overview

About Authentication
Authentication controls access by requiring valid user credentials, which are typically a username and
password. You can configure the security appliance to authenticate the following items:
• All administrative connections to the security appliance including the following sessions:
– Telnet
– SSH
– Serial console
– ASDM (using HTTPS)
– VPN management access
• The enable command
• Network access
• VPN access

About Authorization
Authorization controls access per user after users authenticate. You can configure the security appliance
to authorize the following items:
• Management commands
• Network access
• VPN access
Authorization controls the services and commands available to each authenticated user. Were you not to
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 authenticate inside users who attempt
to access any server on the outside network and then limit the outside servers that a particular user can
access using authorization.
The security appliance caches the first 16 authorization requests per user, so if the user accesses the same
services during the current authentication session, the security appliance does not resend the request to
the authorization server.

About Accounting
Accounting tracks traffic that passes through the security appliance, 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
when sessions start and stop, username, the number of bytes that pass through the security appliance for
the session, the service used, and the duration of each session.

Cisco Security Appliance Command Line Configuration Guide

12-2 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
AAA Server and Local Database Support

AAA Server and Local Database Support

The security appliance supports a variety of AAA server types and a local database that is stored on the
security appliance. This section describes support for each AAA server type and the local database.
This section contains the following topics:
• Summary of Support, page 12-3
• RADIUS Server Support, page 12-4
• TACACS+ Server Support, page 12-5
• RSA/SDI Server Support, page 12-5
• NT Server Support, page 12-6
• Kerberos Server Support, page 12-6
• LDAP Server Support, page 12-6
• SSO Support for Clientless SSL VPN with HTTP Forms, page 12-6
• Local Database Support, page 12-6

Summary of Support
Table 12-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, refer to the topics
following the table.

Table 12-1 Summary of AAA Support

Database Type
RSA/S HTTP
AAA Service Local RADIUS TACACS+ DI NT Kerberos LDAP 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
4
Firewall sessions No Yes Yes No No No No No
5
Administrators Yes 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
6
Administrators No Yes Yes No No No No No
1. For SSL VPN connections, either PAP or MS-CHAPv2 can be used.
2. HTTP Form protocol supports single sign-on authentication for Clientless SSL VPN users only.
3. RSA/SDI is not supported for HTTP administrative access.

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-3
 Chapter 12 Configuring AAA Servers and the Local Database
AAA Server and Local Database Support

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.

RADIUS Server Support

The security appliance supports RADIUS servers.
This section contains the following topics:
• Authentication Methods, page 12-4
• Attribute Support, page 12-4
• RADIUS Authorization Functions, page 12-5

Authentication Methods
The security appliance supports the following authentication methods with RADIUS:
• PAP—For all connection types.
• CHAP—For L2TP-over-IPsec.
• MS-CHAPv1—For L2TP-over-IPsec.
• MS-CHAPv2—For L2TP-over-IPsec, 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/SI to RADIUS.

Note To enable MSChapV2 as the protocol used between the security appliance and the RADIUS server for a
clientless connection, password management must be enabled in the tunnel-group general-attributes.
Enabling password management prevents usernames and passwords from being transmitted in clear text
between the security appliance and the RADIUS server. See the description of the
password-management command for details.

Attribute Support
The security appliance 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 VSAs, identified by RADIUS vendor ID 9.
• Cisco VPN-related VSAs, identified by RADIUS vendor ID 3076.
• Microsoft VSAs, defined in RFC 2548.

Cisco Security Appliance Command Line Configuration Guide

12-4 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
AAA Server and Local Database Support

RADIUS Authorization Functions

The security appliance can use RADIUS servers for user authorization for network access 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 security appliance. Access to a given service is either permitted or
denied by the access list. The security appliance deletes the access list when the authentication session
expires.

TACACS+ Server Support

The security appliance 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 contains the following topics:
• RSA/SDI Version Support, page 12-5
• Two-step Authentication Process, page 12-5
• RSA/SDI Primary and Replica Servers, page 12-5

RSA/SDI Version Support

The security appliance supports SDI Version 5.0 and 6.0. 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/Server IP address with .sdi appended.
A version 5.0 or 6.0 SDI server that you configure on the security appliance can be either the primary or
any one of the replicas. See the “RSA/SDI Primary and Replica Servers” section on page 12-5 for
information about how the SDI agent selects servers to authenticate users.

Two-step Authentication Process

SDI version 5.0 and 6.0 uses 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 means that the same user
cannot authenticate to two security appliances using the same authentication servers simultaneously.
After a successful username lock, the security appliance sends the passcode.

RSA/SDI Primary and Replica Servers

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

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-5
 Chapter 12 Configuring AAA Servers and the Local Database
AAA Server and Local Database Support

NT Server Support
The security appliance 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.
This is a limitation of NTLM version 1.

Kerberos Server Support

The security appliance supports 3DES, DES, and RC4 encryption types.

Note The security appliance 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 security appliance.

For a simple Kerberos server configuration example, see Example 12-2 on page 12-12.

LDAP Server Support

The security appliance supports LDAP. For detailed information, see the “Configuring an LDAP Server”
section on page 12-12.

SSO Support for Clientless SSL VPN with HTTP Forms

The security appliance can use the HTTP Form protocol for single sign-on (SSO) authentication of
Clientless SSL VPN users only. Single sign-on support lets Clientless SSL VPN users enter a username
and password only once to access multiple protected services and Web servers. The Clientless SSL VPN
server running on the security appliance acts as a proxy for the user to the authenticating server. When
a user logs in, the Clientless SSL VPN server sends an SSO authentication request, including username
and password, to the authenticating server using HTTPS. If the server approves the authentication
request, it returns an SSO authentication cookie to the Clientless SSL VPN server. The security
appliance keeps this cookie on behalf of the user and uses it to authenticate the user to secure websites
within the domain protected by the SSO server.
In addition to the HTTP Form protocol, Clientless SSL VPN administrators can choose to configure SSO
with the HTTP Basic and NTLM authentication protocols (the auto-signon command), or with
Computer Associates eTrust SiteMinder SSO server (formerly Netegrity SiteMinder) as well. For an
in-depth discussion of configuring SSO with either HTTP Forms, auto-signon or SiteMinder, see the
Configuring Clientless SSL VPN chapter.

Local Database Support

The security appliance maintains a local database that you can populate with user profiles.

Cisco Security Appliance Command Line Configuration Guide

12-6 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring the Local Database

This section contains the following topics:

• User Profiles, page 12-7
• Fallback Support, page 12-7

User Profiles
User profiles contain, at a minimum, a username. Typically, a password is assigned to each username,
although passwords are optional.
The username attributes command lets you enter the username mode. In this mode, you can add other
information to a specific user profile. The information you can add includes VPN-related attributes, such
as a VPN session timeout value.

Fallback Support
The local database can act as a fallback method for several functions. This behavior is designed to help
you prevent accidental lockout from the security appliance.
For users who need fallback support, we recommend that their usernames and passwords in the local
database match their usernames and passwords in the AAA servers. This 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—When you use the aaa authentication console
command, you can add the LOCAL keyword after the AAA server group tag. If the servers in the
group all are unavailable, the security appliance uses the local database to authenticate
administrative access. This can include enable password authentication, too.
• Command authorization—When you use the aaa authorization command command, you can
add the LOCAL keyword after the AAA server group tag. If the TACACS+ servers in the group all
are 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 security appliance if AAA servers that normally support these VPN
services are unavailable. The authentication-server-group command, available in tunnel-group
general attributes mode, lets you specify the LOCAL keyword when you are configuring attributes
of a tunnel group. When 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.

Configuring the Local Database

This section describes how to manage users in the local database. You can use the local database for
CLI access authentication, privileged mode authentication, command authorization, network access
authentication, and VPN authentication and authorization. You cannot use the local database for network
access authorization. The local database does not support accounting.

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-7
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring the Local Database

For multiple context mode, you can configure usernames in the system execution space to provide
individual logins using the login command; however, you cannot configure any aaa commands in the
system execution space.
To define a user account in the local database, perform the following steps:

Step 1 To create the user account, enter the following command:

hostname(config)# username name {nopassword | password password [mschap]} [privilege
priv_level]

where the username keyword is a string from 4 to 64 characters long.

The password password argument is a string from 3 to 16 characters long.
The mschap keyword specifies that the password is e converted to unicode and hashed using MD4 after
you enter it. Use this keyword if users are authenticated using MSCHAPv1 or MSCHAPv2.
The privilege level argument sets the privilege level from 0 to 15. The default is 2. This privilege level
is used with command authorization.

Caution If you do not use command authorization (the aaa authorization command LOCAL command), then
the default level 2 allows management access to privileged EXEC mode. If you want to limit access to
privileged EXEC mode, either set the privilege level to 0 or 1, or use the service-type command (see
Step 4).

The nopassword keyword creates a user account with no password.

Note The encrypted and nt-encrypted keywords are typically for display only. When you define a password
in the username command, the security appliance encrypts it when it saves it to the configuration for
security purposes. When you enter the show running-config command, the username command does
not show the actual password; it shows the encrypted password followed by the encrypted or
nt-encrypted keyword (when you specify mschap). For example, if you enter the password “test,” the
show running-config display would appear to be something like the following:
username pat password DLaUiAX3l78qgoB5c7iVNw== nt-encrypted

The only time you would actually enter the encrypted or nt-encrypted keyword at the CLI is if you are
cutting and pasting a configuration to another security appliance and you are using the same password.

Step 2 (Optional) To enforce user-specific access levels for users who authenticate for management access (see
the aaa authentication console LOCAL command), enter the following command:
hostname(config)# aaa authorization exec authentication-server

This command enables management authorization for local users and for any users authenticated by
RADIUS, LDAP, and TACACS+. See the “Limiting User CLI and ASDM Access with Management
Authorization” section on page 37-7 for information about configuring a user on a AAA server to
accommodate management authorization.
For a local user, configure the level of access using the service-type command as described in Step 4.
Step 3 (Optional) To configure username attributes, enter the following command:
hostname(config)# username username attributes

where the username argument is the username you created in Step 1.

Cisco Security Appliance Command Line Configuration Guide

12-8 OL-12172-02
Chapter 12 Configuring AAA Servers and the Local Database
Identifying AAA Server Groups and Servers

Step 4 (Optional) If you configured management authorization in Step 2, enter the following command to
configure the user level:
hostname(config-username)# service-type {admin | nas-prompt | remote-access}

where the admin keyword allows full access to any services specified by the aaa authentication console
LOCAL commands. admin is the default.
The nas-prompt keyword allows access to the CLI when you configure the aaa authentication {telnet
| ssh | serial} console LOCAL command, but denies ASDM configuration access if you configure the
aaa authentication http console LOCAL command. ASDM monitoring access is allowed. If you
configure enable authentication with the aaa authentication enable console LOCAL command, the
user cannot access privileged EXEC mode using the enable command (or by using the login command).
The remote-access keyword denies management access. The user cannot use any services specified by
the aaa authentication console LOCAL commands (excluding the serial keyword; serial access is
allowed).
Step 5 (Optional) If you are using this username for VPN authentication, you can configure many VPN
attributes for the user. See the “Configuring User Attributes” section on page 28-76.

For example, the following command assigns a privilege level of 15 to the admin user account:
hostname(config)# username admin password passw0rd privilege 15

The following command creates a user account with no password:

hostname(config)# username bcham34 nopassword

The following commands enable management authorization, creates a user account with a password,
enters username attributes configuration mode, and specifies the service-type attribute:
hostname(config)# aaa authorization exec authentication-server
hostname(config)# username rwilliams password gOgeOus
hostname(config)# username rwilliams attributes
hostname(config-username)# service-type nas-prompt

Identifying AAA Server Groups and Servers

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, RSA/SDI, or TACACS+.
The security appliance contacts the first server in the group. If that server is unavailable, the security
appliance contacts the next server in the group, if configured. If all servers in the group are unavailable,
the security appliance 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 security appliance
continues to try the AAA servers.
To create a server group and add AAA servers to it, follow these steps:

Step 1 For each AAA server group you need to create, follow these steps:
a. Identify the server group name and the protocol. To do so, enter the following command:

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-9
 Chapter 12 Configuring AAA Servers and the Local Database
Identifying AAA Server Groups and Servers

hostname(config)# aaa-server server_group protocol {kerberos | ldap | nt | radius |

sdi | tacacs+}

For example, to use RADIUS to authenticate network access and TACACS+ to authenticate CLI
access, you need to create at least two server groups, one for RADIUS servers and one for TACACS+
servers.
You can have up to 15 single-mode server groups or 4 multi-mode server groups. Each server group
can have up to 16 servers in single mode or up to 4 servers in multi-mode.
When you enter a aaa-server protocol command, you enter group mode.
b. If you want to specify the maximum number of requests sent to a AAA server in the group before
trying the next server, enter the following command:
hostname(config-aaa-server-group)# max-failed-attempts number

The number can be between 1 and 5. The default is 3.

If you configured a fallback method using the local database (for management access only; see the
“Configuring AAA for System Administrators” section on page 37-5 and the “Configuring
TACACS+ Command Authorization” section on page 37-13 to configure the fallback mechanism),
and all the servers in the group fail to respond, then the group is considered to be unresponsive, and
the fallback method is tried. The server group remains marked as unresponsive for a period of 10
minutes (by default) so that additional AAA requests within that period do not attempt to contact
the server group, and the fallback method is used immediately. To change the unresponsive period
from the default, see the reactivation-mode command in the following step.
If you do not have a fallback method, the security appliance continues to retry the servers in the
group.
c. If you want to specify the method (reactivation policy) by which failed servers in a group are
reactivated, enter the following command:
hostname(config-aaa-server-group)# # reactivation-mode {depletion [deadtime minutes] |
timed}

Where the depletion keyword reactivates failed servers only after all of the servers in the group are
inactive.
The deadtime minutes argument specifies the amount of time in minutes, between 0 and 1440, that
elapses between the disabling of the last server in the group and the subsequent re-enabling of all
servers. The default is 10 minutes.
The timed keyword reactivates failed servers after 30 seconds of down time.
d. If you want to send accounting messages to all servers in the group (RADIUS or TACACS+ only),
enter the following command:
hostname(config-aaa-server-group)# accounting-mode simultaneous

To restore the default of sending messages only to the active server, enter the accounting-mode
single command.
Step 2 For each AAA server on your network, follow these steps:
a. Identify the server, including the AAA server group it belongs to. To do so, enter the following
command:
hostname(config)# aaa-server server_group (interface_name) host server_ip

When you enter a aaa-server host command, you enter host mode.
b. As needed, use host mode commands to further configure the AAA server.

Cisco Security Appliance Command Line Configuration Guide

12-10 OL-12172-02
Chapter 12 Configuring AAA Servers and the Local Database
Identifying AAA Server Groups and Servers

The commands in host mode do not apply to all AAA server types. Table 12-2 lists the available
commands, the server types they apply to, and whether a new AAA server definition has a default
value for that command. Where a command is applicable to the server type you specified and no
default value is provided (indicated by “—”), use the command to specify the value. For more
information about these commands, see the Cisco Security Appliance Command Reference.

Table 12-2 Host Mode Commands, Server Types, and Defaults

Command Applicable AAA Server Types Default Value

accounting-port RADIUS 1646
acl-netmask-convert RADIUS standard
authentication-port RADIUS 1645
kerberos-realm Kerberos —
key RADIUS —
TACACS+ —
ldap-attribute-map LDAP —
ldap-base-dn LDAP —
ldap-login-dn LDAP —
ldap-login-password LDAP —
ldap-naming-attribute LDAP —
ldap-over-ssl LDAP —
ldap-scope LDAP —
nt-auth-domain-controller NT —
radius-common-pw RADIUS —
retry-interval Kerberos 10 seconds
RADIUS 10 seconds
RSA/SDI 10 seconds
sasl-mechanism LDAP —
server-port Kerberos 88
LDAP 389
NT 139
RSA/SDI 5500
TACACS+ 49
server-type LDAP auto-discovery
timeout All 10 seconds

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-11
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring an LDAP Server

Example 12-1 shows commands that add one TACACS+ group with one primary and one backup server,
one RADIUS group with a single server, and an NT domain server.

Example 12-1 Multiple AAA Server Groups and Servers

hostname(config)# aaa-server AuthInbound protocol tacacs+

hostname(config-aaa-server-group)# max-failed-attempts 2
hostname(config-aaa-server-group)# reactivation-mode depletion deadtime 20
hostname(config-aaa-server-group)# exit
hostname(config)# aaa-server AuthInbound (inside) host 10.1.1.1
hostname(config-aaa-server-host)# key TACPlusUauthKey
hostname(config-aaa-server-host)# exit
hostname(config)# aaa-server AuthInbound (inside) host 10.1.1.2
hostname(config-aaa-server-host)# key TACPlusUauthKey2
hostname(config-aaa-server-host)# exit
hostname(config)# aaa-server AuthOutbound protocol radius
hostname(config-aaa-server-group)# exit
hostname(config)# aaa-server AuthOutbound (inside) host 10.1.1.3
hostname(config-aaa-server-host)# key RadUauthKey
hostname(config-aaa-server-host)# exit
hostname(config)# aaa-server NTAuth protocol nt
hostname(config-aaa-server-group)# exit
hostname(config)# aaa-server NTAuth (inside) host 10.1.1.4
hostname(config-aaa-server-host)# nt-auth-domain-controller primary1
hostname(config-aaa-server-host)# exit

Example 12-2 shows commands that configure a Kerberos AAA server group named watchdogs, add a
AAA server to the group, and define the Kerberos realm for the server. Because Example 12-2 does not
define a retry interval or the port that the Kerberos server listens to, the security appliance uses the
default values for these two server-specific parameters. Table 12-2 lists the default values for all AAA
server host mode commands.

Note Kerberos realm names use numbers and upper-case letters only. Although the security appliance accepts
lower-case letters for a realm name, it does not translate lower-case letters to upper-case letters. Be sure
to use upper-case letters only.

Example 12-2 Kerberos Server Group and Server

hostname(config)# aaa-server watchdogs protocol kerberos

hostname(config-aaa-server-group)# aaa-server watchdogs host 192.168.3.4
hostname(config-aaa-server-host)# kerberos-realm EXAMPLE.COM
hostname(config-aaa-server-host)# exit
hostname(config)#

Configuring an LDAP Server

This section describes using an LDAP directory with the security appliance for user authentication and
VPN authorization. This section includes the following topics:
• Authentication with LDAP, page 12-13
• Authorization with LDAP for VPN, page 12-14
• LDAP Attribute Mapping, page 12-15
For example configuration procedures used to set up LDAP authentication or authorization, see
“Appendix E, “Configuring an External Server for Authorization and Authentication.”

Cisco Security Appliance Command Line Configuration Guide

12-12 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring an LDAP Server

Authentication with LDAP

During authentication, the security appliance acts as a client proxy to the LDAP server for the user, and
authenticates to the LDAP server in either plain text or using the Simple Authentication and Security
Layer (SASL) protocol. By default, the security appliance passes authentication parameters, usually a
username and password, to the LDAP server in plain text. Whether using SASL or plain text, you can
secure the communications between the security appliance and the LDAP server with SSL using the
ldap-over-ssl command.

Note If you do not configure SASL, we strongly recommend that you secure LDAP communications with
SSL. See the ldap-over-ssl command in the Cisco Security Appliance Command Reference.

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 which
is applied to the VPN session. Thus, using LDAP accomplishes authentication and authorization in a
single step.

Securing LDAP Authentication with SASL

The security appliance supports the following SASL mechanisms, listed in order of increasing strength:
• Digest-MD5 — The security appliance responds to the LDAP server with an MD5 value computed
from the username and password.
• Kerberos — The security appliance responds to the LDAP server by sending the username and realm
using the GSSAPI (Generic Security Services Application Programming Interface) Kerberos
mechanism.
You can configure the security appliance and LDAP server to support any combination of these SASL
mechanisms. If you configure multiple mechanisms, the security appliance retrieves the list of SASL
mechanisms configured on the server and sets the authentication mechanism to the strongest mechanism
configured on both the security appliance and the server. For example, if both the LDAP server and the
security appliance support both mechanisms, the security appliance selects Kerberos, the stronger of the
mechanisms.
The following example configures the security appliance for authentication to an LDAP directory server
named ldap_dir_1 using the digest-MD5 SASL mechanism, and communicating over an SSL-secured
connection:
hostname(config)# aaa-server ldap_dir_1 protocol ldap
hostname(config-aaa-server-group)# aaa-server ldap_dir_1 host 10.1.1.4
hostname(config-aaa-server-host)# sasl-mechanism digest-md5
hostname(config-aaa-server-host)# ldap-over-ssl enable
hostname(config-aaa-server-host)#

Setting the LDAP Server Type

The security appliance 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, and other LDAPv3 directory servers.
By default, the security appliance auto-detects whether it is connected to a Microsoft Active Directory,
a Sun LDAP directory server, 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 using the keywords sun, microsoft, or generic. The
following example sets the LDAP directory server ldap_dir_1 to the Sun Microsystems type:

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-13
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring an LDAP Server

hostname(config)# aaa-server ldap_dir_1 protocol ldap

hostname(config-aaa-server-group)# aaa-server ldap_dir_1 host 10.1.1.4
hostname(config-aaa-server-host)# server-type sun
hostname(config-aaa-server-host)#

Note • Sun—The DN configured on the security appliance 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 ACI on
the default password policy.
• Microsoft—You must configure LDAP over SSL to enable password management with Microsoft
Active Directory.
• Generic—The security appliance does not support password management with a generic LDAPv3
directory server.

Authorization with LDAP for VPN

When user LDAP authentication for VPN access has succeeded, the security appliance queries the LDAP
server which returns LDAP attributes. These attributes generally include authorization data that applies
to the VPN session. Thus, using LDAP accomplishes authentication and authorization in a single step.
There may be cases, however, where you require authorization from an LDAP directory server that is
separate and distinct from the authentication mechanism. For example, if you use an SDI or certificate
server for authentication, no authorization information is passed back. For user authorizations in this
case, you can query an LDAP directory after successful authentication, accomplishing authentication
and authorization in two steps.
To set up VPN user authorization using LDAP, you must first create a AAA server group and a tunnel
group. You then associate the server and tunnel groups using the tunnel-group general-attributes
command. While there are other authorization-related commands and options available for specific
requirements, the following example shows fundamental commands for enabling user authorization with
LDAP. This example then creates an IPsec remote access tunnel group named remote-1, and assigns that
new tunnel group to the previously created ldap_dir_1 AAA server for authorization.
hostname(config)# tunnel-group remote-1 type ipsec-ra
hostname(config)# tunnel-group remote-1 general-attributes
hostname(config-general)# authorization-server-group ldap_dir_1
hostname(config-general)#

After you complete this fundamental configuration work, you can configure additional LDAP
authorization parameters such as a directory password, a starting point for searching a directory, and the
scope of a directory search:
hostname(config)# aaa-server ldap_dir_1 protocol ldap
hostname(config-aaa-server-group)# aaa-server ldap_dir_1 host 10.1.1.4
hostname(config-aaa-server-host)# ldap-login-dn obscurepassword
hostname(config-aaa-server-host)# ldap-base-dn starthere
hostname(config-aaa-server-host)# ldap-scope subtree
hostname(config-aaa-server-host)#

See LDAP commands in the Cisco Security Appliance Command Reference for more information.

Cisco Security Appliance Command Line Configuration Guide

12-14 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Configuring an LDAP Server

LDAP Attribute Mapping

If you are introducing a security appliance to an existing LDAP directory, your existing LDAP attribute
names and values are probably different from the existing ones. You must create LDAP attribute maps
that map your existing user-defined attribute names and values to Cisco attribute names and values that
are compatible with the security appliance. You can then bind these attribute maps to LDAP servers or
remove them as needed. You can also show or clear attribute maps.

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

The following command, entered in global configuration mode, creates an unpopulated LDAP attribute
map table named att_map_1:
hostname(config)# ldap attribute-map att_map_1
hostname(config-ldap-attribute-map)#

The following commands map the user-defined attribute name department to the Cisco attribute name
IETF-Radius-Class. The second command maps the user-defined attribute value Engineering to the
user-defined attribute department and the Cisco-defined attribute value group1.
hostname(config)# ldap attribute-map att_map_1
hostname(config-ldap-attribute-map)# map-name department IETF-Radius-Class
hostname(config-ldap-attribute-map)# map-value department Engineering group1
hostname(config-ldap-attribute-map)#

The following commands bind the attribute map att_map_1 to the LDAP server ldap_dir_1:
hostname(config)# aaa-server ldap_dir_1 host 10.1.1.4
hostname(config-aaa-server-host)# ldap-attribute-map att_map_1
hostname(config-aaa-server-host)#

Note The command to create an attribute map (ldap attribute-map) and the command to bind it to an LDAP
server (ldap-attribute-map) differ only by a hyphen and the mode.

The following commands display or clear all LDAP attribute maps in the running configuration:
hostname# show running-config all ldap attribute-map
hostname(config)# clear configuration ldap attribute-map
hostname(config)#

The names of frequently mapped Cisco LDAP attributes and the type of user-defined attributes they
would commonly be mapped to include:
IETF-Radius-Class — Department or user group
IETF-Radius-Filter-Id — Access control list
IETF-Radius-Framed-IP-Address — A static IP address
IPSec-Banner1 — A organization title
Tunneling-Protocols — Allow or deny dial-in

The following example shows how to limit management sessions to the security appliance based on an
LDAP attribute called accessType. The accessType attribute has three possible values:
• VPN
• admin
• helpdesk

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-15
 Chapter 12 Configuring AAA Servers and the Local Database
Using Certificates and User Login Credentials

Each value is mapped to one of the valid IETF RADIUS Service-Types that the security appliance
supports: remote-access (Service-Type 5) Outbound, admin (Service-Type 6) Administrative, and
nas-prompt (Service-Type 7) NAS Prompt.
hostname(config)# ldap attribute-map MGMT
hostname(config-ldap-attribute-map)# map-name accessType IETF-Radius-Service-Type
hostname(config-ldap-attribute-map)# map-value accessType VPN 5
hostname(config-ldap-attribute-map)# map-value accessType admin 6
hostname(config-ldap-attribute-map)# map-value accessType helpdesk 7

hostname(config-ldap-attribute-map)# aaa-server LDAP protocol ldap

hostname(config-aaa-server-group)# aaa-server LDAP (inside) host 10.1.254.91
hostname(config-aaa-server-host)# ldap-base-dn CN=Users,DC=cisco,DC=local
hostname(config-aaa-server-host)# ldap-scope subtree
hostname(config-aaa-server-host)# ldap-login-password test
hostname(config-aaa-server-host)# ldap-login-dn
CN=Administrator,CN=Users,DC=cisco,DC=local
hostname(config-aaa-server-host)# server-type auto-detect
hostname(config-aaa-server-host)# ldap-attribute-map MGMT

For a list of Cisco LDAP attribute names and values, see Appendix E, “Configuring an External Server
for Authorization and Authentication”. Alternatively, you can enter “?” within ldap-attribute-map mode
to display the complete list of Cisco LDAP attribute names, as shown in the following example:
hostname(config)# ldap attribute-map att_map_1
hostname(config-ldap-attribute-map)# map-name att_map_1 ?

ldap mode commands/options:

cisco-attribute-names:
Access-Hours
Allow-Network-Extension-Mode
Auth-Service-Type
Authenticated-User-Idle-Timeout
Authorization-Required
Authorization-Type
:
:
X509-Cert-Data
hostname(config-ldap-attribute-map)#

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. This applies to both IPsec 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.

Using User Login Credentials

The default method for authentication and authorization uses the user login credentials.
• Authentication
– Enabled by authentication server group setting
– Uses the username and password as credentials

Cisco Security Appliance Command Line Configuration Guide

12-16 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Supporting a Zone Labs Integrity Server

• Authorization
– Enabled by authorization server group setting
– Uses the username as a credential

Using certificates
If user digital certificates are configured, the security appliance first validates the certificate. It does not,
however, use any of the DNs from the certificates as a username for the authentication.
If both authentication and authorization are enabled, the security appliance uses the user login
credentials for both user authentication and authorization.
• Authentication
– Enabled by authentication server group setting
– Uses the username and password as credentials
• Authorization
– Enabled by authorization server group setting
– Uses the username as a credential
If authentication is disabled and authorization is enabled, the security appliance uses the primary DN
field for authorization.
• Authentication
– DISABLED (set to None) by authentication server group setting
– No credentials used
• Authorization
– Enabled by 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 security appliance uses the secondary DN
field value as the username for the authorization request.

For example, consider a user certificate that contains the following Subject DN fields and values:
Cn=anyuser,OU=sales;O=XYZCorporation;L=boston;S=mass;C=us;[email protected].

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 [email protected].

Supporting a Zone Labs Integrity Server

This section introduces the Zone Labs Integrity Server, also called Check Point Integrity Server, and
presents an example procedure for configuring the security appliance to support the Zone Labs Integrity
Server. The Integrity server is a central management station for configuring and enforcing security
policies on remote PCs. If a remote PC does not conform to the security policy dictated by the Integrity
Server, it will not be granted access to the private network protected by the Integrity Server and security
appliance.

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-17
 Chapter 12 Configuring AAA Servers and the Local Database
Supporting a Zone Labs Integrity Server

This section includes the following topics:

• Overview of Integrity Server and Security Appliance Interaction, page 12-18
• Configuring Integrity Server Support, page 12-18

Overview of Integrity Server and Security Appliance Interaction

The VPN client software and the Integrity client software are co-resident on a remote PC. The following
steps summarize the actions of the remote PC, security appliance, and Integrity server in the
establishment of a session between the PC and the enterprise private network:
1. The VPN client software (residing on the same remote PC as the Integrity client software) connects
to the security appliance and tells the security appliance what type of firewall client it is.
2. Once it approves the client firewall type, the security appliance passes Integrity server address
information back to the Integrity client.
3. With the security appliance acting as a proxy, the Integrity client establishes a restricted connection
with the Integrity server. A restricted connection is only between the Integrity client and server.
4. The Integrity server determines if the Integrity client is in compliance with the mandated security
policies. If the client is in compliance with security policies, the Integrity server instructs the
security appliance to open the connection and provide the client with connection details.
5. On the remote PC, the VPN client passes connection details to the Integrity client and signals that
policy enforcement should begin immediately and the client can no enter the private network.
6. Once the connection is established, the server continues to monitor the state of the client using client
heartbeat messages.

Note The current release of the security appliance supports one Integrity Server at a time even though the user
interfaces support the configuration of up to five Integrity Servers. If the active Server fails, configure
another Integrity Server on the security appliance and then reestablish the client VPN session.

Configuring Integrity Server Support

This section describes an example procedure for configuring the security appliance to support the Zone
Labs Integrity Servers. The procedure involves configuring address, port, connection fail timeout and
fail states, and SSL certificate parameters.
First, you must configure the hostname or IP address of the Integrity server. The following example
commands, entered in global configuration mode, configure an Integrity server using the IP address
10.0.0.5. They also specify port 300 (the default port is 5054) and the inside interface for
communications with the Integrity server.
hostname(config)# zonelabs-integrity server-address 10.0.0.5
hostname(config)# zonelabs-integrity port 300
hostname(config)# zonelabs-integrity interface inside
hostname(config)#

If the connection between the security appliance and the Integrity server fails, the VPN client
connections remain open by default so that the enterprise VPN is not disrupted by the failure of an
Integrity server. However, you may want to close the VPN connections if the Zone Labs Integrity Server

Cisco Security Appliance Command Line Configuration Guide

12-18 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Differentiating User Roles Using AAA

fails. The following commands ensure that the security appliance waits 12 seconds for a response from
either the active or standby Integrity servers before declaring an the Integrity server as failed and closing
the VPN client connections:
hostname(config)# zonelabs-integrity fail-timeout 12
hostname(config)# zonelabs-integrity fail-close
hostname(config)#

The following command returns the configured VPN client connection fail state to the default and
ensures the client connections remain open:
hostname(config)# zonelabs-integrity fail-open
hostname(config)#

The following example commands specify that the Integrity server connects to port 300 (default is port
80) on the security appliance to request the server SSL certificate. While the server SSL certificate is
always authenticated, these commands also specify that the client SSL certificate of the Integrity server
be authenticated.

hostname(config)# zonelabs-integrity ssl-certificate-port 300

hostname(config)# zonelabs-integrity ssl-client-authentication
hostname(config)#

To set the firewall client type to the Zone Labs Integrity type, use the client-firewall command as
described in the “Configuring Firewall Policies” section on page 28-61. The command arguments that
specify firewall policies are not used when the firewall type is zonelabs-integrity because the Integrity
server determines the policies.

Differentiating User Roles Using AAA

This section includes the following topics:
• Using Local Authentication, page 12-19
• Using RADIUS Authentication, page 12-20
• Using LDAP Authentication, page 12-20
• Using TACACS+ Authentication, page 12-21
The security appliance enables you to distinguish between administrative and remote-access users when
they authenticate using RADIUS, LDAP, TACACS+, or the local user database. User role differentiation
can prevent remote access VPN and network access users from establishing an administrative connection
to the security appliance.
To differentiate user roles, use the service-type attribute in username configuration mode. For RADIUS
and LDAP (with the ldap-attribute-map command), you can use a Cisco Vendor-Specific Attribute
(VSA), Cisco-Priv-Level, to assign a privilege level to an authenticated user.

Using Local Authentication

Before you configure the service-type attribute and privilege level when using local authentication, you
must create a user, assign a password, and assign a privilege level. To do so, enter the following
command:
hostname(config)# username admin password mysecret123 privilege 15

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-19
 Chapter 12 Configuring AAA Servers and the Local Database
Differentiating User Roles Using AAA

Where mysecret123 is the stored password and 15 is the assigned privilege level, which indicates an
admin user.
The available configuration options for the service-type attribute include the following:
• admin, in which users are allowed access to the configuration mode. This option also allows a user
to connect via remote access.
• nas-prompt, in which users are allowed access to the EXEC mode.
• remote-access, in which users are allowed access to the network.
The following example designates a service-type of admin for a user named admin:
hostname(config)# username admin attributes
hostname(config-username)# service-type admin

The following example designates a service-type of remote-access for a user named ra-user:
hostname(config)# username ra-user attributes
hostname(config-username)# service-type remote-access

Using RADIUS Authentication

The RADIUS IETF service-type attribute, when sent in an access-accept message as the result of a
RADIUS authentication and authorization request, is used to designate which type of service is granted
to the authenticated user. The supported attribute values are the following: administrative(6),
nas-prompt(7), Framed(2), and Login(1).
For more information about using RADIUS authentication, see the “Configuring an External RADIUS
Server” section on page D-27. For more information about configuring RADIUS authentication for
Cisco Secure ACS, see the Cisco Secure ACS documentation on Cisco.com.
The RADIUS Cisco VSA privilege-level attribute (Vendor ID 3076, sub-ID 220), when sent in an
access-accept message, is used to designate the level of privilege for the user. For a list of supported
RADIUS VSAs used for authorization, see the “Configuring an External RADIUS Server” section on
page D-27.

Using LDAP Authentication

When users are authenticated through LDAP, the native LDAP attributes and their values can be mapped
to Cisco security appliance attributes to provide specific authorization features. For the supported list of
LDAP VSAs used for authorization, see the “Configuring an External LDAP Server” section on
page D-3.
You can use the LDAP attribute mapping feature for LDAP authorization. For examples of this feature,
see the “Understanding Policy Enforcement of Permissions and Attributes” section on page D-2.
The following example shows how to define an LDAP attribute map. In this example, the security policy
specifies that users being authenticated through LDAP map the user record fields or parameters title and
company to the IETF-RADIUS service-type and privilege-level, respectively.
To define an LDAP attribute map, enter the following commands:
hostname(config)# ldap attribute-map admin-control
hostname(config-ldap-attribute-map)# map-name title IETF-RADIUS-Service-Type
hostname(config-ldap-attribute-map)# map-name company Privilege-Level

The following is sample output from the ldap-attribute-map command:

Cisco Security Appliance Command Line Configuration Guide

12-20 OL-12172-02
 Chapter 12 Configuring AAA Servers and the Local Database
Differentiating User Roles Using AAA

ldap attribute-map admin-control

map-name company Privilege-Level
map-name title IETF-Radius-Service-Type

To apply the LDAP attribute map to the LDAP AAA server, enter the following commands:
hostname(config)# aaa-server ldap-server (dmz1) host 10.20.30.1
hostname(config-aaa-server-host)# ldap-attribute-map admin-control

Note When an authenticated user tries administrative access to the security appliance through ASDM, SSH,
or Telnet, but does not have the appropriate privilege level to do so, the security appliance generates
syslog message 113021. This message informs the user that the attempted login failed because of
inappropriate administrative privileges.

Using TACACS+ Authentication

For information about how to configure TACACS+ authentication, see the “Configuring an External
TACACS+ Server” section on page E-35.

Cisco Security Appliance Command Line Configuration Guide

OL-12172-02 12-21
 Chapter 12 Configuring AAA Servers and the Local Database
Differentiating User Roles Using AAA

Cisco Security Appliance Command Line Configuration Guide

12-22 OL-12172-02