PowerShell CIM Cmdlets and WS-Management: Remote Authentication Fallback Behavior

Answer

With New-CimSession -Authentication Default the WS-Man client uses Negotiate/SPNEGO. The client does not choose Basic or Digest under Default. SPNEGO on Windows attempts Kerberos first when a valid domain context and SPN exist, then falls back to NTLM if Kerberos is unavailable or fails. There is no automatic fallback to Basic.

Confirmed facts

• Authentication Default resolves to Negotiate/SPNEGO for New-CimSession and New-PSSession on Windows.
• Negotiate ordering is OS-level SPNEGO: Kerberos attempted first, NTLM used as fallback when Kerberos cannot be completed.
• Authentication selection is independent of PSSessionConfiguration constrained endpoints. Authorization to the endpoint is evaluated after a successful authentication. Fallback does not bypass endpoint permission checks for non-privileged accounts.
• Basic and Digest are only used when explicitly requested with -Authentication Basic and allowed by server policy. Default never selects them.

Likely explanation for target OS influence

Target OS version influences which schemes the WinRM service advertises and permits. The handshake is a negotiation between client offer and server allowed list. Newer Windows releases may restrict NTLM via policy or require encryption, older hosts may lack full Kerberos support for WS-Man, which changes the effective scheme that can be completed. Group Policy and service configuration on the target can disable NTLM or Kerberos, causing Negotiate to fail even though the client attempts the normal Kerberos-then-NTLM order.

Assumption: Windows PowerShell 5.1 and PowerShell 7+ on Windows use the same WS-Man client stack for CIM sessions. Behavior is version-sensitive across client and server releases. This is a conservative description for human review.

Verification steps for this case

1. Check what the target advertises:

   Get-WSManInstance -ResourceURI winrm/config/service/auth -ComputerName <target> -Enumerate

2. Test explicit schemes to isolate capability:

   New-CimSession -ComputerName <target> -Authentication Kerberos
   New-CimSession -ComputerName <target> -Authentication NTLM

3. Confirm domain context and SPN prerequisites on the client side, and review WinRM service configuration on the target for allowed authentication and encryption requirements.

One missing diagnostic detail that changes the recommendation: is the client machine domain-joined to the same forest as the target and is a valid SPN registered for the target host? Without domain context, Kerberos will not succeed and Negotiate will fall back to NTLM immediately, or fail if NTLM is blocked.