Overview:
The general design uses the Altiga box to facilitate user connections
and group definitions, and the SecureID box for individual user account
definitions and authentication. There are two major devices discussed
here. The first is the Altiga/Cisco 3005 VPN Concentrator which will
be referred to as concentrator hereafter, and the RSA SecureID ACE server
which will be referred to as the ACE server hereafter.
The order of operations for authentication are as follows:
1. The user installs a VPN client on their PC. At this time the users concentrator group is identified and a password is given to the client for that group.Details follow.
2. User connects to the concentrator. The concentrator checks to see what group they are assigned to and asks for a userid and a passcode.
3. Concentrator checks presented information against the ACE server which will allow or deny access based on authentication information.
4. If allowed in, concentrator will provide routing information based on the users assigned group.
5. Host based access is based on groups assigned to each users ACE server account.
Altiga/Cisco 3005 VPN Concentrator Groups
On the VPN Concentrator there are a series of groups which define the
routing information presented to the client. A user is assigned to
one of these groups when the VPN client is installed on their desktop.
These groups include:
sfoAdmin : direct access to all routing data including production facilitysThere is a clear crossover between slcUser and svUser, but I have differentiated the user pools for possible later modifications for reasons that are not now apparent.
sfoUser : access to sfo routes
slcUser : access to slc routing information (via Firewall VPN) and sv routing information
svUser : access to sv routing information (via Firewall VPN) and slc routing information
internalUser : emergency account with local password in case of ACE server failure
It is important to note that the purpose of these groups is to limit the routing information available to the client and to set the location of the user database to the ace server. They have in no way any influence on the ace server group identities which are assigned upon authentication.
Once the client initially contacts the concentrator, the users group is authenticated. This is done based on the cached password located on the client software, and the user has no influence on this after the initial install. When this authentication is complete, the concentrator identifies that the user is a member of an ACE authenticated group and they are asked for a userid and passcode. This is gathered and presented to the ACE server for user authentication.
ACE Server Details
The function of the ACE server in this design is twofold. First
it is used to authenticate the incoming connections of users. In
this function it simply returns a yes or no to the possible authentication
attempt.
The second function is used for local host authentication once a user
is on the local network. The design of this is based on a series
of groups that users are placed into when their ACE account is created.
These group(s) that each user is placed in are assigned to each host based
on that host's function. The list of ace groups are as follows:
|
|
|
| sfoUnix | Any secure unix host on sfo lan |
| sfoNt | Test group for production access control |
| sfoCisco | Access control for local cisco devices |
| sfoFirewall | Firewall access |
| interconnectCisco | Group for cisco devices used for interconnect access |
| fgWestDynamo | Production Dynamo servers |
| fgWestDatabase | Production database servers |
| fgWestNt | Production NT servers |
| fgWestCisco | All production Cisco devices |
| fgWestFirewall | All production firewall access |
| fgWestWeb | Production web servers |
| fgWestIds | Production IDS access |
| fgWestAce | Access to ace servers |
| sfoUser | sfo account for remote access with no machine access |
| svUser | sv user account for remote access with no machine access |
| slcUSer | slc user account for remote access with no machine access |
For example, a sfo systems administrator who requires access to remote access, local systems and production database boxes would be a member of the following groups: sfoUser, sfoUnix, fgWestDatabase. As their requirements for access was increased, there account could be added to whatever group is necessary.
On the host where access is being limited, we set up a client identifier
on the ACE system. For example we would set one up for anxFirewall1.
Into this client account we would assign the fgWestFirewall group.
When a user authenticates themselves against a host, the ace server checks
to see if that user is a member of an appropriately assigned group for
that action. If so, the user still must have a working account on
the box (user id and password) along with the ACE id and passcode
information. An example of this transaction is as follows:
clienthost:/tmp> telnet gilgamesh
Trying 10.10.10.12...
Connected to gilgamesh.
Escape character is '^]'.
SunOS 5.8
login: ace
Password: ##########
No directory! Logging in with home=/
Last login: Tue Dec 5 16:29:51 from gilgamesh
Enter PASSCODE:
PASSCODE Accepted
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
$
For this additional layer of authentication to be available, several
things must have taken place:
The host (gilgamesh) must be recognized as a client of the ACE servers
The host (gilgamesh) must have client software in place identifying the ACE server
The user (ace) must have their shell changed to sdshell