Chapter 10. Troubleshooting AAA on PIX Firewalls and FWSM
The AAA implementation on PIX firewalls and Firewall Services Modules (FWSMs) is very similar to that on routers with very few exceptions. As of writing this text, the current version of PIX is 7.x, and the current version of FWSM is 2.3.x. The discussion in this chapter is based on PIX Version 7.x. Hence some of the features discussed in this chapter may not be supported on the FWSM Version 2.3.x, which is based on PIX code base 6.3.x. This difference will be pointed out throughout the chapter. The primary focus of this chapter is troubleshooting techniques on AAA, which is the same on both PIX and FWSM. The Case Study section of this chapter examines the feature called Virtual HTTP or Virtual Telnet that addresses some of the problems posed by the Cut-Thru Proxy. Finally, the chapter concludes with Best Practices.
Overview of Authentication, Authorization, and Accounting (AAA)
A thorough understanding of AAA architecture and two commonly used protocols (RADIUS and TACACS+) that support this architecture is a must. You need this knowledge to understand and troubleshoot AAA issues on the PIX firewall. Refer to Chapter 9, "Troubleshooting AAA on IOS Routers" under the section of the same title for details on this. The discussion in this chapter focuses on the perimeter of the PIX and FWSM domain.
PIX Firewall can be configured to support AAA for one of the following purposes:
- To manage administrative users These users connect to the firewall to make configuration changes or to monitor activity through the console, Telnet, Secure Shell (SSH), or the PIX Device Manager (PDM)/Adaptive Security Device Manager (ASDM) application.
- To manage Cut-Thru Proxy users The users of the Cut-Thru Proxy are the end users who make connections across the firewall. When the user first initiates a connection, the firewall intercepts the connection with an authentication challenge. If the user is successfully authenticated, that connection is allowed and with the cut-through proxy feature, the future connections are allowed without any additional interception.
- To mange VPN users (VPN is not supported on FWSM) The users of the Remote Access VPN connection perform extended authentication (X-Auth) in addition to the group authentication.
For the administrative, Cut-Through Proxy, and VPN users the following security services are available using AAA framework:
- Authentication Authentication involves identification of the user.
- Authorization Authorization involves what the user does. Although authentication is valid without authorization, authorization is not valid without authentication.
- Accounting Accounting involves actions the user took after login to the firewall or through the firewall.
More details discussion follow in the next few sections on AAA.
Authentication
A firewall can authenticate a user based on a generic password only, against its local user database, or against an external database server (for example, Cisco Secure ACS Server). Support for different authentication methods is based on the connections types. For example, administrative users' authentication can be done merely by requiring a password, whereas the cut-through proxy authentication requires either a local user or an external database where username and password can be configured.
For administrative users, when users log into a firewall, they are assigned a privilege level from 1 to 15. Note that privilege level 0 is available, but is not assigned to the administrative users. When users log in with just the password configured on the firewall, a default user name enable_1 is used and the user gets privilege level 1. However, when successfully entering into enable mode, that user gets privilege level 15.
Note
For SSH connection, if only a password is configured on the firewall for login, use pix as the username and password for login. If Telnet is used for authentication, use only the password for the Telnet login. For PDM/ASDM, leave the username field blank and use the password as configured on the PIX firewall.
To authenticate users based on an individual username (instead of default username enable_1), you can configure either a LOCAL user database or external server for authentication. You can assign different privilege levels to the user and control what commands users may be able to execute after login to the firewall. Privilege level is discussed in the "Authorization" section, which is discussed in the coming section.
For Cut-Through Proxy and Remote Access VPN connections, user authentication must be performed either by the LOCAL user database or by the external AAA server.
Note
Local User Authentication support was first introduced in PIX Firewall version 6.2.
Prior to version 7.0, PIX firewall authentication protocol support is limited to the local user database, TACACS+, and RADIUS protocol. The PIX Firewall Version 7.0 introduced few new client APIs that are used for different types of authentication servers.
Table 10-1 summarizes AAA support for different protocols based on PIX Firewall Version 7.0.
| Protocol | Authentication | Authorization | Accounting |
|---|---|---|---|
| Internal server | Yes | Yes | No |
| RADIUS | Yes | Yes | Yes |
| TACACS+ | Yes | Yes | Yes |
| SDI | Yes | No | No |
| NT | Yes | No | No |
| Kerberos | Yes | No | No |
| LDAP | No | Yes | No |
As you can see in Table 10-1, authentication is supported by different protocols with the exception of the LDAP database. Authentication for administrative users for PIX management, Remote Access VPN connection, and Cut-Through Proxy connections are not supported by every protocol. Table 10-2 shows the authentication support by different protocols based on PIX Version 7.0.
| Authentication of | LOCAL | RADIUS | TACACS | SDI | NT | Kerberos | LDAP |
|---|---|---|---|---|---|---|---|
| VPN users | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Administrators | Yes | Yes | Yes | No | No | No | No |
| Cut-Through | Yes | Yes | Yes | No | No | No | No |
We recommend strongly that you configure a fallback method so that you are not completely locked out from the PIX firewall if the AAA server is unavailable. AAA fallback was first introduced in PIX Firewall Version 6.3.4. This feature provides the ability for authentication and authorization requests to fall back on the local user database when the AAA server is unreachable. Fallback is available only with the LOCAL user database for firewall management connection (both authentication and authorization), and Remote Access VPN connection (only authentication).
You can configure fallback authentication for the authentication to login to PIX firewall with the following command:
[no] aaa authentication [serial|enable|telnet|ssh|http] console server-tag [LOCAL]
The LOCAL user database can be used as a fallback method for authentication for the Remote Access VPN connection. The syntax for configuring the LOCAL user database as a fallback method for Remote Access VPN connection is as follows:
[no] crypto map name set client authentication server-tag [LOCAL]
Authorization
On the firewall, authorization for different types of connections has different meanings. For example, authorization for an administrative session means being able to control what commands users can execute after login to the firewall, and authorization for Cut-Through Proxy controls what resources users can access after the authentication. For VPN Connection, authorization may control what traffic should be encapsulated and protected by the tunnel by using the split tunneling concept. Table 10-3 shows the authorization support by different protocols based on PIX version 7.0
| Authorization of | LOCAL | RADIUS | TACACS | SDI | NT | Kerberos | LDAP |
|---|---|---|---|---|---|---|---|
| VPN Users | Yes | Yes | No | No | No | No | Yes |
| Administrators | Yes | No | Yes | No | No | No | No |
| Cut-Through | No | Yes | Yes | No | No | No | No |
Use of Authorization for different connection types is explained in the following sections:
Authorization for an Administrative Session
Command authorization allows the firewall to control commands performed on the firewall by the users. Command Authorization is possible only when using a local user database or TACACS+ server (not with RADIUS). This feature is first introduced in PIX Version 6.2. Table 10-3 summarizes the support for authorization on different connections using various protocols on Version 7.0.
Command Authorization is performed based on the privilege level (0-15) if a local user database is used. Every administrative user is assigned a privilege level (1-15). Level 0 is not assigned to any administrative user. Every command on the firewall has a privilege level assigned to it. Levels 0 and 15 are default levels. Level 15 has every command available, but level 0 has a limited number of commands available.
Privilege levels for users are compared with the level of the command executed by users. If the privilege level of the command is at lower level or at the same level as the privilege level of a user, the command will be allowed; otherwise, the command will be denied. For example, if the user is at level 2 and the command you are executing is at privilege level 0, then the command execution will be allowed on the firewall.
As mentioned before, each firewall command has a privilege level associated with it. Some commands with arguments can be used in several different modes. Each of these is considered a separate command, having a unique privilege level. Therefore, the privilege levels are assigned according to the command arguments and the mode in which it is used.
Privilege level for the user is assigned by enable authentication. If the local regular enable password is used for authentication, the enable password can be configured locally with different privilege levels. If authentication is performed based on the RADIUS protocol, the enable password is the same as the login password, and all users are assigned privilege level 15. Therefore, authorization for an administrative session is not possible with the RADIUS server. If TACACS+ is used, the enable password can be configured the same as the login password, and the different privilege level (1-15) can be configured for the users. That privilege level can be used for command authorization. Additionally, the TACACS+ server can be configured to perform command authorization more flexibly than the local user database.
If an external AAA server is used, multiple AAA servers can be defined if one is unreachable. Beginning with PIX Version 6.3.4, in the backup method, LOCAL user database can be used in case all AAA servers are unreachable for command authorization.
Note
For administrative users using a local user database on the firewall, command authorization is done by privilege level only. When TACACS+ is used, the command authorization can be done using a combination of both privilege level and individual command definition, which provides more flexibility.
Authorization for Cut-Through Proxy Authorization for cut-through proxy is not possible with the local user databaseit is only possible with the TACACS+ and RADIUS protocols. With the cut-through proxy authorization, you can control what resources the end users can access after authentication. RADIUS protocol emulates authorization with the help of ACL. But the TACACS+ protocol performs authorization with command parsing and with the help of ACL.
Authorization for VPN Connection (X-Auth)
Authorization for Remote Access VPN connection is used to assign the DNS/WINS IP addresses and to download the ACL from the AAA Server using TACACS+ or the RADIUS protocol for the split tunneling. Local user database authorization is also possible in addition to the RADIUS and TACACS+ protocols, and LDAP server.
Accounting
The accounting for firewall administrative sessions is available only through syslog server in versions earlier than PIX Firewall Version 7.x. By default, all the syslog message IDs that are required for accounting are enabled. However, if you have edited the default Syslog ID settings, you need to ensure that the syslog Message IDs shown in Table 10-4 are enabled for the accounting for the administrative session.
| Syslog Message ID | Description |
|---|---|
| 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 |
Beginning with PIX 7.x, accounting packets can be generated and sent to the one or more AAA servers for the administrative session. This provides the ability to generate accounting records for tracking administrative access to PIX Firewall, and for tracking all configuration changes that are made during an administrative session.
Accounting records will not be generated for a command if the users execute the command at a higher level than the level at which it is configured on the PIX firewall.
Accounting for cut-through proxy and remote access VPN connection is possible with TACACS+ and RADIUS protocols. Accounting for both of these types of connections can log the connection activities to the AAA server. Table 10-5 summarizes accounting support by different methods on various protocols based on PIX Firewall Version 7.0.
| Accounting of | LOCAL | RADIUS | TACACS | SDI | NT | Kerberos | LDAP |
|---|---|---|---|---|---|---|---|
| VPN Connection | No | Yes | Yes | No | No | No | No |
| Administrative connections | No | Yes | Yes | No | No | No | No |
| Cut-Through Proxy | No | Yes | Yes | No | No | No | No |
More details on AAA can be found from the following release note at this URL:
You can find out the features introduced on different releases of PIX Firewall Version 6.3.x in the following location:
PIX 7.0 version features can be found in the following location:
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
