views:

1026

answers:

1

Update

Putting this at the top because it is crazy :)

So some users have it work, some don't. When I use my own account via IE7 it doesn't work (my code catches the exception and falls back to simply using the identity name instead of the AD fullname). When I try via Chrome it prompts me for the username and password, which I supply, and the fullname is displayed. So the user account, server code and settings are identical, but using a different browser to send the authentication is making it work.

I also cleared all cookies from IE7, restarted, and there was no change in IE's behavior. Plenty of users of IE7 are having it work fine.

Update #2

Remotely logged into a different machine, went to the page in IE7, and it shows my full name. No clue. I was thinking maybe session was caching something but I've republished the app and that should clear session. I was thinking maybe a cookie had an old / bad token, but I've cleared those and tried again. Something somewhere has to be getting long term caching. Hopefully it works itself out.

End Updates

Hello,

I am retrieving a users full name from our AD in an ASP.NET (MVC) application running on IIS 6.0.

string domainUser = filterContext.HttpContext.User.Identity.Name;

WindowsIdentity windowsIdentity = filterContext.HttpContext.User.Identity as WindowsIdentity;

WindowsImpersonationContext impersonationContext = windowsIdentity.Impersonate();

DirectoryEntry userEntry = new DirectoryEntry("WinNT://" + domainUser.Replace('\\', '/') + ",User");
filterContext.Controller.ViewData["User"] = (string)userEntry.Properties["fullname"].Value;

The last line throws an exception: "Logon failure: unknown user name or bad password."

If I look at the HttpContext.User.Identity it is a valid Domain User and WindowsIdentity.GetCurrent is being impersonated properly.

This exception also seems to not be thrown 100% of the time, and it doesn't get thrown if browsed from the IIS Server.

My web.config looks like:

<authentication mode="Windows"/>
<authorization>
    <deny users="?"/>
</authorization>
<identity impersonate="false"/>

What is bugging me is that if I remove the impersonation line:

WindowsImpersonationContext impersonationContext = windowsIdentity.Impersonate();

It works. The WindowsIdentity.GetCurrent is NT AUTHORITY\NETWORK SERVICE which isn't a domain user but no exception is thrown and the fullname is retrieved from the AD.

The last bit is that this seems to have only started happening with a new deployment of the application (from test to live). I don't know if I'm missing an IIS setting or what, but the code hasn't changed.

I know I've needed to impersonate previously to make it work, and it seems like I should need to impersonate, so I'm hesitant to remove the impersonation call without fully knowing what is going on and why this error is now happening.

Thanks.

+1  A: 

I suspect the problem is that the server hosting your ASP.NET application is not trusted for delegation. Google for "trusted for delegation" for more info, or this MSDN article is a good starting point.

Joe
After testing a bit more, while I'm not sure where the problem is, I don't think it can 100% be the server. I added an update, but basically it works for the same account, same server, same client machine, different browsers (one browser fails, one works). I'm kind of stumped. I did try the suggestion and set the server to be trusted for delegation, but things didn't seem to be fixed (that said, the time for propagation might be higher than I waited).
eyston