Introduction: Changing your UserPrincipalName (UPN) in an Enterprise

     With your company firmly setting its sights on the expanded use of Microsoft 365 services in its future roadmaps, you may be one of the many organizations where their journey begins with a critical first step: migrating your UserPrincipalName (UPN) to a routable domain. This move is pivotal for leveraging the full suite of Microsoft Cloud's native features, a key to unlocking enhanced productivity and collaboration tools within your enterprise. While change itself is rather straightforward, the complexities of your organization’s tech landscape can make this a daunting and risky task. This blog post aims to succinctly guide you through the complexities of UPN migration, a necessary transition for any organization looking to make the most of Microsoft 365's capabilities.

 

What is a UPN?

At a high level, the UPN is one of the attributes within Active Directory that is used to identify a user when they log in to AD related resources. JohnDoe95@cloudtechbaker.com

It is composed of two parts, the prefix and suffix.

Breakdown of the Prefix and Suffix of a UPN.

You may think this looks a lot like your email address, and you may be right in most cases. However, from an Active Directory perspective, these are two different fields in the AD Database, which means they can be set to different values.

Output of the three attributes from Active Directory.

As shown in the screenshot above, and of course, to complicate things further, there is even a third user attribute used by legacy Windows services that predates Active Directory. It goes by many names (Logon Name, Network ID, username, etc.), but for this blog post, we’ll refer to it as its formal attribute name in AD; sAMAccountName. Sometimes these three values can be set to similar fields, sometimes they are completely different than one another. It really depends on your companies’ policies, and I implore you to familiarize yourself with them now before you dive down this rabbit hole as it will make your understanding of the rest of this post much easier.

Why does this matter?

At a very high-level, it’s because UPN is used for authentication by Microsoft services, even though Microsoft asks for “Email” in the prompt to users:

Microsoft Splash Page prompting user for Email, instead of UPN.

What it really does is check this value against the UserPrincipalName. In my example the end-user’s domain is set to the suffix “cloudtechbaker.com” which happens to be a routable domain. Meaning there are public DNS records for this for Microsoft to check against and validate that you legitimately own this domain. It then routes you to the appropriate tenant space to complete authentication.

But what if you don’t own the domain? How is that even possible? Well, the perk of having an internal private Active Directory is that it’s isolated from the real world, but that means that since it’s isolated, you could have doppelganger scenario where your internal domain which never sees the light of the internet, has a domain owned by another company.

I’ve only seen this in a few scenarios, so hopefully you’re not in that space; more likely though, your domain was created back when the recommendations for internal domains was to use the pseudo-top-level-domain “.local” which was Microsoft recommendation back in the day. We call this a pseudo-TLD because for all intents and purposes, within the internal network it is in fact a TLD, but as soon as you step outside the internal network of the organization and try to talk to the internet, this is not routable, meaning Microsoft’s Azure and 365 services cannot find you and verify you own this domain.

Regardless of which scenario you’ve found yourself in, if you can’t prove to Microsoft that you own the domain, they’re not letting you use their Cloud with said domain. Microsoft provides several Identity Models, and alternatives, but they don’t work as a blanket for all the technologies they offer. Leaving the most viable option as changing the UPN suffix. If you’re curious about the other options, let me know and I’ll cover that in a separate blog post.

 How do I solve this?

For this blog series, I’ll be working with the scenario below:

An enterprise organization named Cloud Tech Baker has its internal domain set to cloudtb.local and they have important roadmap items that require changing the UPN to match their external domain; cloudtechbaker.com. Specifically, they want to move towards autopilot and JAMF for provision end users their MacBooks and Laptops to streamline the onboarding process. The caveat though, is that these new laptops need to access on-premises resources such as files servers over SMB which house all the sensitive financial information the company maintains. To complicate things, the company has over 400 in-house applications that have their identities managed across different identity platforms: ForgeRock, ADFS, and Okta. These applications are managed by the engineering department which consists of 1500 employees broken into groups of 3 to 5 teams each assigned to own the application. Some of these applications are also legacy and may even be authenticating directly against Active Directory, so teams may not be familiar with that mechanism since it’s been operating for so long. The company also needs to have zero downtime, and you need to find a solution that keeps the project on target, while still meeting the needs of each application.

 

We’ll break the blog series down into several key Phases, I will update this blog with relevant links as they’re posted:

1. Planning: Breakdown of the strategies and methodologies to reduce risks in this project.
2. Discovery: Where we communicate with the application teams on what’s need and work with them to remediate any impacts caused by the application.
3. Communication: Developing the communication strategies to ensure a successful migration.
4. Pilot and Preparation: Changes needed to support the applications in all the identified scenarios, and pilot of the UPN change.
5. Cutover Process: Strategy/Scripts for cutover and rollback