The WinRM auth matrix

Lesson 30 settled how you connect to Windows — winrm, psrp or ssh. This lesson settles who you are when you arrive. For the two WinRM-based plugins, that’s an explicit choice among five authentication options — and the whole decision fits in one table from the official docs. Memorise it; it’s worth knowing cold:

Read it column by column. Local vs AD accounts splits the field. Basic and Certificate only authenticate local Windows accounts — dead on arrival for a domain estate. Kerberos is the mirror image: domain accounts only, because it needs a domain controller to issue tickets. NTLM and CredSSP take both.

HTTP encryption decides your port. WinRM refuses an unencrypted channel, but Kerberos, NTLM and CredSSP encrypt the message payload themselves. That satisfies the rule even on plain HTTP 5985. Basic and Certificate bring no encryption of their own, so they only work inside a TLS tunnel on 5986. Hence the official guidance: Basic and NTLM only over HTTPS, and only for local accounts.

Delegation means credential delegation — whether the remote host can reuse your credentials to reach a second machine, like a file share. That column is the whole plot of lesson 35. For now, notice which two rows say Yes.

What the docs actually recommend

In a domain: “Kerberos is the recommended authentication option to use when running in a domain environment.” It’s the only row with no security caveat — encrypted payload, credential delegation available, no password ever sent to the target. For local accounts (the workgroup box, the DMZ host): Basic or NTLM, over HTTPS only.

CredSSP — the row where every column says Yes — carries the sternest warning in the guide. Use it only when absolutely necessary, because “it can be a security risk due to its use of unconstrained delegation.” CredSSP earns its Delegation Yes by handing your actual credentials to the remote host. If that host is compromised, so are you — everywhere those credentials work.

Setting it in inventory

The switch is one variable, ansible_winrm_transport, set where lesson 9 taught you to put connection settings — a group’s group_vars file:

ansible_connection: winrm
ansible_winrm_transport: kerberos # basic | certificate | kerberos | ntlm | credssp
ansible_user: svc_ansible@CORP.EXAMPLE.COM
ansible_port: 5985 # fine in-domain: Kerberos encrypts the payload itself

If the group uses the psrp plugin instead, the variable is ansible_psrp_auth — same five values plus one more:

ansible_connection: psrp
ansible_psrp_auth: negotiate # tries Kerberos first, falls back to NTLM

negotiate is a pragmatic default for mixed estates — domain hosts get Kerberos, the stragglers get NTLM, one group_vars file covers both.

Scope note: this matrix is the WinRM world. If your team standardises on SSH for Windows (lesson 30’s third option), the whole table evaporates — SSH brings its own key-based auth and none of these variables apply. But on-prem AD estates in 2026 still overwhelmingly speak WinRM. When a Windows host answers 401, start here: which row are you on, does it support your account type, is the channel encrypted? Lesson 32 puts it into practice — configuring the Windows side so one of these rows lets you in.