Cisco Systems OL-12180-01 User Manual
Configuring AAA Servers and User Accounts
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-2
• Configuring the Local Database, page 12-7
• Identifying AAA Server Groups and Servers, page 12-12
• Configuring an Authentication Prompt, page 12-20
• Configuring an LDAP Attribute Map, page 12-21
AAA Overview
CHAPTER
12
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 allowingalloutsideuserstoaccessTelnetonaserver 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-1
• About Authorization, page 12-2
• About Accounting, page 12-2
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:
OL-12180-01
ASDM User Guide
12-1
AAA Server and Local Database Support
• All administrative connections to the security appliance including the following sessions:
–
–
–
–
–
• 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. Wereyounot 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 haveadetailed 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 first16 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.
Chapter 12 Configuring AAA Servers and User Accounts
Telnet
SSH
Serial console
ASDM (using HTTPS)
VPN management access
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.
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
ASDM User Guide
12-2
OL-12180-01
Chapter 12 Configuring AAA Servers and User Accounts
• RADIUS Server Support, page 12-3
• TACACS+ Server Support, page 12-4
• SDI Server Support, page 12-4
• NT Server Support, page 12-5
• Kerberos Server Support, page 12-5
• LDAP Server Support, page 12-5
• 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
AAA Server and Local Database Support
Database Type
HTTP
AAA Service
Authentication of...
Local RADIUS TACACS+ SDI NT Kerberos LDAP
Form
VPN users Yes Yes Yes Yes Yes Yes Yes Yes
Firewall sessions Yes Yes Yes Yes Yes Yes Yes No
Administrators Yes Yes Yes Yes
Authorization of...
2
Yes Yes Yes No
VPN users Yes Yes No No No No Yes No
Firewall sessions No Yes
Administrators Yes
Accounting of...
4
3
Yes NoNoNo NoNo
No Yes NoNoNo NoNo
VPN connections No Yes Yes No No No No No
Firewall sessions No Yes Yes No No No No No
Administrators No Yes
1. HTTP Form protocol supports single sign-on authentication for Clientless SSL VPN connections only.
2. SDI is not supported for HTTP administrative access.
3. For firewall sessions, RADIUS authorization is supported with user-specific access lists only, which are received or
specified in a RADIUS authentication response.
4. Local command authorization is supported by privilege level only.
5. Command accounting is available for TACACS+ only.
5
Yes NoNoNo NoNo
1
RADIUS Server Support
The security appliance supports RADIUS servers.
OL-12180-01
ASDM User Guide
12-3
AAA Server and Local Database Support
This section contains the following topics:
• Authentication Methods, page 12-4
• Attribute Support, page 12-4
• RADIUS Authorization Functions, page 12-4
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.
Attribute Support
Chapter 12 Configuring AAA Servers and User Accounts
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.
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.
SDI Server Support
The RSA SecureID servers are also known as SDI servers.
This section contains the following topics:
• SDI Version Support, page 12-5
ASDM User Guide
12-4
OL-12180-01
Chapter 12 Configuring AAA Servers and User Accounts
• Two-step Authentication Process, page 12-5
• SDI Primary and Replica Servers, page 12-5
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 filehas
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 “SDI Primary and Replica Servers” section 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.
AAA Server and Local Database Support
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.
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 havea 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.
OL-12180-01
ASDM User Guide
12-5
AAA Server and Local Database Support
LDAP Server Support
This section describes using an LDAP directory with the security appliance for user authentication and
VPN authorization.
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.
Note If you do not configure SASL, we strongly recommend that you secure LDAP communications with
SSL.
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.
For example configuration procedures used to set up LDAP authentication or authorization, see
Appendix B, “Configuring an External Server for Authorization and Authentication”.
Chapter 12 Configuring AAA Servers and User Accounts
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 only. Single sign-on support lets 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, 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 Clientless SSL VPN
chapter.
Local Database Support
The security appliance maintains a local database that you can populate with user profiles.
This section contains the following topics:
• User Profiles, page 12-6
• Fallback Support, page 12-7
12-6
ASDM User Guide
OL-12180-01
Chapter 12 Configuring AAA Servers and User Accounts
User Profiles
User profiles contain, at a minimum, a username. Typically, a password is assigned to each username,
although passwords are optional. 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—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—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. 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
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.
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.
This section includes the following topics:
• User Accounts, page 12-7
• Add/Edit User Account > Identity, page 12-9
• Add/Edit User Account > VPN Policy, page 12-10
• Identifying AAA Server Groups and Servers, page 12-12
OL-12180-01
ASDM User Guide
12-7
Configuring the Local Database
User Accounts
Chapter 12 Configuring AAA Servers and User Accounts
The User Accounts pane lets you manage the local user database. 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 Device
Name/Password, page 10-12). 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.
Note Although you can configure HTTP authentication using the local database, that functionality is
always enabled by default. Youshould only configure HTTP authentication if you want to use a
RADIUS or TACACS+ server for authentication.
• 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 security appliance refers to
the user privilege level to determine what 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
You cannot use the local database for network access authorization.
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
commands that use the local database in the system execution space.
12-8
Note VPN functions are not supported in multiple context mode.
To configure the enable password from this pane (instead of in Device Name/Password, page 10-12),
change the password for the enable_15 user. The enable_15 user is always present in this 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, etc.
Fields
• User Name—Specifies the user name to which these parameters apply.
• Privilege(Level)—Specifies the privilege levelassigned to that user.The privilege levelis used with
local command authorization.
• VPN Group Policy—Specifies the name of the VPN group policy for this user. Not available in
multimode.
ASDM User Guide
OL-12180-01
Loading...