locked
Password reset - totally lost RRS feed

  • Question

  • User61816585 posted

     Hello all.  I would like to first apologize in advance for my ignorance of LDAP and Active Directory in general.  Unfortunately, I've been assigned a task that requires some work in this area.

    Basically the requirements are to have a site where upon verification of identity (that's the easy part and already taken care of), a person can reset their password from a computer in our domain.  They won't be logged in as themselves as this tool is for if they forget their password.  The site is supposed to use an Active Directory account that we set up that is only allowed to reset passwords but can reset pretty much any password.  We initially balked at having such an account, but the order came from the top so there isn't much to do about it except encrypt the credentials and use it.

    Anyway, my initial attempts have revolved around attempting to impersonate this account and call SetPassword fromn the DirectoryEntry.Invoke method.  Here is the code that I've ended up with:

    DirectoryEntry searchRoot = new DirectoryEntry(String.Format(@"LDAP://{0}", "company.org"), accountName, password, AuthenticationTypes.Secure);
    DirectorySearcher search = new DirectorySearcher(searchRoot);
    search.Filter = "(&(objectClass=user)(objectCategory=person)(title=OtherFilter))";
    search.PropertiesToLoad.Add("samaccountname");
    
    SearchResult result;
    SearchResultCollection resultCol = search.FindAll();
    if (resultCol != null)
    {
         for (int counter = 0; counter < resultCol.Count; counter++)
         {
              result = resultCol[counter];
              if (result.Properties.Contains("samaccountname"))
              {
                   if ((String)result.Properties["samaccountname"][0] == accountToFind)
                   {
                        DirectoryEntry resetEntry = new DirectoryEntry(resultCol[counter].Path);
                        resetEntry.Invoke("SetPassword", new object[] { newPassword });
                   }
              }
     }


    This however throws the exception with a message of "Exception has been thrown by the target of an invocation" with an InnerException having a message of "Make sure you have sufficient privileges to access this resource."  This is obviously telling me that the account doesn't have authority to use the SetPassword method.

    I'm a bit confused about what actual account is being used for this call. For the searchRoot DirectoryEntry object, I gave the credentials that should have the correct authority.  However, the SetPassword method is actually called on the resetEntry object which is created using a result from a search based off of the authorized searchRoot object.  At this point, would it be using the authority of the searchRoot object or it's own new authority (which if it would be for the account I'm searching for, wouldn't have the rights to use SetPassword)?

    Finally, I have also considered the possibility that it is using my actual account that I'm logged into my computer with since I'm running this on localhost right now.  If that is the case, it would fail because I don't have the right to use SetPassword.  Thinking that this may be the case, I started playing around with  the LogonUser and ImpersonateLoggedOnUser methods found in advapi32.dll but have had no luck with those.  I'm also kind of leery about using those methods as it doesn't really seem to be the safest option.

    Okay, I'm sorry for all the text but I'm trying to provide as much detail as possible.  Is it possible to impersonate the A.D. account I've been given in order to make this one method call?  Or will I have to resort to setting this page up as a Virtual Directory and run the application pool for the V.D. with the account that has the right to reset the passwords? 

    Thanks for any help.

    Tuesday, September 15, 2009 11:11 AM

Answers

  • User-2009597737 posted

    Most probably you cannot impersonate an account for such purposes: at least I have not seen one and this is not the "best practice".  You can surely go the virtual directory way. You can also ask for such "service account" from the  AD administrators. This account needs explicit rights to update/set the user passwords across the domain. Once you get a set of credeitials all you need to do is plug this into the directory entry:resetEntry.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 16, 2009 3:22 PM

All replies

  • User-2009597737 posted

    Most probably you cannot impersonate an account for such purposes: at least I have not seen one and this is not the "best practice".  You can surely go the virtual directory way. You can also ask for such "service account" from the  AD administrators. This account needs explicit rights to update/set the user passwords across the domain. Once you get a set of credeitials all you need to do is plug this into the directory entry:resetEntry.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 16, 2009 3:22 PM
  • User61816585 posted

    Thanks for the response. I had pretty much come to the conclusion that the "impersonation" route wasn't going to work. It's not true impersonation which would require a kerberos environment as well as the user being logged in with that super account and it surely didn't feel like a practice that I wanted to follow.   I went ahead and set up the virtual directory method yesterday to see if it worked and thankfully it worked like a charm. I really wanted some kind of confirmation on my thoughts on the impersonation method which you provided, so thanks for that.
     

    Wednesday, September 16, 2009 4:26 PM
  • User-21224605 posted

    Could you post your new code please? I have the same problem. 

    Tuesday, February 23, 2010 3:15 AM