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
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:
- 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
- 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
- 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.