top of page
Search

Ansible with Windows Domains and Kerberos

Welcome Back

Hey there! I'm glad to have you back for the third Ansible article. This time, we're diving into using Ansible to manage Windows Domains and authenticating with Kerberos.


Catch up

If you missed out on the previous articles regarding the setup of Ansible and Encrypting the at rest passwords make sure to catch up on those first, by following the links.


Basic Setup of Ansible managing a Standalone Windows Server


How to Secure the at Rest Passwords with Ansible Vault


Virtual Machines Required

Ansible = 10.1.1.100

Ubuntu


Domain Controller = 10.1.1.50

FQDN = TENAKA.LOC


DHCP Server = 10.1.1.1

Scope Options:

004 Time Server = 10.1.1.50

006 DNS Server = 10.1.1.50


Credentials

Domain Account = Administrator

Windows Passwords = ChangeMe1234


Ansible Vault Password = Password1234


Help Yourselves....

A working set of files for configuring Ansible to manage a Windows Domain can be found at the following link, do help yourselves.



Ubuntu Kerberos Packages

To ensure the smooth installation of new Ubuntu features it's important to keep things up to date. From a terminal shell on Ubuntu execute the following:

sudo apt-get update -y && apt-get upgrade -y


Additional packages are required to provide Kerberos User Authentication with a Windows Domain.

sudo apt-get install python3-dev libkrb5-dev krb5-user


Complete the prompts to match that of your Domain. Writing the Fully Qualified Domain Name (FQDN) in capitals is essential.


Write the host of the PDC, followed by the FQDN, again in capitals.


Repeat the above. I've only 1 Domain Controller (DC), however, this can be updated later so it isn't essential, for now add a single DC.


For other Linux Variants

If you're using something other than Ubuntu the link below provides support. I've extracted the relevant commands below:



Through Yum (RHEL/Centos/Fedora for the older version)

yum -y install gcc python-devel krb5-devel krb5-libs krb5-workstation  


Through DNF (RHEL/Centos/Fedora for the newer version)

dnf -y install gcc python3-devel krb5-devel krb5-libs krb5-workstation


Through Apt (Ubuntu older than 20.04 LTS (focal))

sudo apt-get install python-dev libkrb5-dev krb5-user


Through Apt (Ubuntu newer than 20.04 LTS)

sudo apt-get install python3-dev libkrb5-dev krb5-user


Through Portage (Gentoo)

emerge -av app-crypt/mit-krb5 emerge -av dev-python/setuptools


Through Pkg (FreeBSD)

sudo pkg install security/krb5


Through OpenCSW (Solaris)

pkgadd -d http://get.opencsw.org/now /opt/csw/bin/pkgutil -U /opt/csw/bin/pkgutil -y -i libkrb5_3


Through Pacman (Arch Linux)

pacman -S krb5


KrbFive Config

Let's enhance the readability and tailor the default krb5.conf file to better suit our requirements.


sudo nano /etc/krb5.conf


Pressing Ctrl + K deletes a line, allowing you to eliminate all lines except those containing domain-specific settings. This section is where you can add extra Domain Controllers (DCs) as kdc entries.


To verify Kerberos authentication, we'll utilize kinit along with the following command, ensuring that the FQDN is in capitals.


kinit administrator@TENAKA.LOC


Run klist to display the contents of a Kerberos Ticket Granting Ticket (TGT).


WinRM and GPO

WinRM (Windows Remote Management) is a Microsoft implementation of the WS-Management Protocol, which allows for remote management of Windows-based systems over HTTP(S). It enables administrators to remotely execute commands. on all permissible computers and Servers.


To provide WinRM access in a domain environment using GPOs, administrators can configure GPO settings to enable WinRM, define WinRM listeners, specify trusted hosts, configure authentication settings, and set other WinRM-related policies. These policies are then applied to the relevant organizational units (OUs), groups, or individual computers within the Active Directory domain.


Tier Zero and Ansible

Only the Domain Controller (DC) is being managed remotely for demonstration purposes. This service falls under tier zero, similar to Certificate Authorities (CAs) and any other service that manages or was mentioned previously.


Ansible should not manage these tier zero services unless other precautions are taken For instance, consider isolating a dedicated Ansible server specifically tasked with managing tier zero services.


Group Policy

Move to the Domain Controller, open Group Policy Management, creating a new GPO at the root of the Domain.


Navigate to 'System Services' and set the 'Windows Remote Management (WS-Management)' service to Automatic.


Create a new 'Inbound' firewall rule with the following settings:

Protocol = TCP

Port = 5985 and 5986

Remote IP Address = 10.1.1.100 (Ansible)

Profile = Domain Only


Navigate to 'WinRM Services' under Administrative Templates, Windows Components then to Windows Remote Management (WinRM).


Set the following:

Enable - Allow remote server management through WinRM

IPv4 Filter = *

Disable - Allow Basic authentication

Disable - Allow CredSSP authentication

Enable - Allow unencrypted traffic

Disable - Disallow Kerberos authentication


Regarding the 'Allow unencrypted traffic' setting. Kerberos encrypts data between client-server communications. Ansible, leveraging Kerberos, doesn't need HTTPS because Kerberos handles encryption and authentication, ensuring secure communication.


Ansible Config for Kerberos

If you've been keeping up with the earlier articles on Ansible's Windows management, create a new directory titled 'Domain' and duplicate hosts.ini, ping.yml, and win.yml into it.


Alternatively, the files can be downloaded from:


If not, launch nano to duplicate the files below, not forgetting to change the hostname to that of your own DC.


Host.ini maintains your hosts and variables including the Ansible Jinja2 variable ansible_password="{{vault_ansible_password}}" and resolves to the values in win.yml


Ping.yml provides a simple ping test to confirm authentication and network accessibility.


To create win.yml and encrypt the Windows Domain password, execute the following command.

ansible-vault create win.yml


Enter the encryption password of 'Password1234' at the prompts


Type 'vault_ansible_password: ChangeMe1234'


Here's what the output looks like with cat.


To test the playbook against the Domain Controller execute the following:

ansible-playbook -i hosts.ini ping.yml --ask-vault-pass


Enter the Vault password of 'Password1234'


The test ping via Ansible using Kerberos authentication was successful and the world of free management of Microsoft Windows infrastructure is at your feet.


Final Thoughts

Implementing Ansible for Windows domain management proved straightforward, requiring minimal adjustments to existing Ansible files and only a few GPO tweaks. In production, avoiding Domain Admin usage and employing delegated service accounts with segregated roles enhances security. Relying on a single domain admin service account for all tasks would be less than ideal.





1 view0 comments

Recent Posts

See All
bottom of page