Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 4.1
Configuring AAA Servers and the Local Database
Downloads: This chapterpdf (PDF - 448.0KB) The complete bookPDF (PDF - 8.06MB) | Feedback

Configuring AAA Servers and the Local Database

Table Of Contents

Configuring AAA Servers and the Local Database

AAA Overview

About Authentication

About Authorization

About Accounting

AAA Server and Local Database Support

Summary of Support

RADIUS Server Support

Authentication Methods

Attribute Support

RADIUS Authorization Functions

TACACS+ Server Support

SDI Server Support

SDI Version Support

Two-step Authentication Process

SDI Primary and Replica Servers

NT Server Support

Kerberos Server Support

LDAP Server Support

Local Database Support

User Profiles

Fallback Support

Configuring the Local Database

Identifying AAA Server Groups and Servers


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 includes the following sections:

AAA Overview

AAA Server and Local Database Support

Configuring the Local Database

Identifying AAA Server Groups and Servers

AAA Overview

AAA enables the FWSM 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 an inside interface. 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 FWSM. (The Telnet server enforces authentication, too; the FWSM 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.

If you use multiple security contexts, AAA settings are discrete per context, not shared between contexts. This provides you the opportunity to control access, authorize resources and commands, and perform accounting differently among contexts.

This section includes the following topics:

About Authentication

About Authorization

About Accounting

About Authentication

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

All administrative connections to the FWSM including the following sessions:

Telnet

SSH

Serial console

ASDM (using HTTPS)

VPN management access

The enable command

Network access

About Authorization

Authorization controls access per user after users authenticate. You can configure the FWSM to authorize the following items:

Management commands

Network access

VPN access for management connections

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 FWSM caches the first 16 authorization requests per user, so if the user accesses the same services during the current authentication session, the FWSM does not resend the request to the authorization server.

About Accounting

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

AAA Server and Local Database Support

The FWSM supports a variety of AAA server types and a local database that is stored on the FWSM. This section describes support for each AAA server type and the local database.

This section includes the following topics:

Summary of Support

RADIUS Server Support

TACACS+ Server Support

SDI Server Support

NT Server Support

Kerberos Server Support

LDAP Server Support

Local Database Support

Summary of Support

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

AAA Service
Database Type
Local
RADIUS
TACACS+
SDI
NT
Kerberos
LDAP
Authentication of. . .

VPN users1

Yes

Yes

Yes

Yes

Yes

Yes

No

Firewall sessions

Yes

Yes

Yes

No

No

No

No

Administrators

Yes

Yes

Yes

No

No

No

No

Authorization of. . .

VPN users1

Yes

Yes

No

No

No

No

Yes

Firewall sessions

No

Yes2

Yes

No

No

No

No

Administrators

Yes3

No

Yes

No

No

No

No

Accounting of. . .

VPN connections1

No

Yes

Yes

No

No

No

No

Firewall sessions

No

Yes

Yes

No

No

No

No

Administrators

No

No

Yes

No

No

No

No

1 VPN is available for management connections only.

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

3 Local command authorization is supported by privilege level only.


RADIUS Server Support

The FWSM supports RADIUS servers.

This section contains the following topics:

Authentication Methods

Attribute Support

TACACS+ Server Support

Authentication Methods

The FWSM supports the following authentication methods with RADIUS:

PAP

CHAP

MS-CHAPv1

MS-CHAPv2

MS-CHAPv2 supports password management when the RADIUS server communicates with a Windows Active Directory server. When your password expires, you are prompted to change your password (see the auth-prompt command).

Attribute Support

The FWSM 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 FWSM 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 FWSM can use RSA SecureID servers for VPN authentication. These servers are also known as SDI servers. When a user attempts to establish VPN access and the applicable tunnel-group record specifies a SDI authentication server group, the FWSM sends to the SDI server the username and one-time password and grants or denies user access based on the response from the server.

This section contains the following topics:

SDI Version Support

Two-step Authentication Process

SDI Primary and Replica Servers

SDI Version Support

The FWSM offers the following SDI version support:

Versions prior to Version 5.0—SDI versions prior to 5.0 use the concept of an SDI master and an SDI slave server which share a single node secret file (SECURID).

Versions 5.0—SDI Version 5.0 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 SDI server that you configure on the FWSM 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 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 SDI 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 FWSMs using the same authentication servers simultaneously. After a successful username lock, the FWSM sends the passcode.

SDI Primary and Replica Servers

The FWSM obtains the server list when the first user authenticates to the configured server, which can be either a primary or a replica. The FWSM 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 FWSM supports authentication of VPN-based management connections with Microsoft Windows server operating systems that support NTLM Version 1, which we collectively refer to as NT servers. When a user attempts to establish VPN access and the applicable tunnel-group record specifies an NT authentication server group, the FWSM uses NTLM Version 1 to for user authentication with the Microsoft Windows domain server. The FWSM grants or denies user access based on the response from the domain server.


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 FWSM can use Kerberos servers for VPN-based management connections. When a user attempts to establish VPN access, and the traffic matches an authentication statement, the FWSM consults the Kerberos server for user authentication and grants or denies user access based on the response from the server.

The FWSM supports 3DES, DES, and RC4 encryption types.


Note The FWSM 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 FWSM.


LDAP Server Support

The FWSM can use LDAP servers for authorization of VPN-based management connections. When user authentication for VPN access has succeeded and the applicable tunnel-group record specifies an LDAP authorization server group, the FWSM queries the LDAP server and applies to the VPN session the authorizations it receives.

Local Database Support

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

This section contains the following topics:

User Profiles

Fallback Support

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 enables you to 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

With the exception of fallback for network access authentication, the local database can act as a fallback method for the functions in Table 11-1. This behavior is designed to help you prevent accidental lockout from the FWSM.

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

You cannot enter the username command in the system execution space. However, when you use the login command in system, or use Telnet authentication when you session to the FWSM from the switch, the FWSM uses the admin context username database (Telnet authentication for the system execution space is also configured in the admin context).


Caution If you add to the local database users who can gain access to the CLI but who should not be allowed to enter privileged mode, enable command authorization. (See the "Configuring Local Command Authorization" section on page 23-15.) Without command authorization, users can access privileged mode (and all commands) at the CLI using their own password if their privilege level is 2 or greater (2 is the default). Alternatively, you can use RADIUS or TACACS+ authentication so that the user will not be able to use the login command, or you can set all local users to level 1 so you can control who can use the system enable password to access privileged mode.

To define a user account in the local database, perform the following steps:


Step 1 Create the user account. To do so, enter the following command:

hostname(config)# username username {nopassword | password password} [privilege level]

where the options are as follows:

username—A string from 4 to 64 characters long.

password password—A string from 3 to 16 characters long.

privilege level—The privilege level that you want to assign to the new user account (from 0 to 15). The default is 2. This privilege level is used with command authorization.

nopassword—Creates a user account with no password.

The encrypted keyword is typically for display only. When you define a password in the username command, the FWSM 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 keyword. 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

Step 2 To configure a local user account with VPN attributes, perform the following steps:

a. Enter the following command:

hostname(config)# username username attributes

When you enter the username attributes command, you enter username mode. The commands available in this mode are as follows:

group-lock

password-storage

vpn-access-hours

vpn-filter

vpn-framed-ip-address

vpn-group-policy

vpn-idle-timeout

vpn-session-timeout

vpn-simultaneous-logins

vpn-tunnel-protocol

Use these commands as needed to configure the user profile. For more information about these commands, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

b. When you have finished configuring the user profiles, enter exit to return to config mode.


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 creates a user account with a password, enters username mode, and specifies a few VPN attributes:

hostname(config)# username user1 password gOgeOus
hostname(config)# username user1 attributes
hostname(config-username)# vpn-tunnel-protocol IPSec
hostname(config-username)# vpn-simultaneous-logins 6
hostname(config-username)# exit

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, SDI, or TACACS+.

The FWSM contacts the first server in the group. If that server is unavailable, the FWSM contacts the next server in the group, if configured. If all servers in the group are unavailable, the FWSM 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 FWSM continues to try the AAA servers.

To create a server group and add AAA servers to it, perform the following steps:


Step 1 For each AAA server group you need to create, perform the following steps:

a. Identify the server group name and the protocol by entering the following command:

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 AAA server groups in single mode or 4 AAA 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 you enter a aaa-server 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 "AAA for System Administrators" section on page 23-10 and the "Configuring TACACS+ Command Authorization" section on page 23-18 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. After this period, the server group is still marked as up, whether or not the servers are accessible. 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 FWSM 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, use the reactivation-mode command. For more information about this command, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

d. If you want to indicate whether accounting messages are sent to a single server (single mode) or sent to all servers in the group (simultaneous mode), use the accounting-mode command. For more information about this command, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Step 2 For each AAA server on your network, perform the following steps:

a. Identify the server, including the AAA server group it belongs to by entering the following command:

hostname(config)# aaa-server server_tag [(interface_name)] host server_ip [key] 
[timeout seconds]

When you enter a aaa-server host command, you enter aaa-server host configuration mode.

b. As needed, use host mode commands to further configure the AAA server.

The commands in host mode do not apply to all AAA server types. Table 11-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 Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

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

Command
Applicable AAA Server Types
Default Value

accounting-port

RADIUS

1646

authentication-port

RADIUS

1645

kerberos-realm

Kerberos

key

RADIUS

TACACS+

ldap-base-dn

LDAP

ldap-login-dn

LDAP

ldap-login-password

LDAP

ldap-naming-attribute

LDAP

ldap-scope

LDAP

nt-auth-domain-controller

NT

radius-common-pw

RADIUS

retry-interval

Kerberos

10 seconds

RADIUS

10 seconds

sdi-pre-5-slave

SDI

sdi-version

SDI

sdi-5

server-port

Kerberos

88

LDAP

389

NT

139

SDI

5500

TACACS+

49

timeout

All

10 seconds



For example, to add one TACACS+ group with one primary and one backup server, one RADIUS group with a single server, and an NT domain server, enter the following commands:

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