0

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:

Thanks.

Community
  • 1
Cᴏʀʏ
  • 163
  • 2
  • 11
  • 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 08 '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? – Cᴏʀʏ Apr 08 '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 08 '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. – Cᴏʀʏ Apr 08 '13 at 15:19
  • did you see this: http://stackoverflow.com/questions/168946/iis-returning-old-user-names-to-my-application for clarification here is the solution: http://support.microsoft.com/kb/946358 – Snowburnt Apr 08 '13 at 15:33
  • @Snowburnt: The MSDN link looks promising. I'll give it a try when I have a minute and followup. Thanks! – Cᴏʀʏ Apr 08 '13 at 15:39
  • @Snowburnt: The SID cache was definitely the culprit. If you repost your comment as an answer I'll gladly accept it. Thanks!~ – Cᴏʀʏ Apr 09 '13 at 13:39

1 Answers1

3

The problem looks similar to this issue here:

https://stackoverflow.com/questions/168946/iis-returning-old-user-names-to-my-application

For clarification here is the solution:

http://support.microsoft.com/kb/946358

Community
  • 1
Snowburnt
  • 775
  • 2
  • 5
  • 18