Add PSWSMan and document PowerShell remoting to Windows hosts

[briantist]

Resolves #22
Resolves #3

My original comment #22 (comment) turned out to be partially wrong. It seems we can get remoting working quite nicely with Kerberos using only PSWSMan, which is a very small add.

I've written up some documentation which I stuck in a separate readme.

This is in the first commit: 678e584

TODOs:

• Pin PSWSMan module version (at least to major version)

---

For NTLM, I believe we need https://github.com/gssapi/gss-ntlmssp and as far as I can tell there are no pre-built binaries. I was able to get it built from source in al2023, but installing it brings in a lot of other dependencies and adds a few hundred MB to the image size.

As a result, I built is a new image so that it could be used more optionally.

That work is in the second commit: b9cfde3

The thing is, I can't actually get NTLM auth working.

If we try in the original runtime for example (or even the one with PSWSMan) to use NTLM auth with credentials like DOMAIN\user, it fails pretty quickly with an error like this:

OpenError: [server01.ad.contoso.com] Connecting to remote server server01.ad.contoso.com failed with the following error message : acquiring creds with username only failed No credentials were supplied, or the credentials were unavailable or inaccessible SPNEGO cannot find mechanisms to negotiate For more information, see the about_Remote_Troubleshooting Help topic.

If I use the image above with gss-ntlmssp installed, it just hangs forever, so.. it changed something, but I get no output at all so I'm pretty stuck.

---

We can split this into two PRs, or maybe the community can come up with an answer for the NTLM stuff.
I wonder if @jborean93 might have any ideas? 👀

Let me know what you all think!

[jborean93]

It is very likely that the images are using a version of OpenSSL that is disabling legacy providers that is required by NTLM (RC4/MD4/etc). See jborean93/omi#71 (comment) for some more information when I last tracked this down.

Just as an FYI it might be a good idea to pin the version of PSWSMan or at least put a major version ceiling. I've been hoping to push a new major version based on a pure C# library under PSWSMan to avoid the mess that is libmi and while it hasn't been released yet it supports more features than libmi and provides a better experience when it comes to error messages and things like authentication support.

[briantist]

Thanks for the tip @jborean93 , I was able to go through some of those troubleshooting steps.

The python snippet worked without me needing to enable any legacy providers.

So I moved on to enabling debug logging for OMI. With the logs being generated I found a few interesting things:

• Connecting only hangs when the credentials are correct and authorized. I get an error message in pwsh if for example the credentials are not authorized to connect to the machine.

• Within the part covered by the OMI log, the process seems to be done, socket closed, etc. I'm not sure why it hangs on the pwsh side.

• The last interesting looking thing before it closes that socket is:

  2024/03/04 01:25:36 [572,595] ERROR: null(0): EventId=20146 Priority=ERROR HTTP: Client Authorization failed. gss:(Invalid token was supplied) mech:(Unknown error)
  2024/03/04 01:25:36 [572,595] DEBUG: null(0): _ReadHeader - OK exit

  (this is with good credentials)

• In contrast, with unauthorized credentials it looks like this:

  2024/03/04 01:33:05 [572,595] ERROR: null(0): EventId=20146 Priority=ERROR HTTP: Client Authorization failed. gss:(null) mech:(null)
  2024/03/04 01:33:05 [572,595] DEBUG: null(0): _ReadHeader - ACCESS DENIED reslt = 0

• One other thing, toward the beginning of the log, is a message about it loading gss api, it seems like it doesn't this once on init, not for each request:

  2024/03/04 01:17:18 [572,595] DEBUG: null(0): EventId=50012 Priority=DEBUG HTTP: Loading gss api. (libgssapi_krb5.so.2)

  I only point this out because it sort of looks like it's loading only krb5 and not loading ntlm? But I'm not sure if I'm misreading it.

• I guess for completeness, with Kerberos auth (only thing I'm changing is the format from DOM\user to user@DOM), it's completely successful:

  2024/03/04 01:39:07 [572,595] DEBUG: null(0): EventId=50010 Priority=DEBUG HTTP: Authorization Complete.
  2024/03/04 01:39:07 [572,595] DEBUG: null(0): _ReadHeader - is authorized. continue
  2024/03/04 01:39:07 [572,595] DEBUG: null(0): _ReadHeader - OK exit