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

Question

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?

Thanks Dirk

Answer 1

Did you take the up to 15 minutes of time into account that AD requires to propagate changes like that throughout the network??

Marc

Answer 2

I assume you're ValidateCredentials executes on a client machine. If that is the case, then it has the old (successful) password cached. This is done to enable users to login if the Active Directory is offline or unreachable. Propagating changes takes some time.

If you want to get around this, you should authenticate with the Server serving the Webservice at authentication time instead of the local client machine.

Answer 3

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."