Learn Kerberos - Kerberos Preauth & FAST

#Introduction

In episode 11 we secured Kerberos's cryptographic foundation: choosing modern AES encryption types and eliminating the weak DES/RC4. Strong encryption is useless when the initial authentication process itself can be attacked offline. This time we lock the earliest door: preauthentication — proof that the client truly knows its secret before the KDC issues a ticket — then step up a level with FAST (Flexible Authentication via Secure Tunneling), which wraps the entire authentication process inside an encrypted tunnel.

Imagine a hotel. When checking in, the receptionist should verify your identity first before handing over the room key card. Imagine instead that they hand an envelope containing "secret instructions" to anyone who asks, without asking anything at all. A thief would simply take the envelope home and calmly try to crack it. That's a picture of Kerberos without preauth.

#Why Preauth Exists: The Problem Behind the Open AS-REP

Recall the AS flow from episode 3: the client sends an AS-REQ to request a TGT, and the KDC replies with an AS-REP. The important part: the TGT inside the AS-REP is encrypted with the client's long-term key — the key derived from the password.

The problem: if preauth is not required, a client can send an AS-REQ without proving anything. The KDC still replies with an AS-REP containing ciphertext encrypted with that password-derived key. An attacker with no account at all can record that ciphertext and perform an offline brute force — trying millions of passwords on their own computer, with no login attempt limits. This attack is known as AS-REP roasting (a sibling of Kerberoasting, covered in episode 21).

This is a classic design leak: the KDC must not hand out attack material before the client proves itself. Preauth closes that gap at its source.

#Encrypted Timestamp Preauth: Proof Before the Ticket

The simplest and most widely used preauth mechanism is the encrypted timestamp (PA-ENC-TIMESTAMP). The flow:

1. The client takes the current time (a timestamp).
2. The client encrypts that timestamp with its password-derived key.
3. The AS-REQ is sent with this encrypted preauth data.
4. The KDC looks up the client's key in its database, decrypts the timestamp, and verifies: (a) it decrypts correctly — meaning the client knows its password, and (b) the timestamp is still fresh — meaning it's not a replay attack.

The security core: to produce valid ciphertext, the attacker must know the password. Without the password, there is no proof — and the KDC refuses to issue a TGT. And because the timestamp's freshness is verified, a recorded ticket cannot be replayed minutes later.

#Enforcing Preauth: The requires_preauth Flag

Preauth is not automatically enabled for all principals in all older versions. Enforcement is done through a flag on the principal, called requires_preauth. Through kadmin, this flag is set with +requires_preauth (on) or -requires_preauth (off):

kadmin.local -q "modprinc +requires_preauth alice@EXAMPLE.COM"
kadmin.local -q "getprinc alice@EXAMPLE.COM" | grep -i preauth

For service principals like host/server.example.com that authenticate via keytab, set +requires_preauth as well — ensuring that only clients holding a genuinely authenticated TGT can obtain a service ticket for it.

If preauth is required but the client sends an AS-REQ without it, the KDC replies with the KRB5KDC_ERR_PREAUTH_REQUIRED error. Modern clients like kinit read that error and automatically retry with preauth. That's why transitioning to preauth is usually invisible on the user side:

kinit -V alice@EXAMPLE.COM

For organizations, the best way to ensure all new principals start with preauth is via default_principal_flags in kdc.conf. The +preauth flag on this line makes every principal newly created in that realm inherit requires_preauth immediately:

kdc.conf - requiring preauth for all new principals

[realms]
    EXAMPLE.COM = {
        default_principal_flags = +preauth
        restrict_anonymous_to_tgt = true
    }

#AS-REP Roasting: The Attack That Motivates All of This

Because its relevance is so direct, let's dissect this attack more deeply. AS-REP roasting works in three simple steps:

1. The attacker enumerates all principals that do not require preauth (obtainable via an LDAP query or from an AD dump).
2. For each of those principals, the attacker sends an AS-REQ without preauth.
3. The KDC replies with an AS-REP containing ciphertext. The attacker brute-forces that ciphertext offline — its speed depends on the GPU, not on the server's login limits.

The impact: an account with a weak password and no preauth can be cracked without ever producing a single suspicious login log. This is why the most important step isn't merely "use a strong password" — it's make sure the requires_preauth flag is enabled for everyone.

Detection is also clear on the KDC side: look at successful authentication logs where preauth was not used (in AD, event 4768 with PreAuthType: 0). Any successful login without preauth should be treated as an alarm.

#FAST: A Tunnel for Authentication

Preauth closes the AS-REP gap, but the AS exchange still runs in cleartext. An attacker who can observe network traffic can still perform an offline attack on the preauth data itself, downgrade the encryption version, or even forge KDC error messages to mislead the client.

FAST (RFC 6113) solves this by wrapping the entire AS exchange inside an encrypted tunnel. The key is an armor ticket: a TGT used as encryption material to "coat" the real AS-REQ/AS-REP.

How FAST works:

1. The client and KDC agree to use an armor ticket (which can be the client's ordinary TGT, or an anonymous ticket).
2. The real AS-REQ is wrapped inside a FAST layer encrypted with the armor ticket's key.
3. The KDC opens the tunnel, processes the real preauth, and sends the AS-REP back through the same tunnel.

As a result, the client's credentials and preauth data are never exposed on the open network, and the KDC's response is guaranteed not to be modified in transit. FAST also allows new preauth mechanisms that require confidentiality to be used — something impossible without a tunnel.

An analogy: normal preauth is like showing your ID card at an open reception desk — other door guards nearby can peek. FAST is like whispering that identity number into the receptionist's ear through a closed channel, while the other guards only see sealed envelopes going in and out.

#Configuring FAST & Anonymous PKINIT

FAST is built into the MIT KDC; all you need to do is enable it on the client side. Use -T to specify the ticket cache used as armor, or the pa_fast_armor attribute:

kinit -T FILE:/tmp/armor.cc alice@EXAMPLE.COM
kinit -X pa_fast_armor=FILE:/tmp/armor.cc alice@EXAMPLE.COM

The more interesting variant is anonymous PKINIT: the client obtains an anonymous ticket via a public certificate (without identity), then uses it as armor. The client's true identity is only revealed inside the tunnel — from an eavesdropper's point of view, there is only useless anonymous traffic. This is the model used to secure the login process in many enterprise environments.

To enable it:

• Install the KDC certificate and configure pkinit_anchors on both sides (we'll dissect the PKINIT details in a moment).
• In kdc.conf, set restrict_anonymous_to_tgt = true (see the config block above). This setting allows anonymous tickets for armor while preventing the anonymous principal from accessing other services indiscriminately.
• The client requests an anonymous ticket with:

kinit -n @EXAMPLE.COM

#PKINIT and OTP: Non-Password Preauth

PKINIT (RFC 4556) is a public-key based preauth mechanism: the client proves its identity with a digital certificate — usually from a smart card or hardware token — rather than a password. Its advantages: there is no longer a "shared secret" that can be brute-forced, and authentication can be two-factor (certificate + PIN). On the client side, PKINIT is configured via the -X attribute or pkinit_identities in krb5.conf:

kinit -X X509_user_identity=FILE:/etc/ssl/private/alice.pem,alice.key alice@EXAMPLE.COM

Meanwhile, OTP (One-Time Password) provides preauth based on one-time-use tokens (RFC 6560). The MIT KDC supports OTP natively and can be connected to RADIUS, so tokens from any vendor that speaks RADIUS can be used for Kerberos authentication. The "password + OTP token" combination is a real implementation of two-factor authentication in the Kerberos world, and both run as preauth mechanisms inside the secure FAST tunnel.

#Conclusion

In this episode we locked the earliest phase of Kerberos authentication: preauthentication to ensure the client proves knowledge of its secret before the KDC issues a ticket — closing the AS-REP roasting gap; encrypted timestamp preauth as the main mechanism; the requires_preauth flag as its enforcement lever; FAST as the encrypted tunnel protecting the entire exchange; and PKINIT and OTP as non-password preauth paths.

The core of this episode: preauth is the first wall, FAST is the roof. One principle shelters both — never give the enemy material to work with in their own home; force all proof to happen where you control it.

Now our authentication foundation is solid. In episode 13 we exploit that power: SSH with Kerberos via GSSAPI — logging into dozens of servers without passwords, without scattered public keys, with just one kinit in the morning. See you there!