06 February 2018
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”?