Incorrect LogonUserIdentity.Name

[Scott_A]

We have an AD user account that was setup as R_Smith and then was changed to
JR_Smith.

One of our web applications does a database look up using the
LogonUserIdentity.Name value but this is still returning R_Smith even though
the user logged onto his box with JR_Smith.



Also I created a page that looked at the server variables and AUTH_USER,
LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page is
running on the same web server and in the same virtual directory as the web
application. Why would the server variables return different values to the
LogonUserIdentity.Name? Do they pull different attributes from AD? All the
account settings in AD look fine.

Any ideas?

Thanks

Scott

(I have also posted this on the asp.net forums but have had no luck yet)

 

[Joe Kaplan]

Did you try rebooting the box? Maybe something is cached somewhere in LSA
memory? I'm uncertain why the server variables would be up to date but this
code would be wrong, but perhaps there are different underlying API calls
that get the data from different places.

It will probably eventually fix itself either way.

 

[Scott_A]

Thanks for the reply.

Yes I have rebooted the box and have also run that code on different boxes
that authenticate to different DC's. ("%logonserver%")

I also think there are different API's in play but which ones and where do
they get their info from?

Scott

 

[Joe Kaplan]

I'm not really what's going on then. I can tell you that the
WindowsIdentity class uses the various Translate methods off the
IdentityReferenceCollection to do name translation (really different than
..NET 1.x) and those use the LsaLookupSids under the hood among other things.
It would appear that that particular API is returning the old name for some
reason while some other APIs are not.

I still don't know what the root of the problem is or how to get it resolved
though, especially if rebooting didn't resolve it.

Sorry.

 

[Joe Kaplan]

Note that you might consider using a more durable key into your SQL database
in the future to help avoid these types of problems.

The ideal thing to use for AD users is the GUID (objectGUID attribute in the
directory) since it rename safe, even across domain moves in a multi-domain
forest, is fixed size, has convenient binary and string representations and
also fits nicely into the SQL UniqueIdentifier type.

Another thing you could use is the SID. It isn't as durable and is variable
length, but it is more rename safe. It is also easier to get from the
WindowsIdentity since it is built in where as the GUID would require some
sort of a lookup.

Just an idea. It sounds like that ship may have already sailed and you
really just need to get this fixed, but this may not be the last time you
have this problem.

 

[Scott_A]

Thanks for the help and ideas. It's for a 3rd party app that I had to
decompile a bit to see what was happening.

I will wait another night and reboot in the morning and hope that it
resolves itself like these usually do.

Scott

 

[Joseph Sedlar]

I am running into the same exact problem. Did you ever resolve this issue?