Heimdal- versus MIT-Kerberos

Neben der bereits mehrfach erwähnten schwedischen Kerberos-Implementierung genannt "`Heimdal"' gibt es eine zweite am amerikanischen Massachusetts Institute of Technology beheimatete Implementierung, welche auf [MIT05] gefunden werden kann.
Die beiden frei zugänglichen Kerberos-Implementierungen, die als externes Kerberos-System zum Einsatz kommen könnten, unterscheiden sich einerseits in der Liste und Implementierung der unterstützten Schlüsseltypen, aber auch in der Behandlung der Anfragen.
Auf den erstgenannten Umstand soll hier nur verwiesen werden, da keine umfangreichen Tests mit der MIT-Implementierung stattgefunden haben, insbesondere die ARC4-Verschlüsselung wurde nicht auf Kompatibilität mit der Microsoft-Implementierung hin untersucht. Allerdings machte die Unterscheidung bei der Behandlung der Anfragen einen Test beider Implementierungen interessant.

Beim Betrieb einer Subdomäne stellte sich im Rahmen der Versuche heraus, dass entgegen den Beschreibungen aus den Quellen [Mic05] der University of Michigan und [Alb05] der kanadischen University of Alberta nicht einem Trust-Path über die Root-Domain gefolgt wird. Bestand ein Realm-Trust zwischen Heimdal und der Subdomäne wurde direkt nach dem Authentifizierungsschritt durch den externen Heimdal-Kerberos an den Domaincontroller der Subdomäne verwiesen. Dieser kann auch das Service-Ticket für den Client-Rechner bereitstellen. Allerdings wird im Folgeschritt versucht, einen Domainenbenutzer zu finden, der dem Prinzipal des externen Kerberos entspricht. Ist dieser vorhanden, kann der Nutzer mit den Berechtigungen dieses Domainbenutzerobjektes angemeldet werden. Ziel der Aufgabenstellung ist allerdings eine zentrale Nutzerverwaltung, in der die Nutzer an nur einer Stelle verwaltet werden sollen. Auch ist eine Einschränkung des Zugriffs auf personenbezogene Daten auf einen überschaubaren Personenkreis zu beachten.
Entsprechend der oben genannten Quellen sei eine Bereitstellung der Nutzer im Active Directory der Root-Domaine ausreichend, da der Prinzipal mit dem ersten Vorkommen eines passenden Nutzerobjektes auf dem Trust-Path angemeldet wird. Dies entspricht allerdings nicht dem beschriebenen Verhalten des Heimdal-Kerberos. In den Quellen wurde erwähnt, dass einzig eine Vertrauensstellung zwischen der Windows-Root-Domaine und dem externen Kerberos bestehen muss. Ähnliches wird in verschiedenen Papers der University of Colorado unter [Col00] beschrieben. Ist dies bei der Heimdal-Implementierung der Fall, wird die Anfrage des Clienten nach seinem Service-Ticket durch den Heimdal-Server einzig durch einen "`KRB5_ERROR_PRINZIPAL_UNKNOWN"' beantwortet, da ihm auch kein Trust bekannt ist, der die Anfrage befriedigender bearbeiten kann.
Ein weiterer Versuch bestand darin, dieses Verhalten durch ein geschicktes Verschachteln von Gruppen eine Art Verweis auf die Nutzerobjekte in der Root-Domain innerhalb der Subdomäne anzulegen. Prinzipiell kennt X.500 ja Verweise, um auf den Datenbestand anderer DSA zu vermitteln, welche vom angesprochenen DSA nicht beantwortet werden können. Leider ist das Anlegen eines solchen Verweises in Form eines Nutzerobjektes innerhalb des Active Directorys nicht vorgesehen, weshalb auf die Variante der Gruppenmitgliedschaften ausgewichen werden sollte. Vertiefend könnte ein Versuch in dieser Richtung mit Hilfe von Visual Basic in der Folge der Arbeit durchgeführt werden, da allerdings die Erfolgsaussichten gering sind, wurde es an dieser Stelle nicht ausgeweitet. Eine sinnvolle Gruppenverschachtelung ist im Rahmen der Tests ebenfalls erfolglos geblieben, aber es sei auf Abschnitt 5.8 verwiesen, welcher verschiedene Erkenntnisse zu Gruppenarten und -verweisen enthält, die sicher auch für die tägliche Arbeit interessant sind.

Wie sich im Rahmen der Tests herausstellte, unterstützt hingegen MIT-Kerberos mittels einer Funktion genau eine Befolgung des oben genannten Szenarios. Ein AS-Request, wie er bei der Erstauthentifizierung eines Nutzers gestellt wird, wird auch durch das MIT-Kerberos nur durch Abgleich des angeforderten Prinzipals mit der lokalen Prinzipaldatenbank abgearbeitet. Hingegen wird in der Funktion zur Abarbeitung von TGS-Requests "`do_tgs()"' bei einem erfolglosen Versuch, das Prinzipal in der lokalen Datenbank zu finden oder einem direkten Trust folgend weiter zu vermitteln, eine Funktion gerufen, die das angeforderte Prinzipal an Trennzeichen (üblicherweise dem Punkt) zerlegt und dann die verschiedenen Kombinationen gegen die lokale Datenbasis abgleicht. Die Abweisung eines solchen Verhaltens bei AS-Requests erklärt sich durch das Kerberos-Protokoll, da die Weitervermittlung mittels Erteilung eines TGTs für den Zielrealm erfolgt, dessen Validierung aber durch den empfangenden Realm beim auslösenden KDC möglich sein muss. Beim AS-Request kann aber der ursprünglich angesprochene KDC noch niemanden validieren, da ihm ja eine Prüfung des Prinzipals nicht möglich war.
Beispielhaft am oben aufgeführten Szenario der Subdomain könnte das Verhalten des MIT bei einem TGS-Request wie folgt aussehen:

1. Ein Nutzer meldet sich von einem Windows-PC der Subdomain am MIT-Realm an. Der MIT-Kerberos erteilt das TGT für den Realm
   "`krbtgt/MIT-REALM@MIT-REALM"'.
2. Mit dem TGT versucht nun der Clienten-PC ein Ticket für den Dienst
   "`host/clientpc.sub.domain.tld@MIT-REALM"' zu erhalten.
3. Da der MIT-Kerberos das Prinzipal nicht kennt und auch kein Cross-Realm-Trust zu "`sub.domain.tld"' besteht, kann diese Anfrage nicht direkt bearbeitet werden.
4. Intern wird im MIT-Kerberos nun die Funktion $find\_alternate\_tgs$ aus $do\_tgs\_req$ aufgerufen, welche den Service-Teil des Requests abteilt und den Host-Bestandteil an den Punkten zerlegt und alle Kombinationen zurückliefert. Es wird also ein Feld erstellt, welches "`host/sub.domain.tld@MIT-REALM"',
   "`host/domain.tld@MIT-REALM"' und "`host/tld@MIT-REALM"' enthält.
5. Auf Grund des Cross-Realm-Trusts, findet beim folgenden Abgleich der Feldinhalte mit der lokalen Datenbasis ein Verweis an die Windows-Root-Domain statt, welcher durch den Versuch "`host/domain.tld@MIT-REALM"' einzufordern, ausgelöst wird. Dieser Verweis wird realisiert, in dem statt dessen ein
   "`krbtgt/domain.tld@MIT-REALM"' ausgeliefert wird.

Auf diesem Wege wird auch die Auffindung eines zentral verwalteten Benutzerobjektes in der Windows-Root-Domain sicher gestellt. Einen ähnlichen Weg beschreibt ein Paper der University of Washington auf [Was01], welches die Verlagerung des Springens über eventuelle Realm-Referrals auf den Clienten beschreibt.
Da sich eben zeigte, dass der Aufbau eines Domänenbaums mit ausschließlichem Trust zur Wurzeldomäne und dort zentral verwalteten Nutzeraccounts nur mittels des Einsatzes von MIT-Kerberos realisieren ließe, hingegen die derzeitige Dienststruktur des URZs nicht wesentlich geändert werden soll, wurde im Rahmen der Tests versucht, einen Heimdal-Master mit einem MIT-Slave zu koppeln und die Replikationsmechanismen der beiden Systeme zu kombinieren. Da offenbar allerdings die Propagation-Protokolle zur Replikation von Änderungen in der Prinzipal-Datenbank des KDC-Masters auf die Slaves unterschiedlich implementiert, weil auch nicht standardisiert, wurden und Unterschiede in der Key-Implementierung hinzu kommen, war dieser Anschluss eines MIT- an ein Heimdal-System nicht erfolgreich. Somit ist es nicht möglich, innerhalb eines Baums mit externem Kerberos nur einmalig zentral Nutzerobjekte zu verwalten.