I got a call from a client recently where one particular user was unable to log in to SharePoint via their User Principle Name (UPN).  This turned out to be a quick and easy fix, so I wanted to share hopefully to help anyone else. 

What is a UPN Anyway?

First, for those non-AD SharePoint folks out there, UPN refers to an attribute on the user account object in Active Directory.  Anytime a user is created, at a minimum they will have a user logon name and a UPN suffix (domain name).  The UPN is composed of the user logon name and the UPN suffix joined by the @ sign.

Normally, a user would login with CONTOSO\tado and his password.  A UPN allows the users to use a more casual and friendly name, especially if it matches their email address.  This would allow a client named Tad to login with tado@contoso.com.  To add a UPN suffix, you can follow this MS KB article to be completed by your domain admin.

Now that you know about UPNs, here's a summary of our scenario (Tad will be the client user):

• Tad calls the helpdesk saying that he cannot login to SharePoint today with his friendly login (tado@contoso.com). 
• Tad is able to login to SharePoint via the old style logon name CONTOSO\tado without issue.
• There are no other users who are reporting this issue, they can login with their UPN style logon (username@contoso.com).
• You get the user’s credentials to test on another computer, and you get the same results as the user.  Old style works, UPN fails.

So this definitely seems to point to something with the user.  Luckily I had access to Active Directory, so I started poking around.  I searched AD for just the logon name, and got two results.  Weird! 

Cause

What happened was that there were two user accounts for Tad.  He had been with a previous company that had been renamed at one point.  They were like CONTOSO\tado and CONTOSO\tadorman, but both accounts had tado@contoso.com for the UPN.  Only the user account CONTOSO\tado had access in SharePoint.  When Tad was logging in with tado@contoso.com, it was grabbing the account CONTOSO\tadorman, which had no access in SharePoint. 

Resolution

The fix is very simple.  Since the CONTOSO\tado is the account with access and what we want to use, we need to change the UPN of the CONTOSO\tadorman account.  Go make friends with your domain administrator, and have them change the tado to tadorman in the circled box on his account.  So his account should be tadorman@contoso.com, with a UPN CONTOSO\tadorman.  The working account should be CONTOSO\tado, with a UPN tado@contoso.com.  Clear?

In my scenario, once the duplication was removed, the user was able to login with his friendly UPN just fine.  Even though this was a quick fix, there were strange symptoms. Hopefully my post will help others dealing with the same issue.

If you would like more information on C5 Insight or this blog content, fill out our Contact form.