AAA Implementation on the Concentrator
As mentioned in the introduction, AAA can be implemented on a VPN 3000 Concentrator for two purposes:
VPN concentrator management
Tunnel group and user authentication (X-Auth)
The sections that follow describe each of these purposes in detail.
VPN Concentrator Management
Just as with other Cisco devices such as router, Private Internet Exchange (PIX), etc., the VPN concentrator can be managed using TACACS+ (Terminal Access Controller Access Control System) protocols. The authorization feature allows the VPN 3000 Concentrator to download certain privilege levels from the AAA Server.
Tunnel Group and User Authentication
Both Tunnel Group and User can be authenticated with the RADIUS server or locally on the VPN 3000 Concentrators for IPsec VPN connection. You can also authenticate the Tunnel Group on the VPN 3000 Concentrators, and perform user authentication on the RADIUS server or vice versa. So, it's important to understand the sequence of events that occurs on the VPN 3000 Concentrator for Tunnel Group and user authentication when the VPN client connects to the VPN 3000 Concentrator. The following steps outline the sequence of events:
1. At Phase I of the IPsec tunnel negotiation of the Remote Access VPN connection request, the VPN client sends the group name (also called tunnel group) and password to the VPN 3000 Concentrator. If the group is configured internally, the VPN 3000 Concentrator validates the group name/password against its internal database. If the group is configured externally, the VPN 3000 Concentrator tries to authenticate the group name and password against an external server, for example, Cisco Secure Access Control Server (CS ACS), Microsoft Active Directory (Microsoft AD) and so on. If the group name and password are invalid, you receive this error message: Unable to negotiate IPsec. You can see the error in the event log with debug (1-9) turned on for AUTH, AUTHDBG, AUTHDECODE, IPSEC, IPSECDBG, and IPSECDECODE.
2. If the group name is valid, the Group is authenticated via RADIUS if the password for the Group is stored on the RADIUS Server. The RADIUS server can return many attributes for the group or none at all. At a minimum, the RADIUS server should return the Cisco/Altiga attribute "IPsec Authentication = RADIUS" to tell the concentrator how to authenticate the user. If not, the base group's IPsec Authentication method should be set to "RADIUS." Otherwise, the local user authentication on the VPN 3000 Concentrator will occur.
3. Once the group is authenticated and gets attributes from the Radius Server, the VPN client is asked to enter a username and password. If the group is authenticated locally, the concentrator obtains configuration information such as whether the user should be authenticated against the internal or external database. If authentication was accomplished through the RADIUS server, the concentrator gets this information as a reply attribute. In either case, if the group attribute indicates that the user should be authenticated against an internal server, the concentrator will see if the user is defined internally and will try to authenticate. If the user's authenticity is to be tested against an external server, the concentrator forwards that user's name and password information to the external database, such as a Cisco Secure ACS as configured on the concentrator.
4. If the user is authenticated via RADIUS, the RADIUS server can return many attributes for the user or none at all. If the RADIUS server returns the attribute CLASS (standard RADIUS attribute #25), the VPN 3000 Concentrator uses that attribute as a group name and moves to Step 6, or else it goes to Step 7.
5. If the authentication method in the group is set to NONE, the client machine is not prompted to enter its username and password, and the client machine can establish a tunnel via group name and password only.
6. (Optional) If the user is part of another group, this group is authenticated next. If the user does not belong to another group or the tunnel group, the user defaults to the base group and this step does not occur.
7. The tunnel group from Step 1 is authenticated again. (This is done in case the Group Lock feature is being used. This feature is available in version 2.1 or later.) If the Group Lock feature is turned on in the tunnel group and user belongs to a different group, then authentication fails at this stage.
8. If the user is successfully authenticated, the concentrator pushes down the mode configuration to the client machine. Mode configuration includes network lists, banners, assignment of IP addresses, and so on. If the client connection hangs at this point with just "Negotiating IPsec policy" and never establishes a connection, you need to check these logs: IKE, IKEDBG, IKEDECODE (debug should be 1-9). If everything goes well, you should receive this message: "Your Link is now secure."
Once the VPN 3000 Concentrator has authenticated the user and group(s), it must organize the attributes it has received. The VPN Concentrator uses the attributes in the following order of preference, no matter if the authentication was done internally or externally:
User attributes These take precedence over all others.
Group attributes Any attributes missing from the user attributes are filled in by the group attributes. Any attributes that are the same are overridden by the user attributes.
Tunnel Group attributes Any attributes missing from the user or group attributes are filled in by the tunnel group attributes. Any attributes that are the same are overridden by the user attributes.
Base Group attributes Any attributes missing from the user, group, or tunnel group attributes are filled in by the base group attributes.