Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?

like image 243
Dirk Avatar asked Apr 16 '09 15:04

Dirk


People also ask

How long should it take for ad to sync after a password reset?

After an Active Directory administrator resets the password on-premises, Azure AD Connect takes at least two minutes to sync that temporary password to Azure AD. To avoid receiving this warning message, the user has to wait at least two minutes to sign in and update the password.

Why do I have to reset my password every time I log in?

When users have previously been repeatedly prompted to reset their password on every login, it's typically due to an issue with the specific web browser.


2 Answers

This issue is not related to Code but the culprit over hear is the Active directory...

Please refer http://support.microsoft.com/kb/906305 for solution...

like image 102
deenaik Avatar answered Oct 26 '22 05:10

deenaik


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

like image 25
Dirk Avatar answered Oct 26 '22 04:10

Dirk