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!


Fix SSO Configuration

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?

2 answers

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.

0 votes
Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 07, 2022

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.


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events