Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Last week, an employee's Active Directory username was changed (or a new one was created for them). For the purposes of this example, let's assume these usernames:

Old: Domain\11111
New: Domain\22222

When this user now logs in using their new username, and attempts to browse to any one of a number of ASP.NET applications using only Windows Authentication (no Anonymous enabled), the system authenticates but our next layer of database-driven permissions prevents them from being authorized. We tracked it down to a mismatch of usernames between their logon account and who IIS thinks they are. Below are the outputs of several ASP.NET variables from apps running in a Windows 2008 IIS7.5 environment:

Request.ServerVariables["AUTH_TYPE"]: Negotiate
Request.ServerVariables["AUTH_USER"]: Domain\11111
Request.ServerVariables["LOGON_USER"]: Domain\22222
Request.ServerVariables["REMOTE_USER"]: Domain\11111

HttpContext.Current.User.Identity.Name: Domain\11111
System.Threading.Thread.CurrentPrincipal.Identity.Name: Domain\11111

From the above, I can see that only the LOGON_USER server variable has the correct value, which is the account the user used to log on to their machine. However, we use the "AUTH_USER" variable for looking up the database permissions.

In a separate testing environment (completely different server: Windows 2003, IIS6), all of the above variables show "Domain\22222". So this seems to be a server-specific issue, like the credentials are somehow getting cached either on their machine or on the server (the former seems more plausible).

So the question is: how do I confirm whether it's the user's machine or the server that is botching the request? How should I go about fixing this?

I looked at the following two resources and will be giving the first one a try shortly:


share|improve this question
To figure out if it's the user's machine or the server botching the request you would have to log on from different machines, preferably machines with different security footprints, different domains, different networks. Is your test environment and production environment using the same domain and domain controllers? –  Snowburnt Apr 8 '13 at 15:09
@Snowburnt: The test and production environments are on the same domain, and should be using the same domain controller(s). Should I take a look at DNS settings? –  Cory Larson Apr 8 '13 at 15:13
I doubt it's a DNS issue. When you test in the test environment, you're using a different computer and it works fine, right? Try having the user log into the production environment from a different computer. If it works fine have the user clear out his cookies for that server. –  Snowburnt Apr 8 '13 at 15:18
@Snowburnt: We used the same computer to examine the variables in the production and test environments. We did have them clear out all temporary internet files. The same behavior was observed whether the user used IE or Firefox. –  Cory Larson Apr 8 '13 at 15:19
did you see this: stackoverflow.com/questions/168946/… for clarification here is the solution: support.microsoft.com/kb/946358 –  Snowburnt Apr 8 '13 at 15:33
show 2 more comments

1 Answer

up vote 3 down vote accepted

The problem looks similar to this issue here:


For clarification here is the solution:


share|improve this answer
The registry change and a reboot cleared up the issue. Thanks for pointing me at the article! –  Cory Larson Apr 9 '13 at 18:15
add comment

protected by Community Feb 28 at 19:13

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.