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

[FunkyG]

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.

[FunkyG]

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_]

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

[Ed Letifov _TechTime - New Zealand_]

@FunkyG 

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 https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/atlassian-cloud-tutorial 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 upndomain.com username, they will be redirected back and logged into Atlassian with upndomain.com 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.

[FunkyG]

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

chuck.norris@upndomain.com 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, chuck.norris@upndomain.com is signed in, however, Trello finds his default email address in AzureAD and consumes that, instead of using his chuck.norris@upndomain.com then insists on setting up a new account with chuck.norris@chuck.com 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_]

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