KADMIND(8)

💅 KADMIND 💅

okay bestie, so this is kadmind(8) — the KADM5 administration server page from MIT Kerberos. it's giving "the backbone of your whole Kerberos setup" and honestly you're gonna want to read the whole thing. no skipping. 💖

---

✨ SYNOPSIS ✨

kadmind [-x db_args] [-r realm] [-m] [-nofork] [-proponly] [-port
port-number] [-P pid_file] [-p kdb5_util_path] [-K kprop_path] [-k
kprop_port] [-F dump_file]

---

🌸 DESCRIPTION 🌸

so kadmind starts the Kerberos administration server. periodt. it typically runs on the primary Kerberos server, aka the one that stores the KDC database. but listen — if the KDC database uses the LDAP module, the administration server and the KDC server do not need to run on the same machine. slay, flexible.

kadmind accepts remote requests from programs like kadmin and kpasswd to administer the information in these database. yes bestie, it's literally the main character that everything else talks to.

kadmind requires a number of configuration files to be set up in order for it to work:

🎀 the config files

• kdc.conf — the KDC configuration file contains configuration information for the KDC and admin servers. kadmind uses settings in this file to locate the Kerberos database, and is also affected by the acl_file, dict_file, kadmind_port, and iprop-related settings. lowkey it's a whole vibe check for the server.
• kadm5.acl — kadmind's ACL (access control list) tells it which principals are allowed to perform administration actions. the pathname to the ACL file can be specified with the acl_file kdc.conf variable; by default, it is /var/kerberos/krb5kdc/kadm5.acl. write that down bestie, it's iconic. ✨

---

after the server begins running, it puts itself in the background and disassociates itself from its controlling terminal. main character energy: it simply leaves. 🙈

kadmind can be configured for incremental database propagation. incremental propagation allows replica KDC servers to receive principal and policy updates incrementally instead of receiving full dumps of the database. this facility can be enabled in the kdc.conf file with the iprop_enable option. incremental propagation requires the principal kiprop/PRIMARY\@REALM (where PRIMARY is the primary KDC's canonical host name, and REALM the realm name). and in release 1.13, this principal is automatically created and registered into the datebase. (yes, the manpage says "datebase." i'm not fixing it, i don't gatekeep, i just report. 💀)

---

✨ OPTIONS ✨

• -r realm — specifies the realm that kadmind will serve; if it is not specified, the default realm of the host is used.
• -m — causes the master database password to be fetched from the keyboard (before the server puts itself in the background, if not invoked with the -nofork option) rather than from a file on disk.
• -nofork — causes the server to remain in the foreground and remain associated to the terminal. no disappearing act, it stays right here with you. 🫶
• -proponly — causes the server to only listen and respond to Kerberos replica incremental propagation polling requests. this option can be used to set up a hierarchical propagation topology where a replica KDC provides incremental updates to other Kerberos replicas. cute little chain of command, honestly.
• -port port-number — specifies the port on which the administration server listens for connections. the default port is determined by the kadmind_port configuration variable in kdc.conf.
• -P pid_file — specifies the file to which the PID of kadmind process should be written after it starts up. this file can be used to identify whether kadmind is still running and to allow init scripts to stop the correct process. tracker for your fave. 🎀
• -p kdb5_util_path — specifies the path to the kdb5_util command to use when dumping the KDB in response to full resync requests when iprop is enabled.
• -K kprop_path — specifies the path to the kprop command to use to send full dumps to replicas in response to full resync requests.
• -k kprop_port — specifies the port by which the kprop process that is spawned by kadmind connects to the replica kpropd, in order to transfer the dump file during an iprop full resync request.
• -F dump_file — specifies the file path to be used for dumping the KDB in response to full resync requests when iprop is enabled.
• -x db_args — specifies database-specific arguments. see Database Options in kadmin for supported arguments.

---

🦋 ENVIRONMENT 🦋

see kerberos for a description of Kerberos environment variables.

as of release 1.22, kadmind supports systemd socket activation via the LISTEN_PID and LISTEN_FDS environment variables. sockets provided by the caller must correspond to configured listener addresses (via the kadmind_listen or kpasswd_listen variables or equivalents) or they will be ignored. any configured listener addresses that do not correspond to caller-provided sockets will be ignored if socket activation is used.

ngl bestie, read that one twice. mismatch = ignored, both directions. the sockets have to actually match up or nothing happens. 💀

---

🌈 SEE ALSO 🌈

• kpasswd
• kadmin
• kdb5_util
• kdb5_ldap_util
• kadm5.acl
• kerberos

go read them, seriously, they're all part of the same little universe. 🪐

---

👑 Author 👑

MIT

💜 Copyright 💜

1985-2026, MIT

---

okay that's the whole page bestie, you ate that. this was KADMIND(8) from MIT Kerberos, version 1.22.2 — go forth and administer, mwah 💋✨🍓