Fix SSO Configuration

[Alexander Hammond]

We've been using Atlassian access for our atlassian products for well over a year now. When we did initial set up we configured our atlassian accounts to be our UPN and not our actual email addresses. We did this because for signing into all our products we use our UPNs and we didnt want to confuse users. 

I think i'm starting to realize that may not have been necessary here, but we're a year down the road and just now starting to open up the opportunity for users to submit requests via email.

The problem is the email comes from their email address, NOT their UPN. 

Can I simply update provisioning configurations in Azure AD to set the email address as the username or will that break existing accounts? What impact might users expect if I change this? Will this even resolve my issue, or will this provision duplicate accounts?

Are there other options or solutions?

[Michael Amland]

We are having the exact same issue is our just rolled out JSM Cloud project.  In our existing JSD (server) install using the Crowd connector - users can login and auth using their UPN and still have an 'email' value set to their SMTP email address and the net result is they login as desired, AND they can create and reply to requests via email. No issues.

That does not work in Atalassian Cloud.  Using the Azure > Atlassian Access with SSO enforced only works if their 'email' value is mapped to UPN@domain  (which is what works with their MS 2FA and is a valid email to receive emails an an alias SMTP as well) -- BUT, their Azure AD primary SMTP email (and hence the value stored as 'email' in AD) and used to send emails is in fact "firstname.lastname@domain" and therefore users cannot comment on tickets via, create tickets via email etc.  Their Atlassian account sees their email as UPN@domain -- and any emails from their actual SMTP address gets treated as a seperate user -- and therefore we have to deny signups or new account creation via email or all heck breaks loose with dip accounts being created.

Other companies have surely had to address this using JSM Cloud? I have not located a good solution yet so would appreciate any ideas.  Simply having the ability to map a "other email" value Azure > Atlassian Cloud that is their SMTP email account -- via sync -- and have JSM treat any incoming emails from it as associated with the correct ID -- would be ideal.

[Ste Wright]

Hi @Alexander Hammond 

Are you not populating the user's email address at all from Atlassian Access?

Assuming it's not feasible to block creation of Issues via email - I'd recommend:

• Create a new Atlassian Access, and Jira instance separate to your main instance
• Implement it with Azure AD, and test making changes with a small set of users

I'd recommend this because even if we do provide you advice - realistically, I wouldn't risk doing it in Production until you've thoroughly tested it.

Ste