The Identity Stack, Episode 5
EP01 → EP02 → EP03 → EP04: SSSD → EP05 → EP06: OpenLDAP → …
TL;DR
- Kerberos is a network authentication protocol — it proves identity without sending passwords over the network, using time-limited cryptographic tickets
- Three actors: the client, the KDC (Key Distribution Center), and the service — the KDC issues tickets; clients use tickets to authenticate to services
- The ticket flow: AS-REQ (get a TGT) → TGS-REQ (exchange TGT for a service ticket) → AP-REQ (present service ticket to the target service)
- A TGT (Ticket-Granting Ticket) is a session credential — it lets you request service tickets without re-entering your password for the lifetime of the ticket (default 10 hours)
- LDAP + Kerberos together: LDAP stores identity (who you are), Kerberos authenticates it (proves you are who you say you are) — Active Directory is exactly this combination
kinit,klist,kdestroyare the hands-on tools — run them and read the ticket output
The Big Picture: Three Actors, Three Steps
1. AS-REQ / AS-REP
Client ◄────────────────────► AS (Authentication Server)
│ │
│ (part of KDC) │
│ ▼
│ 2. TGS-REQ / TGS-REP TGS (Ticket-Granting Server)
├───────────────────────────────────►│
│ (part of KDC) │
│ │
│ 3. AP-REQ / AP-REP │
└─────────────────────────────► Service (SSH, LDAP, NFS, HTTP...)
KDC = AS + TGS (usually the same process, same machine)
EP04 mentioned Kerberos tickets and clock skew requirements without explaining the protocol. This episode explains why Kerberos was invented, what a ticket actually is, and how the three-step flow works — so that when SSSD says “KDC unreachable” or kinit fails with “pre-authentication required,” you know exactly what’s happening.
The Problem Kerberos Was Built to Solve
MIT’s Project Athena started in 1983 — a campus-wide computing initiative giving students access to thousands of workstations. The problem: how do you authenticate a student at workstation 847 to a file server across campus without sending their password over the network?
In 1988, Steve Miller and Clifford Neuman published Kerberos version 4. The core insight: a trusted third party (the KDC) can issue cryptographic proof that a user has authenticated, and that proof can be presented to any service on the network without the service ever seeing the user’s password.
The password never leaves the client machine after the initial authentication. Every subsequent authentication — to a different service, to the same service again — uses a ticket. The KDC knows both the client and the service. The client and service only need to trust the KDC.
Keys, Tickets, and Sessions
Before the protocol, the primitives:
Long-term keys — derived from passwords. When you set a password in Kerberos, it’s hashed into a key stored in the KDC database (in the krbtgt account on AD, in /var/lib/krb5kdc/principal on MIT Kerberos). The client also derives this key from the password at authentication time. Neither ever sends the raw password.
Session keys — temporary symmetric keys created by the KDC for a specific session. They’re valid for the ticket’s lifetime. After the ticket expires, the session key is useless.
Tickets — encrypted blobs issued by the KDC. A ticket contains the session key, the client identity, the expiry time, and optional flags. It’s encrypted with the target service’s long-term key — only the service can decrypt it. The client carries the ticket but can’t read the contents.
The Three-Step Flow
Step 1: AS-REQ / AS-REP — Getting a TGT
Client KDC (AS component)
│ │
│── AS-REQ ──────────────────────►
│ {username, timestamp} │
│ (timestamp encrypted with │
│ client's long-term key) │
│ │
│ KDC verifies: decrypts │
│ timestamp with stored key. │
│ If valid → issues TGT │
│ │
◄── AS-REP ──────────────────────│
{session_key_enc_with_client, │
TGT_enc_with_krbtgt_key} │
The client decrypts the session key using its long-term key (derived from the password). The TGT is encrypted with the KDC’s own key (krbtgt) — the client can’t read it, but carries it.
This is the step that requires the password. After this, the TGT is what the client uses for everything else.
Step 2: TGS-REQ / TGS-REP — Getting a Service Ticket
Client KDC (TGS component)
│ │
│── TGS-REQ ─────────────────────►
│ {TGT, authenticator, │
│ target_service_name} │
│ (authenticator encrypted │
│ with TGT session key) │
│ │
│ KDC: decrypts TGT, │
│ verifies authenticator, │
│ issues service ticket │
│ │
◄── TGS-REP ────────────────────│
{service_session_key_enc, │
service_ticket_enc_with_ │
service_long_term_key} │
No password involved. The client proves its identity by presenting the TGT (which only the KDC can issue) and an authenticator (a timestamp encrypted with the TGT’s session key, proving the client holds the session key without revealing it).
Step 3: AP-REQ / AP-REP — Authenticating to the Service
Client Service (sshd, LDAP, NFS...)
│ │
│── AP-REQ ──────────────────────►
│ {service_ticket, │
│ authenticator_enc_with_ │
│ service_session_key} │
│ │
│ Service: decrypts ticket │
│ with its long-term key, │
│ verifies authenticator │
│ │
◄── AP-REP (optional) ───────────│
{mutual authentication} │
The service decrypts the ticket using its own key. It extracts the client identity and session key. It verifies the authenticator. No communication with the KDC required — the service trusts what the KDC signed.
Why Clock Skew Matters
Every Kerberos authenticator contains a timestamp. The service rejects authenticators older than 5 minutes (by default) — this prevents replay attacks where an attacker captures an authenticator and replays it later.
This is why clock skew over 5 minutes breaks Kerberos authentication entirely. If your machine’s clock drifts 6 minutes from the KDC, every authenticator you generate is rejected as too old or too far in the future. No tickets. No AD logins. No SSSD authentication.
# Check time sync status
timedatectl status
chronyc tracking # if using chrony
ntpq -p # if using ntpd
# If clock is off: force a sync
chronyc makestep # immediate step correction (chrony)
Hands-On: kinit, klist, kdestroy
# Get a TGT (will prompt for password)
kinit [email protected]
# Show current tickets
klist
# Credentials cache: FILE:/tmp/krb5cc_1001
# Principal: [email protected]
#
# Valid starting Expires Service principal
# 04/27/26 01:00:00 04/27/26 11:00:00 krbtgt/[email protected]
# renew until 05/04/26 01:00:00
# Show encryption types used (the -e flag)
klist -e
# 04/27/26 01:00:00 04/27/26 11:00:00 krbtgt/[email protected]
# Etype: aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
# Get a service ticket for a specific service
kvno host/[email protected]
# host/[email protected]: kvno = 3
# Show all tickets including service tickets
klist -f
# Flags: F=forwardable, f=forwarded, P=proxiable, p=proxy, D=postdated,
# d=postdated, R=renewable, I=initial, i=invalid, H=hardware auth
# Destroy all tickets
kdestroy
The Valid starting and Expires fields are the ticket lifetime. After expiry, you need to re-authenticate (or renew the ticket if it’s within the renew until window). The renew until date is when even renewal stops working.
/etc/krb5.conf
[libdefaults]
default_realm = CORP.COM
dns_lookup_realm = false
dns_lookup_kdc = true # find KDCs via DNS SRV records
ticket_lifetime = 10h
renew_lifetime = 7d
forwardable = true # tickets can be forwarded to remote hosts (needed for SSH forwarding)
rdns = false
[realms]
CORP.COM = {
kdc = dc01.corp.com
kdc = dc02.corp.com # failover KDC
admin_server = dc01.corp.com
}
[domain_realm]
.corp.com = CORP.COM
corp.com = CORP.COM
With dns_lookup_kdc = true, Kerberos finds KDCs by querying DNS SRV records (_kerberos._tcp.corp.com). AD sets these up automatically. On MIT Kerberos, you add them manually. DNS-based discovery is the recommended approach for AD environments — it picks up new DCs automatically.
Kerberos + LDAP: Why Enterprises Run Both
LDAP and Kerberos solve different problems and are almost always deployed together:
LDAP answers: "Who is vamshi? What groups is he in? What's his home directory?"
Kerberos answers: "Is this really vamshi? Prove it without sending a password."
Active Directory is exactly this combination — the directory is LDAP-based, the authentication is Kerberos. When a Linux machine joins an AD domain via realm join or adcli, it gets:
– LDAP access to the AD directory (for NSS: user and group lookups)
– A Kerberos principal registered in AD (for PAM: ticket-based authentication)
– A machine account (the machine’s identity in the directory)
When you SSH into an AD-joined Linux machine:
1. SSSD issues a Kerberos AS-REQ for the user’s TGT
2. SSSD uses the TGT to get a service ticket for the Linux machine’s PAM service
3. Authentication is verified via the service ticket — no LDAP Bind with a password
4. SSSD does an LDAP Search to get POSIX attributes (UID, GID, home dir)
Password-based LDAP Bind is the fallback when Kerberos isn’t available. Kerberos is the default on AD-joined systems — and it’s more secure because the password never leaves the client.
⚠ Common Misconceptions
“Kerberos sends your password to the KDC.” It doesn’t. The client derives a key from the password locally and uses that key to encrypt a timestamp (the pre-authentication data). The KDC verifies the timestamp using the stored key. The raw password never travels.
“Kerberos is an authorization protocol.” Kerberos authenticates — it proves who you are. Authorization (what you can do) is a separate decision, usually handled by ACLs on the service or directory group membership.
“Once you have a TGT, you’re authenticated to everything.” A TGT only proves your identity to the KDC. Each service requires a separate service ticket. The TGT is what lets you get those service tickets without re-entering your password.
“Kerberos requires AD.” MIT Kerberos 5 is a standalone implementation. FreeIPA (EP08) runs MIT Kerberos. Heimdal is another implementation. AD uses a Microsoft-extended version of Kerberos 5, but the core protocol is the same RFC.
Framework Alignment
| Domain | Relevance |
|---|---|
| CISSP Domain 5: Identity and Access Management | Kerberos is the de facto enterprise authentication protocol — SSO, delegation, and service account authentication all depend on it |
| CISSP Domain 4: Communications and Network Security | Kerberos prevents credential sniffing and replay attacks — two of the core network authentication threat categories |
| CISSP Domain 3: Security Architecture and Engineering | The KDC is a critical single point of trust — its availability, key management, and account (krbtgt) rotation are architectural security decisions |
Key Takeaways
- Kerberos is a ticket-based protocol — the password is used once to get a TGT; from then on, tickets prove identity without the password
- The three-step flow: get a TGT from the AS, exchange it for a service ticket at the TGS, present the service ticket to the target service
- Clock skew over 5 minutes breaks Kerberos — time synchronization is a hard dependency
- LDAP stores identity; Kerberos authenticates it — Active Directory is exactly this combination, and so is FreeIPA
klist -eshows the encryption types in use —aes256-cts-hmac-sha1-96is what you want to see;arcfour-hmac(RC4) is legacy and should be disabled
What’s Next
EP05 covered Kerberos as a protocol. EP06 goes hands-on: building a real LDAP directory with OpenLDAP, configuring replication, and understanding how the server-side components — slapd, the MDB backend, SyncRepl — fit together.
Next: OpenLDAP Setup and Replication: Running Your Own Directory
Get EP06 in your inbox when it publishes → linuxcent.com/subscribe
