多年后我再次支持 Windows。我被分配到的这个客户有运行 2008r2 和 2012r2 的域控制器，他们想要 Azure AD Connect 密码哈希同步。最低要求是功能级别为 2016。
我安装了一个新的 Server 2019 实例，迁移了 FSMO 角色，并确保所有 DC 都相互复制。我创建了一个新的域用户并运行了登录脚本，该脚本从运行 Ontapp 8.2.2.7 的旧 NetApp FAS2552 映射了一些网络驱动器。这是成功的。
应用补丁并重新启动后，新的 DC 将不再连接驱动器。我相信这与 2022 年 11 月进行的 KDC 更改有关，但我不确定。
我向网络添加了另一个 Server 2019 实例，本地登录并成功连接了 NetApp 驱动器。然后，我安装了 Windows 安全更新，重新启动后，驱动器出现故障，就像在新 DC 上一样。
经过一番挖掘，我发现了以下几件事：
以及随机少量关于一些注册表更改：
reg 添加 HKLM\system\currentcontrolset\services\kdc /v KrbtgtFullPacSignature /t REG_DWORD /d 0 /f
reg 添加 HKLM\system\currentcontrolset\services\kdc /v ApplyDefaultDomainPolicy /t REG_DWORD /d 0 /f
reg 添加 HKLM\system\currentcontrolset\services\netlogon\parameters /v RequireSignorSeal /t REG_DWORD /d 0 /f
这些更改在测试实例上有效，并且 NetApp 驱动器再次连接。只要 %logonserver% 是旧域控制器之一。
这些更改在新域控制器上不起作用，并且当任何客户端将其用作其 %logonserver% 时，驱动器无法连接。
我准备卸载 Windows 安全更新，看看 NetApp 驱动器是否再次连接。然后通知客户，在升级 NetApp 操作系统以支持 AES KDC 身份验证之前，他们的环境无法修补。
任何帮助深表感谢。
答案1
如果是关于2022年11月补丁，您可以检查NetApp是否支持AES加密类型。
2022 年 11 月推出新旗帜。
杰特 AES256-CTS-HMAC-SHA1-96-SK