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

Question

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. chuck.norris@upndomain.com, this is equal to their AzureAD upn and AD domain logins e.g. Chuck logs into Microsoft services as chuck.norris@upndomain.com.

Users default vanity email addresses and user.email property in AzureAD is different however, for Chuck his display and default email address is chuck.norris@chuck.com.

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

Upon successful login with chuck.norris@upndomain.com via AzureAD sign-in services, the user is directed back to Atlassian access/Trello and promoted to create a new Trello account with chuck.norris@chuck.com, 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 chuck.norris@chuck.com, but he logs into everything with chuck.norris@upndomain.com - on first login with sso using chuck.norris@upndomain.com, the system marries up the existing accounts with the known email.

Ed Letifov _TechTime - New Zealand_ · Answer

@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.

FunkyG · Answer

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_ · Answer

@FunkyG

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 chuck.norris@upndomain.com) instead of typing their chuck.norris@upndomain.com 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 https://support.atlassian.com/security-and-access-policies/docs/edit-authentication-settings-and-members/).

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.