Lion Cipher Lab

Build Kerberos cross-realm authentication from scratch

• Identity & Access Management
• Advanced
• ~2.5 hours
• Free · no account required

Why it matters

Somebody in your organisation is going to say the sentence 'we just added a forest trust with the acquisition' and everyone in the room is going to nod, because it sounds like plumbing. It is not plumbing. An inter-realm trust is a decision to let another organisation's key distribution centre vouch for identities, and for group memberships, that your own services will then believe. It is one of the largest privilege-boundary changes a company can make with a single command, and it is routinely made by people who have never seen what actually crosses the wire. This lab makes you see it. You…

What you'll learn

• the cross-realm referral chain end to end: AS-REQ in your home realm, a TGS-REQ that returns a REFERRAL TGT for krbtgt/PARTNER.EXAMPLE@LAB.EXAMPLE, a TGS-REQ against the FOREIGN realm's KDC, and an AP-REQ a real service validates -- 3 KDC exchanges, measured
• why an inter-realm trust is a PRINCIPAL and a shared key, not a setting: one krbtgt entry per direction, which is what makes a trust one-way by default
• reading and writing real RFC 4120 structures: Ticket and EncTicketPart in genuine ASN.1 DER, with PrincipalName, EncryptedData, TransitedEncoding, AuthorizationData, and TicketFlags as a BIT STRING (FORWARDABLE, RENEWABLE, INITIAL, PRE-AUTHENT, TRANSITED-POLICY-CHECKED, OK-AS-DELEGATE)
• the transited field and RFC 4120 3.3.3.2 DOMAIN-X500-COMPRESS: encoding, decoding, the null subfield, and why a single-hop cross-realm ticket carries an EMPTY transited field
• proving your crypto instead of trusting it: 51/51 published RFC 3961 and RFC 3962 vectors reproduced by an AES you wrote yourself, and 5/5 of the RFC's own transited examples
• the RFC 3961 simplified profile in practice -- n-fold, DK/DR derivation, PBKDF2 string-to-key, CBC with ciphertext stealing, and the RFC 4120 7.5.1 key usage numbers that keep one key from being reused across message types
• diagnosing the five cross-realm failures by their real error codes: KRB_AP_ERR_BAD_INTEGRITY (31) for a trust-key mismatch, KDC_ERR_S_PRINCIPAL_UNKNOWN (7) for the missing reverse trust, KDC_ERR_WRONG_REALM (68) without canonicalization, KRB_AP_ERR_SKEW (37), KRB_AP_ERR_REPEAT (34) and KRB_AP_ERR_NOT_US (35)
• RFC 6806 name canonicalization: why a client that does not know which realm hosts a service still gets there, and what the KDC returns when CANONICALIZE is off
• transitive trust as a real risk you can measure: a 4-realm path, an unapproved intermediate realm, three service-side transited policies, and a KDC that erases its neighbour and is caught by none of them
• SID filtering and quarantined trusts: why a foreign KDC's authorization data is an assertion, not a fact, and what it costs you to believe it -- 7 SIDs in, 3 out, one admin decision flipped

Steps in this lab

1. Zero assumptions: realm, principal, TGT, KDC, and what 'cross-realm' means
2. What this lab is NOT, so you can place it against the ones you may have done
3. Set up: a folder and a Python you already have
4. Create krbcrypto.py -- the Kerberos crypto profile, written from the specification
5. Prove the crypto before you build on it: 51/51 published vectors
6. Create krbrealm.py -- real DER, the transited field, and the KDCs
7. The transited field, and why it is the strangest thing in Kerberos
8. Create crossrealm.py -- the harness -- and run the whole thing
9. Section [2]: the transited encoder, checked against the RFC's own examples
10. Section [3]: the happy path, hop by hop -- this is the lab
11. Failure 1: the two KDCs stop agreeing on the trust key
12. Failure 2: one-way trust, and why 'we have a trust' is not an answer
13. Failure 3: referrals and name canonicalization (RFC 6806)
14. Failure 4: clock skew, at exactly the boundary
15. Failure 5: replay, and what a replay cache is actually for
16. Failure 6: the right ticket at the wrong service, and why realm is part of the name
17. Section [10]: the multi-hop path, and a KDC that quietly lies
18. Section [11]: authorization data your KDC never issued, and SID filtering
19. Judgment: cross-realm Kerberos, or SAML/OIDC federation, or one shared identity provider?
20. When NOT to build a trust, and how a pro handles the one they cannot avoid
21. What is real here, what is a teaching encoding, and where to go next
22. Clean up

Open the full interactive lab →