This document describes how Cisco VPN Clients are authenticated on the
VPN Concentrator and how the Cisco VPN 3000 Concentrator uses User and Group
There are no specific requirements for this document.
The information in this document is based on the Cisco VPN 3000
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
For more information on document conventions, refer to the
Technical Tips Conventions.
When a VPN Client connects to a VPN 3000 Concentrator, up to four
authentications can take place.
The Group is authenticated. (This is often called the "Tunnel
The User is authenticated.
(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, then the user defaults to the Base Group and this step does NOT occur.
The "Tunnel Group" from Step 1 is authenticated again. (This is done
in case the "Group Lock" feature is used. This feature is available in version
2.1 or later.)
This is an example of the events you see in the Event Log for a VPN
Client authenticated via the Internal Database ( "testuser" is part of the
1 12/09/1999 11:03:46.470 SEV=6 AUTH/4 RPT=6491 18.104.22.168
Authentication successful: handle = 642, server = Internal, user = Tunnel_Group
2 12/09/1999 11:03:52.100 SEV=6 AUTH/4 RPT=6492 22.214.171.124
Authentication successful: handle = 643, server = Internal, user = testuser
3 12/09/1999 11:03:52.200 SEV=6 AUTH/4 RPT=6493 126.96.36.199
Authentication successful: handle = 643, server = Internal, user = Engineering
4 12/09/1999 11:03:52.310 SEV=6 AUTH/4 RPT=6494 188.8.131.52
Authentication successful: handle = 643, server = Internal, user = Tunnel_Group
Note: To see these Events, you must configure the Auth Event Class with
severity 1-6 in Configuration > System
> Events > Classes.
Group Lock Feature - If the Group Lock feature is
enabled on the Group - Tunnel_Group, then the User must be part of Tunnel_Group
to connect. In the previous example, you see all the same Events, but
"testuser" does not connect because they are part of the Group - Engineering
and not part of the Group - Tunnel_Group. You also see this Event:
5 12/09/1999 11:35:08.760 SEV=4 IKE/60 RPT=1 184.108.40.206
User [ testuser ]
User (testuser) not member of group (Tunnel_Group), authentication failed.
For additional information about the Group Lock feature and a sample
configuration, refer to
Users into a VPN 3000 Concentrator Group Using a RADIUS Server.
The VPN 3000 Concentrator can also be configured to authenticate Users
and Groups externally through a RADIUS server. This still requires the names of
the Groups to be configured on the VPN Concentrator, but the Group Type is
configured as "External."
External Groups can return Cisco/Altiga attributes if the RADIUS
server supports Vendor Specific Attributes (VSAs).
Any Cisco/Altiga attributes NOT returned by RADIUS default to the
values in the Base Group.
If the RADIUS server does NOT support VSAs, then ALL attributes
default to the Base Group attributes.
Note: A RADIUS server treats Group names no differently than User names. A
Group on a RADIUS server is configured just like a standard User.
These steps outline what happens when an IPSec Client connects to the
VPN 3000 Concentrator if both Users and Groups are authenticated externally.
Similar the internal case, up to four authentications can take place.
The Group is authenticated via RADIUS. The RADIUS server can return
many attributes for the group or none at all. At a minimum, the RADIUS server
needs to return the Cisco/Altiga attribute "IPSec Authentication = RADIUS" to
tell the VPN Concentrator how to authenticate the User. If not, the Base
Group's IPSec Authentication method needs to be set to "RADIUS."
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 3, or else it goes to Step 4.
The user's Group is authenticated next via RADIUS. The RADIUS server
can return many attributes for the group or none at all.
The "Tunnel Group" from Step 1 is authenticated again via RADIUS. The
authentication subsystem must authenticate the Tunnel Group again because it
has not stored the attributes (if any) from the authentication in Step 1. This
is done in case the "Group Lock" feature is used.
After 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 this order of preference. It does not matter if the
authentication was done internally or externally:
User attributes—These take precedence over all
Group attributes—Any attributes missing from the
User attributes are filled in by the Group attributes. Any 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
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