Local Duke Kerberos Infrastructure

Our Local Realm

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

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

• SAP R/3: SAP R/3 has been using our Kerberos infrastructure since its initial roll-out a few years ago, and continues to be one of the most critical applications we have dependent upon the infrastructure. While it doesn't account for much in the way of actual authentication traffic, it does have some very high-profile users, and since R/3 is used within the Medical Center for patient-care-critical tasks (nurses in the MC, for example, use the local R/3 infrastructure to requisition materials from the Hospital's central warehouse).
• PeopleSoft 8: PS8 is one of the larger users of the LDAP/Kerberos authentication proxying mechanism. Administrative users and faculty who authenticate via STORM or who work directly with the PS8 back-end all authenticate via our Kerberos authentication infrastructure.
• IMAP/POP/SMTP: The central campus postoffices, as well as the campus SMTP servers (smtp.duke.edu) all perform their authentication via SASL libraries which ultimately use our Kerberos infrastructure to authenticate users. Depending on the clients used and their configuration, some authentications are performed at the server-end (with a user passing a password to the server and the server acquiring credentials on the user's behalf in order to validate the password) while some are performed at the client-end, with authentication to the postoffices performed via GSS-API.
• Webauth Clients: The primary authentication mechanisms made available thorugh our Webauth infrastructure are all Kerberos methods built on our existing Kerberos authentication infrastructure. Numerous applications authenticate via our Webauth infrastructure, including ACES Web, Blackboard, our IMP-based webmail facility, and the Online@Duke online self-service application.
• AFS: Our primary AFS cell (the acpub.duke.edu AFS cell) authenticates its users via the campus Kerberos realm. All access to data in the AFS cell (data under /afs/acpub.duke.edu) is authenticated via our local Kerberos realm.
• Lab Systems: The public labs on campus (Solaris, Linux, MacOS and Windows) all perform initial user authentication via our local Kerberos realm. A number of related systems, both within the "acpub.duke.edu" domain and elsewhere, also take advantage of the central authentication infrastructure. Increasingly, we're seeing Windows systems across campus take advantage of the built-in K5 authentication support available for Windows 2000 and later versions, either via direct interaction with the nascent Active Directory environment OIT is testing (which uses inter-realm trust to support authentication through our local Kerberos realm) or via direct interaction with the main KDCs.