因此，基本上我们有一个团队拥有运行 PowerShell Core（6 和 7 的混合）的 Linux 服务器，必须在 Windows 服务器上执行远程 Windows PowerShell 命令。问题是，该团队从未使用 Kerberos 进行身份验证，而是依靠 gssapi 进行 NTLM 身份验证，据我所知，MS 实际上不支持这种方案。
现在的情况是这些 Linux 服务器在一段时间后收到 MI_RESULT_FAILED 错误（这是上周才开始的，之前一切正常），需要重新启动远程节点上的 WinRM 服务才能使远程工作正常。这可以工作大约一天，然后 WinRM 需要再次重新启动。
现在，由于 NTLM 不是 Linux 上 PowerShell Core 支持的身份验证机制（仅由于由 RedHat 而非 Microsoft 维护的 gssntlmssp 而有效），因此这里明确的前进方向是改用 OpenSSH 从 Linux 进行 PS 远程处理，或者转而使用 Kerberos 身份验证而不是 NTLM。但是，由于上周之前一切正常，管理层不想考虑通过身份验证或协议更改来解决这个问题，他们希望修复正在运行的东西。此时，我正在努力找出 NTLM 身份验证失败的原因，我推荐的修复方法目前已无法实施。
源节点运行的是 RHEL8 或 AL2，远程节点运行的是 Windows 2016-2019，其中还混杂了一些旧版 2012。Windows 到 Windows PS 远程处理不是中断就在这里，仅限 Linux 到 Windows。
有人遇到过这种情况或类似情况吗？关于如何解决此问题，您有什么想法吗？
编辑：我已将上述错误更正为MI_RESULT_FAILED。ACCESS_DENIED这是报告该问题的团队所说的，但在我们重现该问题时我们看到MI_RESULT_FAILED。WinRM 跟踪显示 NTLM 身份验证成功，但即使只是通过 显示“Hello World” 仍然会失败Invoke-Command。
答案1
我遇到了完全相同的问题，我们的具体错误是 MI_RESULT_FAILED。重新启动 WinRM 服务后一切正常，但第二天它又停止工作了。
原来是防病毒软件阻止了 WinRM 服务，因为 AWX Ansible 发出了脚本化的 powershell 请求，因为 AWX 对命令使用了 base64 编码，从而触发了“Powershell 命令限制 - EncodedCommand”规则。该命令在夜间发送了两次，因此直到早上 WinRM 重新启动之前，通过该 PID 进行的所有通信都被我们的 AV 阻止了。希望对您有所帮助！