- How to block emails in Outlook and Microsoft 365 (Office 365) - Fri, Jun 9 2023
- Connect to Exchange Online with PowerShell - Wed, Jun 7 2023
- SCP from remote to local - Wed, May 31 2023
Using automated configuration management and remediation processes can help eliminate configuration drift, and makes managing a lot of Windows servers in a large environment much simpler. Although Ansible began life as a Linux configuration tool, it has evolved to encompass Windows servers in its abilities to manage, provision, and configure infrastructure. It’s an extremely popular tool for use in DevOps and configuration management, and we think it will make your Windows server management tasks much easier.
In this post, we take a look at Ansible Tower and how IT operations folks can use its graphical interface to manage, provision and configure the Windows servers in their environments.
How Ansible interacts with Windows hosts
You may be thinking of Ansible as a “Linux only” configuration management platform. However, Ansible also provides powerful support for configuring and managing Windows servers. It has been rapidly evolving with each new version; its support of Windows systems, and the way it interacts with them, has been getting better and better.
To begin, let’s take a look at how Ansible interacts with Linux and Windows, as it interacts with these systems differently. With Linux, by default, Ansible communicates with remote Linux hosts via the SSH protocol. It uses native OpenSSH for remote communication whenever possible. However, with Windows, this communication architecture is much different.
The Windows equivalent of SSH for communication is WinRM, or Windows Remote Management. WinRM has been a feature of Windows operating systems since Microsoft Windows Vista. It lets admins run management scripts remotely. WinRM communicates using the WS-MAN protocol based on SOAP (Simple Object Access Protocol) communication. Ansible uses a WinRM listener that is created and activated on a Windows host to communicate with it. ***Note*** While there has been experimental support added in Ansible 2.8 for Windows SSH communication, the de facto standard for communicating with Windows is still WinRM.
Ansible hosts running on Linux machines connect to WinRM using the WS-MAN protocol, which can proxy these requests so that even requests coming from Linux machines (your Ansible host) can be successfully answered by the Windows operating system.
To enable WinRM connectivity support from Ansible/Ansible Tower to Windows, you must install the following module on your Ansible Tower host: sudo pip install pywinrm
Another great aspect of WinRM is that it is “part of” the Windows operating system, so it’s not an extra installation or bolt-on component that you have to worry about. One thing to be aware of, however, is that WinRM is not configured or enabled by default. How do we do this?
Configuring the Windows WinRM listener for Ansible
Configuring WinRM manually to enable the listeners to listen for your requests properly can be tricky. There are a few methods you can use to set WinRM up correctly for use with Ansible to minimize the issues you might experience by more manual means of configuring. First, let’s look at the current client WinRM settings.
To see the current client settings:
winrm enumerate winrm/config/Listener
Three ways to configure the WinRM listener
- Using winrm quickconfig for HTTP or winrm quickconfig -transport:https for HTTPS – Using both of these commands, the Windows firewall will automatically be adjusted to allow WinRM communication in either mode
- Using Group Policy Objects – Group Policy Objects can be used to configure WinRM communication across domain-joined computers
- Using a PowerShell script - A PowerShell script called ps1 has been provided that automatically configures the WinRM and WS-MAN settings so that your Ansible host can connect to your remote Windows hosts. You can download the latest copy of this script here.
Requirements for Windows management with Ansible
You’ll need to be aware of certain requirements when using Ansible to manage Windows systems. Ansible supports a wide variety of Windows operating systems, however, there is a limit to this support from a legacy Windows perspective. Supported desktop operating system OSes include:
- Windows 7, 8.1, and 10 (desktop)
- Windows Server 2008 SP2
- Windows Server 2008 R2 SP1
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
The main reason for the above requirements is that Ansible requires PowerShell 3.0 or newer and at least .NET 4.0 to be installed on the Windows host. You also need to keep in mind that there are some specific Ansible modules that may have requirements that are above and beyond the basic Ansible Windows requirements, so be sure to read through the module documentation for that information.
Ansible does not work with the following:
- Windows XP
- Windows Server 2003
- Windows Nano Server
- Running the Ansible platform on a Windows Server
Ansible Kerberos support for Windows
Now that we have covered the basics of how Ansible communicates with Windows hosts via WinRM, we still need to be able to authenticate to the Windows remote host. As with Linux, simply having SSH connectivity doesn’t automatically allow you to log in. You still have to have an SSH user or SSH keys.
The same applies to Windows systems. Having WinRM enabled and configured as well as the pywinrm module installed only allows WinRM to be the vehicle for communication; we still need to authenticate.
In most cases, the desired approach with Windows is to authenticate via Kerberos Authentication, which allows you to make use of Active Directory authentication for logging into remote Windows hosts. Let’s see which components need to be installed on your Ansible Tower server to manage your Windows servers.
Configuring Kerberos with Ansible
There are some components and steps required to get Kerberos Authentication to work with Ansible and Windows. A Kerberos installation working with Ansible Tower needs the following components installed. In the list below, the last two components install pywinrm and Ansible itself, which you may already have installed.
- sudo apt-get install gcc python-dev libkrb5-dev
- sudo apt-get install python-pip
- sudo pip install --upgrade pip
- sudo pip install --upgrade virtualenv
- pip install pywinrm[kerberos]
- sudo apt install krb5-user
- sudo pip install pywinrm
- sudo pip install ansible
When installing your Kerberos components, specifically the krb5-user component, you will be prompted to configure your Kerberos Authentication realm, which is your Windows domain name in FQDN format.
Configuring the Kerberos realm
Edit your krb5.conf file, found at /etc/krb5.conf. In this file, you need to populate your domain controllers and realms, which may be additional domains. Below is an example file for reference. Notice how the domain name is capitalized:
[logging]default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]default_realm = MYDOMAIN.LOCAL
allow_weak_crypto = true
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]MYDOMAIN.LOCAL = {
kdc = dc1.mydomain.local
admin_server = dc1.mydomain.local
}
Configuring Ansible Tower to manage Windows servers
When looking at a newly installed Ansible Tower environment, besides configuring the Kerberos components, there are a few extra configuration steps that need to take place to get Ansible ready. This includes configuring the following:
- Organization
- Projects
- Inventory
- Hosts
- Credentials
- Templates
Ansible Tower organization
One of the first things you need to do is create a new organization. An organization is a logical collection of users, teams, projects, and inventories. It is the highest level in the Ansible Tower object hierarchy. Click Organization in the menu on the left:
Creating a new organization in Ansible Tower
Click the green “+” sign to add a new organization. Name is the only required field.
Provisioning the new organization in Ansible Tower
Ansible Tower Project
Before creating a new project in the Ansible Tower interface, we need to create a new project folder. This folder must use the same name as the project you are creating in Ansible Tower. Create a subfolder below the /var/lib/awx/projects folder on your Ansible Tower server.
Creating a new projects directory
Click the Projects menu and click the green “+” sign in the upper-right corner.
Creating a new project in Ansible Tower
On the New Project page, create a new project whose name matches the name of the folder you created in the Projects folder. Then click Save.
Creating an Ansible project with the same name as the new folder
Ansible Tower Inventory
Click the Inventories menu, and click the green “+” sign to create a new inventory.
Creating a new inventory in Ansible Tower
Key components to create the new inventory include Name, Organization, and Variables. Under the Variables section, you populate the information specific to connecting to your Windows servers. This includes specifying WinRM and the WinRM port.
Adding the new inventory along with connection information
After saving the new inventory, you can see the new inventory in the list.
Ansible Tower new inventory successfully added
Next, we need to add our Windows hosts to the inventory. On the Inventories menu, click the Hosts button, then click the green “+” sign.
Adding new hosts to the Ansible Tower inventory
Add the servers you want to manage with the Ansible Tower Inventory in the Create Host section and save your entries. If you are using Kerberos Authentication you will want to include the DOMAIN name in the Host name. Additionally, in my testing, I have found that the domain name needs to be capitalized, just like how it’s written in the krb5.conf file.
Type the name of the server to add it to the inventory hosts list
You can verify the host has been added to the inventory:
Verifying that the server has been added to the inventory hosts list
Ansible Tower Credentials
To authenticate to your Windows servers, we need to configure credentials. Click the Credentials menu and click the green “+” sign.
Adding new credentials to Ansible Tower
The Name is the friendly name you want to use to identify the credentials. Select your organization. Then click the magnifying glass next to Select a Credential Type:
Creating a new credential for Ansible Tower Windows configuration
In the Select Credential Type dialog box, choose Machine for the type, then click Select.
Selecting the Ansible Tower credential type
Once you have selected the credential type, populate the Username and Password fields. Note the ability to check the box to Prompt on launch for the password if you do not wish to store it. Once you have populated the username and password fields, you can click Save to save the credentials for use.
Configuring the username and password settings
Job Template
To run playbooks, we need job templates. Click the Templates menu and click the green “+” sign. Choose Job Template.
Adding a new job template in Ansible Tower
On the New Job Template page, there are a few things you need to select, including the Inventory, Playbook, and Credential fields. Where is the playbook generated from? Remember the Projects folder we created earlier? You place the playbook containing the YAML code you want to execute against your Windows server in that folder. Once you choose the Project in this dialog, it will automatically “see” the playbook(s) in the folder, allowing you to pick one. After making your selections, click Save.
Creating a new job template for Windows configuration
As you see above, I have created a winservers.yml file in the “labs” folder I created in the /var/lib/awx/projects folder. In that file, I have the following code that installs the Telnet client and checks to see if SQL has been installed, and if the service has started:
---
- name: Install Telnet and check SQL
hosts: all
tasks:
- name: Check SQL Server is Installed
win_service:
name: MSSQLSERVER
register: sqlstatus
- name: Start SQL Service
win_service:
name: MSSQLSERVER
start_mode: auto
state: started
when: sqlstatus.exists
To manually run a job template, click the “rocket” icon next to the job template you want to run.
Manually running an Ansible Tower job template
As you recall, we chose to Prompt for password. The password dialog box pops up when you manually launch the job template. Even though the dialog box shows SSH Password, here you enter the password for the Windows credentials that you entered earlier.
Enter the password for your Ansible Tower job template
The Windows configuration playbook run is successful
Wrapping up
Ansible Tower is a very robust platform for managing Windows servers. It is generally easy to configure and allows you to get up and running fairly quickly. By installing the necessary Kerberos components, you can use your Active Directory credentials to manage your Windows Server deployments, which makes authentication very easy. Additionally, by using the WinRM connection method, there are no agents to install, which makes lifecycle management of the platform very easy.
Just wanted to thank you. I followed this exactly and did a little extra krb research and it worked great.
Something has changed it seems. Even if you create the empty directory it will not allow you to save the new project. Ive even tried chmod on the directory but that didnt help. Do you know what the best way to go about this?
I had the same issue as you Nick. I then added a valid playbook into the directory and then it worked.
ansible_ssh_port: 5985
ansible_connection: winrm
ansible_winrm_server_cert_validation: ignore
This is great.
Do we have any references to enable HTTPS based WinRM connection for Windows ?
Thank you
I explained how to enable HTTPS for WinRM a while back.
That is wonderful ! Thank you Michael.
Great collection of article by the way.
Hi Thank you, great blog post, but you say “By installing the necessary Kerberos components, you can use your Active Directory credentials to manage your Windows Server deployments, which makes authentication very easy.” But how do you install those required kerberos items and setup the /etc/krb5.conf file on a recent awx deployment that is in a Kubernetes cluster (minikube for me) deployed by the operator?