Active Directory & Ansible Tower

May 6, 2018 by John Lieske


 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
    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 (win_domain):

- name: Install AD Services feature
    name: AD-Domain-Services
    include_management_tools: yes
    include_sub_features: yes
    state: present
  register: result

- name: Create new forest
    dns_domain_name: tycho.local
    safe_mode_password: RememberTheCant!
  register: result

- name: Reboot after creation
    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
    adapter_names: "Ethernet 2"

- name: Promote to member
    dns_domain_name: tycho.local
    domain_admin_user: drummer@tycho.local
    domain_admin_password: WeNeed2Hydrate!
    state: domain
  register: domain_state

- name: Reboot after joining
    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?

Using the win_feature to manage the roles is similar to the combination of the Install-WindowsFeature and 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, win_domain_controller, win_domain_group, win_domain_membership, 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.

To Conclude

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 win_domain_membership.

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!



Windows, Ansible Tower, Getting Started


John Lieske

John is a Product Field Engineer, Ansible, Red Hat. John has been working in technology since 2003, starting with small business consulting and later managing technology for larger companies. Here at Red Hat Ansible, John helps with folks getting started on Red Hat Ansible Tower. John is an amateur musician in his spare time and likes to study history as a hobby. He can be found on Twitter and on Github at @johnlieske.

rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible Fest Austin 2018
Learn About Ansible Tower