Administrer Windows Server avec Ansible : WinRM, SSH et premiers playbooks

Ansible ne tourne pas sur Windows, mais il pilote très bien des serveurs Windows. Tout se joue dans la connexion : WinRM ou SSH, le bon mode d'authentification et un canal chiffré.

Par la rédaction de Pixelabs · 12 octobre 2026

Une précision d'abord, parce que c'est la première question posée : on n'installe pas Ansible sur Windows. Le nœud de contrôle, la machine qui exécute Ansible, doit être un système de type UNIX ; sous Windows, cela passe par une distribution Linux dans WSL. Les serveurs Windows sont des nœuds gérés : rien à y installer, Ansible s'y connecte à distance et exécute des modules écrits en PowerShell.

Selon la documentation Ansible, les nœuds Windows doivent tourner sous Windows Server 2016, Windows 10 ou plus récent ; ces versions embarquent PowerShell 5.1, ce qui suffit. Le support d'une version de Windows suit son cycle de vie étendu chez Microsoft. Windows Server 2016 sort de son support étendu le 12 janvier 2027 : prévoyez Windows Server 2022 ou 2025 pour un nouveau lab. Ouvrir WinRM ou SSH change la surface d'attaque d'un serveur : testez sur une VM de lab, avec un instantané, avant toute production.

WinRM ou SSH : choisir la connexion

Ansible propose trois plugins de connexion pour Windows : winrm et psrp, qui passent tous deux par WinRM (Windows Remote Management), et ssh.

Entre les deux plugins WinRM, la documentation présente psrp comme le plus récent : un peu plus rapide, moins sensible aux expirations sur un hôte chargé, meilleur avec un proxy. C'est celui utilisé ici.

Topologie du lab

Préparer le nœud de contrôle

Partez d'une installation fonctionnelle d'Ansible, par exemple en suivant la page pour installer Ansible sur Rocky Linux. Les plugins WinRM ont des dépendances Python qui ne sont pas dans le paquet Ansible. Avec une installation par pip :

pip3 install "pypsrp<=1.0.0"
pip3 install "pywinrm>=0.4.0"

La première ligne sert au plugin psrp, la seconde au plugin winrm. Avec pipx, la documentation utilise pipx inject ansible suivi du même nom de paquet.

Préparer Windows : l'écouteur WinRM

WinRM écoute sur un port et accepte les requêtes de gestion. Sur Windows Server, le service est actif par défaut, mais un écouteur HTTPS demande un certificat. La documentation Ansible fournit ce script de démonstration, à exécuter dans PowerShell en administrateur :

Enable-PSRemoting -Force
$certParams = @{
    CertStoreLocation = 'Cert:\LocalMachine\My'
    DnsName           = $env:COMPUTERNAME
    NotAfter          = (Get-Date).AddYears(1)
    Provider          = 'Microsoft Software Key Storage Provider'
    Subject           = "CN=$env:COMPUTERNAME"
}
$cert = New-SelfSignedCertificate @certParams
$httpsParams = @{
    Path                  = 'WSMan:\localhost\Listener'
    Address               = '*'
    CertificateThumbprint = $cert.Thumbprint
    Enabled               = $true
    Port                  = 5986
    Transport             = 'HTTPS'
    Force                 = $true
}
New-Item @httpsParams
$firewallParams = @{
    Action      = 'Allow'
    Description = 'Inbound rule for Windows Remote Management via WS-Management. [TCP 5986]'
    Direction   = 'Inbound'
    DisplayName = 'Windows Remote Management (HTTPS-In)'
    LocalPort   = 5986
    Profile     = 'Any'
    Protocol    = 'TCP'
}
New-NetFirewallRule @firewallParams

Le projet prévient lui-même que ce script est une démonstration : ouvrir le port à tous les profils ou utiliser un certificat autosigné ne convient pas forcément à la production. Dans un domaine, un certificat émis par les services de certificats Active Directory (AD CS) est la solution propre. Pour vérifier les écouteurs :

winrm enumerate winrm/config/Listener

Chaque écouteur affiche son Transport, son Port et, en HTTPS, le CertificateThumbprint du certificat utilisé.

Choisir l'authentification

C'est là que la plupart des échecs se produisent. La documentation recommande Kerberos sur HTTP dans un domaine, ou Basic/NTLM sur HTTPS pour des comptes locaux. Basic et NTLM ne doivent jamais passer sur un écouteur HTTP.

• NTLM : actif par défaut sur WinRM, comptes locaux et de domaine, sans délégation d'identifiants.
• Kerberos : recommandé en domaine, chiffre les messages même en HTTP, mais demande une configuration supplémentaire sur le nœud de contrôle.
• Negotiate (plugin psrp) : tente Kerberos, puis revient à NTLM.
• CredSSP : à réserver aux cas où la délégation est indispensable, car elle utilise une délégation non contrainte.

Par défaut, WinRM refuse de fonctionner sur un canal non chiffré. La documentation décrit comment lever cette exigence côté Windows, et le réserve explicitement au débogage : ne le faites pas sur un serveur réel.

L'inventaire et le premier test

Les variables de connexion se déclarent pour le groupe Windows. Le mot de passe ne doit pas être écrit en clair : stockez-le dans un fichier chiffré avec Ansible Vault.

windows:
  hosts:
    srv-win01:
      ansible_host: 192.168.10.60
  vars:
    ansible_connection: psrp
    ansible_psrp_auth: negotiate
    ansible_port: 5986
    ansible_user: admin-ansible@LAB.LOCAL
    ansible_password: "{{ vault_win_password }}"

Avec un certificat autosigné, la connexion échoue tant que le nœud de contrôle ne fait pas confiance à l'émetteur. La variable ansible_psrp_cert_validation: ignore contourne la vérification en lab ; en production, faites plutôt confiance au certificat de l'autorité AD CS.

Le test de connexion utilise win_ping, l'équivalent Windows du module ping : ce n'est pas un ping ICMP, mais une vérification que la gestion à distance répond.

ansible windows -i inventory.yml -m ansible.windows.win_ping

Un premier playbook Windows

Les modules Linux classiques, écrits en Python, ne fonctionnent pas sur Windows. Il faut ceux des collections ansible.windows, community.windows, microsoft.ad ou chocolatey.chocolatey. Cet exemple installe le rôle IIS, redémarre si nécessaire et s'assure que le spouleur d'impression démarre automatiquement :

- name: Configuration de base des serveurs Windows
  hosts: windows
  tasks:
    - name: Installer IIS avec ses outils de gestion
      ansible.windows.win_feature:
        name: Web-Server
        state: present
        include_management_tools: true
      register: iis

    - name: Redémarrer si l'installation l'exige
      ansible.windows.win_reboot:
      when: iis.reboot_required

    - name: Démarrage automatique du spouleur
      ansible.windows.win_service:
        name: spooler
        start_mode: auto
        state: started

Pour les logiciels, la collection chocolatey.chocolatey s'appuie sur le gestionnaire présenté dans la page pour installer Chocolatey. Les mises à jour se gèrent avec win_updates, par catégorie.

L'option SSH

Depuis Windows Server 2022, la version d'OpenSSH livrée par Microsoft est assez récente pour le support officiel d'Ansible. Après avoir ajouté la fonctionnalité OpenSSH Server et ouvert le port 22, deux variables suffisent côté inventaire : ansible_connection: ssh et ansible_shell_type: powershell. La documentation conseille de passer le shell par défaut d'OpenSSH de cmd.exe à powershell.exe. Attention : pour un compte administrateur, la clé publique va dans C:\ProgramData\ssh\administrators_authorized_keys, pas dans le profil.

Et ensuite

Pour lancer ces playbooks depuis une interface web, avec un journal et des droits par équipe, voyez Rundeck pour piloter Ansible ou CTFreak. Le reste est rangé dans la rubrique automatisation de l'administration système.

Questions fréquentes