none
UserPrincipal.FindByIdentity Permissions RRS feed

  • Question

  • I'm attempting to use the System.DirectoryServices.AccountManagement library to obtain the UserPrincipal for a particular Active Directory user.

    I've got the following code:

    PrincipalContext context = new PrincipalContext(ContextType.Domain, "DomainName");
    userPrincipal = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username);

    This code is running as a valid domain user, but when I execute it I get the following exception:

    System.DirectoryServices.DirectoryServicesCOMException (0x8007052E): Logon failure: unknown user name or bad password.

    What's interesting is that I can make the following call, using the same context, without a problem:

    context.ValidateCredentials(username, password, ContextOptions.Negotiate)

    Ideas?

    • Edited by RMD Thursday, August 26, 2010 5:19 PM formatting
    Thursday, August 26, 2010 5:19 PM

All replies

  •  

    Hi,

     

    What's the current logged on user? Is it a valid user of that domain?

     

    We may need to run the code as a valid domain user, or we can impersonate as a valid domain user. The CSImpersonateUser project in All-In-One Code Framework shows how to impersonate a user, hope it can helps.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, August 27, 2010 6:27 AM
  • This code is being run in an ASP.NET application. The application itself is set to not impersonate, and the application pool is running as a valid domain user.
    Friday, August 27, 2010 2:12 PM
  • What if you change the Identity of apppool to Build-in account: ApplicationPoolIdentity? does it work?
    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, August 30, 2010 4:18 AM
  • Testing it as ApplicationPoolIdentity would be difficult as the application needs to run as a certain user to access a wide variety of resources.

    Can you tell me why you think running it as this built-in account would work? Doesn't the user need to be a domain user?

    Monday, August 30, 2010 3:39 PM
  • I firstly did a testing in a C# console applicaiton with your code snippet, if current logged on user is an invalid domain user, I get the exception you mentioned; If I impersonate as a valid domain user, your code snippet works well.

    then, according to your discription, I moved the code to an ASP.NET application, run the apppool as ApplicationPoolIdentity, it also works well.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, August 31, 2010 1:19 AM
  • This is pretty confusing. The identity of the application pool is definitely a valid domain user. So if this call is failing because the user isn't a valid domain user, what user is it using?

    I used Reflector to dig into what calls are being made, and the call that eventually fails is a Win32 function called ADsOpenObject.

    The documentation for this function is here: http://msdn.microsoft.com/en-us/library/aa772238(VS.85).aspx

    What's interesting is that the documentation says that the method must be passed the username and password to use to connect. It doesn't give the option to pass NULL and have the currnet security context used.

    Yet the PrincipalContext class allows you to use a constructor that doesn't require a username/password. It's difficult to follow the code, but it seems like those null values are passed all the way down to this function.

    Tuesday, August 31, 2010 5:19 PM
  • Anybody have any ideas on this?

    I've tried executing this same code from within a WinForms application that's running as a domain admin. The same thing happens.

    Friday, September 10, 2010 5:38 PM
  • Print out the identity of threads/WindowsIdentity/ User Identity  of ASP.Net app/ the code from following blog post and put  in  any test.aspx page and run in in same app Pool


    http://blogs.msdn.com/b/rahulso/archive/2007/02/12/a-sample-aspx-page-to-show-the-security-details.aspx

    • Proposed as answer by billb08 - MSFTModerator Thursday, October 7, 2010 4:36 PM
    • Unproposed as answer by RMD Monday, November 29, 2010 7:46 PM
    Monday, October 4, 2010 5:14 PM
    Moderator
  •  

    I am new to Directory / AM programming so this suggestion may seem naive, but it works for me in my test programs.  Why can't you do something like this and add the username & password to get the PrincipleContext:

    PrincipalContext context = new PrincipalContext(ContextType.Domain, "DomainName", username, password);
    userPrincipal = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username);

    Monday, November 29, 2010 7:45 PM
  • I've tried this, but to no avail.
    Monday, November 29, 2010 7:46 PM
  • I've tried the same code in a Windows Forms application and it still didn't work.

    In this case, the Windows Forms app was running as a valid domain user (even a domain admin), and I was explicitly passing the username/password of the account in question when creating the context.

    Monday, November 29, 2010 7:47 PM
  • I've tried this, but to no avail.


    OK.  How about if you used a known, good, possibly admin "service" username and password when you get the pc thus (as a sort of explicit trusted subsystem):

    PrincipalContext context = new PrincipalContext(ContextType.Domain, "DomainName", service-username, service-password);

    Then use the FindByIdentity() with the target (possibly not there) dodgy username:
    userPrincipal = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username);

    • Proposed as answer by dba-asp Friday, October 9, 2015 4:27 AM
    Monday, November 29, 2010 9:25 PM