It's all about the answers!

Ask a question

Is it possible to change RTC authentication methods using WebSphere?

Karl Athanasiou (3121317) | asked Oct 01 '12, 12:55 p.m.
My company is moving from a numerical based login scheme to an alphanumeric.
Originally we used sun directory services and they are now moving over to AD.
I am authenticating now using LDAP

Has anyone ever done this?

Is there a way to convert usernames from 1234567 to abcd1?
We are using RTC for Build.. Work Item Tracking and Source Control.


WAS 8.5
RTC 4.0

RHEL 5.8


Bo Chulindra commented Oct 01 '12, 1:26 p.m.

When you say "convert usernames", do you mean convert the usernames for users who already exist in RTC? Is this because the old usernames will no longer exist and the old users will have new usernames?

Karl Athanasiou commented Oct 02 '12, 11:00 a.m.

 That is correct...

Users will now be required to log-in to the domain using an alphanumeric string.
Joe user
Old ID was : 12345
New Id Userj1

Accepted answer

permanent link
Ralph Schoon (63.2k33646) | answered Oct 02 '12, 3:59 a.m.
edited Oct 02 '12, 4:01 a.m.
Hi George,

there is a way that I think allows to change the user ID's. Warning, there are probably dragons.

You can set the User Registry Type in the advanced properties of the applications to UNSUPPORTED.

User registry settings

Once you did that, I understand you can change the user ID's of the users. However, usually I would assume that you keep the user ID's if switching authentication and use this only to fix some few user ID's.

Warning! I have not tried that myself on a production system. If you do this wrong, I assume it is going to be a death trap. Warning!

Please be aware that in doing so, you also remove their ability to login with the current registry. I would suggest to create a new Administration user in the new AD before you change all the other users and test it against the new AD. The Easiest way I can think of is to switch to Tomcat authentication temporarily. Again, you need to make sure you have at least an administrative user in Tomcat (tomcat-users.xml), before you do that. You can reenable the ADMIN/ADMIN account by setting in all teamserver. properies where it is set to false. If you use Tomcat the tomcat-users.xml would at least contain this user. Make sure he has the admin role set in tomcat users.

With WAS you could try to switch to the federated REALM and make sure to manage your ADMIN users.

If you do use this while connected to the old AD, I would also suggest to switch off the nightly LDAP sync task, because you would get the old users synched in.

I have not done this with a JTS and I am not sure if you only have to change the ID in JTS for it to be synched into the other applications, I would suggest testing it in a test environment and create a working procedure before trying this in production.

Karl Athanasiou selected this answer as the correct answer

Ralph Schoon commented Oct 02 '12, 4:17 a.m. | edited Oct 02 '12, 6:28 a.m.

As an afterthought, I guess the trick is to get an ADMIN user that can authenticate against your new LDAP system created. I would test it the following way with a test system:

0. Switch off the LDAP SYNC Task
1. Reenable ADMIN/ADMIN and make sure he has the right repository group.
2. Make sure you have a user ADMIN/ADMIN or any other user with ADMIN repo permission set up in the new LDAP realm.
3. Switch to the new REALM and make sure you can login with ADMIN/ADMIN
4. Switch to unsupported
5. Modify the user ID's
6 TEST, TEST, TEST that you did not break anything.

As a last thought I would look into the repotools-jts -exportUsers where you can export and import the users. Maybe you can use this to modify the userID's while keeping the names stable. I know a customer used this somehow to overwrite data that was in their LDAP system.

Karl Athanasiou commented Oct 02 '12, 11:07 a.m.
This process kinda makes me wish there was a utility similar to ClearCase sidwalk.

I do have a test env that I replicate the prod data to so I can try it out.
I'll post if anything worked and how it worked.

Thank you..

Ralph Schoon commented Oct 02 '12, 11:59 a.m.

It is probably possible to automate the change like this:


        IContributor user = teamRepository.contributorManager().fetchContributorByUserId(oldID, null);
        IContributor archiveIDWorkingCopy = (IContributor) user.getWorkingCopy();
        teamRepository.contributorManager().saveContributor(archiveIDWorkingCopy, null);

        System.out.println("Modified user ID: " + oldID+ ".");


Ralph Schoon commented Oct 12 '12, 6:14 a.m.

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.