About AAA on Security Devices
Authentication-Authorization-Accounting (AAA) enables the security appliance to determine who a user is (authentication), what the user can do (authorization), and what the user did (accounting). You can use authentication alone, or with authorization and accounting. Authorization always requires a user to be authenticated first. You also can use accounting alone, or with authentication and authorization.
Authentication-Authorization-Accounting provides an extra level of protection and control for user access beyond access lists alone. For example, you can create an ACL that allows all outside users to access Telnet on a server on the DMZ network. If you want to limit user access to the server when you may not always know the 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.)
-
Authentication
—Authentication grants access based on user identity. Authentication establishes user identity by requiring valid user credentials, which are typically a user name and password. You can configure the security appliance to authenticate the following items:
– Administrative connections to the security appliance using Telnet, SSH, HTTPS/ASDM, or serial console.
– The
enable
command.
-
Authorization
—Authorization controls user capabilities after users are authenticated. Authorization controls the services and commands available to each authenticated user. If you do not enable authorization, authentication alone would provide the same access to services for all authenticated users.
If you need the control that authorization provides, you can configure a broad authentication rule, and then have a detailed authorization configuration. For example, you might authenticate inside users who attempt to access any server on the outside network, and then use authorization to limit the outside servers that a particular user can access.
The security appliance caches the first 16 authorization requests per user, so if the user accesses the same services during the current authentication session, the security appliance does not resend the request to the authorization server.
-
Accounting
—Accounting tracks traffic that passes through the security appliance, providing 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, user name, the number of bytes that pass through the security appliance for the session, the service used, and the duration of each session.
Preparing for AAA
AAA services depend upon the use of the Local database or at least one AAA server. You can also use the Local database as a fallback for most services provided by an AAA server. Before you implement AAA, you should configure the Local database and configure AAA server groups and servers.
Configuration of the Local database and AAA servers depends upon the AAA services you want the security appliance to support. Regardless of whether you use AAA servers, you should configure the Local database with user accounts that support administrative access, to prevent accidental lock-outs and, if so desired, to provide a fallback method when AAA servers are unreachable. For more information, see Configuring User Accounts.
The following table provides a summary of AAA service support by each AAA server type and by the Local database. You manage the Local database by configuring user accounts on the
Platform > Device Admin > User Accounts
page (see Configuring User Accounts). You establish AAA server groups and add individual AAA servers to the server groups using the
Platform > Device Admin > AAA
page.
Table 47-1 Summary of AAA Support
|
|
|
|
|
|
|
|
|
|
Authentication of...
|
VPN users
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
1
|
Firewall sessions
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Administrators
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Authorization of...
|
VPN users
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Firewall sessions
|
No
|
Yes
2
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Administrators
|
Yes
3
|
No
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Accounting of...
|
VPN connections
|
No
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Firewall sessions
|
No
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
No
|
Administrators
|
No
|
Yes
|
Yes
|
No
|
No
|
No
|
No
|
No
|
1
HTTP Form protocol supports single sign-on authentication for WebVPN users only.
2
For firewall sessions, RADIUS authorization is supported with user-specific ACLs only, which are received or specified in a RADIUS authentication response.
3
Local command authorization is supported by privilege level only.
Local Database
The security appliance maintains a Local database that you can populate with user accounts, which contain, at a minimum, a user name. Typically, you assign a password and a privilege level to each user name, although passwords are optional. You can manage Local user accounts on the
Platform > Device Admin > User Accounts
page (see Configuring User Accounts).
If you enable command authorization using the Local database, the security appliance refers to the assigned user privilege level to determine what commands are available. By default, all commands are assigned either privilege level 0 or level 15.
Note If you add users to the Local database with access to the CLI and whom you do not want to enter privileged mode, you should enable command authorization. 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 for console access so 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.
You cannot use the local database for network access authorization.
The user accounts in the Local database can provide fallback support for console and enable-password authentication, for command authorization, and for VPN authentication and authorization. This behavior is designed to help you prevent accidental lock-out from the security appliance.
For users who need fallback support, we recommend that their user names and passwords in the Local database match their user names and passwords on 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 user names and passwords on AAA servers that are different than the user names and passwords in the Local database means that the user cannot be certain which user name and password should be given.
For multiple-context mode, you can configure user names 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.
Note VPN functions are not supported in multiple mode.
AAA for Device Administration
You can authenticate all administrative connections to the security appliance, including:
-
Telnet
-
SSH
-
Serial console
-
ASDM
-
VPN management access
You can also authenticate administrators who attempt to enter enable mode. You can authorize administrative commands. You can have accounting data for administrative sessions and for commands issued during a session sent to an accounting server.
You can configure AAA for device administration using the
Platform > Device Admin > AAA
page (see About AAA on Security Devices).
AAA for Network Access
You can configure rules for authenticating, authorizing, and accounting for traffic passing through the firewall by using the
Firewall > AAA Rules
page (see Chapter 15, “Managing Firewall AAA Rules”). The rules you create are similar to access rules, except that they specify whether to authenticate, authorize, or perform accounting for the traffic defined; and which AAA server group the security appliance is to use to process the AAA service request.
AAA for VPN Access
AAA services for VPN access include the following:
-
User account settings for assigning users to VPN groups, configured on the
Platform > Device Admin > User Accounts
page (see Configuring User Accounts).
-
VPN group policies that can be referenced by many user accounts or tunnel groups, configured on the
Remote Access VPN > RA VPN Policies > User Group Policy
or
Site to Site VPN > User Group Policy
page.
-
Tunnel group policies, configured on the
Remote Access VPN > RA VPN Policies > PIX7.0/ASA Tunnel Group Policy
or
Site to Site VPN > PIX7.0/ASA Tunnel Group Policy
page.
Configuring AAA - Authentication Tab
The AAA page presents three tabbed panels; the
Authentication
panel is presented when you navigate to the AAA page. Use these options to control privileged access to the device console, to restrict access by connection type, and to define access messages.
Use the Authorization Tab to control the services and commands available to authenticated users.
Use the Accounting Tab to activate tracking of console traffic, providing a record of user activity.
Navigation Path
-
(Device view) Select
Platform > Device Admin > AAA
from the Device Policy selector.
-
(Policy view) Select
PIX/ASA/FWSM Platform > Device Admin > AAA
from the Policy Type selector. Select an existing policy from the Shared Policy selector, or create a new one.
Related Topics
Using the Authentication Tab
Use the Authentication tab to enable authentication for administrator access to the security appliance. The Authentication tab also lets you configure the prompts and messages a user sees when authenticated by an AAA server.
The device will prompt for a user name and password before you can enter commands. If the authentication server is offline, wait until the console login request times out. You can then access the console with the firewall username and the enable password.
Field Reference
Table 47-2 Authentication Tab
|
|
Require AAA Authentication to allow use of privileged commands
|
Enable
|
Requires authentication from an AAA server to allow a user to access EXEC mode on the firewall. This option allows up to three attempts to access the firewall console. If this number is exceeded, an “access denied” message is displayed.
When checked, the Server Group field is enabled.
|
Server Group
|
Enter or Select the name of an AAA server to contact for user authentication.
|
Use LOCAL when server group fails
|
Check this box to use the LOCAL database as back-up if the selected server fails. (This option is not enabled until you provide a Server Group.)
|
Require AAA Authorization for the following types of connections
|
Select the connections that require authorization. For each type, users are allowed up to three attempts to access the firewall console. If this number is exceeded, an “access denied” message is displayed.
Select each connection option individually:
-
HTTP
– Require AAA authentication when a user initiates an HTTPS connection to the firewall console.
-
Serial
– Require AAA authentication when a user initiates a connection to the firewall console via the serial console cable.
-
SSH
– Require AAA authentication when a user initiates a Secure Shell (SSH) connection to the console.
-
Telnet
– Require AAA authentication when a user initiates a Telnet connection to the firewall console.
For each selected connection, provide a Server Group and indicate whether the LOCAL database is used as a back-up:
-
Server Group
– Enter or Select the name of an AAA server to contact for user authentication.
-
Use LOCAL when server group fails
– Check this box to use the LOCAL database as back-up if the selected server fails. (This option is not enabled until you provide a Server Group.)
|
|
Login Prompt
|
Enter the prompt a user will see when logging in to the security appliance.
|
Accepted Message
|
Enter the message displayed when successfully authenticated.
|
Rejected Message
|
Enter the message displayed when authentication fails for any reason.
|
Rejected Message for Invalid Credentials
|
Enter the message displayed when authentication fails following entry of unknown or invalid credentials.
Available only on FWSM 3.2+ devices.
|
Rejected Message for Expired Password
|
Enter the message displayed when authentication fails following entry of an expired password.
Available only on FWSM 3.2+ devices.
|
Maximum Local Authentication Failed Attempts
|
Specify the number of times the device will try to authenticate a user in the LOCAL database before that account is locked; valid values are 1 through 16.
Available only on ASA/PIX 7.01+ and FWSM 3.11+ devices.
|
Authorization Tab
The Authorization tab allows you to configure authorization for accessing firewall commands.
Navigation Path
You can access the Authorization tab from the AAA page; see Configuring AAA - Authentication Tab.
Related Topics
Field Reference
Table 47-3 Authorization Tab
|
|
Enable Authorization for Command Access
|
Requires authorization for accessing firewall commands.
|
Server Group
|
Specify the server group to use for authorization.
|
Use LOCAL when server group fails
|
Uses the LOCAL server group if the selected server group fails.
|
Accounting Tab
Use the Accounting tab to enable accounting for access to the firewall device and for access to commands on the device.
Navigation Path
You can access the Accounting tab from the AAA page; see Configuring AAA - Authentication Tab.
Related Topics
Field Reference
Table 47-4 Accounting Tab
|
|
Require AAA Accounting for privileged commands
|
Enable
|
When selected, enables the generation of accounting records to mark the entry to and exit from privileged mode for administrative access via the console.
|
Server Group
|
Specify the server or group of RADIUS or TACACS+ servers to which accounting records are sent.
|
Require AAA Accounting for the following types of connections
|
Connection type
|
Specify the connection types that will generate accounting records:
-
HTTP
—Enable or disable the generation of accounting records to mark the establishment and termination of admin sessions created over HTTP. Valid server group protocols are RADIUS and TACACS+.
-
Serial
—Enable or disable the generation of accounting records to mark the establishment and termination of admin sessions that are established via the serial interface to the console. Valid server group protocols are RADIUS and TACACS+.
-
SSH
—Enable or disable the generation of accounting records to mark the establishment and termination of admin sessions created over SSH. Valid server group protocols are RADIUS and TACACS+.
-
Telnet
—Enable or disable the generation of accounting records to mark the establishment and termination of admin sessions created over Telnet. Valid server group protocols are RADIUS and TACACS+.
|
Server Group
|
Specify the server or group of RADIUS or TACACS+ servers to which accounting records are sent.
|
Require Accounting for command access
|
Enable
|
When selected, enables the generation of accounting records for commands entered by an administrator/user.
|
Server Group
|
Provides a drop-down menu from which you can choose the server or group of RADIUS or TACACS+ servers to which accounting records are sent.
|
Privilege Level
|
Minimum privilege level that must be associated with a command for an accounting record to be generated. The default privilege level is 0.
|
Configuring Banners
You can use the Banner page to specify Session (exec), Login, and Message-of-the-Day (motd) banners for a security appliance or shared policy.
Note If you use the token $(hostname)
or $(domain)
in a banner, it is replaced with the host name or domain name of the security appliance. When you enter the $(system)
token in a context configuration, the context uses the banner configured in the system configuration.
Spaces in banner text are preserved; however, tabs cannot be entered. Multiple lines in a banner are created by entering a separate line of text for each line you wish to add. Each line is then appended to the end of the existing banner. If the line is empty, a carriage return (CR) is added to the banner.
There is no limit on the length of a banner other than RAM and flash-memory limits. You can only use ASCII characters, including new-line (press the Enter key), which counts as two characters. When accessing the security appliance through Telnet or SSH, the session closes if there is not enough system memory available to process the banner messages, or if a TCP write error occurs when attempting to display the banner messages.
Related Topics
Step 1 To configure banners, access the Banner page:
-
(Device view) Select
Platform > Device Admin > Banner
from the Device Policy selector.
-
(Policy view) Select
PIX/ASA/FWSM Platform > Device Admin > Banner
from the Policy Types selector. Select an existing policy from the Policies selector, or create a new one.
Step 2 In the
Session (exec) Banner
field, enter the text you want the system to display as a banner before displaying the enable prompt.
Step 3 In the
Login Banner
field, enter the text you want the system to display as a banner before the password login prompt when accessing the security appliance using Telnet.
Step 4 In the
Message-of-the-Day (motd) Banner
field, enter the text you want the system to display as a message-of-the-day banner.
Step 5 To replace a banner, change the contents of the appropriate box.
Step 6 To remove a banner, clear the contents of the appropriate box.
Configuring Device Credentials
Use the Credentials page to specify the user credentials Security Manager will use when contacting this device. You can also change the Enable password and the Telnet/SSH password on the device.
This user name-password combination lets you log into the device (in EXEC mode) if you connect to the security appliance using an HTTP, HTTPS, Telnet, or SSH session. You also can specify a separate password specifically for Telnet and SSH sessions. (Further, you can define separate credentials for HTTP/HTTPS connections on the Device Credentials Page in the Device Properties window.)
The Enable password lets you access privileged EXEC mode after you log in.
Tip The Username, Password, and Enable Password on this page are linked to the Credentials settings in the Device Properties window. When you update these parameters and then deploy the changes to the device, Security Manager uses the existing credentials defined in the Device Properties to log into the device and deploy changes. After successful deployment, the Device Properties credentials are updated to match these settings. For more information about Credentials in Device Properties, see Device Credentials Page.
Navigation Path
-
(Device view) Select
Platform > Device Admin > Credentials
from the Device Policy selector.
-
(Policy view) Select
PIX/ASA/FWSM Platform > Device Admin > Credentials
from the Policy Type selector. Select an existing policy from the Shared Policy selector, or create a new one.
Warning Since several user accounts may exist on each device, applying a shared Credentials policy to multiple devices will update only the Enable Password on each device; the Username and Password provided in the shared policy are not applied (nor is the Telnet/SSH password). The Enable Password is sufficient for subsequent access to PIX/ASA/FWSM devices, unless external authentication such as AAA or TACACS+ is configured, in which case the Enable Password alone is not sufficient. In this situation, you must manually update the Username, Password and Enable Password on each device that uses external authentication.
Related Topics
Field Reference
Table 47-8 Credentials Page
|
|
Username
|
Enter a user name for logging into the device. The name must be at least four characters; the maximum is 64 characters. Entries are case-sensitive.
|
Password
Confirm
|
Provide a password for logging into the device (EXEC mode) with the specified Username. This password must be at least three characters; the maximum is 32 characters. Entries are case-sensitive.
Re-enter the user password in the Confirm field.
Note We recommend a password length of at least 8 characters.
|
Privilege Level
|
Choose a privilege level for this user; available values are 1 through 15. Level 1 allows EXEC-mode access only, the default level for log-in; level 15 allows Privileged EXEC-mode access; that is, access to the Enable mode. Other levels must be explicitly defined on the device.
|
Enable Password
Confirm
|
You can specify an Enable password that lets this user access Privileged EXEC mode after logging in. This password must be at least three characters; the maximum is 32 characters. Entries are case-sensitive.
Re-enter the Enable password in the Confirm field.
Note If you configure user authentication for Enable access, each user has their own password and this password is not used. See Configuring AAA - Authentication Tab for more information.
|
Telnet/SSH Password
Confirm
|
You can specify a password that provides access to EXEC mode when connecting to the device via a Telnet or SSH session. This password must be at least three characters; the maximum is 32 characters. Entries are case-sensitive.
Re-enter the Telnet/SSH password in the Confirm field.
Note If you configure user authentication for Telnet or SSH access, each user has their own password and this password is not used. See Configuring AAA - Authentication Tab for more information.
|