active-directorydirectoryservicesaccount-management

DirectoryServices.AccountManagement "old" password still validates after password change


After resetting a users password in Active Directory, if the user tries to log in using their old password, the following code validates as True:

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername)

If up IsNot Nothing Then

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate)


    If (valid) Then strReturn = up.SamAccountName

End If

We are resetting the password using the following code:

Dim objUser As New DirectoryEntry(arg_strLDAPPath)

If Not objUser Is Nothing Then
    objUser.AuthenticationType = AuthenticationTypes.Secure


    objUser.Invoke("SetPassword", arg_strNewPW)
    objUser.CommitChanges()
end if

The password reset works fine and the user can log in with their new password, but their old password should not still validate.

When the above ValidateCredentials works for the old password, we are assigning the credentials to a web service call, which then fails with a "401: Unauthorized" error.

Anyone seen anything like this?


Solution

  • I fount the answer Here

    From the link...

    "However, what counts is that ContextOption does not ensure the use of Kerberos only. It turns out that under certain situations (like if you are specifying AD rather than local, and you have a sufficiently up to date server), the code chooses to do Negotiate no matter what. In that sense, specifying Sealing probably means that it will use Kerberos, but not necessarily exclusively. The flag that really matters is burried several layers under that. Under the covers, this method ends up establishing an LdapConnection, setting the network Credentials for the connection, setting that AuthType (the actual flag that matters!), and finally calling the Bind() method. The LdapConnection.Bind() method establishes an authenticated connection to one of the AD servers using the specified credentials. The problem is that when PrincipalContext.ValidateCredentials sets up this call (in your scenario), it always sets the AuthType = Negotiate. In this case, Kerberos does in fact get used, and ends up failing, but the system falls back to NTLM."