DirectoryServices.AccountManagement "old" password is still verified after changing the password

Question

After resetting the user's password in Active Directory, if the user tries to log in using his old password, the following code is checked 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 reset 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 

Password reset works fine, and the user can log in with his new password, but the old password still should not be verified.

When the above ValidateCredentials works for the old password, we assign the credentials for the web service call, which then fails with the error "401: unauthorized."

Has anyone seen anything like this?

Answer 1

I get an answer here

From the link ...

"However, it is believed that ContextOption does not guarantee the use of only Kerberos. It turns out that in certain situations (for example, if you specify AD, and not local, and you have a fairly modern server), the code chooses to negotiate, despite In this sense, specifying Sealing probably means that it will use Kerberos, but not necessarily exclusively. A flag that really matters is shaded by several layers under it. Under covers this method completes the creation of LdapConnection by setting up network credentials You can connect by setting 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 this call (in your script), it always sets AuthType = Negotiate. In this case, Kerberos is really used and the failure ends, but the system goes back to NTLM. "

Answer 2

This issue is not code related, but the culprit is the Active Directory interception ...

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

Answer 3

It works - see DECISION below - Please let me know if you find it useful, as our store is divided on whether this is OK decision.

The following is a solution for Active Directory that allows the old password to work after the change. I would really like to receive feedback on making this decision as it uses ChangePassword during login authentication. This is a strange thing, but it works. Our store currently does not use this solution, so if someone tells me whether they use it or not, it will be appreciated.

Thanks. Ch

Return Active Directory and old passwords Valid (from 15 minutes to + hours). This happens when calling SetPassword or ChangePassword.

History:

I find this to be called a “Feature” of AD and is built into AD by design, so when a user changes passwords, there is a kind of grace period that allows all resources that use these passwords to switch to a new one.

One example of AD that supports the concept that AD knows the last password is changing the password for entering the PC — in this case, the computer will not allow the old password to be entered. Although I do not have an answer to this question (with the exception of Microsoft, to make it work), I believe that it is not as easy as it might seem, since the PC is involved and has passwords on it.

One example showing how password changes in AD are performed over a period of time can be:

Use Remote Desktop from a Windows 7 PC on Windows Server 2008 R2. Log in from the Windows Security window, then click OK, click OK, and you are logged in. Now change your password for the user you used for the remote one in the box with (different from your Kirkman user?), Log out and log in again with the old password (within 15 minutes to an hour + -). The old password will take you to the Windows Security window and to the OK window. When you click OK, it will fail. If you start working from remote desktop and try a bad password, you will be stopped in the Windows Security Box with the message "Login failed." After the expiration, you will not go through the Windows security window with the old password. (make sure you start from Remote Desktop every time you do NOT switch users who will act as expected, which also shows that the PC is involved in something). At least this is not a user login, but it shows that (what seems to be AD) at some level allows old passwords to authenticate to some level.

Research: I found many references to this problem and only one potential solution, which at this point I could not determine if we can implement it (this is a link to a call strictly through Kerberos, not NTLM, which is not as simple as it may appear in accordance with the documentation and my research). I found many links on how to interact with AD in .NET, but does not have an actual AD manual.

SOLUTION SOLUTIONS SOLUTIONS. Read this part if you want a SAVE SOLUTION! Present: I discovered (by accident during testing) that calling ChangePassword in AD would not allow the passed OldPassword to succeed in changing the password to the new password. In my opinion, this test, which really works, is not really known, since I did not find a link to its use. In fact, I did not find a solution to this problem. One morning at 3 o’clock in the morning, I realized that I could use this ChangePassword to provide a solution to this problem - at least a workaround that we can use immediately until we can determine the best approach.

First, I verify that everything is correct, and AD returns that the password is valid. Then a ChangePassword call (username, oldpassword, newpassword) is made with the old password and newpassword as the password provided by the user (both are the same). I know one of two (maybe three, but breaking a password policy stops him after success). Either OldPassword is good and we fail because the password policy is not executed (history, the new password cannot be one of the last N passwords), or we fail because the old password is incorrect (both returned as an exception error with text in the message ) We check this last condition, and if the old password is invalid, we do not allow the user to log in.

Future: Maybe a second set of eyes will help.
I think the solution is under impersonation or Kerberos. I have not been successful in finding one of them as solutions. Obviously, AD can distinguish between old passwords because ChangePassword does this. What we do is at the heart of security, so not everything is open (for example, the ability to see the password history in AD, I did not find a way to access it).

Answer 4

Have you considered up to 15 minutes that AD requires the propagation of such changes throughout the network?

Mark

Answer 5

I assume that you are running ValidateCredentials on the client machine. If so, then it has an old (successful) password cached. This is to ensure that users can log in if Active Directory is offline or unavailable. Propagation of changes takes some time.

If you want to get around this, you must authenticate with the server serving the web service during authentication, and not with the local client machine.