Usage Guidelines

When you configure the aaa accounting command command, each command other than show commands entered by an administrator is recorded and sent to the accounting server or servers.

Usage Guidelines

You must specify the name of the server group, previously specified in the aaa-server command.

Usage Guidelines

The ASA can send accounting information to a RADIUS or TACACS+ server about any TCP or UDP traffic that passes through the ASA. If that traffic is also authenticated, then the AAA server can maintain accounting information by username. If the traffic is not authenticated, the AAA server can maintain accounting information by IP address. Accounting information includes when sessions start and stop, username, the number of bytes that pass through the ASA for the session, the service used, and the duration of each session.

Before you can use this command, you must first designate a AAA server with the aaa-server command.

To enable accounting for traffic that is specified by an ACL, use the aaa accounting match command. You cannot use the match command in the same configuration as the include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by Adaptive Security Device Manager (ASDM).

You cannot use the aaa accounting include and exclude commands between same-security interfaces. For that scenario, you must use the aaa accounting match command.

Usage Guidelines

The ASA can send accounting information to a RADIUS or TACACS+ server about any TCP or UDP traffic that passes through the ASA. If that traffic is also authenticated, then the AAA server can maintain accounting information by username. If the traffic is not authenticated, the AAA server can maintain accounting information by IP address. Accounting information includes when sessions start and stop, username, the number of bytes that pass through the ASA for the session, the service used, and the duration of each session.

Before you can use this command, you must first designate a AAA server with the aaa-server command.

Accounting information is sent only to the active server in a server group unless you enable simultaneous accounting using the accounting-mode command in aaa-server protocol configuration mode.

You cannot use the aaa accounting match command in the same configuration as the aaa accounting include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by ASDM.

Usage Guidelines

Before the ASA can authenticate a Telnet, SSH, or HTTPS user, you must first configure access to the ASA using the telnet , ssh , or http commands. These commands identify the IP addresses that are allowed to communicate with the ASA.

Logging in to the ASA

After you connect to the ASA, you log in and access user EXEC mode.

• If you do not enable any authentication for serial access, you do not enter a username or password.

• If you do not enable any authentication for Telnet, you do not enter a username; you enter the login password (set with the password command).

• If you enable Telnet or SSH authentication using this command, you enter the username and password as defined on the AAA server or local user database.

Accessing Privileged EXEC Mode

To enter privileged EXEC mode, enter the enable command or the login command (if you are using the local database only).

• If you do not configure enable authentication, enter the system enable password when you enter the enable command (set by the enable password command). However, if you do not use enable authentication, after you enter the enable command, you are no longer logged in as a particular user. To maintain your username, use enable authentication.

• If you configure enable authentication, the ASA prompts you for your username and password.

For authentication using the local database, you can use the login command, which maintains the username but requires no configuration to turn on authentication.

Accessing ASDM

By default, you can log into ASDM with a blank username and the enable password set by the enable password command. However, if you enter a username and password at the login screen (instead of leaving the username blank), ASDM checks the local database for a match.

HTTPS authentication does not support the SDI protocol for a AAA server group. The maximum username prompt for HTTPS authentication is 30 characters. The maximum password length is 16 characters.

No Support in the System Execution Space for AAA Commands

In multiple context mode, you cannot configure any AAA commands in the system configuration.

Number of Login Attempts Allowed

As the following table shows, the action of the prompts for authenticated access to the ASA CLI differ, depending on the option you choose with the aaa authentication console command.

Usage Guidelines

To enable authentication for traffic that is specified by an ACL, use the aaa authentication match command. You cannot use the match command in the same configuration as the include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by ASDM.

You cannot use the aaa authentication include and exclude commands between same-security interfaces. For that scenario, you must use the aaa authentication match command.

TCP sessions might have their sequence numbers randomized even if you disable sequence randomization. This occurs when a AAA server proxies the TCP session to authenticate the user before permitting access.

One-Time Authentication

A user at a given IP address only needs to authenticate one time for all rules and types, until the authentication session expires. (See the timeout uauth command for timeout values.) For example, if you configure the ASA to authenticate Telnet and FTP, and a user first successfully authenticates for Telnet, then as long as the authentication session exists, the user does not also have to authenticate for FTP.

For HTTP or HTTPS authentication, once authenticated, a user never has to reauthenticate, no matter how low the timeout uauth command is set, because the browser caches the string “Basic=Uuhjksdkfhk==” in every subsequent connection to that particular site. This can be cleared only when the user exits all instances of the web browser and restarts. Flushing the cache is of no use.

Applications Required to Receive an Authentication Challenge

Although you can configure the ASA to require authentication for network access to any protocol or service, users can authenticate directly with HTTP, HTTPS, Telnet, or FTP only. A user must first authenticate with one of these services before the ASA allows other traffic requiring authentication.

The authentication ports that the ASA supports for AAA are fixed:

• Port 21 for FTP

• Port 23 for Telnet

• Port 80 for HTTP

• Port 443 for HTTPS

ASA Authentication Prompts

For Telnet and FTP, the ASA generates an authentication prompt.

For HTTP, the ASA uses basic HTTP authentication by default, and provides an authentication prompt. You can optionally configure the ASA to redirect users to an internal web page where they can enter their username and password (configured with the aaa authentication listener command).

For HTTPS, the ASA generates a custom login screen. You can optionally configure the ASA to redirect users to an internal web page where they can enter their username and password (configured with the aaa authentication listener command).

Redirection is an improvement over the basic method because it provides an improved user experience when authenticating, and an identical user experience for HTTP and HTTPS in both Easy VPN and firewall modes. It also supports authenticating directly with the ASA.

You might want to continue to use basic HTTP authentication if: you do not want the ASA to open listening ports; if you use NAT on a router and you do not want to create a translation rule for the web page served by the ASA; basic HTTP authentication might work better with your network. For example non-browser applications, like when a URL is embedded in email, might be more compatible with basic authentication.

After you authenticate correctly, the ASA redirects you to your original destination. If the destination server also has its own authentication, the user enters another username and password. If you use basic HTTP authentication and need to enter another username and password for the destination server, then you need to configure the virtual http command.

Note	If you use HTTP authentication without using the aaa authentication secure-http-client command, the username and password are sent from the client to the ASA in clear text. We recommend that you use the aaa authentication secure-http-client command whenever you enable HTTP authentication.

For FTP, a user has the option of entering the ASA username followed by an at sign (@) and then the FTP username (name1@name2). For the password, the user enters the ASA password followed by an at sign (@) and then the FTP password (password1@password2). For example, enter the following text.

name> asa1@partreq
password> letmein@he110

This feature is useful when you have cascaded firewalls that require multiple logins. You can separate several names and passwords by multiple at signs (@).

The number of login attempts allowed differs between the supported protocols:

Static PAT and HTTP

For HTTP authentication, the ASA checks real ports when static PAT is configured. If it detects traffic destined for real port 80, regardless of the mapped port, the ASA intercepts the HTTP connection and enforces authentication.

For example, assume that outside TCP port 889 is translated to port 80 (www) and that any relevant ACLs permit the traffic:

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 www netmask 255.255.255.255

Then when users try to access 10.48.66.155 on port 889, the ASA intercepts the traffic and enforces HTTP authentication. Users see the HTTP authentication page in their web browsers before the ASA allows HTTP connection to complete.

If the local port is different than port 80, as in the following example:

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 111 netmask 255.255.255.255

Then users do not see the authentication page. Instead, the ASA sends an error message to the web browser indicating that the user must be authenticated before using the requested service.

Authenticating Directly with the ASA

If you do not want to allow HTTP, HTTPS, Telnet, or FTP through the ASA but want to authenticate other types of traffic, you can authenticate with the ASA directly using HTTP or HTTPS by configuring the aaa authentication listener command.

You can authenticate directly with the ASA at the following URLs when you enable AAA for the interface:

http://interface_ip[:port]/netaccess/connstatus.html
https://interface_ip[:port]/netaccess/connstatus.html

Alternatively, you can configure virtual Telnet (using the virtual telnet command). With virtual Telnet, the user Telnets to a given IP address configured on the ASA, and the ASA provides a Telnet prompt.

Usage Guidelines

Without the aaa authentication listener command, when HTTP/HTTPS users need to authenticate with the ASA after you configure the aaa authentication match or aaa authentication include command, the ASA uses basic HTTP authentication. For HTTPS, the ASA generates a custom login screen.

If you configure the aaa authentication listener command with the redirect keyword, the ASA redirects all HTTP/HTTPS authentication requests to web pages served by the ASA.

Redirection is an improvement over the basic method because it provides an improved user experience when authenticating, and an identical user experience for HTTP and HTTPS in both Easy VPN and firewall modes. It also supports authenticating directly with the ASA.

You might want to continue to use basic HTTP authentication if: you do not want the ASA to open listening ports; if you use NAT on a router and you do not want to create a translation rule for the web page served by the ASA; basic HTTP authentication might work better with your network. For example non-browser applications, like when a URL is embedded in email, might be more compatible with basic authentication.

If you enter the aaa authentication listener command without the redirect option, then you only enable direct authentication with the ASA, while letting through traffic use basic HTTP authentication. The redirect option enables both direct and through-traffic authentication. Direct authentication is useful when you want to authenticate traffic types that do not support authentication challenges; you can have each user authenticate directly with the ASA before using any other services.

Note	For cut-through proxy, when the user logs out from the authentication page, the connection stays active. The user must also log out of the SSH session to completely clear the connection.

If you enable the redirect option, you cannot also configure static PAT for the same interface where you translate the interface IP address and the same port that is used for the listener; NAT succeds, but authentication fails. For example, the following configuration is unsupported:

ciscoasa(config)# static (inside,outside) tcp interface www 192.168.0.50 www netmask 255.255.255.255
ciscoasa(config)# aaa authentication listener http outside redirect

The following configuration is supported; the listener uses port 1080 instead of the default 80:

ciscoasa(config)# static (inside,outside) tcp interface www 192.168.0.50 www netmask 255.255.255.255
ciscoasa(config)# aaa authentication listener http outside port 1080 redirect

Usage Guidelines

By default, the cut-through proxy portal page (/netaccess/connstatus.html) presents session information and a logout button if it is accessed when a cut-through-proxy session is already active for the connecting host. You can use this command to remove the logout button.

This is useful in case where users connect from behind a NAT device and cannot be distinguished by IP address. When one user logs out, it logs out all users of the IP address.

Usage Guidelines

This feature applies to usernames in the local database or from a AAA server when you enable local AAA authentication for one or more of the CLI management methods (SSH, Telnet, serial console).

ASDM logins are not saved in the history.

The login history is only saved per unit; in failover and clustering environments, each unit maintains its own login history only.

Login history data is not maintained over reloads.

To view the login history, use the show aaa login-history command.

Usage Guidelines

You cannot use the aaa authentication match command in the same configuration as the include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by ASDM.

TCP sessions might have their sequence numbers randomized even if you disable sequence randomization. This occurs when a AAA server proxies the TCP session to authenticate the user before permitting access.

One-Time Authentication

A user at a given IP address only needs to authenticate one time for all rules and types, until the authentication session expires. (See the timeout uauth command for timeout values.) For example, if you configure the ASA to authenticate Telnet and FTP, and a user first successfully authenticates for Telnet, then as long as the authentication session exists, the user does not also have to authenticate for FTP.

For HTTP or HTTPS authentication, once authenticated, a user never has to reauthenticate, no matter how low the timeout uauth command is set, because the browser caches the string “Basic=Uuhjksdkfhk==” in every subsequent connection to that particular site. This can be cleared only when the user exits all instances of the web browser and restarts. Flushing the cache is of no use.

Applications Required to Receive an Authentication Challenge

Although you can configure the ASA to require authentication for network access to any protocol or service, users can authenticate directly with HTTP, HTTPS, Telnet, or FTP only. A user must first authenticate with one of these services before the ASA allows other traffic requiring authentication.

The authentication ports that the ASA supports for AAA are fixed:

• Port 21 for FTP

• Port 23 for Telnet

• Port 80 for HTTP

• Port 443 for HTTPS (requires the aaa authentication listener command)

ASA Authentication Prompts

For Telnet and FTP, the ASA generates an authentication prompt.

For HTTP, the ASA uses basic HTTP authentication by default, and provides an authentication prompt. You can optionally configure the ASA to redirect users to an internal web page where they can enter their username and password (configured with the aaa authentication listener command).

For HTTPS, the ASA generates a custom login screen. You can optionally configure the ASA to redirect users to an internal web page where they can enter their username and password (configured with the aaa authentication listener command).

Redirection is an improvement over the basic method because it provides an improved user experience when authenticating, and an identical user experience for HTTP and HTTPS in both Easy VPN and firewall modes. It also supports authenticating directly with the ASA.

You might want to continue to use basic HTTP authentication if: you do not want the ASA to open listening ports; if you use NAT on a router and you do not want to create a translation rule for the web page served by the ASA; basic HTTP authentication might work better with your network. For example non-browser applications, like when a URL is embedded in email, might be more compatible with basic authentication.

After you authenticate correctly, the ASA redirects you to your original destination. If the destination server also has its own authentication, the user enters another username and password. If you use basic HTTP authentication and need to enter another username and password for the destination server, then you need to configure the virtual http command.

Note	If you use HTTP authentication without using the aaa authentication secure-http-client command, the username and password are sent from the client to the ASA in clear text. We recommend that you use the aaa authentication secure-http-client command whenever you enable HTTP authentication.

For FTP, a user has the option of entering the ASA username followed by an at sign (@) and then the FTP username (name1@name2). For the password, the user enters the ASA password followed by an at sign (@) and then the FTP password (password1@password2). For example, enter the following text.

name> asa1@partreq
password> letmein@he110

This feature is useful when you have cascaded firewalls that require multiple logins. You can separate several names and passwords by multiple at signs (@).

The number of login attempts allowed differs between the supported protocols:

Static PAT and HTTP

For HTTP authentication, the ASA checks real ports when static PAT is configured. If it detects traffic destined for real port 80, regardless of the mapped port, the ASA intercepts the HTTP connection and enforces authentication.

For example, assume that outside TCP port 889 is translated to port 80 (www) and that any relevant ACLs permit the traffic:

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 www netmask 255.255.255.255

Then when users try to access 10.48.66.155 on port 889, the ASA intercepts the traffic and enforces HTTP authentication. Users see the HTTP authentication page in their web browsers before the ASA allows HTTP connection to complete.

If the local port is different than port 80, as in the following example:

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 111 netmask 255.255.255.255

Then users do not see the authentication page. Instead, the ASA sends to the web browser an error message indicating that the user must be authenticated before using the requested service.

Authenticating Directly with the ASA

If you do not want to allow HTTP, HTTPS, Telnet, or FTP through the ASA but want to authenticate other types of traffic, you can authenticate with the ASA directly using HTTP or HTTPS by configuring the aaa authentication listener command.

You can authenticate directly with the ASA at the following URLs when you enable AAA for the interface:

http://interface_ip[:port]/netaccess/connstatus.html
https://interface_ip[:port]/netaccess/connstatus.html

Alternatively, you can configure virtual Telnet (using the virtual telnet command). With virtual Telnet, the user Telnets to a given IP address configured on the ASA, and the ASA provides a Telnet prompt.

Usage Guidelines

The aaa authentication secure-http-client command offers a secure method for user authentication to the ASA before allowing user HTTP-based web requests to traverse the ASA. This command is used for HTTP cut-through proxy authentication through SSL.

The aaa authentication secure-http-client command has the following limitations:

• At runtime, a maximum of 64 HTTPS authentication processes is allowed. If all 64 HTTPS authentication processes are running, the 65th, new HTTPS connection requiring authentication is not allowed.

• When uauth timeout 0 is configured (the uauth timeout is set to 0), HTTPS authentication might not work. If a browser initiates multiple TCP connections to load a web page after HTTPS authentication, the first connection is let through, but the subsequent connections trigger authentication. As a result, users are continuously presented with an authentication page, even if the correct username and password are entered each time. To work around this, set the uauth timeout to 1 second with the timeout uauth 0:0:1 command. However, this workaround opens a 1-second window of opportunity that might allow non-authenticated users to go through the firewall if they are coming from the same source IP address.

• Because HTTPS authentication occurs on the SSL port 443, users must not configure an access-list command statement to block traffic from the HTTP client to HTTP server on port 443. Furthermore, if static PAT is configured for web traffic on port 80, it must also be configured for the SSL port. In the following example, the first line configures static PAT for web traffic and the second line must be added to support the HTTPS authentication configuration:

static (inside,outside) tcp 10.132.16.200 www 10.130.16.10 www
static (inside,outside) tcp 10.132.16.200 443 10.130.16.10 443

Usage Guidelines

The aaa authorization command command specifies whether command execution at the CLI is subject to authorization. By default when you log in, you can access user EXEC mode, which offers only a minimal number of commands. When you enter the enable command (or the login command when you use the local database), you can access privileged EXEC mode and advanced commands, including configuration commands. If you want to control the access to commands, the ASA lets you configure command authorization, where you can determine which commands are available to a user.

Supported Command Authorization Methods

You can use one of two command authorization methods:

• Local privilege levels—Configure the command privilege levels on the ASA. When a local, RADIUS, or LDAP (if you map LDAP attributes to RADIUS attributes) user authenticates for CLI access, the ASA places that user in the privilege level that is defined by the local database, RADIUS, or LDAP server. The user can access commands at the user privilege level and below. Note that all users access user EXEC mode when they first log in (commands at level 0 or 1). The user needs to authenticate again with the enable command to access privileged EXEC mode (commands at level 2 or higher), or they can log in with the login command (local database only).

Note

You can use local command authorization without any users in the local database and without CLI or enable authentication. Instead, when you enter the enable command, you enter the system enable password, and the ASA places you in level 15. You can then create enable passwords for every level, so that when you enter enable n (2 to 15), the ASA places you in level n . These levels are not used unless you turn on local command authorization. (See the enable command for more information.)

• TACACS+ server privilege levels—On the TACACS+ server, configure the commands that a user or group can use after they authenticate for CLI access. Every command that a user enters at the CLI is checked with the TACACS+ server.

Security Contexts and Command Authorization

The following are important points to consider when implementing command authorization with multiple security contexts:

• AAA settings are discrete per context, not shared between contexts.

When configuring command authorization, you must configure each security context separately. This provides you the opportunity to enforce different command authorizations for different security contexts.

When switching between security contexts, administrators should be aware that the commands permitted for the username specified when they login may be different in the new context session or that command authorization may not be configured at all in the new context. Failure to understand that command authorizations may differ between security contexts could confuse an administrator. This behavior is further complicated by the next point.

• New context sessions started with the changeto command always use the default “enable_15” username as the administrator identity, regardless of what username was used in the previous context session. This behavior can lead to confusion if command authorization is not configured for the enable_15 user or if authorizations are different for the enable_15 user than for the user in the previous context session.

This behavior also affects command accounting, which is useful only if you can accurately associate each command that is issued with a particular administrator. Because all administrators with permission to use the changeto command can use the enable_15 username in other contexts, command accounting records may not readily identify who was logged in as the enable_15 username. If you use different accounting servers for each context, tracking who was using the enable_15 username requires correlating the data from several servers.

When configuring command authorization, consider the following:

• An administrator with permission to use the changeto command effectively has permission to use all commands permitted to the enable_15 user in each of the other contexts.

• If you intend to authorize commands differently per context, ensure that in each context the enable_15 username is denied the use of commands that are also denied to administrators who are permitted to use the changeto command.

When switching between security contexts, administrators can exit privileged EXEC mode and enter the enable command again to use the username they need.

Note	The system execution space does not support aaa commands; therefore, command authorization is not available in the system execution space.

Local Command Authorization Prerequisites

• Configure enable authentication for local, RADIUS, or LDAP authentication using the aaa authentication enable console command.

Enable authentication is essential to maintain the username after the user accesses the enable command.

Alternatively, you can use the login command (which is the same as the enable command with authentication), which requires no configuration. We do not recommend this option because it is not as secure as enable authentication.

You can also use CLI authentication (aaa authentication {ssh | telnet | serial } console ), but it is not required.

• You can use the aaa authorization exec command to enable support of administrative user privilege levels from RADIUS if RADIUS is used for authentication, but it is not required. This command also enables management authorization for local, RADIUS, LDAP (mapped), and TACACS+ users.

• See the following prerequisites for each user type:

• See the privilege command for information about setting command privilege levels.

TACACS+ Command Authorization

If you enable TACACS+ command authorization, and a user enters a command at the CLI, the ASA sends the command and username to the TACACS+ server to determine if the command is authorized.

When configuring command authorization with a TACACS+ server, do not save your configuration until you are sure it works the way you want. If you get locked out because of a mistake, you can usually recover access by restarting the ASA.

Be sure that your TACACS+ system is completely stable and reliable. The necessary level of reliability typically requires that you have a fully redundant TACACS+ server system and fully redundant connectivity to the ASA. For example, in your TACACS+ server pool, include one server connected to interface 1, and another to interface 2. You can also configure local command authorization as a fallback method if the TACACS+ server is unavailable. In this case, you need to configure local users and command privilege levels.

See the CLI configuration guide for information about configuring the TACACS+ server.

TACACS+ Command Authorization Prerequisites

• Configure CLI authentication using the aaa authentication {ssh | telnet | serial } console command.

• Configure enable authentication using the aaa authentication enable console command.

Usage Guidelines

When using the aaa authorization exec command, the service-type credentials of the user are checked before allowing console access.

When you disable management authorization with the no aaa authorization exec command, note the following:

• The service-type credentials of the user are not checked before allowing console access.

• If command authorization is configured, privilege-level attributes are still applied if they are found in the AAA server for RADIUS, LDAP, and TACACS+ users.

If you configure aaa authentication console commands to authenticate users when they access the CLI, ASDM, or the enable command, then the aaa authorization exec command can limit management access depending on the user configuration.

Note	Serial access is not included in management authorization, so if you configure aaa authentication serial console , then any user who authenticates can access the console port. If you configure command authorization, then console users are still subject to command usage limits.

To configure the user for management authorization, see the following requirements for each AAA server type or local user:

• LDAP mapped users—To map LDAP attributes, see the ldap attribute-map command.

• RADIUS users—Use the IETF RADIUS numeric service-type attribute, which maps to one of the following values:

  • Service-Type 5 (Outbound) denies management access. The user cannot use any services specified by the aaa authentication console commands (excluding the serial keyword; serial access is allowed). Remote access (IPsec and SSL) users can still authenticate and terminate their remote access sessions.

  • Service-Type 6 (Administrative) allows full access to any services specified by the aaa authentication console commands.

  • Service-Type 7 (NAS prompt) allows access to the CLI when you configure the aaa authentication {telnet | ssh} console command, but denies ASDM configuration access if you configure the aaa authentication http console command. ASDM monitoring access is allowed. If you configure enable authentication with the aaa authentication enable console command, the user cannot access privileged EXEC mode using the enable command.

Note	The only recognized service-types are Login (1), Framed (2), Administrative (6), and NAS-Prompt (7). Using any other service-types results in denied access.

• TACACS+ users—Request authorization with the “service=shell” entry, and the server responds with PASS or FAIL, as follows:

  • PASS, privilege level 1 allows full access to any services specified by the aaa authentication console commands.

  • PASS, privilege level 2 and higher allows access to the CLI when you configure the aaa authentication {telnet | ssh} console command, but denies ASDM configuration access if you configure the aaa authentication http console command. ASDM monitoring access is allowed. If you configure enable authentication with the aaa authentication enable console command, the user cannot access privileged EXEC mode using the enable command.

  • FAIL denies management access. The user cannot use any services specified by the aaa authentication console commands (excluding the serial keyword; serial access is allowed).

• Local users—Set the service-type command, which is in the username configuration mode of the username command. By default, the service-type is admin , which allows full access to any services specified by the aaa authentication console commands.

Usage Guidelines

This command is not available on platforms that do no support webvpn (ASA 1000v) and platforms with No Payload Encryption (NPE) enabled.

Usage Guidelines

To enable authorization for traffic that is specified by an ACL, use the aaa authorization match command. You cannot use the match command in the same configuration as the include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by ASDM.

You cannot use the aaa authorization include and exclude commands between same-security interfaces. For that scenario, you must use the aaa authorization match command.

You can configure the ASA to perform network access authorization with TACACS+. Authentication and authorization statements are independent; however, any unauthenticated traffic matched by an authorization statement will be denied. For authorization to succeed, a user must first authenticate with the ASA. Because a user at a given IP address only needs to authenticate one time for all rules and types, if the authentication session has not expired, authorization can occur even if the traffic is matched by an authentication statement.

After a user authenticates, the ASA checks the authorization rules for matching traffic. If the traffic matches the authorization statement, the ASA sends the username to the TACACS+ server. The TACACS+ server responds to the ASA with a permit or a deny for that traffic, based on the user profile. The ASA enforces the authorization rule in the response.

See the documentation for your TACACS+ server for information about configuring network access authorizations for a user.

For each IP address, one aaa authorization include command is permitted.

If the first attempt at authorization fails and a second attempt causes a timeout, use the service resetinbound command to reset the client that failed the authorization so that it will not retransmit any connections. An example authorization timeout message in Telnet follows.

Unable to connect to remote host: Connection timed out

Note

Specifying a port range might produce unexpected results at the authorization server. The ASA sends the port range to the server as a string, with the expectation that the server will parse it out into specific ports. Not all servers do this. In addition, you might want users to be authorized on specific services, which does not occur if a range is accepted.

Usage Guidelines

You cannot use the aaa authorization match command in the same configuration as the include and exclude commands. We suggest that you use the match command instead of the include and exclude commands; the include and exclude commands are not supported by ASDM.

You can configure the ASA to perform network access authorization with TACACS+. RADIUS authorization with the aaa authorization match command only supports authorization of VPN management connections to the ASA.

Authentication and authorization statements are independent; however, any unauthenticated traffic matched by an authorization statement will be denied. For authorization to succeed, a user must first authenticate with the ASA. Because a user at a given IP address only needs to authenticate one time for all rules and types, if the authentication session has not expired, authorization can occur even if the traffic is matched by an authentication statement.

After a user authenticates, the ASA checks the authorization rules for matching traffic. If the traffic matches the authorization statement, the ASA sends the username to the TACACS+ server. The TACACS+ server responds to the ASA with a permit or a deny for that traffic, based on the user profile. The ASA enforces the authorization rule in the response.

See the documentation for your TACACS+ server for information about configuring network access authorizations for a user.

If the first attempt at authorization fails and a second attempt causes a timeout, use the service resetinbound command to reset the client that failed the authorization so that it will not retransmit any connections. An example authorization timeout message in Telnet follows.

Unable to connect to remote host: Connection timed out

Note

Specifying a port range might produce unexpected results at the authorization server. The ASA sends the port range to the server as a string, with the expectation that the server will parse it out into specific ports. Not all servers do this. In addition, you might want users to be authorized on specific services, which does not occur if a range is accepted.

Usage Guidelines

You can configure a Kerberos AAA server group to authenticate the servers in the group using the validate-kdc command. To accomplish the authentication, you must also import a keytab file that you exported from the Kerberos Key Distribution Center (KDC). By validating the KDC, you can prevent an attack where the attacker spoofs the KDC so that user credentials are authenticated against the attacker’s Kerberos server.

When you enable KDC validation, after obtaining the ticket-granting ticket (TGT) and validating the user, the system also requests a service ticket on behalf of the user for host /ASA_hostname . The system then validates the returned service ticket against the secret key for the KDC, which is stored in a keytab file that you generated from the KDC and then uploaded to the ASA. If KDC authentication fails, the server is considered untrusted and the user is not authenticated.

To accomplish KDC authentication, you must do the following:

1. (On the KDC.) Create a user account in the Microsoft Active Directory for the ASA (go to Start > Programs > Administrative Tools > Active Directory Users and Computers ). For example, if the fully-qualified domain name (FQDN) of the ASA is asahost.example.com, create a user named asahost.

2. (On the KDC.) Create a host service principal name (SPN) for the ASA using the FQDN and user account:

   
   C:> setspn -A HOST/asahost.example.com asahost
   

3. (On the KDC.) Create a keytab file for the ASA (line feeds added for clarity):

   
   C:\Users\Administrator> ktpass /out new.keytab +rndPass
   /princ host/asahost@EXAMPLE.COM
   /mapuser asahost@example.com
   /ptype KRB5_NT_SRV_HST
   /mapop set
   

4. (On the ASA.) Import the keytab (in this example, new.keytab) to the ASA using the aaa kerberos import-keytab command.

5. (On the ASA.) Add the validate-kdc command to the Kerberos AAA server group configuration. The keytab file is used only by server groups that contain this command.

Note	You cannot use KDC validation in conjunction with Kerberos Constrained Delegation (KCD). The validate-kdc command will be ignored if the server group is used for KCD.

Usage Guidelines

This command only affects authentication with the local user database. If you omit this command, there is no limit on the number of times a user can enter an incorrect password.

After a user makes the configured number of attempts with the wrong password, the user is locked out and cannot log in successfully until the administrator unlocks the username, or until 10 minutes passes. Locking or unlocking a username results in a syslog message.

The number of failed attempts resets to zero and the lockout status resets to No when the user successfully authenticates or when the ASA reboots.

Usage Guidelines

You can only add one aaa mac-exempt command. Configure the MAC list number using the mac-list command before using the aaa mac-exempt command. Permit entries in the MAC list exempt the MAC addresses from authentication and authorization, while deny entries require authentication and authorization for the MAC address, if enabled. Because you can only add one instance of the aaa mac-exempt command, be sure that the MAC list includes all the MAC addresses that you want to exempt.

Usage Guidelines

If a source address is a proxy server, consider excluding this IP address from authentication or increasing the number of allowable outstanding AAA requests.

For example, if two users were at the same IP address (perhaps connected to a terminal server) and both open a browser or connection and try to begin authenticating at exactly the same time, only one would be allowed, and the second would be blocked.

The first session from that IP address will be proxied and sent the auththentication request, while the other session would time out. This has nothing to do with how many connections a single username has.

Usage Guidelines

You can manually import the node-secret file that is generated by the RSA Authentication Manager (SecurID) server.

You must export the node secret file from the RSA Authentication Manager server. For details, see the RSA Authentication Manager documentation. Then, either upload the unzipped file to the ASA, or place it on a server from which you can import it using this command.

Usage Guidelines

You can have up to 100 server groups in single mode or 4 server groups per context in multiple mode. Starting with 9.13(1), the limits are increased to 200 groups in single mode, 8 groups in multiple mode.

Each group can have up to 16 servers in single mode or 4 servers in multiple mode. Starting with 9.13(1), the limit for multiple mode is 8 servers per group. When a user logs in, the servers are accessed one at a time starting with the first server you specify in the configuration, until a server responds.

You control AAA server configuration by defining a AAA server group protocol with the aaa-server command, and then you add servers to the group using the aaa-server host command. When you enter the aaa-server protocol command, you enter aaa-server group configuration mode.

If you are using the RADIUS protocol and are in the aaa-server group configuration mode, note the following:

• To enable multi-session accounting for clientless SSL and Secure Client sessions, enter the interim-accounting-update option. If you choose this option, interim accounting records are sent to the RADIUS server in addition to the start and stop records.

• To specify the shared secret between the ASA and the AD agent and indicate that a RADIUS server group includes AD agents that are not full-function RADIUS servers, enter the ad-agent-mode option. Only a RADIUS server group that has been configured using this option can be associated with user identity. As a result, the test aaa-server {authentication | authorization } aaa-server-group command is not available when a RADIUS server group that is not configured using the ad-agent-mode option is specified.

Usage Guidelines

Without this command, servers in a group that failed remain in a failed state until all servers in the group fail, after which all are reactivated.

Usage Guidelines

You control AAA server configuration by defining a AAA server group with the aaa-server command, and then you add servers to the group using the aaa-server host command. When you use the aaa-server host command, you enter the aaa-server host configuration mode, from which you can specify and manage host-specific AAA server connection data.

Each group can have up to 16 servers in single mode or 4 servers in multiple mode. Starting with 9.13(1), the limit for multiple mode is 8 servers per group. When a user logs in, the servers are accessed one at a time starting with the first server that you specify in the configuration, until a server responds.

Usage Guidelines

To implement a time-based ACL, use the time-range command to define specific times of the day and week. Then use the access-list extended time-range command to bind the time range to an ACL.

Usage Guidelines

During phase 1 processing, an IKE peer might pass both a subordinate certificate and an identity certificate. The subordinate certificate might not be installed on the ASA. This command lets an administrator support subordinate CA certificates that are not configured as trustpoints on the device without requiring that all subordinate CA certificates of all established trustpoints be acceptable; in other words, this command lets the device authenticate a certificate chain without installing the entire chain locally.

Usage Guidelines

Interface-specific access-group rules have higher priority that global rules, so at the time of packet classification, interface-specific rules are processed before global rules.

In routed mode, if you apply access groups to both a BVI and its member interfaces, the precedence depends on direction. Inbound, the member interface access group is checked first, then the BVI access group, and finally the global group. Outbound, the BVI access group is checked first, then the member interface access group.

Usage Guidelines for Interface-specific Rules

The access-group command binds an extended ACL to an interface. You must use the access-list extended command first to create the ACL.

You can apply the ACL to traffic inbound to an interface or outbound from an interface. If you enter the permit option in an access-list command statement, the ASA continues to process the packet. If you enter the deny option in an access-list command statement, the ASA discards the packet and generates syslog message 106023 (or 106100 for ACEs that use non-default logging).

For inbound ACLs, the per-user-override option allows downloaded ACLs to override the ACL applied to the interface. If the per-user-override option is not present, the ASA preserves the existing filtering behavior. When per-user-override is present, the ASA allows the permit or deny status from the per-user access-list (if one is downloaded) associated to a user to override the permit or deny status from the access-group command associated ACL. Additionally, the following rules are observed:

• At the time a packet arrives, if there is no per-user ACL associated with the packet, the interface ACL will be applied.

• The per-user ACL is governed by the timeout value specified by the uauth option of the timeout command but it can be overridden by the AAA per-user session timeout value.

• Existing ACL log behavior will be the same. For example, if user traffic is denied because of a per-user ACL, syslog message 109025 will be logged. If user traffic is permitted, no syslog message is generated. The log option in the per-user access-list will have no effect.

By default, VPN remote access traffic is not matched against interface ACLs. However, if you use the no sysopt connection permit-vpn command to turn off this bypass, the behavior depends on whether there is a vpn-filter applied in the group policy and whether you set the per-user-override option:

• No per-user-override , no vpn-filter —Traffic is matched against the interface ACL.

• No per-user-override , vpn-filter —Traffic is matched first against the interface ACL, then against the VPN filter.

• per-user-override , vpn-filter —Traffic is matched against the VPN filter only.

Note

If all of the functional entries (the permit and deny statements) are removed from an ACL that is referenced by one or more access-group commands, the access-group commands are automatically removed from the configuration. The access-group command cannot reference empty ACLs or ACLs that contain only a remark.

Usage Guidelines for Global Rules

The access-group global command applies a single set of global rules on all traffic, no matter which interface the traffic arrives at the ASA.

All global rules apply only to traffic in the ingress (inbound) direction. Global rules are not applied to egress (outbound) traffic. If global rules are configured in conjunction with inbound interface access rules, then the interface access rule, which is specific, is processed before the global access rule, which is general.

Usage Guidelines

If you configure the log option for an ACL deny statement, and a traffic flow matches the ACL statement, the appliance caches the flow information. To prevent cache overload, there is a maximum number of cached deny flows that will be kept for the statistics shown in syslog message 106100. If the maximum is reached before issuing 106100 and resetting the cache, syslog message 106101 is issued to indicate that the deny flow maximum was exceeded.

The access-list alert-interval command sets the time interval for generating syslog message 106101. When the deny flow maximum is reached, another syslog message 106101 is generated if at least secs seconds have passed since the last syslog message 106101 was generated.

See the access-list deny-flow-max command for information about the deny flow maximum message generation.