Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

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

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

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!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,467,382
Community Members
 
Community Events
177
Community Groups

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

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events