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

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Multiple domains

Hi all

 

So we have a few company acquisitions that use domain aliases, with one Universal Principal Name in our Azure AD (we'll call this maincompany.com).

 

To explain, all of these users log in with username@maincompany.com, but their default SMTP email address is username@secondcompany.com. Secondcompany.com is an alias of maincompany.com.

 

If a user emails our service desk from username@secondcompany.com, is Atlassian Access smart enough to recognise it's the same user as username@maincompany.com? Since @maincompany.com will be the username used by Atlassian SSO / User provisioning.

 

My concern is that if a user emails a query in using their @secondcompany.com email address, when they log in using their @maincompany.com user account into the portal, they won't see their issued logged via email from the other address.

 

Hope this makes sense

 

Thanks

3 answers

Hi @Asher Francis 

Given that its two different domains and not the same email address, Atlassian access won't classify it as the same user. Therefore, the issues done with the secondcompany.com won't be visible to the user if they login with the maincompany.com address. There's no way currently to merge account (two email addresses as one) for Cloud users.

It seems it doesn't work. For accounts in my company with a mismatch between userPrincipalName and primary SMTP they get a failed authentication. 

The only solution we have found so far is match the UPN and primary SMTP so it gets correctly fixed on Atlassian.

My suggestion is that you fix the mismatch on Active Directory before you try to even synchronize the accounts otherwise you will have even more work to fix the duplicate accounts created. 

There may be a convoluted way to solve this – I myself always wanted to test this.

You may want test verifying maincompany.com domain in Organisations, and enabling Atlassian Access for that. You will need at least 1 user in Atlassian Cloud with maincompany.com email (!) to succeed – perhaps create a dummy one? Configure SAML in Atlassian Access, but when configuring Azure AD side (as per https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/atlassian-cloud-tutorial#configure-azure-ad-sso) in step 14 set the name-id value to the user.mail instead of UPN.

The idea here – the user goes to Atlassian Cloud, on the login page (as usual for them) enters their maincompany.com id, this triggers SAML SSO since this is the domain that is verified and SAML in Access is configured for this domain, Access redirects to Azure AD, the user authenticates, Azure AD responds to Cloud with name-id being the email i.e. with secondcompany.com username. This is how this user will be known to Atlassian Cloud. This will ensure they have access to their JSD tickets.

Unfortunately, "test" here is a misnomer – while you doing this it will apply to anyone in the Cloud with maincompany.com username, including Bitbucket.org and Trello users. Also even if this succeeds – you will need to somehow rename all existing users in Cloud that currently have maincompany.com username to their secondcompany.com emails.

I also suspect you will be able to apply the same SAML integration to secondcompany.com domain (just in case some user uses that to identify themselves) though I am not sure how handover from Access to Azure AD will work here e.g. will they be presented with Azure AD login page asking to re-enter the id?

Also, it's important to note that the social login (Login with Microsoft) most probably won't work "in the same way as the SAML one", as it will continue sending whatever it is sending now. I actually think it will be sending the email now so secondcompany.com? If it is so, then perhaps it's fine...

Overall – I think the above is a bit too messy.

If the user part of the UPN is the same as the user part of secondcompany.com email address i.e. you can easily derive one from the other – you may instead look at ScriptRunner for Jira Cloud and write a script that on create of a request in JSD, will examine the reporter's email, and if it is from secondcompany.com, add the same person as Request Participant (or even replace the reporter)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
Community showcase
Published in Atlassian Access

See Atlassian Access in action - Live Demo

Did you know Atlassian Access offers more than SAML single sign-on for Atlassian cloud products, like Jira and Confluence? Whether you're just starting to plan for your organization or in the pr...

103 views 0 3
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you