You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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.
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:
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.