AAA Protocols and Services Supported by Cisco ASA

Cisco ASA can be configured to maintain a local user database or to use an external server for authentication. The following are the AAA authentication underlying protocols and servers that are supported as external database repositories:

• RADIUS
• TACACS+
• RSA SecurID (SDI)
• Windows NT
• Kerberos
• Lightweight Directory Access Protocol (LDAP)

Table 7-1 shows the different methods and the functionality that each protocol supports.

Table 7-1. AAA Support Matrix

Method	Authentication	Authorization	Accounting
Internal server	Yes	Yes	No
RADIUS	Yes	Yes	Yes
TACACS+	Yes	Yes	Yes
SDI	Yes	No	No
Windows NT	Yes	No	No
Kerberos	Yes	No	No
LDAP	No	Yes	No

Note

Using an external authentication server in medium and large deployments is recommended, for better scalability and easier management.

Cisco ASA supports the authentication methods listed in Table 7-1 with the following services:

• Virtual private network (VPN) user authentication
• Administrative session authentication
• Firewall session authentication (cut-through proxy)

Table 7-2 includes the support for the authentication methods in correlation to the specific services.

Table 7-2. Authentication Support Services

Service	Local	RADIUS	TACACS+	SDI	Windows NT	Kerberos
VPN users	Yes	Yes	Yes	Yes	Yes	Yes
Administration	Yes	Yes	Yes	No	No	No
Firewall sessions	Yes	Yes	Yes	No	No	No

Note

Cisco ASA VPN user authentication support is similar to the support provided on the Cisco VPN 3000 Series Concentrator.

As previously mentioned, the authorization mechanism assembles a set of attributes that describes what the user is allowed to do within the network or service. Cisco ASA supports local and external authorization depending on the service used. Table 7-3 shows the authorization support matrix.

Table 7-3. Authorization Support

Service	Local	RADIUS	TACACS+	SDI	NT	Kerberos	LDAP
VPN users	Yes	Yes	No	No	No	No	Yes
Administration	Yes	No	Yes	No	No	No	No
Firewall sessions	No	No	Yes	No	No	No	No

Note

Local authorization for administrative sessions can be used only for command authorization.

Note

Cisco ASA does not support RADIUS command authorization for administrative sessions because of limitations in the RADIUS protocol.

Accounting is supported by RADIUS and TACACS+ servers only. Table 7-4 shows the Cisco ASA accounting support matrix.

Table 7-4. Accounting Support

Service	Local	RADIUS	TACACS+	SDI	NT	Kerberos	LDAP
VPN users	No	Yes	Yes	No	No	No	No
Administration	No	Yes	Yes	No	No	No	No
Firewall sessions	No	Yes	Yes	No	No	No	No

The following subsections introduce each of the authentication protocols and servers that Cisco ASA supports.

RADIUS

RADIUS is a widely implemented authentication standard protocol that is defined in RFC 2865, "Remote Authentication Dial-In User Service (RADIUS)." RADIUS operates in a client/server model. A RADIUS client is usually referred to as a network access server (NAS). A NAS is responsible for passing user information to the RADIUS server. Cisco ASA acts as a NAS and authenticates users based on the RADIUS server's response.

Note

Cisco ASA supports several RADIUS servers, such as the following:

• CiscoSecure ACS for NT
• CiscoSecure ACS for UNIX
• Cisco Access Registrar
• Livingston
• Merit
• Funk Steel Belted
• Microsoft Internet Authentication Server

These are some of the most commonly deployed RADIUS server vendors. Support and testing with other servers is a continuous effort between vendors.

The RADIUS server receives user authentication requests and subsequently returns configuration information required for the client (in this case, the Cisco ASA) to support the specific service to the user. The RADIUS server does this by sending Internet Engineering Task Force (IETF) or vendor-specific attributes. (RADIUS authentication attributes are defined in RFC 2865.) Figure 7-1 shows how this process works.

Figure 7-1. Basic RADIUS Authentication Process

In this example, a Cisco ASA acts as a NAS and the RADIUS server is a Cisco Secure Access Control Server (ACS). The following sequence of events is shown in Figure 7-1:

1. A user attempts to connect to the Cisco ASA (i.e., administration, VPN, or cut-through proxy).
2. The Cisco ASA prompts the user, requesting his username and password.
3. User sends his or her credentials to the Cisco ASA.
4. The Cisco ASA sends the authentication request (Access-Request) to the RADIUS server.
5. The RADIUS server sends an Access-Accept message (if the user is successfully authenticated) or an Access-Reject (if the user is not successfully authenticated).
6. The Cisco ASA responds to the user and allows access to the specific service.

Note

The RADIUS server can also send IETF or vendor-specific attributes to the Cisco ASA depending on the implementation and services used. These attributes can contain information such as an IP address to assign the client and authorization information. RADIUS servers combine authentication and authorization phases into a single request and response communication cycle.

The Cisco ASA authenticates itself to the RADIUS server by using a preconfigured shared secret. For security reasons, this shared secret is never sent over the network.

Note

Passwords are sent as encrypted messages from the Cisco ASA to the RADIUS server. This is useful to protect this critical information from an intruder. The Cisco ASA hashes the password using the shared secret that is defined on the Cisco ASA and the RADIUS server.

The RADIUS servers can also proxy authentication requests to other RADIUS servers or other types of authentication servers. Figure 7-2 illustrates this methodology.

Figure 7-2. RADIUS Server Acting as Proxy to Other Authentication Server

In Figure 7-2, RADIUS Server 1 acts as a proxy to RADIUS Server 2. It sends the authentication request from the Cisco ASA to RADIUS Server 2 and proxies the response back to the ASA.

TACACS+

TACACS+ is a AAA security protocol that provides centralized validation of users who are attempting to gain access to NASs. The TACACS+ protocol offers support for separate and modular AAA facilities. The TACACS+ protocol's primary goal is to supply complete AAA support for managing multiple network devices.

TACACS+ uses port 49 for communication and allows vendors to use either User Datagram Protocol (UDP) or TCP encoding. Cisco ASA uses the TCP version for its TACACS+ implementation.

The TACACS+ authentication concept is similar to RADIUS. The NAS sends an authentication request to the TACACS+ server (daemon). The server ultimately sends any of the following messages back to the NAS:

• ACCEPT User has been successfully authenticated and the requested service will be allowed. If authorization is required, the authorization process will begin at this point.
• REJECT User authentication was denied. The user may be prompted to retry authentication depending on the TACACS+ server and NAS.
• ERROR A certain error took place during authentication. This can be experienced because of network connectivity problems or a configuration error.
• CONTINUE User is prompted to provide further authentication information.

After the authentication process is complete, if authorization is required, the TACACS+ server proceeds with the authorization phase. The user must first successfully be authenticated before proceeding to TACACS+ authorization.

RSA SecurID

RSA SecurID (SDI) is a solution provided by RSA Security. The RSA ACE/Server is the administrative component of the SDI solution. It provides the usage of one-time passwords (OTPs). Cisco ASA supports SDI authentication natively only for VPN user authentication. However, if it is using an authentication server, such as CiscoSecure ACS for Windows NT, the server can use external authentication to an SDI server and proxy the authentication request for all other services supported by Cisco ASA. Cisco ASA and SDI use UDP port 5500 for communication.

The SDI solution uses small devices called tokens that provide users with an OTP that changes every 60 seconds. These OTPs are generated when a user enters a pin number and are synchronized with the server to provide the authentication service. The SDI server can be configured to require the user to enter a new pin when trying to authenticate. This process is called new pin mode, which Cisco ASA supports. Figure 7-3 demonstrates how this solution works when a user attempts to connect to the Cisco ASA using the Cisco VPN Client software.

Figure 7-3. SDI Authentication Using New Pin Mode

The purpose of new pin mode is to allow the user to change its PIN for authentication. The following sequence of events occurs when using SDI authentication with the new pin mode feature, as shown in Figure 7-3:

1. The user attempts to establish a VPN connection with the Cisco VPN client and negotiates IKE Phase 1. (Complete information about IKE and IPSec negotiations is provided in Chapter 1, "Introduction to Network Security.")
2. The Cisco ASA prompts the user for authentication via X-Auth (extended authentication)
3. The user provides its username and passcode. (X-Auth is also covered in Chapter 16, "Remote Access VPN.")
4. The Cisco ASA forwards the authentication request to the SDI server.
5. If new pin mode is enabled, the SDI server authenticates the user and requests a new PIN to be used during the next authentication session for that user.
6. The Cisco ASA prompts the user for a new PIN.
7. User enters new PIN.
8. The Cisco ASA sends the new PIN information to the SDI server.

Note

You can find more information about the RSA SecurID server at http://www.rsasecurity.com.

 

Microsoft Windows NT

Cisco ASA supports Windows NT native authentication only for VPN remote-access connections. It communicates with the Windows NT server using TCP port 139. Similarly to SDI, you can use a RADIUS/TACACS+ server, such as CiscoSecure ACS, to proxy authentication to Windows NT for other services supported by Cisco ASA.

Active Directory and Kerberos

Cisco ASA can authenticate VPN users via an external Windows Active Directory, which uses Kerberos for authentication. It can also communicate with a Unix/Linux-based Kerberos server. Support for this authentication method is available for VPN clients only. Cisco ASA communicates with the Active Directory and/or a Kerberos server using UDP port 88. Configuration and troubleshooting of remote access VPN tunnels are covered in Chapter 16.

Lightweight Directory Access Protocol

Cisco ASA supports LDAP authorization for remote-access VPN connections only. The LDAP protocol is defined in RFC 3377, "Lightweight Directory Access Protocol (v3)," and RFC 3771, "The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message." LDAP provides authorization services when given access to a user database within a Directory Information Tree (DIT). This tree contains entities called entries, which consist of one or more attribute values called distinguished names (DNs). The DN values must be unique within the DIT.

Cisco ASA communicates with an LDAP server over TCP port 389.

Note

LDAP only provides authorization services. Consequently, a separate protocol is required for authentication services.