CLM 5.0.2 with Websphere and Edirectory switching to Active Directory
Since both WAS and CLM have LDAP connection information and user group / role definitions, I am trying to figure out the sequence of how changes can be made and if I run the risk of locking out my environment if they are not done 100% correctly the first time.
Do we change Websphere to AD including the security role to user / group mapping first? After the JVM restart, can I log in to CLM still if WAS has been "flipped to AD" but CLM still has the eDirectory configurations? If so, then I am fine and I can "fix" JTS and RTC as long as it still thinks I'm an admin.
Or do I try to change the LDAP settings in CLM first and then do the websphere changes and hope that after the JVM restart, everything still works with the new settings?
Someone must have done this. Interested in the tricks to minimize the pain.
Thanks!
Accepted answer
One other answer
Comments
Thanks to both of you for responding. We were successful in cutting over to AD in our Dev/test environment. However, I am seeing some odd issues with case of the IDs.
In eDirectory, the UID is upper case for some users and lower case for others. So JTS has some IDs upper and some IDs lower. In Active Directory, all of the UIDs are lower case.
We have user self registration and also have the nightly LDAP synch job set up.
When the change was made in Websphere, they also changed from a stand alone LDAP to a Federated model.
Several ID continue to use their uppercase ID. However, I could find the user and import his ID (lower case) thru import user. So now he has an upper case ID and a lower case ID. But when he logs in, it uses / finds his upper case ID. So the ID the user login is using (upper case) is not the same ID that was imported (lower case). Or put another way, the ID created with user self registration (upper case) is no the same ID that was created thru the import
I am confused how/why this is happening.
Once we are able to eliminated the case insensitve duplicate users by changing some of the IDs using this method (which we have working) https://rsjazz.wordpress.com/2012/10/12/changing-the-jazz-user-id-using-the-rtc-plain-java-client-libraries/
we plan on setting Use case insensitive user ID matching to true.
However, I am concerned that I have not gotten everything properly configured since self registration and import users result in different users being created.