Use UPN with Azure AD - not the email

[Vincent Arancio]

Hello,

I want to use UPN like a login I think is here but I don't find how I can do.

Please help

Thx

[Robert Westendorp]

Even better would be able to do the mapping to an attribute that doesn't change ie EmployeeID.

This means that regardless of email address changes over time .. the users will still map.

Today, if someones email address changes it'll create a new user in the Access and my guess is we have to get support to re-map the user.

On prem this was solved with separating the username from the email.

We also have multiple internal domains, so we can't do a simple mapping as suggested.

When someone migrates from the cloud then the username could be imported into the unique id field.

I'm guessing there is still a uniqiue ID under the hood on the Atlassian side, but we have no control of it.

Anyone know if Atlassian has looked at this possibility?

[Ed Letifov [TechTime - New Zealand]]

Short answer - DO NOT. Nothing else but email will work.

"name" attribute (on the left) is not used by Cloud at all

"urn:oid:0.9.2342.19200300.100.1.1" won't be used by Cloud

the "Unique User Identifier" absolutely MUST be set to user.mail – Cloud uses the email address for everything (whether you want it or not)

Please note, this doesn't prevent you from actually logging into Azure AD with whatever you want – the email, the UPN or the username...

Please see this post as well for how the Atlassian Access User Provisioning should be configured: 

https://community.atlassian.com/t5/Jira-Service-Management/Azure-AD-login-and-incoming-email-not-matching-up/qaq-p/1821809#M88619

and for a longer read:

https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417

[gabriel.muller]

This is not accurate. Although you emphasized that everyone should use user.mail, if you have your Azure configured in a way that this attribute is empty in users profiles, it won't work.

Additionally, the instructions from Microsoft mention 2 different scenarios (step 14): if you have MS 365, they recommend you configure this Unique User Id to user.mail, but if you don't have MS 365, then this attribute is not used in Azure, so they recommend you use UPN.

See here the official documentation with instructions to set up SAML SSO with Azure https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/atlassian-cloud-tutorial.

There is no right or wrong, it all depends on how each company's Azure is configured.

To respond @Vincent Arancio , if you have the UPN attribute configure with a valid email address, then yes, you can change the Unique User Identifier (or Identificateur unique del utilisateur) to be UPN.

[Ed Letifov [TechTime - New Zealand]]

@gabriel.muller 

I will agree to disagree at least on some the parts of your statement. Being an SSO vendor (on Server and Data Center) I know that this "official" documentation is written by Atlassian, not Microsoft. Having engaged with Atlassian multiple times specifically on the matter of integrating Atlassian Access with Azure AD, and having forced the change of this very documentation several times – I know how inaccurate it may be.

I do agree that a lot depends on how your Azure AD is setup, but the original purpose was to describe what matters to Atlassian Cloud. Atlassian Cloud wants to identify the user by an email, though yes, it doesn't matter where the value actually comes from.

One may need expressions in the mapping to address all possible situations e.g. when there are no mail attribute (e.g. for guest users)

[Michael Avery]

I suspect the issue is conflation of UPN and email address between Atlassian Access and their products (Jira, Confluence, etc.) due to reliance on email address as key identifier field for so much functionality.  This is unfortunate and I think you are likely right @Ed Letifov [TechTime - New Zealand] 

One remedy for Orgs with users carrying mismatching UPN and email domain may be using transformation and expression mappings for provisioning and SAML claims.  If we can align provisioning with SAML claim expressions/transformations, it may work?

For instance, SSO claim transformation mapping:

Thoughts?  Any experience with this?

[Ed Letifov [TechTime - New Zealand]]

My main point was – whatever Cloud will be attempting to use as a "username" has to be a functional email address that Atlassian will use to reach the user. Strictly speaking nobody cares where it comes from.

Consider the situation when a use self-registers with no Access in sight – all Atlassian asks you to enter is 1) an email (which Atlassian verifies by sending you a link to click on) 2) a password 3) Full name

There is no notion of "username" or "name" because Atlassian takes whatever you entered as the email and chucks it into the username.

So, even though you can map whatever you want into any attribute expected by Access – you should map the real email to the email attribute.

I understand that it may be stored in some other AAD attribute (e.g. in user.mail for regular users with Office365 accounts, and in the external email address for guests and in onpremisesemail or whatever for those being pushed from your on-premises AD), but I would find it strange if you had to glue a part of UPN and a hardcoded domain... Yes it will work, but why would you need to do this?

[Michael Avery]

So in the case where AAD UPN and primary email domains do not match, adjusting the provisioning mail attribute mapping like so should fix the issue?

Mail mapping:

**EDIT: I don't suggest people try this, particularly if you have AAD B2B users.  Forcing the UPN isn't a solution for guests.  See a lower post for my solution.

[Ed Letifov [TechTime - New Zealand]]

Again, Cloud doesn't care about UPN. At all. Give it something it can use as an email – put it into email attribute and it will be happy.

If I had to email something to you would I be typing the value of your UPN into my mail client? If yes, is this value not present in some other attribute of your AAD? If it is present why are you trying to retrieve it via UPN, why not take it directly from that other attribute?

[Michael Avery]

The products (Jira, etc.) don't care you are right they use email only, but Access does care.

Azure only accepts the UPN to authenticate.  If we are using AAD SAML to authenticate to Atlassian cloud, (under suggested mappings) a UPN/email field mismatch renders the authenticated user outside the managed domain within Atlassian Cloud.

The user with mismatching UPN/email falls out of provisioned users and groups (and thereby access to projects, spaces etc).  Changing their AAD email attribute to match the domain in the UPN/SSO configuration fixes the issue.  This isn't feasible in all cases.  Changing email address for other AAD SAML connected apps is transparent.

[Ed Letifov [TechTime - New Zealand]]

When someone shows up at Atlassian Cloud front door, Atlassian Cloud asks "what's your email". Based on the domain of the email entered Atlassian Access decides to direct you to Azure or to perform the local authentication using Atlassian ID.

When directing to Azure AD the identifier that the user has supplied is not actually passed to Azure, merely "someone is trying to get into application with ID XYZ" where "XYZ" is the entityID from the Atlassian Cloud app that you've installed into Azure.

If the user has not yet logged in in Azure, Azure will present the login dialog. To be clear – here the user can authenticate using something completely different from the identifier they have supplied at the Cloud's front door.

Once the user is authenticated, Azure sends SAML LoginResponse where data is passed through claims/attributes.

Yes in this list there is the Name ID ("Identificateur unique del utilisateur" in the original screenshot), as well as the "name" attribute BUT THE CLOUD IGNORES BOTH COMPLETELY and instead uses whatever arrives in the email attribute to identify the user.

UPN is not used anywhere during SAML SSO with Atlassian Access.

In the provisioning case it's the same – Access will happily accept everything you push to it in whatever attributes you push it, but in the end only the email one matters for SSO.

The catch here is the default selection of the UPN as the "matching attribute" – where Access treats the UPN as something unchangeable. This is incorrect and should always be changed to objectId as in absolutely normal enterprise scenarios UPN, email, and the full name can all change.

[Michael Avery]

I appreciate your engagement Ed - thank you.  My scenario may be a little different, where having existing provisioned users and groups change their primary email address to use a different domain than the managed domain in Atlassian cloud.  This causes affected users to fall out of scope for the managed domain, disappearing from the Atlassian user list, and out of provisioned groups.

Some instructions

---

• Do not directly map UPN to mails[type eq "work"].value - especially if you have B2B provisioned users.
• If the domain used in user UPN has changed from the managed domain in Atlassian config, this method will not work, you will have to reconfigure SAML and SSO.
• This method also works in cases where UPN prefix is different than email address prefix.
• I suggest you disable automatic provisioning and verify with a test user.

---

Change the user provisioning Mappings for the Atlassian Cloud Enterprise App

AAD attribute: mail

Atlassian Cloud attribute: emails[type eq "work"].value

1. Change mapping type from Direct to Expression
2. Replace mail attribute email domain to match UPN domain
3. emailprimarydomain.com - change to your primary email domain
4. upndomain.com - change to the UPN domain

• Save and test