next up previous contents
Next: Heimdal- versus MIT-Kerberos Up: Kerberos im genannten Kontext Previous: Windows und Schlüsseltypen   Contents


Windows mit externem Kerberos

Eine funktionsfähige Zusammenarbeit eines Windows-Systems mit einem externen Kerberos funktioniert nur, indem mit dem $ksetup$-Kommandozeilenwerkzeug aus den Support Tools, welche auf der Windows-Installations-CD als Zusatzpaket mitgeliefert werden, ein KDC für einen externen Realm angegeben wird. Somit wird, wenn im Anmeldebildschirm unter "`Anmelden an"' der externe Realm ausgewählt ist, der Nutzer gegen den externen KDC verifiziert und durch diesen das TGT erteilt. Ist der Rechner, an dem der Nutzer sich anmeldet, Mitglied einer Domain unterscheidet sich der Weg ab diesem Punkt.
Der Client versucht ein Service-Ticket für seinen Rechner zu erlangen und wird an diesem Punkt vom externen KDC an seinen Domaincontroller per Realm-Trust verwiesen. Dieser erteilt das Ticket. Nun werden ein LDAP-Ticket angefordert und mit diesem ein Nutzer in der Domain gesucht, der namensgleich dem Nutzerprincipal ist und ein Attribut hat, welches ihn auf das Kerberos-Principal abbildet. Dieses Attribut heißt "`altSecurityIdentities"' und kann sowohl alternative Windows-Accounts als auch Kerberos-Principals aufnehmen. Wird der Nutzer in der Domain gefunden, wird dieser am Clienten angemeldet und alle Berechtigungen und Einschränkungen des Domainaccounts wirksam. Den Ablauf einer solchen Anmeldung eines Nutzers an einem Windows-Clienten, der gegen einen externen Kerberos-Server authentifiziert wird, verdeutlich Abbildung 5.4 nochmals.
Figure 5.4: Anmeldung eines Kerberos-Nutzers an einem Windows-Clienten
\resizebox*{\textwidth}{0.45\textheight}{\includegraphics{images/ADKerbAnmeldung}} \resizebox*{\textwidth}{0.45\textheight}{\includegraphics{images/ADKerbAnmeldung.eps}}
Ist der Rechner hingegen nicht in einer Domäne, wird dieses Mapping gegen die vorhandenen lokalen Accounts durchgeführt und versucht, ein Nutzer zu finden, der exakt so heißt wie das Nutzer-Principal oder ein passendes User Mapping gesucht. User Mapping heißt, dass eine Abbildung fremder Nutzernamen auf lokale Accounts stattfindet. Dies kann ebenfalls mittels $ksetup$ eingestellt werden.
An dieser Stelle wird auch ein Aspekt wirksam, der oben bereits angedeutet wurde und im Zusammenhang mit dem auf [Win05] vorgestellten Windows 2003 Server Service Pack steht. Gerade dieses Service Pack des Servers brachte Neuerungen mit, die die Zusammenarbeit mit einem externen Kerberos erschwerten - der vormals mögliche Betrieb mit deaktivierten Accounts und Kerberos wurde im Service Pack mittels Registry-Eintrag unterbunden, so dass nun das Deaktivieren der Accounts sich auch auf Nutzer auswirkte, welche per Kerberos authentifiziert werden. Vormals war dies anders, wodurch ein Missbrauch durch die Nutzung des Windows-Passwortes des Accounts verhindert werden konnte. Durch die Aktivierung des Accounts gibt es natürlich auch die Möglichkeit, sich an der Domäne mit dem Passwort zu authentifizieren, welches im Domaincontroller gespeichert ist. Somit ist auch darauf zu achten, ein sicheres Passwort für den Windows-Account zu setzen, um Missbrauch auf diesem Wege zu verhindern.

Was also notwendig ist, um eine Windows-Domäne nutzerseitig zur Authentifizierung an einen externen Kerberos-Dienst zu binden, ist die Installation der Support Tools auf allen Clienten der Domäne und deren Einrichtung eines zusätzlichen Realms dessen KDC der externe Kerberos-Server ist. Es können dort auch mehrere Server angegeben werden. Dies geschieht normalerweise mittels des Support-Tools "`ksetup"', welches nur bei der vollständigen Installation der selbigen enthalten ist. Die Syntax ist einfach, kann mittels eines Aufrufs mit der Option "`/?"' ermittelt werden, findet sich aber auch unter anderem auf [kse03] zum Nachlesen. Dort finden sich auch Beispiele der Nutzung. Andererseits ist die Installation des Werkzeugs auf allen betreffenden Rechnern recht aufwendig, nur um eine einmalige Einrichtung vorzunehmen. Ksetup erstellt nur einige wenige Registry-Keys, die auch mit selber Wirkung in die Registry eingetragen werden können. Es wird im Baum $HKEY\_LOCAL\_MACHINE\backslash
SYSTEM\backslash CurrentControlSet\backslash Control\backslash
Lsa\backslash Kerberos\backslash \_$
$Domains$ ein Schlüssel angelegt, der dem Namen des Kerberos-Realms entspricht, also beispielsweise "`TU-CHEMNITZ.DE"'. In diesem wird ein Wert namens "`KdcNames"' vom Typ "`REG_MULTI_SZ"' erstellt, der die DNS-Namen der KDC-Server für den entsprechenden Realm enthält. Unangenehm ist der Umstand, dass Werte dieses Types beim Export hexadezimal abgelegt werden. Sind für den Realm weitere Flags mittels des Werkzeugs eingetragen, werden diese als Wert des Typs "`REG_DWORD"' unter der Bezeichnung "`RealmFlags"' abgelegt und sind auch beim Export lesbar.
Außerdem lässt sich mittels "`ksetup"' ein Mapping von externen sich anmeldenden Nutzern auf lokale Accounts einrichten. Dazu wird in der Registry unter
$HKEY\_LOCAL\_MACHINE\backslash
SYSTEM\backslash CurrentControlSet\backslash Control\backslash
Lsa\backslash Kerberos$
ein Schlüssel namens "`UserList"' erstellt, der dann das zu mappende externe Prinzipal als Wert vom Typ "`REG_SZ"' enthält, welcher wiederum den Zielaccount fasst. Somit ließe sich vermutliche der Aufwand der Installation der Support Tools und der Ausführung von $ksetup$ durch ein exportiertes Registry-File ersetzen. Andererseits werden die Support Tools als msi-Paket bereitgestellt, was eine Installation im Rahmen der Grundinstallation oder auch mittels Gruppenrichtlinie später vereinfacht.
Um nun die externe Kerberos-Authentifizierung mit einer Domäne zu nutzen, muss zusätzlich zwischen dem Kerberos-Realm und der Windowsdomäne eine Vertrauensstellung, bei Kerberos "`Cross-Realm-Trust"' genannt, eingerichtet werden. Da hier nur vorgesehen ist, dass sich Kerberos-Nutzer an der Windowsdomäne anmelden können, der Umkehrschluss nicht erwünscht ist, reicht eine ausgehende Vertrauensstellung vom Windows aus gesehen. Dazu muss im externen Kerberos ein Principal angelegt werden, welches die Bezeichnung $krbtgt/windows.domain.tld$ hat und kein zufälliges Passwort besitzt. Auf einem Domaincontroller der Domäne wird im Gegenzug in den "`Active Directory Standorten und Vertrauensstellungen"' eine solche ausgehende Vertrauensstellung zum externen Kerberos-Realm eingerichtet, welche das dem TGT zugewiesene Passwort nutzt. Damit ist die Zusammenarbeit grundlegend eingerichtet. "`Nur"' die Pflege der Accounts bleibt, die mit den Kerberos-Principals korrespondieren.
Nachdem der Nutzer gegen den externen Kerberos-Server authentifiziert wurde, versucht der Client auf das Active Directory zuzugreifen, um die Daten des Nutzers zu erfahren und Einstellungen für den Desktop des Nutzers zu übernehmen. Dazu erfragt er beim externen Kerberos ein Ticket für den Dienst "`LDAP/Domaincontroller"', was mittels des Realm-Trusts zu einem Verweis an den Domaincontroller führt, da der KDC dieses Ticket nicht erteilen kann. Hier wird auch ein Problem ersichtlich, alles auf einem externen KDC pflegen zu wollen, da der Schlüssel, der auf dem Domaincontroller dem Dienst zugeteilt wird, nicht bekannt ist, also kein gültiges Service-Ticket erteilt werden könnte. Auch aktualisiert der Domaincontroller die Schlüssel seiner Dienste im Active Directory regelmäßig.


next up previous contents
Next: Heimdal- versus MIT-Kerberos Up: Kerberos im genannten Kontext Previous: Windows und Schlüsseltypen   Contents
Marko Damaschke 2006-03-25