我们有一位客户拥有 Windows Server 2016 域控制器。这是一家小型企业，因此他们的服务器基础架构由 Hyper-V 主机和此 DC 组成。DC 托管文件共享和 Azure AD Connect，用于与 Office 365 同步身份。
我们监控事件 ID 4625 并设置警报阈值，以帮助我们识别针对网络的潜在暴力攻击。
去年 10 月，我们开始收到警报，称已超出失败登录警报阈值。经过调查，我们对该问题进行了以下描述：
- 每当我们的 VSS (Datto) 备份运行或 AADC 同步时，登录失败事件就会自然发生
- 备份成功，AADC 同步正常，无错误
- 有两个账户登录失败：
- 每次备份运行时，SERVERNAME$（例如 SYSTEM 帐户）
- 每当 AADC 运行时，AAD_*
- 事件状态为 0xC000006D - 用户名或密码失败
- 事件 SUB STATUS 为 0x0 - 状态正常
- 可以通过运行以下命令轻松复制 SYSTEM 登录失败
vssadmin list writers
过去几个月的故障排除清单很长。以下并非完整清单：
- 卸载 RRAS 和 WID（包括删除 WID 文件夹以确保重新安装角色时正确设置权限）
- 清除系统凭据缓存（使用 psexec &
rundll32 keymgr.dll,KRShowKeyMgr- 没有缓存凭据） - 使用 SQL Server Management Studio 和已验证的数据库权限登录 WID（针对 LOCALSERVICE 和 NETWORKSERVICE 帐户）
- 调整各种注册表项的权限（这确实消除了应用程序事件日志中不相关的 CAPI2 和 WIDWRITER 错误）
- 运行 DCDIAG 并查看应用程序事件日志并清除任何错误和警告（包括 DNS 警告、添加 SPN 和重新注册 AD DNS 条目，以及运行 DFSR 的 D4 权威还原以清除服务器迁移产生的警告）
- 使用 sysinternals ProcessMonitor 进行监控，以识别任何访问被拒绝或其他错误（这让我开始调整文件夹和注册表项的权限，以确保 LOCALSERVICE 和 NETWORKSERVICE（运行 WIDWRITER 和其他 VSS 服务的服务帐户）都有访问权限）
- 验证 VSS 服务和编写器、AADC 等的服务启动类型和登录帐户。
- 停止服务并运行测试（停止 AADC 同步服务可解决所有登录失败问题。这就是我将范围缩小到 AADC 的方法）
- 卸载 AADC
- 在 SQL Express 本地数据库上运行修复
- 使用我们的 MS 合作支持合同致电 Microsoft 支持 - 他们说“没有功能损失，而且您没有无法登录的实际用户，所以我们无法帮助您，请注册 Premier 支持！”（对不起，SYSTEM 不算作重要用户吗？？？）
- 用头撞墙和撞其他东西
在这一切中学到的一个有用的东西
- 卸载并重新安装 AADC 时，
vssadmin list writers在安装过程中不断运行，错误开始立即地在 SQL 组件安装完成后，安装程序尚未完成运行。 - 当安装 SSMS 并且我登录到数据库时，我也会收到我用来登录的 dom 管理员帐户的登录失败事件，尽管我的 SSMS 会话似乎不受影响。
问题显然与 AADC 有关，因为我可以停止 AAD 同步服务或卸载 AADC，所有失败的登录事件都会消失。但卸载 AADC、删除 AADC 文件夹、清理 AADC 用户帐户和清除 AADC 注册表项以尝试获得真正全新的安装却没有效果，当我重新安装 AADC 时错误会立即返回。
此时我已经束手无策了，我不知道还能做什么，也不知道还能去哪里找。我希望有人比我更了解（很可能），或者之前经历过这种情况并找到了解决办法。
最后需要注意的是 - 服务器的 DNS 名称长度为 9 个字符，这意味着它与其 NETBIOS 名称不匹配。我不认为这是原因，但如果有必要，我可以重命名服务器。对于生产中的 DC 和文件服务器来说，这有点令人头疼。
答案1
这个问题最初于 2019 年 10 月开始出现。花了将近一年的时间，但我终于找到了一个暗示可能的解释的解决方案。
解决方案是配置以下注册表项和值：
- 项：HKLM\System\CurrentControlSet\Control\LSA\MSV1.0
- 值类型：多字符串值
- 值名称：BackConnectionHostNames
- 值：服务器的所有 DNS 主机名，每个主机名占一行
这解决了 VSS 针对 SQL 数据库运行时登录失败的问题。
这是 Windows Server 2003 中引入的安全功能的一部分，称为环回检查功能。
根据我读到的有关环回检查功能如何工作的内容，我认为情况是，每当 VSS 登录到 SQL 执行备份时，它都会以 SYSTEM 身份登录。LSA 期望 SYSTEM 登录来自服务器的 DNS 名称，但登录实际上来自服务器的 NETBIOS 名称。由于在这种情况下 DNS 名称与 NETBIOS 名称不匹配，因此 LSA 无法通过 Kerberos 身份验证，登录将返回到接受 NETBIOS 名称的 NTLM。
通过配置，BackConnectionHostNames我们告诉 LSA 接受来自 NETBIOS 和 DNS 名称的连接，并且 Kerberos 身份验证成功。
我能够通过使用来追踪错误Sysinternals 进程监控器追踪错误发生时 VSS 正在执行的所有操作。我发现 VSS 正在访问位于C:\Users\ {AzureADConnect 帐户} \AppData\Local\Microsoft\Microsoft SQL Server 本地 DB\Instances\ADSync我发现错误日志文件。这些日志包含以下错误：
2020-08-13 13:00:47.43 Logon Error: 17806, Severity: 20, State: 14.
2020-08-13 13:00:47.43 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: <named pipe>]
这就是我需要的突破，因为错误信息引导我找到了几个地方，例如这个 SE 问题，建议完全禁用环回检查。我不想禁用安全功能，所以我继续搜索，直到找到来源（1）和（2）描述了如何通过创建注册表项来配置环回检查功能而不禁用它，正如BackConnectionHostNames我上面概述的那样。