AnsibleByExample

Ansible infra.windows_ops Role Example: Enforce CIS Benchmark Baseline

Beginner
2024-01-014By Luca Berton

Lesson 1 of 16 in Security & Compliance

Ansible Security and Compliance Automation — full curriculum
  1. 1. The Compliance-as-Code Model (and Where Ansible Fits)
  2. 2. Ansible's Security Automation Building Blocks
  3. 3. CIS Benchmarks and DISA STIGs Explained
  4. 4. Scanning Hosts for Compliance Drift with OpenSCAP and Ansible
  5. 5. Ansible Lockdown: Using STIG and CIS Roles in Practice
  6. 6. Custom Compliance Checks with assert and Facts
  7. 7. Remediating Findings Safely
  8. 8. CVE-Driven Patch Management
  9. 9. Firewall and SELinux Hardening at Scale
  10. 10. User, Access and Sudo Policy Enforcement
  11. 11. Secrets and Credential Hygiene at Scale
  12. 12. Audit Logging, Reporting and Evidence for Auditors
  13. 13. Event-Driven Remediation with Event-Driven Ansible
  14. 14. Continuous Compliance in CI/CD Pipelines
  15. 15. Change Control and Safe Rollback for Security Playbooks
  16. 16. Capstone: Automated Compliance Pipeline — Scan, Remediate, Report
View path overview →

infra.windows_ops is one of 12 new content collections announced for Ansible Automation Platform 2.7 at Red Hat Tech Day Netherlands 2026 in Bunnik. It ships higher-level, validated roles for Windows security baseline enforcement — covering DISA STIG, CIS benchmarks, and drift remediation — so you don't have to hand-roll registry and policy checks module by module. Below is a runnable playbook that audits a Windows Server fleet against a CIS benchmark level and remediates any drift it finds.

Example playbook

---
- name: Enforce CIS benchmark baseline on Windows Server fleet
  hosts: windows_servers
  gather_facts: true

  vars:
    windows_ops_baseline: cis
    windows_ops_cis_level: level1
    windows_ops_target_os: windows_server_2022
    windows_ops_remediate: true
    windows_ops_report_path: C:\ProgramData\ansible\cis_report.json
    windows_ops_exceptions:
      - rule_id: "2.3.1.5"
        reason: "Legacy monitoring agent requires local Guest account for one more quarter"

  roles:
    - role: infra.windows_ops.cis_baseline

  post_tasks:
    - name: Fail the play if drift remains after remediation
      ansible.builtin.fail:
        msg: >-
          CIS drift still present on {{ inventory_hostname }}:
          {{ windows_ops_baseline_result.failed_rules | length }} rule(s) failing.
      when:
        - windows_ops_baseline_result.failed_rules is defined
        - windows_ops_baseline_result.failed_rules | length > 0

    - name: Fetch the compliance report for central storage
      ansible.builtin.fetch:
        src: "{{ windows_ops_report_path }}"
        dest: "reports/{{ inventory_hostname }}-cis-report.json"
        flat: true

Run it against your Windows inventory group with:

ansible-playbook -i inventory.ini cis_baseline.yml

What it does and why

The infra.windows_ops.cis_baseline role wraps the collection's lower-level Windows modules (registry keys, local security policy, audit policy, service state) into a single idempotent pass: it audits the target hosts against the CIS Microsoft Windows Server benchmark, records which rules pass or fail, and — because windows_ops_remediate: true — applies the safe, scripted fixes for anything out of compliance. Results land in windows_ops_baseline_result, a structured fact the role sets on each host, which the post_tasks block inspects to fail the run loudly if drift survives remediation (useful as an AAP job template gate before a change window closes).

The windows_ops_exceptions list lets you document and suppress specific rule IDs with a stated reason instead of silently failing or hardcoding skips in your own tasks — handy for the CIS rules that legitimately conflict with a legacy agent or vendor requirement. The windows_ops_report_path variable and the fetch task give you an artifact you can archive or forward into a GRC tool for audit evidence, which is the point of pairing this collection with AAP job templates and scheduling.

Notes / Gotchas

  • Reboot-dependent rules: some CIS controls (audit policy subcategories, certain LSA settings) require a reboot to fully apply. Check windows_ops_baseline_result.reboot_required and follow with ansible.windows.win_reboot in a separate play if needed — don't reboot mid-role.
  • WinRM over HTTPS: as with any infra.windows_ops role, target hosts need WinRM configured (HTTPS strongly recommended) and an account with local administrator rights; the role does not configure WinRM for you.
  • Level 1 vs Level 2: windows_ops_cis_level: level2 enforces stricter, higher-impact controls (e.g., disabling more legacy protocols) — test in a non-production group first, since some Level 2 rules can break older line-of-business apps.
  • DISA STIG mode: swap windows_ops_baseline: stig to run the same role logic against DISA STIG controls instead of CIS — the collection shares one drift-detection engine across both baselines.
  • Idempotency: re-running the playbook on a compliant host should report zero changed tasks; if you see repeated drift on the same rule, check for a Group Policy Object overwriting the setting after each Ansible run.

Treat infra.windows_ops as the fleet-wide compliance layer: point it at your Windows inventory, pick a baseline and level, and let the role's built-in audit-then-remediate loop keep CIS drift from accumulating between audits.

References

All Tutorials