Migrating Passwords with Virtual Directories
When Does Password Migration Get Complicated?
LDAP Directories are the backbone of many enterprise IAM infrastructures, containing user data for authentication services. This user data contains sensitive information, such as passwords stored using various hashing methods. This often becomes a problem when migrating data from a legacy Directory Server to a newer Directory Server.
Migrating from a legacy Sun Directory Server to Oracle Directory Server (ODSEE) 11g or Oracle Unified Directory (OUD) 11g is fairly straightforward as far as user passwords go. They all use compatible hashing methods and, using replication, give a great deal of flexibility with data migration.
Password migration becomes more complicated when moving from another vendor Directory, such as eDirectory or Microsoft Active Directory. While the majority of user data can be extracted, sometimes with quite a bit of massaging to get it to conform to the schema, passwords may not be possible to migrate due to incompatible hashing methods. One solution is to migrate data without the password, requiring all users to change their password after ‘go live’ with the new Directory Server. This is not always an acceptable solution to the business, but a ‘seamless’ solution must be found.
Another more attractive solution is using an LDAP Proxy Server, such as Oracle Virtual Directory (OVD) or OUD’s proxy server functionality. LDAP Proxy Servers, often referred to as Virtual Directories, can intercept LDAP requests and perform operations with custom Java plugins. These plugins can be used as a method to intercept bind requests and migrate passwords from one Directory to another.
The above diagram shows a simple flow of such a process.
The LDAP client performs its normal bind operation during authentication.
The proxy server intercepts the bind request, which contains the username and password. The plugin performs a search for that user, checking for a custom attribute that is defined (such as passwordMigrated). If the password has been migrated, a normal bind is performed, which attempts to authenticate the user.
If the password has not been migrated, the Proxy server will attempt to bind to the legacy LDAP server using the user’s credentials.
If the bind attempt is successful, the plugin has the correct password and writes that password into the new LDAP Server and updates the passwordMigrated attribute, returning a successful authentication to the client.
One caveat to keep in mind is performance. LDAP Directory Servers are designed to deliver high performance, especially in regards to authentication requests. Adding an additional layer to intercept requests does add in a bit of overhead. While this can be negligible and not apparent to an end user in a smaller environment, a larger environment with high throughput can experience some noticeable overhead. It is important to architect the Proxy Server layer accordingly. Proxy servers typically cannot process the same throughput as backend Directory Servers. This can be achieved by horizontally scaling the Proxy Server layer, if necessary.
This solution will migrate passwords with a ‘frictionless experience’ to the end user. This is generally an interim solution for a specified period of time to capture the majority of users until the legacy system is retired. Users that do not perform an authentication during this time will need to change their password after it is removed.
Hub City Media has implemented this method and many other virtual Directory solutions. Please contact us to schedule a discovery session.