KADM5.ACL(5)

💖 KADM5.ACL 💖

okay bestie, so this one is the kadm5.acl page — the Kerberos ACL file manual, straight from MIT Kerberos. It's giving gatekeeper-of-the-database energy and honestly? iconic. let's get into it 💅

---

✨ NAME ✨

kadm5.acl — the Kerberos ACL file 🎀

---

🌸 DESCRIPTION 🌸

so the Kerberos kadmind daemon (yeah, the one from kadmind(8)) uses an Access Control List (ACL) file to manage access rights to the Kerberos database. not me being the bouncer at the club door fr fr 🫶

and for operations that affect principals, this same ACL file also controls which principals can operate on which other principals. so it's not just who gets in — it's who's allowed to mess with who once they're inside. very main character energy.

the default location of the Kerberos ACL file is /var/kerberos/krb5kdc/kadm5.acl — unless, of course, it gets overridden by the acl_file variable in kdc.conf(5). 💖

---

🦋 SYNTAX 🦋

empty lines? ignored. lines starting with the sharp sign (#)? also ignored. we love a low-maintenance queen.

lines containing ACL entries have this format:

principal  permissions  [target_principal  [restrictions] ]

Note: line order in the ACL file is important, no cap. the first matching entry will control access for an actor principal on a target principal. so don't be out here shuffling lines around like it's a playlist. 😭

• principal — a partially or fully qualified Kerberos principal name. this specifies the principal whose permissions are being set. each component of the name may be wildcarded using the * character. periodt.
• permissions — specifies what operations may or may not be performed by a principal matching a particular entry. it's a string of one or more of the following characters, or their upper-case counterparts. here's the vibe check:
  • if the character is upper-case, the operation is disallowed 🙈
  • if the character is lower-case, the operation is permitted ✨

the characters, bestie:

• a — [Dis]allows the addition of principals or policies
• c — [Dis]allows the changing of passwords for principals
• d — [Dis]allows the deletion of principals or policies
• e — [Dis]allows the extraction of principal keys
• i — [Dis]allows inquiries about principals or policies
• l — [Dis]allows the listing of all principals or policies
• m — [Dis]allows the modification of principals or policies
• p — [Dis]allows the propagation of the principal database (used in Incremental database propagation)
• s — [Dis]allows the explicit setting of the key for a principal
• x — short for admcilsp. all privileges except e
• * — same as x.

Note: the extract privilege is not included in the wildcard privilege. it must be explicitly assigned. this privilege lets the user extract keys from the database, and it must be handled with great care to avoid disclosure of important keys like those of the kadmin/* or krbtgt/* principals. the lockdown_keys principal attribute can be used to prevent key extraction from specific principals regardless of the granted privilege. 💀 seriously, be careful.

• target_principal — (optional, partially or fully qualified Kerberos principal name.) specifies the principal on which permissions may be applied. each component of the name may be wildcarded using the * character.

target_principal can also include back-references to principal, in which *number matches the corresponding wildcard in principal. cute, right? 🧚

• restrictions — (optional) a string of flags. the allowed restrictions are:
  • {+|-}flagname — the flag is forced to the indicated value. the permissible flags are the same as those for the default_principal_flags variable in kdc.conf(5).
  • -clearpolicy — policy is forced to be empty.
  • -policy pol — policy is forced to be pol.
  • -{expire, pwexpire, maxlife, maxrenewlife} time — the (getdate time string) associated value will be forced to MIN(time, requested value).

the above flags act as restrictions on any add or modify operation which is allowed due to that ACL line.

Warning: if the kadmind ACL file is modified, the kadmind daemon needs to be restarted for changes to take effect. yes, really. go restart it. don't just sit there wondering why nothing changed bestie 😭

---

👑 EXAMPLE 👑

here's an example of a kadm5.acl file:

*/admin@ATHENA.MIT.EDU    *                               # line 1
joeadmin@ATHENA.MIT.EDU   ADMCIL                          # line 2
joeadmin/*@ATHENA.MIT.EDU i   */root@ATHENA.MIT.EDU       # line 3
*/root@ATHENA.MIT.EDU     ci  *1@ATHENA.MIT.EDU           # line 4
*/root@ATHENA.MIT.EDU     l   *                           # line 5
sms@ATHENA.MIT.EDU        x   * -maxlife 9h -postdateable # line 6

let's break it down line by line, because this example ate and left no crumbs 🔥

• (line 1) any principal in the ATHENA.MIT.EDU realm with an admin instance has all administrative privileges except extracting keys.
• (lines 1-3) the user joeadmin has all permissions except extracting keys with his admin instance, joeadmin/admin@ATHENA.MIT.EDU (matches line 1). he has no permissions at all with his null instance, joeadmin@ATHENA.MIT.EDU (matches line 2). his root and other non-admin, non-null instances (e.g., extra or dbadmin) have inquire permissions with any principal that has the instance root (matches line 3).
• (line 4) any root principal in ATHENA.MIT.EDU can inquire or change the password of their null instance, but not any other null instance. (here, *1 denotes a back-reference to the component matching the first wildcard in the actor principal.)
• (line 5) any root principal in ATHENA.MIT.EDU can generate the list of principals in the database, and the list of policies in the database. this line is separate from line 4, because list permission can only be granted globally, not to specific target principals. iykyk.
• (line 6) finally, the Service Management System principal sms@ATHENA.MIT.EDU has all permissions except extracting keys, but any principal that it creates or modifies will not be able to get postdateable tickets or tickets with a life of longer than 9 hours.

---

🌈 MODULE BEHAVIOR 🌈

the ACL file can coexist with other authorization modules in release 1.16 and later, as configured in the kadm5_auth interface section of krb5.conf(5). 🫶

the ACL file will positively authorize operations according to the rules above, but will never authoritatively deny an operation — so other modules can authorize operations in addition to those authorized by the ACL file. she's supportive, not possessive.

to operate without an ACL file, set the acl_file variable in kdc.conf(5) to the empty string, like this:

acl_file = ""

---

💜 SEE ALSO 💜

• kdc.conf(5)
• kadmind(8)

---

Author: MIT

Copyright: 1985-2026, MIT

---

and that's the whole page, bestie!! 🎀✨ you just read the MIT Kerberos kadm5.acl manual, version 1.22.2, and honestly? you understood all of it. slay. go forth and write a fire ACL file, but pls pls pls restart kadmind after. mwah 💖🦋🌸