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.
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 “something@company.com” 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
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
Great article. Well documented and much-needed. Thank you.
Thanks Trey, I appreciate the feedback.
If the UPN is changed to match the SMTP address, then the samAccountName attribute will be changed as well?
Anry-
No, the samAccountName can remain different from the front part of the UPN.
Thanks
Joe
I guess still we can keep the UPN same alternate email, and then UPN different to primary SMTP.
This way login confusion for users with UPN vs EMAIL is solved right?
Lalith-
If the UPN matches one of the user’s proxy addresses as opposed to the primary SMTP address, it unfortunately creates the same issues. Ideally you want your UPN to match the primary SMTP address to minimize confusion.
Hi Joe
Really useful summary of the issues.
A lot of these issues come down to AD data quality.. An Office 365 engagement is a very good opportunity to get the business to buy into the process of spring cleaning AD.
Is there any limitation if we do not match UPN with primary SMTP; but we use useraccount@domain.com.
Our users have primary smtp as firstname.lastname@domain.com while their login ID is xxx11. we are planning to change UPN- xxx11@domain.com (SAMACCOUNT@domain.com) will it be an issue with Office 365?
Currently we do not use office365 but planning to use office 365 in future, Our users are more familiar with SAMACCOUNT NAme and our application also use SAMACCOUNTNAME; that is the reason we prefer to use USERLOGON NAME as the UPN domain Suffix.
If your UPN does not match the primary SMTP address, you will experience all of the potential issues/confusion in the article. You can still keep your samaccountname as xxx11 and change just the UPN to match the primary SMTP address and that would generally be the recommendation.
Thank you for the summary, Joe. In our environment, we have always automatically updated Primary SMTP email addresses when student’s names change. This was safe for email, because we can just bump the previous email to a proxy address. But it sounds like now we would have to rename AD and O365 UPN’s to match the new email as well? Is this creating a problem for anyone?
Al-
Yes, ideally you would want to keep the UPN the same as the primary email address. Otherwise you run into the scenario where the user’s UPN (and their Skype4B SIP address) is their old email address and the ambiguity that occurs when Office 365 prompts the user for their “email address’ (when they really mean UPN).
It’s not perfect and there are certainly some challenges to changing the UPN along with the SIP address but in the end, it should provide for a better user experience over the long term.
Thanks for the comment!
Joe
Is it possible in Active Directory to identify a UPN logon, vs a sAMAccountName logon? We definitely have applications that utilize the UPN for login, but know one truly understands the scope. I would like to deal in reality if possible and having metrics would be invaluable guidance.
Jonathan-
Unfortunately, I don’t believe that Active Directory really distinguishes between the two login methods. For applications, you can usually tell in the application configuration what values are acceptable; you’ll also find that many applications will be connecting to AD via LDAP and the authentication method will be obvious in the configuration.
What is the benefit to adding the sip:user@domain.com to the proxyAddress in the AD user attributes? Is it necessary when using Skype for Business online?
Stephen-
It is not necessary to add the SIP address into the proxy addresses. When you assign the Skype for Business license, it will add that into the cloud proxy addresses and then if you have hybrid write-back enabled for Exchange, it writes it back to the on-premises object. There should be no reason to populate that yourself.
Thanks
Joe
We have some users in a few branches, that because of business requirements, they have to have their primary smtp address different from our current upn (which is the default smtp address for most). Changing the upn for them is not and option, and when such a user logins to skype for business, theres warnings about the primary smtp address not matching. My question is, can i just ad an alternative upn and have them login to skype with that? Will I have to add the new domain to the domains in O365 admin, or should it just DirSync fine?
Thanks in advance.
-Dave
Dave-
Unlike SMTP addresses, a user can only have a single UPN. If you’re thinking about using “alternative login”, that’s an all or nothing configuration for your domain and comes with it’s own set of limitations and would not be advisable. I have a post titled “The Limitations of Alternate Login ID” which covers many of them.
I would really try and remediate the applications that are stopping you from changing the UPN to match their email address. While it’s not an absolute requirement that the UPN matches the email address, I suspect it will just be a increasing list of nuances that you’ll encounter with those users.
Thanks
Joe
Hi Joe, I didn’t mean O365 alternative login. In your blog above, you mentioned adding alternative UPNs in active directory. If I add an additional UPN in active directory, should I be set?
Thanks again for the quick reply.
-Dave
Dave-
When you add the additional UPN suffix to your AD forest, you will then have the option of changing the users UPNs to be the same as their primary SMTP address (which is different than the rest of the org). You will still need to change their UPN to match but at that point you will be in the ideal configuration.
Thanks!
Joe
Hi Joe, great article and information. How will changing the UPN to SMTP address affect a multiple forest environment where all the email addresses ends with user@abc.com? That will mean in each domain in the different forests, the UPN will end with userX@abc.com? Will AD FS still be able to authenticate users from different forests in this scenario?
Isaac-
Environments where there are multiple AD forests sharing the same SMTP namespace can be a problem. In this situation, you’ll have issues trying to add the same UPN suffix to multiple forests, especially if you have trusts in place and are using AD FS for authentication. While the “Alternate Login” feature would help here, it comes with its own set of problems and I would not recommend it.
Without knowing all the details, you’re probably in a situation where you won’t be able to make the UPN match the SMTP address without changing the SMTP addresses such that they do not overlap the AD forest boundaries.
Thanks for the comment!
Joe
Excellent article, with much better detail than Microsoft’s docs provide. The only issue I don’t see covered is DNS. If your local domains are also public domains, does this mean you now have to manage split DNS settings?
Currently, in my domain all users login to @local.company.com. We have multiple SMTP domains, so I would need to add an alternate UPN for company.com, othercompany.com, thirdcompany.com, etc. None of these, including company.com, have internal AD DNS entries at present. I don’t want to start adding things and suddenly find that our websites are suddenly unavailable to users, either internal or external . Do you know of any documentation on the proper DNS setup for this?
Michael-
I can’t think of a dependency that would require you to have internal DNS zones for the additional UPN suffixes. You should be fine without any changes to DNS.
Thanks for the question and feedback.
Joe
Joe,
We are in the middle of migrating to 365. And i am having issues with reconfiguring active sync and outlook profile
Our internal UPN has always been company.com\first3lettersoflastname.first
So all our activesync devices were configured with company.com as domain and SmithJ as the username.
Our primary smtp has always been first.lastname@externalcompany.com
notice the externalcompany.com domain is not same as our internal AD domain name of company.com
Our partner has told us we need to first change the suffix to match our external tenant name which is externalcompany.com, that part was done and now users are syncing to cloud correctly via ad connect.
Once i migrate the user to the cloud though their phone and outlook client stop working. even if they retype their credentials
company.com\SmithJ
for mobile devices
its only until i manually reconfigure the email server to m.outlook.com and the username to match the new upn smithj@externalcompany.com that it starts to work.
same goes for outlook insdie the company.
shouldnt this be taken care of automatically?
fyi we are a hybrid environment with an onprem hybrid server.
my autodiscover records point to my hybrid server internally and externally.
any thoughts?
Roy-
Assuming you have the necessary patches in Exchange for the ActiveSync redirection (SP3 RU9 for 2010, CU8 for 2013), there are some situations where it won’t work. If you’re changing UPNs, there’s a good change it’s not going to redirect for you if the old ActiveSync profile was configured with the old UPN.
The credentials should be entered as smithj@externalcompany.com for all things related to Office 365, users should not be trying to login with company.com\smithj.
The ActiveSync redirection capability was only added in March of last year, unfortunately it is not perfect and you may have fallen into the scenario where it doesn’t benefit you.
Thanks
Joe
So “theoretically” in a perfect world scenario, if i had the cu i needed in the 2010 environment then the phones should reconfigure themselves to use the smithj1@externalcompany.com and m.outlook.com for the server?
and confirming, the autodiscover service should be pointed to the hybrid server right? internally and externally?
Roy-
Yes, Autodiscover should be pointed to the on-premises Exchange internally and externally. While there is technically no “hybrid” server, it should be pointed to your most current version of Exchange with all of the appropriate settings for vDirs, etc.
As for your “perfect world” scenario, the redirect should work assuming the ActiveSync profile can still authenticate. If ActiveSync was configured with UPN and then you change the UPN in AD, the profile likely has a bad username in it now. Also, the redirect is dependent upon the device supporting a 451 redirect.
Some additional info here: http://blogs.technet.com/b/exchange/archive/2015/03/23/exchange-activesync-on-boarding-to-office-365.aspx
Thanks
Joe
Joe,
Thank you. yes we have a CAS server stood up that was configured as the hybrid server that talks to 365.
as for the upn change, only the suffix is changing. would this still require the device manually be reconfigured?
thank you
Roy-
I suspect changing the suffix would require manual reconfiguration if the original ActiveSync profile was using the UPN as a login.
thanks Joe
Great article. I want to know if i change the upn for users in AD, will it effect how they login to their machines. All my users login using domain\username. Also, all my users login to owa using domain\username and in outlook using domain\username. Will this upn change break all of these?
Seth-
Changing the UPN will not impact the samaccountname, the user can continue to login as domain\username for internal resources.
Thanks
Joe
Well played Sir
I’ve seen that having different UPN and SMTP also breaks IRM in Outlook (Office 365). You cannot read encrypted messages if your SMTP and UPN does not match. You cannot even read the ones you send. Changing UPN to match SMTP fixes this issue.
Joe, this is still an excellent article. I am just sorry I didn’t find you sooner! Hope you are still batting them out like this! Thank you.
Hi Joe,
This is great article, I found this post as I was thinking the real login for O365 is actually the UPN in Active directory. But I don’t know how does this happen, is it possible for you to write another article about why UPN is becoming the login in O365? I am so into the reason but still haven’t figured it out.
Joe,
How would you handle an organization that has multiple forests with multiple domains being consolidated into one forest with multiple domains. Currently all domains have separate email extensions and normally more than one. One of the many SMTP addresses for each user includes: empID@mncppc.org. as well as first.lastname@ xxx. Currently these domains are listed in Office 365 and UPN will be changed based on the users job and department.
Moving forward we are at the cross roads of creating and implementing AD-2016 along with new DCs. We plan to migrate users and objects and rely on HR as our source for employee data but we are at a standstill with standardizing UPN and whether we really have to to ensure single signon integration with other SAAS, IAAS services..
What do you think?
Great article, still relevant. Covered all bases.
Sorry. My company has 150 SMTP domains all contained within a handful of recipient policies and all in active use. Am I really going to add 150 additional UPN domain suffixes to my AD? Trying to align UPNs to primary SMTP address sounds cute but the reality is it’s not feasible for most corporations who want to limit exceptions and differences. I have been an AD Consultant for nearly 15 years, and have heard the “login with UPN” thing preached many times but how many users actually listen and do it? I would say less than 1%. If I put my Exchange/O365 hat on, I’m not sold on the benefits anyway