为什么 Active Directory 验证最后一个密码？

Question

我正在研究一个简单的解决方案来更新 Active Directory 中的用户密码。

我可以成功更新用户密码。更新密码效果很好。假设用户已将密码从 MyPass1 更新为 MyPass2

现在，当我运行自定义代码来验证用户凭据时，使用：

using(PrincipalContext pc = new PrincipalContext(ContextType.Domain, "TheDomain"))
{
    // validate the credentials
    bool isValid = pc.ValidateCredentials("myuser", "MyPass2");
}

//returns true - which is good

现在，当我输入一些错误的密码时，它会很好地验证：

using(PrincipalContext pc = new PrincipalContext(ContextType.Domain, "TheDomain"))
{
    // validate the credentials
    bool isValid = pc.ValidateCredentials("myuser", "wrongPass");
}

//returns false - which is good

现在由于一些奇怪的原因，它会验证之前的最后一个密码，即 MyPass1，还记得吗？

using(PrincipalContext pc = new PrincipalContext(ContextType.Domain, "TheDomain"))
{
    // validate the credentials
    bool isValid = pc.ValidateCredentials("myuser", "MyPass1");
}

//returns true - but why? we have updated password to Mypass2

我从以下位置获取此代码：

验证用户名和密码Active Directory？

这与上次密码过期有关还是验证应该如何工作？

Answer 1

您看到此情况的原因与特定于 NTLM 网络身份验证的特殊行为有关。

在 PrincipalContext 实例上调用 ValidateCredentials 方法会导致建立安全 LDAP 连接，然后使用 ldap_bind_s 函数调用。

调用 ValidateCredentials 时使用的身份验证方法是 AuthType.Negotiate。使用此结果会导致尝试使用 Kerberos 进行绑定操作，这（当然不是 NTLM）不会表现出上述特殊行为。但是，使用 Kerberos 的绑定尝试将失败（密码全部错误），这将导致进行另一次尝试，这次使用 NTLM。

您有两种方法可以解决此问题：

1. 按照我链接的 Microsoft 知识库文章中的说明，使用 OldPasswordAllowedPeriod 注册表值缩短或消除旧密码的生命周期。可能不是最理想的解决方案。
2. 不要使用 PrincipleContext 类来验证凭据。既然您（大致）了解了 ValidateCredentials 的工作原理，那么手动执行该过程应该不会太困难。您需要做的是创建一个新的 LDAP 连接 (LdapConnection)，设置其网络凭据，将 AuthType 显式设置为 AuthType.Kerberos，然后调用 绑定()。如果凭据错误，您将得到一个例外。

以下代码显示如何仅使用 Kerberos 执行凭据验证。如果发生失败，所使用的身份验证方法不会回退到 NTLM。

private const int ERROR_LOGON_FAILURE = 0x31;

private bool ValidateCredentials(string username, string password, string domain)
{
  NetworkCredential credentials
    = new NetworkCredential(username, password, domain);

  LdapDirectoryIdentifier id = new LdapDirectoryIdentifier(domain);

  using (LdapConnection connection = new LdapConnection(id, credentials, AuthType.Kerberos))
  {
    connection.SessionOptions.Sealing = true;
    connection.SessionOptions.Signing = true;

    try
    {
      connection.Bind();
    }
    catch (LdapException lEx)
    {
      if (ERROR_LOGON_FAILURE == lEx.ErrorCode)
      {
        return false;
      }
      throw;
    }
  }
  return true;
}

我尽量不使用异常来处理代码的流程控制；但是，在此特定实例中，测试 LDAP 连接上的凭据的唯一方法似乎是尝试绑定操作，如果凭据错误，该操作将引发异常。 PrincipalContext 采用相同的方法。

Answer 2

我找到了一种仅验证用户当前凭据的方法。它利用了 ChangePassword 不使用缓存凭据的事实。通过尝试将密码更改为其当前值，这首先会验证密码，我们可以确定密码是否不正确或存在策略问题（不能重复使用同一密码两次）。

注意：这可能仅在您的策略具有至少不允许重复最近密码的历史记录要求时才有效。

        var isPasswordValid = PrincipalContext.ValidateCredentials(
            userName,
            password);

        // use ChangePassword to test credentials as it doesn't use caching, unlike ValidateCredentials
        if (isPasswordValid)
        {
            try
            {
                user.ChangePassword(password, password);
            }
            catch (PasswordException ex)
            {
                if (ex.InnerException != null && ex.InnerException.HResult == -2147024810)
                {
                    // Password is wrong - must be using a cached password
                    isPasswordValid = false;
                }
                else
                {
                    // Password policy problem - this is expected, as we can't change a password to itself for history reasons    
                }
            }
            catch (Exception)
            {
                // ignored, we only want to check wrong password. Other AD related exceptions should occure in ValidateCredentials
            }
        }

Answer 3

根据您运行此程序的上下文，它可能与名为“缓存凭据”的内容有关”。