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?
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.
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.
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...
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."
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With