Thread.CurrentPrincipal.Identity vs. Active Directory entry

Question

In this extremely helpful summary from Mike O'Brien

http://blog.mike-obrien.net/PermaLink,guid,5e975b20-7b05-472f-bd80-04028ab8b6fa.aspx

he gives an overview of how IIS 7 deals with authentication for different settings (I couldn't find a similar summary for IIS 6, which is the version we are using). We have set the authentication to Integrated Windows Authentication; anonymous access is turned off and I am not using impersonation. The asp.net app sits in an intranet, but I have no control (and very little knowledge) of how many domains there are, how they interact with each other etc.etc. According to the article above I should get the same user information for all three of:

Thread.CurrentPrincipal.Identity
HttpContext.Current.User.Identity
Request.LogonUserIdentity

I do get the correct user, but the casing is different from the AD name. So my question is: if

Thread.CurrentPrincipal.Identity

(which is what I am using) gives the right AD name, but displays a different casing to AD, is that most likely an issue with Thread.CurrentPrincipal.Identity, with the intranet/domain settings, or differences between IIS 6 & IIS 7?

(apologies for the vague nature of this question: I'm just trying to look for suggestions as where best to look and/or input as to whether there is something inherently unwise about using Thread.CurrentPrincipal.Identity).

EDIT: update for IIS 6 - according to this link

http://msdn.microsoft.com/en-us/library/aa302377.aspx

I should be getting DOMAIN\username for IIS 6 as well, so no difference there. Could the issue be related to how Kerberos/NTLM interact with IIS?

EDIT #2: The problem can be summarised thus:

I am displayed as e.g. DOMAIN\joebloggs in AD. I logged in as joebloggs. But the credentials I get back from a (successful) authentication using Thread.CurrentPrincipal.Identity show DOMAIN\JoeBloggs. Where could that be coming from?

Answer 1

The user name in this case is supplied by the client. The authentication mechanism verifies that the identity can be confirmed, but it does not replace the user-supplied name with the as-stored name from AD, so there is no reason to expect the casing to match.

Answer 2

It turns out that I was not getting accurate information from the client site: i.e. the authentication is happening the way I had understood it (i.e. ASP.Net: lookup and return from AD; ASP: handed off to IIS) and the unexpected casing was down to caching issues and not down to the authentication mechanism.