Migrating between two external LDAP domains with different username formats
本ナレッジベースはアトラシアンの サーバー プラットフォーム向けに記載されたものです。Atlassian Cloud との機能の違いにより、本記事の内容を Atlassian Cloud アプリケーションに適用することはできません。
You've setup Fisheye connected to an external LDAP User Directory and now your organization is migrating users to another domain or LDAP directory where the username format is different. You want to migrate to the new directory without losing any data (commits/reviews etc.) associated with users/usernames from your old LDAP. Simply adding the new directory then disabling the original directory will not transfer over those associations.
DomainA --> UserA --> username: charlieatlassian
DomainB --> UserA (same user in Domain A) --> username: charlie.atlassian
You are planning to discontinue
DomainA, so you want to copy/move/migrate
charlie.atlassian) without any data loss.
It is possible to make the migration without data loss, but using the internal Fisheye user directory as an intermediate step:
- Start with the Fisheye Internal Directory ordered as below the external directory.
- Disable the external directory.
- Create users in the Internal Directory with their username matching the original/old external directory. It may be worthwhile to script this using something like the Fisheye REST API to avoid manually entering these. (See Fisheye/Crucible restAPI)
- Promote the Internal Directory above the external directory. At this point if you had manually set a password for the Internal Directory users, you should be able to log in as one and verify that associations are still intact.
- Rename each user to use the username format of the new external directory. As above, it's probably best to script or otherwise automate this step.
- Add the new directory connector. If you sync at this point, you should not see new users in Fisheye because they will have the same usernames as the users in the Fisheye Internal Directory.
- Promote the new directory connector above the Internal Directory.
The expected result here should be that users are able to log in with their new usernames, be authenticated against the new directory connector, and retain their existing associations.
One notable difference here is that if also you remove the external directory connectors or otherwise promote the Internal Directory to the top of the list, all the users will still be in there since they are defined internally.
One important limitation here is that Group membership information won't be maintained using this approach. If groups are managed entirely externally, you'll need to make sure before migrating that the correct groups are configured in the new directory.
Connecting Fisheye to your external directory is not sufficient to allow your users to log in to Fisheye. You must explicitly grant them access to Fisheye in the global permission screen.