Since the early days of Office 365, the discussion of changing UPNs has been had between consultants and clients. The discussions range from “what is a UPN” to “this line-of-business application uses UPN for login, the application would need to be reinstalled and the vendor is no longer in business”. During Office 365 deployments, I always try to follow the approach of minimizing change in the environment. However, there are some changes that are absolutely necessary and others that, while not absolutely necessary, will make your life easier down the road; this issue falls somewhere in between. Below is some of the background around changing UPNs and why it should be strongly considered if possible.
BACKGROUND
Sometimes it’s good to start from the beginning… The UserPrincipalName (UPN) in Active Directory is separate from the samAccountName and while they may contain similar values, they are completely separate attributes. If you’re looking at an account in Active Directory Users and Computers (ADUC), the “Account” tab displays the UPN as “User Logon Name”. ADUC does something a little odd in that it displays the UPN as two separate fields, one that is free text and the other that is a dropdown. These two fields combine together to create the userPrincipalName attribute in Active Directory, they are not stored separately. Occasionally we’ll find that the UPN is actually blank as a result of accounts being migrated from legacy systems or they were setup via a scripted provisioning process that did not write the attribute; it in fact is not a required attribute although most provisioning methods should, and do, populate it.
WHY DO WE CARE ABOUT UPN?
The on-premises Active Directory UPN becomes your login for Office 365. In addition to the reasons stated later in this article, telling your users to login with their “email address” is easier to communicate than logging in with their UPN (something that is not their email but looks like one). Yes, Microsoft did release a feature last year called “Alternate Login ID” that allows you to use an attribute other than UPN for your Office 365 login, but that feature comes with a list of limitations that you should be aware of. Areas of Concern Changing the UPN doesn’t mean anything happens to the samAccountName which means unless the user is logging into their workstation with the UPN, there will be no change to the user’s workstation login experience. Given that we’ve been conditioning users since the days of Windows NT to login with “DOMAIN\username”, it’s not real common to find users logging in with the UPN. The biggest concern with changing the UPN generally falls on third-party applications that have been integrated into Active Directory. If your organization doesn’t manage directory integrations well, this is where you are left with some unknowns as to the impact of changing the UPN. For the most part, I advise clients to try and inventory applications that are leveraging Active Directory for authentication and at a minimum, dive deeper into the largest and most important applications. Clients are often scared of the unknown but then as we dig into the applications, in very few cases do they generally use the UPN. That’s not to say that an admin in your organization didn’t take the approach of using UPN for every application, but it’s not real common.
BUT MY ACTIVE DIRECTORY DOMAIN IS CALLED “COMPANY.LOCAL”
In the days of Windows 2000, we all did this; we created a “company.local” Active Directory forest, likely as an “empty forest root”. I probably setup hundreds of Active Directory environments like that. Much like the technology, many of the “best practices” have evolved and we don’t see new deployments like that as much anymore; however, there are plenty of those forests still around. Even if your Active Directory isn’t “company.local”, there’s no guarantee that it matches your SMTP domain; on top of that, you very likely have multiple SMTP domains in use. Adding additional available UPN suffixes to your Active Directory forest is quite simple; Microsoft has a KB article (KB243629) that covers the process. This change is pretty non-intrusive in that you’re only adding an additional option to be used as a UPN suffix, you’re not changing any accounts just yet. The only consideration here is if you have another AD forest in your environment with the suffix that you’re looking to add, then it becomes a more in-depth conversation.
CHANGING THE UPN
The actual process of changing the UPN is relatively easy to do. Since we’ve made the statement that the UPN will be the same value as the primary SMTP address, we already have the source data on the same object we’re looking to change. We just need to take the mail attribute and write it to the userPrincipalName; there’s no shortage of PowerShell scripts available that can make this change for you. Keeping with the “minimize changes” approach, you only need to change UPNs for accounts that will be logging into Office 365. There is no reason to change service accounts or other accounts that will not be using Office 365 services.
WHAT IF WE DON’T CHANGE THE UPN?
In some environments, it’s just not feasible to change the UPN due to existing application dependencies or other constraints. If that’s the case, below are some things you’ll want to be aware of.
USER CONFUSION
Your users will need to understand what their UPN is and that it is the login for all things Office 365 related. As you’ll see below, there are some prompts that will say “enter your email” but they will in fact need to use their UPN. You may want to consider making their UPN an alternate email address on their account as users are bound to get confused here; it won’t help them login but it will if an email response is expected and they enter the wrong value. Skype for Business Online The UPN in Office 365 becomes the default SIP address in Skype for Business Online. You can change this by populating the SIP address in the on-premises Active Directory and you’ll want to do this. Your SIP address should match your email address, especially if you plan to communicate with federated partners. Office ProPlus I noticed a while back that Office ProPlus will occasionally prompt the user for credentials either as part of logging into the application for activation or the “call us overprotective” prompt. When it prompts the user for credentials, the prompt explicitly says “Type your email address”. Unfortunately, Microsoft is making some assumptions here because they really mean “type in your Office 365 login (UPN)”. You will need to communicate to your users that this is really their UPN despite what the prompt says to enter. Mobile Applications Much like Office ProPlus, the iOS versions of Office and OneDrive prompt the user for their email address and again, they really mean the UPN.
ACTIVESYNC
Most ActiveSync clients will automatically configure using Autodiscover. When your UPN matches your email, you basically just enter in your email and password. When they don’t match, you enter your email and password, then you’ll get prompted to enter your login (UPN) to actually authenticate. You can see how this would be confusing for the user to now enter in two “[email protected]” values that are similar but different. They will also need to break the habit of using DOMAIN\username for the login to cloud services (aside from some scenarios where you’re on the internal network and using AD FS).
SUMMARY
- While not an absolute requirement, changing the UPN to match the primary SMTP address makes everything easier
- Be kind to your end users and they’ll be kind to your helpdesk ticket queue
- Some applications make the assumption that your UPN is your email address and may provide inaccurate prompts
