Kerberos concepts - tickets, realms, and principals

Kerberos is the authentication protocol behind Active Directory and many Unix enterprise setups. It provides single sign-on: authenticate once, get tickets for many services without re-entering credentials.

The actors

• Client: the user (via kinit, ssh, etc.).
• KDC (Key Distribution Center): the Kerberos server, typically the AD Domain Controller. Holds all secret keys.
• Service: the resource being accessed (SSH, NFS, HTTP, etc.).

A realm is the administrative domain (typically an AD domain, uppercase, like EXAMPLE.COM).

A principal identifies a client or service:

• User principal: alice@EXAMPLE.COM
• Service principal: host/server.example.com@EXAMPLE.COM
• Service with instance: nfs/server.example.com@EXAMPLE.COM

The flow

1. Client -> KDC:  AS-REQ (alice@EXAMPLE.COM)
2. KDC -> Client:  AS-REP (TGT encrypted with alice\'s key)
3. Client decrypts TGT with password
4. Client -> KDC:  TGS-REQ (TGT + service principal)
5. KDC -> Client:  TGS-REP (service ticket)
6. Client -> Service:  AP-REQ (service ticket)
7. Service verifies ticket; access granted

The TGT (Ticket Granting Ticket) is short-lived (typically 10 hours) and lets the client request service tickets without re-entering the password.

kinit and klist

kinit alice@EXAMPLE.COM       # get a TGT
klist                        # list current tickets
kdestroy                     # destroy tickets

klist output:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting       Expires              Service principal
08/09/26 14:30:00    08/10/26 00:30:00    krbtgt/EXAMPLE.COM@EXAMPLE.COM

The krbtgt/EXAMPLE.COM@EXAMPLE.COM is the TGT.

Linux configuration

/etc/krb5.conf:

[libdefaults]
    default_realm = EXAMPLE.COM
    rdns = false
    dns_canonicalize_hostname = false

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

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

The kdc entries are the AD Domain Controllers.

Single sign-on with SSH

For SSH to use Kerberos (no password prompt after kinit):

# /etc/ssh/ssh_config (client)
Host *.example.com
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes

The server must trust the realm:

# /etc/ssh/sshd_config
GSSAPIAuthentication yes

After kinit alice@EXAMPLE.COM:

ssh alice@server.example.com    # no password prompt

Clock skew

Kerberos requires clocks to be within 5 minutes by default. A skewed client cannot get tickets.

kinit: krb5_get_init_creds: Clock skew too great

Fix: configure NTP (covered in Part XXIV).

Common failure modes

• Clock skew: the canonical Kerberos error. Fix NTP.
• Wrong realm: alice@EXAMPLE.COM vs alice@example.com. Kerberos realms are case-sensitive.
• DNS not finding KDC: ensure DNS resolves dc1.example.com and that the SRV records (_kerberos._tcp.EXAMPLE.COM) point to the right servers.
• Service principal missing: a service that does not have a Kerberos principal cannot accept Kerberos auth.
• krb5.conf wrong: typos in the realm, KDC, or domain mapping.

Keytab files

A keytab is a file containing service principal keys. Services use keytabs to authenticate without a password:

sudo ktutil
ktutil: addent -password -p host/server.example.com@EXAMPLE.COM -k 0 -e aes256-cts-hmac-sha1-96
ktutil: wkt /etc/krb5.keytab
ktutil: quit

Or with msktutil for AD:

msktutil -c -b "CN=Computers" -s HTTP/server.example.com \
  -h server.example.com -k /etc/krb5.keytab

Troubleshooting

kdestroy
kinit -V    # verbose
klist -v    # verbose list
kinit -R    # renew TGT

Kerberos is verbose when it fails; the error message almost always tells you the cause.

Knowledge check