Kerberos Interop issues with OMI server

[Iristyle]

Kerberos connections immediately terminate when connecting to OMI server, despite OMI authorizing the given Kerberos ticket, returning a 200 OK and an encrypted body.

Upon decryption, the message is corrupted on the client side... which would seemingly indicate a problem like:

• A difference in expectations around payload structure
• Incorrect key negotiation?

The OMI server Kerberos configuration appears to be configured correctly as two other clients can use Kerberos to talk to the server:

• omicli included with OMI itself
• pwsh (6.2.1)

I have a full reproduction environment that's containerized at puppetlabs/bolt#1101

Follow the description in the PR and you'll end up with 3 containers:

• Samba serving as Active Directory
• OMI Server listening for winrm connections (domain joined)
• An Ubuntu dev environment that has Bolt / winrm gem (domain joined)

I've spent a little bit of time looking at the messages, poking around in pry and augmenting the omi source in an effort to hone in on where the negotiation problem is, but haven't had the a-ha moment just yet. Before I get too far into the weeds, figured I'd post this issue to see if there are any known issues around the Kerberos handling.

Thanks!

[jborean93]

Just an FYI I think I've come across a similar problem when talking to an Exchange based PowerShell endpoint. It is using a custom dll to authenticate the client and encrypt the data and I'm finding that the data is being decrypted without any trouble but it still contains garbage characters https://social.msdn.microsoft.com/Forums/en-US/57709b1d-0578-4ee3-bbc8-975024ed2aee/powershell-remoting-on-exchange-encrypted-data?forum=os_windowsprotocols. I'm still trying to investigate why this is happening but the behaviour I'm seeing with Exchange seems to correlate with what you are seeing with an OMI server.

Edit: unfortunately this might not be related, I tried using PowerShell Core on Linux to connect to the endpoint and it is also failing to continue on past the first encrypted message received from the host. Seems like something special that Windows is doing that I am not privy to.