Chapter 5: Managing a Cisco ASA (Part03)

Chapter 5: Managing Firewall Users

Overview

Refer to the following sections for information about these topics:

• 5-1: Managing Generic Users— Covers how default “generic” or ambiguous users can be allowed to connect to a firewall and execute commands or make configuration changes.

• 5-2: Managing Users with a Local Database— Presents methods to configure unique usernames locally on the firewall. You can then manage these users’ privileges and monitor their activity.

• 5-3: Defining AAA Servers for User Management— Discusses external servers that can be used to authenticate, authorize, and keep accounting records about user activity on and through a firewall.

• 5-4: Configuring AAA to Manage Administrative Users— Explains the configuration steps needed to offload user management functions when administrative users connect to a firewall.

• 5-5: Configuring AAA for End-User Cut-Through Proxy— Covers the methods that can be used to authenticate users initiating connections through a firewall and to authorize their ability to do so.

• 5-6: Firewall Password Recovery— Discusses procedures that can be used to recover or bypass a firewall’s privileged user password when it is lost or forgotten.

Although its primary function is to provide and enforce security policies at the boundaries of networks, a Cisco firewall also supports several methods to manage users who interact with it. Firewall users fall into the following general categories:

• Administrative users— Users who can open administrative sessions with the firewall to make configuration changes or to monitor activity. These users can connect to the firewall through the console, Telnet, Secure Shell (SSH), or the PIX Device Manager (PDM)/Adaptive Security Device Manager (ASDM) application.

• End users— These are users who need to open connections through the firewall. These connections can use various protocols, which are all ultimately inspected by the firewall. When the user first initiates a connection, the firewall intervenes with an authentication challenge. If the user successfully authenticates, that connection is opened. Through the cut-through proxy feature, the firewall opens future connections for that user without any intervention.

• VPN users— Remote-access users who need to open VPN client connections to the firewall. The firewall can use extended authentication (xauth) to authenticate the users before the VPN connections are completed.

Firewalls can perform three basic operations to manage any user’s access:

• Authentication— A user’s identity is verified against known credentials.

• Authorization— A user’s privileges are predefined and approved by a third party.

• Accounting— A user’s activity is recorded for auditing or billing purposes.

Finally, a Cisco firewall can support several levels of user management, based on the amount of control and security that is required. For example, a firewall can authenticate a user based on a generic password only, against a local or internal user database, or against databases maintained on external servers.

When users log in to a firewall, they are assigned a privilege level from 1 to 15 (0 is available, but is not used). User authentication and privilege levels are used for all management interfaces:

• The command-line interface

• Adaptive Security Device Manager (ASDM)

• Cisco Security Manager (CSM) or VPN/Security Management Solution (VMS)

By default, users begin at level 1 and move to level 15 only when they successfully enter privileged EXEC or enable mode.

Firewall commands are also given various privilege levels, so users can run only commands that are at the same level as or at a lower level than their own. By default, all firewall commands (both EXEC and configuration) are given privilege level 0 (the lowest) or 15 (the highest). Additional levels between 0 and 15 can be defined if the user community needs to be segmented further.

5-1: Managing Generic Users

By default, administrative users can authenticate with a firewall by using only a password. After they are authenticated, these users are known by the generic username enable_1.

The firewall prompts you for the password in Telnet and SSH sessions, but not in console sessions. On the console, a user is immediately placed at the unprivileged level.

With SSH sessions, users are prompted for a username and password. You can use the username pix as the generic username.

Tip

Even though you might be using an ASA or FWSM platform, you can still use pix as a username. The generic username began with the PIX family and has been retained since.

The following sections present the configuration steps needed to authenticate administrative users based only on a password or on a username and password pair, and to authenticate end users initiating traffic through the firewall.

Authenticating and Authorizing Generic Users

Generic user authentication is performed using only passwords. Users are authorized to perform certain actions based on the privilege level that they are permitted to use. Passwords can be defined for the two default privilege levels 0 and 15, as well as other arbitrary levels, using the following configuration steps:

1. Set the unprivileged mode password:

   ASA, FWSM	Firewall(config)# {password | passwd} password [encrypted]
   PIX 6.3	Firewall(config)# {password | passwd} password [encrypted]

   The generic user at privilege level 0 can be authenticated by entering the password string password. After the command is entered, the password string is encrypted whenever the configuration is displayed. This is denoted by the encrypted keyword.

   You can also transfer this command to another firewall by copying and pasting. As long as the encrypted keyword is retained, the new firewall can use the same encrypted password.

   Tip

   You can use the following commands to reset the level 0 password to the default value cisco: ASA, FWSM Firewall(config)# clear {password | passwd} PIX 6.3 Firewall(config)# clear {password | passwd}

2. Set a privileged-mode password:

   ASA, FWSM	Firewall(config)# enable password [pw] [level priv_level] [encrypted]
   PIX 6.3	Firewall(config)# enable password [pw] [level priv_level] [encrypted]

   The password for privilege level priv_level is set to the string pw. If the level keyword is omitted, the password for enable mode or privilege level 15 is assumed.

   You can use this command to define a new unique privilege level to support a subset of administrative users. Specify the priv_level as a level between 0 and 15.

   If you need to reset the privilege level password to its default value (no password), use the enable password configuration command with no pw string given.

Tip

Administrative users can gain access to a specific privilege level by using the enable level command, where level is 0 to 15 (the default is 15).

Accounting of Generic Users

When a firewall is configured to authenticate administrative users with only a password, you can perform user accounting only through the logging function. You should make sure the following Syslog message IDs are enabled to use them as an audit trail of user activity. The default severity levels are shown in parentheses:

• 611101 (6)— Successful user authentication

• 611102 (6)— Failed user authentication

• 111008 (5)— User executed the command text

• 111009 (6)— User executed the command show text

• 611103 (5)— User logged out

• 502103 (5)— User changed privilege levels

It might seem odd that users connecting through the firewall console are not logged with a 611101 authentication message. This is because the console remains logged in to the generic privilege level 1 user at all times.

For example, the following output shows the Syslog audit trail for a user who moved into privilege level 15 (enable mode) and made a configuration change. Later, you might need to trace back and see which user made a specific change to the firewall.

single_vf : %PIX-7-111009: User 'enable_1' executed cmd: show clock
single_vf : %PIX-5-502103: User priv level changed: Uname: enable_15 From: 1 To:
15
single_vf : %PIX-5-111008: User 'enable_1' executed the 'enable' command.
single_vf : %PIX-5-111008: User 'enable_15' executed the 'configure terminal'
command.
single_vf : %PIX-5-111008: User 'enable_15' executed the 'access-list acl_outside
permit ip any any' command.
single_vf : %PIX-5-611103: User logged out: Uname: enable_1

Tip

Although the default generic user authentication is flexible and convenient, it offers little security benefit. For example, users log in by entering the level 1 password only. This means that every user must know and use the same password; there will never be an audit trail showing exactly who logged in. All level 1 users are simply shown as enable_1. The level 15 enable access is similar—users must enter one enable password that is common to all administrators. Those users are simply shown as enable_15. Again, no accurate audit trail shows what user made what configuration change to the firewall. Best practice dictates authenticating users with usernames that uniquely identify them. Each user also has a unique password and can be assigned to a specific privilege level if needed. This can be done in a local (internal) user database or on an external user database server.

5-2: Managing Users with a Local Database

You can configure a firewall to control user access by defining users in its local database. This approach assigns usernames and passwords to each end user, allowing access rights and accounting trails to be granular and specific.

Each user must use a unique username when accessing or passing through the firewall. For administrative users, privilege levels can be defined to authorize their ability to access firewall commands. User activity can also be tracked and identified by the unique usernames.

You can define usernames locally on the firewall if external user management servers (RADIUS, TACACS+, and so on) are unavailable or impractical. However, local user management does have some limitations. For example, each user’s password must be configured and updated on the firewall. Usernames must be added or deleted as users come and go from the enterprise. If a consistent user management framework must be used across the network, each user’s credentials and access rights must be maintained at every location.

Without a central point of management, local user databases do not scale very well and can become difficult to administer. Best practice is to use external user management servers first and then fall back on a local user database as a last resort.

Authenticating with Local Usernames

You can use the following configuration steps to define usernames locally on the firewall.

1. Define each firewall user:

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

   The user identified as username (a text string of up to 15 characters) can have a password configured with the password keyword. After password is entered, it is encrypted automatically so that the cleartext string is never displayed in the configuration. If this command is copied and pasted from one firewall to another, the encrypted keyword specifies that the password string is already encrypted before the command is executed.

   If you choose to configure the user with no password, using the nopassword option, the blank password is still displayed as an encrypted string. However, you should carefully consider this, because anyone will be able to log in to the firewall (and potentially make configuration changes) by knowing only the username.

   A privilege level must be given as level (1 to 15), where 15 is the highest level the user is allowed to reach. This limit applies only when enable authentication is configured. (See Step 3.)

   Privilege level 1 is the lowest and offers the user the least capability. At level 15, the user can access and use any command on the firewall platform. All users begin at level 1 when they successfully authenticate. To move to a higher privilege level, users must issue the enable command.

2. Enable local user authentication:

   Firewall(config)# aaa authentication {serial | telnet | ssh | http} console LOCAL
   

   You can enable user authentication locally on the firewall for any of the following access methods:

   • serial (console connection)

   • telnet (Telnet)

   • ssh (SSH sessions)

   • http (Web-based management with PDM or ASDM)

   You can repeat this command to define local authentication for more than one connection type.

   You must always use the console keyword, indicating that firewall management sessions are being authenticated. The LOCAL keyword causes the firewall’s local username database to be used for authentication.

   Tip

   It might seem odd to use the aaa command here, even though external AAA servers are not used for the local user database. The firewall processes all user management functions involving usernames as AAA functions. A predefined AAA server group called LOCAL uses the LOCAL “protocol,” as if the following command were used: Firewall(config)# aaa-server LOCAL protocol local Requests that would go out to an external AAA server are intercepted and handled internally according to the local username database.

3. (Optional) Authenticate users for enable mode:

   Firewall(config)# aaa authentication enable console LOCAL
   

   By default, privilege level 15 is defined with the enable password configuration command. Any user who can successfully authenticate with the firewall can also use the enable command to move to level 15—regardless of the privilege level set for the username. As well, all users share the same password for privilege level 15.

   You can configure enable authentication so that each user must enter an independent enable password to reach a higher privilege level. With local authentication, the enable password is the same as the username password for each user.

   After a user is authenticated with his or her enable password, the privilege level is changed to the level configured for the username. In other words, the privileged EXEC level is set on a per-user basis; not every user automatically arrives at level 15.

For example, suppose the username userjoe is created with a privilege level limit of 15. A second user, userbob, has a privilege level limit of 5. Local authentication is used for SSH sessions. Enable authentication is configured locally so that each user can enter his or her password to move into the respective privilege level, as demonstrated with the following commands:

Firewall(config)# username userjoe password joespasswd privilege 15
Firewall(config)# username userbob password bobspasswd privilege 5
Firewall(config)# aaa authentication ssh console LOCAL
Firewall(config)# aaa authentication enable console LOCAL

User userjoe logs in to the firewall and moves into his privileged EXEC level (15). Each time, userjoe’s username password is used for authentication. The show curpriv command verifies the user’s current identity and privilege level, as shown in the following output:

login as: userjoe
userjoe@192.168.77.14's password:
Type help or '?' for a list of available commands.
Firewall&~~SPECIAL_REMOVE!#~~gt; show curpriv
Username : userjoe
Current privilege level : 1
Current Mode/s : P_UNPR
Firewall&~~SPECIAL_REMOVE!#~~gt; enable
Password: ********
Firewall# show curpriv
Username : userjoe
Current privilege level : 15
Current Mode/s : P_PRIV
Firewall#

Authorizing Users to Access Firewall Commands

Users are authorized to execute firewall commands based on a comparison of their current privilege level and each command’s privilege level. If the user’s level is greater than or equal to the command’s level, the user is allowed to use the command. If not, an error is returned.

By default, only a simple authorization test is used. Users at privilege level 1 can use only commands that are set at level 1. If a user can move to any level greater than 1, he or she can access any other command—even commands set for level 15.

You can use local command authorization to achieve more granularity. When it is enabled, strict privilege level comparisons are done for each command that is entered. Users who have privilege levels lower than the commands they try to use are rejected.

Each firewall command has a privilege level associated with it. Some command keywords can be used in several different modes, such as show (as in show pager), clear (as in clear pager), and configure (as in pager 24 in configuration mode). Each of these is considered a separate command, having a unique privilege level. Therefore, the privilege levels are assigned according to the command keyword and the mode in which it is used. EXEC mode commands that can be run without the show or clear keywords are referenced in configure mode. An example is the help command.

By default, the commands shown in Table 5-1 are accessed with privilege level 0; all other commands default to level 15.

Table 5-1: Commands Accessed with Privilege Level 0
Open table as spreadsheet

Command	PIX 6.3	ASA	FWSM
Firewall&~~SPECIAL_REMOVE!#~~gt; enable	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; exit	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; quit	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; help	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; login	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; logout	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; pager Firewall&~~SPECIAL_REMOVE!#~~gt; clear pager Firewall&~~SPECIAL_REMOVE!#~~gt; show pager	Yes	No	No
Firewall&~~SPECIAL_REMOVE!#~~gt; ping	No	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; traceroute	No	Yes	No
Firewall&~~SPECIAL_REMOVE!#~~gt; show checksum	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; show curpriv	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; show history	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; show version	Yes	Yes	Yes
Firewall&~~SPECIAL_REMOVE!#~~gt; show flash:	No	Yes	No
Firewall&~~SPECIAL_REMOVE!#~~gt; show debug	No	Yes	No

Local user authorization is configured using the following steps:

1. (Optional) Display the current privilege levels for commands:

   ASA, FWSM	Firewall# show privilege {all | command command | level level}
   PIX 6.3	Firewall# show privilege {all | command command | level level}

   You can see the current privilege level configured for all possible firewall commands, or for only a single command command (only the first keyword). You can also see all the commands available to a user at a given privilege level level (0 to 15). (The default privilege levels are not shown in the configuration file. On an ASA or FWSM platform, you can see default settings for any command with the show run all command.)

2. Set a command’s privilege level:

   ASA, FWSM	Firewall(config)# privilege [show | clear | cmd] level level [mode mode] command command
   PIX 6.3	Firewall(config)# privilege {show | clear | configure} level level [mode {enable | configure}] command command

   For the mode (show, clear, or configure) of the command keyword command, a new privilege level (0 to 15) is assigned. In ASA and FWSM, the configure mode is known only as cmd mode.

   Some commands can also be used in several submodes within a single mode. In PIX 6.3, for example, the clear logging command can be run from enable mode or configure mode. In either case, the contents of the logging buffer are cleared, but you might want to restrict that command when a user is in one mode versus another.

   In ASA and FWSM, you can set command privilege levels with a greater granularity. You can use the mode keyword to identify a specific mode or submode where the command keyword is used. The mode parameter can be given as any one of the keywords shown in Table 5-2, usually shown in the firewall configuration mode prompt.

   Table 5-2: ASA Privileged Command Mode Values
   Open table as spreadsheet

   mode Keyword	Mode Description
   aaa-server-group	AAA server group configuration mode
   aaa-server-host	AAA server host configuration mode
   cache	WebVPN cache configuration mode
   class	Resource class configuration mode
   config-dap-webvpn	Dynamic access policy WebVPN configuration mode
   config-group-webvpn	Group policy WebVPN configuration mode
   config-mount-cifs	CIFS mount configuration mode
   config-mount-ftp	FTP mount configuration mode
   config-mount-nfs	NFS mount configuration mode
   config-username-webvpn	Username WebVPN configuration mode
   config-webvpn-customization	WebVPN customization configuration mode
   config-webvpn-sso-saml	WebVPN SAML SSO server configuration mode
   config-webvpn-sso-siteminder	WebVPN SiteMinder SSO server configuration mode
   config-zonelabs-integrity	Zonelabs Firewall Server configuration mode
   configure	Global configuration mode
   context	Context configuration mode
   crypto-ca-cert-chain	Crypto certificate entry mode
   crypto-ca-cert-map	Certificate map entry mode
   crypto-ca-crl	Certificate authority trustpoint CRL entry mode
   crypto-ca-server	Certificate Server entry mode
   crypto-ca-trustpoint	Certificate authority trustpoint entry mode
   crypto-isakmp-policy	Crypto ISAKMP policy configuration mode
   crypto-pubkey	Crypto subsystem public key entry mode
   ctl-provider	CTL Provider configuration mode
   dns-server-group	DNS server group configuration mode
   dual-service-object-group	Dual Service object group configuration
   dynamic-access-policy-record	Dynamic access policy record attribute configuration mode
   dynupd-method	Dynamic DNS update method configuration mode
   enable	EXEC mode (the keyword is converted to exec)
   exec	EXEC mode
   fover-group	Failover user group configuration mode
   ftp-map	ftp-map configuration mode
   group-policy	group-policy attribute configuration mode
   gtpmap	GTP class map configuration mode
   h225-map	h225-map configuration mode
   hsi-group	hsi-group configuration mode
   http-map	http-map configuration mode
   icmp-object-group	ICMPtype object group configuration mode
   imap4s	imap4s configuration mode
   interface	Interface configuration mode
   ldap	LDAP configuration mode
   mgcp-map	mgcp-map configuration mode
   mpf-class-map	MPF Class Map configuration mode
   mpf-policy-map	MPF Policy Map configuration mode
   mpf-policy-map-class	MPF Policy Map class configuration mode
   mpf-policy-map-param	MPF policy map parameter configuration mode
   nac-policy	NAC policy nac-framework configuration mode
   network-object-group	Network object group configuration mode
   pop3s	pop3s configuration mode
   priority-queue	priority-queue configuration mode
   protocol-object-group	Protocol object group configuration mode
   qosclassmap	QoS class map configuration mode
   qospolicymap	QoS policy map configuration mode
   qospolicymapclass	QoS policy map class configuration mode
   route-map	Route map configuration mode
   router	Router configuration mode
   routing	Routing configuration mode
   service-object-group	Service object group configuration mode
   sla-monitor	IP SLA Monitor entry configuration
   sla-monitor-echo	IP SLA Monitor echo configuration
   smtps	smtps configuration mode
   snmp-map	snmp-map configuration mode
   subinterface	Subinterface configuration mode
   tcp-map	tcp-map configuration mode
   test-dynamic-access-policy	Test dynamic access policy configuration
   tls-proxy	TLS proxy configuration mode
   trange	time-range configuration mode
   tunnel-group-general	tunnel-group general attribute configuration mode
   tunnel-group-ipsec	tunnel-group IPSec attribute configuration mode
   tunnel-group-ppp	tunnel-group PPP attribute configuration mode
   tunnel-group-webvpn	tunnel-group WebVPN attribute configuration mode
   username	username attribute configuration mode
   vpn-load-balancing	Configure VPN load balancing
   webvpn	WebVPN configuration mode

   For example, users at or above level 8 can be allowed to show the connection table entries:

   Firewall(config)# privilege show level 8 command conn
   

   ASA and FWSM can also accept this command as

   Firewall(config)# privilege show level 8 mode exec command conn
   

3. Enable local command authorization:

   Firewall(config)# aaa authorization command LOCAL
   

   Each time a user attempts to use a firewall command, the firewall authorizes the user based on the local privilege configuration commands.

Accounting of Local User Activity

With local user authentication and authorization, user accounting can be performed only through the logging function. You should make sure that the following Syslog message IDs are enabled to use them as an audit trail of user activity. The default severity levels are shown in parentheses:

• 611101 (6)— Successful user authentication

• 611102 (6)— Failed user authentication

• 502103 (5)— User changed privilege levels

• 111008 (5)— User executed the command text

• 111009 (7)— User executed the command show text

• 611103 (5)— User logged out

For example, suppose someone managed to log in to a firewall, clear its configuration, and reload it. If Syslog were configured on the firewall, you might be able to find an audit trail with clues as to who took those actions. In the following output, a user named userjane has authenticated, used the enable command to move into privilege level 15, cleared the configuration, and reloaded the firewall:

%ASA-6-109005: Authentication succeeded for user 'userjane' from 172.28.4.41/0 to
10.1.1.10/24 on interface outside
%ASA-6-611101: User authentication succeeded: Uname: userjane
%ASA-5-502103: User priv level changed: Uname: userjane From: 1 To: 15
%ASA-5-111008: User 'userjane' executed the 'enable' command.
%ASA-7-111009: User 'userjane' executed cmd: show clock
%ASA-5-111008: User 'userjane' executed the 'write erase' command.
%ASA-5-111008: User 'userjane' executed the 'reload' command.

5-3: Defining AAA Servers for User Management

A firewall can interface with external user management servers to offload any authentication, authorization, or accounting (AAA) functions. This provides a very scalable solution, because all user identities, privileges, and activity logs can be centralized.

You can use the following steps to configure AAA servers and server groups for all AAA-related firewall functions:

1. Define the AAA server group and protocol:

   ASA, FWSM	Firewall(config)# aaa-server server_tag protocol {tacacs+ | radius}
   PIX 6.3	Firewall(config)# aaa-server server_tag protocol {tacacs+ | radius}

   A group of servers is named server_tag (an arbitrary string without white space) using a common AAA protocol. All firewall platforms support the tacacs+ or radius protocol. In fact, PIX 6.3 has the following three predefined server groups:

   aaa-server TACACS+ protocol tacacs+
   aaa-server RADIUS protocol radius
   aaa-server LOCAL protocol local

   With ASA and FWSM, only the LOCAL group is predefined. You can also use other AAA protocols if they exist in your network. Specific protocol parameters are configured on a per-server basis in Step 2.

   Tip

   You can define multiple AAA servers in a single group. Table 5-3 lists the maximum number of server groups and servers per group. Table 5-3: AAA Server Limits by Security Platform Open table as spreadsheet Platform Server Groups Servers per Group PIX 6.3 14 14 ASA single context 18 16 ASA multiple contexts 7 4 FWSM single context 15 16 FWSM multiple contexts 4 4 The firewall sends requests to the first server configured in the group. If that server does not answer within a configurable time, the other servers in the group are tried in succession.

   1. (Optional) Set the server failure threshold:

      ASA, FWSM	Firewall(config-aaa-server-group)# max-failed-attempts number
      PIX 6.3	Firewall(config)# aaa-server server_tag max-failed-attempts number

      If a AAA server is unreachable, the firewall retries its request. After number (1 to 5; the default is 3) failed attempts, the firewall declares that server dead and moves on to the next server in the group.

   2. (Optional) Define a server reactivation policy:

      ASA, FWSM	Firewall(config-aaa-server-group)# reactivation-mode {depletion [deadtime minutes] | timed}
      PIX 6.3	Firewall(config)# aaa-server server_tag deadtime minutes

      By default, any server that is considered deactivated remains deactivated until no more usable servers remain in the group. This is called depletion mode.

      If only one server group is configured for a AAA function, all servers are immediately reactivated after depletion so that they can be tried again.

      If multiple server groups are configured for a AAA function, a depleted group is skipped so that the next server group can be used. The depleted group is declared dead for the duration of the deadtime timer, configured as minutes (1 to 1440; the default is 10 minutes). After that time, the failed servers are reactivated in the group, and that group is eligible for new AAA requests.

      In ASA and FWSM, you can use an alternative policy called timed reactivation. Here, any failed or deactivated server is automatically reactivated after 30 seconds.

   3. (Optional) Define an accounting policy:

      ASA, FWSM	Firewall(config-aaa-server-group)# accounting-mode {single | simultaneous}
      PIX 6.3	-

      If you are using AAA accounting, you can specify how the accounting information will be sent. With the single keyword, accounting messages are sent to only the active server. The firewall can also send the accounting messages to every server in the group if the simultaneous keyword is used.

2. Add a server to the group.

   1. Identify the server:

      ASA, FWSM	Firewall(config)# aaa-server server_tag [(if_name)] host server_ip [key] [timeout seconds]
      PIX 6.3	Firewall(config)# aaa-server server_tag [(if_name)] host server_ip [key] [timeout seconds]

      The server located on the firewall interface named (if_name) (be sure to include the parentheses) at IP address server_ip is added to the server_tag group. If you do not specify the interface, the outside interface is assumed. The firewall can use the string key (a text string of up to 127 characters without spaces) for all exchanges with the server. Therefore, you must configure the same key on the server and the firewall.

      If a response is not received from the server within a timeout period of seconds (the default is 5 seconds), the firewall sends the same request to the next server in the group.

   2. (Optional) Set the server deactivation timer:

      ASA, FWSM	Firewall(config-aaa-server-host)# timeout seconds
      PIX 6.3	-

      The firewall continues to retry requests for a timeout period of seconds (1 to 60; the default is 10 seconds) before it declares the server dead. After that point, the next server in a server group is tried.

   3. (Optional) Use one common port for all server protocols:

      ASA, FWSM	Firewall(config-aaa-server-host)# server-port port
      PIX 6.3	-

      Each AAA protocol uses a different default port for its services. For example, TACACS uses port 49, Kerberos uses 88, Lightweight Directory Access Protocol (LDAP) uses 389, NT uses 139, and Security Dynamics Incorporated (SDI) uses 5500. You can configure the firewall to use one port (1 to 65535) for any protocol used on the server, as long as the server is also configured to use the same port.

      Although it is not necessary, using one common port for any AAA protocol can simplify the types of traffic passing between the firewall and the server. This in turn might simplify any firewall or router access lists that need to permit the AAA traffic.

3. (Optional) Adjust RADIUS server parameters.

   1. (Optional) Adjust the RADIUS port numbers:

      ASA, FWSM	Firewall(config-aaa-server-host)# authentication-port port Firewall(config-aaa-server-host)# accounting-port port
      PIX 6.3	Firewall(config)# aaa-server {radius-authport | radius-acctport} [port]

      By default, a firewall uses UDP/TCP port 1645 for RADIUS authentication and port 1646 for accounting.

      Tip

      You should confirm that your RADIUS server uses matching port numbers. If it does not, you can configure the authentication port (radius-authport) or the accounting port (radius-acctport) to port. Some RADIUS servers use legacy values of 1812 for authentication and 1813 for accounting.

   2. Set the RADIUS key:

      ASA, FWSM	Firewall(config-aaa-server-host)# key key
      PIX 6.3	-

      In ASA and FWSM, the RADIUS key (a text string of up to 127 characters without spaces) should be configured as a host parameter. You must configure the same key on the firewall and the RADIUS server.

   3. (Optional) Set the retry interval:

      ASA, FWSM	Firewall(config-aaa-server-host)# retry-interval seconds
      PIX 6.3	-

      If the server does not answer a RADIUS request, the firewall retries it after seconds (1 to 10; the default is 10 seconds) has elapsed.

   4. (Optional) Use one common password for server requests:

      ASA, FWSM	Firewall(config-aaa-server-host)# radius-common-pw string
      PIX 6.3	-

      You can configure a common password that the firewall will use for all RADIUS authorization requests. The password is given as string (up to 127 characters).

4. (Optional) Adjust Kerberos server parameters.

   1. Define the Kerberos realm name:

      ASA, FWSM	Firewall(config-aaa-server-host)# kerberos-realm string
      PIX 6.3

      The Kerberos realm name defined on the server is string (up to 64 characters with no spaces).

   2. (Optional) Set the retry interval:

      ASA, FWSM	Firewall(config-aaa-server-host)# retry-interval seconds
      PIX 6.3	-

      If the server does not answer a RADIUS request, the firewall retries it after seconds (1 to 10; the default is 10 seconds) has elapsed.

5. (Optional) Adjust LDAP server parameters.

   1. (Optional) Use SASL authentication:

      ASA, FWSM	Firewall(config-aaa-server-host)# sasl-mechanism {digest-md5 | kerberos server_group_name}
      PIX 6.3	-

      The firewall authenticates with an LDAP server on behalf of the actual clients by using Simple Authentication and Security Layer (SASL). With the digest-md5 keyword, an MD5 hash of the username and password is sent to the LDAP server. Kerberos can be used instead, with the kerberos keyword. The server_group_name is the name of the AAA server group used for Kerberos.

   2. (Optional) Secure the LDAP communication:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-over-ssl enable
      PIX 6.3	-

      Normally, traffic between the firewall and the LDAP server is sent in the clear. With the ldap-over-ssl command, an SSL connection is brought up so that the LDAP traffic is secured.

   3. (Optional) Set the LDAP server type:

      ASA, FWSM	Firewall(config-aaa-server-host)# server-type {auto-detect | microsoft | sun | generic}
      PIX 6.3	-

      By default, the firewall attempts to automatically detect the type of LDAP server it is communicating with. You can use this command to define the server type if auto-detection is not giving the results you expect. The server type can be auto-detect (the default), microsoft (Microsoft LDAP), sun (Sun LDAP), or generic (generic LDAPv3).

   4. Set the starting point in the LDAP hierarchy:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-base-dn string
      PIX 6.3	-

      To process a AAA request, the LDAP server should begin its search at the distinguished name (DN) given by string (up to 128 characters). A DN has the form XX=xxxx,YY=yyyy,... where XX and YY are abbreviations for parameters within the hierarchy, and xxxx and yyyy are strings. For example, a DN string can be o=MyCompany.com or o=MyCompany.com,ou=Engineering.

   5. Limit the scope of an LDAP search:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-scope {onelevel | subtree}
      PIX 6.3	-

      By default, the LDAP server is asked to search only one tree level (onelevel) below the base DN. If your LDAP hierarchy is structured such that there are many levels below the base, you can use the subtree keyword to force a search of the entire subtree.

   6. Define the relative DN attributes to search:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-naming-attribute string
      PIX 6.3	-

      When a user is authenticated or authorized, the firewall can pass only the username and password to the LDAP server. The firewall must also inform the LDAP server which DN attributes are necessary to uniquely identify a user during a search. These are given as string (up to 128 characters).

      For example, if usernames are referenced in the Common Name attribute (the CN field of a DN), the following command would be used:

      Firewall(config-aaa-server-host)# ldap-naming-att cn
      

   7. Authenticate the firewall:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-login-dn string Firewall(config-aaa-server-host)# ldap-login-password string
      PIX 6.3	-

      The firewall must authenticate itself with the LDAP server when AAA requests are sent. This is done with a DN and a password, which are strings of up to 128 and 64 characters, respectively.

      For example, a firewall might authenticate itself with the following DN and password commands:

      Firewall(config-aaa-server-host)# ldap-login-dn cn=firewall,
      o=mycompany.com,ou=networking
      Firewall(config-aaa-server-host)# ldap-login-password mysecretpassword
      

   8. (Optional) Map user-defined LDAP attributes to Cisco LDAP attributes:

      If you are adding a firewall to an existing LDAP environment, you might need to map existing, user-defined attributes to Cisco LDAP attributes. The mapping is defined as an attribute map with the ldap-attribute-map global configuration command. You can map attribute names and attribute values as needed, using the map-name and map-value commands, respectively:

      ASA, FWSM	Firewall(config-aaa-server-host)# ldap-attribute-map map_name Firewall(config-aaa-server-host)# exit Firewall(config)# ldap-attribute-map map_name {auto-detect| microsoft | sun | generic} Firewall(config-ldap-attribute-map)# map-name user_attribute_name cisco_attribute_name Firewall(config-ldap-attribute-map)# map-value user_attribute_name user_value_string cisco_value_string
      PIX 6.3	-

6. (Optional) Identify the NT domain controller:

   ASA, FWSM	Firewall(config-aaa-server-host)# nt-auth-domain-controller string
   PIX 6.3	-

   The name of the Windows NT Primary Domain Controller (PDC) is defined as string (up to 16 characters).

7. (Optional) Adjust SDI SecureID server parameters.

   1. Define the SDI protocol version:

      ASA, FWSM	Firewall(config-aaa-server-host)# sdi-version {sdi-pre-5 | sdi-5}
      PIX 6.3	-

      The SDI version should be set to reflect the version used on the server: sdi-pre-5 (releases before 5.0) or sdi-5 (release 5.0 or later).

   2. (Optional) Set the retry interval:

      ASA, FWSM	Firewall(config-aaa-server-host)# retry-interval seconds
      PIX 6.3	-

      If the server does not answer an SDI request, the firewall retries it after seconds (1 to 10; the default is 10 seconds) has elapsed.

5-4: Configuring AAA to Manage Administrative Users

You can use external AAA servers to manage users who connect to the firewall for administrative purposes. Usernames and passwords are created or deleted on one or more centralized AAA servers. The firewall can query the servers when users connect and need to be authenticated. Firewall command authorization can also be used when various users must be limited to specific privilege levels and sets of commands. A firewall can also generate user accounting information that is collected by the external servers.

You can use the configuration steps covered in the following sections to set up AAA for administrative user management.

Enabling AAA User Authentication

Follow these steps to configure administrative user authentication with AAA servers:

1. Authenticate with a AAA server group:

   Firewall(config)# aaa authentication {serial | telnet | ssh | http} console
   server_tag [LOCAL]

   The AAA server group named server_tag is used to handle authentication requests. The server group must be configured as a separate step, as described in section 5-3, “Defining AAA Servers for User Management.” Each server defined in the group is tried in succession in case some are unreachable or unavailable.

   If all the servers in the group are down or the firewall cannot reach any of them because of networking issues, the user authentication fails. This means that you can effectively be locked out of the firewall, unable to make any configuration changes or execute any commands.

   As a fallback measure, you can add the LOCAL keyword to make the firewall use local authentication after trying the AAA server group. Even if the network is down, the local user database always is available as a way to authenticate with and connect to the firewall. You should define some administrative users on the firewall with the username command. You do not need to duplicate the entire set of users defined on the AAA servers. Just define enough usernames to allow you and your staff to connect.

2. (Optional) Authenticate users for enable mode:

   Firewall(config)# aaa authentication enable console server_tag [LOCAL]

   By default, privilege level 15 is defined with the enable password configuration command. Any user who can successfully authenticate with the firewall can also use the enable command to move to level 15, regardless of the privilege level set for the username. As well, all users share the same password for privilege level 15.

   You can configure enable authentication so that each user must enter an independent enable password to reach a higher privilege level. With an AAA server group, you can define a unique enable password for each user.

   After a user is authenticated with his or her enable password, the privilege level is changed to the level configured for the username. In other words, the privileged EXEC level is set on a per-user basis; not every user automatically arrives at level 15.

   Tip

   Enable authentication is fully functional with TACACS+ servers, because they support per-user enable passwords and enable privilege level settings. You can also use RADIUS servers for this, but each user’s enable password is always identical to his or her RADIUS password. As well, RADIUS does not directly support enable privilege levels for users.

   Figure 5-1 shows an example of the User Setup configuration for a user in CiscoACS. Under Advanced TACACS+ Settings, the user’s maximum privilege level is set to 15 for any AAA client accessible to the user. The per-user enable password has also been configured in the TACACS+ Enable Password section as a separate password maintained in the CiscoACS database.

   
   Figure 5-1: Enabling Authentication Configuration on a CiscoACS Server

   With CiscoACS, make sure the enable authentication options are made available in the user or group setup screens. In the Interface Configuration, go to Advanced Options and make sure the Per-User TACACS+/RADIUS Attributes option is checked. You should also go to Interface Configuration and select TACACS+(Cisco IOS); make sure the Advanced TACACS+ Features option is checked.

For example, suppose a firewall needs to be configured to use a farm of five RADIUS servers for administrative user authentication. The server has IP addresses 192.168.100.10 through 14, all located on the inside firewall interface. These servers authenticate users connecting to the console port, Telnet, SSH, and web-based management applications. As a fallback, local authentication is used to support a single user ID, admin, in case none of the RADIUS servers can be reached.

The following configuration commands can be used to complete the scenario:

Firewall(config)# aaa-server RADIUS_FARM protocol radius
Firewall(config)# aaa-server RADIUS_FARM (inside) host 192.168.100.10 key
Server1Key
Firewall(config)# aaa-server RADIUS_FARM (inside) host 192.168.100.11 key
Server2Key
Firewall(config)# aaa-server RADIUS_FARM (inside) host 192.168.100.12 key
Server3Key
Firewall(config)# aaa-server RADIUS_FARM (inside) host 192.168.100.13 key
Server4Key
Firewall(config)# aaa-server RADIUS_FARM (inside) host 192.168.100.14 key
Server5Key
Firewall(config)# aaa authentication serial console RADIUS_FARM LOCAL
Firewall(config)# aaa authentication telnet console RADIUS_FARM LOCAL
Firewall(config)# aaa authentication ssh console RADIUS_FARM LOCAL
Firewall(config)# aaa authentication http console RADIUS_FARM LOCAL
Firewall(config)# aaa authentication enable console RADIUS_FARM LOCAL
Firewall(config)# username admin password AdminPW privilege 15

Enabling AAA Command Authorization

If you are using external TACACS+ servers, you can configure command authorization with the following configuration command:

Firewall(config)# aaa authorization command server_tag [LOCAL]

In ASA or FWSM, you can add the LOCAL keyword to allow a fallback method of local command authorization in case none of the TACACS+ servers can be reached.

On a CiscoACS server, you can follow these steps to configure command authorization:

1. In Interface Configuration, go to TACACS+(Cisco IOS). Under TACACS+ Services, check the Shell(exec) boxes for User or Group. This displays command authorization options in the user and/or group configuration pages.

2. Select User Setup or Group Setup, depending on whether command authorization will be configured per user or per group. Select the appropriate user or group from the list.

3. Under TACACS+ Settings, look for the Shell Command Authorization Set section. Select Per User (or Per Group) Command Authorization. You can configure specific commands to permit or deny for the user or group. For all other “unmatched” or unspecified Cisco IOS commands, choose whether the CiscoACS server will Permit or Deny them.

4. To authorize a specific command, check the Command box and enter the first command keyword in the text box. You can also specify command arguments or keywords in the Arguments box. Under Unlisted arguments (arguments or keywords that you do not explicitly list for the command), select whether to Permit or Deny them.

   The ACS page can display space for more than one command to be configured. You can enter an additional command in each section that begins with a “Command” checkbox. Click the Submit button at the bottom of the page when all the command arguments have been entered. You can add more commands to the list by selecting the user or group again. Each time you configure a command, it is appended to the list of commands and arguments on the configuration page.

   Figure 5-2 shows an example of how a CiscoACS group has been configured so that enable and exit are permitted commands. All other commands are denied for the group.

   
   Figure 5-2: CiscoACS TACACS+ Command Authorization

5. You can also define lists of permitted firewall commands, which can be applied to users or groups in CiscoACS.

   1. Go to Shared Profile Components, and select Shell Command Authorization Set.

      Enter one command (only the first keyword) at a time in the text box, and click Add Command. If you need to specify keywords that can appear after the command keyword, enter those in the rightmost text box. Be sure to begin each line with permit or deny, followed by the command arguments and keywords.

      Choose whether unmatched (unlisted) commands will be permitted or denied. Then click Submit.

      In Figure 5-3, a shell command authorization set has been configured to allow a subset of users to display various firewall resources. With the show command, only specific keywords are permitted. Any other command that is not listed is denied.

      
      Figure 5-3: CiscoACS Command Authorization Set Configuration

   2. After a command authorization set is configured, you can apply it in User Setup or Group Setup. Under the Shell Command Authorization Set section, you can select the set in the drop-down list. Figure 5-4 shows how the read-only-users command authorization set can be applied to any network device that CiscoACS makes available to a group.

      
      Figure 5-4: Applying a CiscoACS Command Authorization Set

Tip

If you decide to enable command authorization, you should make sure you define an administrative user who can always access all firewall commands. In other words, disable command authorization for at least one administrative user so that you have a fallback plan. Otherwise, it is possible to misconfigure command authorization for users or groups such that you are effectively denied from making configuration changes on the firewall.

Enabling AAA Command Accounting

In PIX 6.3 or FWSM prior to 3.1(1), AAA command accounting can be performed only through the logging function. In that case, you should make sure the following Syslog message IDs are enabled to use them as an audit trail of user activity. The default severity levels are shown in parentheses:

• 611101 (6)— Successful user authentication

• 611102 (6)— Failed user authentication

• 502103 (5)— User changed privilege levels

• 111008 (5)— User executed the command text

• 111009 (7)— User executed the command show text

• 611103 (5)— User logged out

Beginning with ASA 7.0(1) and FWSM 3.1(1), accounting records can be generated each time an administrative user executes a firewall command. These accounting records can be sent to one or more AAA RADIUS or TACACS+ accounting servers.

To enable command accounting, you can use the following configuration command:

Firewall(config)# aaa accounting command [privilege level] server_tag

Accounting records are generated only when users execute commands at or above the privilege level level (0 to 15; the default is 0). The accounting records are sent to the current active server in the server group configured as server_tag.

With CiscoACS, you can view accounting records by clicking the Reports and Activity button. Then click TACACS+ Accounting or RADIUS Accounting. All accounting reports are in comma-separated value (CSV) format and can be displayed in a web browser.