Forum Discussion
Set AD User with External Email Address
This is a really complex scenario. Not so much from the technical side but more because of the restrictions imposed by legal separation.
At a very high level:
- I would have left Company B alone and completely separate;
- I would have then asked for the funding to establish Azure Active Directory Domain Services (Azure AD DS) within their tenant;
- I would have then created a one-way trust from Company B's Azure AD DS to Company A's on-premise Active Directory. This would allow Company B to log into Company A's workstations (so long as they're on-prem or hybrid joined) and access their resources but not vice versa.
You could use a forest trust if that is appropriate, but I wouldn't have thought it would be.
I would not have moved Company B's workstations into Company A's forest - unless Company A's employees are going to log onto Company B's workstations.
Again, I'm reducing a complex requirement into some very basic bullet points but keeping them separate given they are legally separate entities is actually pretty important until such time as they merge and are the one legal identity.
Here's some Microsoft literature on the options.
- How trusts work for Azure AD Domain Services | Microsoft Docs
- Tutorial - Create a forest trust in Azure AD Domain Services | Microsoft Docs
- Tutorial - Create a customized Azure Active Directory Domain Services managed domain | Microsoft Docs
- Azure AD Connect: Supported topologies | Microsoft Docs (the Multiple Azure AD Tenants part in particular - not that I'm recommending this, but you are touching on it already)
- Plan your hybrid Azure Active Directory join deployment | Microsoft Docs (note the limitations, which is another reason to keep them separate)
Cheers,
Lain
I think you've misunderstood how UPN suffix routing works in Active Directory, and it's relationship to Exchange.
Also, knowing that Company A is also on Exchange Online and not Exchange Server (which is on-premise) helps.
I'm going to make what I expect is a safe assumption here: Company A is likely running AAD Connect for synchronising objects from on-premise Active Directory to Azure AD.
So, while my preferred option your scenario would be the Azure AD Domain Services model from above, you can "shoe horn" in other less desirable solutions. The thing is, these other options clearly run against the principles of legal separation, but I've mentioned that enough already and won't bang on about it again here.
What I would do - in line with what I suggested initially when I was guessing what the two company's looked like - is that you add Company B's domain name into Company A's forest as an additional UPN suffix.
What this does
The userPrincipalName can end with the new suffix, for example Email address removed.
What this does not do
This does not impact the server-side configuration of mail in any way, shape or form.
What you need to do with AAD Connect
Filter or scope out any accounts aligned to "@companyb.com" so that it ignores them entirely. You can do scoping using the AAD Connect configuration wizard easily enough. Filtering involves some more steps but offers more control over what it synchronised.
This gives you the easiest configuration to manage because you are not integrating Company B into Company A from a mail perspective at all.
The biggest downside to this approach you've taken with putting Company B's users into Company A's forest is that their passwords will not be in sync with their password from Azure/Office. The Azure AD DS trust model avoids this.
The Microsoft links from above explain more advanced models, such as the single on-prem forest to multiple Azure AD tenant model, but I'll leave it to you to read those links as there's a lot of cause-and-effect considerations for you to plan around.
Cheers,
Lain