Delve into Kerberos fundamentals, exploring network security, authentication, authorization, and auditing. Gain hands-on practice in creating principals, requesting tickets, and mitigating protocol-specific attacks.

data.tar.gz

Kerberos is an essential part of any tech stack. It helps mitigate cyber attacks by providing strong authentication for client/server applications by using secret-key cryptography.

In this course, you will cover the basics of network security including: authentication, authorization, and auditing. You will also learn the fundamental concepts of Kerberos such as Key Distribution Center (KDC), Principals, and Ticketing.

Towards the end of this course, you will explore common attacks that are specific to the protocol and how Kerberos works to triage them. Lastly, you will get some hands-on practice with Kerberos where you’ll work to create a principal and request a Ticket-Granting Ticket from an Authentication Server.

By the time you’re done, you will have picked up a new in-demand skill that will allow you to better protect your data.

Kerberos for Beginners: Intro to Network Authentication Protocol

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.

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.

This lesson discusses cross-realm authentication and Multiple KDCs in a realm.

Theory

Practice

Quiz

Miscellaneous

Cross-realm authentication