Joseph's questions

环境：Windows Server 2019，林/域功能级别 - 2016，约 40 个域控制器，约 17 个站点

PKI 结构：我们从第三方获得证书。我们向他们提交 CSR，并从他们那里获得证书。过去和现在，证书链的顺序是：根证书 > 中间证书 > 机器/用户证书

我在一个站点上有服务器1和服务器2-4，它们各自都有证书。如果我从服务器2检查（使用Windows UI）这两台服务器的证书链，证书链看起来与预期一致。如果我从服务器1检查，两台服务器的证书链顶部都莫名其妙地出现了另一个证书。

这使得我的根 CA 证书看起来像是由另一个证书颁发的，但事实并非如此。

我想知道为什么从不同的服务器查看时这些证书在根目录显示不同的证书。

服务器 1 在漏洞报告中显示由不受信任的证书颁发。服务器 2 未出现在此列表中。生成这些报告的服务器是一台 Linux 服务器，并且似乎正在使用 OpenSSL 执行这些检查。

我们采取的另一个故障排除步骤是剪切一个新的证书。在我导入证书之前，它显示了一个预期的证书链。导入之后，那个神秘的证书又出现了，而且又出现在根证书上方。

因此，在我导入它之前，证书链看起来像 Root > Intermediate > Machine 在我导入它之后，它看起来像这样：Mysterious New Root > Previous Root > Intermediate > Machine

团队，

交换环境都是2016，没有混用。父域和子域存在，但每个域和林的功能级别是2012R2。直到最近，所有域控制器都是 2012R2。AD 团队（与我不同）引入了 Server 2016 域控制器，我认为它引起了问题。以下是症状：

邮件卡在目标为子域的父域中的服务器上。队列上的错误是“454 4.7.0 临时身份验证错误”，事件日志中的相关事件是事件 ID 2017，来源：MSExchangeTransport，消息是：

“发送连接器内部 SMTP 发送连接器的出站身份验证失败，错误 KdcUnknownEncryptionType。身份验证机制是 ExchangeAuth。目标是 SMTPSVC/服务器 fqdn。”

邮件将毫无问题地从子域流向父域。就像我之前所说的，我认为发生的最重要的变化就是引入了 Server 2016 DC。要临时修复它，我可以重新启动消息卡住的服务器，它会工作一段时间。这看起来确实像是一个 Kerberos 问题。

编辑：我们还设置了 ASA，但我所有的交换服务器、DC 和此 ASA 之间支持的加密类型都是“28”。

谷歌搜索显示时间同步问题，但我检查了 Exchange 服务器和域控制器，一切似乎完全同步。我还检查了复制运行状况，似乎没有任何问题。我还检查了重复或格式错误的 SPN，但没有找到任何东西。关于 SPN，我还有更多可以研究的地方吗？就像他们请求/使用什么样的加密一样？我对 Kerberos 了解不多。

编辑：作为另一个说明，使用 GPO，我确实从目标服务器中删除了 RC4-HMAC。结果，该klist tickets命令确实显示了正确的“AES ...”，但后来我的powershell被破坏了......“可能的原因”是：

• “用户或密码错误”
• “未指定身份验证方法和用户名时使用的 Kerberos”
• “Kerberos 接受域用户名，但不接受本地用户名。”
• “远程计算机名称和端口的 SPN 不存在”
• “客户端和远程计算机在不同的域中，没有信任。”

然后它建议尝试在 WinRM TrustedHosts 列表中添加目标计算机。