Learn Kerberos - Principal Management & Administration

#Introduction

In episode 7 you created service principals and keytabs via kadmin.local. In episode 8 we pause from technique and focus on the bigger responsibility: full principal administration. As a Kerberos admin, you don't just add principals — you manage their entire lifecycle: attributes, password policies, admin access rights, and audit trails. At enterprise scale with thousands of accounts, a small administrative mistake can become a large security hole.

#kadmin vs kadmin.local

There are two ways to enter the administration tool:

• kadmin.local: run directly on the KDC machine by root. It reads the principal database directly, so no Kerberos authentication is needed first. Convenient for initial bootstrap, but it should only exist on the KDC.
• kadmin: run from anywhere over the network. It connects to kadmind on the admin_server and demands authentication with an admin principal (e.g. admin/admin) before a single command is processed.

kinit admin/admin
kadmin

kinit admin/admin obtains a TGT for the admin account, and then kadmin uses that ticket to open an administrative connection. The crucial difference: kadmin.local ignores the ACL entirely, whereas remote kadmin is always checked against kadm5.acl. This is why the ACL only matters for remote access — so never expose kadmind to an untrusted network.

#Basic Principal Operations

The core of administration is six commands:

Example session:

kadmin.local:  listprincs
K/M@EXAMPLE.COM
admin/admin@EXAMPLE.COM
budi@EXAMPLE.COM
host/web1.example.com@EXAMPLE.COM
kadmin.local:  getprinc budi
kadmin.local:  modprinc -maxlife 8h budi
kadmin.local:  cpw budi
kadmin.local:  delprinc budi

listprincs is useful for inventory; getprinc shows details like expiration times, policies, and attributes; modprinc -maxlife 8h limits that principal's ticket lifetime; cpw changes the password; and delprinc removes an identity — the final step when a user leaves (offboarding).

#Frequently Changed Principal Attributes

modprinc works on a set of attributes. These are the ones you'll touch most often:

kadmin.local:  modprinc -expire 2027-01-01 budi@EXAMPLE.COM
kadmin.local:  modprinc -maxlife 8h budi@EXAMPLE.COM
kadmin.local:  modprinc -requires_preauth budi@EXAMPLE.COM

The rule of thumb: give principals only the attributes they need. -requires_preauth prevents AS-REP roasting, so enable it for all users. -maxlife and -maxrenewlife control how long credentials live — the shorter, the smaller the misuse window if a cache is stolen.

#Password Policies (krb5-policies)

Weak passwords are an attacker's favorite entry point. Kerberos provides password policies attached to principals — not arbitrary global criteria. The commands are add_policy, modpol, delpol, and listpols:

kadmin.local:  add_policy -minlength 14 -minclasses 3 -history 24 strong
kadmin.local:  listpols
kadmin.local:  modprinc -policy strong budi@EXAMPLE.COM

The main criteria you can set:

• -minlength — minimum password length.
• -minclasses — minimum number of character classes (uppercase, lowercase, digits, symbols).
• -history — number of old passwords that cannot be reused.
• -minlife and -maxlife — the password age range.
• -failcount and -lockout — automatic lockout after several failures.

One principal can only use one policy. Distinguish policies for regular users, service accounts, and admins — don't use a single standard for everything.

#Managing Keytabs: Rotation and Distribution

Although keytab details were covered in episode 7, there's an administrative side you must master: rotation. Because a keytab is a static credential on disk, it must be rotated periodically. The process:

1. Create a new key on the KDC — KVNO goes up.
2. Grab the new key into the keytab with ktadd.
3. Remove the old entry with ktutil, or leave it as a transition.
4. Distribute the new keytab to service machines securely (e.g. via config management with encryption).

kadmin.local:  ktadd -k /etc/krb5.keytab HTTP/web1.example.com
Entry for principal "HTTP/web1.example.com" with kvno 4, encryption type
aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.

Note that the KVNO goes up to 4. A service still holding the KVNO 3 keytab will fail to authenticate until its keytab is updated — so coordinate rotation with maintenance windows, or overlap both KVNOs during the transition period.

#Admin ACL: kadm5.acl

The kadm5.acl file (usually at /var/kerberos/krb5kdc/kadm5.acl or /etc/krb5kdc/kadm5.acl) determines who may do what to which principals. Each line's format:

principal  access-rights  target-principal

The access rights: a (add), d (delete), m (modify), c (change password), i (inspect), l (list), s (set key), and * for all. Example:

/var/kerberos/krb5kdc/kadm5.acl

*/admin@EXAMPLE.COM     *
budi@EXAMPLE.COM        c   user/*

The first line grants all rights to principals prefixed with admin — these are full admin accounts. The second line gives budi the right to only change passwords on principals prefixed with user/. You can apply very fine-grained least privilege: for example, a group admin can only m and c on their group's members, but not a or d.

#Deleting and Resetting Principals

Two operations most often cause problems when done wrong: deletion and reset.

kadmin.local:  cpw -keepold host/web1.example.com
kadmin.local:  delprinc -force budi@EXAMPLE.COM

cpw -keepold keeps the old key while adding a new one — useful when rotating without breaking services still using the old key. delprinc -force skips interactive confirmation, suitable for bulk scripts. Before deleting, make sure the principal is no longer in use: check running processes, job schedulers, and services referencing it. Deleting a principal still in use by a service will kill all that service's authentication abruptly.

#Administrative Auditing

Administration without auditing is like cash without record-keeping. All kadmind operations can be written to a log — configured via admin_server_log in kdc.conf:

Admin logging in kdc.conf

[kdcdefaults]
    kdc_ports = 88
 
[realms]
    EXAMPLE.COM = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /var/kerberos/krb5kdc/kadm5.acl
        admin_server_log = FILE:/var/log/kadmind.log
        kdc_ports = 88
    }

With admin_server_log active, every addprinc, modprinc, delprinc, and cpw is recorded along with the admin principal who performed it. A healthy audit routine: review this log periodically, look for suspicious patterns like mass policy changes or cpw on service accounts without a schedule, and archive logs per your retention policy. In episode 22 we'll deepen monitoring and alerting.

#Conclusion

In episode 8, you mastered the administrative side of Kerberos: the difference between kadmin and kadmin.local, six basic principal operations, principal attributes, password policies, keytab rotation, admin ACLs in kadm5.acl, and administrative auditing.

Key takeaways:

• kadmin.local ignores the ACL; remote kadmin always obeys kadm5.acl.
• Principal attributes restrict what clients may request.
• Password policies (add_policy) attach to principals, not globally.
• kadm5.acl enables fine-grained least privilege — use it.
• All admin actions should be recorded in kadmind.log for audit.

In the next episode, episode 9, we descend into every user's daily experience: ticket management and lifetime — how lifetime, renewable, forwardable, proxiable, and postdated work, plus techniques to keep tickets alive for jobs running for weeks. The attributes you set in this episode will determine what's possible in episode 9.