In diesem Artikel wollen wir uns dem Thema Kerberos widmen und warum man das Kennwort des dazugehörigen KRBTGT-Accounts regelmäßig ändern sollte.
Fangen wir damit da zu erläutern, was Kerberos überhaupt ist und wie es funktioniert und…
…Nein! Kerberos ist nicht der 3-köpfige Hund aus griechischen Mythologie, der das Tor zu Unterwelt bewachen soll! Jedenfalls nicht im Bezug auf die Themen die wir auf diesem Blog anbieten.
Kerberos ist ein Protokoll, um sich innerhalb eines Netzwerkes zu authentifizieren und somit den Zugriff auf bestimmte Ressourcen zu erhalten. In diesem Vorgang werden sogenannte Tickets ausgestellt, die es einem Benutzer erlauben, auf die benötigten Daten zuzugreifen.
Jeder Domänencontroller innerhalb eines Active Directory führt einen KDC-Dienst (Kerberos Distribution Center) aus, der für die Bearbeitung der Ticketanfragen genutzt wird. Das KDC wiederum nutzt das oben erwähnte KRBTGT-Konto (zu finden unter der „Users“-Organisationseinheit in der Active Directory Struktur) um die auszustellenden Tickets zu signieren. Es ist quasi die Unterschrift auf dem Ticket, um die Gültigkeit zu gewährleisten. Alle Domänencontroller in der Domäne nutzen das gleiche KRBTGT-Konto, sodass die Tickets in der gesamten Domäne und von jedem DC überprüft und als validiert angesehen werden. Ein Ausnahme bilde da nur die sogenannten RODC’s (Read Only Domain Controller), da diese jeweils ihren eigenen KRBTGT-Account besitzen.
Wie funktioniert eine Ticketanforderung?
Der genaue technische Ablauf der Ticketanforderung eines Benutzer oder Computers ist sehr komplex. Dort geht es insbesondere um diverse Schlüssel und zugehörige Ver- und Entschlüsselungsverfahren, die auf den getauschten bzw. Client und Server bekannten Schlüsseln basieren. Daher werden wir hier die Kurzfassung darstellen, um den Ablauf einer Anforderung zu erläutern.
Die einzelnen Schritte nochmal etwas genauer erläutert:
- Der Benutzer meldet sich mit seinen Anmeldedaten an. Er möchte gerne Zugriff auf eine Ressource. Dafür fragt er beim KDC nach einem TGT (Ticket Granting Ticket). Die Anfrage ist verschlüsselt und kann vom Domänencontroller mit den ihm bekannten in der Ntds.dit gespeicherten Schlüsseln für den Client entschlüsseln.
- Wenn der KDC die Anfrage entschlüsseln kann, da der Antragssteller bekannt ist, wird diesem nun das TGT ausgestellt. Dieses Ticket ist im Normalfall 10 Stunden gültig.
- Nun schickt der Client eine Anfrage an den TGS, zusammen mit Informationen zum Ziel (Name, Domäne, SPN, Dienst). Diese Anfrage ist ebenfalls wieder mit einem Schlüssel versehen.
- Der KDC erhält nun die Anfrage und überprüft, ob er die Anfrage entschlüsseln kann (auch hier werden wieder Key aus den bereits generierten Informationen genutzt), stellt er für den Client und die angeforderte Ressource das passende Service Ticket aus.
- Mit dem erhaltenen Service Ticket, kann der Client den Zugriff auf die angeforderte Ressource, in unserem Fall den Fileserver, anfordern. Der Zielserver kann das erhaltenen Paket nun mit seinen bekannten Schlüsseln entpacken und erhält somit den Service Ticket sowie den sogenannten Session Key der ebenfalls mit getauscht wird.
- Mit den ihm nun bekannten Informationen ist der Client auch auf dem Fileserver berechtigt und eine Verbindung zwischen den beiden wird aufgebaut.
Sowohl TGS als auch Service Tickets besitzen einen Gültigkeitsreitraum. Das bedeutet, einmal ausgestellt, werden keine Kennwörter mehr über das Netz verschickt, solange das Ticket noch gültig ist. Das ist einer der großen Sicherheitsvorteile von Kerberos.
Kleiner Tipp am Ende:
Einer der Verschlüsselungsattribute ist die Uhrzeit der Systeme. Laufen die Systeme mehr als 5 Minuten auseinander, kann der KDC die Anforderung des Clients nicht mehr entschlüsseln. Dies führt dazu, dass eine Authentifizierung und somit der Austausch der Tickets nicht mehr möglich ist. Also, sollte eine Anmeldung oder der Zugriff auf eine Ressource nicht funktionieren, schaut ob die Zeiten auf beiden Systemen synchron laufen.