|< Day Day Up >|
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:
Table 7-1 shows the different methods and the functionality that each protocol supports.
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:
Table 7-2 includes the support for the authentication methods in correlation to the specific services.
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.
Local authorization for administrative sessions can be used only for command authorization.
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.
The following subsections introduce each of the authentication protocols and servers that Cisco ASA supports.
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.
Cisco ASA supports several RADIUS servers, such as the following:
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:
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.
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+ 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:
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 (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:
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.
LDAP only provides authorization services. Consequently, a separate protocol is required for authentication services.
|< Day Day Up >|