Moving to SSO - Need to "fix" duplicate user accounts

Jeffrey Anderson

We are still using local Atlassian accounts. However, we are moving to SSO soon.
We have many user accounts with old emails. A lot of those accounts have duplicate accounts with their current email addresses. With those new/duplicated accounts I have revoked all access since the permissions are attached to the original/active account.

Example:
UserA_old - usera@OLDdomain.com - permissions set
UserA_new - usera@NEWdomain.com - no permissions set
I need the account with usera@NEWdomain.com to match the permissions of UserA_old

- What can I do to change the active account to the new email address so that SSO log them into that active account and not the duplicated/"no access" account?
- Can I use the "Suggest changes" button in the user account to change the email address associated with the active account?
----- Will Atlassian error out since there is a duplicate account?
----- Will Atlassian merge the accounts?
- Do I need to disable/suspend access for the duplicate account first and then "Suggest changes"?
- Is there anything I can do if the user cannot receive email on the old account?

Thanx in advance!!!

Ed Letifov _TechTime - New Zealand_

Hello @Jeffrey Anderson 

In Atlassian Cloud the email address MUST be unique. As such you won't be able to have two accounts with the same email address, and Atlassian will not merge accounts.

What you need to do:

• verify the OLDdomain as yours, claim all accounts
• verify the NEWdomain as yours, claim all accounts
• for every NEWdomain account that has a "duplicate" OLDDomain account – go and change the email (now that you've claimed them you as are in charge) to some fake email (e.g. add "+fake" i.e. "username+fake@newdomain.com")
• you can also deactivate this account now
• now go into the OLDDomain account – and change the email to "username@newdomain.com"
• the user will have to use the newdoman account to login
• the will not need to receive email on the olddomain account

There is a way to do it a bit faster via User Provisioning from IdP, but this will require updating emails in bulk on the IdP side. Since these are all "live" accounts, unless you have 1000's of them – I suggest you stick to manual update.

This can also be scripted with REST API if you have to...

See:

• Get users: https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-users/#api-scim-directory-directoryid-users-get
• Update a user: https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-users/#api-scim-directory-directoryid-users-userid-put

Be careful to preserve values of attributes other than the email. These APIs will have to be called with the key shown when you configure User Provisioning for a specific directory.

Again, unless you have someone familiar with Atlassian APIs or a Solution Partner (like us – TechTime Initiative Group, a Platinum Atlassian Solution Partner in New Zealand and Australia) on hand – better stick to the manual renaming.

The only little timesaver I can recommend is for deactivation of fake accounts in bulk – try our User Management for Jira Cloud app. It can connect to Atlassian Access source, filter users based on various criteria, and deactivate in bulk even on a trial license. Leave us a review if you can.

If you have any questions – reach out to our 24x7 support