Kerberos in the Enterprise: Architecture, Deployment, and Hardening Guide

Overview

Kerberos is a symmetric-key, ticket-based authentication protocol designed to verify identities over untrusted networks without sending passwords in clear text. Enterprises use it to provide single sign-on (SSO) across domain-joined systems, reduce credential exposure, and centralize authentication policy.

Its core purpose is to let a client prove identity to a service using time-bound tickets issued by a trusted Key Distribution Center (KDC). In practice, Kerberos underpins Microsoft Active Directory, many Linux identity integrations, Hadoop ecosystems, and cross-platform enterprise applications.

Architecture

Core components

• Client/Principal: User or service identity, such as alice@EXAMPLE.COM or HTTP/app01.example.com@EXAMPLE.COM
• KDC: Trusted authority that issues tickets; logically split into:
  • Authentication Server (AS)
  • Ticket Granting Server (TGS)
• Ticket Granting Ticket (TGT): Initial ticket used to request service tickets
• Service Ticket: Ticket presented to a target service
• Keytab: File storing long-term service keys for non-interactive authentication
• Realm: Administrative boundary, usually mapped to a DNS domain in uppercase

Deployment models

• Active Directory Kerberos: Most common enterprise deployment; KDC runs on domain controllers
• MIT Kerberos: Common in Linux/Unix estates and application-specific realms
• Cross-realm trust: Used for mergers, multi-forest access, or hybrid Linux/Windows estates

Data flow

1. User logs in and requests a TGT from the AS.
2. KDC validates credentials and returns a TGT encrypted with the TGS key.
3. Client presents TGT to the TGS and requests a ticket for HTTP/app01.example.com.
4. TGS returns a service ticket.
5. Client presents the service ticket to the application server.
6. Server validates the ticket using its keytab and optionally performs mutual authentication.

Implementation Guide

1. Install Kerberos packages on RHEL/Ubuntu

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

2. Configure /etc/krb5.conf

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 rdns = false
 ticket_lifetime = 10h
 renew_lifetime = 7d
 forwardable = true
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

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

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

3. Initialize the realm

sudo krb5_newrealm

4. Create principals

sudo kadmin.local -q "addprinc admin/admin"
sudo kadmin.local -q "addprinc alice"
sudo kadmin.local -q "addprinc -randkey HTTP/app01.example.com"

5. Create and secure a keytab

sudo kadmin.local -q "ktadd -k /etc/security/keytabs/http_app01.keytab HTTP/app01.example.com"
sudo chown root:root /etc/security/keytabs/http_app01.keytab
sudo chmod 600 /etc/security/keytabs/http_app01.keytab

6. Test ticket issuance

kinit alice
klist
kvno HTTP/app01.example.com

7. Start services

sudo systemctl enable --now krb5-kdc krb5-admin-server
sudo systemctl status krb5-kdc krb5-admin-server

Code Examples

Example 1: Validate a Kerberos ticket cache

kinit alice@EXAMPLE.COM
klist -e
kvno HTTP/app01.example.com@EXAMPLE.COM

Example 2: Service configuration with keytab path

server:
  port: 8443
security:
  kerberos:
    realm: EXAMPLE.COM
    servicePrincipal: HTTP/app01.example.com@EXAMPLE.COM
    keytab: /etc/security/keytabs/http_app01.keytab
    debug: false

Example 3: Python GSSAPI client test

import gssapi
service_name = gssapi.Name("HTTP@app01.example.com", name_type=gssapi.NameType.hostbased_service)
ctx = gssapi.SecurityContext(name=service_name, usage="initiate")
token = ctx.step()
print("Token generated:", token is not None)
print("Complete:", ctx.complete)

Security Hardening

• Enforce AES128/AES256 encryption; disable DES and RC4 where legacy support is not required.
• Require NTP time synchronization; Kerberos is highly sensitive to clock skew.
• Protect keytabs with 0600 permissions and store them outside application directories.
• Limit delegation and use constrained delegation instead of unconstrained delegation in AD.
• Rotate service keys regularly using ktadd or AD service account password rotation.
• Audit privileged principals such as krbtgt, domain admins, and service accounts with SPNs.

Comparison

Troubleshooting

1. Clock skew too great

Log sample:

kinit: Clock skew too great while getting initial credentials
krb5kdc[1842](info): AS_REQ (7 etypes {18 17 20 19 16 23 25}) 10.10.20.15: ISSUE: authtime 1717142103, etypes {rep=18 tkt=18 ses=18}, alice@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM

Fix: Sync all clients and KDCs with the same NTP source; verify timedatectl status.

2. SPN or keytab mismatch

Log sample:

gss_accept_sec_context(): Unspecified GSS failure. Minor code may provide more information
Request ticket server HTTP/app01.example.com@EXAMPLE.COM not found in keytab (ticket kvno 4)

Fix: Recreate the keytab for the exact SPN and verify KVNO with klist -k -t /etc/security/keytabs/http_app01.keytab.

3. KDC unreachable

Log sample:

kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials
systemd-resolved[611]: DNS query failed for _kerberos._udp.example.com IN SRV

Fix: Validate DNS SRV records, firewall rules for UDP/TCP 88, and krb5.conf realm mappings.

Best Practices

Do

• Use DNS SRV records and consistent realm-to-domain mappings.
• Standardize on service principals like HTTP/fqdn@REALM.
• Monitor KDC logs for repeated pre-auth failures and unusual TGS requests.
• Use separate service accounts per application tier.

Don't

• Do not reuse one keytab across many hosts unless the service model explicitly requires it.
• Do not disable pre-authentication except for tightly controlled interoperability cases.
• Do not allow stale SPNs; duplicate SPNs cause authentication ambiguity.
• Do not ignore krbtgt rotation policy in Active Directory after compromise scenarios.