☰

为什么 AD 环境中的服务器允许通过 FQDN 进行远程注册表访问，但拒绝并锁定通过 IP 地址的帐户？

tag-icon • tag-icon active-directory windows-registry windows-authentication rpc
为什么 AD 环境中的服务器允许通过 FQDN 进行远程注册表访问，但拒绝并锁定通过 IP 地址的帐户？

我们遇到过这样一种情况：由于安装期间使用的管理员帐户在先决条件检查期间被锁定，因此无法安装软件应用程序。经过一番调查，我们发现了原因：先决条件检查通过 RPC 调用服务器的 IP 地址（而不是其 FQDN）来查看其他服务器的远程注册表设置，出于某种原因，这导致身份验证失败并锁定帐户。

我们通过以下方式验证了这一点：

  • 当使用 regedit 并尝试使用该服务器的 FQDN 连接到另一个 AD 服务器的注册表时，它可以毫无问题地连接。
  • 当我们尝试使用服务器的 IP 地址建立相同的连接时，它会提示输入新的凭据。
  • 所有 AD 凭据都将失败并最终锁定正在使用的帐户，但使用本地管理员帐户没有问题。

我们也从环境中的其他服务器执行了此测试，但它们在通过 IP 进行连接和身份验证时没有遇到任何问题。我们比较了 NIC/DNS/WINS 设置，但没有明显差异。我们正处于交叉检查 GPO 设置的阶段，但我们不希望发现任何东西。

我们显然可以只使用本地管理员帐户，但我们想了解为什么使用 IP 地址而非 FQDN 的 RPC 调用会导致 AD 身份验证失败并锁定 AD 帐户。有什么想法吗？

答案1

如果账户被锁定，那肯定是密码问题。否则可能是因为不使用 Kerberos 并且禁用了 NTLM 等。您需要检查源服务器和目标服务器的安全日志，并提供可能与身份验证问题相关的任何日志条目。

你也可以尝试一下。但是，当你甚至不知道某些东西无法正常工作的原因时，改变这些东西并不是很有效，而且可能会破坏其他东西。

从 Windows 10 版本 1507 和 Windows Server 2016 开始，可以配置 Kerberos 客户端以支持 SPN 中的 IPv4 和 IPv6 主机名。

默认情况下，如果主机名是 IP 地址，Windows 将不会尝试对主机进行 Kerberos 身份验证。它将回退到其他已启用的身份验证协议，如 NTLM。但是，应用程序有时会被硬编码为使用 IP 地址，这意味着应用程序将回退到 NTLM 而不使用 Kerberos。当环境转向禁用 NTLM 时，这可能会导致兼容性问题。

为了减少禁用 NTLM 的影响，引入了一项新功能，允许管理员使用 IP 地址作为服务主体名称中的主机名。

阅读更多

https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip

相关内容