Same alternate UPN suffix in two forests connected by a trust

  • Last Post 11 January 2019
BrianB posted this 06 February 2018

All:   What are the issues with two forests having the same alternate UPN suffix and connected by a two-way trust? We use ADFS for SSO to Office 365 tenant. The tenant will be migrated to use the other forest and a new ADFS farm for SSO auth at some point in the near future.   I can elaborate if needed but don’t want to bore you with details unless wanted.

    Brian Britt  

Order By: Standard | Newest | Votes
cduers posted this 06 February 2018

From my experience with two forests and a trust – we could not have the same suffix in use in both.


We have had to have the users in each forest use a separate sign-in until we are able to complete a domain migration\collapse (in progress), at which point everyone goes to a single UPN and then they are happy

for 10 minutes. I don’t remember the exact specifics but I can tell you it absolutely wasn’t workable to have users in both forests use the same UPN – even with various ADFS rule customizations and using a different source anchor attribute (than UPN) for the

current (coexistence) phase. I think SSO just didn’t work for half the people – there may have been other issues as well.



Christopher Duers

XL Catlin, Identity and Security







amulnick posted this 06 February 2018

Not sure why you would want two forests you control to use the same UPN suffix.  I'd be interested in a few more details.  
There is no particular reason you couldn't use the same suffix in terms of rules.  I would expect your sso solution to be confused by it though.  Grabbing the UPN definition from MSDN, there is nothing that specifically prevents you from doing that, but once the check is made to an authoritative GC, I'd expect when the user is not found in the forest checked, that the attempt would fail. The result would likely be intermittent failure depending which GC your SSO solution checked first.  Just a guess on my part - I would not want to do that due to the management headache. 

UPN Management

A UPN can be assigned, but is not required, when a user account is created. When a UPN is created, it is unaffected by changes to other attributes of the user object such as the user being renamed or moved. This allows the user to keep the same login name if a directory is restructured. However, an administrator can change a UPN. When you create a new user object, you should check the local domain and the global catalog for the proposed name to ensure it does not already exist.When a user uses a UPN to log on to a domain, the UPN is validated by searching the local domain and then the global catalog. If the UPN is not found in the global catalog, the logon attempt fails.


barkills posted this 06 February 2018

Kerberos name suffix routing is at the heart of this question, and you’ll want to get yourself educated on it.


Basically this is giving the trust object in one domain “hints” to help find trusted domains. See netdom.exe /addTLN.


From a high-level, I believe when the local DC is presented with a domain suffix, it hunts (via the GC) for an object with it, then checks for a name suffix on a trusted object. I suspect there are some cases

where this simple description is not exactly what happens, as I’ve seen some very odd results that I couldn’t follow. One thing to keep in mind that this mapping business is not just specific to user accounts, but also servicePrincipalNames.


To the other person who was asking why you’d want to do this … DNS domains and Windows domains aren’t necessarily 1:1 aligned—they serve two different purposes. At the UW we have thousands of DNS zones, but only

~100 Windows domains. Any given computer gets its FQDN based on who owns the computer, but joined to a Windows domain based on other criteria. Even within our central IT org, we’d regularly have computers from the same DNS zone across 3 or 4 Windows domains.

Of those thousands of DNS zones, only a few have routable email (MX records), but lots of Windows domains which might want to use those as UPNs (so they don’t have a mail and UPN value which differs). I could go on and on about scenarios here. The bottom line

is that these kind of scenarios happen in environments which are not boring. ;)





BrianB posted this 06 February 2018

Al, Chris:


Here is more detail. Bear with me as I try to explain. I am trying to determine impacts if any of using the same UPN value in two forests with a trust relationship.



Years ago I created an alternate UPN suffix in AD that matched our email suffix to comply with Office 365 requirements.


Fast forward a few years to 2016 and we were told we are divesting from our hospital and becoming separate orgs. – Org 1 and Company 1.


Each of our orgs are moving out of the shared AD and LDAP space at our own pace and with different plans. One is migrating and the other is green-fielding

and rebuilding. The intent is to dissolve the old shared AD environment in the future and go about our separate ways. Lots of discussions were had, and good reasons were presented as to why we are both building new rather than one keeping the old and the other

moving out that I won’t go into here.


The Org 1 is keeping the existing O365 tenant and email suffix while the Company 1 has obtained their own O365 environment and new email suffix.


Org 1 plans are to establish a trust relationship with the newly built AD forest and, using migration tools, migrate to the new AD forest. Applications

will either be rebuilt or repointed to the new environment in a cutover.


Org 1’s O365 tenant will be migrated to the new AD at some point after the Company 1 has moved all of their own users mail boxes and shared mailboxes

to their own tenant.


Since Org 1 owns the email suffix and are taking that with them, at the point of Exchange/O365 migration, my plan was to remove the alternate UPN suffix

from the shared AD forest and create it in the new and cutover our O365 and Exchange to the new environment.


The requirement in O365 for the UPN suffix and the email suffix to match still exists, as far as I am aware, hence the need to keep the alternate UPN.



There is a feeler put out about the possibility of the Company 1 continuing to use the existing shared environment for a few more years along with its

alternate UPN that matches the email suffix. This is because there are some apps that utilize the UPN value for identification and their “move out” efforts are being delayed.



Possibly unrelated, but, there is some sort of issue, I do not know how and why, where their O365 tenant keeps using the old shared ADFS for sign-on

to their O365 tenant. Company 1 set up a PING Identity SSO for their own tenant but we are being told that the ADFS setting is ‘Hard-Coded’ into their tenant. I assume their tenant must have used the shared AD space at some point, but I am unsure. (This is

preliminary information that I just heard about. So I am unsure of the how and why this is happening.)



If the Company 1 were to continue to use the alternate UPN, I think this will affect the Org 1 efforts to migrate to the new AD forest. My reasoning

is because the apps that utilize the UPN value may need to be reconfigured, or we would have to use the domain UPN that does not match the email suffix. This would result in a fairly massive communication campaign to tell Org 1 users which UPN value to use

after they have been using their email suffix for several years.



My belief is that if we can’t have two forests with the same alternate UPN suffix, then we will be unable to swing Org 1 O365 tenant to the new AD forest

until they can exclusively use the email suffix as an alternate UPN suffix in the new AD forest for sign-on. If Company 1 apps are still using the alternate UPN value for sign-on (internal or cloud) it can’t be removed.


So the simplistic question is, “Can we have the same UPN value on two forests with a trust relationship”?


Brian Britt




BLCG posted this 11 January 2019

Hey Brian,


Were you able to come to a resolution with this? 


We have a similar issue that we are wrestling with coming up with a solid migration path to:

O365 Tenant 1 has Org1 and Company2 in it. 

Company2 is splitting off onto a new AD and O365 tenant, Tenant 2.

Org1 is maintaing ownership of Tenant 1.


We are trying to figure out how to gracefully move things over from Tenant 1 to Tenant 2.  Obviously at some point there will be the need for a hard cut seeing as you aren't allowed to have the same namespace in multiple tenants but we are tying to find a good way to do it and would like to hear your experiences.