All Kerberos administration commands are run from a special shell, called Kadmin. There are two variants of Kadmin. Kadmin is the usual, remote version of the command which can be run on any machine and requires username and password to connect to the Kerberos admin server. Kadmin.local is the "local" version which can only be ran on the Kerberos KDC machines. (Although it only makes sense running it on Kerberos master server, as any database changes on the slaves will be lost on next update from the master server).
Invoke kadmin.local as sudo kadmin.local -p YOURUSERNAME_admin. It is good to include "-p YOURUSERNAME_admin", or kadmin will "authenticate" as the first user it finds in the ticket cache, which may or may not be the username you expected. All the administrative commands would work anyway (since you ran kadmin.local), but an incorrect principal name would make various statistics incorrect (like name of principal who was adding/changing entries in the DB), reducing logs "meaningfullity". (I want bonus points for this word).
To invoke kadmin, use kadmin -p YOURUSERNAME_admin. In normal course of action, kadmin asks for a password.
Providing a password is impractical for automated scripts. As usual, instead of a password, you can also pass a keytab file. Our keytabs are saved in /etc/keytabs/ on each system, and they are readable by group 'wheel'. So administrators should be able to invoke 'kadmin' (use control shell) or kinit/k5start (impersonate any user) by supplying target user's key from a keytab, such as kadmin -p domtool -k -t /etc/keytabs/domtool.
However, domtool and a couple other keytabs are special cases. One can only obtain the user's $USER.daemon token, which has access to assorted user's read and write directories. There is no way to authenticate as $USER by means other than providing a password. (Strictly speaking, Krb/AFS admins can do it, but others cannot, not even from the Unix root account).