Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Kerberos HOWTOs often have words similar to these:

Securely transfer (via flash drive, disk, or encrypted connection) the keytab to the client host.

Is logging in on the client host as root, running kinit to get credentials for an administrative account, and running kadmin from the client not good enough?

share|improve this question
up vote 7 down vote accepted

I think that's mostly a holdover from older MIT Kerberos releases which did have either security issues or lower functionality (kadmin in network mode used to not be able to do a number of things; you had to run kadmin.local on the master KDC). Certainly Heimdal never bothered with any such restriction and in fact simplified and optimized the process a bit (ktutil get). Also, much of the official MIT Kerberos documentation assumes a lot of paranoia that I've rarely seen in actual use anywhere, such as assuming that any security credential was always manually copied from system to system.

share|improve this answer
Agreed. I've never needed to copy keytabs around. – EEAA May 28 '11 at 5:07
MIT Kerberos was designed to operate over public networks with the assumption that every host and network link was potentially hostile. This is why they seem excessively paranoid. – Michael Hampton Mar 5 '14 at 10:36

Also related is the MIT "ktadd problem." The MIT kadmin ktadd command does not extract keys from the KDC; rather, it generates new keys, writes them into the keytab, then replaces the keys for the principal in the KDC. Only kadmin.local has the ability to extract keys; the kadmin RPC interface simply will not return them. This is touted as a security feature, preventing a compromised kadmin account from reading out everyone's keys. The problem is that this means that a single errant ktadd command will break a running service: if it doesn't update the right keytab, the KDC immediately starts issuing tickets with new keys the service doesn't have. If you have multiple servers for the same service (say behind a load balancer), you can't just go to them one after another and use ktadd to create or update their keytabs: each time you run it, you change the keys and break all the other service instances. You have to create the keytab once and then distribute it separately (e.g. with scp).

The operational hazard of this security feature is so dire that years ago I hacked our MIT KDC to add key extraction to the RPC protocol and make it the default for our ktadd command. Heimdal doesn't have this issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.