我们有一个使用 Windows Server 2016 域控制器的客户。这是一家小型企业,因此他们的服务器基础架构由 Hyper-V 主机和此 DC 组成。DC 托管文件共享和 Azure AD Connect,用于将身份与 Office 365 同步。
我们监控事件 ID 4625 并设置警报阈值,以帮助我们识别针对网络的潜在暴力攻击。
去年 10 月,我们开始收到超出登录失败警报阈值的警报。经调查,我们对问题的描述如下:
- 每当我们的 VSS (Datto) 备份运行或 AADC 同步时,登录失败事件都会自然发生
- 备份成功,AADC 正常同步,没有错误
- 有两个账号登录失败:
- SERVERNAME$(例如 SYSTEM 帐户)每当备份运行时
- AAD_* 每当 AADC 运行时
- 事件状态为 0xC000006D - 用户名或密码失败
- 事件 SUB STATUS 为 0x0 - 状态正常
- 系统登录失败可以通过运行轻松复制
vssadmin list writers
过去几个月的故障排除清单很长。这不是一个完整的列表:
- 卸载 RRAS 和 WID(包括删除 WID 文件夹以确保在重新安装角色时正确设置权限)
- 清除 SYSTEM 凭证缓存(使用 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 支持 - 谁说“没有功能损失,并且您没有无法登录的实际用户,所以我们无法帮助您,注册高级支持!” (不好意思,SYSTEM不算重要用户吗???)
- 把我的头撞在几堵墙上和许多其他东西上
在所有这些过程中学到的有用的东西
- 卸载和重新安装 AADC 时,
vssadmin list writers
在安装过程中持续运行,错误在安装SQL 组件后立即开始,甚至在安装程序完成运行之前。 - 安装 SSMS 并登录数据库后,我也会收到登录时使用的 dom 管理员帐户的登录失败事件,尽管我的 SSMS 会话似乎不受影响。
该问题显然与 AADC 有关,因为我可以停止 AAD 同步服务或卸载 AADC,并且所有失败的登录事件都会消失。但是卸载 AADC 并删除 AADC 文件夹并清除 AADC 用户帐户并清除 AADC 注册表项以尝试获得真正的全新安装没有任何效果,当我重新安装 AADC 时错误会立即返回。
在这一点上,我束手无策,我不知道还能做什么,甚至不知道还能去哪里看。我希望以太中的某个人比我知道的更多(可能),或者以前经历过这种情况并找到了解决办法。
最后一点 - 服务器的 DNS 名称长度为 9 个字符,这意味着它与其 NETBIOS 名称不匹配。我不认为这是原因,但如有必要,我可以重命名服务器。对于生产中的 DC 和文件服务器来说,这只是一件令人头疼的事情。
这个问题最初是在 2019 年 10 月开始出现的。花了将近一年的时间,但我终于找到了一个解决方案,它暗示了一个可能的解释。
解决方案是配置以下注册表项和值:
这解决了每当 VSS 针对 SQL 数据库运行时登录失败的问题。
这是 Windows Server 2003 中引入的称为Loopback Check Functionality的安全功能的一部分。
根据我所读到的有关 Loopback Check Functionality 的工作原理,我相信发生的事情是,每当 VSS 登录到 SQL 以执行备份时,它都会以 SYSTEM 身份登录。LSA 期望 SYSTEM 的登录来自服务器的 DNS 名称,但登录实际上来自服务器的 NETBIOS 名称。由于在这种情况下 DNS 名称与 NETBIOS 名称不匹配,因此 LSA 无法通过 Kerberos 身份验证,并且登录回退到接受 NETBIOS 名称的 NTLM。
通过配置
BackConnectionHostNames
,我们告诉 LSA 接受来自 NETBIOS 和 DNS 名称的连接,并且 kerberos 身份验证成功。我能够通过使用Sysinternals ProcessMonitor来跟踪错误发生时 VSS 所做的一切。我发现 VSS 访问位于C:\Users\ {AzureADConnect Account} \AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\ADSync的文件夹,在那里我找到了error.log文件。这些日志包含以下错误:
这是我需要的突破,因为该错误信息将我带到了几个位置,例如这个 SE question,它建议完全禁用环回检查。不想禁用安全功能,我继续搜索,直到找到源(1)和(2),这些源描述了如何在不禁用环回检查功能的情况下通过创建
BackConnectionHostNames
我上面概述的注册表项来配置它。