CHapter 10 AAA Overview
In access control, the admin controls the user’s access into the node, controls what the user can access in the node, and also monitors the actions made by the user in the node. Authentication, authorization, and accounting (AAA) is a framework through which you can achieve this control to access the node. It is important to understand each component of AAA and its uses. This type of access to the network/security nodes and access to the resources in the node gives a profile to the user. Each user can have different access rights. The user profile is maintained in an external database or the local database of a device. When controlling access to a large number of network/security devices, the common practice is to use an external database and have a backup single user profile in the local database. This backup single user profile is used for fallback purposes. Communication between FWSM and the external database server is achieved through security protocols, such as TACACS+ or RADIUS.
Understanding AAA Components
It is very important to understand the three AAA components and their functions.
Authentication in FWSM
Authentication allows the user to access the network node through password dialog. This password dialog for user access is also an encrypted session, depending on the type of security protocol chosen. Authentication can be done through a centralized server, or it can be done locally (based on the configuration of the local database).
The FWSM can authenticate management commands, network access, and virtual private network (VPN) management access. When a user accesses the FWSM, the user sends its username and password to the FWSM. The FWSM forwards this username and password to the external server and communicates to the external server using RADIUS or TACACS+. The choice of the security protocol used depends on the configuration at the FWSM.
In case of local authentication, the FWSM compares the username/password given by the user with the configured username and password in the FWSM. If the credentials match, the access is allowed. If not, access is denied.
For authentication of traffic between the security zones, the traffic has to match the authentication statement configured in the FWSM. Based on the match criteria, the traffic is sent to the external server for authentication, and then the user is allowed to access a different security zone.
Authorization in FWSM
Authorization works by identifying the set of attributes that the user is authorized to perform after getting access to the node through the authentication process. These attributes can be present locally in the FWSM or in a database server for the user profile. Authorization defines what a user can access in the node after the authentication is successful. The FWSM supports the authorization request for each user and caches the first 16 authorization requests per user.
If the user accesses the same service during the current authentication session, the FWSM does not resend the same request to the authorization server.
The server sends the user credentials, and the user is granted access to services as per the profile. For a local database, the FWSM checks the local configuration to verify the access rights for the user to access different services.
Accounting in FWSM
Accounting allows the network administrator to monitor the services the user’s access at the FWSM, after being authenticated to the node. Security protocols such as TACACS+ or RADIUS are used.
In accounting, user traffic that passes through the FWSM can be tracked. A per-user accounting is possible if accounting is enabled. The following information is included in accounting:
• Traffic Internet Protocol (IP) address
• Duration of each session
• Session start and stop
• Username
• Service type
Accounting will have a record of user profiles having access and authorization rights to the device. This is an important component for auditing. Only after authentication is established can authorization or accounting work. Authorization and accounting need not be configured for authentication to work.
Comparing Security Protocols
The two prominent security protocols used in the industry are RADIUS and TACACS+. RADIUS is defined in RFC 2865 and TACACS+ is defined in RFC 1492.
RADIUS uses User Datagram Protocol (UDP), whereas TACACS+ uses Transmission Control Protocol (TCP). As you may know, TCP offers reliable connection, which is not offered in RADIUS. RADIUS offers some level of reliability but lacks the built-in reliability available in TCP used by TACACS+. Also note that RADIUS encrypts only passwords in the access-request packet from the client to the server, and the rest of the packet in RADIUS goes unencrypted.
TACACS+ encrypts the complete packet. The header field indicates whether the packet is encrypted. The unencrypted option in TACACS+ is used only for troubleshooting purposes. In a normal operation, the packet is completely encrypted. RADIUS combines the authentication and authorization in the access-accept packet sent by the RADIUS server. TACACS+ uses separate authentication and authorization. In this case, it is easy to decouple TACACS+. The administrator can use Kerberos for authentication and TACACS+ for authorization and accounting. TACACS+ provides multi-protocol support, which is not offered by RADIUS.
The FWSM provides RADIUS, TACACS+, Security Dynamics International (SDI, a solution provided by RSA SecurID), NT, Kerberos, Lightweight Directory Access Protocol (LDAP), and local database support. SDI, NT, Kerberos, and LDAP Server support are only for VPN-Management connection to the FWSM.
Table 10-1 summarizes the updated support of security protocols for AAA service offered by FWSM. Refer to the product documentation for FWSM on Cisco.com for new security protocol support based on newer code releases.
Table 10-1 FWSM Security Protocol Support for AAA Service
VPN in FWSM is available only for Management connections.
Firewall authorization in RADIUS is available only in user access lists received in radius authentication response.
The term “local” means the FWSM can use the configuration locally for AAA. This is manually configured in the FWSM.
Local authorization is available in command authorization for privileged mode.
Understanding Two-Step Authentication
Two-step authentication, also called two-factor authentication, is a process in which a user must authenticate twice. The common way the two-step authentication works is that the user knows the PIN or password and has a token generator. The user uses the PIN on the token generator to generate a random sequence of numbers. This number sequence is the password, which is a component of the user password and token card. The authenticating system deciphers the random number sequence to get the password and allows the user access rights.
Two-step authentication is supported by SDI protocol. The FWSM obtains the server list when the first user authenticates to the configured server. This can be either a primary or a replica. The FWSM then assigns priorities to each server on the list, and subsequent server selection is derived at random from those assigned priorities.
Two-step authentication is more secure than the single authentication method. Two-step access authentication is common in the VPN world.
Understanding Fallback Support
Configuration practice dictates having fallback support for all AAA configurations on FWSM. The fallback support helps when the external server is not reachable. In this case, the user will not be able to access the FWSM or AAA functionality for other service types. With the fallback method, the last resort for the user to get access to the FWSM is at the local database of the FWSM. For external server redundancy, you can have more than one external server. More servers can be configured in the FWSM for redundancy and is referred to as a list of servers. Under normal circumstances, the FWSM contacts the first server configured. If that fails, it will sequentially contact other servers in the list. If the network is down, the FWSM will continue to contact the server list until the network comes up. If fallback is configured, during network downtime the FWSM will use the local profile for fallback to authenticate, provided the username and password for the access matches the configured username and password in the FWSM.
The local database supports fallback for authentication, authorization, VPN authentication, and VPN authorization.
Configuring Fallback Authentication
To configure fallback authentication in the FWSM, perform the following steps in the FWSM:
Configuring Local Authorization
To configure local authorization in the FWSM, perform the following steps in the FWSM:
Step 1 | Configure the username and password. |
| username NOCENG password h0TuW5XCVyAHLsUN encrypted privilege 5 |
| Before enabling authorization, ensure that you have a local user with privilege level of 15. If this is not configured, you can be locked out of the enable syntax in the firewall. In Step 1, three usernames and passwords are configured with different privilege modes. |
Step 2 | Configure the enable password. |
| enable password cisco |
Step 3 | Enable privilege level. |
| privilege show level 5 command access-list |
| The user with privilege level 5 can have access only to show access-list and show arp commands. At privilege level 15, all the commands are available to the user. In lower privilege levels, only a few commands are available. If you want to restrict a user to a few commands, use a lower privilege level and allow only the commands that the user can access. |
To configure authorization with fallback in the FWSM, enter the following commands in the FWSM:
! This command enables TACACS+ protocol
aaa-server TACACS protocol tacacs+
aaa-server TACACS max-failed-attempts 3
aaa-server TACACS deadtime 10
!This command configures the inside security domain for the server, IP address
! of the server and timeout value
aaa-server TACACS (inside) host 10.1.1.149 timeout 10
!This command enables local authentication for telnet access
aaa authentication telnet console TACACS LOCAL
! This command enables local authentication for console access
aaa authentication enable console TACACS LOCAL
! This command enables local authorization
aaa authorization command LOCAL
Example 10-1 shows how to test the local authorization.
Example 10-1 Testing Local Authorization
The NOCENG user accesses the FWSM. The user is allowed to access only the show access-list command and cannot access any other command.
For the VPN authentication and authorization, the fallback method is specified in the authentication-server-group command with a LOCAL keyword.
The local authorization in the FWSM is similar to the Cisco IOS configuration for local authorization. This is used when two user groups need to have fallback profiles and different access rights after authentication.
Understanding Cut-Through Proxy in FWSM
In cut-through proxy, the firewall requires the user to authenticate before passing any traffic through the FWSM. Figure 10-1 shows how the cut-through proxy works.
Figure 10-1 Cut-Through Proxy
The high-level steps that describe cut-through proxy are as follows:
The cut-through proxy method significantly improves the performance in comparison to the traditional proxy server. In cut-through proxy, the firewall authenticates the user against TACACS+, RADIUS server, or the local database. After the authentication is complete, the traffic session flow is maintained between the source and destination. This is not the case with the traditional proxy server.
The cut-through proxy server concept is used in FWSM. The FWSM can authenticate the user at the application layer, and then authenticates against standard RADIUS, TACACS+, or the local database. After the FWSM authenticates the user, it shifts the session flow, and all traffic flows directly and quickly between the source and destination while maintaining session state information with any network access or any protocol. The first authentication prompt can be done through Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol over Secure Socket Layer (HTTPS), Telnet, or File Transfer Protocol (FTP) only.
Using these methods, the FWSM generates a user authentication prompt for authenticating the user. For HTTP authentication, the FWSM checks the Port Address Translation (PAT) configuration when a connection for port 80 is seen. The FWSM immediately gives the authentication prompt to the user based on the PAT entry.
Example 10-2 shows a configuration example of Telnet-based proxy for inside users of the demilitarized zone (DMZ). The Telnet authentication will be applicable for all users, and the authorization and accounting will be available for users accessing servers in 10.2.2.0/24 network subnet.
Example 10-2 Configuring Telnet-Based Proxy for DMZ Inside Users
The commands in Example 10-3 authenticate all inside HTTP traffic.
Example 10-3 Configuring Authentication for All Inside HTTP Traffic
Configuring Custom Login Prompts
You can configure local prompts only for FTP and HTTP traffic. For Telnet, you cannot configure the user-defined prompt. Use the following steps to configure custom login prompts:
Step 1 | To customize the login prompt: |
| FWSM(config)# auth-prompt prompt text |
Step 2 | When the user is accepted: |
| FWSM(config)# auth-prompt accept text |
Step 3 | When the user is rejected: |
| FWSM(config)# auth-prompt reject text |
| For example: |
| FWSM(config)# auth-prompt prompt Please enter your username and password |
It’s good to have custom login prompts to let the user know the result of the authentication process.
Using MAC Addresses to Exempt Traffic from Authentication and Authorization
Using this method, the FWSM can permit or deny authentication or authorization based on Media Access Control (MAC) addresses.
Follow the steps to configure MAC address for authentication and authorization:
Step 1 | Configure the MAC list. |
| FWSM(config)# mac-list id {deny | permit} mac macmask |
| For example: |
| FWSM(config)# mac-list test permit 0cb0.c0ad.0180 ffff.ffff.ffff |
Step 2 | Attach the MAC list to the AAA statement. |
| FWSM(config)# aaa mac-exempt match id |
| For example: |
| FWSM(config)# aaa mac-exempt match test |
The use of this feature is seen in IP phones, which cannot authenticate. For example, if you have an IP phone in a particular security zone that has authentication and authorization for cut-through proxy configured, you can use either the IP address to deny the list of subnets or you can use a MAC address–based filter for the specific phones or servers.
Summary
After reading this chapter, you will understand AAA components and the configuration of AAA in relation to the FWSM. Fallback support should be added when the AAA access solution for the FWSM is designed. You will know the difference between TACACS+ and RADIUS and the different security protocols supported in the FWSM. The concept of cut-through proxy is covered with configuration examples.