Multiple domains

[Asher Francis]

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

[Prince Nyeche]

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.

[Rodolfo Salgado]

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. 

[Perumal M]

Hello

[Ed Letifov _TechTime - New Zealand_]

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)