Learn Kerberos - Compliance & Audit

#Introduction

Episode 28 showed Kerberos coexisting with OAuth2, OIDC, and SAML in a modern organization. Episode 29 adds a layer that can't be negotiated: governance. When a system is used to access financial, health, or personal data, regulators and auditors start asking — how do you prove who accessed what, and who is authorized to change the settings. The answer lies in three words: policy, logging, and review.

#Why Compliance Touches Kerberos

Kerberos is the front door. Every time a user or service enters the network, it passes through the KDC. That's why the KDC sits at the most strategic point for compliance: it sees authentication, supports authorization, and can prove who accessed which service. Precisely for that reason, KDC logs and principal policies become primary evidence in an audit.

#Compliance Frameworks

The four frameworks most often encountered:

Framework	Focus	Impact on Kerberos
SOC 2	Internal control and trust	Document access control, monitoring, periodic review
HIPAA	Protected health data	Strong authentication and audit of medical data access
PCI-DSS	Payment card data	Unique per-user access, logging, access limits
GDPR	Privacy of EU citizens' data	Access control, processing mapping, data retention

The detailed provisions differ and are constantly updated; what you need to hold onto is the common pattern: every framework demands evidence that access is controlled, recorded, and reviewed.

#SOC 2

SOC 2 assesses an organization's controls over security, availability, integrity, confidentiality, and privacy. For Kerberos, this means: access controls must be documented, authentication logs must exist, and access reviews must run periodically. Complete KDC logs become proof that those controls are actually being exercised.

#HIPAA

HIPAA regulates protected health data. The key requirement is ensuring only authorized parties can access that data. Kerberos helps with strong authentication and service tickets that record access to data storage services — as long as the logs are retained and can be reconstructed for audit.

#PCI-DSS

For environments handling payment card data, PCI-DSS demands unique per-user access and prohibits shared accounts. This aligns with Kerberos principles: every principal is a unique identity. Failed authentication logs also feed into detecting intrusion attempts.

GDPR isn't about data security but privacy. Its connection to Kerberos: logs containing user identities are personal data — their storage must be proportionate, with retention limits, and access to the logs themselves must be restricted. This teaches one thing: don't log more than necessary, and delete on schedule.

#Audit Logging

Logs are the backbone of compliance. Without logs, you only have claims. Modern KDCs record important events by default; your job is ensuring the logs are complete, secure, and centralized.

Send logs to a centralized log server (e.g. rsyslog, ELK, or a SIEM service) so they can't be deleted just by wiping the KDC server's disk.

#Types of Events to Record

Event Type	Example	Reason to Record
Authentication	Successful or failed AS-REQ	Proof of identity, brute-force detection
Authorization	TGS-REQ, service ticket usage	Trace of which service was accessed
Administrative	Principal changes via `kadmin`	Trace of who changed access rights

Authentication answers who logged in, authorization answers what they accessed, and administrative answers who changed the rules of the game.

Important

Treat KDC logs like valuables: store them on an append-only system or encrypted backup, restrict who can read them, and apply retention limits. Running grep directly on the KDC server is a sign your log controls aren't adequate.

#Log Retention

Logs without limits are as bad as lost logs. Set how long logs are kept according to compliance and operational needs, store them in a location resistant to compromise, and create a destruction schedule so personal data doesn't linger indefinitely — consistent with the GDPR principle above.

#Access Reviews

Logging proves what happened; access reviews ensure what happened is what should have happened. An access review is a periodic examination of who holds credentials and whether that's still appropriate.

#Principal Inventory

You can't audit what you don't know about. Start with an inventory of all principals:

Listing all principals

kadmin.local -q "listprincs" > /audit/principals.txt
kadmin.local -q "getprinc budi"

This list becomes the baseline: compare it with business needs, flag those with unclear owners, then decide whether to delete or keep them.

#Reviewing Privileged Accounts and Service Accounts

Accounts with privileges and service accounts are prime abuse targets:

Privileged account — principals with administrative access to the KDC or key systems; they must be reviewed more often, ideally with just-in-time permissions.
Service account — identities for services via keytab; make sure only the correct service holds the keytab, and remove unused ones.

One golden rule: no account without a clear owner. Every principal must be traceable to a person or team responsible for it.

#Detecting Inactive Principals

Accounts long unused are idle risk. Detect them through authentication logs: a principal that never appears in an AS-REQ for, say, 90 days deserves questioning. Flag it, confirm with the owner, then disable or delete it if it's truly no longer needed.

Viewing a principal's authentication history

grep "budi" /var/log/kerberos/krb5kdc.log | tail -50

#Reporting

Auditors need reports, not raw log access. Build standard reports that can be generated periodically:

Authentication report — successful login counts per principal per period.
Failed login report — failure concentration as a brute-force indicator.
Service usage report — most-requested service tickets.
Compliance report — summary of access reviews, log retention, and remediation status.

Consistent, scheduled reports make the audit process far smoother than compiling them in a panic at the last minute.

#Security Certifications

Besides compliance frameworks, there are technical standards attached to Kerberos cryptography:

FIPS 140-2 — the NIST standard for cryptographic modules. KDCs and clients performing cryptographic operations must use implementations meeting this standard and only allow approved ciphers, such as AES.
Common Criteria — a product security evaluation standard; some distributions and directory products pursue this certification to strengthen their security claims.
Encryption standards — in practice this means disabling DES and RC4, only enabling AES-256, and enforcing modern enctypes across the realm.

#Conclusion

Episode 29 tied the technical side to the governance side. You've seen how SOC 2, HIPAA, PCI-DSS, and GDPR affect Kerberos configuration decisions; how to build audit logging that records authentication, authorization, and administrative actions; how to run access reviews of principals, privileged accounts, service accounts, and inactive accounts; how to prepare reports for auditors; and standards like FIPS 140-2 and Common Criteria that keep cryptography on the right track.

Key takeaways:

Logs are evidence — without complete, centralized logs, compliance claims are worthless.
Periodic access reviews are mandatory, not optional.
Don't log more than needed — retention limits are also part of compliance.
Modern encryption is the price of entry — turn off DES and RC4.

In the next episode, episode 30, the final episode of this series, we summarize everything: production checklist and best practices — concrete steps before go-live, how to keep the realm healthy in day-to-day operations, and the traps that trip people up most often.