Building a Free Kerberos Authentication Lab: Architecture, Prerequisites, and Step-by-Step Deployment

Implementing Kerberos in a local lab costs nothing and provides hands-on experience with ticket-based authentication, Key Distribution Centers (KDCs), service principals, and keytabs. Whether you want to understand how enterprise Single Sign-On (SSO) works under the hood or practice testing Kerberos attacks (such as Kerberoasting or Golden Ticket simulations) safely in isolation, open-source tools let you deploy a full environment in under 30 minutes.

Choosing Your Free Implementation Path

You have three primary zero-cost options depending on what you want to learn:

For a fast, bare-metal understanding of Kerberos tickets and cryptographic exchanges without directory bloat, MIT Kerberos on Ubuntu or Debian is the ideal starting point.

What You Need (Prerequisites)

Before installing packages, ensure your lab environment meets these strict architectural requirements:

1. Two Virtual Machines (or Containers):

   • Node 1 (The KDC / Server): kdc.lab.local (e.g., 192.168.56.10) running Ubuntu Server or Debian.

   • Node 2 (The Client / Application Host): client.lab.local (e.g., 192.168.56.20) running any Linux distribution.

2. Private Virtual Network: Both nodes must sit on an isolated host-only or internal virtual switch so they can communicate directly over TCP/UDP port 88 (Kerberos) and port 749 (kadmin).

3. Deterministic Hostname Resolution (DNS or /etc/hosts): Kerberos relies heavily on Fully Qualified Domain Names (FQDNs) to build Service Principal Names (SPNs). Reverse DNS lookups must match forward lookups.

4. Synchronized Clocks (NTP): Kerberos tickets include timestamps to prevent replay attacks. If the clock drift between your KDC and client exceeds 5 minutes, authentication will fail immediately with a Clock skew too great error.

Step 1: Prepare Hostnames and Time Sync (Both Nodes)

On both the KDC and the Client, set static hostnames and map their IP addresses in /etc/hosts (if you are not running a dedicated DNS server in your lab).

On the KDC:

sudo hostnamectl set-hostname kdc.lab.local

On the Client:

sudo hostnamectl set-hostname client.lab.local

Add the following lines to /etc/hosts on both machines (ensure the FQDN is not mapped to 127.0.0.1):

192.168.56.10   kdc.lab.local kdc
192.168.56.20   client.lab.local client

Ensure systemd-timesyncd or chrony is active on both nodes to prevent clock skew:

timedatectl status

Step 2: Install and Initialize the KDC (Server Node)

On kdc.lab.local, install the MIT Kerberos KDC and administrative server packages:

sudo apt update
sudo apt install krb5-kdc krb5-admin-server -y

During installation, an interactive prompt will ask for three values:

• Default Kerberos version 5 realm: LAB.LOCAL (Always use UPPERCASE by convention)

• Kerberos servers for your realm: kdc.lab.local

• Administrative server for your Kerberos realm: kdc.lab.local

Next, initialize the Kerberos database and generate the master key:

sudo krb5_newrealm

You will be prompted to create a KDC database master password. Store this securely; it encrypts the entire database of user and service keys.

Step 3: Create Principals and Configure ACLs (Server Node)

In Kerberos, every user, host, and service is an identity called a principal formatted as primary/instance@REALM.

Open the local administration console (which authenticates directly over a local UNIX socket without needing a network ticket yet):

sudo kadmin.local

Inside the kadmin.local: prompt, create an administrative user and a standard test user:

addprinc admin/admin
addprinc alice
quit

To allow admin/admin to manage the KDC remotely, grant permissions in /etc/krb5kdc/kadm5.acl:

echo "*/admin@LAB.LOCAL *" | sudo tee -a /etc/krb5kdc/kadm5.acl

Restart the Kerberos daemons to apply your changes:

sudo systemctl restart krb5-kdc krb5-admin-server

Step 4: Configure the Client and Request a Ticket (Client Node)

Switch to client.lab.local and install the Kerberos client utilities:

sudo apt update
sudo apt install krb5-user -y

Enter the exact same realm (LAB.LOCAL) and KDC hostname (kdc.lab.local) when prompted. Your /etc/krb5.conf file should look similar to this:

[libdefaults]
    default_realm = LAB.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = false

[realms]
    LAB.LOCAL = {
        kdc = kdc.lab.local
        admin_server = kdc.lab.local
    }

[domain_realm]
    .lab.local = LAB.LOCAL
    lab.local = LAB.LOCAL

Test authentication by requesting a Ticket Granting Ticket (TGT) for alice using kinit:

kinit alice

Enter alice‘s password. Once authenticated, inspect your local ticket cache:

klist

You should see a valid krbtgt/LAB.LOCAL@LAB.LOCAL ticket along with its issue and expiration timestamps.

Step 5: Kerberize SSH for Passwordless Login (Optional Lab Exercise)

To see Kerberos authenticate a real network service without sending passwords over the wire, enable GSSAPI authentication on SSH between your client and KDC:

1. Create a Host Principal and Keytab: On kdc.lab.local, open sudo kadmin.local and generate a cryptographic keytab for the server:

   Plaintext

   addprinc -randkey host/kdc.lab.local
   ktadd host/kdc.lab.local
   quit
   

   (By default, ktadd writes the key directly to /etc/krb5.keytab.)

2. Enable GSSAPI on the SSH Server: Edit /etc/ssh/sshd_config on kdc.lab.local and ensure these lines are uncommented and set to yes:

   Plaintext

   GSSAPIAuthentication yes
   GSSAPICleanupCredentials yes
   

   Restart SSH: sudo systemctl restart ssh

3. Create a Matching Local User: Create a local Linux account named alice on kdc.lab.local (sudo useradd -m alice) so the OS knows which home directory and UID to assign after Kerberos verifies her identity.

4. Test SSO: From client.lab.local (while holding alice‘s TGT), connect via SSH with GSSAPI enabled:

   Bash

   ssh -K alice@kdc.lab.local
   

   You will log straight into the shell without a password prompt, and running klist on the server will show that your Kerberos ticket was forwarded.

Troubleshooting Tips for Your Lab

• Packet Inspection: Run sudo tcpdump -i any port 88 -w kerberos.pcap on the KDC while running kinit or ssh -K. Opening the capture in Wireshark clearly exposes the AS-REQ, AS-REP, TGS-REQ, and TGS-REP exchanges.

• Verbose Client Debugging: Prefix any Kerberos command with KRB5_TRACE=/dev/stderr (for example, KRB5_TRACE=/dev/stderr kinit alice) to print step-by-step encryption negotiation, DNS lookups, and KDC responses directly to your terminal.