Miscellaneous

Let’s briefly discuss the various capabilities and features of Kerberos that are important, but beyond the scope of an introductory text on the subject.

Cross-realm authentication

Kerberos allows users in one realm to authenticate themselves to entities in a different realm. Cross-realm trust describes situations when clients (typically users) of one realm use Kerberos to authenticate to services (e.g., server processes) that belong to another realm. This feature is known as cross-realm authentication. In order for a KDC in one realm to authenticate Kerberos users in a different realm, it must share a key with the KDC in the other realm. In databases of both the KDCs, there must be krbtgt service principals for realms. These principals should all have the same passwords, key version numbers, and encryption types. For example, if the administrators of DATAJEK.IO and EDUCATIVE.IO wanted to authenticate across their realms, then each of them would need to create the two service principals krbtgt/EDUCATIVE.IO@DATAJEK.IO and krbtgt/DATAJEK.IO@EDUCATIVE.IO in their databases. Cross-realm authentication is beyond the scope of this text, but it is important that the reader is cognizant of the existence of this feature.

Multiple KDCs

Having a single KDC in a realm makes the entire authentication system prone to a single point of failure. Additionally, a single KDC can be overwhelmed by the sheer number of requests it has and is capped by the available compute/storage resources on the machine the KDC runs on. To mitigate these issues, multiple clones of the KDC can run simultaneously in a network. One of the clones is designated as the master KDC and the rest as slave KDCs. Having multiple slave KDCs alongside a master KDC ensures continued availability of Kerberized services in case of failures. Each KDC contains a copy of the Kerberos database. The master KDC contains the writable copy of the realm database, which it replicates to the slave KDCs at regular intervals. All database changes (such as password changes) are made on the master KDC. Slave KDCs provide Kerberos ticket-granting services when the master KDC is unavailable, but not database administration. KDCs can be configured to function as either the master KDC or as one of the slave KDCs.