WinRM authentication methods

Ensure that you have the required Python modules installed on the execution node or execution environment for the authentication method in use, such as pywinrm, pypsrp, pykerberos, requests-credssp, and/or requests-ntlm. These are all included in recent supported execution environments.

If legacy WinRM transport or alternative authentication methods must be retained due to compliance constraints, consult this architectural decision matrix:

Authentication Selection Path]
   |
   +-> Domain Joined?
   |     |
   |     +--> Yes: Use Kerberos (High Security, Native Delegation)
   |     +--> No:  Workgroup Environment?
   |              |
   |              +--> Certificates (X.509) -> Secure Local Auth (No passwords over wire)
   |              +--> NTLM (Message Encryption) -> Fallback, FIPS-Incompatible
   |              +--> CredSSP -> Avoid unless multi-hop required without AD

HTTPS and WinRM Certificates

One way to manage certificates in AD domains is Active Directory Certificate Services (AD CS). It makes configuring WinRM with HTTPS and proper certificates feasible. However, if the customer is not using AD CS, if their DNS setup is not optimal, if they have many non-domain systems, or they do not want additional certificate management, then that might prevent using WinRM HTTPS with proper certificates.

Basic-over-HTTP

Basic authentication should be avoided in all environments. For non-domain joined systems, NTLM with message encryption is the preferred baseline. For production and domain-joined systems, Kerberos or PSRP with Kerberos authentication should be the standard to ensure secure credential delegation and mutual authentication.

Basic-over-HTTPS and Self-Signed Certificate

Basic-over-HTTPS using a self-signed certificate is an improvement over Basic-over-HTTP for non-production setups without the need for a fully thought-out authentication scheme with WinRM. While not acceptable for production, this can be considered for early testing as it allows for encrypted authentication and communications.

Basic-over-HTTPS and Signed Certificates

This requires a certificate management solution to be in place. In this case it might be better to use X.509 certificates, instead of username+password, for Ansible, but with certificate CA chain validation enabled after making the issuer certificate of the CA known to Ansible on the execution node or execution environment.

ansible_winrm_server_cert_validation: validate

ansible_winrm_ca_trust_path: /path/to/certificate/public/ca.pem

Certificate authentication (X.509)

Certificate-based authentication maps X.509 certificates to local users, mimicking SSH key behaviors.

• Architectural Trade-offs: Keys cannot map to Active Directory domain accounts. Private keys used by Ansible must be unencrypted and stored securely on the execution node as local files. If the underlying Windows local account password changes, an administrator must rebuild the cryptographic mapping manually.
• Inventory Variable Syntax

  ansible_winrm_transport=certificate
  ansible_winrm_cert_validation=validate
  ansible_winrm_ca_trust_path=/path/to/ca_cert.pem
  ansible_winrm_cert_key_pem=/path/to/client.key
  ansible_winrm_cert_pem=/path/to/client.pem

NTLM authentication

By default NTLM only allows the Administrator user, not users in the Administrators group, to connect (at least in non-domain environments). Also note that NTLM is not compatible with FIPS so with FIPS Kerberos is likely the best option.

ansible_winrm_transport: ntlm
ansible_winrm_message_encryption: always

CredSSP authentication

CredSSP is a more modern authentication method with support for domain and local users, credential delegation, and authentication and session traffic encryption over HTTP. It uses NTLM or Kerberos for initial authentication underneath. However, a recent Microsoft post states that enabling CredSSP is a degraded security posture.

If CredSSP is needed, even considering the warning above, enable CredSSP authentication on the WinRM server side with the following command or with the WinRM role:

Powershell: (on the Windows host)

Ansible inventory/host variables

ansible_winrm_transport: credssp
ansible_winrm_message_encryption: always

CredSSP might be considered in some special cases, especially when credential delegation is crucial, but in most cases it is not recommended. In FIPS mode NTLM is not possible to use for the initial CredSSP authentication.

• Security Risk: CredSSP enables remote credential delegation for multi-hop operations outside Active Directory. However, Microsoft identifies enabling CredSSP as a degraded security posture because cleartext-equivalent credentials pass to the target memory space. Use Kerberos delegation instead wherever possible.

FIPS-Compliant Alternatives

If Certificate authentication proves unsuitable for your FIPS-compliant environment, consider these more stable alternatives in order of preference:

• Kerberos Authentication: The standard for domain-joined systems; highly recommended over certificates.
• SSH Connection: Using OpenSSH for Windows avoids WinRM complexities entirely while maintaining high security.

Authentication decision table

Select the optimal WinRM authentication method to securely manage your Windows environment. Use this decision table to compare Kerberos, CredSSP, NTLM, Basic, and Certificate schemes based on domain support, credential delegation needs, and security levels