Local Duke Kerberos Infrastructure

Our Local Realm

An authentication domain in the Kerberos world is referred to as a realm. Here at Duke (largely for historical reasons) our Kerberos IV/V authentication realm is known as ACPUB.DUKE.EDU. Hence, for example, a user with the Kerberos principal "rob" and no Kerberos instance would have the fully qualified name "rob@ACPUB.DUKE.EDU".

Kerberos IV and Kerberos V differ in a number of important ways, as well as in a number of unimportant ways. One of the unimportant differences is the internal notation used by Kerberos utilities for indicating instances -- the "role" mechanism, if you will, associated with Kerberos since its inception. In the Kerberos IV world, instances are separated from their principals by dots - "." - while in the Kerberos V world, they're separated from their prinicpals by slashes - "/". Hence, a user named "rob" in our local realm with an instance "admin" would, in the Kerberos IV world be denoted by rob.admin@ACPUB.DUKE.EDU, while in the Kerberos V world, we would write rob/admin@ACPUB.DUKE.EDU. This notational difference is significant, but essentially cosmetic.

Our Infrastructure Layout

The ACPUB.DUKE.EDU realm is currently suported by a set of three primary KDCs. All are running the MIT version of Kerberos V at the moment (krb5-1.2.x). While the underlying machines change from time to time as we bring on newer and faster hardware to cope with increasing traffic, we maintain three primary CNAME records in our DNS tables in support of the three KDCs -- kaserv1.acpub.duke.edu, kaserv2.acpub.duke.edu, and kaserv3.acpub.duke.edu.

In the MIT Kerberos model, one KDC is designated as the "master" KDC, and its database is periodically propagated to the other "slave" KDCs via a built-in encrypted propagation protocol (kprop). The "master" KDC is the only KDC which can accept administrative commands via the "kadmin" protocol, and is the only KDC which can actually perform changes (principal/instance creations and deletions, key changes, etc.). In our case, for simplicity, we make kaserv1.acpub.duke.edu always point to the current "master" KDC.

Currently, our KDCs (Kerberos Key Distribution Centers) hold roughly 73,000 keys for individual users, services, and systems using the ACPUB.DUKE.EDU realm. Of those, roughly 8,000 are "locked principals" (which simply means that the KDCs have been told not to issue tickets on them). Of those, roughly 2/3 are for user-specific principals or principal instance pairs, and the rest are either service or system-related keys.

We maintain a set of special-purpose slave KDCs, as well, targeted for specific applications' use. Our primary LDAP servers both run slave KDCs in support of high-volume authentication traffic through the locally-written PAM LDAP plugin we use to handle LDAP bind operations. Similarly, one of the three campus Webauth servers runs a slave KDC in support of the high volume of authentication traffic coming from the three Webauth servers. On a typical day, our three main KDCs will handle between 800,000 and 1.1 million Ticket Granting Ticket requests, and roughly three times that many individual service ticket requests. On an extremely busy day, the total number of ticket requests handled can approach 4.5 million. Typical transit-times for ticket requests average around 0.8 seconds.

Kerberos Clients on Campus

Our Kerberos infrastructure supports a wide array of applications and systems across campus. Some of the more intersting ones include: