3

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?

lmz
  • 379
  • 2
  • 4
  • 17

2 Answers2

7

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.

geekosaur
  • 7,025
  • 1
  • 19
  • 19
  • Agreed. I've never needed to copy keytabs around. – EEAA May 28 '11 at 05: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 05 '14 at 10:36
0

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.

Richard E. Silverman
  • 794
  • 4
  • 7