AD迁移至2022域控制器后医疗软件LDAP/LDAPS绑定认证失败求助

看到你遇到的这个问题真是头疼——医疗软件对LDAP依赖这么强，偏偏卡在新DC上，还排除了密码问题，换非DC的AD LDS也不行，确实够诡异的。结合我碰到过的类似场景，给你几个方向试试，说不定能解决：

• 检查NTLM身份验证限制：Windows Server 2022默认对NTLM的限制比2012严格得多。如果这个医疗软件用的是NTLMv1或者老版本的NTLM，新DC可能直接拒绝。你可以先在2022 DC上临时放宽NTLM策略试试：

  1. 打开组策略编辑器（gpedit.msc），定位到计算机配置>Windows设置>安全设置>本地策略>安全选项
  2. 找到网络安全: LAN管理器身份验证级别，改为“发送LM和NTLM - 如果协商使用NTLMv2会话安全”
  3. 同时检查网络安全: NTLM: 拒绝NTLM身份验证这类相关策略，确保没有完全禁用NTLM
     改完后运行gpupdate /force，再测试绑定。如果能成功，说明是NTLM版本的问题，后续可以联系软件厂商升级，或者在DC上做针对性的NTLM例外配置。

• 检查Kerberos预身份验证设置：虽然报错是52e，但有时候Kerberos的问题也会伪装成密码错误。打开AD用户和计算机，找到用于绑定的账号，右键属性>账户>账户选项，看看“不需要Kerberos预身份验证”有没有勾选？如果没勾，试试勾选上再测试——有些老软件不支持Kerberos预验证，新DC对这个的校验更严格。

• 检查AD账户的UAC属性：有时候账户的某些UAC标志会导致新DC拒绝认证。用dsquery user -name "<REDACTED>" | dsget user -uac查看账户的UAC值，对比能正常认证的旧DC上的账户UAC。比如如果有“智能卡必须”或者“账户禁用”这类标志肯定不行，但还有一些隐藏的标志，比如“使用DES加密类型”这类，新DC可能不兼容。

• 抓包分析认证过程：如果上面的方法都不行，建议用Wireshark在新DC上抓LDAP/LDAPS的包，对比旧DC上的认证流程。重点看客户端发送的身份验证类型（是NTLM还是Kerberos），以及DC返回的错误细节。比如如果客户端发的是NTLMv1，新DC直接返回拒绝，那就能锁定问题了。

备注：内容来源于stack exchange，提问作者Parallax Abstraction