Cisco ASA Authentication, Authorization, and Accounting Network Security Services
- AAA Protocols and Services Supported by Cisco ASA
- Defining an Authentication Server
- Configuring Authentication of Administrative Sessions
- Authenticating Firewall Sessions (Cut-Through Proxy Feature)
- Configuring Authorization
- Configuring Accounting
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the following topics:
- AAA protocols and services supported by Cisco ASA
- Defining an authentication server
- Authenticating administrative sessions
- Configuring authorization
- Configuring downloadable ACLs
- Configuring accounting
- Troubleshooting AAA
This chapter provides a detailed explanation of the configuration and troubleshooting of authentication, authorization, and accounting (AAA) network security services that Cisco ASA supports. AAA offers different solutions that provide access control to network devices. The following services are included within its modular architectural framework:
- Authentication—The process of validating users based on their identity and predetermined credentials, such as passwords and other mechanisms like digital certificates.
- Authorization—The method by which a network device assembles a set of attributes that regulates what tasks the user is authorized to perform. These attributes are measured against a user database. The results are returned to the network device to determine the user's qualifications and restrictions. This database can be located locally on Cisco ASA or it can be hosted on a RADIUS or Terminal Access Controller Access-Control System Plus (TACACS+) server.
- Accounting—The process of gathering and sending user information to an AAA server used to track login times (when the user logged in and logged off) and the services that users access. This information can be used for billing, auditing, and reporting purposes.
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 6-1 shows the different methods and the functionality that each protocol supports.
Table 6-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 |
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 6-1 with the following services:
- Virtual private network (VPN) user authentication
- Administrative session authentication
- Firewall session authentication (cut-through proxy)
Table 6-2 outlines the support for the authentication methods in correlation to the specific services.
Table 6-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 |
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 6-3 shows the authorization support matrix.
Table 6-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 |
Accounting is supported by RADIUS and TACACS+ servers only. Table 6-4 shows the Cisco ASA accounting support matrix.
Table 6-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.
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 6-1 illustrates how this process works.
)
Figure 6-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 6-1:
- Step 1. A user attempts to connect to the Cisco ASA (i.e., administration, VPN, or cut-through proxy).
- Step 2. The Cisco ASA prompts the user, requesting a username and password. The user sends his or her credentials to the Cisco ASA.
- Step 3. The Cisco ASA sends the authentication request (Access-Request) to the RADIUS server.
- Step 4. 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).
- Step 5. The Cisco ASA responds to the user and allows access to the specific service.
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.
The RADIUS servers can also proxy authentication requests to other RADIUS servers or other types of authentication servers. Figure 6-2 illustrates this methodology.
)
Figure 6-2 RADIUS Server Acting as Proxy to Other Authentication Servers
In Figure 6-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 an 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 is allowed. If authorization is required, the authorization process begins at this point.
- REJECT—User authentication is denied. The user may be prompted to retry authentication, depending on the TACACS+ server and NAS.
- ERROR—A certain error takes 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 enables the use 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 physical devices called tokens that provide users with an OTP that changes every 60 seconds. These OTPs are generated when a user enters a personal identification 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 6-3 demonstrates how this solution works when a user attempts to connect to the Cisco ASA using the Cisco VPN Client software.
)
Figure 6-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 6-3:
- Step 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 Security Technologies.")
- Step 2. The Cisco ASA prompts the user for authentication via X-Auth (extended authentication). The user provides a username and passcode. (X-Auth is also covered in Chapter 17, "IPSec Remote Access VPNs.")
- Step 3. The Cisco ASA forwards the authentication request to the SDI server.
- Step 4. 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.
- Step 5. The Cisco ASA prompts the user for a new PIN.
- Step 6. User enters new PIN.
- Step 7. The Cisco ASA sends the new PIN information to the SDI server.
Microsoft Windows NT
Cisco ASA supports Windows NT native authentication only for VPN remote-access connections. It communicates with the Windows NT server via 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. Kerberos is an authentication protocol created by the Massachusetts Institute of Technology (MIT) that provides mutual authentication used by many vendors and applications. 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 via UDP port 88. Configuration and troubleshooting of remote access VPN tunnels are covered in Chapter 16, "Site-to-Site IPSec VPNs."
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.
HTTP Form Protocol
The Cisco ASA supports single sign-on (SSO) authentication of WebVPN users, using the HTTP Form protocol. The SSO feature is designed to allow WebVPN users to enter a username and password only once while accessing WebVPN services and any web servers behind the Cisco ASA.