Learn Kerberos - Production Checklist & Best Practices

#Introduction

Congratulations — you've come a long way. From episode 0, which introduced the basics of authentication and the myths surrounding Kerberos, you learned the architecture of the KDC, AS, and TGS; the complete ticket exchange flow; keytabs and principals; realm policies like lifetime and renewable; cross-realm trust; large scale and replication in episode 26; Kerberos in the cloud in episode 27; modern alternatives in episode 28; and compliance and audit in episode 29. Episode 30 is the culmination: bringing it all together into a production checklist and best practices you can use tomorrow morning. This isn't new material — it's a checklist distilling the entire series.

#Pre-Production Checklist

Before a realm touches production, make sure the following eight things are correct:

Each item is detailed below.

#Correct DNS

Kerberos relies on DNS to find the KDC and determine the realm. Make sure the A and SRV records _kerberos._udp and _kerberos._tcp are correct, then test from the client's point of view:

host -t SRV _kerberos._udp.prod.example.com
kinit budi
klist

If kinit succeeds and klist shows a TGT, DNS is healthy enough for production. A correct krb5.conf configuration on the client won't help if the SRV records are wrong.

#Time Synchronization

Kerberos uses timestamps to fight replay attacks. The maximum clock skew is usually around 5 minutes, but a healthy production environment keeps well below that. Use NTP or chrony on all hosts, and make sure the KDC itself uses a trusted time source:

timedatectl status
chronyc tracking

A difference of seconds, not minutes, is a healthy target.

#Hardened Encryption

In production, only modern enctypes may live. Disable DES and RC4, enable AES, and reject weak cryptography:

Hardened enctypes in krb5.conf

[libdefaults]
    default_realm = PROD.EXAMPLE.COM
    allow_weak_crypto = false
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

The chosen enctypes must be understood by every member of the realm — KDC, clients, and services. Enctype changes are among the most sensitive changes, so test in staging first.

#KDC Replicas and High Availability

A single KDC is a single point of failure. At least one replica is required; the database is replicated from the master. Clients use DNS SRV covering all KDCs, so one master's failure doesn't break authentication. Test failover periodically — shut down the master and make sure clients can still get tickets.

#Monitoring

An unmonitored KDC is a ticking time bomb. What must be monitored:

• Whether the krb5kdc process is alive or dead
• AS-REQ failure rates — a spike signals brute-force or key problems
• Request volume against capacity
• KDC response latency

alerts:
  - name: kdc-down
    expr: up{job="krb5kdc"} == 0
  - name: auth-fail-spike
    expr: rate(kdc_as_req_failed_total[5m]) > 10

Monitoring prevents outages — not by avoiding failure, but by making failure visible earlier.

#Tested Backup

A KDC backup is the principal database files at /var/lib/krb5kdc/principal* plus kadm5.acl and configuration. A good backup is one that has been restored — schedule a restore test before production, not after a disaster. A database that can't be restored is worth the same as having no backup at all.

#Documentation

A production realm that only exists in its admin's head is a risk. Document the realm topology, the KDC list, the principal-adding procedure, the keytab rotation schedule, and runbooks for common incidents. Documentation saves you in the middle of the night when an incident happens — and good documents are built before the incident, not after.

#Final Security Audit

Before go-live, run an audit: review kadm5.acl, make sure there are no principals without owners, verify enctypes across the realm, and check whether kadmin is only accessible from the right hosts. Treat this final audit as the green light signal.

#Operational Best Practices

Once production is running, the work isn't done — it's just begun. The six practices below keep the realm healthy in the long run.

#Periodic Principal Audit

Repeat the access review from episode 29: compare the principal inventory against business needs, delete idle ones, and confirm the owners of privileged accounts. Schedule monthly or quarterly, depending on the applicable compliance framework.

#Password and Keytab Rotation

Passwords and keytabs have a shelf life. Set a rotation schedule: administrative passwords rotated periodically, service keytabs rotated on personnel changes or signs of compromise, and make sure all hosts receive the new kvno.

#Patch Management

The KDC is a critical component; security holes in MIT Kerberos or in the cryptography underneath it are entry points. Follow vendor security releases and apply patches quickly. Patch negligence is one way a well-built production realm can still be breached.

#Capacity and Planning

Monitor the growth of principal counts and request volume. When approaching limits, add replicas or enlarge instances. Unmonitored capacity makes authentication slow during busy periods — and slow authentication spreads through the entire organization.

#Incident Response Plan

Scenarios that must have procedures: KDC down, compromised keytab, hijacked principal, or brute-force against kpasswd. Write down the steps, who to contact, and how to recover. It doesn't need to be perfect — it needs to exist and be tested.

#Change Management

Every realm configuration change — adding a KDC, changing enctypes, replacing the master — is a risky change. Follow a change management process: plan, test in staging, execute in an agreed window, and prepare a rollback.

#Common Traps

Here are the traps that most often trip up production teams, along with their prevention:

These seven traps are the seven main reasons a well-built realm can still collapse in production.

#Key Takeaways

Summarizing the entire series in ten points:

• Kerberos provides strong, battle-tested authentication spanning decades.
• Time synchronization is truly critical — without it, everything breaks.
• DNS must be reliable.
• AES encryption is a must.
• High availability with replicas is mandatory for production.
• Monitoring prevents outages.
• Periodic security audits keep the realm clean.
• Documentation saves time in difficult moments.
• Testing is a continuous activity, not a one-off.
• Always follow security advisories.

#Conclusion

And here is where the journey ends. Starting from episode 0, you built understanding from scratch: what authentication is and why tickets became the answer; the anatomy of the KDC, AS, and TGS; the complete Kerberos flow; keytabs and principals; realm policies like lifetime and renewable; cross-realm trust; large scale and replication; Kerberos in the cloud; its position among OAuth2, OIDC, and SAML; compliance and audit; and now the production checklist that unites it all. Thirty episodes, one complete story about an authentication protocol that has been the backbone of enterprise networks for over three decades.

Key takeaways:

• Kerberos isn't a dead protocol — it keeps living as the authentication engine behind Active Directory and many enterprise networks.
• Operational discipline determines everything — time, DNS, encryption, and backup are the four pillars of production.
• Compliance and security go together — logs, reviews, and audits are part of the design, not additions.
• Now it's your turn — there's no better teacher than the realm you build yourself.

Your journey in this series stops here, but learning doesn't stop. If you enjoy the identity world, the natural next direction is Active Directory — because most of what you learned about Kerberos in this series is the foundation for understanding how Windows manages authentication at the scale of thousands of domains. After that, the wider identity and access management world — federation, privileged access management, and passwordless — awaits exploration. See you on the next adventure.