Our executive team finally approved the use of two-factor authentication for all virtual private network access into our corporate network. This means we'll get to overhaul the way we deploy our Cisco VPN infrastructure.
Currently, when a user requests virtual private network access, we provide the VPN software and a VPN profile that the user has to import into the VPN client.
The user then launches the VPN software, authenticates and is placed in a group that's defined within the Cisco Secure Access Control Server (ACS). As things now stand, all groups are configured to allow access to just about everything in the company.
This isn't very secure, of course, because a user within the sales organization, for example, has the ability to reach out to production Unix servers. Granted, if the server was configured properly, access would be denied if the user didn't have a valid account on the Unix server.
But if the server wasn't configured properly, a malicious user could gain unauthorized access. What's more, a malicious user who isn't barred from any part of the network could attempt any number of other activities, including denial-of-service and man-in-the-middle attacks. So, as we now move to strong two-factor authentication, we have an opportunity to tie down our systems much more securely.
In implementing two-factor authentication, we're using RSA Security's SecurID tokens, with corresponding access control provided by Cisco Systems Inc. The RSA SecurID token servers and associated tokens provide only for authentication; the tokens don't dictate which areas of the network an employee will have permission to access. This authorization piece is handled by the Cisco ACS.
With the ACS, groups of users are defined and then assigned specific networks or hosts that they can access.
For example, a contractor assigned as an auditor in the finance department doesn't need access to human resources systems. We can configure a group within the ACS and place in that group only the finance servers that the contractor will need to perform his job, plus some common areas of the network, such as the company Web site and the Exchange e-mail servers.
Once we've configured all of the groups we're going to need, it's just a matter of placing each user in the correct group. So, how do we do that? Manually entering thousands of users is too cumbersome and time-consuming to be an option. For this task, we'll turn to a directory server. We use Lightweight Directory Access Protocol for many functions within the company and have had great success with it.
Our LDAP environment is becoming more and more useful, allowing us to more easily handle chores such as storing user credentials or granting access-control rights for applications.
Duplicating Groups
In the case of this VPN project, we want to create the same groups within LDAP that we have defined for our Cisco ACS access groups. Once those groups exist within LDAP, a help desk administrator responding to an approved and verified request for VPN access can simply call up a Web-based account-provisioning dashboard and mark a checkbox for the appropriate access group.
After that, when the user launches his VPN client and authenticates with the SecurID token, the Cisco ACS will first look to see if the user exists within the ACS. If the user can't be found there, the ACS will go out to our LDAP server to see if he exists there.
If the user is found in the LDAP server and has been assigned to a corresponding access group, then he will be added to the ACS and placed in the appropriate access group. And if the user isn't found in the LDAP server, then he can be assigned to a default restrictive group.
I know this seems like a lot of transactions, but in practice, it should take only a couple of seconds. The only difficulty we're having is that the current incarnation of the Cisco ACS has some restrictions on how it can interoperate with LDAP. Once those issues are resolved, we can move forward with the proposed architecture.
We've decided that instead of providing our users with the hardware security tokens, we will deploy software tokens. The software tokens are installed on users' PCs and provide the same level of security as the hardware tokens. The software, combined with a unique "seed" file and a user-configured PIN, provides for two-factor authentication.
The software frees users from having to carry a token with them, but the problem is that the software tokens aren't as user-friendly as the hardware tokens.
With the hardware tokens, a user inserts his PIN, directly followed by the number displayed on the token, which becomes his passcode.
With the software token, when the user keys in his PIN, the token presents a passcode, which the user has to copy and paste from within the token to the application he's accessing.
The software tokens have other advantages, since they are considerably cheaper and can be mass-deployed more easily than the hardware -- we just provide Web links and use provisioning software.
One more thing: There's a nice integration feature when using the Cisco VPN product with the RSA software tokens. When the user accesses the VPN, he's prompted only for his PIN, and on the back end, the software automatically fills in the appropriate token code from the RSA software.
So for now, we'll continue to define our access groups and come up with a work-around for getting users from LDAP to the Cisco ACS.