Showing results forΒ 
Search instead forΒ 
Did you mean:Β 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

AzureAD, SSO, different UPN and Email and existing service accounts?

We already use Trello as a business, we're moving to other Atlassian cloud apps and need better authentication options.

All Trello users are configured in an existing premium workspace logging in with a historic UPN based email address e.g., this is equal to their AzureAD upn and AD domain logins e.g. Chuck logs into Microsoft services as

Users default vanity email addresses and property in AzureAD is different however, for Chuck his display and default email address is

We have setup Atlassian access and claimed the domain, however we're unable to get sso going.

Upon successful login with via AzureAD sign-in services, the user is directed back to Atlassian access/Trello and promoted to create a new Trello account with, even if completed, this loses the existing workspace access and boards etc. Chuck can however still login to his Trello/Atlassian account using their old self managed password. 

Given our upn is a full valid email address for each user, I'd expect this to be possible? 

E.g. chucks default mail is, but he logs into everything with - on first login with sso using, the system marries up the existing accounts with the known email.


2 answers

So what I've done above is spot on and is now working, thanks for the support!

The issue was that I'd not enabled auto claim and when users were being manually claimed they were making their way into the default local policy, not the identity provider causing the issue I was seeing. 

All sorted, cheers all πŸ‘

Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 21, 2023

@FunkyG this is really strange, as according to Atlassian once you integrate with IdP a default policy is created, specifically for the managed accounts, and any accounts you don't want there would have to be moved out into the local one manually. We recently stepped into it as a Solution Partner during Server to Cloud migration

Also, the above doesn't explain how Cloud learns the default email address, when your mapping doesn't pass it.

I know you think it's resolved – but I would still suggest to raise a ticket with Atlassian, because it doesn't quite make sense.

0 votes
Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 19, 2023


When you set up SSO with Azure AD via Atlassian Access, you install an enterprise application on Azure called "Atlassian Cloud". The SSO settings for this application are responsible for configuration of SSO integration with Atlassian Access.

In these settings there is a mapping of Azure attributes to what Cloud wants. One of these is the email address of the user – Atlassian Cloud uses THAT as the user-id, ignoring all other user-id-like attributes it itself asks for (e.g. "Name" and "Unique User Identifier" as listed here in item #13)

Since you say that the UPN is a full valid email address i.e. users can actually receive email into their mailboxes on this email address – for you to achieve what you after you just need to change the mapping for the "emailaddress" from whatever you have now to "user.userprincipalname"

To be clear, if you claim the domain for the "vanity" email address and the user enters THAT on Atlassian's login page – they will still be redirected to Azure, where they can login (or be already logged in) with username, they will be redirected back and logged into Atlassian with email. What you enter in Atlassian's login page is responsible for triggering the redirect to Azure. What you are logged in with is whatever you map to Cloud's "emailaddress" attribute in Atlassian Cloud Azure AD enterprise application.

Thanks, I've not made myself clear in my original post. We are using userprinciplename as below. 


What we've seen happen is as follows... has an existing Workspace enabled premium account in Trello. His user.userprincipalname field matches this and the attributes and claims match those in the screenshot above. 

When SSO is enabled in Atlassian Access, is signed in, however, Trello finds his default email address in AzureAD and consumes that, instead of using his then insists on setting up a new account with which is configured as the default email address for all users. Trello doesn't take on his existing workspace enabled premium account.


Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 21, 2023


The only scenario that I know of where with the configuration you've shown Atlassian Cloud would still learn the default email address (I assure you, Trello does not dive into Azure AD to fetch it) is if the user is clicking "Continue with Microsoft" button and then logging in into Azure with instead of typing their into Atlassian login page, and being redirected to Azure for authentication and then back via SAML SSO).

Can you confirm that this is what the user is doing?

The difference is that "Continue with Microsoft" is not SAML SSO via Atlassian Access, it's just a convenient non-enterprise "shortcut" for SSO on the web also known as 3-rd party login (see

The main problem here is that it is done via a different enterprise application in Azure AD, called "Atlassian" (as opposed to "Atlassian Cloud"), which will be created (and re-created) automatically every time someone uses "Continue with Microsoft" button. This application does return the default email address to Atlassian Cloud as the username – hence the observed behaviour.

When I last checked with Atlassian support – nobody in Atlassian knew how to configure this application. You may want to raise a support ticket and fight through in a hope to get to someone who will eventually be able to help.

It is possible to set "Enabled for users sign-in" to No in Properties for this application in your Azure AD – this will stop users from being able to sign-in with Continue with Microsoft button, but the result will be rather ugly – the regular Azure AD troubleshooting page "sorry we are having trouble signing you in" with multiple UUIDs to describe the error.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events