Welcome to the second installment of our Windows-centric Getting Started series!
Last time we walked you through how Ansible connects to a Windows host. We’ve also previously explored logging into Ansible Tower while authenticating against an LDAP directory. In this post, we’ll go over a few ways you can use Ansible to manage Microsoft’s Active Directory. Since AD plays a role in many Windows environments, using Ansible to manage Windows will probably include running commands against the Active Directory domain.
First, Set Your Protocol
We’ll be using WinRM to connect to Windows hosts, so this means making sure Ansible or Tower knows that. Machine credentials in Ansible Tower can be created and used along with variables, but when using Ansible in a terminal the playbook should make it clear with variables:
--- - name: Your Windows Playbook hosts: win vars: ansible_ssh_user: administrator ansible_ssh_pass: ThisIsWhereStrongPassesGo ansible_connection: winrm ansible_winrm_server_cert_validation: ignore - tasks:
Along with using the local admin account/pass, the WinRM connection method is named specifically. The variable to ignore the certificate validation is for standalone, non-domain hosts because a domain-joined instance should have certificates validated on the domain.
Where’s the Domain?
Speaking of domains, Ansible can spin up a new domain if one doesn’t exist.
In the following example, Ansible (using the previous settings) installs the AD Domain Services features from Server Management
(win_feature), and if there’s no domain present it creates the new Active Directory domain with the provided AD safe mode password (
- name: Install AD Services feature win_feature: name: AD-Domain-Services include_management_tools: yes include_sub_features: yes state: present register: result - name: Create new forest win_domain: dns_domain_name: tycho.local safe_mode_password: RememberTheCant! register: result - name: Reboot after creation win_reboot: msg: "Server config in progress; rebooting..." when: result.reboot_required
After creating the domain, the server sends a message to anyone logged in that the server is rebooting and then commences to reboot. While not a production-quality playbook, this is a good example of what can be configured quickly with a few short plays.
If there’s already a domain present for testing there’s no need to create one, but there may be a test machine that should be joined to an existing domain. Ansible can similarly shorten that task with a few plays as well:
- name: Configure DNS win_dns_client: adapter_names: "Ethernet 2" ipv4_addresses: - 10.0.0.1 - name: Promote to member win_domain_membership: dns_domain_name: tycho.local domain_admin_user: email@example.com domain_admin_password: WeNeed2Hydrate! state: domain register: domain_state - name: Reboot after joining win_reboot: msg: "Joining domain. Rebooting..." when: domain_state.reboot_required
The steps are self-explanatory -- make sure the machine can communicate with the directory server (
win_dns_client), then join to the domain (
win_domain_membership). The target restarts to complete joining the directory. Quick and easy.
What Can It Do?
win_feature to manage the roles is similar to the combination of the
Add-WindowsFeature Powershell cmdlet. If you’re not familiar with the name used for the feature you’re trying to install, use the
Get-WindowsFeature cmdlet to list available features to install.
The Windows domain modules (
win_domain_user ) cover the common tasks run against an Active Directory. For most of the Windows modules a domain account with appropriate privileges should be set as a machine credential (using DOMAIN/User or User@domain.tld), much like you would for a local account.
In this post, we used WinRM to connect to Windows hosts, had Ansible install the AD Domain Services features from Server Management using the
win_feature module (or created the new Active Directory domain if there isn’t one already present by using the
win_domain module), made sure the machine can communicate with the directory server using
win_dns_client, then joined it to the domain using
Don’t forget to make sure that your playbook for Windows nodes sets the connection variables by specifically stating
ansible_connection: winrm (required) as well as
ansible_winrm_server_cert_validation: ignore (if you haven’t added your local CA as trusted). As shown in the beginning of this post, those two variables go along with the connecting account variables after
vars: in an Ansible Playbook. In Ansible Tower, those variables go in the job template.
So now you know how to use Ansible with Microsoft’s Active Directory! In our next post, we’ll dive deeper into the package management abilities you have with Ansible + Windows!