Forum Discussion
Set AD User with External Email Address
I am setting up a co-lo for 2 companies in 1 office space. These companies are sister companies but infrastructure has been separated for legal reasons but we are converting into a hybrid office environment where Company A works 2 days at the office, then Company B comes in 2 other days to work in the office.
Company B network will be the primary on-site and Company A will be cloud-based. I want to import users from Company A into Company B but instead of having Company B's email addresses I want to call out their email address so any emails will route to their Exchange Server. However, I am running into issues doing this....
If I set their email address as Email address removed in any of the following attributes email address, ProxyAddress, or mail it fails to route the email to their Exchange server. I ran a message trace on Company A and Company B to track down the email but it does not show on Company A's message trace. On Company B, the message trace says it was delivered. What I found was that Company B's domain assumes it is an internal route even though that domain normaclature does not exist.
How can I call out the companyb\user email as Email address removed? There has to be a way to make this possible. I have a script setup to email users when their passwords are about to expire or MFA passcodes, etc. that creating a mail contact will not be the answer...
This is one messy setup with some real hurdles, but here's some thoughts on the specific mail problem you've outlined.
First, some assumptions I've made from what you've written (in case I've misinterpreted anything):
Company A
- Has existing on-premise Active Directory
- Has existing on-premise Exchange (not hybrid)
- Does not have an Azure tenant (meaning no AAD Connect)
Company B
- Azure AD-native (meaning no on-premise Active Directory and therefore no AAD Connect)
- Exchange Online native
On-premise Active Directory
This is the one that doesn't make a lot of sense given your statement about the legal separation requirements.
The recommended solution in such a scenario is to have separate forests for each company with either a one- or two-way trust between them (I can't recommend one over the other as there's not enough information in the question to really say.)
The only real purpose I can see for "importing" (it's really re-creating if things are truly separate) Company B's users into Company A's Active Directory is to allow them to log onto computers joined to Company A's on-premise Active Directory. If there's more specific requirements, it might pay to share them as being left to assume creates significant margin for error.
What two separate forests provides is roughly the recommended amount of administrative separation between the companies (though sharing computers clearly undermines this, as does the trust configuration between forests, but it would seem you'd have to accept these limitations) while allowing staff from Company B to log onto and use Company A's client machines.
You also get implicit e-mail domain name separation since the forests and domains will (unless someone makes a mistake) have separate namespaces.
The one issue that's going to hit users whether you take this model or an alternative (such as living in the same forest but adding Company B's namespace as an additional UPN suffix - which I'm not going to speak to here at this stage as that's an even worse model than what I've just put forward) is that they will have two passwords to manage: one for their on-premise forest and the second for Office 365/Azure - and this is probably their main one from what you've described.
There's a lot more that could be fleshed out for just this Active Directory requirement but doing so requires further assumptions and trying to cover all the options available just isn't feasible.
On-premise Exchange versus Exchange Online only
If the assumptions about neither company being hybrid are correct, then really, the two mail environments shouldn't be mixing at all, meaning there are no routing issues or mail domain namespace conflicts to deal with.
From a Company B user experience perspective, they just start Outlook and connect to Exchange Online. Because you don't have single sign-on in this scenario, they'll be asked for their password but that's expected as part of this backwards-facing model. You'd likely also have some DNS work to do to deliver Outlook autoconfiguration but this isn't hard as it's just duplicating the existing external records with the same names and values (though it does incur an additional administration area and potential point of failure.)
With in both Exchange environments for Company A and Company B, nothing should exist for the opposing company. So, no accepted domains, no connectors - nothing. It's a straight Internet routing scenario.
Other stuff
For example things like file servers, printers (only if they require securing via ACL's) and what not.
If this stuff is also to be shared, you might even want to go one step further and create a third forest to act as a resource forest. But I've already said a lot based purely on assumptions and I don't want to spend more time fleshing this one out other than to say it's one way you can better promote legal separation requirements.
Exceptions
I've had to make a number of assumptions in order to be able to say anything at all but you do give away some suggestions that you have set up some kind of infrastructure cohabitation rather than the recommended administrative separation from above.
If you can provide further clarity around the assumptions above, that will help a lot. For example, if you have already done some importing of Company B's users into Company A's Active Directory forest (not a good approach but it sounds like this may have happened already) then that points us back in the direction of adding additional routable UPN suffixes - which I alluded to earlier.
Even in this scenario, this doesn't require the cohabitation of on-premise Exchange. And if Company B is indeed Azure-native then you don't want to make things more complicated by trying to set them up as hybrid Exchange anyway.
That said, if you are looking to allow Company B's users to make use of Company A's on-premise Exchange environment then this gets a great deal more complicated and impacts both companies.
My advice purely based on the legal separation comment is keep everything separate as described above. Doing this means you have no reason to script anything to do with contacts or mail-related attributes. But again, this is also based on the assumption that neither company is hybrid already.
Once you start sharing mail environments and forests/domains, you really aren't delivering against legal separation at all.
Summary
You can achieve office cohabitation where Company A owns everything and Company B just comes in to log onto Company's computers.
This does not and should not result in Company B's users being created in Company A's domain (or even forest, ideally). By virtue of this, you should not need to be scripting anything at all to do with e-mail attributes. This is only necessary if you have folded Company B's users into Company A's Active Directory and Exchange environments.
If this is what's been done then you would need to explore adding a new Active Directory routable UPN suffix for Company B into Company A's forest. Even in this scenario, the mail environments should remain entirely separate and Company B's on-premise Active Directory accounts should not be Mailbox- or MailUser-Enabled at all. Keep things entirely separate and let Internet routing do its thing.
If Company B's users have been folded into Company A's Exchange (on-premise) then this isn't a good end result and I'm leaving that in the "too hard" basket for now.
Cheers,
Lain
My apologies for the delayed response, been hectic at work with our consolidation. Let me help give more insight as to the current setup.
Company A
Existing On-Prem AD
Existing AAD
O365, no Exchange On-Prem
Company B
O365, no Exchange On-Prem
Existing AAD
no On-Prem AD, all in Azure
I have a two-trust between both companies. We have Company B's users imported in Company A's AD to be able to login and reduce IT Overhead given they are both small companies. I have moved Company B's workstations into Company A's AD but not their servers in the cloud.
I have setup a site to site VPN between both domains so users in Company B can still access their cloud resources. I do not want to add UPN suffix into the current AD environment as this will cause more headaches than what I care to have given this is a 1 man IT show. Besides if that was the case I would have to migrate SPO, O365, etc. which is a hard stop for me.
The main purpose of wanting to add Company B's email address to the users account on Company A domain is to route emails for self service passwords and alike.
Let me know if you need anything further clarified. I know it's a cluster but doing the best with what I got.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
