Azure AD login and incoming email not matching up

Rodito Buan

Hello All,

We have a bit of an issue with our Jira Service Management instance. We have everything setup and connected to our Azure AD. When people login they redirected to Office 365 which they use login@domain.com but when they email the service desk queue their email is defaulted to firstname.lastname@domain.com, now service desk thinks this is a new user and will assign it to the firstname.lastname@domain.com email address. When the user tries to login to service desk portal they do not see the issue because their account is tied up to login@domain.com.

My question is, Is there a way to merge those two if the login name is not the same as the default email address in Azure AD/Office 365? I would like to avoid having duplicate users in the Customers section.

Thanks

Ed Letifov _TechTime - New Zealand_

We have discovered the following after long conversation with Atlassian Support:

Short summary: "Atlassian Cloud uses email of the user for everything. What you use to actually login into your IdP is irrelevant".

This is how two Atlassian Cloud enterprise applications need to be configured in Azure AD:

For the app responsible for SSO in Azure AD:

• what is pushed into "name" attribute is absolutely irrelevant, might as well be the UPN to match the meaning a username in AAD
• user's email (wherever it is stored in AAD) MUST be pushed to the Cloud's email attribute
• "Unique User Identifier" in the SSO mappings has meaning "... in Atlassian Cloud" and MUST always be the email of the user.

For the app responsible for User Provisioning in Azure AD (we usually have 2 apps with separate concerns, if you have only one, apply the below to the User Provisioning config in that one):

• what is pushed into "username" attribute is absolutely irrelevant, might as well be the UPN to match the meaning a username in AAD
• user's email (wherever it is stored in AAD) MUST be pushed to the Cloud's email attribute
• AAD objectId must be pushed as Cloud's externalId, and it MUST be selected as the one used for user record matching ("Matching Precedence" = 1)
• any groups assigned to the app responsible for SSO in Azure AD MUST be included in the list of groups assigned to the app responsible for User Provisioning in Azure AD (as otherwise you'd have to rely on product access groups to actually have the user provisioned or won't be able to lock a user out temporarily by removing them from a group giving them SSO without triggering deactivation via User Provisioning)

Specifically the above configuration will ensure that both or either of email and UPN can be changed in Azure AD.

If the email address change is done on AAD site, the user should wait around 40 minutes (for user provisioning to push the change through) before attempting the login via SSO, since jumping into action too fast WILL create a new user based on the email being different.