PROJECTS: Kerberos Research - Gotchas and Tips

Page last modified Mon Oct 25 07:46:17 2004

Gotcha's

• Some of the limitations of Kerberos.
• If you upgrade your MIT KDC from 1.2.X to 1.3.X, note that the default encryption type for the master key has changed. The results in the error message "Stored master key is corrupted while initializing kadmin.local interface" when trying to start kadmind or kadmin.local. You can explicitedly specify this in the kdc.conf using the master_key_type tag. Possible values are des-cbc-md5, des-cbc-crc, and des3-hmac-sha1. It is typically set to des-cbc-crc.
• If you change your hostname, you also need to change your host/ principal and update your keytab. This also applies to special keytab entries like the www/ principal used for Apache's mod_auth_kerb.
• Some distributions (RedHat in particular) don't set the permissions for ksu to be setuid root. This means that ksu doesn't work, which is annoying. Inconviently, every security or version update RedHat produces sets the permissions back to non-setuid root ... get used to changing it back manually after every update.
• When using Windows 2000 and IPsec, IPsec does not secure Kerberos traffic. Apparantly the traffic is sent before IPsec is applied. So use the application-level encryption.
• With MIT Kerberos, if you want to allow a principal to have a ticket life longer than the default 10 hours, you must modify_prinicpal to change the maxlife of both the principal in question and the krbtgt principal. Then the principal can use the -l option with kinit to request a ticket with a longer life.
• With the MIT krb5 port that is provided by FreeBSD, be sure and read the /usr/local/share/doc/krb5/README.FreeBSD file installed by the port if you want to understand why logins via telnetd and klogind behaviour somewhat oddly. Most importantly, correcting the "incorrect permissions on cache file" behaviour requires that the login.krb5 binary be used for authentication so that it can properly chown the forwarded credentials.
• All hosts in your realm must be resolvable (both forwards and reverse) in DNS (or /etc/hosts as a minimum). CNAMEs will work, but the A and PTR records must be correct and in place. The error message isn't very intuitive: "Kerberos V5 refuses authentication because Read req failed: Key table entry not found". This same error message can also result if you the [domain_realms] stanza in your krb5.conf and the host isn't in the right domain. For example, if you have a host server.example.org and your domain_realms section says that example.org = EXAMPLE.ORG but the host server is actually in realm OTHER.REALM, you'll get this error. You can override the realm for a specific host in the domain_realms section like so: server.example.org = OTHER.REALM.

Tips

• If you want to use long ticket lifetimes (a week, for example) and you are using OpenSSH to connect to the machine where you ticket is stored, make sure that KerberosTicketCleanup is set to no in your sshd_config or else your tickets will be deleted when you log out.
• Remember that host principals can have a longer ticket life as well. If your user principal has a lifetime of a week but the host you're connecting to has a lifetime of 9 hours, you'll have an expired host principal in your cache and the ticket cache won't work as expected.
• When setting up a krb5.dict file to prevent specific bad passwords from being used (the man page for kadmind covers this briefly), remember that it only applies to principals that have a password policy assigned to them. Princiapls with no password policy aren't checked against the krb5.dict file when changing their password.
• The krb5.dict files format is simple: one string per line. Creating a symlink to /usr/share/dict/words might be useful.
• You can't use cross-realm trusts with kadmind and the error message is unintuitive: kadmin: Client/server realm mismatch in initial ticket request while initializing kadmin interface. Use the -p option with kadmin and specify a principal in the other realm that you have the password for. Seethis thread for details.

When do you need a keytab and when don't you?

This was taken from a post by Jeffrey Hutzelman to the MIT Kerberos mailing list on April 12, 2004.

First, try to think of clients and servers as processes, not machines.
Several processes may be running on the same machine in both roles.

In any Kerberos authentication exchange, both entities involved (client and
server) share a key with the KDC.  For the most part, when the entity is a
human, that key is derived from a password the human types.  When the
entity is a daemon, the key is normally read from a keytab.

So, telnetd or sshd is going to read its key from a keytab.  On the other
hand, kinit is going to read a password from the user, and turn it into a
key; in this case, a keytab is not needed.  However, an automated process
that needs to access a Kerberos-authenticated service (for example, a cron
job that needs to scp something from a remote machine or write to a file in
AFS) will generally obtain Kerberos tickets using a key stored in a keytab,
even though it is acting as a client.

Then there's the login program.  A Kerberos-aware login generally acts as
both a client and server in the same process.  It accepts a username and
password from a user, and uses them to obtain a TGT, just as kinit does.
It then uses that TGT to obtain a service ticket for the login service
(generally host/fully.qualified.host.name), and verifies the resulting
service ticket against the service key, which is obtained from a keytab.

This step is essential to preventing unauthorized logins by an attacker who
is cooperating with the operator of a bogus KDC.  Since the attacker and
bogus KDC operator both know the password that will be typed, they could
together trick a host into allowing a login, unless the host validates the
obtained TGT against a service whose key is known only to it and to the
real KDC.

Explanations for weird things

• If you run a packet sniffer like tcpdump on your KDC and then run kinit from a kerberized workstation, you'll notice that your TGT is sent imemdiately upon running kinit -- even before you type your password! The explanation is that the Kerberos server freely transmits a TGT to any unauthorized request ... however, every TGT is encrypted in a key derived from the user's password. Therefore, when a user types their password it isn't being sent to the KDC, it's being used to decrypt the TGT that kinit already obtained. If the decryption process results in a valid ticket with a valid time stamp, the user has valid Kerberos credentials. These credentials include a session key for establishing secure communications with the Kerberos server in the future, as well as the actual ticket-granting ticket, which is actually encrypted with the Kerberos server's own key. This second layer of encryption is unknown to the user, but it's what allows the Kerberos server to verify the authenticity of each TGT.