There’s quite a few of us that started off deploying Small Business Server (SBS2008, SBS2011) environments back in the day, loving the handy all-in-one package taking care of everything from Active Directory and Exchange, to disaster recovery and business continuity. However, some of these old environments are starting to catch up with us. I wanted to open a discussion on a big issue I had a couple years ago in one of my first migrations from SBS 2008, to Windows Server 2012 R2 with the Essentials Experience role installed, with Exchange Server 2013.
As most of you know, SBS comes packaged to push “.local” domains on initial domain configuration. This used to be considered best practice, and most of us even configured .local’s on non-SBS environments. This has never really posed any problems for us I.T. guys, except for a few configuration considerations when setting up Outlook clients, DNS, etc…
Now if you’re like me, another thing I always configured, was user accounts that didn’t match e-mail addresses. An example would be “John Doe”, with the username of “JohnD”, and the e-mail address of “[email protected]”. Also, our buddy John Doe would have a AD UPN [email protected] (this was automatically populated on user setup)
User’s Name: John Doe
SAM Account Name: INTERNALDOMAIN\JohnD
Username: JohnD
AD UPN: [email protected]
E-mail Address: [email protected]
I always liked this as it provided some protection if the users password ever got compromised (in a phishing attack, fake e-mail logon page, etc…), as the password could not actually authenticate when using the e-mail address as a username (the username was never actually provided in the attack, only e-mail).
Now let’s flash forward to this migration from SBS 2008, to Windows Server 2012 R2 with Essentials Experience, and throw Exchange 2013 in to the mix. Right off the bat, everything is working fine, Outlook 2010 is working great, Outlook 2013 is working great. Then BAM, Outlook 2016 comes out!
Outlook 2016 does not allow manual or custom configuration of Exchange accounts. They do this for “reliability” and ease of configuration. This means that you HAVE to have autodiscover setup, and working fluidly. No more manual configuration. Internally inside of the LAN this is all automatic if you configured Exchange properly, but you will have to configure autodiscover externally.
Internally on the LAN, Outlook 2016 clients have absolutely no issues, and authentication is working fine (no password prompts). However, when configuring external users, while you can eventually get it configured, the user is constantly prompted for credentials on every Outlook start.
On these password prompts, you’ll notice it’s authenticating for the users e-mail address. In this example, it’s asking for “[email protected]” and you enter: “INTERNALDOMAIN\JohnD” and their password, it work for the session, but keeps prompting on every fresh Outlook start.
I did massive amounts of research and seriously I could not come across one article that actually provided all the information I needed, it almost seemed as if this problem was specific to this single environment. Of course, this makes me think I have something configured incorrectly, and I literally spend forever searching for information, checking my VirtualDirectories on my Exchange server, checking logs, wasting tons and tons of time.
Finally after checking my configurations 6-10 times each and spending weeks, I realized it had nothing to do with anything configured incorrectly.
Outlook 2016 does all the configuration automatically, and expects to find everything it needs via auto discover. Putting it simple, the user’s UPN must match their e-mail address.
This means we have to change John Doe’s Active Directory UPN to match his e-mail address. The SAMAccountName still remains the same, so his login to his computer will not change, however after the change he will now be able to log in both with INTERNALDOMAIN\JohnD and [email protected].
First we have to add the UPN suffix (which is the actual e-mail address domain name) to the Active Directory Domain and Trusts. Instructions are available here: https://support.microsoft.com/en-us/kb/243629. Please note Microsoft has since deleted the original knowledge base article so I created a blog post to outline the instructions here: https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-suffix-to-an-active-directory-domain/.
After adding your e-mail domain to the UPN suffix list. When you go in to “Active Directory Users and Computers”, and view a user’s properties, you’ll notice in the UPN section, you can drop it down and change it from internaldomain.local, to contoso.com (using my example domains). You can also change the username inside of the UPN.
Essentially for Johny boy, his AD properties window now looks like:
User Logon Name:
[email protected] (we changed the name, and chose the external domain in the drop down to the right)
User logon name (pre-Windows 2000):
INTERNALDOMAIN\ JohnD (we left this the way it was)
John can now login either using “INTERNALDOMAIN\JohnD” or “[email protected]”. As far as John is concerned we haven’t changed anything and he still logs in using the same format he always has, totally unaware of any changes.
Surprise surprise, autodiscover is now fully functioning for this user. Not only for easy configuration on mobile devices (iPhones, Windows Phones, etc…), but he can now load up Outlook 2016 away from the LAN on the Internet, type in his e-mail address, password, and BAM he’s good to go!
I am a little bit unsettled in the fact that the e-mail address now becomes a fully accepted username on the domain (for security reasons), but I guess we’re stuck with that!
In short, our problem is:
- Username doesn’t match e-mail (JohnD username, [email protected] email)
- Running Outlook 2016 and forced to use auto-discover, repeated password prompts
- Running .local domain internally, while using different domain externally
In Short, to fix this:
- Add UPN Suffix to Active Directory
- Change users properties so that UPN matches e-mail address, DO NOT CHANGE the old DOMAIN\Username setting
Other Considerations:
- Password prompts on Outlook clients can mean a whole bunch of different problems totally unrelated to this configuration and issue. Always fully diagnose the issue and confirm the issue before applying fixes. Password prompts can mean authentication problems, problems with Exchange’s virtualdirectories, issues with autodiscover, issues with certificate configuration, etc…
- If this is your specific issue, you can write a script to run through and update the UPNs on all the accounts. I generally don’t like scripts touching user accounts, so I’m slowly rolling out these changes per user when upgrading them to Outlook 2016. Doing this one by one as we upgrade, allows us to make sure that none of their mobile devices are affected by the UPN change.
- Since we are changing UPNs, this could have a major effect on any 3rd party applications that integrate with Active Directory that use UPNs. Always test, and make sure you don’t break any integration points to your 3rd party applications or line of business systems.
In terms of real security concepts and boundaries, having a secret name is not a strong privacy measure and causes confusion when trying to verify authenticity. A name is an identity, a public item. A password is a private item. I don’t administer Windows systems if I can help it, but the e-mail being the fully qualified username is a good practice in terms of identity, integrity, and thus security. You may need to look at multifactor auth like yubico or strict IP firewall rules if authentication is your concern. Simplifying the username situation is a good thing overall. I haven’t read any of the rest of your extensive blog, so maybe you already agree with me. 🙂 Glad you got your stuff figured out.
Hi Nobody Special,
I totally agree with you 100%.
The comment I made about the benefit of the username not matching e-mail, was nothing but just a unrelated/semi-related comment, no relation to security policies or measures whatsoever. I don’t want it to be taken as advice.
This blog post wasn’t to address or advise on security policies, but to provide insight on an issue where companies are migrating to Exchange 2013 and deploying Outlook 2016, and in their current environment have e-mail address that don’t match the user’s usernames (non-standard, non-conforming e-mail address naming schemes), which post-deployment of Outlook 2016 causes password prompts on the client side, when Outlook connects externally from their network (and configures via the auto-discovery protocol).
Just hoping to help those who experience this as the issue. Why it occurs isn’t well documented (or maybe it is, but it’s hard to find posts/info discussing it, and why it occurs).
Cheers!
Thanks for that post, have had that issue on a few random people who I now realise (penny drop) are the early adopters of Office 2016.
Brilliant! Search a lot of site for this issue. Finally got the answer! Thank you very much.
Excellent article. 100% work. Before this i waste lot of time for this issue with different aspect like IIS virtual directories and exchange server authentication.
I’ve been beating my head against the wall for a full day trying to figure out why this wasn’t working. A hundred searches, dozens of Technet articles and posts, dozens of blogs, and this fixed it. Wish I could PayPal you a beer or something.
Hi Stephen,
Thank you for the article. I have the same issue. Unfortunately Microsoft has deleted KB article from the link for some reason.
Could you please explain what was in the link in here because they keep deleting things.
Many thanks,
Daniel
Hi Daniel,
Sorry, MS has been killing all of the KBs lately… I’ll update the post later with full instructions that were stated in the article. However to get you running I’ve put them briefly in this comment:
1) On your domain controller, open “Active Directory Domains and Trusts”.
2) Right click on “Active Directory Domain’s and Trusts” on the left panel of the new window that opened.
3) Select “Properties”
4) The “UPN Suffixes” window will open, simply type in an alternative UPN (your external domain name), and hit add.
5) Click apply, and close out.
Now you’ll need to update the user account to use the new alternative UPN instead of the old. Open the Exchange control panel, open the user mailbox, and you’ll be able to switch the user to the new UPN. Technically, after making this change, the users UPN should now match their e-mail!
[…] is also a follow up post to the article here: https://www.stephenwagner.com/2016/09/23/outlook-2016-exchange-2013-password-prompts-upn-and-samacco… as Microsoft has deleted the KB 243629 article which contained the original […]
Hi Daniel,
I’ve created a new blog post which outlines the instructions that were inside of the missing Microsoft KB article. The new post is available here: https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-suffix-to-an-active-directory-domain/
Cheers,
Stephen
There is an old tool called ADModify that is very useful for making these mass updates, and provides a way to roll-back the changes if necessary.
That’s awesome, thanks Chris!
I just want to say, thank you so much for confirming this for me… I’ve been looking around for around 6 hours tonight on autodiscover and this is literally the only post that seems to mirror the “Does nobody else have this problem????” with the domain.local.
I guess the UPN suffix should’ve been the first thing to test but seriously none of the articles mentioned anything about it.
Truly appreciate it, autodiscover working internal + external on desktops and mobile, yes!
Almost 5 years later and your topic is still saving lifes!
Thanks for sharing this knowledge, I spent long time reviewing virtual directory configs before looking at UPN.
Best regards!
[…] Outlook 2016, Exchange 2013 & 2016, password prompts, UPN and SAMAccountName troubles […]
Hello, I have a domain controller: domain.com, with an email server exchange.domain.com, I have added a domain.local and I have copied groups, users to domain.local. Now I need the exchange.domain.com to change to the new domain controller as exchange.domain.local. (Email domain is assumed to be @domain.com)
What should I do, can your help me?
Hello,
I’m not sure why you’d be doing this. Using “.local” domains is not recommended and I think it could be against best practices. You should be using “.com” for domains.
Alao, I don’t believe you can move an exchange server from one domain to another. Exchange stores most of its configuration inside of Active Directory, so I don’t even think it would be possible.
Years ago, many organizations were moving and creating new domains to get away from the “.local” domains, I’ve never heard of a situation where someone went back.
Could you explain what you’re trying to do?
Stephen
We do migration from Exchange 2010 to 2016 in 2022. We noticed some logins were not able to login into new Exchange. It appears users were using their email addresses to register with various MS services like Teams etc. and Outlook 2016 with later updates check those services prior to local Exchange. There is registry fix for that, but another solution was adding alternative email address and changing login name to match new email address. for example, for [email protected] we added [email protected] email address and changed login name johnd to john.d with suffice domain.com
Thank you for the articles, they helped us a lot.
While this is working perfectly for user mailboxes, I still find, that does not help with linked mailboxes, if logged in with another account in Windows (work perfectly if logged in with the same account in Windows). I have to provide the domain\samaccountname with the password for Outlook to start up. Does anyone know if this is intended or I am just missing something?