The kerberos keytab file used for in UNIX/AD kerberos authentication

authenticationkerberosunix

I have proved that UNIX/AD Kerberos authentication works without the presence of a keytab file so I'd like to know whether I should worry about it (given I'll need an individual keytab for each server I want to provide AD authentication services on).

Best Answer

The primary use of the local keytab during local authentication is to protect against KDC spoofing.

Kerberos login authentication works by requesting a TGT from the Kerberos KDC and then decrypting it with a key formed from the password entered locally. If that decryption works, the login is considered successful (if there's no keytab). The problem with this approach is that the attacker could be simultaneously spoofing the KDC reply with a TGT encrypted in the password the attacker chose. If the system gets that reply before the real reply, it will happily decrypt it with the attacker's password and then consider the authentication successful. This is fairly easy to do if one has a system on the same local network, given that Kerberos is a UDP protocol.

If there is a local keytab, the login process takes one more step: it asks the KDC for a service ticket for the principal stored in the local keytab, and then validates that ticket by decrypting it with the key in the keytab. The attacker's KDC has no knowledge of the private key of the keytab on the system, and therefore will fail this step. (This means, of course, that the system keytab needs to be locked down to only be accessible by root, since anyone who can access the keytab can still successfully attack the system.)

(Qualifications: I'm the author of the Kerberos PAM module used in Debian and Ubuntu.)

Related Solutions

Linux – Copying a large directory tree locally? cp or rsync

I would use rsync as it means that if it is interrupted for any reason, then you can restart it easily with very little cost. And being rsync, it can even restart part way through a large file. As others mention, it can exclude files easily. The simplest way to preserve most things is to use the -a flag – ‘archive.’ So:

rsync -a source dest

Although UID/GID and symlinks are preserved by -a (see -lpgo), your question implies you might want a full copy of the filesystem information; and -a doesn't include hard-links, extended attributes, or ACLs (on Linux) or the above nor resource forks (on OS X.) Thus, for a robust copy of a filesystem, you'll need to include those flags:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

The default cp will start again, though the -u flag will "copy only when the SOURCE file is newer than the destination file or when the destination file is missing". And the -a (archive) flag will be recursive, not recopy files if you have to restart and preserve permissions. So:

cp -au source dest

Linux – Squid/Kerberos authentication with only Linux

This seemed familiar and Google searching brought me back to ServerFault. Long story short, Micros*** extends Kerberos in a way that makes client authentication with alternative Kerberos implementations (e.g. MIT or Heimdal) not easily accomplished. This is why projects like pGina were created. That might be primarily for LDAP auth, but the cause will lead to you needing a similar result, namely coding your own custom GINA DLL to handle that kind of auth. If you find one that handles Kerberos, please let us know! I would be super-excited to use it and find out.

Best Answer

Related Solutions

Linux – Copying a large directory tree locally? cp or rsync

Linux – Squid/Kerberos authentication with only Linux

Related Topic