Logon failure error when attempting UserPrincipal.FindByIdentity

Question

I've been searching for solutions on this for a while now, but each thread a dead-end unfortunately.

I'm working on a C#/ASP.net web app that will only be used internally by our company. Anonymous access has been switched off both in IIS and my web.config file forcing IIS to use the windows authenticated user (Active Dir user).

My problem is that the following code works perfectly to get the required (or any) AD user:

using System.DirectoryServices.AccountManagement;

... other code ...

PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "mydomain", "someADuser", "someADuserpassword");
UserPrincipal winuser = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, "samaccountname");

"someADuser" used in the PrincipalContext above is the current logged in user through windows, thus authenticated and a valid AD user. Using the following code (with the exact same user still logged in) gives me a "Logon failure: unknown user name or bad password" error:

PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "mydomain");
UserPrincipal winuser = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, "samaccountname");

It seems UserPrincipal.FindByIdentity doesn't use the logged in user's validated credentials for some reason if it's not specified in the PrincipalContext object - something I don't want to do.

Is it possible that the ctx aren't picking up the logged in Windows users for some reason, even if the necessary settings (i hope) is added to web.config :

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

And Anonymous access is completely disabled in IIS?

Answer 1

It seems UserPrincipal.FindByIdentity doesn't use the logged in user's validated credentials for some reason if it's not specified in the PrincipalContext object - something I don't want to do.

UserPrincipal.FindByIdentity doesn't care about the user's credentials at all. You're just performing a look up to see if the account exists. The reason you're getting an error is because the default user credentials (i.e. the identity that your web application is running as) doesn't have access to the directory, so it can't perform the look up. When you pass in the client's credentials to the PrincipalContext then the problem goes away because your client has a valid AD account with access to the directory.

You should investigate which identity is being used to run the application pool and make sure it has access to the directory.

Answer 2

Quite annoying as I though if anonymous access was turned off, the current principal would default to the user logged in to windows. It turns out it's not as indicated by @RogerN.

Using the following statement as mentioned by @TheKingDave, it basically impersonates the user logged in to windows and makes the current thread run on it's principal rather than the "ASP" (in my case) account.

Because all the users on our domain has query/read access to Active Directory, this shouldn't be a problem to get more detail on them, which is what I wanted in the first place.

The end code (was testing):

System.Web.HttpContext.Current.Request.LogonUserIdentity.Impersonate();
ctx = new PrincipalContext(ContextType.Domain, System.Net.NetworkInformation.IPGlobalProperties.GetIPGlobalProperties().DomainName);
UserPrincipal winuser = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, "whicheveraccount");

Hope it helps some1 in future! thx! ;-)

Answer 3

I did a lot of search/research to resolve the issue, but nothing worked, at last, all what I did was to add @ to the servername, container, username & password like below:

app.CreatePerOwinContext(() => new PrincipalContext(ContextType.Domain, @"abc.net", @"OU=Customers,DC=abc,DC=net", ContextOptions.SimpleBind, @"abcnet\authuser", @"!$%MyPassword"));

And it worked. doh!