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