Exploring Leopard’s Local KDC

I recently had an excuse to dig into Leopard’s local KDC (LKDC), and have created a page on my wiki to hold the results. Some excerpts below:

The Local KDC (LKDC) is a Kerberos implementation that extends “single sign-on” capabilities into ad-hoc networks. The LKDC supports the AFP, CIFS, and VNC services included in Mac OS X and Mac OS X Server. At the surface, the LKDC looks pretty much just like a regular Kerberos setup… you can log into one of the above named services and get Kerberos tickets, use standard tools like klist to manage tickets, use kadmin to administer the KDC, etc, etc.

The crux of the LKDC implementation is the use of a SHA1 hash in place of the server name portion of a kerberos principal, effectively insulating Kerberos from dynamic network conditions. This significant re-definition of a kerberos principal is really cool, but also not standard. The standard kerberos libraries pretty much assume and require that the server name portion of a kerberos principal be just that: a server name (or IP address).

This presents two primary challenges:
* Advertising and discovering LKDC realm information in an ad-hoc, peer to peer context
* Harnessing the authentication process to construct the special kerberos principal and then handing it off to Kerberos

The mechanism used to advertise and discover LKDC information is multicast DNS, as it is very well suited to ad-hoc networks. In other more standard Kerberos deployments, it it not unusual to use DNS to discover Kerberos information in the absence of local configuration (see references at the bottom of the page), but with standard kerberos, the discovery is limited to realm name or KDC name.

The notion of using a unique hash as the sever name portion of the principal name is a new idea, so we cannot rely on standard Kerberos libraries to be able to construct the correct principal name based on the LKDC’s realm name. Accordingly, the authentication process is brokered for supported service clients, in order to perform the LKDC realm name discovery and then construct a kerberos principal name that is correct for the remote LKDC. Once the correct service principal name is obtained, it is handed off to Kerberos and works normally.

The client-side authentication broker (for supported services!) is called NetAuthAgent, and you’ll see it get fired up whenever you use vnc, afp, cifs. Think of this as a session manager, of sorts.

Most of the advertisement, discovery, and management functions involving the LKDC are provided by a private framework called KerberosHelper, and a Kerberos framework plugin called LKDCLocate.

Check the LKDC wiki page for more details.