It's all about the answers!

Ask a question

CLM 5.0.2 with Websphere and Edirectory switching to Active Directory


Steve Mills (5111) | asked Aug 18 '16, 9:20 a.m.
edited Aug 18 '16, 9:21 a.m.
Our company is discontinuing the use of eDirectory so all application must migrate to AD.

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


permanent link
Lily Wang (4.9k714) | answered Aug 18 '16, 9:11 p.m.
To switch to another LDAP server, first you need to keep the Jazz user Id same as the previous. 
The procedure will be:
1. On AD, create the LDAP users which have the same user id and Jazz groups as the old LDAP server.
2. Change the LDAP configuration to point to the new AD server in WAS
3. Redo the group mapping for all applications in WAS
4. Login jts/admin and modify the LDAP configuration. Or you can modify the configuration by manually update conf/jts/teamserver.properties.

Hope the above is helpful.
Ralph Schoon selected this answer as the correct answer

One other answer



permanent link
Donald Nong (14.5k414) | answered Aug 22 '16, 3:13 a.m.
For your concerns, all it matters is the LDAP configuration in WAS. You will need correct LDAP server configuration in WAS so that your credential is accepted. You will need correct security role mapping for each CLM application to identify yourself as an "admin" (as having the JazzAdmins role). You can always fix the LDAP configuration in JTS later down the track, as it's for user synchronization only, not for authentication.

Comments
Steve Mills commented Oct 26 '16, 11:24 a.m.

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.


Steve Mills commented Oct 26 '16, 11:30 a.m.

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.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.