How to copy user attributes to LDAP directory from local directory

[Tom Luo]

We are planning to move the user directory from local directory to an AD server. Most of the local user names have been in the AD server. We can ignore the ones not found in the AD server. How is the best way to do this? It is acceptable if the users will not be able to modify some history data, but all history must be able to be traced. We can also consider any add-ons.

The current running instance is 6.3.7. We can upgrade it to the latest version. The type of the LDAP directory is "Microsoft Active Directory (Read Only, with Local Groups)".

Any advice is appreciated.

Thanks.

[Tom Luo]

Maybe I misunderstood, but I understand that the procedure in the documentation will create new users in the AD, as I can see the sentence below:

•Users and groups will not be migrated if they already exist in the target directory. For example, consider a user that exists in JIRA Internal and JIRA Delegated LDAP but has different groups in JIRA Internal: when migrating from JIRA Internal to the JIRA Delegated LDAP, that user will be skipped and the groups will not be migrated.

In my case, all the user accounts in the local directory has been in the AD with the same user names. We don't want to create any new account on the AD. Is there a way to replace the user accounts of all issues, memberships and other objects with those in the AD?

For example, there are user account test in both the local and AD directories. The account authors three issues and is a member of Development. After the migration, we want to see the author of three issues have been changed to the test account in AD, and that AD account is the member of Development.

[Steven F Behnke]

Alright, thank you for the extra details. Your best source of official documentation is – Migrating users between user directories

Important notes

• Nothing will change if they have the exact username they currently use.
• If you want AD to be the source of truth, I recommend using an AD access account that doesn't have write capabilities. (this ensures you won't push changes upstream to AD)
• You should ensure that you have LOCAL ADMIN access at all times (not a duplicated username)
  • This means you should always have a Internal Directory with your Local Administrator account/password

You need to choose between using a Delegated Authentication directory or using an Active Directory connector. Both of these can be configured to use Active Directory. Once you've created your directory, you can move it higher than the Internal Directory and users will authenticate against that instead. You should ensure that you remove the old users or the groups associated with those users so they don't count against your JIRA license any more.

[Tom Luo]

Hi Steven, Thank you very much for your recommendation. I just noticed you said "Nothing will change if they have the exact username they currently use.". But this is exact what we need in our case, all usernames in the source local directory have been in the target LDAP. Does it mean there is no way to just copy the membership and links to tickets for each local user to the LDAP? We will consider any way including paying add-ons.

[Steve Behnke [DiscoverEquip.com]]

Tom, I really do not think you have a problem. If the usernames are the same as they are in LDAP, JIRA will consider them the same user. They will own the same issues as before. YOU need to make sure the groups that are in-use in JIRA are replicated in LDAP or are removed from use. This will ensure that project membership works. You don't need paid add-ons: You need someone who knows what he's doing.

[Tom Luo]

Thanks Steven. We are using the local directory and going to use an AD to replace it. The AD has had all the usernames the local directory has. We don't want to change anything on the AD server. We hope that after we move to the AD, we can see all issues, comments and other stuffs still linking to the same username except they will be in the AD. We don't know what is the procedure. Is there any documentation describing the procedure? I can't find it from Internet.

[Steven F Behnke]

You don't really describe a problem. This is part of moving any LDAP system to any other LDAP system. What's the confusion?