Ansible Windows: Gestire Server Windows con WinRM e Moduli Core (2026)

L’automazione è la chiave per la gestione efficiente di infrastrutture IT complesse. Quando si parla di ambienti misti, dove Linux e Windows convivono, Ansible emerge come uno strumento potente e flessibile. Ho visto in prima persona come la gestione manuale di centinaia di server Windows possa trasformarsi in un incubo operativo: 350 server da patchare manualmente ogni mese significavano 3 giorni di lavoro intensivo, con un’alta probabilità di errori umani. Questo non è solo uno spreco di risorse, ma un rischio costante per la sicurezza e la stabilità dell’infrastruttura. L’introduzione di Ansible, configurato correttamente con WinRM, ha rivoluzionato questo processo, riducendo il tempo di esecuzione a soli 45 minuti con log centralizzati e la possibilità di rollback automatico. Questo articolo esplora come sfruttare Ansible per orchestrare i server Windows, concentrandosi sulla configurazione sicura di WinRM, l’uso dei moduli core e scenari pratici di automazione, inclusa la gestione di Active Directory e il patching.

Prerequisiti: WinRM, PowerShell 5.1+, .NET Framework

Prima di poter gestire i server Windows con Ansible, è fondamentale assicurarsi che i prerequisiti siano soddisfatti. Il protocollo chiave per la comunicazione tra il controller Ansible (tipicamente Linux) e gli host Windows è WinRM (Windows Remote Management). Questo servizio, basato su SOAP, permette l’esecuzione remota di comandi PowerShell e l’accesso a dati WMI. Per un funzionamento ottimale e sicuro, i server Windows target devono avere:

• Windows Management Framework (WMF) 5.1 o superiore: include PowerShell 5.1, che migliora le capacità di scripting e l’affidabilità di WinRM. Molte versioni di Windows Server moderne lo includono di default, ma per quelle più datate potrebbe essere necessario un aggiornamento.
• .NET Framework 4.5 o superiore: necessario per il corretto funzionamento di PowerShell e WinRM.

Assicurarsi che questi componenti siano aggiornati è il primo passo per evitare problemi di connettività e compatibilità. È un errore che ho visto ripetutamente: tentare di configurare Ansible su server Windows con versioni obsolete di PowerShell, portando a errori criptici e perdita di tempo prezioso.

Configurare WinRM per connessioni Ansible (sicuro via HTTPS)

La configurazione di WinRM è il cuore della comunicazione tra Ansible e i server Windows. Per scopi di sicurezza, è imperativo configurare WinRM per utilizzare HTTPS. Questo garantisce che tutte le comunicazioni siano crittografate, proteggendo le credenziali e i dati scambiati.

Sul server Windows, aprire una console PowerShell come amministratore ed eseguire:

winrm quickconfig
Set-Item WSMan:\localhost\Service\AllowUnencrypted $false

Il comando winrm quickconfig configura i listener WinRM di base e apre le porte del firewall necessarie. Set-Item WSMan:\localhost\Service\AllowUnencrypted $false disabilita le connessioni non crittografate, una best practice fondamentale. Per HTTPS, è necessario un certificato SSL (autofirmato per test, CA-firmato per produzione) e configurare un listener HTTPS. Questo è un passaggio spesso trascurato, ma critico per la compliance (es. NIS2 art. 21) e la protezione dei dati.

# Creare un certificato autofirmato (SOLO PER TEST)
$cert = New-SelfSignedCertificate -DnsName "$env:COMPUTERNAME" -CertStoreLocation Cert:\LocalMachine\My

# Creare un listener HTTPS
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="$env:COMPUTERNAME"; CertificateThumbprint="$($cert.Thumbprint)"}

# Aprire la porta 5986 nel firewall (se non già aperta da quickconfig)
New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Allow

Verificare che la porta 5986 (default HTTPS per WinRM) sia accessibile dal controller Ansible e che il certificato sia attendibile. In ambienti enterprise, un certificato emesso da una CA interna è lo standard.

Inventory e variabili per host Windows

Per Ansible, gli host Windows vengono definiti nel file di inventory, proprio come gli host Linux. La differenza risiede nelle variabili di connessione specifiche per WinRM.

Ecco un esempio di inventory.ini:

[windows_servers]
winserver01.example.com
winserver02.example.com

[windows_servers:vars]
ansible_port=5986
ansible_connection=winrm
ansible_winrm_transport=kerberos # o ntlm, o basic se https
ansible_winrm_server_cert_validation=ignore # o validate per certificati CA validi
ansible_user=Administrator
ansible_password='YourStrongPassword'
# ansible_winrm_kinit_mode=always # Per Kerberos
# ansible_winrm_kerberos_delegation=true # Per Kerberos

Le variabili chiave sono:

• ansible_port: 5986 per HTTPS, 5985 per HTTP.
• ansible_connection: deve essere winrm.
• ansible_winrm_transport: kerberos per ambienti Active Directory (altamente consigliato), ntlm come fallback, o basic se si usa HTTPS e non si ha Kerberos. Il basic con HTTPS è un compromesso accettabile per ambienti meno complessi.
• ansible_winrm_server_cert_validation: ignore è utile per test con certificati autofirmati, ma in produzione si userà validate se il certificato è valido e attendibile.

Per testare la connessione, usare il modulo win_ping:

ansible windows_servers -m win_ping -i inventory.ini

Se la connessione ha successo, si riceverà un pong di risposta. Questo conferma che WinRM è configurato correttamente e che Ansible può comunicare con l’host Windows.

Moduli core: win_package, win_service, win_file, win_reg

Ansible offre un set ricco di moduli specifici per Windows che consentono di gestire praticamente ogni aspetto di un server. Questi moduli sono idempotenti, il che significa che possono essere eseguiti più volte senza causare effetti collaterali indesiderati.

• win_package: Installa, disinstalla o aggiorna pacchetti software MSI o eseguibili. Ho usato questo modulo per distribuire agent EDR su 2.000 workstation.

    - name: Install 7-Zip
      win_package:
        path: 'C:\temp\7z1900-x64.msi'
        product_id: '{23170F69-40C1-2702-1900-000001000000}' # ID del prodotto MSI
        state: present

• win_service: Gestisce lo stato dei servizi Windows (avviato, fermato, riavviato, disabilitato, abilitato).

    - name: Ensure the Spooler service is running and set to automatic
      win_service:
        name: Spooler
        state: started
        start_mode: auto

• win_file: Crea, modifica o elimina file e directory, imposta permessi.

    - name: Create a directory
      win_file:
        path: C:\ansible_logs
        state: directory

• win_reg: Gestisce le chiavi e i valori del registro di sistema di Windows.

    - name: Set a registry value
      win_reg:
        path: HKLM:\SOFTWARE\MyCompany
        name: 'Setting1'
        data: 'Value1'
        type: string
        state: present

Questi sono solo alcuni esempi; la documentazione di Ansible per i moduli Windows è estesa e copre molteplici scenari di gestione.

Gestire utenti e gruppi Active Directory con Ansible

L’automazione della gestione di Active Directory è un’area dove Ansible può portare enormi benefici, specialmente in ambienti enterprise con frequenti cambiamenti di personale o requisiti di conformità. I moduli win_ad_user, win_ad_group, win_domain_controller (e altri) permettono di interagire direttamente con AD.

- name: Create a new AD user
  win_ad_user:
    name: 'jdoe'
    firstname: 'John'
    surname: 'Doe'
    password: 'SuperSecurePassword123!'
    enabled: yes
    state: present
    path: 'OU=Users,OU=MyDept,DC=example,DC=com'

- name: Add user to a group
  win_ad_group_membership:
    name: 'SG_IT_Admins'
    members: 'jdoe'
    state: present
    scope: domainlocal

Automatizzare la creazione e la gestione degli account utente e dei gruppi in AD riduce significativamente gli errori manuali e garantisce che le policy di sicurezza (come l’art. 21 della NIS2 che richiede controlli sugli accessi) siano applicate in modo consistente. Ho utilizzato questa funzionalità per automatizzare il provisioning di nuovi dipendenti, riducendo il tempo di onboarding da ore a pochi minuti.

Installare e configurare software via Chocolatey

Chocolatey è un package manager per Windows, simile ad apt su Debian/Ubuntu o yum su CentOS/RHEL. Integrare Chocolatey con Ansible semplifica enormemente l’installazione e la gestione del software su larga scala.

Prima, assicurarsi che Chocolatey sia installato (tramite PowerShell o un altro playbook Ansible):

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

Una volta installato, si può usare il modulo Ansible win_chocolatey:

- name: Install Google Chrome via Chocolatey
  win_chocolatey:
    name: googlechrome
    state: present

- name: Ensure Notepad++ is at latest version
  win_chocolatey:
    name: notepadplusplus
    state: latest

Questo approccio centralizza la gestione del software, garantendo che le applicazioni siano installate in modo consistente e mantenute aggiornate su tutti i server. L’adozione di un package manager è una best practice moderna anche in ambiente Windows.

Playbook completo: patching Windows mensile

Ecco un esempio di playbook Ansible per automatizzare il processo di patching mensile dei server Windows. Questo playbook installa gli aggiornamenti critici e di sicurezza, gestisce i riavvii e assicura che il sistema sia pienamente aggiornato.

---
- name: Windows Monthly Patching
  hosts: windows_servers
  gather_facts: no
  tasks:
    - name: Check for pending reboots before patching
      win_reboot_info:
      register: reboot_info

    - name: Reboot if pending reboot is detected
      win_reboot:
      when: reboot_info.pending_reboot

    - name: Install Windows Updates
      win_updates:
        category_names: ['SecurityUpdates', 'CriticalUpdates']
        reboot: yes
        log_path: C:\Windows\AnsiblePatching.log
        state: installed
      register: update_result

    - name: Report update status
      debug:
        msg: "Updates installed: {{ update_result.updates | length }}. Reboot required: {{ update_result.reboot_required }}."

    - name: Reboot if required after updates
      win_reboot:
      when: update_result.reboot_required

    - name: Ensure all updates are checked and applied (optional, second pass)
      win_updates:
        category_names: ['SecurityUpdates', 'CriticalUpdates']
        state: installed
      register: second_pass_result

    - name: Final reboot if second pass required one
      win_reboot:
      when: second_pass_result.reboot_required

Questo playbook è un esempio robusto: gestisce i possibili riavvii pre-patching, installa gli aggiornamenti, riavvia se necessario e può eseguire un secondo passaggio per catturare eventuali aggiornamenti dipendenti. Un’automazione del patching come questa può ridurre il tempo di inattività, migliorare la conformità e liberare il personale IT per compiti più strategici. Ho visto la percentuale di server non patchati scendere dal 15% a meno dell’1% grazie a un approccio simile.

Errori comuni e troubleshooting

Quando si usa Ansible con Windows, alcuni problemi ricorrenti possono rallentare l’implementazione:

• WinRM non configurato correttamente: Il problema più comune. Verificare che il servizio sia in esecuzione, i listener siano attivi (specialmente HTTPS sulla porta 5986) e il firewall sia aperto. Ricordate Set-Item WSMan:\localhost\Service\AllowUnencrypted $false.
• Problemi di autenticazione: Credenziali errate, problemi NTLM/Kerberos. Assicurarsi che l’utente specificato in ansible_user abbia i permessi necessari sul server Windows. Per Kerberos, la configurazione lato controller Linux (keytab, /etc/krb5.conf) è fondamentale.
• Certificati SSL non validi o non attendibili: Se si usa HTTPS, il certificato deve essere valido e attendibile dal controller Ansible. Usare ansible_winrm_server_cert_validation=ignore solo per test non è una soluzione a lungo termine.
• Versioni PowerShell/WMF obsolete: Alcuni moduli Ansible potrebbero non funzionare correttamente con versioni di PowerShell meno recenti. Assicurati che i server siano aggiornati a PowerShell 5.1+.
• Windows Defender/Firewall: A volte, le impostazioni aggressive di sicurezza di Windows possono bloccare le connessioni WinRM, anche se la regola del firewall è attiva. Controllare i log degli eventi di Windows per dettagli.

Per il debugging, aumentare la verbosità di Ansible con -vvv o -vvvv può fornire informazioni dettagliate sugli errori di connessione e di esecuzione dei moduli.

FAQ — Domande Frequenti

Come posso gestire le credenziali sensibili (password) in Ansible per Windows in modo sicuro?

Per le password e altre credenziali sensibili, è fondamentale utilizzare Ansible Vault. Questo strumento permette di crittografare file o variabili, garantendo che le informazioni rimangano protette quando non sono in uso. Durante l’esecuzione del playbook, Ansible chiederà la password per decrittografare il Vault, mantenendo le credenziali al sicuro nel repository di codice. Non inserire mai password in chiaro nei playbook o nell’inventory.

Qual è la differenza tra ansible_winrm_transport=ntlm e ansible_winrm_transport=kerberos?

ntlm (NT LAN Manager) è un protocollo di autenticazione più vecchio, basato su challenge/response, meno sicuro e non supporta la delega. kerberos è il protocollo di autenticazione standard in ambienti Active Directory, offre maggiore sicurezza, supporta la delega e riduce la necessità di inviare password in chiaro. Per ambienti enterprise con AD, Kerberos è la scelta preferita per stabilità e sicurezza. Richiede una configurazione specifica del controller Ansible.

Posso usare Ansible per gestire workstation Windows (non solo server)?

Assolutamente sì. Ansible è altrettanto efficace nella gestione di workstation Windows. I moduli win_package, win_updates, win_product_feature e molti altri sono perfettamente adatti per configurare, patchare e installare software su PC client. L’approccio e i prerequisiti (WinRM, PowerShell) rimangono gli stessi. Ho usato Ansible per distribuire software e configurare policy su 2.000 workstation Windows, riducendo significativamente il carico di lavoro del team IT.

È possibile usare Ansible per deployare applicazioni .NET o IIS?

Sì, Ansible offre moduli specifici per la gestione di IIS (win_iis_website, win_iis_webapplication, win_iis_virtualdirectory) e per l’installazione di feature di Windows (win_feature), essenziali per il deploy di applicazioni .NET. È possibile automatizzare l’intero ciclo di vita del deploy, dalla configurazione del server IIS, all’installazione delle dipendenze, fino alla copia dei file dell’applicazione e alla configurazione del sito web. Questo garantisce deploy rapidi e riproducibili.

Conclusioni con takeaway operativi

L’integrazione di Ansible per la gestione dei server Windows non è più una nicchia, ma una pratica essenziale per qualsiasi team IT che desideri migliorare efficienza, sicurezza e conformità. Da un lato, si riduce drasticamente il tempo dedicato a compiti ripetitivi come il patching o la configurazione iniziale di nuovi server. Dall’altro, si aumenta la coerenza delle configurazioni, si minimizzano gli errori umani e si ottiene una tracciabilità completa di ogni operazione, aspetti cruciali per audit e requisiti normativi come la NIS2. L’investimento iniziale nella configurazione sicura di WinRM e nell’apprendimento dei moduli Windows specifici si ripaga rapidamente in termini di tempo risparmiato e maggiore resilienza dell’infrastruttura. L’automazione con Ansible trasforma un ambiente Windows da un onere manuale a un sistema gestibile con la stessa agilità di un’infrastruttura Linux.

Aggiornato: giugno 2026

Leggi anche: Ansible Playbook Provisioning Server: Checklist 12 Task Automatizzati (2026)

Leggi anche: Linux Server Hardening: Checklist 15 Punti per la Produzione (2026)

Leggi anche: FortiGate SSL VPN: Configurazione Completa per Accesso Remoto Sicuro (2026)

Link esterno: Ansible for Windows documentation