Overview: Kerberos in Active Directory

Active Directory (AD) uses Kerberos as its default authentication mechanism. When you set up an AD domain, a Kerberos Key Distribution Center (KDC) is automatically created on the Domain Controller (DC). Each domain user and computer account gets a Kerberos principal, and the domain itself acts as a Kerberos realm. The realm name is typically the uppercase version of the domain name (e.g., EXAMPLE.COM for a domain named example.com).

If you have already set up AD using Ansible, the Kerberos realm is implicitly created. However, you might want to configure specific Kerberos policies, Service Principal Names (SPNs), or integrate Linux clients with the AD Kerberos realm for cross-platform authentication using tools like SSSD or Winbind. Below, I’ll focus on enhancing or customizing the Kerberos setup in AD using Ansible and integrating Linux clients into the AD Kerberos realm. Prerequisites

Active Directory Setup: Ensure your Windows Server 2022 is configured as a Domain Controller using Ansible, and the domain is functioning.
Ansible Setup: Ensure Ansible is set up with the necessary modules for Windows (ansible.windows) and Linux (ansible.builtin, community.general for SSSD, etc.).
WinRM: Ensure WinRM is enabled on Windows servers for Ansible to manage them.
Linux Integration: If you want Linux boxes to use the AD Kerberos realm, ensure they are reachable by Ansible.

Steps to Enhance Kerberos in AD and Integrate with Linux Using Ansible

Test using File Share

Microsoft Windows [Version 10.0.20348.707]
(c) Microsoft Corporation. All rights reserved.

C:\Users\tony>klist

Current LogonId is 0:0x469b92

Cached Tickets: (0)

C:\Users\tony>klist

Current LogonId is 0:0x469b92

Cached Tickets: (3)

#0>     Client: tony @ C2PLATFORM.ORG
        Server: krbtgt/C2PLATFORM.ORG @ C2PLATFORM.ORG
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
        Start Time: 7/12/2025 12:45:36 (local)
        End Time:   7/12/2025 22:45:36 (local)
        Renew Time: 7/19/2025 12:45:36 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x2 -> DELEGATION
        Kdc Called: PXD-AD.c2platform.org

#1>     Client: tony @ C2PLATFORM.ORG
        Server: krbtgt/C2PLATFORM.ORG @ C2PLATFORM.ORG
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 7/12/2025 12:45:36 (local)
        End Time:   7/12/2025 22:45:36 (local)
        Renew Time: 7/19/2025 12:45:36 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: PXD-AD.c2platform.org

#2>     Client: tony @ C2PLATFORM.ORG
        Server: cifs/pxd-ad @ C2PLATFORM.ORG
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 7/12/2025 12:45:36 (local)
        End Time:   7/12/2025 22:45:36 (local)
        Renew Time: 7/19/2025 12:45:36 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: PXD-AD.c2platform.org

C:\Users\tony>

1. Verify Kerberos Realm on Windows AD

Since Kerberos is built into AD, ensure the domain is functioning as a Kerberos realm. You can use Ansible to run PowerShell commands on the Windows DC to check or configure Kerberos-related settings.

Example Playbook for Kerberos Verification on Windows DC:

- name: Verify Kerberos Realm on Windows Domain Controller
  hosts: windows_dc
  gather_facts: no
  tasks:
    - name: Check Kerberos KDC Service
      ansible.windows.win_shell: |
        Get-Service -Name krbtgt        
      register: krbtgt_service
      failed_when: krbtgt_service.rc != 0

    - name: Display Kerberos Realm (Domain Name)
      ansible.windows.win_shell: |
        (Get-ADDomain).DNSRoot.ToUpper()        
      register: realm_name
      failed_when: realm_name.rc != 0

    - name: Output Kerberos Realm Name
      debug:
        msg: "Kerberos Realm Name: {{ realm_name.stdout }}"

This playbook checks if the Kerberos Key Distribution Center (KDC) service is running and outputs the Kerberos realm name (uppercase domain name). 2. Configure Kerberos Policies (Optional)

You can use Ansible to set Kerberos policies in AD, such as ticket lifetimes or encryption types, via Group Policy Objects (GPOs) or direct registry edits on the Domain Controller. Below is an example of setting a Kerberos policy using PowerShell.

Example Playbook to Set Kerberos Ticket Lifetime:

yaml

• name: Configure Kerberos Policies on Windows DC hosts: windows_dc gather_facts: no tasks:
  • name: Set Kerberos Ticket Lifetime (e.g., 10 hours) ansible.windows.win_shell: | Set-ADDefaultDomainPasswordPolicy -Identity “{{ ansible_domain }}” -MaxPasswordAge (New-TimeSpan -Hours 10) register: policy_result changed_when: policy_result.rc == 0 failed_when: policy_result.rc != 0

3. Register Service Principal Names (SPNs) for Services

If you have services running on Windows or Linux servers that need Kerberos authentication, you must register SPNs in AD. SPNs map a service to a specific account in AD for Kerberos authentication.

Example Playbook to Register an SPN:

yaml

• name: Register SPN for a Service hosts: windows_dc gather_facts: no tasks:
  • name: Register SPN for HTTP Service on a Server ansible.windows.win_shell: | setspn -S HTTP/myserver.example.com EXAMPLE\serviceaccount register: spn_result changed_when: spn_result.rc == 0 failed_when: spn_result.rc != 0

Replace myserver.example.com with the FQDN of the server hosting the service and EXAMPLE\serviceaccount with the AD account for the service. 4. Integrate Linux Clients with AD Kerberos Realm

To allow Linux boxes in your Vagrant environment to authenticate against the AD Kerberos realm, you need to configure them to use the AD domain as their Kerberos realm. This typically involves installing and configuring tools like realmd, sssd, or krb5-workstation.

Example Playbook for Linux Integration with AD Kerberos:

yaml

• name: Join Linux Machine to AD Kerberos Realm hosts: linux_boxes become: yes tasks:

  • name: Install required packages for Kerberos and SSSD ansible.builtin.package: name: - realmd - sssd - krb5-workstation - oddjob - oddjob-mkhomedir state: present

  • name: Join Linux machine to AD domain ansible.builtin.shell: | echo “{{ ad_password }}” | realm join –user={{ ad_username }} {{ ad_domain }} args: creates: /etc/sssd/sssd.conf vars: ad_username: “Administrator” ad_password: “YourPassword” ad_domain: “example.com”

  • name: Ensure SSSD is started and enabled ansible.builtin.service: name: sssd state: started enabled: yes

  • name: Test Kerberos Authentication ansible.builtin.shell: | kinit -k {{ ad_username }}@{{ ad_domain|upper }} register: kinit_result failed_when: kinit_result.rc != 0

  • name: Display Kerberos Ticket ansible.builtin.shell: klist register: klist_result failed_when: klist_result.rc != 0

  • name: Debug Kerberos Ticket Info debug: msg: “{{ klist_result.stdout }}”

Notes for Linux Integration:

Replace ad_username, ad_password, and ad_domain with your AD credentials and domain name.
Ensure DNS is configured correctly on Linux boxes to resolve the AD domain (/etc/resolv.conf should point to the AD DC).
The realm join command automatically configures /etc/krb5.conf and /etc/sssd/sssd.conf for Kerberos and authentication.
If realm is not available, you can manually configure /etc/krb5.conf using a template task in Ansible.

Example /etc/krb5.conf Template (if manual configuration is needed):

ini

[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true

[realms] EXAMPLE.COM = { kdc = dc1.example.com admin_server = dc1.example.com }

[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

Use Ansible’s template module to deploy this configuration to Linux hosts. 5. Test Kerberos Authentication Across Systems

After setting up, test Kerberos authentication from both Windows and Linux systems:

On Windows: Use klist to view Kerberos tickets after logging in.
On Linux: Use kinit to obtain a ticket and klist to verify.

Example Playbook for Cross-System Testing:

yaml

• name: Test Kerberos Authentication on Windows and Linux hosts: all gather_facts: no tasks:

  • name: Test Kerberos Ticket on Windows ansible.windows.win_shell: klist register: win_klist when: ansible_os_family == “Windows” failed_when: win_klist.rc != 0

  • name: Test Kerberos Ticket on Linux ansible.builtin.shell: klist register: linux_klist when: ansible_os_family == “Debian” or ansible_os_family == “RedHat” failed_when: linux_klist.rc != 0

  • name: Output Windows Kerberos Ticket Info debug: msg: “{{ win_klist.stdout }}” when: ansible_os_family == “Windows”

  • name: Output Linux Kerberos Ticket Info debug: msg: “{{ linux_klist.stdout }}” when: ansible_os_family == “Debian” or ansible_os_family == “RedHat”

Additional Notes

Security: Store sensitive data like AD passwords in Ansible Vault or use a secrets management tool.
Cross-Realm Trust: If you need to set up trust between multiple Kerberos realms or AD domains, use the New-ADTrust PowerShell cmdlet on Windows via Ansible.
MIT Kerberos on Windows: If you are not using AD and want a standalone Kerberos realm on Windows, you would need to install MIT Kerberos for Windows (not natively supported or recommended) or use a Linux-based KDC. Let me know if this is your use case.

Conclusion

If your goal is to use Kerberos within an AD environment, it’s already set up when you configure the AD domain. The above steps help you customize Kerberos policies, register SPNs, and integrate Linux clients with the AD Kerberos realm using Ansible. If you meant something else (e.g., a standalone Kerberos realm on Windows without AD), please clarify, and I can adapt the guidance accordingly.