Kerberos in Leopard: The Local KDC part 1

The Local KDC and why it shouldn't make you run in fear.

Leopard brings a brand new and much misunderstood invention to Mac OS X. Every client, and server, will create, maintain and use it's own instance of a Kerberos Key Distribution Center. All users on the system will be given Local KDC principals in addition to whatever other form of password store they would have otherwise received.

Crazy?

Maybe.

Brilliant?

Most certainly.

Read on for why this really shouldn't scare the living crap out of you...

What is this crazy thing?

In order to better secure peer-to-peer communication, and this isn't the "dirty" kind of P2P but just any connection not using a centralized directory service, Apple has added a local KDC to every install of Leopard.

This was a rather bold move on the behalf of Apple, as Kerberos has often times been seen as the work of the owner of the 3-headed dog which Kerberos uses as it's logo. Regardless of the perception of amazing complexity though, Kerberos is widely considered a very secure method of authentication. Both Open Directory and Active Directory heavily leverage Kerberos to not only ensure a secure channel for authentication but to also provide a mechanism for single-sign-on to the user.

And that is exactly what the LKDC provides. A method of secure authentication with the additional gravy of a single sign-on environment.

Local Only

The first piece to understand is that the concept of the LKDC isn't just an Apple construct. While Apple seems to have driven the creation of the beast, the functionality, or at least the basics of it, has been rolled back into the MIT Kerberos distribution. Will other vendors use the functionality... that's yet to be determined.

You can recognize a LKDC because the Kerberos realm will start with LKDC: followed by a SHA1 hash or the KDC's public certificate that essentially acts as a unique identifier. No "real" realm is going to start with LKDC: so there should be no confusion between local and managed Kerberos environments.

By definition the LKDC only can encompass one machine. There are no member servers. The KDC and the kadmin servers are one in the same. There is no redundancy and there are no trusts or any relationships between an LKDC and any other, local or not, Kerberos realm.

Because of this you'll find no edu.mit.kerberos file, or krb5.conf file for you non-OS X folk, that references the LKDC. The beauty of the entire instance of the LKDC living on the same server means that you don't need one. If you talk to a system that proclaims to be from an LKDC, by definition you know that the KDC, the kadmin interface and all member services are on that one specific machine. By the mere fact that you've initiated a connection to that server, you now know everything you could ever need to know about the Kerberos realm that the LKDC hosts.

Realms Apart

The other piece of magic that had to occur is for the client system to not completely freak out over the seriously massive amount of Kerberos realms that it now might encounter. Take the example of a larger Enterprise organization. It might have 5000 Mac OS X systems in it. This means that there will be 5000 LKDCs present on the network. If you've worked with Kerberos prior to the LKDC this is a staggering thought. Enough to make the blood of even the most hardened Kerberos admins run cold.

In 10.5 it is perfectly normal, and quite expected, for a client system to acquire and use a multitude of TGTs. Under "old skool" Kerberos you got one TGT when you logged in and you used this for all of your single sign on activities. If you were crazy enough to have multiple Kerberos realms that didn't have trusts between them you could get yourself another TGT to access resources in that secondary realm. However, you would have to manually switch between the two TGTs depending on what resource you wanted to access next.

Now with Leopard the system should be able to use any TGT you currently have to access a service. Well behaved systems on the client will attempt to acquire a service ticket with every TGT you have until it gets one that works. Yes, there's more traffic going across the wire here, but no, the user is not really inconvenienced by this.

For Leopard Apple introduced the NetAuthAgent which you'll find squirreled away in /System/Library/CoreServices. This works as an authentication agent for services. For example, in Leopard when you connect to an AFP share, the AFP client now hands over the task of figuring out the whole Kerberos "problem" to the NetAuthAgent. The agent will figure out the realm as best it can. Some services, specifically AFP can negotiate the realm to use when negotiating the authentication mechanisms that are available. AFP is very much the anomaly here. For the rest of the services the NetAuthAgent will just iterate through the list of TGTs that a user already has and attempt to get a service ticket for the remote server.

If we go back to our large example, this means that it should not only be possible, but even expected, that a Leopard client system could have 5000 TGTs for a user at any one time. While it may take a bit longer to get a service ticket for a particular service in this case, it would still be quicker than the user typing in a password, and much less of a bother.

LKDC Creation

The LKDC is created when a machine is configured with the inital admin user.

The KDC bits and pieces are stored in the usual place, /var/db/krb5kdc. In this location you'll notice all the trappings of a KDC with all of it referring to an LKDC: realm. In particular the kdc.conf file lists out all the particulars of the LKDC. You'll note that there is a keypair presumably for the LKDC stashed away in the System keychain, however from reading the config file it seems that there's no correlation between the keypair and the LKDC. Perhaps this is being reserved for future functionality.

If you are an OD Master, it's perfectly reasonable to expect the ODM to have both a LKDC and a "real" or managed realm associated with it. You'll notice 2 KDC processes running on your system and 2 KDC databases in /var/db/krb5kdc.

The presence of an LKDC can be problematic when imaging systems from a Holy Mac that's already been booted. In this case, it's best to remove the LKDC database and config files and then recreate them after the machine has been deployed using the configureLocalKDC command.

Still to Discuss...

This covers the basic concepts of the LKDC, but not the actual use and abuse thereof. We'll discuss that when we get around to writing a follow up to this.