ASP.NET User.Identity.Name value after a domain username change

[Allister]

Hey

I have an ASP.NET application that is on a Win2000 server in a domain with
Active Directory. There are a number of client machines on this domain that
access a website on the server. IIS has Integrated Authentication only, and
no Anonymous access. I use the User.Identity.Name in my C# code to get the
login name of the requesting user.

I have a very confusing issue when the domain login of a user is changed
(say, from "userZero" to "userOne"). If that user then accesses the site
again with their new login ("userOne"), the User.Identity.Name value in my
code is still returning the username as "userZero".

I thought this might have been some caching issue on the client so I
rebooted the client machine and accessed the site again. The server still
reports the login name to be "userZero". I've also tried accessing the site
from another machine, and the ASP.NET code is still returning "userZero" as
the login name. This is pretty fustrating since I use this value to locate
profile info for that user but ASP.NET isn't providing me with reliable user
information.

I've output a list of the actual server variables from the
Request.ServerVariables collection:

AUTH_USER: gamma\userZero
LOGON_USER: gamma\userOne
REMOTE_USER: gamma\userZero

LOGON_USER seems to be the only variable that is reliably correct. The
others are coming from some unknown, outdated source (a cache perhaps?).

Classic ASP seems to work fine, and I can't reproduce this under that.

Resetting IIS didn't resolve this, but completely rebooting the webserver
did. In my situation, this is not at all ideal, and username changes aren't
uncommon, given the number of users in the domain.

I've also reproduced this on a Windows 2003 server running the ASP.NET app.

I don't think this is a serverside page caching issue because I output the
current date & time with the request, and it is correct, so the code is
executing on every refresh.

My question is how do I get ASP.NET to correctly report the username (using
User.Identity.Name) after it changes on the domain? If this is a server
credential caching issue, how do I clear it, or force it to properly read the
user's credentials?

Cheers

Allister

 

[Joe Kaplan \(MVP - ADSI\)]

This is probably a result of the Local Security Authority on the server
caching the name for the user's SID. That would explain why a reboot solved
it.

I'm not sure there is anything you can do about this. You could get the
user's SID and look up the name directly against the directory with LDAP (or
perhaps try the Translate method on the SecurityIdentifier class). You
could also use the user's SID as a unique ID, which won't suffer from this
problem. The user's GUID is an even better key for a database, as it will
never change in AD and fits in a SQL unique identifier column really nicely.

Joe K.

 

[Allister]

Thanks for your help on this, Joe.

Can you point me to any resources I can use about getting the SID of the
WebRequest user without using the username as the base of a lookup (since I
can't rely on ASP.NET giving me that info accurately)?

Is this issue a bug in the framework? Since it isn't occurring under classic
ASP, my guess is yes. I've found only one other post by another user with
this exact issue elsewhere, but it wasn't resolved.

Cheers

Allister

 

[Joe Kaplan \(MVP - ADSI\)]

In .NET 2.0, the User property on the WindowsIdentity class returns a
SecurityIdentifier object that you can use. If you are using .NET 1.1,
you'll need to P/Invoke GetTokenInformation or one of the similar functions
and pass in the IntPtr value you get from the Token property.

Since .NET is just calling into Windows API calls to resolve the user name,
I seriously doubt this is an issue in the .NET Framework. Windows is
providing the data to it. Can you reproduce the problem with both an ASP
page and and ASP.NET page in the same web app at the exact same time? That
seems unlikely to me.

Joe K.

 

[Allister]

For ASP code running on the same server, at exactly the same time, the ASP
ServerRequest variables of AUTH_USER, LOGON_USER, and REMOTE_USER are
identical and correct before, and immediately following the domain
username/login change.

In ASP.NET, LOGON_USER is the only variable that updates immediately
following the change. The other two are out of sync and still have the old
values, as does User.Identity.Name.

It does seem that the ASP.NET issue can correct itself eventually. I left it
alone over the weekend and when I refreshed the page on Monday it was
reporting consistent values. But I know that for at least 5 hours while I was
investigating it on Friday, it never corrected itself. A process or service
running on the server over the weekend may have corrected it, or the cache
entry was flushed (if it is a caching issue). I'm not sure.

 

[Joe Kaplan \(MVP - ADSI\)]

The only thing I can tell you is that .NET 2.0 uses the Windows
LsaLookupSids function to resolve SIDs into names, so if there is any
caching involved, it is a result of what that function does. Perhaps ASP
uses LookupAccountSid instead and its behavior is different? I'm not really
sure and the API docs don't say. You could try doing P/Invoke on it and
seeing if you get different results.

In any event, hopefully the User property gets you what you want.

Joe K.