Linux servers stopped being able to use PowerShell remoting over WinRM using NTLM on remote Windows Servers

So basically we have a team with Linux servers running PowerShell Core (a mix of 6 and 7) that have to execute remote Windows PowerShell commands on Windows servers. Problem is, the team never got Kerberos working for authentication and is relying on gssapi for NTLM auth to work, which AFAIK is not actually supported by MS for this scenario.

What is happening now is these Linux servers are getting MI_RESULT_FAILED errors after a while (this just started last week, things were working fine prior) and requires a restart of the WinRM service on the remote node in order for remoting to work. This works for about a day before WinRM needs to be bounced again.

Now, since NTLM isn't an auth mechanism supported by PowerShell Core on Linux (only works due to gssntlmssp which is maintained by RedHat, not Microsoft), the clear path forward here would be to either use OpenSSH for PS Remoting from Linux instead, or pivot to using Kerberos authentication instead of NTLM. However, since things were working before last week, management does not want to entertain an authentication or protocol change to resolve this issue, they want what was working to be fixed. At this point I'm spinning my wheels trying to figure out why NTLM auth broke, and my recommended fixes are off the table for now.

Source nodes are running RHEL8 or AL2, remote nodes are Windows 2016-2019, with a few legacy 2012s in the mix. Windows to Windows PS Remoting does not break here, only Linux to Windows.

Has anybody hit this situation before or something similar? Any ideas on what we might try to resolve this?

EDIT: I've corrected the error above to MI_RESULT_FAILED. ACCESS_DENIED is what the team who reported the issue said, but in our reproduction of the issue we see MI_RESULT_FAILED. WinRM trace shows NTLM auth is succeeding but still fails even when simply displaying "Hello World" via Invoke-Command.

I have encountered the exact same issue, our specific error was MI_RESULT_FAILED. Everything worked fine after restarting the WinRM service, but the next day it stopped working again.

It turned out to be antivirus blocking the WinRM service, when a scripted powershell request from AWX Ansible came through, because AWX used base64 encoding for the command, which triggered the 'Powershell Command Restriction - EncodedCommand' rule. That command was sent twice overnight, so until the WinRM was restarted in the morning, all communication through that PID was blocked by our AV. Hope it helps!