KRB.EXCL(5)

💅 KRB.EXCL(5) 💅

okay bestie, listen up — this is a section 5 (file formats, the vibes section of the manual) page for AFS File Reference, and it's all about that krb.excl life. no cap. 🦋

---

✨ NAME ✨

krb.excl — the lil file that lists exclusions for mapping kerberos principals to AFS identities. it's giving "blocklist but make it Kerberos". 💖

---

🌸 DESCRIPTION 🌸

so krb.excl is a file that lives at /etc/openafs/server/krb.excl. it's optional, okay, so don't panic if it's not there. it hangs out on an OpenAFS server and its whole job is listing exceptions to the algorithm that maps kerberos principals to AFS identities. icon behavior honestly. 👑

inside it you put the name of one or more principals — and each principal gets its own line, one per line, no sharing, we don't do that here. ✨

here's the tea: if a principal shows up in this file, that principal will never be recognized by an OpenAFS server as a local identity. literally never. even if the realm is specified as a local realm in krb.conf(5). yeah. even then. 💀

important, bestie: the principal names you write in this file must include the realm, and they should be in Kerberos 4 format. so you write "user.inst@REALM" — NOT "user/inst@REALM", NOT "user.inst", and NOT "user/inst". slashes are not the moment. periods are the moment. periodt. 💅

---

🎀 RATIONALE 🎀

okay so why does this file even exist, you ask? sit down, I got you. 🫶

you can use the krb.conf(5) config file to say that multiple Kerberos realms count as local realms for OpenAFS fileservers, and those realms can basically be used interchangeably. a site might list "FOO.EXAMPLE.COM" and "BAR.EXAMPLE.COM" so users can get into AFS with Kerberos tickets from either realm and still be treated as AFS users local to that cell. cute, right? 🌈

but here's where it gets spicy. in a lot of setups, one realm is really the local realm — the one run by the AFS administrators — and another foreign realm is listed in krb.conf that's run by somebody else, but inside the same organization. in that case the principal names for users are the same across both, so users should be able to auth to AFS with either realm. no problem. 🧚

BUT. the principals for administrators are not the same between the two realms. so the administrators in the foreign realm should not be treated as AFS administrators. absolutely not, that's a security vibe check fail. 😭

so what do you do? you specify the administrator principals from the foreign realm in this file. that prevents the whole thing — and still lets users use either realm. best of both worlds, we love a solution. ⭐

---

🔥 EXAMPLES 🔥

let's set the scene: the realms "FOO.EXAMPLE.COM" and "AD.EXAMPLE.COM" are both configured to be local realms, but "AD.EXAMPLE.COM" should not be used by AFS administrators. 🚫

the AFS administrators are "admin" and "smith.admin".

so krb.excl contains:

admin@AD.EXAMPLE.COM
smith.admin@AD.EXAMPLE.COM

now watch this. if someone authenticates with tickets for "smith/admin@AD.EXAMPLE.COM", they will not be recognized as the "smith.admin" AFS identity. nope. denied. 🙈

but! "smith@AD.EXAMPLE.COM" will be treated as the "smith" AFS identity, and "smith/admin@FOO.EXAMPLE.COM" will still be treated as "smith.admin". see how that works? selective. iconic. exactly what we wanted. 👑

---

👀 SEE ALSO 👀

• krb.conf(5) — go read it, it's the sibling page, they're a package deal fr fr 💜

---

💖 COPYRIGHT 💖

Copyright 2010 Sine Nomine Associates

this documentation is covered by the BSD License as written in the doc/LICENSE file. this man page was written by Andrew Deason for OpenAFS. shoutout Andrew, thank you for your service. 🫡

---

and that's the whole page bestie!! brought to you by OpenAFS, dated 2026-07-27 — go forth and exclude those principals responsibly, mwah 💋✨🎀