The RSA server's database can be synchronized with external Lightweight Directory Access Protocol (LDAP) directories such as AD. But currently, when we disable users from within AD, they aren't automatically removed from within the SecurID token database. Terminated users who have a token and the company's VPN client can gain access to our internal network. They may not have access to the Windows domain because their AD accounts have been terminated, but they are on the network nonetheless, and that's unacceptable from a security perspective. We have to configure our SecurID server to synchronize its user database with AD.

Syncing feeling

That task isn't trivial. If a mistake were made, we could completely wipe out or corrupt the SecurID database. Of course, we'll test this change in a lab environment and back up the existing database, but wiping out the database is still a scary thought. In addition, quite a bit of prep work has to be done. Because the synchronization process is tied to employees' usernames, we must ensure that the usernames within the SecurID database are identical to those in AD. Account reconciliation -- making sure that a single person isn't listed under different usernames -- takes time, especially with more than 5,000 users in the database. And when we find a user who has more than one username, we'll have to communicate our changes to the user in question.

The SecurID server offers a fair amount of flexibility in how we conduct the synchronization. We plan to run the synchronization so that regular employees will be automatically added to a SecurID group that grants them VPN access, while contractors, partners and other nonemployees will be added to a default group with no access. We'll be able to do this by configuring multiple LDAP synchronizations. Users properly registered in AD with a correct username will automatically gain access to the things they should gain access to. Partners, for example, will have SecurID access to the partner portal but not the VPN concentrator. And when the synchronization determines that a particular user no longer has an AD entry -- in other words, that the user is no longer an employee or some kind of partner -- then the user will automatically be deleted from within the Secur-ID server and his token will be placed back into the available token pool.

Once we extend the SecurID infrastructure to other areas, we will be able to conduct synchronizations to place, for example, network or Unix engineers in groups that give them SecurID access to the network or the server infrastructure.