RTC login account issue - case-insensitivity
Environment: JTS, JAZZ running on tomcat. (v 4.0.6)
Case insensitivity is set to True. I have a scenario, the LDAP accounts initially were created with mixed case. (sAMAccountName is the userId used for login) Example: DSikimic is the sAMAccountName value for Dragana Sikimic Relevant contributor ID in JTS is _sQ1lYkZQEeObDa80XLxUvg created at initial LDAP sync. User used to login using mixed case userid. Later, the sAMAccountName attribute for all user accounts were changed from mixed case to lower case. ( DSikimic -> dsikimic) LDAP sync created another user account in JTS for the same LDAP user.! Relevant contributor ID in JTS is _eA_14OaeEeOq4JskBoD-Uw While we are trying to archive the the unused user account, we have below cases... Case 1: ---------- User ID Archived dsikimic No DSikimic No User is able to login using mixed case & lowercase user id. Case 2: ---------- User ID Archived dsikimic Yes DSikimic No User is able to login using mixed case & lowercase user id; but after login it shows below error...
Error!
Case 3: ---------- User ID Renamed dsikimic Yes DSikimic Yes Imported the user dsikimic into JTS freshly. User is able to login using mixed case & lowercase but the history related to user is missing. (WI, changesets, roles etc.,!) We want to have one single account in JTS & retain history for that user. To achieve this, what could be the best approach.? |
2 answers
Ralph Schoon (63.3k●3●36●46)
| answered Sep 10 '15, 3:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I think I have answered a similar question some days ago already.
What happened when you reimported the user with a different ID, you basically got a new User. The user has a different internal ID and is unrelated to the old user. All entries in the repository refer ti the internal ID of the old user. You should rather try to fix the user ID's of the old users and make them work with your LDAP. See Changing the Jazz User ID Using the RTC Plain Java Client Libraries how to possibly approach that. Test this on a test system, backup your system before you try this for production. In tests I did, the change was run against the JTS and these changes got synchronized over to all other applications that are registered to the JTS. In the post is also a link to how to do this manually. E.g. to try it out and test if it works. Comments Ralph, thanks for the response. I will try-out the user modification using java api. Between, JTS is using _sQ1lYkZQEeObDa80XLxUvg (DSikimic) to authenticate the user from LDAP and _eA_14OaeEeOq4JskBoD-Uw (dsikimic) to authorize.! You created duplicate users in the DB, that and the case insensitive issue messes up your system, I guess.
No, I haven't created duplicate user. DSikimic user name was changed to dsikimic in LDAP. Then RTC LDAP sync created another user.! (it seems to be a issue at RTC LDAP sync) 1
LDAP sync has to assume that the user ID in LDAP drives the ID in RTC. I am not sure if it can be made aware of case insensitivity. But that drove the creation of the duplicate users.
|
Hi Nagesh,
1. Could you please check the contributor id of the imported user after Case 3?
If its a different contributor Id, the missing history may be understandable.
2. Could you also add your observations for the following case :
Case 4:
---------- User ID Archived dsikimic No DSikimic Yes
In the context of :
Later, the sAMAccountName attribute for all user accounts were changed from mixed case to lower case. (DSikimic -> dsikimic)
With "dsikimic" un-archived (and not re-imported), the older artifacts should be accessible.
3. Also, I believe these observations for all Cases are from a common Application Server (Websphere, may be), please confirm. I ask this because the handling of Authentication by RTC Application is different between Tomcat as App Server and Websphere as App Server.
Regards,
Dinesh
|
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.