Sonderbeitrag: Windows Server 2008

Neuerungen in Active Directory-Domänendiensten

Gil Kirkpatrick

 

Kurz zusammengefasst:

• Verwenden des neuen Server-Managers mit ADDS
• Ausführen von Domänendiensten auf Server Core
• Domänencontroller ohne Schreibzugriff
• Änderungen bei Kennwörtern, Sicherung und Überwachung

Mit Windows 2000 wurde Active Directory von Microsoft eingeführt. Die nächste Hauptversion, Windows Server 2003, enthielt bedeutende Verbesserungen von Active Directory, aber keine

weltbewegenden Änderungen. Heute ist Active Directory® ein höchst ausgereifter, stabiler Verzeichnisdienst. Dennoch hat das Active Directory Team mehrere wesentliche Verbesserungen in der aktuellen Version bereitgestellt, um die Sicherheit und Verwaltbarkeit dieses zentralen Netzwerkdiensts zu verbessern.

Um das Jahr 2000 herum sorgte Active Directory beim Anmelden eines Benutzers für dessen Authentifizierung, wendete Gruppenrichtlinien für diesen Benutzer und seinen Computer an und ermöglichte ihm, einen gewünschten Drucker zu finden. Ein paar Jahre später veröffentlichte Microsoft eine eigenständige Variante mit der Bezeichnung Active Directory-Anwendungsmodus (Active Directory Application Mode, ADAM).

Doch bis 2006 hatte sich das alles geändert. Active Directory war keine bestimmte Technologie mehr. Heute ist es ein Markenname für eine Sammlung von sofort einsetzbaren Windows®-Identitäts- und Zugriffssteuerungsdiensten. Abbildung 1 bietet einen kurzen Überblick über die Active Directory-Marke.

Figure 1 Active Directory-Komponenten

Aktuelle Active Directory-Technologie	Bisher bezeichnet als	Beschreibung
Active Directory-Domänendienste (ADDS)	Active Directory	Was früher als Active Directory bezeichnet wurde Bietet Kerberos- und NTLM-basierte Authentifizierung für Domänenbenutzer und -Computer und verwaltet Organisationseinheiten, Benutzer, Gruppen, Gruppenrichtlinien und vieles mehr.
Active Directory Lightweight-Verzeichnisdienste (ADLDS)	Active Directory-Anwendungsmodus (ADAM)	Ein Hochleistungs-LDAP-Server auf der Grundlage desselben von ADDS verwendeten Quellcodes.
Active Directory-Zertifikatdienste (ADCS)	Zertifikatdienst	Bietet leistungsfähige Authentifizierung mithilfe von X.509-Zertifikaten.
Active Directory-Rechteverwaltungsdienste (ADRMS)	Rechteverwaltungsserver	Schützt digitale Ressourcen wie Dokumente und E-Mail-Nachrichten vor nicht autorisierter Verwendung durch Erstellen von Dateien und Containern, die durch Rechte geschützt sind.
Active Directory-Verbunddienste (ADFS)	Active Directory-Verbunddienste	Bietet einmaliges Anmelden im Web und Identitätsverbund für WS-*-kompatible Webdienste.

Um die richtige Terminologie zu verwenden, geht es in diesem Artikel also um die Domänendienste. Es handelt sich jedoch um dasselbe Active Directory, an das Sie seit 2000 gewöhnt sind.

Server-Manager in Windows Server 2008

Die ersten beiden Verbesserungen für Active Directory, die hier erörtert werden, sind eigentlich keine Änderungen an den Active Directory-Domänendiensten (Active Directory Domain Services, ADDS), sondern Änderungen in Windows, die sich auf die Verwaltung von Active Directory auswirken. Die erste Änderung, der neue Server-Manager, wird angezeigt, sobald Sie Windows Server® 2008 zum ersten Mal starten. (Die zweite ist die Server Core-Installation, auf die gleich noch eingegangen wird.)

Server-Manager wird Ihnen wahrscheinlich aus dem Serverkonfigurations-Assistenten in Windows Server 2003 vertraut sein, der standardmäßig nach der Installation von Windows Server 2003 angezeigt wird. Diese Version ist jedoch für die tägliche Verwaltung nicht sehr nützlich, und alle, die ich kenne, markieren das Kontrollkästchen „Don't display this page at logon“ (Diese Seite bei der Anmeldung nicht anzeigen).

Server-Manager in Windows Server 2008 ist allerdings recht nützlich (einen Überblick über Server-Manager finden Sie im Artikel von Byron Hynes in dieser Ausgabe des TechNet Magazins). Wie Sie in Abbildung 2 sehen, ist Server-Manager jetzt ein Microsoft®-Verwaltungskonsolen (MMC)-Snap-In und keine Microsoft HTML-Anwendung (HTA). Dies bedeutet, dass eine vertraute und leicht anpassbare Benutzeroberfläche mit allen Funktionen vorhanden ist. Mithilfe von Server-Manager können Sie sofort die Installation von Serverrollen (Hauptdienste wie DNS, ADDS und IIS) und Features (Softwarekomponenten wie Microsoft .NET Framework, BitLockerTM-Laufwerkverschlüsselung und Windows PowerShellTM) verwalten. Neben der Möglichkeit zum Hinzufügen und Entfernen von Software stellt Server-Manager auch einen zentralen Punkt zum Ausführen von Diagnosetools (beispielsweise die Ereignisanzeige und PerfMon) und Systemkonfigurationsprogrammen (beispielsweise Geräte-Manager und das Windows Firewall-Snap-In) bereit. Wenn Sie die MMC-Snap-Ins zu Active Directory dazunehmen (etwa „Benutzer und Computer“, „Domänen und Vertrauensstellungen“ und „Standorte und Dienste“), verfügen Sie über eine recht gute Benutzeroberfläche für die tägliche Verwaltung Ihres Windows Server 2008-Domänencontrollers (Domain Controller, DC).

Abbildung 2** Server-Manager in Windows Server 2008 **(Klicken Sie zum Vergrößern auf das Bild)

Windows Server 2008 Server Core

Windows Server Core ist eine neue Windows Installationsoption. Sie bietet eine verkürzte Version von Windows, die nur die zum Ausführen bestimmter Hauptserverrollen (einschließlich Active Directory-Domänendiensten) erforderlichen Komponenten enthält. (In Abbildung 3 sind die von Server Core unterstützen Rollen aufgeführt.) Obwohl eine Server Core-Installation über eine grafische Benutzeroberfläche verfügt, wird die Windows-Desktopshell nicht ausgeführt, und fast alle grafischen Tools zum Verwalten und Konfigurieren von Windows fehlen (siehe Abbildung 4). An ihre Stelle treten ein Befehlsfenster sowie ein ungutes Gefühl, nicht zu wissen, was Sie als Nächstes tun sollen. Wie lässt sich der Computername ändern? Wie kann eine statische IP-Adresse konfiguriert werden?

Abbildung 4** Auf der Server Core-Benutzeroberfläche gibt es nicht viel zu sehen. **(Klicken Sie zum Vergrößern auf das Bild)

Die ersten Minuten einer Server Core-Installation können beunruhigend sein. Aber wenn Sie sich mit WMIC, NETSH und NETDOM wieder ein wenig vertraut gemacht haben, können Sie alle üblichen Setup- und Konfigurationsaufgaben ohne Schwierigkeit durchführen. Regedit und der Editor sind zur Erfüllung Ihrer Anforderungen an grafische Tools weiterhin vorhanden.

Der Hauptvorteil von Server Core besteht darin, dass viel Code, der bei einer typischen Windows-Installation vorhanden ist und den Sie möglicherweise für diese zentralen Serverrollen nicht brauchen, entfernt wurde. Dies verringert die potenzielle Angriffsfläche für Malware (was gut ist) und verringert das Ausmaß von Patching und Neustarts, die Sie bei den DCs durchführen müssen (was noch besser ist). Zudem sind der Datenträgerbedarf und die Festplattenanforderungen sehr viel geringer. Dies ist normalerweise kein entscheidender Faktor, kann aber in virtualisierten Serverumgebungen helfen.

Wird das Verwalten von ADDS durch den Mangel an grafischen Dienstprogrammen erschwert? Absolut nicht. Sie können fast alle Verwaltungsaufgaben von einem Remotestandort aus durchführen, indem Sie die Dienstprogramme auf Ihrer Arbeitsstation ausführen und eine Verbindung zum Domänencontroller über das Netzwerk herstellen. In Zukunft dürfte die große Mehrzahl von DCs auf Server Core-Installationen ausgeführt werden.

DCPROMO-Änderungen

Die erste Änderung, die Sie bei ADDS feststellen werden, ist das neue DCPROMO-Dienstprogramm. Es funktioniert genauso wie DCPROMO in Windows Server 2003, aber es wurde im Interesse einer einfacheren Verwendung völlig überarbeitet. Sie müssen beispielsweise nicht Ihre Anmeldeinformationen als Domänenadministrator eingeben. DCPROMO kann die Anmeldeinformationen Ihrer aktuellen Anmeldung verwenden, um den Server hochzustufen. Sie müssen auch nicht DCPROMO /ADV eingeben, um die DCPROMO-Optionen im erweiterten Modus aufzurufen. Zur Aktivierung dieser Optionen ist jetzt im ersten DCPROMO-Dialogfeld ein Kontrollkästchen vorhanden. Mithilfe des erweiterten Modus können Sie dazu den vorhandenen Domänencontroller auswählen, von dem aus die Replikation erfolgen soll. Sie können somit also die Replikationslast von DCPROMO von Ihren Produktions-DCs fernhalten.

Wenn Sie einen DC in eine neue Domäne oder Gesamtstruktur hochstufen, bietet DCPROMO Ihnen die Option, die Funktionsebene der Gesamtstruktur und der Domäne festzulegen, statt dies später zu tun. Sie können auch den Active Directory-Standort angeben, in den Sie den DC in während des Hochstufungsprozesses stellen wollen, was im unbeaufsichtigten DCPROMO-Szenario sehr nützlich ist. DCPROMO schlägt sogar den besten Standort für den DC auf der Grundlage seiner IP-Adresse vor.

Das neue DCPROMO-Dienstprogramm sammelt zudem alle Konfigurationsoptionen auf einer einzigen Seite, sodass Sie von einem Ort auswählen können, ob der neue DC ein globaler Katalog (Global Catalog, GC), ein DNS-Server oder ein schreibgeschützter DC sein soll. Sie müssen keinen unbekannten Speicherort im Active Directory-Snap-In für Standorte und Dienste aufsuchen, um den DC als GC zu kennzeichnen.

Doch das vielleicht beste Feature des neuen DCPROMO-Dienstprogramms ist die Möglichkeit, kurz vor Beginn des Hochstufungsprozesses alle DCPROMO-Einstellungen in einer Antwortdatei zu speichern. Dies ist viel einfacher (und weniger fehleranfällig) als das manuelle Zusammenbasteln der Antwortdatei. Sie können dann die Antwortdatei verwenden, um unbeaufsichtigte DCPROMOs auf anderen Servern durchzuführen. Noch eine Information für Skriptfanatiker: Alle DCPROMO-Optionen sind jetzt von der Befehlszeile aus zugänglich.

Domänencontroller ohne Schreibzugriff

Im Anfangsstadium von Active Directory stellten Unternehmen oft Domänencontroller an jedem Standort bereit, an dem sich Benutzer anmelden konnten. Dies war beispielsweise in Banken üblich, wo ein DC in jeder Zweigstelle platziert wurde. Das logische Grundprinzip bestand darin, dass Benutzer in der Zweigstelle in der Lage sein würden, sich anzumelden und auf die lokalen Netzwerkressourcen zuzugreifen, selbst wenn das WAN versagte.

Damals wurde der Bedarf an physischer Sicherheit für DCs nicht besonders gut verstanden. Beispielsweise wurden Domänencontroller einfach unter Schreibtischen platziert, wo praktisch jeder leicht auf sie zugreifen konnte. Erst einige Jahre später wurden sich Active Directory-Architekten vollständig des Sicherheitsrisikos bewusst, das durch einen ungesicherten DC entsteht, und IT-Organisationen konsolidierten ihre DCs nach und nach wieder in stärker zentralisierten Datencentern. Benutzer in Zweigstellen mussten sich dann über das WAN authentifizieren, was aber hinsichtlich der zusätzlichen Sicherheit ein lohnender Kompromiss war.

Active Directory in Windows Server 2008 ändert die Gleichung in Bezug auf Zweigstellenbereitstellungen durch die Einführung von Domänencontrollern ohne Schreibzugriff oder RODCs. Sie repräsentieren die größte Änderung an Windows Server 2008-Domänendiensten.

Das Active Directory-Team konzentrierte sich bei der Entwicklung des RODC auf die Anforderungen von Zweigstellenszenarios, wobei sich die Beteiligten das Ziel setzten, dass sich das, was in der Zweigstelle passiert, auch nur dort auswirkt. Das heißt, beim Bereitstellen eines DC in einer physisch nicht sicheren Zweigstelle kann praktisch nichts getan werden, um eine Gefährdung des DC (und der Computer, die diesem DC vertrauen) zu verhindern, aber es kann verhindert werden, dass sich diese Gefährdung von der Zweigstelle aus in der übrigen Domäne ausbreitet.

Beachten Sie, dass RODCs zwar eine enorme Änderung der ADDS-Infrastruktur bedeuten, sich aber ziemlich einfach implementieren lassen. Ihre Domäne muss sich auf der Funktionsebene der Windows Server 2003-Gesamtstruktur befinden, und es muss mindestens ein Windows Server 2008-DC in der Domäne vorhanden sein. RODCs sind nicht nur als einfache Zweigstellenlösung sinnvoll, sondern auch in mit dem Internet verbundenen Umgebungen, sowie in Situationen, in denen sich der DC im Netzwerkumkreis befindet.

Ein unerlaubt abwesender DC

In einer Zweigstelle müssen mehrere Klassen von Bedrohungen in Betracht gezogen werden. Die erste ist das Szenario, in dem der „DC gestohlen“ wird, indem sich jemand mit dem DC oder dem Datenträger des DC davon macht. Neben der lokalen Dienstunterbrechung besteht das Risiko darin, dass der Angreifer letzten Endes Zugriff auf alle Benutzernamen und Kennwörter in der Domäne gewinnt und von dort aus seine Berechtigungen erweitert, um Zugriff auf geschützte Ressourcen zu erhalten oder einen Denial-of-Service zu verursachen. Um dieser Bedrohung entgegenzuwirken, speichern RODCs standardmäßig keine Kennworthashwerte in der Verzeichnisinformationsstruktur (Directory Information Tree, DIT) des RODC. Um einen Benutzer bei erstmaliger Authentifizierung bei einem bestimmten RODC zu authentifizieren, gibt der RODC die Anforderung an einen vollständigen Domänencontroller (Full Domain Controller, FDC) in der Domäne weiter. Der FDC verarbeitet die Anforderung, und bei Erfolg erstellt der RODC eine Replikationsanforderung für den Kennworthashwert.

Ein beeinträchtigter RODC könnte unter Umständen Kennworthashwerte für vertrauliche Konten anfordern. Um dies zu verhindern, kann der Domänenadministrator eine Kennwortreplikationsrichtlinie für jeden RODC konfigurieren. Die Kennwortreplikationsrichtlinie besteht aus zwei Attributen auf dem Computerobjekt des RODC. Das msDS-RevealOnDemandGroup-Attribut enthält die „Distinguished Names“ von Gruppen-, Benutzer- oder Computerkonten, deren Kennwörter auf dem RODC zwischengespeichert werden dürfen (dies sind in der Regel die Benutzer und Computer am selben Standort wie der RODC). Das msDS-NeverRevealGroup-Attribut enthält die „Distinguished Names“ der Gruppen-, Benutzer- oder Computerkonten, deren Kennwörter nicht auf dem RODC zwischengespeichert werden dürfen (die Kennworthashwerte des Domänenadministratorkontos sollten beispielsweise nie auf einem RODC zwischengespeichert werden). Wenn der RODC den Kennworthashwert für ein bestimmtes Konto anfordert, bewertet der FDC die Anforderung anhand der Kennwortreplikationsrichtlinie, um zu bestimmen, ob der Kennworthashwert auf dem RODC repliziert werden sollte. Wenn ein DC gestohlen wird, schränkt dies das Sicherheitsrisiko für jene Kennwörter ein, die zu dem Zeitpunkt, als er aus dem Netzwerk entfernt wurde, auf dem gestohlenen RODC zwischengespeichert waren, sodass die Möglichkeit einer Gefährdung eines kritischen Kennworts beseitigt wird.

Das RODC-Computerobjekt enthält zwei weitere Attribute, mit denen Sie genau festlegen können, welche Kontenkennwörter zwischengespeichert werden sollten. Das msDS-AuthenticatedAtDC-Attribut listet die Konten auf, die beim RODC authentifiziert wurden, und das msDS-RevealedList-Attribut nennt die Konten, deren Kennwörter derzeit vom RODC gespeichert werden.

Benutzer- und Computerkennworthashwerte sind nicht die einzigen geheimen Informationen, die auf einem DC gespeichert werden. Das KrbTGT-Konto enthält die Schlüssel für den Kerberos-Schlüsselverteilungscenter (Key Distribution Center, KDC)-Dienst, der auf jedem Domänencontroller ausgeführt wird. In einem typischen Szenario nutzen alle KDCs in der Domäne dasselbe KrbTGT-Konto, und es ist möglich, dass ein Angreifer diese Schlüssel von einem gestohlenen DC abrufen und sie zum Angriff auf die übrige Domäne verwenden könnte. Doch jeder RODC hat sein eigenes KrbTGT-Konto und seine eigenen Schlüssel, sodass diese Möglichkeit beseitigt wird.

Es ist zudem nicht ungewöhnlich, dass Anwendungen Kennwörter oder andere geheime Informationen in der DIT speichern. Wenn ein Angreifer einen DC stiehlt, könnte er möglicherweise damit die Anwendungskennwörter stehlen und verwenden, um Zugriff auf die Anwendungen zu gewinnen. Um dieses Risiko zu verringern, ermöglichen Windows Server 2008-Domänendienste es Administratoren, das Read-Only DC Filtered Attribute Set (RO-FAS) zu definieren. Attribute, die Teil des RO-FAS sind, werden nie auf RODCs repliziert, sodass sie nicht von einem gefährdeten DC abgerufen werden können. Sie weisen dem RO-FAS Attribute zu, indem Sie Bit 9 (0x0200) des searchFlags-Attributs des entsprechenden attributeSchema-Objekts im Schema festlegen.

Barbaren innerhalb der Tore

Eine weitere Bedrohungsklasse für Zweigstellendomänencontroller besteht darin, dass ein lokaler Serveradministrator seine Berechtigung erweitert, indem er Berechtigungen des DC nutzt, um Zugriff auf andere Domänenressourcen zu gewinnen oder einen Denial-of-Service-Angriff durchzuführen. Auch hier gilt: wenn der lokale Administrator physischen Zugriff auf den Domänencontroller hat, kann wenig getan werden, um eine Gefährdung zu verhindern. Doch es ist möglich, den Angreifer daran zu hindern, den Zweigstellendomänencontroller zur Gefährdung anderer DCs in der Domäne zu verwenden.

Vollständige DCs in der Domäne vertrauen RODCs nicht als Domänencontroller. Von einem Vertrauensstandpunkt aus behandeln FDCs RODCs als Mitgliedsserver in der Domäne. Ein RODC ist kein Mitglied der Domänencontroller oder Domänencontrollergruppen eines Unternehmens. Das RODC-Konto hat sehr begrenzte Möglichkeiten, Informationen im Verzeichnis zu aktualisieren, und selbst wenn ein Angreifer das RODC-Konto gefährdet, erhält er fast keine nützlichen Berechtigungen.

RODCs werden nicht einmal in der normalen DS-Replikationstopologie angezeigt. Da RODCs wie normale Mitgliedsserver anstelle von Domänencontrollern aussehen, erstellt die Konsistenzprüfung (Knowledge Consistency Checker, KCC, der Prozess auf jedem DC, der für die Berechnung der DS-Replikationstopologie verantwortlich ist) keine Verbindungsobjekte von RODCs. Kein vollständiger DC oder RODC wird versuchen, von einem RODC zu replizieren. Andererseits erstellt der RODC ein Verbindungsobjekt, das eine eingehende Replikationsvereinbarung von einem vollständigen DC darstellt, doch dieses Verbindungsobjekt existiert nur im Replikat des RODC. Kein anderer DC verfügt über eine Kopie dieses Verbindungsobjekts. Von einem Replikationsstandpunkt aus sind RODCs wie Mausefallen für Verzeichnisobjekte. Objekte werden hinein-, aber nicht herausrepliziert.

Administratorrollentrennung auf RODCs

Es ist häufig der Fall, dass ein Zweigstellen-DC von einem lokalen Serveradministrator verwaltet wird, dessen Aufgaben praktisch alles umfassen, vom Ausführen von Sicherungen bis hin zum Reinigen von Tastaturen. Doch es ist ein Sicherheitsrisiko, wenn dem Administrator an einem Remotestandort die erforderlichen Rechte für die allgemeine Wartung eines Domänencontrollers gewährt werden, da der Standortadministrator seine Berechtigungen in der Domäne unter Umständen erhöhen könnte. RODCs bieten zwei Arten der Administratorrollentrennung, um diese Bedrohung zu verringern.

Bei der ersten Form der Rollentrennung kann der Domänenadministrator den RODC auf herkömmliche Weise mithilfe von DCPROMO hochstufen, oder er kann einen aus zwei Schritten bestehenden Prozess verwenden, wobei der eigentliche Hochstufungsprozess sicher an den Zweigstellenadministrator delegiert wird, ohne Domänenverwaltungsrechte zu gewähren. Der Domänenadministrator erstellt das RODC-Computerkonto vorher in der Domäne mithilfe des Active Directory-MMC-Snap-In für Benutzer und Computer, wie in Abbildung 5 dargestellt.

Abbildung 5** Vorherige Erstellung des RODC-Computerkontos **(Klicken Sie zum Vergrößern auf das Bild)

Durch die Auswahl von „Konto für schreibgeschützten Domänencontroller vorbereiten“ wird eine abgekürzte Version von DCPROMO ausgeführt, die alle Aufgaben durchführt, für die Administratorzugriff auf die Domäne erforderlich ist, einschließlich Erstellen des Computerkontos, Zuweisen des RODC zu einem Standort, Festlegen der Rollen des DC, Festlegen der Kennwortreplikationsrichtlinie und Definieren des Benutzers oder der Gruppe, für die Rechte zum Abschließen des DCPROMO-Vorgangs auf dem RODC erforderlich sind. Der delegierte Administrator oder die Gruppe wird im managedBy-Attribut des RODC-Computerobjekts gespeichert.

Der delegierte Administrator kann dann DCPROMO auf dem Server selbst ausführen. DCPROMO erkennt das zuvor erstellte Konto und verwandelt den Server in einen RODC. Für das Ausführen von DCPROMO auf diese Weise sind keine Domänenadministratoranmeldeinformationen erforderlich.

Die zweite Möglichkeit, eine Administratorrollentrennung für RODCs bereitzustellen, besteht im Erstellen lokaler Administratorrollen auf dem RODC selbst. Diese Rollen sehen wie lokale Computergruppen aus – sie werden in der Registrierung des RODC gespeichert und können nur auf dem RODC bewertet werden. Doch anstelle der Verwendung des Computerverwaltungs-MMC-Snap-Ins zu ihrer Verwaltung verwaltet der Administrator lokale RODC-Rollen mithilfe von NTDSUTIL. In Abbildung 6 sind die lokalen Administratorrollen auf einem RODC aufgeführt. Diese Rollen entsprechen jeweils den integrierten Gruppen in Windows.

Figure 6 Lokale RODC-Administratorrollen

Kontenoperatoren

Administratoren

Sicherungsoperatoren

Zertifikatdienst-DCOM-Zugriff

Kryptografische Operatoren

DCOM-Benutzer

Ereignisprotokollleser

Gäste

IIS_IUSRS

Erstellungen eingehender Gesamtstrukturvertrauensstellung

Netzwerkkonfigurationsoperatoren

Leistungsprotokollbenutzer

Systemmonitorbenutzer

Prä-Windows 2000-kompatibler Zugriff

Druckoperatoren

Remotedesktopbenutzer

Replikations-Operator

Serveroperatoren

Terminal Server-Lizenzserver

Benutzer

Windows-Autorisierungszugriffsgruppe

Eigentümlichkeiten von RODCs

Da RODCs schreibgeschützt sind und kein anderer Domänencontroller von ihnen Replikationen vornimmt, zeigen RODCs einige unerwartete Verhaltensweisen. Veraltete Objekte beispielsweise, Objekte also, die überall bis auf einem bestimmten DC gelöscht wurden, weil der DC nicht in der Lage war, für eine längere Zeitdauer als die Tombstone-Gültigkeitsdauer der Gesamtstruktur zu replizieren, werden normalerweise von den ausgehenden Replikationspartnern des DC erkannt. Doch da RODCs keine eingehenden Replikationspartner haben, werden für sie keine veralteten Objekte erkannt.

RODCs stellen keine LDAP-Updatevorgänge (hinzufügen, ändern, löschen, umbenennen oder verschieben) bereit. Stattdessen geben RODCs einen Fehler mit einem LDAP-Verweis an einen beschreibbaren DC zurück, der diesen Vorgang bereitstellen kann. Wenn die Anwendung, die das LDAP-Update veröffentlicht hat, den Verweisvorgang nicht richtig behandelt, könnte die Anwendung fehlschlagen.

Wenn ein Benutzer aus einer anderen Domäne in der Gesamtstruktur versucht, sich auf einem RODC zu authentifizieren, muss der RODC in der Lage sein, auf einen vollständigen DC in seiner eigenen Domäne zuzugreifen, um das Vertrauensstellungskennwort zu erhalten, sodass die Authentifizierungsanforderung richtig an den DC in der Domäne übergeben werden kann. Wenn die Netzwerkverbindung zwischen dem RODC und dem vollständigen DC in seiner Domäne nicht verfügbar ist, schlägt die Authentifizierung fehl.

Fein abgestimmte Kennwortrichtlinien

Die Möglichkeit, mehr als eine Kennwortrichtlinie in der Domäne zu definieren, war wahrscheinlich das am häufigsten geforderte Feature für Windows Server 2008 ADDS. Wie Sie wahrscheinlich wissen, unterstützt jede Domäne in Windows 2000 und Windows Server 2003 Active Directory nur eine einzelne Kennwortrichtlinie, die auf alle Sicherheitsprinzipale in der Domäne angewendet wird. Wenn Sie eine separate Kennwortrichtlinie für eine bestimmte Gruppe von Benutzern benötigen, müssen Sie eine separate Domäne erstellen. Doch mithilfe eines neuen Features in Windows Server 2008 ADDS, das als fein abgestimmte Kennwortrichtlinien bezeichnet wird, können Sie mehrere Kennwortrichtlinien in einer Domäne definieren.

Die neue Strategie verwendet Gruppen zum Anwenden abgestimmter Kennwortrichtlinien auf Benutzer. Sie definieren die abgestimmte Kennwortrichtlinie zunächst durch Erstellen eines neuen msDS-PasswordSettings-Objekts im „CN=Password Settings Container, CN=System, DC=<domain>“-Container. Das msDS-PasswordSettings-Objekt (kurz PSO genannt) enthält Attribute, die der Kennwortrichtlinieneinstellung in der Gruppenrichtlinie entsprechen (siehe Abbildung 7).

Figure 7 Attribute im mSDS-PasswordSettings-Objekt

Attribut	Beschreibung
mSDS-PasswordReversibleEncryptionEnabled	Boolescher Wert, der anzeigt, ob Kennwörter unter Verwendung umkehrbarer Verschlüsselung verschlüsselt sind.
mSDS-PasswordHistoryLength	Anzahl der in der Kennwortchronik verwalteten Einträge.
mSDS-PasswordComplexityEnabled	Boolescher Wert, der anzeigt, ob Einschränkungen für die Kennwortkomplexität aktiviert sind.
mSDS-MinimumPasswordLength	Ganzzahl, die die Mindestlänge des Kennworts definiert.
mSDS-MinimumPasswordAge	INTEGER8-Attribut, das das Mindestalter des Kennworts angibt, bevor es geändert werden kann.
mSDS-MaximumPasswordAge	INTEGER8-Attribut, das das Höchstalter des Kennworts angibt, bevor es geändert werden muss.
mSDS-LockoutThreshold	Ganzzahl, die die Anzahl fehlgeschlagener Anmeldungen vor einer Sperrung anzeigt.
mSDS-LockoutObservationWindow	INTEGER8-Attribut, das die Anzahl von Nanosekunden anzeigt, innerhalb derer fortlaufende fehlgeschlagene Anmeldungen erfolgen müssen, um eine Sperrung auszulösen.
mSDS-LockoutDuration	INTEGER8-Attribut, das die Anzahl von Nanosekunden anzeigt, die das Konto gesperrt ist.

Dann weisen Sie die Kennwortrichtlinie Benutzern oder Gruppen zu, indem Sie dem mehrwertigen mDS-PSOAppliesTo-Attribut des PSO die Benutzer- oder Gruppennamen hinzufügen. Wenn Sie sich erst einmal mit der Vorstellung vertraut gemacht haben, dass keine Kennwortrichtlinien auf Organisationseinheiten angewendet werden, ist alles recht einfach. Doch es gibt eine zusätzliche Komplexität.

Benutzer sind gewöhnlich Mitglieder vieler Gruppen. Was geschieht nun, wenn es mehrere widersprüchliche Kennwortrichtlinien gibt, die einem Benutzer aufgrund dieser Gruppenmitgliedschaften zugeordnet sind? In diesem Fall verwendet ADDS eine Rangfolgenbewertung, um zu bestimmen, welche Kennwortrichtlinie angewendet werden sollte. Sie funktioniert folgendermaßen:

1. Wenn eine Kennwortrichtlinie direkt mit einem Benutzerobjekt (nicht über die Gruppenmitgliedschaft) verknüpft ist, wird diese Kennwortrichtlinie angewendet.
2. Wenn mehrere Kennwortrichtlinien direkt mit dem Benutzer verknüpft sind, wird die Richtlinie mit dem niedrigsten Rangfolgewert (wie vom Wert des msDS-PasswordSettingsPrecendence-Attributs des PSO festgelegt) angewendet.
3. Wenn es mehrere PSOs mit derselben Rangfolge gibt, wird das PSO mit dem niedrigsten objectGUID-Wert angewendet.
4. Wenn keine PSOs direkt mit dem Benutzer verknüpft sind, bewertet ADDS die mit den Gruppen des Benutzers verknüpften PSOs. Wenn mehr als ein PSO vorhanden ist, wird das PSO mit dem niedrigsten Wert im msDS-PasswordSettingsPrecedence-Attribut angewendet.
5. Wenn mehr als ein PSO mit demselben Rangfolgewert vorhanden ist, wird das PSO mit dem niedrigsten objectGUID-Wert angewendet.
6. Wenn dem Benutzer keine PSOs zugeordnet sind, wird die Domänenkennwortrichtlinie verwendet.

Benutzerobjekte verfügen über ein neues Attribut namens msDS-ResultantPSO, mit dem geklärt werden kann, welches PSO für einen Benutzer gilt. Dieses Attribut enthält den „Distinguished Name“ des PSO, der das Kennwort dieses Benutzers steuert.

Fein abgestimmte Kennwortrichtlinien bieten Ihnen mehr Flexibilität als Sie wahrscheinlich je benötigen, doch Sie müssen diese Richtlinien sorgfältig verwalten und sie einfach halten. Es gibt kein einsetzbares Dienstprogramm zum Definieren abgestimmter Kennwortrichtlinien. Sie müssen entweder ADSIEdit verwenden oder sich nach einem Drittanbieterdienstprogramm umsehen.

Neu startbarer Active Directory-Dienst

Jedes Mal, wenn Sie einen Domänencontroller zur DIT-Wartung außer Betrieb nehmen, kommt es zu einer Störung der Servicelevels Ihres Netzwerks. Windows Server 2008-DCs bieten ein neues Feature, mit dem Sie den Verzeichnisdienst anhalten können, ohne den DC vollständig herunterzufahren.

Der NET STOP NTDS-Befehl hält ADDS auf einem Windows Server 2008-DC an. Wenn Sie dies tun, wird der Subsystemdienst für die lokale Sicherheitsautorität (Local Security Authority Subsystem Service, LSASS) auf dem DC weiter ausgeführt, doch alle zu ADDS gehörigen DLLs werden entladen, und der Verzeichnisdienst ist nicht mehr verfügbar. LSASS verhält sich dann im Wesentlichen so wie auf einem Mitgliedsserver, indem Domänenauthentifizierungsanforderungen an einen DC weitergeleitet werden. Da die DLLs, die ADDS behandeln, entladen sind, können Sie zu ADDS gehörige Patches anwenden oder eine Offlinedefragmentierung der DIT durchführen. ADDS wird dann einfach mit NET START NTDS gestartet. Für die Wiederherstellung der DIT nach einer Systemstatussicherung ist es jedoch immer noch erforderlich, im Verzeichnisdienst-Reparaturmodus zu starten.

Machen Sie sich unbedingt bewusst, dass der Verzeichnisdienst kein wirklicher Windows-Dienst ist. Er ist nach wie vor eine integrierte Komponente von LSASS, und Sie können LSASS nicht beenden, ohne den Computer herunterzufahren. Doch die Möglichkeit, den Verzeichnisdienst in Windows Server 2008 zu starten und zu beenden, ist eine praktische Option.

Sicherung und Wiederherstellung

Der gesamte Sicherungs- und Wiederherstellungsmechanismus wurde in Windows Server 2008 überarbeitet. Die Einzelheiten werden hier nicht erläutert, aber bei der neuen Windows Server-Sicherung gibt es einige Änderungen, die sich auf ADDS auswirken.

Windows Server-Sicherung ist eine volumebasierte Sicherungslösung, das heißt, es werden jeweils ganze Datenträgervolumes gesichert. Es werden nur Sicherungskopien auf Datenträgern (oder datenträgerähnlichen) Geräten erstellt. Bandunterstützung ist nicht vorhanden.

Es gibt eine Systemstatussicherungsoption für das WBADMIN-Befehlszeilensicherungsprogramm. Mithilfe des WBADMIN START SYSTEMSTATEBACKUP-Befehls können Sie jetzt ein Sicherungsabbild erstellen, das alle kritischen Systemdateien enthält, die zum Wiederherstellen von Active Directory auf einem Domänencontroller erforderlich sind. Es gibt zwar Potenzial für bis zu fünf Volumes im Sicherungssatz, doch die Volumes im Sicherungssatz enthalten dann nur die Dateien, die für eine Systemstatuswiederherstellung erforderlich sind. Noch unerfreulicher ist jedoch, dass Sie ab RC0-Build von Windows Server 2008 keine Systemstatussicherung auf einer Netzwerkfreigabe durchführen können. Zum Speichern von Systemstatussicherungsabbildern muss ein lokales Datenträgervolume verfügbar sein, und dieses Volume darf nicht Teil des Systemstatussicherungsvolumesatzes sein. Möglicherweise müssen Sie jedem Domänencontroller, auf dem Sie Systemstatussicherungen durchführen, ein neues Datenträgervolume hinzufügen.

Das Durchführen einer Systemstatuswiederherstellung ist einfach. Starten Sie einfach den DC im Verzeichnisdienst-Wiederherstellungsmodus, und führen Sie den Befehl WBADMIN START SYSTEMSTATERECOVERY aus. Das Ergebnis ist eine nicht autorisierend wiederhergestellte DIT, auf der Sie autorisierend bestimmte Objekte mithilfe von NTDSUTIL wiederherstellen können, genau wie dies in Windows Server 2003 der Fall war.

Ein Aspekt von Windows Server-Sicherung sollte besonders erwähnt werden: Sicherungsabbilder werden im Virtual Hard Disk (VHD)-Format gespeichert. Hierbei handelt es sich um dasselbe Format, das Microsoft Virtual Server 2005 zum Speichern virtueller Datenträgerabbilder verwendet. Folglich können Sie also ein mit Windows Server-Sicherung erstelltes Sicherungsabbild als Laufwerk in einem virtuellen Computer bereitstellen, der unter Microsoft Virtual Server ausgeführt wird. Dann können Sie den Sicherungsinhalt genau wie bei einem normalen Laufwerk durchsuchen!

Eine weitere Änderung in Bezug auf die ADDS-Sicherung ist die Möglichkeit, den Volumeschattenkopie-Dienst zum Erstellen von Active Directory-Snapshots zu einem bestimmten Zeitpunkt zu verwenden. Wenn Sie einen Snapshot mithilfe von NTDSUTIL erstellen, speichert der Volumeschattenkopie-Dienst das vorherige Abbild jedes Datenträgerblocks der DIT, bevor es von einem Updatevorgang überschrieben wird. Durch Kombinieren der gespeicherten vorherigen Abbilder mit der aktuellen Version der DIT kann der Volumeschattenkopie-Dienst unter sehr geringem Aufwand einen vollständigen Snapshot der DIT erstellen. Das Erstellen eines typischen Snapshots dauert unabhängig von der Größe der DIT nur ein paar Sekunden.

Für sich allein ist dies eine interessante Funktion, aber eigentlich nicht besonders nützlich. Doch in Windows Server 2008 umfasst ADDS ein Befehlszeilendienstprogramm namens DSAMAIN, wodurch das Snapshotabbild im schreibgeschützten Modus bereitgestellt werden kann. Dadurch wird, ähnlich einer ADLDS-Instanz, ein eigenständiger LDAP-Server bereitgestellt, der den Inhalt des Verzeichnisses zum Zeitpunkt des Snapshots enthält. Sie können das Verzeichnis mithilfe des LDP-Dienstprogramms oder anderer LDAP-Tools durchsuchen und Versionen der Verzeichnisobjekte von einem früheren Zeitpunkt abrufen.

SYSVOL-Replikation mit DFS-R

Windows Server 2003 R2 verfügte über einen überarbeiteten Dienst für ein verteiltes Dateisystem (Distributed File System, DFS), der einen völlig neuen Dateireplikationsmechanismus namens DFS-R umfasste. Er verwendet Remotedifferenzialkomprimierung, die den Dateireplikationsdatenverkehr wesentlich verringert, indem bestimmt wird, welche Blöcke einer Zieldatei repliziert werden müssen, um sie mit der Quelldatei zu synchronisieren. Doch Windows Server 2003 R2 verwendet immer noch den Dateireplikationsdienst (nicht DFS-R) zum Replizieren von SYSVOL zwischen Domänencontrollern. Aus diesem Grund war die SYSVOL-Replikation weiterhin Ursache von Problemen für Active Directory-Administratoren.

Beim Ausführen von Windows Server 2008 auf der Domänenfunktionsebene kann Windows Server 2008 SYSVOL mithilfe von DFS-R replizieren, wodurch die Geschwindigkeit und Stabilität der SYSVOL-Replikation verbessert wird. Aufgrund dessen ist es vernünftig, große Dateien in SYSVOL zu stellen, damit sie auf allen DCs verfügbar sind. Um DFS-R für SYSVOL zu verwenden, müssen Sie zunächst die alten SYSVOL-Daten mithilfe des DFSRMIG-Dienstprogramms nach DFS-R migrieren. Dieser Prozess umfasst vier Schritte:

• Erstellen der für DFS-R erforderlichen Active Directory-Objekte.
• Erstellen der neuen Dateistruktur für SYSVOL auf jedem Domänencontroller.
• Umschalten aller Domänencontroller für die Verwendung des neuen SYSVOL.
• Entfernen des alten SYSVOL.

Abhängig von der Größe des SYSVOL und der Anzahl vorhandener Domänencontroller kann dieser Prozess eine Weile dauern, doch die verbesserte Leistung und Zuverlässigkeit sind die Mühe wert.

Überwachen von Verbesserungen

Das Überwachungssystem in Active Directory für Windows Server 2003 hat gute und schlechte Seiten. Einerseits bietet es eine ziemlich umfassende, flexible und sichere Lösung zum Verfolgen von Änderungen im Verzeichnis. Andererseits gibt es die Ansicht, dass es bedeutende Probleme im Bereich der Benutzerfreundlichkeit aufweist.

Das Aktivieren der Überwachung von Verzeichnisänderungen auf einem Windows Server 2003-Domänencontroller läuft auf das Prinzip Alles oder Nichts hinaus – die Überwachung ist entweder ein- oder ausgeschaltet. Aufgrund des Volumens des Überwachungsdatenverkehrs auf einem ausgelasteten Unternehmens-DC kann die Überwachung daher unpraktisch werden. Das Konfigurieren des Überwachungssystems zum Produzieren der tatsächlich erforderlichen Meldungen durch Experimentieren mit einzelnen Sicherheitsbeschreibungen ist mühsam und fehleranfällig. Die Überwachungsmeldungen sind oft unverständlich und enthalten in vielen Fällen nicht die gewünschten Informationen, beispielsweise die Werte geänderter Attribute vorher und nachher. Außerdem ist das Sammeln, Korrelieren und Archivieren der Meldungen mehrerer Domänencontroller bei Verwendung der systemeigenen Windows-Tools eigentlich nicht durchführbar.

Das Verzeichnisdienstüberwachungssystem in Windows Server 2008 spricht einige dieser Probleme an. Zum einen gibt es vier neue Überwachungsunterkategorien zur Verzeichnisdienstüberwachung: „DS Access“, „DS Changes“, „DS Replication“ und „Detailed DS Replication“. Wenn Sie also nur Verzeichnisänderungen überwachen möchten, müssen Sie sich nicht durch alle Lese- und Replikationsereignisse durcharbeiten. Doch wenn Sie Objektlöschungen in das Überwachungsprotokoll aufnehmen wollen, müssen Sie „DS Access“ aktivieren. Dadurch werden Meldungen für alle DS-Objektzugriffe generiert, sodass im Grunde wieder zu viele Meldungen generiert werden. Außerdem ist es immer noch Ihre Aufgabe, die Sicherheitsbeschreibungen zum Generieren der Überwachungsmeldungen der für Sie wichtigen Objekte zu konfigurieren.

Die Überwachungsmeldungen wurden wesentlich bereinigt, sodass sie lesbar sind und die gewünschten Daten enthalten. Durch Verzeichnisänderungen werden jetzt Überwachungsprotokolleinträge generiert, die die alten und neuen Werte geänderter Attribute enthalten. Dies ist eine enorme Verbesserung. Der einzige Nachteil besteht darin, dass die alten und neuen Werte in separaten Überwachungsprotokolleinträgen erscheinen, sodass sie korreliert werden müssen, um die durchgeführte Änderung wirklich zu verstehen. Viele Add-On-Produkte zum Sammeln von Überwachungsprotokollen, einschließlich Microsoft-Überwachungssammeldienste, unterstützen eine solche Korrelation.

Verbesserungen der Benutzeroberfläche

Die Active Directory-Snap-Ins „Benutzer und Computer“, „Standorte und Dienste“ und „Domänen und Vertrauensstellungen“ waren zum Verwalten von Active Directory immer ausreichend. In Windows Server 2008 wurden die grundlegenden Verwaltungstools bereinigt und verfügen jetzt über einige praktische neue Features. Wenn Sie „Erweiterte Features“ aktivieren, zeigt das Dialogfeld „Eigenschaften“ für jedes Objekt eine zusätzliche Registerkarte mit der Bezeichnung „Attribut-Editor“ an. Dies ist die gleiche von ADSIEdit verwendete Attribut-Editorregisterkarte, mit der Sie alle Attribute des Objekts überprüfen und bearbeiten können. Die Registerkarte selbst bietet nun bessere Möglichkeiten zum Decodieren codierter Attribute, beispielsweise das userAccountControl-Attribut. Abbildung 8 zeigt, wie nahtlos der Attribut-Editor integriert ist.

Abbildung 8** Attribut-Editor in Active Directory-Benutzer und -Computer **(Klicken Sie zum Vergrößern auf das Bild)

Zusammenfassung

Neben den in diesem Artikel erörterten Hauptpunkten gibt es in ADDS in Windows Server 2008 noch viele andere Verbesserungen. KDC beispielsweise verwendet den 256-Bit-AES (Advanced Encryption Standard), wenn sich die Domäne auf der Windows Server 2008-Domänenfunktionsebene befindet. Sie können „Accidental Deletion Prevention“ (Zufällige Löschvorgänge verhindern) für Objekte aktivieren, indem Sie das entsprechende Kontrollkästchen auf der Objekt-Registerkarte für beliebige DS-Objekte markieren. Die Extensible Storage Engine, die den Datenverwaltungsdienst bereitstellt, wurde so verbessert, dass Ein-Bit-Fehlerkorrektur verwendet wird. Dadurch wird die Wahrscheinlichkeit verringert, dass ein Hardware- oder Softwarefehler im Datenträgersubsystem die DIT beschädigt. Der DNS-Dienst beginnt mit dem Verarbeiten von Anforderungen, noch bevor die DNS-Datenbank vollständig geladen wurde. Das DC-Locatormodul wurde so verbessert, dass es bei Nichtauffinden eines DC am gewünschten Standort versucht, einen DC am nächstgelegenen Standort zu suchen, statt einfach einen beliebigen, in der Domäne gefundenen DC zu verwenden. NTDSUTIL unterstützt jetzt RODCs und Volumeschattenkopie-Dienstsnapshots.

Windows Server 2008 bietet also eine wesentliche Anzahl von Verbesserungen in Active Directory-Domänendiensten. Insgesamt wird die Sicherheit und Verwaltbarkeit von ADDS hierdurch beträchtlich verbessert. Das Beste ist jedoch, dass zum Integrieren von Windows Server 2008 in Ihrer Active Directory-Umgebung keine Migration im großen Rahmen erforderlich ist. Vielmehr ist es ein einfacher und inkrementeller Prozess.

Gil Kirkpatrick ist CTO von NetPro und entwickelt seit 1996 Software für Active Directory. Zusammen mit Guido Grillenmeier von HP bietet er die beliebten Workshops zur Active Directory-Notfallwiederherstellung an. Gil Kirkpatrick ist darüber hinaus Gründer der Directory Experts Conference (www.dec2008.com).

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.