brew install pkg-config openssl
rm -rf output
./configure --enable-debug --prefix=/opt/omi-dev
make
sudo make install
sudo mv /usr/local/microsoft/powershell/7/libmi.dylib /usr/local/microsoft/powershell/7/libmi.dylib.bak
sudo ln -s /opt/omi-dev/lib/libmi.dylib /usr/local/microsoft/powershell/7/libmi.dylib
{
"version": "0.2.0",
"configurations": [
{
"name": "(lldb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "/usr/local/bin/pwsh",
"args": [
"-Command",
"$c = [PSCredential]::new('vagrant-domain@DOMAIN.LOCAL', (ConvertTo-SecureString -AsPlainText -Force -String 'VagrantPass1')); Invoke-Command -ComputerName server2019.domain.local -Authentication Kerberos -Credential $c -ScriptBlock {hostname.exe}"
],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "lldb"
}
]
}
- Using
GSS_KRB5_NT_PRINCIPAL_NAME
for the name type which is pretty strict with the target SPN- Without the
default_realm
set in thekrb5.conf
then this will probably fail - Should be using
GSS_C_NT_HOSTBASED_SERVICE
instead but that adds a further complication, see Negotiate
- Without the
- When
-Authentication Negotiate
is set, NTLM always seems to be used when it should be a last resort- This seems to be because the mechlist order in OMI is
['SPNEGO', 'NTLM', 'KERB']
and that's used to derive the priority in SPNEGO
- This seems to be because the mechlist order in OMI is
- While
GSS_C_NT_HOSTBASED_SERVICE
is used for the name type it's using the wrong string format- It's using the krb5 principal format
http/hostname
and notHTTP@hostname
- Note the service part should also be capitalised
- It's using the krb5 principal format
- This effectively makes
Negotiate
an NTLM only process when it should really be SPNEGO - A bug on SPNEGO where the NTLM Authentication message is generated and the context is set to complete but never sent to the target causing an auth failure
- Not a problem on Linux as the context isn't seen to be complete until the SPNEGO mechListMIC was sent back, macOS has a problem with this, see below
- A bug on macOS SPNEGO with NTLM where it generates the mechListMIC on the NTLM auth but thinks the context is complete. Technically it requires the mechListMIC from the server but that fails to process because it thinks it shouldn't need any more token
- Cannot fix this as it's a bug on the macOS SPNEGO/NTLM side
- Need to figure out how to enable logging to debug issues without having to step through the code
- Would also like to make the error messages more descriptive as to what the problem was
- Right now things mostly fail with the below, not very helpful when tracking down the problem - the error was it could not connect to the IP
Connecting to remote server 192.168.56.17 failed with the following error message : MI_RESULT_FAILED For more information, see the about_Remote_Troubleshooting Help topic.
- Multiple requests re-auth causing lots of unecessary network trips as well as authentication attempts
- Whether implicit kerb auth works, i.e.
kinit user@REALM
then Enter-PSSession without a credential
- microsoft/omi#669 - Required to build OMI on modern macOS versions
- microsoft/omi#670 - Fixes
-Authentication Kerberos
on macOS, still requires a very specific host setup to work properly
- Fix up
Negotiate
auth to use Kerberos first and fallback to NTLM not just NTLM - Fix up
NTLM
throughSPNEGO
on macOS so it sends the auth header to authenticate itself - See if it's possible to use a lookup for the OpenSSL libs and not hardcode the path when compiling
- Allows someone to use either the builtin OpenSSL or one from Homebrew
- Might just settle on using the builtin system paths and require people to symlink instead of using the custom macports path for now
- Try and improve the error messages that libpsrpclient reports
- Not sure if this needs to be done through OMI or libpsrpclient
- Not a fix but I want to find a way to enable client side logging to debug failures
- Not require a re-authentication on every message, should hopefully utilise some session cookie