Active Directory.pdf - Gattner

274 Kapitel 8: Active Directory-Domänendienstsicherheit
Das Zugriffstoken wird immer dann vom Sicherheitssubsystem eingesetzt, wenn ein Benutzer versucht,
auf eine Ressource zuzugreifen. Wenn der Benutzer versucht, auf eine lokale Ressource zuzugreifen,
legt die Clientarbeitsstation das Token jedem Thread und jeder Anwendung vor, der bzw. die
Sicherheitsinformationen anfordert, bevor der Zugriff auf eine Ressource gewährt wird. Das Zugriffstoken
wird niemals über das Netzwerk an einen anderen Computer übertragen. Stattdessen wird ein
lokales Zugriffstoken auf jedem Server erstellt, auf dem der Benutzer Zugriff auf eine Ressource
anfordert. Wenn ein Benutzer beispielsweise versucht, auf ein Postfach eines Exchange Server 2007-
Servers zuzugreifen, wird auf dem Server ein Zugriffstoken erstellt. In diesem Fall vergleicht das
Sicherheitssubsystem auf dem Exchange Server 2007-Server die Sicherheitskennungen im Zugriffstoken
mit den Berechtigungen, die in der Postfach-ACL gewährt werden. Sofern die der Sicherheitskennung
gewährten Berechtigungen es erlauben, kann der Benutzer das Postfach öffnen.
Authentifizierung
Damit die Sicherheitsprozesse (einschließlich Verwendung von Sicherheitskennungen und ACLs)
funktionieren, muss eine Methode vorhanden sein, die dem Benutzer den Zugriff auf das Netzwerk
ermöglicht. Grundsätzlich müssen Benutzer in der Lage sein, ihre Identität zu belegen, um ein
Zugriffstoken vom Domänencontroller abrufen zu können. Dieser Vorgang wird als Authentifizierung
bezeichnet.
Die Authentifizierung findet während der ersten Clientanmeldung auf einem Computer statt, der Mitglied
einer AD DS-Domäne ist. Die genauen Schritte richten sich nach dem Betriebssystem, an dem
sich der Client anmeldet. Wenn der Benutzer mit einem Windows 2000-, Microsoft Windows XP
Professional- oder Windows Server 2003-Computer arbeitet und die Tastenkombination STRG+
ALT+ENTF eingibt – auch bekannt als Sicherheitsaufruf (Secure Attention Sequence, SAS) –, wechselt
der Winlogon-Dienst auf dem lokalen Computer zum Anmeldebildschirm und lädt die GINA-
DLL (Graphic Identification and Authentication, Dynamic Link Library). Standardmäßig ist dies die
Datei Msgina.dll. Drittanbieter können jedoch alternative GINA-Dateien erstellen (beispielsweise verwendet
der NetWare-Client die Datei Nwgina.dll). Nach der Eingabe von Benutzername und Kennwort
sowie der Auswahl einer Domäne durch den Benutzer übergibt GINA die eingegebenen Anmeldeinformationen
an den Winlogon-Prozess. Der Winlogon-Dienst leitet die Informationen an die
lokale Sicherheitsautorität (Local Security Authority, LSA) weiter.
Windows Vista und Windows Server 2008 machen keinen Gebrauch von der GINA-DLL. In Windows
Vista und Windows Server 2008 wird ein neues Authentifizierungsmodell eingeführt, bei dem
LogonUI und Winlogon direkt miteinander kommunizieren. Wenn Benutzer an einem System mit
diesen Betriebssystemen ihre Anmeldeinformationen eingeben, werden die Anmeldeinformationen
von der LogonUI-Komponente direkt an den Winlogon-Dienst übergeben, der die Informationen
anschließend an die lokale Sicherheitsautorität weiterleitet. Zur Authentifizierung gegenüber anderen
Verzeichnissen kann ein Drittanbieter einen Anmeldeinformationsanbieter erstellen. Dieses in die
LogonUI-Komponente integrierte Modul beschreibt die Benutzeroberfäche, erfasst die Anmeldeinformationen
und übergibt sie an den Winlogon-Dienst. Anmeldeinformationsanbieter arbeiten gegenüber
Winlogon vollständig transparent.
In beiden Fällen wendet die lokale Sicherheitsautorität sofort einen einseitigen Hash auf das
Benutzerkennwort an und löscht das Klartextkennwort, das vom Benutzer eingegeben wurde.
Anschließend ruft die lokale Sicherheitsautorität über die Security Support Provider-Schnittstelle
den geeigneten SSP (Security Support Provider) auf. Windows Server 2008 stellt für die Netzwerkauthentifizierung
zwei primäre SSPs bereit, den Kerberos SSP und den NTLM SSP (NT LAN
Manager).