Duplicate users when provisioning from EntraID – a missing piece of information in the documentation

[#1]

Hi,

my name is Antti and I'm working as an Atlassian Consultant in a Finnish Atlassian Platinum Partner company Ambientia Group Oy. I have several years of experience on Atlassian Cloud products, mostly Jira, Confluence, Jira Service Management and Guard. We've done dozens of Atlassian Cloud implementations along with configuring Atlassian Guard with the customers, mostly to Entra ID.

I've noticed there's an important aspect missing from the documentation provided by both Microsoft and Atlassian. What if user changes their name, hence their email address?

Atlassian documentation https://confluence.atlassian.com/cloudkb/atlassian-guard---attribute-mappings-for-saml-sso-and-scim-user-provisioning-1455423571.html speaks only about name, email and UPN.

Microsoft documentation https://learn.microsoft.com/en-us/entra/identity/saas-apps/atlassian-cloud-provisioning-tutorial and https://learn.microsoft.com/en-us/entra/identity/saas-apps/atlassian-cloud-tutorial speaks only about name, email and UPN.

The key is "Matching precedence". By default, it's set to UPN or email for value of 1 - meaning that attribute is the one deciding if the user already exists in Atlassian cloud - but when the user changes their name, their email address and UPN usually change. This affects provisioning by creating a duplicate user in Atlassian Cloud - because the new user email address doesn't exist there yet. There will also be "Resource [USER]: with email[firstname.lastname@customer.com] already exists." errors in the provisioning log.

To fix this, you should set "Matching precedence" to 1 on "objectid" <-> "externalid", which is the unique, unchanging identifier for the user account in question. Then you probably need also Atlassian Support's help with purging the duplicate account from their SCIM database. After this, you should be all fixed!

My colleague Rafael wrote a longer and more comprehensive blog post about the topic, also from the Atlassian Data Center point of view: https://www.linkedin.com/posts/rafael-pinto-sperafico-4a991456_handling-user-identity-changes-in-atlassian-activity-7379807081496817664-9SSp

[David Cowley]

Appreciate you brining this forward. We literally have one of the domains we manage systematically changing their email domain. It might not help us this time (as we may not be able to implement before that changes completes), but would make future occurrences much easier.

The upside to the change is obvious: maintaining a 1:1 relationship between Entra ID accounts and Atlassian Cloud accounts, are there downsides to this change?