Best way to change from LDAP & AD identity services to just AD

[Aaron Andrade]

Currently we maintain two separate identity services, a legacy OpenLDAP service and Active Directory. Crowd is currently using the legacy OpenLDAP service (configured as a "Delegated authentication directory" in Crowd). We are decommissioning the OpenLDAP service and need to convert Crowd to use AD for authentication, while retaining all of the users/profiles currently configured. All user data (usernames/passwords/etc.) are synchronized between LDAP & AD, so all user details will remain the same. What would the least-disruptive process be to complete that migration?

[Craig Castle-Mead · Accepted solution]

Hey @Aaron Andrade 

This should generally be pretty straight forward - we've done numerous switches between various directories with the same users. As always with a significant change though, it's always best to try in a non-production environment

1. Ensure your username fields are the same in OpenLDAP and Active Directory
2. I don't believe local groups are supported in Crowd for a delegated directory - but if for some reason you are using Local Groups on a directory you're getting rid of, there are extra steps involved (run an SQL query to get any user,group membership values from the cwd_membership table, then use this as the input for a CSV import file - as you're not importing any users, but a users file is mandatory, just create a dummy file with the first line of "u,e,f,l,p" and map these to User, Email, First name, Last name, Password on the import)
3. Setup a new "Microsoft Active Directory" connector with the appropriate filters, run a sync (assuming you're using a cached directory), or do a user search if you're not caching
4. Import groups from #2 if necessary. Spot check to validate the data looks similar to what you expect
5. To each Crowd Application, add the new AD connector directory ABOVE your delegated authentication directory
6. Go to each application, sync the user directories
7. When a user logs to an application, crowd will attempt to login to the first directory mapped to that application that contains that username
8. eg: say a users email is first.last@domain.com in your delegated directory currently mapped to your Jira Application, and their password is Password1. The user is currently logging in to Jira with first.last@domain.com and Password1. If you then add an AD connector to the Jira application in Crowd and drag it above the Delegated directory - if there's an account first.last@domain.com and Password2 as the password, they would then need to login to Jira with Password2 - you COULD NOT login to Jira using first.last@domain.com with Password1

CCM