Atlassian Access & Azure AD SSO / Provisioning

Christopher Schmitt

Hello everyone,

I am currently working on the connection of Azure AD and have a problem with SSO.

We have configured SAML/SSO and user provisioning. User provisioning works, but unfortunately SSO does not.

Info about our Azure AD:
user principle name = ShortName@internal-domain.de
e-mail address = Surname.Lastname@external-domain.de

I log in to Atlassian with my e-mail address.
Then I am forwarded to Microsoft. I can log in there with my Azure AD access data (e-mail address or user principle name + password) and when I am redirected to Atlassian, I get an error.

 

Mapping is as follows:

We have configured this according to the following instructions:
https://learn.microsoft.com/en-us/entra/identity/saas-apps/atlassian-cloud-tutorial

 

Would be great if someone has a tip.

 

Thanks a lot!

Greetings
Christopher

Ed Letifov _TechTime - New Zealand_

Hello, @Christopher Schmitt and @David Kerry 

1) Assuming the user ACTUALLY has the email address in the mail attribute (this is NOT a given for people without Office365 subscription, or those pushed from on premises AD) this error usually indicates a mismatch in certificates – so re-download the cert from AzureAD, open up in text editor and copy-paste again.

2) The difference in UPN and email, and what you use to login into Azure AD, is irrelevant – Atlassian Cloud keys EVERYTHING on the email address.

3) You may want to check some answers I've provided earlier on how to configure SSO and User Provisioning correctly:

• https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417
• https://community.atlassian.com/t5/Atlassian-Account-questions/SAML-SSO-with-Azure-AD-does-not-work-when-using-quot-Continue/qaq-p/2085502
• https://community.atlassian.com/t5/Jira-Service-Management/Azure-AD-login-and-incoming-email-not-matching-up/qaq-p/1821809#M88619

In the case of Azure AD/Entra ID, the documentation published (by Atlassian?) to the Microsoft documentation site completely omits a very important detail about setting "Matching Precedence" correctly and could, and indeed has been, misunderstood by the admins. And to complicate this, the default value of that being set to the "User Principal Name" is wrong too in a general enterprise use case, since UPNs can change – it should instead be the Object ID.