Active Directory.pdf - Gattner

Microsoft ® 

Windows Server 2008 

Active Directory – 

Die technische Referenz

Dieses Buch ist die deutsche Übersetzung von: 

Stan Reimer, Conan Kezema, Mike Mulcare, Byron Wright, Microsoft Windows® Server® 2008 Active Directory® 

Resource Kit 

Microsoft Press, Redmond, Washington 98052-6399 

Copyright 2008 by Microsoft Corporation 

Das in diesem Buch enthaltene Programmmaterial ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. 

Autoren, Übersetzer und der Verlag übernehmen folglich keine Verantwortung und werden keine daraus folgende 

oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programmmaterials oder Teilen 

davon entsteht. 

Das Werk einschließlich aller Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des 

Urheberrechts ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, 

Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 

Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen 

sowie E-Mail-Adressen und Logos sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit 

tatsächlichen Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen, E-Mail-Adressen und Logos 

ist rein zufällig. 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 

10 09 08 

ISBN 978-3-86645-925-X 

© Microsoft Press Deutschland 

(ein Unternehmen der Microsoft Deutschland GmbH) 

Konrad-Zuse-Str. 1, D-85716 Unterschleißheim 

Alle Rechte vorbehalten 

Übersetzung & Grafik: Lemoine International GmbH, Köln 

(www.lemoine-international.com) 

Satz: Jan Carthaus Publishing, Radolfzell (www.carthaus.com) 

Umschlaggestaltung: Hommer Design GmbH, Haar (www.HommerDesign.com) 

Layout und Gesamtherstellung: Kösel, Krugzell (www.KoeselBuch.de)

Für die drei wunderbaren Frauen in meinem Leben: Rhonda, Angela und Amanda. 

Eure Liebe und Unterstützung spornen mich immer wieder an. 

Stan Reimer 

Dieses Buch ist der Liebe meines Lebens, Rhonda, und unseren beiden Söhnen, 

Brennan und Liam, gewidmet. Danke für eure ständige Unterstützung und dafür, dass Ihr allem, 

was ich tue, einen Sinn gebt. Außerdem widme ich dieses Buch meiner übrigen Familie, 

die sich noch immer fragt, womit ich eigentlich meinen Lebensunterhalt bestreite. 

Conan Kezema 

Für meine Familie: Nancy, James, Sean und Patrick. 

Ewigen Dank für eure Ermutigung und Unterstützung. 

Mike Mulcare 

Tracey, Samantha und Michelle, Ihr seid für mich der Grund, weiterzumachen. 

Darrin, danke, dass du die Stellung gehalten hast. 

Byron Wright

Inhaltsverzeichnis 

V 

Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX 

Über dieses Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX 

Teil I – Windows Server 2008 Active Directory – Überblick . . . . . . . . . . . . . . . . . . . . . XIX 

Teil II – Entwerfen und Implementieren von Windows Server 2008 Active Directory . XX 

Teil III – Verwalten von Windows Server 2008 Active Directory . . . . . . . . . . . . . . . . . XX 

Teil IV – Warten von Windows Server 2008 Active Directory . . . . . . . . . . . . . . . . . . . . XXI 

Teil V – Identitäts- und Zugriffsverwaltung mit Active Directory . . . . . . . . . . . . . . . . . XXI 

Konventionen in diesem Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXII 

Hinweise für den Leser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXII 

Abschnitte mit Zusatzinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXII 

Befehlszeilenbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII 

Begleit-CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII 

Verwaltungsskripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII 

Verwenden der Skripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIV 

Zusätzliche Onlineinhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIV 

Supporthinweise für die technische Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXV 

Teil I: Windows Server 2008 Active Directory – Überblick . . . . . . . . . . . . . . . . . . . . . 1 

Kapitel 1: Neuerungen in Active Directory für Windows Server 2008 . . . . . . . . . . . . . . . . . . 3 

Neuerungen in den Active Directory-Domänendiensten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

Schreibgeschützte Domänencontroller (Read-Only Domain Controllers, RODC) . . . . . 3 

AD DS-Überwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Fein abgestimmte Kennwortrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Neustartmöglichkeit der Active Directory-Domänendienste . . . . . . . . . . . . . . . . . . . . . . 8 

Datenbankbereitstellungstool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Verbesserungen der Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Zusätzliche Active Directory-Dienstrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Active Directory-Zertifikatdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Active Directory-Verbunddienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Active Directory Lightweight Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Active Directory-Rechteverwaltungsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Kapitel 2: Active Directory-Domänendienstkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Physische Struktur der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Verzeichnisdatenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

Domänencontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Globale Katalogserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

V 

XVII

VI 


Schreibgeschützte Domänencontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Betriebsmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

Übertragen von Betriebsmasterrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

Logische Struktur der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

AD DS-Partitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

Domänen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

Gesamtstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

Vertrauensstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

Standorte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 


Zusätzliche Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

Verwandte Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

Ressourcen auf der CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Verwandte Hilfethemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Kapitel 3: Active Directory-Domänendienste und DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

Integration von DNS in die AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

SVR-Ressourceneinträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

Von AD DS-Domänencontrollern registrierte SRV-Einträge . . . . . . . . . . . . . . . . . . . . . 63 

DNS-Locatordienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

Automatische Standortabdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

AD DS-integrierte Zonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Vorteile der Nutzung AD DS-integrierter Zonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Standardanwendungspartitionen für DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

Verwalten AD DS-integrierter Zonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

Integrieren von DNS-Namespaces in AD DS-Domänen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

DNS-Delegierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Weiterleitungen und Stammhinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

Problembehandlung bei der DNS- und AD DS-Integration . . . . . . . . . . . . . . . . . . . . . . . 85 

Problembehandlung für DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

Problembehandlung bei der Registrierung von SRV-Einträgen . . . . . . . . . . . . . . . . . . . 88 


Empfohlene Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 


Verwandte Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 




Kapitel 4: Active Directory-Domänendienstreplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

AD DS-Replikationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

Replikationsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

Aktualisierungstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

Replizieren von Änderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 

Replizieren des Verzeichnisses SYSVOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104


VII 

Standortinterne und standortübergreifende Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

Standortinterne Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

Standortübergreifende Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

Replikationslatenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 

Dringende Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

Erstellen der Replikationstopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Konsistenzprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

Verbindungsobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

Standortinterne Replikationstopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 

Replikation des globalen Katalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 

Standortübergreifende Replikationstopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

RODCs und die Replikationstopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 

Konfigurieren der standortübergreifenden Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 

Erstellen zusätzlicher Standorte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

Standortverknüpfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 

Standortverknüpfungsbrücken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 

Replikationstransportprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

Konfigurieren von Bridgeheadservern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

Problembehandlung bei der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

Verfahren für die Problembehandlung bei der AD DS-Replikation . . . . . . . . . . . . . . . . 131 

Tools für die Problembehandlung bei der AD DS-Replikation . . . . . . . . . . . . . . . . . . . . 133 








Teil II: Entwerfen und Implementieren von Windows Server 2008 

Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

Kapitel 5: Entwerfen der Active Directory-Domänendienstestruktur . . . . . . . . . . . . . . . . . . . 141 

Definieren der Verzeichnisdienstanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

Definieren von Geschäftsanforderungen und technischen Anforderungen . . . . . . . . . . . 143 

Dokumentieren der aktuellen Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

Entwerfen der Gesamtstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

Gesamtstrukturen und der AD DS-Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

Einzelne oder mehrere Gesamtstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

Entwerfen von Gesamtstrukturen für die AD DS-Sicherheit . . . . . . . . . . . . . . . . . . . . . . 158 

Modelle für den Gesamtstrukturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

Definieren des Gesamtstrukturbesitzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

Richtlinien zur Kontrolle von Gesamtstrukturänderungen . . . . . . . . . . . . . . . . . . . . . . . . 164 

Entwerfen der Integration mehrerer Gesamtstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 

Entwerfen gesamtstrukturübergreifender Vertrauensstellungen . . . . . . . . . . . . . . . . . . . 165 

Entwerfen der Verzeichnisintegration zwischen Gesamtstrukturen . . . . . . . . . . . . . . . . . 169

VIII 


Entwerfen der Domänenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

Festlegen der Domänenanzahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

Entwerfen der Gesamtstruktur-Stammdomäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

Entwerfen von Domänenhierarchien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

Domänenstrukturen und -vertrauensstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 

Ändern der Domänenhierarchie nach der Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . 177 

Definieren des Domänenbesitzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 

Entwerfen von Domänen- und Gesamtstrukturfunktionsebenen . . . . . . . . . . . . . . . . . . . . . . . 178 

Auf Domänenfunktionsebene aktivierte Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

Auf Gesamtstrukturfunktionsebene aktivierte Funktionen . . . . . . . . . . . . . . . . . . . . . . . 179 

Implementieren einer Domänen- und Gesamtstrukturfunktionsebene . . . . . . . . . . . . . . . 180 

Entwerfen der DNS-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Entwurf des Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Entwerfen der Struktur von Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

Organisationseinheiten und der AD DS-Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

Entwerfen einer OU-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Erstellen eines OU-Entwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 

Entwerfen der Standorttopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 

Standorte und der AD DS-Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 

Erstellen eines Standortentwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 

Erstellen eines Replikationsentwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

Entwerfen von Serverstandorten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 






Kapitel 6: Installieren der Active Directory-Domänendienste . . . . . . . . . . . . . . . . . . . . . . . . . 213 

Voraussetzungen für die AD DS-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 

Festplattenspeicheranforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

Netzwerkkonnektivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

Administratorrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

Betriebssystemkompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

Grundlegendes zu den AD DS-Installationsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 

Aufgaben der Erstkonfiguration und Assistent zum Hinzufügen von Rollen . . . . . . . . . 218 

Server-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 

Installieren von Active Directory-Domänendiensten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 

Unbeaufsichtigte Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 

Verwenden des Assistenten zum Installieren von Active Directory-Domänendiensten . . . . . 221 

Bereitstellungskonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

Benennen der Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

Konfigurieren der Funktionsebenen von Windows Server 2008 . . . . . . . . . . . . . . . . . . . 224 

Weitere Domänencontrolleroptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 

Dateispeicherorte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228


IX 

Abschließen der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

Überprüfen der AD DS-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

Durchführen einer unbeaufsichtigten Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 

Installieren von Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

Bereitstellen schreibgeschützter Domänencontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

Server Core-Installation unter Windows Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

Bereitstellen von RODCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

Entfernen der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

Entfernen von zusätzlichen Domänencontrollern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 

Entfernen des letzten Domänencontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 

Unbeaufsichtigtes Entfernen der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

Erzwungenes Entfernen eines Windows Server 2008-Domänencontrollers . . . . . . . . . . 238 





Kapitel 7: Migrieren auf die Active Directory-Domänendienste . . . . . . . . . . . . . . . . . . . . . . . 243 

Migrationsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 

Das Verfahren der Domänenaktualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

Domänenumstrukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Festlegen der Migrationsoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

Aktualisieren der Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

Durchführen der Aktualisierung von Windows 2000 Server und 

Windows Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

Umstrukturieren der Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 

Migration zwischen Gesamtstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 

Migration innerhalb der Gesamtstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

Konfigurieren von Vertrauensstellungen zwischen Gesamtstrukturen . . . . . . . . . . . . . . . . . . 262 






Teil III: Verwalten von Windows Server 2008 Active Directory . . . . . . . . . . . . . . . . . 267 

Kapitel 8: Active Directory-Domänendienstsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

AD DS-Sicherheitsgrundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

Sicherheitsprinzipale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

Zugriffssteuerungslisten (ACLs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 

Zugriffstoken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 

Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 

Kerberos-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

Einführung in Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 

Kerberos-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 

Delegieren der Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

X 


Konfigurieren von Kerberos unter Windows Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . 289 

Integration in die Public Key-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

Integration in Smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

Interoperabilität mit anderen Kerberos-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 

Problembehandlung für Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 

NTLM-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 

Implementieren der Sicherheit für Domänencontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 

Verringern der Angriffsfläche von Domänencontrollern . . . . . . . . . . . . . . . . . . . . . . . . . 301 

Konfigurieren der Standard-Domänencontrollerrichtlinie . . . . . . . . . . . . . . . . . . . . . . . . 304 

Konfigurieren von SYSKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 

Entwerfen sicherer administrativer Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 








Kapitel 9: Delegieren der Active Directory-Domänendiensteverwaltung . . . . . . . . . . . . . . . . 319 

Active Directory-Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 

Zugreifen auf Active Directory-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 

Auswerten von Verweigern- und Zulassen-ACEs in einer DACL . . . . . . . . . . . . . . . . . 322 

Active Directory-Objektberechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 

Standardberechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 

Spezielle Berechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 

Berechtigungsvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 

Effektive Berechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 

Besitz von Active Directory-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 

Delegieren von Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 

Überwachen der Verwendung von Administratorrechten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 

Konfigurieren der Überwachungsrichtlinie für Domänencontroller . . . . . . . . . . . . . . . . 342 

Konfigurieren der Überwachung für Active Directory-Objekte . . . . . . . . . . . . . . . . . . . 344 

Tools für die delegierte Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 

Anpassen der Microsoft Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 

Planen der delegierten Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 




Kapitel 10: Verwalten von Active Directory-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

Verwalten von Benutzern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

Benutzerobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 

inetOrgPerson-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

Kontaktobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 

Dienstkonten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359


XI 

Verwalten von Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 

Gruppentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 

Gruppenbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 

Standardgruppen in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 

Spezialidentitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 

Erstellen eines Sicherheitsgruppenentwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 

Verwalten von Computern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 

Verwalten von Druckerobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 

Veröffentlichen von Druckern in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 

Nachverfolgen des Druckerstandorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 

Verwalten von veröffentlichten freigegebenen Ordnern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 

Automatisieren der Active Directory-Objektverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 

Befehlszeilenprogramme für die Verwaltung von Active Directory . . . . . . . . . . . . . . . . 379 

Verwenden von LDIFDE und CSVDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 

Verwenden von VBScript für die Verwaltung von Active Directory-Objekten . . . . . . . 382 







Kapitel 11: Einführung in Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 

Gruppenrichtlinien – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 

Funktionsweise von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 

Neuerungen in Windows Server 2008-Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . 397 

Gruppenrichtlinienkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 

Übersicht über den Gruppenrichtliniencontainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 

Komponenten der Gruppenrichtlinienvorlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 

Replikation der Gruppenrichtlinienobjekt-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 402 

Gruppenrichtlinienverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 

Verarbeitung von Gruppenrichtlinienobjekten auf Clients . . . . . . . . . . . . . . . . . . . . . . . 404 

Anfängliche Verarbeitung von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . . . . 406 

Aktualisierungen von Gruppenrichtlinienobjekten im Hintergrund . . . . . . . . . . . . . . . . . 408 

Beziehung zwischen dem Verlauf eines Gruppenrichtlinienobjekts und Gruppenrichtlinienaktualisierungen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 

Ausnahmen bei den standardmäßigen Zeitpunkten der Hintergrundverarbeitung . . . . . . 411 

Implementieren von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 

Übersicht über die Konsole Gruppenrichtlinienverwaltung . . . . . . . . . . . . . . . . . . . . . . 417 

Erstellen und Verknüpfen von Gruppenrichtlinienobjekten in der Konsole 

Gruppenrichtlinienverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 

Ändern des Verarbeitungsbereichs von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . 420 

Delegieren der Verwaltung von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . . . 429 

Implementieren von Gruppenrichtlinien zwischen Domänen und Gesamtstrukturen . . . 431 

Verwalten von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 

Sichern und Wiederherstellen von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . 432 

Kopieren von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

XII 


Importieren der Einstellungen von Gruppenrichtlinienobjekten . . . . . . . . . . . . . . . . . . . 435 

Modellieren von und Erstellen von Berichten zu Gruppenrichtlinienergebnissen . . . . . . 435 

Erstellen von Skripts für die Gruppenrichtlinienverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

Planen einer Gruppenrichtlinienimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 

Fehlerbehebung bei Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 




Kapitel 12: Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops . . . . 449 

Desktopverwaltung mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 

Verwalten von Benutzerdaten und Profileinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 

Verwalten von Benutzerprofilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 

Einsetzen von Gruppenrichtlinien zum Verwalten servergespeicherter Benutzerprofile 460 

Ordnerumleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 

Administrative Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 

Grundlegendes zu administrativen Vorlagendateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 

Verwalten domänenbasierter Vorlagendateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 

Empfohlene Vorgehensweisen für die Verwaltung von ADMX-Vorlagendateien . . . . . 475 

Verwalten der Benutzerumgebung mithilfe von Skripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 

Bereitstellen von Software mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . 478 

Windows Installer-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 

Bereitstellen von Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 

Verteilen von nicht mit Windows Installer installierten Anwendungen mithilfe von 

Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 

Konfigurieren von Softwarepaketeigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 

Konfigurieren von Windows Installer mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . 491 

Planen der Gruppenrichtlinie für die Softwareinstallation . . . . . . . . . . . . . . . . . . . . . . . . 493 

Einschränkungen beim Einsatz von Gruppenrichtlinien zum Verwalten von Software . 494 

Übersicht über Gruppenrichtlinieneinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 

Das Feature Gruppenrichtlinieneinstellungen im Vergleich zu 

Richtlinieneinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 

Gruppenrichtlinieneinstellungen in Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 

Optionen für das Feature Gruppenrichtlinieneinstellungen . . . . . . . . . . . . . . . . . . . . . . . 500 




Auf der Begleit-CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 

Kapitel 13: Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit . . . . . . . . . . . . 505 

Konfigurieren der Domänensicherheit mit Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . 505 

Übersicht über die Standarddomänenrichtlinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 

Übersicht über die Standardrichtlinie für Domänencontroller . . . . . . . . . . . . . . . . . . . . . 511 

Neuerstellen der Standard-GPOs für eine Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 

Fein abgestimmte Kennwortrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 

Verstärken der Serversicherheit mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . 522 

Richtlinien für Softwareeinschränkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525


XIII 

Konfigurieren der Netzwerksicherheit mit Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . 528 

Konfigurieren der Sicherheit für verkabelte Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . 529 

Konfigurieren der Sicherheit für drahtlose Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . 531 

Konfigurieren von Windows-Firewall und IPsec-Sicherheit . . . . . . . . . . . . . . . . . . . . . . 532 

Konfigurieren von Sicherheitseinstellungen anhand von Sicherheitsvorlagen . . . . . . . . . . . . 534 

Bereitstellen von Sicherheitsvorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 




Teil IV: Warten von Windows Server 2008 Active Directory . . . . . . . . . . . . . . . . . . . . 541 

Kapitel 14: Überwachen und Warten von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 

Überwachen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 

Gründe für die Überwachung von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 

Überwachen von Serverzuverlässigkeit und -leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 

Überwachen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 

Zu überwachende Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 

Überwachen der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 

Verwalten der Active Directory-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 

Sammeln veralteter Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 

Onlinedefragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 

Offlinedefragmentierung der Active Directory-Datenbank . . . . . . . . . . . . . . . . . . . . . . . 569 

Verwalten der Active Directory-Datenbank mithilfe des Tools Ntdsutil . . . . . . . . . . . . . 570 




Kapitel 15: Active Directory-Notfallwiederherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 

Vorbereiten auf einen Ausfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 

Active Directory-Datenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 

Sichern von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 

Notwendigkeit von Sicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 

Tombstone-Ablaufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 

Sicherungshäufigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 

Wiederherstellen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 

Wiederherstellen von Active Directory durch Erstellen eines neuen 

Domänencontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 

Nicht autorisierende Wiederherstellung von Active Directory . . . . . . . . . . . . . . . . . . . . 587 

Autorisierendes Wiederherstellen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 591 

Wiederherstellen von Gruppenmitgliedschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 

Wiederbeleben von Tombstone-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597 

Verwenden des Active Directory-Datenbankbereitstellungstools . . . . . . . . . . . . . . . . . . 599 

Wiederherstellen von SYSVOL-Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 

Wiederherstellen von Betriebsmaster- und globalen Katalogservern . . . . . . . . . . . . . . . 602 


Empfohlene Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

XIV 





Teil V: Identitäts- und Zugriffsverwaltung mit Active Directory . . . . . . . . . . . . . . . . 609 

Kapitel 16: Active Directory Lightweight Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . 611 

AD LDS – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 

AD LDS – Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 

AD LDS – Bereitstellungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 

AD LDS – Architektur und Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614 

AD LDS – Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614 

AD LDS – Instanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 

Verzeichnispartitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 

AD LDS – Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 

AD LDS – Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624 

Implementieren der AD LDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630 

Konfigurieren von Instanzen und Anwendungspartitionen . . . . . . . . . . . . . . . . . . . . . . . 630 

AD LDS-Verwaltungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 

Konfigurieren der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638 

Sichern und Wiederherstellen der AD LDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640 

Konfigurieren der AD DS- und AD LDS-Synchronisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 643 







Kapitel 17: Active Directory-Zertifikatdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 

Active Directory-Zertifikatdienste – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 

Komponenten der Public Key-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650 

Zertifizierungsstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656 

Szenarien für die Bereitstellung der Zertifikatdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . 658 

Implementieren der AD CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658 

Installieren von AD CS-Stammzertifizierungsstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 659 

Installieren untergeordneter AD CS-Zertifizierungsstellen . . . . . . . . . . . . . . . . . . . . . . . 661 

Konfigurieren der Webregistrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661 

Konfigurieren der Zertifikatsperrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 

Verwalten der Schlüsselarchivierung und -wiederherstellung . . . . . . . . . . . . . . . . . . . . . 668 

Verwalten von Zertifikaten in den AC CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672 

Konfigurieren von Zertifikatvorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673 

Konfigurieren der automatischen Zertifikatregistrierung . . . . . . . . . . . . . . . . . . . . . . . . . 677 

Verwalten der Akzeptanz von Zertifikaten mithilfe von Gruppenrichtlinien . . . . . . . . . 679 

Konfigurieren der Serverspeicherung von Anmeldeinformationen . . . . . . . . . . . . . . . . . 680 

Entwerfen einer AD CS-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 

Entwerfen einer Zertifizierungsstellenhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 

Entwerfen von Zertifikatvorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685


XV 

Entwerfen der Zertifikatverteilung und -sperrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687 






Kapitel 18: Active Directory-Rechteverwaltungsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691 

Überblick über die AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 

AD RMS-Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 

AD RMS-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694 

Funktionsweise der AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 

AD RMS-Bereitstellungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 

Implementieren der AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 

Vor der Installation der AD RMS zu berücksichtigende Aspekte . . . . . . . . . . . . . . . . . . 702 

Installieren von AD RMS-Clustern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703 

Konfigurieren des AD RMS-Dienstverbindungspunkts . . . . . . . . . . . . . . . . . . . . . . . . . . 707 

Arbeiten mit AD RMS-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 

Verwalten der AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 

Verwalten von Vertrauensrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 

Verwalten von Vorlagen für Benutzerrechterichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . 720 

Konfigurieren von Ausschlussrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 

Konfigurieren von Sicherheitsrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726 

Anzeigen von Berichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728 




Kapitel 19: Active Directory-Verbunddienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731 

Überblick über die AD FS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 

Identitätsverbund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 

Webdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 

AD FS-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 

AD FS-Bereitstellungsentwürfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 

Implementieren der AD FS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 

AD FS-Bereitstellungsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 

Implementieren der AD FS in einem Federated-Web-SSO-Entwurf . . . . . . . . . . . . . . . . 751 

Konfigurieren des Kontopartner-Verbunddienstes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 

Konfigurieren von AD FS-Komponenten des Ressourcenpartners . . . . . . . . . . . . . . . . . 766 

Konfigurieren von AD FS für Windows NT-Token-basierte Anwendungen . . . . . . . . . 770 

Implementieren eines Web-SSO-Entwurfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772 

Implementieren eines Federated-Web-SSO-Entwurfs mit 

Gesamtstrukturvertrauensstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773 


Empfohlene Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

XVI 





Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 

Über die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 

Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

Danksagung 

XVII 

von Stan Reimer (für das Team): 

Zunächst möchte ich mich bei meinen Koautoren für ihre harte Arbeit an diesem Buch bedanken. Als 

ich gebeten wurde, dieses Projekt zu leiten, habe ich nach geeigneten Leuten gesucht, die mit mir 

zusammen dieses Buch schreiben sollten. Ich hätte kein besseres Team finden können. 

Außerdem möchte ich mich bei den Mitarbeitern von Microsoft Press bedanken. Zu diesem Team gehören 

Martin DelRe, der Programm-Manager, der uns unaufhörlich dazu gedrängt hat, dieses Projekt 

durchzuführen, bis wir letztendlich zugestimmt haben, Karen Szall, die Content-Development-Managerin, 

und Maureen Zimmerman, die Content-Projektmanagerin. Ich bin sicher, dass unsere Probleme, 

den Zeitplan einzuhalten, dieser Gruppe einige Kopfschmerzen bereitet haben. Dennoch waren sie stets 

erstaunlich hilfsbereit und ermutigend. Maureen hatte die unglaubliche Gabe, uns an Fälligkeitstermine 

zu erinnern, ohne uns auf die Nerven zu gehen. 

Unser Dank gilt auch Bob Dean, dem technischen Editor, für seine wertvollen Kommentare. Die Produktion 

dieses Buches wurde professionell von Custom Editorial Productions Inc. durchgeführt, mit 

Linda Allen als Projekt-Managerin, Cecilia Munzenmaier als Redakteurin und vielen anderen, die im 

Hintergrund mitgeschuftet haben. Während wir als Autoren wir den gesamten Spaß am Anfang des Projekts 

haben, müssen diese Leute noch lange daran weiter arbeiten, nachdem wir längst fertig sind. 

Eine technische Referenz entsteht nicht ohne die intensive Zusammenarbeit mit den Produktgruppen 

bei Microsoft und anderen technischen Experten wie Directory Services-MVPs. Alle Kapitel in diesem 

Buch wurden von diesen Experten überprüft, und viele von ihnen haben zu den Hinweisen unter 

„Direkt von der Quelle“, „Praxistipp“ und „So funktioniert es“ beigetragen, die Sie bei der Lektüre 

dieses Buches schätzen werden. Zu diesen Editoren und Mitwirkenden gehören: 

James McColl, Mike Stephens, Moon Majumdar, Judith Herman, Mark Gray, Linda Moore, Greg 

Robb, Barry Hartman, Christiane Soumahoro, Gautam Anand, Michael Hunter, Alain Lissoir, Yong 

Liang, David Hastie, Teoman Smith, Brian Lich, Matthew Rimer, David Fisher, Bob Drake, Rob 

Greene, Andrej Budja, Rob Lane, Gregoire Guetat, Donovan Follette, Pavan Kompelli, Sanjeev Balarajan, 

Fatih Colgar, Brian Desmond, Jose Luis Auricchio, Darol Timberlake, Peter Li, Elbio Abib, Ashish 

Sharma, Nick Pierson, Lu Zhao und Antonio Calomeni. 

von Conan Kezema: 

Besonderer Dank gilt meinen Koautoren für ihre harte Arbeit an diesem Buch. Außerdem möchte ich 

Stan für die vielen Chancen danken, die er mir im Laufe der Jahre geboten hat; er ist ein wunderbarer 

Freund und Mentor.

XIX 

Einführung 

Willkommen zu Windows Server 2008 Active Directory – Die technische Referenz, der umfassenden 

Informationsquelle für das Entwerfen und Implementieren von Active Directory in Windows Server 

2008. 

Das Buch Windows Server 2008 Active Directory – Die technische Referenz ist eine umfassende technische 

Ressource für Planung, Bereitstellung, Wartung und Problembehandlung einer Active Directory-Infrastruktur 

in Windows Server 2008. Die vorliegende technische Referenz richtet sich vornehmlich 

an erfahrene IT-Experten, die in mittelständischen und großen Organisationen tätig sind. 

Das vorliegende Buch stellt jedoch auch für alle anderen Benutzer eine wertvolle Informationsquelle 

dar, die mehr über die Implementierung und Verwaltung von Active Directory in Windows Server 

2008 erfahren möchten. 

Eine Neuerung in Windows Server 2008 Active Directory besteht darin, dass der Begriff Active 

Directory nun weit mehr umfasst als in vorherigen Versionen dieses Verzeichnisdienstes. Der Active 

Directory-Verzeichnisdienst von Windows 2000 und Windows Server 2003 erhält jetzt die Bezeichnung 

Active Directory-Domänendienste (Active Directory Domain Services, AD DS), und unter dem 

Oberbegriff Active Directory werden ab sofort verschiedene weitere Verzeichnisdienstkomponenten 

zusammengefasst. Hierzu zählen die Active Directory Lightweight Directory Services (AD LDS), die 

Active Directory-Zertifikatdienste (Active Directory Certificate Services, AD CS), die Active Directory-Rechteverwaltungsdienste 

(Active Directory Rights Management Services, AD RMS) sowie die 

Active Directory-Verbunddienste (Active Directory Federation Services, AD FS). 

In dieser technischen Referenz finden Sie umfangreiche technische Informationen zur Funktionsweise 

von Active Directory in Windows Server 2008. Zusätzlich werden detaillierte Informationen 

zur Implementierung und Wartung der Active Directory-Infrastruktur bereitgestellt. Darüber hinaus 

finden Sie in diesem Buch zahlreiche Hinweise von Mitgliedern des Active Directory-Produktteams, 

Active Directory-Experten von Microsoft und Verzeichnisdienst-MVPs. Diese Hinweise enthalten 

weiterführende Informationen zur Funktionsweise von Active Directory, Empfehlungen für das Entwerfen 

und Implementieren von Active Directory sowie nützliche Tipps zur Problembehandlung. Die 

Begleit-CD zu diesem Buch schließlich enthält Bereitstellungstools, Vorlagen und zahlreiche Beispielskripts, 

die Sie direkt verwenden oder anpassen können, um verschiedene Aufgaben bei der Verwaltung 

einer Active Directory-Unternehmensumgebung zu automatisieren. 

Über dieses Buch 

Das vorliegende Buch gliedert sich in fünf Teile mit den folgenden Kapiteln: 

Teil I – Windows Server 2008 Active Directory – Überblick 

• Kapitel 1 – Neuerungen in Active Directory für Windows Server 2008 Dieses Kapitel bietet einen 

Überblick über die neuen Features in Windows Server 2008. Wenn Sie bereits mit Windows Server 

2003 Active Directory vertraut sind, können Sie sich anhand dieses Kapitels einen schnellen 

Überblick über das neue Material verschaffen, das in diesem Buch abgedeckt wird.

XX 

Einführung 

• Kapitel 2 – Active Directory-Domänendienstkomponenten Dieses Kapitel bietet einen Überblick über 

die Active Directory-Domänendienste. Wenn Sie sich mit dem Thema Active Directory bisher 

noch nicht beschäftigt haben, können Sie sich anhand dieses Kapitels mit den Begriffen und Konzepten 

der Active Directory-Domänendienste vertraut machen. 

• Kapitel 3 – Active Directory-Domänendienste und DNS Eine der wichtigsten Komponenten zur effektiven 

Nutzung der Active Directory-Domänendienste ist eine sinnvoll implementierte DNS-Infrastruktur. 

In diesem Kapitel erfahren Sie, was Sie bei einer solchen Implementierung 

berücksichtigen müssen. 

• Kapitel 4 – Active Directory-Domänendienstreplikation Die Arbeit mit den Active Directory-Domänendiensten 

setzt das Verständnis der Replikation voraus. In diesem Kapitel werden sämtliche 

Details zur Funktionsweise der AD DS-Replikation und deren Konfiguration bereitgestellt. 

Teil II – Entwerfen und Implementieren von Windows Server 2008 Active 

Directory 

• Kapitel 5 – Entwerfen der Active Directory-Domänendienstestruktur Vor der Bereitstellung der Active 

Directory-Domänendienste müssen Sie einen Entwurf erstellen, der den Anforderungen Ihrer 

Organisation gerecht wird. Dieses Kapitel bietet sämtliche Informationen, die Sie bei der Planung 

benötigen. 

• Kapitel 6 – Installieren der Active Directory-Domänendienste Die Installation der Active Directory- 

Domänendienste auf einem Windows Server 2008-Computer ist unkompliziert, bei der Installation 

gibt es jedoch verschiedene Auswahlmöglichkeiten. Dieses Kapitel beschreibt alle verfügbaren 

Optionen und die Gründe für deren Verwendung. 

• Kapitel 7 – Migrieren auf die Active Directory-Domänendienste Viele Organisationen verwenden 

bereits eine Vorgängerversion von Active Directory. Dieses Kapitel beschreibt, wie Windows Server 

2008-Domänencontroller in einer solchen Umgebung bereitgestellt werden und eine Active 

Directory-Umgebung auf Windows Server 2008 migriert wird. 

Teil III – Verwalten von Windows Server 2008 Active Directory 

• Kapitel 8 – Active Directory-Domänendienstsicherheit Die Active Directory-Domänendienste übernehmen 

in vielen Organisationen die grundlegenden Netzwerkauthentifizierungs- und Autorisierungsdienste. 

Dieses Kapitel beschreibt die Funktionsweise der AD DS-Sicherheit und das 

Vorgehen zum Schutz Ihrer AD DS-Umgebung. 

• Kapitel 9 – Delegieren der Active Directory-Domänendiensteverwaltung Eine der Optionen bei der AD 

DS-Implementierung besteht darin, verschiedene Verwaltungsaufgaben an andere Administratoren 

zu delegieren, ohne ihnen Berechtigungen auf Domänenebene zu gewähren. Dieses Kapitel 

beschreibt, wie AD DS-Berechtigungen funktionieren und wie sie delegiert werden können. 

• Kapitel 10 – Verwalten von Active Directory-Objekten Eine der Hauptaufgaben eines AD DS-Administrators 

besteht in der Verwaltung von AD DS-Objekten wie Benutzern, Gruppen und Organisationseinheiten 

(Organizational Units, OUs). Dieses Kapitel behandelt die Verwaltung einzelner 

Objekttypen, stellt jedoch zusätzlich auch Informationen dazu bereit, wie eine große Anzahl an 

Objekten mithilfe von Skripts verwaltet werden kann.

Über dieses Buch 

XXI 

• Kapitel 11 – Einführung in Gruppenrichtlinien Gruppenrichtlinien stellen eine zentrale Komponente 

in einem Windows Server 2008-Verwaltungssystem dar. Mithilfe von Gruppenrichtlinien können 

Sie zahlreiche Desktopeinstellungen und die Sicherheit konfigurieren. In diesem Kapitel wird 

neben dem Zweck von Gruppenrichtlinien erläutert, wie Sie Gruppenrichtlinienobjekte anwenden 

und filtern. 

• Kapitel 12 – Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops Eine der wichtigen 

Aufgaben, die mithilfe von Gruppenrichtlinien durchgeführt werden können, ist die Konfiguration 

von Benutzerdesktops. In Windows Server 2008 und Windows Vista stehen mehrere 

Tausend Gruppenrichtlinieneinstellungen zur Verfügung. Dieses Kapitel beschreibt nicht nur, wie 

Richtlinien angewendet werden, sondern stellt darüber hinaus auch die wichtigsten Richtlinien 

vor. 

• Kapitel 13 – Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit Ein weiterer wichtiger 

Aspekt in Bezug auf Gruppenrichtlinien ist die Anwendung von Sicherheitseinstellungen. Hierzu 

zählen neben Einstellungen, die auf alle Benutzer und Computer in der Domäne angewendet werden, 

auch Einstellungen, die nur für einzelne Computer oder Benutzer konfiguriert werden. Dieses 

Kapitel bietet detaillierte Informationen dazu, wie Sie die Sicherheit mithilfe von Gruppenrichtlinien 

konfigurieren. 

Teil IV – Warten von Windows Server 2008 Active Directory 

• Kapitel 14 – Überwachen und Warten von Active Directory Dieses Kapitel bereitet Sie auf die Wartung 

Ihrer Active Directory-Infrastruktur nach deren Bereitstellung vor. Sie erfahren, wie Sie Ihre 

AD DS-Umgebung überwachen und wie Sie eine AD DS-Domäne warten. 

• Kapitel 15 – Active Directory-Notfallwiederherstellung Aufgrund der zentralen Rolle, welche die 

Active Directory-Domänendienste in vielen Unternehmen innehat, ist es von grundlegender 

Bedeutung, sich auf die Wiederherstellung nach einem Systemausfall in Ihrer AD DS-Umgebung 

vorzubereiten. In diesem Kapitel erfahren Sie, welche Maßnahmen Sie ergreifen sollten. 

Teil V – Identitäts- und Zugriffsverwaltung mit Active Directory 

• Kapitel 16 – Active Directory Lightweight Directory Services Die Active Directory Lightweight 

Directory Services (AD LDS) gehören zu den neuen Serverrollen, die in Windows Server 2008 

unter dem Oberbegriff Active Directory eingeschlossen sind. Die AD LDS sind als Anwendungsverzeichnis 

entworfen – in diesem Kapitel erfahren Sie, wie Sie Ihre AD LDS-Umgebung bereitstellen 

und verwalten. 

• Kapitel 17 – Active Directory-Zertifikatdienste Die Active Directory-Zertifikatdienste (Active Directory 

Certificate Services, AD CS) können dazu eingesetzt werden, die Public Key-Infrastruktur 

(PKI) zur Bereitstellung von digitalen Zertifikaten zur Verfügung zu stellen, die für zahlreiche 

Netzwerksicherheitsimplementierungen von zentraler Bedeutung ist. Dieses Kapitel beschreibt, 

wie die Active Directory-Zertifikatdienste geplant und implementiert werden. 

• Kapitel 18 – Active Directory-Rechteverwaltungsdienste Die Active Directory-Rechteverwaltungsdienste 

(Active Directory Rights Management Services, AD RMS) bieten die Tools, die zur 

Anwendung persistenter Verwendungsrichtlinien auf Informationen benötigt werden, die selbst 

dann noch zusammen mit den Informationen gespeichert werden, wenn diese innerhalb oder 

außerhalb der Organisation verschoben werden. Dieses Kapitel beschreibt detailliert, wie Sie die 

Active Directory-Zertifikatdienste implementieren.

XXII 

Einführung 

• Kapitel 19 – Active Directory-Verbunddienste Mithilfe der Active Directory-Verbunddienste (Active 

Directory Federation Services, AD FS) können Sie Benutzern den Zugriff auf verschiedene webbasierte 

Anwendungen innerhalb einer Organisation oder in anderen Organisationen ermöglichen, 

ohne dass sich die Benutzer mehrfach authentifizieren müssen. Dieses Kapitel beschreibt die AD 

FS-Bereitstellungsszenarien und die Implementierung der Active Directory-Verbunddienste. 

Konventionen in diesem Buch 

In diesem Buch werden die folgenden Konventionen verwendet, um besondere Features und Verwendungshinweise 

hervorzuheben: 

Hinweise für den Leser 

Die folgenden Hinweise für den Leser verweisen auf nützliche Detailinformationen: 

Element 

Hinweis 

Wichtig 

Achtung 

Auf der Begleit-CD 

Weitere Informationen 

Sicherheitswarnung 

Bedeutung 

Unterstreicht die Bedeutung eines bestimmten Konzepts oder weist auf Sonderfälle 

hin, die nicht für eine alltägliche Situation gelten. 

Lenkt die Aufmerksamkeit auf grundlegende Informationen, die berücksichtigt werden 

sollten. 

Warnt davor, dass eine bestimmte Vorgehensweise oder deren Unterlassung zu 

schweren Problemen für Benutzer, Systeme, Datenintegrität usw. führen kann. 

Weist auf bezogene Skripts, Tools, Vorlagen oder Aufgabeninformationen auf der 

Begleit-CD hin, die den Leser bei der Durchführung einer im Text beschriebenen 

Aufgabe unterstützen. 

Verweist auf Websites oder andere Materialien, die weiterführende Informationen 

zu einem im Text beschriebenen Thema enthalten. 

Betont Informationen oder Aufgaben, die für die Erhaltung einer sicheren Umgebung 

von grundlegender Bedeutung sind, oder verweist auf Ereignisse, die ein 

potenzielles Sicherheitsrisiko darstellen. 

Abschnitte mit Zusatzinformationen 

Die in diesem Buch verwendeten Abschnitte mit Zusatzinformationen stellen Hintergrundinformationen, 

Tipps und Tricks in Bezug auf Windows Server 2008 Active Directory bereit: 

Element 

Direkt von der Quelle 

Praxistipp 

Bedeutung 

Diese Abschnitte enthalten von Microsoft-Experten bereitgestellte Hintergrundinformationen 

zur Funktionsweise von Active Directory in Windows Server 2008, Empfehlungen für 

die Planung und Implementierung der Active Directory-Serverrollen und Tipps zur Problembehandlung. 

Diese Abschnitte enthalten von Verzeichnisdienst-MVPs bereitgestellte Praxisinformationen 

mit empfohlenen Vorgehensweisen für die Planung und Implementierung der Active 

Directory-Serverrollen sowie Tipps zur Problembehandlung.

Begleit-CD 

XXIII 

Element 

So funktioniert es 

Bedeutung 

Diese Abschnitte bieten einen weiterführenden Einblick in Windows Server 2008 Active 

Directory-Features und ihre Funktionsweise. 

Befehlszeilenbeispiele 

Für die in diesem Buch verwendeten Befehlszeilenbeispiele gelten die folgenden Konventionen: 

Formatierung 

Fettformatierung 

Kursivformatierung 

Nicht proportionale Schrift 

%SystemRoot% 

Bedeutung 

Wird zur Kennzeichnung von Benutzereingaben verwendet (Zeichen, die exakt wie dargestellt 

eingegeben werden) 

Wird zur Kennzeichnung von Variablen verwendet, für die ein spezifischer Wert eingegeben 

werden muss (beispielsweise verweist Dateiname auf einen beliebigen gültigen Dateinamen) 

Wird für Codebeispiele und Befehlszeilenausgaben verwendet 

Wird zur Kennzeichnung von Umgebungsvariablen verwendet 

Begleit-CD 

Die Begleit-CD gehört zum Lieferumfang dieses Buches. Viele der in den Buchkapiteln genannten 

Tools und Ressourcen befinden sich auf der Begleit-CD-ROM; darüber hinaus können Sie anhand der 

Verknüpfungen auf weitere Tools und Ressourcen der CD zugreifen. 

Eine Dokumentation der Inhalte und Struktur der Begleit-CD finden Sie in der Datei Readme.txt auf 

der CD. 

Verwaltungsskripts 

Die CD umfasst eine Reihe von Skripts zur Verwaltung von Active Directory. Darunter befinden sich 

Skripts für den Abruf von Informationen zu Active Directory-Objekten und Skripts zum Erstellen 

oder Ändern dieser Objekte. Für sämtliche Skripts ist Windows PowerShell erforderlich. Auf der 

Begleit-CD sind folgende Skripts enthalten: 

• AddUserToGroup.ps1 Fügt ein Benutzerkonto einer Gruppe innerhalb derselben OU hinzu 

• CreateAndEnableUserFromCSV.ps1 Erstellt ein aktiviertes Benutzerkonto durch Lesen einer .csv- 

Datei 

• CreateGroup.ps1 Erstellt eine Gruppe in Active Directory in der angegebenen OU und Domäne 

• CreateObjectInAD.ps1 Erstellt ein Objekt in Active Directory 

• CreateOU.ps1 Erstellt eine Organisationseinheit (OU) in Active Directory 

• CreateUser.ps1 Erstellt ein Benutzerkonto in Active Directory 

• EnableDisableUserSetPassword.ps1 Aktiviert oder deaktiviert ein Benutzerkonto und legt das 

Kennwort fest 

• GetDomainPwdSettings.ps1 Ruft die Kennwortrichtlinieneinstellungen für eine Domäne ab 

• GetModifiedDateFromAD.ps1 Listet das Datum der letzten Änderung für einen spezifischen Benutzer 

einer lokalen Domäne oder Remotedomäne auf 

• ListUserLastLogon.ps1 Listet das Datum der letzten Anmeldung für einen spezifischen Benutzer 

an einer lokalen Domäne oder Remotedomäne auf

XXIV 

Einführung 

• LocateDisabledUsers.ps1 Ermittelt deaktivierte Benutzerkonten in einer lokalen Domäne oder 

Remotedomäne 

• LocateLockedOutUsers.ps1 Ermittelt gesperrte Benutzerkonten in einer lokalen Domäne oder 

Remotedomäne 

• LocateOldComputersNotLogon.ps1 Ermittelt Computerkonten in einer lokalen Domäne oder 

Remotedomäne, die sich für eine bestimmte Anzahl an Tagen nicht angemeldet haben 

• LocateOldUsersNotLogOn.ps1 Prüft eine lokale Domäne oder Remotedomäne auf Benutzerkonten, 

die sich für eine längere Zeit (angegeben in Tagen) nicht an einer Domäne angemeldet haben 

• ModifyUser.ps1 Ändert Benutzerattribute in Active Directory 

• QueryAD.ps1 Fragt Active Directory-Objekte wie beispielsweise Benutzer, Gruppen, Computer 

usw. ab 

• UnlockLockedOutUsers.ps1 Entsperrt Benutzerkonten, die gesperrt wurden 

Zusätzlich zu diesen Skripts enthalten viele der Kapitel Verweise auf zusätzliche Skripts, mit denen 

die in einem Kapitel beschriebenen Verwaltungsaufgaben durchgeführt werden können. 

Eine vollständige Dokumentation der Inhalte und Struktur der Begleit-CD finden Sie in der Datei 

Readme.txt auf der CD. 

Verwenden der Skripts 

Die Begleit-CD enthält Skripts, die in VBScript (Dateierweiterung .vbs) und Windows PowerShell 

(Dateierweiterung .ps1) geschrieben wurden. 

Die VBScript-Skripts auf der Begleit-CD werden durch die Erweiterung .vbs gekennzeichnet. Zur 

Verwendung dieser Skripts doppelklicken Sie auf die Datei oder führen das Skript direkt von einer 

Befehlszeile aus. 

Die Windows PowerShell-Skripts erfordern, dass Windows PowerShell auf Ihrem Computer installiert 

wurde und Sie Windows PowerShell zur Ausführung nicht signierter Skripts konfiguriert haben. 

Sie können die Windows PowerShell-Skripts auf Windows XP SP2, Windows Server 2003 SP1, Windows 

Vista oder Windows Server 2008 ausführen. Damit die Skripts funktionieren, müssen alle Computer 

Mitglieder einer Windows Server 2008-Domäne sein. 

Hinweis Informationen zu den Systemanforderungen für die Ausführung der CD-Skripts finden Sie auf der 

Seite „Systemanforderungen“ am Ende des Buches. 

Zusätzliche Onlineinhalte 

Sobald neue oder aktualisierte Inhalte zur Vervollständigung des vorliegenden Buches zur Verfügung 

stehen, werden diese online auf der Microsoft Press Online Windows Server and Client-Website (in 

englischer Sprache) bereitgestellt. Basierend auf dem finalen Build von Windows Server 2008 finden 

Sie hier Aktualisierungen zum Buchinhalt, Artikel, Links zu Begleitinhalten, Errata, Beispielkapitel 

und weitere Informationen. Diese Website wird in Kürze unter http://www.microsoft.com/learning/ 

books/online/serverclient zur Verfügung stehen und regelmäßig aktualisiert.

Supporthinweise für die technische Referenz 

XXV 

Digital Content for Digital Book Readers: If you bought a digital-only edition of this book, you can 

enjoy select content from the print edition’s companion CD. 

Visit http://go.microsoft.com/fwlink/?LinkId=109208 to get your downloadable content. This content 

is always up-to-date and available to all readers. 

Supporthinweise für die technische Referenz 

Microsoft Press bemüht sich um die Richtigkeit der in diesem Buch sowie der auf der Begleit-CD enthaltenen 

Informationen. Unter der folgenden Webadresse stellt Microsoft Press Korrekturen an diesem 

Buch zur Verfügung: 

http://www.microsoft.com/learning/support/search.asp. 

Wenn Sie Kommentare, Fragen oder Anregungen zu diesem Buch oder den Inhalten der Begleit-CD 

haben, oder wenn eine Frage nicht mithilfe der Knowledge Base beantwortet werden kann, wenden 

Sie sich bitte per E-Mail oder schriftlich an Microsoft Press: 

• Per E-Mail: rkinput@microsoft.com 

• Per Post: 

Microsoft Press 

Betrifft: Windows Server 2008 Active Directory – Die technische Referenz 

Konrad-Zuse-Straße 1 

85716 Unterschleißheim 

Beachten Sie, dass unter den oben aufgeführten Adressen kein technischer Support verfügbar ist. 

Informationen zum Produktsupport finden Sie auf der Supportwebsite von Microsoft Press unter folgender 

Adresse: 

http://support.microsoft.com

T E I L I 

Windows Server 2008 Active Directory – 

Überblick 

Inhalt dieses Teils: 

Kapitel 1: Neuerungen in Active Directory für Windows Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

Kapitel 2: Active Directory-Domänendienstkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Kapitel 3: Active Directory-Domänendienste und DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

Kapitel 4: Active Directory-Domänendienstreplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3 

K A P I T E L 1 

Neuerungen in Active Directory für Windows 

Server 2008 

Inhalt dieses Kapitels: 

Neuerungen in den Active Directory-Domänendiensten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

Zusätzliche Active Directory-Dienstrollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Neuerungen in den Active Directory-Domänendiensten 

Wenngleich vieles von dem, was Sie für die Verwaltung einer Active Directory-Domäne wissen müssen, 

im Vergleich zu vorherigen Versionen der Verzeichnisdienstimplementierung, z.B. unter Windows 

2000 und Windows Server 2003, unverändert geblieben ist, gibt es mehrere nützliche neue Features 

für Administratoren zur Verbesserung der Steuerung und Sicherheit der Domänenumgebung. In 

diesem Kapitel werden sechs Weiterentwicklungen in den Active Directory-Domänendiensten (AD 

DS) sowie vier neue Funktionen behandelt, die Active Directory in Ihrem Unternehmen ausfüllen 

kann und wird. 

Schreibgeschützte Domänencontroller (Read-Only Domain Controllers, 

RODC) 

Eines der neuen Features von Windows Server 2008 ist die Möglichkeit der Bereitstellung eines 

schreibgeschützten Domänencontrollers. Auf diesem neuen Domänencontrollertyp befinden sich, wie 

der Name schon sagt, schreibgeschützte Partitionen der Active Directory-Datenbank. 

Ein schreibgeschützter Domänencontroller ermöglicht Unternehmen die einfache Bereitstellung eines 

Domänencontrollers in Umgebungen, in denen die physische Sicherheit nicht gewährleistet ist, z.B. 

an Zweigstellenstandorten, oder in Szenarien, in denen die lokale Speicherung aller Domänenkennwörter 

als Hauptbedrohung der Sicherheit gilt, z.B. bei einer anwendungsbezogenen Rolle. Ein solcher 

Domänencontroller eignet sich auch für die gemeinsame Verwendung mit der Server Core-Installationsoption 

von Windows Server 2008. 

Unternehmen, welche die physische Sicherheit eines Zweigstellen-Domänencontrollers garantieren 

können, stellen ggf. aufgrund der reduzierten Verwaltungsanforderungen ebenfalls einen schreibgeschützten 

Domänencontroller bereit, die durch Features wie eine Trennung der Administratorrolle 

ermöglicht werden. 

Da die Verwaltung eines schreibgeschützten Domänencontrollers an eine Domänenbenutzer- oder 

Sicherheitsgruppe delegiert werden kann, ist ein schreibgeschützter Domänencontroller gut für Standorte 

geeignet, an denen es keine Mitglieder der Gruppe Domänen-Admins geben soll. Schreibgeschützte 

Domänencontroller besitzen folgende Eigenschaften:

4 Kapitel 1: Neuerungen in Active Directory für Windows Server 2008 

Schreibgeschützte AD DS-Datenbank 

Mit Ausnahme von Kontokennwörtern enthält ein schreibgeschützter Domänencontroller die meisten 

der Active Directory-Objekte und -Attribute, die sich auf einem beschreibbaren Domänencontroller 

befinden. Die Datenbank, die auf dem schreibgeschützten Domänencontroller gespeichert ist, kann 

allerdings nicht geändert werden. Änderungen müssen auf einem beschreibbaren Domänencontroller 

erfolgen und anschließend auf den schreibgeschützten Domänencontroller repliziert werden. 

Lokalen Anwendungen, die einen Lesezugriff auf das Verzeichnis benötigen, kann Zugriff gewährt 

werden. LDAP-Anwendungen (Lightweight Directory Application Protocol), die einen Schreibzugriff 

anfordern, erhalten eine LDAP-Weiterleitungsantwort, die sie zu einem beschreibbaren Domänencontroller 

leitet (in der Regel zu einem Hubstandort). 

Attributsatz mit RODC-Filter 

Nur bestimmte Attribute werden auf den schreibgeschützten Domänencontroller repliziert. Sie können 

einen Attributsatz, der Attributsatz mit RODC-Filter genannt wird, dynamisch so konfigurieren, 

dass dessen Attribute nicht auf einen schreibgeschützten Domänencontroller repliziert werden. Im 

Attributsatz mit RODC-Filter definierte Attribute werden nicht auf schreibgeschützte Domänencontroller 

in der Gesamtstruktur repliziert. 

Ein böswilliger Benutzer, der die Sicherheit eines schreibgeschützten Domänencontrollers gefährdet, 

kann versuchen, diesen so zu konfigurieren, das versucht wird, im Attributsatz mit RODC-Filter definierte 

Attribute zu replizieren. Wenn der schreibgeschützte Domänencontroller versucht, diese Attribute 

von einem Domänencontroller zu replizieren, auf dem Windows Server 2008 ausgeführt wird, 

wird die Replikationsanforderung verweigert. Deshalb sollten Sie als Sicherheitsmaßnahme die 

Funktionsebene der Gesamtstruktur auf Windows Server 2008 festlegen, wenn Sie den Attributsatz 

mit RODC-Filter konfigurieren möchten. Wenn die Funktionsebene der Gesamtstruktur Windows 

Server 2008 ist, kann ein schreibgeschützter Domänencontroller, dessen Sicherheit gefährdet ist, nicht 

auf diese Weise ausgenutzt werden, da Domänencontroller mit Windows Server 2003 in der Gesamtstruktur 

nicht zulässig sind. 

Unidirektionale Replikation 

Ebenso wie keine Änderungen direkt auf den schreibgeschützten Domänencontroller geschrieben 

werden, sorgt dieser auch für keine Änderungen. Dem entsprechend beziehen beschreibbare Domänencontroller, 

die Replikationspartner sind, keine Änderungen vom schreibgeschützten Domänencontroller. 

Dies bedeutet, dass Änderungen oder Manipulationen, die böswillige Benutzer an Zweigstellenstandorten 

vornehmen, nicht vom schreibgeschützten Domänencontroller in den Rest der 

Gesamtstruktur repliziert werden. Außerdem wird die Verarbeitungslast von Bridgeheadservern am 

Hub und der Aufwand zur Überwachung der Replikation reduziert. 

Die unidirektionale RODC-Replikation gilt sowohl für die AD DS- als auch die DFS-Replikation 

(Distributed File System, verteiltes Dateisystem). Der schreibgeschützte Domänencontroller führt für 

AD DS- und DFS-Replikationsänderungen eine normale eingehende Replikation durch. 

Zwischenspeichern von Anmeldeinformationen 

Das Zwischenspeichern von Anmeldeinformationen ist die Speicherung von Benutzer- und Computeranmeldeinformationen 

einschließlich des Benutzerkennworts in Form verschiedener Hashwerte. 

Auf einem schreibgeschützten Domänencontroller werden standardmäßig keine Benutzer- und Computeranmeldeinformationen 

gespeichert.

Neuerungen in den Active Directory-Domänendiensten 5 

Ausnahmen bilden das Computerkonto des schreibgeschützten Domänencontrollers und das besondere 

(und eindeutige) Konto krbtgt, über das jeder schreibgeschützte Domänencontroller verfügt. 

Sie können das Zwischenspeichern von Anmeldeinformationen auf dem schreibgeschützten Domänencontroller 

konfigurieren, indem Sie die Kennwortreplikationsrichtlinie des jeweiligen Domänencontrollers 

ändern. Beispiel: Wenn der schreibgeschützte Domänencontroller die Anmeldeinformationen 

aller Benutzer in der Zweigstelle zwischenspeichern soll, die sich regelmäßig an diesem 

Standort anmelden, können Sie alle Benutzerkonten für Benutzer in der Zweigstelle der Kennwortreplikationsrichtlinie 

hinzufügen. Auf diese Weise können sich Benutzer am Domänencontroller 

anmelden, selbst wenn die WAN-Verbindung zu einem beschreibbaren Domänencontroller nicht verfügbar 

ist. Außerdem können Sie alle Zweigstellen-Computerkonten hinzufügen, sodass sich diese 

Konten beim schreibgeschützten Domänencontroller authentifizieren können, auch wenn die WAN- 

Verbindung ausfällt. Bei diesen beiden Szenarien muss die WAN-Verbindung zu einem beschreibbaren 

Domänencontroller während der ersten Anmeldung verfügbar sein, damit die Anmeldeinformationen 

auf dem schreibgeschützten Domänencontroller zwischengespeichert werden können. 

Trennung der Administratorrolle 

Sie können lokale Administratorberechtigungen für einen schreibgeschützten Domänencontroller an 

beliebige Domänenbenutzer delegieren, ohne ihnen Benutzerrechte für die Domäne oder andere Domänencontroller 

erteilen zu müssen. Dadurch kann sich ein Benutzer in einer lokalen Zweigstelle für Wartungsarbeiten 

(z.B. zur Aktualisierung eines Treibers) an einem schreibgeschützten Domänencontroller 

anmelden. Er kann sich jedoch nicht an einem anderen Domänencontroller anmelden oder andere 

Verwaltungsaufgaben in der Domäne ausführen. Auf diese Weise kann die Fähigkeit zur effektiven 

Verwaltung des schreibgeschützten Domänencontrollers in einer Zweigstelle an einen Benutzer an 

diesem Standort delegiert werden, ohne die Sicherheit der restlichen Domäne zu gefährden. 

Schreibgeschütztes DNS 

Sie können den DNS-Serverdienst auf einem schreibgeschützten Domänencontroller installieren. Ein 

schreibgeschützter Domänencontroller kann alle vom DNS verwendeten Anwendungsverzeichnispartitionen 

replizieren, einschließlich ForestDNSZones und DomainDNSZones. Wenn der DNS-Server 

auf einem schreibgeschützten Domänencontroller installiert ist, können Clients diesen wie jeden 

anderen DNS-Server zur Auflösung von Namen abfragen. 

Der DNS-Server auf einem schreibgeschützten Domänencontroller unterstützt jedoch keine direkten 

Clientaktualisierungen. Demzufolge registriert der schreibgeschützte Domänencontroller keine 

Namenserver-Ressourceneinträge für Active Directory-integrierte Zonen, als dessen Host er dient. 

Wenn ein Client versucht, seine DNS-Einträge im Abgleich mit einem schreibgeschützten Domänencontroller 

zu aktualisieren, gibt der Server eine Weiterleitung zurück. Der Client kann anschließend 

versuchen, die Aktualisierung im Abgleich mit dem DNS-Server auszuführen, der in der Weiterleitung 

angegeben ist. Im Hintergrund versucht der DNS-Server auf dem schreibgeschützten Domänencontroller, 

den aktualisierten Eintrag vom DNS-Server zu replizieren, der die Aktualisierung durchgeführt 

hat. Diese Replikationsanforderung gilt nur für ein einzelnes Objekt (den DNS-Eintrag). Die 

gesamte Liste der geänderten Zonen- bzw. Domänendaten wird bei dieser besonderen Replikationsanforderung 

für ein einzelnes Objekt nicht repliziert. Zur Optimierung der Sicherheit muss der 

schreibgeschützte Domänencontroller der Zweigstelle seine Domänencontrollereinträge (z.B. Zeitserver, 

LDAP-Host, KDC-Host usw.) bei einem Windows Server 2008-Domänencontroller registrieren. 

Wenn anschließend die Sicherheit des schreibgeschützten Domänencontrollers gefährdet sein 

sollte, kann dieser keine DNS-Einträge ändern oder die Identität eines anderen Domänencontrollers 

annehmen bzw. sich nicht Clients außerhalb des eigenen Standorts ankündigen.


AD DS-Überwachung 

Um die AD DS besser verwalten zu können, ist es nicht nur hilfreich, die Objekte zu kennen, die 

geändert wurden, sondern auch deren aktuelle und vorherige Werte. In bisherigen Versionen der AD 

DS gab es mit Verzeichnisdienstzugriff überwachen eine einzige Überwachungsrichtlinie. Windows 

Server 2008 bietet weitere Unterkategorien der Verzeichnisdienstüberwachung, die zusätzliche Protokollinformationen 

zu Erfolgs- und Misserfolgsereignissen in den AD DS bieten. Unter Windows 

Server 2008 wurde die Richtlinie Verzeichnisdienstzugriff überwachen in vier Unterkategorien unterteilt: 

• Verzeichnisdienstzugriff 

• Verzeichnisdienständerungen 

• Verzeichnisdienstreplikation 

• Detaillierte Verzeichnisdienstreplikation 

Diese globale Überwachungsrichtlinie ist unter Windows Server 2008 standardmäßig aktiviert. Die 

ebenfalls standardmäßig aktivierte Unterkategorie Verzeichnisdienständerungen ist so eingestellt, dass 

nur Erfolgsereignisse protokolliert werden. Sie können die zu überwachenden Vorgänge bestimmen, 

indem Sie die System-Zugriffssteuerungsliste für die entsprechenden Verzeichnisdienstobjekte 

ändern. Zum Überwachen von Verzeichnisdienständerungen stehen nun die folgenden Funktionen 

zur Verfügung: 

• Wenn ein erfolgreicher Änderungsvorgang auf ein Attribut eines Objekts angewendet wird, protokollieren 

die AD DS die bisherigen und aktuellen Werte des Attributs. Wenn das Attribut mehrere 

Werte hat, werden nur die Werte protokolliert, die sich als Ergebnis des Änderungsvorgangs 

ändern. 

• Wird ein neues Objekt erstellt, werden die Werte der Attribute protokolliert, die zum Zeitpunkt 

der Erstellung aufgefüllt werden. Wenn Attribute während des Erstellungsvorgangs hinzugefügt 

werden, erfolgt eine Protokollierung dieser neuen Attribute. 

• Wenn ein Objekt in einer Domäne verschoben wird, werden der bisherige und der neue Speicherort 

(in Form des definierten Namens) protokolliert. Beim Verschieben eines Objekts in eine 

andere Domäne wird ein Erstellungsereignis auf dem Domänencontroller in der Zieldomäne 

generiert. 

• Wird ein Objekt wiederhergestellt, wird der Speicherort protokolliert, an den das Objekt verschoben 

wird. Außerdem werden, falls Attribute bei einem Wiederherstellungsvorgang hinzugefügt, 

geändert oder gelöscht werden, die Werte dieser Attribute ebenfalls protokolliert. 

Hinweis Wenngleich die globale Überwachungsrichtlinie Verzeichnisdienstzugriff überwachen über die 

Konsole Gruppenrichtlinienverwaltung aktiviert wird, gibt es in Windows Server 2008 keine grafische Benutzeroberfläche, 

auf der die AD DS-Unterkategorien für diese Überwachungsrichtlinie angezeigt oder konfiguriert 

werden können. Zu diesem Zweck müssen Sie das Befehlszeilenprogramm Auditpol.exe verwenden. 

Weitere Informationen zum Verwenden von Auditpol.exe zum Aktivieren einzelner Unterkategorien finden 

Sie in Kapitel 8, „Active Directory-Domänendienstsicherheit“, sowie im „Windows Server 2008 Auditing AD 

DS Changes Step-by-Step Guide“ unter http://technet2.microsoft.com/windowsserver2008/de/library/ 

9a5cba91-7153-4265-adda-c70df23219821031.mspx?mfr=true.

Fein abgestimmte Kennwortrichtlinien 


Unter Windows Server 2000 und Windows Server 2003 werden sowohl Kennwortrichtlinien- als auch 

Kontosperreinstellungen für alle Benutzer in der Domäne von der Standarddomänenrichtlinie gesteuert. 

Um eine getrennte Kennwortrichtlinien- oder Kontosperreinstellung für bestimmte Benutzer in 

der Domäne einzurichten, mussten bislang zusätzliche Domänen oder Kennwortfilter erstellt werden. 

In den Windows Server 2008-AD DS stehen nun fein abgestimmte Kennwortrichtlinien zur Verfügung, 

um in einer einzelnen Domäne mehrere Kennwortrichtlinien anzugeben. Dadurch können Mitglieder 

der Gruppe Domänen-Admins getrennte Kennwortrichtlinien- und Kontosperreinstellungen für 

verschiedene Benutzertypen in der Domäne einrichten. Ein Domänenadministrator kann eine strengere 

Kennwortrichtlinie für eine Hauptbenutzergruppe mit höheren Berechtigungen und eine weniger 

strenge Kennwortrichtlinie für normale Benutzer wählen. 

Die fein abgestimmten Kennwortrichtlinien unter Windows Server 2008 können entweder Benutzerobjekten 

oder globalen Sicherheitsgruppen zugewiesen werden. Sie können eine fein abgestimmte 

Kennwortrichtlinie nicht direkt einer Organisationseinheit zuweisen. Um eine andere Kennwortrichtlinie 

für Mitglieder der Organisationseinheit zu erstellen, weisen Sie die Kennwortrichtlinie einer 

globalen Sicherheitsgruppe zu, die der Organisationseinheit logisch zugeordnet ist (einer sogenannten 

Schattengruppe). Wenn Sie einen Benutzer aus einer Organisationseinheit in eine andere verschieben, 

müssen Sie die Mitgliedschaft der Schattengruppe aktualisieren, wenn der Benutzer der Kennwortrichtlinie 

der neuen Organisationseinheit (d.h. nicht mehr der Richtlinie der alten Organisationseinheit) 

unterliegen soll. 

Speichern fein abgestimmter Kennwortrichtlinien 

Im AD DS-Schema werden zum Speichern fein abgestimmter Kennwortrichtlinien die beiden neuen 

Objektklassen Password Settings Container (PSC) und Password Settings erstellt. Password Settings- 

Objekte (PSOs) werden im PSC gespeichert. Der PSC wird standardmäßig im Container System der 

Domäne erstellt, der nicht verschoben, umbenannt oder gelöscht werden kann. Ein PSO hat Attribute 

für alle Einstellungen, die in der Standarddomänenrichtlinie festgelegt werden können (außer für Kerberos-Einstellungen). 

Dazu zählen Attribute für die folgenden Kennworteinstellungen: 

• Kennwortchronik erzwingen 

• Maximales Kennwortalter 

• Minimales Kennwortalter 

• Minimale Kennwortlänge 

• Kennwörter müssen den Komplexitätsanforderungen entsprechen 

• Kennwort mit umkehrbarer Verschlüsselung speichern 

Dazu zählen auch Attribute für die folgenden Kontosperreinstellungen: 

• Kontosperrdauer 

• Kontensperrungsschwelle 

• Kontosperrungszähler zurücksetzen nach 

Außerdem hat ein PSO die folgenden beiden neuen Attribute: 

• PSO-Link Ein mehrwertiges Attribut, das mit Benutzern und/oder Gruppenobjekten verknüpft ist. 

• Vorrang Ein Ganzzahlwert, der zum Lösen von Konflikten dient, wenn für ein Benutzer- oder 

Gruppenobjekt mehrere PSOs gelten.


Hinweis Wenn ein Domänencontroller mit Windows Server 2008 einer vorhandenen Active Directory- 

Domäne hinzugefügt wird, müssen Sie Adprep ausführen, um das Active Directory-Schema um die beiden 

neuen Objektklassen zu erweitern, die für die fein abgestimmte Kennwortrichtlinie erforderlich sind. Das 

Befehlszeilenprogramm Adprep bereitet das Schema auf die Änderungen vor, die zur Unterstützung der AD 

DS unter Windows Server 2008 erforderlich sind. Weitere Informationen zum Verwenden von Adprep finden 

Sie in Kapitel 6, „Installieren der Active Directory-Domänendienste“, sowie in „Schrittweise Anleitung für die 

Konfiguration abgestimmter Kennwort- und Kontosperrungsrichtlinien“ unter http://technet2.microsoft.com/ 

windowsserver2008/de/library/76521193-4f13-47d8-85ad-70c3cdbdb4061031.mspx?mfr=true. 

Richtlinienergebnissatz für fein abgestimmte Kennwortrichtlinie 

Fein abgestimmte Kennwortrichtlinieneinstellungen können sowohl Benutzerobjekten als auch globalen 

Sicherheitsgruppen zugewiesen werden. Der Richtlinienergebnissatz (Resultant Set of Policy, 

RSOP) kann nur für das Benutzerobjekt berechnet werden. Wenn mehrere PSOs mit einem Benutzer 

oder einer Gruppe verknüpft sind, wird der Richtlinienergebnissatz, der zugeordnet wird, wie folgt 

bestimmt: 

1. Ein PSO, das direkt mit einem Benutzerobjekt verknüpft ist, ist das resultierende PSO. Wenn 

mehrere PSOs direkt mit dem Benutzerobjekt verknüpft sind, wird im Ereignisprotokoll eine 

Warnmeldung protokolliert, und das PSO mit dem niedrigsten Vorrangwert ist das resultierende 

PSO. 

2. Wenn kein PSO mit dem Benutzerobjekt verknüpft ist, werden die Mitgliedschaften in globalen 

Sicherheitsgruppen des Benutzers und alle für den Benutzer geltenden PSOs basierend auf diesen 

globalen Gruppenmitgliedschaften verglichen. Das PSO mit dem niedrigsten Vorrangwert ist das 

resultierende PSO. (Wenn es mehrere niedrigste Vorrangwerte gibt, wird deren Anwendungsreihenfolge 

anhand der PSO-GUID bestimmt). 

3. Ergibt sich aus den Bedingungen (1) und (2) kein PSO, gilt die Standarddomänenrichtlinie. 

Es gibt drei direkt auf das Benutzerobjekt anwendbare Einstellungen, die stets die Einstellungen außer 

Kraft setzen, die aufgrund der fein abgestimmten Kennwortrichtlinie gelten. Sie können diese Bits im 

Attribut userAccountControl des Benutzerobjekts festlegen: 

• Umkehrbare Kennwortverschlüsselung erforderlich 

• Kennwort nicht erforderlich 

• Kennwort läuft nicht ab 

Diese Bits setzen die Einstellungen im resultierenden PSO außer Kraft, das dem Benutzerobjekt zugeordnet 

wird (ebenso wie diese Bits die Einstellungen in der Standarddomänenrichtlinie unter Windows 

2000 und Windows Server 2003 außer Kraft setzen). 

Neustartmöglichkeit der Active Directory-Domänendienste 

Die Neustartmöglichkeit der Active Directory-Domänendienste unter Windows Server 2008 ermöglicht 

dem Administrator das Ausführen von Aufgaben, die offline erfolgen, ohne den Domänencontroller 

neu starten zu müssen. In früheren Windows Server-Versionen war für Offlineaufgaben wie die 

Offlinedefragmentierung der Datenbank ein Neustart des Domänencontrollers im Verzeichnisdienst- 

Wiederherstellungsmodus erforderlich.


Unter Windows Server 2008 können Sie die AD DS beenden und die erforderlichen Änderungen vornehmen, 

während andere Dienste auf dem Server (z.B. DHCP [Dynamic Host Configuration Protocol]) 

davon nicht betroffen sind und Anforderungen der Benutzer weiter erfüllen können, während die 

AD DS deaktiviert sind. Beachten Sie, dass abhängige Dienste wie DNS und Schlüsselverteilungscenter 

ohne die AD DS nicht funktionieren. Abhängige Dienste werden bei Beenden der AD DS ebenfalls 

beendet. 

Ein Domänencontroller mit Windows Server 2008 kann einen von drei möglichen Status aufweisen: 

• AD DS gestartet In diesem Status sind die AD DS gestartet. Für Clients und andere auf dem Server 

ausgeführte Dienste entspricht ein Windows Server 2008-Domänencontroller in diesem Status 

einem Domänencontroller mit Windows 2000 Server oder Windows Server 2003. 

• AD DS beendet In diesem Status sind die AD DS beendet. Wenngleich dieser Modus besonders 

ist, weist der Server einige Merkmale von sowohl einem Domänencontroller im Verzeichnisdienst-Wiederherstellungsmodus 

als auch einem der Domäne beigetretenen Mitgliedsserver auf. 

• Verzeichnisdienst-Wiederherstellungsmodus Dieser Modus ist im Vergleich zu Windows Server 

2003 unverändert. 

Sie können die AD DS über die Komponente Dienste des MMC-Snap-Ins Computerverwaltung 

bequem starten und beenden oder den Dienst wie alle anderen Dienste beenden, die lokal auf dem 

Server ausgeführt werden. 

Datenbankbereitstellungstool 

Das Datenbankbereitstellungstool (Dsamain.exe) ermöglicht das Anzeigen von Snapshots und 

Sicherungen von AD DS-Daten, um zu bestimmen, welche Sicherung bzw. welcher Snapshot die 

gewünschten wiederherzustellenden Daten enthält. In früheren Versionen der AD DS unter den 

Betriebssystemen Windows 2000 und Windows Server 2003 mussten Administratoren mehrere 

Sicherungssätze wiederherstellen, um zu bestimmen, welcher Satz die wiederherzustellenden Daten 

enthielt. Dieser Prozess erforderte einen Neustart des Domänencontrollers im Verzeichnisdienst-Wiederherstellungsmodus 

und bot keine Möglichkeit des Vergleichs von Daten, die zu verschiedenen 

Zeitpunkten in Sicherungen gespeichert wurden. Wenngleich das Datenbankbereitstellungstool nicht 

zur Wiederherstellung der Daten in den AD DS dient, kann es zum Vereinfachen der Bestimmung 

geänderter Informationen und zum Auswählen der wiederherzustellenden Sicherung genutzt werden, 

ohne dass Ausfallzeiten anfallen. 

Mit dem Datenbankbereitstellungstool können Sie das Snapshotvolume (das mithilfe von Ntdsutil 

oder dem Volumeschattenkopie-Dienst erstellt wurde) als Datei AD.dit offen legen. Anschließend 

können Sie mit einem LDAP-Tool wie LDP.exe (im Funktionsumfang von Windows Server 2008) den 

Snapshot wie jeden anderen aktiven Domänencontroller durchsuchen. 

Verbesserungen der Benutzeroberfläche 

Windows Server 2008 weist mehrere Verbesserungen der AD DS-Benutzeroberfläche auf. Der 

Installations-Assistent für die Active Directory-Domänendienste bietet nun erweiterte Optionen zur 

besseren Unterstützung der Installation schreibgeschützter Domänencontroller. Der AD DS-Installationsprozess 

wurde optimiert und vereinfacht. Darüber hinaus bieten die Verwaltungstools (das 

MMC-Snap-In Active Directory-Standorte und -Dienste) Steuerelemente für neue AD DS-Features 

wie die Kennwortreplikationsrichtlinie für schreibgeschützte Domänencontroller.


Verbesserungen am Installations-Assistenten für die Active Directory-Domänendienste 

Wenngleich Sie den neuen Assistenten zum Hinzufügen von Rollen zum Konfigurieren des Servers 

für die Rolle AD DS verwenden und zum Installieren der für den Start der AD DS-Installation 

benötigten Dateien verwenden können, müssen Sie weiterhin den Installations-Assistenten für die 

Active Directory-Domänendienste ausführen, indem Sie den Befehl Dcpromo.exe aufrufen. Neu in 

Windows Server 2008 ist auf der Begrüßungsseite des Installations-Assistenten für die Active Directory-Domänendienste 

die Option zum Ausführen des Assistenten im Modus Erweitert, sodass bei 

Eingabe des Befehls Dcpromo.exe im Dialogfeld Ausführen oder an der Befehlszeile nicht mehr der 

Parameter /adv angegeben werden muss. 

Es folgen die zusätzlichen Installationsoptionen im erweiterten Modus: 

• Erstellen einer neuen Domänenstruktur 

• Verwenden von Sicherungsmedien eines vorhandenen Domänencontrollers in derselben Domäne 

zum Reduzieren des Netzwerkdatenverkehrs bei der anfänglichen Replikation 

• Auswählen des Quelldomänencontrollers für die Installation, wodurch Sie den Domänencontroller 

bestimmen können, der Domänendaten anfänglich auf den neuen Domänencontroller repliziert 

• Definieren der Kennwortreplikationsrichtlinie eines schreibgeschützten Domänencontrollers 

Der neue Assistent zum Installieren von Active Directory-Domänendiensten bietet außerdem die folgenden 

Verbesserungen: 

• Standardmäßig verwendet der Assistent nun die Anmeldeinformationen des aktuell angemeldeten 

Benutzers. Sie werden aufgefordert, bei Bedarf weitere Anmeldeinformationen einzugeben. 

• Wenn Sie einen weiteren Domänencontroller in einer untergeordneten Domäne einrichten, erkennt 

der Assistent nun, ob die Rolle Infrastrukturmaster auf einem globalen Katalogserver in dieser 

Domäne ausgeführt wird. Er fordert Sie auf, die Rolle Infrastrukturmaster an den Domänencontroller, 

den Sie einrichten, zu übertragen, wenn dieser kein globaler Katalogserver sein soll. 

Dadurch wird eine falsche Zuordnung der Rolle Infrastrukturmaster verhindert. 

• Auf der Seite Zusammenfassung des Assistenten können Sie die Einstellungen, die Sie ausgewählt 

haben, in eine Antwortdatei exportieren, die Sie für nachfolgende Vorgänge (Installationen 

und Deinstallationen) verwenden können. Diese Vorgehensweise ist weniger fehleranfällig als das 

manuelle Erstellen einer Datei für die unbeaufsichtigte Installation. 

• Sie müssen nun nicht mehr das Administratorkennwort in der Antwortdatei angeben. Geben Sie 

stattdessen password=* in die Antwortdatei ein, um sicherzustellen, dass der Benutzer zur Eingabe 

von Kontoanmeldeinformationen aufgefordert wird. 

• Sie können den Assistenten durch Angabe verschiedener Parameter an der Befehlszeile vorab ausfüllen, 

um den Umfang der Benutzerinteraktion mit dem Assistenten zu verringern. Bei der Installation 

der AD DS unter Windows Server 2008 Server Core sind ebenfalls Befehlszeilenparameter 

erforderlich. 

• Sie können nun die Herabstufung eines Domänencontrollers erzwingen, der im Verzeichnisdienst- 

Wiederherstellungsmodus gestartet wurde. 

Verbesserungen an den AD DS-Verwaltungstools 

Das Snap-In Active Directory-Standorte und -Dienste wurde vielfach verbessert, um die Verwaltung 

der AD DS zu erleichtern. Zunächst wurde dem Eigenschaftenblatt von Domänencontrollern die 

Registerkarte Kennwortreplikationsrichtlinie hinzugefügt, auf der angezeigt werden kann, welche 

Kennwörter an einen schreibgeschützten Domänencontroller übermittelt wurden und welche Kenn-

Zusätzliche Active Directory-Dienstrollen 11 

wörter gegenwärtig auf dem schreibgeschützten Domänencontroller gespeichert sind. Diese Registerkarte 

zeigt ferner an, welche Konten auf dem schreibgeschützten Domänencontroller authentifiziert 

wurden, um zu bestimmen, ob die Kennwortreplikation zulässig ist. Darüber hinaus wurde der Befehl 

Suchen der Symbolleiste und dem Menü Aktion des Snap-Ins hinzugefügt. Administratoren können 

nun bestimmen, an welchem Standort sich ein Domänencontroller befindet, um Replikationsprobleme 

besser beheben zu können. 

Verschiedene Tools wie Ldp, Repadmin und Nltest, die zu den Supporttools von Windows Server 2003 

– Die technische Referenz gehörten, sind nun in der Standardinstallation von Windows Server 2008 

enthalten und stehen nach Installation der Domänencontrollerrollen zur Verfügung. Dieselben Tools 

können zum Verwalten von sowohl den AD DS als auch den AD LDS (zuvor Active Directory Application 

Mode [ADAM]) verwendet werden. Es gibt eine Option, bei der Installation nur diese Tools zu 

installieren. 

Zusätzliche Active Directory-Dienstrollen 

Zusätzlich zu den AD DS können Sie einen Computer mit dem Betriebssystem Windows Server 2008 

in den folgenden vier weiteren Active Directory-Dienstrollen bereitstellen: 

• Active Directory-Zertifikatdienste (AD CS) 

• Active Directory-Verbunddienste (AD FS) 

• Active Directory Lightweight Services (AD LS) 

• Active Directory-Rechteverwaltungsdienste (AD RMS) 

In diesem Abschnitt wird kurz die Funktionalität beschrieben, die bei Konfiguration des Servers mit 

diesen Active Directory-Dienstrollen zur Verfügung steht. In späteren Kapiteln werden die Auswirkungen 

der Installation mehrerer Dienstrollen auf einem einzelnen Computer mit dem Betriebssystem 

Windows Server 2008 sowie die detaillierten Funktionen der einzelnen Dienstrollen behandelt. 

Zur Bereitstellung dieser Dienstrollen auf einem Computer mit dem Betriebssystem Windows Server 

2008 wird die Konsole Server-Manager verwendet. Mehrere dieser Dienstrollen erfordern, dass der 

Server zuerst als Domänencontroller konfiguriert wird, während andere verlangen, dass er in einer 

vorhandenen Active Directory-Gesamtstruktur installiert wird. 

Active Directory-Zertifikatdienste 

Die Rolle Active Directory-Zertifikatdienste (AD CS) dient zum Erstellen, Verteilen und Verwalten 

von Zertifikaten für öffentliche Schlüssel, um Netzwerkressourcen abzusichern. Zertifikate für öffentliche 

Schlüssel können Benutzern, Geräten, Computern, Diensten und AD CS-Funktionen ausgestellt 

werden, um die Identität der Person, des Gerätes oder Dienstes an einen dazugehörigen privaten 

Schlüssel zu binden, der für das jeweilige Objekt eindeutig ist. 

Bei der Verwaltung und Sperrung von Zertifikaten in skalierbaren Umgebungen gibt es mehreren Verbesserungen 

bei den AD CS unter Windows Server 2008: 

• CNG (Cryptography Next Generation) CNG bietet verschiedene APIs zum Durchführen grundlegender 

kryptografischer Vorgänge, z.B. Erstellen von Hashwerten oder Ver- und Entschlüsseln 

von Daten. Außerdem dient CNG zum Erstellen, Speichern und Abrufen kryptografischer Schlüssel.


• Webregistrierung Die Webregistrierung ermöglicht Benutzern das Verbinden mit einer Zertifizierungsstelle 

über einen Webbrowser, um Zertifikate anzufordern, Zertifikatsperrlisten abzurufen 

und die Zertifikatregistrierung für Smartcards durchzuführen. 

• Online-Responder-Dienst Der Online-Responder-Dienst ermöglicht Clients das Überprüfen des 

Sperrstatus eines digitalen Zertifikats mithilfe von OCSP (Online Certificate Status Protocol) und 

nicht von Zertifikatsperrlisten. Wenn ein Client einen Zertifikatsperrstatus vom Online-Responder-Dienst 

anfordert, überprüft der Server den Status des Zertifikats und sendet eine signierte Antwort 

zurück, die nur die angeforderten Zertifikatstatusinformationen enthält. Bei Verwenden einer 

Zertifikatsperrliste wird dagegen die gesamte Liste gesperrter Zertifikate auf den Client heruntergeladen. 

• Registrierungsdienst für Netzwerkgeräte Der Registrierungsdienst für Netzwerkgeräte ermöglicht 

Routern, Switches und anderen Netzwerkgeräten ohne Netzwerkkonten den Abruf von Zertifikaten. 

• Unternehmens-PKI (PKIView) PKIView ist ein MMC-Snap-In in den AD CS für Windows Server 

2008, das zum Überwachen und Beheben von Problemen aller Zertifizierungsstellen in einer 

Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure, PKI) dient. Das Snap-In PKIView 

zeigt den Status aller Zertifizierungsstellen in der Umgebung grafisch an. 

• Eingeschränkter Registrierungs-Agent Der eingeschränkte Registrierungs-Agent ist eine neue 

Funktion unter Windows Server 2008, welche die Berechtigungen von Benutzern beschränkt, die 

als „Registrierungs-Agents“ für die Registrierung von Smartcardzertifikaten im Auftrag anderer 

Benutzer vorgesehen sind. Diese Funktion steht nur unter Windows Server 2008 Enterprise zur 

Verfügung. 

• Zertifikatbezogene Richtlinieneinstellungen In den AD CS gibt es neue zertifikatbezogene Gruppenrichtlinieneinstellungen, 

die über die Konsole Gruppenrichtlinienverwaltung verwaltet werden 

können: Diese Gruppenrichtlinieneinstellungen dienen folgenden Zwecken: 

Bereitstellen von Zertifikaten von Zwischenzertifizierungsstellen auf Clientcomputern 

Verhindern, dass Benutzer Anwendungen installieren, die mit einem nicht genehmigten 

Herausgeberzertifikat signiert wurden 

Konfigurieren von Netzwerkzeitlimits für große Zertifikatsperrlisten sowie eine Verlängerung 

der Ablaufzeiten von Zertifikatsperrlisten 

Wenn Sie in den AD CS eine Zertifizierungsstelle bereitstellen, können Sie zwischen einer Unternehmenszertifizierungsstelle 

und einer eigenständigen Zertifizierungsstelle wählen. Eine Unternehmenszertifizierungsstelle 

ist eng mit den AD DS integriert, weshalb Sie viele der Aufgaben für die 

Registrierung und Erneuerung von Zertifikaten automatisieren können. Wenn Sie eine Unternehmenszertifizierungsstelle 

bereitstellen, müssen Sie sie auf einem Computer mit Windows Server 2008 

bereitstellen, der Mitglied einer AD DS-Domäne ist. 

Die AD CS-Komponenten können auf einem Einzelserver bereitgestellt oder auf mehrere Server verteilt 

werden. In kleinen Unternehmen können Sie alle Rollen außer dem Online-Responder-Dienst auf 

einem Einzelcomputer bereitstellen, und der Online-Responder kann auf einem anderen Computer 

dediziert bereitgestellt werden. In Großunternehmen mit komplexen Anforderungen an digitale Zertifikate 

können Sie mehrere Zertifizierungsstellen, einschließlich untergeordneter Zertifizierungsstellen 

und Online-Responder, auf getrennten Computern bereitstellen. Die Anzahl der Server, die Sie in 

Ihrer Umgebung bereitstellen, hängt von der Anzahl der Variablen, einschließlich des Volumens der


Zertifikatanforderungen, der Anzahl und dem Standort von Zertifizierungsstellen und den Anwendungen 

ab, die Zertifikate im Unternehmen benötigen. Zu diesen Anwendungen zählen S/MIME 

(Secure/Multipurpose Internet Mail Extensions), sichere Drahtlosnetzwerke, VPN (virtuelle private 

Netzwerke), IPsec (Internet Protocol Security), EFS (Encrypting File System), SmartCard-Anmeldung, 

SSL/TLS (Secure Socket Layer/Transport Layer Security) und digitale Signaturen. 

Um die Flexibilität der PKI in Ihrem Unternehmen zu steigern, können einzelne oder mehrere Online- 

Responder bereitgestellt werden. Mehrere Online-Responder können zur Unterstützung einer oder 

mehrerer Zertifizierungsstellen bereitgestellt werden. Ein einzelner Online-Responder kann aber auch 

mehrere Zertifizierungsstellen unterstützen. Zur Erhöhung der Fehlertoleranz und zur Unterstützung 

von Remote-Zertifikatsperranforderungen (Zweigstellenszenarien) können Online-Responder als 

Array bereitgestellt werden. Ein Mitglied des Arrays muss als Arraycontroller definiert werden. 

Wenngleich jeder Online-Responder in einem Array unabhängig konfiguriert und verwaltet werden 

kann, setzen bei einem Konflikt die Konfigurationsinformationen des Arraycontrollers die für andere 

Arraymitglieder festgelegten Konfigurationsoptionen außer Kraft. 

Active Directory-Verbunddienste 

Die Active Directory-Verbunddienste (AD FS) sind eine Serverrolle im Betriebssystem Windows Server 

2008, die zum Ausdehnen der Kontoauthentifizierungsfunktionen der AD DS über die Grenzen 

einer AD FS-Gesamtstruktur hinaus auf mehreren Plattformen dient, einschließlich Windows- und 

Nicht-Windows-Umgebungen. Die AD FS eignen sich gut für Anwendungen mit Schnittstelle zum 

Internet oder beliebige Umgebungen, in denen ein einzelnes Benutzerkonto Zugriff auf Ressourcen 

in verschiedenen Netzwerken benötigt. In diesen Szenarien werden Benutzer ggf. zur Eingabe von 

Anmeldeinformationen aufgefordert, wenn sie versuchen, auf eine Anwendung zuzugreifen, die eine 

andere Authentifizierungsquelle verwendet (z.B. in einem anderen Unternehmen oder einer anderen 

Gesamtstruktur, z.B. einer Umkreisnetzwerk-Gesamtstruktur im selben Unternehmen). 

Bei Implementierung der AD FS können Sie eine Verbundvertrauensstellung zwischen zwei verschiedenen 

Unternehmen oder Gesamtstrukturen einrichten. Diese Verbundvertrauensstellung ermöglicht 

Benutzern das Verwenden der Sicherheitsberechtigungen in ihrer eigenen Gesamtstruktur für den 

Zugriff auf eine Anwendung in einer Umgebung außerhalb ihrer Gesamtstruktur. Die Verbundvertrauensstellung 

wird zwischen Ressourcenorganisationen (d.h. Organisationen, die Ressourcen und 

Anwendungen besitzen und verwalten, auf die über das Internet oder andere Netzwerke zugegriffen 

werden kann) und Kontoorganisationen eingerichtet (d.h. Organisationen, welche die Benutzerkonten 

besitzen und verwalten, denen Zugriff auf die Ressourcen in den Ressourcenorganisationen gewährt 

wird). In diesem Szenario bieten die AD FS einen Zugriff per einmaliger Anmeldung an Ressourcen 

in der Ressourcenorganisation für Benutzer, die in der Kontoorganisation authentifiziert wurden. Die 

einmalige Anmeldung ermöglicht Benutzern die Anmeldung am lokalen Netzwerk und den Empfang 

eines Sicherheitstokens, das einen Zugriff auf Ressourcen in verschiedenen Netzwerken gewährt, die 

so konfiguriert wurden, dass sie diesen Konten vertrauen. Selbst in einer einzelnen Organisation mit 

getrennten Netzwerken und Sicherheitsgrenzen können Benutzer in den Genuss der einmaligen 

Anmeldung für den Zugriff auf alle gewünschten Netzwerkressourcen kommen. Die AD FS eignen 

sich sowohl innerhalb großer Unternehmen mit getrennten Ressourcen- und Kontoorganisationen als 

auch außerhalb der Firewall. Die AD FS können in das Internet ausgedehnt werden, um Zugriffsanforderungen 

von Benutzern zu unterstützen, die über einen Webbrowser auf Ressourcen zugreifen.


Die AD FS unter Windows Server 2008 bestehen aus verschiedenen Komponenten: 

• Verbunddienst Dieser Dienst umfasst einen oder mehrere Verbundserver, die über eine gemeinsame 

Vertrauensrichtlinie verfügen. Mithilfe von Verbundservern können Authentifizierungsanforderungen 

von Benutzerkonten in anderen Unternehmen oder von Clients irgendwo im Internet 

weitergeleitet werden. 

• Verbunddienstproxy Der Verbunddienstproxy ist ein Stellvertreter des Verbunddienstes im 

Umkreisnetzwerk (auch DMZ [Demilitarisierte Zone] oder überwachtes Subnetz genannt). Der 

Verbunddienstproxy nutzt WS-F PRP-Protokolle (WS-Federation Passive Requestor Profile) zum 

Erfassen von Benutzeranmeldeinformationen aus Browserclients und sendet diese im Auftrag der 

Benutzer an den Verbunddienst. 

• Ansprüche unterstützender Agent Sie verwenden den Ansprüche unterstützenden Agent auf einem 

Webserver, der als Host einer Ansprüche unterstützenden Anwendung fungiert, um Abfragen für 

Ansprüche von Sicherheitstoken an die AD FS zu ermöglichen. Eine Ansprüche unterstützende 

Anwendung ist eine Microsoft ASP.NET-Anwendung, die Ansprüche in einem AD FS-Sicherheitstoken 

verwendet, um Autorisierungsentscheidungen zu treffen und Anwendungen anzupassen. 

• Windows-Token-basierter Agent Sie verwenden den Windows-Token-basierten Agent in einem 

Webserver, der als Host einer Windows NT-Token-basierten Anwendung dient, um die Umwandlung 

eines AD FS-Sicherheitstoken in ein Windows NT-Zugriffstoken auf Identitätswechselebene 

zu ermöglichen. Eine Windows NT-Token-basierte Anwendung ist eine Anwendung, die Windows-basierte 

Autorisierungsmechanismen unterstützt. 

Eine der zahlreichen Verbesserungen der AD FS unter Windows Server 2008 zeigt sich beim Installationsprozess. 

Im Gegensatz zu den AD FS unter Windows Server 2003 R2, die über die Systemsteuerungsoption 

Software installiert werden mussten, werden die AD FS unter Windows Server 2008 wie 

die anderen Serverrollen über den Server-Manager installiert. Die AD FS benötigen einen Verzeichnisdienst 

und können entweder mit den AD DS oder den Active Directory Lightweight Directory Services 

(AD LDS) als Verzeichnis arbeiten. Weitere Verbesserungen bei den AD FS unter Windows 

Server 2008 ist die enge Integration zwischen den AD FS und Office SharePoint Server 2007 hinsichtlich 

Mitgliedschafts- und Rollenanbietern und mit den AD RMS für die gemeinsame Nutzung 

von durch Rechte geschützten Inhalten mit vertrauenswürdigen externen Partnern. 

Nach Installation der AD FS können Sie diesen Dienst mit der MMC (Microsoft Management Console) 

verwalten. Die Rollendienste Verbunddienst und Verbunddienstproxy werden über das Snap-In 

Active Directory-Verbunddienste verwaltet. 

Active Directory Lightweight Directory Services 

Die Active Directory Lightweight Directory Services (AD LDS) (zuvor Active Directory Application 

Mode [ADAM] genannt) sind ein LDAP-Verzeichnisdienst (Lightweight Directory Access Protocol), 

der die AD DS-Funktionalität in verschiedenen Szenarien ersetzen oder zusammen mit den AD DS 

bereitgestellt werden kann. Die AD LDS wurden speziell entwickelt, um verzeichnisfähigen Anwendungen 

Verzeichnisdienste ohne die Abhängigkeiten der AD DS bereitzustellen. Bei Verwenden der 

AD LDS können Sie einen „abgespeckten“ Verzeichnisdienst ohne Domänen oder Gesamtstrukturen 

(Anforderungen an die AD DS) bereitstellen und für jede bereitgestellte AD LDS-Instanz eigene 

Schemas unterstützen. Die AD DS sind in der ganzen Gesamtstruktur auf ein einzelnes Schema 

begrenzt.


Es gibt mehrere Szenarien, in denen Sie die AD LDS bereitstellen können: 

• Bereitstellen eines Unternehmensverzeichnisspeichers Die AD LDS dienen zum Speichern anwendungsspezifischer 

Daten, die nur für die Unternehmensanwendung relevant sind. Diese Informationen 

können auf demselben Server wie die Anwendung gespeichert und auf mehrere AD LDS- 

Server im gesamten Unternehmen repliziert werden. Die AD LDS können ausschließlich die 

Konfigurationsdaten für die Unternehmensanwendung speichern, während die AD DS zum Speichern 

der Sicherheitsprinzipaldaten verwendet werden können, wodurch sich die Anzahl der 

anwendungsspezifischen Benutzerkontodatenbanken im Netzwerk reduziert. 

• Bereitstellen eines Authentifizierungsspeichers im Extranet Die AD LDS können diesen Authentifizierungsspeicher 

bereitstellen, da Benutzerobjekte gespeichert werden können, die keine Windows-Sicherheitsprinzipale 

sind, jedoch mithilfe einfacher LDAP-Bindungen authentifiziert 

werden können. Webclients können über einen einfachen LDAP-Verzeichnisdienst auf portalbasierte 

Anwendungen zugreifen. 

• Bereitstellen eines Konfigurationsspeichers für verteilte Anwendungen In diesem Szenario wird die 

AD LDS-Instanz, die als Konfigurationsspeicher der Anwendung dient, mit einer verteilten 

Anwendung in einem Paket gebündelt. Auf diese Weise müssen Anwendungsentwickler vor der 

Installation der Anwendung nicht die Verfügbarkeit eines Verzeichnisdienstes berücksichtigen. 

Stattdessen werden die AD LDS in den Installationsprozess der Anwendung einbezogen, um 

sicherzustellen, dass die Anwendung unmittelbar im Anschluss an die Installation Zugriff auf 

einen Verzeichnisdienst hat. Die Anwendung konfiguriert und verwaltet anschließend die AD 

LDS vollkommen selbständig bzw. teilweise (abhängig davon, wie die Anwendung der AD LDS- 

Verwaltung unterliegt) und verwendet die AD LDS zum Erfüllen ihrer verschiedenen Datenanforderungen. 

Hinweis Die Serverfunktion Edge-Transport in Exchange Server 2007 ist ein gutes Beispiel einer 

Anwendung, die mit den AD LDS arbeitet. Bei Installation dieser Serverfunktion werden die AD LDS 

automatisch für deren Unterstützung installiert und konfiguriert. 

• Migrieren älterer verzeichnisfähiger Anwendungen Sie können die AD LDS bereitstellen, um Unterstützung 

für ältere Anwendungen zu bieten, die auf der Benennung im X.500-Format basieren, 

während die AD DS im Unternehmen dazu dienen können, eine gemeinsam genutzte Sicherheitsinfrastruktur 

bereitzustellen. Sie können ein Metaverzeichnis einsetzen oder die Synchronisierung 

zwischen den AD LDS und den AD DS konfigurieren, um zum Erzielen einer reibungslosen 

Migration die Daten in den AD DS und AD LDS zu synchronisieren. 

Nachdem Sie die Serverrolle AD LDS über den Server-Manager Ihrem Server hinzugefügt haben, 

erstellen Sie mit dem Setup-Assistenten für Active Directory Lightweight Directory Services AD 

LDS-Dienstinstanzen und -Anwendungspartitionen. Sie können mehrere Instanzen der AD LDS auf 

einem einzelnen Server installieren, die alle ein anderes Schema verwenden können. Innerhalb der 

einzelnen Instanzen können Sie mehrere Anwendungspartitionen konfigurieren. Nach Erstellen der 

Instanzen und Partitionen können Sie diese mit beliebigen Verwaltungstools verwalten, z.B. mit dem 

MMC-Snap-In ADSI Edit oder LDP.exe. 

Active Directory-Rechteverwaltungsdienste 

Die Active Directory-Rechteverwaltungsdienste (AD RMS) dienen zum Optimieren der vorhandenen 

Sicherheitslösung eines Unternehmens durch Bereitstellen einer objektbasierten dauerhaft geltenden 

Nutzungsrichtlinie.


Die AD RMS erweitern die Sicherheitslösung dergestalt, dass dauerhaft geltende Nutzungsrichtlinien 

einbezogen werden, die dem Schutz vertraulicher Daten, z.B. Textverarbeitungsdateien, Kundendaten, 

E-Mail-Nachrichten und Finanzdaten, dienen. Die Sicherheitseinschränkungen für eine 

bestimmte Datei gelten für das jeweilige Dokument unabhängig von seinem Speicherort und werden 

nicht dem Container zugewiesen, in dem es gespeichert ist (im Gegensatz zu Zugriffssteuerungslisten). 

Mithilfe der AD RMS können Netzwerkbenutzer die Fähigkeit zum Kopieren, Drucken und Weiterleiten 

vertraulicher Daten einschränken. Dadurch können Sie persönliche E-Mail-Nachrichten so senden, 

dass der Empfänger die Nachricht öffnen und lesen, aber nicht ausschneiden, kopieren oder an 

andere Empfänger weiterleiten kann (einschließlich aller Anlagen in der Nachricht). Vertrauliche Firmenkommunikation 

bleibt dadurch vertraulich, dass E-Mail-Empfänger am Weiterleiten von durch 

Rechte geschützter Informationen gehindert werden. Die AD RMS können auch das Kopieren von 

Berechtigungen unterliegenden Daten und deren Einfügung in nicht eingeschränkte E-Mail-Nachrichten 

oder Dokumente verhindern. 

Die AD RMS unter Windows Server 2008 weisen verschiedene Verbesserungen gegenüber Windows 

Rights Management Services (RMS) auf, welche die Verwaltung des Dienstes optimieren und seinen 

Geltungsbereich über die Grenzen des Unternehmens ausdehnen. Die folgenden Features sind neu: 

• Verbesserte Installations- und Verwaltungsumgebung Die AD RMS gehören zum Funktionsumfang 

von Windows Server 2008 und werden als Serverrolle implementiert. Die früheren Versionen der 

RMS mussten aus dem Microsoft Download Center heruntergeladen und anschließend installiert 

werden. Außerdem erfolgt die Verwaltung der AD RMS nun über ein MMC-Snap-In, das wesentlich 

benutzerfreundlicher als die Weboberfläche der früheren RMS-Versionen ist. Ferner werden 

in der AD RMS-Konsole dank Definition der AD RMS-Verwaltungsrollen nur die Teile der Konsole 

angezeigt, auf die der Benutzer zugreifen darf. Ein Benutzer, der beispielsweise zur Verwaltungsrolle 

AD RMS-Vorlagenadministratoren gehört, ist auf Aufgaben beschränkt, die sich 

spezifisch auf Vorlagen beziehen. Alle anderen Verwaltungsaufgaben werden in der AD RMS- 

Konsole nicht angezeigt. 

• Selbstregistrierung des AD RMS-Clusters Der AD RMS-Cluster kann sich selbst registrieren, ohne 

eine Verbindung zum Microsoft-Registrierungsdienst herstellen zu müssen. Durch die Verwendung 

eines Selbstregistrierungszertifikats für den Server erfolgt der Registrierungsprozess ausschließlich 

auf dem lokalen Computer. Dieses neue Feature hebt die Funktionsabhängigkeit vom 

Registrierungsdienst auf und ermöglicht den AD RMS ferner, in einem Netzwerk ausgeführt zu 

werden, das gänzlich vom Internet isoliert ist. 

• Integration mit den Active Directory-Verbunddiensten (AD FS) Die AD RMS und AD FS wurden so 

integriert, dass Unternehmen nun vorhandene Verbundbeziehungen nutzen können, um mit externen 

Partnern zusammenzuarbeiten. In früheren Versionen der RMS waren die Optionen für die 

externe Zusammenarbeit an durch Rechte geschützten Inhalten auf Windows Live ID (früher 

Microsoft Passport) beschränkt. Dank der Integration der AD FS mit den AD RMS können Verbundidentitäten 

zwischen Unternehmen eingerichtet und durch Rechte geschützte Inhalte gemeinsam 

genutzt werden, ohne dass die AD RMS in beiden Unternehmen bereitgestellt sein müssen. 

• Neue AD RMS-Verwaltungsrollen Die Möglichkeit der Delegierung der AD RMS an verschiedene 

Administratoren wird in allen Unternehmensumgebungen benötigt und von den AD RMS in dieser 

Version geboten. Drei Verwaltungsrollen stehen zur Verfügung: AD RMS-Organisationsadministratoren, 

AD RMS-Vorlagenadministratoren und AD RMS-Prüfer. Die neuen AD RMS- 

Verwaltungsrollen ermöglichen das Delegieren von AD RMS-Aufgaben, ohne den Vollzugriff auf 

den gesamten AD RMS-Cluster gewähren zu müssen.

Zusammenfassung 17 

Der AD RMS-fähige Client benötigt AD RMS-fähige Browser oder Anwendungen, z.B. Microsoft 

Word, Outlook oder PowerPoint in Microsoft Office 2007. Um durch Rechte geschützte Inhalte zu 

erstellen, wird Microsoft Office 2007 Enterprise, Professional Plus oder Ultimate benötigt. Windows 

Vista enthält den AD RMS-Client standardmäßig. Bei anderen Clientbetriebssystemen muss der 

RMS-Client installiert werden. Der RMS-Client mit Service Pack 2 (SP2) kann aus dem Microsoft 

Download Center heruntergeladen werden und funktioniert mit Versionen des Clientsbetriebssystems 

vor Windows Vista und Windows Server 2008. Zur weiteren Steigerung der Sicherheit können die AD 

RMS mit anderen Lösungen wie Smartcards integriert werden. 

Hinweis Empfänger von mit Rechten geschützten Nachrichten, die keine E-Mail-Anwendung ausführen, 

die Nachrichten mit eingeschränkten Berechtigungen unterstützen, z.B. Microsoft Office 2003 oder Microsoft 

Office 2007, können diese Nachrichten anzeigen, indem Sie aus dem Microsoft Download Center unter 

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=b48f920b-5af0-46b4-994f- 

2f62582cc86f das Rights Management Add-On für Internet Explorer herunterladen. Dieser Download ist für 

Empfänger erforderlich, die beispielsweise mit Web-E-Mail-Anwendungen arbeiten. 

Die AD RMS werden auf Computern mit dem Betriebssystem Windows Server 2008 installiert. Nach 

der Installation der Serverrolle AD RMS werden die benötigten Dienste installiert. Internetinformationsdienste 

(ISS) ist beispielsweise ein benötigter Dienst. Die AD RMS benötigen ferner eine Datenbank, 

z.B. Microsoft SQL Server, die entweder auf demselben Server wie die AD RMS oder auf 

einem Remoteserver in derselben AD DS-Gesamtstruktur ausgeführt werden kann. Außerdem wurden 

die AD RMS und AD FS integriert, damit Unternehmen vorhandene Verbundbeziehungen nutzen 

können, um mit externen Partnern zusammenzuarbeiten und Informationen abzusichern. 

Zusammenfassung 

In diesem Kapitel wurden die neuen Features der AD DS sowie die Serverrollen unter Windows Server 

2008 vorgestellt. Nachdem sich Verzeichnisdienstadministratoren mit diesen neuen Features und 

Serverrollen vertraut gemacht haben, können sie die Migration zu Windows Server 2008 einschätzen 

und die neue Funktionalität einplanen, die Windows Server 2008 ihren Unternehmen zur Verfügung 

stellt.

19 


Active Directory-Domänendienstkomponenten 


Physische Struktur der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Logische Struktur der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 


Zusätzliche Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

Als AD DS-Administrator (Active Directory Domain Services, Active Directory-Domänendienste) 

verbringen Sie viel Zeit mit dem Konfigurieren von Benutzer- und Gruppenkonten, die sich in Organisationseinheiten 

oder Containerobjekten innerhalb einer Domäne befinden. Bei der Konfiguration 

dieser Objekte wird die auf der Festplatte des Domänencontrollers gespeicherte Datenbankdatei geändert. 

In den meisten Fällen findet keine direkte Interaktion mit der physischen AD DS-Datenbank 

statt; stattdessen verwenden Sie die AD DS-Verwaltungstools, um die in der Datenbank gespeicherten 

logischen Objekte zu ändern. 

Microsoft Windows Server 2008 AD DS umfasst sowohl eine physische Komponente als auch eine 

logische Struktur aus Objekten im Verzeichnis. Im Hinblick auf die physische Struktur bestehen die 

AD DS aus einer einzigen Datenbankdatei auf der Festplatte jedes Domänencontrollers, der zum Hosten 

des Dienstes eingesetzt wird. Die logische Struktur der AD DS umfasst die zum Speichern der 

Verzeichnisdienstobjekte (z.B. Verzeichnispartitionen, -domänen und -gesamtstrukturen) in einem 

Unternehmen verwendeten Container. In diesem Kapitel erfahren Sie zunächst, aus welchen physischen 

Komponenten die AD DS bestehen. Anschließend wird die logische Struktur einer AD DS- 

Implementierung untersucht. Fundierte Kenntnisse der physischen Struktur des Verzeichnisdiensts 

sind wichtig, für eine erfolgreiche Implementierung und Verwaltung der Verzeichnisdienstinfrastruktur 

ist jedoch das Verständnis der logischen Struktur entscheidend. Denn mit dieser logischen Struktur 

des Verzeichnisdiensts interagieren Sie täglich. 

Physische Struktur der AD DS 

AD DS-Daten werden in erster Linie als eine einzige Datenbankdatei gespeichert. Diese Datenbankdatei 

wird auf Domänencontrollern gespeichert, die Administratoren Zugriff auf die Datenbank sowie 

Verzeichnisdienstfunktionen (z.B. die Authentifizierung und Autorisierung für andere Benutzer und 

Computer) bieten. Bei der Implementierung der AD DS kann eine beliebige Anzahl an Domänencontrollern 

hinzugefügt werden, um die Verzeichnisdienstanforderungen einer Organisation zu erfüllen.

20 Kapitel 2: Active Directory-Domänendienstkomponenten 

Sämtliche Domänencontroller in einer Domäne bieten im Wesentlichen dieselben Dienste. Es gibt 

jedoch fünf spezifische Rollen, die sich zu einem Zeitpunkt auf einem einzigen Domänencontroller 

befinden können. Diese Rollen werden als FSMO-Rollen (Flexible Single-Master Operations) 

bezeichnet. Die AD DS ermöglichen ferner einzigartige Domänencontrollerrollen für globale Katalogserver 

und schreibgeschützte Domänencontroller. In diesem Abschnitt werden sowohl der AD DS- 

Datenspeicher als auch die zum Hosten dieses Speichers eingesetzten Domänencontroller untersucht. 

Verzeichnisdatenspeicher 

Sämtliche Daten in der AD DS-Datenbank werden in einer Datei Ntds.dit und in den Transaktionsprotokollen 

auf dem Domänencontroller gespeichert. Diese Datendateien werden standardmäßig im 

Ordner %SystemRoot%\NTDS auf dem Domänencontroller gespeichert. Sie enthalten alle Verzeichnisinformationen 

für die Domäne sowie Daten, die von sämtlichen Domänencontrollern in einer 

Organisation gemeinsam verwendet werden. Globale Katalogserver speichern in diesen Dateien 

zudem die Daten des globalen Katalogs. 

Hinweis Wenngleich Sie nur selten direkt mit den AD DS-Datendateien interagieren, müssen Sie verstehen, 

wie die Datenbank in den AD DS verwaltet wird. Möglicherweise müssen Sie während der Notfallwiederherstellung 

mit diesem Dateien arbeiten. Weitere Informationen zum Warten und Wiederherstellen der 

AD DS-Datenbank finden Sie in Kapitel 14, „Überwachen und Warten von Active Directory“, und Kapitel 15, 

„Active Directory-Notfallwiederherstellung“. 

Der AD DS-Datenspeicher wird auf jedem Domänencontroller in der Gesamtstruktur implementiert. 

Er umfasst verschiedene Komponenten, die in Abbildung 2.1 gezeigt sind. 

Schnittstellen – LDAP, REPL, MAPI, SAM 

Ntdsa.dll 

DSA 

Datenbanklayer 

ESE (Esent.dll) 

Abbildung 2.1 

Der AD DS-Datenspeicher umfasst verschiedene Komponenten 

Die Komponenten des Datenspeichers sind in Tabelle 2.1 beschrieben.

Physische Struktur der AD DS 21 

Tabelle 2.1 

Datenspeicherkomponenten 

Komponente 

Schnittstellen 

Verzeichnisdienst-Agent 

(Directory Service Agent, 

DSA) (Ntdsa.dll) 

Datenbankschicht 

Beschreibung 

Clientcomputer, Administratoren und andere Domänencontroller können nicht direkt mit der 

Datenbank kommunizieren. Der Datenspeicher unterstützt die folgenden Schnittstellen für Verzeichnisclients 

und andere Verzeichnisserver zur Kommunikation mit dem Datenspeicher: 

• Lightweight Directory Access Protocol (LDAP) LDAP v3 ist die von Verzeichnisclients 

am häufigsten verwendete Schnittstelle, um Informationen im Verzeichnisspeicher 

zu ermitteln. LDAP v3 ist abwärtskompatibel mit LDAP v2. Für den Zugriff auf die LDAP- 

Schnittstelle können Clients Port 389 (der standardmäßige LDAP-Port), Port 636 (über 

SSL gesichertes LDAP), Port 3268 (für Suchen im globalen Katalog) und Port 3269 (über 

SSL gesichertes LDAP, für Suchen im globalen Katalog) verwenden. Clients können auch 

UDP-Port 389 für LDAP und Netlogon verwenden (diese Schnittstelle wird zum Ermitteln 

von Domänencontrollern). 

• REPL-Verwaltungsschnittstelle zur Replikation zwischen Domänencontrollern Die 

REPL-Verwaltungsschnittstelle wird von AD DS-Verwaltungstools und während der Replikation 

zwischen Domänencontrollern verwendet. Diese Schnittstelle bietet Funktionen zum 

Ermitteln von Informationen zu Domänencontrollern, zum Konvertieren von Netzwerkobjektnamen 

mit unterschiedlichen Formaten und zum Bearbeiten von Dienstprinzipalnamen 

(Service Principal Name, SPN) und DSAs. Der Zugriff auf diese Schnittstelle erfolgt über 

Remoteprozeduraufrufe (Remote Procedure Call, RPCs) und über SMTP (nur bei der 

SMTP-basierten Replikation). 

• Messaging API (MAPI) MAPI wird von Messagingclients wie Outlook für den Zugriff auf 

die Microsoft Exchange Server-Daten im Datenspeicher verwendet. Exchange Server 

2000 und höher verwenden den AD DS-Datenspeicher zum Speichern aller Empfängerinformationen, 

und über die MAPI-Schnittstelle können Messagingclients auf das globale 

Adressbuch zugreifen. MAPI nutzt die RPC-Kommunikation. 

• Sicherheitskontenverwaltung (Security Accounts Manager, SAM) Bei SAM handelt 

es sich um eine Schnittstelle zum Verbinden des Verzeichnisdienst-Agents (Directory Service 

Agent, DSA) im Auftrag von Clients, die Windows NT 4.0 oder niedriger verwenden. 

Diese Clients verwenden die Windows NT 4.0-Netzwerk-APIs, um über SAM eine Verbindung 

mit dem DSA herzustellen. Für die SAM-Kommunikation wird ebenfalls die RPC- 

Kommunikation verwendet. 

Der DSA wird als Ntdsai.dll auf jedem Domänencontroller ausgeführt und bietet die Schnittstellen 

für den Datenspeicherzugriff. Ferner wird der DSA zum Erzwingen der Verzeichnissemantik, 

Verwalten des Schemas, Sicherstellen der Objektidentität sowie Anwenden von 

Datentypen auf Attribute eingesetzt. 

Wenn Clients oder andere Domänencontroller auf den Verzeichnisspeicher zugreifen müssen, 

verwenden Sie eine der unterstützten Schnittstellen, um eine Verbindung mit dem DSA 

herzustellen, und führen anschließend für AD DS-Objekte und ihre Attribute Such-, Lese- und 

Schreibvorgänge durch. 

Die Datenbankschicht befindet sich in der Datei Ntdsai.dll und bietet eine interne Schnittstelle 

zwischen dem DSA und der Verzeichnisdatenbank. Der DSA kann keine direkte Verbindung 

zur Datenbank herstellen; Anwendungen verbinden sich über die Datenbankschicht. Die Datenbankschicht 

bietet auch eine Objektansicht der Verzeichnisdatenbank, um dem Verzeichnisdienst-Agent 

den Zugriff auf Daten in Form hierarchischer Container zu ermöglichen. 

Über die Datenbankschicht werden ferner einzelne Datensätze (Objekte), Attribute in Datensätzen 

und Werte in Attributen erstellt, abgerufen und gelöscht.


Tabelle 2.1 

Datenspeicherkomponenten (Fortsetzung) 

Komponente 


Datenbankdateien 

Beschreibung 

Die Extensible Storage Engine (ESE) ist eine Windows-Komponente, die von den AD DS sowie 

verschiedenen anderen Windows-Komponenten als Schnittstelle zur Datenbank verwendet 

wird. Die ESE ist zuständig für die Indizierung der Daten in der Datenbankdatei und die 

Übertragung der Daten in die und aus der Datenbank. Ferner wird sie zur Verwaltung der Zeilen 

und Spalten der Datenbank eingesetzt. Mithilfe von ESE können Anwendungen Daten 

speichern und abrufen. Zudem implementiert diese Komponente den Transaktionsprozess 

zum Übernehmen von Änderungen in der Datenbank. 

Der Datenspeicher speichert Verzeichnisinformationen in einer einzigen Datenbankdatei. Zusätzlich 

verwendet der Datenspeicher Transaktionsprotokolldateien, in denen nicht übernommene 

Änderungen sowie übernommene Transaktionen vorübergehend gespeichert werden, 

bevor diese in die Datenbank übernommen werden. 

Hinweis Eine zweite Kopie der Datei Ntds.dit befindet sich auf jedem Domänencontroller im Verzeichnis 

%SystemRoot%\System32. Bei dieser Version der Datei handelt es sich um die Verteilungskopie (Standardkopie) 

der Verzeichnisdatenbank, die lediglich zum Installieren der AD DS verwendet wird. Diese Datei wird 

bei der Installation von Microsoft Windows Server 2008 auf den Server kopiert, sodass der Server zu einem 

Domänencontroller heraufgestuft werden kann, ohne auf das Installationsmedium zugreifen zu müssen. Bei 

der Ausführung des Assistenten zum Installieren von Active Directory-Domänendiensten (Dcpromo.exe) wird 

die Datei Ntds.dit aus dem Ordner System32 in den Ordner NTDS kopiert. Die im Ordner NTDS gespeicherte 

Kopie ist anschließend die aktive Kopie des Verzeichnisdatenspeichers. Wenn dies nicht der erste 

Domänencontroller in der Domäne ist, wird diese Datei über den Replikationsprozess von anderen Domänencontrollern 

in der Domäne aktualisiert. 

Domänencontroller 

Per Definition ist jeder Computer unter Windows Server 2008, auf dem eine Kopie der AD DS- 

Datenbank gespeichert ist, ein Domänencontroller. Domänencontroller bieten Authentifizierungsdienste 

für die Domäne sowie Verzeichnissuchdienste. Mit einigen Ausnahmen, die weiter unten in 

diesem Kapitel erläutert werden, werden sämtliche Domänencontroller identisch erstellt. Unter Verwendung 

der in Kapitel 4, „Active Directory-Domänendienstreplikation“, beschriebenen Multimasterreplikation 

wird auf jedem Domänencontroller in der Domäne eine aktuelle Kopie der Domänendatenbank 

gepflegt. Ferner kann jeder Domänencontroller Änderungen an der Datenbank vornehmen. 

Neben den Domänencontrollern zum Hosten der AD DS sind mehrere Domänencontroller mit besonderem 

Zweck vorhanden, welche die AD DS zum Ausführen bestimmter Funktionen benötigen. 

Dabei handelt es sich um die globalen Katalogserver und die Betriebsmaster. Zusätzlich unterstützt 

Windows Server 2008 schreibgeschützte Domänencontroller (Read-Only Domain Controllers, 

RODCs). 

Globale Katalogserver 

Der globale Katalog ist ein schreibgeschütztes Teilreplikat aller Domänenverzeichnispartitionen in der 

Gesamtstruktur. Die zusätzlichen Domänenverzeichnispartitionen sind nicht vollständig, da lediglich 

eine beschränkte Menge an Attributen für jedes Objekt enthalten ist. Da nur die am häufigsten für 

Suchvorgänge verwendeten Attribute enthalten sind, kann jedes Objekt in jeder Domäne innerhalb der 

Gesamtstruktur in der Datenbank eines einzigen globalen Katalogservers dargestellt werden.


Der globale Katalog bietet selbst bei einer Gesamtstruktur mit mehreren Domänen und Domänenstrukturstämmen 

die Möglichkeit zur effizienten Suche nach Objekten in einer beliebigen Domäne. 

Da für Suchvorgänge, die unter Verwendung des globalen Katalogs durchgeführt werden, nicht auf 

unterschiedliche Domänencontroller verweisen wird, sind diese Vorgänge schneller. 

Der globale Katalog wird auf Domänencontrollern gespeichert, die als globale Katalogserver vorgesehen 

sind, und über die Multimasterreplikation verteilt. 

Ob ein Attribut in den globalen Katalog repliziert wird, hängt vom Schema ab. Die Attribute, die in 

den globalen Katalog aufgenommen werden, sind im Schema als Teilattributsatz (Partial Attribute 

Set, PAS) gekennzeichnet. Der PAS ist durch das Attribut isMemberOfPartialAttributeSet gekennzeichnet: 

wenn dieses Attribut auf true gesetzt ist, wird es in den globalen Katalog aufgenommen. 

Administratoren können Attribute mithilfe des Snap-Ins für das Active Directory-Schema zum globalen 

Katalog hinzufügen. Beispielsweise wird das Attribut Department standardmäßig nicht zum globalen 

Katalog hinzugefügt. Wenn die Benutzer in der Lage sein sollen, in mehreren Domänen basierend 

auf der Abteilung nach einem anderen Benutzer suchen zu können, sollten Sie dieses Attribut 

gegebenenfalls zum globalen Katalog hinzufügen. 

Zum Hinzufügen eines Attributs zum globalen Katalog greifen Sie im Active Directory-Schema auf 

die Attributeigenschaften zu, und wählen Sie die Option Attribut in den globalen Katalog replizieren. 

Dadurch wird der Wert des Parameters isMemberOfPartialAttributeSet für das Attribut auf true 

gesetzt. Abbildung 2.2 zeigt die zur Konfiguration eines Attributs als Mitglied des PAS verwendete 

Oberfläche. 

Abbildung 2.2 Das Attribut Department kann über das MMC-Snap-In für das Active Directory-Schema zum 

globalen Katalog hinzugefügt werden


Vorsicht Gehen Sie beim Hinzufügen von Attributen zum globalen Katalog mit Vorsicht vor. Wenn ein 

Attribut zum globalen Katalog hinzugefügt wird, muss der globale Katalog in allen Domänen innerhalb der 

Gesamtstruktur neu berechnet werden, und die aktualisierten Informationen müssen auf allen globalen 

Katalogservern repliziert werden. Dies ist insbesondere dann wichtig, wenn eine Umgebung über Domänencontroller 

unter Windows 2000 verfügt. Wenn ein neues Attribut zum globalen Katalog auf einem Domänencontroller 

unter Windows 2000 hinzugefügt oder von diesem entfernt wird, erstellt und repliziert der Domänencontroller 

den gesamten globalen Katalog neu. Domänencontroller unter Windows Server 2003 und 

höher replizieren lediglich das Delta (also das Attribut, das zum PAS hinzugefügt oder aus diesem entfernt 

wurde). In großen Organisationen mit mehreren Domänen kann dies eine erhebliche Prozessor- und Netzwerklast 

verursachen. In den meisten Fällen wird der PAS nur geändert, wenn dies für eine bestimmte 

Anwendung erforderlich ist. Bei der Installation von Exchange 2000 Server oder höher werden z.B. eine 

Vielzahl von neuen Attributen zum globalen Katalog hinzugefügt. 

Der erste in der Gesamtstruktur installierte Domänencontroller wird automatisch als globaler Katalogserver 

konfiguriert. Während der Installation der AD DS oder über die Option Globaler Katalog im 

Verwaltungstool Active Directory-Standorte und -Dienste können weitere Domänencontroller als globale 

Katalogserver bestimmt werden. 

Hinweis In den meisten Fällen sollte an jedem Bürostandort, der als AD DS-Standort konfiguriert ist, ein 

globaler Katalogserver konfiguriert werden. Dadurch wird der Anmeldeprozess für Benutzer in diesem Büro 

optimiert. In Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“ finden Sie Informationen zur 

erforderlichen Anzahl an globalen Katalogservern sowie zum geeigneten Standort dieser Komponenten. 

Globale Katalogserver sind aus verschiedenen Gründen wichtig. Ein Grund ist, dass diese Server die 

Effizienz von AD DS-Suchvorgängen erhöhen. Ohne einen globalen Katalog würden Suchanfragen, die 

von einem Domänencontroller für ein Objekt in einer anderen Domäne empfangen werden, dazu führen, 

dass dieser Domänencontroller die Abfrage an einen Domänencontroller in der Objektdomäne 

weitergibt. Diese Suche wäre nur möglich, wenn die Suchabfrage die Domäne enthält, in der sich das 

Objekt befindet. Da der globale Katalog eine vollständige Liste aller Objekte in der Gesamtstruktur 

enthält, kann der globale Katalogserver unter Verwendung eines Attributs, das in den globalen Katalog 

repliziert wurde, auf sämtliche Abfragen antworten, ohne dass auf einen anderen Domänencontroller 

verwiesen werden muss. 

Hinweis Globale Katalogabfragen sind mit normalen LDAP-Abfragen identisch, die an einen Domänencontroller 

unter Windows Server 2008 gesendet werden. Diese Abfragen unterscheiden sich lediglich 

dadurch, dass für die globale Katalogabfrage anstelle des TCP-Ports 389 (der LDAP-Standardport) der TCP- 

Port 3268 verwendet wird. Wenn ein Domänencontroller, der auch als globaler Katalogserver eingesetzt wird, 

eine Abfrage über Port 389 empfängt, wird der globale Katalog nicht nach Objekten in anderen Domänen 

durchsucht. 

Globale Katalogserver werden ferner bei der Verarbeitung von Benutzeranmeldungen verwendet. 

Bei jeder Benutzeranmeldung an einer Domäne wird ein globaler Katalogserver kontaktiert. Der 

Grund dafür ist, dass Domänencontroller, die nicht als globaler Katalogserver konfiguriert sind, keine 

Informationen zu universellen Gruppenmitgliedschaft enthalten. Universelle Gruppen können Benutzer- 

und Gruppenkonten aus einer beliebigen Domäne innerhalb einer bestimmten Gesamtstruktur 

umfassen. Da universelle Gruppenmitgliedschaften gesamtstrukturweit gelten, kann die Gruppenmitgliedschaft 

nur durch einen Domänencontroller aufgelöst werden, der über gesamtstrukturweite Verzeichnisinformationen 

verfügt – der globale Katalog.


Um ein geeignetes Sicherheitstoken für den Benutzer zu generieren, der die Authentifizierungsanforderung 

gesendet hat, muss zum Ermitteln der universellen Gruppenmitgliedschaft des Benutzers der 

globale Katalog kontaktiert werden. 

Hinweis Windows Server 2008 unterstützt das als Zwischenspeichern der universellen Gruppenmitgliedschaft 

bezeichnete Feature, über das die Anmeldung an einem Windows Server 2008-Netzwerk ohne Kontaktierung 

eines globalen Katalogs möglich ist. Nach der Benutzeranmeldung am Domänencontroller kann 

die universelle Gruppenmitgliedschaft auf nicht globalen Katalogdomänencontrollern zwischengespeichert 

werden. Nach dem Erhalt der Informationen von einem globalen Katalog werden diese auf unbestimmte Zeit 

auf dem Domänencontroller für den Standort zwischengespeichert und regelmäßig aktualisiert (standardmäßig 

alle 8 Stunden). Da die authentifizierenden Domänencontroller nicht auf einen globalen Katalog 

zugreifen müssen, führt das Aktivieren dieses Features zu kürzeren Anmeldezeiten für Benutzer an Remotestandorten. 

Die Planung und Konfiguration der Zwischenspeicherung von universellen Gruppenmitgliedschaften 

wird in Kapitel 5 näher erläutert. 

Globale Katalogserver sind ferner zum Verarbeiten von Benutzeranmeldungen erforderlich, wenn 

Benutzer für die Anmeldung einen Benutzerprinzipalnamen (User Principal Name, UPN) verwenden. 

Über UPNs können sich Benutzer unter Verwendung eines konsistenten Benutzernamens an Computern 

in einer beliebigen Domäne innerhalb einer Gesamtstruktur anmelden. Das UPN-Format lautet 

benutzername@domaenenname, der Domänenname muss jedoch nicht mit der Domäne übereinstimmen, 

in der sich das Benutzerkonto befindet. Um die Domäne des Benutzers zu ermitteln, muss der 

UPN im globalen Katalog aufgelöst werden. 

Schreibgeschützte Domänencontroller 

Schreibgeschützte Domänencontroller (Read-Only Domain Controllers, RODC) sind ein weiterer spezieller 

Typ von Domänencontroller, der in Windows Server 2008 AD DS verfügbar ist. RODCs werden 

zum Hosten von schreibgeschützten Versionen der AD DS-Datenbank eingesetzt und bieten sämtliche 

Authentifizierungs- und Autorisierungsdienste, die über andere Domänencontroller bereitgestellt 

werden. 

RODCs sind in erster Linie für die Bereitstellung in Zweigstellenszenarien konzipiert, in denen die 

physische Sicherheit des Domänencontrollers nicht sichergestellt werden kann, oder in Szenarien, in 

denen das lokale Speichern von Domänenkennwörtern als Sicherheitsrisiko eingestuft wird. Ferner 

können RODCs schreibgeschützte Versionen der in den AD DS integrierten DNS-Zonen enthalten 

und als globale Katalogserver konfiguriert werden. 

Hinweis Ziehen Sie für zusätzliche Sicherheit die Bereitstellung von RODCs mit der Server Core-Installationsoption 

von Windows Server 2008 in Betracht. Diese Installationsoption bietet keine grafischen Verwaltungstools. 

Da RODCs an Standorten bereitgestellt werden können, die nicht als sicher betrachtet werden, 

sollten zudem keine normalen Domänencontroller an diesen Standorten bereitgestellt werden. 

Zwischenspeichern von Anmeldeinformationen auf RODCs 

Eine der verfügbaren Konfigurationsoptionen auf einem RODC ist das Zwischenspeichern von 

Anmeldeinformationen. Beim Zwischenspeichern von Anmeldeinformationen wird das mit Sicherheitsprinzipalen 

verknüpfte Kennwort gespeichert. Alle beschreibbaren Domänencontroller haben 

Zugriff auf die Anmeldeinformationen sämtlicher Sicherheitsprinzipale. Um die Sicherheit eines 

RODC zu erhöhen, kann eingeschränkt werden, welche Anmeldeinformationen auf einem RODC 

zwischengespeichert werden.


Standardmäßig werden lediglich die Anmeldeinformationen des RODC-Computerkontos und eines 

speziellen KRBTGT-Kontos auf dem RODC gespeichert. Dies bedeutet, dass der RODC bei der 

Authentifizierung eines Benutzers oder Computers gegenüber dem RODC über eine Verbindung zu 

einem beschreibbaren Domänencontroller verfügen muss. Bei Empfang der Authentifizierungsanforderung 

leitet der RODC diese an einen beschreibbaren Domänencontroller weiter. 

Die standardmäßige Konfiguration der Zwischenspeicherung von Anmeldeinformationen kann über 

die Kennwortreplikationsrichtlinie für RODCs geändert werden. Die Kennwortreplikationsrichtlinie 

sollte möglicherweise z.B. so konfiguriert werden, dass die Anmeldeinformationen aller Benutzer-, 

Computer- und Dienstkonten in der Zweigstelle auf dem RODC zwischengespeichert werden. Wenn 

die Kennwortreplikationsrichtlinie geändert wird, werden Kennwörter nach der nächsten erfolgreichen 

Anmeldung eines in der Richtlinie angegebenen Sicherheitsprinzipals auf dem RODC zwischengespeichert. 

Nach der erfolgreichen Authentifizierung eines Kontos versucht der RODC, einen 

beschreibbaren Domänencontroller am Nebenstandort zu kontaktieren, und fordert eine Kopie der 

geeigneten Anmeldeinformationen an. Der beschreibbare Domänencontroller erkennt, dass die Anforderung 

von einem RODC stammt, und überprüft die geltende Kennwortreplikationsrichtlinie für diesen 

RODC. Wenn die Kennwortreplikationsrichtlinie dies zulässt, repliziert der beschreibbare Domänencontroller 

die Anmeldeinformationen auf dem RODC, und diese Informationen werden auf dem 

RODC zwischengespeichert. Nach der Zwischenspeicherung der Anmeldeinformationen auf dem 

RODC kann der RODC die Anmeldeanforderungen des Benutzers direkt verarbeiten, bis die Anmeldeinformationen 

oder die Kennwortreplikationsrichtlinie geändert werden. 

Durch die Einschränkung der Zwischenspeicherung von Anmeldeinformationen auf dem RODC kann 

die potenzielle Offenlegung von Anmeldeinformationen bei Diebstahl des RODC beschränkt werden. 

Typischerweise sind lediglich die Anmeldeinformationen einer kleinen Untermenge an Domänenbenutzern 

auf einem RODC zwischengespeichert. Bei Diebstahl des RODC können folglich nur diese 

zwischengespeicherten Anmeldeinformationen zu missbräuchlichen Zwecken verwendet werden. In 

diesem Fall kann über Active Directory-Benutzer und -Computer problemlos ermittelt werden, welche 

Anmeldeinformationen auf dem Server zwischengespeichert werden. Anschließend können die 

Kennwörter für all diese Konten zurückgesetzt werden. 

Zur Unterstützung der RODC-Kennwortreplikationsrichtlinie umfasst Windows Server 2008 AD DS 

neue Attribute, die einem RODC zugewiesen werden. Dazu zählen die folgenden Attribute: 

• msDS-Reveal-OnDemandGroup Dieses Attribut kennzeichnet eine Gruppe, deren Mitglieder 

berechtigt sind, ihre Anmeldeinformationen auf dem RODC zwischenzuspeichern. 

• msDS-NeverRevealGroup Dieses Attribut kennzeichnet eine Gruppe, für die das Zwischenspeichern 

von Anmeldeinformationen auf dem RODC für sämtliche Gruppenmitglieder gesperrt ist. 

Dieses Attribut enthält per Voreinstellung sämtliche Administratorkonten. Es wirkt sich nicht auf 

die Möglichkeit dieser Sicherheitsprinzipale aus, über den RODC eine Authentifizierung durchzuführen. 

• msDS-RevealedList Dieses Attribut enthält eine Liste von Sicherheitsprinzipalen, deren Anmeldeinformationen 

auf dem RODC zwischengespeichert sind. 

• msDS-AuthenticatedToAccountList Dieses Attribut umfasst eine Liste von Sicherheitsprinzipalen 

in der lokalen Domäne, die gegenüber dem RODC authentifiziert wurden. Über die RODC-Eigenschaften 

in Active Directory-Benutzer und -Computer kann ermittelt werden, welche Computer 

und Benutzer den RODC zur Anmeldung verwenden. Auf diese Weise kann die Kennwortreplikationsrichtlinie 

für den RODC bearbeitet und präzise angepasst werden.


Delegieren von Administratorrechten für einen RODC 

Ein weiteres für schreibgeschützte Domänencontroller verfügbares Feature ist die Trennung von 

Administratorrollen, über die ein delegierter lokaler Administrator für den RODC konfiguriert werden 

kann, ohne Berechtigungen auf Domänenebene zuzuweisen. Der delegierte Administrator kann 

sich für Verwaltungs- und Wartungsarbeiten (z.B. zur Aktualisierung eines Treibers) an einem RODC 

anmelden. Er könnte sich jedoch nicht an einem anderen Domänencontroller anmelden oder andere 

Verwaltungsaufgaben in der Domäne ausführen. Die Delegierung von Administratorrechten für einen 

RODC sollte in Betracht gezogen werden, wenn sich der Domänencontroller an einem Zweigstellenstandort 

ohne Domänenadministratoren befindet. 

Sicherheitswarnung Für einen RODC delegierte lokale Administratoren verfügen über direkten Zugriff auf 

die Datenbankdateien der Active Directory-Domänendienste und könnten folglich auf sämtliche auf dem RODC 

gespeicherten Informationen zugreifen (einschließlich der zwischengespeicherten Anmeldeinformationen). Aus 

diesem Grund sollten nur äußerst vertrauenswürdige Personen als delegierte lokale Administratoren gewählt 

werden. 

Hinweis Der delegierte lokale Administrator kann während der Ausführung des Assistenten zum Installieren 

von Active Directory-Domänendiensten zum RODC hinzugefügt werden. Wenn Sie lokale Administratorrechte 

delegieren, wird das Benutzerkonto nicht zu einer zusätzlichen Sicherheitsgruppe hinzugefügt. 

Stattdessen wird der Benutzer- oder Gruppenname in einem Attribut für das RODC-Computerobjekt in 

den AD DS gespeichert, das beim Versuch des Benutzers, sich am RODC anzumelden, verwendet wird. 

Beachten Sie, dass die Anmeldeinformationen des delegierten lokalen Administrators per Voreinstellung 

nicht auf dem RODC zwischengespeichert werden. Dies bedeutet, dass sich der delegierte lokale Administrator 

nicht am RODC anmelden kann, wenn kein beschreibbarer Domänencontroller verfügbar ist. Ziehen 

Sie das Ändern dieser Einstellung in Betracht, wenn die lokale Verwaltung auf dem RODC beim Ausfall 

einer WAN-Verbindung erforderlich ist. Zum Hinzufügen von lokalen Administratoren zu den RODC-Administratorengruppen 

nach der Konfiguration der AD DS verwenden Sie das Befehlszeilentool Dsmgmt.exe. 

Umfassende Informationen zu diesem Thema finden Sie in Kapitel 6, „Installieren der Active Directory- 

Domänendienste“. 

Einschränkungen beim Einsatz von RODCs 

Einige für beschreibbare Domänencontroller verfügbare Domänencontrolleroptionen sind auf einem 

RODC nicht verfügbar. Ein RODC kann nicht als eine der folgenden Rollen konfiguriert werden: 

• Besitzer der Betriebsmasterrolle Besitzer der Betriebsmasterrolle müssen Informationen in die AD 

DS-Datenbank schreiben können. Der Schemamaster muss beispielsweise in der Lage sein, Definitionen 

für neue Objektklassen und Attribute zu schreiben. Der RID-Master muss Werte von 

RID-Pools schreiben können, die anderen Domänencontrollern zugewiesen sind. Da die AD DS- 

Datenbank auf einem RODC schreibgeschützt ist, kann er nicht als Besitzer einer Betriebsmasterrolle 

genutzt werden. 

• Bridgeheadserver Bridgeheadserver werden zum Replizieren von Änderungen zwischen verschiedenen 

Standorten eingesetzt. Da RODCs lediglich Änderungen per Replikation empfangen, 

jedoch keine Replikationsaktualisierungen senden können, können diese Domänencontroller nicht 

als Bridgeheadserver für einen Standort eingesetzt werden. Bei Bereitstellung eines RODC an 

einem Standort mit anderen Domänencontrollern in derselben Domäne oder Gesamtstruktur wird 

einer der anderen Domänencontroller als Bridgeheadserver für den Standort konfiguriert.


Auf der DVD Über das auf der CD enthaltene Windows PowerShell-Skript ListDomainControllers.ps1 können 

sämtliche Domänencontroller in einer Domäne und globalen Katalogserver in einer Gesamtstruktur aufgelistet 

werden. Bei Ausführung von Windows PowerShell auf einem Computer unter Windows Server 2008 

muss die PowerShell-Skriptausführungsrichtlinie über den Befehl Set-ExecutionPolicy RemoteSigned zum 

Zulassen von nicht signierten Zertifikaten konfiguriert werden. Ferner muss bei der Ausführung eines Windows 

PowerShell-Skripts der vollständige Pfad angegeben werden. 

Beispiele für VMScript-Skripte (Visual Basic Scripting Edition) zum Abrufen von AD DS-Informationen finden 

Sie auf der Script Center Script Repository-Website unter http://www.microsoft.com/technet/scriptcenter/ 

scripts/default.mspx?mfr=true. 

Betriebsmaster 

Die AD DS sind als Multimaster-Replikationssystem konzipiert. Dies erfordert, dass mit Ausnahme 

von RODCs sämtliche Domänencontroller über Schreibberechtigungen für die Verzeichnisdatenbank 

verfügen. Dieses System eignet sich für die meisten Verzeichnisvorgänge, für bestimmte Verzeichnisvorgänge 

wird jedoch ein einzelner autorisierender Server benötigt. Domänencontroller mit spezifischen 

Rollen werden als Betriebsmaster bezeichnet, und jeder von ihnen verfügt über eine FSMO- 

Rolle (Flexible Single-Master Operations). Domänencontroller mit Betriebsmasterrollen werden zum 

Ausführen bestimmter Aufgaben eingesetzt, um Konsistenz sicherzustellen und mögliche Konflikte 

bei Einträgen in der AD DS-Datenbank zu verhindern. In den AD DS gibt es die folgenden fünf 

Betriebsmasterrollen: 

• Schemamaster 

• Domänennamenmaster 

• RID-Master 

• PDC-Emulator 

• Infrastrukturmaster 

Die ersten beiden Rollen, Schemamaster und Domänennamenmaster gelten pro Gesamtstruktur. Dies 

bedeutet, dass es nur einen Schemamaster und nur einen Domänennamenmaster pro Gesamtstruktur 

gibt. Die anderen drei Rollen gelten pro Domäne, das heißt, dass für jede Domäne in der Gesamtstruktur 

eine dieser Betriebsmasterrollen vorhanden ist. Bei der Installation der AD DS und Erstellung 

des ersten Domänencontrollers in der Gesamtstruktur werden diesem Domänencontroller alle 

fünf Rollen zugewiesen. Ebenso werden beim Hinzufügen von Domänen zur Gesamtstruktur dem ersten 

Domänencontroller in jeder neuen Domäne die pro Domäne geltenden Betriebsmasterrollen zugewiesen. 

Beim Hinzufügen von Domänencontrollern zu einer Domäne können diese Rollen an andere 

Domänencontroller übertragen werden. 

Schemamaster 

Der Schemamaster ist der einzige Domänencontroller mit Schreibberechtigungen für das Verzeichnisschema. 

Zum Ändern des Schemas muss der Administrator (der Mitglied der Sicherheitsgruppe 

Schema-Admins sein muss) mit dem Schemamaster verbunden sein. Beim Versuch, Schemaänderungen 

auf einem Domänencontroller durchzuführen, bei dem es sich nicht um den Schemamaster 

handelt, schlägt dieser Vorgang fehl. Nach dem Durchführen einer Änderung werden Schemaaktualisierungen 

auf allen anderen Domänencontrollern in der Gesamtstruktur repliziert.


Der Schemamaster ist durch den Wert des Attributs fSMORoleOwner für das Stammobjekt der Schemapartition 

gekennzeichnet. Standardmäßig übernimmt der erste in einer Gesamtstruktur installierte 

Domänencontroller die Schmamasterrolle. Diese Rolle kann jederzeit über das Snap-In für das Active 

Directory-Schema oder über das Befehlszeilenprogramm Ntdsutil übertragen werden. 

Domänennamenmaster 

Der Domänennamenmaster ist der zum Hinzufügen und Entfernen aller Verzeichnispartitionen innerhalb 

einer Gesamtstrukturhierarchie eingesetzte Domänencontroller. Der Domänencontroller mit der 

Rolle des Domänennamenmasters muss verfügbar sein, wenn Sie folgende Aufgaben ausführen: 

• Hinzufügen oder Entfernen von Domänen Beim Erstellen oder Entfernen einer untergeordneten 

Domäne oder neuen Domänenstruktur kontaktiert der Installations-Assistent den Domänennamenmaster 

und fordert das Hinzufügen oder Entfernen an. Der Domänennamenmaster stellt sicher, 

dass eindeutige Domänennamen vergeben werden. Wenn der Domänennamenmaster nicht verfügbar 

ist, können keine Domänen aus der Gesamtstruktur entfernt oder zu dieser hinzugefügt werden. 

• Hinzufügen oder Entfernen von Anwendungsverzeichnispartitionen Bei Anwendungsverzeichnispartitionen 

handelt es sich um spezielle Partitionen, die auf Domänencontrollern unter Windows 

Server 2003 oder Windows Server 2008 erstellt werden können, um Speicherplatz für dynamische 

Anwendungsdaten bereitzustellen. Wenn der Domänencontroller, der die Rolle des Domänennamenmasters 

hostet, nicht verfügbar ist, können keine Anwendungsverzeichnispartitionen zur 

Gesamtstruktur hinzugefügt oder aus dieser entfernt werden. 

• Hinzufügen oder Entfernen von Querverweisobjekten Beim Erstellen einer neuen Gesamtstruktur 

werden die Schema-, Konfigurations- und Domänenverzeichnispartitionen auf dem ersten Domänencontroller 

in der Gesamtstruktur erstellt. Auf der Konfigurationsverzeichnispartition wird für 

jede Verzeichnispartition im Container Partitions ein Querverweisobjekt erstellt (CN=partitions, 

CN=configuration, DC=forestRootDomain). Wenn neue Domänen oder Anwendungsverzeichnispartitionen 

erstellt werden, wird im Container Partitions ein verknüpftes Querverweisobjekt 

erstellt. Wenn der Domänennamenmaster nicht verfügbar ist, können keine Querverweisobjekte 

hinzugefügt oder entfernt werden. 

• Validieren von Domänenumbenennungsanweisungen Bei Verwendung des Domänenumbenennungstools 

Rendom.exe zum Umbenennen einer AD DS-Domäne muss das Tool auf den Domänennamenmaster 

zugreifen können. Wenn Sie das Tool ausführen, wird das XML-codierte Skript 

mit den Anweisungen zur Domänenumbenennung in das Attribut msDS-UpdateScript im Containerobjekt 

Partitions (CN=partitions,CN=configuration,DC=ForestRootDomain) auf der Konfigurationsverzeichnispartition 

geschrieben. Ferner wird der neue DNS-Name jeder umbenannten 

Domäne durch Rendom.exe in das Attribut msDS-DnsRootAlias für das Querverweisobjekt 

(Klasse crossRef) für diese Domäne geschrieben. Beide Objekte werden im Container Partitions 

gespeichert, und der Container kann ausschließlich auf dem Domänencontroller mit der Rolle des 

Domänennamenmasters für die Gesamtstruktur aktualisiert werden. 

Der Domänennamenmaster ist durch den Wert des Attributs fSMORoleOwner für das Containerobjekt 

Partitions gekennzeichnet. Standardmäßig übernimmt der erste in einer Gesamtstruktur installierte 

Domänencontroller die Rolle des Domänennamenmasters. Diese Rolle kann jederzeit über das 

Snap-In Active Directory-Domänen und -Vertrauensstellungen oder über das Befehlszeilenprogramm 

Ntdsutil übertragen werden.


RID-Master 

Die Betriebsmasterrolle des RID-Masters gilt pro Domäne. Sie wird zum Verwalten des RID-Pools 

eingesetzt, um neue Sicherheitsprinzipale innerhalb der Domäne (z.B. Benutzer, Gruppen und Computer) 

zu erstellen. Für jeden Sicherheitsprinzipal wird eine eindeutige Sicherheitskennung (Security 

Identifier, SID) mit einer Domänenkennung ausgestellt, die für sämtliche SIDs in der Domäne identisch 

ist. Ferner wird für jeden Sicherheitsprinzipal ein eindeutiger relativer Bezeichner (Relative 

Identifier, RID) erstellt. Da Sicherheitsprinzipale auf einem beliebigen Domänencontroller mit einer 

beschreibbaren Kopie des Verzeichnisses erstellt werden können, wird der RID-Master verwendet um 

sicherzustellen, dass eine RID nicht von zwei Domänencontrollern gleichzeitig ausgestellt wird. Der 

RID-Master erstellt für jeden Domänencontroller innerhalb der Domäne einen Block aus RIDs, den 

sogenannten RID-Pool. Wenn die maximale Anzahl an verfügbaren RIDs im RID-Pool auf einem 

Domänencontroller beinah erreicht ist (bei fast 100), wird ein weiterer RID-Block vom RID-Master 

angefordert. In diesem Fall erstellt der RID-Master einen Pool mit ca. 500 weiteren RIDs für den 

Domänencontroller. 

Wenn der RID-Master für einen bestimmten Zeitraum nicht verfügbar ist, kann die Erstellung neuer 

Konten auf bestimmten Domänencontrollern unterbrochen werden. Der Mechanismus zum Anfordern 

eines neuen RID-Blocks ist so konzipiert, dass dieser Fall nicht eintritt: die Anforderung wird 

gesendet, bevor alle verfügbaren RIDs innerhalb des RID-Pools verwendet wurden. Wenn der RID- 

Master jedoch offline ist und der anfordernde Domänencontroller alle verbleibenden RIDs nutzt, 

schlägt die Kontoerstellung fehl. Um die Kontoerstellung erneut zu aktivieren, muss entweder der 

Besitzer der RID-Masterrolle erneut online geschaltet werden, oder die Rolle muss an einen anderen 

Domänencontroller innerhalb der Domäne übertragen werden. 

Der RID-Master ist durch den Wert des Attributs fSMORoleOwner für das Objekt in der Domänenpartition 

gekennzeichnet, dessen Klasse rIDManager lautet. Standardmäßig übernimmt der erste in einer 

neuen Domäne installierte Domänencontroller die Rolle des RID-Masters. Diese Rolle kann über das 

Snap-In Microsoft Active Directory-Benutzer und -Computer oder über das Befehlszeilenprogramm 

Ntdsutil übertragen werden. 

PDC-Emulator 

Der PDC-Emulator wird als primärer Domänencontroller (Primary Domain Controller, PDC) für 

Betriebssysteme vor Windows 2000 eingesetzt. Zum Verarbeiten von Kennwortänderungen müssen 

Mitgliedsserver und Clientcomputer unter Windows NT mit einem PDC kommunizieren können. 

Neben der Bereitstellung von Diensten für ältere Clients spielt der PDC-Emulator eine wichtige 

Rolle bei der Kennwortreplikation. 

Hinweis Bei Windows 2000 und Windows 2003 Active Directory hat der PDC-Emulator u.a. die wichtige 

Rolle, als PDC für Reservedomänencontroller (Backup Domain Controller, BDC) unter älteren Betriebssystemen 

(Microsoft Windows NT 3.51 oder Windows NT 4.0) zu agieren. Da Windows Server 2008 nicht gemeinsam 

mit Domänencontrollern unter Betriebssystemen vor Windows 2000 bereitgestellt werden kann, ist diese 

Funktion nicht mehr relevant. 

Selbst wenn keine Mitgliedsserver oder Clientcomputer unter Windows NT in der Domäne vorhanden 

sind, verwaltet der PDC-Emulator Kennwortaktualisierungen. Sämtliche Kennwortänderungen 

auf anderen Domänencontrollern innerhalb der Domäne werden mithilfe der dringenden Replikation 

an den PDC-Emulator gesendet. Beim Fehlschlagen der Benutzerauthentifizierung auf einem anderen 

Domänencontroller als dem PDC-Emulator, wird auf dem PDC-Emulator versucht, die Authentifizierung 

durchzuführen.


Wenn der PDC-Emulator eine kürzlich vorgenommene Kennwortänderung für das Konto akzeptiert 

hat, wird die Authentifizierung erfolgreich durchgeführt. Bei der erfolgreichen Benutzerauthentifizierung 

auf einem Domänencontroller, auf dem der vorherige Versuch fehlgeschlagen ist, benachrichtigt 

der Domänencontroller den PDC-Emulator über die erfolgreiche Authentifizierung. Dadurch wird der 

Sperrungszähler auf dem PDC-Emulator für den Fall zurückgesetzt, dass ein anderer Client versucht, 

dasselbe Konto unter Verwendung eines anderen Domänencontrollers zu validieren. 

Der PDC-Emulator ist durch den Wert des Attributs fSMORoleOwner für das Stammobjekt der Domänenpartition 

gekennzeichnet. Standardmäßig übernimmt der erste in einer neuen Domäne installierte 

Domänencontroller die Rolle des PDC-Emulators. Diese Rolle kann jederzeit über das Snap-In Active 

Directory-Benutzer und -Computer oder über das Befehlszeilenprogramm Ntdsutil übertragen werden. 

Infrastrukturmaster 

Der Infrastrukturmaster wird zum Aktualisieren von domänenübergreifenden Verweisen zwischen 

Gruppen und Benutzern eingesetzt. Diese Betriebsmasterrolle stellt sicher, dass Änderungen an 

Objektnamen (Änderungen am cn-Attribut) in den Gruppenmitgliedschaftinformationen für Gruppen 

dargestellt werden, die sich in einer anderen Domäne befinden. Der Infrastrukturmaster verwaltet eine 

aktuelle Liste dieser Verweise und repliziert diese Informationen auf allen anderen Domänencontrollern 

in der Domäne. Wenn der Infrastrukturmaster nicht verfügbar ist, sind die domänenübergreifenden 

Verweise zwischen Gruppen und Benutzern nicht aktuell. 

Der Infrastrukturmaster ist durch den Wert des Attributs fSMORoleOwner für den Infrastrukturcontainer 

in der Domänenpartition (CN=Infrastructure, DC=domain). gekennzeichnet. Standardmäßig 

übernimmt der erste in einer neuen Domäne installierte Domänencontroller die Rolle des Infrastrukturmasters. 

Diese Rolle kann jederzeit über das Snap-In Active Directory-Benutzer und -Computer 

oder über das Befehlszeilenprogramm Ntdsutil übertragen werden. 

Auf der DVD Um anzuzeigen, welche Domänencontroller in einer Gesamtstruktur oder Domäne Besitzer 

der FSMO-Rollen sind, führen Sie das auf der CD enthaltene Windows PowerShell-Skript ListFSMOs.ps1 aus. 

Übertragen von Betriebsmasterrollen 

Zum Optimieren der Domänencontrollerleistung oder Ersetzen eines Domänencontrollers, wenn ein 

Rollenbesitzer nicht mehr verfügbar ist, können Betriebsmasterrollen zwischen Domänencontrollern 

verschoben werden. Die erforderlichen Schritte hängen von der Rolle ab, die übertragen wird. 

Tabelle 2.2 zeigt die zum Übertragen der fünf Betriebsmasterrollen eingesetzten Tools. 

Tabelle 2.2 

Tools zum Verwalten der Betriebsmasterrollen 

Betriebsmasterrolle 

Schemamaster 


RID-Master, PDC-Emulator und Infrastrukturmaster 

Verwaltungstool 

Active Directory-Schema 

Active Directory-Domänen und -Vertrauensstellungen 

Active Directory-Benutzer und -Computer 

Zum Übertragen einer Betriebsmasterrolle muss Konnektivität mit dem aktuellen und dem vorgesehenen 

Domänencontroller bestehen, der Besitzer der Rolle ist bzw. werden soll. Bei einem Serverausfall 

ist der aktuelle Rollenbesitzer möglicherweise nicht verfügbar, um die Rollenübertragung abzuschließen. 

In diesem Fall kann die Rolle übernommen werden.


Das Übernehmen von Betriebsmasterrollen ist keine bevorzugte Option und sollte nur angewendet werden, 

wenn dies unbedingt erforderlich ist. Übernehmen Sie eine Betriebsmasterrolle nur, wenn absehbar 

ist, dass der Domänencontroller, der diese Rolle hostet, für einen längeren Zeitraum nicht verfügbar 

sein wird. Weitere Informationen zum Übernehmen von Betriebsmasterrollen finden Sie in 

Kapitel 15. 

Schema 

Hinweis Die Betriebsmasterrollen können auf einen beliebigen anderen Domänencontroller innerhalb der 

Domäne verschoben werden. Die einzige Einschränkung im Hinblick auf die Betriebsmasterplatzierung ist, 

dass die Infrastrukturmasterrolle nicht auf einem Domänencontroller installiert werden sollte, bei dem es sich 

gleichzeitig um einen globalen Katalogserver handelt, wenn die Gesamtstruktur mehrere Domänen enthält. 

Dies gilt, sofern nicht jeder Domänencontroller in der Domäne gleichzeitig ein globaler Katalogserver ist. 

Der erste Domänencontroller in einer Gesamtstruktur ist standardmäßig sowohl ein globaler Katalogserver 

als auch Besitzer der Infrastrukturmasterrolle. Bei der Installation des zweiten Domänencontrollers in der 

Domäne, bei dem es sich nicht um einen globalen Katalogserver handelt, werden Sie im Assistenten zum 

Installieren von Active Directory-Domänendiensten aufgefordert, den Infrastrukturmaster während der 

AD DS-Installation auf den neuen Domänencontroller zu verschieben. 

Das Schema definiert sämtliche Klassen und Attribute, die in den AD DS gespeichert werden können. 

Jedes Objekt in den AD DS ist eine Instanz einer Klasse. Beispiele für Klassen sind user oder 

group. Um ein Objekt in den AD DS erstellen zu können, muss zunächst die Klasse dieses Objekts im 

Schema definiert werden. Über das Schema werden ferner verschiedene Regeln zur Erstellung von 

Objekten in der Datenbank erzwungen. 

Pro Gesamtstruktur ist ein Schema vorhanden. Allerdings wird eine Kopie des Schemas auf jedem 

Domänencontroller innerhalb der Gesamtstruktur repliziert. Auf diese Weise hat jeder Domänencontroller 

schnellen Zugriff auf sämtliche Klassen- oder Attributdefinitionen, die möglicherweise 

benötigt werden. Darüber hinaus verwendet jeder Domänencontroller beim Erstellen eines Objekts 

dieselbe Definition. Der Datenspeicher verwendet die vom Schema bereitgestellten Klassen- und 

Attributdefinitionen, um Datenintegrität zu erzwingen. Als Ergebnis werden alle Objekte einheitlich 

erstellt, und da sämtliche Domänencontroller dieselben Schemadefinitionen verwenden, spielt es 

keine Rolle, welcher Domänencontroller ein Objekt erstellt oder ändert. 

Schemakomponenten 

Das Schema umfasst classSchema-Objekte und attributeSchema-Objekte. Bei den classSchema- 

Objekten handelt es sich um Definitionen, die im Schema gespeichert und zum Definieren von Klassen 

verwendet werden. Klassen definieren Gruppen von Attributen, die gemeinsame Merkmale aufweisen. 

Ein Beispiel ist die Klasse User. Die Klasse User enthält verschiedene Attribute, u.a. den 

Anmeldenamen, den Vornamen, den Nachnamen und das Kennwort des Benutzers. Beim Erstellen 

eines neuen Benutzerkontos verwendet das Verzeichnis die Klasse User, um die Konfiguration des 

Objekts zu definieren. Über die Klasse User festgelegte Einstellungen umfassen die Attribute, über 

die das Objekt verfügen kann und muss, sowie die Klassen, denen dieses Objekt in der AD DS-Hierarchie 

untergeordnet sein kann. Diese Attribute werden von allen Benutzerobjekten verwendet, die 

erstellt werden. 

Das Schema definiert ferner die Attribute, die für die verschiedenen Klassen gespeichert werden können. 

Attribute werden in den AD DS global als attributeSchema-Objekte definiert, und jede Klasse kann 

mehrere global definierte Attribute verwenden.


Ein Benutzerkontoobjekt verfügt beispielsweise über eine Reihe von Attributen zum Speichern verschiedener 

mit einem Benutzerkonto verknüpfter Daten, wie z.B. einem Anmeldenamen- und einem 

Kennwortattribut. Jedes dieser Attribute ist durch Attributobjekte definiert, die wiederum über eine 

eigene Definition verfügen. Diese Definitionsinformationen umfassen z.B. den Datentyp, der in 

diesen Objekten gespeichert wird, sowie Mindest- und Maximalwerte für Länge oder Wert. Der 

Verzeichnisdienst verwendet attributeSchema-Objekte, um den Datentyp zu definieren, der in den 

Attributen für die verschiedenen Objekte einer Klasse gespeichert wird, und um die im attribute- 

Schema-Objekt definierten Einschränkungen (z.B. den Bereich für die zulässige Zeichenfolgenlänge) 

zu erzwingen. 

Das classSchema-Objekt legt die mit dem Objekt verknüpften Attribute fest. Diese Spezifikation 

enthält sämtliche Attribute, die mit dem Objekt verknüpft werden können. Diese lassen sich in vier 

Kategorien gliedern: 

• mustContain-Attribute mit erforderlichen Attributen, die für Objekte vorhanden sein müssen, die 

eine Instanz dieser Klasse darstellen 

• mayContain-Attribute mit optionalen Attributen, die für Objekte vorhanden sein können, die eine 

Instanz dieser Klasse darstellen 

• systemmayContain-Attribute, bei denen es sich um optionale Attribute handelt, die während der 

Objekterstellung konfiguriert werden und anschließend nicht mehr geändert werden können 

• systemmustContain-Attribute, bei denen es sich um erforderliche Attribute handelt, die während 

der Objekterstellung konfiguriert werden und anschließend nicht mehr geändert werden können 

Zusätzlich gibt das classSchema-Objekt Hierarchieregeln zum Festlegen der möglichen übergeordneten 

Elemente in der Verzeichnisstruktur eines Objekts an, das eine Instanz der Klasse ist. Beispielsweise 

kann ein Computerobjekt, wie in Abbildung 2.3 gezeigt, nur im container-, domainDNS- oder 

organizationUnit-Objekt erstellt werden. 

Abbildung 2.3 

Das Schema definiert, an welchen Stellen Objekte in den AD DS erstellt werden können


Schließlich wird der Datentyp, der in den AD DS für die verschiedenen Attribute gespeichert werden 

kann, im Schema als die Syntax des Attributs definiert. Die Klasse User enthält ein Attribut display- 

Name, und die Syntax für dieses Attribut ist als Zeichenfolgenwert definiert, der ein beliebiges alphanumerisches 

Zeichen akzeptiert. Der Wert für die einzelnen Attribute, die in einer Instanz einer Klasse 

enthalten sind, müssen die Syntaxanforderungen für das Attribut erfüllen. 

Das AD DS-Schema unterstützt die Vererbung von Klassen. Alle Schemaobjekte sind hierarchisch 

organisiert. Aufgrund dieser hierarchischen Struktur kann jede Klasse sämtliche Merkmale der übergeordneten 

Klasse erben. Beispielsweise ist die Klasse Computer eigentlich eine Unterklasse der 

Klasse User, wie in Abbildung 2.3 gezeigt. Daher erbt die Klasse Computer sämtliche mit der Klasse 

User verknüpften Attribute. Die Klasse Computer wird so mit den für die Klasse User festgelegten 

Attributen verknüpft. Unter Verwendung des Snap-Ins für das Active Directory-Schema kann die 

organisatorische Struktur der Klassenvererbung sowie die Hierarchie der Objektklassen angezeigt 

werden. Dieses Vererbungssystem vereinfacht die Erstellung neuer Objektklassen für Administratoren 

erheblich, da nicht jedes Attribut definiert werden muss, das mit einer neuen Klasse verknüpft ist. 

Alle mit einer geeigneten übergeordneten Klasse verknüpften Attribute werden einfach an das neue 

Objekt vererbt. 

Ändern des Schemas 

Das AD DS-Schema enthält die am häufigsten verwendeten Klassen und Attribute, um eine Unternehmensverzeichnisdienste-Implementierung 

zu unterstützen. Um Anwendungen zu unterstützen, die 

Informationen in den AD DS speichern müssen, ist das Schema erweiterbar. Mit anderen Worten, das 

Schema kann geändert oder erweitert werden, um neue Klassen- und Attributobjekte zu umfassen, die 

in einer Organisation benötigt werden. 

Meist wird das Schema erweitert, um die Anforderungen einer Active Directory-fähigen Anwendung 

zu erfüllen. Ein gutes Beispiel ist Microsoft Exchange Server 2007. Hier werden über Tausend Schemaänderungen 

vorgenommen, damit die AD DS Unterstützung für Exchange Server bieten. 

Hinweis Vor der Installation von Exchange 2000, Exchange 2003 oder Exchange 2007 muss das Schema 

geändert werden. Die Exchange-Installationsdateien umfassen verschiedene .ldf-Dateien, die beim Import 

die erforderlichen Schemaänderungen durchführen. Wenn bei Bereitstellung einer anderen Anwendung 

Änderungen am Schema erforderlich sind, sollte das Schema ausschließlich mithilfe von sorgfältig getesteten 

.ldf-Dateien geändert werden. Dadurch lassen sich Fehler beim Ändern des Schemas vermeiden. 

So funktioniert es: Indizieren für optimierte Suchvorgänge 

Der Verzeichnisdatenspeicher kann für eine höhere Effizienz bei Suchvorgängen indiziert werden. 

Die Indizierung wird als Teil der Schemadefinition eines Attributs (z.B. Description oder given- 

Name) festgelegt. Bei der Indizierung eines Attributs sind sämtliche Stellen, an denen dieses 

Attribut vorkommt, im Index enthalten. Einige Attribute sind standardmäßig indiziert, und der Administrator 

kann zusätzliche Attribute für die Indizierung konfigurieren. Abhängig davon, wie das 

Attribut in Suchvorgängen verwendet wird, sind verschiedene Typen von Indizierung verfügbar: 

• Grundlegende Indizierung Der Wert bzw. die Werte des Attributs werden indiziert, sodass Abfragen 

zur Anforderung von Objekten mit einem bestimmten Wert für dieses Attributs schnell ausgeführt 

werden.


• Containerindizes Vergleichbar mit der grundlegenden Indizierung, die Objekte werden jedoch 

ebenfalls nach Container indiziert. Dies ermöglicht eine Abfrage zur schnellen Auswertung 

aller untergeordneten Objekte in einem Container, um zu ermitteln, ob diese mit dem angeforderten 

Attributwert übereinstimmen. 

• Tupelindex Dieser Typ von Index wird für Zeichenfolgenattribute verwendet, sodass Suchvorgänge 

für Teilzeichenfolgen unter Verwendung dieser Attribute schnell ausgeführt werden. 

Wenn z.B. ein Tupelindex auf das Attribut Description angewendet wird, können Abfragen 

wie „alle Objekte zurückgeben, deren Description-Attribut die Zeichenfolge 'Fabrikam' enthält“ 

effizient ausgeführt werden. Da Tupelindizes sehr ressourcenintensiv sein können, sollten 

sie nur selten aktiviert werden. 

• Unterstrukturindizes Dieser Typ von Index ermöglicht die schnelle Ausführung einer speziellen 

Art von Active Directory-Suche, die als virtuelle Listenanzeige bezeichnet wird. Diese 

Indizes sind mit Containerindizes vergleichbar, enthalten jedoch nicht nur die untergeordneten 

Elemente des Containers auf der nächsten Ebene, sondern sämtliche untergeordneten Elemente 

auf den weiteren Ebenen. Wie Tupelindizes können auch Unterstrukturindizes kostenintensiv 

sein. 

Basierend auf den Anforderungen einer Organisation können Administratoren die Indizierung für 

Attribute aktivieren, die standardmäßig nicht indiziert sind. Grundlegende Indizes und Containerindizes 

können über das Snap-In für das Active Directory-Schema aktiviert werden. Für Tupel- und 

Unterstrukturindizes muss der Wert des Attributs searchFlags für die attributeSchema-Objekte, 

welche die zu indizierenden Attribute definieren, manuell gesetzt werden. 

Die Tupelindizierung und die erforderlichen Schritte zur Aktivierung sind unter http://msdn2. 

microsoft.com/en-us/library/ms676931.aspx beschrieben. Eine Beschreibung des searchFlags- 

Attributs, einschließlich der Werte, die für Tupel- und Unterstrukturindizes gesetzt werden müssen, 

finden Sie unter http://msdn2.microsoft.com/en-us/library/ms679765.aspx. 

Matthew Rimer 

Senior SDE, US-Directory and Service Business 

Neben der Verwendung von Active Directory-fähigen Anwendungen können Administratoren das 

Schema über verschiedene andere Methoden erweitern. Das Schema lässt sich im Batchmodus über 

Befehlszeilentools wie u.a. LDIFDE (LDAP Data Interchange Format Directory Exchange) und 

CSVDE (Comma Separated Value Directory Exchange) erweitern. Darüber hinaus kann das Schema 

über ADSI- (Active Directory Service Interfaces) und Microsoft Visual Basic-Skripts programmgesteuert 

erweitert werden. 

Und schließlich können Sie das Schema ebenfalls mithilfe des Snap-Ins für das Active Directory- 

Schema über die Windows Server 2008-Benutzeroberfläche ändern. Möglicherweise benötigt eine 

Organisation z.B. Datensätze zu den Eintrittsdaten der Mitarbeiter. Das Eintrittsdatum der Mitarbeiter 

könnte als Attribut des Benutzerobjekts in den AD DS verwaltet werden. Per Voreinstellung ist 

dieses Attribut nicht in den AD DS enthalten. Damit dieses Attribut beim Erstellen neuer Benutzerobjekte 

verfügbar ist, muss es zunächst im Schema definiert werden. 

Zur Verwendung des Snap-Ins Active Directory-Schema muss dieses zunächst über die Befehlszeile 

mit dem Befehl Regsvr32 Schmmgmt.dll registriert und anschließend zu einer MMC hinzugefügt werden. 

Um das Schema über diese Schnittstelle zu ändern, müssen Sie Mitglied der globalen Gruppe 

Schema-Admins sein.


Achtung Wenngleich Schemaänderungen deaktiviert werden können, können neue Klassen oder Attribute, 

die im Schema erstellt werden, nicht mehr entfernt werden. Änderungen am Schema sollten nur nach 

sorgfältiger Planung und umfassenden Tests in einer Testgesamtstruktur durchgeführt werden. Stellen Sie 

sicher, dass Schemaänderungen mit den aktuellen und zukünftigen Anwendungen kompatibel sind, die 

Schemaänderungen erfordern. 

Erstellen von neuen Attributen 

Führen Sie die folgenden Schritte aus, um das Snap-In Active Directory-Schema zum Hinzufügen 

eines neuen Attributs zum Schema und Verknüpfen dieses Attributs mit dem Klassenobjekt User zu 

verwenden: 

1. Öffnen Sie das Snap-In für das Active Directory-Schema. 

2. Wählen Sie in der Sruktur den Ordner Attribute aus. 

3. Klicken Sie im Menü Aktion auf Attribut erstellen. 

4. Klicken Sie im Warnungsdialogfeld Erstellen des Schemaobjekts auf Weiter. 

5. Geben Sie im Dialogfeld Neues Attribut erstellen im Abschnitt Identifikation die folgenden Informationen 

an: 

Allgemeiner Name 

LDAP-Anzeigename 

Eindeutige X500-OID 

Beschreibung 

6. Geben Sie im Abschnitt Syntax und Bereich folgende Informationen an: 

Syntax 

Minimum 

Maximum 

Legen Sie fest, ob das neue Attribut mehrwertig ist. 

Hinweis Für weitere Informationen zu den Inhalten der einzelnen Felder wählen Sie das Textfeld aus 

und drücken dann die Funktionstaste F1. 

Abbildung 2.4 zeigt die Erstellung eines neuen Attributs über das Snap-In Active Directory- 

Schema. 

7. Nach der Erstellung muss das neue Attribut mit dem Klassenobjekt verknüpft werden. Wählen Sie 

dazu in der Struktur den Ordner Klassen aus. 

8. Wechseln Sie zum Klassenobjekt, zu dem das Attribut hinzugefügt werden soll, klicken Sie mit 

der rechten Maustaste auf das Objekt, und wählen Sie Eigenschaften. 

9. Klicken Sie auf der Registerkarte Attribute auf Hinzufügen, und fügen Sie das neu erstellte Attribut 

hinzu.


Hinweis Beim Hinzufügen eines neuen Attributs zum Schema kann nicht automatisch über die Verwaltungstools 

auf das Attribut zugegriffen werden. In den Verwaltungstools wie Active Directory-Benutzer und 

-Computer werden lediglich einige Attribute für jede Klasse angezeigt und keine durch den Benutzer hinzugefügten 

Attribute. Wenn die neuen Attribute in einem Verwaltungstool angezeigt werden sollen, muss 

entweder das vorhandene Tool geändert oder ein eigenes Tool erstellt werden. Informationen zum Ändern 

und Erstellen von Verwaltungstools finden Sie unter „Extending the User Interface for Directory Objects“ auf 

der Seite http://msdn2.microsoft.com/en-us/library/ms676902.aspx. Im ADSI-Editor werden die neuen Attribute 

angezeigt, da die Liste der verfügbaren Attribute für ein Objekt dynamisch aus dem Schema geladen 

wird. 

Abbildung 2.4 

Erstellen des Attributs MitarbeiterEintrittsdatum in den AD DS 

Direkt von der Quelle: Implementieren von Schemaaktualisierungen 

Nach dem Erstellen neuer Attribute sind diese nicht unbedingt unmittelbar im Schema verfügbar. 

Schemaattribute und Klassen legen die Struktur der Datenbank intern fest. Im Vergleich zu anderen 

Vorgängen hat die Erstellung neuer Klassen oder Attribute wesentlich größere Auswirkungen 

auf die Domänencontrollerleistung. Aufgrund der Bedeutung des Schemas für das System wird der 

gesamte Schemainhalt immer im Arbeitsspeicher zwischengespeichert. Nach dem Aktualisieren 

des Schemas muss auch die zwischengespeicherte Kopie des Schemas aktualisiert werden, bevor 

die neuen Attribute oder Klassen verfügbar sind. Standardmäßig aktualisieren die AD DS den Zwischenspeicher 

fünf Minuten nach der letzten Schemaänderung. 

Das gängigste Szenario für Schemaerweiterungen ist die Installation einer neuen verzeichnisfähigen 

Software (beispielsweise die Installation von Exchange Server oder das Ausführen von 

Adprep, um eine Windows 2000- oder 2003-Gesamtstruktur für Windows Server 2008 vorzubereiten). 

In diesen Szenarien werden innerhalb eines kurzen Zeitraums nacheinander mehrere Änderungen 

am Schema vorgenommen. In vielen Fällen weisen Schemaänderungen Abhängigkeiten 

auf. So kann durch eine Schemaänderung z.B. ein neues Attribut erstellt und dieses Attribut durch 

eine weitere Änderung mit einer Klasse verknüpft werden.


Es wird empfohlen, dass der Entwickler der Schemaerweiterung beim Erstellen der .ldf-Dateien 

zum Aktualisieren des Schemas ein Signal für die AD DS einfügt, um den Schemacache vor der 

Verwendung von Verweisen auf soeben erstellte Attribute oder Klasse zu aktualisieren. Zu diesem 

Zweck kann das rootDSE-Attribut schemaUpdateNow auf 1 gesetzt werden. Über die meisten von 

Adprep verwendeten sch*.ldf-Dateien wird dieser Schritt ausgeführt. Die sch43.ldf-Datei aktualisiert 

den Schemacache z.B. nach der Erstellung von neuen Attributen und bevor von neuen Klassen 

auf diese verwiesen wird. Zum Aktualisieren des Schemacaches enthält die Datei die folgenden 

Zeilen: 

DN: 

changetype: modify 

add: schemaUpdateNow 

schemaUpdateNow: 1 

- 

Elbio Abib, SDE II 

X.500-Objekt-IDs 

Der Namespace X.500-OID ist eine hierarchische Namensstruktur mit einer eindeutigen Nummer 

für jedes classSchema- und attributeSchema-Element in einem Verzeichnisdienst. Unter Verwendung 

der X.500-OID (Object Identifier, Objektkennung) lässt sich jedes Objekt in jeder Verzeichnisdienstestruktur 

eindeutig identifizieren. Die Namespacedefinition X.500-OID umfasst andere 

Verzeichnisse als die AD DS, bei den AD DS handelt es sich jedoch um einen X.500-basierten 

Verzeichnisdienst. 

Dieser Namespace kann mit punktierter Dezimalschreibweise (numerisch) oder als Zeichenfolge 

dargestellt werden. Die Organisationsobjektklasse (mit LDAP-Anzeigename organization) ist 

beispielsweise durch die X.500-OID 2.5.6.4 gekennzeichnet. Die numerische Darstellung dieser 

Objektklasse identifiziert dieses Objekt innerhalb der X.500-Hierarchie eindeutig. 

Zum Anzeigen der X.500-OID kann das Snap-In Active Directory-Schema oder das Snap-In ADSI- 

Editor verwendet werden. Um die X.500-OID für das Objekt Organization classSchema anzuzeigen, 

verwenden Sie den ADSI-Editor, um den Schemacontainer zu öffnen und einen Bildlauf zum 

definierten Namen von classSchema durchzuführen: CN=Organization. 

Ein wichtiger Aspekt, der bei Schemaänderungen berücksichtigt werden muss, ist die Möglichkeit, 

dass zwei Anwendungen nicht kompatible Änderungen am Schema vornehmen, indem beide versuchen, 

ein Klassen- oder Attributobjekt mit demselben Namen oder derselben OID hinzuzufügen. 

Die OID dient zur eindeutigen Identifizierung von Objekten oder Attributen in den AD DS und 

zum Sicherstellen, dass kein anderes Schemaobjekt dieselbe OID verwendet. 

Um diese Identifizierung zu ermöglichen, sollten sich Organisationen, welche die Erstellung neuer 

OIDs planen, bei der International Standards Organization (ISO), beim American National Standards 

Institute (ANSI) oder bei Microsoft registrieren. Bei der Registrierung weist Ihnen die Standardisierungsorganisation 

oder Microsoft einen Teil des OID-Bereichs zu, den Sie gemäß Ihren 

Anforderungen erweitern können. Beispielsweise könnte Ihrem Unternehmen eine Nummer wie 

1.2.840.xxxx zugewiesen werden.


Diese Nummer ist hierarchisch aufgebaut und lässt sich wie folgt aufschlüsseln: 

1 – ISO 

2 – ANSI 

840 – USA 

xxxx – Eine eindeutige Nummer zur Identifizierung Ihres Unternehmens 

Nach dem Erhalt der Nummer können Sie den für Ihr Unternehmen zugewiesenen Teil der Hierarchie 

verwalten. Beispielsweise können Sie beim Erstellen eines neuen Attributs MitarbeiterEintrittsdatum 

eine Nummer wie 1.2.840.xxxx.12. zuweisen. 

Die AD DS sind mit den OID-Standards konform. Die OID für einen Kontakt in den AD DS lautet 

z.B. 1.2.840.113556.1.5.15. Die ersten drei Bereiche der Nummer wurden ISO, ANSI und den 

USA zugewiesen. ANSI wies 113556 anschließend Microsoft zu, und Microsoft wies 1 Active 

Directory, 5 Active Directory-Klassen und 15 den Contact-Klassen zu. 

Wichtig Sie müssen sicherstellen, dass Änderungen am Schema über eine eindeutige OID verfügen, 

sodass Ihre Änderungen mit zukünftigen Änderungen kompatibel sind. Eine Möglichkeit zum Sicherstellen der 

Eindeutigkeit ist das Abrufen einer eindeutigen Kennung für Ihr Unternehmen. Ein weiteres Attribut, dass 

beim Ändern des Schemas eindeutig sein muss, ist das Attribut LdapDisplayName. Stellen Sie vor dem 

Ändern des Schemas sicher, dass Sie sämtliche Regeln für das Durchführen dieser Änderungen verstanden 

haben. 

Deaktivieren von Schemaobjekten 

Wenngleich das Erweitern des Schemas ein unkomplizierter Vorgang ist, sollten solche Änderungen 

sorgfältig geplant werden. Nachdem das Schema erweitert oder vorhandene Klassen oder Attribute 

geändert wurden, können diese Änderungen nicht rückgängig gemacht werden. Schemaojekte können 

nicht gelöscht werden. Wenn beim Erweitern des Schemas ein Fehler unterläuft, kann das Objekt 

deaktiviert werden. In Windows Server 2008 können deaktivierte Schemaobjekte bei Bedarf erneut 

verwendet werden, und neue Schemaobjekte können mit demselben LDAP-Anzeigenamen oder derselben 

OID wie das deaktivierte Objekt erstellt werden. 

Im Hinblick auf die Deaktivierung von Klassen- und Attributobjekten im Schema müssen verschiedene 

Aspekte berücksichtigt werden. Erstens können Category 1- oder base schema-Objekte nicht 

deaktiviert werden. Zweitens können keine Attribute deaktiviert werden, die Mitglied einer Klasse 

sind, die nicht ebenfalls deaktiviert wird. Durch diese Einschränkung werden Fehler beim Erstellen 

neuer Instanzen der nicht deaktivierten Klasse verhindert, wenn das deaktivierte Attribut ein erforderliches 

Attribut ist. 

Hinweis Wenn Ihre Gesamtstruktur auf Windows Server 2003-Funktionsebene festgelegt ist, kann ein 

neues Objekt erstellt werden, das dieselben Identifikationsattributwerte (also attributeID, governsID, lDAP- 

DisplayName, mAPIID oder schemaIDGUID) verwendet wie ein außer Kraft gesetztes Schemaobjekt (sofern 

der definierte Name des neuen Objekts eindeutig ist). Dadurch ist es möglich, ein Schemaobjekt zu deaktivieren 

und anschließend ein völlig neues Schemaobjekt so zu erstellen, als wäre das alte Objekt gelöscht 

worden. 

Zum Deaktivieren eines Klassen- oder Attributobjekts setzen Sie den booleschen Wert des Attributs 

isDefunct für das Schemaobjekt auf true. Dieser Schritt kann über ein Tool wie ADSI-Editor ausgeführt 

werden.


Abbildung 2.5 zeigt, wie das im vorherigen Beispiel erstellte Attribut MitarbeiterEintrittsdatum deaktiviert 

wird. AD DS-Attribute lassen sich ebenfalls deaktivieren, indem Sie bei Anzeige der Attributeigenschaften 

im Snap-In für das Active Directory-Schema das Kontrollkästchen Attribut ist aktiv 

deaktivieren. 

Abbildung 2.5 

Deaktivieren eines Schemaattributs mithilfe von ADSIEdit.msc 

Nach dem Deaktivieren eines Schemaobjekts wird dieses Objekt behandelt, als sei es nicht vorhanden. 

Beim Versuch, eine neue Instanz von außer Kraft gesetzten Klassen oder Attributen zu erstellen, 

werden dieselben Fehlermeldungen angezeigt, die erscheinen, wenn diese Klassen oder Attribute 

nicht im Schema vorhanden sind. Die einzige Änderung, die an einem deaktivierten Schemaobjekt 

durchgeführt werden kann, ist die erneute Aktivierung. Zur erneuten Aktivierung eines außer Kraft 

gesetzten Schemaobjekts setzen Sie das Attribut isDefunct einfach auf false oder aktivieren das Kontrollkästchen 

Attribut ist aktiv. Nach der erneuten Aktivierung eines außer Kraft gesetzten Schemaobjekts 

kann dieses erneut zum Erstellen neuer Instanzen der Klasse bzw. des Attributs verwendet 

werden. Dieser Prozess zur Deaktivierung und erneuten Aktivierung hat keine nachteiligen Auswirkungen. 

Logische Struktur der AD DS 

Nachdem die AD DS in der Netzwerkumgebung installiert wurden und mit der Implementierung der 

geeigneten AD DS-Struktur für die jeweiligen Geschäftszwecke begonnen wurde, beginnt die Arbeit 

mit der logischen Struktur der AD DS. In der logischen Struktur wird die Konfiguration von Domänen, 

Organisationseinheiten und anderen AD DS-Objekten unabhängig von den physischen AD DS- 

Komponenten (z.B. die Domänencontroller oder der auf den verschiedenen Domänencontrollern 

gespeicherte AD DS-Datenspeicher) dargestellt. Die logische Struktur der AD DS umfasst die folgenden 

Komponenten: 

• Partitionen

Logische Struktur der AD DS 41 

• Domänen 

• Domänenstrukturen 

• Gesamtstrukturen 

• Standorte 

• Organisationseinheiten 

In diesem Abschnitt erhalten Sie eine Einführung in diese Komponenten. Ferner wird das Konzept der 

Vertrauensstellungen beschrieben, die für den Ressourcenzugriff durch Sicherheitsprinzipale in anderen 

Domänen verwendet werden. In Kapitel 5 erfahren Sie, wie und weshalb diese Strukturkomponenten 

verwendet werden, um bestimmte Unternehmensziele (z.B. der sichere Ressourcenzugriff) zu 

erreichen und die Netzwerkleistung zu optimieren. 

AD DS-Partitionen 

Wie bereits erläutert, ist die AD DS-Datenbank in einer Datenbankdatei auf der Festplatte jedes 

Domänencontrollers gespeichert. Die in der Verzeichnisdatenbank gespeicherten Informationen werden 

in mehrere logische Partitionen unterteilt, die jeweils unterschiedliche Informationstypen speichern. 

AD DS-Partitionen werden auch als Namenskontexte (Naming Contexts, NCs) bezeichnet. AD DS-Partitionen 

können über Tools wie Ldp.exe oder das Snap-In ADSI-Editor angezeigt werden, wie in 

Abbildung 2.6 gezeigt. 

Abbildung 2.6 

Mithilfe von ADSIEdit.msc angezeigte AD DS-Partitionen 

AD DS und LDAP 

LDAP (Lightweight Directory Access Protocol) ist in Windows Server 2008 AD DS sowohl ein 

Zugriffsprotokoll als auch ein Objektidentifikationsmodell. Als Objektidentifikationsmodell verwendet 

LDAP ein Hierarchieformat zur Identifizierung aller Objekte in den AD DS. Dieses Hierarchieformat 

beginnt auf Verzeichnispartitionsebene und umfasst sämtliche logischen Komponenten 

in der Hierarchie, um jedes Objekt eindeutig zu kennzeichnen. Dies wird als definierter Name 

bezeichnet. Ein Benutzerkonto kann beispielsweise anhand des folgenden definierten LDAP- 

Namens identifiziert werden: 

CN=Yvonne McKay,OU=Marketing,OU=Miami, DC=Adatum,DC=com


Sämtliche Abschnitte des LDAP-Namens sind durch den Objekttyp gekennzeichnet. Diese 

Abschnitte werden als relative definierte Namen (Relative Distinguished Names, RDN), der 

Objekttyp wird als das RDN-Attribut bezeichnet. So bezieht sich cn beispielsweise auf den allgemeinen 

Namen (Common Name), ou auf die Organisationseinheit (Organizational Unit) und dc auf 

eine Domänencomponente (Domain Component). Unter Verwendung dieser Namenskonvention 

kann innerhalb eines LDAP-fähigen Verzeichnisdiensts wie den AD DS auf bestimmte Objekte 

verwiesen oder zugegriffen werden. Das LDAP-Protokoll und -Verzeichnismodell (nicht jedoch die 

Namenssyntax) ist durch RFC 2251 „Lightweight Directory Access Protocol (v3)“ definiert. Dieses 

Dokument steht unter http://www.ietf.org/rfc/rfc2251.txt zur Verfügung. 

LDAP ist zudem ein Zugriffsprotokoll und eine Anwendungsprogrammierschnittstelle (Application 

Programming Interface, API) für den Zugriff auf Informationen in den AD DS. Als API ist 

LDAP in Windows Server 2008 AD DS in der Datei Wldap32.dll implementiert. Unter Verwendung 

des LDAP-Pfades kann innerhalb einer Anwendung oder eines Skripts auf ein beliebiges 

Objekt in den AD DS zugegriffen werden. Um beispielsweise in einem Windows PowerShell- 

Skript auf eine bestimmte Organisationseinheit zu verweisen, verwenden Sie die folgende Syntax: 

$objADSI = [ADSI]"LDAP://OU=Marketing,OU=Miami,DC=Adatum,DC=com" 

Zum Verwalten der AD DS unter Verwendung von LDAP kann ein LDAP-fähiges Verwaltungstool 

wie Ldp.exe verwendet werden, das mit Windows Server 2008 installiert wird. Mithilfe von 

Ldp.exe kann über die TCP-Portnummer (Transmission Control Protocol) der AD DS eine Verbindung 

mit den Domänendiensten hergestellt und der LDAP-Anzeigename der einzelnen Attribute, 

Klassen und Objekte angezeigt werden. Zum Herstellen einer Verbindung mit den AD DS über 

Ldp.exe und Anzeigen der Attribute eines Benutzerobjekts verbinden Sie sich über TCP-Port 389 

mit dem AD DS-Domänencontroller, erweitern den Container oder die Organisationseinheit und 

doppelklicken auf den definierten Namen des Benutzers. 

Domänenverzeichnispartition 

Die Domänenverzeichnispartition enthält sämtliche Domäneninformationen, einschließlich Daten zu 

Benutzern, Gruppen, Computern und Kontakten. Im Wesentlichen sind alle Informationen, die über 

das Verwaltungstool Active Directory-Benutzer und -Computer angezeigt werden können, in der 

Domänenverzeichnispartition gespeichert. 

Die Domänenverzeichnispartition wird automatisch auf allen Domänencontrollern in der Domäne 

repliziert. Die Partition enthält die Informationen, die jeder Domänencontroller zur Authentifizierung 

von Benutzern benötigt. 

Konfigurationsverzeichnispartition 

Die Konfigurationsverzeichnispartition enthält die Informationen zur Konfiguration der gesamten 

Gesamtstruktur. Beispielsweise werden sämtliche Daten zu Standorten, Standortverknüpfungen und 

Replikationsverbindungen in der Konfigurationsverzeichnispartition gespeichert. Auch andere 

Anwendungen können Informationen in der Konfigurationspartition speichern. Exchange Server 2007 

speichert die eigenen Konfigurationsinformationen z.B. nicht im eigenen Verzeichnisdienst, sondern 

in der AD DS-Konfigurationsverzeichnispartition. 

Da die Konfigurationsverzeichnispartition Informationen zur gesamten Gesamtstruktur enthält, wird 

sie innerhalb der gesamten Gesamtstruktur repliziert.


Jeder Domänencontroller enthält eine beschreibbare Kopie der Konfigurationsverzeichnispartition, 

und auf jedem Domänencontroller in der Organisation können Änderungen an dieser Verzeichnispartition 

durchgeführt werden. Dies bedeutet, dass die Konfigurationsinformationen anschließend auf 

allen anderen Domänencontrollern repliziert werden. Nach der vollständigen Synchronisierung der 

Replikation verfügen sämtliche Domänencontroller in der Gesamtstruktur über dieselben Konfigurationsinformationen. 

Schemaverzeichnispartition 

Die Schemaverzeichnispartition enthält das Schema für die gesamte Gesamtstruktur. Wie bereits weiter 

oben in diesem Kapitel beschrieben, ist das Schema ein Satz aus Regeln zum Festlegen, welche 

Objekttypen in den AD DS erstellt werden können, sowie Regeln zu jedem Objekttyp. 

Die Schemaverzeichnispartition wird auf allen Domänencontrollern in der gesamten Gesamtstruktur 

repliziert. Es verfügt jedoch nur ein Domänencontroller, der Schemamaster, über eine beschreibbare 

Kopie der Schemaverzeichnispartition. Sämtliche Änderungen am Schema müssen auf dem Schemamaster 

durchgeführt werden; anschließend werden diese Änderungen auf sämtlichen Domänencontrollern 

repliziert. 

Partition des globalen Katalogs 

Die Partition des globalen Katalogs ist keine Partition im eigentlichen Sinne. Sie ist wie die anderen 

Partitionen in der Datenbank gespeichert, Administratoren können in dieser Partition jedoch keine 

Informationen direkt eingeben. Der globale Katalog ist eine schreibgeschützte Partition auf allen globalen 

Katalogservern und wird aus den Inhalten der Domänendatenbanken erstellt. Alle Attribute im 

Schema verfügen über einen booleschen Wert isMemberOfPartialAttributeSet. Wenn dieser Wert auf 

true gesetzt ist, wird das Attribut in den globalen Katalog repliziert. 

Anwendungsverzeichnispartitionen 

Der letzte Partitionstyp in Windows Server 2008 AD DS ist die Anwendungsverzeichnispartition oder 

NDNC (Non-Domain Naming Context, Nicht-Domänennamenskontext). Anwendungsverzeichnispartitionen 

werden zum Speichern von anwendungsspezifischen Informationen verwendet. Die Verwendung 

von Anwendungsverzeichnispartitionen bietet gegenüber einer der anderen AD DS-Partitionen 

den Vorteil, dass der Replikationsbereich für die Anwendungsverzeichnispartitionen gesteuert werden 

kann. Wenn die Partition zum Speichern von Verzeichnisinformationen verwendet wird, können 

die Informationen recht dynamisch sein. Durch die Festlegung, welche Domänencontroller ein 

Replikat der Anwendungsverzeichnispartition hosten, kann die Menge an Replikationsdatenverkehr 

im Netzwerk eingeschränkt werden. Die Domänencontroller, die ein Replikat der Anwendungsverzeichnispartition 

erhalten, können sich in einer beliebigen Domäne oder an einem beliebigen Standort 

innerhalb der Gesamtstruktur befinden. 

Mit Ausnahme von Sicherheitsprinzipalen können sämtliche Typen von AD DS-Objekten in einer 

Anwendungsverzeichnispartition gespeichert werden. Da Anwendungsverzeichnispartitionen erstellt 

werden um zu steuern, wo die Daten repliziert werden, können die Objekte in der Anwendungsverzeichnispartition 

zudem nicht auf der Partition des globalen Katalogs repliziert werden. 

Per Voreinstellung werden in den AD DS keine Anwendungsverzeichnispartitionen erstellt. Wenn Sie 

bei der Installation der AD DS jedoch auch die Installation von DNS auf dem ersten Domänencontroller 

in der Gesamtstruktur festlegen, werden zwei Anwendungsverzeichnispartitionen mit den Namen 

ForestDnsZones and DomainDnsZones für den DNS-Serverdienst (Domain Name System) erstellt.


Anwendungsverzeichnispartitionen können nicht nur für DNS, sondern auch für andere Anwendungen 


Weitere Informationen Weitere Informationen zu diesen DNS-Anwendungsverzeichnispartitionen finden 

Sie in Kapitel 3, „Active Directory-Domänendienste und DNS“. 

Das Benennungschema für Anwendungsverzeichnispartitionen ist mit dem Schema der anderen AD 

DS-Verzeichnispartitionen identisch. Der LDAP-Name für die Konfigurationsverzeichnispartition in 

der Gesamtstruktur Adatum.com lautet z.B. CN=Configuration,DC=Adatum,DC=com. Wenn Sie eine 

Anwendungsverzeichnispartition AnwPartition1 in der Domäne Adatum.com erstellen, lautet 

der DNS-Name dieser Partition DC=AnwPartition1,DC=Adatum,DC=com. Anwendungsverzeichnispartitionen 

sind im Hinblick auf den Erstellungsort bzw. genauer gesagt im Hinblick auf den Namenskontext 

für die Partition recht flexibel. Beispielsweise kann eine zusätzliche Anwendungsverzeichnispartition 

unterhalb der Partition AnwPartition1 erstellt werden, deren Name DC=AnwPartition2, 

DC=AnwPartition1,DC=Adatum,dc=com lauten würde. Es ist sogar möglich, eine Anwendungsverzeichnispartition 

mit einem DNS-Namen zu erstellen, der nicht mit einer Domäne innerhalb der 

Gesamtstruktur zusammenhängt. In der Domäne Adatum.com kann eine Anwendungsverzeichnispartition 

mit dem DNS-Namen DC=AnwPartition erstellt werden. Dadurch wird innerhalb der 

Gesamtstruktur eine neue Struktur erstellt. 

Hinweis Die Auswahl des DNS-Namens für den Anwendungsnamespace wirkt sich nicht auf die Funktionalität 

der Anwendungsverzeichnispartition aus. Der einzige Unterschied besteht ist der Konfiguration des 

LDAP-Clients, der auf die Partition zugreift. Da Anwendungsverzeichnispartitionen für den LDAP-Zugriff 

konzipiert sind, muss der Client für die Suche nach dem richtigen Namespace auf dem Server konfiguriert 

werden. 

Ein eher komplexer Aspekt bei der Erstellung einer Anwendungsverzeichnispartition ist die Verwaltung 

von Berechtigungen für die Objekte in der Partition. Bei den AD DS-Standardpartitionen werden die 

Berechtigungen automatisch zugewiesen. Wenn in der Domänenverzeichnispartition ein Objekt 

erstellt wird, wird automatisch die Gruppe Domänen-Admins mit vollen Berechtigungen für das 

Objekt zugewiesen. Beim Erstellen eines Objekts in der Konfigurationsverzeichnispartition oder 

Schemaverzeichnispartition werden den Benutzer- und Gruppenkonten in der Stammdomäne der 

Gesamtstruktur Berechtigungen zugewiesen. Da Anwendungsverzeichnispartitionen auf einer beliebigen 

Kombination von Domänen in der Gesamtstruktur repliziert werden können, wird diese Standardmethode 

zur Zuweisung von Berechtigungen nicht angewendet. Während das Zuweisen des Vollzugriffs 

auf die Objekte in der Partition zu einer Gruppe wie den Domänen-Admins kein Problem 

darstellt, ist nicht klar, welche Domäne die Standarddomäne ist. Um dieses Problem zu behandeln, 

werden Anwendungsverzeichnispartitionen immer mit einer Sicherheitsbeschreibungs-Referenzdomäne 

erstellt. Diese Domäne wird zur Standarddomäne, über die Berechtigungen für Objekte in der 

Anwendungsverzeichnispartition zugewiesen werden. Beim Erstellen einer Anwendungsverzeichnispartition 

unterhalb einer Domänenverzeichnispartition wird die übergeordnete Domäne als Sicherheitsbeschreibungs-Referenzdomäne 

verwendet, sodass eine Berechtigungsvererbung implementiert 

wird. Wenn durch die Anwendungsverzeichnispartition eine neue Struktur innerhalb der Gesamtstruktur 

erstellt wird, wird die Stammdomäne der Gesamtstruktur als Referenzdomäne verwendet.

Domänen 


Hinweis Anwendungsverzeichnispartitionen werden üblicherweise durch die Installation von Anwendungen 

erstellt, welche die Verwendung einer Anwendungsverzeichnispartition erfordern. Während der 

Installation der Anwendung sollten ferner zusätzliche Replikate auf anderen Domänencontrollern erstellt werden 

können. Wenngleich Anwendungsverzeichnispartitionen mithilfe von Ntdsutil erstellt werden können, ist 

dies in einer Produktionsumgebung nicht üblich. Die Vorgehensweisen zur Verwaltung von Anwendungsverzeichnispartitionen 

sind im Windows Server 2008-Hilfe und Supportcenter beschrieben. Detaillierte Informationen 

zu Anwendungsverzeichnispartitionen, u.a. zum programmgesteuerten Zugriff auf diese Partitionen, 

finden Sie unter „Application Directory Partitions“ auf der folgenden Seite: http://msdn2.microsoft.com/en-us/ 

library/ms675020.aspx. 

Die Domäne ist die grundlegendste Komponente innerhalb des AD DS-Modells. Bei der Installation 

der AD DS auf dem ersten Computer unter Windows Server 2008 erstellen Sie eine Domäne. Eine 

Domäne dient als Verwaltungsgrenze und definiert gleichzeitig die Grenze für bestimmte Sicherheitsrichtlinien. 

Die Domänenstruktur sollte auf den Verwaltungsanforderungen einer Organisation basieren, 

wie z.B. der Delegierung von Administratorrechten, sowie auf Betriebsanforderungen wie der 

Notwendigkeit, die Replikation zu steuern. Beispielsweise verfügen alle Mitglieder der Gruppe 

Domänen-Admins in einer Domäne über vollen Administratorzugriff auf sämtliche Objekte innerhalb 

dieser Domäne, standardmäßig jedoch nicht über Administratorzugriff auf Objekte in anderen Domänen. 

Innerhalb der AD DS definieren Domänen Folgendes: 

• Replikationsgrenzen Domänengrenzen sind Replikationsgrenzen für die Domänenverzeichnispartition 

und für die Domäneninformationen im Ordner Sysvol auf sämtlichen Domänencontrollern. 

Während andere Verzeichnispartitionen wie die Schema- und Konfigurationspartition sowie die 

Partition des globalen Katalogs innerhalb der Gesamtstruktur repliziert werden, wird die Domänenverzeichnispartition 

nur innerhalb einer Domäne repliziert. Durch die Partitionierung von 

Daten in mehrere Domänen innerhalb derselben Gesamtstruktur kann der Replikationsdatenverkehr 

zwischen Domänencontrollern in sehr großen Organisationen verwaltet werden. Die in der 

Domänenpartition gespeicherten Informationen werden auf allen anderen Domänencontrollern 

innerhalb der Domäne, nicht jedoch auf Domänencontrollern in anderen Domänen repliziert. 

• Grenzen für Sicherheitsrichtlinien Einige Sicherheitsrichtlinien können ausschließlich auf Domänenebene 

festgelegt werden. Diese Richtlinien, wie Kennwort-, Kontosperrungs- und Kerberos- 

Ticketrichtlinien, gelten für alle Domänenkonten. 

Hinweis In Windows Server 2008 können fein abgestimmte Kennwortrichtlinien definiert werden, 

welche die standardmäßigen Domänenkontorichtlinien für bestimmte Benutzer außer Kraft setzen. Fein 

abgestimmte Kennwortrichtlinien lassen sich jedoch nicht auf Containerobjekte anwenden, sondern 

lediglich auf einzelne Benutzerkonten oder Sicherheitsgruppen. 

• Grenzen für den Ressourcenzugriff Domänengrenzen sind gleichzeitig Grenzen für Authentifizierungs- 

und Autorisierungsdienste. Eine Domäne bietet Authentifizierungsdienste für alle Konten 

innerhalb dieser Domäne, um Anmeldevorgänge und die SSO-Zugriffssteuerung (Single Sign-On) 

auf freigegebene Ressourcen innerhalb der Domänengrenzen zu vereinfachen. Standardmäßig 

können Benutzer einer Domäne nicht auf die Ressourcen in einer anderen Domäne zugreifen, 

sofern ihnen nicht explizit die erforderlichen Berechtigungen zugewiesen wurden.


• Grenzen für Vertrauensstellungen Eine Domäne ist der kleinste Container innerhalb der AD DS, 

der in einer Vertrauensstellung verwendet werden kann. Vertrauensstellungen werden zur Aktivierung 

der Authentifizierungs- und Autorisierungsdienste verwendet, sodass die Benutzer in einer 

Domäne auf Ressourcen in einer anderen Domäne zugreifen können. Innerhalb einer Gesamtstruktur 

werden Vertrauensstellungen automatisch zwischen der Stammdomäne der Gesamtstruktur 

und einerseits den Stammdomänen einer Struktur sowie andererseits sämtlichen 

untergeordneten Domänen der Stammdomäne der Gesamtstruktur erstellt. 

Sicherheitswarnung Domänengrenzen sind keine Sicherheitsgrenzen – die von einem Administrator in 

einer Domäne durchgeführten Aktionen können sich auf alle anderen Domänen innerhalb der Gesamtstruktur 

auswirken. Zum Erstellen einer Sicherheitsgrenze müssen separate Gesamtstrukturen erstellt werden. 

Weitere Informationen finden Sie in Kapitel 5. 

Die AD DS-Domänen innerhalb einer Gesamtstruktur sind hierarchisch organisiert. Die erste Domäne 

innerhalb der Organisation wird als Gesamtstruktur-Stammdomäne bezeichnet und ist der Ausgangspunkt 

für einen AD DS-Namespace. Die erste Domäne in der Organisation Adatum ist beispielsweise 

Adatum.com. Bei dieser ersten Domäne kann es sich entweder um eine dedizierte oder 

um eine nicht dedizierte Stammdomäne handeln. Eine dedizierte Stammdomäne wird auch als leere 

Stammdomäne bezeichnet und als leerer Platzhalter zum Starten der AD DS verwendet. Die einzigen 

in der dedizierten Stammdomäne enthaltenen Konten sind der Standarddomänenbenutzer sowie Gruppenkonten 

wie das Administratorkonto und die globale Gruppe Domänen-Admins. Bei einer nicht 

dedizierten Stammdomäne handelt es sich um eine Domäne, in der die eigentlichen Benutzer- und 

Gruppenkonten erstellt werden. Die Gründe für die Auswahl einer dedizierten oder einer nicht dedizierten 

Gesamtstruktur-Stammdomäne sind in Kapitel 5 beschrieben. 

Alle anderen Domänen in der Gesamtstruktur sind entweder Peers der Stammdomäne oder untergeordnete 

Domänen. Untergeordnete Domänen verwenden denselben AD DS-Namespace wie die 

übergeordnete Domäne (die Stammdomäne). Beispiel: Wenn die erste Domäne in der Organisation 

Adatum den Namen Adatum.com trägt, könnte der Name einer untergeordneten Domäne in dieser 

Struktur NA.Adatum.com lauten. Die Domäne NA.Adatum.com würde erstellt, um alle Sicherheitsprinzipale 

für die Standorte von Adatum in den USA zu verwalten. Bei entsprechender Größe oder 

Komplexität der Organisation könnten weitere untergeordnete Domänen wie z.B. Vertrieb.NA. 

Adatum.com erforderlich sein. Abbildung 2.7 zeigt die Hierarchie der über- und untergeordneten 

Domänen für die Organisation Adatum. 

Bei einer Konfiguration aus über- und untergeordneten Domänen wird dieses Modell als Domänenstruktur 

bezeichnet. Eine Domänenstruktur besteht aus einer oder mehreren Domänen, die einen 

zusammenhängenden Namespace gemeinsam nutzen. In der Gesamtstruktur Adatum.com verwendet 

NA.Adatum.com den Namespace Adatum.com gemeinsam mit der Stammdomäne der Gesamtstruktur. 

Es lassen sich auch zusätzliche Domänenstrukturen innerhalb derselben Gesamtstruktur implementieren. 

Beim Erstellen einer neuen Domänenstruktur werden Domänen zur Gesamtstruktur hinzugefügt, 

die nicht denselben zusammenhängenden Namespace gemeinsam verwenden. Beispiel: Adatum verfügt 

über ein Tochterunternehmen Trey Research, das eine separate Domäne erfordert. Sie können die 

Domäne TreyResearch.com zur Gesamtstruktur Adatum.com hinzufügen und eine neue Domänenstruktur 

erstellen. In diesem Szenario ist die Domäne TreyResearch.com die Stammdomäne der 

Domänenstruktur.


Übergeordnete Domäne 

Adatum.com 

Untergeordnete Domäne 


Übergeordnete Domäne 

EMEA.Adatum.com 

NA.Adatum.com 


Vertrieb.NA.Adatum.com 

Abbildung 2.7 

Modell der über- und untergeordneten Domänen für die Organisation Adatum 

Wenn weitere Domänen für die Geschäftseinheit Trey Research benötigt werden, können diese als 

untergeordnete Domänen der TreyResearch-Domänenstruktur erstellt werden. Abbildung 2.8 zeigt die 

Organisation Adatum mit mehreren Domänenstrukturen. 

Stammdomäne der Gesamtstruktur 

Stammdomäne der Domäne 

Adatum.com 

TreyResearch.com 

NA.Adatum.com 

Europa.TreyResearch.com 


Vertrieb.Europa.TreyResearch.com 

Abbildung 2.8 

Adatum mit mehreren Domänenstrukturen


Unabhängig davon, ob ein einziger Namespace (eine Domänenstruktur) oder mehrere Namespaces 

(mehrere Domänenstrukturen) verwendet werden, ist die Funktionsweise zusätzlicher Domänen in 

derselben Gesamtstruktur gleich. Alle Domänen sind weiterhin Teil derselben Gesamtstruktur, und 

sämtliche Domänen verfügen über eine transitive Vertrauensstellung mit allen anderen Domänen 

innerhalb der Gesamtstruktur. Die Erstellung zusätzlicher Domänenstrukturen erfordert lediglich Entscheidungen 

im Hinblick auf Organisation und Benennung, wirkt sich jedoch nicht auf die Funktionsweise 

aus. Die Verwendung mehrerer Strukturen anstelle von untergeordneten Domänen wirkt sich 

allerdings auf die DNS-Konfiguration aus (wie in Kapitel 3 beschrieben). 

Ermitteln von Objekten in anderen Domänen 

Da die Informationen in den verschiedenen Domänenpartitionen lediglich auf anderen Domänencontrollern 

innerhalb derselben Domäne repliziert werden, benötigen Domänencontroller eine 

Methode zum Ermitteln von Objekten in anderen Domänen. Beispiel: Wenn ein Benutzer in einer 

Domäne versucht, auf eine Ordnerfreigabe in einer anderen Domäne innerhalb der Gesamtstruktur 

zuzugreifen, muss der Domänencontroller in der Benutzerdomäne feststellen können, dass die 

andere Domäne vorhanden ist, und die Domänencontroller in dieser Domäne ermitteln können. Um 

zu gewährleisten, dass die Domänencontroller nicht nur die eigene Domäne, sondern sämtliche 

Domänen und Verzeichnispartitionen innerhalb der Gesamtstruktur erkennen, verwenden die AD 

DS Querverweise. 

Querverweise werden als Verzeichnisobjekte der Klasse crossRef gespeichert, die das Vorhandensein 

und den Speicherort aller Verzeichnispartitionen kennzeichnen. Zusätzlich enthalten diese 

Objekte Informationen, die von den AD DS zum Erstellen der Verzeichnisstrukturhierarchie 

verwendet werden. Die Klasse crossRef umfasst die folgenden Attribute: 

• nCName Der definierte Name der Verzeichnispartition, auf welche das Objekt crossRef verweist. 

(Das Präfix nC steht für Naming Context – Namenskontext –, einem Synonym für Verzeichnispartition.) 

Die Kombination aller nCName-Eigenschaften in der Gesamtstruktur 

definiert die vollständige Verzeichnisstruktur, einschließlich der unter- und übergeordneten 

Beziehungen zwischen Partitionen. 

• dNSRoot Der DNS-Name der Domäne, in der Server, auf denen die jeweilige Verzeichnispartition 

gespeichert ist, erreicht werden können. 

Für jede Verzeichnispartition in einer Gesamtstruktur wird ein internes Querverweisobjekt im Container 

Partitions gespeichert (CN=Partitions,CN=Configuration,DC=ForestRootDomain). Da sich 

Querverweisobjekte im Container Configuration befinden, werden sie auf jedem Domänencontroller 

in der Gesamtstruktur repliziert. So verfügen sämtliche Domänencontroller über Informationen 

zum Namen aller Partitionen innerhalb der Gesamtstruktur. Durch die Verwendung von Querverweisobjekten 

kann jeder Domänencontroller Verweise auf eine beliebige andere Domäne innerhalb 

der Gesamtstruktur generieren.

Gesamtstrukturen 


Eine Gesamtstruktur stellt die höchste Ebene der logischen AD DS-Struktur dar. Eine AD DS- 

Gesamtstruktur ist ein einziges eigenständiges Verzeichnis. Die Gesamtstruktur ist die Replikations- und 

Sicherheitsgrenze für das Unternehmen. Sämtliche Domänen und Domänenstrukturen sind innerhalb 

einer AD DS-Gesamtstruktur vorhanden. 

Eine AD DS-Gesamtstruktur lässt sich durch die Komponenten definieren, die von allen Domänencontrollern 

innerhalb der Gesamtstruktur gemeinsam verwendet werden. Zu den gemeinsam verwendeten 

Komponenten zählen die folgenden: 

• Ein gemeinsames Schema Alle Domänencontroller in der Gesamtstruktur verfügen über dasselbe 

Schema. Das Schema wird in der Schemaverzeichnispartition der AD DS gespeichert und auf 

allen Domänencontrollern innerhalb der Gesamtstruktur repliziert. Die einzige Möglichkeit zur 

Bereitstellung von zwei unterschiedlichen Schemata in einer Organisation besteht darin, zwei 

separate Gesamtstrukturen bereitzustellen. 

• Eine gemeinsame Konfigurationsverzeichnispartition Alle Domänencontroller in der Gesamtstruktur 

verwenden denselben Konfigurationscontainer. Die Konfigurationspartition enthält Informationen 

zur Topologie der Gesamtstruktur sowie zu anderen Gesamtstruktur-, Domänen- und 

Domänencontrollereinstellungen. Diese Konfigurationsdaten umfassen eine Liste aller Domänen, 

Strukturen und Gesamtstrukturen sowie die Standorte der Domänencontroller und globalen Kataloge. 

Die Konfigurationsverzeichnispartition wird zudem umfassend von Active Directoryfähigen 

Anwendungen wie Exchange Server verwendet. 

• Ein gemeinsamer globaler Katalog Der globale Katalog enthält Informationen zu sämtlichen 

Objekten innerhalb der gesamten Gesamtstruktur. Dies ermöglicht eine effiziente Suche nach 

Objekten innerhalb der Gesamtstruktur sowie die Benutzeranmeldung an einer beliebigen 

Domäne in der Gesamtstruktur unter Verwendung des Benutzerprinzipalnamens. 

• Ein gemeinsamer Satz an gesamtstrukturweiten Betriebsmastern und Administratoren Der Domänennamenmaster 

und der Schemamaster werden auf Gesamtstrukturebene konfiguriert. In jeder 

Gesamtstruktur gibt es nur einen Schemamaster und einen Domänennamenmaster. Zusätzlich 

werden in der Stammdomäne für die Gesamtstruktur zwei Sicherheitsgruppen mit einzigartigen 

Berechtigungen erstellt. Die Gruppe Schema-Admins ist die einzige Gruppe, die zum Ändern des 

Schemas berechtigt ist. Die Gruppe Organisations-Admins ist als einzige Gruppe zum Durchführen 

von Aktionen auf Gesamtstrukturebene berechtigt (z.B. zum Hinzufügen oder Entfernen von 

Domänen zu bzw. aus der Gesamtstruktur). Die Gruppe Organisations-Admins wird ferner automatisch 

zu jeder lokalen Administratorengruppe auf den Domänencontrollern in jeder Domäne 

innerhalb der Gesamtstruktur hinzugefügt. 

• Eine gemeinsame Konfiguration von Vertrauensstellungen Für alle Domänen in der Gesamtstruktur 

wird automatisch eine Vertrauensstellung mit allen anderen Domänen innerhalb der Gesamtstruktur 

konfiguriert. 

Abbildung 2.9 zeigt die Gesamtstruktur von Adatum.


Vertrauensstellung 

Adatum.com 



NA.Adatum.com 

SA.TreyResearch.com 

Forschung.EMEA.Adatum.com 


TestDom.SA.TreyResearch.com 

Gesamtstruktur von Adatum 

Abbildung 2.9 

Eine Gesamtstruktur kann mehrere Domänen und Strukturen umfassen 

Auf der DVD Zum Anzeigen von Informationen zu Ihrer AD DS-Gesamtstruktur und den Domänen innerhalb 

dieser Gesamtstruktur führen Sie das auf der CD enthaltene Windows PowerShell-Skript ListADDS- 

Domains.ps1 aus. 

Vertrauensstellungen 

Wenn keine Vertrauensstellungen konfiguriert werden, ist die Domäne die Grenze für den Ressourcenzugriff 

in einer Organisation. Mit ausreichend Berechtigungen kann über jeden Sicherheitsprinzipal 

(z.B. ein Benutzer- oder Gruppenkonto) auf eine beliebige freigegebene Ressource innerhalb 

derselben Domäne zugegriffen werden. Für den Zugriff auf freigegebene Ressourcen außerhalb der 

Domäne werden AD DS-Vertrauensstellungen verwendet. Bei einer Vertrauensstellung handelt es sich 

um eine Authentifizierungsverbindung zwischen zwei Domänen, über die Sicherheitsprinzipale für 

den Zugriff auf Ressourcen in der anderen Domäne autorisiert werden. 

Wenn zwischen Domänen eine Vertrauensstellung konfiguriert ist, vertraut der Authentifizierungsmechanismus 

der einzelnen Domänen dem Authentifizierungsmechanismus aller anderen vertrauenswürdigen 

Domänen. Die Authentifizierung von Benutzern oder Anwendungen durch eine Domäne 

wird von allen anderen Domänen akzeptiert, die der authentifizierenden Domäne vertrauen. Die 

Benutzer in einer vertrauenswürdigen Domäne haben Zugriff auf Ressourcen in der vertrauenden 

Domäne, es gelten die Zugriffssteuerungen der vertrauenden Domäne. 

Hinweis Vertrauensstellungen werden automatisch zwischen allen Domänen innerhalb einer Gesamtstruktur 

konfiguriert. Diese Vertrauensstellungen können nicht entfernt werden.


Es gibt verschiedene Typen von Vertrauensstellungen, u.a. die folgenden: 

• Transitive bidirektionale Vertrauensstellungen 

• Shortcutvertrauensstellungen 

• Gesamtstrukturvertrauensstellungen 

• Externe Vertrauensstellungen 

• Bereichsvertrauensstellung 

Transitive bidirektionale Vertrauensstellungen 

Sämtliche Domänen in einer Gesamtstruktur verfügen über transitive, bidirektionale Vertrauensstellungen 

mit allen anderen Domänen innerhalb der Gesamtstruktur. Im oben genannten Beispiel 

wird bei Erstellung der Domäne NA.Adatum.com als untergeordnete Domäne der Stammdomäne 

Adatum.com eine automatische bidirektionale Vertrauensstellung zwischen den Domänen NA. 

Adatum.com und Adatum.com erstellt. Über diese Vertrauensstellung kann jeder Benutzer in der 

Domäne NA.Adatum.com auf sämtliche Ressourcen in der Domäne Adatum.com zugreifen, für deren 

Zugriff er berechtigt ist. Gleichermaßen können Sicherheitsprinzipalen in der Domäne Adatum.com 

Zugriffsberechtigungen für Ressourcen in der Domäne NA.Adatum.com erteilt werden. 

Die Vertrauensstellungen innerhalb einer Gesamtstruktur werden als Vertrauensstellung zwischen 

einer übergeordneten und einer untergeordneten Domäne oder als Strukturstamm-Vertrauensstellung 

eingerichtet. Ein Beispiel für eine Vertrauensstellung zwischen einer übergeordneten und einer untergeordneten 

Domäne ist die Vertrauensstellung zwischen der Domäne NA.Adatum.com und der Domäne 

Adatum.com. Eine Strukturstamm-Vertrauensstellung ist die Vertrauensstellung zwischen zwei 

Strukturen innerhalb der Gesamtstruktur, z.B. zwischen Adatum.com und TreyResearch.com. 

Sämtliche Vertrauensstellungen zwischen den Domänen in einer Gesamtstruktur sind jedoch auch 

transitiv. Dies bedeutet, dass sich alle Domänen in der Gesamtstruktur gegenseitig vertrauen. Wenn 

die Domäne Adatum.com der Domäne NA.Adatum.com vertraut und die Domäne EMEA.Adatum.com 

der Domäne Adatum.com vertraut, dann hat die Transitivität zur Folge, dass die Domäne EMEA. 

Adatum.com auch der Domäne NA.Adatum.com vertraut. So können Benutzer in der Domäne 

NA.Adatum.com auf Ressourcen in der Domäne EMEA.Adatum.com zugreifen und umgekehrt. 

Transitive Vertrauensstellungen gelten ebenso für Strukturstamm-Vertrauensstellungen. Die Domäne 

NA.Adatum.com vertraut der Domäne Adatum.com, und die Domäne Adatum.com vertraut der Domäne 

TreyResearch.com. Daher besteht auch zwischen der Domäne NA.Adatum.com und der Domäne 

TreyResearch.com eine transitive Vertrauensstellung. 

Shortcutvertrauensstellungen 

Zusätzlich zu den automatischen, bidirektionalen transitiven Vertrauensstellungen, die beim Erstellen 

einer neuen untergeordneten Domäne erstellt werden, können zwischen den Domänen in der Gesamtstruktur 

Shortcutvertrauensstellungen erstellt werden. Shortcutvertrauensstellungen werden zur Leistungsoptimierung 

beim Zugriff auf Ressourcen zwischen Domänen verwendet, die über transitive 

Vertrauensstellungen verbunden sind. Eine Shortcutvertrauensstellung sollte beim häufigen Ressourcenzugriff 

zwischen Domänen gewählt werden, die remote über die Domänenstruktur oder Gesamtstruktur 

verbunden sind. Die Vertrauensstellungen von Adatum könnten beispielsweise wie in 

Abbildung 2.10 dargestellt konfiguriert werden.


Gesamtstrukturvertrauensstellung 

Vertrauensstellung zwischen einer 

übergeordneten und einer 

untergeordneten Domäne 

Adatum-Gesamtstruktur 

Adatum.com 

WoodgroveBank.com 

WoodgroveBank- 

Gesamtstruktur 


NA.Adatum.com 

Vertrauensstellungsabkürzungen 

Abbildung 2.10 

Forschung.EMEA.Adatum.com 

Vertrauensstellungen in der Adatum-Gesamtstruktur 


Wenn eine Sicherheitsgruppe in der Domäne Forschung.EMEA.Adatum.com häufig auf eine freigegebene 

Ressource in der Domäne Vertrieb.NA.Adatum.com zugreifen muss und zwischen den 

Domänen lediglich transitive Vertrauensstellungen bestehen, müssen Benutzer in der Domäne Forschung.EMEA.Adatum.com 

an einen Domänencontroller in jeder Domäne innerhalb der Gesamtstruktur 

zwischen ihnen und der Domäne verwiesen werden, welche die Ressource enthält. Wenn ein häufiger 

Zugriff erforderlich ist, ist diese Methode nicht effizient. Eine Shortcutvertrauensstellung ist eine 

direkte Vertrauensstellung, über welche die Benutzer in der Domäne Vertrieb.EMEA.Adatum.com an 

einen Domänencontroller in der Domäne Forschung.NA.Adatum.com verwiesen werden können, 

ohne die gesamte Verzeichnisstruktur zu durchlaufen. Diese Shortcutvertrauensstellung ist in 

Abbildung 2.10 dargestellt. Shortcutvertrauensstellungen können als uni- oder bidirektionale Vertrauensstellungen 

konfiguriert werden. Sie sind nicht transitiv. 

Gesamtstrukturvertrauensstellungen 

Bei einer Gesamtstrukturvertrauensstellung handelt es sich um eine bidirektionale Vertrauensstellung 

zwischen zwei separaten Gesamtstrukturen. Bei einer Gesamtstrukturvertrauensstellung kann den 

Sicherheitsprinzipalen in einer Gesamtstruktur Zugriff auf die Ressourcen in einer beliebigen Domäne 

innerhalb einer anderen Gesamtstruktur gewährt werden. Ferner können Benutzer sich unter Verwendung 

desselben UPN an einer beliebigen Domäne in jeder der beiden Gesamtstrukturen anmelden. 

Abbildung 2.10 zeigt eine Gesamtstrukturvertrauensstellung zwischen der Gesamtstruktur 

Adatum.com und der Gesamtstruktur WoodgroveBank.com. 

Hinweis Zum Konfigurieren einer Gesamtstrukturvertrauensstellung müssen sich beide Gesamtstrukturen 

auf Windows Server 2003-Gesamtstrukturfunktionsebene oder einer höheren Ebene befinden.


Gesamtstrukturvertrauensstellungen können in einer Windows Server 2008-Umgebung äußerst nützlich 

sein. Wenn eine Organisation aus politischen oder technischen Gründen mehrere Gesamtstrukturen 

benötigt, kann Benutzern unter Verwendung einer Gesamtstrukturvertrauensstellung problemlos 

Zugriff auf sämtliche Ressourcen innerhalb aller Domänen erteilt werden. Dabei spielt es keine Rolle, 

in welcher Gesamtstruktur sich der Benutzer oder die Ressource befindet. Wenn zwei Unternehmen 

mit Windows Server 2008-Gesamtstrukturen fusionieren, können die beiden Gesamtstrukturen mithilfe 

der Vertrauensstellung logisch zusammengeführt werden. 

Wenngleich Gesamtstrukturvertrauensstellungen ausgezeichnete Funktionen bieten, gelten auch 

einige Einschränkungen: 

• Gesamtstrukturvertrauensstellungen sind gegenüber anderen Gesamtstrukturen nicht transitiv. 

Wenn zwischen Adatum.com und WoodgroveBank.com beispielsweise eine Gesamtstrukturvertrauensstellung 

besteht und WoodgroveBank.com über eine Gesamtstrukturvertrauensstellung mit 

Fabrikam.com verfügt, besteht zwischen Adatum.com und Fabrikam.com nicht automatisch eine 

Gesamtstrukturvertrauensstellung. 

• Gesamtstrukturvertrauensstellungen ermöglichen lediglich die Authentifizierung zwischen 

Gesamtstrukturen, bieten jedoch keine weiteren Funktionen. So verfügt z.B. jede Gesamtstruktur 

weiterhin über eine individuelle globale Katalog-, Schema- und Konfigurationsverzeichnispartition. 

Zwischen den beiden Gesamtstrukturen werden keine Informationen repliziert, die Gesamtstrukturvertrauensstellung 

ermöglicht lediglich das Zuweisen von Zugriffsberechtigungen für 

Ressourcen innerhalb von Gesamtstrukturen. 

• In einigen Fällen ist es nicht sinnvoll, dass sämtliche Domänen in einer Gesamtstruktur allen 

Domänen in einer anderen Gesamtstruktur vertrauen. Wenn dies zutrifft, können unidirektionale, 

nicht transitive externe Vertrauensstellungen zwischen einzelnen Domänen in zwei separaten 

Gesamtstrukturen eingerichtet werden. Alternativ kann für die Gesamtstrukturvertrauensstellung 

auch die ausgewählte Authentifizierung konfiguriert werden, sodass der Zugriff auf Ressourcen 

auf einem Server in der vertrauenden Domäne für die Benutzer einer vertrauenswürdigen Domäne 

explizit aktiviert werden muss. 

Weitere Informationen 

finden Sie in Kapitel 5. 

Weitere Informationen zur Planung von Gesamtstrukturvertrauensstellungen 

Externe Vertrauensstellungen 

Externe Vertrauensstellungen können zwischen AD DS-Domänen in unterschiedlichen Gesamtstrukturen 

oder zwischen einer AD DS-Domäne und einer Domäne unter Windows NT 4.0 oder niedriger 

erstellt werden. Diese Vertrauensstellungen können zum Bereitstellen von Zugriff auf Ressourcen in 

einer Domäne außerhalb der Gesamtstruktur verwendet werden, zu der keine Gesamtstrukturvertrauensstellung 

besteht, oder zum Erstellen einer direkten Vertrauensstellung zwischen zwei Domänen, 

für die bereits eine Gesamtstrukturvertrauensstellung konfiguriert wurde. Der Unterschied zwischen 

einer externen Vertrauensstellung und einer Gesamtstrukturvertrauensstellung besteht darin, dass die 

externe Vertrauensstellung nicht nur zwischen den Stammdomänen der Gesamtstruktur, sondern zwischen 

zwei beliebigen Domänen in einer der beiden Gesamtstrukturen konfiguriert wird. Ferner weisen 

externe Vertrauensstellungen die folgenden Merkmale auf: 

• Externe Vertrauensstellungen sind nicht transitiv. Die Vertrauensstellung besteht nur zwischen 

zwei Domänen.


• Es müssen beide Seiten der Vertrauensstellung konfiguriert werden. Zum Konfigurieren einer 

bidirektionalen Vertrauensstellung muss eine Vertrauensstellung für jede Richtung konfiguriert 

werden. 

• In Windows Server 2008 erzwingen externe Vertrauensstellungen standardmäßig die SID-Filterung. 

Die SID-Filterung wird eingesetzt um zu verifizieren, dass eingehende Authentifizierungsanforderungen 

von Sicherheitsprinzipalen in der vertrauenswürdigen Domäne ausschließlich SIDs 

von Sicherheitsprinzipalen in der vertrauenswürdigen Domäne enthalten. Mithilfe der SID-Filterung 

wird sichergestellt, dass Administratoren in der vertrauenswürdigen Domäne das Attribut 

SIDHistory nicht verwenden können, um nicht autorisierten Zugriff auf Ressourcen in der vertrauenden 

Domäne zu erhalten. 

Bereichsvertrauensstellung 

Der letzte Typ von Vertrauensstellung ist eine Bereichsvertrauensstellung. Diese Vertrauensstellungen 

werden zwischen einer Windows Server 2008-Domäne oder -Gesamtstruktur und einer Nicht- 

Windows-Implementierung eines Kerberos v5-Bereichs konfiguriert. Die Kerberos-Sicherheit 

basiert auf einem offenen Standard, und es sind verschiedene andere Implementierungen von Kerberos-basierten 

Netzwerksicherheitssystemen verfügbar. Bereichsvertrauensstellungen können zwischen 

beliebigen Kerberos-Bereichen mit Unterstützung für den Kerberos v5-Standard erstellt 

werden. Sie können als unidirektionale oder als bidirektionale sowie als transitive oder als nicht 

transitive Vertrauensstellungen konfiguriert werden. 

Standorte 

Alle bisher beschriebenen logischen AD DS-Komponenten sind praktisch völlig unabhängig von der 

physischen Infrastruktur eines Netzwerks. Beim Entwerfen der Domänenstruktur für ein Unternehmen ist 

der Standort der Benutzer beispielsweise nicht die wichtigste Frage, die Sie sich stellen müssen. Sämtliche 

Benutzer in einer Domäne können sich sowohl in einem einzigen Bürogebäude oder an verschiedenen 

Standorten weltweit befinden. Diese Unabhängigkeit der logischen Komponenten von der Netzwerkinfrastruktur 

ist weitgehend auf die Verwendung von Standorten in den AD DS zurückzuführen. 

Standorte bieten die Verbindung zwischen den logischen AD DS-Komponenten und der physischen 

Netzwerkinfrastruktur. Ein Standort ist als ein Netzwerkbereich definiert, in dem sämtliche Domänencontroller 

über eine schnelle und zuverlässige Netzwerkverbindung verbunden sind. In den meisten 

Fällen enthält ein Standort mindestens ein IP-Subnetz (Internet Protocol) in einem LAN (Local Area 

Network) oder WAN (Wide Area Network) mit sehr hoher Geschwindigkeit. Die Verbindung mit den 

übrigen Netzwerkkomponenten erfolgt über langsamere WAN-Verbindungen. 

Auf der DVD Zum Anzeigen von Informationen zu den Standorten einer AD DS-Gesamtstruktur führen Sie 

das auf der CD enthaltene Windows PowerShell-Skript ListADDSSites.ps1 aus. 

Der Hauptgrund für die Erstellung von Standorten ist, Netzwerkdatenverkehr verwalten zu können, 

der langsame Netzwerkverbindungen verwenden muss. Standorte werden zur Steuerung des Netzwerkdatenverkehrs 

innerhalb des Windows Server 2008-Netzwerks auf drei unterschiedliche Arten 

eingesetzt: 

• Replikation Eine der wichtigsten Methoden für die Verwendung von Standorten zur Optimierung 

von Netzwerkdatenverkehr ist die Verwaltung des Replikationsdatenverkehrs zwischen Domänencontrollern.


Beispielsweise werden Änderungen am Verzeichnis innerhalb eines Standorts in nur wenigen 

Minuten repliziert. Der Replikationszeitplan zwischen Standorten kann so gesteuert werden, dass 

der Replikationsdatenverkehr seltener oder außerhalb der Arbeitszeiten erfolgt. Der Replikationsdatenverkehr 

zwischen Standorten wird zum Reduzieren der Bandbreiteanforderungen standardmäßig 

komprimiert, der Replikationsdatenverkehr innerhalb eines Standorts jedoch nicht. (Die 

Unterschiede zwischen der Replikation innerhalb eines Standorts und der Replikation zwischen 

Standorten wird in Kapitel 4 näher erläutert.) 

• Authentifizierung Bei der Benutzeranmeldung an einer Windows Server 2008-Domäne von 

einem Client unter Windows 2000, Windows XP Professional oder Windows Vista versucht der 

Clientcomputer stets, eine Verbindung zu einem Domänencontroller innerhalb desselben Standorts 

wie der Client herzustellen. Wie in Kapitel 3 erläutert, registriert jeder Domänencontroller 

standortspezifische SRV-Datensätze. Beim Versuch des Clientcomputers, einen Domänencontroller 

zu ermitteln, fragt er die DNS-Server stets nach diesen Standortdatensätzen ab. Dies bedeutet, 

dass der Clientanmeldeverkehr innerhalb des Standorts erfolgt. 

• Standortabhängige Netzwerkdienste Die dritte Möglichkeit, Standorte zum Reduzieren der Netzwerkbandbreiteanforderungen 

einzusetzen, besteht darin, Clientverbindungen auf standortabhängige 

Anwendungen und Dienste innerhalb des Standorts einzuschränken. Durch die Verwendung 

von DFS (Distributed File System, Verteiltes Dateisystem) können mehrere Replikate eines Ordners 

an unterschiedlichen Standorten des Netzwerks erstellt werden. Da DFS die Standortkonfiguration 

berücksichtigt, versuchen Clientcomputer stets, auf ein DFS-Replikat innerhalb des eigenen 

Standorts zuzugreifen, bevor über eine WAN-Verbindung auf Informationen in einem anderen 

Standort zugegriffen wird. Zudem verwendet Exchange Server 2007 die AD DS-Standortkonfiguration 

zum Definieren der Nachrichtenroutingtopologie innerhalb der Organisation. Nachrichten, 

die zwischen Exchange Server-Computern innerhalb desselben Standorts übertragen werden, werden 

stets direkt vom Exchange Server-Quellcomputer zum Exchange Server-Zielcomputer gesendet. 

Dies gilt auch dann, wenn eine Nachricht an mehrere Server innerhalb desselben Standorts 

gesendet werden muss. Zwischen Exchange Server-Computern an unterschiedlichen Standorten 

werden lediglich Einzelkopien der Nachrichten übertragen, selbst wenn die Nachrichten an Benutzer 

auf unterschiedlichen Exchange Server-Computern am Zielstandort gesendet wurden. 

Alle Computer innerhalb eines Windows Server 2008-Netzwerks werden einem Standort zugewiesen. 

Bei der Installation der AD DS in einer Windows Server 2008-Umgebung wird ein Standardstandort 

mit dem Namen Standardname-des-ersten-Standorts erstellt, und sofern keine zusätzlichen 

Standorte erstellt werden, werden sämtliche Computer innerhalb der Gesamtstruktur diesem Standort 

zugewiesen. Bei Erstellung von weiteren Standorten werden diese mit IP-Subnetzen verknüpft. Wenn 

ein Server unter Windows Server 2008 zu einem Domänencontroller heraufgestuft wird, wird der 

Domänencontroller automatisch einem Standort zugewiesen, welcher der IP-Adresse des Computers 

entspricht. Domänencontroller können bei Bedarf unter Verwendung des Verwaltungstools Active 

Directory-Standorte und -Dienste zwischen Standorten verschoben werden. 

Clientcomputer ermitteln ihre Standorte, wenn sie erstmalig gestartet werden und sich an der Domäne 

anmelden. Da der Clientcomputer nicht weiß, zu welchem Standort er gehört, verbindet er sich mit 

einem beliebigen Domänencontroller innerhalb der Domäne. Als Teil dieses erstmaligen Anmeldevorgangs 

informiert der Domänencontroller den Client, zu welchem Standort der Client gehört, und der 

Client speichert diese Informationen für die nächste Anmeldung.


Hinweis Wenn ein Domänencontroller oder Clientcomputer über eine IP-Adresse verfügt, die nicht mit 

einem bestimmten Standort verknüpft ist, wird dieser Computer dem Standort Standardname-des-ersten- 

Standorts zugewiesen. Sämtliche Computer innerhalb einer Windows Server 2008-Domäne müssen einem 

Standort zugewiesen werden. 

Wie bereits in diesem Kapitel erwähnt, gibt es keine direkte Verbindung zwischen Standorten und den 

anderen logischen Konzepten in den AD DS. Ein Standort kann mehrere Domänen enthalten, und eine 

Domäne kann mehrere Standorte umfassen. Wie in Abbildung 2.11 dargestellt, umfasst der Standort 

Seattle beispielsweise die Domäne Adatum.com und die Domäne NA.Adatum.com. Die Domäne Trey- 

Research.com umfasst mehrere Standorte. 

Adatum.com 

NA.Adatum.com 

Calgary-Standort 

Seattle-Standort 

Denver-Standort Vancouver-Standort 



Standorte und Domänen innerhalb einer AD DS-Gesamtstruktur 

Hinweis Standorte sind Thema mehrerer weiterer Kapitel dieses Buches. In Kapitel 3 wird die Rolle von 

DNS und Standorten für die Clientanmeldung erläutert. In Kapitel 4 erfahren Sie, welche Rolle Standorte bei 

der Replikation spielen und wie Standorte erstellt und konfiguriert werden. Einzelheiten zum Entwerfen einer 

idealen Standortkonfiguration für eine AD DS-Gesamtstruktur finden Sie in Kapitel 5. 

Organisationseinheiten 

Durch die Implementierung von mehreren Domänen in einer Gesamtstruktur, entweder in einer einzelnen 

Struktur oder in mehreren Strukturen, ist Windows Server 2008 AD DS skalierbar, um Verzeichnisdienste 

für praktisch jede Netzwerkgröße bereitzustellen. Viele Komponenten der AD DS, 

wie beispielsweise der globale Katalog und automatische transitive Vertrauensstellungen, sind unabhängig 

von der Verzeichnisgröße für eine effiziente Verwendung und Verwaltung dieses Unternehmensverzeichnisses 

konzipiert. 

Der Zweck von Organisationseinheiten (Organizational Units, OUs) ist jedoch eine vereinfachte Verwaltung 

der AD DS in kleineren Strukturen. OUs werden für eine effizientere Verwaltung von einzelnen 

Domänen eingesetzt. Eine Domäne könnte Zehntausende (oder sogar Millionen) von Objekten 

enthalten. Die Verwaltung dieser großen Anzahl an Objekten ohne eine Möglichkeit zum Organisieren 

dieser Objekte in logischen Gruppen ist äußerst schwierig. OUs werden zum Erstellen einer hierarchischen 

Struktur innerhalb einer Domäne verwendet. Abbildung 2.12 zeigt ein Beispiel für eine mögliche 

OU-Struktur im Unternehmen Adatum.


Adatum.com 

OU Seattle OU Calgary OU Denver 

OU Produkt OU Vertrieb OU F&E 

OU Produkt 

OU Marketing 

OU Entwurf 


OU Manu 

OU-Strukturen können eine Vielzahl von Ebenen umfassen 

Bei OUs handelt es sich um Containerobjekte, die verschiedene Typen von Verzeichnisdienstobjekten 

enthalten. Dazu zählen u.a. die folgenden: 

• Computer 

• Kontakte 

• Gruppen 

• inetOrgPerson 

• Drucker 

• Benutzer 

• Freigegebene Ordner 

• Organisationseinheiten 

Mithilfe von OUs werden Objekte zu Verwaltungszwecken gruppiert. Es gibt zwei Möglichkeiten, um 

OUs als Verwaltungseinheiten zu verwenden: zum Delegieren von Administratorrechten und zum 

Verwalten einer Gruppe aus Objekten als einzige Einheit. 

Verwenden von OUs zum Delegieren von Administratorrechten 

OUs können zum Delegieren von Administratorrechten verwendet werden. Ein Benutzer kann beispielsweise 

die Berechtigung zum Durchführen von Administratoraufgaben für eine bestimmte OU 

erhalten. Dabei kann es sich um umfassende Rechte handeln, sodass der Benutzer über Vollzugriff für 

die OU und sämtliche Objekte in der OU verfügt, oder es könnten äußerst eingeschränkte Berechtigungen 

zugewiesen werden (beispielsweise lediglich zum Zurücksetzen der Kennwörter für Benutzer 

in der OU).


Der Benutzer, dem die Administratorrechte für eine OU erteilt werden, verfügt außerhalb der OU 

nicht standardmäßig über Administratorrechte. 

Die OU-Struktur ist im Hinblick auf das Zuweisen von Rechten (in vielen Windows-Dialogfeldern 

und -Eigenschaftenfenstern auch als Berechtigungen bezeichnet) für die Objekte innerhalb der OU 

äußerst flexibel. Die OU selbst verfügt über eine Zugriffssteuerungsliste (Access Control List, ACL), 

um Rechte für diese OU zuweisen zu können. Darüber hinaus verfügen sämtliche Objekte in einer 

OU und sogar alle Attribute für jedes Objekt über eine ACL. Dies bedeutet, dass sich die Administratorrechte 

der verschiedenen Benutzer für die OU äußerst präzise verwalten lassen. So kann einer 

Gruppe Helpdesk beispielsweise die Berechtigung zum Ändern der Kennwörter für die Benutzer in 

einer OU zugewiesen werden, während andere Eigenschaften für das Benutzerkonto jedoch nicht 

geändert werden dürfen. Oder Sie weisen der OU Personalabteilung Berechtigungen zum Ändern von 

persönlichen Informationen für sämtliche Benutzerkonten in allen OUs zu, erteilen den Mitgliedern 

dieser Abteilung jedoch keine weiteren Berechtigungen für die übrigen Attribute der Benutzerkonten 

oder Rechte für andere Objekte. Wenn für einige Objekte andere Berechtigungen festgelegt werden 

sollen als für andere Objekte innerhalb einer OU, können die Berechtigungen auch für einzelne 

Objekte zugewiesen werden. 

Verwenden von OUs zum Verwalten von Objektgruppen 

Ein weiterer Grund für die Verwendung von OUs ist das Gruppieren von Objekten, um diese identisch 

zu verwalten. Wenn beispielsweise alle Arbeitsstationen in einer Abteilung identisch verwaltet 

werden sollen (z.B. um einzuschränken, welche Benutzer sich an diesen Arbeitsstationen anmelden 

dürfen), können Sie sämtliche Arbeitsstationen in einer OU gruppieren und die Berechtigung Lokal 

anmelden auf OU-Ebene konfigurieren. Diese Berechtigung wird anschließend auf alle Arbeitsstationen 

in der OU angewendet. Wenn eine Gruppe von Benutzern dieselbe standardmäßige Desktopkonfiguration 

und dieselben Anwendungen benötigt, können die Benutzer in einer OU zusammengefasst 

werden, und mithilfe von Gruppenrichtlinien können Sie anschließend den Desktop konfigurieren und 

die Installation der Anwendungen verwalten. 

In vielen Fällen werden die Objekte in einer OU über Gruppenrichtlinien verwaltet. Mithilfe von 

Gruppenrichtlinien können Sie Benutzerdesktops sperren und einen standardisierten Desktop, Anund 

Abmeldeskripts sowie die Ordnerumleitung für diese Benutzer bereitstellen. Tabelle 2.3 enthält 

eine kurze Liste der für Gruppenrichtlinien verfügbaren Einstellungstypen. 

Tabelle 2.3 

Einstellungstypen für Gruppenrichtlinien 

Einstellungstypen 

Administrative Vorlagen 

Sicherheit 

Softwareinstallation 

Skripts 

Erläuterung 

Diese Vorlagen werden zur Verwaltung von registrierungsbasierten Parametern für die 

Konfiguration von Anwendungs- und Benutzerdesktopeinstellungen verwendet. Dies 

umfasst den Zugriff auf die Betriebssystemkomponenten, den Zugriff auf die Systemsteuerung 

sowie die Konfiguration von Offlinedateien. 

Diese Einstellungen werden zur Verwaltung von lokalen Computern, Domänen und Netzwerksicherheitseinstellungen 

verwendet. Dies umfasst das Steuern des Benutzerzugriffs 

auf das Netzwerk, das Konfigurieren von Kontorichtlinien sowie das Steuern von 

Benutzerrechten. 

Diese Einstellungen werden zum Zentralisieren der Verwaltung von Softwareinstallationen 

und -wartung verwendet. 

Diese Einstellungen werden zum Angeben von Skripts verwendet, die beim Starten 

oder Herunterfahren eines Computers bzw. beim An- oder Abmelden eines Benutzers 

ausgeführt werden können.


Tabelle 2.3 

Einstellungstypen für Gruppenrichtlinien (Fortsetzung) 

Einstellungstypen 

Ordnerumleitung 

Einstellungen 

Erläuterung 

Diese Einstellungen werden zum Speichern bestimmter Benutzerprofilordner auf einem 

Netzwerkserver verwendet. Diese Ordner, wie z.B. der Ordner Eigene Dateien scheinen 

lokal gespeichert zu werden, befinden sich jedoch eigentlich auf einem Server, sodass 

von jedem Computer im Netzwerk aus darauf zugegriffen werden kann. 

Über diese Einstellungen werden Optionen im Hinblick auf Windows-Einstellungen oder 

die Systemsteuerung verwaltet, u.a. Laufwerkzuordnungen, Umgebungsvariablen, 

Netzwerkfreigaben, lokale Benutzer und Gruppen, Dienste, Geräte usw. 

Gruppenrichtlinienobjekte werden meist auf OU-Ebene zugewiesen. Dies vereinfacht die Verwaltung 

der Benutzer in der OU, da der OU ein Gruppenrichtlinienobjekt – beispielsweise eine Richtlinie administrativer 

Vorlagen – zugewiesen werden kann, die anschließend für alle Benutzer oder Computer in 

der OU erzwungen wird. 

Hinweis OUs sind keine Sicherheitsprinzipale. Daher ist es nicht möglich, OUs zum Zuweisen von 

Berechtigungen zu einer Ressource zu verwenden und anschließend die Vererbung dieser Berechtigungen 

an sämtliche Benutzer in der OU festzulegen. OUs werden zu Verwaltungszwecken eingesetzt. Zum Erteilen 

von Ressourcenzugriff verwenden Sie Sicherheitsgruppen. 


In diesem Kapitel wurden die grundlegenden physischen und logischen Komponenten der AD DS in 

Windows Server 2008 beschrieben. Wenngleich das Verständnis der physischen Komponenten wichtig 

ist (insbesondere bei der Datenbankverwaltung, Platzierung von Domänencontrollern und der 

Schemaverwaltung), betreffen Ihre Aufgaben in den AD DS weitgehend die logischen Komponenten. 

Daher behandelt ein Großteil der übrigen Kapitel in diesem Buch die logische Struktur der AD DS. 

Zusätzliche Ressourcen 

• Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“ enthält Einzelheiten zum 

Entwerfen der logischen und physischen AD DS-Konfiguration. 

• Die technische Referenz zu Domänen- und Gesamtstrukturvertrauensstellungen unter 

http://technet2.microsoft.com/windowsserver/en/library/92b3b6cb-9eb3-4dd7-b5f6- 

3fa9be8080821033.mspx?mfr=true liefert Einzelheiten zu Vertrauensstellungen in einer Active 

Directory-Umgebung (in englischer Sprache) Diese Quelle bezieht sich auf Windows 

Server 2003, die Implementierung von Vertrauensstellungen wurde in Windows Server 2008 

jedoch nicht wesentlich geändert. 

• Auf der Active Directory-Website unter http://www.microsoft.com/technet/scriptcenter/scripts/ 

default.mspx?mfr=true sind verschiedene Skripts zum Auflisten und Ändern der AD DS-Objekte 

verfügbar. 

Verwandte Tools 

Windows Server 2008 bietet mehrere Tools, die zur Verwaltung der logischen und physischen 

AD DS-Komponenten eingesetzt werden können. In Tabelle 2.4 finden Sie einige dieser Tools und 

ihre Einsatzmöglichkeiten.


Tabelle 2.4 

AD DS-Verwaltungstools 

Toolname 

Active Directory-Benutzer und 

-Computer 

Active Directory-Domänen und 

-Vertrauensstellungen 

Active Directory-Standorte und 

-Dienste 

Ntdsutil.exe oder Dsbutil.exe 

ADSI-Editor 

Beschreibung und Zweck 

Zur Konfiguration von AD DS-Domänen, einschließlich Konfiguration und Verwaltung 

von OUs und allen anderen Domänenobjekten. 

Zur Konfiguration von AD DS-Vertrauensstellungen. 

Zur Konfiguration von Standorten und Replikation. 

Zur Verwaltung der AD DS-Datenspeicherdateien und zum Übertragen von FSMO- 

Rollen zwischen Domänencontrollern. 

Zum Anzeigen und Ändern des Inhalts von AD DS-Partitionen. 

Ressourcen auf der CD 

• Bei ListDomainControllers.ps1 handelt es sich um ein Windows PowerShell-Skript zum Auflisten 

aller Domänencontroller in einer Domäne und globalen Katalogserver in einer Gesamtstruktur. 

• Das Windows PowerShell-Skript ListFSMOs.ps1 dient zum Auflisten aller Betriebsmasterserver 

in einer Gesamtstruktur und Domäne. 

• ListADDSDomains.ps1 ist ein Windows PowerShell-Skript zum Auflisten von Informationen zu 

sämtlichen Domänen in einer Gesamtstruktur. 

• ListADDSSites.ps1 ist ein Windows PowerShell-Skript zum Auflisten von Informationen zu sämtlichen 

Standorten in einer Gesamtstruktur. 

Verwandte Hilfethemen 

• „Verwalten von Vertrauensstellungen“ in der Hilfe zu Active Directory-Domänen und -Vertrauensstellungen. 

• „Verwalten von Gesamtstrukturvertrauensstellungen“ in der Hilfe zu Active Directory-Domänen 

und -Vertrauensstellungen. 

• „Grundlegendes zu Domänen“ in der Hilfe zu Active Directory-Benutzer und -Computer.

61 


Active Directory-Domänendienste und DNS 


Integration von DNS in die AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

AD DS-integrierte Zonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Integrieren von DNS-Namespaces in AD DS-Domänen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 


Empfohlene Vorgehensweisen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 

Zusätzliche Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 

Die Active Directory-Domänendienste in Microsoft Windows Server 2008 erfordern für die Ermittlung 

von Ressourcen in einem Netzwerk das Domain Name System (DNS). Ohne eine zuverlässige 

DNS-Infrastruktur kann zwischen Domänencontrollern in Ihrem Netzwerk keine AD DS-Replikation 

durchgeführt werden, Ihre Microsoft Windows XP- und Windows Vista-Clients können sich nicht 

am Netzwerk anmelden und Server, die Microsoft Exchange Server 2007 ausführen, können keine 

E-Mails versenden. Grundsätzlich ist eine stabile und verfügbare DNS-Implementierung erforderlich, 

um die einwandfreie Funktionsfähigkeit des Windows Server 2008-Netzwerks zu gewährleisten. 

Daher benötigen Sie für die Verwaltung einer Windows Server 2008-AD DS-Umgebung umfassende 

Kenntnisse zu DNS-Konzepten und zur DNS-Implementierung für Windows Server 2008. 

Die AD DS sind mit DNS auf verschiedene Weise eng verbunden. Zunächst nutzen alle Computer, die 

Microsoft Windows 2000 oder höhere Betriebssystemversionen ausführen, DNS für die Ermittlung 

von Domänencontrollern in einer AD DS-Umgebung. Dies umfasst auch Clientcomputer, die versuchen, 

sich am Netzwerk anzumelden, Domänencontroller, die versuchen, eine Verbindung mit Replikationspartnern 

aufzubauen, oder Exchange-Server, die Informationen zu E-Mail-Empfängern in den 

AD DS ermitteln. Diese Computer versuchen erst nach einem fehlgeschlagenen DNS-Lookup, die 

NetBIOS-Namensauflösung mithilfe von Windows Internet Name Service (WINS), Broadcasts oder 

LMHosts-Dateien durchzuführen. Außerdem können Sie DNS-Zonendaten im AD DS-Datenspeicher 

speichern, der erweiterte Funktionen und eine erhöhte Sicherheit bietet. Und schließlich handelt es 

sich bei AD DS-Domänennamen um DNS-Namen. Umfasst Ihre AD DS-Gesamtstruktur mehrere 

Domänen in einer hierarchischen Konfiguration (d.h. über- und untergeordnete Domänen) oder in 

einer Peerkonfiguration (mehrere Domänenstrukturen), sollte Ihre DNS-Implementierung der AD DS- 

Domänenimplementierung entsprechen. 

Wichtig Da DNS für die AD DS von wesentlicher Bedeutung ist, ist es unbedingt erforderlich, dass Sie mit 

den DNS-Konzepten vertraut sind und wissen, wie DNS implementiert wird. Wenn Sie mit DNS nicht vertraut 

sind, sollten Sie auf die sehr empfehlenswerten Referenzen auf der Microsoft-Website zurückgreifen, wie beispielsweise 

die „DNS Technical Reference“, die unter http://technet2.microsoft.com/WindowsServer/en/ 

Library/6e45e81e-fb44-4a20-a752-ebe740e2acc61033.mspx in englischer Sprache bereitgestellt wird.

62 Kapitel 3: Active Directory-Domänendienste und DNS 

Integration von DNS in die AD DS 

Die AD DS sind ohne eine zuverlässige DNS-Konfiguration nicht funktionsfähig. DNS ist in den 

AD DS besonders wichtig, da DNS die von den Computern in einem Netzwerk benötigten Informationen 

zum Ermitteln der AD DS-Domänencontroller bereitstellt. Dieser Abschnitt liefert einen 

umfassenden Überblick über die in DNS gespeicherten Informationen sowie die Prozesse, die ein 

Clientcomputer zum Ermitteln der Domänencontroller anwendet. 

Auf der DVD Aufgrund der Abhängigkeit der AD DS von DNS sollten Sie sicherstellen, dass die Dokumentation 

der von Ihrem Unternehmen verwalteten DNS-Zonen stets auf dem aktuellen Stand ist. Sie können das 

auf der Begleit-CD enthaltene Spreadsheet DNSConfig.xlsx für die Dokumentation der Konfiguration Ihrer 

DNS-Zone und DNS-Server nutzen. 

SVR-Ressourceneinträge 

Um die Ermittlung von Domänencontrollern zu vereinfachen, nutzen die AD DS sogenannte SRV- 

Ressourceneinträge (Service Location) bzw. Einträge zur Dienstidentifizierung. Ein SRV-Eintrag, 

beschrieben im RFC 2782, „A DNS RR for Specifying the Location of Services (DNS SRV)“ (in 

englischer Sprache), unter http://www.ietf.org/rfc/rfc2782.txt wird für die Ermittlung von Dienste 

bereitstellenden Computern verwendet, die sich in einem TCP/IP-Netzwerk (Transmission Control Protocol/Internet 

Protocol) befinden. In Windows Server 2008 zeichnen alle Domänencontroller SRV-Einträge 

in DNS auf, um Computer zu kennzeichnen, die AD DS-bezogene Dienste bereitstellen. 

Hinweis Alle Netzwerke benötigen eine Methode zur Ermittlung von Computern, die Domänendienste 

bereitstellen. In Windows NT basierte die Domänenanmeldung auf NetBIOS-Namen. Alle Domänencontroller 

registrierten den NetBIOS-Namen Domänenname mit als 16. Zeichen im Netzwerknamen und in 

WINS (Windows Internet Name Service). Bei der Anmeldung eines Clients am Netzwerk, versuchte der 

Client die Server zu ermitteln, die den Namen des Domänencontrollers registriert hatten. Konnten diese 

Server nicht durch den Client ermittelt werden, schlug die Anmeldung fehl. Seit Windows 2000 werden SRV- 

Einträge zum Ermitteln von Domänencontrollern verwendet. Ohne die SRV-Einträge könnten diese Clients 

keine Anmeldung an der Windows Server 2008-Domäne durchführen. Windows Server 2008-Domänencontroller 

registrieren noch immer den NetBIOS-Domänennamen im Netzwerk und in WINS, sofern ein WINS- 

Server konfiguriert wurde. 

Für jeden SRV-Eintrag wird ein Standardformat verwendet, wie in Tabelle 3.1 erläutert und im folgenden 

Beispiel eines der von den AD DS verwendeten Eintrags dargestellt wird: 

_ldap._tcp.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com 

Tabelle 3.1 

Die Komponenten eines SRV-Eintrags 

Komponente Beispiel Erläuterung 

Dienst _ldap Der Dienst, den dieser Eintrag kennzeichnet. Dieser Server wird durch den 

Dienst als einen Server identifiziert, der auf LDAP-Anforderungen antwortet. 

Protokoll _tcp Das für diesen Dienst verwendete Protokoll. Es kann sich entweder um 

TCP oder UDP (User Datagram Protocol) handeln. 

Name Adatum.com Der Domänenname, auf den dieser Eintrag verweist. 

TTL 600 Die Standardgültigkeitsdauer (Time To Live, TTL) für diesen Eintrag 

(in Sekunden). 

Klasse IN Die Standard-DNS-Internetklasse.

Integration von DNS in die AD DS 63 

Tabelle 3.1 

Die Komponenten eines SRV-Eintrags (Fortsetzung) 

Komponente Beispiel Erläuterung 

Ressourceneintrag SRV Kennzeichnet den Eintrag als SRV-Eintrag. 

Priorität 0 Kennzeichnet die Priorität dieses Eintrags für den Client. Wenn mehrere 

SRV-Einträge für den gleichen Dienst vorhanden sind, versuchen die 

Clients zuerst eine Verbindung mit dem Server herzustellen, der den 

geringsten Prioritätswert aufweist. 

Gewichtung 100 Ein Lastenausgleichsmechanismus. Wenn mehrere SRV-Einträge für einen 

Dienst die gleiche Priorität aufweisen, werden die Einträge mit der höheren 

Gewichtung häufiger von Clients verwendet. 

Port 389 Der von diesem Dienst verwendete Port. 

Ziel SEA-DC1.Adatum.com Der Host, der den durch diesen Eintrag gekennzeichneten Dienst bereitstellt. 

In Abbildung 3.1 wird dieser Eintrag in der DNS-Verwaltungskonsole dargestellt. 

Grundsätzlich wird über die in diesem Eintrag enthaltenen Informationen angegeben, dass ein Client 

für die Ermittlung eines LDAP-Servers (Lightweight Directory Access Protocol) in der Domäne 

Adatum.com eine Verbindung mit SEA-DC1.Adatum.com herstellen soll. 

Abbildung 3.1 

Beispiel eines SRV-Eintrags 

Von AD DS-Domänencontrollern registrierte SRV-Einträge 

Die Domänencontroller in einer Windows Server 2008-Domäne registrieren viele SRV-Einträge in 

DNS. In der folgenden Liste werden alle Einträge aufgeführt, die durch den ersten Server in einer 

Gesamtstruktur registriert werden: 

Adatum.com. 600 IN A 10.10.10.10 

Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c


_ldap._tcp.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

_ldap._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 389 

SEA-DC1.Adatum.com. 

_ldap._tcp.pdc._msdcs.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

_ldap._tcp.gc._msdcs.Adatum.com. 600 IN SRV 0 100 3268 SEA-DC1.Adatum.com. 

_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.Adatum.com. 600 IN SRV 0 

100 3268 SEA-DC1.Adatum.com. 

_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.Adatum.com. 

600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

gc._msdcs.Adatum.com. 600 IN A 10.10.10.10 

175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.Adatum.com. 600 IN CNAME 


gc._msdcs.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c 

_kerberos._tcp.dc._msdcs.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com. 

_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.Adatum.com. 600 IN 

SRV 0 100 88 SEA-DC1.Adatum.com. 

_ldap._tcp.dc._msdcs.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.Adatum.com. 600 IN SRV 0 

100 389 SEA-DC1.Adatum.com. 

_kerberos._tcp.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com. 

_kerberos._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 88 


_gc._tcp.Adatum.com. 600 IN SRV 0 100 3268 SEA-DC1.Adatum.com. 

_gc._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 3268 


_kerberos._udp.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com. 

_kpasswd._tcp.Adatum.com. 600 IN SRV 0 100 464 SEA-DC1.Adatum.com. 

_kpasswd._udp.Adatum.com. 600 IN SRV 0 100 464 SEA-DC1.Adatum.com. 

DomainDnsZones.Adatum.com. 600 IN A 10.10.10.10 

DomainDnsZones.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c 

_ldap._tcp.DomainDnsZones.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.Adatum.com. 600 IN 


ForestDnsZones.Adatum.com. 600 IN A 10.10.10.10 

ForestDnsZones.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c 

_ldap._tcp.ForestDnsZones.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com. 

_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.Adatum.com. 600 IN 


Hinweis Wenn eine Heraufstufung eines Windows Server 2008-Servers zum Domänencontroller vorgenommen 

wird, werden alle diese Einträge in eine Datei mit dem Namen Netlogon.dns geschrieben, die 

sich im Ordner %systemroot%\System32\config befindet. Wenn Sie für die DNS-Server keine dynamischen 

Updates aktivieren möchten, können Sie diese Einträge in die DNS-Zone importieren. 

Durch den ersten Teil des SRV-Eintrags wird der Dienst gekennzeichnet, auf den der SRV-Eintrag 

verweist. Folgende Dienste stehen zur Auswahl: 

• _ldap Bei den AD DS handelt es sich um einen LDAP-kompatiblen Verzeichnisdienst, wobei 

die Domänencontroller die Funktion der LDAP-Server übernehmen. Die _ldap-SRV-Einträge 

kennzeichnen die im Netzwerk verfügbaren LDAP-Server. Bei diesen Servern kann es sich um 

Windows Server 2008-Domänencontroller, um Windows-Domänencontrollern, auf denen Vorgängerbetriebssysteme 

ausgeführt werden, oder um andere LDAP-Server handeln. 

• _kerberos Hierbei handelt es sich um das primäre Authentifizierungsprotokoll für alle Clients 

und Server ab Windows 2000. Die _kerberos-SRV-Einträge kennzeichnen alle Schlüsselverteilungscenter 

(Key Distribution Centers, KDCs) im Netzwerk.


Bei diesen KDCs kann es sich um Windows Server 2008-Domänencontroller, um Windows- 

Domänencontroller, auf denen Vorgängerbetriebssysteme ausgeführt werden, oder um andere 

KDC-Server handeln. 

• _kpasswd Der _kpasswd-SRV-Eintrag kennzeichnet die Kerberos-Kennwortänderungsserver im 

Netzwerk (auch bei diesen Servern kann es sich um Windows Server 2008-Domänencontroller, 

um Windows-Domänencontrollern, auf denen Vorgängerbetriebssysteme ausgeführt werden, oder 

um weitere Kerberos-Kennwortänderungsserver handeln). 

• _gc Der _gc-SRV-Eintrag ist spezifisch für die globale Katalogfunktion in den AD DS. Dieser 

Eintrag wird nur von Windows-Domänencontrollern registriert, auf denen Windows Server 2008 

oder Vorgängerversionen ausgeführt werden, die als globale Katalogserver konfiguriert wurden. 

Viele SRV-Einträge enthalten zusätzlich zu den in Tabelle 3.1 aufgeführten Komponenten außerdem 

eine Standortkennzeichnung. Durch die Standortimplementierung kann sichergestellt werden, dass 

Netzwerkclients immer versuchen, eine Anmeldung an einem Domänencontroller durchzuführen, der 

sich am gleichen Standort wie der Client befindet. Ohne Standorteinträge können Computer keine 

Domänencontroller ermitteln, die sich am gleichen Standort wie der Client befinden. Das von einem 

Client zum Ermitteln der Standortinformationen angewendete Verfahren wird im nächsten Abschnitt 

erläutert. 

Bei dem in vielen Einträgen dargestellten Wert _msdcs handelt es sich um eine weitere wesentliche 

Komponente von SRV-Einträgen. Bei einigen der durch die SRV-Einträge bereitgestellten Dienste 

handelt es sich um nicht Microsoft-spezifische Dienste. Im Netzwerk könnten beispielsweise LDAPoder 

Kerberos-Serverimplementierungen von einem Drittanbieter vorhanden sein. Diese Server 

könnten ebenfalls einen SRV-Eintrag im DNS-Server registrieren. Windows Server 2008-Domänencontroller 

registrieren die allgemeinen Einträge (z.B. _ldap._tcp.Adatum.com), allerdings registrieren die 

Domänencontroller auch Einträge, die die Referenz _msdcs enthalten. Diese Einträge verweisen ausschließlich 

auf Microsoft-spezifische Rollen, d.h. Domänencontroller, die mit mit Betriebssystemversionen 

ab Windows 2000 ausgeführt werden. Durch diese Einträge wird die Hauptfunktion jedes Servers 

als gc (Global Catalog, globaler Katalog), dc (Domain Controller, Domänencontroller) oder pdc 

(Primary Domain Controller Emulator, primärer Domänencontrolleremulator) gekennzeichnet. 

Hinweis Ihnen ist vielleicht bereits aufgefallen, dass die Ressourceneinträge mit dem Wert _msdcs in 

einer anderen Zone dargestellt werden als die Ressourceneinträge in der DNS-Verwaltungskonsole. Der 

Zonenname wird mit _msdcs.Domänenname und nicht einfach nur mit Domänenname bezeichnet. Wenn 

Sie DNS auf einem Domänencontroller installieren und den Assistenten zum Installieren der Active Directory-Domänendienste 

auf dem ersten Domänencontroller in einer Domäne ausführen, werden die DNS- 

Zonen in Anwendungspartitionen im AD DS-Datenspeicher gespeichert. Die _msdcs-Zoneninformation werden 

in einer Anwendungspartition gespeichert, die in der gesamten AD DS-Gesamtstruktur repliziert wird, 

wohingegen die Domänenzone in einer Anwendungspartition gespeichert wird, die auf alle AD DS-Domänencontroller 

repliziert wird, die ebenfalls als DNS-Server fungieren. Dieses Thema wird in den folgenden 

beiden Abschnitten ausführlicher erläutert. 

Bei einem weiteren registrierten Eintrag handelt es sich um die global eindeutige Kennung (Globally 

Unique Identifier, GUID) der Domäne. Durch diesen Eintrag kann der Client einen Domänencontroller 

auf Grundlage seiner GUID ermitteln. Der GUID-Eintrag der Domäne wird für die Ermittlung von 

Domänencontrollern bei einer Domänenumbenennung verwendet. 

Windows Server 2008-Domänencontroller registrieren ferner die folgenden DNS-Hosteinträge (A/ 

AAAA), um LDAP-Clients verwenden zu können, die keine DNS-SRV-Einträge unterstützen:


• DNSDomainname 600 IN A IPv4Address Mithilfe dieses Eintrags kann ein nicht SRV-fähiger Client 

jeden beliebigen Domänencontroller in der Domäne über die Suche nach einem A-Eintrag ermitteln. 

Ein Name dieser Form wird durch einen LDAP-Verweis an den LDAP-Client zurückgegeben. 

Diese Hosteinträge werden für den AD DS-Domänennamen sowie für die Domänennamen 

ForestDNSZones und DomainDNSZones registriert. 

• DNSDomainname 600 IN AAAA IPv6Address Mithilfe dieses Eintrags kann ein nicht SRV-fähiger 

Client jeden beliebigen Domänencontroller in einer Domäne über die Suche nach einem AAAA- 

Eintrag ermitteln. Domänencontroller, die IPv6-fähig sind, registrieren keine verbindungslokale 

IPv6-Adresse, sie registrieren jedoch statisch konfigurierte IPv6-Adressen. Diese Hosteinträge 

werden für den AD DS-Domänennamen sowie für die Domänennamen ForestDNSZones und 

DomainDNSZones registriert. 

• gc._msdcs.DnsForestName Mithilfe dieses Eintrags kann ein nicht SRV-fähiger Client jeden 

beliebigen globalen Katalogserver in der Gesamtstruktur über die Suche nach einem A-Eintrag 

ermitteln. Ein Name wird in dieser Form durch einen LDAP-Verweis an den LDAP-Client 

zurückgegeben. 

So funktioniert es: SRV-Einträge und RODCs 

Aus Sicherheitsgründen nehmen schreibgeschützte Domänencontroller (Read-Only Domain Controller, 

RODC) und schreibgeschützte globale Katalogserver (Read-Only Global Catalog, ROGC) 

standardmäßig keine Registrierung ihrer eigenen DNS-Einträge vor. Stattdessen sendet der RODC 

oder der ROGC eine DNS-Aktualisierungsanforderung an einen Windows Server 2008-Domänencontroller 

mit Schreibberechtigung, der dann die Überprüfung und Registrierung der Einträge im 

Auftrag des RODCs oder ROGCs vornimmt. 

Darüber hinaus registrieren RODCs ausschließlich standortspezifische LDAP-, Kerberos- und 

CName-Einträge in DNS. Standardmäßig können nur Benutzer am gleichen Standort wie die 

RODC-Standortbenutzer diese Einträge ermitteln und verwenden. Dies kann erreicht werden, 

indem nur standortspezifische Einträge registriert werden. ROGCs registrieren außerdem die standortspezifischen 

GC-Einträge. Da RODCs nicht zum Ändern von Kennwörtern verwendet werden 

können, registrieren diese Server keine Kpasswd-Einträge. 

Ashish Sharma 

SDE II, US-Directory and Service Business 

DNS-Locatordienst 

Die Domänencontroller, auf denen Windows Server 2008 ausgeführt wird, registrieren alle oder einen 

Teil der zuvor beschriebenen Einträge in DNS. Diese Einträge sind für Clients von elementarer 

Bedeutung, z.B. wenn ein Client, der eine Betriebssystemversion ab Windows 2000 ausführt, versucht, 

eine Domänenanmeldung vorzunehmen. In den folgenden Schritten wird das Verfahren 

beschrieben, das diese Clients für die Anmeldung an der Domäne verwenden: 

1. Wenn ein Benutzer eine Anmeldung vornimmt, sendet der Clientcomputer einen Remoteprozeduraufruf 

(Remote Procedure Call, RPC) an den lokalen Netzwerkanmeldedienst und initiiert eine 

Anmeldesitzung. Als Teil des RPCs übermittelt der Client Informationen wie z.B. den Computer-, 

Domänen- und Standortnamen an den Netzwerkanmeldedienst. 

2. Der Netzwerkanmeldedienst nutzt den Domänenlocatordienst, um die DsGetDcName()-API abzurufen 

und übergibt einen der Flagparameterwerte, die in Tabelle 3.2 aufgeführt sind.


Tabelle 3.2 

Ein Teilsatz der DsGetDcName-Flagparameterwerte 

DsGetDcName-Flagwerte 

DS_PDC_REQUIRED 

DS_GC_SERVER_REQUIRED 

DS_PDC_REQUIRED 

DS_ONLY_LDAP_NEEDED 

Angeforderter DNS-Eintrag 

_ldap._tcp.pdc._msdcs.Domänenname 

_ldap._tcp.sitename._sites.gc._msdcs.Gesamtstruktur-Stammdomänenname 

_kdc._tcp.sitename._sites.dc._msdcs.Domänenname 

_ldap._tcp.Standortname._sites._msdcs.Domänenname 

Hinweis Die Funktion DsGetDcName umfasst fast immer auch den Parameter Standortname. Mit 

Ausnahme der DS_PDC_REQUIRED-Anforderung stellt der Client für alle Anforderungen mithilfe des 

Standortparameters eine Anfangsanforderung. Antwortet der DNS-Server nicht auf diese Anforderung, 

sendet der Client die gleiche Anforderung ohne den Standortparameter. Wenn beispielsweise die 

DS_KDC_REQUIRED-Anforderung nicht erfüllt wird, sendet der Client eine Anforderung für den Eintrag 

_kdc._tcp.dc._msdcs.Gesamtstruktur-Stammdomäne. Dies kann vorkommen, wenn der Clientstandort 

nicht konfiguriert oder nicht verfügbar ist. 

In Windows Server 2008 wird ein neues Flag mit dem Namen DS_TRY_NEXTCLOSEST_SITE eingeführt. 

Wenn dieses Flag festgelegt ist, versucht der Client, einen Domänencontroller zu ermitteln, der sich 

am gleichen Standort wie der Client befindet. Schlägt diese Ermittlung fehl, greift der Client auf die 

AD DS-Standortverknüpfungskonfiguration zurück, um einen Domänencontroller am nächstgelegenen 

Standort zu ermitteln. 

In Windows Server 2008 wird ein weiteres neues Flag eingeführt, das von der Funktion 

DSGetDCName verwendet werden kann. Dieses Flag mit dem Namen DS_IP_VERSION_AGONISTIC 

wird vom Client verwendet, um anzugeben, dass entweder eine IPv4- oder IPv6-Adresse benötigt wird. 

Wenn dieses Flag nicht gesetzt ist, gibt der Locator eine IPv4-Adresse zurück. 

Der Client übergibt unter Umständen auch den Parameter DomänenGUID anstelle des Domänennamens 

an DsGetDcName(). In diesem Fall fordert der Client den Eintrag _ldap._tcp.DomänenGUID.domains._ 

msdcs.Gesamtstrukturname an. Dies ist jedoch nur der Fall, wenn die Domäne umbenannt wurde. 

3. Der DNS-Server gibt die angeforderte Serverliste zurück. Anschließend sortiert der Client die 

Liste anhand der Priorität. Die Liste der Server mit gleicher Priorität wird basierend auf der 

Gewichtung zufällig angeordnet. Der Client verarbeitet anschließend nacheinander die Server auf 

der Liste. Er erhält die Adresse jedes Servers und sendet eine LDAP-Abfrage über den UDP- 

Port 389 an jede der Adressen in der Reihenfolge, in der sie zurückgegeben wurden. Nachdem 

jedes Paket gesendet wurde, wartet der Client auf Antwort. Erhält er keine Antwort, sendet er das 

Paket an den nächsten Domänencontroller. Der Client fährt mit diesem Verfahren solange fort, bis er 

eine gültige Antwort erhält, in der die angeforderten Dienste (z.B. Zeitdienst, DC mit Schreibberechtigung) 

angegeben werden oder das Paket an jeden Domänencontroller gesendet wurde. 

4. Erhält der Client eine Antwort des Domänencontrollers, überprüft der Client die Antwort, um 

sicherzustellen, das sie die angeforderten Informationen enthält. Sind die Informationen enthalten, 

beginnt der Client den Anmeldeprozess an dem Domänencontroller. 

5. Der Client fügt die Domänencontrollerinformationen in den Zwischenspeicher ein, sodass beim 

nächsten erforderlichen AD DS-Zugriff nicht das gesamte Ermittlungsverfahren erneut durchlaufen 

werden muss.


Direkt von der Quelle: Ermitteln der Verfügbarkeit eines Domänencontrollers durch einen 

Client 

Wenn ein Client einen Domänencontroller ermitteln möchte, nachdem er die IP-Adresse von DNS 

erhalten hat, wartet er unterschiedlich lange auf Antwort, basierend auf der Anzahl an Domänencontrollern, 

für die er bereits ein Ping ausgeführt hat. Die Wartezeit beträgt für die ersten fünf Domänencontroller 

0,4 Sekunden, und für die nächsten fünf Domänencontroller beträgt die Wartezeit 

0,2 Sekunden. Nachdem für zehn Domänencontroller ein Ping ausgeführt wurde, beträgt die Wartezeit 

des Clients für die verbleibenden Anforderungen 0,1 Sekunden. 

Der Algorithmus wurde entworfen, um nach Möglichkeit den Netzwerkdatenverkehr zu verringern 

und um außerdem sicherzustellen, dass der Client in angemessener Zeit eine Antwort erhält, wenn 

alle Abfragen fehlschlagen. Die Logik besteht darin, dass die ersten zehn Domänencontroller im 

Rahmen der längeren Wartezeit in der Lage sein müssten zu antworten, für den Fall, dass alle 

Domänencontroller aufgrund von starker Auslastung langsam arbeiten. Erst danach erhöht der 

Client die Abfragefrequenz, und das führt zu einer Zunahme des Netzwerkdatenverkehrs. 

Ashish Sharma 


Ermitteln der Standortzugehörigkeit durch den Client 

Die AD DS benötigen für den effektiven Betrieb standortspezifische Einträge, da ein erheblicher 

Anteil des ClientNetzwerkdatenverkehrs auf einen bestimmten Standort eingegrenzt werden kann. 

Beim Anmeldeverfahren des Clients wird beispielsweise immer versucht, eine Verbindung mit dem 

Domänencontroller am Standort des Clients herzustellen, bevor eine Verbindung mit anderen Standorten 

aufgebaut wird. Woher weiß jedoch der Client, an welchem Standort er sich befindet? 

Die Standortinformationen für die Gesamtstruktur werden in der Konfigurationsverzeichnispartition 

in den AD DS gespeichert, und diese Informationen werden auf alle Domänencontroller in der 

Gesamtstruktur repliziert. Die Konfigurationsinformationen umfassen auch eine Liste mit IP-Subnetzen, 

die mit einem bestimmten Standort verknüpft sind. Bei der ersten Clientanmeldung an den 

AD DS vergleicht der erste Domänencontroller, von dem eine Antwort erwartet wird, die IP- 

Adresse des Clients mit der IP-Adresse des Standorts. Die Antwort, die der Domänencontroller 

dem Client bereitstellt, umfasst unter anderem die Standortinformationen, die dann im Zwischenspeicher 

des Clients gespeichert werden. Alle zukünftigen Anmeldeversuche enthalten die Clientstandortinformationen. 

Wenn der Client zwischen Standorten verschoben wird (wenn z.B. ein tragbarer Computer mit 

einem Netzwerk in einer anderen Stadt verbunden wird), sendet der Client als Teil der Anmeldung 

noch immer die Standortinformationen. Der DNS-Server sendet als Antwort einen Eintrag eines 

Domänencontrollers, der sich am angeforderten Standort befindet. Ermittelt der Domänencontroller 

jedoch basierend auf der neuen IP-Adresse des Clients, dass sich der Client nicht am ursprünglichen 

Standort befindet, sendet er die neuen Standortinformationen an den Client. Der Client fügt 

diese Informationen dann in den Zwischenspeicher ein, und versucht, einen Domänencontroller am 

geeigneten Standort zu ermitteln. 

Befindet sich der Client nicht an einem in den AD DS definierten Standort, kann er keine standortspezifische 

Anforderung für Domänencontroller stellen.


Direkt von der Quelle: IPv6-Adressierung und Standortbestimmung 

Windows Server 2008 bietet vollständige Unterstützung für IPv6. Das bedeutet, dass der Domänencontroller 

bei der Ermittlung des Clientstandorts jede beliebige IP-Adresse des Clients verwenden 

kann. Diese Adressen umfassen die IPv4-Adresse, die globale IPv6-Adresse sowie die verbindungslokale 

IPv6-Adresse. 

Ermittelt der Domänencontroller die IP-Adresse eines Clients, versucht er, den entsprechenden 

Standort in der Konfiguration zu ermitteln. Standardmäßig nutzt der Domänencontroller nur eine 

der IP-Adressen, auch wenn sowohl die IPv4- als auch die IPv6-Adresse verwendet wird. In Vorgängerversionen 

von Windows Server 2008 gab der Domänencontroller dem Client keine Standortzuordnung 

zurück, wenn die bereitgestellte IP-Adresse keinem Standort zugeordnet werden konnte. 

In Windows Server 2008 nutzt der Domänencontroller sowohl die IPv4- als auch die IPv6-Adresse 

des Clients und gibt den entsprechenden Standort für diese Adressen zurück, wenn eine Zuordnung 

durchgeführt wurde. 

Dies hat Auswirkungen auf die AD DS-Standortkonfiguration. In Vorgängerversionen der AD DS 

mussten einem Standort nur die entsprechenden IPv4-Subnetze zugewiesen werden. In Windows 

Server 2008 sollten Sie sowohl die IPv4- als auch die globale IPv6-Subnetzadresse für einen 

bestimmten Standort konfigurieren. 

Ashish Sharma 


Nachdem ein Clientcomputer die Authentifizierung durchgeführt hat, speichert er standardmäßig für 

15 Minuten die Domänencontrollerinformationen im Zwischenspeicher. Wenn der Clientcomputer die 

Authentifizierung zu einem Zeitpunkt durchgeführt hat, zu dem kein Domänencontroller an seinem 

Standort verfügbar war, wurde die Authentifizierung durch einen Domänencontroller an einem anderen 

Standort durchgeführt. Dies bedeutet, dass der Clientcomputer während dieser 15 Minuten alle 

AD DS-Lookups über den Domänencontroller am anderen Standort durchführt. Um Änderungen an 

diesem Standardwert vorzunehmen, erstellen Sie einen REG_DWORD-Eintrag mit dem Namen Close- 

SiteTimeout im Schlüssel HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Sie können 

für diesen Eintrag einen Wert zwischen 1 Minute und 49,7 Tagen festlegen. Gehen Sie beim 

Ändern des Werts für diesen Eintrag mit Vorsicht vor. Wenn Sie einen zu hohen Wert festlegen, nutzt 

der Client einen Domänencontroller an einem anderen Standort unter Umständen für einen zu langen 

Zeitraum. Legen Sie den Wert jedoch zu niedrig fest, führen die wiederholten Versuche zum Ermitteln 

eines Domänencontrollers zu übermäßigem Netzwerkdatenverkehr. 

Automatische Standortabdeckung 

In den AD DS können Standorte erstellt werden, ohne dass dafür die Installation eines Domänencontrollers 

am Standort erforderlich ist. Sie können auch einen Standort erstellen, der Domänencontroller 

für eine Domäne umfasst, und Clientcomputer von einer anderen Domäne in der Gesamtstruktur müssen 

sich an diesem Standort anmelden. Mit anderen Worten: Clientcomputer an dem Standort müssen 

die Authentifizierung an einem Domänencontroller an einem anderen Standort durchführen. Um 

sicherzustellen, dass diese Clients trotzdem den am besten verfügbaren Domänencontroller wählen, 

wurden die AD DS so entwickelt, dass die Domänencontroller automatisch berechnen, welche Domänencontroller 

die SVR-Einträge für Standorte registrieren, die nicht über Domänencontroller verfügen. 

Dieses Feature wird als automatische Standortabdeckung bezeichnet.


Hinweis Bei der automatischen Standortabdeckung handelt es sich um einen dynamischen Prozess. Ist 

ein Domänencontroller an einem bestimmten Standort nicht verfügbar, übernehmen andere Domänencontroller 

automatisch die Konfiguration der Standortabdeckungseinträge für den Standort. 

Die Domänencontroller nutzen die Standorte und die Standortverknüpfungsinformationen für die 

Ermittlung des Domänencontrollers, der die Abdeckung für einen Standort übernimmt, der nicht 

über Domänencontroller verfügt. Alle Domänencontroller kennen alle Standorte, Standortverknüpfungen 

und Domänencontroller, da diese Informationen in der Konfigurationspartition in den AD DS 

gespeichert sind. Alle Domänencontroller erstellen zunächst eine Liste mit Zielstandorten, d.h. der 

Standorte, die nicht über einen Domänencontroller in der Domäne des lokalen Domänencontrollers 

verfügen. Dann erstellen die Domänencontroller eine Liste mit Standorten, die die automatische 

Standortabdeckung bereitstellen könnten. Diese Liste umfasst alle Standorte, die über Domänencontroller 

in der angegebenen Domäne verfügen. 

Standardmäßig wird die Standortabdeckung von den Domänencontrollern übernommen, die sich am 

Standort mit den geringsten Standortverknüpfungskosten zum Zielstandort befinden. Sind über die 

kostengünstigsten Standortverknüpfungen mehrere Standorte verbunden, wird die Standortabdeckung 

über den Standort bereitgestellt, der über die größte Anzahl an Domänencontrollern verfügt. Wenn 

nach Anwendung dieser Kriterien immer noch mehrere Standorte für die Bereitstellung der Standortabdeckung 

verfügbar sind, wird die Standortauswahl in alphabetischer Reihenfolge vorgenommen. 

Die Domänencontroller am ausgewählten Standort registrieren dann die standortspezifischen SRV- 

Einträge für die Domänencontroller für diese Domäne am Zielstandort. 

Hinweis Wenn Sie einen RODC an einem eigenen Standort bereitstellen, übernehmen Windows Server 

2003-Domänencontroller die automatische Standortabdeckung für den Standort. Der Grund ist, dass Windows 

Server 2003-Domänencontroller RODCs nicht in ihre automatische Standortberechnung einbeziehen. 

In Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, werden ausführliche Informationen 

bereitgestellt, wie Sie dieses Problem umgehen können. 

Verwalten der DNS-Registrierung mithilfe von Gruppenrichtlinien 

Sie können mithilfe von Gruppenrichtlinien festlegen, auf welche Weise AD DS-Domänencontroller 

SRV-Einträge in DNS registrieren. Um diese Einstellungen auf alle Domänencontroller anzuwenden, 

können Sie Änderungen am GPO Default Domain Controllers Policy vornehmen. Wenn 

Sie unterschiedliche Richtlinien auf Domänencontroller anwenden möchten, müssen Sie zunächst 

ein neues Gruppenrichtlinienobjekt erstellen und anschließend einen Filter zum Anwenden der 

Gruppenrichtlinie auf bestimmte Domänencontroller verwenden. In der folgenden Tabelle werden 

die verfügbaren Einstellungen aufgeführt. Diese Einstellungen sind im Ordner Domänencontrollerlocator-DNS-Einträge 

unter Administrative Vorlagen\System\Netzwerkanmeldung verfügbar. 

Gruppenrichtlinieneinstellung 

Zurückgegebener Domänencontroller- 

Adresstyp 

Dynamische Registrierung der Domänencontrollerlocator-DNS-Einträge 

Beschreibung 

Legt fest, ob der Domänencontrollerlocator nur IPv4-Adressen oder IPv4- und 

IPv6-Adressen zurückgibt. Standardmäßig werden beide Adresstypen zurückgegeben, 

wenn diese Einstellung deaktiviert wird, werden nur IPv4-Adressen 

zurückgegeben. 

Legt fest, ob die dynamische Registrierung der DNS-Ressourceneinträge aktiviert 

ist. Die dynamische Registrierung dieser DNS-Einträge wird durch den 

Netzwerkanmeldedienst übernommen.


Gruppenrichtlinieneinstellung 

Domänencontrollerlocator-Einträge 

nicht durch Domänencontroller registrieren 

Aktualisierungsintervall der Domänencontrollerlocator-DNS-Einträge 

Gewichtung, die in DC-Locator-DNS- 

SRV-Einträgen festgelegt wird 

Priorität, die in DC-Locator-DNS-SRV- 

Einträgen festgelegt wird 

Festgelegte Gültigkeitsdauer in den 

Domänencontrollerlocator-DNS- 

Einträgen 

Automatisierte Standortabdeckung 

durch DC-Locator-DNS-SRV-Einträge 

Standorte, die durch DC-Locator-DNS- 

SRV-Einträge abgedeckt werden 

Standorte, die durch GC-Locator-DNS- 

SRV-Einträge abgedeckt werden 

Standorte, die durch Anwendungsver- 

zeichnis-Partitionslocator-DNS-SRV- 

Einträge abgedeckt werden 

Standort der Domänencontroller, auf 

denen sich eine Domäne mit einem 

DNS-Namen mit einer einzigen Bezeichnung 

befindet 

Neuermittlungsintervall erzwingen 

Eingehende Mailslotnachrichten nicht 

verarbeiten, die einen Domänencontrollerspeicherort 

verwendet werden, 

der auf NetBIOS-Domänennamen 

basiert 

Am nächstgelegenen Standort suchen 

Beschreibung 

Legt fest, welche Domänencontrollerlocator-DNS-Einträge nicht vom Netzwerkanmeldedienst 

registriert werden. Sie können für bestimmte Eintragstypen festlegen, 

dass diese nicht von Domänencontrollern registriert werden. 

Legt das Aktualisierungsintervall der DNS-Ressourceneinträge für Domänencontroller 

fest, auf die diese Einstellung angewendet wird. 

Legt das Feld Gewichtung in den SRV-Ressourceneinträgen fest, die von den 

Domänencontrollern registriert werden, auf die diese Einstellung angewendet 

wird. 

Legt das Feld Priorität in den SVR-Ressourceneinträgen fest, die von den Domänencontrollern 

registriert werden, auf die diese Einstellung angewendet wird. 

Legt den Wert für das Feld Gültigkeitsdauerfeld (TTL) in SRV-Ressourceneinträgen 

fest, die durch den Netzwerkanmeldedienst registriert wurden. 

Legt fest, ob Domänencontroller standortspezifische Domänencontrollerlocator- 

SRV-Einträge für die nächstgelegenen Standorte dynamisch registrieren, an 

denen kein Domänencontroller für dieselbe Domäne (oder kein globaler Katalog 

für dieselbe Gesamtstruktur) vorhanden ist. 

Legt die Standorte fest, für die die Domänencontroller die standortspezifischen 

SRV-Einträge registrieren, wenn keine Domänencontroller für die Domäne am 

Standort verfügbar sind. 

Legt die Standorte fest, für die die globalen Katalogserver die Registrierung 

durchführen sollen, wenn kein globaler Katalogserver für die Gesamtstruktur 

am Standort verfügbar ist. 

Legt die Standorte fest, für die die Domänencontroller, die das Anwendungspartitionsverzeichnis 

hosten, die Registrierung der standortspezifischen SRV-Einträge 

übernehmen. 

Legt fest, ob die Computer, auf die diese Einstellung angewendet wird, bei Einzelbezeichner-Domänennamen 

die Namensauflösung per DNS versuchen. 

Legt einen Zeitrahmen fest, nach dem Clients zur Neuermittlung von Domänencontrollern 

gezwungen werden. Diese Einstellung ist nützlich, wenn die Domänenconterollerkonfiguration 

in einem Netzwerk häufig geändert wird. 

Standardmäßig werden die Clients alle zwölf Stunden zur Neuermittlung von 

Domänencontrollern gezwungen. 

Legt fest, ob der Domänencontroller auf Mailslotantworten reagiert, um weitere 

Informationen zum Domänencontroller zu erhalten. Mailslotanforderungen werden 

nur von Windows NT- oder älteren Clients verwendet, die für die Ermittlung 

von und Anmeldung an Domänencontrollern NetBIOS-Namen verwenden. 

Legt fest, ob sich Clientcomputer automatisch an den nächstgelegenen 

Standort wenden, wenn ein Domänencontroller nicht verfügbar ist. Standardmäßig 

fordern Clients mithilfe des Domänencontrollerlocator-Aufrufs 

DS_TRY_NEXTCLOSEST_SITE einen Domänencontroller am nächstgelegenen 

Standort an.


AD DS-integrierte Zonen 

Neben der Verwendung von DNS für die Ermittlung von Domänencontrollern kann Windows Server 

2008 außerdem in DNS integriert werden, indem die DNS-Zoneninformationen im AD DS-Datenspeicher 

gespeichert werden. 

Vorteile der Nutzung AD DS-integrierter Zonen 

AD DS-integrierte Zonen bieten zahlreiche Vorteile: 

• Das Verfahren zum Übertragen von Zonen wird durch die AD DS-Replikation ersetzt. Da die Zoneninformationen 

in den AD DS gespeichert werden, werden die Daten über das normale AD DS- 

Replikationsverfahren repliziert. Das bedeutet, dass die Replikation auf Attributebene vorgenommen 

wird, sodass nur die Änderungen an den Zoneninformationen repliziert werden. Außerdem 

kann der Replikationsdatenverkehr zwischen Standorten stark komprimiert und so zusätzliche 

Bandbreite eingespart werden. Durch die Verwendung AD DS-integrierter Zonen können Sie 

außerdem Anwendungspartitionen für die feine Abstufung der Replikation von DNS-Informationen 

verwenden. Darüber hinaus werden beim Hinzufügen neuer Domänencontroller zur Domäne 

die DNS-Informationen ohne zusätzliche Konfiguration automatisch auf den Domänencontroller 

repliziert. 

• Integrierte Zonen ermöglichen eine Multimaster-DNS-Serverkonfiguration. Ohne die AD DS kann 

DNS nur einen primären Namenserver für jede DNS-Zone unterstützen. Das bedeutet, dass alle 

Änderungen an den Zoneninformationen auf dem primären Namenserver vorgenommen und 

anschließend auf den sekundären Namenserver übertragen werden müssen. Mit AD DS-integrierten 

Zonen verfügt jeder DNS-Server über eine beschreibbare Kopie der Domäneninformationen, 

sodass Änderungen an den Zoneninformationen an jeder beliebigen Stelle in der 

Organisation vorgenommen werden können. Die Informationen werden dann auf alle weiteren 

DNS-Server repliziert. 

• Integrierte Zonen ermöglichen sichere Updates. Wenn eine Zone als AD DS-integrierte Zone konfiguriert 

wird, können Sie für die Zone die ausschließliche Verwendung von sicheren Updates 

konfigurieren. Dadurch können Sie besser steuern, welche Benutzer und Computer die Ressourceneinträge 

in den AD DS aktualisieren können. 

• Integrierte Zonen bieten zusätzliche Sicherheit. Da die DNS-Zonendaten in den AD DS gespeichert 

werden, können Sie zum Schutz des dnsZone-Objektcontainers im Verzeichnis Zugriffsteuerungslisten 

(Access Control Lists, ACLs) verwenden. Dieses Feature ermöglicht Ihnen, den Zugriff auf 

die Zone oder einen bestimmten Ressourceneintrag in der Zone sehr präzise zu steuern. 

Einige Organisationen entscheiden sich nicht sofort für die Verwendung AD DS-integrierter Zonen, 

da dafür die Installation von DNS auf einem Windows Server 2008-Domänencontroller erforderlich 

ist. Dies kann eine zusätzliche Last für den Domänencontroller bedeuten. Wenn alle Clientcomputer 

in einer Organisation zur Registrierung ihrer Hosteinträge in DNS konfiguriert wurden, besteht ein 

weiteres Problem darin, dass die AD DS-Datenbank unter Umständen Tausende zusätzliche Einträge 

umfasst.

Standardanwendungspartitionen für DNS 

AD DS-integrierte Zonen 73 

Hinweis Sie können AD DS-integrierte Zonen mit sekundären Zonen kombinieren. Sie könnten beispielsweise 

über drei Domänencontroller an einem zentralen Speicherort sowie verschiedene Remotebüros verfügen, 

für die kein Domänencontroller zur Verfügung steht. Bei der Installation eines DNS-Servers in einem 

Remotebüro können Sie die DNS-Serverrolle auf einem Mitgliedsserver installieren, auf dem Windows 

Server 2008 ausgeführt wird, und anschließend auf dem DNS-Server eine sekundäre Zone konfigurieren. 

Der sekundäre Server akzeptiert dann Zonenübertragungen von der AD DS-integrierten Zone. 

Wenn Sie DNS beim Heraufstufen des ersten Servers in der Gesamtstruktur zum Domänencontroller 

installieren, werden in den AD DS zwei neue Anwendungsverzeichnispartitionen erstellt. Bei diesen 

beiden Partitionen handelt es sich um die Partition DomainDnsZones und ForestDnsZones. DNS- 

Zoneninformationen werden anschließend in diesen Verzeichnispartitionen und nicht in einer Textdatei 

auf der Festplatte des DNS-Servers gespeichert. 

Jede dieser Partitionen umfasst unterschiedliche Informationen und weist unterschiedliche Replikationskonfigurationen 

auf. Die Partition DomainDNSZones umfasst alle Domänencontrollereinträge, 

die für die Ermittlung von Domänencontrollerdiensten innerhalb der Domäne erforderlich sind. Alle 

zuvor beschriebenen Ressourceneinträge, mit Ausnahme der Ressourceneinträge, die den Wert 

_msdcs enthalten, werden in der Partition DomainDnsZones gespeichert. Die Partition DomainDns- 

Zones wird auf alle DNS-Server repliziert, die auf Domänencontrollern in einer Domäne ausgeführt 

werden. 

Die Partition ForestDnsZones wird auf alle DNS-Server repliziert, die auf Domänencontrollern in der 

Gesamtstruktur ausgeführt werden. Die Partition ForestDnsZones umfasst die Informationen, die von 

Domänencontrollern und Clients für die Ermittlung von Domänencontrollerdiensten in anderen 

Domänen in der Gesamtstruktur benötigt werden. Die Partition ForestDnsZones umfasst beispielsweise 

eine Domänenteilzone, in der alle GUIDs der Domäne und die Domänencontroller jeder Domäne 

aufgeführt werden. Außerdem werden in der Partition ForestDnsZones alle Domänencontroller in 

der Gesamtstruktur anhand ihrer GUID sowie alle globalen Katalogserver in der Gesamtstruktur aufgeführt. 

Die Subzone _msdcs wird in der Partition ForestDnsZones gespeichert. 

Hinweis Die DNS-Anwendungsverzeichnispartitionen werden nur erstellt, wenn Sie beim Heraufstufen 

des ersten Domänencontrollers in der Domäne oder Gesamtstruktur DNS installieren. Wenn Sie die Vorteile 

der DNS-Anwendungsverzeichnispartitionen nach dem Aktualisieren des Domänencontrollers nutzen möchten, 

müssen Sie die Partition manuell erstellen, bevor Sie sie nutzen können. Um die Partitionen zu erstellen, 

können Sie den DNS-Manager oder das Befehlszeilenprogramm DNSCmd verwenden. Wenn Sie das 

DNS-Verwaltungstool verwenden, klicken Sie mit der rechten Maustaste auf den DNS-Servernamen, und 

wählen Sie Standardanwendungs-Verzeichnispartitionen erstellen. Wenn Sie das Tool DNSCmd verwenden, 

öffnen Sie eine Befehlszeile, und geben Sie den Befehl dnscmd DNSServername /CreateBuiltin- 

DirectoryPartitions /forest ein. Dadurch wird die Partition ForestDnsZones erstellt. Um die Partition 

DomainDnsZones zu erstellen, verwenden Sie als letzten Parameter im Befehl "/domain" anstelle des Parameters 

"/forest". Sie können die Partition DomainDNSZones für alle Domänen in der Gesamtstruktur erstellen, 

indem Sie den Befehl mit dem Parameter /Alldomains ausführen. Da durch diesen Befehl eine Änderung 

an der Verzeichnispartitionskonfiguration in den AD DS vorgenommen wird, müssen Sie als Mitglied der 

Gruppe Organisations-Admins angemeldet sein. 

Die DNS-Anwendungspartitionen können mithilfe des DNS-Managers und mithilfe von Tools wie 

beispielsweise DNSCmd, ADSIEdit.msc oder Ldp.exe angezeigt werden.


Im DNS-Manager (dargestellt in Abbildung 3.2) werden die Informationen zur Partition ForestDns- 

Zones in der delegierten Zone _msdcs.Gesamtstrukturname aufgeführt. Die Partition DomainDns- 

Zones wird in der Teilzone DomainDnsZone der Zone Domänenname aufgeführt. In ADSIEdit.msc 

können die Anwendungspartitionen angezeigt werden, indem eine Verbindung mit der Partition 

dc=domaindnszones,dc=Domänenname oder der Partition dc=forestdnszones,dc=Gesamtstrukturname 

(dargestellt in Abbildung 3.3) hergestellt wird. 

Abbildung 3.2 

Die DNS-Anwendungsverzeichnispartitionen in der DNS-Verwaltungskonsole 

Abbildung 3.3 

Die DNS-Anwendungsverzeichnispartitionen in Adsiedit.msc

Verwalten AD DS-integrierter Zonen 


Auf der DVD Sie können das Windows PowerShell-Skript ListAppPartitions.ps1 auf der Begleit-CD nutzen, 

um die in Ihrer Gesamtstruktur bereitgestellten Anwendungspartitionen aufzulisten und anzuzeigen, welche 

Domänencontroller über ein Replikat dieser Partitionen verfügen. Bei Ausführung von Windows PowerShell auf 

einem Computer unter Windows Server 2008 muss die PowerShell-Skriptausführungsrichtlinie konfiguriert 

werden, um durch die Ausführung des Befehls Set-ExecutionPolicy RemoteSigned unsignierte Skripts zuzulassen. 

Ferner muss bei der Ausführung eines Windows PowerShell-Skripts der vollständige Pfad angegeben 

werden. 

Bei der Implementierung von AD DS-integrierten Zonen müssen Sie unter Umständen zusätzliche 

DNS-Verwaltungsaufgaben durchführen, die bei der Verwendung der Standard-DNS-Zonen nicht 

erforderlich sind. Diese Aufgaben umfassen die Konfiguration der AD DS-Anwendungsverzeichnispartitionen, 

die die DNS-Zoneninformationen enthalten, die Verwaltung und Sicherung von dynamischen 

DNSs sowie die Konfiguration der Alterungseinstellungen von Einträgen und der Aufräumvorgänge 

von Einträgen. 

Konfigurieren von DNS-Anwendungspartitionen 

Wenn Sie DNS während der Konfiguration des ersten Domänencontrollers in einer Domäne installieren, 

werden die DNS-Zoneninformationen standardmäßig in den Anwendungspartitionen Domain- 

DnsZones und ForestDnsZones gespeichert. Sie können jedoch Änderungen an der Anwendungspartition 

vornehmen, die für diese Zonen verwendet wird, oder Sie können DNS-Zoneninformationen in 

den AD DS beim Erstellen neuer Zonen auf dem Domänencontroller erstellen. Sie können beim 

Erstellen einer neuen Zone den Speicherort der DNS-Informationen auswählen (siehe Abbildung 3.4), 

oder Sie verwenden dafür das Zoneneigenschaftendialogfeld des DNS-Verwaltungstools. Folgende 

vier Möglichkeiten bestehen zum Festlegen des Speicherorts für DNS-Informationen: 

Abbildung 3.4 

Konfigurieren des Replikationsbereichs für DNS-Zonen 

• Auf allen DNS-Servern in dieser Gesamtstruktur: Gesamtstrukturname Die Informationen werden in 

der Partition ForestDnsZones gespeichert, und von dort aus werden Sie auf alle DNS-Server repliziert, 

die auf Domänencontrollern in der Gesamtstruktur ausgeführt werden.


Verwenden Sie diese Zone nur, wenn Benutzer in mehreren Domänen in der Gesamtstruktur 

Zugriff auf diese Zoneninformationen benötigen. 

• Auf allen DNS-Servern in dieser Domäne: Domänenname Die Informationen werden in der Partition 

DomainDnsZones gespeichert, und von dort aus werden Sie auf alle DNS-Server repliziert, die 

auf Domänencontrollern in der Domäne ausgeführt werden. Verwenden Sie diese Zone, wenn nur 

Benutzer in einer bestimmten Zone Zugriff auf die Zoneninformationen benötigen, oder wenn Sie 

anderen DNS-Servern über Delegierung oder Weiterleitung die Ermittlung dieser Informationen 

ermöglichen möchten. 

• Auf allen Domänencontrollern in dieser Domäne (Windows 2000-Kompatibilität): Domänenname Die 

Informationen werden in der Domänenverzeichnispartition gespeichert, und von dort aus werden 

sie auf alle Domänencontroller in der Domäne repliziert. Der Unterschied zwischen dieser Option 

und dem Speichern der Informationen in der Partition DomainDnsZones besteht darin, dass alle 

Domänencontroller die Informationen erhalten, während die Partition DomainDnsZones ausschließlich 

auf Domänencontroller repliziert wird, bei denen es sich ebenfalls um DNS-Server 

handelt. Da Windows 2000 Server Active Directory keine Anwendungsverzeichnispartitionen 

unterstützt, müssen Sie diese Option verwenden, wenn Sie AD DS-integrierte Zonen mit Windows 

Server-Domänencontrollern verwenden möchten. 

• Auf allen Domänencontrollern, die im Bereich dieser Verzeichnispartition angegeben werden Diese 

Option ist nur verfügbar, wenn Sie eine zusätzliche Anwendungsverzeichnispartition mit einer 

eigenen Replikationskonfiguration erstellen. Die DNS-Informationen werden auf alle Domänencontroller 

repliziert, die über ein Replikat dieser Partition verfügen. 

In der Regel sollten Sie keine Änderungen an der Standardkonfiguration der AD DS-integrierten 

Zonen vornehmen. Wenn Sie über mehrere Domänencontroller in einer Domäne verfügen, es sich 

bei einigen davon allerdings um DNS-Server handelt, wird durch die Verwendung der Partition 

DomainDnsZones die Anzahl an Replikationen verringert, da Domänencontroller, die keine DNS- 

Server sind, keine Kopie der Zone erhalten. Die Partition ForestDnsZones wird in der gesamten 

Gesamtstruktur repliziert, sodass die für die Ermittlung der Domänencontroller in der Gesamtstruktur 

erforderlichen DNS-Informationen auf alle DNS-Server in der Gesamtstruktur repliziert werden. 

Verwalten von dynamischem DNS 

Bisher bestand ein Problem bei der Arbeit mit DNS darin, dass alle Zoneninformationen manuell auf 

dem DNS-Server eingegeben werden mussten. Wie jedoch im RFC 2136 beschrieben, können DNS- 

Server nun so konfiguriert werden, dass sie automatische Aktualisierungen der Ressourceneinträge in 

den Zonen akzeptieren. Diese Option wird als dynamisches DNS (DDNS) bezeichnet. 

Windows Server 2008-DNS-Server unterstützen dynamisches DNS. Standardmäßig führen alle 

Clients ab Windows 2000 eine automatische Aktualisierung ihrer Ressourceneinträge in DNS durch. 

Windows Server 2008-DNS-Server akzeptieren darüber hinaus auch die dynamische Eintragsregistrierung 

von DHCP-Servern (Dynamic Host Configuration Protocol). Der Windows Server 2008- 

DHCP-Server kann so konfiguriert werden, dass automatische Aktualisierungen der DNS-Einträge 

von allen Clients akzeptiert werden, einschließlich Microsoft Windows 95-, Microsoft Windows 98-, 

Microsoft Windows Me- oder Microsoft Windows NT-Clients. 

Für DDNS gelten jedoch Beschränkungen hinsichtlich der Sicherheit. Ohne die Steuerung der Personen, 

die Aktualisierungen der DNS-Ressourceneinträge vornehmen können, haben alle Zugriffsberechtigten 

in Ihrem Netzwerk die Möglichkeit einen Ressourceneintrag in Ihrer DNS-Zone zu erstellen 

und diese Einträge zur Umleitung des Netzwerkdatenverkehrs zu verwenden. Um dieses Problem 

zu umgehen, stellt das Windows Server 2008-DNS sichere Updates bereit.


Sichere Updates sind nur in AD DS-integrierten Zonen verfügbar. Mit sicheren Updates können Sie 

steuern, wer zum Registrieren und Aktualisieren der DNS-Einträge berechtigt ist. Standardmäßig sind 

die Mitglieder der Gruppe Authentifizierte Benutzer zum Aktualisieren ihrer Einträge in DNS berechtigt. 

Das bedeutet, dass Computer, die Domänenmitglieder sind, zum Aktualisieren ihrer eigenen 

DNS-Einträge berechtigt sind. Sie können dies jedoch ändern, indem Sie die Zugriffssteuerungsliste 

für die DNS-Zone bearbeiten. 

Weitere Informationen Weitere Informationen zum Konfigurieren von dynamischem DNS finden Sie im 

Artikel „DNS Technical Reference“. 

Alterungseinstellungen und Aufräumvorgänge 

In großen Unternehmensumgebungen besteht ein Problem mit der Verwendung der AD DS-integrierten 

Zonen darin, Clientcomputern das Aktualisieren ihrer Ressourceneinträge in DNS zu ermöglichen. 

Werden diese Aktualisierungen vorgenommen, liegen in DNS unter Umständen Tausende 

Einträge vor, wodurch die Größe der Datenbankdatei stark ansteigt. Wenn Clientcomputer heruntergefahren 

werden, während weiterhin eine Verbindung mit dem Netzwerk besteht, geben die Clientcomputer 

ihre Ressourceneinträge in den AD DS frei. Wenn jedoch die Clientverbindung mit dem Netzwerk 

nicht ordnungsgemäß getrennt wird, werden die zugehörigen Hosteinträge (A) unter Umständen 

nicht gelöscht. Um diese Ressourceneinträge (Resource Records, RRs) in den AD DS-Zonen zu bereinigen, 

können Sie Alterungseinstellungen und Aufräumvorgänge konfigurieren. 

Mit DDNS erhält jede zu DNS hinzugefügte Ressource einen Zeitstempel basierend auf den Datumsund 

Uhrzeiteinstellungen des Servercomputers. Ressourceneinträge, die in DNS manuell hinzugefügt 

wurden, erhalten den Zeitstempelwert 0 um anzugeben, dass die Einträge nicht durch die Alterungseinstellungen 

und Aufräumvorgänge gelöscht werden sollen. 

Standardmäßig sind Alterungseinstellungen und Aufräumvorgänge für Windows Server 2008-DNS- 

Server und -Zonen nicht aktiviert. Nach dem Aktivieren der Alterungseinstellungen und Aufräumvorgänge 

überwacht der DNS-Server die Zeit aller Einträge seit der letzten Aktualisierung des Eintrags. 

Wenn die seit der letzten Aktualisierung vergangene Zeit die konfigurierte Altersgrenze überschreitet, 

wird der Eintrag über einen Aufräumvorgang aus DNS entfernt. 

Laden von Zonen im Hintergrund 

Wie bereits erwähnt besteht ein mögliches Problem bei der Verwendung AD DS-integrierter Zonen 

und der Aktivierung von dynamischem DNS darin, dass Sie unter Umständen über Tausende Clientcomputer 

verfügen, die ihre Hosteinträge in DNS registrieren. Beim Starten des AD DS-Domänencontrollers 

oder einem Neustart des DNS-Dienstes müssen alle DNS-Zoneninformationen aus dem 

AD DS-Datenspeicher gelesen werden. In besonders großen Organisationen kann das Laden des 

AD DS-Datenspeichers beim Neustart des DNS-Servers eine Stunde oder mehr Zeit in Anspruch nehmen. 

Das führt dazu, dass der DNS-Server während der gesamten, zum Laden der AD DS-basierten 

Zonen erforderlichen Zeit für Dienstclientanforderungen effektiv nicht zur Verfügung steht. 

In Windows Server 2008 wird ein neues Feature zum Laden von Zonen im Hintergrund bezeichnet, 

mit dem dieses Problem umgangen wird. Mit diesem Feature kann ein DNS-Server bereits mit der 

Verarbeitung von DNS-Clientanforderungen beginnen, während im Hintergrund die Zonendaten aus 

den AD DS geladen werden. Der DNS-Server führt beim Starten folgende Vorgänge aus: 

• Auflisten aller zu ladenden Zonen. 

• Laden der Stammhinweise aus Dateien oder dem AD DS-Datenspeicher.


• Laden aller Standard-DNS-Zonen, die nicht in den AD DS, sondern in Textdateien gespeichert 

sind. 

• Beginn der Verarbeitung von DNS-Abfragen und Remoteprozeduraufrufen (Remote Procedure 

Calls, RPCs). Wenn der Server eine Abfrage für eine noch nicht geladene Zone erhält, liest der 

DNS-Server die Daten aus dem Knoten der AD DS und antwortet auf die Clientabfrage. 

• Erstellen der Threads zum Laden der in den AD DS gespeicherten Zonen. 

DNS und schreibgeschützte Domänencontroller 

Wie bereits erwähnt, stellt Windows Server 2008 schreibgeschützte Domänencontroller (Read-Only 

Domain Controllers, RODCs) bereit. Zur Bereitstellung dieser RODCs unterstützt Windows Server 

2008 einen neuen DNS-Zonentyp – die schreibgeschützte primäre Zone. Beim Konfigurieren eines 

RODCs als DNS-Server repliziert der Domänencontroller eine vollständige schreibgeschützte Kopie 

aller von DNS verwendeten Anwendungsverzeichnispartitionen, die Domänenpartition sowie die Partitionen 

ForestDNSZones und DomainDNSZones eingeschlossen. Dadurch wird sichergestellt, dass 

der DNS-Server, der auf dem RODC ausgeführt wird, über eine schreibgeschützte Kopie aller in diesen 

Verzeichnispartitionen gespeicherten DNS-Zonen verfügt. 

Der RODC-DNS-Server antwortet auf Clientabfragen wie jeder andere DNS-Server. Da die AD DSintegrierten 

DNS-Zonen auf dem RODC jedoch schreibgeschützt sind, können keine Änderungen an 

den Zonen auf dem RODC vorgenommen werden. Der Administrator eines schreibgeschützten 

Domänencontrollers kann den Inhalt einer primären schreibgeschützten Zone anzeigen, er kann 

jedoch keine Änderungen an der lokalen Kopie der Zone vornehmen. Änderungen können nur auf 

einem Domänencontroller vorgenommen, der über eine beschreibbare AD DS-Kopie verfügt. Wenn 

Clientcomputer mithilfe von DDNS ihre Hosteinträge auf dem DNS-Server registrieren möchten, 

wird der Clientcomputer an einen DNS-Server umgeleitet, der über eine beschreibbare Kopie der 

DNS-Zone verfügt. 

Hinweis Wie alle anderen Domänencontroller können auch RODCs als DNS-Server konfiguriert werden. 

Wird ein RODC als DNS-Server konfiguriert, unterstützt er bei der Verwendung AD DS-integrierter Zonen 

nur primäre schreibgeschützte Zonen. Sie können den RODC als DNS-Server mit primären oder sekundären 

Standardzonen konfigurieren. Beim Implementieren einer primären Standardzone auf dem RODC ist 

diese nicht schreibgeschützt. 

Integrieren von DNS-Namespaces in AD DS-Domänen 

Bei allen AD DS-Domänennamen muss es sich um DNS-Namen handeln, und DNS ist für die ordnungsgemäße 

Funktionsfähigkeit der AD DS erforderlich. In einer Umgebung mit einer einzelnen 

Domäne ist die Integration der DNS-Namespaces in den AD DS-Namen sehr einfach, Sie benötigen 

lediglich einen DNS-Server, der für die DNS-Zone autorisierend ist, die dem AD DS-Domänennamen 

entspricht. In einer Organisation mit mehreren Domänen und unter Umständen mehreren Domänenstrukturen 

in der Gesamtstruktur ist die Integration der DNS-Namespaces in den AD DS-Domänennamen 

jedoch komplizierter. 

Wichtig Die ordnungsgemäße Integration des DNS-Namespaces in den AD DS-Entwurf ist ebenso wichtig 

wie die Registrierung aller SRV-Einträge der Domänencontroller in DNS. Domänencontroller in unterschiedlichen 

Domänen in der Gesamtstruktur müssen sich gegenseitig in DNS ermitteln können, um eine gegenseitige 

Replikationen durchführen zu können.

DNS-Delegierung 

Integrieren von DNS-Namespaces in AD DS-Domänen 79 

Hinweis In diesem Kapitel werden die Optionen zum Integrieren von DNS-Namespaces in AD DS-Domänen 

in einer einzelnen Gesamtstruktur beschrieben. Entwurfsprobleme, die bei der Integration der AD DS- 

Gesamtstruktur in DNS-Namespaces außerhalb der AD DS auftreten können, werden in Kapitel 5 erläutert. 

DNS nutzt einen hierarchischen Namespace und ein verteiltes Datenbankmodell. Dadurch können 

DNS-Clients jeden Namen im DNS-Namespace auflösen, ohne dass ein DNS-Server alle DNS-Zonen 

im Namespace hosten muss. Wenn beispielsweise ein Client eine Verbindung mit einem DNS-Server 

herstellt, der für die Domäne erster Ebene .com autorisierend ist, und einen Server in der Domäne 

Adatum.com anfordert, muss der autorisierende .com-Server eine Möglichkeit haben, die autorisierenden 

Namenserver für die Domäne Adatum.com zu ermitteln. Diese Ermittlung kann mithilfe 

von Delegierungseinträgen vorgenommen werden. 

Bei einem Delegierungseintrag handelt es sich um einen Zeiger auf eine untergeordnete Domäne, 

die den Namen des Servers für die untergeordnete Domäne kennzeichnet. Wie beispielsweise in 

Abbildung 3.5 dargestellt, handelt es sich bei DNS1.Adatum.com um den autorisierenden Namenserver 

der Domäne Adatum.com. Bei DNS2 und DNS3 handelt es sich um autorisierenden Namenserver 

der Domäne NA.Adatum.com. DNS1 wird als autorisierend für die Domäne NA.Adatum.com.com 

betrachtet, verfügt jedoch nicht über alle Ressourceneinträge für die untergeordnete Domäne. DNS1 

nutzt jedoch einen Delegierungseintragszeiger auf DNS2 und DNS3 als Namenserver für die untergeordnete 

Domäne. Wenn ein Client eine Verbindung mit DNS1 herstellt und Informationen zur 

Domäne NA.Adatum.com anfordert, verweist der Server den Client an die Namenserver der untergeordneten 

Domäne. 

Zonendelegierung 

DNS1.Adatum.com 

Adatum.com 

DNS2.NA.Adatum.com 

DNS3.NA.Adatum.com 

NA.Adatum.com 

Abbildung 3.5 

Delegierte Zonen verknüpfen Domänen höherer Ebene mit untergeordneten Domänen


Hinweis Wenn Sie den ersten Domänencontroller in einer Domäne installieren und ihn als DNS-Server 

konfigurieren, versucht der Installations-Assistent automatisch, einen Delegierungseintrag in der übergeordneten 

DNS-Zone zu erstellen. Wenn Sie beispielsweise eine neue AD DS-Domäne mit dem Namen 

Corp.Adatum.com erstellt haben, versucht der Assistent zum Installieren der Active Directory-Domänendienste 

eine Verbindung mit dem Namenserver herzustellen, der autorisierend für die Domäne Adatum.com 

ist, und anschließend versucht er einen Delegierungseintrag für die Domäne Corp.Adatum.com zu erstellen. 

Wenn der DNS-Server nicht verfügbar ist oder das zum Ausführen des Installations-Assistenten verwendete 

Konto nicht über die erforderlichen Berechtigungen zum Erstellen des Delegierungseintrags verfügt, erhalten 

Sie die in Abbildung 3.6 dargestellte Fehlermeldung. Sie können mit der Installation fortfahren und den 

Delegierungseintrag bei Bedarf manuell erstellen. 

Abbildung 3.6 

Warnmeldung, dass das Erstellen eines Delegierungseintrags fehlgeschlagen ist 

Sicherheitswarnung Wenn es sich bei der übergeordnete Domäne für Ihren Domänennamen um einen 

internetbasierten DNS-Server handelt (wenn Sie z.B. die Domäne Adatum.com erstellen, ist die übergeordnete 

Domäne die auf Internet-DNS-Servern gehostete Domäne .com), sollten Sie keinen Delegierungseintrag 

konfigurieren, der auf Ihre internen DNS-Server zeigt. Die internen DNS-Zonen Ihrer AD DS sollten nie im 

Internet offengelegt werden. 

Weiterleitungen und Stammhinweise 

Weiterleitungen und Stammhinweise bieten ebenfalls die Methode zum Verbinden der unterschiedlichen 

Ebenen der DNS-Hierarchie. In den meisten Fällen werden Weiterleitungen und Stammhinweise 

von den DNS-Servern verwendet, die sich in den unteren Ebenen des DNS-Namespaces befinden, 

um Informationen von übergeorndneten DNA-Servern abzurufen. Sowohl Weiterleitungen als 

auch Stammhinweise werden vom DNS-Server für die Ermittlung von Informationen verwendet, die 

sich nicht in seinen Zonendateien befinden. Ein DNS-Server kann beispielsweise nur für die Domäne 

Adatum.com autorisierend sein. Wenn dieser DNS-Server eine Abfrage von einem Client erhält, der 

eine Namensauflösung in der Domäne TreyResearch.com anfordert, muss der DNS-Server in der 

Domäne Adatum.com über eine Möglichkeit zum Ermitteln dieser Informationen verfügen. 

Weiterleitungen 

Eine Konfigurationsmöglichkeit besteht in Weiterleitungen. Bei einer Weiterleitung handelt es sich 

lediglich um einen weiteren DNS-Server, der auf einen anderen DNS-Server zurückgreift, wenn er 

eine Abfrage nicht auflösen kann. Der autorisierende Server der Domäne Adatum.com erhält beispielsweise 

eine rekursive Abfrage für die Domäne TreyResearch.com.


Wurde der DNS-Server der Domäne Adatum.com mit einer Weiterleitung konfiguriert, wird eine 

rekursive Abfrage an die Weiterleitung gesendet, um diese Informationen anzufordern. Weiterleitungen 

werden häufig in internen Netzwerken von Organisationen verwendet. Eine Organisation kann 

über mehrere DNS-Server verfügen, deren primäre Aufgabe in der internen Namensauflösung besteht. 

Benutzer innerhalb der Organisation sollten jedoch auch Internet-IP-Adressen auflösen können. Eine 

Möglichkeit besteht darin, alle internen DNS-Server zur Auflösung von Internetadressen zu konfigurieren. 

Häufiger werden jedoch alle internen DNS-Server mit einer Weiterleitung konfiguriert, die 

auf einen DNS-Server zeigt, der für die Internetnamensauflösung verantwortlich ist. Diese zuletzt 

genannte Konfiguration wird in Abbildung 3.7 dargestellt. Die internen DNS-Server leiten alle 

Abfragen für eine nicht autorisierende Zone an den DNS-Server weiter, der dann versucht, die Internetadresse 

aufzulösen. Wenn ein DNS-Server mit mehreren Weiterleitungen konfiguriert wurde, versucht 

der DNS-Server alle Weiterleitungen nacheinander, bevor er auf anderem Wege versucht, die 

IP-Adresse aufzulösen. 

Internetstamm- 

DNS-Server 

DNS-Server 

Unternehmensniederlassung 1 

Weiterleitung 

Firewall 

Weiterleitung 

DNS-Server 


DNS-Auflösung 

für das Internet 

DNS-Server 


Weiterleitung 

DNS-Server 


Abbildung 3.7 

Verwenden von Weiterleitungen für die Internetnamensauflösung 

Bedingte Weiterleitungen 

Windows Server 2008-DNS-Server unterstützen bedingte Weiterleitungen, um den Weiterleitungsprozess 

effizienter zu gestalten. Eines der Probleme mit Standardweiterleitungen besteht darin, dass der 

Weiterleitungsprozess keine Unterscheidungen basierend auf Domänennamen vornehmen kann. Stellt 

eine Clientauflösung eine Anforderung, die der Server nicht über seinen Zwischenspeicher oder seine 

Zonendateien beantworten kann, sendet der Server eine rekursive Abfrage an die Liste der konfigurierten 

Weiterleitungen, ohne unterschiedliche Weiterleitungen basierend auf den angeforderten Domänennamen 

auswählen zu können. 

Diese Funktion wird von bedingten Weiterleitungen bereitgestellt: Der DNS-Server kann nun die 

Domänenanforderung an unterschiedliche DNS-Server basierend auf Domänennamen weiterleiten.


Wenn einer der Server eine Namensauflösung in einer Zone benötigt, für die er nicht autorisierend ist, 

kann er einfach die für diese Zone konfigurierte Weiterleitung verwenden. Wenn beispielsweise ein 

Client der Domäne Adatum.com eine Ressource in der Domäne TreyResearch.com benötigt, richtet er 

eine Abfrage an den DNS-Server in der Domäne Adatum.com (siehe Abbildung 3.8). Der DNS-Server 

überprüft seine Zonendateien, um zu ermitteln, ob er für diese Domäne autorisierend ist, und führt 

anschließend eine Überprüfung seines Zwischenspeichers durch. Wenn er den Namen dieser Quellen 

nicht auflösen kann, überprüft er die Weiterleitungsliste. Ist eine der Weiterleitungen für die Domäne 

TreyResearch.com festgelegt, sendet der DNS-Server der Domäne Adatum.com nur an diesen Server 

eine rekursive Abfrage. Wenn der Clientcomputer eine Namensauflösung für einen Domänennamen 

anfordert, der nicht über eine bedingte Weiterleitung verfügt, nutzt der DNS-Server die Standardweiterleitung 

und versucht anschließend, die Zone mithilfe von Stammhinweisen zu ermitteln. 

Internetstamm- 

DNS-Server 

Firewall 

ISP DNS-Server 

DNS-Abfrage 

Weiterleitung 


Bedingte 

Weiterleitung 

Client 

Abbildung 3.8 

DNS1.TreyResearch.com 

Konfigurieren bedingter Weiterleitungen 

Der DNS-Server versucht bei der bedingten Weiterleitung stets, den am besten geeigneten Domänennamen 

zu ermitteln.. Wenn Sie z.B. für die Domänen TreyResearch.com und Europa.TreyResearch.com 

eine bedingte Weiterleitung konfiguriert haben und der Client eine Anforderung für einen 

Server stellt, wie beispielsweise Web1.Europa.TreyResearch.com, leitet der DNS-Server die Anforderung 

an den DNS-Server für Europa.TreyResearch.com weiter. 

Hinweis Windows Server 2003 unterstützt ebenfalls die Verwendung bedingter Weiterleitungen. Eines der 

neuen Features in Windows Server 2008 ist die Option zum Speichern der bedingten Weiterleitungen in 

einer AD DS-integrierten Zone (siehe Abbildung 3.9). Dies bedeutet, dass Sie die Konfiguration einer 

Namensauflösung innerhalb einer Gesamtstruktur vereinfachen können, indem Sie die bedingte Weiterleitung 

für alle DNS-Server in der Domäne oder der Gesamtstruktur bereitstellen.


Abbildung 3.9 

Speichern bedingter Weiterleitungen in der AD DS-Partition 

Stammhinweise 

Die zweite für einen DNS-Server verfügbare Methode zum Auflösen von Abfragen für Zonen, für die 

er nicht autorisierend ist, besteht in der Verwendung von Stammhinweisen. Beim Installieren eines 

Windows Server 2008-DNS-Servers mit Zugriff auf das Internet wird der Server automatisch mit 

einer Standardliste von Stammservern konfiguriert. Bei diesen Servern handelt es sich um Server, die 

für den Stamm des Internetnamespaces autorisierend sind. Erhält ein DNS-Server eine Abfrage für 

eine DNS-Zone, für die er nicht autorisierend ist, sendet der Server eine iterative Abfrage an einen der 

Stammserver und initiiert eine Reihe von iterativen Abfragen, bis der Name aufgelöst ist bzw. bis der 

Server bestätigt hat, dass eine Namensauflösung nicht möglich ist. 

Hinweis Die automatisch auf dem DNS-Server konfigurierten Stammserver werden aus der Datei 

Cache.dns kopiert, die in den Einrichtungsdateien des DNS-Servers enthalten ist. 

Sie können der Stammhinweisliste weitere DNS-Server hinzufügen, einschließlich der DNS-Server in 

Ihrem internen Netzwerk. 

Stubzonen 

Bei Stubzonen handelt es sich um eine weitere in Windows Server 2008 verfügbare Option, die für die 

Vereinfachung der Namensauflösungskonfiguration zwischen mehreren Namespaces verwendet werden 

kann. Eine Stubzone ist mit einer sekundären Zone vergleichbar. Beim Einrichten einer Stubzone 

müssen Sie die IP-Adresse eines primären Namenservers für die Zone angeben. Der Server, der die 

Stubzone umfasst, fordert dann eine Zonenübertragung von dem primären Namenserver an. Der 

Unterschied besteht jedoch darin, dass eine Stubzone nur die SOA-Einträge, die NS-Einträge sowie 

die Hosteinträge (A) für die Namenserver der Domäne umfasst, und nicht alle Einträge in der Zone.


Dadurch wird die Namensauflösung zwischen Namespaces verbessert, ohne dass dafür sekundäre 

Namenserver verwendet werden müssen. Wenn ein DNS-Server mit einer Stubzone konfiguriert 

wurde, ist er für die Domäne nicht autorisierend. Ein solcher DNS-Server kann den autorisierenden 

Namenserver für die angegebene Zone effizienter ermitteln. Mit Stubzonen kann der DNS-Server die 

autorisierenden Namenserver für eine Zone ermitteln, ohne dafür die Stammhinweisserver kontaktieren 

zu müssen. 

Eine weitere nützliche Funktion für Stubzonen besteht in der Verwaltung der Namenserverliste für 

delegierte Zonen. Beim Einrichten einer delegierten untergeordneten Domäne ist die Eingabe der 

IP-Adresse aller Namenserver in der delegierten Domäne erforderlich. Ändert sich diese Liste der 

Namenserver – wenn beispielsweise einer der Namenserver aus dem Netzwerk entfernt wird –, ist die 

manuelle Aktualisierung des Delegierungseintrags erforderlich. Sie können eine Stubzone verwenden, 

um den fortlaufenden Aktualisierungsprozess der Namenserverliste zu automatisieren. Um diese 

Automatisierung in der Domäne Adatum.com zu konfigurieren, würden Sie in der Domäne NA. 

Adatum.com auf den DNS-Server in der Domäne Adatum.com eine Stubzone konfigurieren. Sie 

würden außerdem einen Delegierungseintrag in der Zone Adatum.com konfigurieren, der auf die Stubzone 

zeigt. Wenn Änderungen an Namenservereinträgen in der untergeordneten Domäne vorgenommen 

werden, werden diese automatisch in der Stubzone aktualisiert. Wenn die DNS-Server der Domäne 

Adatum.com den Delegierungseintrag verwenden, werden sie an die Stubzone weitergeleitet, sodass 

sie immer Zugriff auf die aktualisierten Namenserverinformationen haben. 

Integration von DNS-Namespaces in AD DS-Domänen 

Windows Server 2008 bietet zahlreiche Optionen für die Integration der Ebenen im DNS-Namespace, 

doch wie wird diese Integration in einer AD DS-Gesamtstruktur vorgenommen? Standardmäßig 

verwendet Windows Server 2008 die Delegierung und Weiterleitung, um mehrere Domänen 

und Domänenstrukturen in die Gesamtstruktur mit den DNS-Namespaces zu integrieren. 

Stellen Sie sich beispielsweise eine Organisation vor, die mehrere Domänen und Domänenstrukturen 

in einer einzelnen Gesamtstruktur umfasst (Abbildung 3.10 zeigt eine beispielhafte Gesamtstruktur). 

Adatum.com 


Asien.Adatum.com 


Ein Entwurf einer AD DS-Gesamtstruktur mit mehreren Strukturen 

Wenn Sie DNS auf jedem Domänencontroller in jeder Domäne installieren und die DNS-Server als 

autorisierende Server für die Domäne konfigurieren, verwendet Windows Server 2008 die Delegierung 

und Weiterleitung, um die DNS-Zone der untergeordneten Domäne in die DNS-Zone der 

übergeordneten Domäne zu integrieren.


In diesem Beispiel erstellt der Assistent zum Installieren der Active Directory-Domänendienste 

einen Delegierungseintrag im DNS-Server der Domäne Adatum.com, der auf den DNS-Server in 

der Domäne Asien.Adatum.com zeigt. Der DNS-Server in der Domäne Asien.Adatum.com wird 

automatisch für die Verwendung der Domäne Adatum.com als Weiterleitung konfiguriert. Dies 

bedeutet, dass alle Namen zwischen diesen beiden Domänen aufgelöst werden können. 

Die DNS-Konfiguration für die neue Struktur in der Gesamtstruktur (TreyResearch.com) ist jedoch 

etwas komplizierter. Standardmäßig ist der DNS-Server in der Domäne TreyResearch.com für die 

Verwendung des DNS-Servers in der Domäne Adatum.com als Weiterleitung konfiguriert. Dies 

bedeutet, dass die Domänencontroller und Clients in der Domäne TreyResearch.com Namen in der 

Domäne Adatum.com auflösen können. 

DNS-Server in der Domäne Adatum.com können jedoch standardmäßig keine Namen in der 

Domäne TreyResearch.com auflösen. Die einfachste Möglichkeit zum Konfigurieren der 

Namensauflösung zwischen der Stammdomäne der Gesamtstruktur und der Stammdomäne der 

Domänenstruktur besteht darin, eine bedingte Weiterleitung auf den DNS-Servern des übergeordneten 

Stamms zu konfigurieren. In diesem Fall können Sie für die DNS-Server der Domäne 

Adatum.com eine bedingte Weiterleitung zur Domäne TreyResearch.com konfigurieren. Die DNS- 

Integration, die sich daraus ergibt, wird in Abbildung 3.11 dargestellt. 

Weiterleitung 

Weiterleitung 


Adatum.com 

Bedingte 

Weiterleitung 

Delegierung 

DNS1.TreyResearch.com 


DNS1.Asien.Adatum.com 



Integrieren des DNS-Namespaces in eine AD DS-Gesamtstruktur 

Problembehandlung bei der DNS- und AD DS-Integration 

Aufgrund der engen Verbindung zwischen DNS und den AD DS besteht der erste Schritt einer Problembehandlung 

für die AD DS häufig darin zu überprüfen, ob DNS ordnungsgemäß funktioniert. 

Wenn DNS nicht funktioniert oder nicht ordnungsgemäß konfiguriert wurde, sind die AD DS für 

Clients und Domänencontroller nicht verfügbar. 

Um Probleme bei der DNS/AD DS-Integration zu behandeln, sind umfassende Kenntnisse über die 

DNS- und AD DS-Bereitstellung in Ihrer Umgebung erforderlich. Dies umfasst die DNS-Serverkonfiguration, 

die DNS-Zonenkonfiguration (einschließlich einer Auflistung der in den AD DS-Anwendungsverzeichnispartitionen 

gespeicherten Zonen) sowie die Zonendelegierungs- und -weiterleitungskonfiguration.


Problembehandlung für DNS 

Die Behandlung von Fehlern bei der Integration von DNS in die AD DS beginnt häufig mit der Ausführung 

einiger allgemeiner Schritte. Gehen Sie folgendermaßen vor: 

1. Identifizieren Sie das Problem. Oftmals ist das von einem Benutzer beschriebene Problem nicht 

das tatsächliche Problem. Wenn ein Benutzer beispielsweise angibt, nicht auf das Internet zugreifen 

zu können, kann das tatsächliche Problem darin bestehen, dass er auf eine bestimmte Website 

nicht zugreifen kann oder dass der Clientcomputer vom Netzwerk getrennt wurde. 

2. Ermitteln Sie den Problemumfang. Besteht das Problem nur mit dem Clientcomputer oder nur mit 

einem Domänencontroller? Oder sind alle Benutzer in einem bestimmten Büro von dem Problem 

betroffen? Wenn nur ein Computer von dem Problem betroffen ist, können Sie sich bei der Problembehandlung 

schwerpunktmäßig mit diesem einen Computer befassen. Besteht das Problem 

für mehrere Clientcomputer oder Server, sollten Sie versuchen, gemeinsame Elemente aller Computer 

zu ermitteln, die von dem Problem betroffen sind. Befinden sich alle betroffenen Computer 

im gleichen Büro oder im gleichen Netzwerksegment, oder wurden sie für die Verwendung eines 

bestimmten DNS-Servers konfiguriert? 

3. Überprüfen Sie die TCP/IP-Einstellungen auf dem Clientcomputer oder Domänencontroller, um 

sicherzustellen, dass der DNS-Client für die Verwendung des entsprechenden DNS-Servers konfiguriert 

wurde. Am schnellsten können Sie die Einstellungen mithilfe des Befehls Ipconfig /all 

überprüfen. 

4. Überprüfen, ob in den Zonendateien des DNS-Servers die geeigneten Informationen enthalten 

sind. Sie können auf jedem Computer das Tool Nslookup.exe verwenden, um zu ermitteln, ob ein 

bestimmter Eintrag in der DNS-Zone vorhanden ist. Einzelheiten zur Verwendung des Befehls 

Nslookup finden Sie im Knowledge Base-Artikel „Verwendung von NSlookup.exe“ unter http:// 

support.microsoft.com/kb/200525. 

5. Stellen Sie sicher, dass die DNS-Suffixe ordnungsgemäß konfiguriert wurden. DNS-Suffixe werden 

im Windows Server 2008-DNS auf unterschiedliche Weise verwendet. Zum einen werden 

DNS-Suffixe von Clients für die Auflösung von Hostnamen verwendet, wenn nicht der vollqualifizierte 

Domänenname angegeben wird. Wenn der Clientcomputer diesen Namen auflösen 

möchte, hängt er dem Namen alle im Clientcomputer konfigurierten DNS-Suffixe an, um den 

Hostnamen auflösen zu können. Ist das entsprechende DNS-Suffix nicht auf dem Computer konfiguriert, 

kann die Namensauflösung nicht durchgeführt werden. 

DNS-Suffixe werden auch von DDNS verwendet. Standardmäßig versucht der Clientcomputer, 

die Registrierung seines Hosteintrags in der durch das primäre DNS-Suffix gekennzeichneten 

Zone vorzunehmen. Bei dem primären DNS-Suffix handelt es sich um den DNS-Namen für die 

Domäne des Computers. Sie können zusätzliche DNS-Suffixe festlegen und den Computer so 

konfigurieren, dass er seine DNS-Einstellungen in jeder der durch das DNS-Suffix gekennzeichneten 

Zonen registriert. 

6. Stellen Sie sicher, dass der DHCP-Clientdienst aktiviert und zum automatischen Starten festgelegt 

ist. Der DHCP-Clientdienst ist erforderlich, damit dynamische Updates durchgeführt werden 

können, auch wenn der Computer für die Verwendung statischer IP-Adressen und nicht für die 

Verwendung eines DHCP-Servers konfiguriert wurde. 

7. Verwenden Sie den Netzwerkmonitor, um den Netzwerkdatenverkehr zwischen dem DNS-Client 

und dem DNS-Server zu erfassen. Wenn die DNS-Namensauflösung oder die dynamische 

Namensregistrierung fehlschlägt, erfassen Sie den durch die DNS-Anforderung auf beiden Clientcomputern 

und dem DNS-Server entstandenen Netzwerkdatenverkehr. Die Netzwerkerfassung


kann auf ein Konfigurationsproblem (z.B. darauf, dass der DNS-Client versucht, eine Verbindung 

mit dem falschen DNS-Server herzustellen) oder auf ein Netzwerkproblem hinweisen (z.B. darauf, 

dass der Clientcomputer die DNS-Abfrage an den richtigen Server sendet, die Abfrage jedoch 

von einer Firewall oder einer anderen Netzwerkeinstellung blockiert wird). 

8. Aktivieren Sie die Option Debugprotokollierung. Sie können umfangreiche Informationen auf dem 

Windows Server 2008-DNS-Server sammeln, indem Sie die Debugprotokollierung auf dem Server 

aktivieren. Um die Debugprotokollierung zu aktivieren, rufen Sie die DNS-Servereigenschaften 

in der Konsole DNS auf und aktivieren das Kontrollkästchen Pakete zum Debuggen 

protokollieren. Das Dialogfeld wird in Abbildung 3.12 dargestellt. 


Aktivieren der Debugprotokollierung auf einem DNS-Server 

Unter Umständen möchten Sie den durch die Protokollierung erfassten Datenverkehr begrenzen. 

Das Filtern von Paketen anhand der IP-Adresse kann besonders nützlich sein, wenn Sie nur den 

Datenverkehr zwischen dem Server und einem bestimmten DNS-Server protokollieren möchten. 

9. Wenn dynamische Updates fehlschlagen, überprüfen Sie, ob die DNS-Zone so konfiguriert wurde, 

dass dynamische Aktualisierungen durchgeführt werden können. Wenn entsprechend der vorgenommenen 

Konfiguration dynamische Updates vorgenommen werden und die Aktualisierungen 

fehlschlagen, ändern Sie die Zonenkonfiguration, um auch nicht sichere Updates zuzulassen. Auf 

diese Weise können Sie ermitteln, ob das Problem nur mit sicheren oder sowohl mit sicheren als 

auch mit nicht sicheren Updates besteht. Wenn keine der beiden Aktualisierungen vorgenommen 

werden kann, überprüfen Sie die TCP/IP-Konfiguration sowie die Verfügbarkeit des DNS-Servers 

im Netzwerk. Wenn nur sichere Updates fehlschlagen, führen Sie die folgenden Schritte aus: 

a. Überprüfen Sie, ob die Hosts Domänenmitglieder sind. Dynamische Aktualisierungen basieren 

auf der Kerberos-Authentifizierung, für die alle Clientcomputer Domänenmitglieder sein 

müssen.


b. Überprüfen Sie, ob ein Problem mit dem Computerkonto des Hosts besteht, der die Aktualisierung 

durchzuführen versucht. Wenn das Problem nur auf einem Host auftritt, entfernen Sie 

den Host aus der Domäne und fügen ihn erneut zur Domäne hinzu. 

c. Überprüfen Sie, ob bereits ein gleichnamiger Eintrag vorhanden ist. Standardmäßig können 

Einträge, die von einem Host erstellt wurden, nicht von einem anderen Host bearbeitet oder 

entfernt werden. Wenn bereits ein gleichnamiger Eintrag vorhanden ist, löschen Sie den vorhandenen 

Eintrag, und initiieren Sie einen erneuten Registrierungsversuch durch den Host. 

Problembehandlung bei der Registrierung von SRV-Einträgen 

Zusätzlich zu den allgemeinen Schritten zur DNS-Problembehandlung ist unter Umständen eine Problembehandlung 

bei der Registrierung der SRV-Einträge durch Domänencontroller erforderlich. Diese 

Einträge sind für die Ermittlung des Domänencontrollers im Netzwerk erforderlich. Wenn ein Domänencontroller 

keine SRV-Einträge in DNS registriert, beginnen Sie mit der Überprüfung der TCP/IP- 

Einstellungen und den DNS-Zoneneinstellungen (wie zuvor beschrieben). Ermitteln Sie außerdem, ob 

der Domänencontroller seine Host- und PTR-Einträge erfolgreich registrieren kann. Wenn Host- und 

PTR-Einträge ordnungsgemäß registriert werden und nur die SRV-Einträge betroffen sind, führen Sie 

die folgenden Schritte aus: 

1. Überprüfen Sie, ob der Domänencontroller versucht, die entsprechenden Einträge zu registrieren. 

Halten Sie hierfür den Netzwerkanmeldedienst auf dem Domänencontroller an, und löschen 

Sie die Dateien Netlogon.dnb und Netlogon.dns, die sich im Ordner %systemroot%\System32\ 

config befinden. Starten Sie dann den Netzwerkanmeldedienst. Überprüfen Sie, ob die Datei 

Netlogon.dns die entsprechenden SRV-Einträge enthält, und überprüfen Sie, ob diese Einträge in 

DNS aktualisiert wurden. 

2. Wenn die Einträge nicht ordnungsgemäß aktualisiert wurden, überprüfen Sie das Systemereignisprotokoll 

auf Fehler. Überprüfen Sie das Protokoll insbesondere auf die Ereigniskennungen 

5774, 5775 und 5781. Jede dieser Ereigniskennungen weist auf ein Problem mit der Registrierung 

von SRV-Einträgen hin. 

Weitere Informationen Weitere Informationen zu diesem Thema finden Sie im Knowledge Base- 

Artikel 259277, „Problembehandlung bei Netlogon-Ereignissen 5774, 5775 und 5781“, unter 

http://support.microsoft.com/kb/259277. 

Häufig werden diese Fehler verursacht, wenn ein Domänencontroller in seinen TCP/IP-Eigenschaften 

auf sich als primären DNS-Server verweist. Wenn der Domänencontroller mit dieser 

Konfiguration gestartet wird, startet der Netzwerkanmeldedienst unter Umständen vor dem DNS- 

Dienst. Da der Netzwerkanmeldedienst Einträge in DNS registrieren muss und der DNS-Dienst 

noch nicht verfügbar ist, treten unter Umständen Fehler auf. In diesem Fall können Sie die auftretenden 

Fehler einfach ignorieren, da der Netzwerkanmeldedienst nach etwa fünf Minuten einen 

erneuten Registrierungsversuch unternimmt, der dann erfolgreich durchgeführt werden kann. Die 

einfachste Möglichkeit zur Korrektur dieses Problems besteht darin, Domänencontroller zur Verwendung 

eines anderen DNS-Servers für die Registrierung von SRV-Einträgen zu konfigurieren.



Bei DNS handelt es sich um einen besonders wichtigen Netzwerkdienst in Windows Server 2008- 

Netzwerken. Ohne eine stabile DNS-Infrastruktur schlagen nahezu alle Anmelde- und Ressourcenermittlungsversuche 

fehl. Als Netzwerkadministrator eines Windows Server 2008-Netzwerks müssen 

Sie ein DNS-Experte sein. In diesem Kapitel wurde insbesondere die Integration von DNS in die 

AD DS erläutert. 

Empfohlene Vorgehensweisen 

• DNS stellt die Grundlage der AD DS und weiterer AD DS-integrierter Anwendungen wie beispielsweise 

Microsoft Exchange Server dar. Wenn Benutzer über Probleme berichten, ist es empfehlenswert, 

während der Problembehandlung als Erstes die ordnungsgemäße Funktionsfähigkeit 

von DNS zu überprüfen. 

• Für die Unterstützung einer AD DS-Bereitstellung werden keine AD DS-integrierten Zonen in DNS 

benötigt. Aufgrund der engen Verbindung zwischen den AD DS und DNS wird die Verwendung 

AD DS-integrierter Zonen für die AD DS-Bereitstellung jedoch empfohlen – selbst dann, wenn Sie 

andere DNS-Server für die Namensauflösungsdienste verwenden. 

• Wenn Sie in der Gesamtstruktur Ihrer Organisation mehrere Domänen bereitstellen, insbesondere 

wenn Sie mehrere Domänenstrukturen bereitstellen, sollten Sie sicherstellen, dass alle Domänencontroller 

in sämtlichen Domänen die DNS-Namen für alle andere Domänencontroller in der 

Gesamtstruktur auflösen können. Als empfohlene Vorgehensweise sollten Sie Zonendelegierungen 

und bedingte Weiterleitungen verwenden, um die zahlreichen DNS-Namespaces miteinander 

zu verknüpfen. 


Die folgenden Ressourcen enthalten zusätzliche Informationen im Zusammenhang mit diesem 

Kapitel. 

Verwandte Informationen 

• In Kapitel 4, „Active Directory-Domänendienstreplikation“, werden ausführliche Informationen 

zur Funktionsweise der AD DS-Replikation bereitgestellt. Bei der Implementierung AD DS-integrierter 

Zonen werden die DNS-Informationen auf die gleiche Weise zwischen Domänencontrollern 

repliziert wie alle weiteren AD DS-Informationen. 

• Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, enthält Einzelheiten zum 

Entwerfen der DNS-Bereitstellung. 

• Das Dokument „DNS Technical Reference“ (in englischer Sprache) unter http://technet2.microsoft.com/WindowsServer/en/Library/6e45e81e-fb44-4a20-a752-ebe740e2acc61033.mspx 

stellt 

ausführliche Informationen zu DNS als Netzwerkdienst bereit. Diese technische Referenz umfasst 

weiterführende Informationen zu der in diesem Kapitel erläuterten AD DS-Integration. 

• Auf der Webseite „What’s New in DNS in Windows Server 2008“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver2008/en/library/0b0bf633-5732-4b39-80 

d3-a2a4330acb141033.mspx?mfr=true werden ausführliche Informationen zu den neuen 

Features im Windows Server 2008-DNS aufgeführt.


• RFC 2782: „A DNS RR for Specifying the Location of Services (DNS SRV)“ (in englischer 

Sprache) 

• RFC 2136: „Dynamic Updates in the Domain Name System (DNS UPDATE)“ (in englischer 

Sprache) 


Windows Server 2008 bietet verschiedene Tools, die zur Verwaltung von DNS sowie zur Behebung 

von Problemen mit DNS verwendet werden können. In Tabelle 3.3 werden einige dieser Tools 

sowie deren Anwendungsfälle aufgeführt. 

Tabelle 3.3 

DNS-Tools 

Toolname 

Ipconfig.exe 

DNS-Konsole 

Dnscmd.exe 

Dnslint.exe 

Netzwerkmonitor 


Dieses Tool kann auf allen Windows-Server- und -Clientbetriebssystemen ausgeführt werden. 

Ipconfig zeigt alle aktuellen TCP/IP-Netzwerkkonfigurationswerte an und aktualisiert die DHCP- (Dynamic 

Host Configuration Protocol) und DNS-Einstellungen. 

Verwenden Sie IPconfig, um sicherzustellen, dass die TCP/IP-Einstellungen des Clients ordnungsgemäß 

konfiguriert wurden. Sie können dieses Tool auch verwenden, wenn ein bestimmter Client keine 

DNS-Namen auflösen oder seine Ressourceneinträge nicht in DNS registrieren kann. 

Dieses Tool wird zusammen mit der DNS-Serverrolle installiert. 

Die DNS-Konsole wird zur Verwaltung der DNS-Serverrolle genutzt. Mithilfe dieser Konsole können Sie 

alle Aspekte des DNS-Serverdienstes bearbeiten. Dies umfasst das Erstellen und Löschen von Zonen 

und Ressourceneinträgen sowie das Erzwingen von Replikationsereignissen zwischen dem physischen 

Speicher des DNS-Servers und DNS-Datenbanken. Ferner kann die DNS-Konsole zur Aktivierung der 

Debugprotokollierung und zum Testen der Namensauflösung in einem Netzwerk verwendet werden. 

Dieses Tool wird zusammen mit der DNS-Serverrolle installiert. 

Bei Dnscmd handelt es sich um ein Befehlszeilenprogramm, das zum Anzeigen und Bearbeiten der 

Eigenschaften von DNS-Servern, -Zonen und Ressourceneinträgen verwendet werden kann. Darüber 

hinaus kann Dnscmd zum Entwickeln von Konfigurationsskripts für DNS-Server eingesetzt werden. 

Dieses Tool kann kostenlos von der Microsoft-Website heruntergeladen werden. (Unter http://support.microsoft.com/kb/321045 

erfahren Sie, wo Sie das Tool herunterladen können.) 

Sie können dieses Tool für die Problembehandlung häufig auftretender Probleme bei der DNS-Namensauflösung 

verwenden. Verwenden Sie Dnslint zur Überprüfung bestimmter DNS-Eintragssätze und 

stellen Sie mithilfe dieses Tools sicher, dass die Einträge innerhalb mehrerer DNS-Server konsistent 

sind. Ferner können Sie mit Dnslint die für die AD DS-Replikation relevanten DNS-Einträge auf Fehler 

überprüfen. 

Microsoft Network Monitor 3.1 kann im Microsoft Download Center heruntergeladen werden (unter http:// 

www.microsoft.com/downloads/details.aspx? 

familyid=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac&displaylang=en). 

Der Netzwerkmonitor erfasst Daten zu Paketen im Netzwerk und protokolliert diese für zusätzliche Analysen. 

Die Überwachungsdaten können auf unterschiedliche Weise gefiltert werden, unter anderem nach 

Protokollen, Ports sowie physischen und logischen Adressen. Da der Netzwerkmonitor die aktuell über 

DNS-Lookups oder DNS-Zonenübertragungen gesendeten Netzwerkpakete anzeigt, ist er in verschiedenen 

Situationen sehr hilfreich.

Zusätzliche Ressourcen 91 

Tabelle 3.3 

Toolname 

Nslookup.exe 

Nltest.exe 

DNS-Tools (Fortsetzung) 


Dieses Tool ist in allen Microsoft Windows-Server- und -Clientbetriebssystemen enthalten. 

Mithilfe von Nslookup können Sie DNS-Serverabfragen ausführen und detaillierte Antwortinformationen 

abrufen. Anhand der von Nslookup gelieferten Informationen können Sie Namensauflösungsprobleme 

diagnostizieren und beheben, sicherstellen, dass Ressourceneinträge einer Zone ordnungsgemäß hinzugefügt 

bzw. darin aktualisiert wurden, sowie weitere serverbezogene Probleme beheben. 

Dieses Tool ist in allen Microsoft Windows-Server- und -Clientbetriebssystemen enthalten. 

Sie können mit diesem Tool eine Liste aller Domänencontroller abrufen sowie den Status der Vertrauensstellungen 

zwischen Domänencontrollern abfragen. 


• Bei ListAppPartitions.ps1 handelt es sich um ein Windows PowerShell-Skript, mit dem Sie alle 

Anwendungsverzeichnispartitionen in Ihrer Gesamtstruktur auflisten können. 

• Das Microsoft Office Excel-Spreadsheet DNSConfig.xlsx kann dazu verwendet werden, die DNS- 

Zone und die DNS-Serverkonfiguration in Ihrer Organisation zu dokumentieren. 


• „Erstellen einer DNS-Anwendungsverzeichnispartition“ in der Hilfe der DNS-Verwaltungskonsole. 

• „Grundlegendes zur Serveralterung und zum Aufräumvorgang“ in der Hilfe der DNS-Verwaltungskonsole. 

• „Grundlegendes zu dynamischen Updates“ in der Hilfe der DNS-Verwaltungskonsole. 

• „Problembehandlung bei DNS“ in der Hilfe der DNS-Verwaltungskonsole.

93 


Active Directory-Domänendienstreplikation 


AD DS-Replikationsmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

Replikationsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

Replizieren des Verzeichnisses SYSVOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

Standortinterne und standortübergreifende Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

Erstellen der Replikationstopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Konfigurieren der standortübergreifenden Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 

Problembehandlung bei der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

Empfohlene Vorgehensweisen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

Zusätzliche Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

Es nahezu allen Fällen empfiehlt es sich, bei der Bereitstellung einer AD DS-Domäne (Active Directory 

Domain Services) in Microsoft Windows Server 2008 mehrere Domänencontroller bereitzustellen. 

Die Bereitstellung mehrerer Domänencontroller in jeder Domäne ist die einfachste und effektivste 

Möglichkeit, um für die Domänencontrollerdienste eine hohe Verfügbarkeit sicherzustellen. 

Diese Domänencontroller können sich beispielsweise in einem Datacenter am Unternehmenshauptsitz 

befinden, wo sie über sehr schnelle Netzwerkverbindungen miteinander verbunden werden können. 

Sie können aber auch auf mehrere Orte auf der ganzen Welt verteilt sein, in diesem Fall werden 

sie über eine Vielzahl an WAN-Verbindungen (Wide Area Connections) in den Unternehmensniederlassungen 

verbunden. 

Unabhängig von der Anzahl der in einem Unternehmen bereitgestellten Domänencontroller oder dem 

Ort der Domänencontrollerbereitstellung müssen die Domänencontroller Informationen untereinander 

replizieren. Ist keine Informationsreplikation möglich, werden die Domänencontrollerverzeichnisse 

inkonsistent. Wenn ein Benutzer beispielsweise auf einem Domänencontroller erstellt wird und 

Informationen nicht auf alle übrigen Domänencontroller repliziert werden, kann sich der Benutzer nur 

an dem Domänencontroller authentifizieren, auf dem das Konto erstellt wurde. 

In diesem Kapitel wird das Replikationsverfahren in den AD DS beschrieben. Vorwiegend wird in 

diesem Kapitel die Funktionsweise der Replikation beschrieben, d.h. die Erstellung einer Replikationstopologie 

sowie die Funktionsweise der zwischen Domänencontrollern durchgeführten Replikation. 

Standardmäßig beginnen AD DS-Domänencontroller nach der Installation automatisch mit 

der gegenseitigen Replikation. Diese Standardreplikationstopologie ist für Ihre Organisation unter 

Umständen nicht die effektivste, und daher wird in diesem Kapitel beschrieben, auf welche Weise Sie 

Änderungen an der Replikationskonfiguration vornehmen können, um sie an die Anforderungen Ihres 

Unternehmens anzupassen. Darüber hinaus werden in diesem Kapitel die Möglichkeiten zur Problembehandlung 

bei der AD DS-Replikation erläutert.

94 Kapitel 4: Active Directory-Domänendienstreplikation 

AD DS-Replikationsmodell 

Wie bereits in Kapitel 2, „Active Directory-Domänendienstkomponenten“, beschrieben, setzen sich 

die AD DS aus mehreren logischen Partitionen zusammen. Die Replikation zwischen Domänencontrollern 

mit Replikaten jeder Partition wird für alle Partitionen auf genau die gleiche Weise durchgeführt. 

Änderungen an einem Attribut der Verzeichnispartitionskonfiguration werden mithilfe des 

gleichen Modells und der gleichen Verfahren durchgeführt wie Attributänderungen auf jeder beliebigen 

anderen Partition. Der einzige Unterschied besteht in der Liste mit Domänencontrollern, die 

eine Kopie der replizierten Änderung erhalten. Die Replikation zwischen Domänencontrollern am 

gleichen Standort wird nicht auf die gleiche Weise durchgeführt wie die Replikation zwischen Domänencontrollern 

an unterschiedlichen Standorten, wobei sich das grundlegende Modell nicht ändert. In 

diesem Abschnitt wird das von den AD DS verwendete Replikationsmodell beschrieben. 

Die AD DS verwenden ein Multimaster-Replikationsmodell. Das bedeutet, dass Änderungen am 

AD DS-Datenspeicher auf jedem beliebigen Domänencontroller vorgenommen werden können, 

mit Ausnahme speziell konfigurierter schreibgeschützter Domänencontroller (Read-Only Domain 

Controllers, RODCs). Abgesehen von den RODCs verfügt jeder Domänencontroller über eine 

beschreibbare Verzeichniskopie, und daher können Änderungen nicht nur auf einem Domänencontroller 

vorgenommen werden. Nachdem eine Änderung vorgenommen wurde, wird sie auf alle weiteren 

Domänencontroller repliziert. In diesem Multimaster-Replikationsmodell wird vielen wichtigen 

Aspekten in Bezug auf die Zuverlässigkeit und Skalierbarkeit Rechnung getragen. Da von allen 

Domänencontrollern die gleichen Dienste bereitgestellt werden, stellt keiner der Domänencontroller 

einen einzelnen Fehlerpunkt dar. 

Hinweis Wie in Kapitel 2 erläutert wurde, verfügen die AD DS über bestimmte Betriebsmasterrollen, die 

nur von einem Domänencontroller ausgeübt werden können. Diese Rollen stellen einen einzelnen Fehlerpunkt 

dar, sie können jedoch ebenfalls einfach auf einen anderen Domänencontroller verschoben werden 

bzw. der Domänencontroller kann diese einfach übernehmen. 

Das von den AD DS verwendete Replikationsmodell kann als ein Modell mit loser Konsistenz 

beschrieben werden, bei dem jedoch stets Konvergenz angestrebt wird. Als lose Konsistenz wird hierbei 

der Zustand beschrieben, dass nicht alle Domänencontroller mit einem Partitionsreplikat stets über 

identische Informationen verfügen. Wenn z.B. ein neuer Benutzer auf einem Domänencontroller 

erstellt wird, erhalten die verbleibenden Domänencontroller diese Information nicht vor dem nächsten 

Replikationszyklus. Bei der Replikation wird jedoch immer Konvergenz angestrebt. Bei einer fortlaufenden 

Systemverwaltung erreichen alle Domänencontroller den Zustand der Konvergenz, d.h. alle 

Domänencontroller verfügen über identische Informationen, wenn für eine gewisse Zeit keine Änderungen 

am Verzeichnis vorgenommen wurden. 

Bei diesem Replikationsmodell wird außerdem ein Replikationsverfahren verwendet, bei dem das 

Speichern und Weiterleiten von Informationen im Vordergrund steht. Das bedeutet, dass ein Domänencontroller 

eine Verzeichnisänderung empfangen und diese Änderung dann an andere Domänencontroller 

weiterleiten kann. Dies ist vor allem dann von Vorteil, wenn mehrere Domänencontroller in 

verschiedenen Unternehmensniederlassungen über langsame WAN-Verknüpfungen verbunden sind. 

Eine Verzeichnisänderung kann von einem Domänencontroller an einem Standort an einen einzelnen 

Domänencontroller an einem anderen Standort repliziert werden. Der Domänencontroller, der die 

Aktualisierung empfängt, kann diese Änderungen dann an weitere Domänencontroller an einem zweiten 

Standort weiterleiten.

Replikationsverfahren 95 

Die AD DS verwenden außerdem ein statusbasiertes Replikationsmodell. Das bedeutet, dass jeder 

Domänencontroller den Status von Replikationsaktualisierungen nachverfolgt. Wenn ein Domänencontroller 

neue Aktualisierungen empfängt (entweder am Domänencontroller vorgenommene Änderungen 

oder replizierte Änderungen von anderen Domänencontrollern), übernimmt der Domänencontroller 

die Aktualisierungen in sein Replikat des AD DS-Datenspeichers. Versucht ein weiterer 

Domänencontroller die Informationen zu replizieren, über die der Domänencontroller bereits verfügt, 

kann der empfangende Domänencontroller mithilfe des Status seines Datenspeichers festlegen, dass 

das Empfangen doppelter Informationen nicht erforderlich ist. Der aktuelle Status des Datenspeichers 

umfasst Metadaten, die zum Auflösen von Konflikten verwendet werden und verhindern, dass bei 

jedem Replikationszyklus eine vollständige Replikation gesendet wird. 

Replikationsverfahren 

Features wie beispielsweise die Multimaster-Replikation sowie die Replikation durch das Speichern 

und Weiterleiten von Informationen bieten die Möglichkeit, dass ein Domänencontroller AD DS- 

Aktualisierungen von mehreren Domänencontrollern empfangen kann, und dass der AD DS-Replikationsdatenverkehr 

zwischen Domänencontrollern über unterschiedliche Wege geleitet werden kann. 

Wenn z.B. eine Änderung an den AD DS des Domänencontrollers DC1 vorgenommen wird, kann 

diese Änderung direkt auf die Domänencontroller DC2 und DC3 repliziert werden. Aufgrund des 

Modells zum Speichern und Weiterleiten von Informationen versucht der Domänencontroller DC2 

unter Umständen, die gleiche Änderung auf Domänencontroller DC3 zu replizieren. Die AD DS- 

Replikation wurde entworfen, um ein effizientes Replikationsverfahren sicherzustellen, während 

gleichzeitig Redundanz bereitgestellt wird. 

Aktualisierungstypen 

An den AD DS-Informationen auf einem bestimmten Domänencontroller können zwei Arten von 

Änderungen vorgenommen werden. Bei dem einen Aktualisierungstyp handelt es sich um eine 

ursprüngliche Aktualisierung. Eine ursprüngliche Aktualisierung wird beim Hinzufügen, Bearbeiten 

oder Löschen eines Objekts auf einem Domänencontroller durchgeführt. Bei dem zweiten Aktualisierungstyp 

handelt es sich um eine replizierte Aktualisierung. Eine replizierte Aktualisierung wird 

durchgeführt, wenn eine an einem anderen Domänencontroller vorgenommene Änderung auf den 

lokalen Domänencontroller repliziert wird. Per Definition kann es für jede beliebige Änderung nur 

eine ursprüngliche Aktualisierung geben, und zwar auf dem Domänencontroller, auf dem die Änderung 

vorgenommen wird. Diese ursprüngliche Aktualisierung wird dann auf alle Domänencontroller 

repliziert, die über ein Replikat der entsprechenden AD DS-Partition verfügen. 

In allen folgenden Situationen finden in den AD DS ursprüngliche Aktualisierungen statt: 

• Hinzufügen eines neuen Objekts zu den AD DS Beim Hinzufügen eines neuen Objekts zu den 

AD DS wird ein Objekt mit einem eindeutigen AttributobjectGUID erstellt. Darüber hinaus wird 

allen Werten, denen die für das Objekt konfigurierten Attribute zugewiesen wurden, die Versionsnummer 

1 zugewiesen. 

• Löschen eines vorhandenen Objekts aus den AD DS Beim Löschen eines Objekts aus den AD DS 

wird das Objekt als gelöscht gekennzeichnet, es wird jedoch nicht unmittelbar aus dem AD DS- 

Datenspeicher entfernt. Das Objekt wird erst nach Ablauf der für das Objekt festgelegten Tombstone-Zeit 

endgültig gelöscht. Weitere Informationen zu diesem Thema werden im Abschnitt 

„Replizieren von Objektlöschungen“ in diesem Kapitel bereitgestellt.


• Bearbeiten der Attribute eines vorhandenen Objekts Eine solche Bearbeitung kann das Hinzufügen 

eines neuen Werts zu einem Attribut, das Löschen eines Attributwerts oder das Bearbeiten eines 

vorhandenen Werts umfassen. Wenn Sie Änderungen an einem Objekt vornehmen, wird bei der 

Bearbeitungsanforderung der neue Wert jedes Attributs mit dem vorhandenen Wert verglichen. 

Hat sich der Wert eines Attributs nicht geändert, wird das Attribut auch nicht aktualisiert. Hat sich 

der Wert geändert, wird das Attribut aktualisiert, und die Versionsnummer jedes aktualisierten 

Attributs wird um eins erhöht. 

• Verschieben eines Objekts in den AD DS in einen neuen übergeordneten Container Wenn ein übergeordneter 

Container umbenannt wird, wird jedes Objekt im Container ebenfalls in den umbenannten 

Container verschoben. Wird ein Objekt in einen anderen Container in den AD DS verschoben, 

ändert sich für das Objekt nur das Attribut name, wobei diese Attributänderung auf den neuen 

Speicherort in der LDAP-Hierarchie zurückzuführen ist. 

Bei allen ursprünglichen Aktualisierungen an den AD DS handelt es sich um unteilbare Operationen, 

d.h. dass bei einer ursprünglichen Aktualisierung der AD DS entweder die vollständige Transaktion 

durchgeführt und die Änderung in den Datenspeicher übernommen wird, oder dass kein Teil der 

Aktualisierung durchgeführt wird. Weitere Informationen zum Vornehmen von Änderungen am 

AD DS-Datenspeicher werden in Kapitel 14, „Überwachen und Warten von Active Directory“, 

bereitgestellt. 

Das Replikationsverfahren in Windows Server 2008 

In Windows Server 2003 wurden einige wichtige Änderungen am Replikationsverfahren vorgenommen, 

die auch in Windows Server 2008 verfügbar sind. Bei einer dieser Änderungen handelt es 

sich um die Replikation verknüpfter Werte. In Windows 2000 ist die kleinste Replikationseinheit 

ein Attribut. Dies bedeutet, dass in einigen Fällen das Ändern eines Werts in einem Mehrwertattribut 

zu einem erheblichen Replikationsdatenverkehr führen kann. Solche Änderungen werden am 

häufigsten an Mitgliedschaften in universellen Gruppen vorgenommen. Da sich die vollständige 

Mitgliedsliste für eine universelle Gruppen in einem Attribut befindet, führt das Hinzufügen eines 

einzelnen Benutzers zu der universellen Gruppe zu einer umfangreichen Replikation, vor allem 

dann, wenn die Gruppe bereits über Tausende Mitglieder verfügt. In Windows Server 2003 Active 

Directory und den Windows Server 2008-AD DS können Mehrwertattribute wie z.B. die Gruppenmitgliedschaft 

aktualisiert werden, indem nur die Änderung des Attributs mithilfe der Replikation 

verknüpfter Werte repliziert wird. 

Die AD DS nutzen verknüpfte Attribute, um die Replikation verknüpfter Werte zu ermöglichen. 

Verknüpfte Attribute umfassen immer einen Forwardlink und einen Backwardlink, um eine Verknüpfung 

zwischen zwei AD DS-Objekten zu erstellen. Der Forwardlink ist mit einem Attribut des 

Quellobjekts verknüpft (z.B. das Attribut member des Gruppenobjekts), wohingegen der Backwardlink 

das mit dem Zielobjekt verknüpfte Attribut darstellt (z.B. das Attribut memberOf des 

Benutzerobjekts). Ein Backwardlinkwert umfasst die definierten Namen aller Objekte, in deren 

Forwardlink der definierte Name des Objekts festgelegt ist. 

Die Beziehungen zwischen verknüpften Attributen werden als Verknüpfungspaare in einer eigenen 

Tabelle in der Verzeichnisdatenbank gespeichert. Durch das übereinstimmende Paar der Verknüpfungskennungen 

werden die Attribute aneinander gebunden.


Das Attribut member verfügt beispielsweise über eine Verknüpfungskennung mit dem Wert 2, und 

das Attribut memberOf verfügt über eine Verknüpfungskennung mit dem Wert 3. Da die Attribute 

member und memberOf in der Datenbank verknüpft und zu Suchzwecken indiziert sind, kann 

das Verzeichnis auf alle Einträge überprüft werden, in denen das Verknüpfungspaar member/ 

memberOf lautet und das Attribut memberOf die Gruppe kennzeichnet. 

Die Beziehungen zwischen verknüpften Attributen werden als Verknüpfungspaare in einer eigenen 

Tabelle in der Verzeichnisdatenbank gespeichert. Durch das übereinstimmende Paar der Verknüpfungskennungen 

werden die Attribute aneinander gebunden. Das Attribut member verfügt beispielsweise 

über eine Verknüpfungskennung mit dem Wert 2, und das Attribut memberOf verfügt 

über eine Verknüpfungskennung mit dem Wert 3. Da die Attribute member und memberOf in der 

Datenbank verknüpft und zu Suchzwecken indiziert sind, kann das Verzeichnis auf alle Einträge 

überprüft werden, in denen das Verknüpfungspaar member/memberOf lautet und das Attribut 

memberOf die Gruppe kennzeichnet. 

Eine weitere wichtige Änderung in Windows Server 2003 Active Directory bestand in der Unterstützung 

für Gruppen mit mehr als 5000 Mitgliedern. In Windows 2000 konnten Gruppen aufgrund 

der Aktualisierung auf Attributebene und der Replikation nicht mehr als 5000 Mitglieder 

umfassen. Der Grenzwert zum Vornehmen von Änderungen an der Verzeichnisdatenbank während 

einer Transaktion liegt bei 5000. Dadurch wird auch die Höchstanzahl an Änderungen definiert, die 

während der Replikation einer Aktualisierung repliziert werden können. Daher ergibt sich die 

maximale Gruppengröße von 5000 Mitgliedern in Windows 2000. In den Windows Server 2008- 

AD DS besteht durch die Unterstützung von Änderungen an nur einem Wert eines verknüpften 

Mehrwertattributs diese Beschränkung nicht mehr. 

Replizieren von Änderungen 

Nachdem eine ursprüngliche Änderung an den AD DS vorgenommen wurde, muss die Änderung auf 

die weiteren Domänencontroller repliziert werden, die über ein Replikat dieser Partition verfügen. 

Innerhalb eines Standorts wartet der Domänencontroller, an dem die ursprüngliche Aktualisierung 

vorgenommen wurde, 15 Sekunden, bevor er die Änderungen auf seine direkten Replikationspartner 

repliziert. Die Wartezeit von 15 Sekunden ist erforderlich, um die gleichzeitige Replikation von mehreren 

an der Datenbank vorgenommenen Änderungen zu ermöglichen. Dies führt zu einer erhöhten 

Replikationseffizienz. Zwischen Standorten wird die ursprüngliche Aktualisierung basierend auf dem 

für die Standortverknüpfung konfigurierten Zeitplan auf die Replikationspartner repliziert. 

Beim Replizieren von Änderungen an Verzeichnisinformationen benötigen die Domänencontroller 

einen Mechanismus für die Verwaltung des Replikationsflusses. Zur Optimierung der AD DS-Replikation 

sollten bei der Replikation nur die zwischen zwei Domänencontrollern erforderlichen Änderungen 

gesendet werden. Dafür sollten die Domänencontroller ermitteln können, welche Änderungen 

(sofern vorhanden) bisher nicht repliziert wurden, und anschließend sollten sie nur diese erforderlichen 

Änderungen replizieren. Die AD DS verwenden für die Verzeichnisreplikationsverwaltung eine 

Kombination von USNs (Update Sequence Numbers), obere Grenzwerte (High Watermark), Aktualitätsvektoren 

(Up-To-Dateness Vectors, UTDV) und Änderungsstempel.


Update Sequence Numbers (USNs) 

Bei der Aktualisierung eines Objekts in der Datenbank wird der Aktualisierung eine Update Sequence 

Number (USN) zugewiesen. Die USN ist spezifisch für den Domänencontroller, auf dem die Aktualisierung 

vorgenommen wurde. Wenn beispielsweise der Aktualisierung der Telefonnummer eines 

Benutzers die USN 5555 zugewiesen wurde, würde die USN der nächsten Änderung am Domänencontroller 

unabhängig vom geänderten Objekt USN 5556 lauten. Jeder vorgenommenen Änderung 

wird eine USN zugewiesen. Werden während einer Aktualisierung mehrere Attribute geändert (z.B. 

die Adresse, Telefonnummer und die Niederlassung eines Benutzers), wird während der Aktualisierung 

nur eine USN zugewiesen. 

Beim Vornehmen einer Änderung gibt es drei Verwendungsmöglichkeiten für die USN. Die eine 

Möglichkeit besteht darin, dass der lokale USN-Wert mit dem aktualisierten Attribut gespeichert wird. 

Die USN des geänderten Attributs wird mit dem lokalen USN-Wert gekennzeichnet. Die zweite Möglichkeit 

besteht darin, die USN für das Attribut uSNChanged des Objekts zu verwenden. Dieses Attribut 

wird mit jedem Objekt gespeichert und kennzeichnet die höchste USN für jedes beliebige Attribut 

des Objekts. Angenommen, die Telefonnummer eines Benutzers wurde geändert, und die der 

Änderung zugewiesene USN lautete 5556. Sowohl für die lokale USN als auch für das Attribut 

uSNChanged wird der Wert 5556 festgelegt. Nehmen Sie weiter an, dass die nächste im Verzeichnis 

dieses Servers vorgenommene Aktualisierung in der Änderung der Adresse des gleichen Benutzers 

bestand. Sowohl für die lokale USN des Adressattributs als auch das Attribut uSNChanged des Benutzerobjekts 

würde der Wert 5557 festgelegt. Die lokale USN für das Telefonnummernattribut würde 

jedoch unverändert 5556 bleiben, da dies die USN der letzten Aktualisierung ist, durch die dieses 

bestimmte Attribut geändert wurde. 

Die lokale USN sowie das Attribut uSNChanged werden sowohl für ursprüngliche Aktualisierungen 

als auch für replizierte Aktualisierungen angewendet. Und schließlich kann die USN für das Attribut 

originating USN verwendet werden. Dieser Wert wird nur für ursprüngliche Aktualisierungen festgelegt 

und als Teil der Attributreplikation auf alle weiteren Domänencontroller repliziert. Beim 

Ändern der Telefonnummer eines Benutzers auf einem Server wird die USN der Änderung dem 

ursprünglichen USN-Wert zugewiesen. Bei der Replikation der geänderten Telefonnummer auf weitere 

Domänencontroller wird die ursprüngliche USN gemeinsam mit der Aktualisierung gesendet, und 

dieser Wert wird auf dem Zieldomänencontroller nicht bearbeitet. Die lokale USN und das Attribut 

uSNChanged werden auf dem Zieldomänencontroller bearbeitet (und sind spezifisch für diesen 

Domänencontroller), die ursprüngliche USN wird jedoch nicht geändert, bis das Attribut an sich 

erneut aktualisiert wird. Die ursprüngliche USN wird für die an späterer Stelle in diesem Kapitel 

beschriebenen Propagierungsdämpfung verwendet. 

Anzeigen von USN-Informationen 

Die USNs jedes beliebigen Objekts können mithilfe der unterschiedlichen, in Windows Server 

2008 integrierten Verwaltungstools angezeigt werden. Am einfachsten können Sie die aktuellen 

und ursprünglichen USN-Werte für ein Objekt im Verwaltungstool Active Directory-Computer und 

-Benutzer anzeigen. Um diese Informationen anzuzeigen, aktivieren Sie im Menü Ansicht die 

Option Erweiterte Features, und klicken Sie im anschließend angezeigten Eigenschaftendialogfeld 

auf die Registerkarte Objekt. Denken Sie daran, dass die USN Domänencontroller-spezifisch ist. 

Daher ist die USN für ein Objekt auf zwei unterschiedlichen Domänencontrollern nicht identisch.


Sie können die lokale USN, den ursprünglichen Domänencontroller, die ursprüngliche USN und 

den Zeitstempel für jedes beliebige Attribut mithilfe des Befehlszeilenprogramms Repadmin anzeigen. 

Geben Sie in einer Eingabeaufforderung die Zeichenfolge repadmin /showobjmeta Domänencontrollername 

DefinierterObjektnamen ein. In Abbildung 4.1 wird ein Teil der Ausgabe für 

diesen Befehl dargestellt. 

Abbildung 4.1 

Anzeigen von Replikationsmetadaten mithilfe von Repadmin. 

In dieser Ausgabe können Sie sehen, dass der Benutzer auf dem Domänencontroller SEA-DC1 

erstellt wurde, die Attribute description und telephoneNumber wurden dann jedoch auf Domänencontroller 

SEA-DC2 geändert. Die ursprünglichen USNs für alle Attribute stammen, mit Ausnahme 

dieser beiden, vom Domänencontroller SEA-DC1, die ursprünglichen USNs für die Attribute 

description und telephoneNumber stammen jedoch vom Domänencontroller SEA-DC2. Die 

lokalen USNs hingegen stammen alle vom Domänencontroller SEA-DC1, d.h. dem Domänencontroller, 

von dem diese Informationen erfasst wurden. Die Versionsnummer der beiden Attribute 

beträgt 2. Das weist ebenfalls darauf hin, dass die ursprüngliche Version des Attributs geändert 

wurde. 

Sie können auf die gleichen Replikationsinformationen auch mithilfe des Tools Ldp zugreifen. Stellen 

Sie dafür mithilfe des Tools Ldp eine Verbindung bzw. Bindung mit einem Domänencontroller 

her, ermitteln Sie das Objekt, und klicken Sie anschließend mit der rechten Maustaste auf das 

Objekt, wählen Erweitert und klicken anschließend auf Replikationsmetadaten. Bei den Replikationsmetadaten 

handelt es sich um die gleichen Informationen, die mithilfe des Tools Repadmin 

angezeigt werden, es sei denn, dass die ursprünglichen DSA-Informationen mithilfe der Domänencontroller-GUID 

(Globally Unique Identifier, global eindeutige Kennung) und nicht mithilfe des 

Anzeigenamens angezeigt werden.


Obere Grenzwerte (High Watermark) 

Die oberen Grenzwerte (High Watermark-Werte) werden verwendet, um die zwischen Domänencontrollern 

zu replizierenden Informationen zu verwalten. Jeder Domänencontroller verwaltet seinen 

eigenen Satz an oberen Grenzwerten für jeden seiner direkten Replikationspartner. Bei dem oberen 

Grenzwert handelt es sich lediglich um den aktuellen Wert uSNChanged, den der Domänencontroller 

von einem bestimmten Replikationspartner erhalten hat. Wenn ein Domänencontroller eine Aktualisierung 

an einen Replikationspartner sendet, wird der Wert uSNChanged gemeinsam mit der Aktualisierung 

gesendet. Der Zieldomänencontroller betrachtet diesen Wert uSNChanged als den oberen 

Grenzwert für den Replikationspartner. 

Die oberen Grenzwerte finden bei der Replikation Anwendung. Wenn ein Domänencontroller 

Aktualisierungen von einem anderen Domänencontroller anfordert, sendet der Zieldomänencontroller 

seinen oberen Grenzwert, den der Quelldomänencontroller verwenden kann. Anhand des oberen 

Grenzwerts kann der Quelldomänencontroller ermitteln, welche Aktualisierungen der Zieldomänencontroller 

bereits erhalten hat. Der Quelldomänencontroller verwendet den oberen Grenzwert des 

Zieldomänencontrollers, um alle potenziellen Verzeichnisaktualisierungen zu filtern und nur die 

Änderungen mit einem höheren Wert uSNChanged zu senden. 

Hinweis Auf dem Domänencontroller wird ein eigener oberer Grenzwert für jede Verzeichnispartition und 

für jeden direkten Replikationspartner gespeichert. 

Aktualitätsvektoren und Propagierungsdämpfung 

Die Aktualitätsvektoren (Up-To-Dateness Vector, UDTV) werden ebenfalls zur Steuerung der zwischen 

Domänencontrollern zu replizierenden Informationen verwendet. Mithilfe der Aktualitätsvektoren 

können die ursprünglichen Aktualisierungen nachverfolgt werden, die ein Domänencontroller 

von einem beliebigen Domänencontroller erhalten hat. Angenommen, die Telefonnummer eines 

Benutzers wird auf Domänencontroller DC1 geändert, und dem Attribut wird die ursprüngliche 

USN 5556 zugewiesen. Bei der Replikation dieses Attributs auf Domänencontroller DC2 wird die 

ursprüngliche USN mit dem aktualisierten Attribut repliziert. Darüber hinaus wird die GUID von 

Domänencontroller DC1 mit dem neuen Attribut repliziert. Wenn der Domänencontroller DC2 diese 

Aktualisierung erhält, ändert er seinen Aktualitätsvektor, um anzugeben, dass der Wert der aktuellen 

ursprünglichen Aktualisierung, die er von Domänencontroller DC1 erhalten hat, nun 5556 lautet. 

Fordert ein Zieldomänencontroller Aktualisierungen von einem Quelldomänencontroller an, integriert 

er seine Aktualitätsvektoren in die Anforderung. Der Zieldomänencontroller nutzt dann seinerseits 

diese Informationen, um die Liste der möglichen Aktualisierungen zu filtern, die an den Zieldomänencontroller 

gesendet werden könnten. Diese Option ist wichtig, wenn mehr als zwei Domänencontroller 

für eine Verzeichnispartition vorhanden sind. Wenn beispielsweise der Domänencontroller 

DC3 dem im vorangegangenen Abschnitt erläuterten Beispiel hinzugefügt wird, wird die auf dem 

Domänencontroller DC1 geänderte Telefonnummer auf die beiden Domänencontroller DC2 und DC3 

repliziert. Nun verfügen die beiden Domänencontroller DC3 und DC2 über die aktualisierte Telefonnummer, 

und sie ändern ihren Aktualitätsvektor, um anzugeben, dass die ursprüngliche USN, die die 

beiden Domänencontroller von Domänencontroller DC1 erhalten haben, 5556 lautete. 15 Sekunden 

nach Erhalt dieser Aktualisierung benachrichtigt Domänencontroller DC2 Domänencontroller DC3 

über die aktualisierten Informationen. Wenn Domänencontroller DC3 die Verzeichnisaktualisierungen 

von Domänencontroller DC2 anfordert, integriert er seinen Aktualitätsvektor in die Anforderung. 

In diesem Fall kann Domänencontroller DC2 ermitteln, dass der Aktualitätsvektor von Domänencontroller 

DC3 für Domänencontroller DC1 bereits die aktuelle ursprüngliche USN ausweist.


Wenn die Änderung der Telefonnummer während dieses Zeitraums die einzige am Verzeichnis vorgenommene 

Änderung darstellt, werden keine weiteren Informationen zwischen den Domänencontrollern 

DC2 und DC3 repliziert. 

Dieses Verfahren zum Verringern der während der Replikation gesendeten Aktualisierungen mithilfe 

des Aktualitätsvektors wird als Propagierungsdämpfung bezeichnet. Hierbei handelt es sich um ein 

wichtiges Feature, da die AD DS so entworfen sind, dass redundante Replikationsverbindungen zwischen 

Domänencontrollern aufgebaut werden. Eines der Probleme beim Erstellen redundanter Verknüpfungen 

besteht darin, dass einem Domänencontroller unter Umständen die gleiche Aktualisierung 

von mehreren Replikationspartnern gesendet wird. Dies kann zu einem erheblichen Anstieg des 

Replikationsdatenverkehrs und potenziell dazu führen, dass die gleiche Aktualisierung wiederholt an 

alle Domänencontroller gesendet würde – was zu einer Replikationsschleife führen könnte. Durch die 

mithilfe des Aktualitätsvektors vorgenommene Propagierungsdämpfung wird dies unterbunden. 

Der obere Grenzwert und der Aktualitätsvektor werden gemeinsam verwendet, um den Replikationsdatenverkehr 

einzuschränken. Mit dem oberen Grenzwert wird die letzte Änderung gekennzeichnet, 

die ein Domänencontroller von einem bestimmten Domänencontroller empfangen hat, daher muss der 

Quelldomänencontroller diese Änderung nicht erneut senden. Mit dem Aktualitätsvektor werden die 

aktuellen Änderungen gekennzeichnet, die von allen anderen Domänencontrollern empfangen wurden, 

die ein Replikat der Partition umfassen. Daher muss der Quelldomänencontroller keine Verzeichnisaktualisierungen 

senden, die der Zieldomänencontroller bereits von einem anderen Replikationspartner 

erhalten hat. 

Änderungsstempel und Konfliktlösung 

Bei der letzten zur Verwaltung der Replikation zwischen Domänencontrollern verwendeten Eigenschaft 

handelt es sich um den Änderungsstempel. Bei jeder Attributänderung wird die Änderung mit 

einem Änderungsstempel gekennzeichnet. Dieser Änderungsstempel wird dann bei der Replikation 

auf andere Domänencontroller gemeinsam mit der Aktualisierung gesendet. Anhand des Änderungsstempels 

kann im Falle eines Replikationskonflikts die anzuwendende Änderung ermittelt werden. 

Der Änderungsstempel umfasst drei Komponenten: 

• Versionsnummer Die Versionsnummer wird zur Nachverfolgung der Anzahl an Änderungen verwendet, 

die an einem Attribut oder einem Objekt vorgenommen wurden. Beim Erstellen eines 

Objekts wird für die Versionsnummer aller Attribute der Wert 0 festgelegt, sofern keine andere 

Festlegung für das Attribut vorgenommen wird. Wird einem bisher nicht festgelegten Attribut ein 

Wert zugewiesen, wird die Versionsnummer auf den Wert 1 erhöht. Bei jeder Aktualisierung des 

Attributs wird die Versionsnummer um den Wert 1 erhöht. 

• Letzter Schreibzugriff Der letzte Schreibzugriff wird für die Nachverfolgung des letzten Schreibzugriffs 

auf das Objekt verwendet. Der Zeitwert wird auf dem Server aufgezeichnet, auf dem das 

Attribut aktualisiert wird, und er wird mit dem Attribut auf andere Domänencontroller repliziert. 

• Ursprungsserver Hierbei handelt es sich um die GUID des Servers, auf den die letzte ursprüngliche 

Aktualisierung des Attributs angewendet wurde. 

Der Änderungsstempel für jede Änderung an einem Attribut setzt sich aus diesen drei Komponenten 

zusammen. Bei der Replikation des Attributs auf einen anderen Domänencontroller wird die Information 

des Änderungsstempels gemeinsam mit dem Attribut repliziert. Wenn ein Attribut auf einem 

Domänencontroller geändert wird und am gleichen Attribut auf einem anderen Domänencontroller 

ebenfalls eine Änderung vorgenommen wird, bevor die Aktualisierung auf den zweiten Domänencontroller 

repliziert wurde, wird anhand des Änderungsstempels das als endgültige Änderung anzuwendende 

Attribut ermittelt.


Beim Entstehen von Konflikten wird die Entscheidung über die endgültige Änderung in der folgenden 

Reihenfolge getroffen: 

1. Versionsnummer Die Änderung mit der höchsten Versionsnummer wird immer übernommen. 

Daher wird, für den Fall, dass die Änderung auf dem einen Domänencontroller die Versionsnummer 

3 und auf dem anderen Domänencontroller die Versionsnummer 4 aufweist, die Änderung mit 

der Versionsnummer 4 übernommen wird. 

2. Letzter Schreibzugriff Beim nächsten für die Ermittlung der anzuwendenden Änderung verwendeten 

Wert handelt es sich um den letzten Schreibzugriff. Bei identischen Versionsnummern wird die 

Änderung mit dem aktuellen Zeitstempel angewendet. 

3. Server-GUID Bei identischen Versionsnummern und Zeitstempeln wird die GUID der Serverdatenbank 

für die Ermittlung der anzuwendenden Änderung verwendet. Es wird die Änderung angewendet, 

die von dem Server mit der höheren GUID stammt. Diese GUIDs werden beim Hinzufügen eines 

Domänencontrollers zur Domäne zugewiesen, wobei die Zuweisung einer GUID willkürlich vorgenommen 

wird. 

Bei der AD DS-Replikation können Konflikte gelöst werden, die bei der gleichzeitigen Bearbeitung 

des gleichen Objektattributs auf zwei Domänencontrollern entstehen. Es gibt jedoch mindestens zwei 

weitere Konflikte, die entstehen können: 

• Ein Objekt wird auf einem Domänencontroller hinzugefügt oder bearbeitet, während zur gleichen 

Zeit das Containerobjekt des Objekts auf einem anderen Domänencontroller gelöscht wird: Auf 

einem Domänencontroller wird beispielsweise ein neuer Benutzer zur OU (Organizational Unit, 

Organisationseinheit) Buchhaltung hinzugefügt. Zur gleichen Zeit löscht ein anderer Administrator 

auf einem anderen Domänencontroller die OU Buchhaltung. In diesem Fall wird der Container 

über die Replikation auf allen Domänencontrollern gelöscht, und das dem gelöschten 

Container hinzugefügte Objekt wird in den AD DS in den Container LostAndFound verschoben. 

• Objekte werden mit dem gleichen relativ definierten Namen (Relative Distinguished Name, RDN) 

im gleichen Container hinzugefügt: Ein Administrator eines Domänencontrollers erstellt beispielsweise 

ein Benutzerobjekt mit dem relativen definierten Namen Bill in der OU Buchhaltung, während 

zur gleichen Zeit auf einem anderen Domänencontroller ein Benutzer mit dem gleichen 

relativen definierten Namen in die gleiche OU verschoben bzw. darin erstellt wird. In diesem 

Fall wird für die Konfliktlösung die der Verzeichnisaktualisierung zugewiesene GUID verwendet, 

um zu ermitteln, welches Objekt beibehalten und welches Objekt umbenannt wird. Das Objekt 

mit der höheren GUID wird beibehalten, und das Objekt mit der niedrigeren GUID wird in 

Bill*CNF:userGUID umbenannt, wobei es sich bei dem Nummernzeichen (*) um ein reserviertes 

Zeichen handelt. Wenn das zweite Benutzerobjekt benötigt wird, kann es umbenannt werden. 

Replizieren von Objektlöschungen 

Die Replikation von Objektlöschungen wird in den AD DS abweichend zu anderen Verzeichnisaktualisierungen 

gehandhabt. Wird ein Objekt wie beispielsweise ein Benutzerkonto gelöscht, so wird das 

Objekt nicht unmittelbar gelöscht. Es wird vielmehr ein Tombstone-Objekt erstellt. Bei dem Tombstone- 

Objekt handelt es sich um das ursprüngliche Objekt, für dessen Attribut isDeleted der Wert true festgelegt 

wurde, und bei dem ein Großteil der verbleibenden Objektattribute gelöscht wurde. Es werden nur 

wenige Attribute beibehalten, die für die Kennzeichnung des Objekts erforderlich sind, wie beispielsweise 

die GUID, die SID, SIDHistory und der definierte Name. Gelöschte Objekte werden im ausgeblendeten 

Container Gelöschte Objekte gespeichert. Jede Verzeichnispartition verfügt über den Container 

Gelöschte Objekte.


Hinweis Um den Container Gelöschte Objekte in einer Verzeichnispartition anzuzeigen, verwenden Sie 

ein Tool wie beispielsweise Ldp. Nachdem Herstellen einer Verbindung bzw. Bindung mit der Verzeichnispartition 

rufen Sie im Menü Optionen die Option Steuerelemente auf. Fügen Sie im Dialogfeld Steuerelemente 

das Steuerelement Return deleted objects hinzu. Nach dem Hinzufügen des Steuerelements wird der Container 

CN=Deleted Items in der Verzeichnisstruktur angezeigt. 

Dieser Tombstone wird dann auf alle weiteren Domänencontroller in der Domäne repliziert. Wenn 

alle Domänencontroller die Aktualisierung empfangen, werden die am ursprünglichen Objekt vorgenommenen 

Änderungen auf alle Domänencontroller angewendet. Das Tombstone-Objekt verbleibt für 

einen festgelegten Zeitraum im der Domänendatenbank. Dieser Zeitraum wird als Tombstone-Ablaufzeit 

bezeichnet. Nach der standardmäßig auf 180 Tage festgelegten Tombstone-Ablaufzeit löscht jeder 

Domänencontroller den Tombstone aus seiner Datenbankkopie. Das Verfahren zum Entfernen von 

Tombstones aus der Datenbank wird als Sammlung veralteter Objekte bezeichnet. Standardmäßig ist 

für das Intervall der Sammlung veralteter Objekte in der Gesamtstruktur ein Wert von 12 Stunden festgelegt. 

Das bedeutet, dass die Sammlung veralteter Objekte alle zwölf Stunden durchgeführt wird und 

dabei alle Tombstones gelöscht werden, deren Tombstone-Ablaufzeit überschritten ist. 

Hinweis Die Tombstone-Ablaufzeit wurde in Windows Server 2008 Active Directory abweichend zu Vorgängerversionen 

festgelegt. In Windows 2000 und Windows 2003 Active Directory betrug die Tombstone- 

Ablaufzeit 60 Tage. In Windows 2003 SP1 wurde dieser Wert auf 180 Tage erhöht, dann wurde er jedoch 

in Windows Server 2003 R2 auf 60 Tage zurückgesetzt. Wenn Sie eine vorhandene Domäne mit einer 

Tombstone-Ablaufzeit von 60 Tagen auf Windows Server 2008 aktualisieren, wird dieser Zeitraum für die 

Ablaufzeit beibehalten. Sie können mithilfe des ADSI-Editors oder des Tools Ldp.exe Änderungen an der 

Tombstone-Ablaufzeit und dem Intervall zur Sammlung veralteter Objekte vornehmen. Diese Eigenschaften 

werden im Objekt CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=ForestRoot- 

Domain konfiguriert. Diese Einstellungen werden mithilfe der Attribute garbageCollPeriod und der 

tombstoneLifetime definiert. In den meisten Fällen ist es nicht erforderlich, Änderungen an diesen Werten 

vorzunehmen. 

Verknüpfte Attribute sind im Hinblick auf das Löschen von Objekten als Sonderfälle zu betrachten. 

Beim Löschen eines Objekts werden die folgenden Änderungen an den verknüpften Attributen vorgenommen: 

• Alle Forwardlinks für das gelöschte Objekt werden entfernt. Wenn beispielsweise ein Gruppenobjekt 

gelöscht wird, werden alle Mitgliedsverknüpfungen für das Gruppenobjekt entfernt. Das 

bedeutet, dass die Gruppe aus dem Attribut memberOf der rückwärtigen Verknüpfung jedes 

Benutzers entfernt wird, der Mitglied der Gruppe war. 

• Alle rückwärtigen Verknüpfungen werden für das gelöschte Objekt entfernt. Wenn z.B. ein Benutzer 

gelöscht wird, wird der Wert des definierten Namens des Benutzers von den Mitgliedsattributen 

jedes Gruppenobjekts entfernt, das das Attribut memberOf des Benutzers aufweist. 

Nachdem das verknüpfte Attribut auf einem Domänencontroller bearbeitet wurde, werden die Aktualisierungen 

(wie alle anderen Aktualisierungen auch), auf die weiteren Domänencontroller repliziert. 

Wichtig Aufgrund des Vorgehens beim Löschen verknüpfter Attribute unterscheidet sich der Vorgang zur 

autorisierenden Wiederherstellung dieser Objekte von der Wiederherstellung von Objekten, die keine verknüpften 

Attribute aufweisen. Weitere Informationen zu diesem Thema werden in Kapitel 15, „Active Directory- 

Notfallwiederherstellung“, bereitgestellt.


Replizieren des Verzeichnisses SYSVOL 

Änderungen am AD DS-Datenspeicher werden mithilfe des zuvor beschriebenen Verfahrens vorgenommen. 

Der Ordner SYSVOL auf jedem Domänencontroller enthält darüber hinaus jedoch Informationen, 

die für die fehlerfreie Funktionsfähigkeit der AD DS von zentraler Bedeutung sind. Der freigegebene 

Ordner SYSVOL umfasst die folgenden Dateien und Ordner, die verfügbar sein müssen und 

zwischen den Domänencontrollern in einer Domäne synchronisiert werden: 

• Gruppenrichtlinieneinstellungen Der Ordner SYSVOL enthält einen Ordner, der den Namen der 

Domäne trägt, in welcher der Domänencontroller Mitglied ist. Dieser Domänenordner umfasst 

einen Ordner mit dem Namen Policies, in dem Gruppenrichtlinienvorlagen und Skripts für Clients 

ab Windows 2000 enthalten sind. 

• Den freigegebenen Ordner NETLOGON In diesem Ordner sind Systemrichtlinien (die Dateien 

Config.pol oder Ntconfig.pol) sowie benutzerbasierte Anmelde- und Abmeldeskripts für Prä-Windows 

2000-Netzwerkclients enthalten, wie beispielsweise Clients, auf denen Windows 98 oder 

Windows NT 4.0 ausgeführt wird. Der freigegebene Ordner NETLOGON befindet sich im Ordner 

Scripts des Domänenordners. 

Der Inhalt des Ordners SYSVOL wird auf jeden Domänencontroller in einer Domäne repliziert. Wenn 

als Domänenfunktionsebene Windows Server 2003 oder eine niedrigere Funktionsebene festgelegt ist, 

ist der Dateireplikationsdienst (File Replication Service, FRS) für die Replikation des Inhalts des Ordners 

SYSVOL zwischen Domänencontrollern verantwortlich. Beim Heraufstufen der Domänenfunktionsebene 

auf Windows Server 2008 wird die Replikation des Inhalts des Ordners SYSVOL mithilfe 

der DFS-R (Distributed File System Replication) durchgeführt. In beiden Fällen werden die Verbindungsobjekttopologie 

sowie die von der Konsistenzprüfung (Knowledge Consistency Checker, KCC) 

für die Active Directory-Replikation erstellte Planung für die Replikationsverwaltung zwischen 

Domänencontrollern verwendet. 

Hinweis Bei der DFS-R handelt es sich um ein statusbasiertes Multimaster-Replikationsmodul, das in 

Windows Server 2003 R2 eingeführt wurde und die Replikationsplanung sowie die Bandbreiteneinschränkung 

unterstützt. Die DFS-R verwendet einen neuen Komprimierungsalgorithmus, der als Remotedifferenzialkomprimierung 

(Remote Differential Compression, RDC) bezeichnet wird. Mithilfe der RDC werden bei 

der DFS-R nur die Unterschiede (oder Änderungen) zwischen zwei Servern repliziert, wodurch für die Replikation 

weniger Bandbreite erforderlich ist. Weitere Informationen zur DFS-R finden Sie im Artikel „Overview 

of the Distributed File System Solution in Microsoft Windows Server 2003 R2“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver/en/library/d3afe6ee-3083-4950-a093- 

8ab748651b761033.mspx?mfr=true. 

Standortinterne und standortübergreifende Replikation 

Die Beschreibungen zur Funktionsweise der AD DS-Replikation gilt sowohl für die standortinterne 

als auch die standortübergreifende Replikation. In beiden Fällen nutzen Domänencontroller die gleichen 

Verfahren für die Optimierung des Replikationsverfahrens. Die Verwaltung des Replikationsdatenverkehrs 

ist einer der Hauptgründe, die für das Erstellen zusätzlicher Standorte in den AD DS 

sprechen. Da für alle Domänencontroller innerhalb eines Standorts eine schnelle Verbindung 

zugrunde gelegt wird, ist die Replikation zwischen diesen Domänencontrollern für höchstmögliche 

Geschwindigkeit und verringerte Latenz optimiert. Wenn der Replikationsdatenverkehr jedoch über 

eine langsame Netzwerkverbindung übertragen werden muss, stellt die Aufrechterhaltung der Netzwerkbandbreite 

ein größeres Problem dar.

Standortinterne und standortübergreifende Replikation 105 

Die Aufrechterhaltung der Netzwerkbandbreite kann durch das Erstellen mehrerer Standorte erzielt 

werden, indem Features wie die Datenkomprimierung und die geplante AD DS-Replikation aktiviert 

werden. 

Standortinterne Replikation 

Das primäre Ziel einer standortinternen Replikation besteht in der Verringerung der Replikationslatenz, 

d.h. darin, die schnellstmögliche Aktualisierung aller Domänencontroller innerhalb eines 

Standorts sicherzustellen. Um dieses Ziel zu erreichen, weist die standortinterne Replikation folgende 

Merkmale auf: 

• Das Replikationsverfahren wird durch eine Benachrichtigung vom sendenden Domänencontroller 

initiiert. Wenn eine Änderung an der Datenbank vorgenommen wird, benachrichtigt der sendende 

Computer einen Zieldomänencontroller darüber, dass Änderungen verfügbar sind. Die Änderungen 

werden dann durch den Zieldomänencontroller über eine RPC-Verbindung (Remote Procedure 

Call, Remoteprozedurabruf) vom sendenden Domänencontroller abgerufen. Nachdem diese 

Replikation abgeschlossen ist, benachrichtigt der Domänencontroller einen weiteren Zieldomänencontroller, 

der dann die Änderungen abruft. Dieses Verfahren wird so lange fortgeführt, bis die 

Aktualisierung aller Replikationspartner abgeschlossen ist. 

• Die Replikation wird fast unmittelbar nach dem Ändern von AD DS-Informationen vorgenommen. 

Standardmäßig wartet ein Domänencontroller 15 Sekunden, nachdem eine Änderung vorgenommen 

wurde, und beginnt dann mit der Replikation der Änderungen auf Domänencontroller 

am gleichen Standort. Der Domänencontroller schließt die Replikation mit einem Partner ab, wartet 

für drei Sekunden, und initiiert anschließend die Replikation mit einem weiteren Partner. Der 

Domänencontroller wartet 15 Sekunden nach einer Änderung, um die Replikationseffizienz zu 

erhöhen, für den Fall, dass weitere Änderungen an den Partitionsinformationen vorgenommen 

werden. 

• Der Replikationsdatenverkehr wird nicht komprimiert. Da alle Computer innerhalb eines Standorts 

über schnelle Verbindungen verbunden sind, werden die Daten ohne Komprimierung versendet. 

Die Komprimierung von Replikationsdaten erzeugt eine zusätzliche Last auf dem 

Domänencontrollerserver. Durch den unkomprimierten Replikationsdatenverkehr wird die Serverleistung 

auf Kosten der Netzwerkauslastung beibehalten. 

• Während eines Replikationszyklus wird der Replikationsdatenverkehr an mehrere Replikationspartner 

gesendet. Bei jeder am Verzeichnis vorgenommenen Änderung repliziert der Domänencontroller 

die Informationen an alle direkten Replikationspartner, d.h. an einige oder alle 

Domänencontroller am Standort. 

Ändern der standortinternen Replikation 

In dem meisten Fällen ist keine Änderung an der Funktionsweise der standortinternen Replikation 

erforderlich. Es gibt jedoch einige Einstellungen, die in bestimmten Situationen angepasst werden 

können. Dazu gehören: 

• Wartezeit Wenn als Funktionsebene Ihrer AD DS-Gesamtstruktur Windows Server 2003 oder 

Windows Server 2008 festgelegt ist, können Sie den Zeitraum ändern, den der Domänencontroller 

vor der Benachrichtigung des ersten Replikationspartners und der Benachrichtigung nachfolgender 

Replikationspartner abwartet.


Öffnen Sie hierfür die Konfigurationspartition im ADSI-Editor, und wechseln Sie zum Ordner 

CN=Partitions,CN=Configuration,DC=Gesamtstrukturname. Klicken Sie im Ordner mit der 

rechten Maustaste auf die Partition, für die Sie die Replikationseinstellungen ändern möchten. 

Der Wert für die Zeitverzögerung zur Benachrichtigung des ersten Replikationspartners wird 

im Attribut msDS-Replication-Notify-First-DSA-Delay gespeichert. Der Standardwert wird 

nicht angezeigt, er ist jedoch auf 15 Sekunden festgelegt. Der Wert für die nachfolgenden 

Benachrichtigungen wird im Attribut msDS-Replication-Notify-Subsequent-DSA-Delay gespeichert. 

Für diesen Wert sind standardmäßig 3 Sekunden festgelegt. Wenn in Ihrer Organisation 

Windows 2000 Server-Domänencontroller ausgeführt werden, müssen Sie die auf 300 Sekunden 

festgelegte Standardeinstellung für die Benachrichtigung des ersten Replikationspartners 

und 30 Sekunden für nachfolgende Benachrichtigungen ändern. Sie können auch den Befehl 

repadmin Computername /notifyopt Namenskontext /first:Zeit_in_Sekunden /subs: Zeit_in_ 

Sekunden verwenden, um die Replikationswartezeiten festzulegen. Um die Wartezeiten auf die 

Standardwerte zurückzusetzen, verwenden Sie den gleichen Befehl und legen keinen Wert für die 

Zeiteinstellungen fest. 

• Strikte Replikationskonsistenz Über die strikte Replikationskonsistenz wird festgelegt, auf welche 

Weise veraltete Objekte von erneut verbundenen Domänencontrollern repliziert werden, für 

die während eines längeren Zeitraums als der Tombstone-Ablaufzeit keine Replikation durchgeführt 

wurde. Wenn beispielsweise ein Domänencontroller beim Löschvorgang für ein Objekt 

offline ist oder während der gesamten Tombstone-Ablaufzeit offline bleibt, wird der Tombstone 

nicht auf den Server repliziert. Wird der Server erneut mit dem Netzwerk verbunden, 

versucht er, das Objekt auf andere Domänencontroller zu replizieren. Wenn auf dem Zieldomänencontroller 

die strikte Replikationskonsistenz aktiviert ist, akzeptiert er keine eingehende 

Replikation eines veralteten Objekts. Standardmäßig wird in Windows Server 2008 die strikte 

Replikationskonsistenz erzwungen. Sie können diese Einstellung ändern, indem Sie für den 

Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ 

Strict Replication Consistency den Wert 0 festlegen. 

• Datenmenge, die in jedem Replikationspaket repliziert wird Standardmäßig beträgt die Anzahl an 

Objekten, die von Windows Server 2008-Domänencontrollern in einem einzelnen Paket repliziert 

wird, 1/1.000.000 der Arbeitsspeichergröße, wobei mindestens 100 Objekte und höchstens 

1000 Objekte repliziert werden. Die maximale Größe replizierter Objekte beträgt 1/100 der 

Arbeitsspeichergröße, wobei mindestens 1 MB und höchstens 10 MB repliziert werden. Sie 

können diese Einstellungen ändern, indem Sie im Verzeichnis HKEY_LOCAL_MACHINE\SYS- 

TEM\CurrentControlSet\Services\NTDS\Parameters die Werte Replicator intrasite packet size 

(Objekte) und Replicator intrasite packet size (Bytes) erstellen. 

Achtung Bevor Sie Änderungen an den Standardeinstellungen für die standortinterne Replikation vornehmen, 

sollten Sie die geplanten Änderungen umfassend testen. In den meisten Fällen ist es nicht erforderlich, 

Änderungen an diesen Einstellungen vorzunehmen. 

Standortübergreifende Replikation 

Das primäre Ziel einer standortübergreifenden Replikation besteht in der Verringerung der für den 

Replikationsdatenverkehr genutzten Bandbreite. Das bedeutet, dass der Datenverkehr bei der standortübergreifenden 

Replikation folgende Merkmale aufweist:

Standortinterne und standortübergreifende Replikation 107 

• Die Replikation wird nach einem Zeitplan und nicht nach dem Vornehmen von Änderungen 

durchgeführt. Um die standortübergreifende Replikation zu verwalten, müssen Sie eine Standortverknüpfung 

erstellen, die zwei Standorte verbindet. Eine der Konfigurationsoptionen für die 

Standortverknüpfung ist die Planung des Replikationszeitpunkts. Eine weitere Option ist die Einstellung 

eines Replikationsintervalls zum Festlegen der Replikationshäufigkeit während des festgelegten 

Zeitraums. Wenn die Bandbreite zwischen Unternehmensstandorten eingeschränkt ist, 

kann festgelegt werden, dass die Replikation außerhalb der Arbeitszeiten durchgeführt wird. 

• Der Replikationsdatenverkehr wird bei der Komprimierung auf etwa 40 % der unkomprimierten 

Größe reduziert, wenn der Replikationsdatenverkehr eine Größe von 32 KB überschreitet. Um 

weniger Bandbreite der Netzwerkverbindung zu nutzen, komprimiert der Bridgeheadserver an 

jedem Standort den Datenverkehr auf Kosten zusätzlicher CPU-Auslastung. 

• Es werden keine Benachrichtigungen gesendet, um einen Domänencontroller an einem Standort 

über verfügbare Verzeichnisänderungen zu informieren. Stattdessen wird der Replikationszeitpunkt 

anhand des Zeitplans festgelegt. 

Hinweis Sie können die Komprimierung für die standortübergreifende Replikation deaktivieren und 

Benachrichtigungen aktivieren. Weitere Informationen zu diesem Thema werden im Abschnitt „Konfigurieren 

der standortübergreifenden Replikation“ in diesem Kapitel bereitgestellt. 

• Standortübergreifende Replikationsverbindungen können für den Transport entweder IP (Internet 

Protocol, Internetprotokoll) oder SMTP (Simple Mail Transfer Protocol) verwenden. Das SMTP 

kann nur als Transportprotokoll für die Konfigurations-, Schema- und Anwendungsverzeichnispartition, 

nicht jedoch für die Domänenpartition verwendet werden. Das von Ihnen verwendete 

Verbindungsprotokoll wird durch die verfügbare Bandbreite und die Zuverlässigkeit des Netzwerks 

vorgegeben, über das die Unternehmensstandorte verbunden sind. 

• Der Replikationsdatenverkehr wird über Bridgeheadserver und nicht über mehrere Replikationspartner 

geleitet. Wenn Änderungen am Verzeichnis an einem Standort vorgenommen werden, werden 

die Änderungen auf einen einzelnen Bridgeheadserver (pro Verzeichnispartition) am Standort 

repliziert, und anschließend werden die Änderungen auf einen Bridgeheadserver an einem anderen 

Standort repliziert. Die Änderungen werden von dem Bridgeheadserver am zweiten Standort 

auf alle Domänencontroller an diesem Standort repliziert. 

• Der Replikationsfluss zwischen Standorten kann einfach bearbeitet werden. Änderungen können 

an nahezu jeder Komponente der standortübergreifenden Replikation vorgenommen werden. 

Wichtig Eines der wichtigsten Elemente eines AD DS-Entwurfs ist der Standortentwurf. Der Standortentwurf 

umfasst die Planung der Anzahl und der physischen Platzierung von Standorten sowie die Konfiguration 

standortübergreifender Verbindungen, um die Auslastung der Netzwerkbandbreite zu optimieren, während 

gleichzeitig die Replikationslatenz so gering wie möglich sein sollte. Konfigurationsoptionen für standortübergreifende 

Verbindungen werden später in diesem Kapitel erläutert, und Probleme beim Standortentwurf werden 

in Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, beschrieben. 

Replikationslatenz 

Aufgrund der Funktionsweise der Replikation in den Windows Server 2008-AD DS kann einige Zeit 

vergehen, bevor Änderungen, die auf einem Domänencontroller vorgenommen wurden, auf die verbleibenden 

Domänencontroller in einer Organisation repliziert werden. Diese Zeitverzögerung wird 

als Replikationslatenz bezeichnet. In den meisten Fällen kann die Replikationslatenz einfach berechnet 

werden, vor allem innerhalb eines Standorts.


Wie bereits erwähnt, wird jede Änderung, die am Datenspeicher eines Domänencontrollers vorgenommen 

wird, nach etwa 15 Sekunden auf die Replikationspartner des Domänencontrollers repliziert. 

Der Zieldomänencontroller behält diese Änderungen für 15 Sekunden und übergibt diese 

anschließend an seine Replikationspartner. Daher beträgt die Replikationslatenz innerhalb eines 

Standorts 15 Sekunden addiert mit der Anzahl an Abschnitten, die durchlaufen werden, bis alle 

Domänencontroller die Änderung erhalten haben. Wie im folgenden Abschnitt erläutert wird, umfasst 

die Replikationstopologie innerhalb eines Standorts nie mehr als drei Abschnitte, und daher beträgt 

die maximale Latenz bei der standortinternen Replikation in der Regel weniger als eine Minute. 

Das Ermitteln der standortübergreifenden Replikationslatenz ist etwas schwieriger. Als Erstes ist die 

Berechnung der Replikationslatenz innerhalb des Quellstandorts erforderlich. Die Replikationslatenz 

ist die Zeit, die benötigt wird, bis eine auf einem Domänencontroller an dem Standort vorgenommene 

Änderung auf den Bridgeheadserver des Quellstandorts repliziert wurde. Nachdem die Informationen 

am Bridgeheadserver des ursprünglichen Standorts angekommen sind, wird die zur Übertragung der 

Informationen an den Zielstandort benötigte Zeit durch den Zeitplan für die Standortverknüpfungen 

und das Replikationsintervall vorgegeben. Standardmäßig wird über Standortverknüpfungen alle drei 

Stunden eine Replikation durchgeführt. Wenn Sie keine Änderung an dieser Konfiguration vornehmen, 

werden der Replikationslatenz maximal drei Stunden hinzugefügt. Wenn die Informationen am 

Bridgeheadserver am Zielstandort angekommen sind, muss die standortinterne Replikationslatenz für 

den Zielstandort hinzugefügt werden. In einigen Fällen ist diese Replikationslatenz nicht akzeptabel. 

Um die Replikationslatenz zu verringern, können Sie das Replikationsintervall für die standortinterne 

Replikation auf bis zu 15 Minuten verkürzen. 

Bei der Verwaltung der Replikationslatenz muss ein Ausgleich zwischen dem erforderlichen kurzen 

Latenzzeitraum und den Bandbreiteneinschränkungen geschaffen werden. Wenn Sie die kürzestmögliche 

Latenzzeit erreichen möchten, sollten Sie alle Domänencontroller am gleichen Standort platzieren. 

In diesem Fall beträgt die Replikationslatenz für alle Domänencontroller etwa eine Minute. Wenn 

Ihre Unternehmensniederlassungen jedoch über WAN-Verbindungen mit eingeschränkter Bandbreite 

verbunden sind, benötigen Sie mehrere Standorte, um die Netzwerkauslastung für die AD DS-Replikation 

zu verwalten. Dadurch erhöht sich jedoch die Replikationslatenz. 

Dringende Replikation 

In einigen Fällen ist die im Abschnitt zuvor beschriebene Replikationslatenz zu lang. Dies ist insbesondere 

der Fall, wenn ein sicherheitsrelevantes Attribut im Verzeichnis geändert wurde. In diesen 

Fällen verwenden die AD DS die dringende Replikation, bei der ein Domänencontroller die Änderungen 

unmittelbar an seine Replikationspartner weiterleitet. Jeder Domänencontroller, der eine dringende 

Aktualisierung erhält, leitet diese ebenfalls unmittelbar weiter. Auf diese Weise werden alle 

Domänencontroller am Standort innerhalb von Sekunden aktualisiert. Die folgenden Änderungstypen 

lösen eine dringende Replikation aus: 

• Bearbeiten der Kontosperrrichtlinie für die Domäne 

• Bearbeiten der Kennwortrichtlinien 

• Verschieben des RID-Masters (Relative Identifier, relativer Bezeichner) auf einen neuen Domänencontroller 

• Ändern eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität), wenn beispielsweise 

das Kennwort eines Domänencontrollers geändert wird 

• Sperren eines Benutzerkontos, wenn ein Benutzer zu viele Anmeldeversuche mit einem ungültigen 

Kennwort ausführt

Erstellen der Replikationstopologie 109 

Standardmäßig werden dringende Aktualisierungen nur während der standortinternen und nicht während 

der standortübergreifenden Replikation angewendet. Dieses Standardverfahren für dringende 

Aktualisierungen kann geändert werden, indem die Replikationsbenachrichtigung zwischen Standorten 

aktiviert wird. 

Benutzerkennwortänderungen werden nicht über die dringende Replikation repliziert. Stattdessen 

wird bei einer Benutzerkennwortänderung auf einem Domänencontroller diese Änderung direkt auf 

den PDC-Emulator für die Domäne repliziert. Diese Replikation wird über Standortgrenzen hinweg 

durchgeführt, und dabei wird nicht auf die Bridgeheadserver an jedem Standort zurückgegriffen. Der 

Domänencontroller, auf dem die Änderung vorgenommen wurde, nutzt stattdessen eine RPC-Verbindung 

mit dem PDC-Emulator, um das Kennwort zu aktualisieren. Der PDC-Emulator aktualisiert 

anschließend alle weiteren Domänencontroller über das normale Replikationsverfahren. Wenn der 

Benutzer einen Anmeldeversuch an einem Domänencontroller vornimmt, der das neue Kennwort 

noch nicht erhalten hat, führt der Domänencontroller eine Überprüfung des PDC-Emulators durch, 

um zu prüfen, ob Kennwortänderungen für den Benutzer vorgenommen wurden, dem zuvor die 

Anmeldung verweigert wurde. 

Erstellen der Replikationstopologie 

Um die AD DS-Replikation verstehen zu können, müssen Sie wissen, auf welche Weise die Replikationstopologie 

erstellt wird. Standardmäßig wird das Verfahren zum Erstellen der Replikationstopologie 

automatisch von den AD DS durchgeführt. Wenngleich eine manuelle Konfiguration der Replikationstopologie 

möglich ist, stellt die Standardkonfiguration des Systems in der Regel die beste Option 

dar. 

Um die Replikationstopologie erfolgreich erstellen zu können, werden die folgenden Komponenten 

benötigt: 

• Routingfähige IP-Infrastruktur Um eine standortinterne Replikation zu konfigurieren, ist die Konfiguration 

der AD DS-Standorte sowie die Zuordnung der Standorte zu IP-Subnetzadressbereichen 

erforderlich. Domänencontroller und Clientcomputer nutzen dieses IP-Subnetz beim Ermitteln 

von Domänencontrollern für die Standortzuordnung. 

• DNS Die AD DS-Replikationstopologie erfordert DNS, damit die Domänencontroller ihre Replikationspartner 

ermitteln können. DNS speichert ferner SRV-Ressourceneinträge, die Clients 

Standortaffinitätsinformationen für die Ermittlung von Domänencontrollern bereitstellen. 

• Netzwerkanmeldedienst Der Netzwerkanmeldedienst ist für DNS-Registrierungen erforderlich. 

Außerdem muss der Netzwerkanmeldedienst zur ordnungsgemäßen Funktion der AD DS ausgeführt 

werden. 

• RPC-Verbindung AD DS-Domänencontroller müssen mithilfe von RPCs eine Verbindung mit 

Domänencontrollern in der gleichen Domäne herstellen können. RPCs müssen zwischen Domänencontrollern 

am gleichen Standort sowie an unterschiedlichen Standorten verwendet werden, 

wenn sich die Domänencontroller in der gleichen Domäne befinden. Bei SMTP handelt es sich 

um ein alternatives Protokoll, das von Domänencontrollern in unterschiedlichen Domänen und 

Standorten verwendet werden kann. 

• Standortübergreifender Messagingdienst Der standortübergreifende Messagingdient wird für die 

standortübergreifende Replikation über SMTP sowie für Berechnungen zur Standortabdeckung 

benötigt. Wenn als Gesamtstrukturfunktionsebene Windows 2000 festgelegt ist, ist der standortübergreifende 

Messagingdienst auch für die standortübergreifende Topologieerstellung erforderlich.


Konsistenzprüfung 

Die Konsistenzprüfung (Knowledge Consistency Checker, KCC) ist das auf jedem Domänencontroller 

ausgeführte Verfahren zum Erstellen der standortinternen und der standortübergreifenden Replikationstopologie. 

Sobald ein Domänencontroller zu einer AD DS-Gesamtstruktur hinzugefügt wurde, 

beginnt die Konsistenzprüfung mit dem Erstellen einer effizienten und fehlertoleranten Replikationstopologie. 

Beim Hinzufügen weiterer Domänencontroller zu einem Standort oder beim Hinzufügen 

zusätzlicher Standorte nutzt die KCC die Informationen zu Servern, Standorten, Standortverknüpfungen 

und Zeitplänen, um die optimale Replikationstopologie zu erstellen. 

Die KCC wird auf jedem Domänencontroller ausgeführt. Sie nutzt die in der Konfigurationsverzeichnispartition 

auf jedem Domänencontroller gespeicherten Informationen, um eine Replikationstopologie 

zu erstellen. Da alle Domänencontroller die gleichen Konfigurationsinformationen und den 

gleichen Algorithmus zum Erstellen der Topologie verwenden, wird die Topologie ohne direkte Kommunikation 

zwischen KCC-Komponenten auf unterschiedlichen Domänencontrollern erstellt. Die 

KCC kommuniziert nur mit anderen KCCs, um über eine RPC-Anforderung Informationen zu Replikationsfehlern 

anzufordern. 

Die KCC behandelt darüber hinaus Änderungen oder Fehler innerhalb der Replikationstopologie 

dynamisch. Wenn ein Domänencontroller für einen gewissen Zeitraum offline ist, ändert die KCC die 

Replikationstopologie, um den nicht verfügbaren Domänencontroller zu umgehen. Standardmäßig 

nimmt die KCC auf jedem Domänencontroller alle 15 Minuten eine Neuberechnung der Replikationstopologie 

vor. Sie können jederzeit eine Neuberechnung der Replikationstopologie durch die KCC 

mithilfe des Verwaltungstools Active Directory-Standorte und -Dienste erzwingen, indem Sie den Server 

ermitteln, auf dem Sie die Replikationstopologie überprüfen möchten. Klicken Sie mit der rechten 

Maustaste im Container Servers auf den Container NDTS Settings, wählen Sie Alle Aufgaben, und 

klicken Sie anschließend auf Replikationstopologie überprüfen. Sie können die Neuberechnung der 

Replikationstopologie durch den Domänencontroller auch mithilfe des Befehls Repadmin /kcc Domänencontrollername 

überprüfen. 

Verbindungsobjekte 

Wenn die KCC eine Replikationstopologie erstellt, erstellt sie mehrere Verbindungsobjekte, die in der 

Konfigurationsverzeichnispartition der AD DS gespeichert werden. Bei den Verbindungsobjekten 

handelt es sich um direkte logische Verbindungen zwischen Domänencontrollern, die für die Replikation 

der Verzeichnisinformationen verwendet werden. Die KCC versucht eine Replikationstopologie 

zu erstellen, die sowohl effizient als auch fehlertolerant ist. Durch die KCC werden alle zum Erreichen 

dieser Ziele erforderlichen Verbindungsobjekte erstellt. 

Verbindungsobjekte werden immer als unidirektionale Pull-Verbindungen zwischen zwei Domänencontrollern 

erstellt. Der Grund hierfür ist, dass das normale Replikationsverfahren immer einen Pull- 

Vorgang darstellt, wobei der Zieldomänencontroller die Informationen von einem sendenden Domänencontroller 

anfordert. In den meisten Fällen baut die KCC zwei unidirektionale Verbindung zwischen 

Domänencontrollern auf, sodass die Informationen in beide Richtungen repliziert werden können. 

In der Regel sind die automatisch von der KCC erstellten Objekte optimiert, daher müssen daran 

keine Änderungen vorgenommen werden. Unter bestimmten Umständen kann es jedoch erforderlich 

sein, Änderungen an den Verbindungsobjekten vorzunehmen. Es kann beispielsweise im Rahmen der 

AD DS-Problembehandlung vorkommen, dass Änderungen an einem Verbindungsobjekt vorzunehmen 

sind.


Zum Bearbeiten der Standardverbindungsobjekte haben Sie zwei Möglichkeiten: Sie können Einstellungen 

eines durch die KCC erstellen Verbindungsobjekts ändern, oder Sie können neue Verbindungsobjekte 

hinzufügen. 

Bearbeiten eines durch die KCC erstellten Verbindungsobjekts 

Sie können den Zeitplan und den Quelldomänencontroller für ein Verbindungsobjekt innerhalb eines 

Standorts ändern, und Sie können darüber hinaus das Übertragungsprotokoll für Verbindungsobjekte 

zwischen Standorten bearbeiten. Das Verbindungsdialogfeld wird in Abbildung 4.2 dargestellt. Standardmäßig 

überprüfen Domänencontroller innerhalb eines Standorts sämtliche Replikationspartner 

alle 15 Minuten auf fehlende Aktualisierungen. Sie können dieses Intervall ändern, um diese Überprüfung 

nie, stündlich oder alle 30 Minuten durchzuführen. Wenn Sie ein Verbindungsobjekt bearbeiten, 

wird es von in die GUID des Objekts umbenannt. Sie können das Objekt 

nach dem Bearbeiten umbenennen. 

Abbildung 4.2 

Bearbeiten eines vorhandenen Verbindungsobjekts 

Erstellen eines neuen Verbindungsobjekts 

Sie können auch ein vollständig neues Verbindungsobjekt erstellen, um eine bestimmte Replikationstopologie 

zu erzwingen. Beim Erstellen eines Verbindungsobjekts haben Sie die Möglichkeit, den 

Domänencontroller auszuwählen, von dem die Änderungen abgerufen werden. Sie können außerdem 

alle weiteren Einstellungen der Verbindungsvereinbarung bearbeiten. 

Die KCC löscht keine manuell bearbeiteten oder erstellten Verbindungen. Sie verwendet manuelle 

Verbindungsobjekte wie jede andere Verbindung, unter Umständen nimmt die KCC jedoch eine 

erneute Konfiguration der Verbindungsobjekte am Standort vor, um die manuell erstellten Verbindungen 

auszugleichen.


Standortinterne Replikationstopologie 

Innerhalb eines einzelnen Standorts erstellt die KCC eine Replikationstopologie, die redundante Verknüpfungen 

umfasst. Das primäre Ziel bei einem AD DS-Replikationsentwurf ist die Verfügbarkeit 

sowie die Fehlertoleranz. Wenn ein einzelner Domänencontroller nicht verfügbar ist, sollte das nicht 

dazu führen, dass keine AD DS-Replikation durchgeführt werden kann. Der Nachteil der Verwendung 

redundanter Verknüpfungen besteht darin, dass ein Domänencontroller unter Umständen mehrfach 

die gleiche Aktualisierung erhält, da jeder Domänencontroller über mehrere Replikationspartner 

verfügt. Wie bereits zuvor beschrieben, wird bei der AD DS-Replikation die Propagierungsdämpfung 

verwendet, um mehrfache Aktualisierungen derselben Informationen zu vermeiden. 

Beim Hinzufügen von Domänencontrollern mit Replikaten bestimmter AD DS-Partitionen zur Organisation 

beginnt die KCC automatisch mit dem Erstellen der Replikationstopologie. Diese Topologie 

bildet einen Replikationsring. In Abbildung 4.3 wird ein Beispiel einer einfachen Netzwerkstruktur 

mit drei Domänencontrollern in der gleichen Domäne und einem einzelnen Standort angezeigt. 

DC1.Adatum.com 



Abbildung 4.3 

Ein einfacher Replikationsring 

Wie in Abbildung 4.3 dargestellt, erstellt die KCC einen Replikationsring, in dem jeder Domänencontroller 

mit zwei eingehenden Replikationsverbindungen konfiguriert wird. Ist eine der Verbindungen 

nicht verfügbar, können Aktualisierungen weiterhin über die andere Verbindung empfangen 

werden. Darüber hinaus wird jeder Domänencontroller als Quelldomänencontroller für die beiden 

anderen Domänencontroller konfiguriert. Dadurch wird ein redundanter Ring für jeden Domänencontroller 

erstellt. Beim Hinzufügen weiterer Domänencontroller mit einem Replikat einer bestimmten 

Partition ist ein zweiter Grundsatz für das Erstellen von Verbindungen wichtig. Die KCC erstellt 

immer eine Replikationstopologie, in der jeder Domänencontroller an einem Standort nur drei 

Abschnitte von jedem beliebigen weiteren Domänencontroller entfernt ist. Sobald mehr als sieben 

Domänencontroller mit der gleichen Verzeichnispartition an einem Standort vorhanden sind, werden 

zusätzliche Verbindungsobjekte erstellt, um die mögliche Anzahl an Abschnitten auf drei oder weniger 

zu reduzieren. Der in Abbildung 4.4 dargestellte Standort verfügt beispielsweise über neun Domänencontroller. 

Die Replikationstopologie dieses Standorts würde mindestens eine zusätzliche Verbindung 

umfassen. 

Replikationsringe basieren auf Verzeichnispartitionen. Das bedeutet, dass die KCC für jede Verzeichnispartition 

einen Replikationsring berechnet. Eine Organisation kann beispielsweise über mehrere 

Domänen an einem einzelnen Standort und über eine Verzeichnisdienstreplikation verfügen, die auf 

mehrere Domänencontroller am Standort repliziert wird. Die Konfiguration könnte wie in 

Abbildung 4.5 dargestellt eingerichtet werden.








DC9.Adatum.com DC8.Adatum.com DC7.Adatum.com 

Abbildung 4.4 

Ein Replikationsring mit mehr als sieben Domänencontrollern 

Adatum.com 

Replikationsring der 

Domänenpartition 



Partition AnwPartition1 



AnwPartition1 

Replikationsring 

der Partition 





Replikationsring der 





DC6.TreyResearch.com 






Hinweis: Alle Domänencontroller umfassen auch ein Replikat der Konfigurations- und Schemapartition. Der Replikationsring 

für die Konfigurations- und Schemapartition würde alle Domänencontroller umfassen. 

Abbildung 4.5 

Replikationsringe werden für jede Verzeichnispartition erstellt.


In dem in Abbildung 4.5 dargestellten Szenario würden die in Tabelle 4.1 dargestellten Replikationsringe 

erstellt. 

Tabelle 4.1 

Replikationsringe in einem komplexen Standort 

Verzeichnispartition 

Konfigurationsverzeichnispartition, Schemaverzeichnispartition 

Verzeichnispartition der Domäne Adatum.com 

Verzeichnispartition der Domäne TreyResearch.com 


Anwendungsverzeichnispartition AnwPartition1 

Replikationspartner 

Alle Domänencontroller würden in den Replikationsring integriert, 

sowohl für die Konfigurationsverzeichnispartition als auch für die 

Schemaverzeichnispartition. 

DC1.Adatum.com, DC2.Adatum.com, 

DC3.Adatum.com, DC5.Adatum.com 

DC4.TreyResearch.com, DC6.TreyResearch.com 

DC1.Adatum.com, DC4.Adatum.com, 


DC2.Adatum.com, DC6.TreyResearch.com 

Hinweis Die DNS-Anwendungsverzeichnispartitionen (ForestDnsZones und DomainDnsZones) werden 

ebenfalls in die Replikationstopologie integriert. Um das in Abbildung 4.5 dargestellte Szenario einfacher zu 

gestalten, werden diese Partitionen weder in der Abbildung noch in der damit verbundenen Tabelle aufgeführt. 

Wie bereits in Kapitel 3, „Active Directory-Domänendienste und DNS“, erläutert, werden diese Partitionen 

genau wie alle anderen Domänenverzeichnispartitionen behandelt. Die Replikationstopologie des 

globalen Katalogs wird in Abbildung 4.5 ebenfalls nicht dargestellt. Das Verfahren zum Erstellen eines Replikationsrings 

für den globalen Katalog weist leichte Unterschiede zu den übrigen Partitionen auf und wird im 

folgenden Abschnitt beschrieben. 

Die Replikationsverbindungen und der Replikationsstatus können mithilfe des Befehlszeilenprogramms 

Repadmin mit dem Parameter /showrepl angezeigt werden. In Abbildung 4.6 wird ein Teil 

der Ausgabe angezeigt, wenn dieser Befehl auf einem Domänencontroller in einer Gesamtstruktur mit 

mehreren Domänen und Standorten ausgeführt wird. 

Bei dem Replikationsring handelt es sich um ein logisches Konzept. Bei der tatsächlich mit den Verbindungsobjekten 

implementierten Replikationstopologie werden keine doppelten Replikationsringe 

erstellt. Wenngleich ein eigener Replikationsring für jede Verzeichnispartition erstellt wird, erstellt die 

KCC keine zusätzlichen Verbindungsobjekte für jeden Replikationsring. Stattdessen verwendet die 

KCC Verbindungsobjekte mehrfach, um so wenig Verbindungsobjekte wie möglich verwenden zu 

müssen und gleichzeitig eine Replikationstopologie zu erstellen, die Redundanz für jede Partition 

bereitstellt. In dem in Abbildung 4.5 dargestellten Beispiel verfügt DC2.Adatum.com beispielsweise 

über ein Verbindungsobjekt mit DC6.TreyResearch.com. Dieses einzelne Verbindungsobjekt sollte für 

die Replikation der Schemapartition, der Konfigurationspartition sowie der Partition AnwPartition1 

und der DNS-Anwendungsverzeichnispartitionen verwendet werden. Sie können sehen, welche Verzeichnispartitionen 

über welches Verbindungsobjekt repliziert werden, indem Sie das Verbindungsobjekt 

mithilfe des Tools Repadmin bzw. über das Verwaltungstool Active Directory-Standorte und 

-Dienste anzeigen. Wie in Abbildung 4.6 dargestellt, können Sie die Einstellung Replizierte Namenskontexte 

für jedes Verbindungsobjekt anzeigen. Darüber hinaus können Sie mithilfe des Befehls 

Repadmin /showconn Servername die von jedem Verbindungsobjekt replizierten Partitionen anzeigen. 

In Abbildung 4.7 wird ein Teil der Ausgabe dieses Befehls dargestellt. In dieser Abbildung 

können Sie sehen, dass das Verbindungsobjekt mit SEA-DC2.Adatum.com für die Replikation der 

Partitionen DomainDnsZones, ForestDnsZones, Adatum.com sowie der Konfigurations- und Schemapartitionen 

verwendet wird.


Abbildung 4.6 

Verwenden des Befehls Repadmin zum Anzeigen von Replikationsverbindungen 

Abbildung 4.7 

Ein einzelnes Verbindungsobjekt, das für die Replikation mehrerer Verzeichnispartitionen verwendet wird


Replikation des globalen Katalogs 

Der globalen Katalog ist eine Partition, die sich von den übrigen Partitionen dahingehend unterscheidet, 

dass sie aus allen Domänendatenbanken in der Gesamtstruktur gebildet wird. Der globale Katalog 

selbst ist auf allen Domänencontrollern schreibgeschützt, und daher können die Informationen im 

globalen Katalog nicht direkt durch den Administrator bearbeitet werden. Bei dem globalen Katalog 

handelt es sich einfach um eine Liste aller Attribute, die in den globalen Katalog verschoben wurden, 

da für ihr Attribut isMemberOfPartialAttributeSet der Wert true festgelegt wurde. 

Dadurch, dass der globale Katalog aus den Domänendatenbanken erstellt wird, ergeben sich Auswirkungen 

auf den Replikationsring des globalen Katalogs. Jeder globale Katalogserver muss die 

Informationen des globalen Katalogs von den Domänencontrollern in allen Domänen erhalten. 

In Abbildung 4.8 wird als einfaches Beispiel ein Unternehmen mit zwei Domänen an einem Standort 

dargestellt, bei dem jede Domäne über einen Domänencontroller verfügt. Nur die Domäne 

DC1.Adatum.com ist als globaler Katalogserver konfiguriert. Der globale Katalogserver ist außerdem 

der einzige Domänencontroller der Domäne Adatum.com, daher extrahiert er die globalen Kataloginformationen 

für die Domäne Adatum.com aus seiner eigenen Domänendatenbank. Der Domänencontroller 

in der Domäne TreyResearch.com verfügt lediglich über eine Kopie der Domänenverzeichnispartition. 

Daher sammelt die Domäne DC1.Adatum.com die globalen Kataloginformationen für die 

Domäne TreyResearch.com von der Domäne DC2.TreyResearch.com. Um die Informationen von der 

Domäne TreyResearch.com zu extrahieren, wird ein Verbindungsobjekt von der Domäne DC2.Trey- 

Research.com zur Domäne DC1.Adatum.com erstellt, und diese Verbindung wird dann für die Replikation 

der Informationen des globalen Katalogs auf die Domäne DC1.Adatum.com verwendet. 

Verbindungsobjekt zum Replizieren 

der Informationen des globalen 

Katalogs von TreyResearch.com 

auf den globalen Katalogserver 


Globaler Katalog 

Abbildung 4.8 


Beispiel einer einfachen Replikation des globalen Katalogs 

In Abbildung 4.9 wird ein komplexeres Beispiel zum Erstellen und Replizieren des globalen Katalogs 

dargestellt. In diesem Szenario wird ein Verbindungsobjekt von einem Domänencontroller in 

jeder Domäne auf jedem globalen Katalogserver konfiguriert. Die Domäne DC1.Adatum.com verfügt 

beispielsweise über ein eingehendes Verbindungsobjekt von den Domänen DC2.Adatum.com, 

DC4.TreyResearch.com und DC6.Contoso.com. Dieses Verbindungsobjekt wird zum Erstellen des 

globalen Katalogs auf der Domäne DC1.Adatum.com verwendet. Für alle übrigen globalen Katalogserver 

wird ein vergleichbarer Satz an Verbindungsobjekten erstellt. Darüber hinaus wird ein eigener 

Replikationsring für die Partition des globale Katalogs mit allen globalen Katalogservern erstellt.








Quellreplikation 


Replikationsring 


DC6. Contoso.com 

DC5. Contoso.com 


Abbildung 4.9 

Beispiel einer komplexeren Replikation des globalen Katalogs 

Standortübergreifende Replikationstopologie 

Beim Hinzufügen zusätzlicher Standorte zu einer Gesamtstruktur wird die Replikationstopologie 

immer komplexer. In einem Szenario mit mehreren Standorten muss für jeden Standort eine Replikationstopologie 

erstellt werden, und auch zwischen Standorten ist eine Replikationstopologie erforderlich. 

Um diese komplexen Anforderungen zu umgehen, gibt es zum Erstellen von Verbindungsobjekten 

für die standortübergreifende Replikation ein eigenes Verfahren. Innerhalb eines Standorts ist 

die KCC auf jedem Domänencontroller für das Erstellen der Verbindungsobjekte verantwortlich, die 

benötigt werden, um die erforderliche Replikationsredundanz für alle Partitionen sicherzustellen. 

Anschließend werden die Informationen zu den Verbindungsobjekten auf die übrigen Domänencontroller 

repliziert. Der Domänencontroller erhält außerdem Informationen zu den Verbindungsobjekten, 

die von anderen Domänencontrollern erstellt wurden. Beim nächsten Ausführen der KCC werden 

basierend auf den Informationen, die der Domänencontroller über andere Verbindungsobjekte am 

Standort erhalten hat, eventuell Verbindungsobjekte hinzugefügt oder gelöscht. Abschließend legen 

die KCCs auf allen Domänencontrollern an einem Standort die optimale Replikationskonfiguration 

fest. 

Ein vergleichbarer Ansatz wird beim Festlegen der Replikationstopologie zwischen Standorten verwendet 

– mit der Ausnahme, dass ein Domänencontroller an jedem Standort für die Entwicklung der 

standortübergreifenden Topologie verantwortlich ist. Die KCC auf einem Domänencontroller am 

Standort wird als Generator für standortübergreifende Topologie (Inter-Site Topology Generator, 

ISTG) für den Standort bestimmt. Unabhängig von der Anzahl an Domänen oder weiteren Verzeichnispartitionen 

an einem Standort gibt es nur einen ISTG pro Standort. Der ISTG ist für die Berechnung 

der geeigneten Replikationstopologie für den gesamten Standort verantwortlich. Dieses Verfahren 

umfasst die folgenden zwei Vorgänge:


• Ermitteln des Bridgeheadservers für jede Verzeichnispartition am Standort. Die Replikation zwischen 

Standorten wird immer von einem Bridgeheadserver an einem Standort an einen Bridgeheadserver 

an einem anderen Standort gesendet. Das bedeutet, dass die Informationen nur einmal 

über die Netzwerkverbindung zwischen den Standorten repliziert werden. 

• Erstellen der Verbindungsobjekte zwischen den Bridgeheadservern, um die Informationsreplikation 

zwischen den Standorten sicherzustellen. Da die Replikation zwischen Bridgeheadservern 

konfiguriert wird, werden, im Gegensatz zur standortinternen Replikation, keine redundanten Verbindungsobjekte 

konfiguriert. Der ISTG erstellt jedoch Verbindungsobjekte mit Bridgeheadservern 

in mehreren Standorten, wenn die Standortverknüpfungen so konfiguriert wurden, dass sie 

die Verbindungen aktivieren. 

Beim Hinzufügen eines neuen Standorts zur Gesamtstruktur ermittelt der ISTG an jedem Standort, 

welche Verzeichnispartitionen am neuen Standort vorhanden sind. Anschließend berechnet der ISTG 

die neuen Verbindungsobjekte, die für die Replikation der erforderlichen Informationen vom neuen 

Standort benötigt werden. Darüber hinaus bestimmt der ISTG für jede Verzeichnispartition einen 

Domänencontroller zum Bridgeheadserver. Der ISTG erstellt die erforderlichen Verbindungsvereinbarungen 

in seinem Verzeichnis, und diese Informationen werden anschließend auf den Bridgeheadserver 

repliziert. Der Bridgeheadserver erstellt anschließend eine Replikationsverbindung, bei der sich 

der Bridgeheadserver im Remotestandort befindet, und die Replikation beginnt. 

In Abbildung 4.10 wird das Erstellen einer Replikationstopologie dargestellt. In diesem Beispiel setzt 

sich die Gesamtstruktur aus zwei Standorten und zwei Domänen mit Domänencontrollern für jede 

Domäne an jedem Standort zusammen. Darüber hinaus verfügt jeder Standort über mindestens einen 

globalen Katalogserver. Das bedeutet, dass jeder Standort eine Verzeichnispartition für jede der 

Domänen und eine Partition des globalen Katalogs sowie die Schemaverzeichnispartition und die 

Konfigurationsverzeichnispartition umfasst. Zwei Bridgeheadserver werden an jedem Standort 

bestimmt, da die Replikation jeder dieser Partitionen zwischen den Standorten erforderlich ist. Einer 

der Bridgeheadserver an jedem Standort fungiert als Domänencontroller in der Domäne Adatum.com. 

Ein weiterer Bridgeheadserver muss an jedem Standort als Domänencontroller der Domäne Trey- 

Research.com fungieren. In dem in Abbildung 4.10 dargestellten Beispiel handelt es sich bei den 

Domänen DC1.Adatum.com und DC6.TreyResearch.com außerdem um globale Katalogserver. Das 

bedeutet, dass sie für die standortübergreifende Replikation globaler Kataloginformationen als 

Bridgeheadserver eingesetzt werden. Da die Schemaverzeichnispartition und die Konfigurationsverzeichnispartition 

für alle Domänencontroller freigegeben sind, kann eines der vorhandenen Verbindungsobjekte 

für die Replikation dieser Informationen verwendet werden. 

Hinweis Diese Erläuterungen zur Replikationstopologie basieren auf dem Standardverhalten der AD DS- 

Domänencontroller. Administratoren können Änderungen an diesem Standardverhalten vornehmen, vor 

allem für die standortübergreifende Replikation. Diese Änderung sowie die sich daraus ergebenden Auswirkungen 

werden später in diesem Kapitel erläutert. 

RODCs und die Replikationstopologie 

RODCs sind ebenfalls Bestandteil einer normalen AD DS-Replikation, und Verbindungsobjekte müssen 

zwischen RODCs und anderen Domänencontrollern erstellt werden. Da RODCs jedoch über 

schreibgeschützte Kopien der AD DS-Datenbank verfügen, erstellt die KCC nur einzelne unidirektionale 

Verbindungsobjekte von einem Domänencontroller mit einer beschreibbaren Kopie der Datenbank 

zu einem RODC. Der RODC kann nur Änderungen von anderen Domänencontrollern abrufen, 

er kann nicht als Replikationsquelle für ein beliebiges Verbindungsobjekt konfiguriert werden.


Adatum-Standort1 


DC1. Adatum.com 


Verbindungsobjekt 

für die 

Adatum.com- 


DC3. TreyResearch.com 



für die globale 

Katalogpartition 


für die 

TreyResearch.com- 








Objekte der standortübergreifenden Verbindung 

Für die RODC-Replikation besteht außerdem eine Einschränkung im Hinblick auf die Domänencontroller, 

die direkte Replikationspartner des RODCs werden können. RODCs können alle AD DS- 

Partitionen replizieren, mit Ausnahme der Domänenpartition von Windows Server 2003-Domänencontrollern. 

Darüber hinaus können RODCs alle Partitionen von anderen Windows Sever 2008- 

Domänencontrollern replizieren, sie müssen jedoch die Domänenpartition von einem Domänencontroller 

replizieren, auf dem Windows Server 2008 ausgeführt wird. Das bedeutet, dass jeder RODC 

ein Verbindungsobjekt mit einem Windows Server 2008-Domänencontroller benötigt, der über eine 

beschreibbare Kopie der Datenbank der RODC-Domäne verfügt. Dies bedeutet außerdem, dass es 

sich bei dem ersten Windows Server 2008-Domänencontroller bei einer Domänenaktualisierung von 

Windows Server 2003 nicht um einen RODC handeln kann. 

Wenn der RODC an einem eigenen Standort bereitgestellt wird, sollte der Windows Server 2008- 

Domänencontroller am nächstgelegenen Standort in der Topologie platziert werden. In Abbildung 

4.11 wird ein Beispiel einer möglichen RODC-Bereitstellung und der konfigurierten Verbindungsobjekte 

dargestellt.



Windows Server 

2008-Domänencontroller 




DC1. Adatum.com 


Unidirektionales 


für die Adatum.com- 


RODC in der 

Domäne 

Adatum.com 

Verbindungsobjekt für die 

Schema-, Konfigurations- und 

Anwendungspartition und die 





DC1.EMEA.Adatum.com 


RODC1.Adatum.com 


Unidirektionales 

Verbindungsobjekt für die 

Schema-, Konfigurationsund 

Anwendungspartition 

und die Partition des 

globalen Katalogs 


Replikationsverbindungsobjekte mit RODCs 

Konfigurieren der standortübergreifenden Replikation 

In den AD DS werden mehrere Standorte erstellt, um den Replikationsdatenverkehr zwischen Unternehmensniederlassungen 

steuern zu können, vor allem zwischen den Niederlassungen, die über langsame 

WAN-Verbindungen verbunden sind. Wie bereits in Kapitel 2 beschrieben, handelt es sich bei 

einem AD DS-Standort um einen Netzwerkstandort, bei dem alle Domänencontroller über schnelle 

und zuverlässige Verbindungen miteinander verbunden sind. Eine der Aufgaben beim Einrichten 

eines AD DS-Netzwerks besteht darin, festzulegen, an welcher Stelle die Standortgrenzen zu ziehen 

und an welcher Stelle die Standorte miteinander zu verbinden sind. 

Hinweis Es ist nicht einfach, eindeutige Kriterien für das Erstellen eines neuen Standorts zu definieren, da 

in diese Entscheidung eine große Anzahl an Variablen einbezogen werden muss. In Kapitel 5 werden die 

beim Erstellen eines neuen Standorts zu berücksichtigenden Aspekte ausführlich erläutert. In diesem Kapitel 

werden ferner viele weitere Punkte angesprochen, die Sie beim Entwerfen der Standorttopologie bedenken 

müssen.

Erstellen zusätzlicher Standorte 

Konfigurieren der standortübergreifenden Replikation 121 

Beim Installieren der AD DS wird ein einzelner Standort mit dem Namen Standardname-des-ersten- 

Standorts erstellt (der Standort kann umbenannt werden). Da Standorte in der Regel basierend auf 

Unternehmensniederlassungen erstellt werden, können Sie diesen Standort umbenennen, um den geografischen 

Standort der Domänencontroller genauer anzugeben. Werden keine zusätzlichen Standorte 

erstellt, werden alle nachfolgenden Domänencontroller bei der Installation diesem Standort hinzugefügt. 

Wenn Ihr Unternehmen jedoch über mehrere Unternehmensniederlassungen mit eingeschränkten 

Bandbreiten zwischen den Niederlassungen verfügt, möchten Sie sicherlich weitere 

Standorte erstellen. 

Zusätzliche Standorte werden mithilfe des Verwaltungstools Active Directory-Standorte und -Dienste 

erstellt (siehe Abbildung 4.12). Um einen neuen Standort zu erstellen, klicken Sie mit der rechten 

Maustaste auf den Container Sites und klicken anschließend auf Neuer Standort. 


Erstellen eines neuen Standorts in Active Directory-Standorte und -Dienste 

Beim Erstellen eines neuen Standorts müssen Sie den Standort mit einer vorhandenen Standortverknüpfung 

verbinden. Dadurch wird sichergestellt, dass der Standort automatisch in die Replikationstopologie 

integriert wird. Wählen Sie aus der Liste Verknüpfungsname die Standortverknüpfung aus, 

über die Sie diesen Standort mit anderen Standorten verbinden möchten. 

Jeder Standort wird mit mindestens einem IP-Subnetz in den AD DS verknüpft. Standardmäßig werden 

in den AD DS keine Subnetze erstellt, daher besteht Ihre erste Aufgabe in der Regel darin, alle 

mit dem Standort Standortname-des-ersten-Standorts verknüpften Subnetze zu erstellen.


Beim Erstellen zusätzlicher Standorte ist außerdem das Erstellen zusätzlicher Subnetze im Container 

Subnets in Active Directory-Standorte und -Dienste sowie die Verknüpfung der Subnetze mit dem 

neuen Standort erforderlich. 

Auf der DVD Stellen Sie beim Bearbeiten der Standortkonfiguration sicher, dass Sie alle vorgenommenen 

Änderungen dokumentieren. Sie können das auf der Begleit-CD bereitgestellte Spreadsheet ADDSSites.xlsx 

als Vorlage zum Dokumentieren der Standortkonfiguration verwenden. Zur Anzeige der Informationen zu allen 

Standorten in Ihrer Gesamtstruktur können Sie das auf der CD bereitgestellte Windows PowerShell-Skript 

ListADDSSites.ps1 nutzen. Denken Sie daran, dass Sie beim Ausführen eines Windows PowerShell-Skripts 

den vollständigen Pfad angeben müssen, und unter Umständen müssen Sie die Richtlinie zur Ausführung von 

PowerShell-Skripts ändern, um ein Skript ausführen zu können. 

Beispiele für VMScript-Skripts (Visual Basic Scripting Edition) zum Abrufen von Standortinformationen finden 

Sie auf der Script Center Script Repository-Website unter http://www.microsoft.com/technet/scriptcenter/ 

scripts/default.mspx?mfr=true. 

Um einen vorhandenen Domänencontroller an den Standort zu verschieben, klicken Sie mit der rechten 

Maustaste auf das Domänencontrollerobjekt im aktuellen Container Servers und wählen Verschieben. 

Sie können anschließend den Standort auswählen, an den Sie den Domänencontroller verschieben 

möchten. Wenn Sie einen neuen Domänencontroller installieren und Ihre Gesamtstruktur mehrere 

Standorte umfasst, können Sie den Standort zum Installieren des neuen Domänencontrollers auswählen. 

Standardmäßig wird der Domänencontroller vom Assistenten zum Installieren der Active Directory-Domänendienste 

an dem Standort platziert, an dem das IP-Subnetz mit der IP-Adresse des 

Domänencontrollers übereinstimmt. 

Wichtig Wenn Sie einen Domänencontroller an einen neuen Standort verschieben, ist es erforderlich, die 

IP-Konfiguration entsprechend des neuen Standorts des Domänencontrollers zu ändern. Darüber hinaus müssen 

Sie den Hosteintrag in DNS mithilfe des Befehls IPConfig /refreshDNS sowie die SRV-Einträge aktualisieren, 

indem Sie den Netzwerkanmeldedienst anhalten und dann erneut starten. Überprüfen Sie, ob Sie für alle 

Domänencontroller in der Domäne anhand ihres vollqualifizierten Domänennamens ein Ping ausführen können, 

nachdem Sie die Domänencontroller verschoben haben. 

Standortverknüpfungen 

Die AD DS-Objekte, die Standorte verbinden, werden als Standortverknüpfungen bezeichnet. Beim 

Installieren der AD DS wird eine Standortverknüpfung mit dem Namen DEFAULTIPSITELINK 

erstellt. Wenn Sie vor dem Hinzufügen weiterer Standorte keine zusätzlichen Standortverknüpfungen 

erstellen, wird jeder Standort in diese standardmäßig erstelle Standortverknüpfung integriert. Wenn 

alle WAN-Verbindungen zwischen Ihren Unternehmensniederlassungen im Hinblick auf Bandbreite 

und Kosten gleichwertig sind, können Sie diese Standardkonfiguration übernehmen. Wenn sämtliche 

Standorte über eine Standortverknüpfung verbunden sind, weist der Replikationsdatenverkehr zwischen 

allen Standorten die gleichen Eigenschaften auf. Wenn Sie eine Änderung an dieser Standortverknüpfung 

vornehmen, wird die Replikationskonfiguration für alle Standorte geändert. 

Auf der DVD Die Standortverknüpfungskonfiguration sollte unbedingt Bestandteil der Dokumentation zur 

Standortkonfiguration sein. Als Vorlage für die Dokumentation können Sie das auf der Begleit-CD bereitgestellte 

Spreadsheet ADDSSites.xlsx verwenden. Mithilfe des auf der Begleit-CD verfügbaren Skripts 

ListADDSSites.ps1 können die mit jedem Standort verbundenen Standortverknüpfungen aufgelistet werden.


Unter bestimmten Umständen möchten Sie die Replikationskonfiguration möglicherweise nicht auf 

alle Standorte anwenden. Wenn die Unternehmensniederlassungen beispielsweise über unterschiedliche 

Netzwerkverbindungen verknüpft sind, sollten AD DS-Informationen über Netzwerkverbindungen 

mit eingeschränkter Bandbreite seltener repliziert werden als über Netzwerkverbindungen mit 

einer höheren Bandbreite. Wenn Sie zwischen Standorten unterschiedliche Replikationseinstellungen 

konfigurieren möchten, müssen Sie zusätzliche Standortverknüpfungen erstellen und diesen die geeigneten 

Standorte zuweisen. 

Hinweis Das Erstellen einer Standortverknüpfung ersetzt nicht die Arbeit des ISTGs, es ermöglicht vielmehr 

erst die Arbeit des ISTGs. Nachdem eine Standortverknüpfung erstellt wurde, verwendet der ISTG die 

Standortverknüpfung, um die erforderlichen Verbindungsobjekte für die Replikation aller AD DS-Partitionen 

zwischen allen Standorten zu erstellen. 

Im Folgenden werden die Konfigurationsoptionen für alle Standortverknüpfungen dargestellt. In 

Abbildung 4.13 wird das Dialogfeld für die Konfiguration von Standortverknüpfungen dargestellt: 


Konfigurieren von Standortverknüpfungen 

• Kosten Bei den Kosten für eine Standortverknüpfung handelt es sich um einen durch den Administrator 

zugewiesenen Wert, der die relativen Kosten der Standortverknüpfung definiert. Die 

Kosten stellen in der Regel die Netzwerkverbindungsgeschwindigkeit sowie die mit der Nutzung 

der Verbindung verbundenen Aufwendungen dar. Diese Kosten sind besonders bei redundanten 

Standortverknüpfungen in der Organisation von großer Bedeutung, d.h. wenn die Replikation von 

einem Standort zu einem anderen über mehrere Pfade geleitet werden kann. Es wird immer der 

kostengünstigste Weg als Replikationspfad gewählt.


Wichtig Das Erstellen redundanter Standortverknüpfungen und das Konfigurieren von Kosten für die 

Standortverknüpfungen ist nur dann sinnvoll, wenn Sie über mehrere WAN-Verbindungen zwischen 

Standorten verfügen. Wenn Sie zwischen physischen Unternehmensstandorten nur eine Netzwerkverbindung 

betreiben, stellen zusätzliche Standortverknüpfungen keinen Nutzen dar. 

• Replikationszeitplan Anhand des Replikationszeitplans wird definiert, zu welchen Tageszeiten die 

Standortverknüpfung für die Replikation genutzt werden kann. Im Rahmen des Standardreplikationszeitplans 

kann die Replikation 24 Stunden täglich vorgenommen werden. Wenn jedoch die 

verfügbare Bandbreite an einem Standort sehr beschränkt ist, möchten Sie die Replikation unter 

Umständen außerhalb der Arbeitszeiten durchführen. 

• Replikationsintervall Mithilfe des Replikationsintervalls werden die Intervalle definiert, in denen 

die Bridgeheadserver die Bridgeheadserver an anderen Standorten auf verfügbare Verzeichnisaktualisierungen 

überprüfen. Standardmäßig ist als Replikationsintervall für Standortverknüpfungen 

ein Wert von 180 Minuten festgelegt. Das Replikationsintervall wird ausschließlich während des 

Replikationszeitplans angewendet. Wenn entsprechend des Replikationszeitplans die Replikation 

zwischen 22.00 und 5.00 Uhr möglich ist, führen Bridgeheadserver während dieser Zeit alle drei 

Stunden eine Überprüfung auf verfügbare Aktualisierungen durch. 

• Replikationstransport Die Standortverknüpfung kann als Replikationstransportprotokoll entweder 

RPC über IP oder SMTP verwenden. Weitere Informationen zu diesem Thema finden Sie im 

Abschnitt „Replikationstransportprotokolle“ dieses Kapitels. 

Diese Optionen bieten erhebliche Flexibilität im Hinblick auf die Konfiguration der standortübergreifenden 

Replikation. Es gilt jedoch, einige Fehler zu vermeiden. Um verstehen zu können, auf welche 

Weise diese Optionen zusammenarbeiten, stellen Sie sich ein Unternehmensnetzwerk wie das in 

Abbildung 4.14 dargestellte vor. 

Standortverknüpfung 

Kosten 100 

Zeitplan 22:00 - 4:00 Uhr 

Intervall 30 Min 


Kosten 200 



Standort1 Standort2 Standort3 


Kosten 500 




Kosten 200 




Standort4 


Kosten 200 



Eine Standortverknüpfungskonfiguration 

Standort5 

In Windows Server 2008 AD DS werden alle Standortverknüpfungen standardmäßig als transitiv 

betrachtet. Dies bedeutet, dass Verbindungsobjekte zwischen Domänencontrollern erstellt werden 

können, die sich nicht an angrenzenden Standorten befinden. In Abbildung 4.14 verfügt Standort1 

beispielsweise über eine Standortverknüpfung mit Standort2, und Standort4 verfügt über eine Standortverknüpfung 

mit Standort2.


Dadurch, dass Standortverknüpfungen transitiv sind, können Domänencontroller an Standort1ebenfalls 

eine direkte Replikation mit Domänencontrollern an Standort3 und Standort5 durchführen. 

Der Pfad, über den der Replikationsdatenverkehr durch das Netzwerk geleitet wird, wird über die 

Standortverknüpfungskosten definiert. Wenn die KCC die Routingtopologie erstellt, wird das optimale 

Routing anhand der kumulierten Kosten für alle Standortverknüpfungen berechnet. In dem in 

Abbildung 4.14 dargestellten Beispiel gibt es zwei mögliche Routen zwischen Standort1 und 

Standort5: die erste Route führt über Standort2, die zweite Route führt über Standort4. Die Kosten der 

Route über Standort2 betragen 300 (100 + 200), die Kosten über Standort4 betragen 700 (500 + 200). 

Das bedeutet, dass der gesamte Replikationsdatenverkehr über Standort2 geleitet wird – es sein denn, 

die Verbindung ist nicht verfügbar. 

Wenn der Replikationsdatenverkehr über mehrere Standortverknüpfungen geleitet wird, werden 

anhand der Zeitpläne der Standortverknüpfungen und die Replikationsintervalle jedes Standorts der 

effektive Zeitrahmen und das Intervall für die Replikation bestimmt. Die effektive Replikation zwischen 

Standort1 und Standort3 findet beispielsweise zwischen 00.00 Uhr und 4.00 Uhr (die sich in den 

Zeitplänen überschneidende Zeit) alle 60 Minuten (das Replikationsintervall für die Standortverknüpfung 

zwischen Standort1 und Standort3) statt. 

Hinweis Wenn zwischen den Zeitplänen der Standortverknüpfungen keine zeitliche Überschneidung 

besteht, kann die Replikation zwischen mehreren Standorten trotzdem durchgeführt werden. Wenn beispielsweise 

die Standortverknüpfung zwischen Standort1 und Standort2 von 2.00 Uhr bis 6.00 Uhr und die 

Standortverknüpfung zwischen Standort2 und Standort3 zwischen 22.00 Uhr und 1.00 Uhr verfügbar ist, 

können die Verzeichnisänderungen zwischen Standort1 und Standort3 dennoch übertragen werden. Die 

Änderungen werden von Standort1 an Standort2 und anschließend von Standort2 an Standort3 gesendet. 

Die Replikationslatenz würde in diesem Fall jedoch fast einen Tag betragen, da die um 2.00 Uhr auf 

Standort2 replizierten Änderungen auf Standort3 nicht vor 22.00 Uhr repliziert würden. 

Zusätzliche Konfigurationsoptionen für Standortverknüpfungen 

Neben den im Verwaltungstool Active Directory-Standorte und -Dienste verfügbaren Konfigurationsoptionen 

für Standortverknüpfungen können Sie über den ADSI-Editor weitere Standortverknüpfungseinstellungen 

konfigurieren, oder Sie können zu diesem Zweck Änderungen an der 

Registrierung von Domänencontrollern vornehmen. Sie können beispielsweise die folgenden Einstellungen 

konfigurieren: 

• Deaktivieren der Komprimierung für die standortübergreifende Replikation Standardmäßig wird der 

gesamte standortübergreifende Replikationsdatenverkehr komprimiert. Die Komprimierung des 

Datenverkehrs stellt jedoch eine zusätzliche Belastung für den Prozessor des Domänencontrollers 

dar. Wenn Sie über eine ausreichende Bandbreite zwischen den AD DS-Standorten verfügen, 

können Sie in den Windows Server 2008-AD DS die Komprimierung deaktivieren. 

• Aktivieren der Benachrichtigung für die standortübergreifende Replikation Standardmäßig wird die 

Replikation zwischen Standorten basierend auf dem Zeitplan und der Replikationshäufigkeit 

durchgeführt, die in der Standortverknüpfung konfiguriert werden. Alternativ können Sie die 

Benachrichtigung für die standortübergreifende Replikation aktivieren. Wenn die Benachrichtigung 

aktiviert ist, benachrichtigt der Bridgeheadserver an einem Standort den Bridgeheadserver 

am Zielstandort über vorgenommen Änderungen, und die Änderungen werden dann über 

die Standortverknüpfung abgerufen. Dadurch kann der Replikationsdatenverkehr zwischen 

Standorten erheblich verringert werden, allerdings entsteht dadurch ein erhöhter Netzwerkdatenverkehr 

zwischen den Standorten.


Um die Komprimierung zu deaktivieren oder die Benachrichtigung für die standortübergreifende 

Replikation zu aktivieren, müssen Sie ein Tool wie den ADSI-Editor verwenden, um das 

Attribut Options für jedes Standortverknüpfungsobjekt oder Verbindungsobjekt zu bearbeiten. 

Um die Komprimierung zu deaktivieren, legen Sie für das Attribut Options den Wert 4 fest; 

zum Aktivieren der Benachrichtigung verwenden Sie den Wert 1. 

• Ändern der Replikationsdatenmenge Sie können die in einem Replikationspaket enthaltene 

Datenmenge ändern. Standardmäßig beträgt die Anzahl an Objekten die von Windows Server 

2008-Domänencontrollern in einem einzelnen Paket repliziert wird, 1/1.000.000 der Arbeitsspeichergröße, 

wobei mindestens 100 Objekte und höchstens 1000 Objekte repliziert werden. 

Die maximale Größe replizierter Objekte beträgt 1/100 der Arbeitsspeichergröße, wobei mindestens 

1 MB und höchstens 10 MB repliziert werden. Sie können diese Einstellung bearbeiten, 

indem Sie im Schlüssel HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ 

NTDS\Parameters die Werte Replicator inter site packet size (Objekte) und Replicator inter 

site packet size (Bytes) erstellen. 

Standortverknüpfungsbrücken 

In einigen Fällen kann es erforderlich sein, die Transitivität der Standortverknüpfungen zu deaktivieren, 

indem Sie die Standortverknüpfungsbrücke deaktivieren und Standortverknüpfungsbrücken 

manuell konfigurieren. Beim Konfigurieren von Standortverknüpfungsbrücken definieren Sie die 

transitiven und die nicht transitiven Standortverknüpfungen. Das Deaktivieren der Transitivität von 

Standortverknüpfungen kann sinnvoll sein, wenn Sie kein über kein vollständig geroutetes Netzwerk 

verfügen, d.h. wenn nicht alle Netzwerksegmente zu jeder Zeit verfügbar sind (z.B. wenn Sie über 

eine DFÜ-Verbindung oder eine Verbindung für einen Netzwerkspeicherort verfügen, die bei Bedarf 

aufgebaut wird). Standortverknüpfungsbrücken können außerdem für die Replikationskonfiguration 

verwendet werden, wenn ein Unternehmen über mehrere Standorte verfügt, die über ein Backbone 

mit mehreren kleinen Standorten verbunden sind, die wiederum über langsame Netzwerkverbindungen 

mit den größeren Standorten verbunden sind. In diesen Fällen können Standortverknüpfungsbrücken 

eingesetzt werden, um den Fluss des Replikationsdatenverkehrs effizienter zu verwalten. 

Weitere Informationen In Kapitel 5 werden ausführliche Informationen zur Verwendung von Standortverknüpfungsbrücken 


Beim Erstellen einer Standortverknüpfungsbrücke müssen Sie definieren, welche Standortverknüpfungen 

Teil der Brücke sein sollen. Alle der Standortverknüpfungsbrücke hinzugefügte Standortverknüpfungen 

werden als gegenseitig transitiv betrachtet, die nicht in die Standortverknüpfungsbrücke 

integrierten Standortverknüpfungen sind jedoch nicht transitiv. In dem zuvor beschriebenen Beispiel 

könnte eine Standortverknüpfungsbrücke für die Standortverknüpfungen erstellt werden, die Standort1, 

Standort2, Standort4 und Standort5 miteinander verbinden. All diese Standortverknüpfungen würden 

als transitiv betrachtet, d.h. ein Bridgeheadserver an Standort1 könnte eine direkte Replikation mit 

einem Bridgeheadserver an Standort5 durchführen. Da jedoch die Standortverknüpfung von Standort2 

und Standort3 nicht in die Standortverknüpfungsbrücke integriert ist, ist sie nicht transitiv. Das bedeutet, 

dass der gesamte Replikationsdatenverkehr von Standort3 nach Standort2 geleitet würde, und von 

dort an die verbleibenden Standorte. 

Um die transitiven Standortverknüpfungen zu deaktivieren, erweitern Sie im Verwaltungstool Active 

Directory-Standorte und -Dienste den Container Inter-Site Transport, klicken Sie mit der rechten


Maustaste auf IP, wählen Sie Eigenschaften, und deaktivieren Sie anschließend im IP-Eigenschaftendialogfeld 

auf der Registerkarte Allgemein die Option Brücke zwischen allen Standortverknüpfungen 

herstellen. 

Achtung Die Einstellung der Standortverknüpfungsbrücke betrifft alle Standortverknüpfungen, die das 

Transportprotokoll verwenden, für das Sie die Standortverknüpfungsbrücke deaktivieren. Dies bedeutet, 

dass alle Standortverknüpfungsbrücken deaktiviert sind, und Sie müssen nun Standortverknüpfungsbrücken 

für alle Standortverknüpfungen konfigurieren, die Sie als transitive Standortverbindungen konfigurieren 

möchten. 

Replikationstransportprotokolle 

Die Windows Server 2008-AD DS können eines der drei folgenden Transportprotokolle für die Replikation 

verwenden: 

• RPC über IP, standortintern Alle standortinternen Replikationsverbindungen müssen eine RPCüber-IP-Verbindung 

verwenden. Hierbei handelt es sich um eine synchrone Verbindung, d.h. dass 

der Domänencontroller keine Replikation mit mehreren Replikationspartnern gleichzeitig durchführen 

kann. Bei der RPC-Verbindung wird die dynamische Portzuordnung verwendet. Die erste 

RPC-Verbindung wird auf dem RPC-Endpunktzuordnungsport (TCP-Port 135) hergestellt. Diese 

Verbindung wird verwendet, um zu ermitteln, welcher Port auf dem Zieldomänencontroller für die 

Replikation verwendet wird. 

Hinweis Wenn die Replikation von Verzeichnisinformationen über eine Firewall erfolgt oder Sie Router 

mit Portfilterung verwenden, können Sie die Portnummer angeben, die die Domänencontroller für die 

Replikation verwenden. Erstellen Sie dafür den folgenden Registrierungsschlüssel als Wert vom Typ 

DWORD, und geben Sie eine gültige Portnummer an: HKEY_LOCAL_MACHINE\SYSTEM\ 

CurrentControlSet\Services\NTDS \Parameters\TCP/IP Port. 

• RPC über IP, standortübergreifend Standortübergreifende Replikationsverknüpfungen können 

ebenfalls RPC über IP verwenden. Diese RPC-Verbindung entspricht der standortinternen Verbindung, 

jedoch mit einer wichtigen Ausnahme: Standardmäßig wird der gesamte standortübergreifende 

Replikationsdatenverkehr komprimiert. 

Hinweis Wenn Sie sich im Verwaltungstool Active Directory-Standorte und -Dienste die beiden RPCüber-IP-Verbindungstypen 

ansehen, werden Sie feststellen, dass sie auf der Benutzeroberfläche unterschiedlich 

gekennzeichnet werden. Die standortinterne RPC-über-IP-Verbindung wird als RPC, die 

standortübergreifende RPC-über-IP-Verbindung wird als IP bezeichnet. 

• SMTP, standortübergreifend Replikationsverbindungen zwischen Standorten können für die standortübergreifende 

Informationsreplikation auch SMTP verwenden. SMTP empfiehlt sich als Replikationsprotokoll 

bei WAN-Verknüpfungen zwischen Unternehmensstandorten mit hoher Latenz. 

SMTP nutzt eine asynchrone Verbindung, d.h. der Domänencontroller kann eine Replikation mit 

mehreren Servern gleichzeitig durchführen. 

Konfigurieren der SMTP-Replikation 

Das Konfigurieren der SMTP-Replikation ist wesentlich komplizierter als die Konfiguration der 

standortübergreifenden RPC-über-IP-Replikation. Bei der RPC-über-IP-Replikation verwenden 

Domänencontroller integrierte Komponenten sowie die Kerberos-Authentifizierung, um die Replikation 

automatisch zu konfigurieren und zu schützen.


Führen Sie zur Konfiguration der SMTP-Replikation die folgenden Schritte aus: 

1. Installieren Sie das Feature SMTP-Server auf den Bridgeheadservern an beiden Standorten. Beim 

Installieren des Features SMTP-Server ist die Installation der erforderlichen Komponenten der 

Serverrolle Webserver (IIS) erforderlich. 

2. Installieren Sie die Active Directory-Zertifikatdienste, und konfigurieren Sie die Zertifizierungsstelle 

als Unternehmenszertifizierungsstelle. Die Zertifizierungsstelle wird für die Ausgabe von 

Zertifikaten für Domänencontroller verwendet, die für die Signatur und Verschlüsselung von zwischen 

Domänencontrollern ausgetauschten SMTP-Nachrichten verwendet werden. Bei Installieren 

einer Unternehmenszertifizierungsstelle werden von der Zertifizierungsstelle automatisch 

Domänencontrollerzertifikate für Domänencontroller ausgegeben, die sich in der gleichen Domäne 

wie die Unternehmenszertifizierungsstelle befinden. Diese Domänencontroller können die Zertifikate 

zum Schutz von SMTP-Daten verwenden. Für Domänencontroller in anderen Domänen in 

der Gesamtstruktur müssen Sie ein Domänencontrollerzertifikat oder ein Zertifikat für die Verzeichnis-E-Mail-Replikation 

manuell anfordern. 

Hinweis Sie können auch Zertifikate von öffentlichen Zertifizierungsstellen erwerben, die für die 

SMTP-Replikation verwendet werden können. 

3. Konfigurieren Sie SMTP-Standortverknüpfungen zwischen den beiden Standorten mit einem Kostenwert, 

der unter dem der eventuell vorhandenen RPC-über-IP-Standortverknüpfung liegt. Die 

beiden Standorte müssen nicht über Domänencontroller in der gleichen Domäne verfügen. 

4. Stellen Sie sicher, dass zwischen den beiden Domänencontrollern SMTP-E-Mail-Daten gesendet 

werden können. Wenn die Domänencontroller direkt über Port 25 kommunizieren können, ist 

keine weitere Konfiguration erforderlich. In einigen Fällen ist es jedoch erforderlich, dass Domänencontroller 

SMPT-Nachrichten an einen SMTP-Bridgheadserver und nicht direkt an den Zielbridgeheadserver 

weiterleiten. 

Konfigurieren von Bridgeheadservern 

Wie bereits erwähnt, wird die standortübergreifende Replikation über Bridgeheadserver vorgenommen. 

Standardmäßig ermittelt der ISTG den Bridgeheadserver automatisch, da er die standortübergreifende 

Replikationstopologie berechnet. Sie können mithilfe des Befehls Repadmin /bridgeheads 

anzeigen, welche Domänencontroller als Bridgeheadserver fungieren. In der Befehlsausgabe werden 

alle aktuellen Bridgeheadserver an allen Standorten aufgeführt, einschließlich der Verzeichnispartitionen, 

für die jeder Bridgeheadserver verantwortlich ist. Darüber hinaus wird in der Befehlsausgabe 

angezeigt, ob die letzte Replikation mit jeden Bridgeheadserver erfolgreich durchgeführt werden 

konnte. 

Wenn Sie den Befehl Repadmin /bridgeheads /v ausführen, wird in der Befehlsausgabe der letzte 

Replikationsversuch für jede Verzeichnispartition auf dem Bridgeheadserver sowie der Zeitpunkt der 

letzten erfolgreichen Replikation aufgeführt. In Abbildung 4.15 wird ein Teil der Ausgabe für diesen 

Befehl dargestellt. 

In bestimmten Situationen möchten Sie vielleicht festlegen, welche Domänencontroller als Bridgeheadserver 

fungieren. Für Bridgeheadserver sind unter Umständen zusätzliche Serverressourcen 

erforderlich, wenn an den Verzeichnisinformationen umfangreiche Änderungen vorgenommen wur-


den; wenn die Replikation den Einstellungen entsprechend sehr häufig vorgenommen wird, oder 

wenn die Organisation über Hunderte von Standorten verfügt. Um Server als Bridgeheadserver zu 

konfigurieren, müssen Sie im Verwaltungstool Active Directory-Standorte und -Dienste die Computerobjekte 

aufrufen, mit der rechten Maustaste auf den Servernamen klicken und Eigenschaften wählen. 

Das Eigenschaftendialogfeld wird in Abbildung 4.16 dargestellt. Sie können den Server als 

bevorzugten Bridgeheadserver entweder für IP- oder für SMTP-Transporte konfigurieren. 


Anzeigen des Bridgeheadserverstatus mithilfe des Befehls Repadmin 

Auf der DVD Wenn Sie einen Bridgeheadserver konfigurieren und sich später dann nicht mehr daran erinnern 

können, dass Sie diesen Bridgeheadserver konfiguriert haben, müssen Sie beim Ausfall dieses Bridgeheadserver 

unter Umständen viel Zeit in die Problembehandlung der AD DS-Replikation investieren. Stellen 

Sie daher sicher, dass die bevorzugten Bridgeheadserver für beide Replikationstransporttypen dokumentieren. 

Als Vorlage für die Dokumentation können Sie das auf der Begleit-CD verfügbare Spreadsheet ADDS- 

Sites.xlsx verwenden. 

Der Vorteil einen bevorzugten Bridgeheadservers besteht darin, dass Sie sicherstellen können, dass 

die von Ihnen gewählten Domänencontroller als Bridgeheadserver ausgewählt werden. Wenn Sie die 

vollständige Kontrolle darüber haben möchten, welche Server als Bridgeheadserver verwendet werden, 

müssen Sie einen bevorzugten Bridgeheadserver für jede Partition konfigurieren, für die die 

Replikation auf einen Standort erforderlich ist. Wenn beispielsweise ein Standort Replikate der Verzeichnispartition 

der Domäne Adatum.com, der Verzeichnispartition der Domäne TreyResearch.com, 

der Partition des globalen Katalogs sowie der Anwendungsverzeichnispartition umfasst, müssen Sie 

mindestens einen Domänencontroller mit einem Replikat dieser Partitionen konfigurieren.


Wenn Sie keine Bridgeheadserver für all diese Partitionen konfigurieren, erhalten Sie eine Warnmeldung 

wie die in Abbildung 4.17 dargestellte, und der ISTG protokolliert ein Ereignis im Ereignisprotokoll 

und wählt anschließend einen bevorzugten Bridgeheadserver für die Partition. Sie können auch 

mehrere bevorzugte Bridgeheadserver konfigurieren. In diesem Fall wählt der ISTG einen der ermittelten 

Server als Bridgeheadserver. 


Konfigurieren eines bevorzugten Bridgeheadservers 


Warnmeldung bei der Konfiguration von Bridgeheadservern für jede Verzeichnispartition

Problembehandlung bei der Replikation 131 

Sie sollten bei der Konfiguration dieser Option mit Vorsicht vorgehen. Durch die Konfiguration 

bevorzugter Bridgeheadserver werden die Möglichkeiten des ISTGs zum Auswählen des Bridgeheadservers 

eingeschränkt – er wählt immer einen Server, der als bevorzugter Bridgeheadserver konfiguriert 

wurde. Wenn dieser Server ausfällt und keine weiteren Server für diese Verzeichnispartition als 

Bridgeheadserver konfiguriert wurden, wählt der ISTG keinen anderen Bridgeheadserver, und die 

Replikation wird so lange eingestellt, bis der Server wieder verfügbar ist oder eine Neukonfiguration 

der Optionen für den bevorzugten Bridgeheadserver vorgenommen wird. Wenn der bevorzugte Bridgeheadserver 

ausfällt, können Sie entweder den Server als bevorzugten Bridgeheadserver entfernen 

und dem ISTG das Ermitteln eines Bridgeheadservers überlassen, oder Sie wählen einen anderen 

bevorzugten Bridgeheadserver. 

Achtung Wenn der Bridgeheadserver ausfällt und Sie eine Neukonfiguration des bevorzugten Bridgeheadservers 

durchführen, sind die Konfigurationsänderungen an beiden Standorten vorzunehmen. Da Bridgeheadserver 

nicht verfügbar sind, werden so lange keine Informationen zwischen den Standorten repliziert, 

bis die Konfigurationsänderungen an beiden Standorten vorgenommen wurden. Um Änderungen an einem 

Remotestandort vorzunehmen, stellen Sie im Verwaltungstool Active Directory-Standorte und -Dienste eine 

Verbindung mit einem Domänencontroller am Standort her. 

Problembehandlung bei der Replikation 

Wenn die AD DS-Replikation fehlschlägt, können Domänencontroller nicht mit Änderungen aktualisiert 

werden, die an anderen Domänencontrollern vorgenommen wurden. Dies kann dazu führen, dass 

Benutzer und Administratoren nicht über die gleichen Informationen verfügen, abhängig davon, mit 

welchem Domänencontroller Sie sich verbinden. Wenn Kennwort- oder Konfigurationsänderungen 

für Benutzer nicht repliziert werden, können Benutzer unter Umständen keine Anmeldung am Netzwerk 

durchführen. Werden Gruppenrichtlinieneinstellungen oder der Ordner SYSVOL nicht repliziert, 

werden für verschiedene Benutzer unter Umständen unterschiedliche Gruppenrichtlinieneinstellungen 

angewendet. Da die AD DS-Replikation besonders wichtig ist, sollten Sie sich auf die Problembehandlung 

bei der AD DS-Replikation vorbereiten. 

Verfahren für die Problembehandlung bei der AD DS-Replikation 

Der erste Schritt der Problembehandlung bei der AD DS-Replikation besteht darin, den Grund für den 

Fehler zu ermitteln. In vielen Fällen ist es problematisch, direkt zu ermitteln, aus welchem Grund die 

AD DS-Replikation fehlschlägt. Daher besteht die Problembehandlung oftmals darin, ein Ausschlussverfahren 

möglicher Fehler durchzuführen. Führen Sie als allgemeine Richtlinie zunächst die folgenden 

Schritte aus: 

1. Überprüfen Sie die Netzwerkverbindung. Wie bei den meisten anderen Verfahren zur Problembehandlung 

sollten Sie als Erstes überprüfen, ob die Domänencontroller über das Netzwerk miteinander 

kommunizieren können. Die Netzwerkverbindung ist unter Umständen nicht verfügbar, 

oder Netzwerkeinstellungen wurden ggf. nicht ordnungsgemäß konfiguriert. 

2. Überprüfen Sie die Namensauflösung. Einer der häufigsten Gründe für Replikationsfehler ist ein 

Fehlschlagen der DNS-Namensauflösung. Wenn Sie Fehlermeldungen erhalten, die auf eine 

Nichtverfügbarkeit der RPC-Server hinweisen, oder Sie Fehlermeldungen vom Typ Zielkontoname 

ist ungültig erhalten, überprüfen Sie, ob die Domänencontroller den vollqualifizierten Domänennamen 

(Fully-Qualified Domain Name, FQDN) des Zielservers auflösen können.


3. Prüfen Sie auf Authentifizierungs- und Autorisierungsfehler. Wenn Sie während der Replikation 

Fehlermeldungen aufgrund einer Zugriffsverweigerung erhalten, besteht ein Problem mit der 

Authentifizierung oder der Autorisierung. Um die Ursache des Sicherheitsfehlers zu ermitteln, 

führen Sie den Befehl dcdiag /test:CheckSecurityError /s:Domänencontrollername aus, wobei 

Domänencontrollername für den Namen des Domänencontroller steht, den Sie überprüfen möchten. 

Um die Verbindung zwischen zwei Domänencontrollern auf Replikationssicherheitsfehler zu 

überprüfen, führen Sie den Befehl dcdiag /test:CheckSecurityError /ReplSource:Name_des_ 

Quelldomänencontrollers aus. Mithilfe dieses Befehls wird die Verbindung zwischen dem Domänencontroller, 

auf dem Sie den Befehl ausführen, und dem Quelldomänencontroller (angegeben 

über Name_des_Quelldomänencontrollers) geprüft. In der Ausgabe dieser Befehle werden die 

Sicherheitsprobleme zwischen den Domänencontrollern ermittelt. Beheben Sie die Probleme, und 

führen Sie den Befehl erneut aus, um zu überprüfen, ob das Problem tatsächlich behoben ist. 

4. Überprüfen Sie die Ereignisanzeige der betroffenen Domänencontroller. Wenn die Replikation 

fehlschlägt, werden Ereignisse in die Ereignisanzeige geschrieben, in denen der Fehler näher 

beschrieben wird. 

5. Überprüfen Sie die Domänencontroller auf Leistungsprobleme. Wenn die Serverressourcen auf 

einem Domänencontroller nicht ausreichen, schlägt die Replikation unter Umständen fehl, oder 

die Replikationswarteschlange füllt sich mit Daten. Wenn der Domänencontroller beispielsweise 

auf dem Laufwerk, auf dem sich der AD DS-Datenspeicher befindet, nicht mehr über ausreichend 

Speicherplatz verfügt, wendet der Domänencontroller keine Replikationsänderungen an. In einigen 

Fällen kann eine verzögerte Replikation durch die Leistung des Domänencontrollers verursacht 

werden. Um Leistungsprobleme bei einem Domänencontroller zu beheben, führen Sie die 

folgenden Schritte aus: 

a. Verschieben Sie Anwendungen oder Dienste auf einen anderen Server. Wenn der Domänencontroller 

mehrere Rollen oder andere Anwendungen ausführt, sollten Sie unter Umständen 

die Rollen oder Anwendungen auf einen anderen Server im Netzwerk verschieben. 

b. Verteilen Sie die AD DS- und DNS-Rollen auf mehrere Server. Durch die AD DS-integrierten 

DNS-Zonen ergeben sich zwar Vorteile, wenn Sie jedoch die AD DS und die DNS-Dienste 

gemeinsam auf einem Server ausführen, können Leistungsprobleme entstehen. Durch die Verteilung 

der durch diese Dienste entstehenden Last können Sie die Auswirkungen auf die Serverleistung 

verringern. 

c. Stellen Sie Domänencontroller mit 64-Bit-Hardware bereit. Computer mit 64-Bit-Hardware 

bieten im Vergleich zu Domänencontrollern mit 32-Bit-Hardware erhebliche Leistungsverbesserungen. 

6. Überprüfen und bearbeiten Sie die Replikationstopologie. In größeren Organisationen mit Tausenden 

von Standorten kann die Berechnung der Replikationstopologie die gesamten Prozessorressourcen 

auf dem Domänencontroller verbrauchen, der die Rolle Standortübergreifende Topologie 

erstellen ausübt. Sie sollten in Betracht ziehen, die Anzahl der Standorte in der Organisation zu 

reduzieren oder bevorzugte Bridgheadserver zu konfigurieren. Vergewissern Sie sich außerdem, 

dass die AD DS-Standortverknüpfungskonfiguration der tatsächlichen WAN-Verbindungskonfiguration 

in Ihrem Netzwerk entspricht. Die AD DS-Replikation sollte – wann immer möglich – die 

WAN-Verbindungen mit der höchsten verfügbaren Bandbreite nutzen.


Weitere Informationen Zwei hervorragende Referenzen zur Problembehandlung bei speziellen AD DS- 

Replikationsfehlern finden Sie im Artikel „Troubleshooting Active Directory Replication Problems“ (in englischer 

Sprache) (http://technet2.microsoft.com/windowsserver/en/library/4f504103-1a16-41e1-853ac68b77bf3f7e1033.mspx?mfr=true) 

und im Artikel „So wird´s gemacht: Problembehandlung bei standortinternen 

Replikationsfehlern“ unter (http://support.microsoft.com/kb/249256). 

Tools für die Problembehandlung bei der AD DS-Replikation 

In Windows Server 2008 werden verschiedene Tools für die Problembehandlung bei der AD DS- 

Replikation bereitgestellt. Sämtliche dieser Tools werden auf Windows Server 2008 bei der Konfiguration 

des Servers als Domänencontroller installiert. 

Active Directory-Standorte und -Dienste 

Sie können das Verwaltungstool Active Directory-Standorte und -Dienste nicht nur für die Konfiguration 

von Standorten und der Replikation, sondern auch zum Durchführen von grundlegenden Problembehandlungsmaßnahmen 

verwenden. Zu diesen Aufgaben gehören: 

• Erzwingen der Neuberechnung der Replikationstopologie durch die KCC Erweitern Sie hierzu das 

Domänencontrollerobjekt im AD DS-Container mit den Standortservern, klicken Sie mit der rechten 

Maustaste auf NTDS Settings, wählen Sie Alle Aufgaben, und klicken Sie anschließend auf 

Replikationstopologie überprüfen. Dadurch wird die direkte Ausführung der KCC erzwungen und 

nicht auf die nächste geplante Aktualisierung gewartet. 

• Erzwingen des Abrufens von Replikationsänderungen durch einen Domänencontroller Ermitteln Sie 

den Domänencontroller, von dem Sie die Änderungen in dem Standortservercontainer abrufen 

möchten. Klicken Sie im Container NTDS Settings unterhalb des Domänencontrollers mit der 

rechten Maustaste auf das Verbindungsobjekt mit dem Domänencontroller, von dem Sie die Änderungen 

abrufen möchten, und klicken Sie auf Jetzt replizieren. Wenn beide Domänencontroller am 

gleichen Standort platziert sind, erhalten Sie entweder eine Fehlermeldung, oder Sie erhalten die 

Meldung, dass die Replikation erfolgreich durchgeführt wurde. Befinden sich die Domänencontroller 

an unterschiedlichen Standorten, werden Sie in einer Meldung darüber informiert, dass der 

Domänencontroller einen unmittelbaren Replikationsversuch unternimmt. Überprüfen Sie die 

Ereignisanzeige auf Replikationsfehler. 

• Erzwingen der Replikation der Konfigurationspartition von einem oder auf einen Domänencontroller 

Wenn Sie mit der rechten Maustaste auf das NTDS-Objekt unterhalb eines Domänencontrollers 

klicken, der zurzeit nicht im Tool Active Directory-Standorte und -Dienste ausgewählt ist, können 

Sie die Konfiguration von dem ausgewählten Domänencontroller oder auf den ausgewählten 

Domänencontroller replizieren. Einer der Vorteile dieser Befehle besteht darin, dass die Konfigurationsinformationen 

auch dann repliziert werden, wenn zwischen den Domänencontrollern kein 

Verbindungsobjekt vorhanden ist. Diese Option ist nützlich, wenn ein Replikationspartner von der 

Domäne entfernt wurde, während ein Domänencontroller offline war und der Domänencontroller 

andere Domänencontroller zum Erstellen neuer Verbindungsobjekte nicht ermitteln kann. 

Repadmin 

Das nützlichste Tool für die Überwachung und Problembehandlung bei der Replikation ist Repadmin. 

Mithilfe des Befehslzeilenprogramms Repadmin.exe können Sie die Replikationstopologie aus der 

Perspektive jedes Domänencontrollers anzeigen.


Sie können Repadmin.exe auch zum manuellen Erstellen der Replikationstopologie, zum Erzwingen 

von Replikationsereignissen zwischen Domänencontrollern und zum Anzeigen von Replikationsmetadaten 

und Aktualitätsvektoren (Up-To-Dateness Vector, UTDV) verwenden. 

Verwenden Sie für das Befehlszeilenprogramm Repadmin die folgende Syntax: 

repadmin Befehlsargumente [/u:[Domäne\]Benutzer /pw:{Kennwort|*}] 

Sie müssen die Benutzerkonteninformationen nur dann bereitstellen, wenn der derzeit angemeldete 

Benutzer kein Mitglied der Gruppe Domänen-Admins ist. 

In den folgenden Beispielen werden einige der für das Befehlszeilenprogramm Repadmin verfügbaren 

Befehlsargumente dargestellt: 

• Um Replikationsinformationen auf einem Domänencontroller in eine .csv-Datei zu importieren, 

verwenden Sie die folgende Syntax: 

Repadmin /showrepl DC1.Adatum.com /csv>Dateiname.csv 

Dieser Befehl ist nützlich, da Sie die .csv-Datei mithilfe einer Anwendung wie Microsoft Office 

Excel öffnen und durchsuchen können. 

• Um die Replikationspartner des Domänencontrollers DC1 anzuzeigen, verwenden Sie die folgende 

Syntax: 

repadmin /showreps DC1.Adatum.com 

• Um die höchste USN des Domänencontrollers DC2 anzuzeigen, verwenden Sie die folgende 

Syntax: 

repadmin /showvector dc=Adatum,dc=com DC2.Adatum.com 

• Um die Verbindungsobjekte des Domänencontrollers DC1 anzuzeigen, verwenden Sie die folgende 

Syntax: 

repadmin /showreps DC1.Adatum.com 

• Um ein Replikationsereignis zwischen zwei Replikationspartnern zu initiieren, verwenden Sie die 

folgende Syntax: 

repadmin /replicate DC2.Adatum.com DC1.Adatum.com dc=Adatum,dc=com 

• Um ein Replikationsereignis für eine bestimmte Verzeichnispartition mit sämtlichen Replikationspartnern 

zu initiieren, verwenden Sie die folgende Syntax: 

repadmin /syncall DC1.Adatum.com dc= Adatum,dc=com 

Wenn Sie diesen Befehl ausführen, fragt der Domänencontroller Aktualisierungen von allen 

direkten Replikationspartnern für alle Verzeichnispartitionen ab. Wenn Sie für den Domänencontroller 

die Replikation lokaler Änderungen erzwingen möchten, fügen Sie den Parameter /p am 

Ende des Befehls hinzu. 

Dcdiag 

Mit dem Tool Dcdiag.exe können Sie mehrere Tests durchführen, um die Domänencontroller auf Probleme 

zu überprüfen, die unter Umständen Auswirkungen auf die Replikation haben. Bei diesen Tests 

werden die Verbindung, Replikation, Topologieintegration sowie standortübergreifende Statustests 

durchgeführt. 

Verwenden Sie für das Befehlszeilenprogramm Dcdiag die folgende Syntax: 

dcdiag Befehlsargumente [/v /f:Protokolldatei /ferr:Fehlerprotokoll ]


Wenn Sie dem Befehl die Option /v hinzufügen, wird eine ausführliche Befehlsausgabe erstellt, durch 

die Option /f wird die Ausgabe in die Protokolldatei geleitet, und wenn Sie die Option /ferr hinzufügen, 

wird die Ausgabe für schwerwiegende Fehler in eine separate Protokolldatei geschrieben. Um 

sämtliche Dcdiag-Tests auf einem lokalen Computer auszuführen und die Ergebnisse im Fenster der 

Eingabeaufforderung anzuzeigen, geben Sie einfach DCdiag ein und drücken die EINGABETASTE. 

Um einen Remotedomänencontroller zu überprüfen, führen Sie den Befehl run DCDiag /s:Servername 

aus, wobei Servername für den Namen des Remotedomänencontrollers steht. 

Mit DCDiag können unter anderem die folgenden Tests ausgeführt werden: 

• Connectivity Bei diesem Test wird geprüft, ob Domänencontroller in DNS registriert sind, ob für 

sie ein Ping ausgeführt werden kann und ob sie über LDAP/RPC-Konnektivität verfügen. 

• Replications Bei diesem Test wird geprüft, ob die Replikation zeitgerecht ausgeführt wird und ob 

Fehler zwischen Domänencontrollern auftreten. 

• NetLogons Bei diesem Test wird geprüft, ob die für das Ausführen der Replikation erforderlichen 

Anmeldeberechtigungen vorhanden sind. 

• Intersite Prüft auf Fehler, welche die standortübergreifende Replikation verhindern oder vorübergehend 

anhalten würden, und es wird eine Prognose erstellt, welche Zeit die KCC für die Wiederherstellung 

benötigt. Die Ergebnisse dieses Tests liefern häufig keine gültige Aussage, vor allem 

in untypischen Standorten, bei untypischen KCC-Konfigurationen oder bei Verwendung der 

Gesamtstrukturfunktionsebene Windows Server 2008. 

• FSMOCheck Bei diesem Test wird überprüft, ob der Domänencontroller ein KDC, einen Zeitserver, 

einen bevorzugten Zeitserver, einen PDC und einen globalen Katalogserver kontaktieren 

kann. Bei diesem Test werden keine Betriebsmasterrollen von Servern getestet. 

• Services Bei diesem Test wird geprüft, ob die geeigneten Domänencontrollerdienste ausgeführt 

werden. 

• KccEvent Bei diesem Test wird geprüft, ob die KCC fehlerfrei ausgeführt werden kann. 

• Topology Bei diesem Test wird überprüft, ob die KCC eine vollständig verbundene Topologie für 

alle Domänencontroller erstellt hat. 

Hinweis Ausführliche Informationen zur Verwendung der Befehlszeilenprogramme Repadmin und DCDiag 

werden angezeigt, wenn Sie den Befehlsnamen gefolgt von /? eingeben. 

Zusätzliche Tools 

Für die Überwachung und Problembehandlung bei der Replikation gibt es zwei weitere nützliche 

Standardtools für die Serververwaltung. Bei dem ersten Tool handelt es sich um die Ereignisanzeige. 

Jeder Domänencontroller verfügt über ein Ereignisprotokoll namens Verzeichnisdienst. Ein Großteil 

der mit der Verzeichnisreplikation verbundenen Ereignisse werden in diesem Ereignisprotokoll 

erfasst, daher sollten Sie beim Fehlschlagen der Replikation zunächst dieses Protokoll überprüfen. 

Das Tool Zuverlässigkeits- und Leistungsüberwachung ist nützlich für die Überwachung der Replikationsaktivitäten 

auf dem Server. Wenn ein Server zu einem Domänencontroller heraufgestuft wird, 

werden der Liste der Leistungsindikatoren das Leistungsobjekt Verzeichnisdienste sowie verschiedene 

Leistungsobjekte in Bezug auf die Dateireplikation hinzugefügt. Anhand dieser Leistungsindikatoren 

können Sie die Menge des Replikationsdatenverkehrs sowie zahlreiche andere AD DS-bezogene 

Aktivitäten überwachen.



Das Verständnis der Funktionsweise der Replikation ist grundlegend für die Verwaltung der Windows 

Server 2008-AD DS. Eine stabile Replikationsumgebung ist für die Verwaltung einer aktuellen Kopie 

aller Verzeichnisinformationen auf allen Domänencontrollern in der Gesamtstruktur von entscheidender 

Bedeutung, und dies wiederum ist die Voraussetzung für eine konsistente Benutzeranmeldung 

und Verzeichnissuchleistung. Wenn Sie die Funktionsweise der standortinternen und der standortübergreifenden 

Replikation kennen, können Sie die optimale Replikationskonfiguration entwerfen und 

implementieren. 


• Die standortinterne Replikation wird automatisch und zeitnah durchgeführt, und es treten nur selten 

Fehler auf. Wenn alle Domänencontroller in Ihrem Unternehmen über schnelle Netzwerkverbindungen 

verfügen, sollten Sie einen einzelnen Standort implementieren. 

• Wenn Ihr Unternehmen jedoch mehrere Niederlassungen umfasst, an denen Sie Domänencontroller 

installieren, können Sie den AD DS-bezogenen Datenverkehr über WAN-Verbindungen mit 

eingeschränkter Bandbreite am einfachsten verwalten, indem Sie zusätzliche Standorte erstellen. 

Zusätzliche Standorte führen nicht nur zu einer Verringerung des Replikationsdatenverkehrs, sondern 

sorgen außerdem dafür, dass der Authentifizierungsdatenverkehr für Clients lokal verarbeitet 

wird. 

• Führen Sie eine regelmäßige Überwachung der AD DS-Replikation durch. Zur Überwachung aller 

Domänencontroller an einem Standort können Tools wie beispielsweise das Active Directory 

Management Pack mit dem System Center Operations Manager verwendet werden. Wenn Ihnen 

ein solches Tool nicht zur Verfügung steht, sollten Sie das Ereignisprotokoll Verzeichnisdienst und 

entweder das Ereignisprotokoll DFS-Replikation (bei Verwendung der Gesamtstrukturfunktionsebene 

Windows Server 2008) oder das Ereignisprotokoll Dateireplikationsdienst regelmäßig überwachen. 

• In den meisten Organisationen sind DNS-Lookupfehler der häufigste Grund für Fehler bei der 

AD DS-Replikation. Durch die Integration der DNS in die AD DS und das Nutzen der Vorteile 

von DNS-Verzeichnispartitionen können Sie das Auftreten von DNS-Fehlern verringern. 


Die folgenden Ressourcen enthalten zusätzliche Informationen und Tools im Zusammenhang mit 

diesem Kapitel. 


• Kapitel 14, „Überwachen und Warten von Active Directory“, enthält ausführliche Informationen 

zur Verwendung von Überwachungstools wie z.B. der Ereignisanzeige und der Zuverlässigkeitsund 

Leistungsüberwachung zur Überwachung von AD DS-Domänencontrollern und der Replikationsüberwachung. 

• Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, stellt detaillierte Informationen 

zum Entwerfen der DNS-Bereitstellung bereit.


• „Troubleshooting Active Directory Replication Problems” unter http://technet2.microsoft.com/ 

windowsserver/en/library/4f504103-1a16-41e1-853a-c68b77bf3f7e1033.mspx?mfr=true. Auf dieser 

Webseite werden ausführliche Schrittanleitungen für die Problembehandlung bei der Active 

Directory-Replikation sowie Verknüpfungen zu Knowledge Base-Artikeln aufgeführt, in denen 

bestimmte Ereignis-IDs erläutert werden. 

• Der Knowledge Base-Artikel „So wird´s gemacht: Problembehandlung bei standortinternen 

Replikationsfehlern“ unter http://support.microsoft.com/kb/249256 stellt ausführliche Informationen 

zur Problembehandlung bei der standortinternen Replikation bereit. Dieser Knowledge Base- 

Artikel sowie weitere Knowledge Base-Artikel beziehen sich auf Windows Server 2003. Viele der 

für die Problembehandlung bei der AD DS-Replikation erforderlichen Schritte haben sich in Windows 

Server 2008 jedoch nicht geändert. 

• Der Artikel „Troubleshooting Active Directory Replication“ unter http://blogs.technet.com/ 

asksbs/archive/2008/03/28/troubleshooting-active-directory-replication.aspx stellt eine detaillierte 

Schrittanleitung für die Problembehandlung bei der Active Directory-Replikation bereit. 

• Der Artikel „Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)“ (in englischer 

Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/43e6f617-fb49- 

4bb4-8561-53310219f9971033.mspx?mfr=true bietet ausführliche Informationen zur Behandlung 

von Replikationsproblemen, die in Verbindung mit DNS auftreten. 

• Der Artikel „Beheben von Fehlern bei der RPC-Endpunktzuordnung“ ( unterhttp://support.microsoft.com/kb/839880) 

stellt ausführliche Informationen zur Behandlung von Replikationsproblemen 

in Zusammenhang mit der RPC-Verbindung bereit. 

• Der Artikel „Dienste und Port-Anforderungen für das Microsoft Windows-Serversystem“ (unter 

http://support.microsoft.com/kb/832017) beschreibt die für die meisten Windows Server-Dienste, 

einschließlich der AD DS-Replikation, erforderlichen Ports. Diese Informationen sind insbesondere 

bei der Konfiguration von Firewalls zwischen Domänencontrollern nützlich. 

• Der Artikel „Replication Not Working Properly Between Domain Controllers After Deleting One 

from Sites and Services“ (in englischer Sprache) (unter http://support.microsoft.com/kb/262561) 

beschreibt die Verwendung des Tools Repadmin zum manuellen Erstellen von Verbindungsobjekten 

auf Domänencontrollern, die über das Tool Active Directory-Standorte und -Dienste entfernt 

wurden. 

• Der Artikel „Active Directory Replication Technologies“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver/en/library/53998db6-a972-495e-a4e7- 

e3ca3f60b5841033.mspx enthält eine ausführliche Erläuterung zur Funktionsweise der AD DS- 

Replikation. 

• Der Artikel „The Script Repository: Active Directory“ (in englischer Sprache) unter 

http://www.microsoft.com/technet/scriptcenter/scripts/ad/default.mspx stellt verschiedene Skripts 

zum Auflisten und Bearbeiten der AD DS-Standort- und -Standortverknüpfungskonfigurationen 

bereit. 


Windows Server 2008 stellt verschiedene Tools bereit, die zur Verwaltung und Problembehandlung 

der Replikation eingesetzt werden können. In Tabelle 4.2 werden einige dieser Tools sowie deren 

Anwendungsfälle aufgeführt.


Tabelle 4.2 

AD DS-Replikationstools 

Toolname 

Dnslint.exe 

Nslookup.exe 

Active Directory-Standorte 

und -Dienste 

Repadmin.exe 

DCDiag.exe 


Dieses Tool kann kostenlos von der Microsoft-Website heruntergeladen werden. (Unter http://support.microsoft.com/kb/321045 

erfahren Sie, wo Sie das Tool herunterladen können.) Sie können 

dieses Tool für die Problembehandlung häufig auftretender Probleme bei der DNS-Namensauflösung 

verwenden. Ferner können Sie mit Dnslint die für die AD DS-Replikation relevanten DNS-Einträge 

auf Fehler überprüfen. 

Dieses Tool ist in allen Microsoft Windows-Server- und -Clientbetriebssystemen enthalten. Mithilfe 

von Nslookup können Sie DNS-Serverabfragen ausführen und detaillierte Antwortinformationen abrufen. 

Anhand der von Nslookup gelieferten Informationen können Sie Namensauflösungsprobleme 

diagnostizieren und beheben, sicherstellen, dass Ressourceneinträge einer Zone ordnungsgemäß 

hinzugefügt bzw. darin aktualisiert wurden, sowie weitere serverbezogene Probleme beheben. 

Dieses Tool können Sie für die Konfiguration von Standorten und der Replikation sowie zum Durchführen 

einiger grundlegender Probembehandlungsmaßnahmen bei der AD DS-Replikation verwenden. 

Mithilfe des Befehslzeilenprogramms Repadmin.exe können Sie die Replikationstopologie aus der 

Perspektive jedes Domänencontrollers anzeigen. Sie können Repadmin.exe auch zum manuellen 

Erstellen der Replikationstopologie, zum Erzwingen von Replikationsereignissen zwischen Domänencontrollern 

und zum Anzeigen von Replikationsmetadaten und Aktualitätsvektoren (Up-To- 

Dateness Vector, UTDV) verwenden. 

Mithilfe von DCDiag können Sie Domänencontrollerprobleme ermitteln, die unter Umständen Auswirkungen 

auf die Replikation haben. 


• Das Spreadsheet ADDSSite.xlsx ist eine Vorlage für die Dokumentation der AD DS-Standortinformationen. 

• Bei ListADDSSites.ps1 handelt es sich um ein Windows PowerShell-Skript zum Auflisten von 

Informationen zu sämtlichen Standorten in einer Gesamtstruktur. 


• „Prüfliste: Konfigurieren eines zusätzlichen Standorts“ in der Hilfe der Konsole Active Directory- 

Standorte und -Dienste. 

• „Prüfliste: Konfigurieren des Zeitplans für die standortübergreifende Replikation“ in der Hilfe der 

Konsole Active Directory-Standorte und -Dienste. 

• „Problembehandlung bei der Active Directory-Domänendienstereplikation“ in der Hilfe der Konsole 

Active Directory-Standorte und -Dienste.

T E I L I I 

Entwerfen und Implementieren von Windows 

Server 2008 Active Directory 


Kapitel 5: Entwerfen der Active Directory-Domänendienstestruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

Kapitel 6: Installieren der Active Directory-Domänendienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 

Kapitel 7: Migrieren auf die Active Directory-Domänendienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

141 


Entwerfen der Active Directory-Domänendienstestruktur 


Definieren der Verzeichnisdienstanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

Entwerfen der Gesamtstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

Entwerfen der Integration mehrerer Gesamtstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 

Entwerfen der Domänenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

Entwerfen von Domänen- und Gesamtstrukturfunktionsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

Entwerfen der DNS-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Entwerfen der Struktur von Organisationseinheiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

Entwerfen der Standorttopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 




In vielen Unternehmen ist die Active Directory-Domänendienste-Infrastruktur (Active Directory 

Domain Services, AD DS) die wichtigste Komponente der IT-Umgebung. In solchen Unternehmen bieten 

die AD DS zentrale Authentifizierungs- und Autorisierungsdienste, die den Zugriff mit einmaliger 

Anmeldung (Single Sign-On) auf viele weitere Netzwerkdienste des Unternehmens ermöglichen. Daher 

ist es wichtig, die AD DS-Infrastruktur so zu entwickeln, dass sie so viele Anforderungen des Unternehmens 

wie möglich abdeckt. 

Dieses Kapitel bietet eine Übersicht über den Planungsvorgang, den Sie vor dem Einsatz der 

Windows Server 2008 AD DS durchführen müssen. Zu weiten Teilen wird in diesem Kapitel davon 

ausgegangen, dass Sie in einem großen Unternehmen mit mehreren Geschäftseinheiten und Standorten 

arbeiten. Auch wenn Sie für ein kleineres Unternehmen tätig sind, werden viele der vorgestellten 

Konzepte für Sie relevant sein. 

Dieses Kapitel behandelt die größte Frage zuerst: Wie viele Gesamtstrukturen werden für Ihr Netzwerk 

benötigt? Hiervon ausgehend, behandelt das Kapitel die Aufteilung der Gesamtstrukturen in 

Domänen und die Planung des Domänennamespaces. Sobald Ihre Domänen eingerichtet sind, müssen 

Sie außerdem für jede Domäne eine Organisationseinheitenstruktur (Organizational Unit, OU) 

erstellen. Parallel zur Erstellung der logischen AD DS-Struktur müssen Sie auch die physischen AD 

DS-Komponenten planen. Dieses Kapitel behandelt daher auch den Entwurf von Standorten und Platzierungen 

der Domänencontroller.

142 Kapitel 5: Entwerfen der Active Directory-Domänendienstestruktur 

Hinweis Der Entwurf einer Windows Server 2008 AD DS-Infrastruktur unterscheidet sich nicht wesentlich 

von der Entwicklung einer Active Directory-Infrastruktur unter Microsoft Windows 2000 oder Windows 

Server 2003. Windows Server 2008 AD DS umfassen mehrere wichtige neue Funktionen, die sich auf das 

Design der AD DS auswirken. Viele der Hauptkonzepte von AD DS haben sich jedoch nicht verändert, 

ebenso wenig wie viele der Entwurfsentscheidungen. Wenn Sie Active Directory bereits einsetzen, können 

Sie anhand dieses Kapitels das aktuelle Design überprüfen und damit das Upgrade auf Windows Server 

2008 AD DS vorbereiten. 

Definieren der Verzeichnisdienstanforderungen 

Bevor Sie mit dem Entwurf des Verzeichnisdienstes für Ihr Unternehmen beginnen, müssen Sie 

zunächst wissen, warum Ihr Unternehmen den Einsatz des Verzeichnisdienstes plant. Außerdem müssen 

Sie den Zustand des aktuellen Verzeichnisdienstes kennen. Sehr wenige Unternehmen setzen eine 

neue Technologie nur deswegen ein, weil sie gerade neu und angesagt ist. Bevor in eine neue Technologie 

investiert wird, müssen Manager einen deutlichen Geschäftsvorteil erkennen. Das bedeutet, dass 

Sie verstehen und den Entscheidungsträgern des Unternehmens einleuchtend erklären müssen, wie 

eine neue Technologie wie Windows Server 2008 AD DS vorhandene und neue Geschäftsanforderungen 

abdecken wird. 

Abbildung 5.1 zeigt eine Prüfliste der Anforderungstypen, die Sie zu Beginn des AD DS-Entwurfs 

ermitteln müssen. 

Dokumentieren 

von Geschäftsanforderungen 

Dokumentieren 

von funktionellen 

Anforderungen 

Dokumentieren 

von Vereinbarungen 

zum Servicelevel 

Dokumentieren 

von rechtlichen 

Anforderungen 

Dokumentieren 

von Sicherheitsanforderungen 

Dokumentieren 

von Projekteinschränkungen 

Abbildung 5.1 

Informationen. 

Verwenden Sie die Anforderungsprüfliste für den AD DS-Entwurf zum Sammeln der benötigten

Definieren der Verzeichnisdienstanforderungen 143 

Einbeziehen des Unternehmens in den AD DS-Entwurf 

Wenn Sie AD DS für ein Unternehmen entwerfen, sollten Sie unbedingt das Management des Unternehmens 

in den Entwurfsvorgang einbeziehen. Die Benutzer im Unternehmen sind die Hauptkonsumenten 

der von der IT-Infrastruktur (Information Technology) bereitgestellten Dienste. Daher ist es 

wichtig, dass der Entwurf ihren Anforderungen entspricht und vom Management unterstützt wird. 

Inwieweit Sie Mitarbeiter des Unternehmens in den Entwurfsvorgang einbeziehen müssen, ist von 

Unternehmen zu Unternehmen sehr unterschiedlich. In fast jedem Unternehmen müssen jedoch 

zumindest die höheren Ziele des Entwurfsprojekts genehmigt werden. Bei diesen Zielen geht es 

beispielsweise um Aspekte wie die Zugänglichkeit von Informationen, Sicherheit, einfache Verwaltbarkeit 

und Verwendbarkeit. Die Geschäftsleitung wird normalerweise außerdem in höhere 

Entscheidungen mit deutlichen Auswirkungen einbezogen, die nach ihrer Umsetzung nicht einfach 

geändert werden können. Zu diesen Entscheidungen gehört, wie viele Gesamtstrukturen und 

Domänen im Netzwerk benötigt werden und wie viele Domänennamespaces eingesetzt werden 

sollen. 

Definieren von Geschäftsanforderungen und technischen Anforderungen 

Unternehmen investieren in Technologie, um geschäftliche Probleme zu lösen oder neue Möglichkeiten 

zu schaffen. Geschäftsanforderungen bestimmen normalerweise die Gründe, aus denen eine 

neue Technologie innerhalb des Unternehmens implementiert wird. Technische Anforderungen definieren 

häufig, wie die neue Technologie entworfen und eingesetzt wird, um die Geschäftsanforderungen 

zu erfüllen. 

Geschäftsanforderungen 

Geschäftsanforderungen können viele verschiedene Formen annehmen. Zum Beispiel muss ein Unternehmen 

möglicherweise folgende Aufgaben erfüllen: 

• Seine Effizienz steigern Die meisten Unternehmen müssen sich im Wettbewerb behaupten und 

versuchen, effizienter als ihre Mitbewerber zu arbeiten. Bei der Bewertung neuer Technologien 

investieren diese Unternehmen typischerweise in eine Technologie, wenn sie die Effizienz verbessert. 

• Externe Anforderungen erfüllen Kräfte außerhalb eines Unternehmens, beispielsweise die Regierung 

oder Geschäftspartner, erheben möglicherweise Ansprüche. Beispielsweise können Regierungsbestimmungen 

verlangen, dass Organisationen den Schutz aller Benutzer- und Kundendaten 

sicherstellen. 

• Störungen von Geschäftsvorgängen vermeiden Eine aktuelle Technologie entspricht vielleicht den 

meisten Geschäftsanforderungen. Wenn sie jedoch unzuverlässig ist, investiert ein Unternehmen wohl 

eher in eine neue Technologie, die die erforderliche Zuverlässigkeit und Verfügbarkeit gewährleistet. 

• Neue Geschäftsbereiche oder Lösungen erforschen Gelegentlich verwenden Unternehmen Technologien, 

um neue Geschäftsziele zu verfolgen. Der Einsatz webbasierter Tools zum Verkauf von 

Produkten und Leistungen hat beispielsweise die geschäftlichen Möglichkeiten vieler Unternehmen 

gesteigert.


Es ist wahrscheinlicher, dass der Einsatz einer Technologie den Anforderungen eines Unternehmens 

entspricht, wenn die Geschäftsanforderungen knapp und präzise zu Beginn des Projekts definiert werden. 

Außerdem kann der Erfolg eines Projekts leichter eingeschätzt werden, wenn das Projektteam die 

Geschäftsprobleme kennt, die durch das Projekt gelöst werden sollen. 

Funktionsanforderungen 

Funktionsanforderungen definieren das erwartete Verhalten eines Systems. Sie leiten sich von den 

Geschäftsanforderungen ab. Geschäftsanforderungen definieren das zu lösende Problem, während 

Funktionsanforderungen definieren, wie die vorgeschlagene Technologie das Problem lösen soll. 

Ein Unternehmen könnte beispielsweise als Geschäftsanforderung definieren, dass alle Benutzer 

in einem Büro Zugriff auf freigegebene Ressourcen wie ein E-Mail-System oder Geschäftsanwendungen 

erhalten sollen. Die daraus folgende Funktionsanforderung könnte beispielsweise die Serverstandorte 

und -konfigurationen festlegen, die zum Erfüllen dieser Geschäftsanforderung erforderlich 

sind. 

Mithilfe der Funktionsanforderungen wird die Funktionsbeschreibung erstellt, welche die vorgeschlagene 

Lösung im Detail beschreibt und die Grundlage für Projektpläne und zeitliche Abläufe darstellt. 

Die Funktionsbeschreibung ist aus folgenden Gründen wichtig: 

• Sie stellt eine Vereinbarung zwischen dem Bereitstellungsteam und dem Technologiekonsumenten oder 

Kunden her Auf diese Weise kann das Team die richtige Lösung festlegen, die den Kundenerwartungen 

entspricht. 

• Sie stellt sehr detaillierte Einzelheiten zum Projekt bereit, damit das Team eine korrekte Umsetzung der 

Lösung gewährleisten kann Auf diese Weise wird die Lösung auch einfacher zu überprüfen und zu 

verifizieren. 

• Sie ermöglicht dem Team die Abschätzung von Budgets und Zeitplänen Die Anzahl der Mitarbeiter 

und die entsprechenden Fähigkeiten sind ohne die spezifischen Einzelheiten, die in einer Funktionsbeschreibung 

festgelegt sind, schwer zu bestimmen. 

Hinweis Zusätzlich zu den Funktionsanforderungen besitzt jeder Entwurf funktionsunabhängige Anforderungen. 

Funktionsunabhängige Beschreibungen definieren weniger die Systemtätigkeit selbst, sondern vielmehr 

die Art und Weise, in der das System arbeitet, und/oder die von ihm bereitgestellte Quality of Service 

(Dienstqualität). Zu den gängigen funktionsunabhängigen Anforderungen gehören die Verfügbarkeit, Wartbarkeit, 

Leistung, Zuverlässigkeit und Skalierbarkeit des Systems. 

Vereinbarungen zum Servicelevel (SLA) 

Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) sind Einverständniserklärungen 

zwischen einem Unternehmen und der Gruppe, welche die Informationssysteminfrastruktur verwaltet. 

In diesen Vereinbarungen werden die erwarteten Leistungen festgehalten. Ein SLA sollte unbedingt 

definiert werden, weil darin die Service-Erwartungen und -Anforderungen eines Unternehmens an 

die IT-Abteilung dokumentiert sind. In SLAs können mehrere Kategorien der erwarteten Leistung definiert 

sein. Hierzu gehören Folgende: 

• Verfügbarkeit Beispielsweise kann ein SLA fordern, dass alle Benutzer sich zu 99,99% der Zeit 

während der Geschäftszeiten und zu 99,9% der Zeit außerhalb der Geschäftszeiten am Netzwerk 

anmelden und auf kritische Anwendungen zugreifen können. 

• Leistung In einem SLA kann beispielsweise festgelegt sein, dass alle Benutzer innerhalb von 

15 Sekunden nach Eingabe ihrer Anmeldeinformationen an AD DS angemeldet sein müssen.


• Wiederherstellung Ein SLA kann zum Beispiel vorschreiben, dass bei Ausfall eines einzigen Servers 

die von diesem Server bereitgestellten Dienste innerhalb von vier Stunden nach dem Ausfall 

zu mindestens 75% der normalen Kapazität wiederhergestellt sein müssen. 

Hinweis Die von Unternehmen eingesetzten SLAs variieren zwischen eher informell und extrem durchstrukturiert. 

Informelle SLAs sind oft nicht dokumentiert, sondern eher allgemeine, bekannte Erwartungen an 

die Systemleistung. Ein Unternehmen kann beispielsweise eine interne, ungeschriebene Richtlinie befolgen, 

dass bestimmte Server während der Geschäftszeiten höchstens im Notfall heruntergefahren werden dürfen. 

Formelle SLAs werden in der Regel ausgiebig dokumentiert und enthalten ausführlich beschriebene Erwartungen, 

die sich aus Verhandlungen zwischen Dienstanbietern und Geschäftskunden ergeben. Solche SLAs 

definieren genaue Erwartungen für jede Systemkomponente des Systems und enthalten möglicherweise 

auch Vertragsstrafen für den Fall, dass die Erwartungen nicht erfüllt werden. Oft werden besonders formelle 

SLAs zwischen Geschäftskunden und externen IT-Anbietern verhandelt. 

SLAs haben erhebliche Auswirkungen auf den Umfang und das Budget eines Projekts. Es ist daher 

wichtig, sie zu Anfang des Projekts zu definieren. Die Geschäftsanforderungen zusammen mit den 

Funktionsbeschreibungen und den funktionsunabhängigen Beschreibungen bilden normalerweise die 

Grundlage für die ersten SLA-Verhandlungen. In den meisten Fällen handeln das Projektteam und die 

Auftraggeber die endgültigen Einzelheiten des SLA aus. In den ersten Anforderungen können sehr 

hohe Erwartungen gestellt werden. Die Erfüllung solcher Erwartungen kann jedoch teuer werden. 

Wenn ein SLA beispielsweise vorsieht, dass alle Benutzer in allen Büros sich jederzeit an AD DS 

anmelden können sollen, müssen Sie vollständig redundante Systeme oder WAN-Verbindungen im 

gesamten Unternehmen bereitstellen. Die Kosten hierfür wären wahrscheinlich nicht erschwinglich. 

Das Unternehmen wird daher wahrscheinlich einen akzeptableren Leistungsgrad zu angemesseneren 

Kosten verhandeln. 

Rechtliche Anforderungen 

Mit Informationssystemen ist das Sammeln, Speichern und Übertragen von Informationen sehr einfach. 

Viele Länder haben Vorschriften erlassen, in denen vorgeschrieben ist, wie Unternehmen die 

Vertraulichkeit von Daten gewährleisten müssen. Beispiele zeigen, wie die Rechtsprechung die Verwaltung 

von Daten in Unternehmen einschränkt: 

• Vereinigte Staaten: 

Sarbanes-Oxley Act von 2002 (SOX) 

Gramm-Leach-Bliley Act (Financial Modernization Act) 

Health Insurance Portability and Accountability Act von 1996 (HIPAA) 

Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and 

Obstruct Terrorism Act von 2001 (USA Patriot Act) 

• Kanada: Personal Information Protection and Electronic Documents Act 

• Australien: Federal Privacy Act 

• Europa: European Union Data Protection Directive (EUDPD) 

• Japan: Personal Information Protection Act 

Beim Entwurf der AD DS-Infrastruktur müssen Sie diese rechtlichen Anforderungen berücksichtigen. 

In einigen Fällen können Sie die Anforderungen durch den Entwurf technischer Lösungen 

erfüllen.


Wenn beispielsweise Kundendaten grundsätzlich nur von wenigen bestimmten Benutzern eingesehen 

werden dürfen, könnten Sie die Kundendaten in einer separaten AD DS-Gesamtstruktur speichern 

oder eine Instanz der Active Directory Lightweight Directory Services (AD LDS) mit strengen Einschränkungen 

des Benutzerzugriffs einsetzen. Um zu verhindern, dass Benutzer vertrauliche Daten 

aus dem Unternehmen heraus senden, könnten Sie eine AD RMS-Lösung (Active Directory Rights 

Management Services) implementieren. 

Technische Lösungen können selten sämtliche Rechtsanforderungen erfüllen. Wenn Sie vertrauliche 

Daten beispielsweise über AD RMS schützen, kann ein Benutzer diese Daten noch immer mit einer 

Digitalkamera ablichten und die Daten aus dem Unternehmen schleusen. Benutzer mit Zugriff auf 

vertrauliche Kundendaten können diese Daten noch immer an unbefugte Benutzer weitergeben. Um 

diese Probleme zu lösen, müssen Unternehmen die technischen Lösungen durch auf Unternehmensrichtlinien 

basierende Lösungen ergänzen, in denen zulässige Aktionen und die bei unzulässigen 

Aktionen zu befürchtenden Konsequenzen deutlich festgelegt sind. 

Sicherheitsanforderungen 

Alle IT-Bereitstellungen haben außerdem Sicherheitsanforderungen. Die Anforderungen erlangen 

beim Einsatz von AD DS besondere Bedeutung, weil AD DS wahrscheinlich zum Sichern des 

Zugriffs auf die meisten Daten, Dienste und Anwendungen im Netzwerk verwendet wird. 

Stellen Sie sich die folgenden Fragen, um Ihre Sicherheitsanforderungen festzustellen: 

• Wo liegen die Sicherheitsrisiken für das Unternehmen? Auf diese Frage gibt es viele mögliche 

Antworten, zum Beispiel: 

Mobile Benutzer, die viel reisen und sich mit dem internen Netzwerk verbinden müssen, um 

auf ihre E-Mail, Anwendungen oder Daten zuzugreifen. 

Benutzer außerhalb des Unternehmens, die auf in einem Umkreisnetzwerk befindliche Websites 

zugreifen und sich über ihre internen AD DS-Benutzerkonten authentifizieren müssen. 

Büros, die physisch nicht abgesichert sind und in denen böswillige Benutzer Zugriff auf das 

Netzwerk erlangen können. Andere Büros besitzen möglicherweise keinen sicheren Standort 

für Domänencontroller oder andere Server. 

Eine Datenbank mit vertraulichen Kundendaten, die für Webanwendungen im Umkreisnetzwerk 

zugänglich sein muss. 

• Wie werden Sicherheitsanforderungen derzeit berücksichtigt? Fast alle Unternehmen berücksichtigen 

wenigstens einige Sicherheitsanforderungen. Beispielsweise haben praktisch alle Unternehmen 

Antiviruslösungen und Firewalls implementiert, um das interne Netzwerk vor Angriffen aus 

dem Internet zu schützen. 

• Welche Lücken bestehen zwischen Sicherheitsanforderungen und aktuellen Lösungen? Diese 

Lücken sind je nach Unternehmen unterschiedlich groß. Einige Unternehmen setzen beispielsweise 

Anwendungen ein, für die Benutzer sich über Anmeldeinformationen authentifizieren müssen, 

die im Netzwerk nicht sicher übertragen werden. Um diesen Vorgang für den Benutzer zu 

vereinfachen, weisen manche Unternehmen der Anwendung denselben Benutzernamen und dasselbe 

Kennwort zu, der bzw. das auch für die Anmeldung an AD DS verwendet wird. Wenn daher 

die Anmeldeinformationen für die Authentifizierung bei der Anwendung geknackt werden, sind 

somit auch die AD DS-Anmeldeinformationen offengelegt. 

• Welche allgemeinen Sicherheitsanforderungen oder -richtlinien muss das Projekt befolgen? Die 

meisten Unternehmen verfügen über allgemeine Sicherheitsanforderungen, die für alle Projekte gelten. 

Hierzu gehören beispielsweise folgende Anforderungen:


Alle Server müssen sich in einem sicheren Serverraum befinden, der nur befugten Benutzern 

zugänglich ist. 

Der gesamte Authentifizierungsdatenverkehr muss bei der Übertragung im Netzwerk abgesichert 

sein. 

Alle Benutzer, die über ein VPN (Virtual Private Network) auf das interne Netzwerk zugreifen, 

müssen eine zweistufige Authentifizierung verwenden. 

Sicherheitsanforderungen stehen manchmal in Widerspruch zu den Geschäftsanforderungen. Beispielsweise 

könnte eine Geschäftsanforderung besagen, dass alle Benutzer in einer bestimmten Abteilung 

über ein VPN auf das interne Netzwerk zugreifen müssen. In der Sicherheitsanforderung könnte festgelegt 

sein, dass alle VPN-Benutzer eine zweistufige Authentifizierung bereitstellen müssen. Wenn nicht 

alle Benutzer in der Abteilung mobile Computer verwenden, die die zweistufige Authentifizierung 

unterstützen, besteht ein Konflikt zwischen der Geschäftsanforderung und der Sicherheitsanforderung. 

Sicherheitsanforderungen schränken häufig die Leistungsfähigkeit eines Projekts ein. Eine technische 

Lösung kann Geschäftsanforderungen möglicherweise erfüllen oder sogar übertreffen; wenn jedoch 

derjenige, der für die Definition der Sicherheitsanforderungen zuständig ist, die Lösung als unsicher 

betrachtet, muss diese überarbeitet oder die Geschäftsanforderung aufgehoben werden. In vielen 

Unternehmen sind einige Sicherheitsanforderungen nicht verhandelbar, während andere Sicherheitsanforderungen 

zugunsten einer kritischen Geschäftsanforderung geändert werden können. 

Projekteinschränkungen 

Projekteinschränkungen definieren die Parameter des Projekts, indem sie die gegebenen Möglichkeiten 

beschränken. Wenn dem Projekt beispielsweise ein festes Budget zugrunde liegt, müssen Planer 

möglicherweise eher die Hardware verwenden, die sie sich leisten können, anstelle der Hardware, 

die sie als optimal geeignet betrachten. 

Es gibt drei allgemeine Kategorien von Projekteinschränkungen: 

• Ressourceneinschränkungen Das Budget eines Projekts ist eine typische Ressourceneinschränkung. 

Wenn das vorgeschlagene Budget den veranschlagten Personalkosten, Ausrüstungskosten 

und Softwarekosten nicht entspricht, kann das Projekt nicht fortgesetzt oder muss an die Einschränkungen 

angepasst werden. Außerdem können andere Ressourceneinschränkungen für ein 

Projekt vorliegen: 

Das geeignete Personal ist möglicherweise nicht verfügbar, oder seine Fertigkeiten reichen 

zum Abschließen des Projekts nicht aus. 

Computerressourcen oder Hardware ist möglicherweise nicht zugänglich. 

• Zeitplaneinschränkungen Auch der Projektzeitplan kann die Möglichkeiten eines Projekts einschränken. 

Beispielsweise erlauben viele Unternehmen zu bestimmten Zeiten keine Änderungen 

an der IT-Umgebung, beispielsweise am Ende des Geschäftsjahres oder bei Hochkonjunktur. Soll 

ein Projekt während eines dieser Zeiträume abgeschlossen werden, muss der Projektumfang möglicherweise 

geändert werden. Außerdem kann ein Projekt durch den Zeitplan anderer Projekte eingeschränkt 

werden. 

• Funktionseinschränkungen Funktionseinschränkungen können sich auf den Beginn oder den 

Umfang eines Projekts auswirken. Wenn ein Unternehmen beispielsweise ein neues Produkt 

basierend auf einer bestimmten Funktion bewertet und diese Funktion nicht verfügbar ist oder den 

Anforderungen des Unternehmens nicht entspricht, entscheidet sich das Unternehmen möglicherweise 

für den Abbruch des Projekts. Ist eine bestimmte Funktion besonders wichtig, kann der Projektumfang 

um die jeweilige Funktion erweitert werden.


Das Projektteam und die Auftraggeber verhandeln häufig über Projekteinschränkungen sowie über 

Geschäftsanforderungen und SLAs. Das Budget mag vielleicht als feste Größe erscheinen; wenn eine 

Erhöhung des Budgets jedoch zur Einhaltung einer wichtigen Geschäftsanforderung oder eines 

bestimmten SLA-Levels dient, kann das Budget entsprechend angepasst werden. 

Dokumentieren der aktuellen Umgebung 

Sobald Sie die Verzeichnisdienstanforderungen zusammengestellt haben, besteht der nächste Schritt 

in der Analyse der aktuellen Netzwerk- und Verzeichnisumgebung. Durch die Analyse der aktuellen 

Umgebung können Sie leichter ermitteln, was beim Einsatz der neuen Infrastruktur geändert werden 

muss. Diese Informationen bieten einen Ausgangspunkt für die Festlegung eines geeigneten Aufbauund 

Implementierungsplans für die Windows Server 2008-Bereitstellung. 

Abbildung 5.2 zeigt eine Prüfliste der Datentypen, die Sie zu Beginn des AD DS-Entwurfs ermitteln 

müssen. 

Wichtig Während Sie Informationen über die aktuelle Netzwerkinfrastruktur oder eine andere Komponente 

in der aktuellen Umgebung sammeln, sollten Sie außerdem unbedingt auch Informationen zu geplanten Änderungen 

an der Umgebung zusammenstellen. Wenn beispielsweise die WAN-Verbindungen vor dem Einsatz 

der AD DS aufgerüstet werden sollen, nehmen Sie diese Information in Ihre Dokumentation auf. Diese Änderungen 

stehen möglicherweise aufgrund von Projektabhängigkeiten in Konflikt mit der AD DS-Bereitstellung 

oder führen zu Änderungen an Ihrem Entwurf. 

Dokumentieren 

des physischen 

Netzwerks 

Dokumentieren 

der Namensauflösungsinfrastruktur 

Dokumentieren der 

Active Directory- 

Infrastruktur 

Dokumentieren 

zusätzlicher 

Infrastrukturkomponenten 

Dokumentieren von 

Verwaltungsmodellen 

und -verfahren 

Abbildung 5.2 

Prüfliste zur aktuellen Umgebung für den AD DS-Entwurf 

Dokumentieren der Infrastruktur des physischen Netzwerks 

Berücksichtigen Sie beim Dokumentieren der Infrastruktur des physischen Netzwerks die folgenden 

Komponenten:


• Die Anzahl, geografische Lage und Verbindungsgeschwindigkeit sämtlicher Standorte, an denen Netzwerkdienste 

eingesetzt werden Führen Sie unbedingt sämtliche Standorte auf, aus denen die Netzwerkinfrastruktur 

besteht, also Gebäude, Betriebsgelände und Zweigniederlassungen. Außerdem 

müssen Sie die Verbindungstypen und die Netzwerkgeschwindigkeit für jeden Standort ermitteln. 

Berücksichtigen Sie auch die physische Sicherheit der verschiedenen Standorte. Besonders in 

Zweigniederlassungen ist die physische Sicherheit häufig gering, und dieser Umstand wirkt sich auf 

die Designauswahl aus, die Sie treffen müssen. 

• Eine Karte der Routingtopologie, in der die physischen Standorte und die dort verwendeten IP-Subnetze 

(Internet Protocol) dargestellt sind Diese Karte ist hilfreich bei der Planung oder Integration in den 

AD DS-Standortentwurf. 

• Bandbreite, Latenz und aktuelle Auslastung Die Bandbreite ist die Übertragungsgeschwindigkeit 

über eine Netzwerkverbindung in Kilobit pro Sekunde (KBit/s). Latenz bezieht sich auf den Zeitraum 

in Millisekunden, der für die Übertragung von Daten zwischen zwei Punkten erforderlich 

ist. Kombiniert legen beide Faktoren fest, wie viele Daten in einem bestimmten Zeitraum über das 

Netzwerk übertragen werden können. Diese Information sowie die Anwendungen, die derzeit das 

Netzwerk verwenden, und die Anzahl der Benutzer an verschiedenen Standorten sowie ihre Nutzungsmuster 

können genutzt werden, um einen Entwurf für Ihre AD DS-Implementierung zu 

erstellen, der ein zufriedenstellendes Benutzererlebnis gewährleistet. 

• Anforderungen an die Firewallkonfiguration Wenn Ihr Unternehmen Firewalls zwischen den Unternehmensstandorten 

einsetzt, dokumentieren Sie die Firewallstandorte und die Firewallregeln. 

Falsch konfigurierte Firewalls können die DNS-Namensauflösung, die AD DS-Replikation und 

die Authentifizierung stören. 

• Nicht technische Einschränkungen Hierzu gehören geografische, politische oder kostenbezogene 

Einschränkungen, die sich aus einer Änderung oder Aktualisierung der Netzwerkverbindungen 

zwischen Standorten ergeben. 

Auf der DVD Sie können die Datei CurrentNetworkEnviroment.xlsx auf der CD nutzen, um die aktuelle 

Netzwerkumgebung zu dokumentieren. Mehrere Registerkarten im Arbeitsblatt beziehen sich auf zugehörige 

Netzwerkdiagramme. Eines der besten Tools zur Erstellung von Netzwerkdiagrammen ist Microsoft Office 

Visio. Vier Visio-Vorlagen, die zum Erstellen von Diagrammen für LAN- und WAN-Konfigurationen eingesetzt 

werden können, sind auf der CD enthalten. Zusätzliche Visio-Vorlagen können außerdem von 

http://office.microsoft.com/en-us/templates/default.aspx heruntergeladen werden. Ein WAN-Beispieldiagramm 

(WANDiagram_Sample.vsd) befindet sich ebenfalls auf der CD. 

Dokumentieren der Infrastruktur zur Namensauflösung 

AD DS erfordern eine DNS-Infrastruktur (Domain Name System), damit Domänencontroller einander 

und Clientcomputer die Domänencontroller finden können. Berücksichtigen Sie beim Dokumentieren 

der DNS-Infrastruktur folgende Aspekte: 

• Welche Art von DNS-Software wird derzeit verwendet? Kann sie Dienstressourceneinträge (Service, 

SRV) verarbeiten? 

• Wer wartet und verwaltet die internen und externen DNS-Server und Zoneninformationen des 

Unternehmens? Wie lauten die IP-Adressen aller DNS-Server? 

• Wer weist DNS-Namen und -Domänen innerhalb des Unternehmens zu? Gibt es eine zentrale 

Stelle für die Planung und Steuerung von DNS-Namespaces? 

• Wo befinden sich interne DNS-Server im Netzwerk? Welche Zonen sind auf den einzelnen DNS- 

Servern gespeichert?


• Wie ist die DNS-Namensauflösung über mehrere Namespaces konfiguriert? Wie werden Stammhinweise, 

Weiterleitungen (Forwarder), bedingte Weiterleitungen, Stubzonen und Delegierungen 

verwendet, um die Namensauflösung zu ermöglichen? 

• Sind die DNS-Zonen in AD DS integriert? 

Auf der DVD Sehen Sie auf den Registerkarten DNS Zone Configuration und DNS Server Configuration in 

den Aufgabeninformationen CurrentNetworkEnvironment auf der Begleit-CD nach, um die aktuelle DNS-Infrastruktur 

zu dokumentieren. 

Dokumentieren der Active Directory-Infrastruktur 

Die meisten Unternehmen, die AD DS neu einsetzen, führen bereits eine andere Version von Active 

Directory aus. Bevor Sie mit dem Entwurf der AD DS beginnen, stellen Sie sicher, dass Ihnen die 

aktuelle Umgebung genau bekannt ist. Wenn Sie die aktuelle Active Directory-Bereitstellung dokumentieren, 

berücksichtigen Sie folgende Punkte: 

• Active Directory-Gesamtstruktur- und -Domänentopologie 

Besteht Ihr Unternehmen aus einer einzigen oder aus mehreren Gesamtstrukturen? Wenn in 

Ihrem Unternehmen mehrere Gesamtstrukturen verwendet werden, sollten Sie die Optionen 

zum Konsolidieren von Gesamtstrukturen erkunden. 

Wie viele Domänen sind in jeder Gesamtstruktur implementiert? 

Welchen Zweck erfüllen die einzelnen Domänen? Um festzustellen, ob Domänen konsolidiert 

werden können, müssen Sie verstehen, warum die einzelnen Domänen erstellt wurden. 

IWas hat das Unternehmen bewogen, mehrere Gesamtstrukturen einzusetzen und zu verwalten? 

Wenn der Grund für die Verwendung mehrerer Domänen noch immer gilt, müssen Sie 

möglicherweise weiterhin mehrere Gesamtstrukturen verwalten. Andernfalls können Sie 

erwägen, Gesamtstrukturen zu konsolidieren. 

• Konfiguration der Active Directory-Vertrauensstellungen 

Welche Vertrauensstellungen wurden zusätzlich zu den Standardvertrauensstellungen innerhalb 

einer AD DS-Gesamtstruktur konfiguriert? Ermitteln Sie bei der Dokumentation der Vertrauensstellungen 

die Gründe für jede einzelne Vertrauensstellung. Besitzen die Gründe noch 

immer Gültigkeit? 

Welche Vertrauensstellungen bestehen mit externen Domänen? Stellen Sie fest, ob diese Vertrauensstellungen 

noch immer erforderlich sind oder ob zusätzliche Vertrauensstellungen 

benötigt werden. 

• Welche Domänen- und Gesamtstrukturfunktionsebenen werden eingesetzt? Wenn Sie die Domänen- 

und die Gesamtstrukturfunktionsebene heraufstufen, erhalten Sie Zugriff auf neue Funktionen 

in Active Directory. Wenn die Domänen- und die Gesamtstrukturfunktionsebene nicht der 

höchsten Ebene entspricht, die von den Betriebssystemen auf den Domänencontrollern unterstützt 

wird, prüfen Sie, warum die Funktionsebene nicht heraufgestuft wurde. 

• Active Directory-Standortkonfiguration: Dokumentieren Sie die aktuelle Active Directory-Standorttopologie, 

und berücksichtigen Sie dabei folgende Aspekte: 

Anzahl konfigurierter Standorte 

Subnetzkonfigurationen und ihre Standortverknüpfung 

IP-Standortverknüpfungen und ihre Mitgliedsstandorte 

IP-Standortverknüpfungskosten und Replikationszeitpläne


• Konfiguration der Domänencontroller und globalen Katalogserver: Während Sie die einzelnen 

Active Directory-Standorte analysieren, dokumentieren Sie die Konfiguration und den physischen 

Standort jedes Domänencontrollers und jedes globalen Katalogservers. Stellen Sie im 

Zuge der Domänencontrollerdokumentation fest, welche Domänencontroller die Betriebsmasterrollen 

der Gesamtstruktur und Domänen hosten. 

• Inhaber der FSMO-Rolle: AD DS stellen eine Reihe von Betriebsmasterrollen zur Verfügung, und 

es ist wichtig zu wissen, welche Domänencontroller in der Domäne oder in der Gesamtstruktur 

diese Rollen ausführen. 

• Zeitdienstkonfiguration: Die Zeitsynchronisierung ist in einer AD DS-Umgebung von Bedeutung, 

daher sollten Sie prüfen, wie der Zeitdienst in Ihrer Gesamtstruktur konfiguriert ist. 

• Konfiguration der Organisationseinheiten (Organizational Units, OU): Dokumentieren Sie bei der 

Domänenanalyse die aktuelle OU-Struktur. Dokumentieren Sie für jede Organisationseinheit die 

Position in der Domänenhierarchie, den Zweck jeder Organisationseinheit sowie die delegierten 

Berechtigungen und verknüpften Gruppenrichtlinienobjekte (Group Policy Objects, GPOs). 

• Konfiguration der Gruppenrichtlinien: Viele Unternehmen verwenden die Active Directory-Gruppenrichtlinie, 

um eine zentrale Verwaltung und Sicherheit der Benutzer, Gruppen und Computer 

sowie weiterer Verzeichnisobjekte bereitzustellen. Dokumentieren Sie die GPOs, den Zweck jedes 

Gruppenrichtlinienobjekts, die Vererbungs- und Filtereinstellungen der einzelnen GPOs und die 

GPO-Einstellungen. 

• Active Directory-Gruppen: Dokumentieren Sie die Gruppenkonfiguration, einschließlich des 

Gruppenbereichs und -typs, der Gruppenbesitzer und der Mitgliedschaftsliste sowie der Verwendungsart 

der Gruppe. Dies ist vor allem für alle Gruppen mit Administratorrechten von Bedeutung. 

Auf der DVD Sie können die Datei CurrentDirectoryEnviroment.xlsx auf der CD nutzen, um die aktuelle 

Active Directory-Umgebung zu dokumentieren. 

Aktuelle Active Directory-Konfiguration und der AD DS-Entwurf 

Eine wichtige Anforderung beim AD DS-Entwurf besteht darin, den optimalen Entwurf für ein 

Netzwerk abzuwägen, in dem AD DS bereits eingesetzt werden. Berücksichtigen Sie bei der Vorbereitung 

des AD DS-Entwurfs den aktuellen Active Directory-Aufbau und die Auswirkungen 

einer Migration von dieser Infrastruktur auf einen anderen AD DS-Entwurf. Die aktuelle Domänenstruktur 

ist vielleicht nicht ideal. Es ist jedoch bedeutend einfacher (und preiswerter), die aktuellen 

Domänen nur zu aktualisieren, als die ideale AD DS-Struktur zu erstellen und anschließend 

sämtliche Domänenobjekte auf die neuen Domänen zu migrieren. Das heißt, dass Sie unter 

Umständen gezwungen sind, mit einer weniger idealen AD DS-Struktur zu arbeiten, weil Sie die 

aktuellen Domänen aktualisieren müssen. Natürlich könnten Sie auch zu dem Schluss kommen, 

dass die aktuelle Struktur so weit von einer idealen Struktur entfernt ist, dass sich der zusätzliche 

Aufwand und die Kosten für die Umstrukturierung sämtlicher Domänen lohnen. Im Normalfall ist 

die aktuelle Struktur wahrscheinlich nahezu akzeptabel, Sie würden jedoch einige Änderungen vornehmen 

wollen. In diesem Szenario könnten Sie eine oder mehrere Domänen aktualisieren und 

anschließend andere Domänen mit den aktualisierten Domänen zusammenführen.


Erwägen Sie beim Vorbereiten Ihres AD DS-Entwurfs die Erstellung eines idealen AD DS-Entwurfs, 

und erstellen Sie anschließend einen anderen Entwurf, der auf dem optimalen Aktualisierungsszenario 

für die aktuelle Umgebung basiert. Höchstwahrscheinlich wird Ihr endgültiger Entwurf 

irgendwo zwischen dem idealen und dem optimalen Entwurf liegen. 

Dieses Zusammenspiel zwischen einem idealen Entwurf und dem, was realistischerweise möglich 

ist, zeigt einen weiteren wichtigen Aspekt des AD DS-Entwurfs: Es handelt sich fast immer um 

einen iterativen Vorgang. Zu Beginn haben Sie einen bestimmten Entwurf im Kopf, und während 

Sie zusätzliche Informationen sammeln, müssen Sie diesen Entwurf höchstwahrscheinlich verändern. 

Wenn Sie anfangen, die Implementierungs- oder Migrationsszenarios zu testen, werden Sie 

Ihren AD DS-Entwurf möglicherweise erneut überarbeiten. 

Es ist jedoch wichtig, dass einige Teile Ihres Entwurfs vor Beginn der Bereitstellung fertig gestellt 

sind. Entwurfsentscheidungen wie die Anzahl der Gesamtstrukturen und Domänen sowie der Entwurf 

des Domänennamespaces können nach Beginn der Bereitstellung nicht ohne weiteres geändert 

werden. Andere Aspekte, beispielsweise der endgültige OU-Entwurf und der Standortaufbau, 

können auch nach der Bereitstellung relativ einfach bearbeitet werden. 

Dokumentieren zusätzlicher Infrastrukturkomponenten 

Zusätzlich zu den Netzwerkinfrastruktur- und Verzeichniskomponenten müssen Sie möglicherweise 

Informationen zu weiteren Infrastrukturkomponenten sammeln. Hierzu gehören: 

• Exchange Server-Implementierung Wenn Ihr Unternehmen Exchange Server einsetzt, müssen Sie 

die Exchange Server-Infrastruktur dokumentieren. Exchange-Server und Messagingclients unterliegen 

einer starken Abhängigkeit von AD DS, die sich auf die Anzahl und die Platzierung der 

Domänencontroller und globalen Katalogserver auswirkt. Wenn Ihr Unternehmen außerdem 

Exchange Server 2007 einsetzt oder einzusetzen plant, müssen Sie die das Exchange-Nachrichtenrouting 

beim Entwurf der Standortkonfiguration berücksichtigen. Weitere Einzelheiten zum Einfluss 

von Exchange Server auf Ihren AD DS-Entwurf finden Sie im Abschnitt „Exchange Server 

2007 und der Standortentwurf“ weiter unten in diesem Kapitel. 

• Verzeichnisfähige Anwendungen Dokumentieren Sie außer Exchange Server auch alle weiteren 

verzeichnisfähigen Anwendungen, die im Unternehmen eingesetzt werden. Beschreiben Sie in 

Ihrer Dokumentation, ob die Anwendung derzeit Active Directory oder einen anderen Verzeichnisdienst 

nutzt, ob die Anwendung AD DS-Schemaänderungen erfordert und wo die Anwendung 

bereitgestellt wird. 

• Infrastruktur zur Sicherung und Notfallwiederherstellung In den meisten Fällen müssen die AD DS- 

Domänencontroller in die aktuelle Infrastruktur für die Sicherung und Notfallwiederherstellung 

integriert werden. Sammeln Sie Informationen zur Sicherungs- und Notfallwiederherstellungstechnologie 

und zu den Sicherungszeitplänen und -vorgängen. 

• Zusätzliche Anwendungen Erstellen Sie eine Inventarisierung der in Ihrer Umgebung verwendeten 

Produkte, einschließlich der Antiviruslösungen, Speicherverwaltungssoftware und Systemverwaltungs- 

und -überwachungstools. 

Dokumentieren von Verwaltungsmodellen und -prozessen 

Die Verwaltungsstruktur und -prozesse in Ihrem Unternehmen haben großen Einfluss auf den Entwurf 

der IT-Infrastruktur. Dies gilt vor allem für den AD DS-Entwurf aufgrund der Flexibilität, die 

AD DS für die Delegierung administrativer Aufgaben bereitstellen. Berücksichtigen Sie beim Dokumentieren 

des Verwaltungsmodells folgende Aspekte:


• Aktuelles Verwaltungsmodell des Unternehmens In manchen Unternehmen erfolgt die IT-Verwaltung 

möglicherweise zentral, während in anderen Unternehmen die Zuständigkeiten an regionale 

Bereiche oder einzelne Geschäftsabteilungen delegiert werden. Der übliche Ansatz ist eine Kombination 

aus beidem, wobei einige IT-Funktionen, beispielsweise die Netzwerkbereitstellung und 

-sicherheit, zentral gehandhabt werden, während andere Funktionen, wie die Verwaltung von 

Benutzerkonten oder Desktopcomputern, an geografische oder geschäftliche Unterabteilungen 

delegiert werden. 

• Verwaltungsmodell mit Benutzerkonten In einer zentralen Umgebung kann eine einzige Gruppe 

von Administratoren diese Aufgaben für sämtliche Benutzer im gesamten Unternehmen durchführen. 

In einer nicht zentral ausgerichteten Umgebung liegt diese Verantwortung möglicherweise bei 

einer Abteilung oder bei einem anderen Team, beispielsweise bei der Personalverwaltung oder der 

Abteilung für die Sicherheit des Unternehmens. 

• Struktur mit Geschäftsabteilungen Auf die Beziehungen zwischen den Geschäftsabteilungen oder 

Geschäftsbereichen muss hier nicht ausführlich eingegangen werden. Allerdings ist es hilfreich, 

einige Aspekte dieser Beziehungen zu untersuchen. Beispiel: 

Müssen zwischen separaten Geschäftsabteilungen oder -bereichen Sicherheitsgrenzen eingerichtet 

werden? In diesem Fall ist möglicherweise ein Entwurf mit mehreren Gesamtstrukturen 

erforderlich. 

Welche Anforderungen bestehen für die Kommunikation zwischen verschiedenen Geschäftsabteilungen? 

Ist beispielsweise ein einheitliches Verzeichnis oder eine Adressliste für das gesamte 

Unternehmen erforderlich? 

Wie wird die Kommunikation zwischen den Abteilungen gesteuert? Mit anderen Worten, welche 

Gruppe ist für das Feststellen und Lösen von Problemen mit der Authentifizierung, mit dem 

Netzwerk oder mit Protokollen zuständig, durch welche die Kommunikation zwischen Benutzern 

und Ressourcen in verschiedenen Abteilungen verhindert wird? 

• Problembehandlung Die meisten großen Unternehmen verfügen über einen umfassend definierten 

Problembehandlungsprozess, der möglicherweise mehrere Supportlevel umfasst. Die Informationen 

über den aktuellen Problembehandlungsprozess sind nützlich für die Erstellung des Bereitstellungsplans 

und stellen außerdem sicher, dass die richtigen Administratoren die erforderliche 

Schulung zur Problembehandlung für die AD DS-Bereitstellung erhalten. 

• Änderungskontrollprozess Der Prozess zur Änderungskontrolle unterscheidet sich stark von 

Unternehmen zu Unternehmen. Einige Unternehmen haben keinen offiziellen Änderungskontrollprozess 

implementiert, während andere strenge Prozesse zur Änderungsanforderung, Genehmigung 

und Benachrichtigung vorsehen. Folgende Fragen sind für Änderungskontrollprozesse 

besonders relevant: 

Wie implementiert das Unternehmen Änderungen an der IT? Sie müssen bestimmte Prozesse 

feststellen, die bei der Implementierung von Änderungen stattfinden. 

Wie werden Änderungen an der IT-Infrastruktur genehmigt? Bevor Änderungen durchgeführt 

werden, ist möglicherweise eine besondere Genehmigung durch IT-Manager, Unternehmensadministratoren 

oder Sicherheitspersonal erforderlich. Sie müssen dokumentieren, wer die 

Entscheidungsträger sind und wie sie den Prozess zur Änderungsgenehmigung beeinflussen. 

Wie werden Änderungsbenachrichtigungen gehandhabt? Bevor die Änderung durchgeführt 

wird, müssen alle betroffenen Benutzer über die Änderung und alle dadurch verursachten 

Auswirkungen informiert werden.


 

 

 

Es ist wichtig, alle aktuellen Prozesse zur Änderungsbenachrichtigung und die Anforderungen 

zu dokumentieren, in denen festgelegt ist, wann Änderungsbenachrichtigungen erforderlich 

sind. 

Welche Prozesse werden im Notfall zur Eskalation eingesetzt? Wenn während der Implementierung 

der genehmigten Änderung Probleme auftreten, müssen Sie wissen, an wen Sie sich 

wenden können, um die erforderlichen Vorgehensweisen zur Problembehandlung und Wiederherstellung 

zu erfragen. 

Welche Zeitrahmen gelten für die Durchführung von Änderungen, die sich auf die Verfügbarkeit 

auswirken? Viele Unternehmen begrenzen die Zeiträume, in denen wichtige Netzwerkdienste 

geändert oder offline geschaltet werden dürfen. 

Welche Prozesse werden im Zusammenhang mit der Änderungsverwaltung zur Risikoverwaltung 

eingesetzt? Zu einem vollständigen Änderungskontrollprozess gehört eine Risikoanalyse 

und Prozesse zum Verringern von Risiken. 

Entwerfen der Gesamtstruktur 

Nachdem Sie die Geschäfts- und die technischen Anforderungen gesammelt und die aktuelle Umgebung 

dokumentiert haben, können Sie mit dem Entwurf der AD DS-Infrastruktur beginnen. Wahrscheinlich 

die wichtigste Entscheidung, die Sie früh im Entwurfsvorgang treffen müssen, ist, wie viele 

Gesamtstrukturen Sie erstellen möchten. Der Einsatz einer einzigen AD DS-Gesamtstruktur vereinfacht 

die Freigabe und den Zugriff auf Informationen innerhalb des Unternehmens. Außerdem ist auch 

die zentrale Verwaltung der gesamten Verzeichnisinfrastruktur einfacher. Die Nutzung einer einzigen 

Gesamtstruktur für ein großes Unternehmen verlangt jedoch ein erhebliches Maß an Zusammenarbeit 

und gegenseitiger Abhängigkeit zwischen möglicherweise verschiedenartigen und unzusammenhängenden 

Geschäftsabteilungen. Letztlich hängt die Anzahl an bereitgestellten Gesamtstrukturen davon 

ab, was in Ihrem Unternehmen wichtiger ist: die einfache Freigabe von Informationen über alle Domänen 

in der Gesamtstruktur hinweg oder die Möglichkeit, einen Teil der Verzeichnisstruktur vollkommen 

unabhängig zu kontrollieren. 

In Abbildung 5.3 wird der Prozess zum Erstellen eines Gesamtstrukturentwurfs dargestellt. 

Gesamtstrukturen und der AD DS-Entwurf 

Eine AD DS-Gesamtstruktur wird als abgeschlossene Einheit entworfen. Innerhalb der Gesamtstruktur 

ist es einfach, Informationen gemeinsam zu nutzen und mit anderen Benutzern in derselben Einheit 

zusammenzuarbeiten. Weil es sich bei der Gesamtstruktur jedoch um eine abgeschlossene Einheit 

handelt, können sich die Handlungen einer einzigen Person möglicherweise auf alle anderen in 

der Gesamtstruktur auswirken. Beim Entwerfen der höchsten Ebene der AD DS-Infrastruktur müssen 

Sie entscheiden, ob Sie eine oder mehrere Gesamtstrukturen einsetzen möchten. Jede Gesamtstruktur 

ist eine integrierte Einheit, weil sie über folgende Eigenschaften verfügt: 

• Globaler Katalog Die Gesamtstruktur kann viele globale Katalogserver enthalten, besitzt jedoch 

nur einen globalen Katalog. Mit dem globalen Katalog ist es einfach, Objekte in jeder Domäne in 

der Gesamtstruktur zu finden und sich an einer beliebigen Domäne in der Gesamtstruktur zu 

authentifizieren, unabhängig davon, welche Domäne Ihr Benutzerkonto hostet.

Entwerfen der Gesamtstruktur 155 

Prüfen von 

Auswirkungen der 

Auswahl einer oder 

mehrerer Gesamtstrukturen 

Ermitteln, ob mehrere 


benötigt werden 

Mehrere Gesamtstrukturen 

erforderlich 

Eine Gesamtstruktur 

erforderlich 

Festlegen der Anzahl 

an Gesamtstrukturen 

Festlegen des 

Gesamtstruktur-Entwurfsmodells 

Festlegen der 

Gesamtstrukturintegration 

Für jede Gesamtstruktur 

Festlegen des Entwurfs der 

Gesamtstrukturvertrauensstellungen 

Festlegen des 

Gesamtstrukturbesitzers 

Festlegen des Verfahrens zur 

Änderungssteuerung der Gesamtstruktur 

Abbildung 5.3 

Erstellen eines Gesamtstrukturentwurfs 

• Konfigurationsverzeichnispartition Alle Domänencontroller nutzen dieselbe Konfigurationsverzeichnispartition. 

Diese Konfigurationsinformationen werden zum Optimieren der Replikation 

von Informationen über die gesamte Gesamtstruktur, zum Speichern von Anwendungsinformationen 

für verzeichnisfähige Anwendungen und zum Freigeben von Informationen in Anwendungsverzeichnispartitionen 

verwendet. 

• Vertrauensstellungen Alle Domänen in der Gesamtstruktur sind über bidirektionale transitive Vertrauensstellungen 

verbunden. Es gibt keine Möglichkeit, dies zu ändern.


Hinweis Am besten kann man die Art, wie eine einzige Gesamtstruktur die Zusammenarbeit vereinfacht, 

anhand von Microsoft Exchange 2000 Server und späteren Versionen nachvollziehen. Die Gesamtstrukturgrenze 

ist auch die Grenze für die Exchange Server-Organisation. Exchange Server speichert die meisten 

Konfigurationsdaten in der Konfigurationsverzeichnispartition, sodass das Nachrichtenrouting in einem großen 

Unternehmen einfach verwaltet werden kann. Die globale Adressliste (GAL) besteht aus allen E-Mail- 

Empfängern im globalen Katalog. Eine einzige Exchange Server-Organisation ist für die meisten Unternehmen 

ideal. Innerhalb eines Unternehmens sind Kalenderinformationen, öffentliche Ordner und Empfängerdaten 

für jedermann zugänglich, und viele Arten der Zusammenarbeit sind standardmäßig aktiviert. Sobald 

Sie mehrere Organisationen (und mehrere Gesamtstrukturen) bereitstellen, sind diese Vorteile wesentlich 

schwieriger umzusetzen. 

Auch wenn die Freigabe von Informationen durch AD DS vereinfacht wird, werden auch eine Reihe 

von Einschränkungen durchgesetzt, welche die Zusammenarbeit verschiedener Abteilungen des 

Unternehmens in mehrerlei Hinsicht erfordern. Zu diesen Einschränkungen gehören Folgende: 

• Ein Schema Alle Domänen in der Gesamtstruktur nutzen ein einziges Schema. Dies klingt zwar 

lapidar, kann jedoch der wichtigste Grund für ein Unternehmen sein, mehrere Gesamtstrukturen 

einzusetzen. Wenn eine Geschäftseinheit beschließt, eine Anwendung einzusetzen, die das 

Schema verändert, sind hiervon alle Geschäftseinheiten betroffen. Wenn sich gleich 20 Geschäftseinheiten 

für den Einsatz von schemaverändernden Anwendungen entschließen, kann dies unkontrollierbare 

Auswirkungen haben. Jede Schemaänderung muss getestet werden, um sicherzustellen, 

dass kein Konflikt mit anderen Schemaänderungen entsteht. 

• Richtlinien zur Änderungskontrolle Weil Änderungen an der Gesamtstruktur sich auf jede Domäne 

auswirken können und weil die meisten größeren Änderungen nur zentral vorgenommen werden 

sollten, muss eine gut definierte Richtlinie zur Änderungskontrolle eingesetzt werden. 

• Zentrale Verwaltung Die Entscheidung für den Einsatz einer einzigen Gesamtstruktur bedeutet, 

dass einige Komponenten der Netzwerkadministration zentral verwaltet werden müssen. Beispielsweise 

besitzt nur die Gruppe Schema-Admins das Recht zum Ändern des Schemas. Die einzige 

Gruppe zum Hinzufügen und Entfernen von Domänen aus der Gesamtstruktur ist die Gruppe 

Organisations-Admins. Beide Gruppen sind in der Gesamtstruktur-Stammdomäne enthalten, und 

die Handlungen dieser Administratoren betreffen die gesamte Gesamtstruktur. Die Gruppe Organisations-Admins 

wird der domänenlokalen Gruppe Administratoren automatisch auf jedem 

Domänencontroller in der Gesamtstruktur hinzugefügt. Für einige Unternehmen ist diese Art der 

zentralen Verwaltung nicht akzeptabel. 

• Vertrauenswürdige Administratoren Der Einsatz einer einzigen Gesamtstruktur erfordert ein 

gewisses Maß an Vertrauen von allen Administratoren in allen Domänen. Jeder Administrator mit 

den Rechten zum Verwalten eines Domänencontrollers kann Änderungen vornehmen, die sich auf 

die ganze Gesamtstruktur auswirken. Das heißt, dass alle Domänenadministratoren sehr vertrauenswürdig 

sein müssen. Sie können das Risiko, dass Administratoren für die ganze Gesamtstruktur 

gültige Änderungen vornehmen, verringern, indem Sie an Standorten, an denen keine 

besonders vertrauenswürdigen Administratoren beschäftigt sind, RODCs einsetzen. 

Während Sie sich mit der Frage beschäftigen, wie viele Gesamtstrukturen eingesetzt werden sollen, 

müssen Sie die Vorteile einer einzelnen Gesamtstruktur gegen die Art und Weise abwägen, in der eine 

einzelne Gesamtstruktur ein hohes Maß an Integration zwischen Domänen, OUs und den von diesen 

Objekten dargestellten Geschäftseinheiten verlangt.

Einzelne oder mehrere Gesamtstrukturen 


Wie zuvor erwähnt, ist die wichtigste Frage bei der Erstellung Ihres Gesamtstrukturentwurfs die nach 

der Anzahl an Gesamtstrukturen. Diese Entscheidung sollte vor der Bereitstellung getroffen werden, 

weil sie nach der Bereitstellung nur schwer geändert werden kann. Es gibt keinen einzelnen Schritt 

zum Zusammenführen von Gesamtstrukturen; stattdessen müssen Sie alle Objekte, die Sie in die neue 

Gesamtstruktur aufnehmen möchten, aus der alten Gesamtstruktur verschieben. Außerdem kann eine 

einzelne Gesamtstruktur nicht einfach in zwei Gesamtstrukturen aufgeteilt werden. Sie müssen 

zunächst eine separate Gesamtstruktur erstellen und anschließend Objekte von einer in die andere 

verschieben. 

Die übliche Bereitstellung einer AD DS-Gesamtstruktur ist eine einzige Gesamtstruktur. Für die meisten 

Unternehmen überwiegen die Vorteile eines gemeinsam genutzten globalen Katalogs, vorgegebener 

Vertrauensstellungen und einer gemeinsamen Konfigurationsverzeichnispartition gegenüber der 

Verwaltung einer völligen Trennung sämtlicher administrativer Rollen. Wenn Sie am Entwurf der AD 

DS arbeiten, sollte Ihre erste Wahl immer der Einsatz einer einzigen Gesamtstruktur sein. Gehen Sie 

zunächst von einer einzigen Gesamtstruktur aus, und seien Sie darauf vorbereitet, sich vielleicht von 

einer anderen Lösung überzeugen zu lassen. 

Andererseits gibt es klare Situationen, in denen mehrere Gesamtstrukturen die beste Option darstellen: 

• Einige Unternehmen setzen separate AD DS-Gesamtstrukturen in Umkreisnetzwerken (oder 

entmilitarisierten Zonen) ein. Die meisten Unternehmen verwenden Server, die direkt über das 

Internet in einem Umkreisnetzwerk zugänglich sein müssen, um eine zusätzliche Sicherheitsstufe 

für das interne Netzwerk zu gewährleisten. Diese Server können als eigenständige Server 

eingesetzt werden; durch Bereitstellung einer separaten AD DS-Gesamtstruktur im Umkreisnetzwerk 

können Sie jedoch von den AD DS-Funktionen zur Computer- und Benutzerverwaltung 

profitieren und gleichzeitig die Isolation von der internen AD DS-Gesamtstruktur sicherstellen. 

• Einige Unternehmen stellen keine hohen Anforderungen an die Zusammenarbeit zwischen den 

internen Abteilungen. In manchen Unternehmen arbeiten Geschäftseinheiten relativ unabhängig 

voneinander, und es werden abgesehen von E-Mails nur wenige Informationen ausgetauscht. Diesen 

Unternehmen gehen durch den Einsatz mehrerer Gesamtstrukturen keine Vorteile verloren. 

• Manche Unternehmen benötigen eine völlige Trennung von Netzwerkinformationen. Aus Sicherheits- 

oder rechtlichen Gründen kann ein Unternehmen gezwungen sein sicherzustellen, dass 

einige Netzwerkdaten niemandem außerhalb der Geschäftseinheit zugänglich sind. Standardmäßig 

sind die Informationen in einer Gesamtstruktur in keiner anderen Gesamtstruktur sichtbar. 

• Einige Unternehmen benötigen nicht kompatible Schemakonfigurationen. Wenn zwei Teile des 

Unternehmens ein jeweils eigenes Schema verlangen, weil sie Anwendungen einsetzen, die nicht 

kompatible Änderungen am Schema vornehmen, müssen separate Gesamtstrukturen erstellt werden. 

• Manche Unternehmen können sich nicht auf eine zentrale Verwaltung einigen. Wenn Geschäftseinheiten 

sich nicht auf Richtlinien zur Änderungskontrolle für Gesamtstruktur oder Schema oder 

auf eine zentrale Verwaltung einigen können, müssen Sie separate Gesamtstrukturen bereitstellen. 

• Einige Unternehmen müssen das Ausmaß an Vertrauensstellungen begrenzen. Innerhalb einer 

Gesamtstruktur teilen alle Domänen eine transitive Vertrauensstellung, die nicht aufgehoben werden 

kann. Wenn Ihre Netzwerkumgebung eine Vertrauensstellungskonfiguration verlangt, bei der 

es keine bidirektionalen transitiven Vertrauensstellungen zwischen allen Domänen geben darf, 

müssen mehrere Gesamtstrukturen eingerichtet werden.


Für einige Unternehmen mag die Verwendung mehrerer Gesamtstrukturen attraktiv erscheinen. Die 

Netzwerkinfrastruktur wird jedoch hierdurch wesentlich komplexer. Folgende Aspekte sind unter 

anderem zu berücksichtigen: 

• Erhöhter Administrationsaufwand für die Netzwerkverwaltung. Mindestens eine Domäne sowie 

die Konfiguration auf Gesamtstrukturebene müssen in jeder Gesamtstruktur verwaltet werden. 

• Weniger Möglichkeiten zur Zusammenarbeit zwischen Benutzern. Ein Beispiel hierfür ist das 

Durchsuchen des Netzwerks nach Ressourcen. Benutzer können nicht länger den globalen Katalog 

nach Ressourcen in der anderen Gesamtstruktur durchsuchen. Benutzer müssen geschult werden, 

um nach Ressourcen außerhalb des globalen Katalogs suchen zu können. 

• Zusätzlicher Verwaltungsaufwand für den Zugriff von Benutzern auf Ressourcen in anderen 

Gesamtstrukturen. Administratoren müssen die Vertrauensstellungen konfigurieren, statt die vorgegebenen 

Vertrauensstellungen zu nutzen. Wenn zwischen den Gesamtstrukturen Informationen 

synchronisiert werden müssen, so muss auch dies zunächst konfiguriert werden. 

Einbeziehen des Unternehmens in den Gesamtstrukturentwurf 

Wenige Unternehmen besitzen rein technische Gründe für den Einsatz mehrerer Gesamtstrukturen. 

Eine Gesamtstruktur kann mehrere Domänen enthalten, wobei jede Domäne Hunderte oder Tausende 

von Objekten umfassen kann. Die Domänen können mit mehreren Namespaces und je 

Domäne mit einer unterschiedlichen Verwaltung bereitgestellt werden. 

Wenn Sie den Entscheidungsträgern Ihres Unternehmens jedoch die Liste der Anforderungen einer 

Gesamtstruktur vorlegen, also zentrale Steuerung, ein gemeinsames Schema oder vertrauenswürdige 

Administratoren, stoßen Sie mit Sicherheit auf Widerstand. Die üblichen Gründe, aus denen Unternehmen 

mehrere Gesamtstrukturen einsetzen, liegen in der Unternehmenspolitik oder darin, dass verschiedene 

Abteilungen oder Geschäftseinheiten sich nicht auf die zentralen Komponenten zur Verwaltung 

einer einzigen Gesamtstruktur einigen können. In manchen Fällen kann das Unternehmen 

sich nicht auf einen Prozess zur Gesamtstruktur- oder Schemaänderung einigen. In anderen Fällen 

macht die Tatsache, dass ein Domänenadministrator in einer Domäne sämtliche anderen Domänen in 

der Gesamtstruktur schädigen kann, eine Gesamtstruktur mit einer einzigen Domäne inakzeptabel. Dies 

gilt vor allem für das gängige Szenario, in dem eine Reihe von zuvor unabhängigen Unternehmen 

aufgrund von Firmenübernahmen oder Fusionen jetzt zusammen arbeiten müssen. 

Separate Gesamtstrukturen sind möglicherweise die Lösung für einige dieser Unternehmen; Sie 

müssen jedoch die Entscheidungsträger darauf hinweisen, was ihnen entgeht, wenn sie auf mehreren 

Gesamtstrukturen bestehen. Die Implementierung mehrerer Gesamtstrukturen ermöglicht eine 

Autonomie zwischen den Geschäftseinheiten, bedeutet jedoch auch, dass die gemeinsame Nutzung 

von Informationen viel schwieriger und die Verwaltung der Umgebung wesentlich kostspieliger 

wird. 

Entwerfen von Gesamtstrukturen für die AD DS-Sicherheit 

Für manche Unternehmen begründet sich die Entscheidung für mehrere Gesamtstrukturen letztlich 

darauf, dass das Unternehmen administrative Autonomie oder eine administrative Abgrenzung zwischen 

den Geschäftseinheiten erfordert. In AD DS gibt es viele Arten administrativer Tätigkeiten. 

Hierzu gehören sowohl die Konfiguration der Verzeichnisdienste (Gesamtstrukturkonfiguration, 

Domänencontrollerplatzierung, DNS-Konfiguration) als auch die Verwaltung der Daten im Verzeichnisdienst 

(Verwalten von Benutzer- und Gruppenobjekten, Gruppenrichtlinienobjekten etc.).


Besitzer und Administratoren von Diensten und Daten 

In großen Unternehmen sind die administrativen AD DS-Rollen oft in verschiedene Kategorien 

unterteilt. Eine Möglichkeit, die verschiedenen Kategorien zu beschreiben, besteht in der 

Unterscheidung zwischen Dienstbesitzern und -administratoren sowie Datenbesitzern und 

-administratoren: 

• Dienstbesitzer und -administratoren sind für AD DS als Dienst verantwortlich. Das heißt, sie 

sind für den Entwurf und die Verwaltung der AD DS-Infrastruktur zuständig. Die Dienstbesitzer 

treffen die Entscheidungen, wie viele Gesamtstrukturen, Domänen und Standorte erforderlich 

sind, damit der AD DS-Dienst den Anforderungen des Unternehmens entspricht. Die 

Dienstadministratoren besitzen die erforderlichen Rechte und Berechtigungen, um diese AD 

DS-Objekte zu erstellen und zu verwalten. 

• Datenbesitzer und -administratoren sind für die in AD DS gespeicherten Daten verantwortlich. 

Die Datenbesitzer legen Richtlinien und Prozesse für die Datenverwaltung fest, und die Datenadministratoren 

besitzen die Rechte und Berechtigungen zum Erstellen der AD DS-Objekte 

innerhalb der von den Dienstbesitzern und -administratoren definierten Struktur. 

Grundsätzlich empfiehlt es sich, nur sehr wenige Dienstadministratoren in einem Unternehmen zu 

beschäftigen. Demnach sollten nur sehr wenige Konten die erforderlichen Berechtigungen zum 

Ändern der AD DS-Struktur besitzen. Standardmäßig besitzen die Gruppen Domänen-Admins in 

der Gesamtstruktur-Stammdomäne, Organisations-Admins und Schema-Admins die Berechtigungen 

von Dienstbesitzern. Da Berechtigungen für Datenadministratoren jedoch auf bestimmte 

Container innerhalb einer OU begrenzt werden können, kann ein Unternehmen wesentlich mehr 

Datenadministratoren einsetzen. Um die Konten von Datenadministratoren zu konfigurieren, sollten 

Sie die erforderlichen Gruppen und Konten erstellen demjenigen Container und spezifische 

Berechtigungen zuweisen, auf den der Datenadministrator zugreifen muss. 

Beim Entwerfen einer administrativen Trennung oder Autonomie müssen Sie sowohl Dienstadministratoren 

als auch Datenadministratoren berücksichtigen. Auch wenn ein Dienstadministrator höhere 

Berechtigungen besitzt, kann auch ein Datenadministrator noch Änderungen an AD DS vornehmen, 

die sich auf die ganze Gesamtstruktur auswirken. Wenn ein Datenadministrator beispielsweise 

ein neues Benutzerkonto erstellt, wird der globale Katalog für das gesamte Unternehmen 

geändert. 

Eine detailliertere Diskussion zur Rolle von Dienst- und Datenbesitzern und -administratoren finden 

Sie unter „Creating a Forest Design“ unter http://technet2.microsoft.com/windowsserver/en/ 

library/ff92f142-66ea-498b-ad0f-a379c411eb6e1033.mspx?mfr=true. Dieser Leitfaden basiert auf 

dem Einsatz von Windows Server 2003-Gesamtstrukturen. Viele der Grundsätze gelten auch für 

Windows Server 2008. Sie sollten außerdem im TechCenter für Windows Server 2008 nach einer 

aktualisierten Version dieses Leitfadens suchen. 

Administrative Autonomie heißt, dass Sie vollständige administrative Kontrolle über einige Komponenten 

der Gesamtstruktur besitzen. Sie können über administrative Autonomie auf Gesamtstrukturebene, 

Domänenebene oder OU-Ebene verfügen. Administrative Autonomie heißt jedoch nicht, dass 

Sie endgültige oder exklusive Kontrolle besitzen. Beispielsweise können Sie Ihre Domäne vollständig 

verwalten, die Gruppe Organisations-Admins der Gesamtstruktur-Stammdomäne besitzt jedoch 

ebenfalls administrative Berechtigungen für Ihre Domäne.


Administrative Isolation hingegen heißt, dass Sie die exklusive Kontrolle für eine Komponente des 

Verzeichnisses besitzen. Im Falle administrativer Isolierung besitzt niemand sonst die Kontrolle über 

Ihren Teil der Gesamtstruktur, und niemand sonst kann die Verzeichnisdienstkonfiguration oder die 

Daten in Ihrem Teil der Gesamtstruktur ändern. 

AD DS stellen viele Möglichkeiten zum Erreichen administrativer Autonomie bereit. Domänenadministratoren 

haben in einer Domäne freie Hand. OU-Administratoren können vollständige Rechte zum 

Erstellen und Administrieren jeder Art von Objekten in einer OU erhalten. Eine einzige Gesamtstruktur 

in AD DS ist auf administrative Delegierung und Autonomie ausgelegt. 

Wenn Sie jedoch administrative Isolation benötigen, kann dies nur durch Erstellung separater Gesamtstrukturen 

erreicht werden. Dies liegt zum Teil am Aufbau der AD DS. Die Gruppe Organisations- 

Admins wird automatisch jeder domänenlokalen Gruppe Administratoren hinzugefügt. Die Gruppe 

Domänen-Admins besitzt die vollständige Kontrolle über jedes Objekt in der Domäne und wird automatisch 

der Gruppe Administratoren auf jedem Computer in der Domäne hinzugefügt. Auch wenn die 

Standardkonfiguration geändert werden kann und die Gruppen aus den administrativen Gruppen niedrigerer 

Ebene entfernt werden können, können Administratoren einer höheren Ebene jederzeit die 

Kontrolle über Objekte auf niedrigerer Ebene zurückerlangen. Das heißt, dass kein Teil der Gesamtstruktur 

in administrativer Hinsicht isoliert ist. 

Ein weiterer Grund dafür, dass eine separate Gesamtstruktur zur administrativen Isolation benötigt 

wird, ist die Möglichkeit böswilliger Aktionen vonseiten der Administratoren in der Domäne. Jeder, 

der Administratorzugriff auf einen Domänencontroller besitzt, kann die administrative Isolation einer 

beliebigen anderen Partition in der Gesamtstruktur verletzen. Ein Administrator kann auf dem Domänencontroller 

in einer Domäne Software installieren, welche die Verzeichnisinformationen für jede 

Domäne in der Gesamtstruktur verändert. Der Administrator kann die eigene Sicherheitskennung 

(Security Identifier, SID) so verändern, dass er scheinbar ein Mitglied der Gruppe Organisations- 

Admins ist, und diesen Zugriff anschließend nutzen, um Änderungen an der ganzen Gesamtstruktur 

vorzunehmen. 

Alle Domänencontroller und Partitionen in der Gesamtstruktur sind eng integriert, und jede Änderung 

an einem beschreibbaren Domänencontroller wird auf alle übrigen Domänencontroller repliziert. 

Es gibt keine Sicherheitsprüfung für die Gültigkeit replizierter Informationen; es gibt nur eine 

Sicherheitsprüfung beim Vornehmen von Änderungen an den Verzeichnisdaten. Wenn daher ein böswilliger 

Administrator es schafft, Änderungen an den Verzeichnisdaten vorzunehmen, werden die 

replizierten Änderungen von allen übrigen Domänencontrollern blind übernommen. Aus diesen Gründen 

müssen Sie separate Gesamtstrukturen erstellen, wenn Sie administrative Isolation benötigen. In 

manchen Fällen müssen Sie eine vollständige Isolation einer Verzeichnispartition sicherstellen. In diesem 

Fall müssen Sie den zusätzlichen administrativen Aufwand und den Verlust der Zusammenarbeit 

in Kauf nehmen, den der Einsatz mehrerer Gesamtstrukturen mit sich bringt. 

Viele Unternehmen fordern jedoch administrative Autonomie zusammen mit einer angemessenen 

Zusicherung, dass Administratoren aus anderen Partitionen in der Gesamtstruktur nicht böswillig 

handeln werden. Diese angemessene Zusicherung kann in den meisten Unternehmen folgendermaßen 

erzielt werden: 

• Nehmen Sie nur extrem vertrauenswürdige Administratoren in Gruppen auf, die administrative 

Kontrolle über Domänencontroller besitzen. Zu diesen Gruppen gehören die Gruppe Domänen- 

Admins sowie die domänenlokalen Gruppen Administratoren, Server-Operatoren und Sicherungs- 

Operatoren. Administrative Aufgaben, die keinen Zugriff auf die Domänencontroller erfordern, 

sollten an andere Gruppen delegiert werden.


• Sichern Sie die Domänencontroller physisch, und ermöglichen Sie nur besonders vertrauenswürdigen 

Administratoren Zugriff auf die Server. 

• Überprüfen Sie alle von Administratoren höherer Ebene durchgeführten Aktionen. 

Administratoren höherer Ebene sollten sich nur bei Bedarf mit dem Administratorkonto anmelden. 

Diese Administratoren sollten außerdem normale Benutzerkonten für die tägliche Arbeit besitzen. 

Modelle für den Gesamtstrukturentwurf 

Auf einer höheren Ebene gibt es drei gängige Modelle für den Gesamtstrukturentwurf. Die meisten 

Unternehmen benötigen eines dieser Gesamtstrukturentwurfsmodelle; in manchen Unternehmen müssen 

Sie möglicherweise eine Kombination von Entwürfen verwenden. 

Organisatorisches Gesamtstrukturmodell 

Im organisatorischen Gesamtstrukturmodell werden die Gesamtstrukturen anhand einiger organisatorischer 

Kriterien entworfen. Beispielsweise wird sich ein Unternehmen mit mehreren Geschäftseinheiten 

oder geografischen Standorten bzw. ein Unternehmen, das sich durch Übernahmen oder 

Fusionen gebildet hat, möglicherweise für ein organisatorisches Gesamtstrukturmodell entscheiden. 

Um den Zugriff auf Ressourcen zwischen den organisatorischen Entitäten zu ermöglichen, können Sie 

Gesamtstrukturvertrauensstellungen oder externe Vertrauensstellungen zwischen bestimmten Domänen 

in jeder Gesamtstruktur konfigurieren. Eine Darstellung des organisatorischen Gesamtstrukturmodells 

finden Sie in Abbildung 5.4. 

Optionale 


Benutzer 

Benutzer 

Server Gruppe 

Freigegebene Ressourcen 

Adatum.com 

Server Gruppe 


Fabrikam.com 

Benutzer 

Optionale 

externe Vertrauensstellung 

Server 

Gruppe 


NA.Adatum.com 

Abbildung 5.4 

Ein organisatorisches Gesamtstrukturmodell


Hinweis Wenn ein Unternehmen nur eine einzige Gesamtstruktur einsetzt, verwendet es das organisatorische 

Gesamtstrukturmodell. 

In diesem Modell werden alle Benutzerkonten und freigegebenen Ressourcen, die den einzelnen organisatorischen 

Entitäten zugehören, innerhalb der relevanten Gesamtstruktur gespeichert. Durch Erstellen 

separater Gesamtstrukturen können Sie administrative Autonomie und Isolation zwischen den 

Geschäftseinheiten sicherstellen. 

Ressourcengesamtstrukturmodell 

Im Ressourcengesamtstrukturmodell erfolgt die Verwaltung von Benutzer- und Gruppenkonten von 

der Ressourcenverwaltung getrennt, indem für jede Funktion eine separate Gesamtstruktur erstellt 

wird. Alle Benutzer- und Gruppenkonten sind in einer oder in mehreren Kontengesamtstrukturen 

gespeichert, und alle freigegebenen Ressourcen sind auf Servern in einer oder in mehreren Ressourcengesamtstrukturen 

konfiguriert. Die Ressourcengesamtstrukturen enthalten keine Benutzerkonten 

außer den Administratorkonten und den Dienstkonten, die für Anwendungen erforderlich sind. 

Im Ressourcengesamtstrukturmodell müssen Sie Vertrauensstellungen zwischen den beiden Gesamtstrukturen 

konfigurieren. In den meisten Fällen handelt es sich hierbei um eine unidirektionale 

Gesamtstrukturvertrauensstellung, die so konfiguriert ist, dass Benutzer in der Kontengesamtstruktur 

auf die Ressourcen in der Ressourcengesamtstruktur zugreifen können. In diesem Modell können Sie 

bidirektionale Vertrauensstellungen, externe Vertrauensstellungen oder Gesamtstrukturvertrauensstellungen 

mit ausgewählter Authentifizierung aktivieren. Abbildung 5.5 zeigt eine Darstellung des Ressourcengesamtstrukturmodells. 

Unidirektionale 



Abbildung 5.5 

Benutzer 

Gruppe 

Adatum.com 

Ein Ressourcengesamtstrukturmodell 

Freigegebene 

Domänen- 

Ressourcen 

controller 

AdatumResources.com 

Das Ressourcengesamtstrukturmodell ermöglicht administrative Autonomie und Isolation sowohl für 

die Konten- als auch für die Ressourcengesamtstrukturen. 

Gesamtstrukturmodell mit eingeschränktem Zugriff 

Das Gesamtstrukturmodell mit eingeschränktem Zugriff ist eine Variation des organisatorischen 

Gesamtstrukturmodells. In einem Gesamtstrukturmodell mit eingeschränktem Zugriff wird eine separate 

Gesamtstruktur mit Benutzerkonten und freigegebenen Ressourcen erstellt, die vom Rest des 

Unternehmens isoliert werden müssen. 

Server


Die Gesamtstruktur mit eingeschränktem Zugriff unterschiedet sich von der organisatorischen 

Gesamtstruktur dadurch, dass zwischen den beiden Domänen keine Vertrauensstellungen konfiguriert 

werden. 

Die Gesamtstruktur mit eingschränktem Zugriff ist darauf ausgelegt, administrative Isolation sicherzustellen. 

Das bedeutet, dass kein Benutzerkonto in einer Gesamtstruktur außerhalb der Gesamtstruktur 

mit eingeschränktem Zugriff Berechtigungen für Daten oder Zugriff auf Daten in der Gesamtstruktur 

besitzt. Wenn Benutzer in der organisatorischen Gesamtstruktur Zugriff auf die Gesamtstruktur 

mit eingeschränktem Zugriff benötigen, müssen sie über ein separates Benutzerkonto in dieser 

Gesamtstruktur verfügen und zwei Clientcomputer besitzen, die jeweils einer anderen Gesamtstruktur 

angehören. Abbildung 5.6 zeigt eine Darstellung des Gesamtstrukturmodells mit eingeschränktem 

Zugriff. 

Benutzer müssen in 

beiden Gesamtstrukturen 

über Konten und 

Clientcomputer verfügen 

Server 

Benutzer 

Gruppe 

Zwischen Gesamtstrukturen 

ist keine Vertrauensstellung 

konfiguriert 

Server 

Benutzer 

Gruppe 


Adatum.com 


AdatumRestricted.com 

Abbildung 5.6 

Ein Gesamtstrukturmodell mit eingeschränktem Zugriff 

Definieren des Gesamtstrukturbesitzes 

Unabhängig von der Anzahl der eingesetzten Gesamtstrukturen müssen Sie die Besitzer der einzelnen 

Gesamtstrukturen festlegen. Technisch ist es einfach, die Besitzer der Gesamtstrukturen zu definieren. 

Die Gruppe Schema-Admins, die Gruppe Organisations-Admins und die Gruppe Domänen- 

Admins in der Stammdomäne können als Gesamtstrukturbesitzer betrachtet werden, weil sie steuern, 

welche Änderungen an der Gesamtstruktur vorgenommen werden können. Diese Rollen sind jedoch 

rein technischer Natur, und die Personen in diesen Gruppen sind fast nie die letzte Instanz, die 

entscheidet, ob Änderungen an der Gesamtstruktur tatsächlich durchgeführt werden. Die Gruppe 

Schema-Admins kann zum Beispiel das Schema ändern, aber ein Mitglied der Gruppe Schema-Admins 

besitzt normalerweise nicht die Befugnis zu entscheiden, ob die Anforderung einer Schemaänderung 

genehmigt wird. 

Gesamtstrukturbesitzer sollten eine Kombination aus technischem Fachwissen und Geschäftssinn besitzen. 

Es sollte sich um Personen handeln, die die allgemeinen Geschäftsanforderungen eines Unternehmens 

kennen, jedoch auch die technischen Auswirkungen der Erfüllung all dieser Anforderungen 

verstehen. Gesamtstrukturbesitzer können entscheiden, dass eine schemaverändernde Anwendung eingesetzt 

wird, weil sie dem Unternehmen erhebliche geschäftliche Vorteile bringt. Der Schemaadministrator 

erhält anschließend die Aufgabe, das Schema entsprechend zu bearbeiten. 

In einem Unternehmen mit mehreren Geschäftseinheiten sollte die Gruppe der Gesamtstrukturbesitzer 

aus Vertretern sämtlicher Geschäftseinheiten bestehen. Auch wenn es wichtig ist, dass alle 

Geschäftseinheiten repräsentiert werden, muss diese Gruppe jedoch auch in der Lage sein, effizient 

zu handeln.


Es muss daher ein Prozess eingesetzt werden, der der Gruppe ermöglicht, effizient zu entscheiden, ob 

eine Änderung auf Gesamtstrukturebene implementiert wird oder nicht. Wenn die Implementierung 

einer globalen Änderung unverhältnismäßig lange dauert, könnten einzelne Geschäftseinheiten möglicherweise 

bereuen, dass sie der Einrichtung einer einzigen Gesamtstruktur jemals zugestimmt haben. 

Richtlinien zur Kontrolle von Gesamtstrukturänderungen 

Die erste Aufgabe für Gesamtstrukturbesitzer besteht darin, eine Richtlinie zur Kontrolle von Gesamtstrukturänderungen 

zu definieren. Diese Richtlinie definiert, welche Änderungen an der Konfiguration 

auf Gesamtstrukturebene unter welchen Umständen vorgenommen werden können. Im Wesentlichen 

gibt es zwei Typen von Gesamtstrukturänderungen: Schemaänderungen und Änderungen an 

der Konfigurationsverzeichnispartition (beispielsweise das Hinzufügen oder Entfernen von Domänen 

oder Anwendungsverzeichnispartitionen oder das Ändern der Standortkonfiguration). 

Die Richtlinie zur Kontrolle von Gesamtstrukturänderungen definiert außerdem die Vorgehensweisen 

zum Testen, Genehmigen und Implementieren aller Änderungen an der Gesamtstruktur. Dies ist vor 

allem für Schemaänderungen relevant, weil Schemaänderungen nicht einfach rückgängig gemacht 

werden können und weil jede Schemaänderung mit allen übrigen Schemaänderungen kompatibel sein 

muss. Die Richtlinie zur Kontrolle von Gesamtstrukturänderungen sollte den Testvorgang für Schemaänderungen 

definieren, und die Gesamtstrukturbesitzer sollten eine Testumgebung zum Prüfen dieser 

Änderungen bereitstellen. Die Richtlinie zur Kontrolle von Gesamtstrukturänderungen sollte einen 

gründlichen Test sämtlicher Änderungen auf Gesamtstrukturebene erfordern, jedoch auch sicherstellen, 

dass der Testvorgang schnell abgewickelt werden kann. Wenn die Verarbeitung jeder Änderungsanforderung 

einen langen Zeitraum beansprucht, wird sich der Frustrationsgrad der Benutzer stetig 

erhöhen. 

Die Richtlinie zur Kontrolle von Gesamtstrukturänderungen sollte vor dem Einsatz von AD DS 

bereitstehen. In Unternehmen mit unterschiedlichen und separaten Geschäftseinheiten kann die Entwicklung 

dieser Richtlinie schwierig und zeitaufwändig sein, sie wird jedoch nach der Bereitstellung 

von AD DS nicht einfacher. Wenn sich Geschäftseinheiten vor der Bereitstellung nicht auf eine Richtlinie 

zur Kontrolle von Gesamtstrukturänderungen einigen können, müssen Sie sich möglicherweise 

für den Einsatz mehrerer Gesamtstrukturen entscheiden. 

Auf der DVD Verwenden Sie die Registerkarte Forest Design Decisions in der Excel-Arbeitsmappe 

ADDS_DesignDocument.xlsx auf der CD, um Ihre Entscheidungen zum Gesamtstrukturentwurf zu dokumentieren. 

Entwerfen der Integration mehrerer Gesamtstrukturen 

Unternehmen, die mehrere Gesamtstrukturen benötigen, brauchen möglicherweise dennoch ein 

gewisses Maß an Integration zwischen den Gesamtstrukturen. Im organisatorischen oder im Ressourcengesamtstrukturmodell 

benötigen Benutzer in einer Gesamtstruktur beispielsweise Zugriff auf Ressourcen 

in einer anderen Gesamtstruktur. Unternehmen, die separate Gesamtstrukturen verwenden, 

jedoch dennoch einige der mit Exchange Server verfügbaren Funktionen zur Zusammenarbeit nutzen 

möchten, müssen ebenso einige Integrationsmöglichkeiten zwischen mehreren Gesamtstrukturen entwerfen. 

Für die Integration von Gesamtstrukturen gibt es auf hoher Ebene zwei Optionen. Wenn Unternehmen 

nur den Zugriff auf Ressourcen zwischen den Gesamtstrukturen bereitstellen müssen, können sie 

gesamtstrukturübergreifende Vertrauensstellungen konfigurieren.

Entwerfen der Integration mehrerer Gesamtstrukturen 165 

Wenn Unternehmen eine fortgeschrittenere Integration zwischen den Gesamtstrukturen ermöglichen 

müssen, können sie die Optionen zum Implementieren einer Art von Verzeichnissynchronisierung 

zwischen den Gesamtstrukturen erkunden. 

Hinweis Active Directory-Verbunddienste bieten eine weitere Alternative für die Bereitstellung des Zugriffs 

auf Anwendungen in einer Gesamtstruktur für Benutzer in einer anderen Gesamtstruktur. Weitere Einzelheiten 

hierzu finden Sie in Kapitel 19, „Active Directory-Verbunddienste“. 

Entwerfen gesamtstrukturübergreifender Vertrauensstellungen 

Die einfachste Möglichkeit, den Zugriff auf freigegebene Ressourcen zwischen Gesamtstrukturen zu 

ermöglichen, besteht darin, Vertrauensstellungen zwischen den Gesamtstrukturen oder zwischen 

Domänen in den jeweiligen Gesamtstrukturen zu konfigurieren. Wenn Sie Vertrauensstellungen zwischen 

Gesamtstrukturen konfigurieren, können Sie entweder Gesamtstrukturvertrauensstellungen, 

also transitive Vertrauensstellungen zwischen den Gesamtstruktur-Stammdomänen, oder externe Vertrauensstellungen 

zwischen zwei beliebigen Domänen in beiden Gesamtstrukturen konfigurieren. 

Hinweis Bevor Sie Vertrauensstellungen zwischen AD DS-Gesamtstrukturen konfigurieren, müssen Sie 

sicherstellen, dass Domänencontroller in beiden Gesamtstrukturen die DNS-Adressen für Domänencontroller 

in der anderen Gesamtstruktur auflösen können. Die einfachste Möglichkeit, die Namensauflösung 

zwischen Gesamtstrukturen zu ermöglichen, ist die Konfiguration bedingter Weiterleitungen in jeder Gesamtstruktur. 

Zudem müssen beide Gesamtstrukturen in einer Gesamtstrukturvertrauensstellung zumindest für 

die Funktionsebene Windows Server 2003 (oder höher) konfiguriert sein. 

Entwerfen von Gesamtstrukturvertrauensstellungen 

Beim Erstellen einer Gesamtstrukturvertrauensstellung richten Sie eine Vertrauensstellung zwischen 

den Gesamtstruktur-Stammdomänen der beiden Gesamtstrukturen ein. Für das Entwerfen der Konfiguration 

der Gesamtstrukturvertrauensstellung gelten folgende Anforderungen: 

• Entwerfen der Richtung der Gesamtstrukturvertrauensstellung 

• Entwerfen der ausgewählten Authentifizierung 

• Entwerfen der SID-Filterung 

• Entwerfen des UPN-Suffixrouting 

Entwerfen der Richtung der Gesamtstrukturvertrauensstellung Beim Konfigurieren einer Gesamtstrukturvertrauensstellung 

können Sie die Richtung der Vertrauensstellung auswählen. Wenn Sie 

den Entwurf für die Gesamtstrukturvertrauensstellung erstellen, planen Sie immer die geringste 

Zugriffsebene ein, die den Geschäftsanforderungen entspricht. In einem Szenario mit Ressourcengesamtstruktur 

sollten Sie beispielsweise eine unidirektionale Vertrauensstellung von der Kontengesamtstruktur 

zur Ressourcengesamtstruktur konfigurieren. Ermöglichen Sie bidirektionale Vertrauensstellungen 

nur dann, wenn Benutzer in beiden Gesamtstrukturen auf Ressourcen in der jeweils anderen 

Gesamtstruktur zugreifen müssen. 

Entwerfen der ausgewählten Authentifizierung Die zweite Option, die Sie beim Erstellen einer Gesamtstrukturvertrauensstellung 

konfigurieren können, ist die ausgewählte Authentifizierung. Durch Aktivieren 

der ausgewählten Authentifizierung besitzen Sie mehr Kontrolle darüber, welche Benutzergruppen 

in einer vertrauten Gesamtstruktur auf welche freigegebene Ressourcen in einer vertrauenden 

Gesamtstruktur zugreifen können.


Ist die gesamtstrukturweite Authentifizierung aktiviert, erhalten Benutzer, die über eine gesamtstrukturübergreifende 

Vertrauensstellung authentifiziert sind, automatisch die SID authentifizierter Benutzer 

der vertrauenden Gesamtstruktur. Die SID authentifizierter Benutzer gewährt Benutzern in einer 

Gesamtstruktur viele Standardrechte. Nachdem Sie eine gesamtstrukturübergreifende Vertrauensstellung 

eingerichtet haben, erhalten daher Benutzer aus der vertrauten Gesamtstruktur einige Standardrechte 

für alle Ressourcen in der vertrauenden Gesamtstruktur, die für die Gruppe Authentifizierte 

Benutzer zugänglich sind. 

So funktioniert es: Ausgewählte Authentifizierung in Windows-Vertrauensstellungen 

Die ausgewählte Authentifizierung begrenzt die Möglichkeit von Benutzern in vertrauten Gesamtstrukturen, 

auf Ressourcen in der vertrauenden Gesamtstruktur zuzugreifen. Im Wesentlichen müssen 

die Benutzer eine zusätzliche, detailliertere Sicherheitsprüfung bestehen. Diese Funktion steht 

nur in Gesamtstrukturen zur Verfügung, die für die Funktionsebene Windows 2003 oder höher konfiguriert 

sind. 

Ohne die ausgewählte Authentifizierung sind Benutzer in einer vertrauten Gesamtstruktur praktisch 

wie Mitglieder der vertrauenden Gesamtstruktur, weil sie der Gruppe Authentifizierte Benutzer 

in dieser Gesamtstruktur hinzugefügt werden. Hierdurch erhalten sie Zugriff auf alle Ressourcen 

in der vertrauenden Gesamtstruktur, sofern die Zugriffssteuerungsliste (Access Control List, 

ACL) so konfiguriert ist, dass der Gruppe Authentifizierte Benutzer der Zugriff gewährt wird. 

Die ausgewählte Authentifizierung wird für den ausgehenden Teil einer gesamtstrukturübergreifenden 

Vertrauensstellung konfiguriert. Wenn Benutzer in der vertrauten Gesamtstruktur anschließend 

auf eine Ressource in der vertrauenden Gesamtstruktur zuzugreifen versuchen, erhalten Sie die 

Meldung „Anmeldefehler: Der Computer, an dem Sie sich anmelden, ist durch eine Authentifizierungsfirewall 

geschützt. Das angegebene Konto darf sich nicht an diesem Computer anmelden.“ 

Um Benutzern oder Gruppen in der vertrauten Gesamtstruktur den Zugriff auf die entsprechenden 

Ressourcen zu gewähren, müssen Sie dem Benutzer die Berechtigung Authentifizierung zulassen 

auf dem Computer erteilen, auf den er zugreifen muss. Wenn der Benutzer anschließend auf die 

Ressource zugreift, enthält das Zugriffstoken ein Sicherheitsprinzipal namens Andere Organisation, 

und der Zugriff wird ihm gewährt. 

Darol Timberlake 

Senior Premier Field Engineer, Microsoft 

Sicherheitswarnung Wenn Sie die gesamtstrukturweite Authentifizierung für eine Gesamtstrukturvertrauensstellung 

aktivieren, sollten Sie unbedingt sicherstellen, dass die Gruppe Authentifizierte Benutzer aus allen 

vertraulichen Ressourcen in der vertrauten Domäne entfernt wird. 

Wenn Sie die ausgewählte Authentifizierung aktivieren, können Sie einschränken, welche Benutzergruppen 

über die Vertrauensstellung auf Ressourcen zugreifen können. Ferner können Sie einschränken, 

welche Computer in der vertrauenden Domäne über diese Vertrauensstellung zugänglich sind. 

Zum Implementieren der ausgewählten Authentifizierung müssen Sie die Gesamtstrukturvertrauensstellung 

so konfigurieren, dass die ausgewählte Authentifizierung anstelle der gesamtstrukturweiten 

Authentifizierung verwendet wird. Diese Option kann beim Erstellen der Vertrauensstellung oder 

danach aktiviert werden. Nach der Konfiguration der Vertrauensstellung müssen Sie auf die Computerkontoeigenschaften 

in AD DS zugreifen und den Gruppen oder Benutzern aus der vertrauten 

Domäne die Berechtigung Authentifizierung zulassen für das Computerobjekt erteilen.

Entwerfen der Integration mehrerer Gesamtstrukturen 167 

Hinweis Um die ausgewählte Authentifizierung für Gesamtstrukturvertrauensstellungen zu aktivieren, 

muss die Gesamtstrukturfunktionsebene der vertrauenden Gesamtstruktur, in der sich freigegebene Ressourcen 

befinden, auf Windows Server 2003 oder höher eingestellt sein. Zum Aktivieren der ausgewählten 

Authentifizierung für externe Vertrauensstellungen muss die Domänenfunktionsebene der vertrauenden 

Domäne, in der sich freigegebene Ressourcen befinden, auf Windows Server 2000 einheitlich oder höher 

eingestellt sein. 

Diese Art der Authentifizierungssteuerung bietet freigegebenen Ressourcen einen zusätzlichen 

Schutz, da sie nicht jedem authentifizierten Benutzer aus einem anderen Unternehmen frei zugänglich 

sind. Wenn Sie die ausgewählte Authentifizierung aktivieren, werden alle über eine Vertrauensstellung 

an die vertrauende Gesamtstruktur gestellten Authentifizierungsanforderungen von Domänencontrollern 

in der vertrauenden Gesamtstruktur verifiziert. Wenn dem Benutzerkonto auf dem 

Server, auf den der Benutzer zuzugreifen versucht, nicht die Berechtigung Authentifizierung zulassen 

zugewiesen ist, stellt der Domänencontroller nicht das Dienstticket aus, das für den Zugriff auf die 

Gesamtstruktur erforderlich ist. 

Zur Sicherheit empfiehlt es sich, die ausgewählte Authentifizierung für alle Gesamtstruktur- und 

externen Vertrauensstellungen zu aktivieren. Wenn jedoch viele Benutzer in beiden Gesamtstrukturen 

Zugriff auf viele Ressourcen in der jeweils anderen Gesamtstruktur benötigen, kann die Verwaltung 

der ausgewählten Authentifizierung zu umständlich werden. 

Entwerfen der SID-Filterung Die SID-Filterung wird verwendet, um Benutzer an der Verwendung der 

im Attribut SIDHistory gespeicherten SIDs zu hindern, wenn sie auf Ressourcen in einer separaten 

Gesamtstruktur zugreifen. Das Attribut SIDHistory wird normalerweise bei der Migration von Benutzer- 

und Gruppenkonten von einer Domäne auf eine andere verwendet. Während der Migration können 

die dem Benutzer oder der Gruppe in der Quelldomäne zugewiesenen SIDs auf das Benutzeroder 

Gruppenkonto in der Zieldomäne migriert und im Attribut SIDHistory gespeichert werden. 

Durch die Beibehaltung der SIDs kann das Benutzerkonto während der Migration von Ressourcen auf 

die neue Domäne auf Ressourcen in der Quelldomäne zugreifen. Ist die SID-Filterung nicht aktiviert, 

können die SIDs im Attribut SIDHistory für den Zugriff auf Ressourcen in jeder beliebigen vertrauten 

Gesamtstruktur verwendet werden. 

Weitere Informationen Weitere Einzelheiten zur Benutzer- und Gruppenmigration und zur Verwendung von 

SIDHistory finden Sie in Kapitel 7, „Migrieren auf die Active Directory-Domänendienste“. 

Die Deaktivierung der SID-Filterung stellt ein Sicherheitsrisiko dar, weil das Attribut SIDHistory zum 

Ausnutzen der ungeschützten Vertrauensstellung eingesetzt werden kann. Ein böswilliger Benutzer 

mit Administratoranmeldeinformationen kann Administrator-SIDs von Administratorkonten in der 

vertrauenden Gesamtstruktur dem Attribut SIDHistory eines Sicherheitsprinzipals in der vertrauten 

Gesamtstruktur hinzufügen. Das Konto kann anschließend verwendet werden, um Administratorzugriff 

auf die vertraute Gesamtstruktur zu erhalten. 

Mithilfe der SID-Filterung können Sie die Verwendung des Attributs SIDHistory in der gesamten 

Gesamtstrukturvertrauensstellung blockieren. Ist die SID-Filtering aktiviert, vergleichen die Domänencontroller 

in der vertrauten Domäne die SID des anfordernden Sicherheitsprinzipals mit der 

Domänen-SID der vertrauten Domäne. Alle SIDs aus anderen Domänen als der vertrauten Domäne 

werden entfernt bzw. gefiltert. Das heißt, auch wenn das Attribut SIDHistory die SIDs von höchst vertrauten 

Administratorkonten in der vertrautenden Domäne enthält, werden die SIDs dennoch nicht 

über die Vertrauensstellung akzeptiert.


Die SID-Filterung ist standardmäßig für alle Vertrauensstellungen auf Windows Server 2008-Computern 

aktiviert und sollte nur nach sorgfältiger Abwägung deaktiviert werden. Wenn Sie Benutzer- und 

Gruppenkonten aus einer Gesamtstruktur auf eine andere migrieren, könnten Sie die SID-Filterung 

nur für die Zeit des Migrationsvorgangs deaktivieren. Nach Abschluss der Migration sollten Sie die 

SID-Filterung wieder aktivieren. 

Entwerfen des UPN-Suffixrouting Ein UPN (User Principal Name) ist ein Anmeldename, der das 

Präfix und das Suffix des Benutzerprinzipalnamens enthält. Standardmäßig ist das UPN-Präfix der 

Anmeldename des Benutzers und das Suffix der Name der Domäne, in der das Benutzerkonto erstellt 

wurde. Sie können die anderen Domänen im Netzwerk oder zusätzlich erstellte Suffixe verwenden, 

um weitere Suffixe für Benutzer zu konfigurieren. Beispielsweise könnten Sie ein Suffix konfigurieren, 

um Benutzeranmeldenamen zu erstellen, die den E-Mail-Adressen der Benutzer entsprechen. 

UPNs können in einer Umgebung mit mehreren Domänen oder mehreren Gesamtstrukturen verwendet 

werden, um die Benutzeranmeldung zu vereinfachen. Wenn Benutzer beispielsweise häufig zwischen 

Unternehmensstandorten reisen und sich an Computern in mehreren verschiedenen Domänen 

anmelden, können sie hierfür einfach ihren UPN verwenden. Der UPN muss in der Gesamtstruktur 

eindeutig sein, damit der Benutzer sich jederzeit anmelden kann – unabhängig von der Domäne, in 

der er sich befindet. Wenn der UPN mit der E-Mail-Adresse des Benutzers übereinstimmt, muss sich 

der Benutzer nur einen einzigen Benutzernamen merken, um sowohl auf das Netzwerk als auch auf 

seine E-Mails zuzugreifen. 

Beim Entwurf von Gesamtstrukturvertrauensstellungen müssen Sie berücksichtigen, wie das 

Namensuffixrouting zwischen Gesamtstrukturen funktioniert. Das Namensuffixrouting ist ein Mechanismus, 

der die Namensauflösung in den Gesamtstrukturen basierend auf den folgenden Kriterien 

ermöglicht: 

• Wenn sich zwei Windows Server 2008-Gesamtstrukturen über eine Gesamtstrukturvertrauensstellung 

verbinden, wird das Namensuffixrouting automatisch aktiviert. Wenn beispielsweise 

eine Vertrauensstellung zwischen der Gesamtstruktur Adatum.com und der Gesamtstruktur 

Contoso.com konfiguriert wird, kann sich ein Benutzer mit einem Konto in der Gesamtstruktur 

Adatum.com anhand seines UPN an einem Computer in der Gesamtstruktur Contoso.com anmelden. 

Die Authentifizierungsanforderung wird automatisch an den entsprechenden Domänencontroller 

in der Gesamtstruktur Adatum.com geleitet. 

• Wenn beide Gesamtstrukturen dasselbe UPN-Suffix besitzen, können Benutzer nicht den UPN- 

Namen mit diesem Suffix für die Anmeldung an einem Computer in einer anderen Gesamtstruktur 

verwenden. Wenn beispielsweise sowohl das Unternehmen Adatum.com als auch das Unternehmen 

Contoso.com das UPN-Suffix TreyResearch.com verwenden würden, könnten Benutzer 

sich nicht mithilfe dieses Suffixes an der jeweils anderen Gesamtstruktur anmelden. 

Fehler beim UPN-Namensuffixrouting werden festgestellt, wenn Sie Gesamtstrukturvertrauensstellungen 

konfigurieren. Wenn die Gesamtstrukturen dasselbe UPN-Suffix verwenden, erkennt der 

Assistent für neue Vertrauensstellungen den Konflikt zwischen den beiden UPN-Suffixen und zeigt 

diesen an, wenn Sie die Vertrauensstellung einzurichten versuchen. Wenn Sie einer Domäne mit einer 

vorhandenen Gesamtstrukturvertrauensstellung ein UPN-Suffix hinzufügen, das einen Konflikt verursacht, 

wird dem UPN-Suffix die Authentifizierung in der vertrauenden Domäne nicht gestattet.

Entwerfen der Domänenstruktur 169 

Entwerfen der Verzeichnisintegration zwischen Gesamtstrukturen 

In manchen Unternehmen bietet die reine Erstellung von Vertrauensstellungen zwischen Gesamtstrukturen 

nicht die erforderliche Funktionalität. In diesen Unternehmen ist es vielleicht nicht erforderlich, 

den Ressourcenzugriff zwischen verschiedenen Gesamtstrukturen zu ermöglichen. Stattdessen müssen 

möglicherweise die Verzeichnisdaten zwischen den Gesamtstrukturen synchronisiert werden. In 

vielen Unternehmen, die mehrere Gesamtstrukturen und mehrere Exchange Server-Organisationen 

einsetzen, müssen Benutzer in den separaten Organisationen dazu in der Lage sein, sich gegenseitig 

E-Mails zu senden. Hierzu müssen die Benutzerkonten in beiden Gesamtstrukturen mit der jeweils 

anderen Gesamtstruktur synchronisiert werden, um als Nachrichtenempfänger innerhalb der Messagingclients 

zur Verfügung zu stehen. 

Weitere Informationen Zusätzlich zur Verzeichnissynchronisierung müssen viele andere Aspekte, wie die 

Kalenderverfügbarkeit, die Replikation öffentlicher Ordner und das Nachrichtenrouting, beim Entwerfen von 

Exchange Server-Bereitstellungen in komplexen Unternehmen berücksichtigt werden. Weitere Informationen 

hierzu finden Sie unter „Planung für eine komplexe Exchange-Organisation“ unter http://technet.microsoft.com/de-de/library/aa996010.aspx. 

Die einfachste Möglichkeit, die Verzeichnissynchronisierung zwischen mehreren Gesamtstrukturen zu 

ermöglichen, besteht darin, ein Tool wie Microsoft Identity Lifecycle Manager (ILM) 2007 zu verwenden. 

Eine der ILM-Komponenten ist Microsoft Identity Integration Server 2003 (MIIS). Mithilfe 

von MIIS oder mithilfe des Identity Integration Feature Pack für Microsoft Windows Server Active 

Directory (IIFP) können Sie den Vorgang zur Synchronisierung von Verzeichnisinformationen zwischen 

mehreren Gesamtstrukturen automatisieren. Bei MIIS handelt es sich um eine mit leistungsstarke 

Lösung zur Identitätsverwaltung, die zum Synchronisieren vieler verschiedener Verzeichnistypen 

verwendet werden kann. IIFP ist hingegen eine eingeschränktere Version von MIIS, die zum 

Synchronisieren von Identitätsinformationen zwischen Microsoft-Verzeichnissen einsetzbar ist. 

Wenn Sie die Verzeichnissynchronisierung über MIIS oder IIFP konfigurieren, werden Benutzerkonten 

und E-Mail-fähige Gruppen in einer Quellgesamtstruktur in der Regel als E-Mail-fähige Kontakte 

in der Zielgesamtstruktur dargestellt. Das heißt, dass die Empfänger in der globalen Adressliste angezeigt 

werden. 

Weitere Informationen Der Entwurf der Integration mehrerer Gesamtstrukturen ist kompliziert und hängt 

von dem Integrationsgrad ab, der zwischen den Gesamtstrukturen erforderlich ist. Eine detaillierte Erörterung 

der verfügbaren Integrationsoptionen und eine Anleitung zum Implementieren der Optionen finden Sie im englischsprachigen 

Whitepaper „Windows 2000/2003: Multiple Forests Considerations“ unter http://www.microsoft.com/downloads/details.aspx?familyid=b717bfcd-6c1c-4af6-8b2c-b604e60067ba&displaylang=en. 

Entwerfen der Domänenstruktur 

Nachdem die Frage, wie viele Gesamtstrukturen verwendet werden sollen, geklärt ist, besteht der 

nächste Schritt darin, die Domänenstruktur innerhalb der Gesamtstrukturen zu definieren. Anhand 

von Domänen wird eine große Gesamtstruktur, hauptsächlich zu Verwaltungs- oder Replikationszwecken, 

in kleinere Komponenten unterteilt. Die folgenden Domäneneigenschaften sind für den AD DS- 

Entwurf relevant: 

• Replikationsgrenzen Domänengrenzen sind Replikationsgrenzen für die Domänenverzeichnispartition 

und für die Domäneninformationen im Ordner SYSVOL auf sämtlichen Domänencontrollern.


Während andere Verzeichnispartitionen wie Schema, Konfiguration und globaler Katalog innerhalb 

der Gesamtstruktur repliziert werden, wird die Domänenverzeichnispartition nur innerhalb 

einer Domäne repliziert. 

• Grenze für den Ressourcenzugriff Domänengrenzen sind auch Grenzen für den Ressourcenzugriff. 

Standardmäßig können Benutzer einer Domäne nicht auf die Ressourcen in einer anderen Domäne 

zugreifen, sofern keine Vertrauensstellung eingerichtet ist und ihnen nicht explizit die erforderlichen 

Berechtigungen zugewiesen wurden. 

• Grenzen für Sicherheitsrichtlinien Einige Sicherheitsrichtlinien gelten für alle Benutzerkonten in 

der Domäne, wenn sie auf Domänenebene angewendet werden. Zu diesen Richtlinien gehören 

Kennwortrichtlinien, Kontosperrungsrichtlinien und Kerberos-Ticketrichtlinien. 

In Abbildung 5.7 wird der Prozess zum Erstellen eines Domänenentwurfs dargestellt. 

Prüfen von 

Auswirkungen 

der Auswahl einer 

oder mehrerer Domänen 

Festlegen, ob mehrere 

Domänen erforderlich sind 

Mehrere Domänen 

erforderlich 

Eine Domäne 

erforderlich 

Festlegen der 

Domänenanzahl 

Festlegen der Stammdomäne 

der Gesamtstruktur 

Festlegen des 

Domänenentwurfsmodells 

Für jede Domäne 

Festlegen des Entwurfs 

der Domänenvertrauensstellungen 

Festlegen des 

Domänenbesitzers 

Abbildung 5.7 

Erstellen eines Domänenentwurfs 

Wichtig Wie im vorherigen Abschnitt zum Entwerfen einer Gesamtstruktur bereits erläutert wurde, stellen 

Domänengrenzen keine Sicherheitsgrenzen dar.


Festlegen der Domänenanzahl 

Auch wenn die meisten Unternehmen eine einzige Gesamtstruktur verwenden, richten die meisten großen 

Unternehmen mehrere Domänen innerhalb dieser Gesamtstruktur ein. Im Idealfall ist eine einzige 

Domäne am einfachsten zu verwalten und bietet den Benutzern die unkomplizierteste Umgebung. Es 

gibt jedoch auch mehrere Gründe, warum Unternehmen sich für den Einsatz mehrerer Domänen entscheiden. 

Verwenden einer einzigen Domäne 

Die meisten kleinen bis mittelgroßen Unternehmen sollten die Implementierung einer einzigen Domäne 

aus folgenden Gründen in Betracht ziehen: 

• Der AD DS-Datenspeicher kann leicht über eine Million Objekte enthalten. Das bedeutet, dass die 

Gesamtzahl an Objekten in AD DS selten ein Grund für die Erstellung mehrerer Domänen ist. 

• Wenn ein Unternehmen administrative Autonomie zwischen verschiedenen Geschäftseinheiten 

benötigt, können Sie Organisationseinheiten verwenden und administrative Aufgaben auf OU- 

Ebene delegieren. Wenn das Unternehmen administrative Isolation erfordert, müssen Sie mehrere 

Gesamtstrukturen verwenden, da Domänen keine Grenze für administrative Sicherheit darstellen. 

• Wenn Ihr Unternehmen häufig umstrukturiert wird oder wenn Benutzer zwischen den Geschäftseinheiten 

wechseln, können Benutzer recht einfach zwischen OUs in einer Domäne verschoben 

werden. Es ist viel schwieriger, Benutzer zwischen Domänen zu verschieben. 

• Einzelne Domänen sind insofern einfacher zu verwalten, als Sie sich nur um eine einzige Gruppe 

von Administratoren auf Domänenebene und um einen einzigen Satz an Richtlinien auf Domänenebene 

kümmern müssen. Außerdem müssen Sie nur eine Gruppe von Domänencontrollern 

verwalten. 

• Das einfachste Szenario für die Verwaltung von Gruppenrichtlinien ist das einer Umgebung mit 

einer einzigen Domäne. Einige Gruppenrichtlinienobjekte sind im Ordner SYSVOL auf jedem 

Domänencontroller in einer Domäne gespeichert. Wenn Sie nur eine Domäne verwenden, werden 

die Gruppenrichtlinienobjekte automatisch auf alle Domänencontroller repliziert. 

• Eine einzige Domäne bietet die einfachste Umgebung für den Entwurf der Authentifzierung und 

des Ressourcenzugriffs. Mit einer einzigen Domäne müssen Sie sich nicht um Vertrauensstellungen 

oder das Erteilen des Ressourcenzugriffs an Benutzer in anderen Domänen kümmern. Innerhalb 

einer einzigen Domäne ist es außerdem zweckmäßig, nur eine einzige Gruppe für das 

Zuweisen des Ressourcenzugriffs zu verwenden, statt sowohl Konto- als auch Ressourcengruppen 

zu konfigurieren. 

• In einer einzigen Domäne können alle Domänencontroller als globale Katalogserver verwendet 

werden, weil die Einschränkungen des Infrastrukturmasters nicht gelten. Das heißt, dass Sie die 

Platzierung des globalen Katalogs nicht planen müssen. 

Verwenden mehrerer Domänen 

Auch wenn eine einzige Domäne für einige Unternehmen die ideale Konfiguration darstellt, setzen 

die meisten großen Unternehmen mehrere Domänen ein. Separate Domänen sind in folgenden Fällen 

ratsam: 

• Der Replikationsdatenverkehr muss eingeschränkt werden. Die Domänenverzeichnispartition, die 

größte und am meisten geänderte Verzeichnispartition, wird auf alle Domänencontroller in einer 

Domäne repliziert.


Außerdem wird der Ordner SYSVOL auf alle Domänencontroller in derselben Domäne repliziert. 

In einigen Fällen führt dies zu übermäßigem Replikationsdatenverkehr zwischen den physischen 

Unternehmensstandorten (selbst wenn mehrere logische Standorte konfiguriert werden). Dies 

kann der Fall sein, wenn zwischen den Unternehmensstandorten langsame Netzwerkverbindungen 

bestehen oder wenn sich in mehreren Unternehmensstandorten eine große Anzahl von 

Benutzern befindet. Die einzige Möglichkeit, den Replikationsdatenverkehr einzuschränken, 

besteht in der Erstellung zusätzlicher Domänen. 

• Einige Standorte verwenden SMTP-Konnektivität (Simple Mail Transfer Protocol). Alle Unternehmensstandorte, 

die nur SMTP-Konnektivität besitzen, müssen als separate Domänen konfiguriert 

werden. Die Domänenpartition kann nicht über Standortverknüpfungen repliziert werden, die 

SMTP verwenden. 

• Es sind verschiedene Kennwortrichtlinien erforderlich. Die einzige Möglichkeit zum Einsetzen 

verschiedener Kennwortrichtlinien, Kontosperrungsrichtlinien und Kerberos-Ticketrichtlinien 

besteht darin, separate Domänen einzurichten. Auch wenn Sie sehr detaillierte Kennwortrichtlinien 

einsetzen können, um die Kennwortrichtlinien für einige Benutzer in einer einzigen Domäne 

zu ändern, erfordert die Verwaltung verschiedener Kennwortrichtlinien für mehrere Personengruppen 

in derselben Domäne einen zusätzlichen Verwaltungsaufwand. 

• Der Zugriff muss eingeschränkt werden. Wenn Sie den Zugriff auf Ressourcen und administrative 

Berechtigungen einschränken müssen, empfiehlt sich der Einsatz zusätzlicher Domänen. Für 

einige Unternehmen gibt es möglicherweise rechtliche Gründe für die Erstellung separater Verwaltungseinheiten. 

• Für verschiedene Geschäftseinheiten sind verschiedene Namespaces erforderlich. Wenn Unternehmen 

zusammengelegt werden, kann es für alle Geschäftseinheiten wichtig sein, eine eigenständige 

Identität zu bewahren. Durch den Einsatz mehrerer Domänen in verschiedenen Strukturen 

können Sie für jede Domäne einen eigenständigen Namespace verwalten. 

• Der beste Migrationspfad für das Unternehmen ist, mehrere der aktuellen Domänen zu aktualisieren. 

Es gibt viele gute Gründe für die Erstellung zusätzlicher Domänen. Jede Domäne kann einem Unternehmen 

jedoch erhebliche administrative und finanzielle Kosten verursachen. Bevor Sie sich zur 

Erstellung weiterer Domänen entschließen, erwägen Sie folgende Aspekte: 

• Jede zusätzliche Domäne erfordert zusätzliche Hardware und zusätzliche Administratoren. Wenn 

Sie konsistente Verwaltungsprozesse und Überwachungsvorgänge für alle Domänen konfigurieren 

möchten, müssen Sie die entsprechenden Einstellungen in jeder Domäne festlegen. 

• Die Verwaltung konsistenter Gruppenrichtlinieneinstellungen in allen Domänen ist schwierig. Sie 

müssen die GPOs in jeder einzelnen Domäne konfigurieren und Dateien wie Skripts und Vorlagen 

auf Domänencontroller in den einzelnen Domänen kopieren. 

• In einer Umgebung mit mehreren Domänen greifen Benutzer über Vertrauensstellungen auf Ressourcen 

zu, was zu mehr Komplexität und möglicherweise zu zusätzlichen Fehlerquellen führt. 

• Benutzer, die zwischen Standorten mit verschiedenen Domänen wechseln, müssen sich an einem 

Domänencontroller in ihrer Basisdomäne authentifizieren. Steht keine Netzwerkverbindung mit 

der Basisdomäne zur Verfügung, kann der Benutzer sich nicht an der Domäne authentifizieren. 

Aufgrund dieser zusätzlichen Kosten sollte die Gesamtzahl der Domänen so niedrig wie möglich 

gehalten werden.

Entwerfen der Gesamtstruktur-Stammdomäne 


Eine weitere wichtige Entscheidung, die Sie beim Entwerfen einer AD DS-Lösung mit mehreren 

Domänen treffen müssen, ist, ob eine dedizierte Stammdomäne (auch als leere Stammdomäne 

bezeichnet) eingerichtet werden sollte. Eine dedizierte Stammdomäne ist eine Domäne, die ausschließlich 

die Rolle als Gesamtstruktur-Stammdomäne ausübt. Das heißt, diese Domäne enthält nur 

diejenigen Benutzerkonten oder Ressourcen, die zum Verwalten der Gesamtstruktur erforderlich sind. 

Eine Gesamtstruktur mit einer dedizierten Stammdomäne wird in Abbildung 5.8 dargestellt. 

Eine dedizierte Stammdomäne, 

die ausschließlich 

Standardobjekte enthält: 

Gesamtstruktur-Betriebsmaster 

und Administratorengruppen 

der Gesamtstruktur 

Adatum.com 


Unternehmensdomänen, 

die alle Administratorengruppen 

und weitere Domänenobjekte 

enthalten 

NA.Adatum.com 


Abbildung 5.8 

Eine Gesamtstruktur mit dedizierter Stammdomäne 

Für die meisten Unternehmen mit mehreren Domänen wird eine dedizierte Stammdomäne dringend 

empfohlen. Die Stammdomäne ist eine wichtige Domäne in der AD DS-Struktur. Der Einsatz einer 

dedizierten Stammdomäne bietet folgende Vorteile: 

• Die Stammdomäne enthält die administrativen Gruppen auf Gesamtstrukturebene (die Gruppen 

Organisations-Admins und Schema-Admins) sowie die Betriebsmasterdomänencontroller auf 

Gesamtstrukturebene (den Domänennamenmaster und den Schemamaster). Die Verwendung einer 

dedizierten Stammdomäne vereinfacht außerdem die Einschränkung der Mitgliedschaft der administrativen 

Gruppen auf Gesamtstrukturebene. Selbst wenn Sie die Anzahl der Administratoren in 

den Gruppen Schema-Admins und Organisations-Admins rigoros einschränken, kann jedes Mitglied 

der Gruppe Domänen-Admins in der Gesamtstruktur-Stammdomäne die Mitgliederliste für 

diese Gruppen ändern. 

• Eine dedizierte Stammdomäne kann leicht auf andere Standorte repliziert werden. Die Gesamtstruktur-Stammdomäne 

muss immer verfügbar sein, wenn Benutzer sich an anderen Domänen als 

ihrer Basisdomäne anmelden oder wenn Benutzer auf Ressourcen in anderen Domänen zugreifen. 

Weil Sie nur selten Änderungen am Datenspeicher der dedizierten Gesamtstrukturdomäne vornehmen 

müssen, gibt es kaum Replikationsdatenverkehr zwischen den Stammdomänencontrollern. 

Sie können daher Domänencontroller an mehreren Unternehmensstandorten aufstellen, um 

Redundanz zu gewährleisten.


Daher ist es außerdem leicht, die Stammdomäne im Fall einer Notfallwiederherstellung an einen 

anderen physischen Standort zu verschieben. 

• Eine dedizierte Stammdomäne ist einfacher zu verwalten als eine Stammdomäne, die viele 

Objekte enthält. Da die Verzeichnisdatenbank klein ist, können die Stammdomänencontroller 

leicht gesichert und wiederhergestellt werden. Die Stammdomäne kann nicht ersetzt werden; 

wenn die Stammdomäne zerstört ist und nicht wiederhergestellt werden kann, müssen Sie die 

ganze Gesamtstruktur neu aufbauen. 

• Eine dedizierte Stammdomäne veraltet außerdem nie, vor allem dann nicht, wenn die Domäne 

einen generischen Namen erhält. 

Aus diesen Gründen sollten die meisten Unternehmen, die sich für die Verwendung mehrerer Domänen 

entschließen, ernsthaft die Verwendung einer dedizierten Stammdomäne in Betracht ziehen. 

Selbst einige Unternehmen, die nur eine Domäne einzusetzen planen, sollten die Vorteile einer 

dedizierten Stammdomäne abwägen. 

Die dedizierte Stammdomäne erfordert eine bestimmte Konfiguration, die für die anderen Domänen in 

der Gesamtstruktur nicht relevant ist. Zunächst einmal müssen die Domänencontroller der Stammdomäne 

so gut wie möglich abgesichert werden, weil die Stammdomäne die Gesamtstrukturbetriebsmaster 

enthält. Die Gesamtstrukturdomäne umfasst außerdem die Gruppen, die die Gesamtstruktur und das 

Schema verändern können. Noch mehr als in allen anderen Domänen müssen die Mitglieder der 

Administratorengruppen in der Stammdomäne extrem vertrauenswürdig sein. Sie werden wahrscheinlich 

die Option Eingeschränkte Gruppen in der Domänensicherheitsrichtlinie verwenden, um die Mitgliedschaft 

in diesen Gruppen zu verwalten. Die DNS-Konfiguration der Stammdomäne sollte ebenfalls 

so sicher wie möglich sein. Da zusätzliche Computer wahrscheinlich nicht in der Stammdomäne 

installiert werden, sollten Sie während der Installation der Domänencontroller sichere dynamische 

Aktualisierungen für die DNS-Zone der Stammdomäne aktivieren und anschließend dynamische 

Aktualisierungen für diese Zone deaktivieren. 

Entwerfen von Domänenhierarchien 

Nachdem der Stammdomänenentwurf abgeschlossen ist, müssen Sie im nächsten Schritt festlegen, 

wie viele zusätzliche Domänen Sie einrichten müssen und wie die übrigen Domänen in den DNS- 

Namespace für die Gesamtstruktur passen. 

Es gibt grundsätzlich drei Modelle zum Erstellen zusätzlicher Domänen in einer AD DS-Gesamtstruktur: 

• Erstellen von Domänen basierend auf der geografischen Lage, also regionale Domänen Regionale 

Domänen werden hauptsächlich zum Verringern des Replikationsdatenverkehrs über langsame 

oder teure WAN-Verknüpfungen verwendet. Regionale Domänen sind die bevorzugte Option für 

Unternehmen mit einer großen Anzahl an Benutzern, die geografisch verstreut sind. Beispielsweise 

Unternehmen mit Niederlassungen auf mehreren Kontinenten können sich zur Implementierung 

regionaler Domänen entschließen, um den Replikationsdatenverkehr zwischen Kontinenten 

einzuschränken. Regionale Domänen sind auch die bevorzugte Option, wenn die geografisch verteilten 

Bereiche des Unternehmens sich fest etabliert haben und wahrscheinlich nicht geändert 

werden. Die Domänenkonfiguration ist nach der Bereitstellung schwierig zu ändern.


Wichtig Die verfügbare Bandbreite zwischen Unternehmensstandorten ist möglicherweise das wichtigste 

Kriterium für die Erstellung zusätzlicher Domänen in Unternehmen mit mehr als 10.000 Benutzern 

und mit sehr begrenzter Bandbreite in WAN-Verknüpfungen zwischen Unternehmensstandorten. Da in 

einer einzelnen Domäne alle Änderungen in AD DS auf alle Domänencontroller repliziert werden, kann 

der AD DS-Replikationsdatenverkehr die gesamte verfügbare Bandbreite beanspruchen. Durch Erstellen 

separater Domänen auf beiden Seiten einer langsamen WAN-Verknüpfung können Sie die für die Replikation 

genutzte Netzwerkbandbreite erheblich reduzieren. Eine detaillierte Analyse der für die Replikation 

erforderliche Bandbreite finden Sie unter „Determining Your Active Directory Design and Deployment 

Strategy“ unter http://technet2.microsoft.com/windowsserver/en/library/ff92f142-66ea-498b-ad0fa379c411eb6e1033.mspx?mfr=true. 

Dieser Leitfaden basiert auf dem Einsatz von Windows Server 2003- 

Gesamtstrukturen. Viele der Grundsätze gelten auch für Windows Server 2008. Sie sollten außerdem im 

TechCenter für Windows Server 2008 nach einer aktualisierten Version dieses Leitfadens suchen. 

• Erstellen von Domänen basierend auf Geschäftseinheiten Einige Unternehmen erstellen zusätzliche 

Domänen basierend auf Geschäftseinheiten. Dieser Entwurf ist die bevorzugte Option, wenn die 

Geschäftseinheiten relativ eigenständig arbeiten oder wenn eine Geschäftsanforderung vorliegt, 

dass für jede Geschäftseinheit ein separater Namespace verwaltet werden soll. Die Erstellung von 

Domänen für Geschäftseinheiten ist relativ üblich in Unternehmen, die mehrere Fusionen und 

Übernahmen erlebt haben. 

• Erstellen von Konto- und Ressourcendomänen Einige Unternehmen erstellen zusätzliche Domänen, 

um Konto- und Ressourcendomänen zu trennen. Dies ermöglicht Domänenadministratoren in 

der Ressourcendomäne, sämtliche Aspekte der Ressourcenverwaltung vollständig zu kontrollieren, 

ohne auf die Kontenverwaltung zuzugreifen. Die Trennung von Kontodomänen und Ressourcendomänen 

war üblich in Unternehmen, die Windows NT 4.0 eingesetzt haben, und einige dieser 

Unternehmen haben gerade die Windows NT-Domänen auf Active Directory migriert. Weil Sie in 

AD DS den Administratorzugriff auf OU-Ebene delegieren können und weil AD DS Millionen 

von Objekten enthalten können, ist es unter Windows Server 2008 AD DS wesentlich unwahrscheinlicher, 

dass Konto- und Ressourcendomänen eingesetzt werden müssen. 

Domänenstrukturen und -vertrauensstellungen 

Wenn Sie der Gesamtstruktur weitere Domänen hinzufügen, kann dies entweder in einer Konfiguration 

mit einer einzigen Struktur oder in einer Konfiguration mit mehreren Strukturen geschehen. 

Wenn Sie alle Domänen in einer einzigen Struktur hinzufügen, besitzen alle Domänen einen zusammenhängenden 

Namespace. (Sie fallen also unter den Namespace der Stammdomäne.) Dies ist häufig 

der beste Entwurf für ein zentrales Unternehmen, in dem alle Geschäftseinheiten unter einem Namen 

bekannt sind. Wenn das Unternehmen jedoch verschiedene Geschäftseinheiten mit unterschiedlichen 

Identitäten besitzt, gibt es wahrscheinlich erheblichen Widerstand gegen die Verwendung des Namespaces 

einer anderen Geschäftseinheit. In diesem Fall fügen Sie Domänen in verschiedenen Strukturen 

hinzu und erstellen auf diese Weise mehrere Namespaces. 

Standardkonfiguration von Vertrauensstellungen 

Aus funktioneller Sicht gibt es fast keinen Unterschied zwischen einer einzigen und mehreren Strukturen. 

In beiden Fällen nutzen alle Domänen eine transitive Vertrauensstellung mit allen übrigen 

Domänen und teilen sich außerdem den globalen Katalog und den Container Konfiguration. Der Faktor, 

der mehrere Strukturen komplizierter werden lässt, ist der Entwurf des DNS-Namespaces und die 

Konfiguration der DNS-Server.


Die Standardkonfiguration von Vertrauensstellungen zwischen Domänen in einer AD DS-Gesamtstruktur 

ist entweder eine Vertrauensstellung zwischen übergeordnetem und untergeordnetem Element 

oder eine Strukturstammvertrauensstellung. Jedes Paar aus übergeordnetem und untergeordnetem 

Element nutzt eine bidirektionale Vertrauensstellung, und die Stämme jeder Struktur nutzen 

eine bidirektionale Vertrauensstellung. Da die Vertrauensstellungen transitiv sind, vertrauen sich alle 

Domänen in der Gesamtstruktur gegenseitig. Wenn sich jedoch ein Benutzer an einer anderen als 

seiner Basisdomäne anmeldet, muss der Anmeldevorgang möglicherweise den gesamten Vertrauenspfad 

durchlaufen. Ein Unternehmen verfügt beispielsweise über eine Domänenstruktur, die der in 

Abbildung 5.9 gezeigten entspricht. Wenn ein Benutzer mit einem Konto in der Domäne Asien. 

Fabrikam.com sich an der Domäne Kanada.NA.Adatum.com anmeldet, geht die anfängliche Anmeldeanforderung 

zunächst an einen Domänencontroller in der Domäne Kanada. Die Anmeldeanforderung 

wird anschließend den Vertrauenspfad entlang an die Domäne NA geleitet, dann an die Domäne 

Adatum, anschließend an die Domäne Fabrikam und schließlich an die Domäne Asien. 

Vertrauensstellungsabkürzungen 

Standardvertrauensstellungen 

Adatum.com 

Fabrikam.com 

NA.Adatum.com SA.Adatum.com Asien.Fabrikam.com 

US.NA.Adatum.com 

Kanada.NA.Adatum.com 

Abbildung 5.9 Eine Shortcutvertrauensstellung kann zum Optimieren des Ressourcenzugriffs zwischen Domänen 

eingesetzt werden. 

Shortcutvertrauensstellungen 

Wenn Sie mehrere Domänen einsetzen und Benutzer häufig auf Ressourcen in anderen Domänen 

zugreifen oder sich an anderen Domänen als ihren Basisdomänen anmelden, sollten Sie vielleicht 

Shortcutvertrauensstellungen in Ihrem Domänenentwurf vorsehen. Shortcutvertrauensstellungen werden 

verwendet, um die Leistung für den Ressourcenzugriff oder die Anmeldung zwischen Domänen 

zu verbessern. Wenn eine Shortcutvertrauensstellung beispielsweise zwischen der Domäne Kanada 

und der Domäne Asien eingerichtet wird, könnte die Anmeldeanforderung direkt an einen Domänencontroller 

in der Domäne Asien geleitet werden. Die Shortcutvertrauensstellung optimiert darüber hinaus 

den Zugriff auf Ressourcen zwischen den Domänen.

Ändern der Domänenhierarchie nach der Bereitstellung 


Hinweis Da Shortcutvertrauensstellungen zusätzlichen Verwaltungsaufwand bedeuten, sollten sie nur bei 

Bedarf implementiert werden. Sie sind nur dann nötig, wenn der Vertrauenspfad mehr als vier oder fünf 

Domänen umfasst und wenn Benutzer sich häufig an anderen Domänen als der eigenen anmelden oder auf 

darin befindliche Ressourcen zugreifen. 

Ihr Domänenplan sollte vor Beginn der Bereitstellung abgeschlossen sein, weil die Domänenkonfiguration 

nach der Bereitstellung nur noch schwer geändert werden kann. Bei Windows Server 2003 oder 

höher können Sie Domänen in einer Gesamtstruktur umbenennen, die auf der Funktionsebene Windows 

Server 2003 oder Windows Server 2008 ausgeführt wird. Wenn Sie Domänen umbenennen, können 

Sie eine Domäne aus einer Struktur in eine andere Innerhalb der Gesamtstruktur verschieben, 

haben jedoch nicht die Möglichkeit, die Gesamtstruktur-Stammdomäne zu ersetzen. Es ist außerdem 

nicht möglich, Domänen über das Domänenumbenennungstool der Gesamtstruktur hinzuzufügen oder 

daraus zu entfernen. 

Der Vorgang zur Domänenumbenennung ist komplex und seine Planung und Ausführung erfordert ein 

hohes Maß an Umsicht. Außerdem verhält sich der für eine vollständige Domänenumbenennung 

erforderliche Zeitraum direkt proportional zur Größe einer Active Directory-Gesamtstruktur in Bezug 

auf die Anzahl der Domänen, Domänencontroller und Mitgliedscomputer. 

Weitere Informationen Einzelheiten zum Umbenennen von Domänen finden Sie unter „Domain Rename 

Technical Reference“ unter http://technet2.microsoft.com/windowsserver/en/library/35e63f1e-f097-4c9ca788-efc840d781931033.mspx?mfr=true. 

Definieren des Domänenbesitzes 

Jeder der im AD DS-Entwurf enthaltenen Domänen müssen Sie einen Domänenbesitzer zuweisen. In 

den meisten Fällen sind die Domänenbesitzer Administratoren der Geschäftseinheit oder die Administratoren 

in der geografischen Region, in der die Domäne definiert wurde. 

Hinweis Wenn Sie eine dedizierte Stammdomäne einsetzen, sind die Domänenbesitzer der Domäne 

gleichzeitig die Gesamtstrukturbesitzer. Die einzigen echten Funktionen, die in einer dedizierten Stammdomäne 

durchgeführt werden, sind Gesamtstrukturfunktionen; es ist daher sinnvoll, dass die Gesamtstrukturbesitzer 

auch die Stammdomäne besitzen. 

Die Rolle des Domänenbesitzers ist die Verwaltung der einzelnen Domäne. Zu seinen Aufgaben zählen 

Folgende: 

• Erstellen von Sicherheitsrichtlinien auf Domänenebene Hierzu gehören Kennwortrichtlinien, Kontosperrungsrichtlinien 

und Kerberos-Ticketrichtlinien. 

• Entwerfen der Gruppenrichtlinienkonfiguration auf Domänenebene Der Domänenbesitzer kann die 

GPOs (Gruppenrichtlinienobjekte) für die gesamte Domäne entwerfen und das Recht zum Verknüpfen 

von GPOs und OUs an Administratoren auf OU-Ebene delegieren. 

• Erstellen der obersten OU-Struktur in der Domäne Nach der Erstellung der obersten OU-Struktur 

kann die Aufgabe zum Erstellen untergeordneter OUs den Administratoren auf OU-Ebene übertragen 

werden. 

• Delegieren administrativer Rechte innerhalb der Domäne Der Domänenbesitzer sollte die administrativen 

Richtlinien für die Domänenebene festlegen (inkl. Richtlinien zur Benennung von Schemata, 

Gruppenaufbau etc.) und anschließend Rechte an Administratoren auf OU-Ebene delegieren.


• Verwalten der administrativen Gruppen auf Domänenebene Wie bereits erwähnt, müssen die Administratoren 

in jeder Domäne extrem vertrauenswürdig sein, da ihre Aktionen sich auf die ganze 

Gesamtstruktur auswirken können. Die Rolle des Domänenbesitzers besteht darin, die Mitgliedschaft 

der administrativen Gruppen auf Domänenebene einzuschränken und nach Möglichkeit 

administrative Rechte auf niedrigerer Ebene zu delegieren. 

Entwerfen von Domänen- und Gesamtstrukturfunktionsebenen 

Beim Entwerfen von AD DS müssen Sie außerdem entscheiden, welche Domänen- und Gesamtstrukturfunktionsebene 

implementiert werden soll. 

Auf Domänenfunktionsebene aktivierte Funktionen 

Tabelle 5.1 zeigt, welche Funktionen auf welcher Domänenfunktionsebene aktiviert sind. Außerdem 

werden die Betriebssysteme für Domänencontroller aufgeführt, die auf der jeweiligen Funktionsebene 

unterstützt werden. 

Tabelle 5.1 

Domänenfunktionsebenen 

Domänenfunktionsebene 

Windows 2000 

einheitlich 

Windows 

Server 2003 

Aktivierte Funktionen 

Alle Active Directory-Standardfunktionen und folgende Funktionen: 

• Universelle Gruppen aktiviert sowohl für Verteilergruppen als auch 

für Sicherheitsgruppen 

• Gruppenverschachtelung 

• Gruppenkonvertierung aktiviert 

• SID-Verlauf (Sicherheitskennung) 

Alle Active Directory-Standardfunktionen, alle Funktionen aus der Domänenfunktionsebene 

Windows 2000 einheitlich und folgende Funktionen: 

• Domänenumbenennung 

• Aktualisierung des Anmeldezeitstempels: Das lastLogonTimestamp- 

Attribut wird mit der letzten Anmeldezeit des Benutzers oder Computers 

aktualisiert 

• Die Möglichkeit, das Attribut userPassword als effektives Kennwort 

für inetOrgPerson- und User-Objekte festzulegen 

• Die Möglichkeit zum Umleiten der Container Users und Computers 

• Die Möglichkeit zum Speichern von Richtlinien des Autorisierungs- 

Managers in AD DS 

• Eingeschränkte Delegierung, sodass Anwendungen die sichere 

Delegierung von Benutzeranmeldeinformationen durch das Kerberos-Authentifizierungsprotokoll 

nutzen können 

• Ausgewählte Authentifizierung, mit deren Hilfe die Benutzer und 

Gruppen aus einer vertrauten Gesamtstruktur festgelegt werden können, 

die sich an Ressourcenservern in einer vertrauenden Gesamtstruktur 

authentifizieren dürfen 

Unterstützte Betriebssysteme 

für Domänencontroller 

Windows 2000 




Windows Server 2008

Entwerfen von Domänen- und Gesamtstrukturfunktionsebenen 179 

Tabelle 5.1 

Domänenfunktionsebenen (Fortsetzung) 


Windows 

Server 2008 


Alle Active Directory-Standardfunktionen, alle Funktionen aus der Domänenfunktionsebene 

Windows Server 2003 und folgende Funktionen: 

• Unterstützung der DFS-Replikation (Distributed File System) für 

SYSVOL 

• Unterstützung von AES 128 und 256 (Advanced Encryption Services) 

für das Kerberos-Protokoll 

• Informationen zur letzten interaktiven Anmeldung: die Uhrzeit der 

letzten erfolgreichen interaktiven Anmeldung eines Benutzers, die 

Arbeitsstation, an der er sich angemeldet hat, und die Anzahl fehlgeschlagener 

Anmeldeversuche seit der letzten Anmeldung 

• Detaillierte Kennwortrichtlinien, die eine Angabe von Kennwort- und 

Kontosperrungsrichtlinien für Benutzer und globale Sicherheitsgruppen 

in einer Domäne ermöglichen 

Unterstützte Betriebssysteme 

für Domänencontroller 


Auf Gesamtstrukturfunktionsebene aktivierte Funktionen 

Tabelle 5.2 zeigt, welche Funktionen auf welcher Gesamtstrukturfunktionsebene aktiviert sind. 

Außerdem werden die Betriebssysteme für Domänencontroller aufgeführt, die auf der jeweiligen 

Funktionsebene unterstützt werden. 

Tabelle 5.2 

Gesamtstrukturfunktionsebenen 

Gesamtstrukturfunktionsebene 


Unterstützte Domänencontroller 

Windows 2000 Alle Active Directory-Standardfunktionen Windows Server 2008 


Windows 2000 

Windows 

Server 2003 

Alle Active Directory-Standardfunktionen und folgende Funktionen: 

• Vertrauensstellung mit einer anderen Gesamtstruktur 


• Replikation verknüpfter Werte (Änderungen an der Gruppenmitgliedschaft 

zum Speichern und Replizieren von Werten für einzelne Mitglieder 

statt Replikation der gesamten Mitgliedschaft als 

abgeschlossene Einheit) 

• Die Möglichkeit zur Bereitstellung eines schreibgeschützten Domänencontrollers 

(RODC) unter Windows Server 2008 

• Verbesserte KCC-Algorithmen (Knowledge Consistency Checker) 

und Skalierbarkeit 

• Die Möglichkeit zum Erstellen von Instanzen der dynamischen Erweiterungsklasse 

namens dynamicObject in einer Domänenverzeichnispartition 

• Die Möglichkeit zum Konvertieren einer inetOrgPerson-Objektinstanz 

in eine User-Objektinstanz und umgekehrt 

• Deaktivieren und Umdefinieren von Attributen und Klassen im 

Schema 


Windows Server 2008


Tabelle 5.2 

Gesamtstrukturfunktionsebenen (Fortsetzung) 


Windows 

Server 2008 


Bietet alle Funktionen, die auf der Gesamtstrukturebene 

Windows Server 2003 bereitstehen, jedoch keine zusätzlichen Funktionen; 

alle Domänen, die der Gesamtstruktur nachträglich hinzugefügt 

werden, werden jedoch standardmäßig auf der Domänenfunktionsebene 

Windows Server 2008 ausgeführt 



Implementieren einer Domänen- und Gesamtstrukturfunktionsebene 

In den meisten Fällen sollten Sie, basierend auf den Betriebssystemen der Domänencontroller, die eingesetzt 

werden oder noch eingesetzt werden sollen, die höchstmögliche Domänen- und Gesamtstrukturfunktionsebene 

implementieren. Wenn Sie eine neue Windows Server 2008-Gesamtstruktur einsetzen 

und nicht planen, Windows Server 2003-Domänencontroller in die Gesamtstruktur aufzunehmen, 

sollten Sie die Domänen- und Gesamtstrukturfunktionsebene auf Windows Server 2008 einstellen. 

Wenn Sie eine vorhandene Domäne aktualisieren, sollten Sie die Domänenfunktionsebene heraufstufen, 

nachdem Sie die letzten Domänencontroller unter Windows 2000 oder Windows Server 2003 entfernt 

haben. Sobald alle Domänen auf die Funktionsebene Windows Server 2008 heraufgestuft wurden, 

sollten Sie die Gesamtstrukturfunktionsebene auf dieselbe Ebene heraufstufen. 

Auf der DVD Mithilfe der Registerkarte Domain Design Decisions im Arbeitsblatt 

ADDS_DesignDocument.xlsx auf der CD können Sie Ihre Entscheidungen zum Domänenentwurf und mithilfe 

der Registerkarte AD Domain Design die Entwürfe zu Gesamtstruktur und Domänen dokumentieren. 

Entwerfen der DNS-Infrastruktur 

Nachdem Sie entschieden haben, wie viele Domänen Sie bereitstellen müssen, und die Domänenhierarchie 

festgelegt haben, müssen Sie im nächsten Schritt die DNS-Infrastruktur für Ihr Netzwerk entwerfen. 

AD DS unter Windows Server 2008 erfordern DNS, da jeder Domänenname ein Teil des 

DNS-Namespaces ist. Als wichtige Entwurfsentscheidung muss festgelegt werden, wo AD DS- 

Domänen innerhalb dieses Namespaces platziert werden. Zusätzlich zum Namespace müssen Sie 

auch die DNS-Serverkonfiguration entwerfen. Wenn das Unternehmen bereits eine DNS-Infrastruktur 

verwendet, müssen Sie möglicherweise Ihren Namespace an den aktuellen Namespace anpassen 

und auch die Windows Server 2008-DNS-Server für die Zusammenarbeit mit den vorhandenen DNS- 

Servern konfigurieren. 

Auf der DVD Der erste Schritt zum Entwerfen der DNS-Infrastruktur besteht darin, die aktuelle DNS-Infrastruktur 

zu untersuchen. Sie können die Arbeitsblätter DNS Zone Configuration und DNS Server Configuration 

in CurrentNetworkEnvironment.xslx zum Dokumentieren der DNS-Zonenkonfiguration verwenden. 

Entwurf des Namespaces 

Nachdem Sie die Informationen zur aktuellen DNS-Infrastruktur gesammelt haben, können Sie mit 

dem Entwurf des AD DS-Namespaces beginnen.

Entwerfen der DNS-Infrastruktur 181 

Interne und externe DNS-Namespaces 

Eine der ersten Fragen, die Sie zu Beginn des Namespace-Entwurfs klären müssen, ist, ob derselbe 

DNS-Namespace intern und extern verwendet werden soll. 

Verwenden desselben Namespaces intern und extern Einige Unternehmen entscheiden sich dafür, 

denselben DNS-Namen intern wie auch extern einzusetzen. In diesem Fall hat ein Unternehmen nur 

einen DNS-Namen im Internet registriert. Wie in Abbildung 5.10 gezeigt, könnte Adatum beschließen, 

Adatum.com sowohl intern als auch extern zu verwenden. 

Interner Namespace 

Adatum.com 

Externer Namespace 

Adatum.com 

DNS-Server 

Adatum.com-Zonendatei 

Interne Hosteinträge 

Firewall 

DNS-Server 


Externe Hosteinträge 

Adatum.com 


Verwenden eines einzigen DNS-Namespaces 

Sicherheitswarnung Unabhängig davon, ob Sie intern wie extern dieselben oder unterschiedliche Namespaces 

verwenden, sollte Ihr interner DNS-Server niemals für externe Clients zugänglich sein. Der interne 

DNS-Server hostet alle Domänencontrollereinträger sowie möglicherweise die Einträge für alle Computer in 

Ihrem Netzwerk (wenn dynamisches DNS aktiviert ist). Die einzigen Einträge, die vom Internet aus zugänglich 

sein sollten, sind die Einträge für Ressourcen, die vom Internet aus zugänglich sein müssen. Für die meisten 

Unternehmen besteht die Liste extern verfügbarer Ressourcen aus den Adressen für die SMTP-Server, Webserver 

und möglicherweise einige andere Server. Die Verwendung desselben Namespaces bedeutet nicht, 

dass Sie nur einen DNS-Server oder eine Zonendatei intern und extern einsetzen sollten. 

Der Hauptvorteil der Verwendung desselben Namespaces intern wie extern liegt darin, dass dem Endbenutzer 

eine konsistente Benutzerumgebung bereitgestellt wird. Der Benutzer verwendet immer 

denselben Domänennamen für jede Verbindung mit dem Unternehmensnetzwerk. Die SMTP-Adresse 

des Benutzers und der UPN (User Principal Name) verwenden denselben Domänennamen wie die 

öffentliche Website. Wenn der Benutzer auf webbasierte Ressourcen zugreifen muss, kann er denselben 

Namen sowohl intern als auch extern verwenden (auch wenn er nicht auf denselben Server 

zugreift). Ein weiterer Vorteil der Nutzung desselben Namespaces liegt darin, dass nur ein DNS- 

Name registriert werden muss. 

Die Hauptnachteile der Verwendung desselben Namespaces hängen mit den Themen Sicherheit und 

Verwaltungsaufwand zusammen. Viele Unternehmen möchten ihren internen DNS-Namen nicht im 

Internet preisgeben und betrachten dies als potenzielles Sicherheitsrisiko. Die Verwendung desselben 

Namespaces intern wie extern kann die DNS-Verwaltung verkomplizieren, da DNS-Administratoren 

jetzt zwei verschiedene Zonen mit demselben Domänennamen verwalten müssen. Die Verwendung 

desselben Namens kann auch einige Clientkonfigurationen komplizierter gestalten.


Beispielsweise können die meisten Webproxyclients so konfiguriert werden, dass sie angegebene 

Domänennamen als intern interpretieren, sodass der Client sich direkt mit ihnen verbindet, ohne über 

den Proxyserver zu gehen. Die Verwendung desselben Namens kann bei dieser Konfiguration zu Verwicklungen 

führen. 

Verwenden eines unterschiedlichen internen und externen Namespaces Die meisten Unternehmen 

verwenden intern und extern unterschiedliche Namespaces. Beispielsweise kann ein Unternehmen 

beschließen, Adatum.com als externen Namespace und einen Namen wie Adatum.net oder 

AD.Adatum.com als internen Namespace zu verwenden. (Siehe Abbildung 5.11.) 

Hinweis Jeder Unterschied in den Domänennamen heißt, dass Sie intern einen anderen Namespace 

verwenden. Wenn Sie beispielsweise Adatum.com als externen Namespace einsetzen, sind Adatum.net, 

ADAdatum.com und AD.Adatum.com alles unterschiedliche Namespaces. AD.Adatum.com erfordert eine 

andere DNS-Konfiguration als die anderen beiden, alle drei sind jedoch eigenständig. 

Interner Namespace 

Adatum.net 

Externer Namespace 

Adatum.com 

DNS-Server 

Adatum.net-Zonendatei 

Interne Hosteinträge 

Firewall 

DNS-Server 


Externe Hosteinträge 


Adatum.net 

Verwenden separater Namespaces intern und extern 

Oft wird der eigenständige interne Namespace aus Sicherheitsgründen ausgewählt, um zu verhindern, 

dass der interne Namespace im Internet preisgegeben wird. Auch sind die DNS- und Proxykonfigurationen 

mit dem eigenständigen Namespace leichter zu verwalten. Der Hauptnachteil der Verwendung 

eines eigenständigen Namespaces besteht darin, dass das Unternehmen möglicherweise zusätzliche 

DNS-Namen bei den Vergabestellen für Internetnamen registrieren muss. Auch wenn die Registrierung 

des internen DNS-Namen bei den Vergabestellen für Internetnamen nicht zwingend erforderlich 

ist, wird sie dennoch empfohlen. Wenn Sie den Namen nicht registrieren und ein anderes Unternehmen 

kommt Ihnen zuvor, können Ihre Benutzer keine Internetressourcen mit dem Domänennamen des 

internen Namespaces mehr finden. 

Optionen für den Namespace-Entwurf 

Die Namen, die Sie letztlich für Ihren DNS-Namespace wählen, sind flexibel und werden größtenteils 

durch die aktuelle DNS-Infrastruktur festgelegt. Wenn noch keine DNS-Infrastruktur vorliegt 

und Sie einen oder mehrere Domänennamen zweiter Ebene bereits für Ihr Unternehmen registriert 

haben, ist der Entwurf des DNS-Namespaces ziemlich einfach. In diesem Fall können Sie den registrierten 

Domänennamen zweiter Ebene als Stammdomänennamen wählen und anschließend untergeordnete 

Domänennamen für zusätzliche Domänen in derselben Struktur oder zusätzliche Domänennamen 

zweiter Ebene für zusätzliche Strukturen in der Gesamtstruktur delegieren. In Abbildung 5.12 

wird ein Beispiel dargestellt.


Firewall 

INTERNET 

Internet-DNS-Server 

Autorisierender 

DNS-Server für 

Adatum.com 



Fabrikam.com 

Adatum.com 

Fabrikam.com 



NA.Adatum.com 




NA.Adatum.com 




Delegierung 


Entwurf des DNS-Namespaces ohne vorhandene DNS-Infrastruktur 

Abbildung 5.12 zeigt außerdem, wie die DNS-Server in diesem Szenario konfiguriert würden. Der 

DNS-Server von Adatum.com ist für seine Domäne autorisierend und enthält Delegierungseinträge an 

NA.Adatum.com und EMEA.Adatum.com sowie bedingte Weiterleitungen oder Stubzonen für die 

Domäne Fabrikam.com. Der DNS-Server von Fabrikam.com ist für seine Zone autorisierend und enthält 

bedingte Weiterleitungen oder Stubzonen für Adatum.com. Zur Auflösung von Internetadressen 

könnten die Strukturstammserver mit einer Weiterleitung konfiguriert werden, die auf einen Server im 

Internet verweist. Alternativ dazu könnten sie mit Internetstammhinweisen konfiguriert werden. 

Interne und externe Namespaces 

Das Problem der Verwendung eines internen Namespaces, der sich vom externen, öffentlichen 

Namespace unterscheidet, kann innerhalb des Unternehmens zu zahlreichen Diskussionen führen. 

In manchen Fällen besteht die technisch beste Lösung darin, intern und extern verschiedene 

Namespaces zu verwenden; möglicherweise setzen Entscheidungsträger des Unternehmens jedoch 

allem, was sich vom Internetnamespace unterscheidet, erheblichen Widerstand entgegen. Oft ist 

Markenpolitik der Grund hierfür: Einige Unternehmen haben viele Jahre und Millionen Dollar in die 

Erstellung eines Markennamens gesteckt, den Kunden sofort wiedererkennen. Die Websites des 

Unternehmens und die SMTP-Adressen aller Benutzer spiegeln diesen Namespace wider.


Einige Unternehmen verfügen vielleicht sogar über mehrere öffentliche Identitäten mit mehreren 

Geschäftseinheiten innerhalb des Unternehmens, die alle einen eigenen Markennamen besitzen. 

Die meiste Zeit über möchten die Benutzer des Unternehmens der Welt keinen anderen Namen als 

ihren bekannten Unternehmensnamen präsentieren. 

Die gute Nachricht lautet, dass Sie intern und extern verschiedene Namespaces verwenden und 

dennoch extern nur einen Namespace anzeigen können. Beispielsweise könnte Adatum sich entschließen, 

Adatum.net als internen Namespace und Adatum.com als öffentlichen Namespace zu 

verwenden. Der interne Namespace kann beinahe vollständig vor jedem außer den Netzwerkadministratoren 

verborgen werden. Die SMTP-Adressen für alle Benutzer können dennoch alias@Adatum.com 

lauten, und alle Webserver können das Websuffix Adatum.com verwenden. Falls erforderlich 

kann der UPN für alle Benutzer sogar als alias@Adatum.com konfiguriert werden, selbst wenn 

ein anderer interner Namespace verwendet wird. 

Der DNS-Entwurf kann etwas komplizierter ausfallen, wenn bereits eine interne DNS-Infrastruktur 

vorhanden ist. In diesem Fall stehen mindestens drei Optionen für die Integration in die aktuelle Infrastruktur 

zur Verfügung. Die erste Option besteht darin, nur die aktuelle DNS-Infrastruktur einschließlich 

des Domänennamens für AD DS zu verwenden. Beispielsweise könnte Adatum ADatum.net als 

internen Namespace verwenden und BIND-DNS-Server zum Bereitstellen des DNS-Dienstes einsetzen. 

Das Unternehmen könnte beschließen, Adatum.net als AD DS-Domänennamen zu nutzen und 

weiterhin die aktuellen DNS-Server zu verwenden (vorausgesetzt, sie unterstützen SRV-Einträge 

(Service Locator)). Alternativ dazu könnte das Unternehmen sich für denselben Domänennamen entscheiden, 

den DNS-Dienst jedoch auf einen DNS-Server unter Windows Server 2008 verschieben. 

In beiden Fällen ist nur ein geringer Aufwand an Neukonfiguration der DNS-Server erforderlich. 

Die DNS-Server können weiterhin dieselben Weiterleitungen oder Stammhinweise für die Internetnamensauflösung 

verwenden. 

Hinweis Bei der Konfiguration der DNS-Server für die Internetnamensauflösung stehen zwei Optionen zur 

Verfügung: Sie können Weiterleitungen verwenden oder die DNS-Server mit Stammhinweisen konfigurieren. 

Die Verwendung von Weiterleitungen ist im Allgemeinen sicherer, weil Sie den internen DNS-Server für 

die Weiterleitung an einen oder zwei externe DNS-Server konfigurieren können. Auf diese Weise können Sie 

die Firewallkonfiguration vereinfachen. Der Einsatz von Stammhinweisen führt eventuell zu verbesserter 

Redundanz, weil Sie damit eine einzelne Fehlerstelle vermeiden. Wenn ein Stammhinweisserver nicht 

reagiert, wendet der DNS-Server sich einfach an einen anderen. 

Die zweite Option für eine bereits vorhandene DNS-Infrastruktur besteht darin, einen anderen DNS- 

Namen für AD DS-Domänen zu wählen. Beispielsweise könnte Adatum den Namen Adatum.net als 

aktuellen internen DNS-Namespace verwenden und sich für die Verwendung von AD DS-Domänen 

mit dem Domänennamen ADAdatum.net entscheiden. (Siehe Abbildung 5.13.) 

In diesem Fall kann ein DNS-Server als primärer Namenserver für ADAdatum.net mit Delegierungseinträgen 

für NA.ADAdatum.net und EMEA.ADAdatum.com eingesetzt werden. Bei diesem DNS-Server 

kann es sich um den autorisierenden Server für Adatum.net oder auch um einen zusätzlichen 

DNS-Server handeln. Wenn Sie für die AD DS-Domäne einen zusätzlichen DNS-Server bereitstellen, 

müssen Sie die Weiterleitungen und Stammhinweise für diesen DNS-Server konfigurieren.


Firewall 

INTERNET 


Windows Server 2008- 

DNS-Server, 

autorisierend für 

ADAdatum.net 

BIND-DNS-Server, 


Adatum.net 

ADAdatum.net 



NA.ADAdatum.net 



EMEA.ADAdatum.net 

NA.ADAdatum.net 

EMEA.ADAdatum.net 



Delegierung 


Konfigurieren von DNS für die Verwendung eines anderen internen Namespaces 

Bei einem dritten DNS-Entwurf, den Sie mit einer vorhandenen DNS-Infrastruktur nutzen können, 

sind die AD DS-Domänen untergeordnete Domäne des vorhandenen internen Namespace. Adatum 

könnte beispielsweise beschließen, eine Unterdomäne AD.Adatum.net als AD DS-Domäne zu erstellen. 

(Siehe Abbildung 5.14.) In diesem Fall wird der DNS-Server für Adatum.net mit einem Delegierungseintrag 

für die Domäne AD.Adatum.net konfiguriert. Der DNS-Server von AD.Adatum.net wird 

dann mit einem Weiterleitungseintrag konfiguriert, der auf den DNS-Server von Adatum.net verweist. 

Integration in die aktuelle DNS-Infrastruktur 

Fast alle großen Unternehmen haben bereits eine DNS-Infrastruktur eingerichtet. Wenn das Unternehmen 

Active Directory bereits verwendet, ist eine DNS-Infrastruktur eingerichtet, um Active 

Directory zu unterstützen. Zusätzlich verwenden die meisten großen Unternehmen DNS für die 

Namensauflösung für UNIX-Server oder zum Bereitstellen der DNS-Dienste, die Benutzer für den 

Internetzugriff benötigen. In vielen Fällen werden die DNS-Dienste von BIND-DNS-Servern bereitgestellt, 

die auf UNIX-Servern ausgeführt werden. Die meisten Unternehmen mit einer vorhandenen 

BIND-DNS-Infrastruktur werden die aktuelle Infrastruktur wahrscheinlich nicht einfach entfernen 

und alles auf Windows Server 2008 verschieben. Das bedeutet, dass die DNS-Anforderungen für AD 

DS mit der aktuellen DNS-Infrastruktur zusammen funktionieren müssen.


INTERNET 

Firewall 


Windows Server 2008- 

DNS-Server, 


AD.Adatum.net 

BIND-DNS-Server, 


Adatum.net 

ADAdatum.net 



NA.AD.Adatum.net 



EMEA.AD.Adatum.net 

NA.AD.Adatum.net 

EMEA.AD.Adatum.net 



Delegierung 

Abbildung 5.14 Konfigurieren von DNS durch Hinzufügen einer untergeordneten Domäne zum vorhandenen 

internen Namespace 

Für die Integration gibt es zwei Optionen, wenn die aktuelle BIND-DNS-Infrastruktur beibehalten 

werden soll. Die erste Option besteht darin, Nicht-Microsoft-DNS-Server zu verwenden und die 

erforderlichen DNS-Zoneninformationen für AD DS auf diesen Servern zu hosten. Dies ist sicher eine 

Möglichkeit. Die einzige absolute Anforderung an die Integration von DNS und AD DS ist, dass der 

Server SRV-Einträge unterstützen muss. Außerdem werden Sie wahrscheinlich sicherstellen wollen, 

dass die DNS-Server auch dynamische Aktualisierungen (besonders, wenn Sie eine Registrierung 

aller Client-IP-Adressen in DNS planen) und inkrementelle Zonenübertragungen unterstützen. Wenn 

in der aktuellen Infrastruktur BIND-DNS-Server eingesetzt werden, unterstützen BIND 8.1.2-Server 

SRV-Einträge und dynamische Aktualisierungen. Zusätzlich zu der von BIND 8.1.2 bereitgestellten 

Unterstützung unterstützt BIND 8.2.1 auch inkrementelle Zonenübertragugnen. Solange Sie eine dieser 

neueren BIND-Versionen verwenden, können Sie weiterhin BIND-DNS-Server einsetzen. 

Auswählen des zu verwendenden DNS-Servers 

Die Frage, ob DNS-Server unter Windows Server oder Nicht-Microsoft-DNS-Server verwendet 

werden sollen, kann zu erhitzten Diskussionen ohne zufriedenstellende Lösung führen.


Große Unternehmen haben viele Jahre lang BIND-DNS-Server verwendet; ihre DNS-Administratoren 

sind oft sehr sachkundig und erfahren und geben die DNS-Dienste nur unwillig an eine 

Microsoft-Plattform ab. Oft haben diese Administratoren Bedenken in Bezug auf die Stabilität, 

Zuverlässigkeit und Sicherheit von DNS auf Microsoft-Servern. 

Eine Möglichkeit, in dieser Diskussion Position zu beziehen, ist, dass es eigentlich keine Rolle 

spielt, wie der DNS-Dienst bereitgestellt wird. Solange die DNS-Server SRV-Einträge unterstützen, 

können Windows Server 2008 AD DS mit einem beliebigen DNS-Server zusammenarbeiten. 

Absolut entscheidend ist jedoch, dass der DNS-Dienst immer verfügbar sein muss. Wenn der DNS- 

Dienst je während der Geschäftszeiten heruntergefahren wird, können Clients oder Server keine 

AD DS-Domänencontroller mehr finden. Die Schlüsselfrage lautet also, welcher DNS-Server die 

Zuverlässigkeit bietet, die für AD DS erforderlich ist. 

Sowohl UNIX- als auch Windows-Server können sehr zuverlässig sein, sofern sie richtig konfiguriert 

werden. Selbst die Diskussion über die Zuverlässigkeit verschiedener Server scheint jedoch 

den Kern der Sache nicht zu treffen. Kein einzelner Server kann zu hundert Prozent zuverlässig 

sein. Eine Frage, die man sich daher stellen sollte, ist, welcher DNS-Server die besten Optionen 

zum Beseitigen einer Einzelfehlerquelle und zum Verteilen der Dienstverfügbarkeit über mehrere 

Server bietet. Windows Server 2008 stellt hervorragende Optionen für die Bereitstellung dieser 

Zuverlässigkeit über mehrere Server bereit, vor allem dann, wenn AD DS-integrierte Zonen verwendet 

werden. Mit AD DS-integrierten Zonen kann jeder Domänencontroller, der gleichzeitig als 

DNS-Server eingesetzt wird, eine beschreibbare Kopie der DNS-Informationen verwalten. AD DSintegrierte 

Zonen gehen auch gegen die Sicherheitsbedenken an, indem sie sichere Aktualisierungen 

implementieren. 

Viele Unternehmen haben sich dafür entschieden, den BIND-DNS-Servern treu zu bleiben, und 

diese Server haben die erforderliche Funktionalität ohne Probleme bereitgestellt. Einige Unternehmen 

haben beschlossen, den primären DNS-Dienst auf Microsoft DNS-Server zu verschieben und 

die BIND-DNS-Server als sekundäre Namenserver zu behalten. Fast jede Konfiguration funktioniert, 

und solange die DNS-Server immer verfügbar sind, spielt es wirklich keine Rolle, für welche 

Option ein Unternehmen sich entscheidet. 

Die zweite Option zur Integration von Windows Server 2008 DNS in BIND besteht darin, beide Arten 

von DNS einzusetzen. Viele Unternehmen nutzen die BIND-DNS-Server als primäre Namenserver 

für den internen Namespace. Beispielsweise könnte Adatum BIND zur Namensauflösung für 

Adatum.com verwenden. Wenn Adatum beschließt, AD DS einzusetzen und DNS-Server unter 

Windows Server 2008 zu verwenden, stehen dem Unternehmen eine Reihe von Optionen zur Verfügung. 

Wenn Adatum Adatum.com als AD DS-DNS-Namen nutzen möchte, kann das Unternehmen 

die primäre Zone auf den DNS-Server unter Windows Server 2008 verschieben und den BIND-DNS- 

Server als sekundären Namenserver beibehalten. Der DNS-Server unter Windows Server 2008 könnte 

jedoch auch der sekundäre Namenserver für den BIND-DNS-Server sein. 

Hinweis Sie können BIND-DNS-Server und DNS-Server unter Windows Server 2008 für denselben 

Namespace verwenden. Beide DNS-Server können entweder als primärer oder als sekundärer Namenserver 

für die Zoneninformationen des jeweils anderen fungieren. Wenn Sie jedoch AD DS-integrierte Zonen 

verwenden möchten, muss die BIND DNS-Zone als sekundäre Zone konfiguriert werden. Eine AD DS-integrierte 

Zone kann keine sekundäre Zone sein.


Adatum kann auch beschließen, AD DS mit einem anderen Domänennamen als dem, der derzeit auf 

den BIND-DNS-Servern verwendet wird, bereitzustellen. Beispielsweise kann das Unternehmen sich 

entscheiden, Adatum.net als AD DS-DNS-Namen zu nutzen. In diesem Fall können die DNS-Server 

unter Windows Server 2008 als autorisierende Server für Adatum.net und die BIND-Server als autorisierend 

für Adatum.com konfiguriert werden. Der DNS-Server unter Windows Server 2008 kann 

anschließend mit einer bedingten Weiterleitung an den BIND-DNS-Server für Adatum.com konfiguriert 

werden. 

Hinweis Der Abschnitt zum Planen des DNS-Namespaces weiter oben in diesem Kapitel hat eine Reihe 

von möglichen Szenarios für die Bereitstellung von DNS-Namespaces aufgezeigt. Die im Abschnitt zur 

Namespaceplanung erörterten DNS-Server sind im Wesentlichen austauschbar: Alle DNS-Server könnten 

BIND-Server oder DNS-Server unter Windows Server sein. Theoretisch könnten Sie Windows Server 2008 

DNS sogar zum Hosten des externen DNS-Namens verwenden und BIND DNS für AD DS-Domänen einsetzen. 

Entwerfen der Struktur von Organisationseinheiten 

Nach dem Abschluss des Entwurfs auf Domänenebene besteht der nächste Schritt darin, einen OU- 

Entwurf für jede Domäne zu erstellen. Wie in Kapitel 2, „Active Directory-Domänendienstkomponenten“, 

bereits beschrieben wurde, werden OUs zum Erstellen einer hierarchischen Struktur innerhalb 

einer Domäne verwendet. Mithilfe dieser Hierarchie können administrative Aufgaben delegiert 

oder eine Reihe von Gruppenrichtlinieneinstellungen auf eine Sammlung von Objekten angewendet 

werden. 

Organisationseinheiten und der AD DS-Entwurf 

Beim Entwerfen der OU-Struktur stellen Sie eine Sammlung von Objekten zusammen, um diese 

Objekte auf dieselbe Weise zu verwalten. Beispielsweise soll ein gemeinsamer Satz an Desktopeinstellungen 

für alle Benutzer in einer bestimmten Abteilung konfiguriert werden. Indem Sie alle 

Benutzer in einer OU gruppieren, können Sie eine Gruppenrichtlinie auf diese OU anwenden, die den 

Benutzerdesktop automatisch konfiguriert. Außerdem können Sie Objekte gruppieren, um dieser 

Objektgruppe einen Administrator zuzuweisen. Wenn Sie beispielsweise eine Außenstelle mit einem 

lokalen Administrator besitzen, können Sie eine OU erstellen, alle Benutzer- und Computerobjekte in 

der Außenstelle in diese OU platzieren und anschließend die Verwaltung dieser OU an den lokalen 

Administrator delegieren. 

OUs verfügen über mehrere Eigenschaften: 

• Der OU-Entwurf wirkt sich nicht auf den Entwurf des DNS-Namespaces aus. OUs erhalten 

Verzeichnisnamen innerhalb eines DNS-Namespaces. Beispielsweise kann eine OU den definierten 

Namen OU=Manager,DC=Adatum,DC=com besitzen. In diesem Fall lautet der DNS- 

Name Adatum.com, und die OU-Namen sind LDAP-Namen innerhalb des DNS-Namespaces. 

• OUs können innerhalb anderer OUs erstellt werden. Standardmäßig werden administrative Rechte 

und Gruppenrichtlinieneinstellungen, die für OUs höherer Ebenen eingestellt werden, von untergeordneten 

OUs übernommen. Dieses Standardverhalten kann geändert werden. 

• OUs sind für Endbenutzer transparent. Wenn ein Benutzer AD DS nach einem beliebigen Objekt 

durchsucht, fragt die Benutzeranwendung die Information vom globalen Katalog ab. Der Benutzer 

muss die OU-Struktur nicht kennen, um sich anzumelden oder Objekte in AD DS zu finden.

Entwerfen der Struktur von Organisationseinheiten 189 

• Im Gegensatz zu den anderen AD DS-Komponenten wie Domänen und Gesamtstrukturen kann 

die OU-Struktur nach der Bereitstellung leicht geändert werden. Auch ist zum Verschieben von 

Objekten zwischen OUs nur ein Rechtsklick auf das Objekt und die Auswahl der Option Verschieben 

aus dem Kontextmenü erforderlich. 

Achtung Auch wenn es einfach ist, Objekte zwischen OUs zu verschieben und die OU-Struktur zu verändern, 

müssen Sie dennoch die Auswirkungen solcher Änderungen beachten. Wenn Sie einen Benutzer von 

einer OU in eine andere verschieben, ändern sich die auf OU-Ebene angewandten Gruppenrichtlinienobjekte. 

Wenn Sie OUs innerhalb der Domäne verschieben, müssen Sie berücksichtigen, wie übernommene 

Administratorberechtigungen und Gruppenrichtlinienobjekte auf die verschobene OU angewendet 

werden. 

Entwerfen einer OU-Struktur 

In den meisten Unternehmen besitzen Sie ein erhebliches Maß an Flexibilität beim Erstellen des OU- 

Entwurfs. Beim Entwerfen der OUs für die einzelnen Domänen sind jedoch eine Reihe von Faktoren 

zu berücksichtigen. 

Unternehmensstrukturen und der OU-Entwurf 

Die erste Tendenz beim Erstellen einer OU-Struktur könnte sein, das Organisationsschema des 

Unternehmens nachzubilden. In manchen Unternehmen kann dies funktionieren, in anderen Unternehmen 

führt dieser Ansatz jedoch zu einer ineffektiven OU-Struktur. Beispielsweise beruht das 

Organisationsschema eines Unternehmens in der Regel auf Geschäftseinheiten und berücksichtigt 

nicht, wo die Benutzer tatsächlich arbeiten. Vielleicht sind die Mitglieder derselben Geschäftseinheit 

über mehrere Standorte rund um den Globus verteilt. Die Gruppierung dieser Benutzer in derselben 

OU könnte ziemlich ineffizient sein. 

Oft ist die Analyse der Unternehmensstruktur und des Organisationsschemas jedoch ein guter 

Ansatzpunkt für den OU-Entwurf. Wenn das Unternehmen beispielsweise sehr zentralisiert und 

hierarchisch aufgebaut ist, wird die OU-Struktur dieses Modell wahrscheinlich widerspiegeln. 

Wenn die Unternehmensstruktur den Geschäftseinheiten oder geografischen Standorten einen 

hohes Maß an Autonomie einräumt, sollte der OU-Entwurf diesen Ansatz ebenfalls reflektieren. 

Untersuchen Sie bei der Analyse der Unternehmensstruktur auch die IT-Verwaltungsstruktur. In 

manchen Unternehmen sind separate Geschäftseinheiten weitestgehend eigenständig in der Verwaltung 

ihrer Geschäfte, die IT-Verwaltung kann jedoch dennoch stark zentralisiert sein. In diesem Fall 

entwerfen Sie die OU-Struktur basierend auf der IT-Verwaltungsstruktur, nicht basierend auf der 

Geschäftsverwaltungsstruktur. 

Auf der Verwaltungsdelegierung basierender OU-Entwurf 

Einer der Gründe für das Erstellen einer OU-Struktur besteht darin, Verwaltungsaufgaben delegieren 

zu können. Viele Unternehmen mit separaten Geschäftseinheiten setzen eine einzige AD DS-Domäne 

ein, möchten jedoch dennoch die administrativen Aufgaben basierend auf Ressourcen oder Geschäftseinheiten 

delegieren. Einige Unternehmen mit mehreren Standorten und lokalen Administratoren an 

jedem Standort möchten möglicherweise die Verwaltung der einzelnen Standorte delegieren. Andere 

Unternehmen möchten eine bestimmte administrative Aufgabe delegieren können. Beispielsweise sollen 

ein oder zwei Personen in jeder Abteilung das Recht erhalten, Benutzerkennwörter in der Abteilung 

zurückzusetzen und Benutzerinformationen für alle Benutzer in der Abteilung zu ändern.


All diese Optionen und viele mehr werden durch das Erstellen einer OU-Struktur in AD DS und das 

anschließende Delegieren des Administratorzugriffs ermöglicht. Sie können beinahe jeden Level an 

Administratorzugriff auf OU-Ebene erteilen. Wenn Sie zum Beispiel eine OU für eine Außenstelle 

erstellen, können Sie dem Administrator in dieser Außenstelle die vollständige Steuerung aller 

Objekte in diesem Büro übertragen. Dieser Administrator kann anschließend jede administrative Aufgabein 

dieser OU durchführen, auch die Erstellung untergeordneter OUs und die Delegierung von 

Berechtigungen an andere Administratoren. Wenn Sie eine OU für jede Abteilung erstellen, können 

Sie einigen Benutzern in der Abteilung sehr spezielle Rechte, beispielsweise das Recht zum Zurücksetzen 

von Kennwörtern, erteilen. Sie können administrative Rechte sogar basierend auf den Objekttypen 

in einer OU gewähren: Die Abteilungsadministratoren können beispielsweise Benutzerkonten, 

jedoch keine Gruppen- oder Computerobjekte ändern. In Kapitel 9, „Delegieren der Active Directory- 

Domänendiensteverwaltung“, wird die Delegierung der Verwaltung detaillierter ausgeführt. 

Für die meisten Unternehmen beruht der Entwurf der obersten OUs auf der Anforderung zur Verwaltungsdelegierung. 

Die oberste OU basiert wahrscheinlich auf dem geografischen Standort oder auf 

Geschäftsabteilungen. Oft sind diese OU-Grenzen auch Verwaltungsgrenzen. 

Auf dem Gruppenrichtlinienentwurf basierender OU-Entwurf 

Der zweite Grund für die Erstellung von OUs liegt in der Verwaltung der Zuweisung von Gruppenrichtlinienobjekten. 

Gruppenrichtlinieneinstellungen werden für die Änderungs- und Konfigurationsverwaltung 

von Desktops verwendet. Mit Gruppenrichtlinieneinstellungen können Sie Benutzern eine 

Standarddesktopkonfiguration, einschließlich der automatischen Installation einer Reihe von Anwendungen, 

bereitstellen. Anhand von Gruppenrichtlinieneinstellungen können Sie außerdem steuern, 

welche Änderungen Benutzer an ihren Computern vornehmen können, und viele Sicherheitseinstellungen 

konfigurieren. Fast alle Gruppenrichtlinieneinstellungen in AD DS werden auf OU-Ebene 

zugewiesen. Die Bereitstellung von Gruppenrichtlinieneinstellungen spielt daher für den OU-Entwurf 

eine wichtige Rolle. Gruppieren Sie beim Planen der OU-Struktur Objekte zusammen, die dieselben 

Gruppenrichtlinieneinstellungen verlangen. Wenn beispielsweise alle Benutzer in einer Abteilung dieselben 

Anwendungen benötigen, können diese mithilfe eines Gruppenrichtlinienobjekts installiert 

werden. Die Benutze benötigen vielleicht außerdem einen Standardsatz an Laufwerkzuordnungen. 

Die Anmeldeskripts für die Benutzer können über ein Gruppenrichtlinienobjekt zugewiesen werden. 

Vielleicht möchten Sie auf alle Dateiservern in Ihrem Unternehmen eine Sicherheitsvorlage anwenden. 

Gruppieren Sie zu diesem Zweck alle Dateiserver in einer OU und weisen Sie die Sicherheitsvorlage 

über ein Gruppenrichtlinienobjekt zu. 

In den meisten Unternehmen werden die unteren Ebenen des OU-Entwurfs vorrangig durch den 

Bedarf an Gruppenrichtlinienobjekten bestimmt. Standardmäßig werden alle Gruppenrichtlinieneinstellungen 

von übergeordneten OUs übernommen. Das heißt, dass Sie ein Gruppenrichtlinienobjekt 

auf viele Abteilungen anwenden können, die in der OU-Struktur weit oben angesiedelt sind, und 

anschließend spezifischere Gruppenrichtlinienobjekte auf niedrigerer Ebene zuweisen können. Wenn 

Sie die Standardvererbung von Gruppenrichtlinieneinstellungen ändern möchten, können Sie eine OU 

erstellen und die Richtlinienvererbung für diese OU-Ebene deaktivieren. Diese starke Abhängigkeit 

des OU-Entwurfs von Gruppenrichtlinien bedeutet, dass Sie die Funktionalität der Gruppenrichtlinien 

und die Anforderungen für Ihr Unternehmen genau kennen müssen. In Kapitel 11, „Einführung 

in Gruppenrichtlinien“, Kapitel 12, „Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops“, 

und Kapitel 13, „Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit“, wird 

detailliert beschrieben, wie Gruppenrichtlinien verwendet werden können.

Erstellen eines OU-Entwurfs 

Entwerfen der Struktur von Organisationseinheiten 191 

Wenn Sie mit dem OU-Entwurf beginnen, sollten Sie zunächst die oberen OUs festlegen. Obere OUs 

sind aufgrund aller ihnen untergeordneten OUs nach der Bereitstellung schwieriger zu ändern. Das 

bedeutet auch, dass die oberen OUs auf einer statischen Einheit im Unternehmen beruhen sollten. 

Normalerweise basieren diese OUs auf geografischen Bereichen oder Geschäftseinheiten. 

Ein auf geografischen Standorten beruhender OU-Entwurf ist wahrscheinlich der beständigste. Einige 

Unternehmen scheinen oft umzustrukturieren, ändern jedoch selten die geografische Konstellation. 

Eine auf geografischen Standorten basierende OU-Struktur funktioniert auch dann gut, wenn das 

Unternehmen ein dezentrales Verwaltungsmodell verwendet – vor allem, wenn die Verwaltung geografisch 

eingeteilt ist. Wenn jeder geografische Standort (entweder eine einzelne Niederlassung oder 

eine zentrale Niederlassung mit mehreren damit verbundenen Zweigniederlassungen) seine eigenen 

Netzwerkadministratoren besitzt, können die geografischen OUs zum Delegieren administrativer Aufgaben 

an diese Administratoren verwendet werden. Eine auf den geografischen Standorten basierende 

OU-Struktur ist möglicherweise nicht die beste Wahl, wenn sich an jedem Standort mehrere 

Geschäftseinheiten befinden. Wenn beispielsweise jede Abteilung in jeder Niederlassung des Unternehmens 

repräsentiert ist, kann es effektiver sein, eine auf Geschäftseinheiten basierende OU-Struktur 

auf der obersten Ebene zu verwenden. 

Die zweite gängige oberste OU-Struktur basiert auf Geschäftseinheiten. In diesem Modell wird auf 

oberster Ebene eine OU für jede Geschäftseinheit innerhalb des Unternehmens erstellt. Dieser Konfigurationstyp 

ist besonders geeignet, wenn ein Unternehmen nur einen Standort besitzt oder wenn 

viele administrative Aufgaben auf der Ebene der Geschäftseinheit delegiert werden. Eines der Probleme 

mit einer auf Geschäftseinheiten basierenden OU-Struktur besteht darin, dass die obersten OUs 

im Falle einer Umstrukturierung möglicherweise geändert werden müssen. 

Die meisten großen Unternehmen verwenden tatsächlich eine Kombination aus OUs, die auf geografischen 

Standorten basieren, und OUs, die auf Geschäftseinheiten beruhen. Eine der gängigsten 

Konfigurationen ist eine oberste OU, die auf den geografischen Regionen basiert, und auf der Ebene 

darunter liegende OUs innerhalb jeder Region, die auf Geschäftseinheiten basieren. Einige Unternehmen 

wählen eine oberste OU basierend auf den Geschäftseinheiten und erstellen anschließend eine 

auf Regionen basierende OU-Struktur unterhalb dieser obersten OUs. 

Abbildung 5.15 zeigt, wie ein OU-Entwurf in einer Domäne für ein großes Unternehmen aussehen 

könnte. 

In diesem Beispiel gehören zu den obersten OUs die OU Domain Controllers (in dieser OU befinden 

sich sämtliche Domänencontroller) und eine OU für die Administratoren auf Domänenebene. Weiterhin 

zählt zu den obersten OUs eventuell auch eine OU Service Account für alle Dienstkonten, die in 

der Domäne verwendet werden. Durch Erstellung einer OU oberster Ebene für besondere Benutzerkonten 

wie Dienstkonten wird die Verwaltung dieser Konten vereinfacht. Die obersten OUs können 

auch eine OU Servers umfassen, falls alle Server zentral verwaltet werden. Zusätzlich zu diesen Verwaltungs-OUs 

können weitere OUs der höchsten Ebene auf geografischen Standorten des Unternehmens 

basieren. Die geografischen OUs können hauptsächlich zum Delegieren administrativer Aufgaben 

eingesetzt werden.


NA.Adatum.com 

OU Domänencontroller 

OU Domänenadministratoren 

OU Dienstkonto 

OU Region 

Osten 

OU Region 

Westen 

OU Vertrieb OU Fertigung OU Transportwesen 

OU Konten 


OU Arbeitsstation 

OU Ressourcen 

Beispiel für eine OU-Struktur 

OU Projekte 

Die OUs der zweiten Ebene in jeder geografischen Region basieren auf den Geschäftseinheiten der 

einzelnen Regionen. Die OUs der Geschäftseinheiten können zum Delegieren der Verwaltung, jedoch 

auch zum Zuweisen von Gruppenrichtlinienobjekten verwendet werden. Unter den OUs der 

Geschäftseinheiten befinden sich OUs, die auf den Abteilungen innerhalb der Geschäftseinheiten 

basieren. Auf dieser Ebene dienen die OUs hauptsächlich zum Zuweisen von Gruppenrichtlinienobjekten 

oder zum Zuweisen bestimmter administrativer Aufgaben wie das Recht zum Zurücksetzen 

von Kennwörtern. Die Abteilungs-OUs können mehrere andere OUs enthalten: 

• OU Accounts Diese OU enthält die Benutzer- und Gruppenkonten für die Abteilung. In manchen 

Fällen können die Konten-OUs weiter unterteilt werden in OUs, die Gruppen, Benutzerkonten oder 

Remotebenutzer enthalten. 

• OU Workstations Diese OU enthält alle Benutzerarbeitsstationen und kann separate OUs für 

Windows NT-Arbeitsstationen, Windows 2000-Arbeitsstationen, Microsoft Windows XP 

Professional-Arbeitsstationen und tragbare Computer enthalten. 

• OU Resources Diese OU enthält die mit der OU verknüpften Ressourcen. Hierzu können Objekte 

wie domänenlokale Gruppen, Server, Drucker und freigegebene Ordner gehören. 

• Anwendungs- oder projektbasierte OUs Wenn eine Gruppe von Personen und Ressourcen an einem 

bestimmten Projekt oder mit einer Anwendung arbeiten, das bzw. die eine einheitliche Verwaltung 

verlangt, können Sie für diese Benutzer eine OU-Struktur erstellen und dann die für das Projekt 

erforderlichen Benutzer, Ressourcen und Computer in dieser OU gruppieren.

Entwerfen der Standorttopologie 193 

Hinweis Theoretisch gibt es keine Begrenzung für die Anzahl der Ebenen in Ihrer OU-Struktur. Im Allgemeinen 

empfiehlt es sich jedoch, nicht mehr als zehn Ebenen zu verwenden. Für die meisten Unternehmen 

wird eine OU-Struktur aus vier oder fünf Ebenen völlig ausreichen. 

Stellen Sie beim Erstellen des OU-Entwurfs sicher, dass Sie den Entwurf sorgfältig dokumentieren. 

Dieser Entwurf umfasst ein Diagramm der OU-Struktur, eine Liste aller OUs und den Zweck jeder 

einzelnen OU. Wenn Sie die OU außerdem zum Delegieren administrativer Aufgaben nutzen, 

dokumentieren Sie die Rechte, die auf jeder OU-Ebene delegiert werden. Wenn Sie mit den einzelnen 

OUs verknüpfte Gruppenrichtlinien bereitstellen, dokumentieren Sie die Konfiguration der Gruppenrichtlinien. 

Auf der DVD Sie können die Registerkarte AD Organizational Unit Design im Arbeitsblatt 

ADDS_DesignDocument.xlsx auf der CD zum Dokumentieren des OU-Entwurfs verwenden. 

Entwerfen der Standorttopologie 

Alle bislang behandelten Entwurfsthemen haben sich hauptsächlich mit den logischen Aspekten des 

AD DS-Entwurfs beschäftigt und die eigentliche Netzwerktopologie des Unternehmens weitgehend 

außer Acht gelassen. Bevor Sie einen AD DS-Entwurf anwenden können, müssen Sie sich mit dem 

Aspekt des Standortentwurfs beschäftigen, der direkt durch die Netzwerktopologie beeinflusst wird. 

In Abbildung 5.16 wird der Prozess zum Erstellen eines Standortentwurfs dargestellt. 

Ermitteln der 

Gründe zum Erstellen 

von Standorten 

Ermitteln, welche 

geografischen Standorte einen 

Domänencontroller benötigen 

Erstellen des 

Standortentwurfs 

Erstellen des 

Replikationsentwurfs 

Planen der 

Serverplatzierung 


Erstellen eines Standortentwurfs 

Standorte und der AD DS-Entwurf 

In AD DS sind Standorte spezielle Organisationseinheiten, die zum Verwalten des Netzwerkdatenverkehrs 

verwendet werden. Dies geschieht hauptsächlich auf drei Arten:


• Die Replikation zwischen Standorten wird komprimiert, sodass die Replikation zwischen Standorten 

weniger Bandbreite als die Replikation innerhalb eines Standorts nutzt. Außerdem kann die 

Replikation zeitlich geplant werden, um sicherzustellen, dass sie stattfindet, wenn das Netzwerk 

durch wenige andere Anforderungen beansprucht wird. 

• Der Datenverkehr zur Clientanmeldung verbleibt innerhalb des Standorts, wenn der lokale Domänencontroller 

verfügbar ist. 

• AD DS-fähige Anwendungen wie DFS (Distributed File System) und Exchange Server 2007 können 

mithilfe von Standorten den Datenverkehr des Clientzugriffs begrenzen oder das Messagerouting 

basierend auf der Standortkonfiguration verwalten. 

Erstellen eines Standortentwurfs 

Da der Standortentwurf stark von der Netzwerkinfrastruktur abhängt, besteht der erste Schritt zum 

Erstellen eines Standortentwurfs in der Dokumentation dieser Infrastruktur. Nachdem Sie Informationen 

über Ihr Unternehmensnetzwerk gesammelt haben, können Sie mit dem Erstellen der Standorte 

beginnen. Untersuchen Sie zunächst jeden physischen Standort, an dem die Computer über eine 

schnelle Netzwerkverbindung verbunden sind. Wie viele Benutzer befinden sich an diesem Standort? 

Gibt es so viele Benutzer an dem Standort, dass dort ein Domänencontroller erforderlich ist? Welche 

Netzwerkverbindungen bestehen von diesem Standort zu anderen Standorten des Unternehmens? 

Hinweis Die Definition einer schnellen Netzwerkverbindung variiert abhängig von Faktoren wie der Anzahl 

von Benutzern am jeweiligen Standort, der Gesamtzahl an Objekten in der Domäne und der Anzahl an 

Domänen in der Gesamtstruktur. Außerdem müssen Sie feststellen, wie viel von der gesamten Bandbreite 

für die Replikation zur Verfügung steht. In den meisten Fällen sollten die Netzwerkverbindungen innerhalb 

eines Standorts mindestens 512 KBit/s Bandbreite zur Verfügung haben; in einem großen Unternehmen sollten 

Sie mindestens 10 MBit/s als Mindestnetzwerkverbindung innerhalb eines Standorts in Erwägung ziehen. 

Wenn der Grund für die Erstellung eines Standorts darin besteht, Benutzern die Anmeldung an AD 

DS zu ermöglichen, sollte jeder Standort einen Domänencontroller und die meisten Standorte auch 

einen globalen Katalogserver besitzen. Wenn Sie daher entscheiden möchten, ob ein logischer Standort 

für einen Unternehmensstandort mit einer kleinen Benutzeranzahl und einer langsamen Netzwerkverbindung 

mit anderen Unternehmensstandorten erstellt werden soll, lautet die Frage eigentlich, ob 

Sie an diesem Standort einen Domänencontroller vorsehen sollen. Eine Möglichkeit, diese Frage zu 

beantworten, liegt darin festzustellen, welche Option den geringsten Netzwerkdatenverkehr über die 

Netzwerkverknüpfung verursacht. Wodurch wird mehr Datenverkehr erzeugt: durch Clients, die sich 

an einem Domänencontroller an einem anderen Unternehmensstandort anmelden, oder durch den 

Replikationsdatenverkehr zwischen den Domänencontrollern? 

Außer, dass Sie ermitteln müssen, welche Option mehr Netzwerkdatenverkehr verursacht, müssen Sie 

auch andere Faktoren in Betracht ziehen. Wenn Sie keinen Domänencontroller am Standort aufstellen, 

müssen Sie die Arbeitsunterbrechung für die Benutzer berücksichtigen, falls die Netzwerkverbindung 

ausfällt und sie sich nicht an der Domäne anmelden können. Außerdem sollten Sie abwägen, ob 

ein Server aus anderen Gründen am Standort notwendig ist. Wenn Sie ohnehin einen Server unter 

Windows Server 2008 am Standort einsetzen, könnte er auch als Domänencontroller für den Standort 

dienen?


Einer der wichtigsten Faktoren für die Entscheidung, ob ein Domänencontroller an einem Unternehmensstandort 

aufgestellt wird, ist die physische Sicherheit des Domänencontrollers. Wenn die physische 

Sicherheit des Domänencontrollers nicht gewährleistet werden kann, sollten Sie keinen 

beschreibbaren Domänencontroller am Standort aufstellen. Der Einsatz eines RODC kann einige dieser 

Sicherheitsbedenken verringern, Sie sollten jedoch dennoch alles daran setzen, dass auch RODCs 

physisch abgesichert sind. 

Hinweis Beim Erstellen eines AD DS-Entwurfs für ein Unternehmen gilt die allgemeine Regel, alles so einfach 

wie möglich zu halten, für alles – nur nicht für Standorte. Bei der Planung der Gesamtstruktur, Domäne 

oder OU-Struktur sollte Einfachheit eines Ihrer obersten Gebote sein. Die Erstellung zusätzlicher Standorte 

für alle Unternehmensstandorte, die über langsame Netzwerkverbindungen miteinander verbunden sind, 

bietet jedoch erhebliche Vorteile, ohne den Verwaltungsaufwand wesentlich zu erhöhen. Dies ist wohl der 

einzige Punkt im AD DS-Entwurfsvorgang, an dem die einfachste Lösung nicht die beste Lösung ist. 

Nachdem Sie festgelegt haben, wie viele AD DS-Standorte benötigt werden, erstellen Sie im nächsten 

Schritt den Entwurf für die einzelnen Standorte. Jeder Standort in AD DS ist mit einem oder mehreren 

IP-Subnetzen verknüpft. Während Sie den Entwurf für die einzelnen Standorte erstellen, sollten 

Sie daher festlegen, welche Subnetze in jeden Standort einbezogen werden. Wenn Sie entscheiden, 

dass an einem Unternehmensstandort kein Domänencontroller eingesetzt wird, müssen Sie festlegen, 

zu welchem logischen Standort dieser Unternehmensstandort gehört, und dieses IP-Subnetz dem entsprechenden 

Standort hinzufügen. Auf diese Weise wird sichergestellt, dass die Clients am Remotestandort 

sich mit den nächstgelegenen Domänencontrollern verbinden. 

Praxistipp: Subnetzdefinitionen in Active Directory 

Subnetze werden in Active Directory ausschließlich zum Definieren der Standorte in Active Directory 

verwendet, denen eine Reihe von Computern angehört. Die Subnetzdefinitionen entsprechen 

nicht dem tatsächlichen Layer-3-Routing innerhalb des Unternehmens. Hierbei handelt es sich um ein 

häufiges Missverständnis – der Aufbau des Layer-3-Routings muss nicht mit den Subnetz-/Standortdefinitionen 

in Active Directory übereinstimmen. Zweitens wählt Active Directory das spezifischere 

Subnetz. Das heißt, wenn Sie zwei Subnetzobjekte in Active Directory definiert haben – 

10.1.0.0/16 und 10.1.2.0/24 – und einen Client mit der IP-Adresse 10.1.2.5, so wird das zweite 

Subnetzobjekt verwendet. 

Eines der gängigen Ereignisse, die das Ereignisprotokoll auf Domänencontrollern in großen Unternehmen 

füllen, ist die NetLogon-Warnung Nr. 5807. Diese tritt in einigen Szenarios auf. In einem 

Szenario haben die Active Directory-Administratoren einfach keine Subnetze für ihre Standortobjekte 

definiert. Im zweiten Beispiel – das gängigere Szenario – kommuniziert das Team, das Active 

Directory ausführt, nicht gut genug mit den Netzwerkadministratoren, die Subnetze im Netzwerk 

bereitstellen. In großen Unternehmen ändert sich die Subnetzkonfiguration möglicherweise häufig, 

und die Active Directory-Standortspezifikationen werden eventuell nicht beibehalten. Die Lösung, 

die ich verwende und empfehle, besteht darin, sehr weit reichende Übernetzwerke an den Hubstandorten 

zu definieren. Beispielsweise würde ich in einem Hub-and-Spokes-Netzwerkentwurf mit 

einem Hub, der private IP-Adressen im Bereich 10.0.0.0/8 verwendet, den Wert 10.0.0.0/8 mit dem 

Hubstandort verknüpfen. Auf diese Weise ist garantiert, dass jeder Client, der von einer beliebigen 

10.0.0.0-IP-Adresse kommt, dem Subnetz in Active Directory entspricht. 

Sie können dieses Prinzip auch auf Unternehmen mit mehreren Hubstandorten anwenden. In 

Abbildung 5.17 wird ein Beispiel dargestellt.


Montevideo 

10.3.3.0/24 

Rio de Janiero 

10.3.4.0/24 

Chicago 

10.1.2.0/24 

Milwaukee 

10.1.3.0/24 

Sao Paolo 

10.3.2.0/24 

Springfield 

10.1.4.0/24 

Manchester 

10.2.3.0/24 

London 

10.2.2.0/24 

Birmingham 

10.2.4.0/24 

Abbildung 5.17 Sie können den Hubstandorten und den Spokestandorten Subnetzoptionen mit anderen 

Subnetzmasken zuweisen. 

In diesem Szenario ist es einfach, die 10.x.x.0-Subnetze mit den Spokestandorten zu verknüpfen 

und die 10.x.x.0/16-Subnetze anschließend mit den Hubstandorten zu verknüpfen. Beispielsweise 

würde ich in Active Directory-Standorte und -Dienste ein Subnetz für das Subnetz 10.3.0.0/16 

erstellen und es São Paolo zuweisen. Anschließend würde ich separate Subnetzobjekte für Montevideo 

und Rio de Janeiro anhand der Subnetze 10.3.x.0/24 konfigurieren. Der Vorteil dieses 

Ansatzes liegt darin, dass die Clients im Standort den nächsten Hubstandort zum Auffinden eines 

Domänencontrollers verwenden, wenn die IP-Adresssubnetze in Montevideo oder Rio de Janeiro 

geändert werden oder wenn eine zusätzliche Niederlassung erstellt und mit dem Hubstandort verknüpft 

wird. 

Eine weitere interessante Option, die bei der Konfiguration von Subnetzen in Active Directory 

angewendet werden kann, besteht darin, definierte Hostsubnetze zu verwenden, indem Sie Subnetze 

anhand von /32- oder 255.255.255.255-Subnetzmasken konfigurieren. Mithilfe dieser Option 

können Sie einen Standort innerhalb eines Standorts aufbauen. Zum Beispiel möchte ein Unternehmen 

einen dedizierten Standort für seine Exchange-Umgebung erstellen, jedoch kein dediziertes 

Subnetz für die Exchange-Server und verknüpften Domänencontroller bereitstellen. Durch Erstellen 

von Hostsubnetzen und Gruppieren der Subnetze in einem einzigen Standort können Sie die 

Server mit einem gemeinsamen Standort verknüpfen. 

Brian Desmond 

Microsoft MVP, Directory Services 

www.briandesmond.com


Erstellen eines Replikationsentwurfs 

Nachdem Sie die Standorte erstellt haben, besteht der nächste Schritt darin, die Replikationstopologie 

für die Standorte zu erstellen. Entwerfen Sie hierzu Standortverknüpfungen zwischen Unternehmensstandorten. 

Planen Sie für jede Standortverknüpfung den Zeitplan und das Replikationsintervall sowie 

die Standortverknüpfungskosten. Wenn Sie für jeden Standort Bridgeheadserver für die Replikation 

festlegen möchten, geben Sie alle AD DS-Partitionen an, die im Standort enthalten sein werden, und 

definieren Sie für jede Partition einen Bridgeheadserver. 

Die Berechnung der Kosten für die einzelnen Standortverknüpfungen kann kompliziert werden, vor 

allem dann, wenn zwischen den Unternehmensstandorten mehrere Routen möglich sind. Gibt es mehrere 

Routen, müssen Sie die Kosten für die Standortverknüpfungen so zuweisen, dass die optimale 

Route für die AD DS-Replikation verwendet wird. Eine Möglichkeit festzustellen, welche Kosten den 

einzelnen Standortverknüpfungen zuzuweisen sind, besteht darin, eine Tabelle zu erstellen, in der die 

Netzwerkbandbreite mit den Standortverknüpfungskosten verbunden wird. Ein Beispiel wird in 

Tabelle 5.3 dargestellt. 

Tabelle 5.3 

Verknüpfen der Netzwerkbandbreite mit den Standortverknüpfungskosten 

Verfügbare Bandbreite 

Standortverknüpfungskosten 

Größer oder gleich 10 MBit/s 10 

10 MBit/s bis 1,544 MBit/s 100 

1,544 MBit/s bis 512 KBit/s 200 

512 KBit/s bis 128 KBit/s 400 

128 KBit/s bis 56 KBit/s 800 

Weniger als 56 KBit/s 2000 

Anhand der in dieser Tabelle enthaltenen Informationen können Sie jeder Standortverknüpfung entsprechende 

Kosten zuweisen. Berechnen Sie anschließend, über welche Route der Replikationsdatenverkehr 

im Netzwerk verläuft, wenn alle Verknüpfungen verfügbar sind. Berechnen Sie außerdem die 

Auswirkungen eines Ausfalls einer Netzwerkverknüpfung. Wenn es innerhalb des Netzwerks redundante 

Pfade gibt, stellen Sie sicher, dass die Standortverknüpfungskosten so konfiguriert sind, dass 

der optimale Sicherungspfad im Falle eines Verknüpfungsausfalls gewählt wird. 

Praxistipp: Festlegen von Active Directory-Standortverknüpfungskosten 

Es gibt wenige Dinge, die Sie beim Einrichten der Standortverknüpfungen wirklich beachten müssen. 

Von diesen können die Kosten, die Sie den Standortverknüpfungen zuweisen, am wichtigsten 

sein – oder auch völlig irrelevant. Die Kosten der Verknüpfung werden beim Berechnen der einbezogenen 

Struktur genutzt, bei der mehrere Netzwerkverbindungen mit einem Standort bestehen. 

Wenn von einem Hub eine Reihe von Spokes ausgehen, die jeweils nur eine einzige Verknüpfung 

wieder zurück zum Hub besitzen, spielen die Kosten beim Errechnen der Routingtopologie überhaupt 

keine Rolle. Wenn jedoch von einem Standort zum anderen mehrere Pfade verlaufen, werden 

die Kosten von der Konsistenzprüfung (KCC) zum Erstellen der Routingtopologie verwendet. 

Um einer Standortverknüpfung Kosten zuzuweisen, verwende ich gerne eine Formel, welche der 

Geschwindigkeit des zugrunde liegenden Transports einem numerischen Wert zuordnet, der 

anschließend den Standortverknüpfungskosten zugewiesen werden kann.


Diese Formel lautet folgendermaßen: 

Referenzbandbreite 

Verknüpfungsbandbreite 

Die Referenzbandbreite ist die maximale Bandbreite mit einem Kostenwert von 1, und die Verknüpfungsbandbreite 

ist die Geschwindigkeit des zugrunde liegenden Transports. Wenn Sie beispielsweise 

eine OC768-Verbindung mit ganzen 38,4 GBit/s verwenden, erhält diese einen Kostenwert 

von 1. Wenn ein anderer Standort Ihres Unternehmens über eine T1-Verbindung (1536 KBit/s) 

verbunden ist, sollte der Standortverknüpfung zu diesem Standort Kosten von 158 zugewiesen werden. 

Die Zuweisung von Kosten zu den Standortverknüpfungen zwischen den verbundenen Standorten 

basierend auf dem zugrunde liegenden Transport erfordert, dass Sie eng mit Ihrer WAN-Gruppe 

zusammenarbeiten, um über alle Verbindungen informiert zu sein und benachrichtigt zu werden, 

wenn eine Verbindung geändert wird. Außerdem müssen Sie die für die Verbindung verfügbare 

Bandbreite beim Zuweisen der Standortverknüpfungskosten berücksichtigen. Beispielsweise haben 

Sie eine WAN-Verbindung mit hoher Bandbreite, die über einen Großteil des Tages völlig ausgelastet 

ist, und eine andere, langsamere, WAN-Verbindung, die nicht viel genutzt wird. Um sicherzustellen, 

dass der Replikationsdatenverkehr über die weniger ausgelastete WAN-Verbindung gesendet 

wird, müssen Sie möglicherweise die Kosten für die überlastete Verknüpfung erhöhen. 

Außerdem müssen Sie vielleicht die Kosten der Standortverknüpfungen ändern, wenn WAN-Verknüpfungen 

verwendet werden, die je nach Anzahl der übertragenen Bytes Geld kosten. 

Brian Desmond 

Microsoft MVP – Directory Services 

www.briandesmond.com 

Eine weitere Option zum Verwalten der AD DS-Replikation ist das Deaktivieren von Standortverknüpfungsbrücken. 

Standardmäßig sind Standortverknüpfungsbrücken aktiviert, was zur Folge hat, 

dass alle Standortverknüpfungen transitiv sind. Das heißt: Wenn Standort A eine Standortverknüpfung 

mit Standort B besitzt und Standort B eine Standortverknüpfung mit Standort C, dann kann 

Standort A direkt auf Standort C replizieren. In den meisten Fällen ist dieses Verhalten erwünscht. Es 

gibt jedoch Ausnahmefälle, in denen Sie die Standortverknüpfungsbrücken deaktivieren sollten. Zum 

Beispiel besitzt ein Unternehmen mehrere Hubstandorte auf der ganzen Welt und mehrere kleinere 

Niederlassungen, die sich über langsame oder mittelschnelle Netzwerkverbindungen mit den Hubstandorten 

verbinden. (Siehe Abbildung 5.18.) Wenn die Hubstandorte über schnelle Netzwerkverbindungen 

verbunden sind, sind automatische Standortverknüpfungsbrücken akzeptabel. Wenn die Netzwerkverbindungen 

zwischen den Hubstandorten jedoch relativ langsam sind oder der Großteil der 

Bandbreite für andere Anwendungen beansprucht wird, sind transitive Verbindungen möglicherweise 

nicht erstrebenswert. 

In Abbildung 5.18 besitzt die Netzwerkverbindung zwischen Hub A und Hub B möglicherweise eine 

begrenzt verfügbare Bandbreite. Wenn die standardmäßig eingestellten Standortverknüpfungsbrücken 

nicht geändert werden, repliziert der Bridgeheadserver in Hub A mit dem Bridgeheadserver in Hub B, 

jedoch auch mit den Bridgeheadservern in anderen mit Hub B verbundenen Standorten. Das heißt, 

dass derselbe Replikationsdatenverkehr die Netzwerkverbindung möglicherweise fünfmal durchläuft.


Um dies zu ändern, können Sie Standortverknüpfungsbrücken deaktivieren und anschließend manuelle 

Standortverknüpfungsbrücken für alle Standortverknüpfungen zwischen den Hubstandorten und 

den kleineren Standorten erstellen, die sich mit den Hubstandorten verbinden. Nachdem Sie diese 

Konfiguration vorgenommen haben, verläuft die gesamte Replikation von Hub A nach Hub B und 

wird anschließend an alle mit Hub B verbundenen Standorte verteilt. 

Standort B2 

Standort B3 

Standort B1 

Standort B4 

Standort A1 

Hub B 

Standort A2 

Hub A 

Standort A3 

Hub C 

Standort C2 

Standort C1 


Konfigurieren von Standortverknüpfungsbrücken 

Auf der DVD Auf der Registerkarte Site Design Decisions im Arbeitsblatt ADDS_DesignDocument.xlsx auf 

der CD können Sie Ihre Entscheidungen zum Standortentwurf, und auf den Registerkarten AD Site Design 

und AD Site Link Design Ihren endgültigen Standortentwurf dokumentieren. 

Exchange Server 2007 und der Standortentwurf 

Einer der Faktoren, die Sie beim Erstellen des Standortentwurfs berücksichtigen müssen, ist, ob Ihr 

Unternehmen Exchange Server einsetzt und insbesondere, ob Ihr Unternehmen Exchange Server 

2007 verwendet oder einzusetzen plant. 

Exchange 2000 oder höher und Messagingclients wie Outlook XP oder höher sind von der AD DS- 

Standortkonfiguration und vom Domänencontroller und den globalen Katalogservern abhängig, die 

in den Standorten bereitgestellt werden. Wenn Exchange Server-Dienste gestartet werden, verwendet 

der Server DNS, um einen Domänencontroller im Exchange Server-Standort zu finden und die 

Exchange Server-Konfiguration aus AD DS auszulesen. Wenn der Exchange-Server Nachrichten 

zwischen Empfängern routet, fragt er die Empfängereigenschaften vom globalen Katalog ab und 

fordert Informationen über das Routen von Nachrichten an die Empfänger von einem Domänencontroller 

an. Wenn ein Outlook-Client auf die globale Adressliste zugreift, wird er vom Exchange- 

Server an einen globalen Katalogserver umgeleitet, um eine Liste aller E-Mail-Benutzer im Unternehmen 

abzurufen. Damit Exchange-Server und Messageclients schnell reagieren, ist eine schnelle 

Netzwerkverbindung mit Domänencontrollern und globalen Katalogservern erforderlich.


Exchange Server 2007 führt mehrere neue Abhängigkeiten von AD DS-Standorten ein. In 

Exchange Server 2007 müssen alle Nachrichten über einen Exchange-Server geleitet werden, der 

die Hubtransport-Serverrolle ausübt. Wird eine Nachricht an den Server übermittelt, fragt der Server 

Informationen über die Lieferadresse der Nachricht von Active Directory ab. Wenn sich das 

Postfach des Empfängers auf einem Postfachserver in demselben AD DS-Standort befindet, in dem 

auch der Hubtransportserver zu finden ist, wird die Nachricht direkt an das entsprechende Postfach 

geliefert. Befindet sich das Postfach des Empfängers auf einem Postfachserver in einem anderen 

AD DS-Standort, wird die Nachricht an einen Hubtransportserver im jeweiligen Standort weitergeleitet, 

der sie anschließend an den Postfachserver ausliefert. Wenn die Nachricht für einen Empfänger 

außerhalb des Unternehmens bestimmt ist, wird sie an einen Exchange-Server in einem AD 

DS-Standort mit Internetverbindung geleitet. Wenn zwischen den AD DS-Standorten mehrere Routen 

verfügbar sind, ermittelt der Hubtransportserver anhand der Standortverknüpfungskosten die 

effizienteste Route zwischen den Standorten. Mit anderen Worten, das Messagerouting in 

Exchange Server 2007 ist abhängig vom AD DS-Standortentwurf. 

Der Zugriff der Clients auf die Postfächer hängt ebenfalls vom Standortentwurf ab. Wenn Benutzer 

anstelle von Outlook einen anderen Messagingclient als MAPI-Client (Messaging API) für das Herstellen 

einer Verbindung mit dem Postfach konfiguriert haben, müssen sie sich mit einem Exchange- 

Server verbinden, der die Serverrolle ClientAccess ausführt. Die Serverrolle ClientAccess verwendet 

AD DS-Standortinformationen, um einen effizienten Zugriff auf Benutzerpostfächer bereitzustellen. 

Erhält die Serverrolle ClientAccess eine Benutzerverbindungsanforderung, werden die AD DS 

abgefragt, um festzustellen, welcher Postfachserver das Postfach des Benutzers und die Standortmitgliedschaft 

des Servers hostet. Wenn der ClientAccess-Server, der die anfängliche Benutzerverbindung 

erhalten hat, sich nicht in demselben Standort befindet wie der Postfachserver des Benutzers, 

wird die Verbindung direkt oder über einen Proxy an einen ClientAccess-Server im Standort 

des Postfachservers umgeleitet. 

Aufgrund dieser engen Integration zwischen Exchange Server 2007 und den AD DS-Standorten 

sollten Sie den Exchange Server-Entwurf und den AD DS-Standortentwurf gleichzeitig ausarbeiten. 

Berücksichtigen Sie beim Entwerfen der AD DS-Standorte für die Unterstützung von 

Exchange Server 2007 folgende Aspekte: 

• Wenn Sie Exchange Server 2007 an einem beliebigen Unternehmensstandort verwenden, stellen 

Sie immer einen Domänencontroller und einen globalen Katalogserver im selben Standort 

bereit. Ziehen Sie außerdem bei der Planung der Hardwareanforderungen für den Domänencontroller 

und den globalen Katalogserver die zusätzliche Belastung in Betracht, der der Server 

durch die Exchange-Server und Messagingclients ausgesetzt ist. 

• Erwägen Sie eine Bereitstellung aller Exchange-Server in einem zentralen Standort. Sie müssen 

nicht in jedem AD DS-Standort Exchange-Server bereitstellen. Wenn alle Standorte Ihres 

Unternehmens über zuverlässige Netzwerkverbindungen mit hoher Bandbreite verbunden sind, 

unabhängig von der Entfernung zwischen den Niederlassungen, sollten Sie die Implementierung 

eines zentralen Messagingsystems in Betracht ziehen, in dem alle Exchange-Server an 

einem zentralen Standort aufgestellt sind. Da alle Exchange-Server und andere erforderlichen 

Dienste wie Domänencontroller und DNS-Server sich in demselben schnellen Netzwerk befinden, 

erzielen Sie mit diesem Entwurf die beste Exchange Server-Leistung. Wenn die Anforderungen 

an die Erfahrung der Benutzer und an die Verfügbarkeit jedoch durch die Verbindung 

mit einem zentralen Standort nicht erfüllt werden können, haben Sie keine andere Wahl, als die 

Server in den Remotestandorten zu platzieren.


• Erwägen Sie die Erstellung eines dedizierten AD DS-Standorts für Exchange-Server. Wenn Sie 

für Ihre Exchange-Server einen zentralen Entwurf verwenden oder mehrere Exchange-Server in 

einem Datacenter bereitstellen, ziehen Sie die Erstellung eines dedizierten AD DS-Standorts in 

Betracht. Dieser enthält alle Exchange-Server im Unternehmenstandort sowie Domänencontroller 

und globale Katalogserver, die dediziert für die Bereitstellung von Verzeichnisdiensten für 

die Exchange-Server eingesetzt werden. Dieser Entwurf ermöglicht eine vorhersehbarere 

Exchange Server-Leistung, da die Domänencontroller nicht von anderen Clients zur Authentifizierung 

oder für Verzeichnissuchen verwendet werden. 

Zusätzliche Informationen zu AD DS-Entwürfen, die den Anforderungen von Exchange Server 

2007 entsprechen, finden Sie unter „Guidance on Active Directory Design for Exchange Server 

2007“ unter der Adresse http://msexchangeteam.com/archive/2007/03/28/437313.aspx, unter 

„Dedicated Active Directory Sites for Exchange“ unter der Adresse http://msexchangeteam.com/ 

archive/2006/08/28/428776.aspx und unter „Planen von Active Directory“ unter der Adresse http:// 

technet.microsoft.com/de-de/library/bb123715.aspx. 

Entwerfen von Serverstandorten 

Im Zuge des Standortentwurfs müssen Sie außerdem festlegen, wo DNS-Server, Domänencontroller, 

globale Katalogserver, RODCs und Betriebsmaster aufgestellt werden. In den meisten Fällen ist die 

Platzierung der Server nicht weiter kompliziert, nachdem Sie den Standortentwurf abgeschlossen 

haben. 

Lokalisieren von DNS-Servern 

Sie wissen bereits, dass DNS in Windows Server 2008 AD DS ein wichtiger Dienst ist. Ohne DNS 

können Clients keine AD DS-Domänencontroller finden, und Domänencontroller können sich gegenseitig 

ebenfalls nicht zur Replikation zusammenfinden. Das bedeutet, dass DNS an jedem Standort 

Ihres Unternehmens bereitgestellt werden sollte, vielleicht mit Ausnahme sehr kleiner Niederlassungen 

mit nur wenigen Benutzern. 

Generell sollten Sie mindestens einen DNS-Server in jedem Standort mit Domänencontroller bereitstellen. 

Es wird dringend empfohlen, AD DS-integrierte Zonen zu verwenden und DNS auf dem 

Domänencontroller bereitzustellen. Für kleine Niederlassungen, in denen Sie einen Domänencontroller 

aufstellen möchten, sollten Sie die Bereitstellung eines RODC mit installiertem DNS in Betracht 

ziehen. 

Standortentwurf für Zweigniederlassungen 

Ein besonderer Fall für den Standortentwurf liegt vor, wenn ein Unternehmen Hunderte kleiner 

Standorte mit Domänencontrollern an jedem Standort besitzt. Dieses Szenario verkompliziert AD 

DS-Entwurf und -Bereitstellung in mehrerlei Hinsicht. Ein Beispiel ist der Zeitraum, den die Konsistenzprüfung 

(Knowledge Consistency Checker, KCC) zum Berechnen der Replikationstopologie 

benötigt. Mit jedem zusätzlichen Standort dauert die Berechnung der Routingtopologie länger. 

Während die KCC auf einem Domänencontroller ausgeführt wird, kann sie die CPU-Zeit auf dem 

Server zu 100 Prozent beanspruchen. Bei einer großen Anzahl an Standorten kann der Domänencontroller 

in der zentralen Niederlassung den ISTG (Inter-Site Topology Generator) dauerhaft mit 

hundertprozentiger CPU-Auslastung ausführen und dennoch nicht in der Lage sein, die Berechnung 

abzuschließen.


Ein weiterer komplizierter Aspekt steht im Zusammenhang mit dem Replikationsfenster. Wenn der 

Standortconnector mit einem Zeitplan konfiguriert wurde, der die Replikation für nur sechs Stunden 

jede Nacht vorsieht, werden Sie vielleicht feststellen, dass Sie mehrere Bridgeheadserver 

bereitstellen müssen, damit die Replikation auf sämtliche Remotestandorte jede Nacht abgeschlossen 

wird. Selbst das Einrichten von Domänencontrollern für jeden Standort ist in diesem Szenario 

kompliziert. Wenn die Netzwerkverbindung sehr langsam ist und Sie einfach einen Domänencontroller 

im Standort installieren und das Verzeichnis anschließend durch Replikation füllen, kann die 

erste Replikation für ein großes Verzeichnis mehrere Stunden dauern. 

Windows Server 2003 und Windows Server 2008 bieten mehrere erhebliche Verbesserungen, die 

die Bereitstellung von AD DS in diesem Szenario einfacher gestalten, als dies in Windows 2000 

der Fall war. Verbesserungen an dem vom ISTG-Prozess verwendeten Berechnungsalgorithmus 

verringern den Zeitraum für die Berechnung der standortübergreifenden Replikationstopologie 

beträchtlich. Die Option zum Erstellen eines Domänencontrollers und zum Befüllen von AD DS 

über Sicherungsmedien hat zur Folge, dass die Erstellung eines Domänencontrollers in einer 

Remoteniederlassung nicht so viel Replikationsdatenverkehr erzeugt. 

Trotz dieser Verbesserungen sind der Entwurf und die Bereitstellung von AD DS-Standorten in 

Unternehmen mit Hunderten von Standorten noch immer ein Sonderfall. Wenn Sie sich mit dieser 

Art von Umgebung beschäftigen, ist die beste verfügbare Referenz der Windows Server 2003 

Active Directory Branch Office Guide, der zum Download unter http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en 

verfügbar 

ist. Auch wenn dieses Handbuch für die Windows Server 2003-Umgebung verfasst wurde, 

gelten viele der vorgestellten Konzepte auch für Windows Server 2008. 

So funktioniert es: KCC-Verbesserungen unter Windows Server 2008 

Windows Server 2008 enthält Verbesserungen an der Konsistenzprüfung (Knowledge Consistency 

Checker, KCC) für RODCs. Diese unterstützen Sie beim automatischen Ausgleich der Replikationsarbeitslast 

auf Domänencontrollern in einem Datacenter, mit dessen Standort mehrere RODC- 

Standorte verbunden sind. 

Ein typisches Bereitstellungsszenario für RODCs ist die Zweigstellenniederlassung. Die in diesem 

Szenario am häufigsten bereitgestellte Active Directory-Replikationstopologie basiert auf einem 

Hub-and-Spokes-Entwurf, in dem Zweigniederlassungsdomänencontroller in mehreren Standorten 

mit einer kleinen Anzahl an Bridgeheadservern in einem Hubstandort replizieren. 

Eine durch die Hub-and-Spokes-Topologie in vorherigen Windows Server-Betriebssystemen 

herausgestellte administrative Herausforderung besteht darin, dass es nach dem Hinzufügen eines 

neuen Bridgeheaddomänencontrollers im Hub keinen automatischen Mechanismus zum Neuverteilen 

der Replikationsverbindungen zwischen den Zweigniederlassungsdomänencontrollern und den 

Hubdomänencontrollern gibt, um den neuen Hubdomänencontroller zu nutzen. 

Unter Windows Server 2008 stellt die normale Konsistenzprüfung (Knowledge Consistency 

Checker, KCC) ein gewisses Maß an Neuverteilung. Wenn die KCC auf einem RODC einen neuen 

Kandidaten für einen Bridgeheadserver erkennt, der für die Replikation verwendet werden kann, 

legt sie fest, ob sie diesen neuen Bridgehead als Replikationspartner verwendet. Die Entscheidung 

basiert auf einem Algorithmus, der einen Lastenausgleich nach dem Wahrscheinlichkeitsprinzip 

bereitstellt.


Beispielsweise kann ein Hubstandort vier Bridgeheadserver und 100 RODCs enthalten, die eine 

eingehende Replikation von den vier Bridgeheadservern durchführen – ein Verhältnis von 25:1. 

Wenn dem Hubstandort ein weiterer Bridgehead hinzugefügt wird, erkennt jeder RODC den neuen 

Bridgeheadserver, wenn er die Konfigurationspartition von einem Bridgeheadserver repliziert. 

Beim nächsten Ausführen der KCC legt der RODC fest, ob die Replikationsverbindung auf den 

neuen Bridgeheadserver umgelegt werden soll. In diesem Beispiel gibt es eine Chance von 1:5 

(eine Wahrscheinlichkeit von 20 Prozent), dass ein RODC seine Replikationsverbindung ändert. 

Nachdem alle 100 RODCs diesen Vorgang abgeschlossen haben, werden etwa 20 von ihnen die 

Replikation vom neuen Bridgeheadserver durchführen. 

Diese neue Funktionalität ist standardmäßig aktiviert. Sie können sie deaktivieren, indem Sie auf 

dem RODC die folgende Registrierungsschlüsseleinstellung hinzufügen: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 

“Random BH Loadbalancing Allowed” 

1 = Enabled (default), 0 = Disabled 

Rob Lane 

Microsoft Escalation Engineer IV 

Platzieren von Domänencontrollern 

In den meisten Fällen sollte ein Domänencontroller sich an Unternehmensstandorten mit einer großen 

Anzahl an Benutzern befinden. Es gibt mindestens zwei Gründe dafür, einen Domänencontroller an 

einem bestimmten geografischen Standort aufzustellen. Erstens können sich die Benutzer nach wie 

vor am Netzwerk anmelden, wenn das Netzwerk ausfällt. Zweitens stellt die Platzierung eines Domänencontrollers 

in einer Niederlassung sicher, dass der Datenverkehr für die Clientanmeldung nicht die 

WAN-Verbindung zu einem anderen Standort durchläuft. Wenn Ihre Geschäftsanforderungen besagen, 

dass Benutzer sich auch im Fall eines Netzwerk- oder Serverausfalls anmelden können müssen, 

sollten Sie an jedem Standort zwei Domänencontroller aufstellen. In einer kleinen Zweigniederlassung 

können Sie einen einzigen Domänencontroller verwenden, um die Gesamtzahl an Domänencontrollern 

zu begrenzen. Wenn Sie an einem Unternehmensstandort einen Domänencontroller bereitstellen, 

sollten Sie auch einen logischen Standort für den geografischen Standort erstellen, sodass der 

gesamte Anmeldedatenverkehr innerhalb des Standorts verbleibt. 

Es gibt zwei Gründe, warum Sie sich gegen das Aufstellen eines Domänencontrollers in einem einzelnen 

Standort entscheiden könnten. Wenn der Replikationsdatenverkehr zum Domänencontroller am 

Standort höher wäre als der Datenverkehr für die Clientanmeldung, könnten Sie den Domänencontrollerstandort 

einfach so einrichten, dass die Clients versuchen können, einen Domänencontroller in 

einem angrenzenden Standort für die Anmeldung zu verwenden. Auch wenn die Server physisch nicht 

abgesichert werden können, sollten Sie am Standort keinen beschreibbaren Domänencontroller aufstellen. 

Wenn Sie sich tatsächlich entschließen, in einem Standort keinen Domänencontroller bereitzustellen, 

können Sie dennoch steuern, an welchen Domänencontrollern sich die Clients anmelden. Eine Option 

besteht darin, einen logischen Standort für den Zweigniederlassungsstandort zu konfigurieren und alle 

IP-Subnetze für die Niederlassung in den Standort aufzunehmen. Anschließend können Sie eine 

Standortverknüpfung zu einem oder mehreren vorhandenen Standorten konfigurieren.


Durch die automatische Standortabdeckung wählen die AD DS die Domänencontroller in dem Standort 

aus, der über die günstigste Standortverknüpfung verbunden ist, um den Standort ohne Domänencontroller 

abzudecken. Eine zweite Methode zum Festlegen des Domänencontrollers, der für die 

Authentifizierung der Benutzer verwendet wird, besteht darin, IP-Subnetzobjekte für die Niederlassung 

ohne Domänencontroller zu erstellen und das IP-Subnetzobjekt anschließend einem vorhandenen 

Standort hinzuzufügen. 

Ein weiterer Aspekt, den Sie bei Bereitstellung mehrerer Domänen einplanen müssen, sind die Standorte 

der Gesamtstruktur-Stammdomänencontroller. Diese Domänencontroller sind erforderlich, wenn 

ein Benutzer auf eine Ressource in einer anderen Domänenstruktur zugreift oder wenn ein Benutzer 

sich an einer Domäne in einer anderen als der eigenen Domänenstruktur anmeldet. Aus diesem Grund 

sollten Sie Gesamtstruktur-Stammdomänencontroller in allen Niederlassungen aufstellen, in denen 

eine große Anzahl von Benutzern arbeitet oder in denen eine erhebliche Menge an Datenverkehr an 

die Stammdomänencontroller geleitet wird. Wenn in der Netzwerktopologie Ihres Unternehmens 

regionale Hubniederlassungen enthalten sind, sollten Sie die Bereitstellung eines Stammdomänencontrollers 

in jeder der Hubniederlassungen erwägen. 

Achtung Aufgrund der Bedeutung der Stammdomäne und der Auswirkungen auf die Gesamtstruktur, 

wenn die Stammdomäne jemals verloren gehen sollte, sollten die Gesamtstruktur-Stammdomänencontroller 

geografisch verteilt werden. Auch wenn es keinen ersichtlichen Grund für das Aufstellen eines Stammdomänencontrollers 

in Niederlassungen außerhalb des Hauptsitzes gibt, empfiehlt es sich dennoch, allein um 

geografische Redundanz zu gewährleisten. Wie alle Domänencontroller sollten jedoch auch die Stammdomänencontroller 

niemals in einer Niederlassung platziert werden, in der sie nicht physisch abgesichert werden 

können. 

Platzieren globaler Katalogserver 

Globale Katalogserver sind erforderlich, damit Benutzer sich an den AD DS-Domänen anmelden oder 

AD DS nach Verzeichnisinformationen durchsuchen können. Im Allgemeinen bedeutet das, dass Sie 

einen globalen Katalogserver in jedem Standort platzieren sollten. Dieses Ideal ist jedoch abzuwägen 

gegen den Replikationsdatenverkehr, der durch das Aufstellen eines globalen Katalogservers in jedem 

Standort entsteht. Wenn Sie in einem sehr großen Unternehmen mit mehreren umfangreichen Domänen 

arbeiten, ist der Replikationsdatenverkehr für den globalen Katalog beträchtlich. 

Eine Verbesserung an Windows Server 2003 Active Directory und Windows Server 2008 AD DS ist 

die Tatsache, dass Anmeldungen an einer Domäne ohne Zugriff auf einen globalen Katalogserver 

unterstützt werden. Dies wird durch die Unterstützung der Zwischenspeicherung der universellen 

Gruppenmitgliedschaft ermöglicht. Ist die Zwischenspeicherung der universellen Gruppenmitgliedschaft 

aktiviert, können Domänencontroller die universelle Gruppenmitgliedschaften für Benutzer in 

der Domäne zwischenspeichern. Wenn der Benutzer sich erstmals am Standort anmeldet, muss seine 

universelle Gruppenmitgliedschaft von einem globalen Katalogserver abgerufen werden. Nach der 

ersten Anmeldung speichert der Domänencontroller die universelle Gruppenmitgliedschaft des Benutzers 

jedoch auf unbestimmte Zeit zwischen. Die Zwischenspeicherung der universellen Gruppenmitgliedschaft 

auf dem Domänencontroller wird alle acht Stunden durch Kontaktieren eines festgelegten 

globalen Katalogservers aktualisiert. Zum Aktivieren der Zwischenspeicherung der universellen 

Gruppenmitgliedschaft öffnen Sie das Verwaltungsprogramm Active Directory-Standorte und 

-Dienste und erweitern das Standortobjekt für den Standort, in dem Sie diese Einstellung aktivieren 

möchten. Klicken Sie mit der rechten Maustaste auf das Objekt NTDS Site Settings, und wählen Sie 

Eigenschaften.


Wählen Sie auf der Registerkarte Standorteinstellungen die Option Zwischenspeichern der universellen 

Gruppenmitgliedschaft aktivieren, und wählen Sie in der Dropdownliste Cache aktualisieren 

von den Standort aus, in dem sich der nächste globale Katalogserver befindet. 

Entwerfen von Bereitstellungen schreibgeschützter Domänencontroller 

Eine der wichtigen neuen Funktionen in Windows Server 2008 ist die Option zum Bereitstellen von 

RODCs. RODCs bieten die gesamte Funktionalität, die Clients zur Authentifizierung benötigen, und 

gleichzeitig eine zusätzliche Sicherheit für Domänencontroller in Niederlassungen, in denen die physische 

Sicherheit des Domänencontrollers nicht sichergestellt werden kann. Beim Entwerfen der 

RODC-Bereitstellung müssen Sie sich mit der RODC-Platzierung, mit der Zwischenspeicherung der 

Benutzerkontokennwörter auf dem Server und mit der Konfiguration delegierter administrativer 

Berechtigungen für den Domänencontroller beschäftigen. 

Entwerfen der RODC-Platzierung RODCs sind für die Platzierung an Standorten ausgelegt, an denen 

Sie einen Domänencontroller einsetzen möchten, jedoch hinsichtlich der Sicherheit für den Domänencontroller 

Bedenken haben. Außerdem können Sie den Einsatz von RODCs in Niederlassungen erwägen, 

in denen keine Administratoren beschäftigt sind, die Änderungen an AD DS vornehmen müssten. 

In den meisten Fällen werden RODCs in Zweigniederlassungen eingesetzt, sie können jedoch 

auch zum Ausführen von Anwendungen verwenden werden, für die ein Domänencontroller erforderlich 

ist. 

Für die Entscheidung, ob ein RODC in einer Zweigniederlassung eingesetzt werden soll, gelten dieselben 

Überlegungen wie für den Einsatz eines Domänencontrollers bei geringerer physischer Sicherheit. 

Generell sollte ein RODC als einziger Domänencontroller für die zugehörige Domäne in einem 

Standort bereitgestellt werden. Beim Entwurf der Platzeriung von RODCs gibt es zwei zusätzliche 

Überlegungen: 

• Jeder RODC erfordert einen beschreibbaren Domänencontroller unter Windows Server 2008 für 

dieselbe Domäne, von dem der RODC direkt replizieren kann. RODCs können Änderungen an 

Schema, Konfiguration und Anwendungspartitionen von einem Windows Server 2003-Domänencontroller 

replizieren, jedoch nur Änderungen an der Domänenpartition von einem Windows Server 

2008-Domänencontroller. Das bedeutet, dass ein beschreibbarer Domänencontroller unter 

Windows Server 2008 in dem Standort platziert werden sollte, der in der Topologie am nächsten 

liegt. Wenn Sie Standortverknüpfungsbrücken nicht deaktiviert haben, ist dies kein absolutes 

Muss, wird jedoch dennoch dringend empfohlen. 

• Domänencontroller unter Windows Server 2003 führen eine automatische Standortabdeckung für 

Standorte mit RODCs durch. Anhand der automatischen Standortabdeckung wird sichergestellt, 

dass Clients in Domänen ohne Domänencontroller sich am nächstmöglichen Domänencontroller 

authentifizieren können. Domänencontroller unter Windows Server 2003 berücksichtigen keine 

RODCs bei der Auswertung des Standortabdeckungsbedarfs. Daher führen sie eine automatische 

Standortabdeckung für jeden Standort durch, der nur einen RODC für dieselbe Domäne enthält. 

Das bedeutet, dass Windows Server 2003-Domänencontroller standortspezifische SRV-Einträge 

für den Standort registrieren, was möglicherweise zur Folge hat, dass Clientcomputer sich an den 

Domänencontrollern außerhalb des Standorts und nicht am lokalen RODC authentifizieren. Um 

dies zu verhindern, können Sie folgendermaßen vorgehen: 

Stellen Sie sicher, dass alle Domänencontroller in dem Standort, der dem Standort mit dem 

RODC am nächsten liegt, Windows Server 2008 ausführen. Stellen Sie außerdem sicher, dass 

mindestens einer dieser Server ein globaler Katalogserver ist.


 

 

 

Deaktivieren Sie die automatische Standortabdeckung auf Domänencontrollern unter Windows 

Server 2003. Dieser Schritt ist über die Registrierung möglich. 

Erhöhen Sie die Gewichtung der vom RODC registrierten DNS-SRV-Ressourceneinträge, 

oder verringern Sie die Priorität der von Windows Server 2003 registrierten SRV-Einträge, 

damit die Clientcomputer sich mit höherer Wahrscheinlichkeit eher am RODC als an einem 

Windows Server 2003-Domänencontroller authentifizieren. 

Konfigurieren Sie die Domänencontrollerlocator-DNS-Einträge über die Gruppenrichtlinien. 

Sie können den DNS-Locatoreinträgen über die Gruppenrichtlinien unterschiedliche Gewichtungen 

zuordnen. 

Weitere Informationen Einzelheiten zur Konfigurierung dieser Optionen finden Sie in englischer Sprache 

unter „Step-by-Step Guide for Read-Only Domain Controller in Windows Server 2008“ unter http:// 

technet2.microsoft.com/windowsserver2008/en/library/ea8d253e-0646-490c-93d3- 

b78c5e1d9db71033.mspx?mfr=true. 

Entwerfen der RODC-Verwaltung Beim Entwerfen der Bereitstellung von RODCs müssen Sie auch die 

delegierte Verwaltung für die RODCs einplanen. Einer der Vorteile eines RODCs besteht darin, dass 

Sie einen delegierten lokalen Administrator für den RODC konfigurieren können, ohne Berechtigungen 

auf Domänenebene zu erteilen. Der delegierte Administrator kann sich für Wartungsarbeiten 

(z.B. zur Aktualisierung eines Treibers) an einem RODC anmelden. Er könnte sich jedoch nicht an 

einem anderen Domänencontroller anmelden oder andere Verwaltungsaufgaben in der Domäne ausführen. 

Die Delegierung von Administratorrechten für einen RODC sollte in Betracht gezogen werden, wenn 

sich der Domänencontroller an einem Zweigstellenstandort ohne Domänenadministratoren befindet. 

Auch wenn Sie die meisten administrativen Aufgaben remote durchführen können, steht der lokale 

Administrator zur Verfügung, wenn die WAN-Verbindung nicht verfügbar ist (sofern Sie die Zwischenspeicherung 

von Anmeldeinformationen für den lokalen Administrator aktiviert haben). Wenn 

Sie lokale Administratorberechtigungen delegieren, wird das Benutzerkonto keiner zusätzlichen 

Sicherheitsgruppe hinzugefügt. Stattdessen wird der Benutzer- oder Gruppenname in einem Attribut 

des RODC-Computerobjekts in den AD DS beibehalten, das beim Versuch des Benutzers, sich am 

RODC anzumelden, verwendet wird. 

Die Anmeldeinformationen des delegierten lokalen Administrators werden per Voreinstellung nicht 

auf dem RODC zwischengespeichert. Dies bedeutet, dass sich der delegierte lokale Administrator 

nicht am RODC anmelden kann, wenn kein beschreibbarer Domänencontroller verfügbar ist. Wenn 

Sie den delegierten Administrator hauptsächlich als Backup im Fall eines WAN-Ausfalls einsetzen 

möchten, müssen Sie für das Administratorkonto die Zwischenspeicherung von Anmeldeinformationen 

aktivieren. Außerdem müssen Sie sicherstellen, dass der Administrator vom RODC authentifiziert 

wurde oder dass der Zwischenspeicher für Anmeldeinformationen für dieses Benutzerkonto 

vorbelegt wurde. 

Entwerfen von Richtlinien zur Kennwortreplikation Eine weitere Entwurfsoption, die Sie für RODCs in 

Betracht ziehen müssen, ist die Zwischenspeicherung von Anmeldeinformationen. Standardmäßig 

werden lediglich die Anmeldeinformationen des RODC-Computerkontos und eines speziellen 

KRBTGT-Kontos auf dem RODC gespeichert. Dies bedeutet, dass der RODC bei der Authentifizierung 

eines Benutzers oder Computers gegenüber dem RODC über eine Verbindung zu einem 

beschreibbaren Domänencontroller verfügen muss. Bei Empfang der Authentifizierungsanforderung 

leitet der RODC diese an einen beschreibbaren Domänencontroller weiter.


Wenn die Kennwortreplikationsrichtlinie geändert wird, werden Kennwörter nach der nächsten 

erfolgreichen Anmeldung eines in der Richtlinie angegebenen Sicherheitsprinzipals auf dem RODC 

zwischengespeichert. Nachdem ein Konto erfolgreich authentifiziert wurde, versucht der RODC einen 

beschreibbaren Domänencontroller am Hubstandort zu kontaktieren und fordert eine Kopie der entsprechenden 

Anmeldeinformationen an. Der beschreibbare Domänencontroller erkennt, dass die 

Anforderung von einem RODC stammt, und fragt die für diesen RODC geltende Kennwortreplikationsrichtlinie 

ab. Wenn die Kennwortreplikationsrichtlinie dies zulässt, repliziert der beschreibbare 

Domänencontroller die Anmeldeinformationen auf dem RODC, und diese Informationen werden auf 

dem RODC zwischengespeichert. Nach der Zwischenspeicherung der Anmeldeinformationen auf 

dem RODC kann der RODC die Anmeldeanforderungen des Benutzers direkt verarbeiten, bis die 

Anmeldeinformationen oder die Kennwortreplikationsrichtlinie geändert werden. 

Bei der Implementierung einer Kennwortreplikationsrichtlinie müssen Sie Benutzerkomfort und 

Sicherheitsbedenken gegeneinander abwägen. Standardmäßig werden auf dem RODC keine Kennwörter 

zwischengespeichert. Zudem wird die Zwischenspeicherung von Anmeldeinformationen für 

alle Domänenadministratorgruppen durch die Richtlinie ausdrücklich verweigert. Wenn Sie die Standardeinstellung 

nicht ändern, können sich Benutzer nicht am RODC anmelden, wenn keine Verbindung 

zu einem beschreibbaren Windows Server 2008-Domänencontroller verfügbar ist. Wenn Sie für 

alle Konten die Zwischenspeicherung von Kennwörtern aktivieren, erhöht sich die Gefahr einer 

Sicherheitsverletzung auf dem RODC. 

Hinweis Wird die Sicherheit eines RODC beeinträchtigt, sollten Sie das RODC-Computerkonto aus Active 

Directory entfernen und die Kennwörter für alle Benutzerkonten zurücksetzen, die auf dem Server zwischengespeichert 

sind. Wenn Sie das RODC-Konto löschen, erhalten Sie die Möglichkeit, eine Liste aller Konten 

mit auf dem RODC zwischengespeicherten Anmeldeinformationen zu exportieren. Wenn die Sicherheit des 

RODC verletzt wurde, sollten Sie außerdem eine Sicherheitsprüfung auf allen Arbeitsstationen im Standort 

durchführen, um sicherzustellen, dass nicht auch deren Sicherheit verletzt wurde. 

Bei der Implementierung einer Kennwortreplikationsrichtlinie stehen Ihnen drei grundsätzliche Optionen 


• Sie übernehmen die Standardkonfiguration, sodass keine Anmeldeinformationen auf dem Server zwischengespeichert 

werden. Diese Option ist möglich, wenn die Serversicherheit besonders wichtig 

und die WAN-Verbindung zwischen dem Standort mit dem RODC und einem Standort mit einem 

beschreibbaren Domänencontroller hoch verfügbar ist. Auch wenn diese Option die Anmeldung 

für Benutzer im Remotestandort nicht sonderlich verbessert, kann der RODC noch immer für 

Suchen im DNS und im globalen Katalog verwendet werden (falls diese Funktionen auf dem 

RODC installiert sind). 

• Sie erlauben oder verweigern die Zwischenspeicherung von Benutzer- oder Computeranmeldeinformationen 

auf dem Server explizit. Greifen Sie zu diesem Zweck auf die Eigenschaften des RODC-Computerkontos 

in Active Directory-Benutzer und -Computer zu, und fügen Sie der entsprechenden 

Liste Benutzer-, Gruppen- oder Computerkonten hinzu. Durch Auswahl dieser Option können Sie 

die Zwischenspeicherung von Anmeldeinformationen denjenigen Benutzern und Computern 

erlauben, die sich im Standort des RODC befinden. Wenn Sie die Eigenschaften des RODC-Computers 

in Active Directory-Benutzer und -Computer öffnen, können Sie feststellen, welche Benutzer 

und Computer sich am RODC authentifiziert haben. Anschließend können Sie diese Konten 

der Kennwortreplikationsrichtlinie hinzufügen und auch die Kennwörter auf dem RODC vordefinieren. 

Diese Option gewährleistet in den meisten Unternehmen ein ausgewogenes Verhältnis 

zwischen Benutzerkomfort und Sicherheitsbedenken.


Wenn die Sicherheit des RODC beschädigt wird, ist nur eine begrenzte Anzahl an Anmeldeinformationen 

auf dem RODC gespeichert. 

• Sie konfigurieren die RODC-Replikationsgruppen für die Konfiguration der Zwischenspeicherung von 

Anmeldeinformationen. AD DS umfassen zwei Gruppen, die auf die Verwaltung der Zwischenspeicherung 

von Anmeldeinformationen durch RODCs ausgelegt sind: 

Die Gruppe mit Domänen-RODC-Kennwortreplikationserlaubnis enthält alle Konten, deren 

Anmeldeinformationen auf allen RODCs in der Domäne zwischengespeichert werden können. 

Wenn Sie dieser Liste einen Benutzer oder eine Gruppe hinzufügen, können dessen bzw. 

deren Anmeldeinformationen auf allen RODCs in der Domäne zwischengespeichert werden. 

Standardmäßig enthält diese Gruppe keine Mitglieder. 

Die Gruppe ohne Domänen-RODC-Kennwortreplikationserlaubnis enthält alle Konten, deren 

Anmeldeinformationen nicht auf allen RODCs in der Domäne zwischengespeichert werden 

können. Standardmäßig enthält diese Gurppe alle Administratorkonten und alle Domänencontrollerkonten. 

Die Gruppe ohne Domänen-RODC-Kennwortreplikationserlaubnis hat Vorrang 

vor der Gruppe mit Domänen-RODC-Kennwortreplikationserlaubnis; wenn daher ein Benutzer 

oder ein Computer in beiden Gruppen enthalten ist, können die Anmeldeinformationen 

nicht auf dem RODC zwischengespeichert werden. 

Wählen Sie diese Option, wenn Sie eine konsistente Kennwortreplikationsrichtlinie auf alle RODCs 

in der Domäne anwenden möchten. Wenn Sie beispielsweise eine Gruppe von Benutzern verwalten, 

die häufig zu allen Remotestandorten mit RODCs reisen, können Sie diese Gruppe der Gruppe mit 

Domänen-RODC-Kennwortreplikationserlaubnis hinzufügen. Die Kennwortzwischenspeicherung 

kann dennoch für lokale Benutzer aktiviert werden, indem Sie lokale Gruppen direkt der Kennwortreplikationsrichtlinie 

hinzufügen. 

Achtung Ein weiterer Faktor, den Sie bei der Bereitstellung von RODCs berücksichtigen sollten, ist die 

Anwendungskompatibilität. Die meisten Anwendungen, die AD DS verwenden, funktionieren auch dann, 

wenn sie sich mit einer schreibgeschützten Version des Datenspeichers verbinden; Anwendungen, die 

Schreibzugriff auf AD DS verlangen, funktionieren jedoch möglicherweise nicht. Einzelheiten zu Anwendungen, 

die mit RODCs funktionieren, und Vorschläge dazu, wie die Kompatibilität von Drittanbieterprodukten 

mit RODCs getestet werden kann, finden Sie unter „Application Compatibility with Read-Only Domain 

Controllers“ unter http://technet2.microsoft.com/windowsserver2008/en/library/f1b06c27-0f6a-4932-afe6- 

a70749f8ab2f1033.mspx. 

Ermitteln von Betriebsmasterservern 

Der wichtigste Betriebsmaster für alltägliche Operationen ist der PDC-Emulator (primärer Domänencontroller). 

Dieser Server ist besonders wichtig, wenn Ihr Unternehmen Clients der Vorgängerversionen 

Windows NT oder Window 9x umfasst, da diese Clients sich mit dem PDC-Emulator verbinden 

müssen, um ihre Kennwörter zu ändern. Selbst wenn Ihr Unternehmen diese älteren Clients nicht verwendet, 

erhält der PDC-Emulator dennoch weiterhin Änderungen hoher Priorität, wie z.B. Änderungen 

am Benutzerkennwort. Demzufolge ist die Platzierung des PDC-Emulators wichtig. Der PDC- 

Emulator sollte an einem zentralen Ort platziert werden, an dem die Höchstzahl an Clients sich mit 

dem Server verbinden kann. 

Die Platzierung der anderen Betriebsmaster ist nicht so wichtig, da es nur minimale Auswirkungen 

hat, wenn diese Server vorübergehend nicht erreichbar sind. Wenden Sie beim Planen der Betriebsmasterplatzierung 

folgendes Prinzip an:


• Nach Möglichkeit sollten der Schemamaster, der Domänennamenmaster und der RID-Master 

(Relative Identifier) an einem Standort platziert werden, in dem sich auch ein anderer Domänencontroller 

als direkter Replikationspartner befindet. Diese Maßnahme dient der Notfallwiederherstellung. 

Wenn einer der Server ausfällt, müssen Sie möglicherweise die Betriebsmasterrolle auf 

einen anderen Domänencontroller übertragen. Idealerweise sollten Sie die Rolle auf einen anderen 

Domänencontroller übertragen, der mit dem ursprünglichen Betriebsmaster vollständig repliziert 

ist. Dies ist wahrscheinlich eher der Fall, wenn sich die beiden Domänencontroller in 

demselben Standort befinden und als direkte Replikationspartner konfiguriert sind. 

• Der RID-Master muss allen Domänencontrollern über eine RPC-Verbindung (Remote Procedure 

Call) zugänglich sein. Wenn ein Domänencontroller mehr RIDs benötigt, fordert er diese vom 

RID-Master über eine RPC-Verbindung an. 

• Der Infrastrukturmaster sollte sich nicht auf einem globalen Katalogserver befinden, wenn Sie 

mehrere Domänen verwenden. Die Rolle des Infrastrukturmasters besteht darin, Verweise auf 

Objektanzeigenamen zwischen Domänen zu aktualisieren. Wenn beispielsweise ein Benutzerkonto 

umbenannt wird und der Benutzer Mitglied einer universellen Gruppe ist, aktualisiert der 

Infrastrukturmaster den Benutzernamen. Wenn sich der Infrastrukturmaster auf einem globalen 

Katalogserver befindet, kann er nicht funktionieren, da der globale Katalog ständig mit den neuesten 

globalen Informationen aktualisiert wird. Demzufolge erkennt der Infrastrukturmaster niemals 

veraltete Informationen und aktualisiert daher auch niemals domänenübergreifende 

Informationen. 

Allgemein gilt folgende Regel: Wenn ein Unternehmen einen zentralen Standort besitzt, in dem sich 

die meisten Benutzer befinden, sollten alle Betriebsmaster in diesem Standort platziert werden. 


Der AD DS-Entwurf ist ein Thema, das allein bereits ein ganzes Buch füllen könnte. Wie in diesem 

Kapitel beschrieben wurde, besteht der AD DS-Entwurf aus folgenden Phasen: Erkennen der Anforderungen 

des Unternehmens an den AD DS-Entwurf, Entwerfen der obersten Komponenten und 

anschließend Entwerfen der Komponenten niedrigerer Ebenen, um sie an diese Entwürfe anzupassen. 

Das bedeutet, dass im ersten Schritt des AD DS-Entwurfs die Gesamtstruktur entworfen wird. Danach 

folgt der Entwurf der Domänen, dann der DNS-Entwurf und schließlich der OU-Entwurf. Während 

Sie die logische AD DS-Struktur entwerfen, müssen Sie auch die physischen AD DS-Komponenten 

planen, indem Sie die Standorte und die Platzierungen der Domänencontroller entwerfen. 


• Beim Erstellen eines Gesamtstrukturentwurfs beginnen Sie immer in der Erwartung, dass Sie nur 

eine einzige Gesamtstruktur implementieren werden. Dies ist die einfachste Option für Bereitstellung 

und Verwaltung, die automatisch Zusammenarbeitsfunktionen wie die Suche im globalen 

Katalog und Exchange Server-Funktionen ermöglicht. Seien Sie jedoch darauf vorbereitet, dass 

zusätzliche Gesamtstrukturen zur administrativen Isolation erforderlich sein können. 

• In einem Unternehmen mit mehreren Domänen wird die Erstellung einer dedizierten Stammdomäne 

dringend empfohlen. Dieser Entwurf vereinfacht die Bereitstellung geografischer Redundanz 

für die Stammdomäne und trennt Gesamtstrukturadministratoren von Domänenadministratoren.


• Machen Sie DNS-Server, auf denen AD DS-Domäneneinträge gehostet werden, niemals für das 

Internet zugänglich. Wenn Sie denselben Namespace sowohl intern als auch extern nutzen, implementieren 

Sie ein geteiltes DNS, in dem zwei verschiedene Server die interne und die externe 

Zone hosten. 

• Implementieren Sie selbst dann AD DS-integrierte Zonen für AD DS-Domänen, wenn Sie eine 

DNS-Serverinfrastruktur für andere DNS-Funktionalitäten in Ihrem Unternehmen verwalten. AD 

DS-integrierte Zonen bieten ein hohes Maß an Redundanz, indem sie allen DNS-Servern das Verwalten 

beschreibbarer Kopien der Zonendateien ermöglichen. 

• Wenn Sie entscheiden, dass Sie einen Domänencontroller in einer Niederlassung installieren müssen, 

erstellen Sie für diese Niederlassung einen Standort. Wenn Sie die physische Sicherheit des 

Domänencontrollers nicht sicherstellen können, stellen Sie einen RODC bereit. 



• In Kapitel 4, „Active Directory-Domänendienstreplikation“, wird die Konfiguration von AD DS- 

Standorten und Replikation im Detail behandelt. 

• Kapitel 6, „Installieren der Active Directory-Domänendienste“, enthält Einzelheiten zur Installation 

von AD DS-Domänencontrollern sowie zur Konfiguration von RODC-Einstellungen. 

• Kapitel 9, „Delegieren der Active Directory-Domänendiensteverwaltung“, und Kapitel 11, „Einführung 

in Gruppenrichtlinien“, sollten vor dem Erstellen eines OU-Entwurfs gelesen werden, da 

die in diesen Kapiteln behandelten Themen beim Erstellen des Entwurfs relevant sind. 

• „Multiple Forest Considerations in Windows 2000 and Windows Server 2003“ unter 

http://technet2.microsoft.com/windowsserver/en/library/bda0d769-a663-42f4-879ff548b19a8c7e1033.mspx?mfr=true 

• Das englischsprachige Whitepaper „Windows 2000/2003: Multiple Forests Considerations“ unter 

http://www.microsoft.com/downloads/details.aspx?familyid=b717bfcd-6c1c-4af6-8b2cb604e60067ba&displaylang=en 

• „Domain Rename Technical Reference“ unter http://technet2.microsoft.com/windowsserver/en/ 

library/35e63f1e-f097-4c9c-a788-efc840d781931033.mspx?mfr=true 

• „Windows Server 2003 Active Directory Branch Office Guide“ unter 

http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7- 

3A95C9540112&displaylang=en 

• „Creating a Forest Design“ unter http://technet2.microsoft.com/windowsserver/en/library/ 

ff92f142-66ea-498b-ad0f-a379c411eb6e1033.mspx?mfr=true 

• „Determining the Number of Domains Required“ unter http://technet2.microsoft.com/ 

windowsserver/en/library/d390f147-22bc-4ce3-8967-e65d969bc40b1033.mspx?mfr=true 

• Die folgenden Artikel behandeln die Auswirkungen der Bereitstellung von Exchange Server 2007 

auf die Erstellung eines AD DS-Entwurfs: 

„Planung für eine komplexe Exchange-Organisation“ unter http://technet.microsoft.com/dede/library/aa996010.aspx 

„Guidance on Active Directory Design for Exchange Server 2007“ unter 

http://msexchangeteam.com/archive/2007/03/28/437313.aspx


„Dedicated Active Directory Sites for Exchange“ unter http://msexchangeteam.com/archive/ 

2006/08/28/428776.aspx 

„Planen von Active Directory“ unter http://technet.microsoft.com/de-de/library/ 

bb123715.aspx 

• „Application Compatibility with Read-Only Domain Controllers“ unter 

http://technet2.microsoft.com/windowsserver2008/en/library/f1b06c27-0f6a-4932-afe6- 

a70749f8ab2f1033.mspx 


• Bei ListDomainControllers.ps1 handelt es sich um ein Windows PowerShell-Skript, das alle 

Domänencontroller in einer Domäne und alle globalen Katalogserver in einer Gesamtstruktur auflistet. 

• Das Windows PowerShell-Skript ListFSMOs.ps1 dient zum Auflisten aller Betriebsmasterserver 

in Gesamtstruktur und Domäne. 

• ListADDSDomains.ps1 ist ein Windows PowerShell-Skript zum Auflisten von Informationen zu 

sämtlichen Domänen in einer Gesamtstruktur. 

• ListADDSSites.ps1 ist ein Windows PowerShell-Skript zum Auflisten von Informationen zu sämtlichen 

Standorten in einer Gesamtstruktur. 

• CurrentDirectoryEnvironment.xlsx und CurrentNetworkEnvironment.xlsx sind Arbeitsblätter, die 

zum Dokumentieren der aktuellen Verzeichnis- und Netzwerkumgebung Ihres Unternehmens verwendet 

werden können. 

• Die CD enthält mehrere Microsoft Office Visio-Vorlagen, mit denen Sie LAN- und WAN-Konfigurationen 

in Diagrammform entwerfen können, sowie ein Beispiel-WAN-Diagramm, 

WANDiagram_Sample.vsd. 

• ADDS_DesignDocument.xlsx ist ein Arbeitsblatt, das zum Dokumentieren von AD DS-Entwurfsentscheidungen 

und des AD DS-Entwurfs verwendet werden kann.

213 


Installieren der Active Directory-Domänendienste 


Voraussetzungen für die AD DS-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 

Grundlegendes zu den AD DS-Installationsoptionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 

Verwenden des Assistenten zum Installieren von Active Directory-Domänendiensten . . . . . . . . . . . . . . . . . 221 

Durchführen einer unbeaufsichtigten Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 

Bereitstellen schreibgeschützter Domänencontroller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

Entfernen der AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 



Die Installation der Active Directory-Domänendienste (Active Directory Domain Services, AD DS) 

auf einem Server mit Windows Server 2008 ist ein unkomplizierter Vorgang. Dies ist auf den gut entworfenen 

Assistenten zum Installieren von Active Directory-Domänendiensten zurückzuführen, die 

zum Installieren der Dienste verwendete Benutzeroberfläche. Nach der Installation der AD DS auf 

einem Windows Server 2008-Computer nimmt dieser die Rolle eines Domänencontrollers (Domain 

Controller, DC) ein. Dieser Vorgang wird auch als Heraufstufung bezeichnet, d.h. ein Mitgliedsserver 

wird zu einem Domänencontroller heraufgestuft. Sofern es sich bei dem heraufgestuften Server um 

den ersten Domänencontroller in einer neuen Domäne und der Gesamtstruktur handelt, wird eine neue 

Verzeichnisdatenbank zum Speichern von Verzeichnisdienstobjekten erstellt. Wenn es sich um einen 

zusätzlichen Domänencontroller in einer vorhandenen Domäne handelt, werden durch das Replikationsverfahren 

sämtliche Verzeichnisdienstobjekte dieser Domäne an den neuen Domänencontroller 

weitergegeben. 

In diesem Kapitel wird die Navigation im Assistenten zum Installieren von Active Directory- 

Domänendiensten erläutert, und Sie erfahren, wie Sie eine unbeaufsichtigte Installation oder eine 

Installation von Medium (Installing From Media, IFM) durchführen. Die Installation eines schreibgeschützten 

Domänencontrollers (Read-Only Domain Controller, RODC) wird ebenfalls erläutert. 

Abschließend wird der Vorgang zum Entfernen der AD DS von einem Domänencontroller vorgestellt. 

Voraussetzungen für die AD DS-Installation 

Jeder Windows Server 2008-Server, der die im folgenden Abschnitt erläuterten Voraussetzungen 

erfüllt, kann die AD DS hosten und die Rolle eines Domänencontrollers übernehmen. Tatsächlich 

handelt es sich bei jedem neuen Domänencontroller bis zum Abschluss der AD-DS-Installation 

zunächst um einen eigenständigen Server. Bei der Installation werden zwei wichtige Vorgänge ausgeführt. 

Der erste Vorgang besteht im Erstellen oder Füllen der Verzeichnisdatenbank.

214 Kapitel 6: Installieren der Active Directory-Domänendienste 

Im zweiten Vorgang werden die AD DS gestartet, damit der Server auf Domänenanmeldeversuche 

und LDAP-Anforderungen (Lightweight Directory Access Protocol, LDAP) antworten kann. 

Nach der Installation der AD DS wird die Verzeichnisdatenbank auf der Festplatte des Domänencontrollers 

in der Datei Ntds.dit gespeichert. Bei der Installation von Windows Server 2008 werden für 

die Installation der AD DS die erforderlichen Pakete auf den Computer kopiert. Während der Installation 

der AD DS wird die Datenbank Ntds.dit erstellt und an einen während des Installationsvorgangs 

festgelegten Speicherort kopiert. Falls kein Speicherort angegeben ist, wird die Datenbank standardmäßig 

im Pfad %systemroot%\NTDS gespeichert. Bei der Installation werden außerdem sämtliche 

zum Betreiben des Verzeichnisdiensts erforderlichen Tools und DLLs (Dynamic-Link Library) 

installiert. 

In den folgenden Abschnitten werden die Voraussetzungen für die Installation der AD DS auf einem 

Windows Server 2008-Computer erläutert. 

Festplattenspeicheranforderungen 

Der für das Hosten von Active Directory erforderliche Festplattenspeicherplatz ist letztlich von der 

Anzahl an Objekten in der Domäne sowie in einer Umgebung mit mehreren Domänen davon abhängig, 

ob der Domänencontroller als globaler Katalogserver (Global Catalog, GC) konfiguriert ist. Für 

die Installation von Windows Server 2008 gelten die folgenden Festplattenspeicheranforderungen: 

• Mindestens: 10 GB 

• Empfohlen: 40 GB oder mehr 

Hinweis Für eine Server Core-Installation werden lediglich etwa 1 GB Festplattenspeicher für die Installation 

und etwa 2 GB für Vorgänge nach der Installation benötigt. 

Für die Installation der AD DS auf einem neu eingerichteten Windows Server 2008-Computer gelten 

die folgenden Mindestanforderungen in Bezug auf den Festplattenspeicher: 

• 15 MB freier Speicherplatz auf der Partition für die Systeminstallation 

• 250 MB freier Speicherplatz für die AD DS-Datenbank Ntds.dit 

• 50 MB freier Speicherplatz für die ESENT-Protokolldateien (Extensible Storage Engine Transaction, 

ESENT) Bei ESENT handelt es sich um ein transaktives Datenbanksystem, das anhand von 

Protokolldateien die Rollbacksemantik unterstützt, um das Übernehmen von Transaktionen in die 

Datenbank sicherzustellen. 

Für Windows Server 2003-Domänencontroller, die auf Windows Server 2008 aktualisiert werden sollen, 

gelten zusätzliche Voraussetzungen für den Festplattenspeicher. Es muss ausreichend Festplattenspeicher 

für die folgenden Ressourcen vorhanden sein: 

• Anwendungsdaten (%AppData%) 

• Programme (%ProgramFiles%) 

• Benutzerdaten (%SystemDrive%\Dokumente und Einstellungen) 

• Windows-Verzeichnis (%WinDir%) 

Für eine AD DS-Installation in einem Upgradeszenario muss mindestens soviel freier Festplattenspeicherplatz 

vorhanden sein, wie für die vier genannten Ressourcen (und ihre Unterordner) benötigt 

wird. Bei einer Standardinstallation von Active Directory werden sowohl die NTDS-Datenbank als 

auch die Protokolldateien im Ordner %WinDir%\NTDS gespeichert.

Voraussetzungen für die AD DS-Installation 215 

Dies muss in der Berechnung des für das Upgrade erforderlichen Festplattenspeichers berücksichtigt 

werden. Während der Upgrades werden diese Ressourcen – einschließlich NTDS-Datenbank und Protokolldateien 

– an einen Quarantänespeicherort kopiert und im Anschluss an die Aktualisierung wieder 

an den ursprünglichen Speicherort zurückkopiert. Der für den Kopiervorgang der Active Directory-Dateien 

reservierte Festplattenspeicher wird anschließend als freier Speicherplatz an das 

Dateisystem zurückgegeben. 

Zusätzlich zu den hier aufgeführten Festplattenanforderungen muss mindestens ein logisches Laufwerk 

mit dem NTFS-Dateisystem formatiert werden, um die Installation des SYSVOL-Ordners zu 

unterstützen. Während des Upgradeszenarios wird der SYSVOL-Ordner im Gegensatz zu der Datenbank 

Ntds.dit und den Protokolldateien verschoben und nicht kopiert. Aus diesem Grund ist für diese 

Ressource kein zusätzlich freier Festplattenspeicher erforderlich. 

Bevor Sie eine neue Windows Server 2008-Domäne in einer Windows 2000 Server- oder 

Windows Server 2003-Gesamtstruktur erstellen, müssen Sie die vorhandene Umgebung durch eine 

Schemaerweiterung auf die Verwendung von Windows Server 2008 vorbereiten. Durch die Ausführung 

von Adprep.exe können Sie sicherstellen, dass das vorhandene Active Directory-Schema auf die 

Interoperabilität mit den auf einem Windows Server 2008-Computer installierten AD DS vorbereitet 

ist. Das Tool Adprep wird in Kapitel 7, „Migrieren auf die Active Directory-Domänendienste“, ausführlich 

behandelt. 

Netzwerkkonnektivität 

Überprüfen Sie nach der Installation von Windows Server 2008 und vor der Installation der AD DS, 

ob der Server ordnungsgemäß für die Netzwerkkonnektivität konfiguriert ist. Versuchen Sie im Rahmen 

dieser Überprüfung, eine Verbindung zu einem anderen Computer im Netzwerk herzustellen. 

Geben Sie hierzu entweder den UNC-Pfad oder die IP-Adresse des Zielcomputers in die Adresszeile 

von Windows Explorer ein, oder verwenden Sie das Dienstprogramm Ping (geben Sie z.B. an der 

Befehlszeile den Befehl ping 192.168.1.1 ein). Zusätzlich zur Überprüfung der Netzwerkkonnektivität 

müssen Sie prüfen, ob für eine Unterstützung des domänencontrollerbasierten Netzwerkdatenverkehrs 

während der Entwurfsphase der AD DS-Implementierung ausreichend Bandbreite im 

Netzwerksegment zur Verfügung steht. Weitere Informationen zur Planung der Platzierung von 

Domänencontrollern werden in Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, 


Vor der Installation der AD DS sollten Sie außerdem im Dialogfeld Eigenschaften von LAN-Verbindung 

die TCP/IP-Einstellungen (Transmission Control Protocol/Internet Protocol, TCP/IP) konfigurieren. 

Klicken Sie hierzu im Ordner Netzwerkverbindungen mit der rechten Maustaste auf das Objekt 

LAN-Verbindung, öffnen Sie im Bereich Netzwerk- und Freigabecenter die Option Netzwerkverbindungen 

verwalten, und wählen Sie dann Eigenschaften. Wählen Sie im Dialogfeld Eigenschaften von 

LAN-Verbindung die Option Internetprotokoll, Version 4 (TCP/IPv4) und/oder Internetprotokoll, Version 

6 (TCP/IPv6), und klicken Sie dann auf Eigenschaften. Führen Sie im Dialogfeld Internetprotokolleigenschaften 

(TCP/IP) die folgenden Schritte aus: 

• Geben Sie auf der Registerkarte Allgemein eine statische IP-Adresse für den Computer ein. 

• Soll der Domänencontroller, den Sie installieren möchten, nicht als DNS-Server dienen, müssen 

Sie auf der Registerkarte Allgemein für die DNS-Serveradresse die IP-Adresse des DNS-Servers 

eingeben, der für die Domäne autorisierend ist. Weitere Informationen zur Konfiguration von 

DNS für die Installation der AD DS erhalten Sie im folgenden Abschnitt.


• Wählen Sie für den IPv4-Stapel auf der Seite Erweiterte TCP/IP-Einstellungen im Bereich Internetprotokoll, 

Version 4 (TCP/IPv4) auf der Registerkarte Allgemein die Option Erweitert, und klicken 

Sie auf die Registerkarte WINS. Geben Sie hier für den Server die IP-Adresse des WINS- 

Servers (Windows Internet Naming Service, WINS) ein, den der Domänencontroller verwendet. 

(Für den IPv6-Stapel gibt es keine WINS-Einstellungen.) 

DNS 

Die AD DS benötigen DNS für die Ressourcenermittlung. Clientcomputer verwenden DNS zum 

Ermitteln von Domänencontrollern, um sich selbst und die Netzwerkbenutzer zu authentifizieren 

sowie Verzeichnisabfragen zum Ermitteln veröffentlichter Ressourcen durchzuführen. Zudem muss 

der DNS-Dienst Ressourceneinträge für die Dienstidentifizierung (Service Locator, SRV) unterstützen, 

und es wird die Unterstützung dynamischer Aktualisierungen empfohlen. Ist DNS nicht im Netzwerk 

installiert, wird der Dienst durch den Assistenten zum Installieren von Active Directory-Domänendiensten 

zusammen mit den AD DS installiert und konfiguriert. 

Hinweis Für Windows Server 2003 wird die DNS-Installation bei Bedarf angeboten. In Windows 

Server 2008 erfolgt die Installation und Konfiguration (sofern erforderlich) automatisch. Bei einer Installation 

von DNS auf dem ersten Domänencontroller in einer untergeordneten Domäne mit Windows Server 2008 

wird in DNS automatisch eine Delegierung für die neue Domäne erstellt. Sie können DNS jedoch auch 

manuell installieren und konfigurieren. 

Administratorrechte 

Zum Installieren oder Entfernen der AD DS müssen Sie Kontoanmeldeinformationen mit Administratorrechten 

angeben. Die Art der Kontoberechtigungen, die Sie für eine Installation einer 

AD DS-Domäne benötigen, hängt vom Installationsszenario ab: Installation einer neuen Windows 

Server 2008-Gesamtstruktur, Installation einer neuen Windows Server 2008-Domäne in einer vorhandenen 

Gesamtstruktur oder Installation eines neuen Windows Server 2008-Domänencontrollers in 

einer vorhandenen Domäne. Der Assistent zum Installieren von Active Directory-Domänendiensten 

überprüft die Kontoberechtigungen vor der Installation der Verzeichnisdienste. Sind Sie nicht über ein 

Konto mit Administratorenberechtigungen angemeldet, fordert der Assistent Sie zum Eingeben der 

entsprechenden Kontoanmeldeinformationen auf. 

Wenn Sie eine neue Gesamtstruktur-Stammdomäne erstellen möchten, müssen Sie als lokaler Administrator 

angemeldet sein, Sie müssen jedoch keine Sicherheitsinformationen für das Netzwerk angeben. 

Möchten Sie eine neue Strukturstammdomäne oder eine neue untergeordnete Domäne in einer 

vorhandenen Struktur erstellen, müssen Sie zur Installation der Domäne Sicherheitsinformationen für 

das Netzwerk bereitstellen. Bei der Erstellung einer neuen Strukturstammdomäne müssen Sie die 

Kontoanmeldeinformationen eines Mitglieds der Gruppe Organisations-Admins angeben. Wenn Sie 

einen zusätzlichen Domänencontroller in einer vorhandenen Domäne installieren möchten, müssen 

Sie ein Mitglied der globalen Gruppe Domänen-Admins sein. 

Betriebssystemkompatibilität 

Domänencontroller mit Windows Server 2008 sind sicherer als Domänencontroller, auf denen ältere 

Versionen des Windows Server-Betriebssystem ausgeführt werden.

Voraussetzungen für die AD DS-Installation 217 

Der Assistent zum Installieren von Active Directory-Domänendiensten liefert Informationen dazu, 

wie sich diese Sicherheit auf die Clientanmeldung auswirkt. Die Standardsicherheitsrichtlinie für 

Domänencontroller unter Windows Server 2008 erfordert zwei Sicherheitsebenen für die Kommunikation 

des Domänencontrollers: SMB-Signatur und -Verschlüsselung (Server Message Block) sowie 

die Signatur von Netzwerkdatenverkehr über einen sicheren Kanal. 

Diese Features zur Domänencontrollersicherheit können für kompatible Clientcomputer und einige 

Drittanbieteranwendungen bei der Anmeldung ein Problem darstellen. Dies hat auch Auswirkungen 

auf die kompatiblen Clientbetriebssysteme in einer gemischten Domänencontrollerumgebung mit 

Windows Server 2008-Betriebssystemen und Vorgängerversionen. Hier können zeitweilige Fehler 

auftreten, wenn Windows Server 2008-Domänencontroller Authentifizierungsanforderungen und 

Anforderungen zum Hinzufügen zur Domäne bearbeiten. 

Domänencontroller unter Windows Server 2008 werden mit einer „Richtlinie“ konfiguriert, die es 

nicht zulässt, dass Windows- und Drittanbieterclients mit unsicheren Kryptografiemethoden sichere 

Kanäle zu diesen DCs aufbauen. 

Um dieses Problem zu lösen, sollten Sie inkompatible Clients aktualisieren, damit diese Kryptografiemethoden 

verwenden, die mit den standardmäßigen Sicherheitseinstellungen von Windows Server 

2008 kompatibel sind. Hierzu müssen Sie ggf. aktualisierte Software vom jeweiligen Anbieter anfordern. 

Können inkompatible Clients nicht aktualisiert werden, ohne dass es zu einem Dienstausfall kommt, 

müssen Sie die folgenden Schritte ausführen: 

1. Melden Sie sich an der Konsole eines Windows Server 2008-Domänencontrollers an. 

2. Starten Sie die Konsole Gruppenrichtlinienverwaltung. 

3. Bearbeiten Sie die Standardrichtlinie für die Domänencontroller. 

4. Wählen Sie den folgenden Pfad im Gruppenrichtlinien-Editor: Computerkonfiguration|Richtlinien|Administrative 

Vorlagen|System|Netzwerkanmeldung 

5. Legen Sie die Option Mit Windows NT 4.0 kompatible Kryptografiealgorithmen zulassen auf Aktiviert 

fest. 

Hinweis Die Standardeinstellung der Standarddomänenrichtlinie, der Standard-Domänencontrollerrichtlinie 

und der lokalen Richtlinie für die Option Mit Windows NT 4.0 kompatible Kryptografiealgorithmen 

zulassen lautet Nicht konfiguriert. Das Standardverhalten von Windows Server 2008-Domänencontrollern 

sieht jedoch programmatisch vor, dass Verbindungen mit Verwendung NT 4.0-basierter 

Kryptografiealgorithmen nicht zulässig sind. Dadurch können Tools, welche die effektiven Richtlinieneinstellungen 

auf einem Mitgliedscomputer oder Domänencontroller auflisten, die Option Mit Windows 

NT 4.0 kompatible Kryptografiealgorithmen zulassen nicht ermitteln – es sei denn, diese ist ausdrücklich 

in einer Richtlinie aktiviert oder deaktiviert. 

Die Option Mit Windows NT 4.0 kompatible Kryptografiealgorithmen zulassen findet bei Domänencontrollern 

unter Windows 2000 und Windows Server 2003 in der effektiven Richtlinie keine Anwendung. Daher 

bearbeiten Domänencontroller mit Vorgängerversionen von Windows Server 2008 weiterhin Anforderungen 

für sichere Kanäle von Computern, die NT 4.0-basierte Kryptografiemethoden verwenden. Dies 

kann zu inkonsistenten Ergebnissen führen, wenn Anforderungen für sichere Kanäle zeitweilig von Windows 

Server 2008-Domänencontrollern verarbeitet werden.


6. Installieren Sie korrigierende Fixes, oder verwenden Sie keine inkompatiblen Clients. 

7. Legen Sie die Option Mit Windows NT 4.0 kompatible Kryptografiealgorithmen zulassen auf 

Deaktiviert fest, nachdem weniger sichere Clients und Geräte aktualisiert oder aus der Domäne 

entfernt wurden. 

Grundlegendes zu den AD DS-Installationsoptionen 

Sie können die Installation der AD DS entweder über eine der grafischen Benutzeroberflächen oder 

direkt über die Befehlszeile oder den Befehl Ausführen starten. Mit den grafischen Benutzeroberflächen 

wird der Verzeichnisdienst installiert und konfiguriert sowie der Verzeichnisdatenspeicher 

erstellt und initialisiert. Da die AD DS eine autorisierende DNS-Implementierung für die geplante 

Domäne benötigen, wird der DNS-Serverdienst während der Installation installiert und konfiguriert, 

falls er noch nicht vorhanden ist. 

Für die Installation von Active Directory stehen verschiedene Methoden zur Verfügung: 

• Assistent für die Aufgaben der Erstkonfiguration und Assistent zum Hinzufügen von Rollen 

• Assistent zum Installieren von Active Directory-Domänendiensten (Dcpromo.exe) 

• Unbeaufsichtigte Installation 

Aufgaben der Erstkonfiguration und Assistent zum Hinzufügen von 

Rollen 

Bei der Erstinstallation von Windows Server 2008 öffnet sich der Assistent für die Aufgaben der Erstkonfiguration. 

Über diesen Assistenten können Sie die Zeitzone einstellen, das Netzwerk konfigurieren 

und einen Computernamen eingeben. Sie können auch Serverrollen hinzufügen – einschließlich 

AD DS-, AD CS-, AD FS-, AD LDS- und AD RMS-Rollen. Beim Hinzufügen der AD DS-Rolle zum 

Computer werden die erforderlichen Dateien installiert und der Computer für die Ausführung des 

Assistenten zum Installieren von Active Directory-Domänendiensten vorbereitet. Abbildung 6.1 zeigt 

die Benutzeroberfläche des Assistenten zum Hinzufügen von Rollen mit der ausgewählten AD DS- 

Serverrolle. 

Nachdem die AD DS-Rolle zum Server hinzugefügt wurde, können Sie den Assistenten zum Installieren 

von Active Directory-Domänendiensten (Dcpromo.exe) über den Assistenten zum Hinzufügen 

von Rollen starten. Sie können auch weitere Serverrollen hinzufügen und Dcpromo.exe zu einem späteren 

Zeitpunkt ausführen.

Grundlegendes zu den AD DS-Installationsoptionen 219 

Abbildung 6.1 

Serverrolle 

Benutzeroberfläche des Assistenten zum Hinzufügen von Rollen mit der ausgewählten AD DS- 

Server-Manager 

Beim Server-Manager handelt es sich um ein neues in Windows Server 2008 integriertes Feature, das 

Administratoren durch die Installation, Konfiguration und Verwaltung von Windows Server 2008-Serverrollen 

und -Features leitet. Der Server-Manager wird automatisch gestartet, wenn ein Administrator 

den Assistenten für die Aufgaben der Erstkonfiguration beendet und sich an den Server anmeldet. 

Im Server-Manager können Sie Serverrollen wie z.B. die AD DS-Rolle zum Server hinzufügen. 

Hierzu müssen Sie zunächst den Assistenten für die Aufgaben der Erstkonfiguration beenden. 

Abbildung 6.2 zeigt den Server-Manager mit der installierten AD DS-Serverrolle.


Abbildung 6.2 

Server-Manager mit der installierten AD DS-Serverrolle 

Starten Sie, nachdem die AD DS-Serverrolle hinzugefügt wurde, den Assistenten zum Installieren von 

Active Directory-Domänendiensten entweder über den Befeh Ausführen, über die Eingabeaufforderung 

oder direkt über die Verknüpfung im Server-Manager. Im folgenden Abschnitt wird der Installations-Assistent 

näher erläutert. 

Installieren von Active Directory-Domänendiensten 

Sie können den Assistenten zum Installieren von Active Directory-Domänendiensten starten, indem 

Sie dcpromo.exe in das Dialogfeld Ausführen oder an der Eingabeaufforderung eingeben. Für die 

Verwendung von Dcpromo.exe stehen verschiedene Befehlszeilenparameter zur Verfügung: 

• Mit dem Parameter /adv starten Sie den Assistenten zum Installieren von Active Directory-Domänendiensten 

im Modus Erweitert. Für Windows Server 2008 wird die Option zum Ausführen von 

Dcpromo im erweiterten Modus jetzt auf der Begrüßungsseite des Assistenten zum Installieren 

von Active Directory-Domänendiensten angezeigt. Verwenden Sie den erweiterten Modus, wenn 

der Domänencontroller aus wiederhergestellten Sicherungsdateien erstellt wird (diese Installationsmethode 

wird auch Installation von Medium [Installed from Media, IFM] genannt), oder wenn 

Sie die Kennwortreplikationsrichtlinie für einen RODC konfigurieren. Beim Hinzufügen des 

Parameters /adv werden Sie während der Installation dazu aufgefordert, den Pfad zu den wiederhergestellten 

Sicherungsdateien anzugeben.

Verwenden des Assistenten zum Installieren von Active Directory-Domänendiensten 221 

• Mit dem Parameter /unattend:[Datei_unbeaufsichtigte_Installation] können Sie eine unbeaufsichtigte 

Installation der AD DS durchführen – entweder für eine vollständige Installation von Windows 

Server 2008 oder für eine Server Core-Installation. (Die Server Core-Installation ist eine 

neue Installationsoption von Windows Server 2008, die keine grafische Benutzeroberfläche wie 

z.B. den Assistenten zum Installieren von Active Directory-Domänendiensten bereitstellt.) 

• Der Parameter /CreateDCAccount dient dem Erstellen eines Kontos für den schreibgeschützten 

Domänencontroller (Read-Only Domain Controller, RODC). 

• Mit dem Parameter /UseExistingAccount:Attach wird der Server dem RODC-Konto zugeordnet. 

Die Optionen /CreateDCAccount und /UseExistingAccount:Attach schließen sich gegenseitig aus. 

Informationen zu den wichtigsten Entscheidungsfaktoren bei der AD DS-Installation finden Sie im 

Abschnitt „Verwenden des Assistenten zum Installieren von Active Directory-Domänendiensten“ 

weiter unten in diesem Kapitel. 

Unbeaufsichtigte Installation 

Zusätzlich zur Verwendung der grafischen Benutzeroberflächen zum Installieren der 

Active Directory-Domänendienste kann die Installation auch unbeaufsichtigt (automatisch) erfolgen. 

Geben Sie hierzu den Befehl dcpromo.exe /unattend:Datei_unbeaufsichtigte_Installation ein, 

wobei Datei_unbeaufsichtigte_Installation für den Dateinamen der von Ihnen erstellten Datei für die 

unbeaufsichtigte Installation steht. Die Skriptdatei für die unbeaufsichtigte Installation übergibt die 

Werte für sämtliche Felder mit Benutzereingaben, die Sie normalerweise mithilfe des Assistenten 

zum Installieren von Active Directory-Domänendiensten vervollständigen würden. Für jeden Wert, 

der nicht in der Datei für die unbeaufsichtigte Installation angegeben ist, wird entweder der Standardwert 

verwendet, oder Dcpromo informiert Sie in einer Fehlermeldung, dass die Angaben in der Datei 

für die unbeaufsichtigte Installation unvollständig sind. Im Gegensatz zu älteren AD DS-Versionen 

wurde das Erstellen der Datei für die unbeaufsichtigte Installation in Windows Server 2008 erheblich 

vereinfacht. Dieses Thema wird im späteren Verlauf dieses Kapitels noch näher erläutert. 

Verwenden des Assistenten zum Installieren von Active 

Directory-Domänendiensten 

Der Assistent zum Installieren von Active Directory-Domänendiensten stellt eine unkomplizierte 

Benutzeroberfläche bereit, bei der Sie zur Eingabe aller Optionen und Variablen für die AD DS- 

Installation aufgefordert werden. Da dieser Vorgang selbsterklärend ist, werden in diesem Abschnitt 

nur die wichtigsten Entscheidungsfaktoren für die Installation der AD DS erläutert. 

Sie können den Assistenten zum Installieren von Active Directory-Domänendiensten starten, indem 

Sie dcpromo in das Dialogfeld Ausführen oder an der Eingabeaufforderung eingeben. Die Begrüßungsseite 

des Assistenten zum Installieren von Active Directory-Domänendiensten wird angezeigt. 

Auf der Begrüßungsseite können Sie für die Ausführung von Dcpromo den Modus Erweitert wählen. 

In diesem Modus werden zusätzliche Assistentenseiten zur Abdeckung aller gängigen Installationsszenarien 

bereitgestellt. Die Auswahl des Modus Erweitert im Assistenten zum Installieren von 

Active Directory-Domänendiensten wird in Abbildung 6.3 gezeigt.


Abbildung 6.3 

Begrüßungsseite des Assistenten zum Installieren von Active Directory-Domänendiensten 

Bereitstellungskonfiguration 

Die erste Entscheidung, die Sie während des Installationsvorgangs treffen müssen, betrifft den Domänencontrollertyp, 

den Sie erstellen möchten. Sie können (wie in Abbildung 6.4) gezeigt einen Domänencontroller 

in einer vorhandenen Gesamtstruktur oder eine neue Domäne in einer neuen Gesamtstruktur 

erstellen. Möchten Sie einen Domänencontroller zu einer vorhandenen Domäne hinzufügen 

oder eine neue Domäne in einer vorhandenen Gesamtstruktur erstellen, müssen Sie berücksichtigen, 

dass sämtliche lokale Konten auf dem Server und alle auf dem Computer gespeicherten kryptografischen 

Schlüssel gelöscht werden. Sie werden zudem dazu aufgefordert, verschlüsselte Daten zu entschlüsseln, 

da auf diese anderenfalls nach der Installation der AD DS nicht mehr zugegriffen werden 

kann. 

Wenn Sie eine neue Domäne erstellen, können Sie entweder eine Stammdomäne in einer neuen 

Gesamtstruktur, eine untergeordnete Domäne in einer vorhandenen Domäne oder eine neue Domänenstruktur 

in einer vorhandenen Gesamtstruktur erstellen. Weitere Informationen zur Bestimmung 

des zu erstellenden Domänentyps finden Sie in der AD DS-Entwurfsdokumentation (Kapitel 5). Wenn 

Sie eine untergeordnete Domäne in einer vorhandenen Domäne oder eine neue Domänenstruktur in 

einer vorhandenen Gesamtstruktur erstellen, müssen Sie zum Fortsetzen der Installation geeignete 

Sicherheitsinformationen für das Netzwerk bereitstellen. Zur Erstellung einer neuen Gesamtstruktur- 

Stammdomäne ist die Angabe von Sicherheitsinformationen für das Netzwerk nicht erforderlich. 

Hinweis Die Option zum Installieren einer neuen Domänenstruktur steht nur zur Verfügung, wenn Sie den 

Assistenten zum Installieren von Active Directory-Domänendiensten im erweiterten Modus ausführen.


Abbildung 6.4 

Die Seite Bereitstellungskonfiguration wählen 

Benennen der Domäne 

Bei der Erstellung eines neuen Domänencontrollers in einer neuen Gesamtstruktur müssen Sie einen 

vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) für die neue Gesamtstruktur-Stammdomäne 

angeben. In Abbildung 6.5 wird der erste Schritt dieses Vorgangs dargestellt. Bei 

der Erstellung eines solchen Namens müssen Sie bestimmten Regeln folgen. 

Der FQDN muss bei einer neuen Domäne ein eindeutiger Name sein. Wenn Sie eine untergeordnete 

Domäne erstellen, muss die übergeordnete Domäne im DNS-Namen enthalten und verfügbar sein. Erstellen 

Sie z.B. eine neue Domäne NA in der Domänenstruktur Adatum.com, muss der von Ihnen festgelegte 

FQDN NA.Adatum.com lauten. Für den Namen der Domäne können Sie die Buchstaben A bis Z, 

die Zahlen 0 bis 9 und den Bindestrich (-) verwenden. Die Groß- und Kleinschreibung wird nicht berücksichtigt. 

Jede Komponente (Bezeichnung) des FQDNs (die Bereiche, die durch einen Punkt [.] getrennt 

sind) darf aus maximal 63 Bytes bestehen. (Internationalisierte Domänennamen können Unicode-Zeichen 

in Byte-Zeichenfolgen innerhalb des FQDN-Zeichensatzes codieren, wodurch die Unterstützung für 

die verfügbaren Zeichen und Längen verbessert wird.) 

Achtung Die Verwendung von DNS-Namen mit einfacher Bezeichnung wird bei der Namensgebung der 

AD DS-Domäne nicht empfohlen. DNS-Namen, die kein Suffix wie com, .corp, .net, .org oder Unternehmensnamen 

enthalten, werden als DNS-Namen mit einfacher Bezeichnung betrachtet. Beispielsweise 

handelt es sich bei „host“ um einen DNS-Namen mit einer einzigen Bezeichnung. Die meisten Internetregistrierungsstellen 

erlauben keine Registrierung von DNS-Namen mit einfacher Bezeichnung. Es wird außerdem 

empfohlen, keine DNS-Namen mit dem Suffix .local zu erstellen. Weitere Informationen zu diesen 

empfohlenen Vorgehensweisen finden Sie im Artikel „Informationen zur Konfiguration von Windows für 

Domänen mit DNS-Namen mit einfacher Bezeichnung“ unter http://support.microsoft.com/kb/300684.


Abbildung 6.5 

Die Seite Name der Gesamtstruktur-Stammdomäne 

Konfigurieren der Funktionsebenen von Windows Server 2008 

Durch die Domänen- und Funktionsebeneneinstellungen von Windows Server 2008 werden die AD DS- 

Features festgelegt, die in einer Domäne oder Gesamtstruktur aktiviert sind. Darüber hinaus legt die 

Funktionsebene fest, welche Windows Server-Version als Domänencontroller in der Domäne oder 

Gesamtstruktur installiert werden kann. Die Gesamtstruktur- und Domänenfunktionsebenen werden 

nach dem Windows Server-Betriebssystem benannt, das Unterstützung für die Features dieser Active 

Directory-Version bietet: Windows 2000, Windows Server 2003 und Windows Server 2008. 

Abbildung 6.6 zeigt die Seite Funktionsebene der Gesamtstruktur festlegen des Assistenten zum 

Installieren von Active Directory-Domänendiensten. In Tabelle 6.1 finden Sie eine Auflistung der 

verfügbaren Features für jede Funktionsebene der Gesamtstruktur. 

Tabelle 6.1 Gesamtstrukturfunktionsebenen in Windows Server 2008 


Windows 2000 

einheitlich 

Windows 

Server 2003 

Verfügbare Features 


Es stehen alle standardmäßigen AD DS-Features zur Verfügung. Windows Server 2008, 

Windows Server 2003, 

Windows 2000 

Es stehen alle standardmäßigen AD DS-Features sowie die folgenden 

Features zur Verfügung: 

• Gesamtstrukturvertrauensstellung 



Windows Server 2008


Tabelle 6.1 

Gesamtstrukturfunktionsebenen in Windows Server 2008 (Fortsetzung) 


Windows 

Server 2003 

(Fortsetzung) 

Windows 

Server 2008 


• Replikation verknüpfter Werte 

• Bereitstellung schreibgeschützter Domänencontroller (Read-Only 

Domain Controllers, RODC) 

• Verbesserte KCC-Algorithmen (Knowledge Consistency Checker, KCC) 

und Skalierbarkeit 

• Verbesserter ISTG-Algorithmus 

• Erstellung von Instanzen der dynamischen Erweiterungsklasse dynamicObject 

in Domänenverzeichnispartitionen 

• Konvertierung einer inetOrgPerson-Objektinstanz in eine User- 

Objektinstanz und umgekehrt 

• Erstellung von Instanzen neuer Gruppentypen zur Unterstützung der 

rollenbasierten Autorisierung 

• Deaktivierung und Neudefinition von Attributen und Klassen im Schema 

Es stehen alle für die Windows Server 2003-Gesamtstrukturfunktionsebene 

verfügbaren Features zur Verfügung, darüber hinaus jedoch keine zusätzlichen. 

Sämtliche Domänen, die gleichzeitig zur Gesamtstruktur 

hinzugefügt werden, werden standardmäßig mit der Domänenfunktionsebene 

Windows Server 2008 ausgeführt. 



Abbildung 6.6 

Die Seite Funktionsebene der Gesamtstruktur festlegen


In Tabelle 6.2 werden die verfügbaren Features für jede Domänenfunktionsebene aufgelistet. 

Tabelle 6.2 Domänenfunktionsebenen in Windows Server 2008 


Windows 2000 

einheitlich 

Windows 

Server 2003 

Windows 

Server 2008 


Es stehen alle standardmäßigen AD 

DS-Features sowie die folgenden Verzeichnisfeatures zur Verfügung: 

• Universelle Gruppen für Verteiler- und Sicherheitsgruppen 

• Gruppenverschachtelung 

• Gruppenkonvertierung, wodurch eine Konvertierung zwischen Sicherheits- 

und Verteilergruppen ermöglicht wird 

• SID-Historie (Security Identifier, SID) 

Es stehen alle standardmäßigen AD DS-Features, sämtliche der für die 

Domänenfunktionsebene Windows 2000 einheitlich verfügbaren Features 

und die folgenden Features zur Verfügung: 

• Das Domänenverwaltungstool Netdom.exe ermöglicht die Umbenennung 

von Domänencontrollern. 

• Aktualisierung von Anmeldezeitstempeln. 

• Das Attribut lastLogonTimestamp wird mit der letzten Anmeldezeit des 

Benutzers oder Computers aktualisiert. Dieses Attribut wird innerhalb 

der Domäne repliziert. 

• Festlegung des Attributs userPassword als effektives Kennwort für 

inetOrgPerson und Benutzerobjekte. 

• Möglichkeit zur Umleitung der Container Users und Computers. 

• Standardmäßig werden die bekannten Container zum Speichern von 

Computer- und Benutzerkonten bereitgestellt: cn=Computers, 

und cn=Users,. Mit diesem Feature 

können Sie neue Speicherorte für diese Konten definieren. 

• Fähigkeit des Autorisierungs-Managers, seine Autorisierungsrichtlinien 

in den AD DS zu speichern. 

• Eingeschränkte Delegierung. 

• Mit einer eingeschränkten Delegierung können Anwendungen die 

sichere Delegierung von Benutzeranmeldeinformationen durch die 

Kerberos-Authentifizierung nutzen. 

• Sie können die Delegierung auf bestimmte Zieldienste einschränken. 

• Ausgewählte Authentifizierung. 

• Die ausgewählte Authentifizierung ermöglicht Ihnen die Festlegung 

der Benutzer und Gruppen aus einer vertrauten Gesamtstruktur, die 

sich an Ressourcenservern in einer vertrauenden Gesamtstruktur 

authentifizieren dürfen. 

Es stehen alle standardmäßigen AD DS-Features, sämtliche Features der 

Domänenfunktionsebene Windows Server 2003 und die folgenden Features 


• Unterstützung der DFS-Replikation (Distributed File System) für das 

Windows Server 2003-Systemvolume (SYSVOL). 

• Die DFS-Replikation bietet eine stabilere und detailliertere Replikation 

der SYSVOL-Inhalte. 

Unterstützte 




Windows 2000 



Windows Server 2008


Tabelle 6.2 

Domänenfunktionsebenen in Windows Server 2008 (Fortsetzung) 


Windows 

Server 2008 

(Fortsetzung) 


• AES 128- und AES 256-Unterstützung (Advanced Encryption Standard, 

AES) für das Kerberos-Protokoll. 

• Informationen zur letzten interaktiven Anmeldung. 

Über dieses Feature werden die folgenden Informationen angezeigt: 

• Zeitpunkt der letzen erfolgreichen interaktiven Anmeldung eines Benutzers. 

• Name der Arbeitsstation, an der sich der Benutzer angemeldet hat. 

• Anzahl fehlgeschlagener Anmeldeversuche seit der letzten Anmeldung. 

• Fein abgestimmte Kennwortrichtlinien. 

Fein abgestimmte Kennwortrichtlinien ermöglichen es Ihnen, Kennwortund 

Kontosperrrichtlinien für Benutzer und globale Sicherheitsgruppen in 

einer Domäne festzulegen. 

Unterstützte 


Legen Sie die Domänen- und Gesamtstrukturfunktionsebenen auf den höchsten Wert fest, den Ihre 

Umgebung unterstützen kann. So stellen Sie sicher, dass möglichst viele AD DS-Features genutzt 

werden. Falls Sie Ihrer Umgebung Windows Server 2003-Domänencontrollerhinzufügen, sollten Sie 

in Dcpromo die Funktionsebene Windows Server 2003 wählen. Sie können die Funktionsebene zu 

einem späteren Zeitpunkt heraufstufen, wenn Sie die kompatiblen Domänencontroller aus Ihrer 

Umgebung entfernt haben. Dieser Vorgang wird in Kapitel 7 näher erläutert. 

Wichtig Nachdem Sie die Domänen- oder Gesamtstrukturfunktionsebene heraufgestuft oder in Dcpromo 

auf Windows Server 2008 festgelegt haben, können Sie die Funktionsebene nicht wieder herabstufen. 

Weitere Domänencontrolleroptionen 

Die AD DS erfordern eine Installation von DNS im Netzwerk, damit Clientcomputer die Domänencontroller 

für die Authentifizierung ermitteln können. Zudem muss die DNS-Implementierung hierzu 

SRV-Einträge unterstützen. Eine Unterstützung dynamischer Updates durch die DNS-Implementierung 

wird empfohlen. 

Handelt es sich bei dem Computer, auf dem die Installation der AD DS erfolgt, nicht um einen DNS- 

Server oder kann durch den Assistenten zum Installieren von Active Directory-Domänendiensten 

nicht bestätigt werden, dass für die neue Domäne ein ordnungsgemäß installierter DNS-Server vorhanden 

ist, kann der DNS-Serverdienst während der Installation der AD DS installiert werden. Wenn 

sich eine nicht ordnungsgemäß konfigurierte DNS-Implementierung im Netzwerk befindet, erstellt 

der Assistent zum Installieren von Active Directory-Domänendiensten einen detaillierten Bericht zum 

entsprechenden Konfigurationsfehler. In diesem Fall sollten Sie die erforderlichen Änderungen an der 

DNS-Konfiguration vornehmen und die DNS-Diagnoseroutine erneut durchführen. Wenn Sie die 

Standardoption für die Installation und Konfiguration des DNS-Servers wählen, werden zusammen 

mit den AD DS der DNS-Server und der DNS-Serverdienst installiert. Die primäre DNS-Zone stimmt 

mit dem Namen der neuen AD DS-Domäne überein und wird für die Zulassung von dynamischen 

Updates konfiguriert.


Die Einstellung Bevorzugter DNS-Server (im Dialogfeld für die TCP/IP-Eigenschaften) wird aktualisiert, 

um auf den lokalen DNS-Server zu verweisen. Darüber hinaus werden Weiterleitungen und 

Stammhinweise konfiguriert, um eine ordnungsgemäße Funktion des DNS-Serverdiensts zu gewährleisten. 

Weitere Informationen Wenn der DNS-Serverdienst über den Assistenten zum Installieren von Active 

Directory-Domänendiensten installiert wird, wird die DNS-Zone als AD DS-integrierte Zone erstellt. Weitere 

Informationen zur Konfiguration von AD DS-integrierte Zonen finden Sie in Kapitel 3, „Active Directory- 

Domänendienste und DNS“. 

Erstellen Sie den ersten Domänencontroller in einer neuen Gesamtstruktur, muss der DC als globaler 

Katalogserver konfiguriert werden. Der erste DC in einer Gesamtstruktur kann nicht als RODC konfiguriert 

werden. Auf der Dcpromo-Benutzeroberfläche (siehe Abbildung 6.7) ist die Option Globaler 

Katalog standardmäßig ausgewählt und kann nicht deaktiviert werden. Die RODC-Option ist nicht 

verfügbar. Diese Optionen können bei der Installation weiterer Domänencontroller in der Domäne 

konfiguriert werden. 

Abbildung 6.7 

Die Seite Weitere Domänencontrolleroptionen 

Dateispeicherorte 

Der Assistent zum Installieren von Active Directory-Domänendiensten fordert Sie zur Auswahl eines 

Speicherorts für die AD DS-Datenbankdatei (Ntds.dit), die AD DS-Protokolldateien und den SYS- 

VOL-Ordner auf. Sie können entweder die Standardspeicherorte wählen oder andere Speicherorte für 

diese Ordner angeben. Die entsprechende Assistentenseite wird in Abbildung 6.8 gezeigt.


Abbildung 6.8 

Die Seite Speicherort für Datenbank, Protokolldateien und SYSVOL 

Der Ordner %systemroot%\ 

NTDS ist der Standardspeicherort für die Verzeichnisdatenbank und die Protokolldateien. Für eine 

optimale Leistung sollten Sie die AD DS jedoch so konfigurieren, dass die Datenbankdatei und die 

Protokolldateien auf separaten physischen Festplatten gespeichert werden. Der Standardspeicherort 

für den freigegebenen SYSVOL-Ordner lautet %systemroot%\sysvol. Die einzige Einschränkung bei 

der Auswahl des Speicherorts für den freigegebenen Ordner SYSVOL besteht darin, dass er auf einem 

NTFS v5-Volume gespeichert werden muss. Im Ordner SYSVOL werden sämtliche Dateien gespeichert, 

auf die alle Clients innerhalb einer AD DS-Domäne zugreifen können müssen. Beispielsweise 

müssen bei der Clientanmeldung an der Domäne die erforderlichen Anmeldeskripts oder Gruppenrichtlinienobjekte 

verfügbar sein; diese werden im SYSVOL-Ordner gespeichert. 

Abschließen der Installation 

Die letzen Seiten des Assistenten zum Installieren von Active Directory-Domänendiensten sind unkompliziert. 

Hier legen Sie das Kennwort für die Verzeichnisdienstwiederherstellung fest und können die 

Zusammenfassungsseite überprüfen. 

Das Kennwort für die Verzeichnisdienstwiederherstellung (Directory Services Restore Mode, DSRM) 

wird beim Starten des Domänencontrollers in diesem besonderen Wiederherstellungsmodus zur 

Authentifizierung gegenüber der registrierungsbasierten Datenbank für die Sicherheitskontenverwaltung 

(Security Accounts Manager, SAM) verwendet. Wenn Sie den ersten Domänencontroller in der 

Gesamtstruktur erstellen, wird die auf dem lokalen Server geltende Kennwortrichtlinie für das 

DSRM-Administratorkennwort erzwungen. Bei allen anderen Installationen erzwingt der Assistent 

zum Installieren von Active Directory-Domänendiensten die Kennwortrichtlinie, die auf dem als 

Installationspartner verwendeten Domänencontroller gilt.


Das bedeutet, dass das von Ihnen angegebene DSRM-Kennwort die Anforderungen zur Mindestlänge, 

Kennwortchronik und Komplexität für die Domäne erfüllen muss, die vom Installationspartner 

vorgegeben werden. Standardmäßig müssen Sie ein komplexes Kennwort eingeben, das aus einer 

Kombination aus Groß- und Kleinbuchstaben, Zahlen und Symbolen besteht. 

Die Zusammenfassungseite zeigt alle der im Assistenten zum Installieren von Active Directory- 

Domänendiensten gewählten Optionen an. Sie sollten diese Zusammenfassung überprüfen, bevor Sie 

den Installations-Assistenten abschließen und die AD DS installieren. Gehen Sie bei Bedarf auf vorherige 

Seiten zurück. 

Auf der Seite Zusammenfassung können Sie mithilfe der Schaltfläche Einstellungen exportieren eine 

Datei für die unbeaufsichtigte Installation mit den von Ihnen im Assistenten zum Installieren von 

Active Directory-Domänendiensten gewählten Optionen erstellen. Sie können die Datei für die unbeaufsichtigte 

Installation zum Installieren weiterer Domänencontroller verwenden, wenn Sie den Installationsvorgang 

mit dem Befehl Dcpromo /unattend:[Datei_unbeaufsichtigte_Installation] initieren. 

Wenn Sie auf der Zusammenfassungsseite auf Weiter klicken, startet Windows Server 2008 die AD 

DS-Installation und -Konfiguration auf dem Server. Handelt es sich um den ersten Domänencontroller 

in einer neuen Domäne, sind diese Vorgänge relativ zügig abgeschlossen, da lediglich die Standarddomänenobjekte 

erstellt werden und die Verzeichnispartitionen schnell erstellt werden können. 

Wenn Sie einen zusätzlichen Domänencontroller für eine vorhandene Domäne erstellen, müssen sämtliche 

Verzeichnispartitionen nach der Erstellung des Domänencontrollers vollständig synchronisiert 

werden. Um Ihnen die Möglichkeit zu geben, die vollständige Replikation erst nach dem Neustart des 

Computers auszuführen, wird zu Beginn des anfänglichen Repikationsvorgangs die Schaltfläche 

Replikation später abschließen angezeigt. Auch wenn es sich hierbei um keine empfohlene Vorgehensweise 

handelt, kann anhand dieser Option die Synchronisation der Verzeichnispartitionen auf diesem 

Domänencontroller im normalen Replikationsverfahren zu einem späteren Zeitpunkt durchgeführt 

werden. 

Da die erste Replikation der Verzeichnispartition sehr zeitaufwendig sein kann – insbesondere dann, 

wenn es sich um langsame Netzwerkverknüpfungen handelt –, können Sie zusätzliche Domänencontroller 

über wiederhergestellte Sicherungsdateien installieren. Diese Option wird im Abschnitt „Installieren 

von Medium“ weiter unten in diesem Kapitel näher erläutert. 

Überprüfen der AD DS-Installation 

Nach der AD DS-Installation sollten Sie das Snap-In Active Directory-Benutzer und -Computer öffnen 

und sich vergewissern, dass sämtliche der vordefinierten Sicherheitsprinzipale erstellt wurden, 

z.B. das Benutzerkonto Administrator sowie die Sicherheitsgruppen Domänen-Admins und Organisations-Admins. 

Sie sollten auch die Erstellung der Spezialidentitäten wie Authentifizierte Benutzer und 

Interaktiv überprüfen. Spezialidentitäten werden allgemein als Gruppen bezeichnet, Sie können ihre 

Mitgliedschaft jedoch nicht anzeigen. Stattdessen werden Benutzer diesen Gruppen automatisch hinzugefügt, 

wenn Sie sich anmelden oder auf bestimmte Ressourcen zugreifen. Diese Spezialidentitäten 

werden standardmäßig nicht in der Konsole Active Directory-Benutzer und -Computer angezeigt. 

Zur Anzeige dieser Objekte klicken Sie auf Ansicht und dann auf Erweiterte Features. 

Auf diese Weise werden Ihnen weitere Komponenten in der Konsole angezeigt, die standardmäßig 

ausgeblendet sind. Wenn Sie den Container Fremde Sicherheitsprinzipale öffnen, können Sie auf die 

Objekte S-1-5-11 und S-1-5-4 zugreifen. Hierbei handelt es sich um die SID für authentifizierte Benutzer 

und die interaktive SID. Doppelklicken Sie auf diese Objekte, um ihre Eigenschaften und Standardberechtigungen 

anzuzeigen.

Durchführen einer unbeaufsichtigten Installation 231 

Zusätzlich zu einer Überprüfung in der Konsole Active Directory-Benutzer und -Computer sollten Sie 

die folgenden Schritte zur Überprüfung der AD DS-Installation ausführen: 

• Überprüfen Sie das Verzeichnisdienstprotokoll in der Ereignisanzeige, und beheben Sie ggf. aufgetretene 

Fehler. 

• Stellen Sie sicher, dass Clients auf den Ordner SYSVOL zugreifen können. 

• Wenn DNS während der Installation der Active Directory-Domänendienste installiert wurde, sollten 

Sie überprüfen, ob der Dienst ordnungsgemäß installiert wurde: 

a. Öffnen Sie den DNS-Manager. 

b. Klicken Sie auf Start, dann auf Server-Manager, und navigieren Sie zur Seite DNS-Server. 

c. Wechseln Sie zur Seite mit den Forward-Lookupzonen, um zu überprüfen, ob die Zonen 

_msdcs.Gesamtstruktur-Stammdomäne und Gesamtstruktur-Stammdomäne erstellt wurden. 

d. Erweitern Sie den Knoten Stammdomäne, um zu überprüfen, ob die Anwendungsverzeichnispartitionen 

DomainDnsZones und ForestDnsZones erstellt wurden. 

• Vergewissern Sie sich anhand des Tools zur Domänencontrollerdiagnose, Dcdiag.exe, dass die 

AD DS-Replikation ordnungsgemäß funktioniert: 

a. Öffnen Sie eine Eingabeaufforderung. 

b. Geben Sie den folgenden Befehl ein, und drücken Sie die EINGABETASTE: 

dcdiag /test:replication 

c. Um zu überprüfen, ob die entsprechenden Berechtigungen für die Replikation konfiguriert 

sind, geben Sie den folgenden Befehl ein und drücken die EINGABETASTE: 

dcdiag /test:netlogons 

Meldungen weisen darauf hin, dass die Tests zu Konnektivität und Netzwerkanmeldung 

erfolgreich durchgeführt wurden. 

Durchführen einer unbeaufsichtigten Installation 

Zur Installation der AD DS ohne Benutzerinteraktion können Sie den Parameter /unattend: 

[Datei_unbeaufsichtigte_Installation] mit dem Befehl Dcpromo.exe verwenden. Bei diesem Parameter 

müssen Sie den Namen der Datei für die unbeaufsichtigte Installation (der Antwortdatei) angeben. 

Die Antwortdatei enthält alle Daten, die normalerweise während des Installationsvorgangs benötigt 

werden. Die Datei kann automatisch erzeugt werden, wenn Sie zuvor die Option Einstellungen exportieren 

in Dcpromo aktiviert haben. 

Hinweis Zusätzlich zum Ausführen von Dcpromo im unbeaufsichtigten Modus auf einem Computer, auf 

dem Windows Server 2008 bereits installiert ist, können Sie die AD DS auch installieren, während Sie 

Windows Server 2008 im unbeaufsichtigten Modus installieren. Verwenden Sie für dieses Szenario den 

Befehl \I386\winnt32/unattend:[Datei_unbeaufsichtigte_Installation.txt], wobei 

Datei_unbeaufsichtigte_Installation.txt für den Namen der Antwortdatei für die vollständige Installation von 

Windows Server 2008 steht. Die Datei Datei_unbeaufsichtigte_Installation.txt muss den Bereich [DCInstall] 

enthalten, damit die AD DS-Rolle während der unbeaufsichtigten Installation von Windows Server 2008 

installiert werden kann.


Um eine unbeaufsichtigte Installation der AD DS nach der Installation des Windows Server 2008- 

Betriebssystems durchzuführen, müssen Sie eine Antwortdatei erstellen, die sämtliche für die AD DS- 

Installation benötigten Informationen enthält. Geben Sie für eine unbeaufsichtigte Installation an 

der Eingabeaufforderung oder im Dialogfeld Ausführen den Befehl dcpromo /unattend:Datei_ 

unbeaufsichtigte_Installation ein. Bei der Datei für die unbeaufsichtigte Installation handelt es sich 

um eine ASCII-Textdatei, die alle erforderlichen Informationen enthält, um den Assistenten zum 

Installieren von Active Directory-Domänendiensten abzuschließen. Beim Erstellen einer neuen 

Domäne in einer neuen Struktur einer neuen Gesamtstruktur mit automatisch konfiguriertem DNS- 

Serverdienst würden die Inhalte der Datei für die unbeaufsichtigte Installation dem folgenden Beispiel 

ähneln: 

[DCInstall] 

InstallDNS=yes 

NewDomain=forest 

NewDomainDNSName=Adatum.com 

DomainNetBiosName=Adatum 

ReplicaOrNewDomain=domain 

ForestLevel=3 

DomainLevel=3 

DatabasePath="C:\Windows\NTDS" 

LogPath="C:\Windows\NTDS" 

RebootOnCompletion=yes 

SYSVOLPath="C:\Windows\SYSVOL" 

SafeModeAdminPassword=Pa$$w0rd 

Schlüssel und entsprechende Werte bei der unbeaufsichtigten Installation 

Bei einer unbeaufsichtigten Installation werden für Schlüssel ohne vorgegebene Werte oder ausgelassene 

Schlüssel die Standardwerte verwendet. Die erforderlichen Schlüssel für die Antwortdatei 

ändern sich je nach zu erstellendem Domänentyp (neue oder vorhandene Gesamtstruktur, neue oder 

vorhandene Struktur). Ein weiterer Schlüssel, der für das Heraufstufen von Domänencontrollern 

über eine Wiederherstellung von Sicherungsmedien verwendet werden kann, ist der Schlüssel 

ReplicationSourcePath. Um diesen Schlüssel zu verwenden, geben Sie den Speicherort der wiederhergestellten 

Sicherungsdateien an, mit denen die Verzeichnisdatenbank das erste Mal gefüllt wird. 

(Hierbei handelt es sich um den gleichen Pfad zu den wiederhergestellten Sicherungsdateien, den 

auch der Assistent zum Installieren von Active Directory-Domänendiensten für dieses Feature verwendet.) 

Im Abschnitt „Installieren von Medium“ finden Sie weitere Informationen zu diesem 

Feature. 

Die Schrittweise Anleitung zum Installieren und Entfernen von Active Directory-Domänendiensten 

unter Windows Server 2008 enthält den Anhang zu den Parametern für die unbeaufsichtigte Installation 

mit weiteren Informationen zu Schlüsseln und entsprechenden Werten. Dieser kann unter 

http://technet2.microsoft.com/windowsserver2008/de/library/bab0f1a1-54aa-4cef-9164- 

139e8bcc44751031.mspx?mfr=true abgerufen werden. 

Installieren von Medium 

Sie können mit der Option Installieren von Medium (Install From Media, IFM) einen zusätzlichen 

Domänencontroller in einer vorhandenen Domäne installieren und wiederhergestellte Sicherungsdateien 

zum Füllen der AD DS-Datenbank verwenden. Dadurch wird der Replikationsdatenverkehr 

während der Installation minimiert.

Durchführen einer unbeaufsichtigten Installation 233 

Diese Option eignet sich außerdem für Bereitstellungen mit eingeschränkter Bandbreite zu anderen 

Replikationspartnern wie z.B. in Zweigstellenszenarien. Mit dem Windows Server 2008-Sicherungsprogramm 

in Windows Server 2008 können Sie Installationsmedien erstellen. In diesem Fall benötigen 

Sie die Option des Befehlszeilenprogramms Wbadmin, um Systemstatusdaten an einem anderen 

Speicherort wiederherzustellen. 

Windows Server 2008 enthält eine verbesserte Version des Programms Ntdsutil.exe, mit dem Sie 

ebenfalls Installationsmedien erstellen können. Die Verwendung von Ntdsutil.exe wird empfohlen, da 

die Windows Server-Sicherung lediglich wichtige Volumes sichern kann, wodurch mehr Speicherplatz 

in Anspruch genommen wird, als für AD DS-Installationsdaten benötigt wird. Das Programm 

Ntdsutil.exe kann vier Typen von Installationsmedien erstellen, sowohl für beschreibbare Domänencontroller 

als auch für RODCs. 

Hinweis Bei der Erstellung von RODC-Installationsmedien entfernt Ntdsutil alle zwischengespeicherten 

vertraulichen Daten wie z.B. Kennwörter. 

Führen Sie die folgenden Schritte aus, um Installationsmedien mit Ntdsutil.exe zu erstellen: 

1. Öffnen Sie im Menü Start eine Eingabeaufforderung mit erhöhten Berechtigungen, indem Sie mit 

der rechten Maustaste auf Eingabeaufforderung klicken und Als Administrator ausführen wählen. 

2. Geben Sie ntdsutil ein, und drücken Sie die EINGABETASTE. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl activate instance ntds ein, und drücken 

Sie die EINGABETASTE. 

4. Geben Sie an der ntdsutil-Eingabeaufforderung ifm ein, und drücken Sie die EINGABETASTE. 

5. Geben Sie an der ifm-Eingabeaufforderung den Befehl für den Typ von Installationsmedien ein, 

den Sie erstellen möchten, und drücken Sie die EINGABETASTE. Geben Sie beispielsweise zum 

Erstellen von RODC-Installationsmedien, die keine SYSVOL-Daten enthalten, den folgenden 

Befehl ein: 

Create rodc Dateipfad 

wobei Dateipfad für den Pfad zu dem Ordner steht, in dem Sie die Installationsmedien erstellen 

möchten. Sie können die Installationsmedien auf einem lokalen Laufwerk, in einem freigegebenen 

Netzwerkordner oder auf jedem beliebigen Wechseldatenträger speichern. 

In Tabelle 6.3 werden die vier verschiedenen Typen von Installationsmedien aufgelistet. 

Tabelle 6.3 

IFM-Typen 

Parameter 

Create Full 

Create RODC 

Create Sysvol Full 

Create Sysvol RODC 

Typ von Installationsmedien 

Vollständiger (oder beschreibbarer) Domänencontroller 

Schreibgeschützter Domänencontroller 

Vollständiger (oder beschreibbarer) Domänencontroller ohne SYSVOL-Daten 

Schreibgeschützter Domänencontroller ohne SYSVOL-Daten 

Um die AD DS-Datenbank bei der Installation zusätzlicher Domänencontroller zu füllen, geben Sie 

auf der Seite Installieren von Medium im Assistenten zum Installieren von Active Directory-Domänendiensten 

den Speicherort der freigegebenen Ordner oder den Wechseldatenträger zum Speichern 

der Installationsmedien an. Verwenden Sie bei der unbeaufsichtigten Installation den Parameter / 

ReplicationSourcePath, um auf die Installationsmedien zu verweisen.


Bereitstellen schreibgeschützter Domänencontroller 

Unter Windows Server 2008 steht eine neue Möglichkeit zum Installieren eines Domänencontrollers 

in einer Zweigstelle zur Verfügung. Mit diesem Installationsvorgang können Sie einen schreibgeschützten 

Domänencontroller in zwei Schritten in einer Zweigstelle bereitstellen. Zunächst erstellen 

Sie ein Konto für den RODC. Beim Erstellen des Kontos können Sie das Benutzerkonto festlegen, das 

für die Installation und Verwaltung des schreibgeschützten Domänencontrollers verantwortlich ist. 

Der delegierte RODC-Administrator kann die Installation abschließen, indem er einen Server mit dem 

von Ihnen zu diesem Zweck erstellten RODC-Konto verknüpft. Auf diese Weise sind zum Erstellen 

von Zweigstellen-Domänencontrollern weder ein Stagingstandort noch Domänenadministratorberechtigungen 

zum Erstellen von RODCs in einer Zweigstelle erforderlich. 

Berücksichtigen Sie bei der RODC-Installation die folgenden Punkte: 

• Vor der Installation von RODCs in Ihrer Gesamtstruktur müssen Sie diese vorbereiten, indem Sie 

adprep /rodcprep ausführen (dieses Tool wird auf dem Windows Server 2008-Installationsmedium 

bereitgestellt). 

• Bei dem ersten in einer Gesamtstruktur installierten Domänencontroller muss es sich um einen 

globalen Katalogserver handeln, es darf sich nicht um einen RODC handeln. 

• Der RODC muss Domänendaten von einem beschreibbaren Domänencontroller replizieren, der 

unter Windows Server 2008 ausgeführt wird. 

• Standardmäßig führt der RODC keine Zwischenspeicherung der Kennwörter von Domänenbenutzern 

durch. Sie müssen die Standard-Kennwortreplikationsrichtlinie für den RODC ändern, damit 

dieser Benutzer und ihre Computer authentifizieren kann, wenn die WAN-Verknüpfung zum Hubstandort 

offline ist. 

Server Core-Installation unter Windows Server 2008 

Die empfohlene Vorgehensweise ist eine Bereitstellung des RODCs über eine Server Core-Installation 

von Windows Server 2008. Eine Server Core-Installation von Windows Server 2008 bietet eine 

minimale Umgebung zum Ausführen bestimmter Serverrollen, die aufgrund einer verringerten 

Angriffsfläche zu einer Verbesserung der Netzwerksicherheit beiträgt. Der Begriff minimal bezieht 

sich in diesem Zusammenhang auf die geringe Arbeitsspeicher- und Speicherplatzbelegung der Server 

Core-Installation. Darüber hinaus weist eine Server Core-Installation keine grafische Benutzeroberfläche 

(Graphical User Interface, GUI) auf. 

Führen Sie zur Installation von AD DS auf einer Server Core-Installation von Windows Server 2008 

eine unbeaufsichtigte Installation aus. Eine Server Core-Installation unterstützt die folgenden Serverrollen: 

• Active Directory-Domänendienste (AD DS) 

• Active Directory Lightweight Directory Services (AD LDS) 

• DHCP-Server 

• DNS-Server 

• Dateidienste 

• Druckdienste 

• Webdienste (IIS) 

• Hyper-V

Bereitstellen von RODCs 

Entfernen der AD DS 235 

Sie können eine gestaffelte RODC-Installation durchführen. Hierbei führen verschiedene Benutzer 

den Installations-Assistenten zu unterschiedlichen Zeiten und höchstwahrscheinlich an verschiedenen 

Standorten aus. Zunächst erstellt ein Mitglied der Gruppe Domänen-Admins über das Snap-In Active 

Directory-Benutzer und -Computer in Microsoft Management Console (MMC) ein RODC-Konto. 

Klicken Sie entweder mit der rechten Maustaste auf den Container Domain Controllers, oder klicken 

Sie auf den Container Domain Controllers und anschließend auf Aktion und dann auf Konto für 

schreibgeschützten Domänencontroller vorbereiten, um den Assistenten zu starten und das Konto 

zu erstellen. Das RODC-Konto kann auch mithilfe des Befehlszeilenparameters dcpromo /Replica- 

DomainDNSName: /createDCaccount vorbereitet werden. Beim Erstellen des 

RODC-Kontos können Sie die Installation und Verwaltung des RODC an einen Benutzer oder vorzugsweise 

an eine Sicherheitsgruppe delegieren. 

Auf dem Server, der die Rolle des RODC einnimmt, führt der delegierte RODC-Administrator den 

Assistenten zum Installieren von Active Directory-Domänendiensten aus, indem er den Befehl 

dcpromo /UseExistingAccount:Attach an der Eingabeaufforderung eingibt, um den Assistenten 

zu starten. 

Entfernen der AD DS 

AD DS werden von einem Domänencontroller mit dem gleichen Befehl entfernt, der auch für die 

Installation verwendet wird – Dcpromo.exe. Wenn Sie diesen Befehl auf einem Computer ausführen, 

bei dem es sich bereits um einen Domänencontroller handelt, erhalten Sie vom Assistenten zum 

Installieren von Active Directory-Domänendiensten eine Meldung, dass die AD DS entfernt werden, 

wenn Sie fortfahren. In diesem Abschnitt wird der Vorgang zum Entfernen der AD DS sowohl vom 

letzten als auch von einem zusätzlichen Domänencontroller in einer Windows Server 2008-Domäne 

erläutert. 

Das Entfernen der AD DS von einem Domänencontroller hat folgende Auswirkungen: Die Verzeichnisdatenbank 

wird gelöscht, sämtliche der für die AD DS benötigten Dienste werden angehalten und 

entfernt, die lokale SAM-Datenbank wird erstellt, und der Computer wird zu einem Mitgliedsserver 

herabgestuft. Die einzelnen Auswirkungen hängen davon ab, ob es sich bei dem Domänencontroller 

um einen zusätzlichen DC oder den letzten DC in der Domäne oder Gesamtstruktur handelt. 

Geben Sie zum Entfernen der AD DS von einem Domänencontroller dcpromo an der Eingabeaufforderung 

oder in das Dialogfeld Ausführen ein. Zunächst müssen Sie ermitteln, ob es sich bei dem 

Domänencontroller um den letzten Domänencontroller in der Domäne handelt. In Abbildung 6.9 wird 

die entsprechende Assistentenseite angezeigt. 

Als Nächstes zeigt der Assistent zum Installieren von Active Directory-Domänendiensten eine Liste 

aller auf dem Domänencontroller gefundenen Anwendungsverzeichnispartitionen an. Handelt es sich 

um den letzten Domänencontroller in der Domäne, ist dies die letzte Quelle für diese Anwendungsdaten. 

Sie sollten erwägen, diese Daten zu sichern oder auf andere Weise schützen, da die Verzeichnispartitionen 

durch eine Verwendung des Assistenten zum Installieren von Active Directory-Domänendiensten 

gelöscht werden. Handelt es sich bei dem Domänencontroller, von dem Sie die AD DS 

entfernen, gleichzeitig um einen DNS-Server, sind mindestens zwei Anwendungsverzeichnispartitionen 

zum Speichern der Zonendaten vorhanden. Abbildung 6.10 zeigt ein Beispiel von DNS-Anwendungsverzeichnispartitionen, 

die während der Deinstallation der AD DS gefunden wurden.


Abbildung 6.9 

Die Option zum Entfernen des letzten Domänencontrollers 


Entfernen der DNS-Anwendungsverzeichnispartitionen

Entfernen der AD DS 237 

Nachdem Sie das Entfernen der Anwendungsverzeichnispartitionen bestätigt haben, werden Sie dazu 

aufgefordert, ein neues Kennwort für das lokale Administratorkonto einzugeben. Überprüfen Sie 

abschließend die Zusammenfassungsseite, und schließen Sie den Vorgang zum Entfernen der AD DS 

ab. Um den Vorgang abzuschließen, müssen Sie den Computer neu starten. Nach dem Neustart übernimmt 

der Computer entweder die Rolle eines Mitgliedsservers oder eines eigenständigen Servers. 

Entfernen von zusätzlichen Domänencontrollern 

Der Vorgang zum Entfernen der AD DS von zusätzlichen Domänencontrollern ist weniger kompliziert 

als das Entfernen der AD DS von dem letzten Domänencontroller in einer Domäne oder Gesamtstruktur. 

Der Grund hierfür ist, dass Replikate der Verzeichnispartitionen auf anderen Domänencontrollern 

gespeichert sind, sodass keine Verzeichnisdaten verloren gehen. Beim Entfernen werden 

jedoch Daten in Anwendungspartitionen gelöscht. Stellen Sie deswegen sicher, dass Sie die Anwendung(en) 

nach dem Entfernen der AD DS nicht mehr benötigen, oder wählen Sie einen anderen DC in 

der Domäne als Replikatspeicherort für die Anwendungspartition. Die Deinstallation der AD DS auf 

dem Domänencontroller zieht folgende Änderungen nach sich: 

• Sämtliche Betriebsmasterrollen werden auf andere Domänencontroller in der Domäne verschoben. 

Um die Platzierung von FSMO-Rollen (Flexible Single Master Operations) in Ihrer Umgebung 

besser steuern zu können, sollten Sie die FSMO-Rollen vor der Herabstufung manuell 

verschieben. 

• Der SYSVOL-Ordner und sämtliche Inhalte werden vom Domänencontroller entfernt. 

• Das Objekt NTDS Settings und sämtliche Querverweise werden entfernt. 

• DNS wird aktualisiert, um die SRV-Einträge der Domänencontroller zu entfernen. 

• Die lokale SAM-Datenbank zum Verarbeiten der lokalen Sicherheitsrichtlinie wird erstellt. 

• Sämtliche Active Directory-bezogene Dienste, die bei der Installation der AD DS gestartet werden 

(wie z.B. der Netzwerkanmeldedienst), werden angehalten. 

Schließlich wird der Typ des Computerkontos von Domänencontroller in Mitgliedsserver geändert, 

und das Computerkonto wird vom Container Domain Controllers in den Container Computers verschoben. 

Um die AD DS von einem zusätzlichen Domänencontroller zu entfernen, müssen Sie als ein 

Mitglied der Gruppe Domänen-Admins oder Organisations-Admins angemeldet sein. 

Hinweis Stellen Sie beim Entfernen der AD DS von einem zusätzlichen Domänencontroller sicher, dass 

weitere GCs in der Domäne vorhanden sind. GCs werden für Benutzeranmeldungen benötigt und im Gegensatz 

zu Betriebsmasterrollen nicht automatisch verschoben. 

Entfernen des letzten Domänencontrollers 

Zusätzlich zu den interessanten Aspekten beim Entfernen eines zusätzlichen Domänencontrollers treten 

beim Entfernen des letzten Domänencontrollers in einer Domäne weitere Besonderheiten auf. Am 

wichtigsten hierbei ist, dass das Entfernen des letzten Domänencontrollers in einer Domäne dazu 

führt, dass die Domäne selbst entfernt wird. Ebenso wird auch die Gesamtstruktur entfernt, wenn Sie 

den letzten Domänencontroller in einer Gesamtstruktur entfernen. Unter anderem treten die folgenden 

Besonderheiten beim Entfernen des letzten Domänencontrollers in einer Domäne auf: 

• Der Assistent zum Installieren von Active Directory-Domänendiensten überprüft, ob untergeordnete 

Domänen vorhanden sind. Der Vorgang zum Entfernen der AD DS wird angehalten, wenn 

untergeordnete Domänen gefunden werden.


• Handelt es sich bei der zu entfernenden Domäne um eine untergeordnete Domäne, wird ein 

Domänencontroller in der übergeordneten Domäne kontaktiert, und es werden Replikate der 

Änderungen erstellt. 

• Sämtliche der mit dieser Domäne verknüpften Objekte werden aus der Gesamtstruktur entfernt. 

• Sämtliche Vertrauensstellungsobjekte für übergeordnete Domänencontroller werden entfernt. 

Nachdem die AD DS entfernt worden sind, wird der Typ des Computerkontos von Domänencontroller 

in Mitgliedsserver geändert. Der Server wird anschließend in einer Arbeitsgruppe mit der Bezeichnung 

Arbeitsgruppe platziert. 

Um den letzten Domänencontroller einer untergeordneten Domäne oder Strukturstammdomäne zu 

entfernen, müssen Sie als Mitglied der Gruppe Organisations-Admins angemeldet sein oder im Assistenten 

zum Installieren von Active Directory-Domänendiensten Anmeldeinformationen eines Unternehmensadministrators 

angeben. Um die AD DS vom letzten Domänencontroller in der Gesamtstruktur 

zu entfernen, müssen Sie entweder als Administrator oder als ein Mitglied der Gruppe Domänen- 

Admins angemeldet sein. 

Unbeaufsichtigtes Entfernen der AD DS 

Das Entfernen der AD DS kann ähnlich wie die zuvor erläuterte unbeaufsichtigte Installation automatisiert 

werden. Tatsächlich wird die gleiche Befehlszeile zum Entfernen der AD DS verwendet wie bei 

der Installation. Der einzige Unterschied besteht im Inhalt der Antwortdatei. 

Um die AD DS unbeaufsichtigt zu entfernen, geben Sie an der Befehlszeile oder im Dialogfeld Ausführen 

den Befehl dcpromo /unattend:Antwortdatei ein (wobei Antwortdatei für den Namen der von 

Ihnen erstellten Antwortdatei steht). Die Antwortdatei enthält die Schlüsselwerte, welche die zuvor 

erläuterten Entscheidungen zur Verwendung des Assistenten zum Installieren von Active Directory- 

Domänendiensten für eine Deinstallation der AD DS wiederspiegeln. Ein zu berücksichtigender 

Schlüsselwert ist IsLastDCInDomain, der entweder den Wert Yes oder No aufweisen kann. Ist der 

Wert dieses Schlüssels auf Yes gesetzt, geben Sie damit an, dass Sie die AD DS vom letzten Domänencontroller 

in der Domäne entfernen, woraufhin die Domäne selbst entfernt wird. Im Folgenden 

finden Sie ein Beispiel einer Antwortdatei zum Entfernen eines zusätzlichen Domänencontrollers: 

[DCInstall] 

RebootOnSuccess=Yes 

IsLastDCInDomain=No 

AdministratorPassword=Kennwort 

Password=DomainAdminKennwort 

UserName=Administrator 

Erzwungenes Entfernen eines Windows Server 2008-Domänencontrollers 

Windows Server 2008 bietet ein neues Feature, um das Entfernen eines Domänencontrollers selbst 

dann zu erzwingen, wenn er im Verzeichnisdienst-Wiederherstellungsmodus gestartet wurde. Dieses 

Feature ist vor allem dann nützlich, wenn der Domänencontroller keine Konnektivität mit anderen 

Domänencontrollern aufweist. Da der Domänencontroller während des Vorgangs keine Verbindung 

mit anderen Domänencontrollern herstellen kann, werden die AD DS-Gesamtstrukturmetadaten nicht 

automatisch aktualisiert, wie dies beim gewöhnlichen Entfernen eines Domänencontrollers der Fall 

ist. Stattdessen müssen Sie die Gesamtstrukturmetadaten nach dem Entfernen des Domänencontrollers 

manuell aktualisieren.


Weitere Informationen Im Microsoft Knowledge Base-Artikel 216498 unter http://go.microsoft.com/fwlink/ 

?LinkId=80481 finden Sie Informationen zur Bereinigung der Metadaten. 

Sie können das Entfernen eines Domänencontrollers über die Befehlszeile oder mithilfe einer Antwortdatei 

erzwingen. Führen Sie die folgenden Schritte aus, um das Entfernen eines Windows Server 

2008-Domänencontrollers mithilfe der grafischen Benutzeroberfläche zu erzwingen: 

1. Geben Sie an der Eingabeaufforderung den Befehl dcpromo /forceremoval ein, und drücken Sie 

die EINGABETASTE. 

2. Falls der Domänencontroller FSMO-Rollen hostet oder es sich beim Domänencontroller um einen 

DNS-Server oder einen globalen Katalogserver handelt, werden Warnungen angezeigt. In diesen 

wird erläutert, wie sich das erzwungene Entfernen auf die restliche Umgebung auswirkt. Klicken 

Sie nach dem Lesen jeder Warnung auf Ja. 

Hinweis Sie können die Warnmeldungen bereits vor dem Entfernen unterdrücken, indem Sie an der 

Eingabeaufforderung /demotefsmo:yes eingeben. 

3. Klicken Sie auf der Willkommenseite des Assistenten zum Installieren von Active Directory- 

Domänendiensten auf Weiter. 

4. Überprüfen Sie auf der Seite Entfernen der Active Directory-Domänendienste erzwingen die 

Informationen zum Erzwingen des Entfernens der AD DS sowie die Anforderungen für die Metadatenbereinigung, 

und klicken Sie dann auf Weiter. 

5. Geben Sie auf der Seite Administratorkennwort ein sicheres Kennwort für das lokale Administratorkonto 

ein, und bestätigen Sie es. Klicken Sie anschließend auf Weiter. 

6. Prüfen Sie Ihre Auswahl auf der Seite Zusammenfassung. Klicken Sie auf Zurück, um ggf. notwendige 

Änderungen vorzunehmen. 

7. Klicken Sie zum Entfernen der AD DS auf Weiter. 

8. Aktivieren Sie die Option Nach Abschluss neu starten, um den Server automatisch neu zu starten. 

Alternativ können Sie den Server zum Abschließen des Entfernens der AD DS neu starten, wenn 

Sie dazu aufgefordert werden. 


In diesem Kapitel wurden die wichtigsten Entscheidungen vorgestellt, die Sie während einer AD DS- 

Installation unter Windows Server 2008 treffen müssen. Auch wenn die Mechanismen zum Installieren 

der AD DS unkompliziert sind, sollten Sie die zu treffenden Entscheidungen sorgfältig planen und 

auf Ihren AD DS-Entwurfsplan abstimmen. Die Möglichkeit zum Bereitstellen von RODCs an Remotestandorten 

ist ein leistungsstarkes neues Feature von Windows Server 2008. In diesem Kapitel 

wurde erläutert, wie Sie die RODC-Bereitstellung durchführen, indem Sie zunächst ein DC-Konto 

und die Rollendelegierung erstellen und anschließend den Domänencontroller am Remotestandort 

installieren sowie die Attribute replizieren, deren Speicherung Sie an diesem Remotestandort als 

sicher eingestuft haben. Beim Entfernen der AD DS handelt es ebenfalls sich um ein unkompliziertes 

Verfahren, Sie müssen jedoch die Auswirkungen des Entfernens eines Domänencontrollers auf die 

übrige Verzeichnisdienstinfrastruktur berücksichtigen. In diesem Kapitel wurde außerdem ein neues 

Feature für die AD DS-Installation vorgestellt: das Installieren eines zusätzlichen Domänencontrollers 

oder eines Replikats aus wiederhergestellten Sicherungsdateien.


Dieses Feature verringert den Zeitaufwand erheblich, der beim Installieren eines zusätzlichen Domänencontrollers 

aufgrund der Synchronisierung der Verzeichnispartitionen entsteht. 


Die folgenden Ressourcen enthalten zusätzliche Informationen und Tools im Zusammenhang mit diesem 

Kapitel. 


Die folgenden zusätzlichen Ressourcen enthalten weitere Informationen zur Installation der AD DS 

auf einem Computer unter Windows Server 2008. 

• Weitere Informationen zum Planen Ihres DNS-Namespaces und Entwerfen der AD DS-Struktur 

werden in Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, bereitgestellt. 

• Weitere Informationen zum Installieren und Entfernen der AD DS erhalten Sie im Artikel 

„Schrittweise Anleitung zum Installieren und Entfernen von Active Directory-Domänendiensten 

unter Windows Server 2008” unter http://go.microsoft.com/fwlink/?LinkId=100492. 

• Weitere Informationen zur Bereitstellung der AD DS werden im Artikel „Planning an Active 

Directory Domain Services Deployment” (in englischer Sprache ) unter http://go.microsoft.com/ 

fwlink/?LinkId=100493 bereitgestellt. 

• Wissenswertes zum Bewerten der Hardwareanforderungen von Domänencontrollern in einer Windows 

Server 2008-Domäne finden Sie im Artikel „Planning Domain Controller Capacity“ (in englischer 

Sprache) unter http://go.microsoft.com/fwlink/?LinkId=89027. 

• Weitere Informationen zu AD DS-Funktionsebenen finden Sie im Artikel „Enabling Windows 

Server 2008 Advanced Features for Active Directory Domain Services“ (in englischer Sprache) 

unter http://go.microsoft.com/fwlink/?LinkId=89030. 

• Wissenswertes zur Bereitstellung regionaler AD DS-Domänen wird im Artikel „Deploying Windows 

Server 2008 Regional Domains“ (in englischer Sprache) unter http://go.microsoft.com/ 

fwlink/?LinkId=89029 aufgeführt. 

• Weitere Informationen zur Installation und Konfiguration von DNS-Servern erhalten Sie im Artikel 

„Deploying Domain Name System (DNS)“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId=93656. 

• Weitere Informationen zu zusätzlichen Installationsmethoden für eine neue Windows 

Server 2008-Gesamtstruktur finden Sie unter „Installieren einer neuen Gesamtstruktur unter 

Windows Server 2008“ unter http://go.microsoft.com/fwlink/?LinkId=101704. 

• Wissenswertes zu Tests, die mithilfe des Tools Dcdiag.exe durchgeführt werden können, finden 

Sie im Dokument „Dcdiag Overview” (in englischer Sprache) unter http://go.microsoft.com/ 

fwlink/?LinkId=93660. 

• Weitere Informationen zu Überprüfungsaufgaben, die auf einem Computer mit neu installierter 

Active Directory-Installation ausgeführt werden können, werden im Artikel „Verifying Active 

Directory Installation“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId= 

68736 bereitgestellt. 

• Weitere Informationen zur Installation und Bereitstellung des Windows-Zeitdiensts erhalten Sie 

im Artikel „Administering the Windows Time Service“ (in englischer Sprache) unter http:// 

go.microsoft.com/fwlink/?LinkId=93658.


• Nähere Informationen zu DNS-Serverweiterleitungen werden im Artikel „Using Forwarders to 

Manage DNS Servers“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId= 

93659 aufgeführt. 

• Wissenswertes zur Verwendung von Medien für die Installation des Domänencontrollers finden 

Sie im Artikel „Installing AD DS from Media“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId=93104. 

• Weitere Informationen zu alternativen Installationsmethoden für zusätzliche Windows 

Server 2008-Domänencontroller in einer vorhandenen Gesamtstruktur werden im Artikel „Installing 

an Additional Windows Server 2008 Domain Controller“ (in englischer Sprache) unter http:// 

go.microsoft.com/fwlink/?LinkId=92692. bereitgestellt. 

• Nähere Informationen zur Konfiguration von DNS-Clientdiensten erhalten Sie im Artikel „Configuring 

and Managing DNS Clients“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/ 

?LinkId=93662. 

• Ein Verfahren zur Übertragung der Betriebsmasterrollen wird im Artikel „Übertragen der 

Betriebsmasterrollen“ unter http://go.microsoft.com/fwlink/?LinkId=93664 beschrieben. 

• Wissenswertes zur Platzierung der Betriebsmasterrollen wird im Artikel „Planning Operations 

Master Role Placement“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId= 



• Um zu ermitteln, ob das Netzwerksegment, in dem Sie den Domänencontroller platzieren möchten, 

über eine ausreichende Bandbreite zur Unterstützung des Domänencontrollerdatenverkehrs 

verfügt, können Sie ein Analysetool für Netzwerkframes wie beispielsweise den Netzwerkmonitor 

verwenden. Die aktuelle Version 3.1 dieses Tools kann im Microsoft Download Center unter 

http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8-4213-8d17- 

2f6dde7d7aac&DisplayLang=en. heruntergeladen werden. 

• Weitere Informationen zum Netzwerkmonitor erhalten Sie im englischsprachigen Blog Network 

Monitor unter http://blogs.technet.com/netmon oder auf der englischsprachigen Seite Network 

Monitor im Microsoft Technet unter http://technet2.microsoft.com/WindowsServer/en/library/ 

ad2b59d1-0fb8-45e3-9055-a5aeba8817a91033.mspx?mfr=true.


Migrieren auf die Active Directory-Domänendienste 

243 


Migrationsoptionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 

Festlegen der Migrationsoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

Aktualisieren der Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

Umstrukturieren der Domäne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 

Migration innerhalb der Gesamtstruktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

Konfigurieren von Vertrauensstellungen zwischen Gesamtstrukturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 




In Kapitel 6, „Installieren der Active Directory-Domänendienste“, wurden die wichtigsten Entscheidungen 

vorgestellt, die Sie beim Installieren der AD DS auf einem Computer zu treffen haben, auf 

dem Windows Server 2008 ausgeführt wird. Zum einfacheren Verständnis wurde in diesem Kapitel 

eine „unbelastete“ Umgebung zugrunde gelegt, d.h. eine Umgebung, in der noch keine Verzeichnisdienststruktur 

vorhanden ist. Außerdem wurde in Kapitel 6 die Bedeutung des AD DS-Namespaces 

und des DNS-Namespaces (Domain Name System) hervorgehoben. Höchstwahrscheinlich verfügen 

Organisationen, die zu den AD DS und Windows Server 2008 wechseln (bzw. darauf migrieren), 

bereits über eine Verzeichnisdienstumgebung einschließlich Vorgängerversionen der AD DS. In diesem 

Kapitel wird die Migration auf die Windows Server 2008-AD DS von einer vorhandenen Microsoft-Verzeichnisdienstumgebung 

erläutert – insbesondere von einer Windows 2000 Server- oder Windows 

Server 2003-Active Directory-Plattform. Migrationsszenarien von 

Verzeichnisdiensttechnologien, die nicht von Microsoft stammen, wie beispielsweise Novell Directory 

Services (NDS) oder UNIX-basierten Verzeichnisdienstimplementierungen werden im Rahmen 

dieses Kapitels nicht beschrieben. 

Weitere Informationen Auf der Microsoft-Website werden zahlreiche Ressourcen bereitgestellt, die eine 

Hilfestellung für die Migration von anderen Verzeichnisdienstplattformen auf die AD DS bieten. Weitere Informationen 

zum Migrieren von einer UNIX- oder Linux-Umgebung finden Sie im Artikel „UNIX Migration Project 

Guide“, der in englischsprachiger Version im Microsoft Download Center verfügbar ist. 

Zu Beginn dieses Kapitels werden unterschiedliche Optionen in Bezug auf Aktualisierung und 

Migration für den Wechsel zu Windows Server 2008 und den AD DS vorgestellt. Im Anschluss daran 

werden die wichtigsten Aspekte jeder Option und die zum Durchführen von Aktualisierung oder Migration 

erforderlichen Verfahren beschrieben.

244 Kapitel 7: Migrieren auf die Active Directory-Domänendienste 

Migrationsoptionen 

Bei einer Verzeichnisdienstmigration ist der Startpunkt die Quelldomäne (Punkt A) und der Zielpunkt 

die Zieldomäne (Punkt B), wobei die Quelldomäne Ihre aktuelle Verzeichnisdienstinfrastruktur und 

die Zieldomäne die angestrebte Windows Server 2008-AD DS-Struktur ist. Als Erstes müssen Sie bei 

der Planung einer Migration auf die AD DS entscheiden, auf welche Weise Sie zur Zieldomäne gelangen 

möchten. Tatsächlich gibt es mehrere Möglichkeiten, um mithilfe der sogenannten Migrationsoptionen 

von der Quelldomäne zur Zieldomäne zu gelangen. Die Migrationsoption ist die grundlegende 

Komponente Ihres gesamten Plans, d.h. Ihrer Migrationsstrategie. Ihre Migrationsstrategie umfasst 

die Art und Weise, in der Sie die Migration durchführen möchten, die zu verschiebenden Verzeichnisdienstobjekte 

sowie die Reihenfolge, in der die Objekte verschoben werden. Es hat sich bei Verzeichnisdienstmigrationsprojekten 

bewährt, alle Einzelheiten zur Migrationsstrategie und den auszuführenden 

Aktionen in einem Dokument festzuhalten, dem sogenannten Migrationsplan. 

Die folgenden drei Migrationsoptionen stehen zur Auswahl: 

• Domänenaktualisierung 

• Domänenumstrukturierung 

• Aktualisierung vor Umstrukturierung 

Bei der Domänenaktualisierung führen Sie eine Aktualisierung des Betriebssystems auf einem Domänencontroller 

mit einem älteren Betriebssystem auf Windows Server 2008 durch, oder Sie installieren 

Windows Server 2008-Domänencontroller in einer Windows 2000 Server- oder Windows Server 

2003-Domäne. Nach der Aktualisierung der Domäne auf Windows Server 2008 ist die ursprüngliche 

Domänenumgebung (Punkt A im angenommenen Szenario) nicht mehr vorhanden. Bei der Domänenaktualisierung 

handelt es sich um die einfachste Migrationsmethode. Daher sollten Sie diese Methode 

als Standardmigrationsoption in Erwägung ziehen. 

Die zweite Möglichkeit besteht in einer Domänenumstrukturierung. Bei einer Domänenumstrukturierung 

werden Verzeichnisdienstobjekte von der vorhandenen Verzeichnisdienstplattform (Quelldomäne) 

auf die AD DS (Zieldomäne) kopiert. Dieses Verfahren wird auch als Klonen bezeichnet. Bei 

einer Domänenumstrukturierung sind sowohl die Quell- als auch die Zieldomäne vorhanden. Nachdem 

alle Verzeichnisdienstobjekte von der Quelle auf das Ziel migriert und alle Computer für die Verwendung 

der AD DS konfiguriert wurden, können Quelldomänencontroller entweder herabgestuft 

oder außer Betrieb genommen werden. Wenn sich in Ihrem Unternehmen eine Domänenumstrukturierung 

als geeignetes Migrationsverfahren erweist, sind im Vergleich zu einer Domänenaktualisierung 

einige zusätzliche Aspekte in Betracht zu ziehen. Diese Aspekte werden in den folgenden Abschnitten 

näher erläutert. 

Die dritte Migrationsoption: Das Verfahren der Aktualisierung vor Umstrukturierung wird auch als 

Zweiphasenmigration bezeichnet. Bei der Aktualisierung vor Umstrukturierung aktualisieren Sie 

zuerst die Quelldomäne bzw. -domänen und migrieren anschließend die Konten auf neue oder 

vorhandene Windows Server 2008-Domänen. Bei diesem Verfahren profitieren Sie sowohl von den 

kurzfristigen Vorteilen der Domänenaktualisierung als auch von den langfristigen Vorteilen der 

Domänenumstrukturierung. 

In den folgenden Abschnitten werden die Vor- und Nachteile jedes dieser Migrationsverfahren 

dargestellt.

Das Verfahren der Domänenaktualisierung 

Migrationsoptionen 245 

Eine Domänenaktualisierung, auch als ersetzende Domänenaktualisierung bezeichnet, ist das einfachste 

der drei Migrationsverfahren. Bei einer Domänenaktualisierung wird die vorhandene Domänenumgebung 

in die AD DS konvertiert. Diese Konvertierung wird entweder zeitgleich mit der Aktualisierung 

des Domänencontrollers auf Windows Server 2008 oder während der Installation der neuen 

Windows Server 2008-Domänencontroller in der Zieldomäne durchgeführt. Eine Domänenaktualisierung 

ist unkompliziert, da während des Aktualisierungsvorgangs nicht die Möglichkeit besteht, Änderungen 

an der Domänenstruktur vorzunehmen. Wenn Sie beispielsweise Administrator der Domäne 

NA in der Windows 2000 Server-basierten Domänenumgebung Adatum.com sind, sind Sie per Definition 

auch Administrator der Domäne NA nach der Aktualisierung auf Windows Server 2008. Bei einer 

Domänenaktualisierung haben Sie keine Möglichkeit, Änderungen an der Domänenstruktur vorzunehmen, 

Sie können während der Aktualisierung noch nicht einmal den Domänennamen der Quelldomäne 

ändern. 

Windows NT 4.0-Aktualisierung 

Windows Server 2008 unterstützt keine direkten Serveraktualisierungen von Windows NT 4.0, und 

Sie können keine NT 4.0-Domänencontroller in einem Windows Server 2008-Netzwerk ausführen 

und umgekehrt. Wenn Sie eine Aktualisierung Ihrer Windows NT 4.0-Quelldomänenstruktur auf 

die Windows Server 2008-AD DS durchführen möchten, müssen Sie zuerst Ihre Windows NT 4.0- 

Domänenumgebung auf Windows 2000 Server oder Windows Server 2003 aktualisieren. Nach der 

Migration Ihrer Domäne auf Windows 2000 Server oder Windows Server 2003 können Sie eine Aktualisierung 

der Quelldomäne auf Windows Server 2008 vornehmen. In diesem Kapitel werden ausschließlich 

die Domänenmigrationsszenarien von Windows 2000 Server und Windows Server 2003 

erläutert. 

Wenn Sie das Active Directory-Migrationsprogramm (Active Directory Migration Tool, ADMT) der 

Version 3.1 für Windows Server 2008 verwenden, können Sie versuchen, Migrationsvorgänge durchzuführen, 

die Windows NT 4.0-Domänencontroller einschließen (mit Service Pack 4 oder höher). Da 

es sich jedoch bei Windows NT 4.0 nicht um ein derzeit unterstütztes Produkt handelt, ist dies ein 

nicht unterstütztes Szenario. 

Domänenaktualisierung 

Benutzer, die derzeit Active Directory einsetzen und eine Aktualisierung auf Windows Server 2008 

planen, können ein sehr einfaches Migrationsverfahren nutzen. Viele Änderungen der Verzeichnisdienstarchitektur 

wurden höchstwahrscheinlich implementiert, als Kunden die vorhandene Netzwerkumgebung 

erstellt oder eine Aktualisierung von Windows NT Server 4 vorgenommen haben. Kunden, 

die von Windows 2000 oder Windows Server 2003 auf die Windows Server 2008-AD DS 

migrieren, sind vermutlich hauptsächlich an den neuen AD DS-Features von Windows Server 2008 

interessiert. 

Sie haben zwei Möglichkeiten, um eine Migration mithilfe einer Domänenaktualisierung durchzuführen. 

Zum einen können Sie das Betriebssystem der Domänencontroller von Windows 2000 Server 

oder Windows Server 2003 auf Windows Server 2008 aktualisieren. Nach Abschluss des Aktualisierungsvorgangs 

können Sie die neuen Features in den AD DS nutzen. 

Weitere Informationen Weitere Informationen zu den neuen, in Windows Server 2008 Active Directory 

verfügbaren Features finden Sie in Kapitel 1, „Neuerungen in Active Directory für Windows Server 2008“.


Zum anderen können Sie neue Windows Server 2008-Domänencontroller (DCs) in einer Windows 

2000 Server- oder Windows 2003 Server-Quelldomänenumgebung installieren. Die Verzeichnisdienstobjekte 

werden auf die Windows Server 2008-Domänencontroller repliziert, und Sie können 

unmittelbar oder im Laufe der Zeit die DCs mit dem älteren Betriebssystem außer Betrieb setzen. 

Bei einer Aktualisierung auf Windows Server 2008 sind vor der Migration zwei Schritte auszuführen. 

Bevor Sie die Domäne für Windows Server 2008 vorbereiten, ist eine Vorbereitung der Gesamtstruktur 

erforderlich. Diese beiden Aufgaben werden mithilfe des Tools Adprep.exe durchgeführt. Die 

Vorbereitung von Gesamtstruktur und Domäne vor dem Durchführen der Aktualisierung wird an späterer 

Stelle in diesem Kapitel im Abschnitt „Aktualisieren der Domäne“ erläutert. 

Domänenumstrukturierung 

Bei einer Domänenumstrukturierung wird eine neue Windows Server 2008-Domäne erstellt, und 

AD DS-Objekte werden in diese neue Umgebung migriert. Ein Vorteil dieser Migrationsoption 

besteht darin, dass die ursprüngliche Active Directory-Umgebung während der Erstellung der Zielumgebung 

nicht verändert wird. Ein weiterer Vorteil liegt darin, dass es sich bei der Domänenumstrukturierung 

um ein selektives Verfahren handelt. Im Gegensatz zu einer Domänenaktualisierung können 

Sie auswählen, welche Objekte Sie auf die neue Domäne migrieren möchten. Bei einer Domänenaktualisierung 

haben Sie nur zwei Möglichkeiten: alles oder nichts – alle Objekte in der Domäne werden 

auf Windows Server 2008 und die AD DS aktualisiert. Eine Domänenumstrukturierung ist eine gute 

Gelegenheit, alle doppelten, inaktiven, zum Testen verwendeten oder anderweitig außer Kraft gesetzten 

Benutzer-, Gruppen-, Dienst- und Computerkonten zu entfernen. Diese sind nach der Migration 

auf das neue Domänenmodell nicht mehr vorhanden. Die alten Domänencontroller übernehmen entweder 

weniger Funktionen oder eine neue Rolle, oder sie werden außer Betrieb genommen. 

Benutzer-, Gruppen-, Dienst- und Computerkonten, auch als Sicherheitsprinzipale bezeichnet, werden 

von der NTDS-Datenbank auf die neue AD DS-Datenbank migriert. Zum Durchführen dieser 

Migration bestehen zwei Möglichkeiten: Konten können entweder verschoben oder kopiert werden. 

Beim Verschieben eines Objekts wird der ursprüngliche Sicherheitsprinzipal während des Migrationsverfahrens 

aus der Quelldomäne entfernt. Das Verschieben ist ein zerstörerisches Verfahren, dabei 

werden die Objekte der Quelldomäne nicht für ein Rollback (Notfallwiederherstellung) gesichert. 

Beim Kopieren wird auf Grundlage des Objekts in der Quelldomäne ein neuer, identischer Sicherheitsprinzipal 

in der Zieldomäne erstellt. Das Kopieren stellt das bevorzugte Verfahren zum Übertragen 

von Sicherheitsprinzipalen in die neue Windows Server 2008-Gesamtstruktur dar. Das Verschieben 

von Sicherheitsprinzipalen wird häufiger beim Durchführen einer Migration zwischen zwei 

Windows Server 2008-Domänen innerhalb einer Gesamtstruktur oder zwischen einer Windows 2000/ 

Windows Server 2003-Gesamtstruktur und einer Windows Server 2008-Domäne genutzt, denn bei 

diesen Vorgängen besteht nicht die Möglichkeit zum Kopieren von Sicherheitsprinzipalen. 

So funktioniert es: Verwenden des SID-Verlaufs, um den Ressourcenzugriff beizubehalten 

Wie wird bei der Migration von Benutzerkonten von einem Domänencontroller auf einen anderen 

der Zugriff der Benutzerkonten auf Ressourcen wie beispielsweise Drucker und freigegebene Ordner 

beibehalten?

Migrationsoptionen 247 

Betrachten Sie das folgende Beispiel. Während einer Domänenumstrukturierung migrieren Sie 

mehrere Benutzerkonten von einer Windows Server 2003-Domäne auf eine Windows Server 2008- 

Domäne. Nach Abschluss der Kontomigration weisen Sie die Benutzer an, sich an der neuen 

Domäne anzumelden und ihre Kennwörter zurückzusetzen. Benutzerin X meldet sich erfolgreich 

an der Zieldomäne an und versucht, auf einen zuvor vorhandenen, freigegebenen Ordner auf einem 

Dateiserver zuzugreifen, auf dem Windows Server 2003 ausgeführt wird. Sie konnte mehrere 

Monate auf diesen Ordner zugreifen. Kann Benutzerin X auf diesen Ordner zugreifen? 

Die Antwort auf diese Frage lautet Ja, und zwar aufgrund des Attributs sIDHistory. 

Das Attribut sIDHistory von AD DS-Sicherheitsprinzipalen (wie beispielsweise Benutzer- und 

Gruppenkonten) wird zum Speichern der vorherigen Sicherheitskennungen (Security Identifiers, 

SIDs) von Objekten verwendet. Wenn also in der Windows Server 2003-Domäne die SID von 

Benutzerin X im vorangegangenen Beispiel S-1-5-21-2127521184-1604012920-1887927527- 

324294 lautete, würde nun im Attributfeld sIDHistory der gleiche Wert für das neu erstellte Windows 

Server 2008-Kontoobjekt angezeigt. Wenn Gruppen von einer Windows Server 2003-Domäne 

auf eine AD DS-Domäne migriert werden, wird die SID der Windows Server 2003-Domäne 

ebenfalls für den Wert des Attributs sIDHistory der Gruppe beibehalten. Beim Migrieren von 

Benutzern und Gruppen werden die migrierten Benutzerkonten automatisch den migrierten Gruppen 

in der Windows Server 2008-Domäne zugewiesen. Dies bedeutet, dass die den Gruppen in der 

Windows Server 2003-Domäne zugewiesenen Zugriffsberechtigungen während des Migrationsverfahrens 

erhalten bleiben. Die SID der Quelldomäne wird während der Migration in das Attribut 

sIDHistory verschoben. Die durch den Zieldomänencontroller erstellte SID wird im Attribut 

objectSID des migrierten Kontos platziert. 

Wie bleiben dadurch Zugriffsberechtigungen nach einer Migration bestehen? Versucht Benutzerin 

X auf den freigegebenen Ordner auf dem Windows Server 2003-Dateiserver zuzugreifen, überprüft 

das Sicherheitssubsystem ihr Zugriffstoken, um sicherzustellen, dass sie über die erforderlichen 

Berechtigungen für den Ordner verfügt. Das Zugriffstoken enthält neben der SID von Benutzerin 

X und den SIDs aller Gruppen, denen Benutzerin X angehört, alle SID-Verlaufseinträge 

sowohl für die Benutzer- als auch für die Gruppenkonten. Wird eine Übereinstimmung zwischen 

der freigegebenen Zugriffssteuerungsliste (Discretionary Access Control List, DACL) in der 

Sicherheitsbeschreibung (Security Descriptor, SD) des Ordners und der vorherigen SID (die nun 

über das Attribut sIDHistory in das Sicherheitstoken integriert ist) ermittelt, wird die Berechtigung 

erteilt und Zugriff auf den Ordner gewährt. 

Bei einer Benutzerkontomigration entstehen die meisten Probleme dabei, den Zugriff auf sichere 

Ressourcen sicherzustellen. Wenn Sie wissen, auf welche Weise Berechtigungen nach einer Migration 

beibehalten werden, können Sie als Administrator Probleme beim Ressourcenzugriff effektiv 

beheben. Während des Migrationsverfahrens müssen Sie unter Umständen zusätzliche Maßnahmen 

ergreifen, um sicherzustellen, dass das Attribut sIDHistory ordnungsgemäß aufgefüllt wird. 

Eine ausführlichere Beschreibung dieser Maßnahmen wird im Rahmen der Erläuterungen zum 

Kontomigrationsdienstprogramm bereitgestellt: dem Active Directory-Migrationsprogramm. 

Bei der Domänenaktualisierung spielt der SID-Verlauf keine Rolle. Während einer Domänenaktualisierung 

wird die SID mit den Benutzer- und Gruppenkonten beibehalten. Benutzerin X kann wie 

gewohnt auf Ressourcen zugreifen.


Festlegen der Migrationsoption 

Wenn Sie sich für eine Migrationsoption entscheiden, sollten Sie bedenken, dass diese Entscheidung 

für jede Domäne getroffen werden muss und dass Sie durchaus für unterschiedliche Domänen in Ihrer 

Organisation unterschiedliche Migrationsoptionen verwenden können. Ist Ihr bestehendes Domänenmodell 

nach geografischen Aspekten ausgerichtet, können Sie eine oder zwei der größeren Domänen 

aktualisieren und anschließend eine Umstrukturierung der kleineren Domänen in die größeren vornehmen. 

Dabei können Sie die Verwaltungsautonomie der einzelnen Domänen mithilfe von Organisationseinheiten 

(Organizational Units, OUs) aufrechterhalten. Dies ist ein Beispiel einer Domänenkonsolidierung. 

Nachdem Sie nun die Grundlagen der unterschiedlichen Migrationsoptionen kennengelernt haben, 

werden nun die Entscheidungskriterien für die einzelnen Optionen erläutert. 

Mithilfe der folgenden Fragen können Sie die für Ihre Organisation am besten geeignete Methode 

auswählen: 

• Sind Sie mit Ihrem derzeitigen Domänenmodell zufrieden, d.h. entspricht es den Anforderungen, die Sie derzeit 

aus organisatorischer und geschäftlicher Sicht an die Domänenstruktur stellen? Wenn im Rahmen 

einer Aktualisierung auf Windows Server 2008 keine größeren Änderungen am Domänenmodell 

vorgenommen werden sollen, bietet sich die einfachste Migrationsoption an: die Aktualisierung. 

Der Domänenname sowie alle Benutzer- und Gruppenkonten werden beibehalten. Da Sie bei einer 

Domänenaktualisierung wie bereits erwähnt nur die Entscheidung „alles oder nichts“ treffen können, 

erstellen Sie einfach eine Windows Server 2008-Version Ihrer derzeitigen Verzeichnisdienstimplementierung. 

• Welches Risiko können Sie bei einer Migration auf ein neues Domänenmodell in Kauf nehmen? Die 

Domänenaktualisierung ist nicht nur die einfachste Methode, sondern sie bringt auch das 

geringste Risiko mit sich. Der Prozess wird automatisch während der Betriebssystemaktualisierung 

auf Domänencontrollern durchgeführt, auf denen Vorgängerversionen des Betriebssystems 

ausgeführt werden. Ein Prozess, für den keine Benutzerinteraktion erforderlich ist, bietet wenig 

Fehlerquellen. Auch die Domänenaktualisierung anhand einer Notfallwiederherstellung ist ein 

einfaches Verfahren. Schlägt die Aktualisierung fehl, schalten Sie einfach den aktualisierten 

Domänencontroller aus, beheben die während der Aktualisierung aufgetretenen Fehler und starten 

die Aktualisierung anschließend erneut. 

• Welcher Zeitrahmen ist zum Durchführen der Migration verfügbar? Meist ist der Zeitrahmen nicht der 

entscheidende Faktor bei der Auswahl einer Migrationsoption, für kleinere Organisationen, die für 

das Migrationsprojekt nur begrenzte Ressourcen bereitstellen können, ist dies jedoch unter 

Umständen ein bedeutender Aspekt. Da während einer Domänenaktualisierung im Vergleich zu 

einer Domänenumstrukturierung weniger Schritte erforderlich sind, wird für die vollständige 

Durchführung auch weniger Zeit benötigt. Während einer Domänenumstrukturierung ist zum 

Erstellen und Testen der Zieldomäneninfrastruktur und zum Migrieren aller Konten von der 

Quelle auf die Domäne ein längerer Zeitraum erforderlich. In besonders großen Organisationen 

können unter Umständen nicht alle Objekte gleichzeitig migriert werden, daher ist es nicht 

unüblich, dass eine Domänenumstrukturierung während mehrerer Phasen über einen bestimmten 

Zeitraum hinweg durchgeführt wird. Im Gegensatz dazu handelt es sich bei einer Domänenaktualisierung 

um ein lineares Verfahren, das, sobald es einmal begonnen wurde, auch abgeschlossen 

werden muss.

Festlegen der Migrationsoption 249 

• Welche Systemausfallzeit ist im Verlauf des Migrationsprozesses annehmbar? Ein weiterer Aspekt ist 

der Zeitraum, während dessen sich die Verzeichnisdienste während des Migrationsverfahrens in 

Betrieb befinden müssen. Während einer Domänenaktualisierung werden die Kontoobjekte 

(Benutzer, Gruppen, Computer) zu Objekten der Windows Server 2008-AD DS-Objekten aktualisiert. 

Daher sind diese Kontoobjekte während der Aktualisierung nicht verfügbar. Eine Domänenaktualisierung 

wirkt sich in dem Zeitraum, der zum Abschließen der NOS-Aktualisierung 

erforderlich ist, auf den Zugriff auf Netzwerkressourcen aus. Je nach Größe Ihrer Vorgängerversionsdomäne 

und der Anzahl an vorgesehenen Verifizierungsschritten kann eine solche Aktualisierung 

fast einen vollständigen Tag beanspruchen (sofern alles planmäßig verläuft). Daher sollte 

eine Organisation, die sich für eine Domänenaktualisierung entscheidet, auch die Netzwerkausfallzeiten 

bedenken. 

• Welche Ressourcen sind zum Durchführen der Migration verfügbar? Da es sich bei einer Domänenaktualisierung 

um einen weniger komplexen Vorgang handelt (oder zumindest um einen hochgradig 

automatisierten Vorgang), sind dafür weniger Ressourcen erforderlich. Organisationen, die 

weniger Personal mit der Durchführung der komplexeren Aufgaben einer Domänenumstrukturierung 

betrauen können, entscheiden sich unter Umständen für eine Domänenaktualisierung. 

• Welches Budget ist für das Migrationsprojekt vorhanden? Eine Domänenaktualisierung ist aus finanziellen 

Gesichtspunkten günstiger als eine Domänenumstrukturierung, da die vorhandene Serverhardware 

genutzt werden kann. Es bietet sich jedoch an, bei einer NOS-Aktualisierung auch die 

Hardware für Domänencontroller und weitere anwendungskritische Server (z.B. E-Mail- oder 

Webserver) zu aktualisieren. Entspricht Ihre derzeitige Serverhardware den für die Ausführung 

von Windows Server 2008 bestehenden Anforderungen, können Sie Kosten sparen, wenn Sie eine 

Domänenaktualisierung durchführen. Zum einen müssen Sie keine zusätzlichen Server erwerben, 

die zur Erstellung der für die Umstrukturierung der Domäne erforderlichen neuen Gesamtstrukturumgebung 

benötigt werden. Zu den finanziellen Aspekten zählt auch die Tatsache, dass weniger 

Ressourcen erforderlich sind (einschließlich geringerer vertragsbedingter Ausgaben und Kosten, 

die durch den Einsatz von Vollzeitressourcen entstehen) und weniger Testkosten anfallen (da 

weniger Migrationsaufgaben getestet werden müssen). 

• Auf wie vielen Servern mit Vorgängerversionen müssen nach der Migration serverbasierte Anwendungen 

ausgeführt werden? Entscheiden Sie sich für eine Domänenaktualisierung, wenn auf den Domänencontrollern, 

die Sie aktualisieren möchten, keine Netzwerkdienste oder geschäftskritische 

Anwendungen ausgeführt werden, für die die Vorgängerversion des Netzwerkbetriebssystems 

erforderlich ist. Hierbei kann es sich um Fax- oder Kommunikationsanwendungen, Buchhaltungsanwendungen 

oder andere serverbasierte Anwendungen handeln, die selten aktualisiert werden. 

Sind in Ihrer Organisation solche Dienste und Anwendungen vorhanden, sollten Sie sich die Zeit 

nehmen, all Ihre geschäftskritischen Anwendungen auf einem Windows Server 2008-Computer zu 

testen, um zu ermitteln, ob die Anwendungen ordnungsgemäß funktionieren. Wenn Sie feststellen, 

dass Ihre Anwendungen unter Windows Server 2008 nicht ausgeführt werden können, stehen 

Ihnen mehrere Möglichkeiten zur Verfügung: Sie können die Aktualisierung verschieben, bis eine 

kompatible Anwendungsversion verfügbar oder ein geeigneter Ersatz gefunden ist, Sie können die 

Anwendung vom Domänencontroller auf einen Mitgliedsserver in der Domäne übertragen (sofern 

möglich), oder Sie können den Server, auf dem eine Vorgängerbetriebssystemversion ausgeführt 

wird, erst dann aktualisieren, wenn eine neue Version verfügbar ist. Denken Sie daran, dass ein 

Server mit einem Vorgängerbetriebssystem für unbegrenzte Zeit in Ihrem Windows Server 2008- 

basierten Netzwerk ausgeführt werden kann.


Stellen Sie sich die möglichen Antworten auf diese Fragen auf einer Skala vor, in der das untere Ende 

einer Domänenaktualisierung und das obere Ende einer Domänenumstrukturierung entspricht, wie in 

Abbildung 7.1 dargestellt. 

Niedrig 

Hoch 

A 

k 

t 

u 

a 

l 

i 

s 

i 

e 

r 

u 

n 

g 

Unzufriedenheit mit aktuellem Domänenmodell 

Risikotoleranz 

Zum Abschließen der Migration verfügbare Zeit 

Erforderliche Systembetriebszeit 

Menge an verfügbaren Ressourcen 

Migrationsprojektbudget 

Anzahl an serverbasierten Legacyanwendungen 

U 

m 

s 

t 

r 

u 

k 

t 

u 

r 

i 

e 

r 

u 

n 

g 

Abbildung 7.1 

Die Skala mit Entscheidungskriterien für die Domänenmigrationsoption 

Aktualisieren der Domäne 

Der zweite Schritt der Aktualisierung auf Windows Server 2008 besteht darin, die Domäne auf die 

AD DS zu aktualisieren. (Im ersten Schritt erfolgt die Aktualisierung des Netzwerkbetriebssystems 

[Network Operating System, NOS].) Beim Aktualisieren eines Domänencontrollers, auf dem entweder 

Windows 2000 Server oder Windows Server 2003 ausgeführt wurde, wird nach dem Abschluss 

der NOS-Aktualisierung und dem Neustart des Computers der Assistent zum Installieren der Active 

Directory-Domänendienste gestartet. Sie sollten die Felder im Assistenten zum Installieren der Active 

Directory-Domänendienste entsprechend Ihrem AD DS-Entwurfsdokument ausfüllen. Nach Fertigstellung 

des Assistenten wird der Verzeichnisdienst auf die AD DS für Windows Server 2008 aktualisiert. 

Weitere Informationen Weitere Informationen zum Entwerfen Ihrer Active Directory-Struktur werden in 

Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, bereitgestellt. Weitere Informationen 

zum Verwenden des Assistenten zum Installieren der Active Directory-Domänendienste finden Sie in 

Kapitel 6.

Aktualisieren der Domäne 251 

Während einer Aktualisierung müssen zahlreiche Schritte ausgeführt werden, die sich nach der Windows 

Server-Version richten, von der die Aktualisierung durchgeführt wird. Im nächsten Abschnitt 

wird das Verfahren für die Aktualisierung der Domäne von Windows 2000 Server und anschließend 

von Windows Server 2003 beschrieben. 

Durchführen der Aktualisierung von Windows 2000 Server und Windows 

Server 2003 

Die Aktualisierung einer Domäne von Windows 2000 Server und Windows Server 2003 Active 

Directory auf die Windows Server 2008-AD DS ist kein schwieriger Prozess. Da in Windows 2000 

Server- und Windows Server 2003-basierten Netzwerken Active Directory bereits für Verzeichnisdienste 

verwendet wird, handelt es sich eher um ein Aktualisierungsszenario als um eine Migration. 

Bevor Sie mit der Aktualisierung einer Vorgängerbetriebssystemversion beginnen können, sind einige 

wenige eindeutige Schritte zu beachten. (Im Rahmen der Erläuterungen in diesem Abschnitt bezeichnet 

Vorgängerversion sowohl Windows 2000 Server als auch Windows Server 2003, nicht jedoch 

Windows NT 4.0 oder vorherige Versionen des Windows-Netzwerkbetriebssystems.) 

Insbesondere ist eine „Vorbereitung“ der Windows 2000-Active Directory-Domäne und -Gesamtstruktur 

für eine Aktualisierung auf die Windows Server 2008-AD DS erforderlich. Während dieser Verfahren 

werden die vorhandenen Domänen- und Gesamtstrukturen aktualisiert, um Kompatibilität mit 

den neuen Features von Windows Server 2008 Active Directory zu erreichen. 

Vorbereiten der Gesamtstruktur 

Um die Active Directory-Gesamtstruktur für eine Aktualisierung auf die Windows Server 2008- 

AD DS vorzubereiten, nehmen Sie mithilfe des Verwaltungstools Adprep.exe die erforderlichen Änderungen 

am Active Directory-Schema vor. Denken Sie daran, dass dieses Verfahren abgeschlossen sein 

muss, bevor die Aktualisierung auf Windows Server 2008 für Domänencontroller mit einer Vorgängerversion 

initiiert wird. 

Führen Sie die folgenden Schritte aus, um die Gesamtstruktur für die Aktualisierung des ersten 

Domänencontrollers mit Vorgängerbetriebssystem auf Windows Server 2008 vorzubereiten: 

1. Ermitteln Sie den Server, der als Schemabetriebsmaster fungiert. Öffnen Sie hierfür über die 

Microsoft Management Console (MMC) das Snap-In Active Directory-Schema, klicken Sie mit 

der rechten Maustaste auf den Knoten Active Directory-Schema, und wählen Sie anschließend 

Betriebsmaster. Beachten Sie den im Dialogfeld Schemamaster ändern angezeigten Namen des 

aktuellen Schemabetriebsmasters. 

2. Sichern Sie den Schemabetriebsmaster. Unter Umständen ist eine Wiederherstellung dieses 

Images erforderlich, wenn die Vorbereitung der Gesamtstruktur nicht erfolgreich verläuft. 

3. Trennen Sie die Verbindung des Schemabetriebsmasters mit dem Netzwerk. Stellen Sie die Verbindung 

nicht vor dem Durchführen von Schritt 8 dieses Verfahrens wieder her. 

4. Legen Sie im Schemabetriebsmaster die Windows Server 2008-DVD ein. 

5. Öffnen Sie eine Eingabeaufforderung, wechseln Sie zum entsprechenden DVD-Laufwerk, und 

öffnen Sie den Ordner \I386. 

6. Geben Sie die Zeichenfolge adprep /forestprep ein. Um den Befehl adprep /forestprep auszuführen, 

müssen Sie Mitglied der Gruppe Organisations-Admins in Active Directory sein oder über die 

erforderliche Autorisierung verfügen.


7. Um sicherzustellen, dass der Befehl fehlerfrei ausgeführt wurde, öffnen Sie die Ereignisanzeige, und 

überprüfen Sie das Systemprotokoll auf Fehler oder unerwartete Ereignisse. Wenn Sie Fehler in Verbindung 

mit dem Vorbereitungsverfahren für die Gesamtstruktur ermitteln, beheben Sie diese, bevor 

Sie mit dem nächsten Schritt fortfahren. Können diese Probleme nicht behoben werden, verwenden 

Sie das Active Directory-Diagnosetool (indem Sie im Dialogfeld Ausführen den Befehl dcdiag eingeben), 

um die Funktionsfähigkeit des Domänencontrollers zu prüfen. Wenn die Fehlerbehebung weiterhin 

fehlschlägt, stellen Sie den Schemabetriebsmaster aus der Sicherung wieder her, und untersuchen 

Sie die Schritte zur Fehlerkorrektur, sodass die Gesamtstrukturvorbereitung erfolgreich abgeschlossen 

werden kann. 

8. Wurde der Befehl adprep /forestprep fehlerfrei ausgeführt, stellen Sie die Verbindung zwischen 

dem Schemabetriebsmaster und dem Netzwerk wieder her. 

Dadurch wird die Vorbereitung der Gesamtstruktur für eine Domänenaktualisierung von Windows 

2000 Server oder Windows Server 2003 auf Windows Server 2008 abgeschlossen. Als Nächstes wird 

die Domäne vorbereitet. 

Hinweis Warten Sie mit der Vorbereitung der Domäne, bis die am Schemamaster vorgenommenen Änderungen 

auf den Infrastrukturmaster repliziert wurden. Denken Sie daran, dass die Replikation für Server, die 

sich in unterschiedlichen Standorten befinden, mehr Zeit in Anspruch nimmt. Wenn Sie mit der Domänenvorbereitung 

vor der Replikation der Änderungen beginnen, erhalten Sie eine Fehlermeldung, dass mehr Zeit 

erforderlich ist. 

Vorbereiten der Domäne 

Die Domänenvorbereitung ist mit der Vorbereitung der Gesamtstruktur vergleichbar, ein geringer 

Unterschied besteht jedoch beim Windows 2000 Server-Aktualisierungsszenario. Um diese Aufgabe 

durchzuführen, müssen Sie nicht wie im vorherigen Verfahren den Schemamaster, sondern den Besitzer 

der Infrastrukturmasterrolle ermitteln und vorbereiten. 

Führen Sie die folgenden Schritte aus, um jede Domäne für eine Aktualisierung des ersten Domänencontrollers 

mit Vorgängerbetriebssystem auf Windows Server 2008 vorzubereiten: 

1. Ermitteln Sie den Server, der als Infrastrukturbetriebsmaster fungiert. Öffnen Sie hierfür das Verwaltungstool 

Active Directory-Benutzer und -Computer, klicken Sie mit der rechten Maustaste auf 

den Domänenknoten, und wählen Sie Betriebsmaster. Beachten Sie den im Dialogfeld Betriebsmaster 

auf der Registerkarte Infrastruktur angezeigten Namen des aktuellen Infrastrukturmasters. 

2. Legen Sie auf dem Server, der als Infrastrukturbetriebsmaster fungiert, die Windows Server 2008- 

DVD ein. 

3. Öffnen Sie eine Eingabeaufforderung, wechseln Sie zum entsprechenden DVD-Laufwerk, und 

öffnen Sie den Ordner \I386. 

4. Geben Sie für Windows 2000 Server-Domänencontroller den Befehl adprep /domainprep / 

gpprep ein. Um den Befehl adprep /domainprep /gpprep auszuführen, müssen Sie Mitglied der 

Gruppe Domänen-Admins oder Organisations-Admins in Active Directory sein oder die erforderliche 

Autorisierung erhalten haben. Geben Sie für Windows Server 2003-Domänencontroller den 

Befehl adprep /domainprep ein. Wie zuvor müssen Sie Mitglied der Gruppe Domänen-Admins 

oder Organisations-Admins in Active Directory sein, oder Sie müssen über die erforderliche 

Autorisierung verfügen.

Umstrukturieren der Domäne 253 

Wenn Sie eine Windows Server 2003-Domäne vorbereiten, indem Sie den Befehl adprep / 

domainprep /gpprep ausführen, können Sie die Fehlermeldung unbeachtet lassen, die darauf hinweist, 

dass eine Domänenaktualisierung nicht erforderlich ist. 

5. Um sicherzustellen, dass der Befehl adprep /domainprep fehlerfrei ausgeführt wurde, öffnen Sie 

die Ereignisanzeige, und überprüfen Sie das Systemprotokoll auf Fehler oder unerwartete Ereignisse. 

Wurde der Befehl adprep /domainprep fehlerfrei ausgeführt, haben Sie die Domäne erfolgreich 

für eine Aktualisierung auf Windows Server 2008 vorbereitet. 

Auch in diesem Fall sollten Sie warten, bis die am Infrastrukturmaster vorgenommenen Änderungen 

auf die übrigen Domänencontroller in der Gesamtstruktur repliziert wurden, bevor Sie weitere Domänencontroller 

aktualisieren. Wenn Sie mit der Aktualisierung eines der Domänencontroller vor der 

Replikation der Änderungen beginnen, erhalten Sie eine Fehlermeldung, dass mehr Zeit erforderlich 

ist. 

Nachdem nun die Vorbereitung der Domäne und der Gesamtstruktur für die Aktualisierung auf Windows 

Server 2008 und die AD DS abgeschlossen ist, können Sie mit der eigentlichen Aktualisierung 

beginnen. 

Umstrukturieren der Domäne 

Meist entscheiden sich Organisationen, die ihre Active Directory-Struktur ändern möchten oder müssen, 

für die Migrationsoption der Domänenumstrukturierung. Für eine Domänenumstrukturierung ist 

zuerst die Erstellung der gewünschten Gesamt- und Domänenstruktur und anschließend die Migration 

der vorhandenen AD DS-Objekte in diese neue Struktur erforderlich. Zum Zeitpunkt der Erstellung 

wird die neue Struktur auch als neue Gesamtstruktur bezeichnet. 

Domänenmigrationsstrategien können in zwei Hauptgruppen gegliedert werden: 

• Migration zwischen Gesamtstrukturen Benutzer-, Gruppen- und Computerkonten werden dabei 

zwischen zwei getrennten AD DS-Gesamtstrukturen migriert, hierbei kann es sich um Gesamtstrukturen 

handeln, die auf unterschiedlichen Versionen des Windows Server-Betriebssystems 

gehostet werden. 

• Migration innerhalb einer Gesamtstruktur Benutzer-, Gruppen- und Computerkonten werden zwischen 

zwei Domänen der gleichen AD DS-Gesamtstruktur migriert. 

Die Migration von Active Directory-Objekten (einschließlich Benutzer-, Gruppen- und Computerkonten 

sowie Vertrauensstellungen und Dienstkonten) wird durch die Domänenmigrationstools vereinfacht. 

Für diese Aufgabe sind mehrere Tools verfügbar, die sowohl von Microsoft als auch von anderen 

Softwareherstellern angeboten werden. Im nächsten Abschnitt wird die 

Domänenumstrukturierung mithilfe des Active Directory-Migrationstools (Active Directory Migration 

Tool, ADMT) beschrieben. 

Das Active Directory-Migrationstool vereinfacht das Verfahren zur Umstrukturierung Ihrer 

Verzeichnisdienstumgebung, die erforderlich ist, um die Anforderungen Ihrer Organisation zu erfüllen. 

Sie können das ADMT für die Migration von Benutzern, Gruppen und Computern von Domänen 

mit Vorgängerbetriebssystem auf AD DS-Domänen, für die Migration zwischen Active Directory- 

Domänen in unterschiedlichen Gesamtstrukturen (Migration zwischen Gesamtstrukturen) sowie für 

die Migration zwischen Active Directory-Domänen in der gleichen Gesamtstruktur (Migration innerhalb 

einer Gesamtstruktur) nutzen. Das ADMT führt außerdem die Sicherheitskonvertierung von 

Quell- zu Zieldomänen sowie zwischen AD DS-Domänen in unterschiedlichen Gesamtstrukturen 

durch.


Hinweis Zum Zeitpunkt der Veröffentlichung von Windows Server 2008 war die aktuelle Version des 

ADMT die Version 3.0, die nur auf Windows Server 2003 installiert werden kann. Ein Update des ADMT ist 

insbesondere für Windows Server 2008 (V3.1) geplant. Stellen Sie sicher, dass Sie die Version des Tools 

auswählen, die Migrationen auf die AD DS in Windows Server 2008 unterstützt. Die aktuelle Version des 

ADMT steht im Microsoft Download Center unter http://www.microsoft.com/download zur Verfügung. 

Migration zwischen Gesamtstrukturen 

Wenn Sie eine Domäne mithilfe einer Migration zwischen Gesamtstrukturen umstrukturieren, werden 

die AD DS-Objekte von der Quelldomäne in die Zieldomäne verschoben oder kopiert. Im Gegensatz 

zu einer Domänenaktualisierung haben Benutzer während der Migration Zugriff auf die freigegebenen 

Ressourcen der Quelldomäne, und es ist nur mit sehr kurzen Ausfallzeiten zu rechnen. In diesem 

Abschnitt werden die folgenden Aufgaben und Überlegungen erläutert: 

• Erstellen der neuen Gesamtstruktur 

• Erstellen der Migrationskonten 

• Erstellen der Vertrauensstellungen 

• Installieren des Active Directory-Migrationstools 

• Aktivieren der Überwachung in den Quell- und Zieldomänen 

• Migrieren globaler und domänenlokaler Gruppenkonten 

• Migrieren von Benutzerkonten 

• Ermitteln von Dienstkonten 

• Migrieren von Computerkonten 

• Migrieren von Dienstkonten 

• Außerbetriebsetzen der Quelldomänen 

Als Erstes wird bei einer Migration zwischen Gesamtstrukturen der geeignete Punkt B erstellt, auf 

den die Konten migriert werden. 

Erstellen der neuen Gesamtstruktur 

Die neue Gesamtstruktur umfasst die Windows Server 2008-Zieldomäne, in die Ihre vorhandenen 

Konten migriert werden, d.h. Punkt B der Migration von A nach B. Eine Domänenumstrukturierung 

bietet die Gelegenheit, die optimale Domänenumgebung für Ihre Organisation zu erstellen. Dieser 

Schritt sollte am Ende eines vollständigen AD DS-Entwurfsverfahrens eingeplant werden, wenn alle 

Komponenten Ihrer AD DS-Struktur in Ihrem Entwurfsdokument bereits eindeutig definiert sind. 

Weitere Informationen zum Entwurfsverfahren werden in Kapitel 5 bereitgestellt. Nach der Implementierung 

Ihrer Zieldomänenstruktur sind zahlreiche Schritte zur Vorbereitung der Kontenmigration 

erforderlich. 

Erstellen der Migrationskonten 

Es empfiehlt sich, in der neuen Gesamtstruktur als Erstes das Benutzerkonto zu erstellen, das zum 

Durchführen der Migration erforderlich ist. Indem Sie ein spezielles Benutzerkonto für die Migration 

erstellen, können Sie sicherstellen, dass das Konto die erforderlichen Sicherheitsanforderungen für die 

Durchführung der anfallenden Aufgaben bei einer Domänenumstrukturierung erfüllt.


Im Rahmen der empfohlenen Vorgehensweisen melden Sie sich aus Sicherheitsgründen nicht mit dem 

Administratorkonto an. Sie können beispielsweise ein neues Benutzerkonto (z.B. Migrator) oder mehrere 

Konten (z.B. Migrator1, Migrator2 usw.) erstellen, wenn Sie die Migration von mehreren vertrauenswürdigen 

Administratoren durchführen lassen möchten. Auf diese Weise können Sie die von jedem 

Kontobesitzer durchgeführten Ereignisse nachverfolgen, und Sie benötigen kein freigegebenes Konto 

mit Administratorrechten. 

Für die Migration von Benutzer-, Gruppen- und Dienstkonten muss das Konto Mitglied der Gruppe 

Domänen-Admins in der Zieldomäne sein, wenn Sie mithilfe des SID-Verlaufs den Ressourcenzugriff 

beibehalten möchten. Das Konto sollte außerdem Mitglied der Gruppe Administratoren in der Vorgängerversions-Quelldomäne 

sein. 

Erstellen der Vertrauensstellungen 

Da während des Migrationsverfahrens Administratorrechte für Konten in einer anderen Domäne 

erforderlich sind, müssen Sie mehrere Vertrauensstellungen erstellen, um die Konten von der Quelldomäne 

bzw. den Quelldomänen auf die Zieldomäne migrieren zu können. Erstellen Sie zwischen der 

Windows Server 2008-Zieldomäne und den Vorgängerversions-Quelldomänen eine unidirektionale 

Vertrauensstellung von jeder der Quelldomänen (vertrauend) zur Zieldomäne (vertraut). 

Nach dem Erstellen dieser Vertrauensstellungen validieren Sie diese mithilfe des Verwaltungstools 

Active Directory-Domänen und -Vertrauensstellungen sowohl in der Windows Server 2008-Zieldomäne 

als auch in den Vorgängerversions-Quelldomänen. 

Installieren des Active Directory-Migrationstools 

Mit dem ADMT können Sie sowohl Migrationen zwischen Gesamtstrukturen (Verschieben von Konten 

von einer Gesamtstruktur in eine andere) als auch Migrationen innerhalb einer Gesamtstruktur 

(Verschieben von Konten innerhalb einer Gesamtstruktur) durchführen. Das ADMT stellt sowohl eine 

grafische Benutzeroberfläche (Graphical User Interface, GUI) als auch eine Skriptingschnittstelle 

bereit und sollte auf dem Windows Server 2008-Zieldomänencontroller installiert werden. 

Das ADMT unterstützt die folgenden Aufgaben zum Durchführen Ihrer Domänenmigration: 

• Benutzerkontenmigration 

• Gruppenkontenmigration 

• Computerkontenmigration 

• Dienstkontenmigration 

• Vertrauensstellungsmigration 

• Exchange-Verzeichnismigration 

• Sicherheitskonvertierung migrierter Computerkonten 

• Berichterstellung zum Anzeigen der Ergebnisse von Migrationsereignissen 

• Funktionen zum Rückgängigmachen der letzten Migration und zum erneuten Durchführen der 

letzten Migration 

Nach der Installation des ADMT können Sie das Migrationstool über den Startmenüordner Verwaltung 

aufrufen . Das ADMT startet als MMC-Snap-In mit allen im Menü Aktion verfügbaren Assistenten.


Aktivieren der Überwachung in den Quell- und Zieldomänen 

Für den Domänenumstrukturierungsprozess muss die Überwachung der erfolgreichen und fehlgeschlagenen 

Kontoverwaltungsvorgänge sowohl für die Quell- als auch für die Zieldomänen aktiviert 

werden. 

Führen Sie die folgenden Schritte durch, um die Überwachung der Windows Server 2008-Zieldomäne 

und der Vorgängerversions-Quelldomäne zu aktivieren: 

1. Öffnen Sie das Verwaltungsprogramm Gruppenrichtlinienverwaltung, und erweitern Sie den Container 

Domain Controllers. 

2. Klicken Sie mit der rechten Maustaste auf das GPO Default Domain Controllers Policy, und wählen 

Sie Bearbeiten. 

3. Erweitern Sie Default DomainControllers Policy\Computerkonfiguration\Richtlinien\ 

Windows-Einstellungen\Sicherheitseinstellugen\Lokale Richtlinien\Überwachungsrichtlinie, 

doppelklicken Sie auf Kontenverwaltung überwachen, und aktivieren Sie die beiden Optionen 

Erfolgreich und Fehlgeschlagen. 

4. Erzwingen Sie die Replikation dieser Änderung auf alle Domänencontroller in der Domäne, oder 

warten Sie, bis die Replikation der Änderung automatisch durchgeführt wird. 

Migrieren globaler und domänenlokaler Gruppenkonten 

Bei der Migration von Konten werden zuerst die Konten globaler Gruppen und anschließend Benutzerkonten 

migriert. Wenn Benutzerkonten später auf die Zieldomäne migriert werden, bleiben die 

Gruppenmitgliedschaften und auch der Zugriff auf Ressourcen erhalten. Beim Migrieren globaler 

Gruppen von einer Vorgängerbetriebssystemdomäne auf Windows Server 2008 wird für die neue globale 

Gruppe eine neue SID erstellt. Die SID der Quelldomäne wird dem Attribut sIDHistory für jedes 

neue Gruppenobjekt hinzugefügt. Wie Sie sich sicher erinnern, können Benutzer durch die Übernahme 

der SID aus der Quelldomäne im Feld IDHistory weiterhin auf Ressourcen auf den noch nicht 

migrierten Quelldomänen zugreifen. 

Durch das Kopieren globaler Gruppen (mithilfe des ADMTs) können Sie in der Zieldomäne die Gruppenstruktur 

in der Ihrem Active Directory-Entwurf entsprechenden Untergliederung erstellen. Indem die 

Benutzerkonten später migriert werden, werden sie automatisch den Gruppen hinzugefügt, denen sie 

bereits in der Quelldomäne als Mitglieder angehörten. 

Das Verfahren zum Migrieren globaler Gruppen von der Quell- zur Zieldomäne mithilfe des ADMT- 

Assistenten zum Migrieren von Gruppenkonten ist unkompliziert. Führen Sie zum Migrieren globaler 

Gruppen mithilfe des ADMT-Assistenten zum Migrieren von Gruppenkonten folgende Schritte durch: 

1. Ermitteln Sie die Quell- und Zieldomänen. Wenn die Domänennamen in der Dropdownliste nicht 

angezeigt werden, können Sie sie eingeben. 

2. Wählen Sie die globalen Gruppen der Quelldomäne, die Sie auf Windows Server 2008 migrieren 

möchten. 

3. Wählen Sie die OU, der Sie die globalen Gruppen in der Zieldomäne hinzufügen möchten. 

Hinweis Mit dem ADMT können Sie nur eine einzelne OU als Zielcontainer für die migrierten Konten der 

globalen Gruppen auswählen. Beachten Sie dies bei der Planung der Migration Ihrer globalen Gruppen. 

Unter Umständen möchten Sie nicht alle globalen Gruppen der Quelldomäne auswählen, sondern nur die 

Gruppen, die in eine bestimmte OU migriert werden sollen. Sie können anschließend erneut den Assistenten 

zum Migrieren von Gruppenkonten ausführen, um die Gruppen zu migrieren, die in einer anderen OU 

gespeichert werden sollen.


4. Wählen Sie die gewünschten Gruppenoptionen. Dies umfasst auch die Entscheidung, ob die Gruppenmitglieder 

(d.h. die Benutzerkonten) gleichzeitig mit den Gruppen kopiert werden sollen. 

Standardmäßig werden Gruppenmitglieder nicht kopiert. Das gleichzeitige Kopieren von Gruppenmitgliedern 

während der Gruppenmigration kann in kleineren Organisationen sehr rasch 

durchgeführt werden, und die nach Gruppen gegliederte Migration ist ebenfalls ein sinnvoller 

Ansatz. In größeren Organisationen enthalten globale Gruppen oberster Ebene (wie z.B. die Gruppe 

Angestellte) zu viele Benutzer, und daher kann keine Migration für alle Mitglieder gleichzeitig 

durchgeführt werden. 

Hinweis Nachdem die Gruppenmitglieder in mehreren Vorgängen migriert wurden, führen Sie eine letzte 

globale Gruppenmigration durch, um sicherzustellen, dass alle kürzlich in der Quelldomäne vorgenommenen 

Änderungen an den Mitgliedschaften globaler Gruppen in die Zieldomäne übernommen werden. Sie 

können globale Gruppen mithilfe der Konsole Active Directory Migration Tool erneut migrieren, indem Sie die 

Befehlszeilenoption des ADMTs oder ein Skript verwenden. 

Nach den globalen Gruppen können Sie mithilfe des Assistenten zum Migrieren von Gruppenkonten 

mit der Migration der domänenlokalen Gruppen fortfahren. Nachdem alle Gruppen auf Windows Server 

2008 migriert wurden, beginnen Sie mit der Migration der Benutzerkonten. 

Migrieren von Benutzerkonten 

Es ist nicht erforderlich, alle Benutzerkonten auf einmal zu migrieren. Es empfiehlt sich sogar, die 

Reihenfolge und die zeitliche Abfolge der Benutzermigration sorgfältig zu planen. Da Sie während 

des Migrationsverfahrens den Zugriff auf die domänenbasierten Ressourcen in der Vorgängerversions-Quelldomäne 

aufrechterhalten möchten, kann sich das Migrationsverfahren über Tage, Wochen 

oder auch Monate erstrecken. 

Während des ersten Schritts der Benutzerkontenmigration werden die zu migrierenden Benutzer 

sowie der Zeitpunkt für die Migration festgelegt. Der eigentliche Migrationsprozess für Benutzerkonten 

ist mit der Migration globaler Gruppenkonten vergleichbar. 

Führen Sie zum Migrieren von Benutzerkonten mithilfe des ADMT-Assistenten zum Migrieren von 

Benutzerkonten folgende Schritte durch: 

1. Wählen Sie die Quell- und Zieldomänen. 

2. Wählen Sie die zu migrierenden Benutzerkonten der Vorgängerversions-Quelldomäne. 

3. Wählen Sie die Ziel-OU in der Windows Server 2008-Zieldomäne. 

4. Legen Sie fest, ob Sie die Kennwörter der Benutzerkonten ebenfalls migrieren möchten. Wenn Sie 

das ADMT verwenden, haben Sie folgende Möglichkeiten: 

Erstellen eines neuen, komplexen Kennworts In diesem Fall wird ein Textdokument (als durch 

Komma getrennte Wertdatei [.csv]) erstellt, in dem Benutzernamen den neuen Kennwörtern 

zugeordnet werden. Ihre Aufgabe besteht dann darin, den migrierten Benutzern die neuen 

Kennwörter mitzuteilen. 

Festlegen eines Kennworts, das dem Benutzernamen entspricht In diesem Fall wird für das 

Kennwort der gleiche Wert wie für den Benutzernamen festgelegt. Da sowohl diese als auch 

die zuvor erwähnte Option ein Sicherheitsrisiko darstellen, wird das Attribut Benutzer muss 

Kennwort bei der nächsten Anmeldung ändern für die migrierten Benutzer in der Zieldomäne 

festgelegt.


Migrieren von Kennwörtern Durch Auswahl dieser Option werden die Benutzerkennwörter von 

der Quelldomäne auf die Zieldomäne migriert. Wenn Sie diese Option wählen möchten, müssen 

Sie den Domänencontroller der Kennwortmigrationsquelle ermitteln. 

Hinweis Bei dem Domänencontroller der Kennwortmigrationsquelle handelt es sich um den Domänencontroller 

in der Quelldomäne, der durch die Installation der Kennwortmigrations-DLL als Kennwortexportserver 

(Password Export Server, PES) konfiguriert wurde. Bei der Kennwortmigration handelt es 

sich um eine eigene Komponente des ADMTs, die auf jedem beliebigen Domänencontroller in der Quelldomäne 

installiert werden kann. Um die Kennwortmigrations-DLL auf dem Quelldomänencontroller zu 

installieren, öffnen Sie den Ordner \%systemroot%\windows\ 

ADMT\PWDMIG, und doppelklicken Sie auf die Datei Pwdmig.msi. Der PES verwaltet eine Datenbank 

der Benutzerkennwörter der Quelldomäne und baut einen sicheren Kommunikationskanal mit der Zieldomäne 

auf, um diese Kennwörter migrieren zu können. 

5. Verwalten Sie den Kontostatus mithilfe der Optionen für die Kontoaktualisierung. Mithilfe des 

ADMTs können Sie den Übergang vom Quellkonto zum Zielkonto auf der Seite Account Transition 

Options verwalten. Dadurch können Sie den Status des Zieldomänenkontos (aktiviert, deaktiviert 

oder identisch mit Quelle) und des Quelldomänenkontos (deaktiviert oder aktiviert für eine 

konfigurierbare Anzahl an Tagen) steuern. 

In einem gängigen Szenario werden mehrere Benutzerkonten zum Migrieren zusammengefasst, 

jedoch erst nach Abschluss der Migration aktiviert. Zu diesem Zeitpunkt können Sie alle Benutzerkonten 

programmgesteuert aktivieren und in die Zieldomäne übernehmen. Aus Sicherheitsgründen 

sollte ein Konto nicht gleichzeitig in der Quell- und der Zieldomäne aktiviert sein. Wenn Sie Benutzern 

die Anmeldung an der Windows Server 2008-Domäne direkt im Anschluss an die Migration 

ihrer Konten ermöglichen möchten, sollten Sie das ADMT zum Deaktivieren des Quelldomänenkontos 

während der Migration verwenden. Wenn Sie Benutzern während der Migration jedoch den Rückgriff 

auf die Quelldomäne ermöglichen möchten, sollten Sie das ADMT verwenden, um das Quelldomänenkonto 

erst einige Tage nach Ausführung des ADMTs zu deaktivieren. 

Ermitteln von Dienstkonten 

Bei Dienstkonten handelt es sich um spezielle Benutzerkonten, die zum Betreiben von Diensten auf 

Computern verwendet werden, auf denen Windows 2000 Server, Windows Server 2003 und Windows 

Server 2008 ausgeführt werden. Ein Großteil der Dienste wird mit den Konto Lokale Sicherheitsautorität 

(Local Security Authority, LSA) ausgeführt. Beim Migrieren der Quelldomäne müssen 

Sie zuerst alle Dienste ermitteln, die entsprechend ihrer Konfiguration nicht mit der LSA ausgeführt 

werden. 

Beim Migrieren von Dienstkonten handelt es sich um ein in zwei Stufen gegliedertes Verfahren. 

Zuerst müssen die Dienstkonten ermittelt werden. Anschließend können die ermittelten Dienstkonten 

nach der Migration der Computer, auf denen ein Vorgängerversions-Betriebssystem ausgeführt wird, 

auf die Windows Server 2008-Zieldomäne migriert werden. 

Führen Sie die folgenden Schritte aus, um mithilfe des ADMTs die Dienstkonten zu ermitteln, die in 

der Quelldomäne betrieben werden: 

1. Öffnen Sie den Assistenten zum Migrieren von Dienstkonten. 

2. Wählen Sie die Quell- und Zieldomänen.


3. Wählen Sie in der Quelldomäne alle Computer, die Sie in die Ermittlung der Dienstkonten einbeziehen 

möchten. Um diese Aufgabe abzuschließen, sollten Sie die vor der Migration erstellte 

Dokumentation Ihrer vorhandenen Domänenumgebung lesen. 

4. Beenden Sie den Assistenten zum Migrieren von Dienstkonten. 

Zu diesem Zeitpunkt hat der Assistent alle Dienstkonten ermittelt, die auf den von Ihnen ermittelten 

Computern ausgeführt werden. Diese Informationen werden in der ADMT-Datenbank gespeichert, bis 

sie später für die tatsächliche Migration dieser Konten benötigt werden. Die Migration der Dienstkonten 

wird nach der Migration der Computerkonten durchgeführt. 

Migrieren von Computerkonten 

Die Computerkonten, die sich in der Quelldomäne befinden, umfassen alle Mitgliedsserver mit 

Vorgängerversionen sowie alle Computer, auf denen Windows 2000 Professional, Windows XP Professional 

und Windows Vista Business Edition oder höher ausgeführt wird. Bei der Migration von 

Computerkonten werden alle Computerkonten von der Quelldomäne in eine OU in der Zieldomäne 

geklont. 

Führen Sie zum Migrieren von Computerkonten mithilfe des ADMTs die folgenden Schritte durch: 

1. Öffnen Sie den Computermigrations-Assistenten. 


3. Wählen Sie in der Quelldomäne die zu migrierenden Computerkonten. 

4. Wählen Sie in der Zieldomäne die OU, in die Sie die Computerkonten migrieren möchten. 

5. Wählen Sie alle Computerobjekte, für die Sie die Sicherheit von zuvor von der Quell- auf die 

Zieldomäne migrierten Konten konvertieren möchten. Bei diesem Verfahren werden die freigegebenen 

Zugriffssteuerungslisten (Discretionary Access Control Lists, DACLs) für die Ressourcen 

auf den migrierten Computern mit den neuen SIDs der migrierten Gruppen- und Benutzerkonten 

der Zieldomänencomputer aktualisiert. Folgende Objekte sind verfügbar: 

Dateien und Ordner 

Lokale Gruppen 

Drucker 

Registrierung 

Freigaben 

Benutzerprofile 

Benutzerrechte 

Hinweis Wenn Sie die Sicherheitskonvertierung für diese aufgeführten Objekte nicht während der 

Ausführung des Computermigrations-Assistenten durchführen möchten, können Sie später im ADMT 

den Sicherheitskonvertierungs-Assistenten verwenden. Die wichtigste Komponente des Sicherheitskonvertierungs-Assistenten 

entspricht der Seite Translate Objects des Computermigrations-Assistenten. Auf 

der ersten Seite des Sicherheitskonvertierungs-Assistenten werden Sie gefragt, ob Sie die Sicherheit 

zuvor migrierter Objekte konvertieren möchten. Wenn Sie den Sicherheitskonvertierungs-Assistenten 

nach der Migration von Computerkonten ausführen, wählen Sie die Option Zuvor migrierte Objekte. 

6. Konfigurieren Sie den Neustart des migrierten Computers. Um ein Computerkonto von einer 

Domäne auf eine andere migrieren zu können, übergibt das ADMT die Durchführung der Änderungen 

am Computer an einen Agent.


Um das Verfahren zum Migrieren von Computerkonten abzuschließen, muss der migrierte Computer 

neu gestartet werden. Mit dem ADMT können Sie den Zeitrahmen konfigurieren, der zwischen 

dem Beenden des Assistenten und dem Computerneustart liegen soll. 

7. Beenden Sie den Computermigrations-Assistenten. Wenn der Assistent beendet ist, klicken Sie 

auf Protokoll anzeigen, um zu überprüfen, ob der Verteiler-Agent das Verfahren erfolgreich abgeschlossen 

hat. Bei diesem Agent handelt es sich um die Komponente zum Aktualisieren der 

Domänenmitgliedschaft des Computers und zum anschließenden Neustarten des Computers. Das 

Verteilerprotokoll ist hilfreich für die Problembehandlung für fehlgeschlagene Computerkontenmigrationen. 

Migrieren von Dienstkonten 

Nachdem die Computerkonten auf die Zieldomäne migriert wurden, können Sie die zweite Phase des 

Dienstkontenmigrationsverfahrens durchführen. Vor dem Migrieren der Computerkonten haben Sie 

bereits die Dienstkonten ermittelt, die auf Mitgliedsservern zum Ausführen von Diensten verwendet 

wurden. An dieser Stelle des Verfahrens führen Sie die Migration dieser Dienstkonten von der Quelldomäne 

auf die Windows Server 2008-Zieldomäne durch. Durch dieses Verfahren wird sichergestellt, 

dass alle Dienste, die nicht über die LSA ausgeführt werden, nach der Migration des Mitgliedsservers 

auf die Zieldomäne weiterhin die erforderlichen Dienste starten. 

Führen Sie zum Migrieren der Dienstkonten mithilfe des ADMTs die folgenden Schritte durch: 

1. Öffnen Sie den Assistenten zum Migrieren von Benutzerkonten. 


3. Wählen Sie die zu migrierenden Dienstkonten. 

Hinweis Wenn Sie sich nicht mehr an den Kontonamen des zuvor ermittelten Dienstkontos erinnern 

können, können Sie den Inhalt der Protokolldatei des Verteiler-Agents, die Datei Dctlog.txt, überprüfen, 

die sich im Ordner %userprofile%\Temp befindet. Wenn Sie beispielsweise an dem Windows Server 

2008-Computer als Migrator1 angemeldet sind, befindet sich die Datei unter C:\Benutzer\Migrator1\ 

Temp. 

4. Wählen Sie in der Zieldomäne die OU, in die Sie die Dienstkonten migrieren möchten. 

5. Für die Dienstkontenmigration wird die komplexe Kennworterstellung verwendet. Unabhängig von 

der von Ihnen auf der Seite Password Options gewählten Kennwortmigrationsoption verwendet das 

ADMT immer die komplexe Kennwortoption. Das ADMT erkennt, dass es sich bei dem von 

Ihnen migrierten Benutzerkonto um ein Dienstkonto handelt, und daher erteilt es dem Konto die 

Berechtigung zum Anmelden als Dienst. 

Hinweis Wurden den von Ihnen migrierten Dienstkonten lokale Rechte (beispielsweise Anmelden als 

Dienst als Mitglied der lokalen Administratorengruppe) nur durch die Mitgliedschaft in einer lokalen Gruppe 

vererbt, müssen Sie dies durch Ausführung des Sicherheitskonvertierungs-Assistenten beheben. Wählen 

Sie in diesem Fall auf der Seite Translate Objects des Sicherheitskonvertierungs-Assistenten die Objekte 

Local Group und User Rights für die migrierten Mitgliedsserver, die die lokalen Gruppen umfassen, von 

denen die Rechte vererbt wurden. Auf diesem Computer wird die Sicherheitskonvertierung durchgeführt.

Migration innerhalb der Gesamtstruktur 261 

Außerbetriebsetzen der Quelldomänen 

Nachdem die Migration aller Quelldomänen auf Windows Server 2008 und die AD DS abgeschlossen 

ist, können Sie die Vorgängerversionsdomänen außer Betrieb setzen. Zu diesem Zeitpunkt handelt 

es sich bei den verbleibenden Computern in den Quelldomänen um Domänencontroller. Wenn im 

Rahmen Ihres Migrationsplans das Verschieben dieser Domänencontroller auf die Windows Server 

2008-Zieldomäne erforderlich ist, können Sie diese Computer auf die Zieldomäne verschieben. Am 

einfachsten können Sie diese Computer verschieben, indem Sie zuerst sicherstellen, dass alle benötigten 

Daten von diesen Servern entfernt wurden, und anschließend eine Neuinstallation des Windows 

Server 2008-Betriebssystems durchführen. 

Die abschließende Aufgabe besteht darin, alle zum Durchführen der Migration erstellten Vertrauensstellungen 

zu entfernen. Wählen Sie mithilfe des Verwaltungstools Active Directory-Domänen und 

-Vertrauensstellungen jede der Vertrauensstellungen der Vorgängerversions-Quelldomänen, die nun 

außer Betrieb gesetzt sind, und klicken Sie auf Entfernen. 

Migration innerhalb der Gesamtstruktur 

Bei der dritten zu erläuternden Migrationsoption handelt es sich um das Verfahren Aktualisierung vor 

Umstrukturierung bzw. um die Migration innerhalb einer Gesamtstruktur. Wie bereits zuvor in diesem 

Kapitel erwähnt, ist zu Beginn der Aktualisierung vor Umstrukturierung eine Aktualisierung der 

Vorgängerversions-Domänencontroller auf Windows Server 2008 erforderlich (bei der die ursprüngliche 

Domänenhierarchie beibehalten wird). Anschließend wird eine Domänenumstrukturierung vorgenommen, 

bei der die AD DS-Objekte von den aktualisierten Quelldomänen auf die Zieldomäne 

bzw. die Zieldomänen migriert werden. Nachdem Sie bereits die Abschnitte in diesem Kapitel gelesen 

haben, in denen Domänenaktualisierungen und die Domänenumstrukturierung erläutert werden, 

sind Sie mit den erforderlichen Aufgaben zum Durchführen der Migration über das Verfahren Aktualisierung 

vor Umstrukturierung auf die Windows Server 2008-AD DS bereits vertraut. Sie werden 

jedoch feststellen, dass sich die Kontomigration in Szenarien innerhalb einer Gesamtstruktur aufgrund 

der Sicherheitsanforderungen für Windows Server 2008 von der Kontomigration in Szenarien 

zwischen Gesamtstrukturen unterscheidet. 

Das Verfahren zum Umstrukturieren der Domäne nach einer Aktualisierung auf Windows Server 

2008 muss nicht unmittelbar nach der Aktualisierung durchgeführt werden. Die Domänenumstrukturierung 

kann einfach als Domänenverwaltungsfunktion betrachtet werden, sodass Sie Ihre AD DS- 

Struktur an die Änderungen Ihrer geschäftlichen Anforderungen anpassen können. In diesem 

Abschnitt werden die Unterschiede zwischen einer Migration innerhalb einer Gesamtstruktur und der 

bereits beschriebenen Migration zwischen Gesamtstrukturen erläutert. In diesem Abschnitt wird kein 

bestimmtes Tool erläutert, da die technischen Unterschiede unabhängig vom verwendeten Migrationstool 

bestehen. 

Folgende Unterschiede bestehen zwischen einer Migration innerhalb einer Gesamtstruktur und einer 

Migration zwischen Gesamtstrukturen: 

• Bei einer Migration innerhalb einer Gesamtstruktur müssen Konten für die Beibehaltung des 

Ressourcenzugriffs mithilfe des SID-Verlaufs verschoben und nicht geklont werden. Beim Verschieben 

von Kontoobjekten innerhalb einer Gesamtstruktur handelt es sich jedoch um ein zerstörerisches 

Verfahren, die Benutzer-, Gruppen- und Computerkonten werden in der Quelldomäne 

gelöscht, sobald die neuen Konten in der Zieldomäne erstellt sind. Daher können Sie die „Parallelumgebung“ 

nicht beibehalten, auf die während eines Umstrukturierungsszenarios zwischen 

Gesamtstrukturen einfach zurückgegriffen werden kann.


• Bei einer Migration innerhalb einer Gesamtstruktur müssen Sie zum Beibehalten der Gruppenmitgliedschaftsregeln 

Benutzerkonten und die Gruppen, denen die Benutzer angehören, gleichzeitig 

verschieben. Dieses Verfahren wird als geschlossener Satz bezeichnet. Das ADMT nimmt jedoch 

keine Berechnung eines vollständigen geschlossenen Satzes vor, daher müssen Sie beim Migrieren 

von Benutzern, die Mitglieder globaler Gruppen sind, besonders vorsichtig vorgehen. Wenn 

Sie eine Gruppe migrieren, deren Mitgliedschaft ein Benutzerkonto umfasst, das Mitglied einer 

anderen globalen Gruppe ist, und wenn diese globale Gruppe umgekehrt kein Mitglied einer der 

zu diesem Zeitpunkt migrierten Gruppen ist, bricht die Mitgliedschaft zwischen dem Benutzerkonto 

und der globalen Gruppe, die nicht in die Migration integriert ist. Bei anderen Gruppentypen 

(wie z.B. universelle Gruppen) besteht dieses Problem nicht, da sie Mitglieder umfassen 

können, die sich außerhalb ihrer Domänen befinden. 

Konfigurieren von Vertrauensstellungen zwischen Gesamtstrukturen 

Als Alternative zum Durchführen einer Domänenumstrukturierung können Sie Vertrauensstellungen 

zwischen Gesamtstrukturen bzw. Gesamtstrukturvertrauensstellungen von einer Windows Server 

2008-Gesamtstruktur nutzen, um auf Ressourcen in einer anderen, nicht verbundenen Windows Server 

2008-Gesamtstruktur zuzugreifen. 

Eine deutliche Verbesserung, die in Windows Server 2003 an Active Directory vorgenommen wurde, 

ist die Möglichkeit, Vertrauensstellungen zwischen AD DS-Gesamtstrukturen zu erstellen. In Windows 

2000 Active Directory können Sie nur eine Vertrauensstellung zwischen einer Domäne in einer 

Gesamtstruktur und einer Domäne in einer anderen Gesamtstruktur erstellen. In Windows Server 

2003 und Windows Server 2008 können Sie eine Vertrauensstellung zwischen den Stammdomänen 

der Gesamtstruktur erstellen. Bei dieser Vertrauensstellung kann es sich um eine uni- oder bidirektionale 

Vertrauensstellung handeln. Nachdem die Vertrauensstellung erstellt wurde, können Sie globale 

oder universelle Gruppen aus einer Gesamtstruktur nutzen, um Berechtigungen für Ressourcen in 

einer anderen Gesamtstruktur zu erteilen. 

Hinweis Durch das Erstellen einer Vertrauensstellung zwischen zwei Gesamtstrukturen können nur Ressourcen 

zwischen den beiden Gesamtstrukturen freigegeben werden. Alle übrigen Trennungen auf Gesamtstrukturebene 

bleiben auch nach dem Erstellen der Vertrauensstellung weiterhin bestehen. Das Erstellen 

einer Vertrauensstellung bedeutet beispielsweise nicht, dass die Gesamtstrukturen einen gemeinsamen globalen 

Katalog (Global Catalog, GC) oder ein gemeinsames Schema nutzen. Wenn Sie eine Vertrauensstellung 

in Active Directory erstellen, wird durch die Vertrauensstellung das Namensuffixrouting zwischen den 

beiden Gesamtstrukturen automatisch aktiviert. Benutzer können durch das Namensuffixrouting ihre Benutzerprinzipalnamen 

(User Principle Names, UPNs) beim Anmelden an jeder Domäne in einer der Gesamtstrukturen 

verwenden. Wenn Sie beispielsweise eine Gesamtstrukturvertrauensstellung zwischen den 

beiden Gesamtstrukturen Adatum.com und TreyResearch.com erstellen, können Benutzer der Gesamtstruktur 

TreyResearch.com ihren UPN Benutzername@treyresearch.com zur Anmeldung an einer Arbeitsstation 

in der Gesamtstruktur Adatum.com verwenden. Das Namensuffixrouting wird standardmäßig auf alle Domänennamen 

erster Ebene angewendet, die in der Gesamtstruktur verfügbar sind. Dies umfasst sowohl die 

Standard-UPN-Suffixe sowie alle weiteren alternativen Suffixe, die in der Gesamtstruktur konfiguriert sind. 

Das Namensuffixrouting funktioniert zwischen Gesamtstrukturen nur dann nicht, wenn in beiden Gesamtstrukturen 

das gleiche UPN-Suffix konfiguriert wurde. Wurde das UPN-Suffix aus der Gesamtstruktur Trey- 

Research.com in der Gesamtstruktur Adatum.com konfiguriert, können sich Benutzer der Gesamtstruktur 

TreyReserch.com nicht mit ihrem UPN an der Gesamtstruktur Adatum.com anmelden.

Konfigurieren von Vertrauensstellungen zwischen Gesamtstrukturen 263 

Beim ersten Aktivieren der Gesamtstrukturvertrauensstellung werden alle Domänensuffixe erster 

Ebene automatisch an die UPN-Vertrauensstellung weitergeleitet. Die Weiterleitung der untergeordneten 

Domänensuffixe wird implizit über das übergeordnete Domänensuffix vorgenommen. Wenn Sie 

einer Gesamtstruktur ein weiteres UPN-Suffix hinzufügen, nachdem die Vertrauensstellung erstellt 

wurde, müssen Sie das Namensuffixrouting für das neue Suffix aktivieren. Hierzu können Sie entweder 

die Vertrauensstellung zwischen den Domänen verifizieren, oder Sie können das neue Suffix 

manuell im Eigenschaftendialogfeld der Vertrauensstellung auf der Registerkarte Namensuffixrouting 

hinzufügen. 

Um eine Gesamtstrukturvertrauensstellung zu erstellen, muss für die Gesamtstrukturfunktionsebene 

Windows Server 2003 oder Windows Server 2008 festgelegt sein. In einer Gesamtstruktur verfügen 

nur die Mitglieder der Gruppe Organisations-Admins über die Berechtigung zum Erstellen von 

Gesamtstrukturvertrauensstellungen. 

Um eine Gesamtstrukturvertrauensstellung zu erstellen, gehen Sie wie folgt vor: 

1. Öffnen Sie das Verwaltungstool Active Directory-Domänen und -Vertrauensstellungen. Klicken 

Sie mit der rechten Maustaste auf die Stammdomäne der Gesamtstruktur, und wählen Sie Eigenschaften. 

Klicken Sie auf die Registerkarte Vertrauensstellungen. 

2. Klicken Sie auf Neue Vertrauensstellung. Der Assistent für neue Vertrauensstellungen wird gestartet. 

Geben Sie den Domänennamen der Stammdomäne der anderen Gesamtstruktur ein. 

3. Sie haben nun die Möglichkeit, den zu konfigurierenden Vertrauensstellungstyp auszuwählen. 

Folgende Vertrauensstellungstypen stehen zur Auswahl: 

Vertrauensstellung mit einer externen Domäne 

Vertrauensstellung mit einer NT 4.0-Domäne 

Kerberos (v5)-Bereichvertrauensstellung 

Vertrauensstellung mit einer anderen Gesamtstruktur 

Bei einer externen Vertrauensstellung handelt es sich um eine nicht transitive Vertrauensstellung, 

Gesamtstrukturvertrauensstellungen dagegen sind immer transitiv. Wählen Sie die Gesamtstrukturvertrauensstellung. 

4. Wählen Sie die Richtung für die Vertrauensstellung. Folgende Möglichkeiten stehen zur Auswahl: 

Bidirektional Eine Authentifizierung kann für Benutzer dieser Domäne in der angegebenen 

Domäne, dem angegebenen Bereich oder der angegebenen Gesamtstruktur und für Benutzer 

der angegebenen Domäne, dem angegebenen Bereich oder der angegebenen Gesamtstruktur in 

dieser Domäne durchgeführt werden. 

Unidirektional, eingehend Eine Authentifizierung kann für Benutzer dieser Domäne in der 

angegebenen Domäne, dem angegebenen Bereich oder der angegebenen Gesamtstruktur 

durchgeführt werden. 

Unidirektional, ausgehend Eine Authentifizierung kann für Benutzer der angegebenen Domäne, 

dem angegebenen Bereich oder der angegebenen Gesamtstruktur in dieser Domäne durchgeführt 

werden. 

5. Sie können entscheiden, ob Sie die Vertrauensstellung nur für diese Domäne oder auch für die 

andere Domäne erstellen möchten. (Bei diesen beiden Domänen handelt es sich um die Stammdomänen 

der beiden Gesamtstrukturen.) Die Gesamtstrukturvertrauensstellung kann nur zwischen 

den Stammdomänen von Gesamtstrukturen erstellt werden.


Wenn Sie beide Seiten der Vertrauensstellung gleichzeitig konfigurieren möchten, müssen Sie den 

Namen und das Kennwort des Kontos Organisations-Admins der anderen Gesamtstruktur eingeben. 

Wenn Sie die Vertrauensstellung nur für diese Domäne erstellen möchten, werden Sie zur 

Angabe des Kennworts aufgefordert, das für die Konfiguration der ersten Vertrauensstellung verwendet 

wird. Dieses Kennwort muss anschließend für die Konfiguration der Vertrauensstellung in 

der Stammdomäne der anderen Gesamtstruktur verwendet werden. 

6. Sie können auch entscheiden, welche Authentifizierungsebene Sie für sowohl die eingehende als 

auch die ausgehende Vertrauensstellung festlegen möchten. Dadurch haben Sie die Möglichkeit, 

den Zugriff auf Ressourcen zwischen Gesamtstrukturen sehr genau zu steuern. Wenn Sie sich für 

die Festlegung einer gesamtstrukturweiten Authentifizierung entscheiden, können Benutzer der 

einen Gesamtstruktur auf alle Server und Ressourcen in der anderen Gesamtstruktur zugreifen. 

Diese Konfiguration entspricht der Konfiguration für Vertrauensstellungen zwischen den Domänen 

innerhalb einer Gesamtstruktur. Benutzer von einer Domäne in einer Gesamtstruktur können 

auf Ressourcen in jeder beliebigen Domäne in einer der Gesamtstrukturen zugreifen, vorausgesetzt, 

sie verfügen über die Zugriffsberechtigung für die Ressourcen. Sie können für die Gesamtstrukturvertrauensstellung 

auch eine selektive Authentifizierung festlegen. In diesem Fall müssen 

Sie den Benutzern oder Gruppen der einen Gesamtstruktur den Zugriff auf Server in der anderen 

Gesamtstruktur explizit ermöglichen. Erteilen Sie hierfür den Benutzern oder Gruppen in Active 

Directory die Berechtigung Authentifizierung zulassen. 

7. Nachdem Sie die Vertrauensstellung konfiguriert haben, können Sie die Vertrauensstellung automatisch 

verifizieren. 

Wenn Sie eine bidirektionale transitive Vertrauensstellung konfiguriert haben, können Benutzer nun 

auf freigegebene Ressourcen in der vertrauten Gesamtstruktur zugreifen. 


In diesem Kapitel wurden die unterschiedlichen Migrationsoptionen erläutert, um eine Migration von 

Active Directory in Windows 2000 Server oder Windows Server 2003 zu den Windows Server 2008- 

AD DS durchzuführen. Die drei wichtigsten Migrationsoptionen – Aktualisierung, Umstrukturierung 

und Aktualisierung vor Umstrukturierung – wurden beschrieben. Um die für Ihre Organisation geeignete 

Option zu ermitteln, stehen verschiedene Kriterien zur Verfügung. Für Organisationen, die mit der 

derzeitigen Domänenstruktur zufrieden sind, ist die Aktualisierung die einfachste Option, d.h. sie 

können einfach den Verzeichnisdienst von Windows 2000 Server oder Windows Server 2003 auf 

Windows Server 2008 aktualisieren. Entspricht Ihre Domänenstruktur nicht Ihren Geschäftsanforderungen 

oder Ihrem Organisationsmodell, ist eine Umstrukturierung der Domäne erforderlich. Unabhängig 

von der Option, für die Sie sich entscheiden, ist zur erfolgreichen Durchführung Ihres Migrationsprojekts 

eine sorgfältige Planung, Prüfung sowie Test- und Pilotphase erforderlich. 

In diesem Kapitel wurde neben den wichtigsten Entscheidungsfaktoren zum Durchführen einer ersetzenden 

Aktualisierung auf Windows Server 2008 auch das Verfahren der Domänenumstrukturierung 

mithilfe des ADMTs erläutert. Anschließend wurde der Unterschied zwischen dem Verfahren der 

Aktualisierung vor Umstrukturierung, auch als Migration innerhalb einer Gesamtstruktur bezeichnet, 

und einer Domänenumstrukturierung beschrieben. Am Ende dieses Kapitels folgte dann die Erläuterung 

des Windows Server 2008-Features zum Erstellen von Vertrauensstellungen zwischen Gesamtstrukturen.


Empfohlene Vorgehensweisen 265 

Durch die Einhaltung der folgenden empfohlenen Vorgehensweisen können Migrationen auf Windows 

Server 2008 erfolgreich durchgeführt werden. 

• Anwenden von Service Packs auf Windows 2000 Server-Domänencontroller Bevor Sie die Domäne 

(und die Gesamtstruktur, in der sich die Domäne befindet) für die Migration vorbereiten, sollten 

Sie Windows 2000 Server Service Pack 4 (SP4) oder höher auf alle Domänencontroller anwenden, 

auf denen Windows 2000 Server ausgeführt wird. Sie können die aktuellen Service Packs 

für Windows 2000 Server von der Microsoft-Website unter http://technet.microsoft.com/en-us/ 

windowsserver/2000/bb735341.aspx herunterladen. 

• Migrieren von Computerkonten in virtuellen privaten Netzwerken Für VPN-Clients (Virtual Private 

Network, virtuelles privates Netzwerk) müssen Sie bei der Migration von Computerkonten mithilfe 

des ADMTs sicherstellen, dass der Verteiler-Agent über die VPN-Verbindung installiert 

werden kann. Konfigurieren Sie hierfür das VPN so, dass eine direkte Verbindung mit dem DFÜ- 

Client hergestellt werden kann. Das ADMT versucht, den Verteiler-Agent-Dienst auf dem zu migrierenden 

Computer zu installieren. Diese Installation schlägt jedoch fehl, wenn der SMB-Serverdatenverkehr 

(Server Message Block) durch die Firewall oder den Proxyserver blockiert wird. 

Konfigurieren Sie die Firewalleinstellungen für die Zulassung dieses Datenverkehrs, bevor Sie 

über das VPN verbundene Computerkonten migrieren. 

• Migrieren von Domänencontrollern Computerkonten von Domänencontrollern können nicht 

mithilfe des ADMTs migriert werden. Domänencontroller müssen auf die Windows Server 2008- 

Domäne verschoben werden. Um einen DC von der Quell- zur Zieldomäne zu verschieben, sollten 

Sie ihn herabstufen (d.h. Active Directory deinstallieren), den Server zur Zieldomäne hinzufügen 

und anschließend zum Windows Server 2008-Domänencontroller heraufstufen. 


Die folgenden Ressourcen enthalten zusätzliche Informationen, die für die Migration auf Windows 

Server 2008-AD DS hilfreich sind. 


• Weitere Informationen zu den neuen, in Windows Server 2008 Active Directory verfügbaren Features 

finden Sie in Kapitel 1, „Neuerungen in Active Directory für Windows Server 2008“. 

• Weitere Informationen zum Entwerfen Ihrer Active Directory-Struktur werden in Kapitel 5, „Entwerfen 

der Active Directory-Domänendienstestruktur“, bereitgestellt. 

• Weitere Informationen zur Verwendung des Assistenten zum Installieren der Active Directory- 

Domänendienste werden in Kapitel 6, „Installieren der Active Directory-Domänendienste“, 


• Vor der Migration auf Windows Server 2008 und die AD DS ist eine präzise Planung und ein 

umfassender Entwurf Ihrer Infrastruktur erforderlich. Für die Planung Ihrer Bereitstellung sollten 

Sie den Artikel „Planning an Active Directory Domain Services Deployment“ (in englischer Sprache) 

unter http://technet2.microsoft.com/windowsserver2008/de/library/817d84f0-a0c3-4776- 

8ea3-20054f342a701031.mspx?mfr=true lesen.


• Der Artikel „The Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services 

Installation and Removal“ (in englischer Sprache) steht unter http://technet2.microsoft.com/ 

windowsserver2008/en/library/f349e1e7-c3ce-4850-9e50-d8886c866b521033.mspx?mfr=true zur 

Verfügung. 

• Weitere Informationen zur Bereitstellung der AD DS werden im Artikel „Planning an Active 

Directory Domain Services Deployment” (in englischer Sprache ) unter http://go.microsoft.com/ 

fwlink/?LinkId=100493 bereitgestellt. 

• Informationen zum Bewerten der Hardwareanforderungen von Domänencontrollern in einer Windows 

Server 2008-Domäne finden Sie im Artikel „Planning Domain Controller Capacity“ (in englischer 

Sprache) http://technet2.microsoft.com/windowsserver/en/library/4af3271a-4407-4ca5- 

9cd5-e05b79046d081033.mspx?mfr=true. 

• Weitere Informationen zur Bereitstellung regionaler AD DS-Domänen werden im Artikel „Deploying 

Windows Server 2008 Regional Domains“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId=89029 


• Weitere Informationen zum Durchführen einer Aktualisierung von Active Directory-Domänen auf 

Windows Server 2008 finden Sie im Artikel „Upgrading AD DS Domains to Windows Server 

2008“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId=89032. 

• Weitere Informationen zu zusätzlichen Installationsmethoden für eine neue Windows 

Server 2008-Gesamtstruktur finden Sie unter „Installieren einer neuen Gesamtstruktur unter Windows 

Server 2008“ unter http://go.microsoft.com/fwlink/?LinkId=101704. 

• Weitere Informationen zu Tests, die mithilfe des Tools Dcdiag.exe durchgeführt werden können, 

finden Sie in der „Dcdiag Overview” (in englischer Sprache) unter http://go.microsoft.com/fwlink/ 

?LinkId=93660. 

• Informationen zur Verwendung von Medien für die Installation des Domänencontrollers finden 

Sie im Artikel „Installing AD DS from Media“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId=93104. 

• Ein Verfahren, das bei der Übertragung der Betriebsmasterrollen hilfreich sein kann, wird unter 

„Übertragen der Betriebsmasterrollen“ unter http://go.microsoft.com/fwlink/?LinkId=93664 

beschrieben. 

• Wissenswertes zur Platzierung der Betriebsmasterrolle wird im Artikel „Planning Operations 

Master Role Placement“ (in englischer Sprache) unter http://go.microsoft.com/fwlink/?LinkId= 



• Active Directory Migration Tool v.3.1, verfügbar unter http://go.microsoft.com/fwlink/?LinkId= 

82740

T E I L I I I 

Verwalten von Windows Server 2008 Active 



Kapitel 8: Active Directory-Domänendienstsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

Kapitel 9: Delegieren der Active Directory-Domänendiensteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 

Kapitel 10: Verwalten von Active Directory-Objekten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

Kapitel 11: Einführung in Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 

Kapitel 12: Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops . . . . . . . . . . . . . . . . . . 449 

Kapitel 13: Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit. . . . . . . . . . . . . . . . . . . . . . . . . 505

269 


Active Directory-Domänendienstsicherheit 


AD DS-Sicherheitsgrundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

Kerberos-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

NTLM-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 

Implementieren der Sicherheit für Domänencontroller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 

Entwerfen sicherer administrativer Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 




Einer der vornehmlichen Gründe für die Bereitstellung eines Verzeichnisdienstes wie den Active 

Directory-Domänendiensten (Active Directory Domain Services, AD DS) ist der, Sicherheit im 

Unternehmensnetzwerk zu gewährleisten. Jedes Unternehmen speichert geschäftskritische Informationen 

auf Dateiservern im Netzwerk. E-Mails haben sich zu einem der wichtigsten Mittel für den 

Austausch von Geschäftsinformationen entwickelt. Intranet- oder Internetsites enthalten möglicherweise 

vertrauliche Informationen, und der Zugriff auf die Sites muss für bestimmte Benutzer eingeschränkt 

werden. Um sicherzustellen, dass nur autorisierte Benutzer Zugriff erhalten, ist die Verwaltung 

eines sicheren Zugriffs auf diese Arten von Informationen von wesentlicher Bedeutung. 

Microsoft Windows Server 2008 AD DS stellt den Verzeichnisdienst zur Verfügung, der zur Gewährleistung 

von Sicherheit in diesen und vielen weiteren Szenarien verwendet werden kann. 

Das vorliegende Kapitel beginnt mit einer Einführung in die Grundlagen der AD DS-Sicherheit. Die 

Active Directory-Domänendienste verwenden verschiedene Bausteine und Konzepte zur Gewährleistung 

der Sicherheit in einem Windows Server 2008-Netzwerk. Im Anschluss an die Sicherheitsgrundlagen 

werden die Authentifizierungs- und Autorisierungsfunktionen besprochen, die von den AD DS 

zur Überprüfung der Benutzeridentität (Authentifizierung) und zur Erteilung des Zugriffs auf die 

geeigneten Ressourcen (Autorisierung) eingesetzt werden. Windows Server 2008 verwendet, ebenso 

wie Microsoft Windows 2000 und Windows Server 2003, Kerberos als primäres Authentifizierungsprotokoll. 

Aus diesem Grund konzentriert sich der erste Teil des vorliegenden Kapitels auf die Rolle 

des Kerberos-Protokolls für die Authentifizierung. 

Nach der Besprechung von Authentifizierung und Autorisierung werden die AD DS-Domänencontrollersicherheit 

und die Entwicklung von sicheren Verfahren für die Umgebungsverwaltung erläutert. 

Dies ist eine wichtige zweite Komponente beim Aufbau einer sicheren AD DS-Umgebung. 

Weitere Informationen Das vorliegende Kapitel bietet eine Grundlage für das Verständnis und die Implementierung 

der Sicherheit in einem Windows Server 2008-Netzwerk. In späteren Kapiteln, wie etwa Kapitel 9, 

„Delegieren der Active Directory-Domänendienste“, und Kapitel 13, „Einsetzen von Gruppenrichtlinien zum 

Verwalten der Sicherheit“, werden die hier angesprochenen Konzepte eingehender behandelt.

270 Kapitel 8: Active Directory-Domänendienstsicherheit 

AD DS-Sicherheitsgrundlagen 

Um die Funktionsweise der AD DS-Sicherheit in einem Windows Server 2008-Netzwerk verstehen 

zu können, müssen zunächst einige grundlegende Konzepte erläutert werden. Im Wesentlichen besteht 

die AD DS-Sicherheit aus zwei Arten von Objekten und der Interaktion zwischen diesen zwei 

Objekten. Das erste Objekt ist ein Sicherheitsprinzipal, d.h. ein Objekt, das einen Benutzer, eine 

Gruppe oder einen Computer repräsentiert, der bzw. die Zugriff auf eine Ressource im Netzwerk 

benötigt. Das zweite Objekt ist die Ressource selbst – das Objekt, für das der Sicherheitsprinzipal 

Zugriff benötigt. Zur Gewährleistung der erforderlichen Sicherheit müssen die AD DS die Identität des 

Sicherheitsprinzipals bestimmen können und anschließend die erforderliche Zugriffsebene für die Ressourcen 

gewähren. 

Sicherheitsprinzipale 

Sicherheitsprinzipale sind die einzigen Objekte in den AD DS, denen Berechtigungen für den Zugriff 

auf Ressourcen im Netzwerk erteilt werden kann. Jedem Sicherheitsprinzipal wird bei Erstellung des 

Objekts eine Sicherheitskennung (Security Identifier, SID) erzeugt. Die Sicherheitskennung besteht 

aus zwei Teilen. Der erste Teil ist eine Domänenkennung, die für alle Sicherheitsprinzipale in einer 

Domäne identisch ist. Der zweite Teil der Sicherheitskennung ist ein relativer Bezeichner (Relative 

Identifier, RID), der für jeden Sicherheitsprinzipal in einer AD DS-Domäne eindeutig ist. 

Die Sicherheitskennung ist eine wesentliche Komponente bei der Konfiguration der Ressourcensicherheit 

in einem Windows Server 2008-Netzwerk. Wenn Sie Berechtigungen für eine Ressource 

erteilen, verwenden Sie den Anzeigenamen des Sicherheitsprinzipals, Windows Server 2008 verwendet 

tatsächlich jedoch die Sicherheitskennung zur Verwaltung des Ressourcenzugriffs. Wenn ein 

Benutzer versucht, auf die Ressourcen eines Servers in der Domäne zuzugreifen, erteilt das Betriebssystem 

nicht dem Namen der Person, sondern der Benutzer-SID Berechtigungen für die Ressource. 

Wenn demzufolge der Anzeigename eines Benutzers geändert wird, hat dies keine Auswirkung auf 

die gewährten Berechtigungen. Wenn jedoch ein Benutzerobjekt gelöscht und anschließend mit demselben 

Namen neu erstellt wird, kann der Benutzer nicht auf dieselben Ressourcen zugreifen, da dem 

neuen Objekt eine andere Sicherheitskennung zugewiesen wird. 

Praxistipp: Sicherheitskennungen 

Eine Sicherheitskennung (Security Identifier, SID) ist eine numerische Darstellung, die einen 

Sicherheitsprinzipal eindeutig identifiziert. Sicherheitskennungen setzen sich aus drei Komponenten 

zusammen: Revisionsstufe, Bezeichnerautorität und Teilautorität oder relativer Bezeichner 

(Relative Identifier, RID). 

Sicherheitskennungen verwenden die folgende Syntax: 

S-R-I-S-S 

Der Buchstabe S zeigt an, dass es sich bei der folgenden Informationen um eine Sicherheitskennung 

handelt. Der Buchstabe R kennzeichnet die Revisionsstufe der Sicherheitskennung. Der 

Buchstabe I repräsentiert die Bezeichnerautorität (Identifier Authority), und das S steht für die Teilautorität 

(Subauthority) oder den relativen Bezeichner (Relative Identifier, RID). Es können mehrere 

Werte für die Teilautorität oder den relativen Bezeichner vorliegen: 

• Revisionsstufe Die Revisionsstufe repräsentiert die Änderungsstufe der SID-Struktur. Die derzeitige 

Revisionsstufe lautet 1.

AD DS-Sicherheitsgrundlagen 271 

• Bezeichnerautorität Die Bezeichnerautorität ist ein 48-Bit-Wert zur Identifizierung der Stelle, 

welche die Sicherheitskennung ausgegeben hat. 

• Teilautorität/Relativer Bezeichner Die Teilautorität bzw. der relative Bezeichner werden verwendet, 

um den Sicherheitsprinzipal relativ zur ausgebenden Stelle eindeutig zu identifizieren. Teilautorität 

bzw. relative Bezeichner stellen sicher, dass keine identischen Sicherheitskennungen 

vorhanden sind. Dies wird erreicht, indem einer ausgebenden Stelle für Sicherheitskennungen 

untersagt wird, einen relativen Bezeichner mehrfach zuzuweisen. 

Windows erstellt Sicherheitskennungen unter Verwendung der Bezeichnerautorität 5 und der Teilautorität 

21. Aus diesem Grund beginnen unter Windows erstellte Sicherheitskennungen mit S-1-5- 

21. Die nächste Teilautorität wird entweder von der Domäne oder vom lokalen Computer abgeleitet. 

Dies hängt davon ab, ob der neue Sicherheitsprinzipal in der Domäne vorliegt oder es sich um 

einen lokalen Sicherheitsprinzipal handelt. Die verbleibenden drei Teilautoritäten leiten sich vom 

relativen Bezeichner ab. Jedem Domänencontroller wird von der FSMO-Rolle des RID-Managers 

ein Pool relativer Bezeichner zugeordnet. Der Domänencontroller, der den neuen Sicherheitsprinzipal 

erstellt, weist dem neuen Sicherheitsprinzipal aus diesem RID-Pool einen relativen Bezeichner 

zu. Auf diese Weise wird die vollständige Sicherheitskennung erzeugt: 

S-1-5-21-3093361465-529454648-2942243305-1007 

Bezeichnerautorität 

Teilautorität 

S-1-5-21-3093361465-529454648-2942243305-1007 

Windows 

Domänenteilautorität 

Mike Stephens 

Microsoft-Supportmitarbeiter 

Relativer Bezeichner 

Zugriffssteuerungslisten (ACLs) 

Die zweite Komponente in der AD DS-Sicherheit ist das Objekt, auf das ein Sicherheitsprinzipal 

Zugriff benötigt. Bei diesem Objekt kann es sich um eine AD DS-Organisationseinheit (Organizational 

Unit, OU), um ein Druckerobjekt oder sogar um einen Sicherheitsprinzipal handeln. Bei dem 

Objekt kann es sich ebenfalls um eine Ressource wie z.B. eine Datei auf einem Windows Server 

2008-Server oder um ein Postfach auf einem Microsoft Exchange Server 2007-Server handeln. 

Die Berechtigungen, die diesen Objekten gewährt wurden, befinden sich in einer Zugriffssteuerungsliste 

(Access Control List, ACL). Jedes Objekt in den Active Directory-Domänendiensten oder auf 

einer NTFS-Dateisystempartition umfassen eine Sicherheitsbeschreibung. Die Sicherheitsbeschreibung 

enthält die Sicherheitskennung des Sicherheitsprinzipals, der das Objekt besitzt, sowie die 

Sicherheitskennung der primären Gruppe für das Objekt. Zusätzlich verfügt jedes Objekt über zwei 

separate ACLs: eine DACL (Discretionary Access Control List) und eine SACL (System Access Control 

List). Die DACL listet die Sicherheitsprinzipale oder Vertrauensnehmer auf, denen Berechtigungen 

für das Objekt erteilt wurden, sowie den Berechtigungsumfang, der jedem Sicherheitsprinzipal 

zugewiesen wurde. Die DACL besteht aus einer Reihe von Zugriffssteuerungseinträgen (Access 

Control Entries, ACEs). Jeder ACE listet eine Sicherheitskennung auf und gibt die Zugriffsebene der 

Sicherheitskennung für das Objekt an.


Der ACE kann einen Eintrag für alle Arten von Sicherheitsprinzipalen enthalten. Beispielsweise kann 

ein Benutzerkonto Leseberechtigungen für eine Datei besitzen, und eine Sicherheitsgruppe hat möglicherweise 

Vollzugriff. Die DACL für die Datei umfasst (mindestens) zwei ACEs. Mit dem ersten 

Zugriffssteuerungseintrag werden Leseberechtigungen gewährt, mit dem zweiten Vollzugriff. 

Die SACL listet die Sicherheitsprinzipale auf, deren Zugriff auf die Ressource überwacht werden 

muss. Die Liste der ACEs in der SACL gibt an, wessen Zugriff überwacht werden muss und in welchem 

Umfang diese Überwachung zu erfolgen hat. 

Hinweis Die DACL kann gleichermaßen ACEs zur Gewährung des Zugriffs auf eine Ressource sowie 

ACEs für die Zugriffsverweigerung enthalten. Die ACEs für die Zugriffsverweigerung sollten als erste in der 

ACL aufgeführt werden, damit sie vom Sicherheitssubsystem als erste ausgewertet werden. Wenn ein ACE 

den Zugriff auf eine Ressource verweigert, wertet das Sicherheitssubsystem keine weiteren ACEs aus. Dies 

bedeutet, dass eine ACE zur Verweigerung des Ressourcenzugriffs eine ACE zur Gewährung von Zugriff für 

eine bestimmte Sicherheitskennung immer außer Kraft setzt. Weitere Informationen zur Verwendung von 

Sicherheitsbeschreibungen zum Gewähren von Zugriff auf AD DS-Objekte finden Sie in Kapitel 9. 

Praxistipp: Sicherheitsbeschreibungen 

Windows verwendet Sicherheitsbeschreibungen zum Schutz und für die Überwachung von Ressourcen. 

Eine Sicherheitsbeschreibung umfasst einen Besitzer, eine primäre Gruppe eine DACL 

(Discretionary Access Control List) und eine Systemzugriffsliste (System Access Control List, 

SACL). 

Besitzer und primäre Gruppe 

Die Felder für Besitzer und primäre Gruppe sind Sicherheitskennungen. Der Besitzer ist der Sicherheitsprinzipal, 

der das Objekt besitzt. Der Ressourcenbesitzer hat Vollzugriff auf das Objekt, einschließlich 

der Fähigkeit zum Hinzufügen oder Entfernen von Berechtigungen innerhalb der 

Sicherheitsbeschreibung. 

Die primäre Gruppe verbleibt zur Erhaltung der Kompatibilität mit dem POSIX-Subsystem in der 

Sicherheitsbeschreibung. Windows greift auf diesen Teil der Sicherheitsbeschreibung nur bei Verwendung 

von Dienstprogrammen zurück, die POSIX-Interoperabilität erfordern. Standardmäßig schreibt 

der Sicherheitsprinzipal, der das Objekt erstellt, die standardmäßige primäre Gruppe in die Sicherheitsbeschreibung. 

Die standardmäßige primäre Gruppe von Windows lautet Domänen-Benutzer. 

Die primäre Gruppe ist eine implizierte Gruppenmitgliedschaft. Wenn sich ein Benutzer anmeldet, 

fügt das Betriebssystem die Sicherheitskennung für diese Gruppe in das Benutzertoken ein. Im 

Attribut memberOf wird die primäre Gruppe nicht aufgeführt. Das Attribut memberOf schließt nur 

Gruppenmitgliedschaften ein, die explizit zugewiesen wurden. 

DACL und SACL 

Eine Zugriffssteuerungsliste (Access Control Lists, ACL) umfasst zwei Teile. Der erste Teil der 

Zugriffssteuerungsliste umfasst die sogenannten Steuerungsflags. Diese Einstellungen steuern, wie 

Windows Berechtigungen innerhalb der ACL und die Regeln zur Vererbung anwendet. Der zweite 

Teil der Zugriffssteuerungsliste ist die Liste selbst. Die Zugriffssteuerungsliste enthält mindestens 

einen Zugriffssteuerungseintrag (Access Control Entry, ACE).


Zugriffssteuerungsflags legen fest, wie Windows die ACEs innerhalb der Zugriffssteuerungsliste 

anwendet. Windows verwendet hauptsächlich die Flags Protected und Automatic. Das geschützte 

Flag verhindert, dass die Zugriffssteuerungsliste von einer vererbten Zugriffssteuerungsliste geändert 

wird. Dieses Flag entspricht dem Deaktivieren des Kontrollkästchens Berechtigungen übergeordneter 

Objekte, sofern vererbbar, über alle untergeordneten Objekte verbreiten. Das automatische 

Flag entspricht dem Aktivieren des Kontrollkästchens Berechtigungen übergeordneter 

Objekte, sofern vererbbar, über alle untergeordneten Objekte verbreiten. Dieses Flag lässt die Vererbung 

von ACEs in der Zugriffssteuerungsliste an untergeordnete Objekte zu. 

Zugriffssteuerungseinträge (ACEs) 

Zugriffssteuerungslisten (ACLs) enthalten mindestens einen Zugriffssteuerungseintrag (Access 

Control Entry, ACE). Windows unterteilt Zugriffssteuerungseinträge in zwei Typen: Zulassen und 

Verweigern. Jeder ACE-Typ weist einen Untertyp object und nonobject-Untertypen auf. Die 

Zugriffssteuerungseinträge Zulassen und Verweigern geben die Zugriffsebene an, die das Autorisierungssubsystem 

basierend auf dem vom Sicherheitsprinzipal angeforderten Recht zuweist. Objekt- 

ACEs sind ausschließlich für Objekte in den AD DS bestimmt, da sie zusätzliche Felder für die 

Objektvererbung bieten. Windows verwendet Nicht-Objekt-ACEs für die meisten verbleibenden 

Ressourcen, z.B. für Dateisystem- und Registrierungsressourcen. Nicht-Objekt-ACEs ermöglichen 

eine Containervererbung – hierbei erbt ein Objekt in einem Container den ACE des Containers. 

Dies ähnelt der Dateiberechtigungsvererbung von übergeordneten Ordnern. Jeder ACE-Typ verfügt 

über ein Feld für die Rechte und ein Feld für den Vertrauensnehmer. Das Feld für die Rechte 

besteht üblicherweise aus einer vordefinierten Zahl, die für eine spezifische Aktion steht, die ein 

Sicherheitsprinzipal anfordern kann. Ein Beispiel für ein solches Recht wäre eine Benutzeranforderung 

zum Lesen oder Schreiben einer Datei. In diesem Beispiel handelt es sich um zwei separate 

Rechte Lesen und Schreiben. Das Feld für den Vertrauensnehmer gibt eine Sicherheitskennung an, 

der das spezifische Recht gewährt oder verweigert wurde. Ein Beispiel für einen Vertrauensnehmer 

wäre ein Benutzer oder eine Gruppe, dem die im Feld für die Rechte angegebene Aktion gewährt 

oder verweigert wurde. 

Mike Stephens 

Microsoft-Supportmitarbeiter 

Zugriffstoken 

Der Verbindungspunkt zwischen der Sicherheitskennung und der ACL eines Sicherheitsprinzipals ist 

das Zugriffstoken. Wenn Windows den Benutzer unter Verwendung von Kerberos authentifiziert, wird 

dem Benutzer während der Anmeldung ein Zugriffstoken auf dem lokalen Computer zugewiesen. 

Dieses Token enthält die primäre Sicherheitskennung des Benutzers, die Sicherheitskennungen für 

alle Gruppen, denen der Benutzer angehört, sowie die Berechtigungen und Rechte des Benutzers. 

Hinweis Das Zugriffstoken kann auch zusätzliche Sicherheitskennungen im SIDHistory-Attribut aufweisen. 

Diese Sicherheitskennungen können aufgefüllt werden, wenn Sie Benutzerkonten von einer Domäne in 

eine andere verschieben. Eine eingehende Erörterung des SIDHistory-Attributs finden Sie in Kapitel 7, „Migrieren 

auf die Active Directory-Domänendienste“.


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).


Wenn Windows 2000-Clients (oder höher) sich an einem Windows Server 2008-Netzwerk anmelden, 

wird der Kerberos SSP ausgewählt, und die Informationen werden an den SSP übergeben. Der SSP 

kommuniziert anschließend mit dem Domänencontroller, um den Benutzer zu authentifizieren. Der 

Kerberos-Authentifizierungsprozess wird an späterer Stelle in diesem Kapitel ausführlich behandelt. 

Sofern die Authentifizierung erfolgreich ist, wird der Benutzer authentifiziert und erhält Zugriff auf 

das Netzwerk. Wenn sich der Benutzer an einer Domäne angemeldet hat und sich alle vom Benutzer 

benötigten Ressourcen in derselben Gesamtstruktur befinden, muss der Benutzer seine Anmeldeinformationen 

nur einmal eingeben. Sämtliche Berechtigungen, die dem Benutzer bis zur Abmeldung im 

Netzwerk gewährt werden, basieren auf der anfänglichen Authentifizierung. Auch wenn das Benutzerkonto 

bei jedem Ressourcenzugriff erneut authentifiziert wird, sofern der Benutzer sich gegenüber 

diesem Server noch nicht authentifiziert hat, erfolgt diese Authentifizierung für den Benutzer unbemerkt. 

Autorisierung 

Die Autorisierung ist der zweite Schritt beim Zugriff auf Netzwerkressourcen, und dieser Schritt 

erfolgt nach der Authentifizierung. Während der Authentifizierung stellen Sie Ihre Identität unter 

Beweis, indem Sie den richtigen Benutzernamen und das zugehörige Kennwort eingeben. Während 

der Autorisierung erhalten Sie Zugriff auf die Ressourcen im Netzwerk. Anders betrachtet wird während 

der Authentifizierung ein Zugriffstoken für Sie erstellt. Bei der Autorisierung wird das Zugriffstoken 

einem Server vorgelegt und der Zugriff auf eine Ressource angefordert. Sofern die Sicherheitskennungen 

im Zugriffstoken mit den Sicherheitskennungen in der DACL übereinstimmen, wird der 

Zugriff gemäß Zugriffssteuerungseintrag (ACE) für die Ressource gewährt oder verweigert. 

Die Autorisierung, auch Zugriffssteuerung genannt, bezeichnet die Ermittlung der Zugriffsebene, die 

für ein Active Directory- oder Dateisystemobjekt gewährt oder verweigert wird. Nachdem das Schlüsselverteilungscenter 

(Key Distribution Center, KDC) die Identität des Benutzers bestätigt hat, generiert 

das Sicherheitssystem auf dem authentifizierenden Domänencontroller Autorisierungsdaten. 

Diese bestehen aus der primären Sicherheitskennung für den Benutzer sowie den Sicherheitskennungen 

für Gruppen, denen der Benutzer angehört. Diese Sicherheitskennungen werden von allen 

Ressourcen im Windows-Netzwerk erkannt. Die Autorisierungsdaten werden von dem Computer, der 

die Netzwerkressource verwaltet, zum Generieren eines Zugriffstokens verwendet. Das Zugriffstoken 

dient der Ermittlung der Zugriffsebene, die dem Benutzer für die Netzwerkressource gewährt wird. 

Das Zugriffstoken umfasst folgende Elemente: 

• Die Liste der Sicherheitskennungen, die den Benutzer repräsentieren (einschließlich der in 

SIDHistory gespeicherten Sicherheitskennungen) 

• Alle Gruppen (einschließlich verschachtelter Gruppen), denen der Benutzer angehört 

• Die Benutzerprivilegien (auch Benutzerrechte genannt) auf dem lokalen Computer 

Allen geschützten Objekten oder Ressourcen wird eine DACL (Discretionary Access Control List) 

zugewiesen, in der die Zugriffsrechte von Benutzern und Gruppen für diese Ressource definiert sind. 

Der Zugriff auf diese Objekte oder Ressourcen wird durch eine Zugriffsüberprüfung gesteuert, bei 

dem das Sicherheitssystem ermittelt, ob der angeforderte Zugriff gewährt oder verweigert werden 

sollte. Hierzu werden die Inhalte des Zugriffstokens des Anfordernden überprüft und mit der DACL 

der Ressource verglichen.


Kerberos-Sicherheit 

Bisher wurden die Grundlagen der AD DS-Sicherheit besprochen, ohne auf den tatsächlichen Mechanismus 

einzugehen, der die Sicherheit implementiert. Der primäre Mechanismus zur Bereitstellung 

der Authentifizierung in den AD DS ist das Kerberos-Protokoll. Dieses Protokoll wurde in den späten 

80er Jahren am Massachusetts Institute of Technology (MIT) entwickelt. Die aktuelle Version von 

Kerberos ist Version 5 (Kerberos 5), beschrieben in RFC 1510, „The Kerberos Network Authentication 

Service (V5)“. Die Windows Server 2008-Implementierung von Kerberos ist vollständig kompatibel 

mit RFC-1510 und weist einige Erweiterungen für die Authentifizierung mit öffentlichen Schlüsseln 

auf. 

Kerberos ist das standardmäßige Authentifizierungsprotokoll für Windows 2000 und Windows Server 

2003 Active Directory sowie für Windows Server 2008 AD DS. Wann immer ein Windows 2000- 

Client (oder ein Client mit einer höheren Windows-Version) sich gegenüber Active Directory oder 

den AD DS authentifiziert, versucht der Client Kerberos zu verwenden. Das zweite Protokoll, das zur 

Authentifizierung gegenüber den AD DS verwendet werden kann, ist NTLM. Dieses Protokoll wird 

jedoch hauptsächlich zur Bereitstellung von Abwärtskompatibilität mit älteren Clients verwendet. 

Kerberos hat gegenüber NTLM zahlreiche Vorteile: 

• Gegenseitige Authentifizierung Mit NTLM erfolgt die Authentifizierung einseitig, d.h. der Server 

authentifiziert den Client. Bei Verwendung von Kerberos kann der Client auch den Server authentifizieren. 

Auf diese Weise wird sichergestellt, dass der auf die Anforderung antwortende Server 

der richtige Server ist. 

• Effizienterer Zugriff auf Ressourcen Wenn ein Benutzer versucht, auf eine Netzwerkressource in 

einem NTLM-basierten Netzwerk (z.B. Microsoft Windows NT 4) zuzugreifen, muss der Server, 

auf dem sich die Ressource befindet, einen Domänencontroller kontaktieren, um die Zugriffsberechtigungen 

des Benutzers zu überprüfen. In einem Kerberos-basierten Netzwerk stellt der 

Client eine Verbindung zum Domänencontroller her und ruft ein Dienstticket zur Verbindungsherstellung 

mit dem Ressourcenserver ab. Dies bedeutet, dass der Ressourcenserver keine Verbindung 

zum Domänencontroller herstellen muss. 

• Verbesserte Verwaltung von Vertrauensstellungen NTLM-Vertrauensstellungen sind stets unidirektional, 

nicht transitiv und werden manuell konfiguriert. Kerberos-Vertrauensstellungen sind transitiv, 

bidirektional und werden automatisch konfiguriert und zwischen allen Domänen in einer 

Gesamtstruktur verwaltet. Zusätzlich können Kerberos-Vertrauensstellungen zwischen Gesamtstrukturen 

und zwischen Windows Server 2008-Kerberos-Domänen und anderen Kerberos-Implementierungen 

konfiguriert werden. 

• Delegierte Authentifizierung Wenn ein Client unter Verwendung der NTLM-Authentifizierung eine 

Verbindung mit einem Server herstellt, kann der Server die Clientanmeldeinformationen nur für 

den Zugriff auf Ressourcen des lokalen Servers verwenden. Mit der Kerberos-Authentifizierung 

kann der Server die Clientanmeldeinformationen für den Zugriff auf die Ressourcen eines anderen 

Servers nutzen. 

Hinweis Windows Server 2008 unterstützt darüber hinaus auch die Authentifizierung über SSL/TLS 

(Secure Sockets Layer/Transport Layer Security), die Digest- und die Passport-Authentifizierung. Da diese 

Authentifizierungsdienste jedoch hauptsächlich in einer Internetumgebung für die Authentifizierung gegenüber 

Microsoft IIS 7.0 (Internet Information Services, Internetinformationsdienste) zum Einsatz kommen, 

werden diese Authentifizierungsoptionen hier nicht besprochen.

Einführung in Kerberos 

Kerberos-Sicherheit 277 

Ein Kerberos-basiertes System umfasst drei Komponenten. Die erste Komponente ist der Client, der 

Zugriff auf Netzwerkressourcen benötigt. Die zweite Komponente ist der Server, der die Netzwerkressourcen 

verwaltet und sicherstellt, dass nur ordnungsgemäß authentifizierte und autorisierte Benutzer 

Zugriff auf die Ressource erhalten. Die dritte Komponente ist ein Schlüsselverteilungscenter (Key 

Distribution Center, KDC), das als zentraler Ort für die Speicherung von Benutzerinformationen und 

als zentraler Dienst für die Benutzerauthentifizierung dient. 

Das Kerberos-Protokoll definiert, wie diese drei Komponenten interagieren. Diese Interaktion basiert 

auf zwei Hauptgrundsätzen. Zunächst wird beim Kerberos-Modell davon ausgegangen, dass der 

Authentifizierungsdatenverkehr zwischen einer Arbeitsstation und einem Server über ein unsicheres 

Netzwerk erfolgt. Dies bedeutet, dass vertrauliche Anmeldeinformationen niemals als Klartext über 

das Netzwerk gesendet werden. Ein praktisches Beispiel hierfür ist, dass das Benutzerkennwort niemals 

über das Netzwerk gesendet wird, auch nicht in verschlüsselter Form. Der zweite Grundsatz 

besagt, dass die Verwendung von Kerberos basierend auf einem Authentifizierungsmodell mit einem 

gemeinsamen geheimen Schlüssel erfolgt. In einem Authentifizierungsmodell mit gemeinsamem 

geheimem Schlüssel verwenden der Client und der authentifizierende Server gemeinsam einen 

geheimen Schlüssel, der niemandem sonst bekannt ist. In den meisten Fällen, in denen sich Benutzer 

gegenüber dem Netzwerk authentifizieren, handelt es sich bei dem gemeinsamen geheimen Schlüssel 

um das Benutzerkennwort. Wenn der Benutzer sich an einem über Kerberos geschützten Netzwerk 

anmeldet, wird ein Hash des Benutzerkennworts zum Verschlüsseln eines Informationspakets verwendet. 

Sobald das Schlüsselverteilungscenter das Paket erhält, entschlüsselt es die Informationen mit 

dem in den AD DS gespeicherten Benutzerkennworthash. Ist die Entschlüsselung erfolgreich, weiß 

der authentifizierende Server, dass der Benutzer den gemeinsamen geheimen Schlüssel kennt, und der 

Zugriff wird gewährt. 

Hinweis Wenn sich der Benutzer anmeldet, gibt er bzw. sie üblicherweise ein Kennwort ein. Der Domänencontroller 

prüft, ob das Kennwort korrekt ist. Da die Verwendung von Kerberos jedoch in der Annahme 

erfolgt, das Netzwerk sei unsicher, wird diese Prüfung durchgeführt, ohne dass das Kennwort über das Netzwerk 

gesendet wird. 

Eines der Probleme bei einem Authentifizierungsmodell mit gemeinsamem geheimem Schlüssel 

besteht darin, dass der Benutzer und der Server, der die Netzwerkressource verwaltet, über eine 

Methode zur gemeinsamen Verwendung des geheimen Schlüssels verfügen müssen. Wenn ein Benutzer 

versucht, Zugriff auf eine Ressource eines Servers zu erlangen, kann ein Benutzerkonto mit einem 

Kennwort auf dem Server erstellt werden, das nur der Benutzer kennt. Wenn der Benutzer versucht, 

auf die Ressourcen des Servers zuzugreifen, kann der Benutzer den gemeinsamen geheimen Schlüssel 

(das Kennwort) vorlegen und erhält Zugriff auf die Ressource. In einer Unternehmensumgebung 

jedoch können Tausende von Benutzern und Hunderte von Servern vorliegen. Die Verwaltung individueller 

gemeinsamer geheimer Schlüssel für sämtliche dieser Benutzer wäre praktisch unmöglich. 

Kerberos umgeht dieses Problem durch die Verwendung eines Schlüsselverteilungscenters (Key Distribution 

Center, KDC). Das Schlüsselverteilungscenter wird als Dienst auf einem Domänencontroller 

im Netzwerk ausgeführt und verwaltet die gemeinsamen geheimen Schlüssel für alle Benutzer im 

Netzwerk. Das Schlüsselverteilungscenter verfügt über eine zentrale Datenbank aller Benutzerkonten 

im Netzwerk und speichert den gemeinsamen geheimen Schlüssel für jeden Benutzer (in Form 

eines unidirektionalen Hashwerts des Benutzerkennworts).


In einer AD DS-Umgebung werden diese gemeinsamen geheimen Schlüssel im AD DS-Datenspeicher 

abgelegt. Wenn ein Benutzer Zugriff auf das Netzwerk und auf Ressourcen im Netzwerk benötigt, 

bestätigt das Schlüsselverteilungscenter, dass der Benutzer den gemeinsamen geheimen Schlüssel 

kennt und authentifiziert den Benutzer. Das Schlüsselverteilungscenter speichert darüber hinaus auch 

gemeinsame geheime Schlüssel für Computer, die Mitglieder der AD DS-Domäne sind. Diese Schlüssel 

werden zur Authentifizierung von Computern verwendet, die für den Zugriff auf Netzwerkressourcen 

eingesetzt werden. 

Hinweis In der Kerberos-Terminologie ist dieser zentrale Server zur Verwaltung des Benutzerkontos ein 

Schlüsselverteilungscenter (Key Distribution Center, KDC), wie zuvor besprochen. In der Windows Server 

2008-Implementierung von Kerberos wird dieser Server als Domänencontroller bezeichnet. Jeder AD DS- 

Domänencontroller, schreibgeschützte Domänencontroller eingeschlossen, ist ein Schlüsselverteilungscenter. 

In Kerberos wird die Grenze, die durch die Benutzerdatenbank für ein Schlüsselverteilungscenter definiert 

ist, als Bereich bezeichnet. In der Windows Server 2008-Terminologie wird diese Grenze Domäne 

genannt. 

Jedes Schlüsselverteilungscenter (ausgeführt als Kerberos-Schlüsselverteilungscenter-Dienst in 

Windows Server 2008) umfasst zwei getrennte Dienste: den Authentifizierungsdienst (AS) und den 

Ticketerteilungsdienst (Ticket Granting Service, TGS). Der Authentifizierungsdienst ist für die 

anfängliche Clientanmeldung verantwortlich und gibt ein TGT an den Client aus (Ticket-Granting 

Ticket). Der Ticketerteilungsdienst (TGS) ist für alle Diensttickets verantwortlich, mit denen auf Ressourcen 

im Windows Server 2008-Netzwerk zugegriffen wird. 

Das Schlüsselverteilungscenter speichert die Kontodatenbank für die Kerberos-Authentifizierung. In 

der Windows Server 2008-Implementierung von Kerberos wird die Datenbank durch den Verzeichnissystem-Agenten 

(Directory System Agent, DSA) verwaltet, der innerhalb des LSA-Prozesses auf 

jedem Domänencontroller ausgeführt wird. Clients und Anwendungen erhalten niemals direkten 

Zugriff auf die Kontodatenbank; alle Anforderungen müssen über den Verzeichnissystem-Agenten 

und unter Verwendung einer der AD DS-Schnittstellen erfolgen. Jedes Objekt innerhalb der Kontodatenbank 

(tatsächlich jedes Attribut für jedes Objekt) wird durch eine Zugriffssteuerungliste (Access 

Control List, ACL) geschützt. Der Verzeichnissystem-Agent stellt sicher, dass Zugriffsversuche auf 

die Kontodatenbank ordnungsgemäß autorisiert werden. 

Hinweis Wenn die AD DS auf dem ersten Domänencontroller in der Domäne installiert werden, wird ein 

spezielles Konto namens krbtgt in der Domäne erstellt. Das Konto kann weder gelöscht noch umbenannt 

werden und sollte niemals aktiviert oder aus dem Container Users verschoben werden. Dem Konto wird bei 

der Erstellung ein Kennwort zugewiesen, und das Kennwort wird automatisch in regelmäßigen Abständen 

geändert. Dieses Kennwort wird verwendet, um einen geheimen Schlüssel zu erstellen, der zum Verschlüsseln 

und Entschlüsseln der TGTs eingesetzt wird, die von allen Domänencontrollern (Schlüsselverteilungscentern) 

in der Domäne ausgegeben werden. Für jeden schreibgeschützten Domänencontroller wird ein 

eindeutiges krbtgt-Konto angelegt, wenn der Computer heraufgestuft wird. Auf diese Weise wird eine kryptografische 

Isolierung zwischen den Schlüsselverteilungscentern in unterschiedlichen Teilstrukturen erreicht, 

und es wird verhindert, dass ein gefährdeter schreibgeschützter Domänencontroller (Read-Only Domain 

Controller, RODC) Diensttickets and Ressourcen in anderen Teilstrukturen oder einem Hubstandort ausgibt.

Kerberos-Authentifizierung 


Die Kerberos-Authentifizierung beginnt, wenn der Kerberos-Sicherheitsanbieter durch die lokale 

Sicherheitsautorität auf einer Windows Vista-Arbeitsstation oder einem Windows Server 2008-Computer 

aufgerufen wird. Wenn ein Benutzer sich durch Eingabe eines Benutzernamens und Kennworts 

anmeldet, wendet der Clientcomputer einen einseitigen Hash auf das Benutzerkennwort an, um einen 

geheimen Schlüssel zu erzeugen. Dieser wird anschließend in einem sicheren Speicherbereich auf der 

Arbeitsstation zwischengespeichert. Bei Verwendung eines einseitigen Hashwerts kann das Kennwort 

nicht aus dem Hash abgeleitet werden. Der Hashwert ist außerdem konsistent – wenn ein Hash 

auf dasselbe Kennwort angewendet wird, ist das Ergebnis immer gleich. 

Hinweis Dieser Vorgang gilt auch für Computer unter Windows 2000 Professional oder höheren Clientbetriebssystemen, 

sowie für Windows 2000 Server oder höhere Serverbetriebssysteme. 

Zur Durchführung einer Clientanmeldung werden auf den Client- und Serversystemen die folgenden 

Schritte ausgeführt: 

1. Der Kerberos-SSP auf der Arbeitsstation sendet eine Authentifizierungsmeldung an das Schlüsselverteilungscenter. 

(Siehe Abbildung 8.1.) Die Meldung hat folgenden Inhalt: 

Benutzername 

Benutzerbereich (Domänenname) 

Anforderung für ein TGT 

Vorauthentifizierungsdaten, z.B. einen Zeitstempel und mögliche weitere Daten 

Die Vorauthentifizierungsdaten werden mithilfe des geheimen Schlüssels verschlüsselt, der aus 

dem Benutzerkennwort abgeleitet wurde. 

2. Sobald die Meldung beim Schlüsselverteilungscenter eintrifft, untersucht der Server den Benutzernamen 

und prüft die Verzeichnisdatenbank auf seine Kopie des geheimen Schlüssels, der mit 

dem Benutzerkonto verknüpft ist. Der Server entschlüsselt die verschlüsselten Daten in der Meldung 

mit dem geheimen Schlüssel und prüft den Zeitstempel. Wenn die Entschlüsselung erfolgreich 

durchgeführt und der Zeitstempel innerhalb von fünf Minuten zur aktuellen Serverzeit 

registriert wurde, bereitet der Server die Authentifizierung des Benutzers vor. Schlägt die Entschlüsselung 

fehl, muss der Benutzer das falsche Kennwort eingegeben haben, und die Authentifizierung 

ist nicht erfolgreich. Wenn der Zeitstempel mehr als fünf Minuten von der aktuellen 

Serverzeit liegt, schlägt die Authentifizierung ebenfalls fehl. Das kurze Zeitfenster soll verhindern, 

dass jemand die Authentifizierungspakete sammelt und sie zu einem späteren Zeitpunkt wieder 

abspielt. Der standardmäßige maximal zulässige Zeitunterschied von fünf Minuten kann in den 

Domänensicherheitsrichtlinien konfiguriert werden. 

3. Nach der Authentifizierung des Benutzers sendet der Server eine Nachricht an den Client, die 

einen TGS-Sitzungsschlüssel (Ticket Granting Service, Ticketerteilungsdienst) und ein TGT enthält. 

(Siehe Abbildung 8.1.) Bei dem Sitzungsschlüssel handelt es sich um einen Verschlüsselungsschlüssel, 

der zur Interaktion mit dem Schlüsselverteilungscenter (KDC) eingesetzt wird, 

anstatt den geheimen Schlüssel des Clients zu verwenden. Das TGT erteilt dem Benutzer Zugriff 

auf den TGS. Für die Lebensdauer des TGT zeigt der Client dem TGS das TGT vor, wann immer 

der Client auf Ressourcen im Netzwerk zugreifen muss.


Alle Zugriffstoken für den Prinzipal (einschließlich der Benutzer-SID und der Sicherheitsgruppen- 

SIDs) sind ebenfalls im TGT enthalten. Diese Informationen sind als PAC (Privilege Attribute 

Certificate) bekannt. Der TGS-Sitzungsschlüssel wird anhand des geheimen Schlüssels des Benutzers 

verschlüsselt. Zusätzlich wird das TGT mit dem langfristigen geheimen Schlüssel des KDC 

(KRBRGT) verschlüsselt. 

Benutzername 

Bereichsname 

TGT-Anforderung 

Präauthentifizierungsdaten 

(verschlüsselt mit geheimem Benutzerschlüssel) 

1 


4 

Extrahiert TGS-Sitzungsschlüssel 

Fügt das Sitzungsticket in 

den Zwischenspeicher ein 

Löscht geheimen Schlüssel 

Arbeitsstation 

2 

KDC 

Überprüft Benutzername 

Extrahiert geheimen Schlüssel 

Entschlüsselt Präauthentifizierungsdaten 

Überprüft Zeitstempel 

3 

Ticketinformationen 

TGT-Sitzungsschlüssel 

Benutzeranmeldeinformationen 

Abbildung 8.1 

Abrufen eines Kerberos-TGT 

4. Wenn das Paket beim Clientcomputer ankommt, wird der geheime Schlüssel des Benutzers zum 

Entschlüsseln des TGS-Sitzungsschlüssels verwendet. Verläuft die Entschlüsselung erfolgreich 

und ist der Zeitstempel gültig, geht der Computer des Benutzers davon aus, dass das KDC authentisch 

ist, weil ihm der geheime Schlüssel des Benutzers bekannt war. Der TGS-Sitzungsschlüssel 

wird anschließend auf dem lokalen Computer zwischengespeichert, bis er abläuft oder bis der 

Benutzer sich von der Arbeitsstation abmeldet. Dieser TGS-Sitzungsschlüssel wird zum Verschlüsseln 

aller zukünftigen Verbindungen mit dem KDC verwendet. Das bedeutet, dass der 

Client sich den geheimen Schlüssel nicht länger merken muss und dass dieser aus dem Cache der 

Arbeitsstation gelöscht wird. Das TGT wird in verschlüsselter Form im Cache der Arbeitsstation 

gespeichert. 

Hinweis Das Kerberos-Protokoll umfasst den Authentication Service (AS) Exchange, das Unterprotokoll, 

das zum Durchführen der anfänglichen Authentifizierung des Benutzers verwendet wird. Der oben 

beschriebene Vorgang verwendet das AS Exchange-Unterprotokoll. Die anfängliche Nachricht, die vom 

Client an das KDC gesendet wurde, wird als KRB_AS_REQ-Nachricht bezeichnet. Die Serverantwort an 

den Client wird als KRB_AS_REP-Nachricht bezeichnet.


5. An dieser Stelle ist der Benutzer authentifiziert, besitzt jedoch noch keinen Zugriff auf Ressourcen 

im Netzwerk. Das TGT erteilt dem Ticketerteilungsdienst Zugriff; um jedoch Zugriff auf 

andere Ressourcen im Netzwerk zu erhalten, muss der Benutzer ein Dienstticket vom TGS beziehen. 

(Siehe Abbildung 8.2.) Die Clientarbeitsstation sendet eine Dienstticketanforderung an den 

TGS. Die Anforderung enthält den Namen des Zielcomputers, die Domäne des Zielcomputers, 

das während der Authentifizierung erteilte TGT, den SPN (Service Principal Name), auf den der 

Benutzerprinzipal zugreifen möchte, und einen Zeitstempel, der anhand des während des AS 

Exchange-Vorgangs bezogenen TGS-Sitzungsschlüssels verschlüsselt wurde. 

8 

Fügt das Sitzungsticket in den 

Zwischenspeicher ein 

Arbeitsstation 

Netzwerkdienst 

5 Name des Zielcomputers 

Domäne des Zielcomputers 

TGT (weiterhin mit dem 

dauerhaften Schlüssel des KDCs) 

Der SPN, auf den der 

UPN zugreifen möchte 

Zeitstempel 

7 

Das Sitzungsticket umfasst 

folgende Komponenten: 

Sitzungsticket für Client 

(verschlüsselt 

mit Clientsitzungsschlüssel) 

Sitzungsticket für 

Netzwerkdienst (verschlüsselt 

mit dauerhaftem 

Netzwerkdienstschlüssel) 


6 KDC entschlüsselt TGT 

mit seinem dauerhaften 

Schlüssel 

Extrahiert den Sitzungsschlüssel 

Entschlüsselt den Zeitstempel 

Bereitet das Sitzungsticket für 

den Netzwerkdienst vor 

Abbildung 8.2 

Anfordern eines Kerberos-Sitzungstickets für eine Netzwerkressource 

6. Das KDC entschlüsselt das TGT anhand des langfristigen Schlüssels. Anschließend extrahiert es 

den TGS-Sitzungsschlüssel aus dem TGT und entschlüsselt den Zeitstempel, um sicherzustellen, 

dass der Client den korrekten Sitzungsschlüssel verwendet und dass der Zeitstempel noch immer 

gültig ist. Wenn der Sitzungsschlüssel und der Zeitstempel zulässig sind, führt das KDC anschließend 

eine LDAP-Abfrage durch, um das Konto zu finden, für das der Dienstprinzipal registriert 

ist. Danach bereitet es ein Dienstticket für den angeforderten Dienst vor. 

7. Die Antwort enthält zwei Kopien eines Dienstsitzungsschlüssels. Die erste Kopie des Dienstsitzungsschlüssels 

wird über den TGS-Sitzungsschlüssel verschlüsselt, den der Client während der 

ersten Anmeldung erhalten hat. Die zweite Kopie des Dienstsitzungsschlüssels ist für den Dienstprinzipal 

bestimmt, der den angeforderten Dienst hostet und die Zugriffsinformationen des 

Benutzers enthält – ein Dienstticket. Das Dienstticket wird über den geheimen Schlüssel des 

Dienstprinzipals verschlüsselt, der den Netzwerkdienst hostet. Dieser Schlüssel ist der Clientarbeitsstation 

unbekannt, jedoch sowohl dem KDC als auch dem Dienstprinzipal bekannt, da der 

Dienstprinzipal sich im KDC-Bereich oder in einem vertrauten Kerberos-Bereich befindet.


8. Die Clientarbeitsstation speichert beide Teile des Sitzungstickets im Arbeitsspeicher zwischen. 

Hinweis Der in den Schritten 5 bis 8 beschriebene Vorgang verwendet das TGS Exchange-Unterprotokoll. 

Die vom Client gesendete Sitzungsticketanforderung wird als KRB_TGS_REQ-Nachricht bezeichnet; 

die Serverantwort ist eine KRB_TGS_REP-Nachricht. 

9. Der Client legt das Dienstticket jetzt dem Netzwerkdienst vor, um Zugriff zu erhalten. (Siehe 

Abbildung 8.3.) 

9 

Sitzungsticket 

wird an den 


gesendet 

Arbeitsstation Netzwerkdienst 

10 Entschlüsselt den 

Sitzungsschlüssel 

des Netzwerkdiensts 

Überprüft das Benutzerzugriffstoken 

Gewährt Zugriff auf Arbeitsstation 

Abbildung 8.3 

Zugreifen auf den Netzwerkdienst 

10. Der Netzwerkdienst verschlüsselt das Dienstticket über seinen geheimen Schlüssel. Mithilfe des 

Dienstsitzungsschlüssels entschlüsselt der Dienst anschließend den in der Anforderung enthaltenen 

Zeitstempel. Wenn beide Entschlüsselungen erfolgreich verlaufen und der Zeitstempel 

innerhalb von fünf Minuten der Uhrzeit des Hostcomputers liegt, vertraut der Dienst darauf, 

dass das Ticket vom KDC ausgestellt wurde. Der Netzwerkdienst stellt anschließend fest, ob der 

Client eine gegenseitige Authentifizierung angefordert hat. Wenn der Client eine gegenseitige 

Authentifizierung anfordert, verschlüsselt der Dienst denselben Zeitstempel, den er in der Anforderung 

erhalten hat, mithilfe des Dienstsitzungsschlüssels und antwortet dem Client. 

Der Dienst sendet eine Antwort zurück an den Client, wenn der Client eine gegenseitige Authentifizierung 

anfordert. In diesem Fall entschlüsselt der Client den Zeitstempel anhand des Dienstsitzungsschlüssels. 

Dann vergleicht der Client den erhaltenen Zeitstempel in der Antwort mit dem 

Zeitstempel, den er in der ursprünglichen Anforderung gesendet hat. Wenn die Zeitstempel übereinstimmen, 

vertraut der Client dem Dienst. 

Nach Abschluss der Kerberos-Authentifizierung leitet der Dienstprinzipal, der den angeforderten 

Dienst hostet, das Dienstticket an die LSA. Die LSA entschlüsselt daraufhin das Dienstticket und 

extrahiert die Autorisierungsdaten. Die Autorisierungsdaten enthalten die Benutzer-SID und die 

SIDs von Gruppen, denen der Benutzer angehört. Die LSA verwendet diese Daten für die Erstellung 

eines Zugriffstokens. Die Autorisierungsdaten werden als Privilege Attribute Certificate oder 

PAC bezeichnet. 

Hinweis Der in den Schritten 9 bis 10 beschriebene Vorgang verwendet das Client-/Server-Exchange- 

Unterprotokoll (CS). Die Clientanforderung wird als KRB_AP_REQ-Nachricht bezeichnet.


Praxistipp: Dienstprinzipalnamen 

Sie können Dienstprinzipalnamen (Service Principal Names, SPN) Benutzer- oder Computerkonten 

zuweisen. Dienstprinzipalnamen werden in einem Active Directory-Mehrwertattribut des 

Benutzer- oder Computerkontos gespeichert. Auf diese Weise kann jeder Benutzer oder Computer 

mehrere SPNs besitzen. SPNs müssen in der gesamten Active Directory-Gesamtstruktur eindeutig 

sein. 

Im Folgenden sehen Sie ein Beispiel für ein Attribut eines Dienstprinzipalnamens für ein Active 

Directory-Objekt: 

Host /DC1 

Host/DC1.contoso.com 

Dieser Beispiel-SPN wird folgendermaßen gelesen: der Dienstname Host auf dem Sicherheitsprinzipal 

DC1. Der nächste Dienstprinzipalname beschreibt denselben Dienst, verwendet jedoch einen 

anderen Sicherheitsprinzipal: DC1.contoso.com. Die Kerberos-Authentifizierung basiert auf 

Namen. Wenn Ihre Clients sich sowohl über NetBIOS- als auch über FQDN-Namen verbinden, 

möchten Sie sicherstellen, dass Sie den angeforderten Dienst, wie im Beispiel gezeigt, unter beiden 

Namen registrieren. 

Im Folgenden sehen Sie ein Beispiel für einen Dienstprinzipalnamen für ein Benutzerkonto, unter 

dem der SQL-Dienst ausgeführt wird. Windows startet den SQL-Dienst mithilfe eines Domänenbenutzerkontos 

(auch als Dienstkonto bezeichnet). Sie müssen den SQL-Dienstprinzipalnamen auf 

dem Benutzerkonto registrieren, da dies das Konto ist, an das Sie die Authentifizierung delegieren. 

Ein gängiger Konfigurationsfehler besteht darin, den SPN auf dem Computerkonto zu registrieren, 

das den SQL-Dienst hostet. 

MSSQLSvc/sqlsrvr.contoso.com:1433 

MSSQLSvc/sqlsrvr:1433 

Kerberos-fähige Dienste verwenden eine vorkonfigurierte Dienstkennung in ihrem SPN. In 

diesem Beispiel verwendet der Microsoft SQL-Dienst MSSQLSvc. Dieser Dienstprinzipalname 

wird folgendermaßen gelesen: Der Microsoft SQL-Dienst (MSSQLSvc) wird auf dem Computer 

sqlsrvr.contoso.com gehostet, und diese Instanz von SQL hört Port 1433 ab. Wieder berücksichtigen 

wir sowohl den FQDN- als auch den NetBIOS-Namen für den Server, um sicherzustellen, dass 

die Authentifizierung mit beiden Namen funktioniert. Denken Sie daran, dass der Dienstprinzipalname 

in der Active Directory-Gesamtstruktur eindeutig sein muss. 

Microsoft bietet mehrere Dienstprogramme, mit deren Hilfe Sie Dienstprinzipalnamen anzeigen 

können. Zu diesen Dienstprogrammen gehören LDP, LDIFDE, ADSIEdit und SETSPN. 

Robert Greene 

Microsoft Support Escalation Engineer 

Wenn die Authentifizierung und die Autorisierung erfolgreich durchgeführt werden, erhält der Client 

Zugriff auf die Serverressourcen. Wenn der Client dieselbe Ressource oder denselben Dienst anschließend 

noch einmal verwendet, wird das Sitzungsticket aus dem Ticketzwischenspeicher bezogen und 

erneut an den Zielressourcenserver ausgestellt. Ist das Sitzungsticket abgelaufen, muss der Client sich 

erneut an das KDC wenden, um ein neues Ticket zu erhalten.


Hinweis Der Inhalt des Clientzwischenspeichers kann mithilfe von zwei Tools angezeigt werden. 

KList.exe, welches auf Computern unter Windows Server 2008 installiert wird, bietet eine Befehlszeilenschnittstelle 

zum Anzeigen und Löschen der Kerberos-Tickets. Das Kerberos Tray-Tool (Kerbtray.exe) bietet 

eine grafische Benutzeroberfläche zum Anzeigen der Tickets. Abbildung 8.4 zeigt ein Beispiel für die vom 

Kerberos Tray-Tool bereitgestellten Informationen. Das Kerberos Tray-Tool steht als Bestandteil der Windows 

Server 2003 Resource Kit Tools zur Verfügung, die unter https://www.microsoft.com/downloads/ 

details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en heruntergeladen werden 

können 

Abbildung 8.4 

Anzeigen von Kerberos-Tickets über das Kerberos Tray-Tool 

So funktioniert es: Kerberos-Ticketflags 

Ticketflags werden innerhalb aller Tickets konfiguriert und identifizieren den Zweck und/oder die 

Einschränkungen des Tickets. Sie können diese Flags anzeigen, wenn Sie das Dienstprogramm 

Kerberos Tray verwenden. Kerberos-Tickets nutzen die folgenden Ticketflags: 

• Weiterleitbar Nur gültig für ein TGT. Weist den Ticketerteilungsdienst an, dass er ein neues 

TGT mit einer anderen Netzwerkadresse basierend auf dem vorgelegten TGT ausstellen kann. 

Ein weiterleitbares Ticket kann in der Kerberos-Delegierung verwendet werden. 

• Weitergeleitet Zeigt an, dass das TGT weitergeleitet wurde oder dass ein Ticket von einem 

weiterleitbaren TGT ausgegeben wurde. Die Anwendung der mittleren Schicht in der Kerberos- 

Delegierung sollte diesen Tickettyp besitzen. 

• Übertragbar Ein übertragbares Ticket ist ein Ticket (in der Regel nur ein TGT), das Ihnen das 

Abrufen eines Tickets für einen Dienst mit anderen IP-Adressen als den im TGT enthaltenen 

ermöglicht. Dies unterscheidet sich von einem weiterleitbaren Ticket insofern als dass Sie ein 

neues TGT nicht von Ihrem aktuellen TGT übertragen können; Sie können nur Nicht-TGT- 

Diensttickets übertragen.


• Proxy Dieses Ticketflag weist darauf hin, dass das Dienstticket von einem übertragbaren TGT 

erhalten wurde. 

• Verlängerbar Zeigt an, dass das Ticket erneuert werden kann. Dieses Flag wird in Verbindung 

mit den Feldern EndTime und Renew-Till verwendet, damit Tickets im KDC regelmäßig erneuert 

werden. 

• Anfang Zeigt an, dass es sich um ein TGT (Ticket Granting Ticket) handelt. 

Weitere Flags sind unter anderem May Postdate, Invalid, HW Auth und OK As Delegate. Nachdatierte 

Tickets können im Voraus zur Batchverarbeitung etc. angefordert werden, sind jedoch bis zu 

dem Zeitpunkt, zu dem sie in Kraft treten, als ungültig gekennzeichnet. Ein KDC muss das Ticket 

validieren und das Flag Ungültig zum gegebenen Zeitpunkt entfernen. 

Robert Greene 


Dieser Prozess zum Erlangen des Zugriffs auf eine Ressource im Netzwerk bedeutet, dass das KDC 

nur während der anfänglichen Clientanmeldung und beim ersten Zugriffsversuch des Clients auf eine 

bestimmte Ressource auf einem bestimmten Server einbezogen wird. Bei der ersten Anmeldung erhält 

ein Benutzer ein TGT, das dem Client für die Lebensdauer des Tickets Zugriff auf das KDC erteilt. 

Wenn der Client sich mit einer Netzwerkressource zu verbinden versucht, wendet sich der Client 

erneut an das KDC und erhält ein Dienstticket für den Zugriff auf die Ressource. Dieses Dienstticket 

enthält die Autorisierungsdaten für den Benutzer. Nach einer erfolgreichen Authentifizierung verwendet 

das lokale Sicherheitssubsystem diese Daten zum Erstellen eines Zugriffstokens auf dem Computer, 

der den Dienst oder die Ressource hostet, sodass der Server den Grad des Ressourcenzugriffs 

ermitteln kann, der dem Benutzer zugeteilt werden soll. 

Domänenübergreifende Authentifizierung 

Derselbe Authentifizierungsprozess gilt für die Authentifizierung eines Benutzers über Domänengrenzen 

hinweg. Beispielsweise besitzt ein Unternehmen eine Gesamtstruktur mit drei Domänen, 

wie in Abbildung 8.5 gezeigt. 

Wenn ein Benutzer mit einem Konto in TreyResearch.com zum Domänenstandort von NA.ADatum.com 

reist und sich auf einem Rechner in der Domäne NA.ADatum.com am Netzwerk anzumelden 

versucht, muss die Clientarbeitsstation sich mit einem Domänencontroller (KDC) in der Domäne 

TreyResearch.com sowie in NA.ADatum.com und ADatum.com verbinden können. In diesem Fall 

sendet der Clientcomputer die ursprüngliche Anmeldeanforderung an den Domänencontroller 

NA.ADatum.com. Der Domänencontroller stellt fest, dass das Benutzerkonto sich in der Domäne 

TreyResearch.com befindet und muss daher die Clientarbeitsstation an diese Domäne verweisen. 

Wenn alle Domänen mit Shortcutvertrauensstellungen konfiguriert wurden, kann der Domänencontroller 

den Clientcomputer direkt an einen Domänencontroller in der Domäne TreyResearch.com 

verweisen. Wenn jedoch keine Shortcutvertrauensstellungen erstellt wurden, gibt es keine direkte 

Vertrauensstellung zwischen NA.ADatum.com und TreyResearch.com. In diesem Fall verweist 

der NA-Domänencontroller den Clientcomputer an einen Domänencontroller in der Domäne 

ADatum.com. Der Verweis umfasst ein TGT für ADatum.com, das mit einem bereichsübergreifenden 

Sitzungsschlüssel verschlüsselt wurde, der sowohl von ADatum.com als auch von 

NA.Adatum.com genutzt wird. Dieses TGT ermöglicht den Zugriff auf den KDC-Dienst auf dem 

Domänencontroller in der Domäne Adatum.com.


Der bereichsübergreifende Sitzungsschlüssel wurde erstellt, als die NA-Domäne der Gesamtstruktur 

Adatum.com hinzugefügt und die anfängliche Vertrauensstellung zwischen den beiden Domänen 

erstellt wurde. Der bereichsübergreifende Sitzungsschlüssel gewährleistet, dass die Anmeldeanforderung 

von einer vertrauten Domäne stammt. Der Clientcomputer sendet anschließend eine 

Authentifizierungsanforderung an die Domäne ADatum.com. Der Client wird dann an einen Domänencontroller 

in der Domäne TreyResearch.com verwiesen. Auch dieser Verweis umfasst ein TGT 

für TreyResearch.com, das über einen bereichsübergreifenden Sitzungsschlüssel für den Zugriff auf 

die KDC-Dienste auf dem Domänencontroller in TreyResearch.com verfügt. Der Clientcomputer 

sendet anschließend eine TGT-Anforderung an den Basisdomänencontroller in TreyResearch.com. 

Adatum.com 

NA.Adatum.com 


Abbildung 8.5 

Domänenübergreifende Authentifizierung 

Ein ähnlicher Vorgang wird durchgeführt, wenn ein Client auf eine Ressource zugreifen möchte, 

die nicht der Basisdomäne des Benutzers entspricht. In diesem Fall muss der Client ein Dienstticket 

von einem Domänencontroller in der Domäne anfordern, in der sich die Ressource befindet. 

Er wird demnach über denselben Vorgang weitergeleitet, bis er sich mit dem richtigen Domänencontroller 

verbinden kann. 

Dieser Authentifizierungsprozess hat besonders dann Auswirkungen auf den Gesamtstrukturentwurf, 

wenn Benutzer sich häufig an anderen Domänen als ihrer Basisdomäne anmelden oder auf 

Ressourcen in anderen Domänen zugreifen. Wenn Sie eine Gesamtstruktur mit mehreren Domänen 

entwerfen, muss der Client möglicherweise den gesamten Vertrauenspfad zwischen den Domänen 

durchlaufen. Wenn dies oft geschieht, empfiehlt es sich möglicherweise, Domänencontroller für die 

Stammdomänen in Standorten in der Nähe der Benutzer zu platzieren. Sie können auch Shortcutvertrauensstellungen 

verwenden, damit die Verweise der Domänencontroller direkt an die entsprechenden 

Domänen gesendet werden können. 

Delegieren der Authentifizierung 

Einer der Aspekte, die den Zugriff auf Netzwerkdienste kompliziert machen können, ist, dass der 

Netzwerkdienst über mehrere Server verteilt sein kann. Beispielsweise kann der Client sich mit einem 

Front-End-Server verbinden, der sich mit einem Back-End-Datenbankserver verbinden muss, um 

Informationen zu sammeln. In dieser Umgebung sollten die Anmeldeinformationen des Benutzers 

(und nicht die des Front-End-Servers) für den Zugriff auf den Back-End-Server verwendet werden, 

damit der Benutzer nur auf für ihn autorisierte Informationen zugreifen kann. Unter Windows 2000 

bietet Kerberos diese Funktionalität in zweierlei Hinsicht: Verwenden von Proxytickets und Verwenden 

weitergeleiteter Tickets. Wenn Proxytickets aktiviert sind, sendet der Client eine Sitzungsticketanforderung 

an das KDC und fordert Zugriff auf den Back-End-Server an.


Das KDC erteilt das Sitzungsticket und stellt im Ticket das Flag Übertragbar ein. Der Client legt 

anschließend dem Front-End-Server das Sitzungsticket vor, der wiederum das Ticket für den Zugriff 

auf Informationen auf dem Back-End-Server verwendet. Das Hauptproblem mit Proxytickets besteht 

darin, dass der Client die Identität des Back-End-Server kennen muss. Die zweite Option ist die Verwendung 

weitergeleiteter Tickets. Wenn diese Tickets aktiviert sind, sendet der Client eine AS 

Exchange-Anforderung an das KDC und fordert ein TGT an, das der Front-End-Server für den 

Zugriff auf Back-End-Server verwenden kann. Das KDC erstellt ein TGT und sendet es an den Client. 

Der Client sendet das TGT an den Front-End-Server, der das TGT anschließend zum Abrufen eines 

Sitzungstickets verwendet, um im Namen des Clients auf den Back-End-Server zuzugreifen. 

Bei der Weise, in der die Delegierung der Authentifizierung unter Windows 2000 implementiert ist, 

gibt es zwei erhebliche Bedenken. Der erste Grund ist, dass die Delegierung der Authentifizierung nur 

dann verwendet werden kann, wenn der Client über Kerberos authentifiziert ist. Das bedeutet, dass 

kein Client unter Windows NT, Microsoft Windows 95 oder Windows 98 die Delegierung der 

Authentifizierung nutzen kann. Der zweite Grund im Hinblick auf Windows 2000 hängt mit der 

Sicherheit der Delegierung zusammen. Nachdem der Front-End-Server das weitergeleitete Ticket vom 

KDC erhalten hat, kann er unter Windows 2000 dieses Ticket verwenden, um im Namen des Clients 

auf beliebige Netzwerkdienste zuzugreifen. Windows Server 2003 und Windows Server 2008 bieten 

die Option der eingeschränkten Delegierung. Das bedeutet, Sie können das Konto so konfigurieren, 

dass es nur für bestimmte Dienste im Netzwerk delegiert wird (basierend auf den Dienstprinzipalnamen). 

Die eingeschränkte Delegierung ist nur dann verfügbar, wenn die Domäne auf die Funktionsebene 

Windows Server 2003 oder Windows Server 2008 eingestellt ist. 

Damit die Delegierung der Authentifizierung erfolgreich ist, müssen Sie sicherstellen, dass sowohl 

das Benutzerkonto als auch das Dienst- oder Computerkonto so konfiguriert sind, dass sie die Delegierung 

der Authentifizierung unterstützen. Um dies an einem Benutzerkonto durchzuführen, öffnen 

Sie im Verwaltungsprogramm Active Directory-Benutzer und -Computer die Eigenschaften des 

Benutzers, wählen Sie die Registerkarte Konto, führen Sie einen Bildlauf in der Liste Kontooptionen 

durch, und stellen Sie sicher, dass die Option Konto ist vertraulich und kann nicht delegiert werden 

deaktiviert ist. (Diese Option ist standardmäßig nicht aktiviert.) Um das Dienstkonto für die Delegierung 

zu konfigurieren, müssen Sie zunächst ermitteln, ob es sich bei dem vom Dienst verwendeten 

Anmeldekonto um ein normales Benutzerkonto oder um das Konto LocalSystem handelt. Wenn der 

Dienst unter einem normalen Benutzerkonto ausgeführt wird, stellen Sie zuerst sicher, dass Sie dem 

Benutzerkonto einen SPN hinzugefügt haben. Öffnen Sie anschließend die Registerkarte Konto in den 

Benutzereigenschaften, und stellen Sie sicher, dass die Option Konto ist vertraulich und kann nicht 

delegiert werden deaktiviert ist. (Diese Option ist standardmäßig nicht aktiviert.) Prüfen Sie außerdem 

den entsprechenden Delegierungsgrad auf der Registerkarte Delegierung des Benutzerkontos. 

(Dieses Fenster ist in Abbildung 8.6 dargestellt.) Wenn der Dienst unter einem LocalSystem-Konto 

ausgeführt wird, muss die Delegierung im Eigenschaftenfenster des Computerkontos konfiguriert 

werden. Um die Authentifizierungsstufe von Windows 2000 zu implementieren, wählen Sie die 

Option Computer bei Delegierungen aller Dienste vertrauen (nur Kerberos) aus. Um die Erweiterungen 

von Windows Server 2003 oder Windows Server 2008 zu implementieren, wählen Sie die 

Option Computer bei Delegierungen angegebener Dienste vertrauen aus. Anschließend können Sie 

auswählen, ob der Client sich über Kerberos authentifizieren muss oder ein beliebiges Protokoll verwenden 

und die Dienste auswählen kann (basierend auf den in AD DS registrierten Dienstprinzipalnamen), 

denen der Computer delegierte Anmeldeinformationen vorlegen kann.


Abbildung 8.6 

Konfigurieren der eingeschränkten Delegierung für ein Computerkonto 

Praxistipp: Delegierte Authentifizierung 

Die delegierte Authentifizierung wird in Kundenumgebungen immer häufiger eingesetzt, weil der 

Benutzerzugriff auf vertrauliche Daten eingeschränkt werden muss. Außerdem muss täglich überwacht 

werden, auf welche Daten Benutzer zugreifen. Bei den heutigen Anwendungen handelt es 

sich normalerweise um mehrschichtige Lösungen, was für eine erhöhte Komplexität bei der 

Authentifizierung sorgt. Beispielsweise ist eine delegierte Authentifizierung erforderlich, wenn 

eine webbasierte Anwendung anhand der Anmeldeinformationen des Benutzers, der sich an der 

Website authentifiziert hat, Daten von einer SQL-Datenbank anfordern muss. Im Folgenden werden 

die am häufigsten auftretenden Probleme aufgeführt, die zu einem Fehlschlag der delegierten Authentifizierung 

führen: 

• Die Clientanwendung ist nicht für die Verwendung von Kerberos konfiguriert. Im vorliegenden 

Beispiel ist der Webbrowser die Clientanwendung, die Sie für die Unterstützung der Kerberos- 

Authentifizierung konfigurieren müssen. 

• SPNs werden nicht für das richtige Dienstkonto registriert. Im vorliegenden Beispiel müssen im 

Dienstkonto, das die Webanwendung ausführt, die richtigen SPNs für den Namen registriert sein, 

den Benutzer zum Verbinden mit der Webanwendung verwenden. Wenn Benutzer sich sowohl über 

NetBIOS- als auch über FQDN-Namen verbinden, müssen Sie beide Namen im Dienstkonto registrieren 

(http/webapp1 und http/webapp1.contoso.com). Außerdem ist das richtige Dienstkonto im 

vorliegenden Beispiel dasjenige, das zum Ausführen des Webanwendungspools mit der Webanwendung 

verwendet wird, die sich mit SQL verbindet. Im übrigen ist keine SPN-Registrierung 

erforderlich, wenn der Webanwendungspool als Netzwerkdienst ausgeführt wird.


• Auch doppelte SPNs können die delegierte Authentifizierung verhindern. Jeder SPN muss in 

der Domäne eindeutig sein. Zwei Sicherheitsprinzipale, die denselben SPN besitzen, verursachen 

ein Fehlschlagen der Delegierung. 

• Der IIS-Server ist falsch konfiguriert. Sie müssen IIS so konfigurieren, dass die Kerberos- 

Authentifizierung verwendet wird. Stellen Sie sicher, dass die Webanwendung für die integrierte 

Authentifizierung konfiguriert ist. Stellen Sie außerdem sicher, dass der Anbieter der 

Aushandlungsauthentifizierung nicht deaktiviert wurde. Weitere Informationen finden Sie 

im Microsoft Knowledge Base-Artikel 215383, „So konfigurieren Sie IIS darauf, sowohl 

das Kerberos- als auch das NTLM-Protokoll für Netzwerkauthentifizierung zu unterstützen“, 

der unter http://support.microsoft.com/kb/215383 verfügbar ist. 

Robert Greene 


Konfigurieren von Kerberos unter Windows Server 2008 

Wie bereits erwähnt, ist Kerberos das Standardprotokoll zur Authentifizierung, mit dem Clients unter 

Windows 2000 oder höher sich an AD DS anmelden. Sie können mehrere Kerberos-Eigenschaften 

über die Domänensicherheitsrichtlinien konfigurieren. Um auf die Kerberos-Richtlinieneinstellungen 

zuzugreifen, öffnen Sie die Konsole Gruppenrichtlinienverwaltung, und bearbeiten Sie die Standarddomänenrichtlinie. 

Erweitern Sie unter Computerkonfiguration zunächst die Sicherheitseinstellungen, 

und erweitern Sie anschließend den Ordner Kontorichtlinien. (Die Benutzeroberfläche wird in Abbildung 

8.7 dargestellt.) 

Abbildung 8.7 

Konfigurieren der Kerberos-Einstellungen über die Domänensicherheitsrichtlinie 

• Benutzeranmeldeeinschränkungen erzwingen Diese Richtlinie legt fest, dass das KDC jede Anforderung 

eines Sitzungstickets anhand der Einstellung der Benutzerrechte auf dem Zielcomputer 

prüfen muss. Wenn diese Richtlinie aktiviert ist, muss der Benutzer, der das Sitzungsticket anfordert, 

entweder das Recht Lokal anmelden zulassen besitzen, falls er sich interaktiv anmeldet, oder 

auf dem Zielcomputer über das Recht Auf diesen Computer vom Netzwerk aus zugreifen verfügen. 

Die Rechte Lokal anmelden zulassen und Auf diesen Computer vom Netzwerk aus zugreifen 

werden in der Domänensicherheitsrichtlinie unter Lokale Richtlinien\Zuweisen von Benutzerrechten 

erteilt. Diese Richtlinie ist standardmäßig aktiviert.


• Maximale Gültigkeitsdauer des Diensttickets Diese Richtlinie stellt den maximalen Zeitraum 

(in Minuten) ein, für den ein Dienstticket für den Zugriff auf einen bestimmten Dienst verwendet 

werden kann. Wenn die Einstellung null Minuten lautet, läuft das Ticket nie ab. Lautet der eingestellte 

Wert nicht null, muss er höher sein als zehn Minuten und niedriger als oder gleich der Einstellung 

für „Max. Gültigkeitsdauer des Benutzertickets“. Standardmäßig ist dieser Wert auf 600 

Minuten (zehn Stunden) eingestellt. 

• Maximale Gültigkeitsdauer des Benutzertickets Diese Richtlinie stellt den maximalen Zeitraum 

(in Stunden) ein, für den das TGT des Benutzers verwendet werden kann. Nach Ablauf des TGT 

muss ein neues vom KDC angefordert werden oder das vorhandene Ticket muss erneuert werden. 

Standardmäßig ist dieser Wert auf 10 Stunden eingestellt. 

• Maximaler Zeitraum, in dem ein Benutzerticket erneuert werden kann Diese Richtlinie legt den Zeitraum 

(in Tagen) fest, in dem ein TGT erneuert werden kann (und das Anfordern eines neuen TGT 

nicht erforderlich ist). Standardmäßig ist dieser Wert auf 7 Tage eingestellt. 

• Maximale Toleranz für die Synchronisation des Computertakts Diese Richtlinie stellt den maximalen 

Zeitunterschied (in Minuten) ein, den Kerberos zwischen der Uhrzeit auf einem Clientcomputer 

und der Uhrzeit auf einem Domänencontroller, der die Kerberos-Authentifizierung bereitstellt, 

zulässt. Ist der Zeitunterschied zwischen den beiden Computern größer als der angegebene Toleranzwert, 

werden alle Kerberos-Tickets abgelehnt. Standardmäßig ist dieser Wert auf 5 Minuten 

eingestellt. Beachten Sie, wenn diese Einstellung geändert wird, dass sie bei einem Neustart des 

Computers auf den Standardwert zurückgesetzt wird. 

In den meisten Fällen sind die Kerberos-Standardeinstellungen angemessen. In Umgebungen mit 

hohen Sicherheitsanforderungen können Sie die Einstellungen für die Ticketgültigkeitsdauer verringern. 

In diesem Fall müssen sich die Clients jedoch häufiger mit dem KDC verbinden und verursachen 

auf diese Weise zusätzlichen Netzwerkdatenverkehr und eine zusätzliche Belastung der Domänencontroller. 

Es empfiehlt sich, diese Einstellungen immer innerhalb eines Gruppenrichtlinienobjekts 

zu definieren und das GPO auf Domänenebene zu verknüpfen. 

Integration in die Public Key-Infrastruktur 

Wie zuvor erwähnt, basiert Kerberos auf einem Authentifizierungsmodell mit gemeinsamem 

geheimem Schlüssel. Dieses Modell bietet eine herausragende Sicherheit, birgt jedoch eine erhebliche 

Einschränkung für die Bereitstellung des Zugriffs auf ein Windows Server 2008-Netzwerk. 

Diese Einschränkung ist, dass jeder Benutzer, der auf das Netzwerk zugreift, ein Benutzerkonto in der 

KDC-Kontodatenbank besitzen muss. Wenn ein Benutzer nicht in der Datenbank enthalten ist, kann 

er keinen Zugriff auf das Netzwerk erhalten. 

Dies ist kein Problem für ein Unternehmen, in dem alle Benutzer, die sich am Netzwerk anmelden, 

bekannt sind und in dem für jeden Benutzer ein Benutzerkonto erstellt werden kann. Viele Unternehmen 

erweitern jedoch die Liste der Benutzer, die auf Netzwerkressourcen zugreifen müssen, um 

externe, nicht angestellte Benutzer. Ein Unternehmen kann eine kurzfristige Partnerschaft mit einem 

anderen Unternehmen eingehen und den Mitarbeitern des Partnerunternehmens Zugriff auf Netzwerkressourcen 

einräumen müssen. Außerdem könnte ein Unternehmen bestimmten Kunden Zugriff auf 

Ressourcen des Unternehmensnetzwerks bereitstellen wollen. In diesen Szenarios kann die Liste der 

Personen, die auf das Netzwerk zugreifen müssen, sehr lang werden. Die Erstellung eines Benutzerkontos 

für jeden einzelnen Benutzer wäre somit fast unmöglich.


Die PKI (Public Key-Infrastruktur) geht von einem Authentifizierungsmodell mit gemeinsamem 

geheimem Schlüssel ab und ersetzt es durch ein Authentifizierungsmodell, das auf Zertifikaten 

basiert. In der PKI werden Benutzer nicht auf der Grundlage authentifiziert, dass sie das richtige 

Kennwort kennen, sondern basierend auf der Tatsache, dass sie das richtige Zertifikat besitzen. Die 

PKI beruht auf drei wesentlichen Konzepten: öffentliche und private Schlüssel, digitale Zertifikate 

und Zertifizierungsstellen (Certificate Authorities, CAs). Die PKI beginnt mit dem Konzept, dass 

jeder am Informationsaustausch beteiligte Benutzer oder Computer zwei Schlüssel besitzt: einen 

privaten Schlüssel und einen öffentlichen Schlüssel. Der private Schlüssel ist nur einem Benutzer 

bekannt. Er kann auf der Festplatte des Computers, als Teil eines servergespeicherten Profils oder auf 

einem anderen Gerät wie beispielsweise einer Smartcard gespeichert sein. Der öffentliche Schlüssel 

hingegen wird jedem zugänglich gemacht, der darum bittet. Zwischen dem privaten und dem öffentlichen 

Schlüssel gibt es einen mathematischen Bezug, ein privater Schlüssel kann jedoch niemals von 

einem öffentlichen Schlüssel abgeleitet werden. Der öffentliche und der private Schlüssel werden in 

vielerlei Hinsicht eingesetzt. 

Zum einen werden öffentliche und private Schlüssel zum Verschlüsseln von Informationen verwendet, 

wenn diese über das Netzwerk gesendet werden. Der öffentliche Schlüssel eines Benutzers wird 

zum Verschlüsseln der Nachricht verwendet. Da der öffentliche Schlüssel jedem zugänglich gemacht 

wird, der diesen anfordert, kann jeder eine Nachricht senden, die mit dem öffentlichen Schlüssel eines 

Benutzers verschlüsselt wurde. Der einzige Schlüssel, der die Nachricht jedoch wieder entschlüsseln 

kann, ist der private Schlüssel des Benutzers. Die Person mit dem entsprechenden privaten Schlüssel 

ist daher die einzige Person, die eine mit einem öffentlichen Schlüssel verschlüsselte Nachricht entschlüsseln 

kann. Jeder andere, der das Paket im Netzwerk abfängt, besitzt nicht den richtigen privaten 

Schlüssel und kann die Nachricht daher nicht lesen. 

Eine andere Verwendungsmöglichkeit von öffentlichen und privaten Schlüsseln besteht in der digitalen 

Signatur von Nachrichten, die zwischen zwei Benutzern gesendet werden. Anhand einer digitalen 

Signatur werden die Identität des Absenders und die Integrität der Nachricht sichergestellt. Zum 

Erstellen einer digitalen Signatur wird die gesamte Nachricht durch einen mathematischen Hash 

gesendet. Dieser Hash erstellt einen Nachrichtenhash, der anhand des privaten Schlüssels des Absenders 

verschlüsselt wird. Der verschlüsselte Hash wird mit der Nachricht als digitale Signatur versendet. 

Wenn der Nachrichtenempfänger die Nachricht erhält, wird derselbe Hash auf die Nachricht 

angewendet und somit ein zweiter Nachrichtenhash erstellt. Der öffentliche Schlüssel des Absenders 

wird anschließend zum Entschlüsseln der digitalen Signatur verwendet. Wenn der Nachrichtenhash 

des Empfängers mit dem Ergebnis der entschlüsselten Signatur übereinstimmt, sind die Integrität und 

Echtheit der Nachricht bestätigt. 

Die zweite Komponente der PKI ist das digitale Zertifikat. Der Zweck eines Zertifikats besteht darin, 

den Zertifikathalter zu identifizieren. Wenn eine Person oder ein Unternehmen sich um ein Zertifikat 

von einer Zertifizierungsstelle bewirbt, bestätigt die Zertifizierungsstelle die Identität der Person oder 

des Unternehmens, die bzw. das das Zertifikat anfordert. Beim Erstellen der Zertifikatanforderung 

wird der private Schlüssel erstellt und auf dem lokalen Computer gespeichert. Wenn das Zertifikat 

zugeordnet wird, erhält der Benutzer außerdem den zugehörigen öffentlichen Schlüssel. Das Zertifikat 

wird darüber hinaus digital von der Zertifizierungsstelle signiert, um dem Zertifikat den Echtheitsstempel 

der Zertifizierungsstelle hinzuzufügen. Der aktuelle Standard für diese Zertifikate lautet 

X.509 v3. Das Zertifikat enthält Informationen über die Person, den Computer oder den Dienst, an die 

bzw. den das Zertifikat ausgegeben wurde. Weiterhin umfasst es Informationen über das Zertifikat 

selbst, zum Beispiel das Ablaufdatum, sowie Informationen über die ausgebende Zertifizierungsstelle.


Die für die PKI erforderlichen Zertifikate werden von Zertifizierungsstellen ausgegeben, bei denen es 

sich um Netzwerkserver handelt, die das Erteilen und Sperren von Zertifikaten verwalten. Aufgrund 

der Bedeutung der PKI für das Internet ist derzeit eine breite Vielfalt an Zertifizierungsstellen verfügbar, 

einschließlich beliebter kommerzieller Zertifizierungsstellen wie Verisign und Thawte. Die meisten 

Internetclients wie Microsoft Internet Explorer werden automatisch so konfiguriert, dass sie den 

von diesen kommerziellen Zertifizierungsstellen ausgegebenen Zertifikaten vertrauen. Außerdem 

können Sie Ihre eigene Zertifizierungsstelle über Windows Server 2008 einrichten. Die in Windows 

Server 2008 enthaltene AD CS-Rolle (Active Directory Certificate Services) ist eine voll funktionsfähige 

Zertifizierungsstelle, die zum Ausstellen von Zertifikaten an Personen innerhalb Ihres Unternehmens 

oder an Personen anderer Unternehmen verwendet werden kann. 

Hinweis Einer der Vorteile bei der Verwendung der AD CS ist die Möglichkeit zum Bereitstellen der Zertifizierungsstelle 

als Unternehmenszertifizierungsstelle. Die Unternehmenszertifizierungsstelle ist in AD DS eng 

integriert. Daher können Sie Richtlinien so konfigurieren, dass Zertifikate automatisch an Benutzer und Computer 

ausgestellt und verwaltet werden können. In Kapitel 17, „Active Directory-Zertifikatdienste“, finden Sie 

Einzelheiten zur Planung und Implementierung der AD CS. 

Ein Zweck von Zertifikaten liegt darin, den Benutzern, die möglicherweise kein Konto in AD DS 

besitzen, den Zugriff auf Ressourcen im Windows Server 2008-Netzwerk zu ermöglichen. Beispielsweise 

möchten Sie eine sichere Website so einrichten, dass Partnerunternehmen oder Kunden auf 

einige vertrauliche Daten in Ihrem Netzwerk zugreifen können. Unter Windows Server 2008 kann die 

Berechtigung für den Zugriff auf Netzwerkressourcen nur Sicherheitsprinzipalen erteilt werden. Es 

gibt keine Option, Berechtigungen nur aufgrund von Zertifikaten zuzuweisen. Sie können Benutzern 

mit Zertifikaten und ohne AD DS-Benutzerkonten jedoch den Zugriff auf Netzwerkressourcen ermöglichen, 

indem Sie ein Zertifikat einem Benutzerkonto zuordnen und das Konto anschließend verwenden, 

um Berechtigungen zuzuweisen. 

Windows Server 2008 bietet zwei verschiedene Möglichkeiten für das Zuordnen eines Zertifikats zu 

einem Benutzerkonto: 

• 1:1-Zuordnung In diesem Fall wird ein einzelnes Zertifikat einem einzigen Windows Server 

2008-Benutzerkonto zugeordnet. Bei einer 1:1-Zuordnung müssen Sie sowohl ein Zertifikat 

zuweisen als auch ein Benutzerkonto für jeden Benutzer erstellen. Dies ist möglicherweise eine 

gute Lösung, wenn Sie Remotemitarbeitern des Unternehmens den Zugriff auf sichere Ressourcen 

über eine sichere Website ermöglichen möchten. Dieser Ansatz verringert jedoch nicht den 

Verwaltungsaufwand. Dennoch können Sie mithilfe der 1:1-Zuordnung die Zugriffsebene für 

jeden Benutzer steuern. 

• n:1-Zuordnung In diesem Fall werden einem AD DS-Kontonamen viele Zertifikate zugeordnet. 

Wenn Sie beispielsweise eine Partnerschaft mit einem anderen Unternehmen eingehen und die 

Mitarbeiter des Unternehmens auf eine sichere Website zugreifen müssen, können Sie ein Benutzerkonto 

erstellen. Anschließend können Sie so viele Zertifikate wie nötig mit diesem einen 

Benutzerkonto verknüpfen. Wenn das andere Unternehmen beispielsweise eine eigene Zertifizierungsstelle 

besitzt, können Sie eine Regel erstellen, die alle von dieser Zertifizierungsstelle ausgestellten 

Zertifikate einem Benutzerkonto in Ihrer Domäne zuordnet. Anschließend können Sie 

anhand dieses einen Kontos Berechtigungen für Netzwerkressourcen zuweisen.

Integration in Smartcards 


Hinweis Zertifikate können Benutzerkonten über das Verwaltungsprogramm Active Directory-Benutzer 

und -Computer oder über den Microsoft Internet Information Server (IIS) Manager zugeordnet werden. Aktivieren 

Sie im Verwaltungsprogramm Active Directory-Benutzer und -Computer im Menü Ansicht die Option 

Erweiterte Features, und verwenden Sie anschließend die Option Namenszuordnungen, die beim Rechtsklick 

auf ein Benutzerkonto verfügbar wird. 

Smartcards stellen eine weitere Option zur Integration der PKI in die Kerberos-Authentifizierung dar. 

Wenn Kerberos ohne PKI verwendet wird, wird der gemeinsame geheime Schlüssel zwischen dem 

Client und dem KDC zum Verschlüsseln des anfänglichen Anmeldeaustauschs mit dem Authentifizierungsdienst 

verwendet. Dieser Schlüssel leitet sich aus dem Benutzerkennwort ab, und es wird derselbe 

Schlüssel zum Verschlüsseln und Entschlüsseln der Informationen verwendet. Smartcards nutzen 

ein PKI-Modell, in dem sowohl ein öffentlicher als auch ein privater Schlüssel zum Verschlüsseln 

und Entschlüsseln der Anmeldeinformationen verwendet werden. 

Eine Smartcard enthält den öffentlichen und den privaten Schlüssel des Benutzers sowie ein X.509 

v3-Zertifikat. All diese Komponenten werden verwendet, wenn der Benutzer sich mithilfe der Smartcard 

an den AD DS authentifiziert. Der Anmeldevorgang beginnt, sobald der Benutzer eine Smartcard 

in den Smartcard-Leser einlegt und seine PIN (persönliche Identifizierungsnummer) eingibt. Das 

Einlegen der Smartcard in das Lesegerät wird von der LSA auf dem Computer als Strg+Alt+Entf- 

Sequenz interpretiert, und der Anmeldevorgang beginnt. 

Die PIN wird zum Lesen des Benutzerzertifikats und des öffentlichen und privaten Schlüssels von der 

Smartcard verwendet. Anschließend sendet der Client eine reguläre TGT-Anforderung an das KDC. 

Statt jedoch die Vorautorisierungsdaten (Zeitstempel) zu senden, die mit dem vom Kennwort abgeleiteten 

geheimen Schlüssel des Benutzers verschlüsselt sind, sendet der Client den öffentlichen Schlüssel 

und das Zertifikat an das KDC. Die TGT-Anforderung enthält noch immer die Vorautorisierungsdaten, 

ist jedoch mit dem privaten Schlüssel des Benutzers digital signiert. 

Wenn die Nachricht beim KDC ankommt, wird das Clientzertifikat überprüft, um sicherzustellen, 

dass es gültig ist und dass die Zertifizierungsstelle, die das Zertifikat ausgestellt hat, vertrauenswürdig 

ist. Das KDC überprüft außerdem die digitale Signatur der Vorautorisierungsdaten, um die 

Echtheit des Nachrichtenabsenders und die Integrität der Nachricht sicherzustellen. Wenn beide 

Prüfungen positiv verlaufen, verwendet das KDC den im Clientzertifikat enthaltenen UPN (User Principal 

Name) zum Nachschlagen des Kontonamens in AD DS. Wenn das Benutzerkonto gültig ist, 

authentifiziert das KDC den Benutzer und sendet ein TGT mit einem Sitzungsschlüssel an den Client 

zurück. Der Sitzungsschlüssel ist mit dem öffentlichen Schlüssel des Clients verschlüsselt, und der 

Client verwendet den privaten Schlüssel zum Entschlüsseln der Informationen. Dieser Sitzungsschlüssel 

wird anschließend für sämtliche Verbindungen mit dem KDC verwendet. 

Hinweis Das Einrichten der Smartcardanmeldung für Ihr Netzwerk bedeutet einen erheblichen Arbeitsaufwand. 

Zuerst müssen Sie eine Zertifizierungsstelle zum Ausstellen der Zertifikate bereitstellen. Anschließend 

müssen Sie Smartcard-Registrierungsstationen einrichten, von denen Benutzer ihre Smartcards 

beziehen und die Zertifikate und Schlüssel den Karten zugewiesen werden können. Nach der ersten Bereitstellung 

müssen Sie sich um die Verwaltungsaufgaben wie verlorene oder verlegte Karten kümmern. Smartcards 

bieten eine hervorragende zusätzliche Sicherheit in Ihrem Netzwerk; diese zusätzliche Sicherheit ist 

jedoch mit erheblichem Verwaltungsaufwand verbunden. In vielen Unternehmen werden Smartcards nur 

zum Sichern von Administratorkonten und zum Ermöglichen der Remotezugriffsicherheit eingesetzt.


Interoperabilität mit anderen Kerberos-Systemen 

Da Kerberos auf einem offenen Standard basiert, bietet es herausragende Möglichkeiten zur Interoperabilität 

mit anderen auf Kerberos basierenden Systemen. Alle Komponenten, die Bestandteil der 

Windows Server 2008-Kerberos-Implementierung sind, können durch eine Nicht-Windows-Entsprechung 

ersetzt werden. Bei diesen drei Komponenten handelt es sich um Folgende: 

• Der Kerberos-Client 

• Das Kerberos-Schlüsselverteilungscenter 

• Die Netzwerkressource, die Kerberos zur Autorisierung nutzt 

Für die Interoperabilität gibt es vier mögliche Szenarios: 

• Ein Windows 2000- oder Windows XP Professional-Client meldet sich an einem Domänencontroller 

unter Windows Server 2008 an und greift auf Ressourcen auf einem Server unter Windows 

Server 2008 oder auf einem anderen Kerberos-basierten Dienst zu. 

• Ein Windows-Client meldet sich an einem Nicht-Windows-KDC an und greift auf Ressourcen auf 

einem Server unter Windows Server 2008 oder einem anderen Kerberos-basierten Dienst zu. 

Hinweis Windows Server 2008 stellt das Befehlszeilenprogramm Ksetup.exe zur Verfügung, das zum 

Konfigurieren von Windows-Clients für die Kommunikation mit Nicht-Windows-KDCs eingesetzt werden 

kann. 

• Ein Nicht-Windows-Kerberos-Client kann sich an ein Windows Server 2008-KDC anmelden und 

auf Ressourcen auf einem Server unter Windows Server 2008 oder auf einem anderen Kerberosbasierten 

Dienst zugreifen. 

• Ein Nicht-Windows-Kerberos-Client kann sich an ein Windows Server 2008-KDC anmelden und 

auf Ressourcen auf einem Server unter Windows Server 2008 oder auf einem anderen Kerberosbasierten 

Dienst zugreifen. 

Windows Server 2008 kann für die Beteiligung an einer beliebigen dieser Konfigurationen konfiguriert 

werden. Die einfachste Option ist eine homogene Lösung, in der die gesamte Umgebung entweder 

auf Windows Server 2008-Kerberos oder auf einer nicht auf Windows basierenden Kerberos- 

Implementierung beruht. 

Die Windows Server 2008-Implementierung von Kerberos macht eine Zusammenarbeit mit anderen 

Kerberos-Implementierungen jedoch relativ leicht. Die einfachste Möglichkeit zum Implementieren 

dieser Konstellation besteht darin, bereichsübergreifende Vertrauensstellungen zwischen der Windows 

Server 2008-Domäne und dem Nicht-Windows-Kerberos-Bereich zu erstellen. Diese Bereichsvertrauensstellungen 

können als transitiv oder nicht transitiv und als unidirektional oder bidirektional 

konfiguriert werden. Um eine Vertrauensstellung mit einem anderen Bereich zu konfigurieren, öffnen 

Sie das Verwaltungsprogramm Active Directory-Domänen und -Vertrauensstellungen und greifen auf 

das Eigenschaftenfenster für die Domäne zu, in der Sie eine Vertrauensstellung erstellen möchten. 

Klicken Sie auf der Registerkarte Vertrauensstellungen auf Neue Vertrauensstellung, und der Assistent 

für neue Vertrauensstellungen wird gestartet. Mit diesem Assistenten können Sie die Windows 

Server 2008-Seite der Vertrauensstellung mit einem anderen Kerberos-Bereich erstellen. 

Weitere Informationen Microsoft bietet einen Leitfaden mit Schrittanleitungen zur Konfiguration bereichsübergreifender 

Kerberos-Vertrauensstellungen an. Dieser englischsprachige Leitfaden mit dem Titel „Stepby-Step 

Guide to Kerberos 5 (krb5 1.0) Interoperability“ steht auf der Microsoft-Website unter http://technet.microsoft.com/en-us/library/Bb742433.aspx 

zur Verfügung.

Problembehandlung für Kerberos 


Wenn Ihr Unternehmen nur Clients und Server unter Windows 2000 oder höher einsetzt, verwenden 

alle Benutzer in Ihrem Unternehmen Kerberos als Authentifizierungsprotokoll. Da der gesamte 

Clientzugriff auf Netzwerkressourcen auf einer erfolgreichen Authentifizierung beruht, führt jeder 

Authentifizierungsfehler zur Unterbrechung der Benutzerinteraktion mit dem Netzwerk. Sie müssen 

daher auf eine Problembehandlung für die Kerberos-Authentifizierung vorbereitet sein. 

Anforderungen an die TCP/IP-Netzwerkkonnektivität 

Damit die Kerberos-Authentifizierung erfolgreich ist, müssen Clientcomputer mit Domänencontrollern 

kommunizieren können. Wenn zwischen den Clientcomputern und den Domänencontrollern Firewalls 

bereitgestellt werden, stellen Sie sicher, dass die in Tabelle 8.1 genannten Ports geöffnet sind. 

Tabelle 8.1 

Für die Kerberos-Authentifizierung erforderliche Ports 

Port Dienst Beschreibung 

53/TCP 

DNS-Dienst 

Der interne DNS-Server muss allen Clients für den Standort von KDC-Computern 

53/UDP 

zugänglich sein. 

88/TCP 

88/UDP 

123/TCP 

123/UDP 

Kerberos-Ticketerteilungsdienst 

Zeitdienst 

464/TCP Microsoft Windows 2000 

Kerberos-Protokoll zur 

Kennwortänderung 

Alle Clients müssen sich mit diesem Port auf den KDC-Servern verbinden 

können. 

Alle Clients müssen sich mit diesem Port zur Zeitsynchronisierung entweder 

mit einem internen Zeitserver oder mit einer externen Zeitquelle verbinden 

können. 

Dieser Port wird auch vom kpasswd-Protokoll verwendet. Er sollte nur dann 

geöffnet sein, wenn Clients das kpasswd-Protokoll verwenden. 

Hinweis Auch wenn dies für die Kerberos-Authentifizierung nicht erforderlich ist, sollten Sie sicherstellen, 

dass Clientcomputer auch mit Domänencontrollern über LDAP (Port 389) und LDAP für den globalen Katalog 

(Port 3268) kommunizieren können, um Verzeichnissuchen durchzuführen. 

Problembehandlung bei der Authentifizierung 

Wenn Benutzer sich nicht an der Domäne anmelden können, kann das Problem mit der Kerberos- 

Authentifizierung zusammenhängen. Insbesondere, wenn das Systemereignisprotokoll auf Domänencontrollern 

oder Clientcomputern Fehler von beliebigen Authentifizierungsdiensten anzeigen, wie 

Kerberos, KDC, LsaSrv oder Netlogon, sollten Sie bei der Problembehandlung bei Kerberos-Fehlern 

ansetzen. Außerdem sollten Sie das Sicherheitsereignisprotokoll auf Fehlerüberwachungen prüfen, die 

Hinweise auf den Grund des Authentifizierungsfehlers bereitstellen könnten. 

Als ersten Schritt bei der Problembehandlung von Authentifizierungsfehlern verwenden Sie die Problembehandlungstools 

für Windows-Netzwerke, um die Verfügbarkeit und Konfiguration von Servern 

und Clients zu überprüfen. Beispielsweise können Sie mithilfe von Dcdiag den Status der 

Dienste prüfen, die die Authentifizierungsdienste auf den Domänencontrollern unterstützen. Auf der 

Clientseite prüfen Sie die IP-Adresskonfiguration und löschen den Namenzwischenspeicher. Außerdem 

können Sie den Befehl Nltest ausführen, um sicherzustellen, dass der Client mit dem richtigen 

Domänencontroller einen sicheren Kanal aufgebaut hat. Mithilfe von Nslookup und Portquery können 

Sie Probleme mit der Namensauflösung oder einer Portblockierung beheben.


Wenn Sie vermuten, dass der Authentifizierungsfehler auf ein Kerberos-Problem zurückzuführen ist, 

gehen Sie folgendermaßen vor, um die Fehlerursache genauer zu identifizieren: 

1. Überprüfen Sie mithilfe von Kerberos Tray oder Kerberos List, dass Sie ein Dienstticket für den 

Server besitzen, mit dem Sie eine Verbindung herstellen möchten. Diese Tools führen alle auf der 

Arbeitsstation aktiven Diensttickets auf. Wenn Sie ein Dienstticket für den Server besitzen und 

noch immer eine Fehlermeldung beim Zugriff auf eine Ressource erhalten, kann ein Fehler mit 

dem Dienstprinzipalnamen oder ein Autorisierungsfehler vorliegen. 

2. Wenn Sie kein Dienstticket besitzen, bestätigen Sie anhand von Kerberos Tray oder Kerberos List, 

dass Sie über ein TGT verfügen. Das TGT wird vom KDC-Dienst auf einem Domänencontroller 

erteilt, sobald der Benutzer sich anmeldet. Wenn Sie ein TGT, jedoch kein Dienstticket besitzen, 

untersuchen Sie das Systemereignisprotokoll. Anhand der im Systemprotokoll aufgeführten Fehler 

können Sie feststellen, warum Sie für den Dienst kein Ticket erhalten können. 

Hinweis Standardmäßig ist die detaillierte Kerberos-Ereignisprotokollierung nicht aktiviert. Fügen Sie 

zum Aktivieren der Kerberos-Protokollierung dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\ 

SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters einen LogLevel-Wert vom Typ 

REG_DWORD hinzu. Setzen Sie den Wert auf 0x1. 

3. Wenn die Kerberos-Authentifizierung fehlschlägt, prüfen Sie das Systemereignisprotokoll oder 

gesammelte Daten in einer Netzwerkablaufverfolgung, worin der vom KDC oder dem Kerberos- 

SSP zurückgegebene Kerberos-Fehlercode enthalten sein sollte. 

Weitere Informationen Eine vollständige Liste von Fehlercodes im Zusammenhang mit der Kerberos- 

Authentifizierung finden Sie im englischsprachigen Artikel „Troubleshooting Kerberos Errors“ unter http:// 

www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx. 

Im Folgenden sind einige der Hauptgründe für Fehler bei der Kerberos-Authentifizierung aufgeführt: 

• Der Zeitunterschied zwischen dem Clientcomputer und den Domänencontrollern beträgt mehr als 

fünf Minuten. Wenn ein Kerberos-Client sich authentifiziert, befindet sich ein Zeitstempel in dem 

an das KDC gesendete Authentifizierungspaket. Außerdem besitzen alle vom KDC ausgestellten 

Tickets eine Ablaufzeit. Das bedeutet, dass die Kerberos-Authentifizierung sich auf das Datum 

und die Uhrzeit verlässt, die im KDC und auf dem Client eingestellt sind. Wenn zwischen dem 

KDC und einem Client, der Tickets anfordert, ein zu großer Zeitunterschied liegt, kann das KDC 

nicht feststellen, ob die Anforderung legitim ist oder ob es sich um eine erneute Wiedergabe handelt. 

Es ist daher von großer Wichtigkeit, dass die Uhrzeit auf allen Computern in einem Netzwerk 

synchronisiert ist, damit die Kerberos-Authentifizierung ordnungsgemäß funktioniert. Das 

bedeutet, dass alle Domänen und Gesamtstrukturen in einem Netzwerk dieselbe Zeitquelle verwenden 

müssen. Ein AD DS-Domänencontroller fungiert als autorisierender Zeitserver für seine 

Domäne, wodurch sichergestellt ist, dass die Uhrzeit in der gesamten Domäne übereinstimmt. 

Allerdings ist die Uhrzeit über mehrere Domänen möglicherweise nicht synchronisiert. Es empfiehlt 

sich, entweder eine externe Zeitquelle oder eine einzige Zeitquelle innerhalb des Netzwerks 

für die Synchronisierung aller Computer zu verwenden. 

• Die AD DS-Replikation schlägt fehl oder verzögert sich. Beim Kerberos-Ticketerteilungsvorgang 

werden Kontokennworthashes verwendet. Wenn das Kennwort eines Benutzers oder Computers 

kürzlich geändert wurde und das neue Kennwort nicht in der Umgebung repliziert wurde, kann 

das KDC ein Dienstticket mit dem falschen geheimen Schlüssel verschlüsseln. in diesem Fall 

schlägt die Kerberos-Authentifizierung fehl.


• UDP-Pakete können zwischen dem Clientcomputer und den Domänencontrollern fragmentiert 

werden. Standardmäßig verwendet die Kerberos-Authentifizierung UDP zum Übertragen der 

Daten. UDP gewährt jedoch keine Garantie, dass ein im Netzwerk gesendetes Paket unbeschädigt 

sein Ziel erreicht. In Umgebungen mit sehr starkem Netzwerkdatenverkehr gehen Pakete auf 

ihrem Weg zum Ziel häufig verloren oder werden fragmentiert. Sie können eine Diagnose für die 

UDP-Fragmentierung stellen, indem Sie die vom Netzwerkmonitor gesammelten Daten überprüfen. 

Wenn durch starken Netzwerkdatenverkehr eine UDP-Fragmentierung verursacht wird, sollten 

Sie den Kerberos-Authentifizierungsdienst für TCP statt UDP konfigurieren. TCP garantiert, 

dass ein gesendetes Paket sein Ziel intakt erreicht, und kann daher in jeder Netzwerkumgebung 

verwendet werden. Informationen dazu, wie Sie die Kerberos-Authentifizierung zur Nutzung von 

TCP zu veranlassen, finden Sie unter „So erzwingen Sie, dass Kerberos in Windows Server 2003, 

Windows XP und Windows 2000 TCP anstelle von UDP verwendet“ in der Microsoft Knowledge 

Base unter http://support.microsoft.com/kb/244474. 

• Benutzer können Mitglieder in zu vielen Gruppen sein. Nach der erfolgreichen Authentifizierung 

des Benutzers überträgt das KDC PAC-Daten (Privilege Attribute Certificate) im TGT. Das PAC 

enthält verschiedene Typen von Autorisierungsdaten, einschließlich der Gruppen, denen der 

Benutzer angehört, der Rechte des Benutzers und der für den Benutzer gültigen Richtlinien. Wenn 

der Client ein Ticket erhält, wird anhand der im PAC enthaltenen Informationen das Zugriffstoken 

des Benutzers generiert. Um die Leistung zu optimieren, wird die Puffergröße für das PAC 

vorbelegt. Die vorbelegte Puffergröße ist normalerweise ausreichend, um die gesamten Autorisierungsdaten 

aufzunehmen. Wenn ein Benutzer jedoch sehr vielen Gruppen angehört – von über 70 

bis zu über 120, je nach Art der Gruppen – kann die Größe des PAC die vorbelegte Puffergröße 

überschreiten. In solch einem Fall generiert das System einen Speicherzuweisungsfehler, die PAC- 

Erstellung schlägt fehl, und der Kerberos-Ticketerteilungsdienst kann entweder kein gültiges 

Ticket generieren oder generiert ein Ticket mit einem leeren PAC. Mithilfe des Tools Tokensz.exe 

können Sie überprüfen, ob dieses Problem vorliegt. Falls ja, können Sie die Anzahl an Gruppen 

reduzieren, denen der Benutzer angehört, oder die Registrierung bearbeiten und den Wert Max- 

TokenSize für Domänenarbeitsstationen erhöhen. Informationen hierzu finden Sie unter „New 

Resolution for Problems with Kerberos Authentication When Users Belong to Many Groups“ in 

der Microsoft Knowledge Base unter http://support.microsoft.com/kb/327825. 

• Der Dienstprinzipalname für den angeforderten Server ist möglicherweise nicht verfügbar. Dienstprinzipalnamen 

(Service Principal Names (SPNs) sind eindeutige Kennungen für auf Servern ausgeführte 

Dienste. Jeder Dienst, der die Kerberos-Authentifizierung nutzt, muss einen SPN 

besitzen, damit die Clients den Dienst im Netzwerk erkennen können. Er wird in AD DS unter 

einem Benutzer- oder Computerkonto als Attribut namens service-Principal-Name registriert. Der 

SPN wird dem Konto zugeordnet, unter dem der Dienst oder die Anwendung ausgeführt wird. 

Jeder Dienst kann den SPN für einen anderen Dienst nachschlagen. Wenn ein Dienst sich an 

einem anderen Dienst authentifziert, unterscheidet er diesen Dienst anhand des SPN von anderen 

Diensten, die auf demselben Computer ausgeführt werden. Im Allgemeinen sollten SPNs festgelegt 

werden, wenn Sie ein Computerkonto erstellen. Wird für einen Dienst kein SPN eingestellt, 

kann das KDC diesen Dienst nicht finden. Da mehrere Dienste gleichzeitig unter demselben 

Konto ausgeführt werden können, sind zum Festlegen eines SPN vier Informationen erforderlich, 

um den SPN eindeutig zu definieren: 

Die Dienstklasse, mit der Sie zwischen mehreren Diensten unterscheiden können, die unter 

demselben Konto ausgeführt werden 

Das Konto, unter dem der Dienst ausgeführt wird


Der Computer, auf dem der Dienst ausgeführt wird, einschließlich Aliasnamen, die auf den 

Computer verweisen 

Der Port, auf dem der Dienst ausgeführt wird 

Diese vier Informationen dienen der eindeutigen Identifikation jedes Dienstes, der in einem Netzwerk 

ausgeführt wird, und können zur wechselseitigen Authentifizierung an jedem Dienst verwendet 

werden. Wenn der SPN für einen Dienst in AD DS nicht registriert ist, konfigurieren Sie den SPN 

mithilfe des Dienstprogramms Setspn.exe. Einzelheiten finden Sie im englischsprachigen Artikel 

„Service Logons Fail Due to Incorrectly Set SPNs“ unter http://technet2.microsoft.com/windowsserver/en/library/579246c8-2e32-4282-bce7-3209d1ea8bf11033.mspx?mfr=true. 

Dienstprinzipalnamen müssen eindeutig sein. Ein weiteres häufig auftretendes Problem im Zusammenhang 

mit Dienstprinzipalnamen ist, dass derselbe SPN für mehrere Konten (Benutzer oder Computer) 

definiert wurde. Die beste Möglichkeit, dies zu überprüfen, ist eine LDAP-Abfrage, über die 

nach Konten mit doppelten SPNs gesucht wird. Einzelheiten hierzu finden Sie im Artikel „Ereigniskennung 

11 im Systemprotokoll von Domänencontrollern“ unter http://support.microsoft.com/kb/ 

321044. 

NTLM-Authentifizierung 

Die zweite Option zur Authentifizierung an einem Windows Server 2008-Domänencontroller ist die 

Verwendung der NTLM-Authentifizierung. Die NTLM-Authentifizierung wird hauptsächlich zur 

Abwärtskompatibilität mit Clientcomputern unter Windows NT 4.0, Windows 95 und Windows 98 

unterstützt. Dieses Protokoll wird in folgenden Situationen eingesetzt: 

• Wenn ein Computer unter Windows 95, Windows 98 oder Windows NT sich an einem Windows 

Server 2008-Domänencontroller authentifiziert. Die Active Directory-Clienterweiterung muss auf 

Computern unter Windows 95 und Windows 98 installiert sein, da diese Betriebssysteme sich nur 

über das LAN Manager-Protokoll authentifizieren können. 

• Wenn ein Computer unter Windows XP Professional oder Windows Server 2008 sich an einem 

Server unter Windows NT 4 authentifiziert. 

• Wenn ein beliebiger Client auf einen eigenständigen Server unter Windows Server 2008 zugreift. 

• Wenn ein Client unter Windows XP Professional oder Windows 2000 versucht, sich an einem 

Windows Server 2008-Domänencontroller anzumelden, sich jedoch über das Kerberos-Protokoll 

nicht authentifizieren kann. In diesem Fall kann die NTLM-Authentifizierung als Alternative verwendet 

werden. 

Weitere Informationen Die Active Directory-Clienterweiterung steht zum Download unter „SO WIRD'S 

GEMACHT: Installieren von Active Directory Client Extension“ unter der Adresse http://support.microsoft.com/kb/288358 

zur Verfügung. 

Das NTLM-Protokoll ist wesentlich weniger sicher als Kerberos. Mit Windows NT 4 Service Pack 4 

hat Microsoft eine neue Version des NTLM-Protokolls namens NTLMv2 eingeführt. Diese neue Version 

enthält zusätzliche Sicherheitsfunktionen, wie die Erstellung eines eindeutigen Sitzungsschlüssels 

bei jeder neuen Verbindungsherstellung sowie einen erweiterten Schlüsselaustauschprozess zum 

Schutz der Sitzungsschlüssel. 

NTLM verwendet einen Anfrage/Antwort-Mechanismus zum Authentifizieren von Benutzern und 

Computern. Bei diesem Format wird der Benutzer aufgefordert (Anfrage), einige persönliche Informationen 

bereitzustellen (Antwort).

NTLM-Authentifizierung 299 

Windows Server 2008 unterstützt die folgenden drei Methoden der Anfrage/Antwort-Authentifizierung: 

• LAN Manager (LM) Die LM-Authentifizierung ist die am wenigsten sichere Form der Anfrage/ 

Antwort-Authentifizierung. Sie können die LM-Authentifizierung einsetzen, um Kompatibilität 

mit älteren Betriebssystemen wie Windows 95 und Windows 98 bereitzustellen, auf denen die 

Active Directory-Clienterweiterung nicht installiert ist. Es gibt auch frühere Anwendungen, die 

auf diesem Authentifizierungsmechanismus beruhen. Allerdings ist die LM-Authentifizierung das 

schwächste Protokoll, da ein Kennwort nach seiner Erstellung und Speicherung für LM in Großbuchstaben 

konvertiert wird. Das Kennwort ist auf 14 Zeichen beschränkt, die auf dem Computer 

in zwei Hashes aus je sieben Zeichen gespeichert werden. 

• NTLM, Version 1 Diese Form der Anfrage/Antwort-Authentifizierung ist sicherer als LM. Sie wird 

zum Herstellen von Verbindungen mit Servern unter Microsoft Windows NT mit Service Pack 3 

oder früher verwendet. NTLMv1 nutzt die 56-Bit-Verschlüsselung zum Sichern des Protokolls. 

• NTLM, Version 2 Dies ist die sicherste Form der Anfrage/Antwort-Authentifizierung. Diese Version 

enthält einen sicheren Kanal zum Schutz des Authentifizierungsvorgangs. Sie wird zum Verbinden 

mit Servern unter Windows 2000, Windows XP und Windows NT mit Service Pack 4 oder 

höher eingesetzt. NTLMv2 nutzt die 128-Bit-Verschlüsselung zum Sichern des Protokolls. 

Domänencontroller unter Windows Server 2008 können alle Arten von Authentifizierungsprotokollen 

annehmen, einschließlich LM, NTLMv1 und NTLMv2 sowie Kerberos, um die Kompatibilität mit 

früheren Betriebssystemen zu gewährleisten. Um sicherzustellen, dass Computer in Ihrem Unternehmen 

nur die sichersten Authentifizierungsprotokolle annehmen, können Sie die Gruppenrichtlinien für 

die ausschließliche Unterstützung der sichersten Protokolle wie NTLMv2 und Kerberos konfigurieren. 

Windows Server 2008 stellt die folgenden beiden Optionen zum Verbessern der Authentifizierungssicherheit 

über die Gruppenrichtlinien bereit. Beide Optionen stehen im Abschnitt Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale 

Richtlinien\Sicherheitsoptionen 


• Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern Standardmäßig 

ist diese Option in einer Windows Server 2008-Domäne aktiviert und wird durch die 

Standarddomänenrichtlinie durchgesetzt. Das bedeutet, dass die Richtlinie für alle Mitgliedsserver 

und für Domänencontroller gilt. Wenn diese Option aktiviert ist, erstellt der Server bei der 

nächsten Kennwortänderung des Benutzers keine Kopie des LAN Manager-Kennworthashwerts. 

Sicherheitswarnung Wenn Sie LAN Manager-Kennworthashwerte speichern, kann jeder, der Zugriff 

auf die AD DS-Datenspeicherdatei erlangt, die Benutzerkennwörter aus der Datei extrahieren. Es empfiehlt 

sich, diese Option in einer Windows Server 2008-Domäne niemals zu deaktivieren. Wenn die Option 

deaktiviert wurde, stellen Sie fest, ob diese Einstellung für irgendwelche Anwendungen oder Clientbetriebssysteme 

erforderlich ist. Wenn bestimmte Server diese Option verlangen, verschieben Sie diese 

Server in eine separate OU, und deaktivieren Sie die Option nur für diese OU. Wenn Sie diese Einstellung 

von deaktiviert in aktiviert ändern, sollten Sie alle Benutzer zwingen, ihre Kennwörter zu ändern, damit alle 

LAN Manager-Hashes aus dem AD DS-Datenspeicher gelöscht werden. 

• Netzwerksicherheit: LAN Manager-Authentifizierungsebene Diese Einstellung gibt die Mindestebene 

für die Authentifizierung an, die von allen Clients im Netzwerk unterstützt werden muss. 

Die Konfigurationsoptionen sind in Tabelle 8.2 aufgeführt.


Tabelle 8.2 

LAN Manager-Authentifizierungseinstellungen 

Ebene Einstellung Ergebnis 

0 LM- und NTLM-Antworten 

senden 

1 LM- und NTLM-Antworten 

senden (NTLMv2-Sitzungssicherheit 

verwenden, wenn 

ausgehandelt) 

Clients verwenden die LM- und NTLM-Authentifizierung und niemals die 

NTLMv2-Sitzungssicherheit; Domänencontroller akzeptieren die LM-, NTLMund 

NTLMv2-Authentifizierung. 

Clients verwenden die LM- und NTLM-Authentifizierung und nutzen die 

NTLMv2-Sitzungssicherheit, sofern sie vom Server unterstützt wird; Domänencontroller 

akzeptieren die LM-, NTLM- und NTLMv2-Authentifizierung. 

2 Nur NTLM-Antworten senden Clients verwenden nur die NTLM-Authentifizierung und nutzen die NTLMv2- 

Sitzungssicherheit, sofern sie vom Server unterstützt wird; Domänencontroller 


3 Nur NTLMv2-Antwort senden Clients verwenden nur die NTLMv2-Authentifizierung und nutzen die 



4 Nur NTLMv2-Antwort senden\ 

LM ablehnen 

5 Nur NTLMv2-Antwort senden\ 

LM & NTLM ablehnen 

Clients verwenden nur die NTLMv2-Authentifizierung und nutzen die 

NTLMv2-Sitzungssicherheit, sofern sie vom Server unterstützt wird. Domänencontroller 

lehnen LM ab und akzeptieren nur die NTLM- und die NTLMv2- 

Authentifizierung. 

Clients verwenden nur die NTLMv2-Authentifizierung und nutzen die 


lehnen LM und NTLM ab und akzeptieren nur die NTLMv2- 

Authentifizierung. 

Standardmäßig wird diese Einstellung auf Ebene 3, Nur NTLMv2-Antwort senden, für die Standard- 

Domänencontrollerrichtlinie unter Windows Server 2008 konfiguriert. Es empfiehlt sich, die Authentifizierungsebene 

auf Ebene 4 oder höher zu ändern, um sicherzustellen, dass der Domänencontroller 

keine LM-Authentifizierung akzeptiert. Dies kann in einigen Anwendungen, die auf früheren Authentifizierungsmethoden 

beruhen, zu einem Fehler führen. 

Weitere Informationen Eine detaillierte Erläuterung der Probleme, die beim Erhöhen der Sicherheitseinstellungen 

für die LM-Authentifizierung entstehen können, sowie weitere Sicherheitseinstellungen finden Sie 

unter „Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit 

Clients, Diensten und Programmen auftreten“ unter http://support.microsoft.com/kb/823659/de-de. 

Implementieren der Sicherheit für Domänencontroller 

Zusätzlich zur Konfiguration der AD DS-Sicherheit durch Konfigurieren der Authentifizierungseinstellungen 

sollten Sie auch weitere Schritte zum Sichern der Domänencontroller ergreifen. Da auf den 

Domänencontrollern alle AD DS-Daten gespeichert sind, ist das Absichern der Domänencontroller 

ein wichtiger Schritt zur Erhöhung der Sicherheit Ihrer AD DS-Bereitstellung. 

Hinweis Zwei Hauptkomponenten bei der Planung der Domänensicherheit sind die Konfiguration sicherer 

Domänengrenzen und die Planung der physischen Sicherheit Ihrer Domänencontroller. In Kapitel 5, „Entwerfen 

der Active Directory-Domänendienstestruktur“, finden Sie Einzelheiten zum Entwerfen der administrativen Isolation 

und Autonomie sowie zu Planungsüberlegungen hinsichtlich der Bereitstellung schreibgeschützter Domänencontroller 

an Standorten, in denen die physische Sicherheit von Domänencontrollern nicht gewährleistet 

werden kann.

Verringern der Angriffsfläche von Domänencontrollern 

Implementieren der Sicherheit für Domänencontroller 301 

Der erste Schritt bei der Absicherung von Domänencontrollern besteht darin, die Angriffsfläche des 

Domänencontrollers zu verringern. Hierdurch reduzieren Sie die Anzahl an Optionen, die einem 

Angreifer für das Erlangen von Zugriff auf den Domänencontroller zur Verfügung stehen. Normalerweise 

bedeutet dies, dass Sie sämtliche Anwendungen entfernen und alle Dienste deaktivieren, die auf 

dem Domänencontroller nicht erforderlich sind. 

Eines der besten erhältlichen Tools zum Verringern der Angriffsfläche eines Domänencontrollers ist 

der Sicherheitskonfigurations-Assistent. Wenn Sie den Sicherheitskonfigurations-Assistenten ausführen, 

untersucht dieser die tatsächliche Konfiguration des Zielservers. Basierend auf den Informationen, 

die während dieser Untersuchung gesammelt werden, stellt der Sicherheitskonfigurations-Assistent 

fest, welche Serverrollen, Clientfunktionen und anderen Komponenten auf dem Computer 

installiert und aktiviert sind. Anschließend stellt der Sicherheitskonfigurations-Assistent anhand einer 

Sicherheitskonfigurationsdatenbank fest, welche Dienste und Einstellungen auf dem Server aktiviert 

sein müssen. Der Sicherheitskonfigurations-Assistent nutzt diese Informationen und die Entscheidungen, 

die Sie bei der Erstellung einer Sicherheitskonfigurationsrichtlinie treffen, um folgende Aufgaben 

durchzuführen: 

• Deaktivieren nicht erforderlicher Dienste. Basierend auf den installierten Serverrollen deaktiviert 

die Sicherheitskonfigurationsrichtlinie alle Dienste, die auf dem Server nicht erforderlich sind. Sie 

können den Sicherheitskonfigurations-Assistenten auch so konfigurieren, dass die Starteinstellungen 

von Diensten, die in der Sicherheitskonfigurationsdatenbank nicht enthalten sind, deaktiviert 

oder nicht verändert werden. 

• Konfigurieren der Windows-Firewall. Wenn Sie eine Sicherheitskonfigurationsrichtlinie anwenden, 

blockiert diese den Zugriff auf den Server für alle Ports, die nicht zum Bereitstellen der Serverrollenfunktionalität 

erforderlich sind. Sie können die Richtlinie außerdem so konfigurieren, 

dass weitere Adress- oder Sicherheitseinschränkungen für offen gebliebene Ports angewendet 

werden. Beispielsweise kann die Windows-Firewall so konfiguriert werden, dass nur Verbindungen 

aus einem lokalen Subnetz oder nur für bestimmte Protokolle zugelassen werden, wenn 

die Verbindung über IPSec gesichert wird. 

• Verbieten unnötiger IIS-Weberweiterungen. Wenn IIS auf dem Server installiert ist, können nicht 

benötigte IIS-Weberweiterungen über die Sicherheitskonfigurationsrichtlinie deaktiviert werden. 

• Reduzieren der Protokollfreilegung für SMB (Server Message Block), LanMan und LDAP (Lightweight 

Directory Access Protocol). 

• Bei Ausführung des Sicherheitskonfigurations-Assistenten können Sie wählen, welche Client- und 

Servertypen in Ihrem Netzwerk verwendet werden. Basierend auf Ihren Entscheidungen kann der 

Sicherheitskonfigurations-Assistent die Server so konfigurieren, dass nur verschlüsselte SMBoder 

LDAP-Verbindungen akzeptiert und LAN Manager-Verbindungen deaktiviert werden. 

• Konfigurieren einer Überwachungsrichtlinie. Beim Ausführen des Sicherheitskonfigurations- 

Assistenten können Sie auch eine Überwachungsrichtlinie für den Server konfigurieren. 

Auf der Grundlage der ausgewählten Serverrollen leitet der Sicherheitskonfigurations-Assistent Sie 

durch den Vorgang der Erstellung, Bearbeitung, Anwendung oder Rücksetzung einer Sicherheitsrichtlinie. 

Der Sicherheitskonfigurations-Assistent besteht aus drei Komponenten: 

• Benutzeroberfläche des Assistenten Der Sicherheitskonfigurations-Assistent leitet Sie, basierend 

auf den von einem bestimmten Server durchgeführten Rollen, durch den Vorgang zur Erstellung 

einer Sicherheitsrichtlinie.


Nachdem eine Richtlinie erstellt wurde, kann diese bearbeitet oder auf einen oder mehrere ähnlich 

konfigurierte Server angewendet werden. Für angewandte Richtlinien kann ein Rollback ausgeführt 

werden, um Änderungen rückgängig zu machen, die Probleme verursacht haben. 

• Befehlszeilenprogramm Scwcmd Der Sicherheitskonfigurations-Assistent umfasst das Befehlszeilenprogramm 

Scwcmd.exe. Mit Scwcmd können Sie folgende Aufgaben ausführen: 

Konfigurieren eines oder mehrerer Server mit einer vom Sicherheitskonfigurations-Assistenten 

generierten Richtlinie. 

Analysieren eines oder mehrerer Server mit einer vom Sicherheitskonfigurations-Assistenten 

generierten Richtlinie. 

Anzeigen von Analyseergebnissen in HTML-Format. 

Durchführen eines Rollbacks der Sicherheitskonfigurationsrichtlinien. 

Umwandeln einer vom Sicherheitskonfigurations-Assistenten generierten Richtlinie in 

systemeigene Dateien, die von Gruppenrichtlinien unterstützt werden. 

Registrieren der Erweiterung einer Sicherheitskonfigurationsdatenbank beim Sicherheitskonfigurations-Assistenten. 

Hinweis Wenn Sie Scwcmd zum Konfigurieren, Analysieren oder Rollback einer Richtlinie auf einem 

Remoteserver einsetzen, muss der Sicherheitskonfigurations-Assistent auf dem Remoteserver installiert 

sein. 

• Sicherheitskonfigurationsdatenbank Die Sicherheitskonfigurationsdatenbank besteht aus einer 

Reihe von XML-Dokumenten, in denen Dienste und Ports aufgeführt sind, die für die einzelnen 

vom Sicherheitskonfigurations-Assistenten unterstützten Serverrollen erforderlich sind. Diese 

Dateien werden unter %Systemroot%\Security\Msscw\KBs installiert. Wenn Sie den Sicherheitskonfigurations-Assistenten 

starten, stellt dieser anhand der Sicherheitskonfigurationsdatenbank 

Folgendes fest: 

Welche Rollen auf dem Server installiert sind 

Welche Rollen wahrscheinlich durch den Server ausgeführt werden 

Welche Dienste installiert, jedoch nicht Bestandteil der Sicherheitskonfigurationsdatenbank 

sind 

Die IP-Adressen und Subnetze, die für den Server konfiguriert wurden 

Der Sicherheitskonfigurations-Assistent fasst diese serverspezifischen Informationen in einer einzigen 

XML-Datei namens Main.XML zusammen. Die Datei Main.XML wird angezeigt, wenn Sie im 

Sicherheitskonfigurations-Assistenten auf der Seite Die Sicherheitskonfigurationsdatenbank verarbeiten 

auf Sicherheitskonfigurationsdatenbank anzeigen klicken. Abbildung 8.8 zeigt die Informationen, 

die für die Domänencontrollerrolle eines Servers unter Windows Server 2008 angezeigt werden. 

Auf der DVD Ein Beispiel einer für einen Domänencontroller konfigurierten Sicherheitskonfigurationsrichtlinie 

finden Sie in der Datei SampleDC_SCWPolicy.xml auf der Begleit-CD. Diese Datei kann im Internet 

Explorer oder über den Sicherheitskonfigurations-Assistenten geöffnet werden.


Abbildung 8.8 

Domänencontrollerdienste und Firewallregeln des Sicherheitskonfigurations-Assistenten. 

Nach dem Konfigurieren einer Sicherheitskonfigurationsrichtlinie können Sie diese auf den Server 

anwenden, auf dem Sie die Richtlinie konfiguriert haben. Außerdem können Sie diese Sicherheitskonfigurationsrichtlinie 

auf andere Computer mit derselben Konfiguration anwenden, indem Sie mithilfe 

des Tools Scwcmd die Richtlinie entweder direkt anwenden oder in ein Gruppenrichtlinienobjekt 

umwandeln, das anschließend mit der OU Domain Controllers verknüpft werden kann. Einzelheiten 

hierzu finden Sie in Kapitel 13. 

Achtung Gehen Sie mit Sorgfalt vor, wenn Sie eine auf einem Computer konfigurierte Sicherheitskonfigurationsrichtlinie 

auf andere Computer anwenden. Die Sicherheitskonfigurationsrichtlinie wird speziell für 

einen bestimmten Computer erstellt. Wenn daher die anderen Computer eine andere Konfiguration besitzen 

(beispielsweise andere Serverrollen oder Anwendungen ausführen), kann die Sicherheitskonfigurationsrichtlinie 

Dienste deaktivieren oder Firewallports blockieren. Stellen Sie sicher, dass alle Server über dieselbe 

Konfiguration verfügen, bevor Sie die Richtlinie anwenden.


Konfigurieren der Standard-Domänencontrollerrichtlinie 

Zusätzlich zum Verringern der Angriffsfläche von Domänencontrollern können Sie auch Gruppenrichtlinien 

zum Erhöhen der Sicherheit Ihrer Domänencontrollerbereitstellung einsetzen. Bei der 

Bereitstellung einer Windows Server 2008-Domäne werden die beiden folgenden Standard-GPOs 

erstellt und auf die Domäne sowie auf die OU Domain Controllers angewandt: 

• Standarddomänenrichtlinie, die mit dem Domänenobjekt verknüpft wird und sich durch Richtlinienvererbung 

auf alle Benutzer und Computer in der Domäne auswirkt (einschließlich Computer, 

die als Domänencontroller eingesetzt werden). 

• Standard-Domänencontrollerrichtlinie, die mit der OU Domain Controllers verknüpft ist. Diese 

Richtlinie betrifft generell nur Domänencontroller, da standardmäßig Computerkonten für Domänencontroller 

in der OU Domain Controllers abgelegt werden. 

Sie können Sicherheitsrichtlinien sowohl über die Standarddomänenrichtlinie als auch über die 

Standard-Domänencontrollerrichtlinie konfigurieren. Standardmäßig werden alle auf Domänenebene 

definierten Richtlinien von OUs in der Domäne übernommen, sofern die Richtlinienvererbung nicht 

blockiert ist oder eine mit der OU verknüpfte Richtlinie keine Einstellungen enthält, welche die 

Domänenrichtlinien außer Kraft setzen. Durch Anwenden der spezifischen Sicherheitseinstellungen 

für Domänencontroller in der Standard-Domänencontrollerrichtlinie oder in einem anderen GPO, das 

mit der OU Domain Controllers verknüpft ist, können Sie Sicherheitsrichtlinieneinstellungen anwenden, 

die speziell für Domänencontroller, jedoch nicht für alle Benutzer, Gruppen und Computer in der 

Domäne gelten. 

Hinweis Dieses Kapitel befasst sich hauptsächlich mit der Domänencontrollersicherheit, daher legen wir 

den Schwerpunkt auf Einstellungen, die in der Standard-Domänencontrollerrichtlinie zur Verfügung stehen. 

Einzelheiten zur Konfiguration der Sicherheitseinstellungen in der Standarddomänenrichtlinie finden Sie in 

Kapitel 13. Einzelheiten zur Konfiguration der Gruppenrichtlinien, einschließlich der Konfiguration von Gruppenrichtlinienverknüpfungen 

und -vererbung, finden Sie in Kapitel 11, „Einführung in Gruppenrichtlinien“. 

Konfigurieren von Überwachungsrichtlinieneinstellungen für Domänencontroller 

Eine der Hauptkomponenten in einer Sicherheitsrichtlinie für Domänencontroller ist die Überwachung 

von Änderungen, die an Domänencontrollern vorgenommen werden. Durch die Überwachung der an 

Domänencontrollern vorgenommenen Änderungen können Sie herausfinden, wer für Verzeichnisänderungen 

verantwortlich ist und wann die Änderungen durchgeführt wurden. 

In Windows Server 2008 werden einige wichtige Änderungen an der Überwachung von Domänencontrollern 

eingeführt. In Windows 2000 Server und Windows Server 2003 gab es eine Überwachungsrichtlinie 

Verzeichnisdienstzugriff überwachen, mit der man steuern konnte, ob die Überwachung von 

Verzeichnisdienstereignissen aktiviert oder deaktiviert war. Unter Windows Server 2008 ist diese 

Richtlinie in vier Unterkategorien unterteilt: 




• Detaillierte Verzeichnisdienstreplikation


Hinweis Diese Unterkategorien sind im Gruppenrichtlinienverwaltungs-Editor nicht sichtbar. Zum Anzeigen 

und Konfigurieren der Unterkategorien können Sie das Befehlszeilenprogramm Auditpol.exe verwenden. 

Um die aktuellen Überwachungseinstellungen für den Verzeichnisdienstzugriff anzuzeigen, geben Sie 

Folgendes ein: Auditpol /get /category:“ds access”. 

Aus der Sicht der Sicherheitsüberwachung ist die wichtigste neue Funktion die Unterkategorie Verzeichnisdienständerungen. 

Diese neue Unterkategorie fügt die folgende Funktionalität hinzu: 

• Wenn Sie ein Attribut für ein Objekt ändern, protokollieren die AD DS den vorherigen und den 

aktuellen Wert des Attributs. Wenn das Attribut mehrere Werte besitzt, werden nur die Werte protokolliert, 

die sich als Ergebnis des Änderungsvorgangs ändern. 

• Wird ein neues Objekt erstellt, werden die Werte der Attribute protokolliert, die zum Zeitpunkt 

der Erstellung aufgefüllt werden. Wenn Attribute während des Erstellungsvorgangs hinzugefügt 

werden, erfolgt eine Protokollierung dieser neuen Attribute. In den meisten Fällen weisen die AD 

DS den Attributen Standardwerte (wie samAccountName) zu. Die Werte solcher Systemattribute 

werden nicht protokolliert. 

• Wenn ein Objekt innerhalb der Domäne verschoben wird, werden der bisherige und der neue 

Speicherort (in Form des definierten Namens) protokolliert. Beim Verschieben eines Objekts in 

eine andere Domäne wird ein Erstellungsereignis auf dem Domänencontroller in der Zieldomäne 

generiert. 

• Wird ein Objekt wiederhergestellt, wird der Speicherort protokolliert, an den das Objekt verschoben 

wird. Wenn der Benutzer Attribute bei einem Wiederherstellungsvorgang hinzufügt, bearbeitet 

oder löscht, werden auch die Werte dieser Attribute protokolliert. 

Standardmäßig ist die Überwachungskategorie Verzeichnisdienstzugriff überwachen in der OU 

Default Domain Controllers nicht aktiviert, die Unterkategorie Verzeichnisdienstzugriff hingegen ist 

aktiviert. Diese Überwachungsrichtlinie protokolliert, wenn Administratoren auf Objekte in AD DS 

zugreifen; die Änderungen an diesen Objekten werden jedoch nicht festgehalten. Um die Überwachung 

von Verzeichnisdienständerungen zu aktivieren, können Sie die Option Verzeichnisdienstzugriff 

überwachen in der Überwachungsrichtlinie der Standard-Domänencontrollerrichtlinieaktivieren. 

Wenn Sie diese Option aktivieren, werden alle Unterkategorien ebenfalls aktiviert. 

Um nur die Unterkategorie Verzeichnisdienständerungen zu aktivieren, müssen Sie das Befehlszeilenprogramm 

Auditpol.exe verwenden und folgenden Befehl ausführen: 

auditpol /set /subcategory:"directory service changes" /success:enable 

In Windows Server 2008 werden außerdem Unterkategorien unter den anderen Überwachungskategorien 

eingeführt. Die Kategorien, Unterkategorien und Standardeinstellungen für AD DS-spezifische 

Überwachungseinstellungen sind in Tabelle 8.3 aufgeführt. Um diese Überwachungseinstellungen 

anzuzeigen, geben Sie an einer Eingabeaufforderung den Befehl Auditpol /get /category:* ein. 

Tabelle 8.3 

Konfigurieren von Überwachungsrichtlinieneinstellungen für Domänencontroller 

Kategorie Unterkategorie Standardeinstellung 

Anmeldeereignisse Anmelden 

Erfolg und Fehler 

überwachen 

Anmeldeereignisse Abmelden 

Erfolg 

überwachen 

Kontosperrung 

Erfolg


Tabelle 8.3 

Konfigurieren von Überwachungsrichtlinieneinstellungen für Domänencontroller (Fortsetzung) 

Kategorie Unterkategorie Standardeinstellung 

Keine Überwachung 

Anmeldeereignisse 

überwachen 


überwachen 


überwachen 


überwachen 

Richtlinienänderungen 

überwachen 


überwachen 


überwachen 

Kontenverwaltung 

überwachen 


überwachen 


überwachen 


überwachen 

Anmeldeversuche 

überwachen 


überwachen 


überwachen 


überwachen 

IPSec-Hauptmodus, IPSec-Erweiterungsmodus, IPSec-Schnellmodus 

Spezielle Anmeldung 

Andere Anmelde-/Abmeldeereignisse 

Netzwerkrichtlinienserver 

Richtlinienänderungen überwachen 

Authentifizierungsrichtlinienänderung 

Authentifizierungsrichtlinienänderung, MPSSVC-Richtlinienänderung 

auf Regelebene, Filterplattform-Richtlinienänderung, Andere 

Richtlinienänderungsereignisse 

Benutzerkontenverwaltung 

Computerkontoverwaltung 

Sicherheitsgruppenverwaltung 

Verteilergruppenverwaltung, Anwendungsgruppenverwaltung, 

Andere Kontoverwaltungsereignisse 

Kerberos-Dienstticketvorgänge 

Andere Kontoanmeldungsereignisse 

Kerberos-Authentifizierungsdienst 

Überprüfung der Anmeldeinformationen 

In den meisten Fällen sollten Sie die Standardüberwachungseinstellungen für Domänencontroller 

übernehmen, wenn das Ziel Ihrer Überwachungsrichtlinie darin liegt, die Administratoraktivitäten in 

AD DS zu überwachen. Wenn Sie die Überwachungsrichtlinie für andere Zwecke verwenden, beispielsweise 

zur Angriffserkennung, können Sie auch das Fehlschlagen von Ereignissen wie Anmeldeereignissen 

oder Kontoverwaltungsereignissen überwachen. Wenn Sie die Überwachung für eine 

der Kategorien aktivieren, wird standardmäßig die Überwachung aller Unterkategorien ebenfalls aktiviert. 

Erfolg 


Erfolg und Fehler 

Erfolg 

Erfolg 


Erfolg 

Erfolg 

Erfolg 


Erfolg 


Hinweis Die Konfiguration der Überwachungsrichtlinie ist nur der erste Schritt zum Aktivieren der AD DS- 

Überwachung. Nachdem Sie die Überwachungsrichtlinie konfiguriert haben, müssen Sie die SACL (System 

Access Control List) für jedes Objekt konfigurieren, um die Überwachung zu aktivieren. Aktivieren Sie hierzu 

die Überwachung für das Domänen- oder OU-Objekt in Active Directory-Benutzer und -Computer. 

Erfolg 

Erfolg


Konfigurieren von Ereignisprotokoll-Richtlinieneinstellungen für Domänencontroller 

Wenn Sie die Überwachungseinstellungen für Domänencontroller konfigurieren, sollten Sie möglicherweise 

auch die Einstellungen des Ereignisprotokolls auf den Domänencontrollern ändern. Insbesondere 

sollten Sie die maximale Größe des Sicherheitsprotokolls anpassen, damit die erhöhte Anzahl 

überwachter Ereignisse darin Platz findet. In Tabelle 8.4 sind die Änderungen aufgeführt, die für die 

Ereignisprotokolleinstellungen in der Standard-Domänencontrollerrichtlinie empfohlen werden. 

Tabelle 8.4 

Empfohlene Ereignisprotokoll-Richtlinieneinstellungen für Domänencontroller 

Richtlinie Standardeinstellung Empfohlene 

Einstellung 

Maximale Größe des 

Sicherheitsprotokolls 

Lokalen Gastkontozugriff 

auf Anwendungsprotokoll 

verhindern 


auf Sicherheitsprotokoll 

verhindern 


auf Systemprotokoll 

verhindern 

Sicherheitsprotokoll- 

Aufbewahrung 

Systemprotokoll- 

Aufbewahrung 

Aufbewahrungsmethode 

des Sicherheitsprotokolls 

Aufbewahrungsmethode 

des Systemprotokolls 

Nicht definiert; standardmäßig 

liegt die maximale 

Protokollgröße bei 128 

MB 

Kommentare 

131.072 KB Erhöht, um die in der Überwachungsrichtlinie 

der Standard-Domänencontrollerrichtlinie 

aktivierte Sicherheitsüberwachung 

aufzunehmen 

Nicht definiert Aktiviert Hindert Mitglieder der vordefinierten Gruppe 

Gast am Lesen der Anwendungsprotokollereignisse 


Gast am Lesen der Sicherheitsprotokollereignisse 


Gast am Lesen der Systemprotokollereignisse 

Nicht definiert (Keine Änderung) Gibt die Anzahl an Tagen an, für die die Ereignisse 

aufbewahrt werden, wenn die Aufbewahrungsmethode 

für dieses Protokoll 

nach Tagen definiert ist 

Nicht definiert 

(Keine Änderung) 



Ereignisse bei Bedarf 

überschreiben 

Ereignisse bei Bedarf 

überschreiben 

Überschreibt das Sicherheitsprotokoll, sobald 

die maximale Protokollgröße erreicht 

ist, um sicherzustellen, dass das Protokoll 

die neuesten Sicherheitsereignisse enthält 

und dass die Protokollierung fortgesetzt wird 

Überschreibt das Systemprotokoll, sobld die 

maximale Protokollgröße erreicht ist, um sicherzustellen, 

dass das Protokoll die neuesten 

Sicherheitsereignisse enthält und dass 

die Protokollierung fortgesetzt wird 

Sicherheitswarnung Um sicherzustellen, dass die Überwachungsinformationen aufbewahrt werden, müssen 

Sie die System- und Sicherheitsprotokolle regelmäßig archivieren, bevor sie ihre maximale Größe erreicht 

haben. Wenn Sie die empfohlenen Einstellungen für die Aufbewahrungsmethode übernehmen, werden die 

ältesten Ereignisse überschrieben, sobald die Protokolldateien gefüllt sind. Mit der Aufbewahrungsmethode 

Ereignisse nicht überschreiben werden neue Ereignisse nicht in die Protokolldatei geschrieben, wenn diese 

ihre maximale Größe erreicht hat.


Konfigurieren von Richtlinieneinstellungen für die Benutzerrechtzuweisung auf 

Domänencontrollern 

Benutzerrechte definieren, welche Art von administrativen oder operativen Aufgaben Benutzer auf 

Domänencontrollern durchführen können. Um die Sicherheit von Domänencontrollern zu gewährleisten, 

sollten Sie durch die Benutzerrechtzuweisung einschränken, welche Benutzer sich an Domänencontrollern 

anmelden und administrative Aufgaben durchführen können. 

Wichtig Die meisten Standardeinstellungen für die Benutzerrechts- und Sicherheitsoptionen auf Domänencontrollern 

sind für eine optimale Sicherheit konfiguriert. Auch wenn die meisten Einstellungen in der Standard-Domänencontrollerrichtlinie 

als Nicht definiert konfiguriert sind, besitzen fast alle Einstellungen einen 

Standardwert, der den Sicherheitsanforderungen entspricht. Um den Standardwert anzuzeigen, öffnen Sie die 

Eigenschaften der Einstellung, und klicken Sie auf die Registerkarte Erklärung. 

Weil die Standardeinstellungen auf Sicherheit ausgelegt sind, müssen Sie die meisten Einstellungen nicht 

unbedingt aktivieren oder deaktivieren. Wenn Sie allerdings einige dieser Einstellungen auf Domänenebene 

ändern, werden sie von den Domänencontrollern in der OU Domain Controllers übernommen. Bevor Sie auf 

Domänenebene Änderungen an den Sicherheitseinstellungen vornehmen, sollten Sie die Sicherheitseinstellungen 

in der Standard-Domänencontrollerrichtlinie an die Standardeinstellung anpassen oder die Richtlinienvererbung 

in der OU Domain Controllers blockieren. 

In Tabelle 8.5 werden die standardmäßigen und die empfohlenen Einstellungen für Richtlinien zur 

Benutzerrechtzuweisung auf Domänencontrollern aufgeführt. 

Tabelle 8.5 Standardmäßige und empfohlene Richtlinieneinstellungen für die Benutzerrechtzuweisung auf 


Richtlinie Standardeinstellung Empfohlene 

Einstellung 

Lokal anmelden 

zulassen 

Herunterfahren 

des Systems 

Laden und Entfernen 

von Gerätetreibern 

Verwalten von 

Überwachungsund 

Sicherheitsprotokollen 

Konten-Operatoren 

Administratoren 

Sicherungs-Operatoren 

Druck-Operatoren 

Server-Operatoren 









Sicherungs- 

Operatoren 



Sicherungs- 

Operatoren 



Abhängig von Unternehmensanforderungen 

Kommentare 

Drucker sollten auf Domänencontrollern nicht installiert 

sein, daher müssen Druck-Operatoren 

sich nicht an Domänencontrollern anmelden. 

Konten-Operatoren sollten die Verwaltungsprogramme 

auf ihren Arbeitsstationen installiert 

haben, statt sich an Domänencontrollern anzumelden. 

Siehe oben. 

Wenn auf dem Domänencontroller keine Drucker 

installiert sind, sollte es Druck-Operatoren nicht 

gestattet sein, Gerätetreibereinstellungen zu 

ändern. 

In einigen Unternehmen müssen andere Benutzer 

als Administratoren auf die Sicherheitsprotokolle 

zugreifen und diese verwalten. Erstellen Sie 

für diesen speziellen Zweck eine Gruppe, und 

weisen Sie ihr dieses Recht zu.


Konfigurieren von Richtlinieneinstellungen für Sicherheitsoptionen auf 


Die Standard-Domänencontrollerrichtlinie umfasst eine große Anzahl an Sicherheitseinstellungen, 

die sich auf eine breite Vielfalt von Konfigurationseinstellungen für Domänencontroller, Netzwerk, 

Dateisystem und Benutzeranmeldesicherheit auswirken. Auch wenn einige dieser Einstellungen nur 

Domänencontroller betreffen, können andere Einstellungen auch die Netzwerkkonnektivität für 

Clientcomputer beeinflussen. 

Wichtig Wie die Benutzerrechteinstellungen sind die meisten Sicherheitseinstellungen in der Standard- 

Domänencontrollerrichtlinie als Nicht definiert konfiguriert. Fast alle Einstellungen besitzen jedoch einen Standardwert. 

In Tabelle 8.6 werden die in der Richtlinie verfügbaren Kategorien von Sicherheitseinstellungen aufgeführt. 

Tabelle 8.6 

Kategorien von Sicherheitseinstellungen 

Kategorie 

Konten 

Überwachung 

DCOM 

Geräte 


Domänenmitglied 

Interaktive Anmeldung 

Microsoft-Netzwerk (Client) 

Beschreibung 

Mit diesen Einstellungen können Sie die Konten Administrator und Gast aktivieren, deaktivieren 

oder umbenennen bzw. den Zugriff auf die lokalen Konten mit leeren Kennwörtern einschränken. 

Wird zum Konfigurieren der globalen Überwachungseinstellungen verwendet. Diese Kategorie 

umfasst zwei Einstellungen, die nähere Betrachtung erfordern: 

• Unterkategorieeinstellungen der Überwachungsrichtlinie erzwingen (Windows Vista oder 

höher). Wenn Sie diese Option aktivieren, werden alle Überwachungseinstellungen auf 

Ebene der Unterkategorie vorgenommen, statt dass die Unterkategorie die Kategorieeinstellungen 

übernimmt. 

• System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden 

können. Wenn Sie diese Option aktivieren, wird der Domänencontroller heruntergefahren, 

wenn eine Sicherheitsüberwachung nicht protokolliert werden kann. In den meisten Fällen 

sollten Sie diese Einstellung deaktivieren, um das Herunterfahren von Domänencontrollern 

zu vermeiden. 

Wird verwendet, um Benutzern das Starten von DCOM-Anwendungen von einem lokalen oder 

einem Remotecomputer aus zu ermöglichen oder zu verweigern. 

Wird zum Konfigurieren des Zugriffs auf Geräte wie CD-ROM- oder Diskettenlaufwerke verwendet 

oder, um zu verhindern, dass Benutzer Drucktreiber auf Druckservern installieren. 

Wird verwendet, um Server-Operatoren am Planen von Aufgaben über den AT-Befehl zu hindern, 

die LDAP-Signatur zu konfigurieren und den Domänencontroller so zu konfigurieren, 

dass Kennwortänderungen von Mitgliedscomputern aus abgelehnt werden. 

Wird zum Konfigurieren von Netzwerksicherheitseinstellungen und zum Konfigurieren von Einstellungen 

zum Festlegen von Computerkennwörtern verwendet. 

Wird zum Festlegen von Einschränkungen für den interaktiven Anmeldevorgang auf den 

Domänencontrollern verwendet. Zu den Optionen zählen: 

• Löschen des letzten Benutzeranmeldenamens 

• Konfigurieren von Anmeldenachrichten, wenn Benutzer sich an der Domäne anmelden 

• Konfigurieren von Smartcardanforderungen 

Wird verwendet, um Anforderungen für die digitale Signatur der Netzwerkkommunikation für 

Clientcomputer zu konfigurieren.


Tabelle 8.6 

Kategorien von Sicherheitseinstellungen (Fortsetzung) 

Kategorie 

Microsoft-Netzwerk (Server) 

Netzwerkzugriff 

Wiederherstellungskonsole 

Herunterfahren 

Systemkryptographie 

Systemobjekte 

Systemeinstellungen 

Benutzerkontensteuerung 

Beschreibung 

Wird verwendet, um Einstellungen für die digitale Signatur der Netzwerkkommunikation und 

für das Trennen von Benutzern nach Ablauf der Anmeldezeiten zu konfigurieren. 

Wird zum Konfigurieren einer breiten Vielfalt an Netzwerkzugriffseinstellungen verwendet, beispielsweise, 

ob die anonyme Aufzählung von SAM-Konten erlaubt ist, und von Optionen für die 

Verbindung mit Freigaben. 

Wird verwendet, um zu definieren, wer auf die Wiederherstellungskonsole zugreifen kann und ob 

Diskettenlaufwerke und andere Laufwerke von der Wiederherstellungskonsole aus zugänglich 

sind. 

Wird verwendet, um zu konfigurieren, ob Benutzer den Computer ohne Anmeldung herunterfahren 

können und ob die Auslagerungsdatei für virtuellen Speicher beim Herunterfahren 

gelöscht wird. 

Wird verwendet, um Sicherheitsanforderungen für auf Computern gespeicherte Schlüssel und 

für Algorithmen durchzusetzen, die zum Erstellen sicherer Schlüssel verwendet werden. 

Wird zum Einstellen von Sicherheitsanforderungen für Windows-Systemobjekte verwendet. 

Wird zum Konfigurieren zusätzlicher Subsysteme wie POSIX und zum Aktivieren von Zertifikatregeln 

für Softwareeinschränkungsrichtlinien verwendet. 

Wird verwendet, um zu konfigurieren, wie Einstellungen zur Benutzerkontensteuerung auf 

Clientcomputer unter Windows Vista angewendet werden. 

Weitere Informationen Einzelheiten zu allen unter Windows Server 2008 verfügbaren Sicherheitseinstellungen 

erhalten Sie, indem Sie das Arbeitsblatt Group Policy Settings Reference Windows Vista von folgender 

Adresse herunterladen: http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b- 

3328-4350-ade1-c0d9289f09ef&displaylang=en. 

Implementieren der SMB-Signatur 

Windows Server 2008 unterstützt die SMB-Signatur, damit Sie sicherzustellen können, dass jeder 

Dateifreigabezugriff auf Domänencontrollern verschlüsselt wird. Computer in derselben Domäne wie 

der Domänencontroller greifen während des Benutzeranmeldevorgangs auf Dateifreigaben zu, um 

Anmeldeskripts und Profile in der Freigabe Netlogon zu verwenden. Gruppenrichtlinienobjekte sind 

über die Freigabe SYSVOL zugänglich. Aus diesen Gründen sollten alle Domänencontroller die SMB- 

Signatur nutzen, um die Sicherheit zu verbessern. 

In Tabelle 8.7 werden die Richtlinieneinstellungen der Sicherheitsoptionen für die SMB-Signatur 

beschrieben. 

Tabelle 8.7 

Richtlinieneinstellungen der Sicherheitsoptionen für die SMB-Paketsignatur 

SMB-Einstellung 

Microsoft-Netzwerk (Client): 

Kommunikation digital signieren 

(immer) 

Erläuterung 

Der Domänencontroller erfordert eine SMB-Signatur beim Initiieren von SMB-Anforderungen 

an andere Domänencontroller, Mitgliedsserver oder Arbeitsstationen. Der Domänencontroller 

lehnt die Kommunikation mit anderen Systemen ab, die keine SMB-Signatur unterstützen. 

Aktivieren Sie diese Gruppenrichtlinieneinstellung zum Verbessern der Sicherheit.


Tabelle 8.7 

Richtlinieneinstellungen der Sicherheitsoptionen für die SMB-Paketsignatur (Fortsetzung) 

SMB-Einstellung 

Microsoft-Netzwerk (Client): 


(wenn Server zustimmt) 

Microsoft-Netzwerk (Server): 


(immer) 

Microsoft-Netzwerk (Server): 


(wenn Client zustimmt) 

Erläuterung 

Der Domänencontroller verhandelt über eine SMB-Signatur beim Initiieren von SMB-Anforderungen 

an andere Domänencontroller, Mitgliedsserver oder Arbeitsstationen. Der Domänencontroller 

verlangt die SMB-Signatur, kommuniziert jedoch auch mit anderen Systemen, die 

keine SMB-Signatur unterstützen. Aktivieren Sie diese Option nur dann, wenn Sie 

Windows 95 und frühere Betriebssysteme verwenden. 

Der Domänencontroller erfordert eine SMB-Signatur beim Empfangen von SMB-Anforderungen 

von anderen Domänencontrollern, Mitgliedsservern oder Arbeitsstationen. Der Domänencontroller 

lehnt die Kommunikation mit anderen Systemen ab, die keine SMB-Signatur 

unterstützen. Aktivieren Sie diese Gruppenrichtlinieneinstellung zum Verbessern der Sicherheit. 

Diese Option ist standardmäßig in der Standard-Domänencontrollerrichtlinie aktiviert. 

Der Domänencontroller verhandelt über eine SMB-Signatur beim Empfangen von SMB-Anforderungen 

von anderen Domänencontroller, Mitgliedsservern oder Arbeitsstationen. Der 

Domänencontroller verlangt die SMB-Signatur, kommuniziert jedoch auch mit anderen Systemen, 

die keine SMB-Signatur unterstützen. Diese Option ist standardmäßig in der Standard- 

Domänencontrollerrichtlinie aktiviert. 

Hinweis Diese Optionen können auch durch Anwenden einer Sicherheitskonfigurationsrichtlinie auf die 

Domänencontroller durchgesetzt werden. Beim Ausführen des Sicherheitskonfigurations-Assistenten 

haben Sie die Möglichkeit, Registrierungseinträge auf dem Server so zu konfigurieren, dass die SMB-Sicherheit 

durchgesetzt wird. Die Benutzeroberfläche wird in Abbildung 8.9 gezeigt. Wenn Sie beide Optionen auswählen, 

wird die SMB-Signatur auf dem Server durchgesetzt. 

Abbildung 8.9 

Konfigurieren der SMB-Signatur mithilfe des Sicherheitskonfigurations-Assistenten


Konfigurieren von SYSKEY 

Standardmäßig wird der AD DS-Datenspeicher verschlüsselt, wenn er auf der Festplatte des Domänencontrollers 

gespeichert wird. Dies bietet eine gewisse Sicherheit, wenn ein Angreifer sich Zugriff 

auf die physische Festplatte verschafft, auf der sich der Datenspeicher befindet. Die Daten werden 

über den Systemschlüssel (SYSKEY) in Windows Server 2008 verschlüsselt. 

Mithilfe des Tools SYSKEY können Sie zusätzliche Sicherheit beim Starten von Domänencontrollern 

gewährleisten. SYSKEY stellt Ihnen drei Optionen zum Konfigurieren des Startschlüssels bereit: 

• Systemstartschlüssel lokal speichern Diese Option erstellt anhand eines komplexen Verschlüsselungsalgorithmus 

einen vom Computer nach dem Zufallsprinzip generierten Schlüssel, der auf 

dem lokalen System gespeichert ist. Dies ist die Standardkonfiguration von Syskey.exe, welche 

eine starke Verschlüsselung von Kennwortinformationen in der Registrierung bietet. Da der Systemschlüssel 

auf dem lokalen System gespeichert wird, ermöglicht diese Methode unbeaufsichtigte 

Systemneustarts. 

• Kennwort für den Systemstart Diese Option erfordert ein vom Administrator gewähltes Kennwort 

zum Ableiten des Systemschlüssels. Wenn Sie diese Option auswählen, muss ein Administrator 

während des Systemstarts das Systemschlüsselkennwort eingeben. 

• Systemstartschlüssel auf Diskette speichern Diese Option erstellt einen vom Computer nach dem 

Zufallsprinzip generierten Schlüssel, der auf einer Diskette gespeichert wird. Die Diskette mit 

dem Systemschlüssel muss in das Diskettenlaufwerk eingelegt werden, um den Domänencontroller 

zu starten. 

Das Konfigurieren von SYSKEY für die Verwendung eines Kennworts oder einer Diskette für den 

Systemstart kann zusätzliche Sicherheit für Domänencontroller bieten, die physisch nicht abgesichert 

sind. Diese Option erfordert jedoch, dass ein Administrator, der das Kennwort kennt, bzw. die Diskette 

beim Neustart des Domänencontrollers verfügbar sein muss. Wenn Sie den SYSKEY auf einer 

Diskette speichern und die Diskette verloren geht, können Sie den Domänencontroller nicht neu starten. 

Hinweis Erwägen Sie den Einsatz eines RODC in Situationen, in denen der Domänencontroller nicht physisch 

gesichert werden kann, statt die SYSKEY-Sicherheitseinstellungen zu implementieren. 

Entwerfen sicherer administrativer Vorgehensweisen 

Eine der wichtigsten Komponenten beim Entwerfen der AD DS-Sicherheit ist das Entwerfen sicherer 

administrativer Vorgehensweisen. Da Administratoren vollständige Kontrolle über die AD DS-Umgebung 

besitzen, können sie sogar den besten Sicherheitsentwurf umgehen oder ändern. Ziehen Sie 

beim Erstellen Ihrer administrativen Vorgehensweisen die folgenden Vorschläge in Betracht: 

• Beschränken Sie die Anzahl von Organisations- und Domänenadministratorkonten auf höchst vertrauenswürdiges 

Personal. Dies ist besonders für Dienstadministratorkonten wichtig. Beschränken 

Sie die Mitgliedschaft von Dienstadministratorkonten auf ein absolutes Minimum, und weisen 

Sie nur zuverlässige und vertrauenswürdige Benutzer zu, denen die Auswirkungen aller Änderungen 

am Verzeichnis umfassend bekannt sind. Verwenden Sie Dienstadministratorkonten nicht 

für alltägliche Aufgaben.

Entwerfen sicherer administrativer Vorgehensweisen 313 

• Implementieren Sie einen Änderungskontrollprozess. Alle an einer AD DS-Umgebung vorgenommenen 

Änderungen sollten einem Änderungskontrollprozess unterliegen. Dies ist besonders für 

Änderungen relevant, die sich auf die gesamte Verzeichnisdienstumgebung auswirken. Beispielsweise 

sollten Schemaänderungen nur nach sorgfältiger Planung und Testläufen und mit Genehmigung 

des Gesamtstrukturbesitzers implementiert werden. 

• Begrenzen Sie die Gruppe Schema-Admins auf temporäre Mitglieder. Die meisten Unternehmen 

ändern das Schema sehr selten, daher muss sich niemand regelmäßig als Schemaadministrator 

anmelden. Um den Schemaänderungsvorgang zu sichern, lassen Sie die Mitgliedschaft in der 

Gruppe Schema-Admins leer. Fügen Sie der Gruppe nur dann einen vertrauenswürdigen Benutzer 

hinzu, wenn eine administrative Aufgabe am Schema durchgeführt werden muss. Entfernen Sie 

den Benutzer, sobald die Aufgabe abgeschlossen ist. 

• Verwenden Sie eine Richtlinie für eingeschränkte Gruppen, um die Mitgliedschaft für die wichtigen 

Domänen- und Gesamtstrukturkonten zu beschränken. Beim Implementieren einer Richtlinie 

für eingeschränkte Gruppen wird die Gruppenmitgliedschaft von den Domänencontrollern 

überwacht, und nicht in der Richtlinie für eingeschränkte Gruppen enthaltene Benutzer werden 

automatisch entfernt. 

• Stellen Sie sicher, dass Administratoren zwei verschiedene Konten besitzen und verwenden. 

Erstellen Sie für Benutzer, die eine administrative Funktion erfüllen, zwei Konten: ein normales 

Benutzerkonto für normale, alltägliche Aufgaben und ein Administratorkonto, das nur zur Durchführung 

administrativer Aufgaben verwendet wird. Das Administratorkonto sollte nicht E-Mailfähig 

sein oder zur Ausführung täglich genutzter Anwendungen, wie beispielsweise Microsoft 

Office, oder für das Surfen im Internet verwendet werden. 

• Wenden Sie den Prinzipal mit den wenigsten Berechtigungen für alle Administratorengruppen an. 

Definieren Sie die Berechtigungen, die für die einzelnen Administratorengruppen tatsächlich 

erforderlich sind, mit Sorgfalt, und weisen Sie anschließend nur diese Berechtigungen zu. Wenn 

ein Administrator beispielsweise nur bestimmte Benutzerkonten oder Computerkonten oder auch 

nur einige Einstellungen für diese Konten verwalten muss, erstellen Sie eine OU für diese Konten, 

und delegieren Sie anschließend Berechtigungen an das Administratorkonto. Vermeiden Sie 

außerdem die Verwendung der Gruppe Konten-Operatoren, um die Berechtigung zum Konfigurieren 

von Benutzer- und Gruppenkonten zuzuweisen. Die Standardverzeichnisberechtigungen erteilen 

dieser Gruppe die Möglichkeit, die Computerkonten von Domänencontrollern zu ändern. Dies 

schließt auch den Löschvorgang mit ein. Standardmäßig enthält die Gruppe Konten-Operatoren 

keine Mitglieder, und dies sollte so bleiben. 

• Verbergen Sie das Domänenadministratorkonto. Jede AD DS-Installation verfügt über ein Konto 

namens Administrator in jeder Domäne. Dies ist das Standardadministratorkonto, das während der 

Domäneneinrichtung erstellt wird und das Sie für den Zugriff und die Verwaltung des Verzeichnisdienstes 

nutzen können. Es handelt sich um ein besonderes Konto, das vom System geschützt 

wird, um sicherzustellen, dass es bei Bedarf vorhanden ist. Dieses Konto kann nicht deaktiviert 

oder gesperrt werden. Sie sollten ihm einen anderen Namen als Administrator geben. Wenn Sie 

das Konto umbenennen, stellen Sie sicher, dass Sie auch den Beschreibungstext für das Konto 

ändern. Zusätzlich sollten Sie ein Lockvogel-Benutzerkonto namens Administrator erstellen, das 

keinerlei besondere Berechtigungen oder Benutzerrechte besitzt, und die Ereignis-IDs 528, 529 

und 534 in Verbindung mit dem umbenannten und dem Lockvogelkonto überwachen.


• Lassen Sie Administratorkonten niemals von mehreren Personen nutzen. In manchen Unternehmen 

kennen alle Administratoren das Kennwort für das Standardadministratorkonto, und alle verwenden 

dieses Konto für die Durchführung administrativer Aufgaben. Die gemeinsame Nutzung 

von Administratorkonten vereitelt jede Möglichkeit, genau zu überwachen, wer Änderungen am 

Verzeichnis vorgenommen hat; von dieser Vorgehensweise wird daher dringend abgeraten. Die 

gemeinsame Nutzung von Administratorkonten und Kennwörtern kann außerdem zu einem 

Sicherheitsproblem führen, wenn Administratoren das Team oder das Unternehmen verlassen. 

• Sichern Sie den Anmeldevorgang für Administratoren. Um das Risiko, dass jemand ein Administratorkonto 

missbraucht oder schädigt, auf ein Minimum zu beschränken, sollten Sie folgende 

Schritte in Betracht ziehen, um starke Administratoranmeldeinformationen durchzusetzen: 

Verlangen Sie Smartcards für die Administratoranmeldung. Lassen Sie Dienstadministratoren 

Smartcards für ihre interaktive Anmeldung verwenden. Abgesehen davon, dass Sie Administratoren 

zum Besitz einer Karte für die Anmeldung zwingen, stellen Smartcards außerdem 

sicher, dass ein zufällig generiertes, kryptografisch starkes Kennwort für das Benutzerkonto 

verwendet wird. Diese starken Kennwörter stellen einen Schutz gegen den Diebstahl 

schwacher Kennwörter zum Erlangen des Administratorzugriffs dar. Sie können die Verwendung 

von Smartcards durch Aktivieren der Sicherheitsoption Interaktive Anmeldung: Smartcard 

erforderlich für jedes Administratorkonto durchsetzen. 

Teilen Sie die Anmeldeinformationen für besonders kritische Administratorkonten auf. Jedem 

Konto, das Mitglied der Gruppe Organisations-Admins oder Domänen-Admins in der Gesamtstruktur-Stammdomäne 

ist, weisen Sie zwei Benutzer zur gemeinsamen Nutzung zu, sodass 

beide Benutzer anwesend sein müssen, um sich erfolgreich am Konto anzumelden. Sie können 

die Anmeldeinformationen aufteilen, indem Sie entweder geteilte Kennwörter (jeder Administrator 

kennt nur einen Teil des Kennworts) oder geteilte Smartcards plus PINs verwenden. 

• Sichern Sie die Arbeitsstationen von Dienstadministratoren. Zusätzlich zur Konfiguration der 

Sicherheit des Administratorkontos sollten Sie außerdem die Sicherheit der Administratorarbeitsstationen 

sicherstellen. Erwägen Sie zu diesem Zweck die Implementierung folgender Prozesse: 

Schränken Sie ein, an welchen Arbeitsstationen Dienstadministratoren sich anmelden können. 

Jedes Administratorkonto kann so eingeschränkt werden, dass es sich nur an bestimmten 

Arbeitsstationen anmelden darf. Wenn die Sicherheit eines Ihrer Administratorkonten verletzt 

wird, begrenzt das Einschränken der möglichen Arbeitsstationen auch die Anzahl der Stellen, 

an denen das Konto verwendet werden kann. 

Wenden Sie eine besondere Sicherheitsrichtlinie auf die Administratorarbeitsstationen an. Ziehen 

Sie das Verschieben aller Arbeitsstationen der Dienstadministratoren in eine dedizierte 

OU in Betracht, und weisen Sie dieser anschließend eine hoch sichere Richtlinie für die 

Arbeitsstationen zu. Beispielsweise können Sie das Benutzerrecht Lokal anmelden zulassen 

auf die Dienstadministratorkonten einschränken. 

Stellen Sie sicher, dass auf Administratorarbeitsstationen alle Sicherheitsupdates installiert 

sind und dass die Antivirussoftware auf den Arbeitsstationen auf dem neuesten Stand ist. 

Fordern Sie Administratoren zur Verwendung von Remote Desktop für die Durchführung administrativer 

Aufgaben auf. Sie können Remote Desktop auf jedem Windows Server 2008 aktivieren 

und die Sicherheitseinstellungen so konfigurieren, dass nur die angegebenen Administratoren 

sich über Remote Desktop mit dem Server verbinden können. Wenn Sie den Remote Desktop 

6-Client auf Windows XP-Clients installieren oder einen Windows Vista-Client verwenden, können 

Sie die Netzwerkverschlüsselung für alle Remote Desktop-Verbindungen durchsetzen.


• Sichern Sie die Sicherungsmedien. Wenn Sie die Domänencontroller in Ihrem Unternehmen 

sichern, wird der gesamte Verzeichnisspeicher auf die Sicherungsmedien kopiert. Auch wenn die 

Daten verschlüsselt sind, besitzt ein Angreifer, der Zugriff auf die Bänder erlangt, beliebig viel 

Zeit, um die Daten zu entschlüsseln und darauf zuzugreifen. Sie können folgendermaßen verhindern, 

dass unbefugte Benutzer physisch auf Sicherungsmedien zugreifen: 

Lagern Sie Sicherungsmedien, die am Standort verwendet werden, an einem sicheren Ort, dessen 

Zugang überwacht wird. 

Lagern Sie Archivsicherungsmedien an einem sicheren Ort außerhalb des Standorts. 

Richten Sie sichere Verfahren für den Transport von Sicherungsmedien ein. 

• Stellen Sie Kontingente für den Objektbesitz ein. Auf Domänencontrollern unter Windows 

Server 2008 können Sie Kontingente festlegen, um die Anzahl an Objekten einzuschränken, die 

ein Sicherheitsprinzipal (Benutzer, Gruppe, Computer oder Dienst) in einer Domänen-, Konfigurations- 

oder Anwendungsverzeichnispartition besitzen kann. Standardmäßig ist der Sicherheitsprinzipal, 

der ein Objekt erstellt, der Objektbesitzer, auch wenn der Besitz übertragen werden 

kann. AD DS-Kontingente unterbinden die Möglichkeit, eine unbegrenzte Anzahl an Objekten in 

einer Verzeichnispartition zu erstellen, was für Dienstverweigerungsangriffe (Denial-of-Service 

Attacks) genutzt werden könnte. Standardmäßig sind keine Kontingente eingestellt; es gibt daher 

keine Einschränkung für die Anzahl an Objekten, die jeder Sicherheitsprinzipal besitzen kann. 

Verwenden Sie zum Festlegen von Kontingenten den Befehl Dsmod Quota. 


Dieses Kapitel hat Ihnen in einer kurzen Übersicht die grundlegenden Konzepte der AD DS-Sicherheit 

unter Windows Server 2008 vorgestellt. Hierzu gehören Sicherheitsprinzipale, Zugriffssteuerungslisten, 

Authentifizierung und Autorisierung. Im ersten Teil dieses Kapitels wurde der Schwerpunkt 

auf die wichtigsten Möglichkeiten zum Bereitstellen der Authentifizierung und Autorisierung in 

AD DS über das Kerberos-Protokoll gelegt. Kerberos bietet einen sicheren Mechanismus, mit dem 

Benutzer sich an AD DS authentifizieren und Zugriff auf Netzwerkressourcen erlangen können. 

Die zweite Komponente zur Bereitstellung von AD DS-Sicherheit besteht darin, Domänencontroller 

abzusichern und sichere administrative Vorgehensweisen zu implementieren. Der zweite Teil dieses 

Kapitels bietet Einzelheiten zur Implementierung dieser Art der Sicherheit. 


• Aktualisieren Sie nach Möglichkeit alle Server und Arbeitsstationen zumindest auf Windows 

Server 2000 mit den neuesten Service Packs. Hierdurch können Sie sicherstellen, dass für alle 

Authentifizierungsanforderungen Kerberos verwendet wird, und Sie können Sicherheitsfunktionen 

wie SMB-Signaturen auf Domänencontrollern konfigurieren. 

• Implementieren Sie dedizierte Domänencontroller. Mit anderen Worten, führen Sie keine Anwendungen 

oder Dienste aus, die auf Domänencontrollern nicht erforderlich sind. Dies macht es leichter, 

die Angriffsfläche von Domänencontrollern zu verringern, und vereinfacht außerdem die 

Erstellung einer Sicherheitskonfigurationsrichtlinie, die auf alle Domänencontroller angewendet 

werden kann.


• Implementieren Sie eine vollständige Kennwortrichtlinie, und fordern Sie Administratoren zum 

Konfigurieren extrem komplexer Kennwörter auf. Schlagen Sie vor, dass Administratoren eher 

Kennsätze statt Kennwörtern verwenden sollten. 

• Weisen Sie die allen Administratorkonten die geringstmöglichen Berechtigungen zu. Stellen Sie 

sicher, dass alle Administratoren nur über diejenigen Berechtigungen verfügen, die sie zum 

Durchführen der für ihre Position erforderlichen Aufgaben benötigen. 


Die folgenden Ressourcen enthalten Zusatzinformationen im Zusammenhang mit diesem Kapitel. 


• Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, enthält Einzelheiten zum 

Entwerfen sicherer AD DS-Grenzen. 

• Kapitel 9, „Delegieren der Active Directory-Domänendiensteverwaltung“, erläutert, wie Administratorberechtigungen 

innerhalb von AD DS delegiert werden. Dies ist hilfreich beim Anwenden 

des geringsten Berechtigungsstandards. 

• Kapitel 11, „Einführung in Gruppenrichtlinien“, schildert detailliert die Konfiguration der Gruppenrichtlinien 

und wie die Gruppenrichtlinienvererbung aktiviert oder deaktiviert wird. Möglicherweise 

möchten Sie die Gruppenrichtlinienvererbung in der OU Domain Controllers 

blockieren, um zu verhindern, dass Sicherheitseinstellungen auf Domänenebene auf Domänencontroller 

angewendet werden. 

• Kapitel 13, „Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit“, bietet Informationen 

über zusätzliche Gruppenrichtlinieneinstellungen, die zum Konfigurieren der Sicherheit zur 

Verfügung stehen. 

• Im englischsprachigen Artikel „The Kerberos Network Authentication Service (V5)“, der unter 

http://www.ietf.org/rfc/rfc1510.txt zur Verfügung steht, wird der aktuelle Kerberos-Standard 

beschrieben. 

• „Kerberos Authentication Technical Reference“, verfügbar in englischer Sprache unter http:// 

technet2.microsoft.com/windowsserver/en/library/74d58697-970a-45db-9139- 

ebcd3db051181033.mspx?mfr=true 

• „Authorization and Access Control Technologies“, verfügbar in englischer Sprache unter http:// 

technet2.microsoft.com/windowsserver/en/library/74d58697-970a-45db-9139- 

ebcd3db051181033.mspx?mfr=true 

• „Troubleshooting Kerberos“, verfügbar in englischer Sprache unter http://technet2.microsoft.com/ 

windowsserver/en/library/26ce2e7f-52d6-4425-88cc-1573bc5e646d1033.mspx?mfr=true 

• „Troubleshooting Kerberos Errors“, verfügbar in englischer Sprache unter http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx



Windows Server 2008 bietet mehrere Tools, die zur Problembehandlung bei der Kerberos-Authentifizierung 

eingesetzt werden können. In Tabelle 8.8 werden einige dieser Tools gemeinsam mit Nutzungsinformationen 

aufgeführt. 

Tabelle 8.8 Tools zur Problembehandlung bei Kerberos 

Toolname 

Klist.exe: Kerberos List 

Kerbtray.exe: Kerberos 

Tray 

Tokensz.exe 

Kerberos Token Size 

Setspn.exe 

Ksetup.exe 

Ktpass.exe 

W32tm.exe: Windows-Zeitgeber 


Dieses Tool wird auf Windows Server 2008-Domänencontrollern installiert und steht als Bestandteil 

der Windows Server 2003 Resource Kit-Tools zum Download zur Verfügung. 

Kerberos List ist ein Befehlszeilenprogramm, das zum Anzeigen und Löschen von Kerberos- 

Tickets eingesetzt wird, die für die aktuelle Anmeldesitzung erteilt wurden. Um Kerberos List 

zum Anzeigen von Tickets auszuführen, müssen Sie das Tool auf einem Computer ausführen, 

der Mitglied in einem Kerberos-Bereich ist. 

Kerberos Tray steht als Bestandteil der Windows Server 2003 Resource Kit-Tools zum Download 


Kerberos Tray ist ein Tool mit grafischer Benutzeroberfläche, welches Ticketinformationen für 

einen Computer anzeigt, auf dem die Microsoft-Implementierung des Authentifizierungsprotokolls 

Kerberos, Version 5, ausgeführt wird. Über das Kerberos Tray-Symbol im Benachrichtigungsbereich 

des Desktops können Sie den Ticketzwischenspeicher anzeigen und löschen. 

Wenn Sie den Cursor auf dem Symbol platzieren, können Sie die Zeit bis zum Ablaufen des anfänglichen 

TGT anzeigen. Das Symbol ändert sich außerdem in der Stunde, bevor die LSA 

(Local Security Authority) das Ticket erneuert. 

Kerberos Token Size kann vom Microsoft-Downloadcenter heruntergeladen werden. 

Mithilfe von Kerberos Token Size können Sie prüfen, ob die Quelle der Kerberos-Fehler von 

einem Problem mit der maximalen Tokengröße herrührt. Das Tool simuliert eine Authentifizierungsanforderung 

und meldet die Größe des daraus resultierenden Kerberos-Tokens. Außerdem 

meldet das Tool die maximal unterstützte Größe für das Token. 

Das Dienstprogramm Setspn wird auf Windows Server 2008-Domänencontrollern installiert und 

ist in den Windows Server 2003-Supporttools enthalten. 

Mit dem Dienstprogramm Setspn können Sie die SPN-Verzeichniseigenschaft (Service Principal 

Name) für ein Active Directory-Dienstkonto lesen, ändern und löschen. Da SPNs sicherheitsrelevant 

sind, können Sie nur dann SPNs für Dienstkonten erstellen, wenn Sie Domänenadministratorrechte 

besitzen. 

Das Dienstprogramm Ksetup wird auf Windows Server 2008-Domänencontrollern installiert und 


Das Dienstprogramm Ksetup konfiguriert einen Client, der mit einem Server unter 

Windows Server 2008 verbunden ist, für die Verwendung eines Servers, auf dem Kerberos V5 

ausgeführt wird. Der Client verwendet anschließend einen Kerberos V5-Bereich anstelle einer 

Windows Server 2008-Domäne. 

Das Dienstprogramm Ktpass wird auf Windows Server 2008-Domänencontrollern installiert und 


Mit dem Dienstprogramm Ktpass können Sie einen Kerberos-Dienst, der nicht unter Windows 

ausgeführt wird, als Sicherheitsprinzipal in den Windows Server 2008-AD DS konfigurieren. 

Dieses Tool ist in Microsoft Windows-Server- und -Clientbetriebssystemen enthalten. 

W32tm.exe wird zum Konfigurieren der Windows-Zeitdiensteinstellungen verwendet. Es kann 

außerdem zum Diagnostizieren von Problemen mit dem Zeitdienst eingesetzt werden.



• SampleDC_SCWPolicy.xml. Hierbei handelt es sich um eine Beispieldatei des Sicherheitskonfigurations-Assistenten, 

welche die Dienste, die Windows-Firewall und die Registrierungseinstellungen 

für einen Windows Server 2008-Domänencontroller konfiguriert. 


• Hilfe zum Sicherheitskonfigurations-Assistenten

319 


Delegieren der Active Directory-Domänendiensteverwaltung 


Active Directory-Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 

Zugreifen auf Active Directory-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 

Active Directory-Objektberechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 

Delegieren von Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 

Überwachen der Verwendung von Administratorrechten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 

Tools für die delegierte Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 

Planen der delegierten Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 



Die Active Directory-Domänendienste (Active Directory Domain Services, AD DS) werden typischerweise 

als Verzeichnisdienst bereitgestellt, der von mehreren Geschäftsbereichen innerhalb einer 

Organisation gemeinsam verwendet wird. Durch die Verwendung eines gemeinsamen Verzeichnisdiensts 

lassen sich die Kosten für Verwaltung und Pflege der Infrastruktur reduzieren, es müssen 

jedoch verschiedene andere Faktoren berücksichtigt werden: 

• Unabhängige Verwaltung von Benutzern und Ressourcen für einzelne Bereiche, wenn eine 

dezentrale Verwaltung erforderlich ist 

• Sicherstellen, dass Administratoren oder Benutzer innerhalb ihres Geschäftsbereichs ausschließlich 

Aufgaben ausführen dürfen, für die sie berechtigt sind 

• Sicherstellen, dass bestimmte Objekte oder Informationen, die im Verzeichnis gespeichert sind, 

ausschließlich für Administratoren mit den erforderlichen Berechtigungen verfügbar sind 

Diesen Faktoren kann durch umfangreiche Kenntnisse zur Delegierung von Verwaltungsaufgaben 

Rechnung getragen werden. Bei der Delegierung erteilt ein Administrator auf höherer Ebene anderen 

Benutzern Berechtigungen zum Durchführen bestimmter Verwaltungsaufgaben innerhalb der Active 

Directory-Struktur. Die Active Directory-Struktur bietet eine hierarchische Sicht des Verzeichnisdiensts: 

zunächst auf Standort- und Domänenebene, dann auf OU-Ebene (Organizational Unit, Organisationseinheit) 

innerhalb einer Domäne. Diese Hierarchie bietet leistungsfähige Optionen zum Verwalten 

von Berechtigungen und Delegieren von Verwaltungsaufgaben auf unterschiedlichen Ebenen 

innerhalb der logischen Infrastruktur. 

In diesem Kapitel wird die Delegierung der Verwaltung erläutert. Zunächst werden die unterschiedlichen 

Typen von Verwaltungsaufgaben beschrieben, die innerhalb eines Unternehmens delegiert werden 

können. Anschließend werden der Objektzugriff, die Typen von Berechtigungen, die Objekten 

innerhalb des Verzeichnisses zugewiesen werden können, sowie die Verwendung dieser Berechtigungen 

zur Delegierung der Verwaltung erklärt.

320 Kapitel 9: Delegieren der Active Directory-Domänendiensteverwaltung 

Und schließlich werden Informationen zum Überwachen von Änderungen an Objekten innerhalb der 

AD DS bereitgestellt. 

Active Directory-Verwaltungsaufgaben 

Active Directory-Verwaltungsaufgaben lassen sich typischerweise einer von zwei Kategorien zuordnen: 

der Datenverwaltung oder der Dienstverwaltung. Datenverwaltungsaufgaben beziehen sich auf 

die Verwaltung von Inhalten, die innerhalb der Active Directory-Datenbank gespeichert sind. Dienstverwaltungsaufgaben 

umfassen die Verwaltung aller Aspekte, die erforderlich sind, um eine zuverlässige 

und effiziente Bereitstellung des Verzeichnisdiensts innerhalb des Unternehmens sicherzustellen. 

In Tabelle 9.1 sind einige der Aufgaben für jede dieser Kategorien beschrieben. 

Tabelle 9.1 

Active Directory-Verwaltung 

Kategorie 

Datenverwaltung 

Dienstverwaltung 

Aufgaben 

Kontenverwaltung – umfasst das Erstellen, Verwalten und Entfernen von Benutzerkonten 

Sicherheitsgruppenverwaltung – umfasst das Erstellen von Sicherheitsgruppen, Bereitstellen 

von Sicherheitsgruppen für den Zugriff auf Netzwerkressourcen, Verwalten von Sicherheitsgruppenmitgliedschaften 

sowie das Entfernen von Sicherheitsgruppen 

Ressourcenverwaltung – umfasst sämtliche Aspekte der Verwaltung von Netzwerkressourcen 

wie z.B. Endbenutzerarbeitsstationen, Server und auf Servern gehostete Ressourcen 

(beispielsweise Dateifreigaben oder Anwendungen) 

Gruppenrichtlinienverwaltung – umfasst sämtliche Aspekte beim Erstellen, Zuweisen und 

Entfernen von Gruppenrichtlinienobjekten innerhalb der Active Directory-Struktur 

Anwendungsspezifische Datenverwaltung – umfasst sämtliche Aspekte der Verwaltung 

von in Active Directory integrierten oder Active Directory-fähigen Anwendungen wie z.B. 

Microsoft Exchange Server 

Verwaltung von Installation und Vertrauensstellungen – umfasst Aspekte wie das Erstellen 

und Löschen von Domänen, die Bereitstellung von Domänencontrollern sowie die Konfiguration 

von geeigneten Active Directory-Funktionsebenen 

Verwaltung von Domänencontrollern und Verzeichnisdatenbank – umfasst Aspekte im 

Hinblick auf die Verwaltung von Domänencontrollerhardware, Datenbankwartung sowie die 

Anwendung von Service Packs und Sicherheitsupdates 

Schemaverwaltung – umfasst das Erweitern oder Ändern des Schemas, um die Bereitstellung 

von Active Directory-fähigen Anwendungen zu unterstützen 

Verwaltung der Betriebsmasterrolle – umfasst Aufgaben zum Sicherstellen der ordnungsgemäßen 

Zuweisung und Konfiguration von Betriebsmasterrollen 

Verwaltung von Sicherungen und Wiederherstellungen – umfasst sämtliche Aufgaben im 

Zusammenhang mit regelmäßigen Sicherungen der Verzeichnisdatenbank und (bei Bedarf) 

den erforderlichen Wiederherstellungsverfahren 

Replikationsverwaltung – umfasst sämtliche Aufgaben im Zusammenhang mit der Erstellung, 

Verwaltung und Überwachung der Replikationstopologie 

Sicherheitsrichtlinienverwaltung – umfasst sämtliche Aufgaben im Zusammenhang mit der 

Verwaltung der standardmäßigen Sicherheitsrichtlinie für Domänencontroller sowie der Kennwort-, 

Kontosperrungs- und Kerberos-Kontorichtlinien

Zugreifen auf Active Directory-Objekte 321 

Weitere Informationen Weitere Informationen zu den Aufgaben im Hinblick auf die Daten- und Dienstverwaltung 

finden Sie im Artikel „Best Practices for Delegating Active Directory Administration“ unter http:// 

www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/ 

actdid1.mspx. 

Das Delegieren von Daten- und Dienstverwaltungsaufgaben setzt ein Verständnis der administrativen 

Anforderungen aller Geschäftseinheiten voraus. Auf diese Weise wird die Verwendung des effektivsten 

Delegierungsmodells sichergestellt, um eine effektivere, effizientere und sicherere Netzwerkumgebung 

bereitzustellen. Zur Bereitstellung des Delegierungsmodells ist ein Verständnis von Active 

Directory-Objektberechtigungen, Delegierungmethoden und Überwachungsvorgängen erforderlich. 

Diese Konzepte werden in den folgenden Abschnitten näher erläutert. 

Zugreifen auf Active Directory-Objekte 

Für eine effektive Delegierung von Verwaltungsaufgaben müssen Sie wissen, wie der Zugriff auf 

Objekte im Verzeichnisdienst in Active Directory gesteuert wird. Die Zugriffssteuerung umfasst 

Folgendes: 

• Anmeldeinformationen des Sicherheitsprinzipals, der versucht, die Aufgabe auszuführen oder auf 

die Ressource zuzugreifen 

• Autorisierungsdaten zum Schützen der Ressource oder Autorisieren der Aufgabe 

• Eine Zugriffsüberprüfung für den Vergleich der Anmeldeinformationen mit den Autorisierungsdaten, 

um zu ermitteln, ob der Sicherheitsprinzipal zum Zugreifen auf die Ressource oder Ausführen 

der Aufgabe berechtigt ist 

Bei der Anmeldung eines Benutzers an einer AD DS-Domäne wird dieser authentifiziert und erhält 

ein Zugriffstoken. Ein Zugriffstoken enthält die Sicherheitskennung (Security Identifier, SID) für das 

Benutzerkonto, SIDs für die verschiedenen Sicherheitsgruppen, zu denen der Benutzer gehört, sowie 

eine Liste der Berechtigungen, über die der Benutzer und die Sicherheitsgruppen des Benutzers verfügen. 

Das Zugriffstoken dient zur Bereitstellung des Sicherheitskontexts und der Anmeldeinformationen, 

die zum Verwalten von Netzwerkressourcen, Durchführen von Verwaltungsaufgaben oder 

Zugreifen auf Objekte in Active Directory benötigt werden. 

Mithilfe von Autorisierungsdaten, die in der Sicherheitsbeschreibung der einzelnen Objekte gespeichert 

sind, wird die Sicherheit auf eine Netzwerkressource oder ein Active Directory-Objekt angewendet. 

Die Sicherheitsbeschreibung umfasst die folgenden Komponenten: 

• Objektbesitzer Die SID für den aktuellen Besitzer des Objekts. Der Besitzer ist üblicherweise der 

Ersteller des Objekts oder ein Sicherheitsprinzipal, der den Besitz eines Objekts übernommen hat. 

• Primäre Gruppe Die SID für die primäre Gruppe des aktuellen Besitzers. Diese Information wird 

ausschließlich vom POSIX-Subsystem (Portable Operating System Interface for UNIX) verwendet. 

• Freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) Eine Liste mit 

Zugriffssteuerungseinträgen (Access Control Entries, ACEs), welche die Berechtigungen der verschiedenen 

Sicherheitsprinzipale für ein Objekt definieren. Jeder Sicherheitsprinzipal, der zur 

Zugriffssteuerungsliste hinzugefügt wird, erhält eine Reihe von Berechtigungen zum Festlegen, in 

welchem Umfang der Benutzer oder die Gruppe das Objekt bearbeiten darf. Benutzer, die nicht in 

einer ACE aufgeführt werden (entweder separat oder als Mitglied einer Gruppe) haben keinen 

Zugriff auf das Objekt.


• System-Zugriffssteuerungsliste (System Access Control List, SACL) Definiert die Überwachungseinstellungen 

für ein Objekt, u.a. welcher Sicherheitsprinzipal und welche Vorgänge überwacht 

werden sollen. 

Abbildung 9.1 zeigt die Architektur für das Zugriffstoken eines Benutzers und die Sicherheitsbeschreibung 

eines Objekts. Beim Versuch eines Benutzers, auf eine Netzwerkressource oder ein 

Active Directory-Objekt zuzugreifen, wird eine Zugriffsüberprüfung durchgeführt und jeder ACE 

wird untersucht, bis eine übereinstimmende Benutzer- oder Gruppen-SID ermittelt wird. Der Zugriff 

wird anschließend basierend auf den für den ACE konfigurierten Berechtigungen erteilt oder verweigert. 

Zugriffsüberprüfung 

Benutzerzugriffstoken 

Sicherheitsbeschreibung 

eines Objekts 

SID des Benutzers 

SIDs der Gruppe 

SID des Besitzers 

SID der 

primären Gruppe 

SACL 

ACE 

Liste mit 

Berechtigungen 

und weiteren 

Zugriffsinformationen 

ACE 

DACL 

ACE 

ACE 

ACE 

ACE 

Abbildung 9.1 

eines Objekts 

Zugriffsüberprüfung zwischen dem Zugriffstoken eines Benutzers und der Sicherheitsbeschreibung 

Auswerten von Verweigern- und Zulassen-ACEs in einer DACL 

ACEs werden innerhalb einer DACL mit einer bestimmten Reihenfolge aufgeführt. Dies wirkt sich 

direkt auf das Ergebnis der Zugriffsüberprüfung aus. Während einer Zugriffsüberprüfung werden die 

ACEs mit einer bestimmten Reihenfolge ausgewertet. Diese Auswertungsreihenfolge ist im Folgenden 

aufgeführt: 

• Explizit zugewiesene ACEs werden vor vererbten ACEs ausgewertet. 

• Innerhalb einer Gruppe aus expliziten oder vererbten ACEs werden Verweigern-ACEs immer vor 

Zulassen-ACEs ausgewertet. 

Abbildung 9.2 zeigt, wie Berechtigungen zum Zulassen oder Verweigern von Zugriff für explizite und 

vererbte ACEs ausgewertet werden.

Active Directory-Objektberechtigungen 323 

Sicherheitsbeschreibung 

eines Objekts 

DACL 

Verweigern-ACE 1 (Explizit) 

Verweigern-ACE 2 (Explizit) 

Zulassen-ACE 1 (Explizit) 

Zulassen-ACE 2 (Explizit) 

Verweigern-ACE 1 (Vererbt) 

Verweigern-ACE 2 (Vererbt) 

Zulassen-ACE 1 (Vererbt) 

Zulassen-ACE 2 (Vererbt) 

Abbildung 9.2 

Auswerten von Zulassen- und Verweigern-ACEs 

Active Directory-Objektberechtigungen 

Da sämtliche Objekte in Active Directory über eine ACL verfügen, können die Berechtigungen für 

die einzelnen Objekte geändert werden. Dies umfasst Objekte, die über die Tools Active Directory- 

Benutzer und -Computer, Active Directory-Standorte und -Dienste, ADSI-Editor oder Ldp.exe angezeigt 

werden. Das am häufigsten zum Bearbeiten des Active Directory-Objektzugriffs verwendete 

Tool ist Active Directory-Benutzer und -Computer. Es kann jedoch jedes der oben genannten Tools 

verwendet werden, um die gängige Aufgabe der Objektzugriffsverwaltung innerhalb des Verzeichnisdiensts 

auszuführen. 

Die Zugriffssteuerungsberechtigungen für Active Directory-Objekte lassen sich in zwei Kategorien 

gliedern: Standardberechtigungen und spezielle Berechtigungen. Spezielle Berechtigungen sind genau 

abgestimmte Optionen, die sich auf ein Objekt anwenden lassen. Eine Standardberechtigung umfasst 

eine Gruppe spezieller Berechtigungen, um eine bestimmte Funktion zuzulassen oder zu verweigern. 

Die Standardberechtigung Lesen umfasst beispielsweise die speziellen Berechtigungseinträge Berechtigungen 

lesen, Inhalt auflisten und Alle Eigenschaften lesen. 

Standardberechtigungen 

Zum Anzeigen der Standardberechtigungen für ein Active Directory-Objekt in der Domänenverzeichnispartition 

öffnen Sie in der Konsole Active Directory-Benutzer und -Computer im Eigenschaftenfenster 

für das Objekt die Registerkarte Sicherheit. 

Hinweis Wenn die Registerkarte Sicherheit nicht angezeigt wird, wählen Sie im Menü Ansicht den Eintrag 

Erweiterte Features 

Auf der Seite Sicherheit werden die Gruppen- oder Benutzernamen angezeigt, denen für das Objekt 

Berechtigungen zugewiesen wurden. Bei Auswahl eines Gruppen- oder Benutzereintrags werden die 

verknüpften zugelassenen oder verweigerten Berechtigungen angezeigt.


Abbildung 9.3 zeigt die Berechtigungen für die Gruppe Domänen-Admins in der OU Vertrieb. Beachten 

Sie, dass das Kontrollkästchen Zulassen per Voreinstellung für sämtliche Berechtigungen aktiviert 

ist, sodass die Gruppe Domänen-Admins für die OU Vertrieb über Vollzugriff verfügt. 

Abbildung 9.3 

Anzeigen der Seite Sicherheit für ein OU-Objekt 

Abhängig davon, welcher Objekttyp geschützt werden soll, werden auf der Seite Sicherheit unterschiedliche 

Berechtigungen angezeigt. Die folgenden Standardberechtigungen gelten beispielsweise 

für sämtliche Objekte: 

• Vollzugriff 

• Lesen 

• Schreiben 

• Alle untergeordneten Objekte erstellen 

• Alle untergeordneten Objekte löschen 

Einige Active Directory-Objekte verfügen zudem über Standardberechtigungen, die auf gruppierte 

Eigenschaftensätze angewendet werden. Ein Benutzerobjekt verfügt beispielsweise über mehrere 

Eigenschaftensätze mit Lese- und Schreibberechtigung, z.B. für allgemeine Informationen, persönliche 

Informationen, Telefon- und Postoptionen sowie Webinformationen. Da sich jeder dieser Eigenschaftensätze 

auf einen Satz an Objektattributen bezieht, wird beim Erteilen von Zugriff auf eine 

einzige Eigenschaft der Zugriff auf einen Satz an Attributen zugelassen. Der Eigenschaftensatz für 

persönliche Informationen umfasst beispielsweise Attribute wie homePhone, homePostalAddress und 

streetAddress. Die Verwendung von Eigenschaftensätzen zum Zuweisen von Zugriff auf Attributgruppen 

vereinfacht die Zuweisung von Berechtigungen, ohne dass Optionen auf detaillierter Attributebene 

geändert werden müssen.


Hinweis Das Active Directory-Schema definiert über den Wert rightsGuid für die Eigenschaftenkategorie 

(in der Konfigurationsverzeichnispartition) und den Wert attributeSecurityGUID für das schema-Objekt, 

welche Attribute Teil der verschiedenen Eigenschaftensätze sind. Der rightsGuid-Wert für cn=Personal-Information, 

cn=Extended-Rights, cn=configuration, dc=forestname entspricht beispielsweise dem attributeSecurityGUID-Wert 

für cn=Telephone-Number, cn=Schema, cn=Configuration, dc=forestname. Dies bedeutet, 

dass die Telefonnummer im Eigenschaftensatz Persönliche Informationen enthalten ist. 

Zusätzlich zu den Standardberechtigungen werden auf der Seite Sicherheit möglicherweise auch 

erweiterte Berechtigungen im Zusammenhang mit dem Objekt angezeigt, das geschützt wird. Abhängig 

vom Objekt können diese Berechtigungen Optionen wie z.B. Authentifizierung zulassen, Richtlinienergebnissatz 

erstellen, Empfangen als, Senden als, Senden an, Kennwort ändern und Kennwort 

zurücksetzen umfassen. 

Spezielle Berechtigungen 

Die Berechtigungsliste auf der Seite Sicherheit umfasst u.a. den Eintrag Spezielle Berechtigungen. 

Neben den Standardberechtigungen können für Active Directory-Objekte auch spezielle Berechtigungen 

zugewiesen werden. 

Hinweis Anhand der Kontrollkästchen Zulassen und Verweigern neben dem Eintrag Spezielle Berechtigungen 

lässt sich ermitteln, ob für ein Objekt spezielle Berechtigungen festgelegt wurden. Bei aktiviertem 

Kontrollkästchen wurden spezielle Berechtigungen zugewiesen. 

Wie bereits erwähnt, sind spezielle Berechtigungen deutlich genauer abgestimmt und spezifischer als 

Standardberechtigungen. Für eine vereinfachte Verwaltung verwenden Sie für ein Objekt typischerweise 

die Standardberechtigungen; möglicherweise müssen jedoch bestimmte Anforderungen erfüllt 

werden, aufgrund derer die Einträge der speziellen Berechtigungen geändert werden müssen. 

Für den Zugriff auf spezielle Berechtigungen klicken Sie auf der Seite Sicherheit auf Erweitert und 

stellen dann sicher, dass die Registerkarte Berechtigungen ausgewählt ist. Diese Seite ist in 

Abbildung 9.4 gezeigt. In Tabelle 9.2 sind die verfügbaren Optionen auf der Seite Berechtigungen 

erläutert. 

Tabelle 9.2 

Option 

Typ 

Name 

Berechtigung 

Geerbt von 

Konfigurieren von speziellen Berechtigungen 

Erläuterung 

Dieser Wert ist entweder auf Zulassen oder auf Verweigern gesetzt. Normalerweise sind die 

Berechtigungen so sortiert, dass zunächst sämtliche Berechtigungen mit dem Wert Verweigern 

aufgeführt sind. Diese Sortierreihenfolge lässt sich jedoch ändern, indem Sie auf eine 

Spaltenüberschrift klicken. Unabhängig von der Anzeigereihenfolge in dieser Spalte werden 

die Berechtigungen mit dem Wert Verweigern immer zuerst ausgewertet. 

Dies ist der Name des Sicherheitsprinzipals, für den die einzelnen ACEs gelten. 

In dieser Spalte wird der Berechtigungsumfang für den Sicherheitsprinzipal 

aufgeführt. Dabei kann es sich um Standardberechtigungen wie Vollzugriff, um spezielle Berechtigungen 

zum Erstellen/Löschen von Benutzerobjekten oder einfach um den Berechtigungseintrag 

Speziell handeln. Die verfügbaren Berechtigungstypen hängen vom Objekttyp 

und davon ab, wie detailliert der Berechtigungseintrag ist. 

In dieser Spalte wird der Speicherort angezeigt, an dem diese Berechtigung festgelegt ist, 

sowie die Information, ob die Berechtigung von einem übergeordneten Container geerbt 

wurde oder nicht.


Tabelle 9.2 

Konfigurieren von speziellen Berechtigungen (Fortsetzung) 

Option 

Anwenden auf 

Vererbbare Berechtigungen 

des übergeordneten Objektes 

einschließen 

Hinzufügen/Bearbeiten/ 

Entfernen 

Erläuterung 

In dieser Spalte wird angegeben, auf welcher Ebene diese Berechtigung angewendet wird. 

Es sind diverse Einstellungen möglich, u.a. Nur dieses Objekt, Dieses und alle untergeordneten 

Objekte, Alle untergeordneten Objekte sowie eine Vielzahl weiterer Einstellungen. 

Über diese Option kann angegeben werden, ob übergeordnete Berechtigungseinträge auf 

das Objekt angewendet werden sollen. 

Über diese Schaltflächen können neue ACEs hinzugefügt, vorhandene ACEs entfernt oder 

bestimmte ACEs bearbeitet werden, um detailliertere Berechtigungseinstellungen festzulegen. 

Abbildung 9.4 

Anzeigen der erweiterten Sicherheitseinstellungen für ein Objekt 

Hinweis Über die Schaltfläche Standard wiederherstellen auf der Seite Berechtigungen werden die 

Berechtigungen für das Objekt auf die Standardberechtigungseinstellungen zurückgesetzt, wie in den Einstellungen 

Standardsicherheit der Objektklasse im Active Directory-Schema angegeben. 

Häufig sind dieselben Sicherheitsprinzipale in mehreren ACEs aufgelistet. Die Gruppe Konten-Operatoren 

verfügt beispielsweise über mehrere Einträge Erstellen/Löschen für Computer-, Gruppen-, 

Benutzer-, Drucker- und InetOrgPerson-Objekte in verschiedenen ACEs. Dieser Fall tritt immer dann 

ein, wenn eine Kombination aus Berechtigungen angegeben wird, die nicht innerhalb eines einzigen 

ACE gespeichert werden können. In diesem Beispiel kann der Schwerpunkt der einzelnen ACEs 

lediglich auf einem Objekttyp (Computer, Benutzer usw.) liegen, die Zusammenfassung zu einem 

einzigen ACE ist nicht möglich.


Beim Hinzufügen oder Bearbeiten der Berechtigungen für einen Sicherheitsprinzipal sind zwei Optionen 

zum Anwenden von Berechtigungen verfügbar. Abbildung 9.5 zeigt die erste Option, bei der 

Berechtigungen auf ein Objekt angewendet werden. 

Abbildung 9.5 

Zuweisen von speziellen Berechtigungen zu Active Directory-Objekten 

Über die Registerkarte Objekt werden Berechtigungen auf verschiedene Objektebenen angewendet: 

• Nur dieses Objekt Berechtigungen werden ausschließlich auf das Objekt angewendet, das gegenwärtig 

geschützt oder bearbeitet wird. 

• Dieses und alle untergeordneten Objekte Berechtigungen werden sowohl auf das Objekt, das 

gegenwärtig geschützt wird, als auch auf alle untergeordneten Objekte innerhalb dieses Objekts 

angewendet. 

• Alle untergeordneten Objekte Berechtigungen werden ausschließlich auf die untergeordneten 

Objekte innerhalb des Objekts angewendet, das gegenwärtig bearbeitet wird. 

• Einzelne untergeordnete Objekte Windows Server 2008 bietet eine umfangreiche Auswahl an einzelnen 

untergeordneten Objekten, die sich detailliert schützen lassen. Wenn beispielsweise auf 

OU-Ebene Berechtigungen zugewiesen werden, können Sie festlegen, dass Berechtigungen ausschließlich 

auf Computerobjekte innerhalb der OU Vertrieb angewendet werden. Über diese 

Optionen lassen sich Berechtigungen auf fein abgestufter Objektebene delegieren. 

Die zweite Option zum Anwenden von Berechtigungen wird verwendet, um den Zugriff auf die 

Objekteigenschaften zu steuern. Dieses Fenster ist in Abbildung 9.6 gezeigt. 

Auf der Seite Eigenschaften werden Berechtigungen für den im Feld Name aufgeführten Sicherheitsprinzipal 

auf die einzelnen Eigenschaften für das Objekt angewendet. Beim Anwenden von Berechtigungen 

auf ein Benutzerobjekt haben Sie z.B. die Möglichkeit, die Berechtigungen Lesen und 

Schreiben auf jedes für die Ojektklasse verfügbare Attribut anzuwenden. Dazu zählen beispielsweise 

Allgemeine Informationen, Gruppenmitgliedschaft und Persönliche Informationen.


Abbildung 9.6 

Konfigurieren von Eigenschaftenberechtigungen für ein Objekt 

So funktioniert es: Anzeigen des ACE mithilfe von Ldp.exe 

Bei Ldp.exe handelt es sich um ein GUI-Tool (Graphical User Interface, grafische Benutzeroberfläche) 

zum Durchführen von verschiedenen Vorgängen für einen LDAP-kompatiblen Verzeichnisdienst. 

Dazu zählen z.B. Vorgänge wie das Verbinden, Binden, Bearbeiten, Hinzufügen oder 

Löschen von Elementen sowie das Suchen nach Objekten. LDP kann zum Anzeigen von erweiterten 

Active Directory-Metadaten wie beispielsweise Sicherheitsbeschreibungen und Replikationsmetadaten 

verwendet werden. 

So zeigen Sie eine ACL mithilfe von Ldp.exe an: 

1. Öffnen Sie das Dialogfeld Ausführen, geben Sie ldp ein, und drücken Sie anschließend die 

EINGABETASTE. 

2. Klicken Sie auf das Menü Remotedesktopverbindung und anschließend auf Verbinden. 

Wenn das Serverfeld nicht ausgefüllt wird, stellt der Server eine Verbindung mit dem lokalen 

Computer her. Sie können auch den Servernamen eingeben. 

3. Nachdem die Verbindung mit dem Server hergestellt wurde, klicken Sie auf das Menü Remotedesktopverbindung 

und anschließend auf Gebunden. Wenn Sie nicht über ein Benutzerkonto 

mit Administratorrechten angemeldet sind, geben Sie alternative Anmeldeinformationen an. 

Anderenfalls lassen Sie das Feld für die Anmeldeinformationen leer. 

4. Nach dem Herstellen einer Bindung mit der Domäne klicken Sie auf das Menü Ansicht und 

anschließend auf Struktur. 

5. Zum Anzeigen der gesamten Domäne klicken Sie auf OK. Die OU-Struktur der Domäne wird 

im linken Fensterbereich angezeigt. 

Um die ACL für ein beliebiges Objekt anzuzeigen, wechseln Sie im linken Fenster in der Strukturansicht 

zu diesem Objekt. Klicken Sie mit der rechten Maustaste auf das Objekt, zeigen Sie auf 

Schwer, klicken Sie auf Sicherheitsbeschreibung und schließlich auf OK.


Wie in Abbildung 9.7 gezeigt, sind eine Reihe von erweiterten Optionen verfügbar. Beispielsweise 

können DACL- und SACL-Berechtigungen geändert oder SD-Steuerungen (Security Descriptor, 

Sicherheitsbeschreibung) bearbeitet werden – wie z.B. der DACL- und SACL-Schutz. 

Abbildung 9.7 

Verwenden von Ldp.exe zum Ändern der Sicherheitsbeschreibung 

Beim Hinzufügen oder Bearbeiten eines ACEs mithilfe von Ldp.exe können bestimmte Berechtigungen 

und ACE-Flags für verschiedene Objekttypen geändert und die Objektvererbung festgelegt 

werden. Abbildung 9.8 zeigt den mit Ldp.exe bereitgestellten ACE-Editor. 

Abbildung 9.8 

Bearbeiten eines ACEs mithilfe von Ldp.exe


Berechtigungsvererbung 

In den AD DS wird ein statisches Berechtigungsvererbungsmodell verwendet. Das heißt, dass beim 

Ändern von Berechtigungen für ein Containerobjekt in der Active Directory-Struktur die Änderungen 

berechnet und auf die Sicherheitsbeschreibung für alle Objekte innerhalb des Containers angewendet 

werden. Folglich kann die Berechnung der neuen ACL für jedes Objekt prozessorintensiv sein, wenn 

Berechtigungen auf höherer Ebene in der Active Directory-Struktur geändert und diese Berechtigungen 

auf sämtliche untergeordneten Objekte angewendet werden. Dieser anfängliche Aufwand 

bedeutet jedoch, dass die Berechtigungen beim Versuch eines Benutzers oder Prozesses, auf das 

Objekt zuzugreifen, nicht neu berechnet werden müssen. 

Zum Steuern der Vererbung von Berechtigungen werden zwei Hauptmethoden verwendet: 

• Konfigurieren von vererbbaren Berechtigungen für das Objekt Beim Erstellen eines Objekts in 

Active Directory werden standardmäßig vererbbare Berechtigungen aus dem übergeordneten 

Objekt eingeschlossen. Anhand des Kontrollkästchens auf der Seite Sicherheit oder der Spalte 

Geerbt von im Fenster Erweiterte Sicherheitseinstellungen lässt sich ermitteln, ob ein Berechtigungseintrag 

vererbt wird. 

• Konfigurieren des Umfangs für die Anwendung von Berechtigungen Wie bereits erwähnt, besteht 

eine weitere Möglichkeit zum Steuern der Vererbung darin anzugeben, wie Berechtigungen beim 

Anwenden von Sicherheit auf ein Objekt auf die untergeordneten Objekte angewendet werden. 

Beim manuellen Hinzufügen eines neuen Gruppen- oder Benutzernamens zum ACE verfügt der 

Eintrag standardmäßig über Berechtigungen, die nur für dieses eine Objekt gelten. Um die Vererbung 

auf ein untergeordnetes Objekt zu erzwingen, muss der Umfang so geändert werden, dass 

die Berechtigungen zusätzlich zum aktuellen Objekt auch auf untergeordnete Objekte angewendet 

werden. 

Hinweis Bei Verwendung des Assistenten zum Zuweisen der Objektverwaltung wird die Vererbung automatisch 

auf Dieses und alle untergeordneten Objekte gesetzt. Weitere Informationen zu diesem Assistenten 

finden Sie im Abschnitt „Delegieren von Verwaltungsaufgaben“ weiter unten in diesem Kapitel. 

Wenn Sie Ihre OU-Struktur für die delegierte Verwaltung entworfen haben, verfügen Sie über eine 

OU-Struktur, in der den Administratoren auf höchster Ebene, die Berechtigungen für sämtliche Active 

Directory-Objekte benötigen, auf einer hohen Hierarchieebene Rechte mit delegierten Berechtigungen 

für alle untergeordneten Objekte zugewiesen werden. Auf niedrigeren Hierarchieebenen können 

Berechtigungen an andere Administratoren delegiert werden, die lediglich zum Verwalten eines 

kleineren Bereichs der Domäne berechtigt sein sollen. In Abbildung 9.9 ist beispielsweise die OU 

Vertrieb gezeigt. Die OU Vertrieb verfügt über zwei untergeordnete OUs Vertrieb_Ost und Vertrieb_ 

West. An den für die gesamte Vertriebsabteilung verantwortlichen Abteilungsleiter können Berechtigungen 

für die gesamte OU Vertrieb mit allen untergeordneten Objekten delegiert werden, während 

an die Abteilungsleiter der Bereiche Vertrieb_Ost und Vertrieb_West lediglich Berechtigungen für ihre 

jeweilige OU delegiert werden.


Abbildung 9.9 

Delegieren der Verwaltung für die OU Vertrieb 

In einigen Fällen kann es jedoch sinnvoll oder erforderlich sein, die Administratorrechte für Administratoren 

auf höheren Ebenen für eine bestimmte untergeordnete OU zu deaktivieren. Wenn beispielsweise 

eine untergeordnete OU für eine Zweigstelle eines Unternehmens erstellt wird, kann einer lokalen 

Administratorgruppe Vollzugriff auf diese OU zugewiesen werden. Möglicherweise sollen diese 

lokalen Administratoren jedoch nicht auf Benutzerkonten von leitenden Angestellten in der OU 

zugreifen können. Zum Beschränken des Zugriffs kann innerhalb der OU für die Zweigstelle eine OU 

Leitende Angestellte erstellt und die Option zum Einschließen von vererbbaren Berechtigungen des 

übergeordneten Objekts deaktiviert werden. Dies verhindert die Berechtigungsvererbung auf Ebene 

der OU Leitende Angestellte. 

Zum Deaktivieren der Vererbung von Berechtigungen für ein Active Directory-Objekt öffnen Sie das 

in Abbildung 9.4 gezeigte Dialogfeld Erweiterte Sicherheitseinstellungen für das Objekt. Deaktivieren 

Sie die Option Vererbbare Berechtigungen des übergeordneten Objektes einschließen. Wenn Sie 

diese Option deaktivieren, können Sie die vorhandenen Berechtigungen kopieren oder sämtliche 

Berechtigungen entfernen, bevor Sie explizit neue Berechtigungen zuweisen (wie in Abbildung 9.10 

gezeigt). 

Abbildung 9.10 Auswählen der Option zum Kopieren oder Entfernen von Berechtigungen beim Deaktivieren der 

Berechtigungsvererbung


Das Deaktivieren der Vererbung hat folgende Auswirkungen: 

• Die Berechtigungen werden für das Objekt und alle untergeordneten Objekte deaktiviert. Dies 

bedeutet, dass es nicht möglich ist, die Berechtigungsvererbung auf einer Containerebene zu deaktivieren 

und die Vererbung von einem höheren Container anschließend auf einer niedrigeren 

Ebene erneut anzuwenden. 

• Auch wenn die Berechtigungen vor dem Ändern kopiert werden, beginnt die Berechtigungsvererbung 

auf der Ebene, auf der die Berechtigungen deaktiviert werden. Wenn die Berechtigungen auf 

einer höheren Ebene geändert werden, werden sie nicht weiter als bis zur Ebene der deaktivierten 

Berechtigungen vererbt. 

• Es kann nicht ausgewählt werden, welche Berechtigungen deaktiviert werden. Beim Deaktivieren 

von Berechtigungen werden alle vererbten Berechtigungen deaktiviert. Berechtigungen, die dem 

Objekt oder untergeordneten Objekten explizit zugewiesen wurden, werden nicht deaktiviert. 

Hinweis Eine der möglichen Bedenken beim Deaktivieren von vererbten Berechtigungen ist, dass möglicherweise 

ein verwaistes Objekt erstellt wird, für das kein Benutzer über Berechtigungen verfügt. Sie können 

beispielsweise eine OU erstellen, die Berechtigungsvererbung für diese OU vollständig deaktivieren und 

die Berechtigungen einer einzigen Administratorengruppe zuweisen. Sogar die Gruppe Domänen-Admins 

kann aus der ACL der OU entfernt werden, sodass die Mitglieder dieser Gruppe unter normalen Bedingungen 

über keine Berechtigungen verfügen. Wenn diese Administratorengruppe gelöscht wird, gibt es für 

die OU keine Gruppe mit Verwaltungsberechtigungen. In diesem Fall müsste die Gruppe Domänen-Admins 

den Besitz des Objekts übernehmen und Berechtigungen neu zuweisen. 

Direkt von der Quelle: Delegieren der Verwaltung für ein OU-Modell 

Es gibt verschiedene Meinungen dazu, wie ein OU-Modell entworfen und die Delegierung innerhalb 

des Modells durchgeführt werden sollte. Die gängigsten Ausgangspunkte für ein OU-Modell 

basieren auf Geschäftsfunktion, Geografie oder einer Kombination dieser beiden Faktoren. Ein 

Delegierungsmodell kann zentral, dezentral oder zentral mit dezentraler Ausführung aufgebaut 

sein. Der Aufbau hängt letztendlich jedoch davon ab, wie ein Kunde operativen Support bereitstellen 

möchte. 

Wenn die Delegierung in Betracht gezogen wird, befindet sich eine Organisation an einem von 

zwei Punkten innerhalb des Active Directory-Lebenszyklus: entweder wird die Migration auf 

Active Directory in Erwägung gezogen, oder die Migration auf Active Directory wurde bereits 

durchgeführt und nun bietet sich die Möglichkeit, frühere Entscheidungen zu überdenken, um eine 

effektivere und effizientere Umgebung bereitzustellen. 

Wenn Sie die Migration auf Active Directory in Betracht ziehen, sollten Sie sich so früh und häufig 

wie möglich mit dem Kunden besprechen. Ein Verständnis davon, wie Kunden ihre Geschäfte 

abwickeln, ist bei der Entwicklung einer funktionierenden und effizienten Infrastruktur entscheidend. 

Wenn Sie als Mitarbeiter eines Unternehmens mit der Migration der Umgebung auf Active 

Directory beauftragt wurden, gilt dieser Rat ebenso: besprechen Sie sich so früh und häufig wie 

möglich mit der oberen Führungsebene, um ein besseres Verständnis davon zu erlangen, wie die 

Geschäftsabwicklung aussehen soll. Berücksichtigen Sie bei der Entscheidung, wie die Lösung 

aufgebaut werden soll, dass Active Directory aufgrund der äußerst großen Flexibilität eine unbegrenzte 

Granularität (Tiefe) und einen uneingeschränkten Umfang (Breite) bieten kann.


Es könnten Gruppen für jede vorstellbare Rolle (Tiefe) und Gruppen zur Abdeckung jedes 

Umfangs (Breite) definiert werden. Dies würde zu einer Umgebung führen, die sich nur schwer 

verwalten ließe. Es gibt ein ausgewogenes Gleichgewicht zwischen Tiefe und Breite, das für jeden 

Kunden unterschiedlich sein kann. Faktoren wie die Anzahl an Standorten und das Supportpersonal 

sind äußerst wichtig, um ein effektives Delegierungsmodell zu entwerfen. Aus diesem Grund 

sind von Anfang an häufige Treffen zu Planung und Entwurf mit dem Kunden oder der oberen 

Führungsebene erforderlich, um eindeutig zu klären, wie der operative Support bereitgestellt werden 

soll. 

Wenn Sie bereits über eine Active Directory-Umgebung verfügen und das vorhandene Delegierungsmodell 

überdenken können, sollten Sie untersuchen, wie der operative Support gegenwärtig 

verwaltet wird. Möglicherweise lassen sich die Abläufe durch eine Verringerung von Tiefe und 

Breite des aktuellen Modells optimieren. Meine Erfahrungen haben gezeigt, dass im Zusammenhang 

mit dem operativen Support weniger manchmal mehr ist. 

Und schließlich ist die Kommunikation entscheidend, um wirklich effektiv zu sein und die Erwartungen 

des Kunden oder der oberen Führungsebene zu erfüllen. Ich war an vielen Kundengesprächen 

beteiligt, in denen IT-Experten Themen wie die Delegierung innerhalb von Active Directory 

mit dem Kunden oder der oberen Führungsebene besprochen haben, und die verwendete Terminologie 

hat auf beiden Seiten zu Frustration geführt. Bevor Sie mit technischen Diskussionen beginnen, 

sollten Sie sich daher Gedanken zu den folgenden Themen machen: 

• An wen richten sich die Informationen? Ihre Zielgruppe kann abhängig davon variieren, ob es 

sich um ein Meeting handelt, oder ob Sie ein Whitepaper oder ein Angebot schreiben. 

• Wie lassen sich Kenntnisse und Wissen an die Zielgruppe vermitteln? Nehmen Sie sich ein paar 

Minuten, um Ihre Strategie zur Vermittlung der Informationen durchzugehen. Gibt es Wörter, 

Sätze oder Themen, die abhängig von der Zielgruppe eine unterschiedliche Bedeutung haben? 

• Versuchen Sie, zwei oder drei verschiedene Strategien für die Diskussion zu entwickeln. Der Einsatz 

von Analogien ist eine hervorragende Methode, um eine Diskussion weniger technisch zu 

gestalten und das Thema in einem Kontext zu vermitteln, den auch die meisten Zuhörer ohne IT- 

Kenntnisse verstehen. 

Barry Hartman 

Senior Consultant 

Microsoft Consulting Services 

Effektive Berechtigungen 

Wie bereits in diesem Kapitel beschrieben, können einem Benutzer Berechtigungen für ein bestimmtes 

Objekt in Active Directory über verschiedene Methoden zugewiesen werden: 

• Dem Benutzerkonto werden ausdrückliche Berechtigungen für ein Objekt zugewiesen. 

• Eine oder mehrere Gruppen, zu denen der Benutzer gehört, erhalten ausdrückliche Berechtigungen 

für ein Objekt. 

• Dem Benutzerkonto oder einer oder mehrerer Gruppen, zu denen der Benutzer gehört, werden 

Berechtigungen auf Containerobjektebene zugewiesen, und Berechtigungen werden von Objekten 

auf niedrigeren Ebenen geerbt.


All diese Berechtigungen sind kumulativ; das heißt, dass der Benutzer den größten Berechtigungsumfang 

aus all diesen Konfigurationen erhält. Wenn einem Benutzer beispielsweise explizit die Berechtigung 

Lesen für ein Objekt zugewiesen wird, der Benutzer zu einer Gruppe mit ausdrücklicher Berechtigung 

Ändern und zu einer Gruppe mit Vollzugriff auf Containerebene gehört, verfügt der Benutzer 

über die Berechtigung Vollzugriff. Beim Versuch eines Benutzers, auf ein Objekt zuzugreifen, untersucht 

das Sicherheitssubsystem sämtliche ACEs, die an das Objekt angefügt sind. Alle ACEs, die für 

den Sicherheitsprinzipal gelten (basierend auf Benutzerkonto oder Gruppen-SIDs) werden ausgewertet, 

und die höchste Berechtigungsebene wird festgelegt. Zusätzlich zu ACEs zum Erteilen von 

Berechtigungen unterstützt Active Directory jedoch auch verweigernde Berechtigungen. Verweigernde 

Berechtigungen können auf zwei Ebenen angewendet werden: 

• Dem Benutzerobjekt oder einer oder mehreren Gruppen, zu denen der Benutzer gehört, kann die 

Berechtigung für ein Objekt ausdrücklich verweigert werden. 

• Dem Benutzerobjekt oder einer oder mehreren Gruppen, zu denen der Benutzer gehört, können 

Berechtigungen auf Containerebene verweigert werden, und diese Verweigerung kann an Objekte 

auf niedrigeren Ebenen vererbt werden. 

Verweigernde Berechtigungen setzen zulassende Berechtigungen fast immer außer Kraft. Wenn ein 

Benutzer beispielsweise Mitglied einer Gruppe mit der Berechtigung Berechtigungen ändern für ein 

Active Directory-Objekt ist, dem Benutzer diese Berechtigung jedoch ausdrücklich verweigert wurde, 

kann der Benutzer das Objekt nicht bearbeiten. Der Grund dafür ist, dass ACEs zum Verweigern von 

Berechtigungen vor ACEs zum Zulassen von Berechtigungen ausgewertet werden. Wenn die Berechtigung 

für den Sicherheitsprinzipal durch einen ACE verweigert wird, werden keine weiteren ACEs 

für das Objekt ausgewertet. 

In einer einzigen Situation setzen zulassende Berechtigungen verweigernde Berechtigungen außer 

Kraft: wenn die verweigernden Berechtigungen geerbt und die zulassenden Berechtigungen ausdrücklich 

zugewiesen wurden. So kann einem Benutzer beispielsweise die Berechtigung zum Ändern von 

Benutzerkonten in einem Container verweigert werden. Wenn für ein Objekt innerhalb des Containers 

jedoch ausdrücklich die Berechtigung Berechtigungen ändern erteilt wird, verfügt das Benutzerkonto 

für dieses Objekt über die Berechtigung Berechtigungen ändern. 

Verwenden Sie verweigernde Berechtigungen mit Bedacht: 

Die Verwendung der Option Verweigern zum Verweigern von Berechtigungen kann zur Folge 

haben, dass sich die Active Directory-Sicherheitsstruktur nur sehr schwer verwalten lässt. Es sind 

eine Reihe verschiedener Szenarien möglich, in denen Sie möglicherweise die Verwendung der 

Berechtigung Verweigern in Betracht ziehen. Möglicherweise erwägen Sie die Verwendung der 

Option Verweigern z.B., um einige Berechtigungen zu entfernen, die vererbt werden. Beispiel: Sie 

erteilen die Berechtigung Berechtigungen ändern auf Containerebene, möchten diese Einstellung 

auf einer niedrigeren Hierarchieebene jedoch in Berechtigungen lesen ändern. In diesem Fall 

könnten Sie die Schreibberechtigung für Objekte und Eigenschaften auf einer niedrigeren Hierarchieebene 

verweigern. 

Ein weiteres Szenario, in dem die Verwendung der Option Verweigern denkbar ist, besteht, wenn 

Sie einen Container erstellen, für den eine höhere Sicherheitsstufe erforderlich ist. Beispielsweise 

verfügen Sie möglicherweise über einen Container für alle leitenden Angestellten und möchten 

sicherstellen, dass ein normaler Benutzer die Kontoeigenschaften dieser Mitarbeiter nicht lesen 

kann. Sie könnten die Berechtigung Berechtigungen lesen unter Verwendung der Gruppe Domänen-Benutzer 

für den Container verweigern.


Unglücklicherweise wird dadurch sämtlichen Benutzern die Leseberechtigung für die Verzeichnisobjekte 

verweigert, einschließlich aller Administratoren. Aufgrund der Probleme, die bei Verwendung 

der Option Verweigern auftreten können, sollten Sie diese nur mit Bedacht verwenden. 

In den meisten Fällen kann einfach sichergestellt werden, dass ein Benutzer oder eine Gruppe nicht 

über bestimmte Berechtigungen verfügt, anstatt diese Berechtigungen zu verweigern. Wenn einem 

Benutzer keine Berechtigungen erteilt werden, und er kein Mitglied einer Gruppe mit Berechtigungen 

ist, verfügt der Benutzer nicht über Zugriffsrechte, da diese implizit verweigert werden. Es 

ist nicht erforderlich, die Berechtigung Verweigern ausdrücklich anzuwenden, um den Benutzerzugriff 

auf Objekte in Active Directory zu verhindern. 

Eine Situation, in der die Verwendung der Option Verweigern sinnvoll sein kann, ist, wenn einer 

Gruppe Berechtigungen zugewiesen werden sollen, jedoch mindestens ein Benutzer innerhalb dieser 

Gruppe über einen geringeren Berechtigungsumfang verfügen soll. Möglicherweise verfügen 

Sie z.B. über eine Gruppe Konten-Admins, die für die Verwaltung aller Benutzerkonten innerhalb 

der Domäne verantwortlich ist. Einige Mitglieder dieser Gruppe könnten temporäre Mitarbeiter 

sein, die zwar zur Verwaltung sämtlicher Benutzerkonten in der Domäne berechtigt sein müssen, 

jedoch keine Eigenschaften von Konten leitender Angestellter ändern dürfen. In diesem Fall 

könnten Sie der Gruppe Konten-Admins zunächst die Berechtigung zum Verwalten aller Benutzerkonten 

in der Domäne zuweisen. Anschließend erstellen Sie eine OU für die Konten der leitenden 

Angestellten sowie eine Gruppe für die temporären Mitglieder der Gruppe Konten-Admins. Dann 

verweigern Sie den temporären Benutzern die Berechtigung zum Ändern von Benutzerkonten in 

der OU der leitenden Angestellten. 

Wie Sie sehen, kann die Konfiguration der Sicherheit für Active Directory-Objekte die Verwaltung 

einer großen Anzahl von zusammenhängenden Variablen umfassen. Die meisten Unternehmen beginnen 

mit einem recht einfachen Sicherheitsentwurf, in dem eine kleine Gruppe von Administratoren 

über sämtliche Berechtigungen in Active Directory verfügt. In den meisten Fällen ist die ursprüngliche 

Active Directory-Sicherheitskonfiguration sorgfältig dokumentiert. Im Lauf der Zeit wird diese 

einfache Erstkonfiguration jedoch immer komplexer. Manchmal wird einer weiteren Gruppe von 

Administratoren einen Satz an Berechtigungen für eine bestimmte Aufgabe und für einen bestimmten 

Zeitraum zugewiesen. Berechtigungen lassen sich problemlos erteilen, werden häufig jedoch nie entfernt. 

Zudem werden diese nach der ursprünglichen Bereitstellung durchgeführten Änderungen an der 

Sicherheit zudem nicht sorgfältig dokumentiert. 

Bei einer Active Directory-Struktur, die bereits seit längerer Zeit bereitgestellt wird, ist die aktuelle 

Sicherheitskonfiguration wahrscheinlich komplexer als der ursprüngliche Entwurf. Manchmal führt 

dies dazu, dass Benutzer über mehr Berechtigungen verfügen als notwendig oder gewünscht. Doch 

glücklicherweise bietet Windows Server 2008 ein Tool, mit dessen Hilfe die effektiven Berechtigungen 

eines Sicherheitsprinzipals für sämtliche Objekte in Active Directory problemlos ermittelt 


Zum Ermitteln der effektiven Berechtigungen, über die ein Sicherheitsprinzipal für ein Active Directory-Objekt 

verfügt, greifen Sie über das entsprechende Active Directory-Verwaltungstool auf die 

Eigenschaften des Objekts zu. Klicken Sie auf der Seite Sicherheit auf Erweitert und anschließend auf 

die Seite Effektive Berechtigungen. Zum Ermitteln der effektiven Berechtigungen für ein bestimmtes 

Benutzer- oder Gruppenkonto klicken Sie auf Auswählen, und suchen Sie nach dem Benutzer- oder 

Gruppennamen.


Nach Auswahl des Namens klicken Sie auf OK. Auf der Seite Effektive Berechtigungen werden alle 

Berechtigungen angezeigt, über die der Sicherheitsprinzipal für das Active Directory-Objekt verfügt. 

Abbildung 9.11 zeigt die Oberfläche des Verwaltungstools Active Directory-Benutzer und -Computer. 

Beachten Sie, dass auf der Seite Effektive Berechtigungen für die OU Vertrieb sämtliche Berechtigungen 

angezeigt werden, die dem Benutzerobjekt Don Hall zugewiesen sind. 

Hinweis Dieses Tool ist mit einigen Einschränkungen verbunden, die sich auf die angezeigten effektiven 

Berechtigungen auswirken können. Die effektiven Berechtigungen werden basierend auf geerbten und explizit 

definierten Berechtigungen für das Benutzerkonto und die Gruppenmitgliedschaften des Benutzers ermittelt. 

Dem Benutzer werden möglicherweise jedoch auch abhängig davon Berechtigungen erteilt, wie er sich 

anmeldet und mit dem Objekt verbindet. In Windows Server 2008 können beispielsweise Berechtigungen zur 

interaktiven Gruppe (also allen am Computer angemeldeten Benutzern) oder zur Netzwerkanmeldegruppe 

(also allen Benutzern, die auf Informationen innerhalb des Netzwerks zugreifen) zugewiesen werden. Über 

das hier beschriebene Active Directory-Verwaltungstool können die einem Benutzer basierend auf diesen 

Gruppentypen erteilten Berechtigungen nicht ermittelt werden. Ferner kann das Tool Berechtigungen lediglich 

unter Verwendung der Berechtigungen des Benutzers ermitteln, der es ausführt. Wenn der Benutzer, der 

das Tool ausführt, beispielsweise nicht zum Lesen der Mitgliedschaft einiger Gruppen berechtigt ist, zu 

denen das ausgewertete Benutzerobjekt gehört, können die Berechtigungen nicht ordnungsgemäß ermittelt 

werden. 


Anzeigen der effektiven Berechtigungen für ein Active Directory-Objekt 

Besitz von Active Directory-Objekten 

Jedes Objekt in Active Directory verfügt über einen Besitzer. Standardmäßig ist der Benutzer, der ein 

Objekt erstellt, der Besitzer. Der Besitzer eines Objekts ist berechtigt, die Berechtigungen für das 

Objekt zu ändern. Dies bedeutet, dass der Besitzer auch ohne Vollzugriff für ein Objekt die Berechtigungen 

für das Objekt immer ändern kann.


In den meisten Fällen ist der Besitzer eines Objekts eher ein bestimmtes Benutzerkonto als ein Gruppenkonto. 

Eine Ausnahme ist die Erstellung eines Objekts durch ein Mitglied der Gruppe Domänen- 

Admins; in diesem Fall wird der Objektbesitz der Gruppe Domänen-Admins zugewiesen. Wenn der 

Besitzer des Objekts ein Mitglied der lokalen Administratorengruppe, jedoch kein Mitglied der 

Gruppe Domänen-Admins ist, wird der Besitz des Objekts der Gruppe Administratoren zugewiesen. 

Zum Ermitteln des Besitzers eines Active Directory-Objekts greifen Sie über das geeignete Active 

Directory-Verwaltungstool auf die Eigenschaften des Objekts zu. Klicken Sie auf der Seite Sicherheit 

auf Erweitert, und wählen Sie die Seite Besitzer. Abbildung 9.12 zeigt die Oberfläche des Verwaltungstools 

Active Directory-Benutzer und -Computer. 

Wenn Sie über die Berechtigung Besitzer ändern für das Objekt verfügen, können Sie auf dieser Seite 

den Objektbesitz ändern. Sie können den Besitz für Ihr eigenes Konto übernehmen oder einem anderen 

Benutzer bzw. einer anderen Gruppe zuweisen. Diese letzte Option ist nur in Windows Server 

2003 und Windows Server 2008 Active Directory verfügbar. In Microsoft Windows 2000 Active 

Directory konnte der Objektbesitz nur übernommen werden; es war nicht möglich, den Besitz einem 

anderen Sicherheitsprinzipal zuzuweisen. 


Anzeigen des Besitzes für ein Active Directory-Objekt 

Administratorrechte 

Die bisher erläuterten Administratorrechte hängen mit spezifischen Berechtigungen für Active 

Directory-Objekte zusammen und legen fest, welche Aktionen der Administrator für diese Objekte 

ausführen kann. Zusätzlich dazu können auch Benutzer zum Ausführen von einigen Aufgaben in 

Active Directory berechtigt sein. Die bisher besprochenen Berechtigungen basieren auf den ACLs, 

die mit jedem Active Directory-Objekt verknüpft sind. Benutzerberechtigungen unterscheiden sich 

von diesen Berechtigungen, da sie auf Benutzerkonten angewendet werden.


Ein Benutzer verfügt aufgrund seiner Identität über Benutzerberechtigungen, nicht weil er zum 

Ändern eines bestimmten Active Directory-Objekts berechtigt ist. Beispielsweise gibt es zwei 

Methoden, um einem Benutzer oder einer Gruppe die Berechtigung zum Hinzufügen von Arbeitsstationen 

zur Domäne zu erteilen. Dem Benutzer oder der Gruppe kann die Berechtigung zum 

Erstellen von Computerobjekten auf einer OU-Ebene oder auf Ebene des Containers Computers 

erteilt werden. Dies ermöglicht es dem Benutzer, eine beliebige Anzahl an Arbeitsstationen zur 

Domäne im angegebenen Container hinzuzufügen. 

Eine weitere Möglichkeit, um einem Benutzer das Hinzufügen von Arbeitsstationen zur Domäne 

zu ermöglichen, besteht darin sicherzustellen, dass der Benutzer über das Recht Hinzufügen von 

Arbeitsstationen zur Domäne verfügt. Dieses Benutzerrecht ist Teil der Standard-Domänencontrollerrichtlinie. 

Benutzer mit diesem Recht können bis zu zehn Arbeitsstationen zur Domäne hinzufügen. 

Standardmäßig wird der Gruppe Authentifizierte Benutzer dieses Recht zugewiesen. 

Delegieren von Verwaltungsaufgaben 

Bisher haben Sie in diesem Kapitel erfahren, wie die Sicherheit von Active Directory-Objekten 

gewährleistet werden kann. Diese Informationen dienen als Vorbereitung für diesen Abschnitt, in 

dem beschrieben wird, wie die Sicherheitsoptionen angewendet und Verwaltungsaufgaben delegiert 

werden. Da sämtliche Objekte in Active Directory über eine ACL verfügen, kann der Administratorzugriff 

für jede Eigenschaft eines Objekts gesteuert werden. So können Sie anderen Active Directory-Administratoren 

äußerst präzise Berechtigungen zuweisen, sodass diese lediglich die für ihren 

Verantwortungsbereich erforderlichen Aufgaben ausführen dürfen. 

Wenngleich sich Administratorrechte äußerst spezifisch delegieren lassen, sollten Sie darauf achten, 

dass die Komplexität dieser Einstellungen so gering wie möglich bleibt, während Sie gleichzeitig die 

Sicherheitsanforderungen der Organisation erfüllen. In den meisten Fällen werden Administratorrechte 

in Active Directory in einem der folgenden Szenarien delegiert: 

• Zuweisen von Vollzugriff für eine OU Dies ist ein recht gängiges Szenario, in dem eine Organisation 

über mehrere Zweigstellen mit lokalen Administratoren an jedem Standort verfügt, für welche 

die Verwaltung sämtlicher Objekte in der jeweiligen Zweigstelle erforderlich ist. Diese Option 

kann auch für Organisationen gewählt werden, in denen mehrere Ressourcendomänen in OUs in 

einer einzigen Active Directory-Domäne zusammengefasst wurden. Den Administratoren der vorherigen 

Ressourcendomäne kann Vollzugriff auf alle Objekte in ihrer spezifischen OU zugewiesen 

werden. Bei Verwendung dieser Option kann die Verwaltung einer Organisation praktisch 

vollständig dezentralisiert werden, während trotzdem eine einzige Domäne vorhanden ist. 

• Zuweisen von Vollzugriff für bestimmte Objekte in einer OU Dieses Szenario weicht leicht von dem 

vorherigen ab. In einigen Fällen kann eine Organisation über mehrere Zweigstellen verfügen, die 

lokalen Administratoren sollten jedoch lediglich zur Verwaltung bestimmter Objekte in der 

Zweigstellen-OU berechtigt sein. Möglicherweise soll einem lokalen Administrator z.B. die 

Berechtigung zum Verwalten aller Benutzer- und Gruppenobjekte, nicht jedoch von Computerobjekten 

zugewiesen werden. In einem Szenario, in dem Ressourcendomänen in OUs umgewandelt 

wurden, sollen OU-Administratoren möglicherweise alle Computerkonten und domänenlokalen 

Gruppen in ihrer OU, jedoch keine Benutzerobjekte verwalten können.

Delegieren von Verwaltungsaufgaben 339 

• Zuweisen von Vollzugriff für bestimmte Objekte in der gesamten Domäne Einigen Unternehmen 

implementieren eine höchst zentralisierte Benutzer- und Gruppenverwaltung, in der nur eine einzige 

Gruppe zum Hinzufügen und Löschen von Benutzer- und Gruppenkonten berechtigt ist. In 

diesem Szenario kann dieser Gruppe Vollzugriff für Benutzer- und Gruppenobjekte unabhängig 

davon erteilt werden, wo sich die Objekte innerhalb der Domäne befinden. Dies ist ferner ein 

recht gängiges Szenario für Organisationen mit zentraler Desktop- und Serververwaltungsgruppe. 

Den Mitgliedern der Desktopverwaltungsgruppe kann Vollzugriff auf alle Computerobjekte in der 

Domäne zugewiesen werden. 

• Zuweisen von Berechtigungen zum Ändern von bestimmten Objekteigenschaften In einigen Fällen 

kann es sinnvoll oder erforderlich sein, dass eine Administratorengruppe lediglich zum Verwalten 

bestimmter Objekteigenschaften berechtigt ist. Beispielsweise kann einer Administratorengruppe 

ausschließlich die Berechtigung zum Zurücksetzen von Kennwörtern für sämtliche Benutzerkonten 

zugewiesen werden, jedoch keine weiteren Administratorrechte. Oder den Mitarbeitern der 

Personalabteilung wird die Berechtigung zum Ändern der persönlichen und öffentlichen Informationen 

für alle Benutzerkonten innerhalb der Domäne zugewiesen, jedoch keine Berechtigung 

zum Erstellen oder Löschen von Benutzerkonten. 

Mit Windows Server 2008 AD DS können all diese Optionen separat verwendet bzw. beliebig kombiniert 

werden. Wie bereits erwähnt, ist eine Möglichkeit zum Konfigurieren von delegierten Berechtigungen 

der direkte Zugriff auf die ACL für ein Objekt, um die Berechtigungen zu konfigurieren. Aufgrund 

der Anzahl von verfügbaren Optionen und der Fehleranfälligkeit kann diese Option jedoch 

recht komplex werden. 

Direkt von der Quelle: Delegieren der Verwaltung 

Beim Delegieren der Berechtigungen zum Erstellen von Benutzern und Gruppen ist es unabdinglich, 

ein System zum Nachverfolgen von Änderungen zu implementieren. Dies vereinfacht nicht 

nur die tägliche Verwaltung, sondern ist zudem bei der Behandlung von Zugriffsproblemen äußerst 

hilfreich. 

Greg Robb 

Microsoft Premier Field Engineer 

Zum Vereinfachen dieser Aufgabe umfassen die AD DS den Assistenten zum Zuweisen der Objektverwaltung. 

Zum Verwenden dieses Assistenten führen Sie die folgenden Schritte aus: 

1. Öffnen Sie die Verwaltungskonsole Active Directory-Benutzer und -Computer, und wechseln Sie 

zum übergeordneten Objekt, dessen Verwaltung delegiert werden soll. In den meisten Fällen wird 

die Verwaltung auf Ebene einer OU delegiert, dieser Vorgang kann jedoch auch auf Domänenoder 

Containerebene (z.B. für die Container Computers und Users) ausgeführt werden. Klicken 

Sie mit der rechten Maustaste auf das übergeordnete Objekt, und wählen Sie Objektverwaltung 

zuweisen. Klicken Sie auf Weiter. 

2. Fügen Sie auf der Seite Benutzer oder Gruppen die Benutzer oder Gruppen hinzu, denen die 

Objektverwaltung zugewiesen werden soll. Klicken Sie auf Hinzufügen, um Active Directory 

nach den erforderlichen Benutzern oder Gruppen zu durchsuchen. 

3. Wählen Sie anschließend die Aufgabe, die delegiert werden soll. In dem in Abbildung 9.13 

gezeigten Fenster kann eine allgemeine Aufgabe ausgewählt oder eine benutzerdefinierte Aufgabe 

für die Delegierung erstellt werden.


Abbildung 9.13 Verwenden des Assistenten zum Zuweisen der Objektverwaltung, um eine allgemeine Aufgabe 

für die Delegierung auszuwählen 

4. Beim Erstellen einer benutzerdefinierten Aufgabe kann der Typ von Objekten ausgewählt 

werden, für welche Administratorrechte delegiert werden sollen. (Dieses Fenster ist in 

Abbildung 9.14 dargestellt.) 


Auswählen des Typs von Objekten, für welchen Berechtigungen delegiert werden 

5. Nach der Auswahl des Objekttyps kann festgelegt werden, welcher Berechtigungsumfang für das 

Objekt angewendet werden soll. Sie können Vollzugriff für das Objekt oder lediglich Berechtigungen 

für bestimmte Eigenschaften zuweisen. (Dieses Fenster ist in Abbildung 9.5 dargestellt.

Überwachen der Verwendung von Administratorrechten 341 


Auswählen der spezifischen Berechtigungen, für welche die Verwaltung delegiert wird 

Mithilfe des Assistenten zum Zuweisen der Objektverwaltung ist es deutlich einfacher, die Verwaltung 

konsistent zu delegieren als beim Konfigurieren von Berechtigungen über die ACL. Beide 

Methoden haben jedoch dasselbe Ergebnis: die ACL für das Objekt wird geändert, um den erforderlichen 

Zugriff bereitzustellen. 

Direkt von der Quelle: Der Assistent zum Zuweisen der Objektverwaltung 

Der Assistent zum Zuweisen der Objektverwaltung kann zum Delegieren einer Vielzahl von allgemeinen 

Aufgaben verwendet werden, indem einzelnen Benutzern oder Gruppen Verwaltungsberechtigungen 

zugewiesen werden. Für diese Aufgaben können bestimmte vordefinierte Optionen 

wie Erstellt, entfernt und verwaltet Benutzerkonten und Setzt Benutzerkennwörter zurück und 

erzwingt Kennwortänderung bei der nächsten Anmeldung festgelegt werden. Zusätzlich zu den 

vordefinierten Optionen können unter Verwendung äußerst detaillierter Auswahlmöglichkeiten, wie 

z.B. Konten-, Computer- oder Gruppenobjekten, benutzerdefinierte Aufgaben delegiert werden. 

Daher ist der Assistent zum Zuweisen der Objektverwaltung ein äußerst leistungsfähiges Tool, um 

eine dezentrale Verwaltung innerhalb von Active Directory zu implementieren. 

Greg Robb 

Microsoft Premier Field Engineer 

Überwachen der Verwendung von Administratorrechten 

Bei der Delegierung von Verwaltungsaufgaben in den AD DS ist es erforderlich, die Verwendung von 

Administratorrechten innerhalb der Verzeichnisstruktur überwachen zu können. Die Überwachung hat 

mindestens zwei Ziele. Zunächst ermöglicht sie die Nachverfolgung von Änderungen, die am Verzeichnis 

vorgenommen wurden. Bei Verzeichnisänderungen ist es möglicherweise erforderlich nachzuverfolgen, 

welcher Benutzer diese Änderung durchgeführt hat. Dies ist besonders wichtig, wenn 

eine falsche oder böswillige Änderung an den Domäneninformationen vorgenommen wurde.


Ferner bietet die Überwachung eine zusätzliche Prüfung der Administratorrechte, die innerhalb einer 

Domäne ausgeübt werden. Durch eine regelmäßige Überprüfung der Überwachungsprotokolle lässt 

sich ermitteln, ob ein Benutzer Administratoraufgaben ausführt, der nicht über die erforderlichen 

Rechte verfügen sollte. 

Beim Überwachen von AD DS-Ereignissen werden Einträge in das Sicherheitsprotokoll auf dem 

Domänencontroller geschrieben. Über die Ereignisanzeige können die Ereignisse angezeigt werden, 

die Windows Server 2008 im Sicherheitsprotokoll speichert. Die Ereignisse lassen sich ferner in einer 

Ereignisdatei speichern, um Trends für einen bestimmten Zeitraum zu archivieren und nachzuverfolgen. 

Um die Überwachung von Änderungen an Active Directory-Objekten zu aktivieren, müssen zwei 

Schritte ausgeführt werden: Konfigurieren der Überwachungsrichtlinie für Domänencontroller sowie 

Konfigurieren der SACL für bestimmte Active Directory-Objekte, die überwacht werden solllen. In 

den folgenden Abschnitten werden diese zwei Schritte erläutert. 

Konfigurieren der Überwachungsrichtlinie für Domänencontroller 

Der erste Schritt zum Aktivieren der Überwachung ist die Konfiguration der Überwachungsrichtlinie 

für die Domänencontroller. Diese Aufgabe kann über die Standard-Domänencontrollerrichtlinie innerhalb 

der Konsole Gruppenrichtlinienverwaltung ausgeführt werden. Wechseln Sie in der Konsole 

Gruppenrichtlinienverwaltung zum Container Gruppenrichtlinienobjekte. Klicken Sie in der Detailansicht 

mit der rechten Maustaste auf Default Domain Controllers Policy und anschließend auf Bearbeiten, 

um den Gruppenrichtlinienverwaltungs-Editor zu öffnen. Im Gruppenrichtlinienverwaltungs- 

Editor wechseln Sie zu Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale 

Richtlinien und klicken auf Überwachungsrichtlinie. Abbildung 9.16 zeigt die 

standardmäßige Überwachungskonfiguration in Windows Server 2008 AD DS. 

Zum Überwachen von Änderungen an Active Directory-Objekten muss die Richtlinie Verzeichnisdienstzugriff 

überwachen aktiviert und konfiguriert werden. Wenn diese Richtlinie aktiviert und konfiguriert 

ist, werden sämtliche Änderungen an Active Directory-Objekten im Sicherheitsprotokoll 

aufgezeichnet. Es können sowohl erfolgreiche Änderungen an Active Directory-Objekten als auch 

fehlgeschlagene Änderungsversuche überwacht werden. 

In Windows 2000 Server und Windows Server 2003 war die Richtlinie Verzeichnisdienstzugriff überwachen 

die primäre Option zum Überwachen von Verzeichnisdienstereignissen. In Windows Server 

2008 ist diese Richtlinie in vier Unterkategorien unterteilt: 




• Detaillierte Verzeichnisdienstreplikation 

Die Unterteilung der Richtlinie Verzeichnisdienstzugriff überwachen in vier Unterkategorien ermöglicht 

eine detailliertere Steuerung der Aktionen, die im Hinblick auf die Verzeichnisdienstereignisse 

überwacht werden. Bei Aktivierung der Richtlinie Verzeichnisdienstzugriff überwachen werden sämtliche 

Unterkategorien dieser Richtlinie aktiviert. Zum Ändern der Unterkategorien kann der Gruppenrichtlinienobjekt-Editor 

nicht verwendet werden. Die Unterkategorien können ausschließlich über das 

Befehlszeilentool Auditpol.exe angezeigt oder bearbeitet werden. Wenn Sie z.B. alle möglichen Kategorien 

und Unterkategorien anzeigen möchten, geben Sie an der Eingabeaufforderung den folgenden 

Befehl ein, und drücken Sie die EINGABETASTE:


auditpol /list /subcategory:* 

Hinweis Zum Anzeigen der für Auditpol.exe verfügbaren Befehle öffnen Sie eine Eingabeaufforderung, 

und geben Sie den folgenden Befehl ein: Auditpol.exe /? 


Konfigurieren der Überwachung für die OU Default Domain Controllers Policy 

Überwachen von Änderungen an Objekten unter Verwendung der Unterkategorie 

Verzeichnisdienständerungen 

Die Unterkategorie Verzeichnisdienständerungen bietet die Möglichkeit, Änderungen an Objekten 

in den AD DS zu überwachen. Über diese Unterkategorie werden die folgenden Änderungstypen 

überwacht: 

• Bei erfolgreicher Änderung eines Attributs werden sowohl die vorherigen als auch die aktuellen 

Werte des Attributs in den AD DS protokolliert. 

• Beim Erstellen eines neuen Objekts werden die Werte der Attribute protokolliert, die während 

der Erstellung aufgefüllt werden. Beachten Sie, dass Standardwerte für Attribute, die von den 

AD DS zugewiesen werden, nicht protokolliert werden. 

• Beim Verschieben eines Objekts innerhalb der Domäne wird sowohl der vorherige als auch der 

neue Speicherort protokolliert.


• Beim Wiederherstellen eines gelöschten Objekts wird sowohl der Speicherort protokolliert, an 

den das Objekt verschoben wird, als auch Vorgänge zum Hinzufügen oder Ändern von Attributen 

während des Wiederherstellens des gelöschten Attributs. 

Zum Aktivieren der Überwachungsunterkategorie Verzeichnisdienständerungen geben Sie an der 

Eingabeaufforderung den folgenden Befehl ein, und drücken Sie die EINGABETASTE: 

auditpol /set /subcategory:"directory service changes" /success:enable 

Bei Aktivierung der Unterkategorie Verzeichnisdienständerungen werden in den AD DS verschiedene 

Ereignistypen im Sicherheitsereignisprotokoll gespeichert, wie in Tabelle 9.3 gezeigt. 

Tabelle 9.3 

Ereignisse bei Verzeichnisdienständerungen 

Ereignis-ID Typ Beschreibung 

5136 Ändern Wird bei Attributänderungen in den AD DS protokolliert. 

5137 Erstellen Wird beim Erstellen von neuen Objekten in den AD DS protokolliert. 

5138 Wiederherstellen Wird beim Wiederherstellen von gelöschten Objekten in den AD DS protokolliert. 

5139 Verschieben Wird beim Verschieben von Objekten innerhalb der Domäne protokolliert. 

Konfigurieren der Überwachung für Active Directory-Objekte 

Als zweiter Schritt beim Konfigurieren der Active Directory-Objektüberwachung muss die Überwachung 

direkt für die SACL jedes Active Directory-Objekts aktiviert werden, das überwacht werden 

soll. Zum Aktivieren der Active Directory-Objektüberwachung greifen Sie über das geeignete Active 

Directory-Verwaltungstool auf die Eigenschaftenseite des Objekts zu. Anschließend klicken Sie auf 

der Seite Sicherheit auf Erweitert und wählen die Registerkarte Überwachung. Abbildung 9.17 zeigt 

das Fenster der Verwaltungskonsole Active Directory-Benutzer und -Computer und die standardmäßige 

Überwachungseinstellung für eine OU in Active Directory. 

Zum Hinzufügen zusätzlicher Überwachungseinträge klicken Sie auf Hinzufügen und legen fest, welche 

Benutzer oder Gruppen und welche Aktionen überwacht werden sollen. In den meisten Fällen 

sollte die Gruppe Jeder ausgewählt werden, um die Änderungen sämtlicher Benutzer überwachen zu 

können. Anschließend kann festgelegt werden, welche Aktivitäten überwacht werden sollen. Sie können 

sämtliche Änderungen an allen Objekten innerhalb des Containers, an bestimmten Objekttypen 

oder an spezifischen Eigenschaften überwachen. Sie können die Überwachung aller erfolgreichen 

Änderungen, aller fehlgeschlagenen Änderungsversuche oder beide Optionen aktivieren. Wenn alle 

erfolgreichen Änderungen überwacht werden, verfügen Sie über einen Audit-Trail für sämtliche 

Änderungen, die am Verzeichnis vorgenommen werden. Bei Aktivierung der Überwachung für fehlgeschlagene 

Änderungsversuche können nicht zulässige Versuche, die Verzeichnisinformationen zu 

bearbeiten, überwacht werden. Nachdem die Überwachung aktiviert wurde, werden alle Überwachungsereignisse 

im Sicherheitsprotokoll aufgezeichnet, auf das über die Ereignisanzeige zugegriffen 

werden kann.



Konfigurieren der Überwachung für Active Directory-Objekte 

Das Aktivieren der Überwachung ist einfach. Die Verwaltung ist jedoch deutlich schwieriger. Bei 

Aktivierung der Überwachung aller Verzeichnisänderungen auf Ebene der Domänencontroller-OU 

erhöht sich die Größe des Sicherheitsprotokolls äußerst schnell. Und da es sich bei praktisch allen 

Ereignissen um berechtigte Änderungen handelt, sind diese Informationen lediglich als Audit-Trail 

nützlich, liefern sonst jedoch keine wichtigen Daten. Unter den zulässigen Änderungen befinden sich 

jedoch möglicherweise auch einige wenige Änderungen, denen Sie Ihre Aufmerksamkeit widmen 

sollten. Und das Ermitteln der geringen Anzahl an interessanten und wichtigen Überwachungsereignisse 

innerhalb der großen Anzahl an Routineereignisse stellt ein Problem dar. In einigen Unternehmen 

wird z.B. ein Administrator mit der Aufgabe betraut, die Ereignisprotokolle täglich durchzusehen. 

Eine bessere Möglichkeit ist jedoch die Erstellung einiger automatisierter Methoden zur 

Zentralisierung und Analyse der Ereignisprotokolle. Ferner kann ein Tool wie Microsoft System 

Center Operations Manager (dieses Produkt kann separat erworben werden) eingesetzt werden, um 

die Ereignisse zu filtern und nur bei wichtigen Ereignissen eine Warnung auszulösen. 

Weitere Informationen Weitere Informationen zu Microsoft System Center Operations Manager finden 

Sie auf der folgenden Website: http://www.microsoft.com/systemcenter/opsmgr/default.mspx. Operations 

Manager bietet umfangreiche Funktionen, welche die Überwachung der Sicherheitsprotokolle bei weitem 

übersteigen.


Direkt von der Quelle: Legen Sie Ereignisprotokolleinstellungen mit Bedacht fest 

Bedenken Sie immer, welche Auswirkungen die Aktivierung einer Option hat, über welche die 

Menge an Informationen erhöht wird, die an die Ereignisprotokolle gesendet werden. Viele Kunden 

passen die Ereignisprotokolle an ihre spezifischen Sicherheitsanforderungen an, überdenken 

die Einstellungen anschließend jedoch nicht, um zu ermitteln, ob die zusätzliche Protokollierung 

Probleme verursacht. Ich habe viele Szenarien gesehen, in denen die Überwachung und gleichzeitig 

die Richtlinieneinstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen 

nicht protokolliert werden können aktiviert war, was zu einem Dienstverweigerungsangriff 

führte. Eine weitere Einstellung, die viele IT-Experten ändern, ist die maximale 

Protokollgröße. Führen Sie vor dem Ändern von Protokollgrößen in hohe Werte eine Analyse 

durch, um zu ermitteln, ob das System, auf dem diese Einstellung aktiviert wird, über genügend 

Arbeitsspeicherkapazität verfügt. Informationen zum Ereignisprotokoll und zu Arbeitsspeichereinschränkungen 

finden Sie unter http://support.microsoft.com/kb/183097. 

Barry Hartman 



Tools für die delegierte Verwaltung 

Die AD DS bieten leistungsfähige Optionen zum Delegieren von Verwaltungsaufgaben und Zuweisen 

von spezifischen Berechtigungen, welche die Benutzer zum Ausführen bestimmter Aufgaben 

benötigen. Als Ergänzung ermöglicht Windows Server 2008 ferner die problemlose Entwicklung von 

Verwaltungstools für die verschiedenen Benutzeraufgaben. Bei Delegierung der Berechtigung zum 

Zurücksetzen von Kennwörtern für eine einzige OU kann z.B. auch ein sehr einfaches Verwaltungstool 

bereitgestellt werden, das ausschließlich zum Zurücksetzen der Kennwörter in der angegebenen 

OU verwendet werden kann. Windows Server 2008 ermöglicht die Erstellung einer benutzerdefinierten 

Anzeige des MMC-Snap-Ins (Microsoft Management Console), um delegierten Administratoren 

effektive Tools zum Ausführen ihrer Aufgaben bereitzustellen. 

Direkt von der Quelle: Arbeiten mit Delegierungstools anderer Anbieter 

Viele Kunden verwenden Drittanbieterprodukte für die Delegierung. Diese Produkte bieten üblicherweise 

eine Webschnittstelle und ermöglichen es Administratoren, anstelle von benutzerdefinierten 

MMC-Snap-Ins benutzerdefinierter Webanzeigen für tägliche Verwaltungsfunktionen zu 

erstellen. Stellen Sie bei der Arbeit mit Kunden mit Zweigstellenszenarien sicher, dass Sie für den 

Fall von längeren Unterbrechungen der Kommunikation über ein umfassendes Verständnis der 

Betriebsanforderungen des Unternehmens und der Zweigstellen verfügen. Wenn der Kunde über 

äußerst zuverlässige Kommunikationsverbindungen mit der Zweigstelle verfügt, stellt dieser 

Aspekt kein großes Problem dar; bei Kunden ohne zuverlässige Kommunikationswege muss dieses 

Problem jedoch bedacht und behandelt werden. 

Bei einer Unterbrechung der Kommunikationsverbindungen müssen Sie wissen, was erforderlich 

ist, damit die Aufgaben in der Zweigstelle weiterhin ausgeführt werden können.

Tools für die delegierte Verwaltung 347 

Wenn im Fall einer delegierten Verwaltung die Abläufe und Verwaltungsaufgaben in der Zweigstelle 

weiterhin ausgeführt werden müssen, die für einige dieser Funktionen erforderliche Webschnittstelle 

jedoch nicht verfügbar ist, da sie über den Hauptsitz gehostet wird, stellt sich die 

Frage, wie die Mitarbeiter in der Zweigstelle ihre Arbeit erledigen sollen. 

Wenn das Drittanbieterprodukt das Delegierungsmodell in Active Directory-Benutzer und -Computer 

instanziiert, gelten die Einschränkungen der Webschnittstelle auch bei Einsatz von systemeigenen 

Tools. Daher müssen Sie als qualifizierter Berater wissen, wie Drittanbieterprodukte mit Active 

Directory interagieren. Mit diesen Kenntnissen können Sie Ihre Kunden umfassend beraten und 

vorbereiten, sodass diese ihre Aktivitäten auch in Situationen wie Kommunikationsunterbrechungen 

weiterhin ausführen können. 

Barry Hartman 



Anpassen der Microsoft Management Console 

Eine Möglichkeit zum Entwickeln von Verwaltungstools ist die Erstellung eines benutzerdefinierten 

MMC-Snap-Ins, indem Sie den angezeigten Inhalt eines Standard-Snap-Ins für den Benutzer bearbeiten. 

Achtung Durch die Erstellung des benutzerdefinierten MMC-Snap-Ins allein werden die Benutzerrechte 

zum Ausführen von Verwaltungsaufgaben noch nicht erteilt oder eingeschränkt. Vor der Erstellung der angepassten 

Verwaltungsschnittstelle muss zunächst der erforderliche Berechtigungsumfang delegiert werden. 

Wenn einem Benutzer z.B. das Recht zum Erstellen von Benutzerkonten auf Domänenebene zugewiesen 

und anschließend ein MMC-Snap-In erstellt wird, das dem Benutzer lediglich die Anzeige einer OU ermöglicht, 

kann der Benutzer dennoch Benutzerkonten in sämtlichen OUs innerhalb der Domäne erstellen. Wenn 

der Benutzer das normale Verwaltungstool Active Directory-Benutzer und -Computer lädt oder an einem 

Computer mit einem andere MMC-Snap-In arbeitet, kann er das Konto an einer beliebigen Stelle erstellen. 

Öffnen Sie zum Erstellen eines benutzerdefinierten MMC-Snap-Ins das Dialogfeld Ausführen, und 

geben Sie mmc ein. Es wird ein leeres MMC-Snap-In geöffnet. Fügen Sie über das Menü Datei das 

gewünschte Active Directory-Verwaltungstool-Snap-In hinzu. Beim Erstellen eines benutzerdefinierten 

MMC-Snap-Ins über das Snap-In Active Directory-Benutzer und -Computer würden Sie 

anschließend die Domäne erweitern und zum Containerobjekt wechseln, für das die Berechtigungen 

delegiert wurden. Klicken Sie im linken Fenster mit der rechten Maustaste auf das Containerobjekt, 

und wählen Sie Neues Fenster. 

Es wird ein neues Fenster geöffnet, in dem lediglich das Containerobjekt und alle untergeordneten 

Objekte sichtbar sind. Anschließend können Sie erneut in das Fenster mit der gesamten Domäne 

wechseln und dieses Fenster schließen. Schließlich speichern Sie das Verwaltungstool und stellen es 

für die Benutzer bereit, die lediglich den Teil der Domäne verwalten, der im MMC-Snap-In angezeigt 

wird. Das MMC-Snap-In kann über unterschiedliche Methoden für die Benutzer bereitgestellt werden. 

Sie können es beispielsweise auf dem Computer des jeweiligen Benutzers installieren oder eine 

Verknüpfung über eine Netzwerkfreigabe erstellen.


Zum Sicherstellen, dass die Administratoren das benutzerdefinierte MMC-Snap-In nach der Bereitstellung 

nicht ändern, können die MMC-Optionen über den Eintrag Optionen im Menü Datei geändert 

werden. Es kann konfiguriert werden, dass das MMC-Snap-In im Benutzermodus gespeichert 

wird; ferner können die Berechtigungen so festgelegt werden, dass der Endbenutzer keine Änderungen 

am MMC-Snap-In speichern kann. Abbildung 9.18 zeigt das entsprechende Dialogfeld. 

Einzelheiten zum Erstellen von benutzerdefinierten MMC-Snap-Ins finden Sie unter Windows-Hilfe 

und Support. 


Konfigurieren eines benutzerdefinierten MMC-Snap-Ins, um Änderungen zu verhindern 

Planen der delegierten Verwaltung 

Wie in diesem Kapitel gezeigt, bietet Windows Server 2008 AD DS die erforderlichen Tools zum 

Delegieren von Administratorrechten in einer Domäne. Trotz aller positiven Aspekte bei der Delegierung 

von Berechtigungen birgt dieser Vorgang auch das Risiko, die falschen Berechtigungen zuzuweisen. 

Dies könnte dazu führen, dass Benutzer in Active Directory Aufgaben ausführen können, für die 

sie nicht berechtigt sein sollten. Falsche Berechtigungen kann auch bedeuten, dass nicht ausreichend 

Berechtigungen zugewiesen werden, sodass die Benutzer ihre erforderlichen Aufgaben nicht ausführen 

können. Zum Erstellen einer Delegierungsstruktur, in der Benutzer genau die Berechtigungen 

erhalten, die sie benötigen, sind daher umfangreiche Planungsmaßnahmen erforderlich. Im Folgenden 

finden Sie verschiedene Empfehlungen, um Sie bei der Planung der delegierten Verwaltung 

zu unterstützen: 

• Dokumentieren Sie sorgfältig die Verwaltungsanforderungen für alle potenziellen Administratoren. 

In den meisten Unternehmen benötigen mehrere Benutzer und Gruppen bestimmte Administratorrechte 

innerhalb der Domäne. Eine Vielzahl dieser Benutzer könnten Mitglieder der Gruppe 

Domänen-Admins sein. Wenn Sie die erforderlichen Verwaltungsaufgaben der Benutzer dokumentieren, 

stellen Sie üblicherweise fest, dass eine deutlich niedrigere Zugriffsebene erforderlich ist.


Um den erforderlichen Umfang der Administratorrechte jeder Gruppe zu dokumentieren, müssen 

häufig sämtliche Administratoraufgaben aufgezeichnet werden, die diese Benutzer täglich ausführen. 

So lässt sich präzise festlegen, welche Berechtigungen benötigt werden. 

• Testen Sie alle Änderungen an Sicherheitseinstellungen in einer Testumgebung, bevor Sie die Produktionsumgebung 

selbst ändern. Eine falsche Sicherheitskonfiguration kann schwerwiegende 

Auswirkungen für das Netzwerk haben. Verwenden Sie die Testumgebung um sicherzustellen, 

dass mithilfe der Änderungen die erforderlichen Berechtigungen erteilt, jedoch keine zusätzlichen 

Berechtigungen zugewiesen werden, die nicht erforderlich sind. 

• Überwachen und testen Sie die Benutzerberechtigungen im Dialogfeld Erweiterte Sicherheitseinstellungen 

auf der Seite Effektive Berechtigungen Über diese Seite lassen sich die exakten Berechtigungen 

ermitteln, über die ein Benutzer oder eine Gruppe in den AD DS verfügt. Verwenden Sie 

das Tool in der Testumgebung, um sicherzustellen, dass die Konfiguration ordnungsgemäß ist, 

und verwenden Sie es erneut in der Produktionsumgebung, um sicherzustellen, dass die Implementierung 

plangemäß erfolgt ist. 

• Dokumentieren Sie alle Berechtigungen, die Sie zuweisen. Da das Dokumentieren von Änderungen 

am Netzwerk eine äußerst aufwendige und scheinbar unwichtige Aufgabe sein kann, 

scheint dies die unbeliebteste Aufgabe eines Netzwerkadministrators zu sein. Folglich ist die 

Dokumentation häufig unvollständig oder überholt. Die einzige Möglichkeit für eine effektive 

Verwaltung der Sicherheitskonfiguration eines Netzwerks ist jedoch, die Erstkonfiguration zu 

dokumentieren und diese Informationen anschließend konsequent mit allen zukünftigen Änderungen 

zu aktualisieren. 


Die Option zum Delegieren von Administratorrechten in Windows Server 2008 AD DS bietet eine 

hohe Flexibilität im Hinblick darauf, wie eine Domäne verwaltet werden kann. Die Delegierung 

von Administratorrechten basiert auf dem Active Directory-Sicherheitsmodell, in dem sämtliche 

Objekte und sogar sämtliche Attribute für jedes Objekt über eine ACL zum Steuern der Berechtigungen 

verfügen, die Sicherheitsprinzipalen für ein bestimmtes Objekt zugewiesen sind. Gemäß diesem 

Sicherheitsmodell werden sämtliche Berechtigungen standardmäßig von Containerobjekten an 

die Objekte innerhalb des Containers vererbt. Diese zwei grundlegenden Features des Sicherheitsmodells 

ermöglichen es Ihnen, einen praktisch beliebigen Berechtigungsumfang für ein Active Directory-Objekt 

zuzuweisen. Diese Flexibilität kann jedoch auch eine hohe Komplexität bedeuten, wenn 

die Sicherheit für Active Directory nicht so einfach wie möglich gestaltet wird. In diesem Kapitel 

wurde ein Überblick über Sicherheitsberechtigungen, den Active Directory-Objektzugriff, die Delegierung 

der Verwaltung sowie die Überwachung von Änderungen in Active Directory vermittelt. 



Kapitel. 


• In Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“ finden Sie Einzelheiten 

zur Planung der Active Directory-Struktur (z.B. Standorte, Domänen, Organisationseinheiten und 

Gesamtstrukturen).


• In Kapitel 6, „Installieren der Active Directory-Domänendienste“ finden Sie Einzelheiten zum 

Delegieren der Verwaltung für schreibgeschützte Domänencontroller. 

• In Kapitel 8, „Active Directory-Domänendienstsicherheit“ finden Sie zusätzliche Einzelheiten zu 

Sicherheitsgrundlagen und Authentifizierung in Active Directory. 

• „Best Practices for Delegating Active Directory Administration”“ unter http://www.microsoft.com/ 

technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/actdid1.mspx. 

• „Best Practices for Delegating Active Directory Administration Appendices“ unter http:// 

www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739- 

cb1fb22a0642&DisplayLang=en. 

• „Delegating Authority in Active Directory“ unter http://www.microsoft.com/technet/technetmag/ 

issues/2007/02/ActiveDirectory/default.aspx. 

• „Using Scripts to Manage Active Directory Security“ unter http://www.microsoft.com/technet/ 

scriptcenter/topics/security/exrights.mspx. 

• „Sample Scripts to Manage Active Directory Delegation and Security“ unter http://www.microsoft.com/technet/scriptcenter/scripts/security/ad/default.mspx?mfr=true. 

• „Step-by-Step Guide to Using the Delegation Of Control Wizard“ unter http://www.microsoft.com/ 

technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/ 

ctrlwiz.mspx. 

• „Default Security Concerns in Active Directory Delegation“ unter http://support.microsoft.com/ 

?kbid=235531.

351 

K A P I T E L 1 0 

Verwalten von Active Directory-Objekten 


Verwalten von Benutzern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

Verwalten von Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 

Verwalten von Computern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 

Verwalten von Druckerobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 

Verwalten von veröffentlichten freigegebenen Ordnern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 

Automatisieren der Active Directory-Objektverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 




Ein Großteil der mithilfe der Windows Server 2008-Active Directory-Domänendienste (Active Directory 

Domain Services, AD DS) durchgeführten Aufgaben umfasst die Verwaltung von Active Directory-Objekten 

wie Benutzern und Gruppen. In den meisten Unternehmen wird zuerst ein Active 

Directory-Entwurf erstellt, der einmal implementiert wird. Nach der Bereitstellung werden an den 

meisten Active Directory-Objekten nur noch wenige Änderungen vorgenommen. Benutzer- und 

Gruppenobjekte stellen allerdings eine bedeutende Ausnahme dieser Regel dar. Wenn Angestellte das 

Unternehmen verlassen oder zum Unternehmen hinzukommen, ist die Verwaltung von Benutzern und 

Gruppen Aufgabe des Administrators. Druckerobjekte, Computerobjekte und die Objekte freigegebener 

Ordner sind weitere Active Directory-Objekte, für die häufiger Verwaltungsaufgaben anfallen. 

In diesem Kapitel werden die Konzepte und Verfahren für die Verwaltung von Active-Objekten erläutert. 

Die unterschiedlichen Objekttypen werden erläutert, die in Active Directory gespeichert werden 

können, und die Verwaltung dieser Objekte wird beschrieben. Außerdem werden in diesem Kapitel 

Tools für die Verwaltung von Active Directory-Objekten vorgestellt, einschließlich VBScript und 

Windows PowerShell für die Automatisierung von Änderungen. 

Verwalten von Benutzern 

In Windows Server 2008 Active Directory sind drei unterschiedliche Objekte verfügbar, die einzelne 

Benutzer im Verzeichnis repräsentieren. Bei zweien dieser Objekte, d.h. dem Benutzerobjekt und dem 

Objekt inetOrgPerson, handelt es sich um Sicherheitsprinzipale, die für die Zuweisung des Zugriffs 

auf Ressourcen im Netzwerk verwendet werden können. Bei dem dritten Objekt, dem Kontaktobjekt, 

handelt es sich nicht um einen Sicherheitsprinzipal, dieses Objekt wird vorwiegend für E-Mail-Zwecke 

verwendet.

352 Kapitel 10: Verwalten von Active Directory-Objekten 

Benutzerobjekte 

Das Benutzerobjekt ist eines der Objekte, die in einer Active Directory-Datenbank am häufigsten vorkommen. 

Bei einem Benutzerobjekt handelt es sich wie auch bei jedem anderen Active Directory- 

Klassenobjekt um eine Attributsammlung. Ein Benutzerobjekt kann sich aus über 250 vom System 

erstellten und noch weiteren von Ihrer Organisation erstellten Attributen zusammensetzen. Daher 

weist Windows Server 2008 Active Directory große Unterschiede zu den eher eingeschränkten lokalen 

Sicherheitsdatenbanken auf, die sich auf Mitgliedsservern, Windows-Arbeitsstationen und einigen 

Linux-Computern befinden. In lokalen Sicherheitsdatenbanken verfügen Benutzerobjekte nur 

über sehr wenig Attribute, wie beispielsweise ein Kennwort und ein Basisverzeichnis. Da Active 

Directory zusätzliche Objektattribute bereitstellen kann, ist Active Directory nicht nur eine Datenbank 

zur Speicherung von Authentifizierungsinformationen, sondern dient darüber hinaus als Verzeichnisdienst. 

Active Directory kann beispielsweise der primäre Speicherort für die meisten Benutzerinformationen 

in Ihrem Unternehmen werden. Das Verzeichnis kann der Ort sein, an dem alle 

Benutzerinformationen wie beispielsweise Telefonnummern, Adressen und organisatorische Informationen 

gespeichert werden. Wenn Benutzer mit der Suchfunktion in Active Directory vertraut sind, 

können sie nahezu alle Informationen zu anderen Benutzern finden, für die sie über Anzeigeberechtigung 

verfügen. 

Beim Erstellen von Benutzerobjekten gibt es erforderliche und optionale Attribute. Wie in 

Abbildung 10.1 dargestellt, gibt es sechs erforderliche Attribute. Diese sechs Attribute müssen bei 

der Erstellung eines Benutzerkontos konfiguriert werden. Von diesen sechs Attributen werden die beiden 

Attribute cn und sAMAccountName basierend auf den von Ihnen beim Erstellen des Kontos mithilfe 

des Verwaltungstools Active Directory-Benutzer und Computer angegebenen Daten konfiguriert. 

Alle weiteren erforderlichen Attribute wie z.B. die Sicherheitskennung (Security Identifier, SID) 

werden automatisch ausgefüllt. Wenn bei der programmgesteuerten Benutzererstellung mithilfe von 

Skripts das Attribut sAMAccountName nicht bereitgestellt wird, wird es ebenfalls automatisch generiert. 


In Adsiedit.msc dargestellte erforderliche Benutzerkontenattribute

Verwalten von Benutzern 353 

Beim Erstellen von Benutzerkonten können Sie vielen anderen Benutzerobjektattributen einen Wert 

zuweisen. Einige dieser Attribute werden auf der Benutzeroberfläche (User Interface, UI) der Standardverwaltungstools 

wie z.B. Active Directory-Benutzer und -Computer nicht angezeigt. Jedes 

Benutzerobjekt verfügt beispielsweise über das Attribut Assistent, das nicht auf der Benutzeroberfläche 

angezeigt wird. Sie können dieses Attribut jedoch trotzdem mithilfe eines Skripts oder eines Tools 

wie z.B. Adsiedit.msc ausfüllen, das direkt auf dieses Attribut zugreift. Sie können Attribute, die nicht 

über eine grafische Benutzeroberfläche verfügbar sind, über einen Massenimport von Verzeichnisinformationen 

mithilfe der Befehlszeilenprogramme Csvde oder Ldifde ausfüllen. Diese beiden 

Befehlszeilenprogramme werden später in diesem Kapitel erläutert. 

Nicht auf der Benutzeroberfläche angezeigte Attribute können von Anwendungen zum Speichern 

zusätzlicher Benutzerinformationen verwendet werden. In den meisten Fällen können Sie über das 

Suchfeld im Verwaltungstool Active Directory-Benutzer und -Computer auf diese Attribute zugreifen. 

Verwenden Sie beispielsweise in Active Directory-Benutzer und -Computer für die Suche nach allen 

Benutzern, die das gleiche Attribut Assistent aufweisen, im Suchdialogfeld die Registerkarte Erweitert, 

um eine Abfrage basierend auf dem Attribut Assistent zu erstellen. In Abbildung 10.2 wird die 

Registerkarte Erweitert im Suchdialogfeld angezeigt. Klicken Sie in diesem Dialogfeld auf Feld, 

wählen Sie den Benutzer und anschließend das Attribut, nach dem Sie suchen möchten. Viele der 

ausgeblendeten Attribute können Sie über dieses Dialogfeld ermitteln. 

Suchen nach einem Benutzerkonto auf Grundlage eines nicht auf der Benutzeroberfläche ange- 


zeigten Attributs 

Hinweis Sie können jedes Attribut eines Benutzerobjekts mithilfe von Tools wie Adsiedit.msc oder Ldp.exe 

anzeigen und bearbeiten. Wenn Sie viele Objekte bearbeiten müssen, ist die Verwendung von Skripts zum 

Bearbeiten dieser Attribute empfehlenswert. Active Directory ermöglicht und unterstützt die Verwendung von 

Skripts. Weitere Informationen zur Verwendung von Skripts zum Automatisieren der Active Directory-Verwaltungsaufgaben 

werden später in diesem Kapitel erläutert.


Die häufigsten Benutzerverwaltungsaufgaben können mithilfe des Verwaltungstools Active Directory- 

Benutzer und -Computer durchgeführt werden. Um ein Benutzerobjekt im Verwaltungstool Active 

Directory-Benutzer und -Computer zu erstellen, ermitteln Sie den Container, in dem Sie das Objekt 

erstellen möchten, klicken Sie mit der rechten Maustaste darauf, wählen Sie Neu und klicken 

anschließend auf Benutzer. Beim Erstellen des Benutzers müssen Sie für den Benutzer zumindest 

die Informationen für Vollständiger Name und Benutzeranmeldename bereitstellen. Die im Feld Vollständiger 

Name angegebenen Daten werden zum Auffüllen des Attributs cn für den Benutzer verwendet, 

und die im Feld Benutzeranmeldename angegebenen Daten werden als Wert für das Attribut 

sAMAccountName übernommen. Nachdem der Benutzer erstellt wurde, können Sie auf die Objekteigenschaften 

zugreifen, um für den Benutzer weitere Attribute festzulegen. Der Großteil der 

Benutzerobjektattribute ist einfach zu verstehen. Bei der für die Verwaltung eines Benutzerkontos 

wichtigsten Registerkarte handelt es sich um die in Abbildung 10.3 dargestellte Registerkarte Konto. 

Die auf der Registerkarte Konto verfügbaren Einstellungen werden in Tabelle 10.1 erläutert. 


Die Registerkarte Konto für ein Benutzerobjekt 

Tabelle 10.1 

Kontoeigenschaften für ein Benutzerobjekt 

Kontoeigenschaft 

Benutzeranmeldename 

Benutzeranmeldename 

(Prä-Windows 2000) 

Erläuterung 

Mit dieser Eigenschaft wird der Benutzerprinzipalname (User Principle Name, UPN) für diesen Benutzer 

gekennzeichnet. 

Mit dieser Eigenschaft wird der Prä-Microsoft Windows 2000-Anmeldename gekennzeichnet, dabei 

wird das Format Domäne\Benutzername verwendet.


Tabelle 10.1 

Kontoeigenschaften für ein Benutzerobjekt (Fortsetzung) 

Kontoeigenschaft 

Anmeldezeiten 

Anmelden an 

Kontosperrung 

aufheben 

Kontooptionen 

Konto läuft ab 

Erläuterung 

Mit dieser Eigenschaft wird der Zeitrahmen festgelegt, während dessen sich ein Benutzer an der 

Domäne anmelden kann. Standardmäßig wird die Verbindung der Benutzer mit der Domäne nach 

Ablauf des Anmeldezeitraums getrennt. Dieses Verhalten kann jedoch in einer Gruppenrichtlinie 

über die Einstellung Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\ 

Lokale Richtlinien\Sicherheitsoptionen\Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit 

erzwingen konfiguriert werden. 

Mit dieser Eigenschaft werden die Computer aufgeführt, an denen der Benutzer zur Anmeldung berechtigt 

ist. Hierbei kann es sich um NetBIOS- oder DNS-Namen handeln. 

Diese Eigenschaft wird für das Aufheben der Kontosperrung verwendet (Anmeldung zulassen), 

wenn das Konto nach zu vielen fehlgeschlagenen Anmeldeversuchen gesperrt wurde. Dieses Verfahren 

unterscheidet sich jedoch von dem von einem Administrator vorgenommenen Aktivieren und 

Deaktivieren von Benutzerkonten. 

Mit dieser Eigenschaft werden mehrere Optionen für Einstellungen wie beispielsweise Kennwortrichtlinien 

und Authentifizierungsanforderungen bereitgestellt. 

Mit dieser Eigenschaft wird das Ablaufdatum für das Konto festgelegt. In der Regel wird diese 

Option verwendet, wenn ein Benutzer nur vorübergehend Zugriff auf Domänenressourcen benötigt. 

Manchmal ist es hilfreich zu wissen, wann sich ein Benutzer zum letzten Mal am Netzwerk angemeldet 

hat. Für die Domänenfunktionsebene Windows Server 2003 wurde das Benutzerattribut lastLogon- 

Timestamp eingeführt, das die letzte Anmeldung eines Benutzers am Netzwerk anzeigt. Dieses Attribut 

wird jedoch in Active Directory-Benutzer und -Computer nicht angezeigt. Auf dieses Attribut 

können Sie nur mithilfe eines Skripts zugreifen. Wenn für die Domänenfunktionsebene Windows Server 

2008 festgelegt ist, stehen Ihnen erweiterte Informationen zur letzten interaktiven Anmeldung zur 

Verfügung, mit denen Sie die Uhrzeit der letzten interaktiven Anmeldung, die für die Anmeldung verwendete 

Arbeitsstation sowie die Anzahl an fehlgeschlagenen Anmeldeversuchen seit der letzten 

Anmeldung ermitteln können. 

Benennen von Benutzerobjekten in Active Directory 

Obwohl jedes Objekt in Active Directory über einen eindeutigen Namen verfügen muss, kann 

dieses einfache Konzept im Hinblick auf Benutzerobjekte sehr kompliziert werden, da ein Benutzerobjekt 

tatsächlich über mehrere Namen verfügt, die zur Identifizierung verwendet werden können. 

In Tabelle 10.2 werden die Namen aufgeführt, die mit einem Benutzernamen verknüpft werden 

können, sowie der Bereich, in dem ein Name eindeutig sein muss. 

Tabelle 10.2 

Anforderungen für die Eindeutigkeit von Benutzernamen 

Benutzername 

Vorname, Initialen, Nachname 

Anzeigename: Der Anzeigename wird in den meisten Active Directory- 

Verwaltungstools wie z.B. Active Directory-Benutzer und -Computer 

angezeigt. Standardmäßig wird der Anzeigename aus den Feldern 

Vorname, Initialen und Nachname im Dialogfeld Neues Objekt - Benutzer 

gebildet. 

Anforderung der Eindeutigkeit 

Keine Eindeutigkeit erforderlich 

Keine Eindeutigkeit erforderlich


Vollständiger Name: Die Eigenschaft Vollständiger Name wird verwendet, 

um das Attribut cn des Benutzerkontos aufzufüllen. Dieser Wert 

entspricht der Einstellung für Anzeigename. Nach dem Erstellen können 

die Werte für Vollständiger Name und Anzeigename jedoch unabhängig 

voneinander bearbeitet werden. 

Benutzerprinzipalname (UPN): Der Benutzerprinzipalname setzt sich 

aus dem Anmeldenamen sowie dem Domänen-DNS-Namen oder 

einem alternativen UPN zusammen, sofern zusätzliche UPN-Suffixe für 

die Gesamtstruktur konfiguriert wurden. 

Benutzeranmeldename (Prä-Windows 2000) 

Muss innerhalb des Containers eindeutig sein, 

in dem sich der Benutzer befindet 

Muss innerhalb der Gesamtstruktur eindeutig 

sein 

Muss innerhalb der Domäne eindeutig sein 

Bearbeiten des Standardanzeigenamens 

Während der Erstellung von Benutzern wird der Anzeigename standardmäßig aus den Feldern Vorname, 

Initialen und Nachname im Dialogfeld Neues Objekt - Benutzer gebildet. Sie können diesen 

Standardnamen überschreiben, indem Sie einen alternativen Anzeigenamen eingeben. Sie können 

außerdem mithilfe des Tools Adsiedit.msc festlegen, auf welche Weise der Anzeigename erstellt 

wird: 

1. Öffnen Sie im ADSI-Editor den Namenskontext für den Konfigurationscontainer. 

2. Erweitern Sie hierzu ///CN=409CN=Configuration,CN=DisplaySpecifiersDC=Domänenname, 

wobei Domänenname für den Namen Ihrer Domäne steht. 

Beachten Sie, dass die Gebietsschema-ID 409 für US-Englisch gilt. Daher ist bei der Verwendung 

anderer Sprachen unter Umständen die Bearbeitung zusätzlicher Codeseiten erforderlich. 

Weitere Informationen zu Codeseiten werden auf den Websites der International Telecommunication 

Union (ITU) und der International Organization for Standardization aufgeführt. 

3. Öffnen Sie die Eigenschaften für CN=user-Display. 

4. Bearbeiten Sie das Attribut createDialog. Der Wert dieses Attributs kann Text und die Variablen 

%, %, und % umfassen. Bei den Namen dieser Variablen muss 

die Groß- und Kleinschreibung berücksichtigt werden. 

Der häufigste Grund für die Bearbeitung des Anzeigenamenformats besteht darin, das Format von 

Namen zu steuern, die in der globalen Adressliste von Exchange Server aufgeführt werden. Häufig 

wird der Standardanzeigename in das Format Nachname, Vorname geändert. Dafür muss für den 

Wert des Attributs createDialog die Reihenfolge %, % festgelegt werden. 

Von der Änderung des Werts für das Attribut createDialog sind vorhandene Benutzer nicht betroffen. 

Diese Änderung hat nur Auswirkungen auf die für neue Benutzer im Verwaltungstool Active Directory-Benutzer 

und -Computer erstellten Standardanzeigenamen. In den meisten Fällen bearbeiten Sie 

nicht jeden einzelnen Benutzer mit einem Tool wie Adsiedit.msc, sondern verwenden ein Skript oder 

die Tools Csvde oder Ldifde, um mehrere vorhandene Benutzer gleichzeitig zu bearbeiten.


Benutzerprinzipalnamen 

Der UPN kann das Anmeldeverfahren für einen Benutzer vereinfachen. Ein Benutzer kann sich an 

jeder beliebigen Domäne in der Gesamtstruktur mit seinem UPN anmelden, die Auswahl der 

Stammdomäne des Benutzers ist für die Anmeldung nicht erforderlich. Standardmäßig wird für das 

UPN-Suffix der DNS-Name (Domain Name System) für die Domäne verwendet. Das UPN-Suffix 

kann jedoch bearbeitet werden. Sie können beispielsweise intern einen anderen definierten Namen 

verwenden, als den im Internet angezeigten. In den meisten Fällen würde die SMTP-E-Mail- 

Adresse (Simple Mail Transfer Protocol) für alle Benutzer dem externen DNS-Namen entsprechen. 

Benutzer möchten sich unter Umständen mit ihrer SMTP-Adresse an der Domäne anmelden 

können. Sie können Ihren Benutzern diese Anmeldung ermöglichen, indem Sie der Gesamtstruktur 

ein alternatives UPN-Suffix hinzufügen und dieses Suffix dann allen Benutzerkonten hinzufügen. 

Um ein zusätzliches UPN-Suffix zu erstellen, öffnen Sie das Verwaltungstool Active Directory- 

Domänen und -Vertrauensstellungen, klicken mit der rechten Maustaste im oberen Bereich des linken 

Fensters auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen und wählen die 

Option Eigenschaften. Das entsprechende Dialogfeld wird in Abbildung 10.4 dargestellt. Geben Sie 

die alternativen UPN-Suffixe ein, die Sie verwenden möchten. 


Hinzufügen von alternativen UPN-Suffixen zu Ihrer Gesamtstruktur 

inetOrgPerson-Objekte 

Eines der in Windows Server 2003 Active Directory erstmals verfügbaren Objekte ist das Objekt 

inetOrgPerson. Bei diesem Objekt handelt es sich um ein primäres Benutzerkonto, das von anderen 

LDAP- und X.500-Verzeichnissen (Lightweight Directory Access Protocol) verwendet wird, die RFC 

2798-kompatibel sind (Request for Comments). Mit der Einführung des Objekts inetOrgPerson hat 

Microsoft die Integration von Active Directory in andere Verzeichnisse vereinfacht. Außerdem wird 

dadurch die Migration von anderen Verzeichnissen auf Active Directory erleichtert.


Hinweis Bei der Aktualisierung einer Windows 2000-Gesamtstruktur auf Windows Server 2008 wird das 

Objekt inetOrgPerson im Schema erstellt, wenn Sie den Befehl Adprep.exe mit der Option 

/forestprep ausführen. Das Tool Adprep.exe wird auf der Windows Server 2008-DVD im Ordner \sources\ 

adprep bereitgestellt. 

Sie können das inetOrgPerson-Objekt mithilfe des Verwaltungstools Active Directory-Benutzer und 

-Computer erstellen. Um ein inetOrgPerson-Objekt im Verwaltungstool Active Directory-Benutzer 

und -Computer zu erstellen, wechseln Sie zu dem Container, in dem Sie das Objekt erstellen möchten, 

klicken Sie mit der rechten Maustaste darauf, wählen Sie Neu, und klicken Sie auf InetOrgPerson. 

Sie müssen beim Erstellen des inetOrgPerson-Objekts zumindest den Benutzeranmeldenamen 

und den vollständigen Namen angeben. Bei dem inetOrgPerson-Objekt handelt es sich um eine 

Unterklasse des Benutzerobjekts, d.h. es umfasst alle Merkmale der Benutzerklasse, einschließlich 

der Möglichkeit, als Sicherheitsprinzipal zu agieren. Die inetOrgPerson-Objekte können wie jedes 

andere Benutzerobjekt verwaltet und verwendet werden. 

Um das Attribut userPassword als effektives Kennwort für die Authentifizierung von inetOrgPersonund 

Benutzerobjekten verwenden zu können, muss für die Domänenfunktionsebene mindestens Windows 

Server 2003 festgelegt sein. Diese Festlegung ist für Programmierer hilfreich, die Active Directory 

als LDAP-Verzeichnis verwenden. Für die Konvertierung eines inetOrgPerson-Objekts in ein 

Benutzerobjekt (oder umgekehrt) muss für die Gesamtstrukturfunktionsebene mindestens Windows 

Server 2003 festgelegt sein. 

Kontaktobjekte 

Bei dem dritten Objekttyp, der für die Darstellung von Benutzern in Active Directory verwendet werden 

kann, handelt es sich um das Kontaktobjekt. Kontaktobjekte unterscheiden sich von inetOrgPerson- 

und Benutzerobjekten dahingehend, dass sie nicht als Sicherheitsprinzipale fungieren können. 

Kontaktobjekte werden in der Regel ausschließlich zu Informationszwecken verwendet. Um ein Kontaktobjekt 

im Verwaltungstool Active Directory-Benutzer und -Computer zu erstellen, wechseln Sie 

zu dem Container, in dem Sie das Objekt erstellen möchten, klicken Sie mit der rechten Maustaste 

darauf, wählen Sie Neu, und klicken Sie auf Kontakt. Beim Erstellen eines Kontaktobjekts müssen Sie 

zumindest den vollständigen Namen angeben. Darüber hinaus können Sie beim Erstellen eines Kontaktobjekts 

zahlreiche Attribute des Objekts ausfüllen, einschließlich Telefonnummern und Adressen. 

Hinweis Sie können, wie auch bei Benutzerobjekten, den Standardanzeigenamen für Kontakte mithilfe 

des Tools Adsiedit.msc bearbeiten. Bearbeiten Sie für Kontakte das Attribut createDialog des Objekts 

CN=contact-Display anstelle des Objekts CN=user-Display. 

Kontakte sind in vielen Szenarien hilfreich. Sie können Kontakte zum einen verwenden, wenn ein 

Benutzer in Ihrer Domäne nicht als Sicherheitsprinzipal fungieren darf, seine Kontaktinformationen 

jedoch zugänglich sein müssen. In Ihrem Büro arbeiten beispielsweise Berater, die keine Netzwerkanmeldung 

vornehmen können, ihre Kontaktinformationen müssen jedoch an einem für alle Personen 

in Ihrem Unternehmen einfach zugänglichen Ort gespeichert werden. Zum anderen können Sie Kontakte 

zum Freigeben von Informationen zwischen Gesamtstrukturen verwenden. Ihr Unternehmen hat 

beispielsweise mit einem anderen Unternehmen fusioniert, das Active Directory bereits einsetzt. Sie 

können zwischen den beiden Gesamtstrukturen gesamtstrukturübergreifende Vertrauensstellungen 

erstellen, sodass Sie Netzwerkressourcen freigeben können. Der globale Katalog (Global Catalog, 

GC) umfasst jedoch weiterhin nur die Konten für die einzelne Gesamtstruktur. Möglicherweise müssen 

einige oder alle Konten beider Gesamtstrukturen von den Benutzern angezeigt werden können.


Sie können hierfür mithilfe eines Tools wie Microsoft Identity Integration Server (MIIS) 2003 oder 

Microsoft Identity Lifecycle Manager (ILM) 2007 ein Kontaktobjekt für jedes Benutzerkonto der 

anderen Gesamtstruktur erstellen und das Kontaktobjekt mit den geeigneten Kontaktinformationen 

auffüllen. 

Weitere Informationen Weitere Informationen zu ILM 2007 werden auf der Webseite „Microsoft Identity 

Lifecycle Manager 2007“ (in englischer Sprache) unter http://www.microsoft.com/windowsserver/ilm2007/ 

default.mspx bereitgestellt. 

Am häufigsten werden Kontaktobjekte für die Integration in die globale Adressliste von Microsoft 

Exchange Server verwendet. Wenn Sie ein Kontaktobjekt für E-Mails aktivieren möchten, weisen Sie 

dem Konto eine E-Mail-Adresse zu. Die zugewiesene E-Mail-Adresse gilt für ein externes E-Mail- 

System, wie beispielsweise einen Internetdienstanbieter oder eine andere Organisation. Dieser E- 

Mail-aktivierte Kontakt wird in der globalen Adressliste von Exchange Server angezeigt. Wenn Sie 

dem Kontakt eine E-Mail senden, wird diese an die im Kontakt angegebene E-Mail-Adresse gesendet. 

Dienstkonten 

Bei Diensten handelt es sich um Computerprogramme, die auf Windows-Servern im Hintergrund ausgeführt 

werden. Da Dienste so konzipiert sind, dass sie ohne Benutzeroberfläche ausgeführt werden 

und ohne dass Benutzer daran angemeldet sind, muss ein Anmeldekonto für den Dienst bereitgestellt 

werden. Wenn der Dienst startet, führt er mit dem Anmeldekonto eine Authentifizierung durch und 

verfügt über die gleichen Berechtigungen für Ressourcen wie das Anmeldekonto. Beim Festlegen 

eines Anmeldekontos auf einem Domänencontroller (Domain Controller, DC) können Sie ein 

bestimmtes Benutzerkonto in Active Directory oder einen lokalen Benutzer angeben. Dann würden 

Sie dem angegebenen Benutzerkonto die erforderlichen Berechtigungen zuweisen, sodass der Dienst 

ordnungsgemäß ausgeführt werden kann. 

In Windows Server 2008 sind einige lokale Konten integriert, die eigens zum Ausführen von Diensten 

entworfen wurden. Diese Konten verfügen über die Berechtigungen, die in der Regel von diesen 

Diensten für die Ausführung benötigt werden. Es können keine Kennwörter für diese Konten konfiguriert 

werden. In Tabelle 10.3 werden häufig verwendete Dienstkonten aufgeführt. 

Tabelle 10.3 

Häufig verwendete Dienstkonten 

Lokaler Kontoname 

SYSTEM 

LOKALER DIENST 

NETZWERKDIENST 

Beschreibung 

Dieses Konto verfügt über volle Zugriffsrechte für den Computer und kann mithilfe der dem 

Computerkonto zugewiesenen Berechtigungen auf Netzwerkressourcen zugreifen. Auf einem 

DC hat dieses Konto Zugriff auf die gesamte Domäne. Die Nutzung dieses Kontos sollte 

weitestgehend vermieden werden. 

Die Zugriffsebene dieses Kontos entspricht der Zugriffsebene der integrierten Gruppe Benutzer. 

Der Zugriff auf Netzwerkressourcen wird über eine Nullsitzung, d.h. anonym vorgenommen. 

Bei diesem Konto handelt es sich um das für die Dienstausführung bevorzugte Konto, 

da es nur über eingeschränkte Berechtigungen verfügt. 

Dieses Konto verfügt über die gleichen Zugriffsberechtigungen auf lokale Ressourcen wie 

das Konto LOKALER DIENST. Der Zugriff auf Netzwerkressourcen wird jedoch über die dem 

Computerkonto zugewiesenen Berechtigungen bestimmt.


Verwalten von Gruppen 

Eine der wichtigsten Funktionen eines Verzeichnisdienstes wie Active Directory ist es, die Autorisierung 

für den Zugriff auf Netzwerkressourcen bereitzustellen. Letztendlich basiert der gesamte Zugriff 

auf Netzwerkressourcen auf den einzelnen Benutzerkonten. In den meisten Fällen empfiehlt es sich 

jedoch nicht, den Ressourcenzugriff in den einzelnen Benutzerkonten zu verwalten. In einem großen 

Unternehmen wäre ein solches Vorgehen mit einem immensen Verwaltungsaufwand verbunden. 

Darüber hinaus ließen sich die Zugriffssteuerungslisten (Access Control Lists, ACLs) für Netzwerkressourcen 

innerhalb kürzester Zeit nicht mehr verwalten, wenn Berechtigungen über einzelne Benutzerkonten 

zugewiesen würden. Da der Zugriff auf Netzwerkressourcen mithilfe einzelner Benutzerkonten 

nicht verwaltet werden kann, erstellen Sie Gruppenobjekte, um große Sammlungen von 

Benutzern gleichzeitig verwalten zu können. 

Gruppentypen 

In Windows Server 2008 werden vier Gruppentypen bereitgestellt. Bei Verteilergruppen und Sicherheitsgruppen 

handelt es sich um die in der Regel von Administratoren verwendeten Gruppentypen. 

Anwendungsbasisgruppen und LDAP-Abfragegruppen werden von Autorisierungs-Manager-Anwendungen 

verwendet. Beim Erstellen eines neuen Gruppenobjekts mithilfe des Verwaltungstools Active 

Directory-Benutzer und -Computer haben Sie die Möglichkeit, eine Verteilergruppe oder eine Sicherheitsgruppe 

zu erstellen. Das entsprechende Dialogfeld wird in Abbildung 10.5 dargestellt. 


Erstellen einer neuen Gruppe im Verwaltungstool Active Directory-Benutzer und -Computer 

Am häufigsten wird in Active Directory die Sicherheitsgruppe verwendet. Bei einer Sicherheitsgruppe 

handelt es sich um einen Sicherheitsprinzipal, der für die Zuweisung von Berechtigungen auf 

Netzwerkressourcen verwendet werden kann. Bei einer Verteilergruppe kann es sich nicht um einen 

Sicherheitsprinzipal handeln. Da Verteilergruppen nicht für die Zuweisung von Ressourcenzugriff 

verwendet werden können, bieten sie nur einen sehr eingeschränkten Nutzen. Am häufigsten werden 

Verteilergruppen bei der Installation von Microsoft Exchange Server verwendet, wenn Benutzer gruppiert 

werden müssen, sodass einer gesamten Gruppe eine E-Mail gesendet werden kann.

Verwalten von Gruppen 361 

Wenn Sie Microsoft Exchange Server installiert haben, können Sie die Verteilergruppe für E-Mails 

aktivieren und anschließend können Sie der Gruppe Benutzer und Kontakte hinzufügen, die E-Mails 

empfangen können. So können Sie E-Mails an die vollständige Benutzergruppe senden. 

Wenn für die Domänenfunktionsebene mindestens Windows 2000 einheitlich festgelegt ist, können 

Sie Verteilergruppen in Sicherheitsgruppen und Sicherheitsgruppen in Verteilergruppen konvertieren. 

Die Gruppenmitgliedschaften werden nach einer Konvertierung beibehalten. 

Autorisierungs-Manager-Anwendungsgruppen 

Der Autorisierungs-Manager wurde in Windows Server 2003 eingeführt, um rollenbasierte Autorisierungen 

innerhalb von Anwendungen gewähren zu können. Dieses System wird von Anwendungsentwicklern 

für die Steuerung des Zugriffs auf Anwendungsdaten und -funktionen verwendet. Es wird 

nicht von Netzwerkadministratoren für die Steuerung des Zugriffs auf Netzwerkressourcen verwendet. 

Der Autorisierungs-Manager unterstützt die Verwendung von Active Directory, Active Directory 

Lightweight Directory Server oder .xml-Dateien als Datenspeicher. Um Active Directory als Speicherort 

für den Autorisierungs-Manager zu verwenden, muss für die Domänenfunktionsebene Windows 

Server 2003 festgelegt sein. Bei den beiden Gruppentypen im Autorisierungs-Manager handelt 

es sich um Anwendungsbasisgruppen und LDAP-Abfragegruppen. 

Bei Anwendungsbasisgruppen handelt es sich um eine Sammlung von Sicherheitsprinzipalen, die 

über eine Liste mit Mitgliedern und eine Liste mit Nicht-Mitgliedern verfügen. Die Liste mit Nicht- 

Mitgliedern wird als Alternative zum Verweigern von Berechtigungen verwendet. Die Überprüfung 

der Mitgliedschaft erfolgt für Anwendungsbasisgruppen beim Zugriff auf eine Ressource, nicht bei 

Anmeldung des Benutzers. Dadurch entsteht zwar eine höhere Serverlast, Änderungen an der Gruppenmitgliedschaft 

werden jedoch übernommen, ohne dass dafür ein Abmeldevorgang erforderlich ist. 

LDAP-Abfragegruppen verfügen über eine dynamische Mitgliedsliste, die auf einer LDAP-Abfrage 

basiert. Die Abfrage kann für jedes beliebige, in Active Directory verfügbare Benutzerattribut durchgeführt 

werden. Dadurch ergibt sich der Vorteil, dass die Gruppenmitgliedschaft bei einer Änderung 

der Benutzereigenschaften automatisch aktualisiert wird. Die Überprüfung der Mitgliedschaft in 

LDAP-Abfragegruppen wird beim Zugriff auf eine Ressource durchgeführt. 

Weitere Informationen Weitere Informationen zum Autorisierungs-Manager werden im Artikel „Role- 

Based Access Control for Multi-tier Applications Using Authorization Manager“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver/en/library/72b55950-86cc-4c7f-8fbf-3063276cd0b61033.mspx 


Hinweis Da Verteilergruppen in Active Directory nur einen eingeschränkten Nutzen bieten, beziehen sich 

die folgenden Erläuterungen in diesem Kapitel auf Sicherheitsgruppen. 

Gruppenbereich 

In Windows Server 2008 Active Directory können Sie Gruppen mit drei unterschiedlichen Gruppenbereichen 

erstellen: Global, Lokal (in Domäne) und Universal. In Tabelle 10.4 werden die Merkmale 

der einzelnen Gruppenbereiche aufgeführt.


Hinweis Universelle Gruppen sind nur dann verfügbar, wenn für die Domänenfunktionsebene mindestens 

Windows 2000 einheitlich festgelegt ist. Bei verschachtelten Gruppen handelt es sich um Gruppen, die Mitglieder 

anderer Gruppen sind. Die für verschachtelte Gruppen verfügbaren Optionen richten sich nach der 

Domänenfunktionsebene. Sie können beispielsweise mit jeder beliebigen Funktionsebene globale Gruppen 

in eine domänenlokale Gruppe verschachteln, um jedoch eine globale Gruppe in eine weitere globale 

Gruppe zu verschachteln, muss für die Domänenfunktionsebene mindestens Windows 2000 einheitlich 

festgelegt sein. 

Um für domänenlokale Gruppen die volle Funktionsfähigkeit sicherzustellen, muss für die Domänenfunktionsebene 

mindestens Windows 2000 einheitlich festgelegt sein. Wenn für die Domänenfunktionsebene 

Windows 2000 gemischt festgelegt ist, können domänenlokale Gruppen nur wie lokale 

Gruppen auf Domänencontrollern in Windows NT 4 ausgeführt werden. Die Gruppe kann zum 

Zuweisen von Ressourcenberechtigungen auf Domänencontrollern, nicht jedoch auf anderen Computern 

in der Domäne verwendet werden. Wenn für die Domänenfunktionsebene mindestens Windows 

2000 einheitlich festgelegt wurde, können domänenlokale Gruppen für die Erteilung von Zugriff auf 

Ressourcen auf jedem beliebigen Windows-Server in der Domäne verwendet werden. 

Tabelle 10.4 

Active Directory-Gruppenbereiche 

Gruppenbereich 

Lokal (in Domäne) 

Global 

Universal 

Gruppenmitgliedschaft kann folgende 

Komponenten umfassen 

• Benutzerkonten von jeder beliebigen 

Domäne in der Gesamtstruktur 

• Globale oder universelle Gruppen von jeder 

beliebigen Domäne in der Gesamtstruktur 

• Benutzerkonten oder globale oder universelle 

Gruppen von jeder beliebigen Domäne 

in einer vertrauten Gesamtstruktur 

• Verschachtelte domänenlokale Gruppen 

von der lokalen Domäne 

• Benutzerkonten von der Domäne, in der die 

Gruppe erstellt wurde 

• Verschachtelte globale Gruppen von der 

gleichen Domäne 

• Benutzerkonten von jeder beliebigen 


• Globale Gruppen von jeder beliebigen 


• Verschachtelte universelle Gruppen von 

jeder beliebigen Domäne in der Gesamtstruktur 

Verwendungszweck 

• Zum Zuweisen von Zugriff auf Ressourcen 

in der lokalen Domäne 

• Auf allen Servern in der Domäne, auf 

denen Windows 2000, Windows Server 

2003 oder Windows Server 2008 ausgeführt 

wird 


in allen Domänen in der Gesamtstruktur 

oder zwischen vertrauten Gesamtstrukturen 

• Auf allen Mitgliedsservern, auf denen Windows 

ausgeführt wird, einschließlich Mitgliedsservern, 

auf denen Windows NT 

ausgeführt wird 


in allen Domänen in der Gesamtstruktur 

oder zwischen vertrauten Gesamtstrukturen 

• Auf allen Servern in der Domäne, auf 

denen Windows 2000, Windows Server 

2003 oder Windows Server 2008 ausgeführt 

wird


Hinweis Die Verwendungsweise von Gruppen richtet sich nach den in Ihrer Umgebung bereitgestellten 

Servern. Wenn Ihre Domäne nur Server umfasst, auf denen Windows 2000 und Windows Server 2003 ausgeführt 

wird, können Sie für die Zuweisung von Berechtigungen für alle Ressourcen auf diesen Servern 

domänenlokale Gruppen verwenden. Sie können auf diesen Mitgliedsservern jedoch weiterhin lokale Gruppen 

verwenden. Beachten Sie, dass Sie auf Servern, auf denen Windows NT ausgeführt wird, weiterhin 

lokale Gruppen verwenden müssen. Lokale Gruppen können in jedem Fall globale Gruppen von jeder beliebigen 

Domäne in der Gesamtstruktur umfassen. Wenn Sie lokale Gruppen auf einem Sever erstellen, auf 

dem Windows 2000 oder Windows Server 2003 ausgeführt wird, können die Gruppen auch universelle 

Gruppen von jeder beliebigen Domäne in der Gesamtstruktur oder von einer vertrauten Gesamtstruktur 

umfassen. 

Die Funktionalität von globalen Gruppen hat sich von Windows 2000 Active Directory zu Windows 

Server 2008 Active Directory nicht verändert. Wenn für die Domänenfunktionsebene mindestens 

Windows 2000 einheitlich festgelegt wurde, können Sie globale Gruppen von der gleichen 

Domäne in andere globale Gruppen verschachteln. Das Verschachteln von Gruppen ist hilfreich, um 

mehrere Gruppenmitgliedschaften zu umgehen. Ihr Unternehmen ist beispielsweise in mehrere 

Geschäftseinheiten gegliedert, wobei jede eine Gruppe mit Vorgesetzten und leitenden Angestellten 

umfasst. Sie können eine globale Gruppe Vorgesetzte für jede Geschäftseinheit erstellen und diese 

globalen Gruppen anschließend in einer unternehmensweiten Gruppe Vorgesetzte verschachteln. 

Hinweis Wenn für Ihre Domänenfunktionsebene weiterhin Windows 2000 einheitlich oder Windows 2000 

gemischt festgelegt ist, sollten Sie die Gruppenmitgliedschaft auf maximal 5000 Benutzer beschränken, um 

mögliche Replikationsprobleme zu vermeiden. Durch das Verschachteln von Gruppen treten diese Probleme 

seltener auf. Gelöst werden sie durch ein aktualisiertes Verfahren für die Replikation verknüpfter 

Werte, wenn die Domänenfunktionsebene auf Windows Server 2003 heraufgestuft wird. 

Universelle Gruppen weisen in Active Directory die größte Flexibilität auf, jedoch sind damit auch 

Nachteile verbunden. Universelle Gruppen können Mitglieder von jeder Domäne in der Gesamtstruktur 

umfassen, und sie können zum Zuweisen von Berechtigungen für Ressourcen in jeder beliebigen 

Domäne in der Gesamtstruktur verwendet werden. Um dies zu ermöglichen, wird die Mitgliedsliste 

für alle universellen Gruppen im globalen Katalog (Global Catalog, GC) gespeichert. Die Mitgliedsliste 

wird als einzelnes Attribut im GC gespeichert. Wenn Ihre Domäne mit der Funktionsebene Windows 

2000 einheitlich ausgeführt wird, bedeutet dies, dass bei jedem Hinzufügen eines Mitglieds zur 

universellen Gruppe die Replikation der vollständigen Mitgliedsliste auf alle weiteren globalen Katalogserver 

erforderlich ist. Dies kann zu einem erheblichen Replikationsaufwand führen, wenn die 

universelle Gruppe Tausende Mitglieder umfasst. Wenn für die Domänenfunktionsebene mindestens 

Windows Server 2003 festgelegt wurde, können Sie dieses Problem durch die Replikation verknüpfter 

Werte lösen. 

Durch die Replikation verknüpfter Werte wird der Replikationsdatenverkehr für verknüpfte Mehrwertattribute 

reduziert. Gruppenmitgliedslisten sind ein Beispiel für verknüpfte Mehrwertattribute. 

Bei jedem Gruppenmitglied handelt es sich um einen Wert im Mitgliedschaftsattribut für die Gruppe. 

Bei der Replikation verknüpfter Werte werden nur die Änderungen an einem verknüpften Mehrwertattribut 

repliziert. Im Fall von Änderungen an der Gruppenmitgliedschaft bedeutet dies, dass nur 

die Aktualisierungen der Gruppenmitgliedschaft und nicht die gesamte Gruppenmitgliedsliste repliziert 

werden.


Wenn für die Domänenfunktionsebene Windows 2000 einheitlich oder eine höhere Funktionsebene 

festgelegt ist, wirken sich universelle Gruppen auch auf das Anmeldeverfahren aus. Während der 

Authentifizierung kommuniziert der die Authentifizierung durchführende DC mit dem globalen Katalogserver, 

um die Mitgliedschaft in universellen Gruppen zu überprüfen. Diese Kommunikation ist 

erforderlich, da der DC nicht über die Mitgliedslisten der universellen Gruppen verfügt, die sich in 

anderen Domänen befinden. Wenn auf dem DC Windows 2000 Server ausgeführt wird und er keine 

Verbindung mit einem globalen Katalog herstellen kann, führt der DC keine Authentifizierung für den 

Benutzer durch, und es werden die zwischengespeicherten Anmeldeinformationen der Arbeitsstation 

verwendet. Befinden sich keine zwischengespeicherten Anmeldeinformationen auf der Arbeitsstation, 

kann sich der Benutzer nicht an der Domäne anmelden. 

Wenn auf einem DC Windows Server 2008 oder Windows Server 2003 ausgeführt wird, kann der DC 

universelle Gruppenmitgliedschaften im Zwischenspeicher speichern. Wurde die Option Zwischenspeichern 

der universellen Gruppenmitgliedschaft aktiviert, führt der DC eine Zwischenspeicherung 

der SIDs universeller und globaler Gruppen im Attribut msDS-Cached-Membership von Benutzerund 

Computerobjekten durch. Die Zwischenspeicherung erfolgt bei der ersten Benutzeranmeldung. 

Nach der ersten Anmeldung werden die zwischengespeicherten Anmeldeinformationen bei der 

Authentifizierung verwendet, daher ist kein Lookup im globalen Katalog erforderlich. Die Anmeldung 

ist nicht davon betroffen, wenn ein globaler Katalog nicht verfügbar ist. Wenn ein Benutzer sich 

zuvor nicht an der Domäne angemeldet hat und ein globaler Katalog nicht verfügbar ist, kann der 

Benutzer keine Anmeldung an der Domäne durchführen. 

Hinweis Die Option Zwischenspeichern der universellen Gruppenmitgliedschaft steht auf allen Domänenfunktionsebenen 

zur Verfügung. Allerdings muss dieses Feature mithilfe des Verwaltungstools Active Directory-Standorte 

und -Dienste für jeden Active Directory-Standort aktiviert werden. 

Standardmäßig werden die zwischengespeicherten Gruppenmitgliedschaftsinformationen alle acht 

Stunden aktualisiert. Daher werden Änderungen an der Mitgliedschaft in universellen oder globalen 

Gruppen unter Umständen erst nach acht Stunden wirksam. Für einen einzelnen Benutzer können Sie 

mithilfe des ADSI-Editors die Akutalisierung der zwischengespeicherten Informationen bei der 

nächsten Anmeldung erzwingen. Hierfür müssen die Festlegungen der Attribute msDS-Cached- 

Membership und msDS-Cached-Membership-Timestamp entfernt werden. 

Achtung Wenn die zwischengespeicherten Informationen zur Mitgliedschaft in universellen Gruppen sieben 

Tage lang nicht aktualisiert werden kann, werden die Informationen als veraltet betrachtet und nicht 

mehr verwendet. In diesem Fall wird die Anmeldung so durchgeführt, als lägen keine zwischengespeicherten 

Informationen vor, und während der Anmeldung ist ein globaler Katalog erforderlich. 

Durch den Neustart eines Domänencontrollers wird für den Zwischenspeicher der Neustart des Aktualisierungsintervalls 

erzwungen, und dabei werden alle zwischengespeicherten Gruppenmitgliedschaften 

aktualisiert. Von diesem Neustart können jedoch unter Umständen zahlreiche Dienste in 

Ihrem Netzwerk betroffen sein, daher sollte er weitestgehend vermieden werden. Um die zwischengespeicherten 

Informationen zu Gruppenmitgliedschaften zu aktualisieren, ohne den Domänencontroller 

dafür erneut zu starten, können Sie für das Vorgangsattribut updateCachedmemberships des 

Objekts rootDSE mithilfe des Tools Ldp.exe den Wert 1 festlegen. Beide genannten Methoden müssen 

auf allen Domänencontrollern in einem Active Directory-Standort durchgeführt werden, um konsistente 

Ergebnisse zu erzielen.

Standardgruppen in Active Directory 


Weitere Informationen Weitere Informationen zur Zwischenspeicherung von Informationen zu universellen 

Gruppenmitgliedschaften, einschließlich Registrierungseinträgen, die zum Ändern des Standardaktualisierungsverhaltens 

verwendet werden können, werden im Artikel „How the Global Catalog Works” (in 

englischer Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/440e44ab-ea05-4bd8- 

a68c-12cf8fb1af501033.mspx?mfr=true bereitgestellt. 

Windows Server 2003 Active Directory umfasst viele Standardgruppen in den beiden Containern 

Users und Builtin. Diese Gruppen können für vielerlei Zwecke verwendet werden, und sie verfügen 

über Standardberechtigungen innerhalb der Domäne. Gruppen im Container Builtin entsprechen den 

lokalen vordefinierten Gruppen, die auf Mitgliedsservern vorhanden sind. Auf Mitgliedsservern werden 

Mitgliedern über diese Gruppen Berechtigungen für den lokalen Server erteilt. In Active Directory 

werden den Mitgliedern dieser Gruppen Berechtigungen für alle Domänencontroller in der 

Domäne erteilt. In Tabelle 10.5 werden die vordefinierten Gruppen für Active Directory aufgeführt. 

Tabelle 10.5 

Vordefinierte Gruppen in Active Directory 

Gruppen 


Benutzer 

Distributed COM-Benutzer 


Ereignisprotokollleser 

Erstellungen eingehender Gesamtstrukturvertrauensstellung 

Gäste 

IIS_IUSRS 


Kryptografie-Operatoren 

Leistungsprotokollbenutzer 

Netzwerkkonfigurations-Operatoren 

Prä-Windows 2000 kompatibler Zugriff 

Beschreibung 

Mitglieder haben uneingeschränkten Zugriff auf die Domäne. 

Mitglieder können die meisten Anwendungen ausführen, sie können jedoch die meisten 

systemweiten Änderungen auf Domänencontrollern in der Domäne nicht durchführen. 

Mitglieder können DCOM-Objekte auf Domänencontrollern in der Domäne starten, 

verwenden und aktivieren. 

Mitglieder können Drucker auf Domänencontrollern in der Domäne verwalten. 

Mitglieder können Ereignisprotokolle auf Domänencontrollern in der Domäne lesen. 

Mitglieder können eingehende unidirektionale Vertrauensstellungen für diese 

Gesamtstruktur erstellen. 

Mitglieder verfügen über den gleichen Zugriff wie die Benutzergruppen. Das Konto 

Gäste weist allerdings die Einschränkung auf, dass es ein Mitglied der Gruppe Jeder, 

jedoch kein Mitglied der Gruppe Authentifizierte Benutzer ist. 

Dieses Konto wird von IIS zum Anwenden von Berechtigungen für anonymen Zugriff 

verwendet. 

Mitglieder können Domänenbenutzer-, Gruppen- und Computerkonten in der Domäne 

verwalten. Sie können jedoch nicht die Gruppen Administratoren oder Domänen- 

Admins, das Administratorkonto oder Computerkonten in der OU Domain Controllers 

bearbeiten. 

Mitglieder können kryptografische Operationen durchführen. 

Mitglieder können Daten zu Leistungsindikatoren protokollieren, Ablaufverfolgungsanbieter 

aktivieren und Ereignisablaufverfolgungen auf Domänencontrollern in der 

Domäne sammeln. 

Mitglieder können einige Netzwerkfeatures auf Domänencontrollern in der Domäne 


Mitglieder haben Lesezugriff für alle Benutzer und Gruppen in der Domäne. Diese 

Gruppe wird für die Abwärtskompatibilität mit Windows NT-Servern verwendet.


Tabelle 10.5 

Vordefinierte Gruppen in Active Directory (Fortsetzung) 

Gruppen 

Remotedesktopbenutzer 

Replikations-Operator 



Systemmonitorbenutzer 

Terminalserver-Lizenzserver 

Windows-Autorisierungszugriffsgruppe 

Zertifikatdienst-DCOM-Zugriff 

Beschreibung 

Mitglieder können sich mithilfe von Remotedesktop auf Domänencontrollern in der 

Domäne anmelden. 

Diese Gruppe wird für die Unterstützung der Dateireplikation in der Domäne 

verwendet. 

Mitglieder können Domänencontroller in der Domäne verwalten. 

Mitglieder können unabhängig von ihren Sicherheitsberechtigungen Dateien auf 

Domänencontrollern sichern und wiederherstellen. 

Mitglieder können Daten zu Leistungsindikatoren auf Domänencontrollern in der 

Domäne anzeigen. 

Diese Gruppe wird verwendet, um die Nachverfolgung der Auslastung von Terminalserver-Clientzugriffstoken 

(pro Benutzer) zu unterstützen. 

Mitglieder haben Zugriff auf das Attribut tokenGroupsGlobalAndUniversal von Benutzerobjekten. 

Mitglieder können Verbindungen mit Zertifizierungsstellen in der Domäne herstellen. 

Die Standardgruppen im Container Users werden für die Zuweisung von Rechten und Berechtigungen 

für Active Directory und Domänenressourcen verwendet. Die Standardgruppen im Container 

Users werden in Tabelle 10.6 aufgeführt. 

Tabelle 10.6 

Active Directory-Standardgruppen im Container Users 

Gruppen 

Abgelehnte RODC-Kennwortreplikationsgruppe 

DnsAdmins 

DnsUpdateProxy 

Domänen-Admins 

Domänen-Benutzer 

Domänen-Gäste 

Domänencomputer 


Domänencontroller der Organisation 

ohne Schreibzugriff 

Domänencontroller ohne Schreibzugriff 

Organisations-Admins 

RAS- und IAS-Server 

Richtlinien-Ersteller-Besitzer 

Beschreibung 

Mitglieder können ihre Kennwörter nicht auf schreibgeschützte Domänencontroller 

replizieren. 

Mitglieder können DNS-Objekte in der Domäne verwalten. 

Mitglieder können dynamische DNS-Aktualisierungen im Namen anderer Clients 

durchführen. In der Regel sind die Mitglieder DHCP-Server. 

Mitglieder können Domänenobjekte in Active Directory und alle der Domäne hinzugefügten 

Domänencontroller und Computer verwalten. Diese Gruppe ist Mitglied 

aller lokalen Administratorengruppen in der Domäne. 

Diese Gruppe ist Mitglied aller lokalen Benutzergruppen in der Domäne. 

Diese Gruppe ist Mitglied aller lokalen Gästegruppen in der Domäne. 

Alle Arbeitsstationen und Mitgliedsserver in der Domäne. 

Alle Domänencontroller in der Domäne. 

Alle schreibgeschützten Domänencontroller in der Gesamtstruktur. 

Alle schreibgeschützten Domänencontroller in der Domäne. 

Mitglieder verfügen über Administratorrechte für die vollständige Active Directory- 

Gesamtstruktur. 

Server in dieser Gruppe können die Remotezugriffseigenschaften von Benutzern 

lesen. 

Mitglieder können Gruppenrichtlinienobjekte in der Domäne erstellen und bearbeiten.


Tabelle 10.6 

Active Directory-Standardgruppen im Container Users (Fortsetzung) 

Gruppen 

Schema-Admins 

Zertifikatherausgeber 

Zulässige RODC-Kennwortreplikationsgruppe 

Beschreibung 

Mitglieder können Änderungen am Schema für die Gesamtstruktur vornehmen. 

Mitglieder können Zertifikate in Active Directory veröffentlichen. 

Mitglieder können ihre Kennwörter auf schreibgeschützte Domänencontroller replizieren. 

Es gibt nur wenige Gruppen, die beim Erstellen einer neuen Domäne bereits Benutzer umfassen. Das 

Domänenadministratorkonto ist Mitglied der domänenlokalen Administratorengruppe und der globalen 

Gruppe Domänen-Admins. Wenn es sich bei der Domäne um die erste Domäne in der Gesamtstruktur 

handelt, wird das Administratorkonto ebenfalls den globalen Gruppen Organisations-Admins und 

Schema-Admins hinzugefügt. Das Gastkonto ist deaktiviert, es ist jedoch Mitglied der globalen 

Gruppe Domänen-Gäste. Alle neuen Benutzer werden automatisch der Gruppe Domänen-Benutzer 

hinzugefügt. 

Weitere Informationen Eine umfangreiche Liste mit den Benutzerberechtigungen, die jeder 

Standardgruppe erteilt werden, finden Sie im Artikel „Default Groups“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver/en/library/1631acad-ef34-4f77-9c2e- 

94a62f8846cf1033.mspx?mfr=true. 

Spezialidentitäten 

Bei Spezialidentitäten handelt es sich um Gruppen mit dynamischen Mitgliedschaften, die von dem 

jeweiligen Benutzer abhängig sind. Die Mitgliedschaft in diesen Gruppen wird automatisch durch das 

System verwaltet, und Sie können daran keine Änderungen vornehmen. Sie können diesen Gruppen 

jedoch Rechte und Berechtigungen zuweisen. Auf diese Spezialidentitäten findet das Konzept des 

Gruppenbereichs keine Anwendung. Einige Spezialidentitäten werden in Tabelle 10.7 aufgeführt. 

Tabelle 10.7 

Spezialidentitäten 

Spezialidentität 

ANONYMOUS-ANMELDUNG 

Authentifizierte Benutzer 

INTERAKTIV 

Jeder 

NETZWERK 

TERMINALSERVERBENUTZER 

Definition 

Benutzer oder Dienste, die nicht mit einem Kontonamen angemeldet sind 

Alle Benutzer der lokalen Domäne und von Remotedomänen, mit Ausnahme des 

Gastkontos 

Alle Benutzer, die logisch am Computer angemeldet sind 

Alle Benutzer der lokalen Domäne, anderer Domänen sowie Gäste. Diese Spezialidentität 

umfasst nicht die Mitglieder der Spezialidentität ANONYMOUS- 

ANMELDUNG. 

Alle Benutzer, die über das Netzwerk auf den Computer zugreifen 

Alle Benutzer, die mithilfe von Remotedesktop über das Netzwerk angemeldet sind 

Erstellen eines Sicherheitsgruppenentwurfs 

Eine der umfangreichen Entwurfskomponenten einer Active Directory-Implementierung ist der 

Sicherheitsgruppenentwurf. Mit dem Erstellen eines Sicherheitsgruppenentwurfs ist vor allem in 

großen Organisationen ein großer Aufwand verbunden. In diesem Abschnitt werden die grundlegenden 

Prinzipien für die Erstellung eines Sicherheitsgruppenentwurfs für Ihre Organisation erläutert.


Als Erstes müssen Sie beim Erstellen eines Sicherheitsgruppenentwurfs festlegen, welche Gruppenbereiche 

Sie verwenden möchten. In vielen Unternehmen werden umfassende Diskussionen zur Verwendung 

der unterschiedlichen Gruppen geführt. Die Verwendung von Gruppen kann in Active 

Directory sehr flexibel gehandhabt werden. In einer einzelnen Domäne können Benutzer beispielsweise 

einer Gruppe mit einem beliebigen Gruppenbereich in der Domäne hinzugefügt werden, und 

die Gruppen können zum Zuweisen von Berechtigungen für beliebige Ressourcen in der Domäne verwendet 

werden. In einer Umgebung mit mehreren Domänen gibt es verschiedene Optionen für die 

Verwendung universeller, globaler und domänenlokaler Gruppen. 

In den meisten Unternehmen können die unterschiedlichen Gruppenbereiche am besten anhand der 

folgenden Schritte implementiert werden: 

1. Hinzufügen von Benutzern zu globalen oder universellen Gruppen 

2. Hinzufügen der globalen oder universellen Gruppen zu domänenlokalen Gruppen 

3. Zuweisen von Zugriffsberechtigungen auf Ressourcen mithilfe der domänenlokalen Gruppen 

In einigen Unternehmen gibt es viel Widerstand gegen die Erstellung von sowohl einer domänenlokalen 

als auch einer globalen oder universellen Gruppe, wenn eine Gruppe eigentlich ausreichend wäre. 

Es sprechen jedoch wichtige Gründe für die Verwendung von zwei Gruppen. 

Wenn Sie den Ansatz der Verwendung globaler oder universeller Gruppen und domänenlokaler Gruppen 

verfolgen, können Sie globale oder universelle Gruppen erstellen, um Benutzer zusammenzufassen, 

die gemeinsame Merkmale aufweisen. Meist werden globale oder universelle Gruppen basierend 

auf einer Unternehmensabteilung oder einer funktionellen Grundlage erstellt. Alle Mitglieder der Vertriebsabteilung 

weisen beispielsweise in der Regel untereinander mehr gleiche Merkmale auf als mit 

Mitgliedern anderer Abteilungen. Diese Benutzer benötigen unter Umständen alle Zugriff auf die 

gleichen Ressourcen, oder alle benötigen die gleiche Software. Die Gruppenmitgliedschaft wird oftmals 

auch nach funktionellen Gesichtspunkten festgelegt. Es ist beispielsweise die gemeinsame Gruppierung 

aller Manager erforderlich, unabhängig davon, in welcher Geschäftseinheit sie beschäftigt 

sind. Alle Mitglieder eines Projektteams benötigen ggf. Zugriff auf die gleichen Projektressourcen. 

Domänenlokale Gruppen werden in der Regel vorwiegend für die Zuweisung von Ressourcenberechtigungen 

verwendet. In vielen Fällen sind die Berechtigungen eng mit den Geschäftseinheiten oder 

-funktionen verbunden. Alle Mitglieder der Vertriebsabteilung benötigen beispielsweise Zugriff auf 

den gleichen freigegebenen Ordner Vertrieb. In der Regel benötigen alle Projektteammitglieder 

Zugriff auf die gleichen Projektinformationen. In anderen Fällen werden Zugriffsberechtigungen über 

geschäftliche oder funktionelle Grenzen hinweg erteilt. Ein Unternehmen nutzt beispielsweise einen 

freigegebenen Ordner, für den alle Personen im Unternehmen über den Zugriff Lesen verfügen. Oder 

unterschiedliche Abteilungen und Projektteams benötigen unter Umständen Zugriff auf den gleichen 

freigegebenen Ordner. Durch das Erstellen einer domänenlokalen Gruppe für eine bestimmte Ressource 

können Sie den Zugriff auf diese Ressource einfach verwalten. Anschließend können Sie der 

domänenlokalen Gruppe die geeigneten globalen oder universellen Gruppen hinzufügen. 

Häufig sind für Benutzer unterschiedliche Zugriffsebenen auf freigegebene Ordner erforderlich. Ein 

Unternehmen verfügt z.B. über den freigegebenen Ordner Personalabteilung, in dem die gesamten 

Informationen zu Mitarbeiterrichtlinien gespeichert sind. Allen Benutzern kann Lesezugriff auf diesen 

Ordner erteilt werden, es sollten jedoch nur die Mitarbeiter der Personalabteilung Änderungen an 

den Informationen in diesem Ordner vornehmen können. In diesem Fall würden Sie zwei domänenlokale 

Gruppen für den freigegebenen Ordner erstellen. Einer Gruppe wird der Zugriff Lesen erteilt, 

während der anderen Gruppe der Vollzugriff oder der Zugriff Bearbeiten erteilt wird.


Die globale Gruppe Personalabteilung kann dann der domänenlokalen Gruppe hinzugefügt werden, 

der bereits der Vollzugriff zugewiesen wurde, und die übrigen globalen Gruppen, für die nur Lesezugriff 

erforderlich ist, können der domänenlokalen Gruppe mit dem Zugriff Lesen hinzugefügt werden. 

Wenn Sie globale und domänenlokale Gruppen auf diese Weise verwenden, bedeutet dies, dass Sie 

den Besitz der globalen und domänenlokalen Gruppen aufteilen. In großen Unternehmen ist es aus 

sicherheitstechnischer Sicht von großer Bedeutung, zu gewährleisten, dass nur den geeigneten Benutzern 

Zugriff auf freigegebene Informationen erteilt wird. Um dies sicherzustellen, muss jede Gruppe 

über einen Besitzer verfügen, der auch als autorisierender Benutzer bezeichnet wird. Nur der Besitzer 

einer Gruppe kann Änderungen an der Gruppenkonfiguration autorisieren. Bei dem Besitzer der globalen 

Gruppe handelt es sich in der Regel um einen Abteilungsadministrator. Als Besitzer einer projektbasierten 

globalen Gruppe wird unter Umständen der Projektmanager eingesetzt. Diese Besitzer 

sind die einzigen Personen, die Änderungen an der Mitgliedsliste autorisieren können. 

Bei dem Besitzer einer domänenlokalen Gruppe handelt es sich in der Regel um den Daten- oder Ressourcenbesitzer. 

Wenn jede Ressource in Ihrem Unternehmen über einen Besitzer verfügt, der als einzige 

Person Änderungen an den Berechtigungen für die freigegebene Ressource autorisieren kann, 

wird diese Person ebenfalls Besitzer der domänenlokalen Gruppe, die mit dieser Ressource verbunden 

ist. Bevor der domänenlokalen Gruppe eine beliebige globale oder universelle Gruppe hinzugefügt 

werden kann, ist die Zustimmung des Besitzers zu dieser Änderung erforderlich. 

Die Verwendung der beiden Gruppenebenen ist vor allem in Szenarien wichtig, in denen mehrere 

Domänen vorhanden sind und Benutzer aus allen Domänen Zugriff auf eine freigegebenen Ressource 

in einer Domäne benötigen. Wie in Abbildung 10.6 dargestellt, können Sie eine globale Gruppe in 

jeder Domäne erstellen und anschließend diese globale Gruppe einer domänenlokalen Gruppe in der 

Domäne hinzufügen, in der sich die Ressource befindet. 

Globale Gruppe 

Adatum.com 



NA.Adatum.com 

Freigegebener Freigegebener 

Ordner Ordner 


Globale 

Gruppe 

Abbildung 10.6 Konfigurieren von Ressourcenzugriff mithilfe von globalen und domänenlokalen Gruppen mit 

mehreren Domänen


Hinweis Windows NT verwendet zwar globale und lokale Gruppen, domänenlokale Gruppen können 

jedoch in Windows NT nicht verwendet werden. Wenn Sie in Ihrer Domäne über Mitgliedsserver verfügen, 

auf denen Windows NT ausgeführt wird, benötigen Sie weiterhin lokale Gruppen auf jedem Server. Wenn 

auf Ihren Servern Windows 2000, Windows Server 2003 oder Windows Server 2008 ausgeführt wird und für 

Ihre Domänenfunktionsebene mindestens Windows 2000 einheitlich festgelegt ist, sollten Sie nach Möglichkeit 

domänenlokale Gruppen verwenden. Domänenlokale Gruppen können über mehrere Server hinweg 

verwendet werden. Wenn Sie darüber hinaus domänenlokale Gruppen anstelle von lokalen Gruppen verwenden, 

können Sie eine Ressource zwischen Servern verschieben und die gleiche domänenlokale Gruppe 

zum Zuweisen von Berechtigungen verwenden. 

Beim Erstellen des Sicherheitsgruppenentwurfs müssen Sie sich die Frage stellen, wann globale 

Gruppen und wann universelle Gruppen zu verwenden sind. In manchen Fällen haben Sie keine Wahl. 

E-Mail-aktivierte Gruppen für Exchange 2000 Server und Exchange Server 2003 beispielsweise, die 

Mitglieder mehrerer Domänen umfassen, können nicht ordnungsgemäß verarbeitet werden, wenn sie 

keine universellen Gruppen sind. Exchange Server 2007 erstellt alle neuen E-Mail-aktivierten Gruppen 

als universelle Gruppen. 

In den meisten Fällen empfahl es sich beim Erstellen des universellen Gruppenentwurfs in Windows 

2000 Active Directory, universelle Gruppen nicht allzu häufig zu verwenden, vor allem wenn Standorte 

vorhanden waren, die über langsame Netzwerkverbindungen verfügten. Dies war bedingt durch 

Replikationsprobleme mit dem globalen Katalog. Wenn Ihre Gesamtstruktur auf Windows 2000- 

Funktionsebene ausgeführt wird, gilt diese Empfehlung weiterhin. Wenn für die Interimsfunktionsebene 

Ihrer Gesamtstruktur Windows Server 2003 oder Windows Server 2003 festgelegt wurde, 

besteht dieses Replikationsproblem nicht mehr, da die Replikation verknüpfter Werte implementiert 

wurde. Durch die Option Zwischenspeichern der universellen Gruppenmitgliedschaft muss nicht mehr 

in jedem Standort ein globaler Katalogserver bereitgestellt werden. Durch diese Verbesserungen ist es 

in Windows Server 2008 Active Directory weniger problematisch, sich für die Verwendung universeller 

oder globaler Gruppen zu entscheiden. Meist sind globale oder universelle Gruppen nahezu austauschbar. 

Verwalten von Computern 

Bei einem weiteren Objekttyp in Active Directory handelt es sich um das Computerobjekt. Computerobjekte 

werden verwendet, um Domänencontroller, Mitgliedsserver und Arbeitsstationen zu repräsentieren. 

Computer führen eine Authentifizierung an der Domäne mithilfe des Computerobjekts auf die 

gleiche Weise durch, wie Benutzer mithilfe von Benutzerobjekten eine Authentifizierung an der 

Domäne durchführen. Computerkonten ändern ihr Kennwort mit einem Hintergrundprozess automatisch 

alle 30 Tage. 

Hinweis Alle Computer, auf denen Windows NT, Windows 2000, Microsoft Windows XP Professional, 

Windows Server 2003, Windows Vista und Windows Server 2008 ausgeführt wird, müssen über ein Computerkonto 

in der Domäne verfügen. Computer, auf denen Microsoft Windows 95 oder Microsoft Windows 98 

ausgeführt wird, können in der Domäne nicht über Konten verfügen. 

Computerobjekte werden nur selten direkt in Active Directory verwaltet. Wenn Sie mit der rechten 

Maustaste auf ein Computerkonto in Active Directory klicken, können Sie sehen, dass nur wenige 

Verwaltungsoptionen angezeigt werden. Eine der verfügbaren Optionen ist die Option zum Zurücksetzen 

des Computerkontos.

Verwalten von Computern 371 

Diese Option sollte allerdings mit Vorsicht verwendet werden, da durch das Zurücksetzen eines Computerkontos 

die Verbindung des Computers mit der Domäne unterbrochen wird und dadurch ein 

erneutes Hinzufügen des Computers zur Domäne erforderlich wird. Stellen Sie vor dem Zurücksetzen 

des Computerkontos sicher, dass das Computerkonto nicht deaktiviert ist. Wenn ein Computerkonto 

deaktiviert ist, kann der Computer keine Anmeldung an der Domäne durchführen. 

Die Option zum Zurücksetzen eines Computerkontos ist nützlich, wenn keine fehlerfreie Kommunikation 

zwischen dem Computer und der Domäne möglich ist. Dies kann beispielsweise vorkommen, 

wenn das Computerkonto und der Computer nicht über das gleiche Kennwort verfügen. Diese fehlende 

Kennwortübereinstimmung kann auf Kommunikationsfehler nach einer Notfallwiederherstellung 

zurückzuführen sein. Wenn Sie das Computerkonto zurücksetzen und den Computer anschließend 

wieder zur Domäne hinzufügen, wird das Kennwort wieder synchronisiert. Dieses Verfahren 

kann nicht für Domänencontroller angewendet werden, da Domänencontroller nicht erneut zur Domäne 

hinzugefügt werden können. Es ist einfacher, das Dienstprogramm Netdom.exe für diesen Zweck 

zu verwenden, da es sowohl für Mitgliedsserver als auch für Domänencontroller funktioniert. Mithilfe 

des Dienstprogramms Netdom.exe können Sie gleichzeitig die Kennwörter des lokalen Computers 

sowie des Computerobjekts zurücksetzen. Dadurch ist ein erneutes Hinzufügen zur Domäne nicht 

erforderlich. Für einen Domänencontroller muss zuerst der Dienst Kerberos-Schlüsselverteilungscenter 

angehalten werden. Geben Sie anschließend in einer Befehlszeile den Befehl netdom resetpwd 

/s:Domänencontroller /ud:Domänenname\Administrator /pd:* ein. Beim Zurücksetzen des Computerkontos 

eines Domänencontrollers muss es sich bei dem von Netdom verwendeten Domänencontroller 

um einen anderen Domänencontroller in der gleichen Domäne handeln. Geben Sie das Kennwort 

des Administratorkontos ein, wenn Sie dazu aufgefordert werden. Nach dem Ausführen des 

Befehls ist ein Computerneustart erforderlich. 

Weitere Informationen Weitere Informationen zum Zurücksetzen des Kennworts eines Computerkontos 

mithilfe des Tools Netdom.exe finden Sie im Artikel „Zurücksetzen von Computerkontokennwörtern eines 

Windows Server 2003-Domänencontrollers mit "Netdom.exe"“ unter http://support.microsoft.com/kb/325850. 

Die Option, in Active Directory auf die Computerverwaltungsanwendung jedes Computers zugreifen 

zu können, ist vor allem im Hinblick auf die Verwaltung besonders nützlich. Ermitteln Sie einen 

Computer im Verwaltungstool Active Directory-Benutzer und -Computer, klicken Sie mit der rechten 

Maustaste auf das Symbol für die gewünschte Arbeitsstation bzw. den gewünschten Server, und wählen 

Sie Verwalten. In der MMC (Microsoft Management Console) Computerverwaltung wird die von 

Ihnen ausgewählte Arbeitsstation bzw. der gewählte Server angezeigt. 

In den meisten Fällen werden Computerobjekte beim Hinzufügen des Computers zur Domäne erstellt. 

Die Computerobjekte für Mitgliedsserver und Arbeitsstationen werden im Container Computers 

erstellt. Wenn ein Mitgliedsserver zum Domänencontroller heraufgestuft wird, wird das Computerobjekt 

für den Domänencontroller in die OU Domain Controllers verschoben. 

Achtung Sie können zwar die Computerobjekte für Domänencontroller aus der OU Domain Controllers 

verschieben können, dies ist jedoch nicht zu empfehlen. Viele der Sicherheitseinstellungen für Domänencontroller 

werden in der OU Domain Controllers konfiguriert. Durch das Verschieben eines Computerobjekts 

für einen Domänencontroller aus diesem Container heraus werden die Sicherheitseinstellungen für alle verschobenen 

Domänencontroller geändert. 

Meist werden die Computerobjekte aus dem Container Computers in bestimmte OUs verschoben. 

Wenn Sie Computerobjekte in bestimmte OUs verschieben, können Sie die Computer unterschiedlich 

verwalten.


Sie möchten vermutlich die Mitgliedsserver in Ihrem Unternehmen abweichend von den Arbeitsstationen 

verwalten, und daher ist es erforderlich, dass Sie zwei eigene OUs erstellen. Arbeitsstationen 

können häufig in kleinere Gruppen aufgeteilt werden. Für Arbeitsstationen in der Vertriebsabteilung 

sind beispielsweise andere Anwendungen erforderlich als auf den Arbeitsstationen in der Ingenieurabteilung. 

Indem Sie zwei OUs erstellen und die Arbeitsstationen in die geeignete OU verschieben, 

können Sie die beiden Arbeitsstationstypen unterschiedlich verwalten. 

Hinweis Da es sich bei dem Container Computers nicht um eine OU handelt, können Gruppenrichtlinien 

nicht direkt auf diesen Container angewendet werden. 

Sie können den Standardspeicherort für Computerobjekte während der Erstellung beim Hinzufügen 

zur Domäne umleiten. Wenn für die Domänenfunktionsebene mindestens Windows Server 2003 festgelegt 

ist, können Sie mithilfe des Dienstprogramms Redircmp.exe einen neuen Speicherort festlegen. 

Öffnen Sie eine Eingabeaufforderung, und geben Sie anschließend den Befehl redircmp 

ou=OUfürComputer,dc=Domänenname,dc=com ein. 

Hinweis Sie können den Befehl Rediruser.exe zum Ändern des Standardspeicherorts für neue Benutzerobjekte 

verwenden. 

Um Computerobjekte nach dem Erstellen nicht verschieben zu müssen, können Sie Computerobjekte 

in der gewünschten OU erstellen, bevor Sie die Computer zur Domäne hinzufügen. Wenn bereits ein 

Computerobjekt vorhanden ist, das dem Namen des Computers entspricht, wird dieses Computerobjekt 

verwendet. Dadurch ist es auch nicht erforderlich, Verwaltungsrechte zum Hinzufügen von 

Computern zur Domäne zu delegieren. 

Der Gruppe Authentifizierte Benutzer wird das Recht Hinzufügen von Arbeitsstationen zur Domäne 

zugewiesen. Dadurch können Benutzer Arbeitsstationen zu einer Domäne hinzufügen und bis zu zehn 

Computerkonten erstellen. Wenn Benutzer weitere Computerkonten erstellen müssen, muss diesen 

Benutzern in Active Directory die Berechtigung Computerobjekt erstellen delegiert werden. Diese 

Berechtigung kann bei Bedarf nur für bestimmte OUs delegiert werden. Alternativ können Sie Benutzern 

die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne auch mithilfe einer Gruppenrichtlinie 

erteilen. Dadurch können Benutzer Computerobjekte in der Domäne erstellen. Darüber 

hinaus können Mitglieder der Gruppen Konten-Operatoren, Domänen-Admins und Organisations- 

Admins Computerobjekte erstellen. Mitglieder der Gruppe Konten-Operatoren können keine Computerobjekte 

in der OU Domain Controllers erstellen. 

Beim Erstellen neuer Computerobjekte können Sie Befehlszeilenprogramme für die skriptbasierte 

Durchführung des Verfahrens verwenden. Mithilfe des Dienstprogramms Dsadd.exe können Sie 

während der Erstellung einen bestimmten Speicherort festlegen. Sie können das Dienstprogramm 

Netdom.exe auch zum Hinzufügen eines Computers zur Domäne sowie zum Festlegen der OU für das 

neue Computerobjekt verwenden. 

Hinweis Die Tatsache, dass Sie vermutlich wenig Verwaltungsaufgaben für Computerobjekte in Active 

Directory durchführen, heißt nicht, dass Sie Active Directory gar nicht für die Verwaltung von Computern verwenden. 

In Kapitel 11, „Einführung in Gruppenrichtlinien“, Kapitel 12, „Einsetzen von Gruppenrichtlinien zum 

Verwalten von Benutzerdesktops“, und Kapitel 13, „Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit“, 

werden Gruppenrichtlinien ausführlich beschrieben, die leistungsstarke Tools für die Computerverwaltung 

darstellen.

Verwalten von Druckerobjekten 

Verwalten von Druckerobjekten 373 

Bei der dritten Objektgruppe in Active Directory handelt es sich um Druckerobjekte. Sie können ein 

Druckerobjekt erstellen, indem Sie den Drucker in Active Directory veröffentlichen. Beim Veröffentlichen 

eines Druckers in Active Directory wird ein Druckerobjekt erstellt, in dem die Druckerattribute 

wie beispielsweise der Druckerstandort sowie Druckerfeatures wie die Druckgeschwindigkeit, 

Farbdruckfunktionen und weitere druckerspezifische Funktionen gespeichert werden. Druckerobjekte 

werden primär in Active Directory veröffentlicht, um Benutzern das Ermitteln von und Verbinden mit 

Netzwerkdruckern zu vereinfachen. 

Veröffentlichen von Druckern in Active Directory 

Standardmäßig wird jeder auf einem Computer unter Windows 2000 Server und Windows Server 

2003 installierte und freigegebene Drucker in einer Active Directory-Domäne automatisch veröffentlicht. 

Wenn Sie einen auf einem Computer unter Windows Server 2008 freigegebenen Drucker automatisch 

in Active Directory veröffentlichen möchten, können Sie im Eigenschaftendialogfeld des 

Druckers auf der Registerkarte Freigabe im Verzeichnis die Option Im Verzeichnis anzeigen wählen. 

Hinweis Die zu Active Directory hinzugefügten Druckerobjekte werden automatisch unter dem Computerobjekt 

gespeichert. Um diese Objekte im Verwaltungstool Active Directory-Benutzer und -Computer anzuzeigen, 

müssen Sie im Menü Ansicht die Option Benutzer, Kontakte, Gruppen und Computer als Container aktivieren. 

Wenn sich ein freigegebener Drucker auf einem Server befindet, auf dem Windows NT oder ein anderes, 

nicht Windows-basiertes Serverbetriebssystem ausgeführt wird, müssen Sie den Drucker manuell 

in Active Directory veröffentlichen. Ermitteln Sie hierfür das Containerobjekt, in dem Sie das Druckerobjekt 

veröffentlichen möchten, klicken Sie mit der rechten Maustaste auf den Container, zeigen Sie 

auf Neu, und wählen Sie Drucker. Geben Sie anschließend den UNC-Pfad (Universal Naming Convention) 

zum freigegebenen Drucker an. Für Druckerobjekte, die manuell zu Active Directory hinzugefügt 

wurden, werden Änderungen an Druckerinformationen nicht automatisch angewendet, die 

Objekte werden in dem Container angezeigt, in dem Sie sie erstellen. 

Windows Server 2008 umfasst das Skript Pubprn.vbs zum automatischen Hinzufügen freigegebener 

Drucker von Windows NT zu Active Directory. Dieses Skript kann nicht für Drucker verwendet werden, 

die auf Computern freigegeben wurden, auf denen Windows 2000 Server, Windows Server 2003 

oder Windows Server 2008 ausgeführt wird. Das Skript Pubprn.vbs befindet sich im Ordner 

%WINDIR%\System32\Printing_Admin_Scripts\. 

Weitere Informationen Ausführliche Informationen zur Syntax des Skripts Pubprn.vbs werden auf der 

Seite „Pubprn.vbs“ in der technischen Bibliothek für Windows Server 2008 unter http://technet2.microsoft.com/windowsserver2008/en/library/0bc7f7e3-84e1-4359-b477-7b1a1a0bd6391033.mspx?mfr=true 


Durch das Veröffentlichen eines Druckers in Active Directory können Benutzer in Active Directory 

nach Druckerobjekten suchen. Beim Veröffentlichen eines Druckers in Active Directory werden die 

Informationen zu dem Drucker im Druckerobjekt ausgefüllt. Diese Informationen können für Benutzer 

sehr hilfreich sein, die einen bestimmten Drucker suchen. Ein Benutzer sucht beispielsweise einen 

Farbdrucker, der mindestens sechs Seiten pro Minute drucken kann. Wenn diese Informationen in 

Active Directory gespeichert sind, kann der Client mithilfe des Suchdialogfelds Drucker ermitteln, die 

diesen Anforderungen entsprechen.


In Abbildung 10.7 wird das Suchdialogfeld auf einer Windows Vista-Arbeitsstation angezeigt. Nachdem 

der Netzwerkdrucker ermittelt wurde, kann der Benutzer mit der rechten Maustaste auf den Drucker 

klicken und die Option Verbinden wählen, um den Drucker auf dem Clientcomputer zu installieren. 

Wenn Druckerobjekte in Active Directory veröffentlicht sind, können Sie sie mithilfe von Gruppenrichtlinien 

verwalten. In Tabelle 10.8 werden die Optionen für die Verwaltung von Druckereinstellungen 

angezeigt. 


Suchen nach Druckern in Active Directory 


Konfigurieren von Druckereinstellungen mithilfe des Gruppenrichtlinienverwaltungs-Editors

Verwalten von Druckerobjekten 375 

Mit einigen der Optionen, die Sie mithilfe von Gruppenrichtlinien konfigurieren können, können Sie 

das Löschen von Druckern verwalten. Der Löschdienst auf einem Domänencontroller löscht Druckerobjekte 

automatisch aus Active Directory, wenn die Druckerobjekte nicht mehr benötigt werden. 

Wenn ein Drucker beispielsweise von einem Druckserver entfernt wurde oder der Drucker auf dem 

Server nicht mehr freigegeben ist, wird das Druckerobjekt durch den Löschdienst entfernt. Standardmäßig 

versucht der Löschdienst auf den Active Directory-Domänencontrollern alle acht Stunden 

Kontakt mit jedem Druckserver aufzunehmen, um die Gültigkeit der Druckerinformationen zu überprüfen. 

Antwortet der Druckserver nicht, wird das Druckerobjekt aus Active Directory gelöscht. Bei 

jedem Neustart eines Druckservers, auf dem Windows 2000 oder ein höheres Betriebssystem ausgeführt 

wird, werden die freigegebenen Drucker automatisch erneut in Active Directory veröffentlicht. 

Sie können die Parameter zum Löschen der Drucker mithilfe des Gruppenrichtlinienobjekt-Editors 

konfigurieren. In Tabelle 10.8 werden die Gruppenrichtlinieneinstellungen für die Verwaltung 

von Druckerobjekten beschrieben. 

Tabelle 10.8 

GPO-Einstellungen für die Verwaltung von Druckerobjekten 

GPO-Einstellung 

Neue Drucker automatisch in Active 

Directory veröffentlichen 

Löschen von öffentlichen Druckern 

zulassen 

Nicht wiederveröffentlichende Drucker 

löschen 

Verzeichnislöschintervall 

Verzeichnislöschpriorität 

Verzeichnislöschwiederholungen 

Verzeichnislöschwiederholungsversuche 

protokollieren 

Druckerveröffentlichung zulassen 

Veröffentlichungsstatus überprüfen 

Beschreibung 

Wenn diese Option aktiviert ist, werden freigegebene Drucker automatisch in Active 

Directory veröffentlicht. 

Wenn diese Option aktiviert ist, werden Druckerobjekte durch den Löschdienst auf 

einem Domänencontroller aus Active Directory entfernt, wenn der Computer, durch 

den der Drucker veröffentlicht wurde, nicht auf Kontaktanforderungen antwortet. 

Diese Option wird nur auf Drucker angewendet, die nicht automatisch erstellt bzw. 

veröffentlicht wurden, wie beispielsweise die mithilfe des Skripts Pubprn.vbs oder 

manuell mithilfe des Verwaltungstools Active Directory-Benutzer und -Computer erstellten 

Drucker. Diese Option kann für die Einstellungen Nie, Nur wenn Druckserver 

gefunden wird oder Immer wenn Drucker nicht gefunden wird konfiguriert werden. 

Über diese Option wird festgelegt, wie häufig der Löschdienst auf einem Domänencontroller 

die Betriebsbereitschaft von Druckern überprüft. Diese Option findet nur 

Anwendung, wenn das Löschen von Druckern aktiviert ist. Das Standardlöschintervall 

beträgt acht Stunden. 

Über diese Option wird die Priorität festgelegt, mit der der Thread die Verzeichnislöschung 

auf Domänencontrollern durchführt. Standardmäßig ist für die Priorität normal 

festgelegt. 

Über diese Option wird festgelegt, wie viele zusätzliche Kontaktversuche für einen 

Drucker unternommen werden, bevor der Drucker gelöscht wird. Für diesen Wert 

sind standardmäßig zwei Versuche festgelegt. 

Wenn diese Option aktiviert ist, werden die vom Löschthread unternommenen Versuche, 

den Drucker zu kontaktieren, im Ereignisprotokoll aufgezeichnet. 

Wenn diese Option aktiviert ist, steht im Eigenschaftendialogfeld eines Druckers auf 

der Registerkarte Freigabe die Option Im Verzeichnis anzeigen zur Verfügung. Wenn 

diese Option deaktiviert ist, kann der Computer keine Drucker veröffentlichen. Diese 

Einstellung überschreibt die Option Neue Drucker automatisch in Active Directory 

veröffentlichen. 

Über diese Option wird festgelegt, wie häufig ein Computer überprüft, ob sich seine 

veröffentlichten Drucker in Active Directory befinden. Standardmäßig werden Drucker 

nur beim Startvorgang überprüft.


Nachverfolgen des Druckerstandorts 

Eine der für die Verwaltung von Druckerobjekten in Active Directory verfügbaren Optionen ist die 

Option zum automatischen Ausfüllen der Einstellungen für den Druckerstandort für Benutzer, wenn 

diese einen Drucker suchen. Viele Unternehmen mit mehreren Niederlassungen beschäftigen Mitarbeiter, 

die in verschiedenen Niederlassungen arbeiten. Die meisten Unternehmen verfügen über Konferenzräume 

in unterschiedlichen Teilen des Gebäudes. Wenn sich Benutzer zwischen den unterschiedlichen 

Unternehmensbereichen oder -niederlassungen bewegen, benötigen sie in der Regel 

unabhängig von ihrem aktuellen Standort die Möglichkeit zum Drucken. Wenn Benutzer nicht wissen, 

wo sich an ihrem aktuellen Standort die Drucker befinden, benötigen sie meist einige Zeit, um 

den nächstgelegenen Drucker zu ermitteln. 

Sie können diese Suche nach Druckern vereinfachen, indem Sie jedem Drucker einen Standort in 

Active Directory zuweisen und anschließend anhand des Benutzerstandorts eine Liste mit Druckern 

bereitstellen, die sich in der Nähe des Benutzers befinden. Diese Funktion basiert auf der Standortkonfiguration 

in Active Directory. 

Führen Sie die folgenden Schritte durch, um die Nachverfolgung des Druckerstandorts zu aktivieren: 

1. Öffnen Sie das Verwaltungtool Active Directory-Standorte und -Dienste, und ermitteln Sie das 

Subnetobjekt , in dem Sie die Druckernachverfolgung aktivieren. Klicken Sie mit der rechten 

Maustaste auf das Subnetobjekt , und wählen Sie Eigenschaften. Klicken Sie auf die Registerkarte 

Standort, und geben Sie den Standortwert für dieses Subnetz ein. Der Standorteintrag sollte 

das Format Standort/untergeordneter Standort aufweisen (z.B. Hauptsitz/3.Stock). 

2. Verwenden Sie den Gruppenrichtlinienobjekt-Editor, um die Richtlinie Druckerstandortsuchtext 

im Vornhinein ausfüllen für einen ausgewählten Container zu aktivieren. Dieser Vorgang erfolgt 

meist auf Domänenebene. 

3. Rufen Sie auf Ihrem Druckserver das Eigenschaftendialogfeld für jeden Drucker auf. Füllen Sie 

auf der Registerkarte Allgemein den Standort des Druckers aus. Wenn Sie die ersten beiden 

Schritte dieses Verfahrens abgeschlossen haben, können Sie auf Durchsuchen klicken, um den 

Druckerstandort zu ermitteln. Sie können für den Druckerstandort weitere Informationen hinzufügen, 

sodass der Druckerstandort eindeutig ist (z.B. Hautpsitz/3.Stock/Außerhalb von Konferenzraum 

5). 

Nachdem Sie die Nachverfolgung des Druckerstandorts aktiviert haben, können Benutzer den nächstgelegenen 

Drucker einfach ermitteln. Wenn der Benutzer den Assistenten zum Hinzufügen von Druckern 

aufruft und nach einem Drucker in Active Directory sucht, wird das Standortattribut basierend 

auf dem aktuellen Subnetz des Benutzers ausgefüllt. In Abbildung 10.9 wird das Suchdialogfeld auf 

einer Windows Vista-Arbeitsstation angezeigt. Der Benutzer kann mithilfe der Schaltfläche Durchsuchen 

einen bestimmten Druckerstandort auswählen. 

Sie können Parameter für die Nachverfolgung von Druckern mithilfe des Gruppenrichtlinienobjekt- 

Editors konfigurieren. In Tabelle 10.9 werden die Gruppenrichtlinieneinstellungen für die Nachverfolgung 

des Druckerstandorts beschrieben. 

Tabelle 10.9 

GPO-Einstellungen für die Nachverfolgung des Druckerstandorts 


Computerstandort 

Beschreibung 

Diese Option wird verwendet, um den Wert des Standardspeicherorts zu überschreiben, 

der bei der Suche nach Druckern verwendet wird. Der Standardwert wird in 

Active Directory im Subnetobjekt definiert.

Verwalten von veröffentlichten freigegebenen Ordnern 377 

Tabelle 10.9 

GPO-Einstellungen für die Nachverfolgung des Druckerstandorts (Fortsetzung) 


Druckerstandortsuchtext im Vornhinein 

ausfüllen 

Beschreibung 

Diese Option wird für die Konfiguration des Assistenten zum Hinzufügen von Druckern 

verwendet, um Drucker basierend auf dem im lokalen Active Directory-Subnetobjekt 

definierten Speicherort zu ermitteln. Benutzer können Drucker auch anhand 

ihres Standorts suchen. Standardmäßig ermittelt der Assistent zum Hinzufügen von 

Druckern Drucker auf Grundlage der IP-Adresse und der Subnetzmaske des Clients. 


Ermitteln von Druckerobjekten in Active Directory mithilfe des Standortattributs 

Verwalten von veröffentlichten freigegebenen Ordnern 

Bei einem weiteren Objekt, das Sie in Active Directory veröffentlichen können, handelt es sich um 

ein freigegebenes Ordnerobjekt. Um einen freigegebenen Ordner in Active Directory zu veröffentlichen, 

ermitteln Sie den Active Directory-Container, in dem Sie den freigegebenen Ordner veröffentlichen 

möchten. Klicken Sie mit der rechten Maustaste auf den Container, zeigen Sie auf Neu, und 

klicken Sie auf Freigegebener Ordner. Geben Sie anschließend einen Namen für das Active Directory-Objekt 

sowie die UNC für den freigegebenen Ordner ein. Nach dem Erstellen eines freigegebenen 

Ordnerobjekts in Active Directory können Benutzer den freigegebenen Ordner ermitteln oder 

in Active Directory einen Suchlauf für das Objekt starten. Nachdem Benutzer das Objekt in Active 

Directory ermittelt haben, können sie mit der rechten Maustaste auf das Objekt klicken und dem freigegebenen 

Ordner ein Laufwerk zuordnen.


Der größte Vorteil der Veröffentlichung eines freigegebenen Ordners in Active Directory besteht 

darin, dass Benutzer Freigaben in Active Directory auf Grundlage vieler Eigenschaften ermitteln können. 

Beim Erstellen eines freigegebenen Ordnerobjekts können Sie eine Beschreibung für den freigegebenen 

Ordner bereitstellen. Das entsprechende Dialogfeld wird in Abbildung 10.10 dargestellt. 

Nach dem Erstellen des freigegebenen Ordners können Sie das Eigenschaftendialogfeld des Ordners 

verwenden, um die mit dem freigegebenen Ordner verknüpften Schlüsselwörter festzulegen. Wenn 

Clients den freigegebenen Ordner ermitteln müssen, können sie Active Directory mithilfe eines Arguments 

durchsuchen, das auf dem Objektnamen, Schlüsselwörtern oder einer Beschreibung basiert. 


Veröffentlichen eines freigegebenen Ordners in Active Directory 

Die größte Einschränkung beim Veröffentlichen freigegebener Ordner in Active Directory besteht 

darin, dass beim Verschieben eines freigegebenen Ordners auf einen anderen Server jeder Client, der 

über ein verbundenes Laufwerk mit diesem Ordner verfügt, feststellen wird, dass diese Zuordnung 

nicht mehr funktioniert. Die Verbindung ist nicht mehr funktionsfähig, da die Verbindung eines Laufwerks 

mit einem freigegebenen Ordner in Active Directory auf dem Client weiterhin auf dem UNC- 

Pfad der Freigabe basiert. Sie erstellen und veröffentlichen beispielsweise einen freigegebenen Ordner 

namens Vertriebsinformationen, der auf \\SEA-SRV1\Vertriebsinformationen zeigt. Wenn ein 

Benutzer diesen freigegebenen Ordner in Active Directory ermittelt und ihm ein Laufwerk zuordnet, 

wird für die Laufwerkzuordnung die Syntax \\SEA-SRV1\Vertriebsinformationen verwendet. Wenn 

dieser Ordner nun auf einen anderen Server verschoben wird, ist die Laufwerkzuordnung nicht mehr 

funktionsfähig, selbst wenn Sie das Active Directory-Objekt so ändern, dass es auf den neuen Speicherort 

zeigt. 

Sie können diese Einschränkung beim Veröffentlichen freigegebener Ordner umgehen, indem Sie das 

DFS (Distributed File System) verwenden. Das DFS kann einen fehlertoleranten Namespace (UNC- 

Pfad) bereitstellen, der das Verschieben von Daten zwischen Servern ermöglicht, ohne dass Clients 

die Verbindung verlieren.

Automatisieren der Active Directory-Objektverwaltung 379 

Automatisieren der Active Directory-Objektverwaltung 

Windows Server 2008 bietet grafische Dienstprogramme wie beispielsweise das Verwaltungstool 

Active Directory-Benutzer und -Computer für die Verwaltung von Active Directory-Objekten. Diese 

grafischen Dienstprogramme stellen Assistenten und Strukturen für die Objekterstellung bereit und 

vereinfachen so das Erstellen und Bearbeiten von Active Directory-Objekten. Beim Erstellen eines 

neuen Benutzerobjekts mithilfe des Verwaltungstools Active Directory-Benutzer und -Computer werden 

Sie beispielsweise von dem Assistenten zur Angabe aller erforderlichen Informationen wie beispielsweise 

des vollständigen Vornamens, des Nachnamens und des Benutzeranmeldenamens aufgefordert. 

Dadurch müssen Sie sich später nicht erneut mit Informationen wie beispielsweise den 

Eigenschaftennamen auseinandersetzen. 

Die grafischen Dienstprogramme bieten eingeschränkte Unterstützung zum Durchführen von Massenänderungen 

an Active Directory-Objekten. Sie können beispielsweise nur einige wenige Benutzereigenschaften 

ändern, wenn mehrere Benutzer im Verwaltungstool Active Directory-Benutzer und 

-Computer ausgewählt wurden. Darüber hinaus bieten die grafischen Dienstprogramme nicht die 

Möglichkeit, die Verwaltung von Active Directory-Objekten zu automatisieren. Eine Anwendung 

kann beispielsweise über Active Directory-Benutzer und -Computer keine neuen Benutzerobjekte 

erstellen. 

Um Massenänderungen an Active Directory-Objekten vorzunehmen und die Verwaltung von 

Active Directory-Objekten zu automatisieren, müssen Sie eigens für diesen Zweck entwickelte Tools 

verwenden. Die in Windows Server 2008 integrierten Tools umfassen Befehlszeilenprogramme, 

LDIFDE, CSVDE sowie Unterstützung für VBScript und Windows PowerShell. 

Befehlszeilenprogramme für die Verwaltung von Active Directory 

Die Windows-Tools für die Unterstützung von Windows 2000 Server und Windows Server 2003 

umfassen mehrere Befehlszeilenprogramme für die Verwaltung von Active Directory-Objekten. In 

Windows Server 2008 werden diese Tools beim Hinzufügen der AD DS-Rolle installiert, sie stehen 

nicht als Komponente zum Herunterladen bereit. 

Befehlszeilenprogramme für die Active Directory-Verwaltung sind bei Batchdateien besonders hilfreich. 

Bei einer Batchdatei handelt es sich um eine Textdatei mit der Dateinamenerweiterung .bat. 

Jede Zeile in der Batchdatei stellt einen neuen Befehl dar. Der Inhalt der Batchdatei wird von dem 

Tool Cmd.exe interpretiert. Daher können Sie jeden beliebigen Befehl in einer Batchdatei verwenden, 

den Sie auch an der Befehlszeile verwenden könnten. Darüber hinaus bieten Batchdateien komplexere 

Verarbeitungsmöglichkeiten, wie beispielsweise die Anzeige von Menüs. 

Sie können mithilfe von Batchdateien die Verfahren automatisieren, die für viele Objekte gleichzeitig 

durchgeführt werden. Sie können z.B. eine Batchdatei zum Bearbeiten der Adressinformationen 

für alle Benutzer in einer OU erstellen, wenn eine Abteilung an einen anderen Standort verlagert 

wird. Sie können außerdem regelmäßig durchzuführende Aufgaben automatisieren, indem Sie 

die Batchdatei als geplante Aufgabe ausführen. In Tabelle 10.10 werden die für die Verwaltung von 

Active Directory-Objekten in Windows Server 2008 verfügbaren Befehlszeilenprogramme aufgeführt.


Tabelle 10.10 

Programm 

Dsadd 

Dsmod 

Dsmove 

Dsrm 

Dsquery 

Dsget 

Befehlszeilenprogramme für die Verwaltung von Active Directory 

Beschreibung 

Dieses Programm wird zum Hinzufügen von Objekten zu Active Directory verwendet. Sie können Computerobjekte, 

Kontakte, Gruppen, OUs und Benutzer hinzufügen. Darüber hinaus können Sie einer Active Directory-Partition 

eine Kontingentspezifikation hinzufügen. Durch eine Kontingentspezifikation wird die Anzahl an 

Objekten eingeschränkt, die ein Sicherheitsprinzipal wie z.B. ein Benutzer in der Partition besitzen kann. 

Dieses Programm wird zum Bearbeiten von Objekten in Active Directory verwendet. Sie können Computerobjekte, 

Kontakte, Gruppen, OUs, Benutzer und Kontingentspezifikationen bearbeiten. Darüber hinaus können 

Sie die Eigenschaften einer Domänencontroller- oder Active Directory-Partition bearbeiten. Sie können die 

Ausgabe des Befehls Dsquery als Eingabe für diesen Befehl weiterleiten. 

Dieses Programm wird zum Verschieben und Umbenennen von Objekten in Active Directory verwendet. 

Mithilfe dieses Dienstprogramms können Objekte nur innerhalb einer Domäne verschoben werden. 

Dieses Programm wird zum Entfernen von Objekten aus Active Directory verwendet. Sie können nicht nur 

einzelne Objekte, sondern auch Container und ihren Inhalt entfernen. 

Dieses Programm wird für die Suche nach Objekten mit bestimmten Eigenschaften in Active Directory verwendet. 

Für häufig verwendete Objekttypen werden Optionen bereitgestellt, die Sie in einer Befehlszeile für 

bestimmte Eigenschaften verwenden können. Mit dem Tool Dsquery können Sie auch LDAP-Abfragen verwenden, 

um beliebige Objekttypen und Objektattribute zu ermitteln. Die Ergebnisse eines Dsquery-Befehls 

können an andere Befehle wie z.B. Dsmod, Dsget, Dsmove und Dsrm weitergeleitet werden. 

Dieses Programm wird für die Anzeige von Eigenschaften eines Objekts in Active Directory verwendet. Standardmäßig 

werden die Eigenschaften auf dem Bildschirm dargestellt, sie können aber auch für eine weitere 

Überprüfung in einer Datei ausgegeben werden. 

Hinweis In jedem Befehlszeilenprogramm können Sie die Option /? verwenden, um zusätzliche 

Informationen über die Verwendungsweise und die Syntax des Programms anzuzeigen. 

Verwenden von LDIFDE und CSVDE 

Sie können die in Windows Server 2008 integrierten Tools LDIFDE und CSVDE für Massenimporte 

und -exporte von Informationen in bzw. aus Active Directory verwenden. Die beiden Tools lesen 

Informationen aus einer Datendatei und erstellen oder bearbeiten anschließend Active Directory- 

Objekte entsprechend den Anweisungen in der Datendatei. Der Hauptunterschied zwischen den beiden 

Tools besteht im Datenformat. CSVDE nutzt Daten in .csv-Dateien (durch Komma getrennte 

Wertedateien), und LDIFDE nutzt Daten in .ldf-Dateien (LDAP Directory Interchange Format). 

Welches Tool Sie auswählen, richtet sich nach dem Format Ihrer Daten. Wenn in einer Organisation 

beispielsweise in der Personalabteilung eine Anwendung Daten zu neuen Mitarbeitern in .ldf-Dateien 

exportiert, sollte das Tool LDIFDE verwendet werden. Wenn jedoch für eine Hochschule die Daten zu 

neuen Studenten in einer Microsoft Office Excel-Tabelle bereitgestellt werden, kann diese einfach als 

.csv-Datei gespeichert werden, und die neuen Studenten werden mithilfe des Tools CSVDE erstellt. 

LDIFDE 

Bei LDIF handelt es sich um ein gemäß RFC 2849 definiertes Standarddatenformat. Es wird häufig 

für den Import und Export von Daten aus Verzeichnissen bzw. in Verzeichnisse verwendet, einschließlich 

Active Directory und weiteren LDAP-Verzeichnissen (Lightweight Directory Access Protocol).


.ldf-Dateien umfassen viele Einträge, die durch eine Leerzeile voneinander getrennt werden. Jeder 

Eintrag setzt sich aus mehreren Zeilen mit bestimmten Informationen zusammen. Dn wird für die 

Angabe des zu bearbeitenden Objekts verwendet. Changetype wird für die Angabe der zu ergreifenden 

Maßnahme verwendet. Bei den gültigen Werten für changetype handelt es sich um die Werte add, 

modify und delete. Ein Bindestrich (-) wird für die Trennung mehrerer Attribute eines einzelnen 

Objekts verwendet und ist außerdem am Ende jedes Eintrags erforderlich, wenn für changetype der 

Wert modify festgelegt ist. Mithilfe der folgenden .ldf-Datei werden zwei Attribute des Benutzerobjekts 

Paul West bearbeitet: 

dn: CN=Paul West,OU=Buchhaltung,DC=Adatum,DC=com 

changetype: modify 

replace: physicalDeliveryOfficeName 

physicalDeliveryOfficeName: 315 

- 

replace: title 

title: Leitender Angestellter der Personalabteilung 

- 

Das Tool LDIFDE kann in zahlreichen Szenarien nützlich sein: 

• Massenverarbeitung von Benutzerkonten Exportieren Sie hierfür die ausgewählten Benutzerkonten 

in eine .ldf-Datei, bearbeiten Sie die Datei entsprechend den Anforderungen für den Import, 

und importieren Sie anschließend die .ldf-Datei. Wenn Sie die .ldf-Datei nach dem Export bearbeiten 

möchten, sind weitreichendere Bearbeitungen als das Suchen und Ersetzen des zu bearbeitenden 

Attributwertes erforderlich. Der Wert changetype ist während eines Exports auf add 

gesetzt. Nachdem der Export abgeschlossen ist und bevor der Import durchgeführt wird, muss dieser 

Wert in change geändert werden. Die Attributwerte müssen ebenfalls in das für den Import 

erforderliche Format geändert werden. 

• Verschieben von Benutzerkonten in eine neue Domäne Benutzerkonten in einer Domäne können in 

eine .ldf-Datei exportiert und anschließend in eine neue Domäne importiert werden. Die vorhandenen 

Sicherheitskennungen (Security Identifiers, SIDs) der Benutzer werden dabei nicht beibehalten. 

Benutzer können jedoch im Rahmen des Importvorgangs den geeigneten Gruppen 

hinzugefügt werden. 

• Massenerstellung von neuen Benutzern Zusätzlich zu den Zeilen dn und changetype handelt es 

sich bei den Attributen, die zum Erstellen eines neuen Benutzers unbedingt erforderlich sind, um 

die Attribute cn=displayname und objectClass=user. Das Attribut samAccountName=logonname 

sollte ebenfalls integriert werden. Anderenfalls wird es zufällig generiert. Neu erstellte Benutzer 

sind deaktiviert. Sie können für Benutzer mithilfe des Attributs unicodePwd ein neues Kennwort 

festlegen, wenn Ihre Verbindung mit dem Server durch SSL verschlüsselt ist. 

Sie sollten den Export von Benutzerinformationen auf die Objekte und Attribute beschränken, an 

denen Sie Änderungen vornehmen möchten. Wenn beispielsweise die Buchhaltung in eine neue 

Unternehmensniederlassung verlagert wird, exportieren Sie nur die Benutzerobjekte in der OU Buchhaltung 

und nur die Adressattribute, die geändert werden. Während des Exportvorgangs können Sie 

einen Filter definieren, mit dem Sie die zu exportierenden Active Directory-Objekte auf bestimmte 

Objektklassen und Objekte mit bestimmten Attributwerten beschränken. Sie können darüber hinaus 

einen Stamm-DN festlegen, um die OU zu definieren, für die die LDAP-Abfrage durchgeführt wird. 

Es werden nur Objekte mit dem Stamm-DN zurückgegeben. Über einen Bereich wird definiert, wie 

viele Ebenen innerhalb des Stamm-DNs durchsucht werden.


CSVDE 

Weitere Informationen Weitere Informationen zur Verwendung von LDIFDE zum Durchführen von Massenvorgängen 

finden Sie im Artikel „Step-by-Step Guide to Bulk Import and Export to Active Directory“ 

(in englischer Sprache) auf der Technet-Website unter http://technet.microsoft.com/en-us/library/ 

Bb727091.aspx. 

CSVDE ist in den Fällen hilfreich, in denen die Daten noch nicht vollständig im LDIF-Format zur 

Verfügung stehen. In vielen Anwendungen können Daten als .csv-Datei exportiert werden, nicht 

jedoch als .ldf-Datei. In einer .csv-Datei wird jede Zeile von CSVDE als einzelner Eintrag betrachtet 

und verarbeitet. In dieser Zeile werden die Attributwerte aufgeführt, die hinzugefügt oder bearbeitet 

werden sollen. In der Datei wird kein Vorgang definiert, da das Tool CSVDE – im Gegensatz zu 

LDIFDE – für jede Zeile in der .csv-Datei immer ein neues Objekt erstellt. Die erste Zeile in der .csv- 

Datei ist eine Kopfzeile, in der definiert wird, welches Attribut in den folgenden Zeilen welchem Wert 

entspricht. 

Wenn Sie das Tool CSVDE zum Exportieren von Daten verwenden, können Sie die gleichen Optionen 

zum Filtern von Daten verwenden wie mit dem Tool LDIFDE. Sie können eine Ausgabe basierend 

auf Objektklasse und Attributen filtern. Sie können einen Export ohne Attributfilterung durchführen, 

um eine .csv-Datei zu erstellen, in der die Eigennamen für alle Attribute in der Kopfzeile 

angezeigt werden. Mit dem Tool CSVDE können Sie nur Attribute exportieren, die einen Wert für 

mindestens ein Objekt aufweisen. 

Weitere Informationen Weitere Informationen zur CSVDE-Syntax und zu Optionen werden im Artikel 

„CSVDE“ (in englischer Sprache) auf der Technet-Website unter http://technet2.microsoft.com/windowsserver/en/library/1050686f-3464-41af-b7e4-016ab0c4db261033.mspx?mfr=true 

bereitgestellt. Zum Anzeigen 

der CSVDE-Hilfe können Sie auch die Option /? verwenden. 

Verwenden von VBScript für die Verwaltung von Active Directory- 

Objekten 

Bei Batchdateien handelt es sich um eine einfache Skriptimplementierung, die in Windows Server 

2008 verwendet werden kann. Wenn Sie jedoch Skripts mithilfe einer Skriptsprache wie VBScript 

erstellen, können Sie sehr komplexe Aufgaben ausführen. Im Folgenden werden einige der Vorteile 

der Verwendung von Skripts für die Verwaltung von Active Directory-Objekten aufgeführt: 

• Das Ausführen eines Skripts nimmt in der Regel weniger Zeit in Anspruch als das Ausführen der 

gleichen Aufgabe über die grafische Benutzeroberfläche. 

• Skripts können mehrfach verwendet werden. Die Entwicklung eines Skripts nimmt zwar mehr 

Zeit in Anspruch als das Durchführen der Aufgabe über die grafische Benutzeroberfläche, aber 

sobald das Skript fertig gestellt ist, kann es immer wieder mit kleinen Änderungen durchgeführt 

werden, um neuen Anforderungen zu entsprechen. 

• Durch den Einsatz von Skripts können menschliche Fehler reduziert oder sogar vollständig verhindert 

werden. Indem Sie ein geprüftes Skript wiederverwenden, können Sie Fehler vermeiden, 

die bei der manuellen Durchführung von wiederholten Verfahren entstehen können. Mit Skripts 

können Sie auch eingegebene Informationen überprüfen. 

• Mithilfe von Skripts können alle verfügbaren Objektattribute bearbeitet werden. Tools mit einer 

grafischen Benutzeroberfläche können hingegen nur für die Bearbeitung bestimmter Objektattribute 

verwendet werden. Solche Beschränkungen bestehen bei Skripts nicht.


• Sie können einen Zeitplan für die Skriptausführung festlegen. Die Ausführung von Skripts anhand 

eines Zeitplans ist vor allem für regelmäßig anfallende Verwaltungsaufgaben nützlich. Sie können 

beispielsweise wöchentlich alle deaktivierten Benutzerkonten in eine bestimmte OU verschieben. 

Active Directory-Skriptkomponenten 

Skripts werden in Windows Server 2008 von Windows Script Host (WSH) unterstützt. Für WSH gibt 

es zwei Laufzeitumgebungen: Bei Wscript.exe handelt es sich um ein Windows-basiertes Laufzeit für 

grafische Anwendungen, Cscript.exe ist eine befehlszeilenbasierte Laufzeit mit Ausgabe an die Eingabeaufforderung. 

Wscript.exe ist die standardmäßige Laufzeit, die beim Doppelklicken auf ein Skript 

verwendet wird. 

Windows Script Host unterstützt sowohl VBScript als auch JScript als Skriptsprachen. Die meisten 

mit Skripts weniger vertrauten Benutzer bevorzugen VBScript. Auch die meisten Skriptbeispiele auf 

der Microsoft-Website verwenden VBScript. VBScript-Skripts tragen in der Regel die Dateinamenerweiterung 

.vbs. Die Dateinamenerweiterung .vbe kann jedoch ebenfalls für VBScript-Skripts verwendet 

werden. Bei .wsf-Dateien handelt es sich um allgemeine Windows Script Host-Dateien, die eine 

Kombination aus VBScript und JScript enthalten können. 

Eine Skriptingschnittstelle kann als abstrakte Schicht bezeichnet werden, über die Sie auf Informationen 

in einer Datenquelle zugreifen können. Bei ADSI (Active Directory Service Interfaces) handelt es 

sich um die am häufigsten für den Zugriff auf Active Directory-Objekte verwendete Skriptingschnittstelle. 

Mithilfe von ADSI können Sie Active Directory-Objekte erstellen, bearbeiten und löschen. Sie 

können auch ActiveX Data Objects (ADO) für den Zugriff auf Active Directory-Objekte verwenden. 

Allerdings können Sie mit ADO ausschließlich Abfragen für Active Directory-Objekte erstellen, eine 

Objektbearbeitung ist damit nicht möglich. Beim Durchführen einer Abfrage besteht der bedeutendste 

Unterschied zwischen ADSI und ADO im Ergebnissatz – der bei einer ADO-Abfrage nicht 

umfassend ist. Es wird eine Benutzerliste als einzelne Liste zurückgegeben, die keine hierarchische 

Gliederung nach Domäne oder OU aufweist. 

Die Windows-Verwaltungsinstrumentierung (Windows Management Instrumentation, WMI) ist die 

Microsoft-Implementierung einer Initiative zur webbasierten Unternehmensverwaltung (Web-Based 

Enterprise Management, WBEM), d.h. ein standardisiertes Verfahren für die Verwaltung von Netzwerk- 

und Computerressourcen. Neben dem Bearbeiten von Active Directory-Objekten können Sie 

mit WMI Konfigurationseinstellungen auf Desktopcomputern und Serversystemen, Anwendungen, 

Netzwerken sowie weiteren Unternehmenskomponenten abfragen, ändern und überwachen. 

Erstellen und Ausführen eines Skripts mithilfe von VBScript 

Beim Erstellen eines Skripts mithilfe von VBScript benötigen Sie lediglich einen einfachen Text-Editor, 

wie beispielsweise den Editor. Die einzige Anforderung besteht darin, das Skript mit der Dateinamenerweiterung 

.vbs oder .vbe zu speichern. Es gibt jedoch auch Skript-Editoren, die das Erstellen 

von Skripts vereinfachen. Mithilfe eines Skript-Editors kann die Skriptsyntax überprüft werden, 

sodass Sie Fehler schon beim Schreiben des Skripts und nicht erst nach der Ausführung korrigieren 

können. Skript-Editoren bieten darüber hinaus typischerweise Optionen zur Codevervollständigung 

sowie eine Möglichkeit zur Farbcodierung der Syntax. 

Binden mit einem Objekt Als Erstes stellen Sie bei der Bearbeitung eines Active Directory-Objekts 

mithilfe von VBScript eine Bindung mit einem Active Directory-Objekt her. „Binden mit einem 

Objekt“ bezeichnet das Herstellen einer Verbindung mit einem Objekt. Beim Erstellen eines neuen 

Objekts binden Sie das Objekt mit dem Container, in dem das Objekt erstellt wird.


Beim Bearbeiten eines vorhandenen Objekts stellen Sie eine Bindung mit dem Objekt her, das Sie 

bearbeiten. Wenn Sie eine Bindung mit einem Objekt herstellen, wird es in einem lokalen Zwischenspeicher 

auf dem Computer gespeichert, auf dem das Skript ausgeführt wird. 

Bei VBScript handelt es sich um eine objektbasierte Skriptsprache. Dadurch können Sie in Active 

Directory mit Objekten als einzelne Einheit arbeiten und Aktionen für ein vollständiges Objekt 

sowie für Objekteigenschaften durchführen. Beim Binden mit einem Active Directory-Objekt wird 

das Objekt in einer Variablen platziert, die das Objekt repräsentiert. Anschließend bearbeiten Sie die 

Variable und nicht das Objekt. 

Im folgenden Codebeispiel wird das Herstellen einer Bindung mit einer Active Directory-OU dargestellt. 

Die Variable acctOU wird als speicherinterne Instanz der OU Buchhaltung festgelegt. Beachten 

Sie, dass die OU Buchhaltung über einen LDAP-Pfad definiert wird: 

Set acctOU = GetObject("LDAP://OU=Buchhaltung,dc=adatum,dc=com") 

Erstellen eines Objekts 

Beim Erstellen eines neuen Objekts ist das Erstellen einer neuen Variablen mit 

den Informationen zu dem neuen Objekt erforderlich. Das neue Objekt wird mithilfe der Methode 

Create in der Variablen für den Container erstellt. Bei Methoden handelt es sich um Vorgänge, die ein 

Objekt durchführen kann. In Tabelle 10.11 werden einige der häufig verwendeten Methoden dargestellt, 

die für Active Directory-Objekte über die ADSI-Schnittstelle verfügbar sind. 

Tabelle 10.11 

VBScript-Methoden für die Verwaltung von Active Directory-Objekten 

Methode 

Create 

Get 

GetEx 

Put 

PutEx 

SetInfo 

Beschreibung 

Diese Methode wird zum Erstellen neuer Objekte verwendet. 

Diese Methode wird zum Abrufen des Werts eines Objektattributs verwendet. 

Diese Methode wird zum Abrufen von Werten als Array verwendet. In der Regel wird diese Methode für Mehrwertattribute 

verwendet. 

Diese Methode wird zum Platzieren eines neuen Werts in einem Objektattribut verwendet. 

Diese Methode wird zum Platzieren eines neuen Werts in einem Objektattribut mit erweiterten Optionen verwendet. 

Sie können mithilfe dieser Methode die Werte eines Mehrwertattributs verwalten. 

Diese Methode wird zum Speichern der Änderungen an einem neuen oder bearbeiteten Objekt verwendet. 

Im folgenden Codebeispiel wird das Erstellen eines neuen Benutzers in der OU Buchhaltung dargestellt. 

Die Variable newUser wird entsprechend des neuen Benutzerobjekts Paul West festgelegt. 

Anschließend wird für das Attribut sAMAccountName der Variablen newUser der Wert Paul festgelegt: 

Set newUser = acctOU.create("User","cn=Paul West") 

newUser.Put "sAMAccountName","Paul" 

Beim Erstellen eines neuen Objekts müssen Sie alle für diese Objektklasse erforderlichen Attribute 

definieren. In diesem Fall ist es ausreichend, die Attribute cn und sAMAccountName zu definieren, 

um ein neues Benutzerobjekt zu erstellen. Weitere erforderliche Attribute wie z.B. die SID werden 

automatisch vom System generiert. 

Speichern von Änderungen Beim Bearbeiten von Objekten mithilfe eines Skripts werden die Änderungen 

nur an der lokal zwischengespeicherten Version des Objekts vorgenommen. Diese Änderungen 

müssen mithilfe des folgenden Codes in Active Directory gespeichert werden: 

newUser.SetInfo


Mit der Methode SetInfo werden Änderungen nur für ein einzelnes Objekt gespeichert. Wenn Sie in 

Ihrem Skript mehrere Objekte bearbeitet haben, müssen Sie die Methode SetInfo für jedes Objekt 

anwenden. In manchen Fällen muss die Methode SetInfo für ein Objekt angewendet werden, bevor 

ein weiteres Objekt bearbeitet werden kann. Sie wenden beispielsweise die Methode SetInfo für einen 

neu erstellten Benutzer an, bevor Sie den Benutzer einer Gruppe hinzufügen können, da der Benutzer 

nicht im Verzeichnis vorhanden ist und eine Gruppe daher nicht auf ihn verweisen kann, bis die 

Methode SetInfo zum Erstellen des Benutzers in Active Directory angewendet wurde. 

Bearbeiten eines vorhandenen Objekts Anhand des folgenden Codes wird das Bearbeiten der Eigenschaften 

eines Benutzerkontos dargestellt. Die Variable modUser wird entsprechend des Benutzerobjekts 

Paul West festgelegt, anschließend werden die Attribute givenName, sn und displayName des 

Objekts geändert. Abschließend werden die Änderungen im Zwischenspeicher in Active Directory 

gespeichert. 

Set modUser = GetObject("LDAP://cn=Paul West,OU=Buchhaltung,DC=Adatum,DC=com") 

modUser.Put "givenName","Paul" 

modUser.Put "sn","West" 

modUser.Put "displayName","Paul West" 

modUser.SetInfo 

Weitere Informationen Weitere Informationen zum Verwalten von Active Directory-Objekten mithilfe von 

VBScript finden Sie auf der Seite „Getting Started“ (in englischer Sprache) des TechNet Script Center unter 

http://www.microsoft.com/technet/scriptcenter/hubs/start.mspx. Weitere Beispiele für VBScript-Skripts, die für 

die Verwaltung von Active Directory-Objekten verwendet werden können, werden auf der Seite „Active Directory“ 

(in englischer Sprache) des Script Repository unter http://www.microsoft.com/technet/scriptcenter/ 

scripts/default.mspx?mfr=true bereitgestellt. 

Verwenden von Windows PowerShell für die Verwaltung von Active Directory-Objekten 

Windows PowerShell ist eine neue, in Windows Server 2008 integrierte, Skripting- und Befehlszeilenumgebung, 

die Sie für die Verwaltung von Windows-Systemen einsetzen können. Sie müssen 

Windows PowerShell als Feature installieren, da es nicht standardmäßig installiert wird. Sie können 

Windows PowerShell auch für Windows XP SP2, Windows Vista und Windows Server 2003 herunterladen. 

Die Windows PowerShell-Befehle können direkt von einer Eingabeaufforderung oder in einem Skript 

verwendet werden. Die Befehlsshell PowerShell.exe stellt die Umgebung zum Ausführen von Windows 

PowerShell-Befehlen bereit. Diese Umgebung ist mit der von Cmd.exe bereitgestellten Umgebung 

für herkömmliche Befehlszeilenprogramme vergleichbar. Bei Windows PowerShell-Skripts handelt 

es sich um Textdateien mit Windows PowerShell-Befehlen, ebenso wie es sich bei Batchdateien 

um Textdateien mit Befehlen handelt, die über die Befehlszeile ausgeführt werden können. Windows 

PowerShell-Skripts tragen die Dateinamenerweiterung .ps1. 

Einige MMC-Snap-Ins (Microsoft Management Console) nutzen Windows PowerShell zum Durchführen 

von Aufgaben. Für die Exchange-Verwaltungskonsole für die Verwaltung von Microsoft 

Exchange Server 2007 beispielsweise ist Windows PowerShell erforderlich. 

Weitere Informationen Weitere Informationen zu Windows PowerShell werden auf der Seite „Windows 

PowerShell“ (in englischer Sprache) der Microsoft-Website unter http://www.microsoft.com/ 

windowsserver2003/technologies/management/powershell/default.mspx bereitgestellt.


Cmdlet-Syntax 

Bei einem Cmdlet handelt es sich um einen in Windows PowerShell verwendeten Befehl. Jedes Cmdlet 

setzt sich aus einem Verb-Nomen-Paar zusammen, das durch einen Bindestrich getrennt wird. Das 

Verb beschreibt den durchzuführenden Vorgang, und das Nomen beschreibt, wofür der Vorgang ausgeführt 

wird. Bei einigen häufig in Cmdlets verwendeten Verben handelt es sich um Get, Set, New 

und Remove. Meist werden dem Cmdlet Parameter hinzugefügt, um zusätzliche Informationen bereitzustellen. 

Den Parametern wird ein Bindestrich vorangestellt. Im folgenden Beispiel wird die Syntax 

für die Verwendung eines Cmdlets dargestellt: 

Verb-Nomen -Parametername Parameterwert -Parametername 

Im folgenden Beispiel wird ein Befehl dargestellt, der das Cmdlet Get-Help zum Anzeigen von Hilfeinformationen 

zum Cmdlet Get-Service verwendet. Der Parameter -Name wird verwendet, um den 

Namen des Cmdlets anzugeben, für das die Informationen angefordert werden. Der Parameter -Detailed 

gibt an, dass nicht nur zusammenfassende, sondern ausführliche Informationen ausgegeben werden 

sollen: 

Get-Help -Name Get-Service -Detailed 

Zugreifen auf Active Directory-Objekte 

Windows PowerShell umfasst keine speziellen Cmdlets für die Verwaltung von Active Directory- 

Objekten. Es gibt jedoch zwei Schnittstellen, über die Sie zur Bearbeitung auf Active Directory- 

Objekte zugreifen können. Bei System.DirectoryServices.DirectoryEntry handelt es sich um ein Klassenobjekt 

im Microsoft .Net Framework, das für den Zugriff auf alle verfügbaren Active Directory- 

Funktionen in Windows PowerShell verwendet werden kann. [ADSI] beschleunigt die Eingabe für 

das Klassenobjekt System.DirectoryServices.DirectoryEntry, das den Zugriff auf Active Directory 

vereinfacht. Die Verwendung von [ADSI] ist vergleichbar mit dem Zugreifen auf und Bearbeiten von 

Active Directory-Objekten mithilfe von VBScript. Diese beiden Methoden können auch gemeinsam 

verwendet werden. Sie können beispielsweise mithilfe von [ADSI] eine Verbindung mit einem Objekt 

herstellen und anschließend DirectoryEntry-Befehle für die Bearbeitung des Objekts verwenden. Im 

verbleibenden Teil dieses Kapitels wird [ADSI] verwendet, da es sich leichter verstehen und einsetzen 

lässt. 

Weitere Informationen Weitere Informationen zur Verwendung des DirectoryEntry-Objekts sowie ein Vergleich 

mit [ADSI] wird im Artikel „Benp’s Basic Guide to Managing Active Directory Objects with PowerShell“ 

auf der Technet Blogs-Website unter http://blogs.technet.com/benp/archive/2007/03/05/benp-s-basic-guideto-managing-active-directory-objects-with-powershell.aspx 


Das Verfahren zum Zugreifen auf Active Directory-Objekte in Windows PowerShell ist mit dem Verfahren 

bei der Verwendung von VBScript vergleichbar, die Syntax weist jedoch geringe Unterschiede 

auf. Als Erstes müssen Sie die ausgewählten Active Directory-Objekte binden, die gewünschten Änderungen 

vornehmen und anschließend die Änderungen anwenden. Bei den von [ADSI] am häufigsten 

verwendeten Methoden handelt es sich um Create(), Get() Put(), Delete(), und SetInfo(). 

Im folgenden Beispiel wird ein neuer Benutzer in der OU Buchhaltung erstellt. Die Variable $acctOU 

wird zur Herstellung einer Bindung mit der OU Buchhaltung verwendet. Mithilfe der Variablen 

$newUser wird der neue Benutzer Paul West erstellt. Beachten Sie, dass der neue Benutzer mithilfe 

der Methode SetInfo übernommen werden muss, bevor das Attribut sAMAccoutName definiert und 

angewendet wird. Hier besteht ein Unterschied zu der im VBScript-Beispiel dargestellten Vorgehensweise.


$acctOU = [ADSI] 'LDAP://OU=Buchhaltung,DC=Adatum,DC=com' 

$newUser = $acctOU.create('User','CN=Paul West') 

$newUser.setinfo() 

$newUser.sAMAccountName = 'Paul' 

$newUser.setinfo() 

Verwenden von .csv-Dateien 

Sie können das Cmdlet Import-Csv zum Laden von Daten aus einer .csv-Datei in eine Variable verwenden. 

Dieses Verfahren kommt am ehesten bei einer Massenobjekterstellung in Active Directory 

zum Einsatz. Die .csv-Datei muss eine Kopfzeile mit einer Beschreibung jeder Datenspalte enthalten. 

Die Beschreibungen in der Kopfzeile müssen jedoch nicht genau mit dem Namen der Objektattribute 

übereinstimmen, wie es bei Datendateien für das Dienstprogramm CSVDE der Fall ist. Die in der 

Kopfzeile bereitgestellten Beschreibungen werden nur zur Referenzierung der importierten Daten verwendet. 

Die Kopfzeile könnte beispielsweise die Beschreibung Anmeldename für die Daten enthalten, 

die letztendlich für das Attribut sAMAccountName verwendet werden. 

Wenn Sie nicht alle in einer .csv-Datei enthaltenen Daten verwenden möchten, können Sie die Daten 

mithilfe des Cmdlets Where-Object filtern. Mithilfe dieses Cmdlets können Sie basierend auf den 

Daten in der .csv-Datei einen Filter festlegen. Im folgenden Beispiel wird der Inhalt der Datei Benutzer.csv 

gefiltert, um nur die Zeilen zu verwenden, in denen für die Abteilung Buchhaltung festgelegt 

ist. Sie können zusätzliche Kriterien zu dem Filter hinzufügen, um komplexere Abfragen zu erstellen. 

Nachdem die angegebenen Zeilen in der Variablen $users gespeichert wurden, können die Daten zum 

Erstellen neuer Benutzer verwendet oder weiter bearbeitet werden. 

$users = Import-Csv C:\Users.csv | Where-Object {$_.department -eq "Buchhaltung"} 

Exchange-Verwaltungsshellbefehle 

Bei der Exchange-Verwaltungsshell handelt es sich um eine Erweiterung von Windows PowerShell, 

die in Microsoft Exchange Server 2007 integriert ist. Sie umfasst einige Cmdlets, die zur Verwaltung 

von Active Directory-Benutzern und -Gruppen eingesetzt werden können. Einige der für die Verwaltung 

von Active Directory-Objekten geeigneten Cmdlets werden in Tabelle 10.12 aufgeführt. Außerdem 

gibt es weitere Cmdlets speziell für postfachaktivierte Benutzer, E-Mail-aktivierte Benutzer, 

E-Mail-aktivierte Kontakte und Verteilergruppen. Mithilfe des Cmdlets New-Mailbox können beispielsweise 

neue Benutzer mit einem Exchange-Postfach erstellt werden. 

Tabelle 10.12 

Cmdlet 

Get-User 

Set-User 

Get-Group 

Set-Group 

Exchange-Verwaltungsshell-Cmdlets 

Beschreibung 

Dieses Cmdlet wird zum Abrufen einer Liste von Benutzern verwendet, die festgelegten Kriterien 

entsprechen. Zum Filtern von Benutzern auf Grundlage von Organisationseinheit, Unternehmensname 

oder Abteilung stehen zahlreiche Parameter zur Verfügung. Darüber hinaus 

gibt es einen allgemeinen Filterparameter, mit dem Sie eine Vielzahl weiterer Benutzerattribute 

als Filter einsetzen können. 

Mit diesem Cmdlet werden die Eigenschaften des angegebenen Benutzers bearbeitet. Die mithilfe 

des Cmdlets Get-User abgerufene Benutzerliste kann an dieses Cmdlet weitergeleitet 

werden. 

Dieses Cmdlet wird zum Abrufen einer Liste von Gruppen verwendet, die festgelegten Kriterien 

entsprechen. 

Dieses Cmdlet wird zum Bearbeiten einer eingeschränkten Anzahl an Merkmalen für die angegebene 

Gruppe verwendet.


Tabelle 10.12 

Cmdlet 

Get-Contact 

Set-Contact 

Exchange-Verwaltungsshell-Cmdlets (Fortsetzung) 

Beschreibung 

Dieses Cmdlet wird zum Abrufen einer Liste von Kontakten verwendet, die festgelegten Kriterien 

entsprechen. 

Mit diesem Cmdlet werden die Eigenschaften der angegebenen Kontakte bearbeitet. Die mithilfe 

des Cmdlets Get-Contact abgerufene Benutzerliste kann an dieses Cmdlet weitergeleitet 

werden. 


In diesem Kapitel wurde ein Überblick über die häufigsten Windows Server 2008 Active Directory- 

Objekte sowie über die Verfahren zum Verwalten von Active Directory-Objekten gegeben. Ein Großteil 

der von Ihnen durchgeführten Verwaltungsaufgaben fällt für diese Objekte an. Insbesondere werden 

Sie sich mit der Verwaltung von Gruppen- und Benutzerkonten beschäftigen, da Mitarbeiter neu 

eingestellt werden oder das Unternehmen verlassen, oder weil Sie im Rahmen der Absicherung von 

Netzwerkressourcen neue Gruppen erstellen müssen. Das Festlegen einer effektiven Strategie für 

Gruppentypen und -bereiche ist von grundlegender Bedeutung. Darüber hinaus fallen auch bei 

Objekten wie Computerobjekten, Druckerobjekten oder freigegebenen Ordnerobjekten Verwaltungsaufgaben 

an. 

In Windows Server 2008 haben Sie mehrere Möglichkeiten zur Automatisierung der Verwaltung von 

Active Directory-Objekten. Diese umfassen z. .B Befehlszeilenprogramme wie CSVDE und 

LDIFDE. Für komplexere Aufgaben stehen VBScript oder Windows PowerShell zur Verfügung. 


• Verwenden Sie die Tools Ldp.exe und Adsiedit.msc zum Bearbeiten von Objektattributen, die in 

Standardverwaltungstools wie z.B. Active Directory-Benutzer und -Computer nicht angezeigt 

werden. Gehen Sie jedoch beim direkten Bearbeiten von Objekten sehr umsichtig vor. 

• Verwenden Sie UPNs, um das Anmeldeverfahren in Umgebungen mit mehreren Domänen zu vereinfachen. 

Benutzer können sich an beliebigen Computern anmelden, ohne im Anmeldefeld die 

geeignete Domäne auswählen zu müssen. 

• Verwenden Sie beim Auswählen eines Dienstkontos nach Möglichkeit das Konto, das über die 

wenigsten Berechtigungen verfügt. Das Konto LOKALER DIENST verfügt über die geringsten 

Berechtigungen. Das Konto NETZWERKDIENST kann als lokales Computerkonto auf Netzwerkressourcen 

zugreifen. Mit dem Konto SYSTEM erhalten Sie vollen Zugriff auf den lokalen Computer 

und können über das lokale Computerkonto auf Netzwerkressourcen zugreifen. 

• Für eine einfachere Anwendung empfiehlt es sich, Gruppen in einer Hierarchie zu organisieren. 

Fügen Sie Gruppen zu globalen oder universellen Gruppen hinzu, um sie zu organisieren. Weisen 

Sie domänenlokalen Gruppen Berechtigungen für Ressourcen zu, und fügen Sie diesen Gruppen 

anschließend die geeigneten Mitglieder globaler und universeller Gruppen hinzu. 

• Beim Organisieren von Gruppen zwischen vertrauten Gesamtstrukturen sollten Benutzer in 

globalen Gruppen platziert werden, die wiederum in universellen Gruppen in der gleichen 

Gesamtstruktur platziert werden. Domänenlokalen Gruppen sollten Berechtigungen für Ressourcen 

zugewiesen werden, anschließend können die geeigneten Mitglieder universeller Gruppen als 

Mitglieder domänenlokaler Gruppen festgelegt werden.


• Verwenden Sie das Tool Netdom.exe zum Zurücksetzen des Kennworts eines Computerkontos, um 

zu vermeiden, dass das Computerkonto der Domäne erneut hinzufügt werden muss, wenn die Vertrauensstellung 

zwischen dem Computerkonto und der Domäne unterbrochen wurde. 

• Um Benutzern das Ermitteln von Druckern zu vereinfachen, sollten Sie die Nachverfolgung von 

Druckerstandorten konfigurieren und Druckerobjekte in Active Directory veröffentlichen. 

• Verwenden Sie zur Durchführung von Massenvorgängen für Active Directory-Objekte Befehlszeilenprogramme 

und Skripts. Das anfängliche Testen nimmt zwar etwas mehr Zeit in Anspruch, die 

Implementierung wird jedoch erheblich beschleunigt, was vor allem bei häufig durchgeführten 

Aufgaben von Vorteil ist. 

• Verwenden Sie zum Bearbeiten von Objekten das Tool LDIFDE, nicht CSVDE. Mit CSVDE können 

Sie vorhandene Objekte nicht bearbeiten, es dient lediglich zum Erstellen neuer Objekte. 

• Verwenden Sie in Windows PowerShell das Klassenobjekt System.DirectoryServices.Directory- 

Entry, um auf Active Directory-Objekte zuzugreifen, wenn [ADSI] nicht die erforderlichen Funktionen 

bereitstellt. 

• Denken Sie bei der Verwendung von VBScript- und PowerShell-Skripts daran, dass Sie die Änderungen 

im lokalen Zwischenspeicher mithilfe der Methode SetInfo in Active Directory speichern. 

• Verwenden Sie nach Möglichkeit Exchange-Verwaltungsshellbefehle, um die grundlegende 

Erstellung und Bearbeitung von Benutzer- und Gruppenobjekten zu vereinfachen. 



Kapitel. 


• Die Webseite „Microsoft Identity Lifecycle Manager 2007“ (in englischer Sprache) unter 

http://www.microsoft.com/windowsserver/ilm2007/default.mspx 

• Der Artikel „Role-Based Access Control for Multi-tier Applications Using Authorization Manager“ 

(in englischer Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/ 

72b55950-86cc-4c7f-8fbf-3063276cd0b61033.mspx 

• Der Artikel „How the Global Catalog Works“ (in englischer Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/440e44ab-ea05-4bd8-a68c-12cf8fb1af501033.mspx?mfr=true 

• Der Artikel „Default Groups“ (in englischer Sprache) unter http://technet2.microsoft.com/ 

windowsserver/en/library/1631acad-ef34-4f77-9c2e-94a62f8846cf1033.mspx?mfr=true 

• Der Artikel „Zurücksetzen von Computerkontokennwörtern eines Windows Server 2003-Domänencontrollers 

mit "Netdom.exe"“ unter http://support.microsoft.com/kb/325850. 

• Die Seite „Pubprn.vbs“ (in englischer Sprache) unter http://technet2.microsoft.com/ 

windowsserver2008/en/library/0bc7f7e3-84e1-4359-b477-7b1a1a0bd6391033.mspx?mfr=true 

• Der Artikel „Step-by-Step Guide to Bulk Import and Export to Active Directory“ (in englischer 

Sprache) auf der Technet-Website unter http://technet.microsoft.com/en-us/library/Bb727091.aspx 

• Der Artikel „CSVDE“ (in englischer Sprache) auf der Technet-Website unter 

http://technet2.microsoft.com/windowsserver/en/library/1050686f-3464-41af-b7e4- 

016ab0c4db261033.mspx?mfr=true


• Die Seite „Getting Started“ (in englischer Sprache) des TechNet Script Center unter 

http://www.microsoft.com/technet/scriptcenter/hubs/start.mspx 

• Die Seite „Active Directory“ (in englischer Sprache) des Script Repository unter 

http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true 

• Die Seite „Windows PowerShell“ (in englischer Sprache) der Microsoft-Website unter 

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx 


• Das Tool Ldp.exe verwendet LDAP für den Zugriff auf Active Directory. Über dieses Tool können 

Objekteigenschaften angezeigt und geändert werden, auf die mit dem Snap-In Active Directory-Benutzer 

und -Computer nicht zugegriffen werden kann. 

• Das Tool Adsiedit.msc verwendet ADSI für den Zugriff auf Active Directory. Über dieses Tool 

können Objekteigenschaften angezeigt und geändert werden, auf die mit dem Snap-In Active 

Directory-Benutzer und -Computer nicht zugegriffen werden kann. 


Die CD umfasst mehrere Beispiele für VBScript- und PowerShell-Skripts. Diese Skripts sind vollständig 

kommentiert, sodass Sie sie für die Verwendung in Ihrer eigenen Umgebung bearbeiten können. 

• Bei CreateUser.vbs handelt es sich um ein VBScript-Skript, in dem die grundlegenden Schritte 

zum Erstellen eines Benutzers dargestellt werden. 

• Bei CreateUser.ps1 handelt es sich um ein PowerShell-Skript, in dem die grundlegenden Schritte 

zum Erstellen eines Benutzers dargestellt werden. 

• Bei CreateUserFromCSV.vbs handelt es sich um ein VBScript-Skript, in dem das Erstellen von 

Benutzern auf Grundlage von Daten dargestellt wird, die aus einer .csv-Datei gelesen wurden. 

Dieses Skript ist für die Massenerstellung von Benutzern hilfreich. 

• Bei CreateUserFromCSV.ps1 handelt es sich um ein PowerShell-Skript, in dem das Erstellen von 

Benutzern auf Grundlage von Daten dargestellt wird, die aus einer .csv-Datei gelesen wurden. 

Dieses Skript ist für die Massenerstellung von Benutzern hilfreich. 

• Bei SearchforUserFromCSV.vbs handelt es sich um ein VBScript-Skript zum Ermitteln von 

Benutzern, die den in einer .csv-Datei aufgeführten Benutzern entsprechen. Dieses Skript ist hilfreich, 

wenn Sie vor der Massenerstellung von Konten aus der gleichen .csv-Datei die Eindeutigkeit 

der Daten überprüfen möchten. 

• Bei SearchforUserFromCSV.ps1 handelt es sich um ein PowerShell-Skript zum Ermitteln von 

Benutzern, die den in einer .csv-Datei aufgeführten Benutzern entsprechen. Dieses Skript ist hilfreich, 

wenn Sie vor der Massenerstellung von Konten aus der gleichen .csv-Datei die Eindeutigkeit 

der Daten überprüfen möchten. 

• Bei FindAndModifyUsers.vbs handelt es sich um ein VBScript-Skript, das die Ermittlung von 

Benutzern mithilfe eines bestimmten Attributwerts sowie die Bearbeitung der Benutzer darstellt. 

Dieses Skript ist für die Massenbearbeitung von Benutzerkonten hilfreich. 

• Bei FindAndModifyUsers.ps1 handelt es sich um ein PowerShell-Skript, das die Ermittlung von 

Benutzern mithilfe eines bestimmten Attributwerts sowie die Bearbeitung der Benutzer darstellt. 

Dieses Skript ist für die Massenbearbeitung von Benutzerkonten hilfreich.


• Bei CreateGroupAndAddMembers.vbs handelt es sich um ein VBScript-Skript, das die grundlegenden 

Schritte zum Erstellen einer Gruppe und zum Hinzufügen von Mitgliedern zu dieser 

Gruppe darstellt. 

• Bei CreateGroupAndAddMembers.ps1 handelt es sich um ein PowerShell-Skript, das die grundlegenden 

Schritte zum Erstellen einer Gruppe und zum Hinzufügen von Mitgliedern zu dieser 

Gruppe darstellt.

393 

K A P I T E L 1 1 

Einführung in Gruppenrichtlinien 


Gruppenrichtlinien – Übersicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 

Gruppenrichtlinienkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 

Gruppenrichtlinienverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 

Implementieren von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 

Verwalten von Gruppenrichtlinienobjekten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 

Erstellen von Skripts für die Gruppenrichtlinienverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

Planen einer Gruppenrichtlinienimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 

Fehlerbehebung bei Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 



Seit den Anfängen von Active Directory spielen Gruppenrichtlinien eine wichtige Rolle bei der Optimierung 

der Verwaltung von IT-Umgebungen. Vielen Unternehmen merken, dass der Kaufpreis oder 

die Leasinggebühren eines Computers nur einen kleinen Teil der Gesamtkosten darstellen, die bei der 

Verwaltung und Wartung des Computers im Verlauf seiner Nutzungsdauer anfallen. Die Hauptkosten 

verursachen die Mitarbeiter, die diese Computer verwalten. Wenn alle Clientcomputer manuell verwaltet 

werden müssten, könnten die Kosten des Betriebs dieser Computer sehr schnell einen nicht 

mehr akzeptablen Grad erreichen. Um diese Thematik in den Griff zu bekommen, müssen sich Unternehmen 

von manuellen Prozessen verabschieden und eine automatisiertere und zentral verwaltete 

Form des Änderungs- und Konfigurationsmanagements für Benutzer- und Computereinstellungen in 

der Umgebung finden. 

Das Windows Server 2008-Feature Gruppenrichtlinien bietet viele der Funktion, die zum Senken der 

Verwaltungskosten von Computersystemen benötigt werden. Das Änderungs- und Konfigurationsmanagement 

wird mithilfe von Gruppenrichtlinien optimiert, indem benutzerund computerbasierte 

Richtlinieneinstellungen gruppiert werden, die auf verschiedenen Ebenen der Active Directory-Hierarchie 

angewendet werden können. Wenn Sie eine Konfigurationseinstellung mithilfe von Gruppenrichtlinien 

anwenden, kann diese Einstellung (bzw. Einstellungsgruppe) auf einige oder alle Computer 

und Benutzer in Ihrem Unternehmen angewendet werden. 

Dieses Kapitel bietet eine Einführung in Gruppenrichtlinien und erläutert, wie dieses Feature konfiguriert 

und innerhalb der gesamten Active Directory-Struktur angewendet werden kann. Ferner werden 

einige der neuen Gruppenrichtlinienfeatures und Weiterentwicklungen unter Windows Server 2008 

beschrieben.

394 Kapitel 11: Einführung in Gruppenrichtlinien 

Hinweis Gruppenrichtlinieneinstellungen gelten nur auf Computern mit Microsoft Windows 2000 oder 

höher. Mithilfe von Gruppenrichtlinieneinstellungen können Sie Server mit Windows 2000, Windows Server 

2003 und Windows Server 2008 verwalten. Außerdem können Sie hiermit Computer mit Windows 2000, 

Windows XP Professional und den meisten Editionen von Windows Vista verwalten. Nicht möglich ist hingegen 

eine Gruppenrichtlinienverwaltung von Computern mit Windows NT, Windows 95, Windows 98 und Windows 

Millennium. Windows Server 2008 enthält eine Obermenge aller Richtlinieneinstellungen früherer 

Betriebssystemversionen. Einstellungen gelten jedoch nur für Betriebssysteme, die von der jeweiligen Einstellung 

unterstützt werden. Einstellungen, die von einem bestimmten Betriebssystem nicht unterstützt werden, 

werden ignoriert und auf dem Computersystem nicht verarbeitet. 

Gruppenrichtlinien – Übersicht 

Gruppenrichtlinien unter Windows Server 2008 bieten leistungsstarke Funktionen zum Verwalten von 

Konfigurationseinstellungen von Computern und Benutzern in Ihrer Active Directory-Umgebung. 

Tabelle 11.1 zeigt, welche Aufgaben Sie mithilfe von Gruppenrichtlinien erledigen können. 

Tabelle 11.1 

Konfigurationsfeatures von Gruppenrichtlinien 

Feature 


und -verwaltung 

Skripts 

Sicherheitseinstellungen 


Richtlinienbasierte 

Dienstqualität 

Internet Explorer- 

Einstellungen 

Administrative 

Vorlagen 

Erläuterung 

Über Active Directory-basierte Gruppenrichtlinien können Sie Benutzern und Computern Software und 

Softwareaktualisierungen bereitstellen. Sie können Software auch entfernen oder Softwarebereitstellungen 

basierend auf der Position von Benutzer- und Computerobjekten in der Active Directory-Struktur 

steuern. 

Sie können Skripts zum Starten und Herunterfahren von Computern sowie zur An- und Abmeldung 

von Benutzern ausführen. 

Sie können sehr viele Sicherheitseinstellungen für Computer- und Benutzerobjekte konfigurieren. Zu 

den computerbasierten Sicherheitseinstellungen zählen Kontorichtlinien, lokale Richtlinien, Ereignisprotokolleinstellungen 

sowie Einstellungen für eingeschränkte Gruppen, Systemdienste, die Windows-Firewall 

und den Netzwerkzugriffsschutz. Zu den benutzerbasierten Sicherheitseinstellungen 

zählen Richtlinien für öffentliche Schlüssel und Softwarebeschränkungsrichtlinien. 

Sie können verschiedene Teile der Arbeitsumgebung des Benutzers, z.B. den Ordner Dokumente, 

das Menü Start oder den Desktop, an eine Netzwerkfreigabe umleiten, in der diese dem Benutzer 

stets zur Verfügung stehen und im Rahmen der routinemäßigen Sicherungsvorgänge des Unternehmens 

gesichert werden können. Diese Umleitung erfolgt vom Benutzer unbemerkt. Windows Server 

2008 und Windows Vista bieten zusätzliche Funktionalität zum Umleiten weiterer Ordner, z.B. der 

Ordner Kontakte, Downloads, Favoriten, Links, Musik, Gespeicherte Spiele, Suchen und Videos. 

Mithilfe von Gruppenrichtlinien können Sie Einstellungen aktivieren, um ausgehenden Netzwerkdatenverkehr 

mit Prioritäten zu versehen und zu steuern. Eine Dienstqualitätsrichtlinie kann ausgehendem 

Netzwerkdatenverkehr einen bestimmten DSCP-Wert (Differentiated Services Code Point) zuweisen 

und steuern, welche Anwendungen, IP-Adressen, Protokolle und Portnummern im Netzwerk mit Prioritäten 

versehen und gesteuert werden sollen. 

Mithilfe von Gruppenrichtlinien können Sie die Menüs und Symbolleisten des Browsers, die Verbindungseinstellungen, 

URL-Favoriten, Sicherheitsfeatures und standardmäßigen Interneteinstellungen 

verwalten. Unter Administrative Vorlagen\Windows-Komponenten\Internet Explorer können Internet 

Explorer-Einstellungen nun umfassend konfiguriert werden. 

Mit der Funktion Administrative Vorlagen können Sie viele Elemente auf der grafischen Benutzeroberfläche 

verwalten, z.B. Systemsteuerungs- und Desktopeinstellungen, das Menü Start und Taskleisteneinstellungen. 

Diese Einstellungen dienen zum Konfigurieren von Registrierungswerten, welche 

die Änderungen einschränken, die Benutzer auf ihren Computern vornehmen dürfen.

Gruppenrichtlinien – Übersicht 395 

Tabelle 11.1 

Konfigurationsfeatures von Gruppenrichtlinien (Fortsetzung) 

Feature 

Einstellungen 

Drucker 

Sperren der 

Geräteinstallation 

Energieverwaltungseinstellungen 

Erläuterung 

Über diese Einstellungen werden Optionen von Windows-Einstellungen oder der Systemsteuerung 

verwaltet, u.a. Laufwerkzuordnungen, Umgebungsvariablen, Netzwerkfreigaben, lokale Benutzer und 

Gruppen, Dienste, Geräte usw. 

Administratoren können nun über Gruppenrichtlinien Berechtigungen an Benutzer für die Installation 

von Druckertreibern (sowie anderer Gerätetreiber) delegieren. Weitere Informationen zu diesem Feature 

finden Sie in „Neue Kategorien der Richtlinienverwaltung“ unter http://technet2.microsoft.com/ 

windowsvista/de/library/0077cf9d-b06c-4264-99ff-1beb569dd3d21031.mspx?mfr=true. 

Sie können die Installation von Geräten auf Computern in Ihrem Unternehmen zentral sperren. Sie 

können Richtlinieneinstellungen definieren, die den Zugriff auf Geräte wie USB-, CR-RW-, DVD-RW- 

Laufwerke und andere Wechseldatenträger steuern. Geräteinstallationseinstellungen finden Sie unter 

Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Geräteinstallation. 

Sämtliche Energieverwaltungseinstellungen können nun mit Gruppenrichtlinien gesteuert werden, was 

möglicherweise zu hohen Kosteneinsparungen führt. Sie können über einzelne Gruppenrichtlinieneinstellungen 

bestimmte Energieeinstellungen ändern oder einen angepassten Energieplan erstellen, der 

über Gruppenrichtlinien bereitgestellt werden kann. Energieverwaltungseinstellungen finden Sie unter 

Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Energieverwaltung. 

Funktionsweise von Gruppenrichtlinien 

Jedes der in Tabelle 11.1 beschriebenen Features besteht aus sehr vielen Richtlinieneinstellungen, die 

so konfiguriert werden können, dass sie für einen Benutzer oder Computer gelten. Richtlinieneinstellungen 

werden als Gruppenrichtlinienobjekte konfiguriert und mit verschiedenen Ebenen der Active 

Directory-Struktur verknüpft, z.B. Standort, Domäne und Organisationseinheit. Die Active Directory- 

Hierarchie bietet die Möglichkeit, dass Gruppenrichtlinieneinstellungen, die mit Containern auf 

höherer Ebene verknüpft sind (z.B. der Domäne oder Organisationseinheitscontainern auf oberster 

Ebene), von Containern auf tieferer Ebene übernommen werden. Diese „Vererbbarkeit“ bietet eine 

effiziente und effektive Methode zum Anwenden von Gruppenrichtlinieneinstellungen in der gesamten 

Umgebung. 

Bei der Ersterstellung einer Active Directory-Domäne werden zwei Gruppenrichtlinienobjekte erstellt 

und innerhalb von Active Directory verknüpft: Default Domain Policy (Standarddomänenrichtlinie) 

und Default Domain Controllers Policy (Standard-Domänencontrollerrichtlinie). Die Standarddomänenrichtlinie 

ist auf Domänenebene verknüpft und dient zum Festlegen der standardmäßigen Sicherheits- 

und Kennwortrichtlinien für die gesamte Domäne. Die Standard-Domänencontrollerrichtlinie 

ist mit der Organisationseinheit des Domänencontrollers verknüpft und dient zum Konfigurieren von 

Sicherheitseinstellungen für Domänencontroller. Zusätzlich zu diesen standardmäßigen Gruppenrichtlinienobjekten 

können Sie nach Wunsch beliebige viele weitere Gruppenrichtlinienobjekte erstellen 

und diese mit verschiedenen Ebenen in Ihrer Active Directory-Struktur verknüpfen. 

Hinweis Ausdrücklich empfohlen wird, die Standarddomänenrichtlinie und die Standard-Domänencontrollerrichtlinie 

nicht zu bearbeiten oder zu ändern. Sie sollten stets neue Gruppenrichtlinienobjekte erstellen, 

um benutzerdefinierte Richtlinieneinstellungen anzuwenden, und sicherstellen, dass sich die standardmäßigen 

Gruppenrichtlinienobjekte ganz oben in der Prioritätenliste befinden.


Neben Active Directory-basierten Gruppenrichtlinien arbeiten lokale oder eigenständige Computerumgebungen 

auch mit einem lokalen Gruppenrichtlinienobjekt. Computer, auf denen Windows 

2000, Windows XP oder Microsoft Windows Server 2003 ausgeführt wird, verfügen über nur ein 

lokales Gruppenrichtlinienobjekt, das für alle Benutzer gilt, die sich am lokalen Computer anmelden. 

Windows Vista und Windows Server 2008 enthalten standardmäßig auch ein lokales Gruppenrichtlinienobjekt, 

bieten jedoch die Möglichkeit, lokale Gruppenrichtlinienobjekte für mehrere Benutzer 

zu verwenden, um die Verwaltungs- und Sicherheitsfunktionen von eigenständigen Computern oder 

Computern in einer Arbeitsgruppe zu optimieren. 

Hinweis Für den Computer gilt stets ein einzelnes lokales Gruppenrichtlinienobjekt, das auch auf allen 

Computern verarbeitet wird, die zu Active Directory gehören. Das lokale Gruppenrichtlinienobjekt hat jedoch 

die niedrigste Priorität und ist die erste angewendete Richtlinie. Die Active Directory-basierten Gruppenrichtlinieneinstellungen 

setzen die Einstellungen des lokalen Gruppenrichtlinienobjekts häufig außer Kraft. Sie 

können die Verarbeitung des lokalen Gruppenrichtlinienobjekts für domänenbasierte Computer deaktivieren, 

indem Sie in der Konsole Gruppenrichtlinienverwaltung die Richtlinie Verarbeitung lokaler Gruppenrichtlinienobjekte 

deaktivieren unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Gruppenrichtlinie 

aktivieren. Dies betrifft nur Computer mit Windows Vista und Windows Server 2008. 

Abbildung 11.1 veranschaulicht, wie Gruppenrichtlinien ausgehend vom lokalen Gruppenrichtlinienobjekt 

auf den verschiedenen Ebenen von Active Directory angewendet werden: 

1. Falls aktiviert, wird das lokale Gruppenrichtlinienobjekt für sowohl eigenständige Computer als 

auch Mitgliedscomputer einer Active Directory-Domäne zuerst verarbeitet. 

2. Auf der Ebene Standort angewendete Gruppenrichtlinienobjekte werden als Nächstes verarbeitet. 

In der Abbildung wird Gruppenrichtlinienobjekt1 auf alle Benutzer und Computer in Domänen 

und Organisationseinheiten angewendet, die zu einem bestimmten Standort gehören. Gibt es in 

Konflikt stehende Einstellungen mit dem lokalen Gruppenrichtlinienobjekt, setzen die im 

Gruppenrichtlinienobjekt1 konfigurierten Einstellungen diese spezifischen Einstellungen außer 

Kraft. 

3. Im nächsten Schritt werden die Gruppenrichtlinienobjekte auf Domänenebene verarbeitet. Hier 

zugewiesene Gruppenrichtlinienobjekte wirken sich nur auf Benutzer und Computer der jeweiligen 

Domäne aus. Wenn es mit Gruppenrichtlinieneinstellungen auf Standortebene oder mit dem 

lokalen Gruppenrichtlinienobjekt in Konflikt stehende Einstellungen gibt, haben die domänenbasierten 

Einstellungen Vorrang. Nicht in Konflikt stehende Einstellungen werden von den 

Gruppenrichtlinienobjekten auf höherer Ebene übernommen. 

4. Im letzten Schritt werden auf den Organisationseinheitsebenen zugewiesene Gruppenrichtlinienobjekte 

verarbeitet. Auf Organisationseinheitsebene zugewiesene Gruppenrichtlinienobjekte wirken 

sich üblicherweise auf Benutzer und Computer in der jeweiligen Organisationseinheit aus und 

werden auch von sämtlichen untergeordneten Organisationseinheiten übernommen. Wenn es mit 

Gruppenrichtlinieneinstellungen auf Domänen- oder Standortebene bzw. mit dem lokalen Gruppenrichtlinienobjekt 

in Konflikt stehende Einstellungen gibt, haben die organisationseinheitsbasierten 

Einstellungen, die dem Computer und Benutzer am nächsten sind, Vorrang. Nicht in 

Konflikt stehende Einstellungen werden von den Gruppenrichtlinienobjekten auf höherer Ebene 

übernommen. 

Hinweis Die vorherigen Ausführungen beschreiben das Standardverhalten bei der Gruppenrichtlinienverarbeitung. 

Außerkraftsetzung, Deaktivierung von oben und Loopback sind andere Mechanismen zum 

Ändern der Verarbeitungsreihenfolge entsprechend den Anforderungen des Administrators.

Gruppenrichtlinien – Übersicht 397 

LGPO 

1 

GPO1 

Standort 

2 

GPO2 

GPO3 

Domäne 

3 

GPO4 

4 


Das Anwenden von Gruppenrichtlinienobjekten in Active Directory 

Neuerungen in Windows Server 2008-Gruppenrichtlinien 

In Windows Server 2008 wurden weitreichende Verbesserungen und Weiterentwicklungen von Features 

eingeführt, um die Verarbeitung und Verwaltung von Gruppenrichtlinien zu unterstützen. Dazu 

zählen die Folgenden: 

• Integration der Konsole Gruppenrichtlinienverwaltung Gruppenrichtlinien werden nicht mehr über 

die Konsole Active Directory-Benutzer und -Computer verwaltet. Die Konsole Gruppenrichtlinienverwaltung, 

die zuvor als separate Zusatzkomponente aus dem Microsoft Download Center 

heruntergeladen werden musste, ist nun integrierter Bestandteil von Windows Server 2008. Die 

Konsole Gruppenrichtlinienverwaltung kann mithilfe des Assistenten zum Hinzufügen von Features 

oder automatisch installiert werden, wenn einem Server die Serverrolle Active Directory- 

Domänendienste zugewiesen wird. Diese Konsole unterstützt nun die neue ADMX-Dateivorlage 

und bietet neue Filterfunktionen sowie die Möglichkeit, bestimmte Richtlinieneinstellungen zu 

kommentieren.


• Der Gruppenrichtlinienclient-Dienst Das Gruppenrichtlinienmodul und clientseitige Erweiterungen 

werden nicht mehr vom Prozess Winlogon verwaltet. Das Gruppenrichtlinienmodul wird nun als 

Dienst (gpsvc) ausgeführt, der eine effizientere und sicherere Verarbeitungsumgebung für das 

Anwenden von Gruppenrichtlinieneinstellungen bietet. 

• Netzwerkadressinformationen Das Gruppenrichtlinienmodul arbeitet nicht mehr mit dem ICMP- 

Protokoll (PING), um die effektive Netzwerkbandbreite zu bestimmen. Unter Windows Server 

2008 verwendet das Gruppenrichtlinienmodul nun den Dienst für Netzwerkadressinformationen 

(NlaSvc), um sich ändernde Netzwerkbedingungen zu bestimmen, die sich ggf. auf die Anwendung 

von Gruppenrichtlinien auswirken. 

• Neue auf XML basierende administrative Vorlagen Für Gruppenrichtlinien wurde bislang ein 

besonderes ADM-Dateiformat verwendet. Die entsprechende Datei enthält die Sprache zum 

Beschreiben registrierungsbasierter Einstellungen, die ggf. auf Netzwerkclients mithilfe von 

Gruppenrichtlinien zugewiesen werden. Unter Windows Server 2008 wird ein neues XML-Dateiformat 

mit der Bezeichnung ADMX eingeführt. Dieses neue Dateiformat vereinfacht die Verwaltung 

administrativer Vorlagen in mehrsprachigen Umgebungen und bietet die Möglichkeit, 

Änderungsmanagementprozesse zu integrieren. 

• Zentraler Speicher für Gruppenrichtlinien ADMX-Dateien können in einem zentralen Speicher in 

der Freigabe SYSVOL auf Domänencontrollern gespeichert werden. Dieser zentrale Speicher 

ermöglicht Administratoren beim Bearbeiten der Einstellungen von Gruppenrichtlinienobjekten 

den Zugriff auf denselben ADMX-Dateisatz und gewährleistet eine einheitliche Verwaltungsumgebung 

in der gesamten Domäne. 

• Verbesserte Gruppenrichtlinienprotokollierung Für frühere Versionen von Gruppenrichtlinien 

musste die Protokollierung für die Komponente userenv.dll aktiviert werden. Unter Windows Server 

2008 wird ein eigenständiger Dienst unter dem Protokoll Svchost ausgeführt. Dazugehörige 

Ereignismeldungen werden nun im Systemprotokoll mit der Ereignisquelle Microsoft-Windows- 

GroupPolicy angezeigt. Außerdem ersetzt das neue Betriebsprotokoll der Gruppenrichtlinie die 

Protokollierung über Userenv.dll, wodurch sich verbesserte Ereignismeldungen zur Gruppenrichtlinienverarbeitung 

ergeben. 

• Unterstützung mehrerer lokaler Gruppenrichtlinienobjekte Windows Server 2008 und Windows 

Vista unterstützen auf einem Computer mehrere lokale Gruppenrichtlinienobjekte. Dadurch ergeben 

sich verbesserte Möglichkeiten zum Steuern von Umgebungen, in denen ein einzelner Computer 

von mehreren Benutzern genutzt wird (z.B. in einer Bibliothek), oder von Computern in 

Arbeitsgruppen. Mehrere lokale Gruppenrichtlinieneinstellungen können einzelnen lokalen Benutzern 

bzw. lokalen Benutzern zugewiesen werden, die den vordefinierten lokalen Gruppen Administratoren 

oder Benutzer (Nichtadministratoren) angehören. In der Regel kommt dieses Feature 

auf eigenständigen Arbeitsstationen in einer Arbeitsgruppe zum Einsatz, doch lokale Gruppenrichtlinienobjekte 

funktionieren auch mit domänenbasierten Gruppenrichtlinien. Dieses Feature 

kann über eine Gruppenrichtlinieneinstellung deaktiviert werden. 

• Neue Gruppenrichtlinieneinstellungen Windows Server 2008 bietet nun über 2600 Richtlinieneinstellungen 

für administrative Vorlagen, einschließlich Kategorien für die Energieverwaltung, die 

Zuweisung von Druckern abhängig vom Standort, das Verhindern der Installation von Geräten 

(z.B. USB-, DVD- und andere Wechsellaufwerke) u.s.w. Verschiedene clientseitige Erweiterungen 

unter der Überschrift Einstellungen wurden ebenfalls hinzugefügt und bieten eine bessere 

Steuerung verschiedener Windows- und Systemsteuerungseinstellungen.

Gruppenrichtlinienkomponenten 399 

Einzelne Registrierungseinstellungen können nun außerhalb der Richtlinienstruktur bearbeitet und 

auf ausschließlich ausgewählte Benutzer oder Gruppen angewendet werden (ähnlich der Verwendung 

von Anmeldeskripts in vielen Unternehmen). Der Hauptvorteil des Features Einstellungen 

ist, dass diese einzelnen Registrierungseinstellungen als Richtlinieneinstellungen behandelt und 

entfernt werden können, falls sie nicht mehr benötigt werden. 

Gruppenrichtlinienkomponenten 

Ein Active Directory-basiertes Gruppenrichtlinienobjekt besteht aus zwei Hauptkomponenten, welche 

die logische und physische Struktur des Objekts abbilden. Die logische Komponente wird in der 

Active Directory-Datenbank gespeichert und heißt Gruppenrichtliniencontainer. Die physische Komponente 

wird im replizierten Ordner SYSVOL auf allen Domänencontrollern gespeichert und heißt 

Gruppenrichtlinienvorlage. 

Übersicht über den Gruppenrichtliniencontainer 

Der Gruppenrichtliniencontainer wird beim Erstellen eines neuen Gruppenrichtlinienobjekts in der 

Active Directory-Datenbank erstellt. Sie können das Containerobjekt in der Konsole Active Directory- 

Benutzer und -Computer im Container System\Richtlinien anzeigen. Wird der Container System nicht 

angezeigt, wählen Sie im Menü Ansicht den Befehl Erweiterte Features. Abbildung 11.2 zeigt den 

Container System\Richtlinien mit mehreren Gruppenrichtliniencontainern. 


Bestimmen von Gruppenrichtliniencontainern in Active Directory 

Wie in Abbildung 11.2 gezeigt, wird der Gruppenrichtliniencontainer in Active Directory mit dem 

Objekttyp groupPolicyContainer erstellt und mit der GUID (Globally Unique Identifier, global eindeutige 

Kennung) als Name angezeigt. Der Gruppenrichtliniencontainer enthält Attribute, die verschiedene 

Arten von Informationen zum Gruppenrichtlinienobjekt beschreiben: 

• Name des Gruppenrichtlinienobjekts Das Attribut displayName enthält den Namen des Gruppenrichtlinienobjekts.


• Pfad zur Gruppenrichtlinienvorlage Das Attribut gPCFileSysPath enthält den Pfad zum Speicherort 

der dazugehörigen Gruppenrichtlinienvorlage, die mithilfe des GUID-Namens des Gruppenrichtliniencontainers 

bestimmt wird. 

• Liste der Computer- und Benutzererweiterungen Die Attribute gPCMachineExtensionNames und 

gPCUserExtensionNames stellen eine Liste der clientseitigen Erweiterungen zum Verarbeiten des 

Gruppenrichtlinienobjekts zur Verfügung. Hierzu wird das folgende Format verwendet: 

[{GUID der clientseitigen Erweiterung}{GUID der MMC-Erweiterung}{GUID der zweiten 

MMC-Erweiterung, falls zutreffend}][GUIDs der nächsten clientseitigen Erweiterungen und 

MMC-Erweiterungen gemäß der Konfiguration] 

• Versionsnummer Das Attribut versionNumber enthält die Version des Gruppenrichtliniencontainer-Teils 

des Gruppenrichtlinienobjekts. Eine Versionsnummer wird sowohl vom Gruppenrichtliniencontainer 

als auch von der Gruppenrichtlinienvorlage geführt und soll sicherstellen, dass die 

beiden Objekte synchronisiert werden. 

• Status von Gruppenrichtlinienobjekten Das Attribut flags veranschaulicht den Status des Gruppenrichtlinienobjekts. 

Ist der Wert 0, ist das Gruppenrichtlinienobjekt aktiviert. Beim Wert 1 ist der 

Teil Benutzerkonfiguration des Gruppenrichtlinienobjekts deaktiviert. Beim Wert 2 ist der Teil 

Computerkonfiguration des Gruppenrichtlinienobjekts deaktiviert. Ist der Wert 3, ist das gesamte 

Gruppenrichtlinienobjekt deaktiviert. 

• Zugriffssteuerungsliste Die Zugriffssteuerungsliste zeigt die Benutzer und Gruppen, die die Einstellungen 

des Gruppenrichtlinienobjekts verwalten dürfen bzw. die Benutzer und Gruppen, für 

die die Einstellungen des Gruppenrichtlinienobjekts gelten sollen. 

Diese Details des Gruppenrichtliniencontainer-Objekts können in der Konsole Active Directory- 

Benutzer und -Computer oder mit einem Tool wie ADSI Edit angezeigt werden. Abbildung 11.3 zeigt 

die Registerkarte Attribut-Editor im Eigenschaftendialogfeld des Gruppenrichtliniencontainers in 

Active Directory-Benutzer und -Computer. Der Attribut-Editor ist ein neues Windows Server 2008- 

Feature in Active Directory-Benutzer und -Computer. 


Anzeigen der Attribute des Gruppenrichtliniencontainers

Komponenten der Gruppenrichtlinienvorlage 

Gruppenrichtlinienkomponenten 401 

Achtung Das Ändern der Zugriffssteuerungsliste bzw. der dazugehörigen Attribute unmittelbar im Gruppenrichtliniencontainer 

wird nicht empfohlen, es sei denn, Sie untersuchen Probleme. Gruppenrichtlinien 

sollten stets in der Konsole Gruppenrichtlinienverwaltung verwaltet werden. Diese Konsole sorgt dafür, dass 

sowohl der Gruppenrichtliniencontainer als auch die Gruppenrichtlinienvorlage ordnungsgemäß bearbeitet 

werden. 

Beim Konfigurieren eines neuen Gruppenrichtlinienobjekts wird die dazugehörige Gruppenrichtlinienvorlage 

im Ordner %SystemRoot%\SYSVOL auf jedem Domänencontroller in der Domäne 

gespeichert. Abbildung 11.4 zeigt Beispiele mehrerer Gruppenrichtlinienvorlagen, die im freigegebenen 

Ordner SYSVOL (\SYSVOL\sysvol\Adatum.com\Policies) gespeichert werden. Beachten Sie, 

dass jede Gruppenrichtlinienvorlage mit derselben entsprechenden GUID-Nummer gespeichert wird, 

die im Gruppenrichtliniencontainer in Active Directory gespeichert ist. 

Hinweis Der Ordner, der im Ordner SYSVOL denselben Namen wie die Domäne trägt, ist kein Ordner, 

sondern eine Dateiverbindung. Dateiverbindungen ähneln Dateisystemordnern, enthalten jedoch einen Link, 

der auf einen tatsächlichen Ordner zeigt. Über den Befehl DIR in einem Konsolenfenster können Sie das Ziel 

einer Verbindung anzeigen. Das Wort wird vor dem Namen der Verbindung angezeigt, auf das 

der Name des Zielordners in eckigen Klammer folgt. Tools für die Verwaltung von Gruppenrichtlinien lesen 

und schreiben Gruppenrichtlinienvorlagen mittels der Domänenverbindung (Adatum.com) in der Freigabe 

SYSVOL. Windows speichert die Gruppenrichtlinienvorlagen jedoch unter %SYSTEMROOT%\SYSVOL\ 

domain\policies. Dadurch hat es den Anschein, es gäbe zwei Kopien der Gruppenrichtlinienvorlagen. 


Anzeigen der Speicherorte von Gruppenrichtlinienvorlagen auf Domänencontrollern


Die Gruppenrichtlinienvorlage enthält die meisten Einstellungen des Gruppenrichtlinienobjekts sowie 

verschiedene Ordner und Konfigurationsdateien (siehe Tabelle 11.2). 

Tabelle 11.2 

Komponente 

Adm 

USER 

MACHINE 

Gpt.ini 

Komponenten einer Gruppenrichtlinienvorlage 

Beschreibung 

Bei Verwenden von Windows Vista bzw. Windows Server 2008 kommt dieser Ordner nicht zum 

Einsatz. Falls jedoch der Gruppenrichtlinienobjekt-Editor aus früheren Windows-Versionen verwendet 

wird, enthält dieser Ordner eine Kopie aller ADM-Dateien (administrativen Vorlagen) im 

Ordner %SystemRoot%\inf des Computers, auf dem das Gruppenrichtlinienobjekt erstellt wurde. 

Enthält alle Einstellungen für die Benutzerkonfiguration. Je nach Konfiguration enthält dieser Ordner 

ggf. Folgendes: 

• Registry.pol: Enthält die Registrierungseinstellungen der Konfigurationen aller administrativen 

Vorlagen. 

• \Applications: Enthält Informationen, die bei der Installation der Gruppenrichtliniensoftware verwendet 

werden. 

• \Documents & Settings: Enthält Informationen zu Ordnerumleitungsrichtlinien, die im Gruppenrichtlinienobjekt 

konfiguriert sind. 

• \Microsoft\IEAK: Enthält Informationen zu Internet Explorer-Einstellungen, die im Gruppenrichtlinienobjekt 

konfiguriert sind. 

• \Scripts\Logon: Enthält die eigentlichen Dateien, die für im Gruppenrichtlinienobjekt definierte 

Anmeldeskripts verwendet werden. 

• \Scripts\Logoff: Enthält die eigentlichen Dateien, die für im Gruppenrichtlinienobjekt definierte 

Abmeldeskripts verwendet werden. 

Enthält alle Einstellungen für die Computerkonfiguration. Je nach Konfiguration enthält dieser Ordner 

ggf. Folgendes: 

• Registry.pol: Enthält die Registrierungseinstellungen der Konfigurationen aller administrativen 

Vorlagen. 

• \Applications: Enthält Informationen, die bei der Installation der Gruppenrichtliniensoftware verwendet 

werden. 

• \Microsoft\Windows NT\SecEdit: Enthält die Datei GptTmpl.inf, die zum Definieren der verschiedenen 

Sicherheitseinstellungen gemäß der Konfiguration im Teil Sicherheitseinstellungen 

des Gruppenrichtlinienobjekts dient. 

• \Scripts\Shutdown: Enthält die eigentlichen Dateien, die für im Gruppenrichtlinienobjekt definierte 

Skripts zum Herunterfahren verwendet werden. 

• \Scripts\Startup: Enthält die eigentlichen Dateien, die für im Gruppenrichtlinienobjekt definierte 

Skripts zum Starten verwendet werden. 

Die Datei Gpt.ini dient zum Speichern der Versionsnummer der Gruppenrichtlinienvorlage und des 

Anzeigenamens des dazugehörigen Gruppenrichtlinienobjekts. Die Versionsnummer ermöglicht 

clientseitigen Erweiterungen die Überprüfung, ob der Client hinsichtlich der letzten Verarbeitung 

der Richtlinieneinstellungen auf dem neuesten Stand ist. 

Replikation der Gruppenrichtlinienobjekt-Komponenten 

In den meisten Active Directory-Domänenumgebungen befinden sich mehrere Domänencontroller. 

Wenn ein Gruppenrichtlinienobjekt erstellt oder geändert wird, müssen die Änderungen von einem 

Domänencontroller auf die anderen repliziert werden.

Gruppenrichtlinienverarbeitung 403 

Wichtig ist dabei zu verstehen, dass die Komponenten, die ein Gruppenrichtlinienobjekt bilden 

(hauptsächlich der Gruppenrichtliniencontainer und die Gruppenrichtlinienvorlage) für die Replikation 

in der gesamten Domäne mit unterschiedlichen Mechanismen arbeiten. Der Gruppenrichtliniencontainer 

wird im Rahmen der regelmäßigen Active Directory-Replikation repliziert. Die Replikation 

der Gruppenrichtlinienvorlage hängt von der für die Domäne konfigurierten Domänenfunktionsebene 

ab. Wenn Ihre Domäne mit der Funktionsebene Windows Server 2008 konfiguriert ist, wird die Gruppenrichtlinienvorlage 

vom DFS-R-Dienst (Distributed File System Replication) repliziert. Domänen, 

die mit der Domänenfunktionsebene Windows Server 2003 oder niedriger konfiguriert sind, arbeiten 

mit dem Dateireplikationsdienst, der in früheren Windows Server-Versionen zumeist zum Einsatz 

kam. 

Gruppenrichtlinienverarbeitung 

Die Gruppenrichtlinieninfrastruktur ist eine Client/Server-Architektur, die sowohl Server- als auch 

Clientkomponenten nutzt, um Richtlinieneinstellungen auf Netzwerkclients anzuwenden. Die serverseitigen 

Erweiterungen sind MMC-Snap-Ins (Microsoft Management Console) zum Verwalten und 

Konfigurieren von Gruppenrichtlinieneinstellungen in der Konsole Gruppenrichtlinienverwaltung. 

Die clientseitigen Erweiterungen werten die auf dem Server konfigurierten Gruppenrichtlinieneinstellungen 

aus und wenden sie auf den Clientcomputer an. Abbildung 11.5 veranschaulicht die Kommunikation 

zwischen Server und Gruppenrichtlinienarchitektur. 


Client 

Serverseitige 

MMC-Snap-Ins 

Konsole 

Gruppenrichtlinienverwaltung 

Verwaltung 

Active 


(GPO) 

GPO 

SYSVOL 

(GPT) 

Gruppenrichtlinien für 

Clientdienst (gpsvc) 

Gruppenrichtlinienmodul 

Clientseitige 

Erweiterungen 

(CSEs) 

Dateisystem 

Registrierung 

Sicherheit 



Gruppenrichtlinienkommunikation zwischen Server und Client


Verarbeitung von Gruppenrichtlinienobjekten auf Clients 

Wie Abbildung 11.5 zeigt, wird auf Computern mit Windows Vista und Windows Server 2008 der 

neue Dienst Gruppenrichtlinienclient-Dienst (gpsvc) ausgeführt. Dieser Dienst übernimmt die Gruppenrichtlinienverarbeitung, 

die in früheren Windows-Versionen Teil des Winlogon-Dienstes war. 

Direkt von der Quelle: Der Gruppenrichtliniendienst 

Die Gruppenrichtlinienfunktion wird nun als eigener Dienst und nicht innerhalb des Winlogon-Prozesses 

ausgeführt. Durch diese Änderung erhöht sich die Zuverlässigkeit der Gruppenrichtlinienfunktion, 

da diese nun als gehosteter Dienst unter Svchost ausgeführt wird. Zu den Vorteilen dieser 

Änderung zählen die verbesserte Netzwerkerkennung, eine effizientere Gruppenrichtlinienverarbeitung 

und weniger Arbeitsspeicherbelegung durch jeden mit Gruppenrichtlinien arbeitenden Prozess. 

Die clientseitigen Erweiterungen von Microsoft werden im selben Prozessbereich ausgeführt. 

Clientseitige Erweiterungen anderer Anbieter werden jedoch zur Verbesserung der Zuverlässigkeit 

unter einem getrennten Prozess ausgeführt. 

Mike Stephens 

Group Policy Technical Writer 

Management and Solutions Division UA 

Bei allen gruppenrichtlinienfähigen Windows-Betriebssystemen werden die clientseitigen Erweiterungen 

im Rahmen der Installation installiert und registriert. Diese Erweiterungen bestehen aus verschiedenen 

DDL-Dateien (Dynamic Link Libraries), die vom Gruppenrichtlinienmodul aufgerufen 

werden, das anschließend die von der Gruppenrichtlinienvorlage und vom Gruppenrichtliniencontainer 

bereitgestellten Informationen nutzt, um die auf den Benutzer oder Computer anzuwendenden 

Richtlinieneinstellungen zu bestimmen. 

Hinweis Die DLLs der clientseitigen Erweiterungen (CSE) werden im Ordner %WinDir%\System32 

gespeichert. Andere Anwendungsanbieter können zusätzliche Erweiterungen entwickeln, damit ihre Anwendungen 

in die Verwaltung über Gruppenrichtlinien einbezogen werden können. 

Jede CSE-DLL arbeitet mit CSE-Registrierungseinstellungen unter dem folgenden Registrierungsschlüssel: 

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions 

Im Registrierungs-Editor (Regedit.exe) können Sie die Liste der clientseitigen Erweiterungen auf 

einem Clientcomputer anzeigen (siehe Abbildung 11.6). 

Wie in Abbildung 11.6 zu erkennen, ist jede clientseitige Erweiterung mit einer GUID verknüpft. 

Diese GUIDs werden im Gruppenrichtliniencontainer-Objekt in Active Directory referenziert. Jede 

Erweiterung hat verschiedene Attribute, die verschiedene Verarbeitungskonfigurationen bestimmen, 

z.B. ob der Benutzer- oder Computerteil der Richtlinie verarbeitet wird (gemäß den Schlüsseln 

NoMachinePolicy und NoUserPolicy) oder ob die Richtlinie über eine langsame Verbindung verarbeitet 

wird (gemäß dem Schlüssel NoSlowLink). Sie können auch die dazugehörige DLL bestimmen, 

indem Sie den für den Schlüssel Dllname angegebenen Wert untersuchen.



Anzeigen der auf einem Windows-Client registrierten clientseitigen Erweiterungen 

Eine Übersicht der standardmäßigen clientseitigen Erweiterungen und dazugehörigen GUIDs finden 

Sie in Tabelle 11.3. 

Tabelle 11.3 

Standardmäßige clientseitige Erweiterungen 

Clientseitige Erweiterung 

Gruppenrichtlinie für Drahtlosnetzwerk 

Gruppenrichtlinie für die Umgebung 

Gruppenrichtlinie für lokale Benutzer und Gruppen 

Gruppenrichtlinie für Geräteeinstellungen 



Microsoft-Datenträgerkontingente 

Gruppenrichtlinie für Netzwerkoptionen 

QoS-Paketplaner 

Skripts 

Zonenzuordnung für Internet Explorer 

Gruppenrichtlinie für Laufwerkzuordnungen 

GUID 

{0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63} 

{0E28E245-9368-4853-AD84-6DA3BA35BB75} 

{17D89FEC-5C44-4972-B12D-241CAEF74509} 

{1A6364EB-776B-4120-ADE1-B63A406A76B5} 

{25537BA6-77A8-11D2-9B6C-0000F8080861} 

{35378EAC-683F-11D2-A89A-00C04FBBCFA2} 

{3610eda5-77ef-11d2-8dc5-00c04fa31a66} 

{3A0DBA37-F8B2-4356-83DE-3E90BD5C261F} 

{426031c0-0b47-4852-b0ca-ac3d37bfcb39} 

{42B5FAAE-6536-11d2-AE5A-0000F87571E3} 

{4CFB60C1-FAA6-47f1-89AA-0B18730C9FD3} 

{5794DAFD-BE60-433f-88A2-1A31939AC01F}


Tabelle 11.3 

Standardmäßige clientseitige Erweiterungen (Fortsetzung) 


Gruppenrichtlinie für Ordner 

Gruppenrichtlinie für Netzwerkfreigaben 

Gruppenrichtlinie für Dateien 

Gruppenrichtlinie für Datenquellen 

Gruppenrichtlinie für INI-Dateien 

Gruppenrichtlinienerweiterung für Windows-Suchdienst 

Sicherheit 

Bereitgestellte Druckerverbindungen 

Gruppenrichtlinie für Dienste 

Internet Explorer-Branding 

Gruppenrichtlinie für Ordneroptionen 

Gruppenrichtlinie für geplante Tasks 

Gruppenrichtlinie für die Registrierung 

EFS-Wiederherstellung 

802.3-Gruppenrichtlinie 

Gruppenrichtlinie für Drucker 

Gruppenrichtlinie für Verknüpfungen 

Microsoft-Offlinedateien 


IP-Sicherheit 

Gruppenrichtlinie für Interneteinstellungen 

Gruppenrichtlinie für Einstellungen für das Menü "Start" 

Gruppenrichtlinie für regionale Einstellungen 

Gruppenrichtlinie für Energieoptionen 

Gruppenrichtlinie für Anwendungen 

Enterprise QoS 

GUID 

{6232C319-91AC-4931-9385-E70C2B099F0E} 

{6A4C88C6-C502-4f74-8F60-2CB23EDC24E2} 

{7150F9BF-48AD-4da4-A49C-29EF4A8369BA} 

{728EE579-943C-4519-9EF7-AB56765798ED} 

{74EE6C03-5363-4554-B161-627540339CAB} 

{7933F41E-56F8-41d6-A31C-4148A711EE93} 

{827D319E-6EAC-11D2-A4EA-00C04F79F83A} 

{8A28E2C5-8D06-49A4-A08C-632DAA493E17} 

{91FBB303-0CD9-4055-BF42-E512A681B325} 

{A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B} 

{A3F3E39B-5D83-4940-B954-28315B82F0A8} 

{AADCED64-746C-4633-A97C-D61349046527} 

{B087BE9D-ED37-454f-AF9C-04291E351182} 

{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A} 

{B587E2B1-4D59-4e7e-AED9-22B9DF11D053} 

{BC75B1ED-5833-4858-9BB8-CBF0B166DF9D} 

{C418DD9D-0D14-4efb-8FBF-CFE535C8FAC7} 

{C631DF4C-088F-4156-B058-4375F0853CD8} 

{c6dc5466-785a-11d2-84d0-00c04fb169f7} 

{e437bc1c-aa7d-11d2-a382-00c04f991e27} 

{E47248BA-94CC-49c4-BBB5-9EB7F05183D0} 

{E4F48E54-F38D-4884-BFB9-D4D2E5729C18} 

{E5094040-C46C-4115-B030-04FB2E545B00} 

{E6288F0-25FD-4c90-BFF5-F508B9D2E31F} 

{F9C77450-3A41-477E-9310-9ACD617BD9E3} 

{FB2CA36D-0B40-4307-821B-A13B252DE56C} 

Anfängliche Verarbeitung von Gruppenrichtlinienobjekten 

Wenn ein neues Gruppenrichtlinienobjekt erstellt oder geändert wird, werden die darin enthaltenen 

Richtlinieneinstellungen nur auf Clientcomputern verarbeitet, wenn dies vom Client explizit angefordert 

wird. Diese Anforderung erfolgt zu verschiedenen Zeitpunkten und kann von bestimmten Bedingungen 

abhängen: 

• Dem Typ des verwendeten Betriebssystems 

• Angaben dazu, ob der Computer zu einer Domäne gehört oder nicht 

• Der Position des Computers in Active Directory 

• Qualität oder Art der Netzwerkverbindung (z.B. langsame DFÜ- oder VPN-Verbindung) 

• Aktualisierungseinstellungen im Hintergrund (standardmäßige Aktualisierungszeiten sind 

5Minuten für einen Domänencontroller und 90 Minuten + einer beliebigen maximal 30-minütigen 

Abweichung für Domänenmitglieder. Hinweis: Eine Verkürzung ist nicht möglich.)


Gruppenrichtlinieneinstellungen werden in verschiedenen Abständen angefordert und auf Benutzer 

und Computer angewendet. Beim Start eines Computers werden die Computerrichtlinieneinstellungen 

angewendet. Sobald sich ein Benutzer am Computer anmeldet, werden die Benutzerrichtlinieneinstellungen 

angewendet. Je nach verwendetem Betriebssystem kann dies mithilfe synchroner oder 

asynchroner Verarbeitungsmethoden erfolgen. 

Direkt von der Quelle: Synchrone und asynchrone Gruppenrichtlinienverarbeitung 

Windows Server 2008 bietet eine synchrone und asynchrone Gruppenrichtlinienverarbeitung. Die 

asynchrone Gruppenrichtlinienverarbeitung (auch Hintergrundverarbeitung genannt) ist die Standardverarbeitungsmethode 

für Gruppenrichtlinien unter Windows Server 2008, Windows Vista, 

Windows Server 2003 und Windows XP. In diesem Modus erfolgt die Verarbeitung von Computerund 

Benutzergruppenrichtlinien im Hintergrund, während der Computer gestartet wird oder der 

Benutzer sich anmeldet. Diese Methode verkürzt die Anmeldedauer, da der Computer bzw. Benutzer 

nicht warten muss, bis die Gruppenrichtlinienverarbeitung abgeschlossen ist. Ordnerumleitung 

und Softwareinstallation werden dagegen nur während der synchronen Gruppenrichtlinienverarbeitung 

angewendet, da das asynchrone Anwenden dieser Richtlinieneinstellungen (im Hintergrund) 

zur Instabilität des Computers oder zum Datenverlust führen könnte. Die synchrone Gruppenrichtlinienverarbeitung 

gilt ferner standardmäßig für Benutzer mit einem servergespeicherten Profil, 

Basisverzeichnis oder Benutzeranmeldeskript. 

Im Gegensatz zur asynchronen Verarbeitung erfolgt die synchrone Gruppenrichtlinienverarbeitung 

während des Computerstarts und der Benutzeranmeldung und muss abgeschlossen sein, bevor der 

nächste Schritt des Anmeldevorgangs beginnen kann. Die Verarbeitung von Computergruppenrichtlinien 

muss beendet sein, damit Windows eine Benutzeranmeldung erlaubt. Die Verarbeitung 

von Benutzergruppenrichtlinien muss beendet sein, damit Windows den Benutzerdesktop bereitstellt. 

Regelmäßige Gruppenrichtlinienaktualisierungen werden stets ungeachtet des Verarbeitungsmodus 

von Gruppenrichtlinien asynchron verarbeitet. 

Im Gruppenrichtlinienmodul können Sie den Verarbeitungsmodus von Gruppenrichtlinien für 

Computer und Benutzer ändern, indem Sie die Richtlinieneinstellung Beim Neustart des Computers 

und bei der Anmeldung immer auf das Netzwerk warten unter Computerkonfiguration\ 

Richtlinien\Administrative Vorlagen\System\Anmelden aktivieren. 

Mike Stephens 


Management and Solutions 

Zur Verkürzung der Anmeldedauer sind Clientcomputer mit Windows XP Professional und Windows 

Vista für die Verwendung der Funktion Optimierung für schnelles Anmelden konfiguriert. Diese 

Funktion ermöglicht die asynchrone Verarbeitung von Gruppenrichtlinieneinstellungen beim Computerstart 

und der Benutzeranmeldung. Das Ergebnis ist, dass Benutzer einen Computer schneller starten 

und sich anmelden können, während Gruppenrichtlinieneinstellungen im Hintergrund angewendet 

werden. 

Hinweis Sie können die Einstellung Optimierung für schnelles Anmelden bearbeiten, indem Sie in der 

Konsole Gruppenrichtlinienverwaltung die Richtlinieneinstellung Beim Neustart des Computers und bei der 

Anmeldung immer auf das Netzwerk warten unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Anmelden 

konfigurieren.


Wichtig ist der Hinweis, dass Optimierung für schnelles Anmelden unter folgenden Bedingungen 

nicht wirksam wird und in einer synchronen Verarbeitung von Gruppenrichtlinieneinstellungen resultiert: 

• Wenn sich ein Benutzer erstmals an einem neuen oder anderen Computer anmeldet 

• Wenn ein Benutzer für die Verwendung synchroner Anmeldeskripts konfiguriert ist 

• Wenn ein Benutzer für Anmeldezwecke mit einem servergespeicherten Benutzerprofil oder Basisverzeichnis 

konfiguriert ist 

• Wenn Richtlinieneinstellungen zur Softwareinstallation angewendet werden 

Hinweis Windows 2000 und alle Windows Server-Versionen arbeiten mit der synchronen Verarbeitung bei 

der Anwendung von Gruppenrichtlinieneinstellungen und unterstützen nicht die Optimierung für schnelles 

Anmelden. 

Hinweis Die Richtlinien Softwareinstallation und Ordnerumleitung werden nur während der synchronen 

Richtlinienverarbeitung angewendet. Wenn die asynchrone Verarbeitung aktiviert ist, sind bei diesen Erweiterungen 

zwei Anmeldungen erforderlich, um die Richtlinieneinstellungen anzuwenden. Die erste Anmeldung 

legt das synchrone Verarbeitungskennzeichen fest, die zweite Anmeldung bringt die Aufgabe zum 

Abschluss. 

Aktualisierungen von Gruppenrichtlinienobjekten im Hintergrund 

Sie können Änderungen an einem vorhandenen Gruppenrichtlinienobjekt vornehmen oder neue 

Richtlinieneinstellungen anwenden, nachdem sich Benutzer bereits an ihren Computern angemeldet 

haben. Um sicherzustellen, dass alle neuen oder geänderten Einstellungen von Gruppenrichtlinienobjekten 

umgesetzt werden, arbeitet das Gruppenrichtlinienmodul mit einem Hintergrundaktualisierungsintervall. 

Das Hintergrundaktualisierungsintervall hängt vom verwendeten Betriebssystem ab, was nachfolgend 

erklärt wird: 

• Auf Mitgliedsservern und Clientarbeitsstationen erfolgt die Hintergrundverarbeitung standardmäßig 

alle 90 Minuten plus einem beliebigen Wert von 0 bis 30 Minuten. Dieser Toleranzwert soll 

sicherstellen, dass nicht alle Computer gleichzeitig versuchen, ihre Richtlinieneinstellungen zu 

aktualisieren. Dies hat zur Folge, dass Änderungen an einer Gruppenrichtlinieneinstellung mindestens 

90 Minuten und höchstens 120 Minuten benötigen, um für Benutzer und Computer wirksam 

zu werden, die bereits am Netzwerk angemeldet sind. 

• Auf Domänencontrollern werden Gruppenrichtlinieneinstellungen standardmäßig alle 5 Minuten 

aktualisiert. 

Hinweis Bei allen Betriebssystemen gelten für die Verarbeitung von Sicherheitsrichtlinien dieselben 

Regeln wie für andere Richtlinieneinstellungen. Sicherheitseinstellungen werden jedoch unabhängig davon, 

ob sich die Gruppenrichtlinienobjekt-Einstellungen geändert haben oder nicht, auf Nichtdomänencontrollern 

alle 16 Stunden und auf Domänencontrollern alle 5 Minuten aktualisiert. Dies stellt sicher, dass sämtliche 

sicherheitsbezogenen Richtlinieneinstellungen stets über die neueste Konfiguration verfügen. 

Wichtig ist der Hinweis, dass das Hintergrundaktualisierungsintervall für die Benutzer- und Computerteile 

des Gruppenrichtlinienobjekts getrennt angewendet wird. Sie können das Verarbeitungsintervall 

und das Toleranzintervall ändern, indem Sie in der Konsole Gruppenrichtlinienverwaltung die 

folgenden Gruppenrichtlinieneinstellungen konfigurieren:


• Gruppenrichtlinien-Aktualisierungsintervall für Computer unter Computerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Gruppenrichtlinie 

• Gruppenrichtlinien-Aktualisierungsintervall für Domänencontroller unter Computerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Gruppenrichtlinie 

• Gruppenrichtlinien-Aktualisierungsintervall für Benutzer unter Benutzerkonfiguration\Richtlinien\ 

Administrative Vorlagen\System\Gruppenrichtlinie 

Hinweis Die Gruppenrichtlinien Softwareinstallation und Ordnerumleitung werden nur beim Computerstart 

oder der Benutzeranmeldung angewendet und unterliegen keinem Hintergrundaktualisierungsintervall. Ferner 

erfolgen für Skriptdateien in der clientseitigen Erweiterung Skripts und Datenträgerkontingente keine Hintergrundaktualisierungen. 

Auch wenn die clientseitige Erweiterung Skripts eine Hintergrundverarbeitung 

durchführt, um Registrierungszeiger einzurichten, werden die tatsächlichen Skriptdateien, auf die in der 

clientseitigen Erweiterung verwiesen wird, nur zu ihrem konfigurierten Zeitpunkt ausgeführt (z.B. beim Start, 

Herunterfahren, Anmelden oder Abmelden). Datenträgerkontingente gelten erst, nachdem der Computer neu 

gestartet wurde. 

Beziehung zwischen dem Verlauf eines Gruppenrichtlinienobjekts und 

Gruppenrichtlinienaktualisierungen 

Jeder Computer, der Gruppenrichtlinieneinstellungen verarbeitet, verwaltet in der lokalen Registrierung 

einen Verarbeitungsverlauf. Über diese Verlaufsinformationen kann z.B. geprüft werden, ob ein 

Gruppenrichtlinienobjekt sich seit seinem letzten Verarbeitungsintervall geändert hat. Zu den gespeicherten 

Verlaufsdaten gehören die GUID der verarbeiteten clientseitigen Erweiterungen, eine numerische 

Liste der Gruppenrichtlinienobjekte, die eine bestimmte clientseitige Erweiterung verwenden, 

der Anzeigename der einzelnen Gruppenrichtlinienobjekte, der Pfad zu Gruppenrichtliniencontainer 

und -vorlage jedes Gruppenrichtlinienobjekts und die Versionsnummer aller Gruppenrichtlinienobjekte 

zum Zeitpunkt der letzten Verarbeitung. 

Damit für eine bestimmte clientseitige Erweiterung eine Aktualisierung im Hintergrund erfolgt, muss 

die Versionsnummer des verarbeiteten Gruppenrichtlinienobjekts größer als die in den Verlaufsdaten 

aufgezeichnete Versionsnummer sein. Wenn die Versionsnummer zwischen dem Gruppenrichtlinienobjekt 

und den Verlaufsdaten identisch ist, wird die clientseitige Erweiterung für das bestimmte Gruppenrichtlinienobjekt 

nicht aktualisiert. 

Sie können die Verlaufsdaten von Gruppenrichtlinien auf einem Computer im Registrierungs-Editor 

im folgenden Registrierungsschlüssel anzeigen: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\GroupPolicy\History 

Abbildung 11.7 veranschaulicht die in der Registrierung eines typischen Netzwerkclients gespeicherten 

Verlaufsdaten. Sie sehen, dass die clientseitige Erweiterung {827D319E-6EAC-11D2-A4EA- 

00C04F79F83A} zuvor mithilfe zweiter Gruppenrichtlinienobjekte verarbeitet wurde. Das markierte 

Objekt ist die Default Domain Controller Policy (Standard-Domänencontrollerrichtlinie) mit der Version 

0x00010001. Damit die Verarbeitung im nächsten Aktualisierungsintervall stattfindet, muss die 

Versionsnummer des Computer- oder Benutzerteils des Gruppenrichtlinienobjekts größer als der aktuelle 

Wert sein. Ist dies nicht der Fall, findet die Hintergrundaktualisierung für diesen bestimmten Teil 

des Gruppenrichtlinienobjekts nicht statt.



Anzeigen von Verlaufsdaten zur Gruppenrichtlinienverarbeitung 

So funktioniert es: Funktionsweise der Versionsnummern von 

Gruppenrichtlinienobjekten 

Die Versionsnummer des Gruppenrichtlinienobjekts in der Datei GPT.INI entspricht der in einer 

Nummer zusammengefassten Computer- und Benutzerversionsnummer. Die Computerversionsnummer 

ist stets die niedrigere Hälfte, die Benutzerversionsnummer stets die höhere Hälfte des 

Wertes. Bei Umwandlung in eine Hexadezimalzahl wird die Computerversion in den ersten vier 

Hexadezimalzeichen angezeigt. Die Benutzerversionsnummer besteht aus den restlichen oberen 

Hexadezimalzeichen hinter den unteren vier Hexadezimalzeichen. Auf der Begleit-CD befinden 

sich zwei Skripts zum Anzeigen der Benutzer- und Computerversionsnummern eines lokalen Gruppenrichtlinienobjekts 

zur Veranschaulichung der Unterteilung dieser Komponenten mithilfe einer 

Maske. Siehe DisplayMachineVersionLGPO.vbs und DisplayUserVersionLGPO.vbs. 

Judith Herman, Group Policy Programming Writer 

Windows Enterprise Management Division UA 

Anhand von Verlaufsinformationen kann auch bestimmt werden, wann ein Gruppenrichtlinienobjekt 

gelöscht wurde. Wenn sich bei der Verarbeitung von Gruppenrichtlinienobjekten herausstellt, dass ein 

bestimmtes Gruppenrichtlinienobjekt gelöscht wurde oder nicht mehr gilt, werden die Richtlinieneinstellungen 

entfernt und in den meisten Fällen auf dem Netzwerkclient auf die Standardeinstellungen 

zurückgesetzt.

Ausnahmen bei den standardmäßigen Zeitpunkten der 

Hintergrundverarbeitung 


Es gibt ggf. Situationen, in denen die Gruppenrichtlinienverarbeitung nicht den zuvor besprochenen 

Standardintervallen folgt. Ausnahmen erfolgen in folgenden Fällen: 

• Die Hintergrundaktualisierung von Gruppenrichtlinien wird auf dem Client auf Anforderung ausgelöst. 

• Das Gruppenrichtlinienmodul erkennt eine langsame Verbindung. 

• Die Loopbackverarbeitung findet statt. 

Erzwingen einer Hintergrundaktualisierung von Gruppenrichtlinien 

Nach dem Erstellen oder Ändern eines Gruppenrichtlinienobjekts wollen Sie ggf., dass die Richtlinieneinstellungen 

sofort umgesetzt werden. Um Clientcomputer zu zwingen, eine Aktualisierung 

von Gruppenrichtlinieneinstellungen anzufordern, müssen Sie das Befehlszeilenprogramm Gpupdate 

ausführen. Sie können mithilfe von Gpupdate sofort sämtliche Aktualisierungen des Gruppenrichtlinienobjekts 

empfangen, sofern der vom Client genutzte Domänencontroller die aktualisierten 

Inhalts- und Versionsinformationen von Gruppenrichtliniencontainer und -vorlage empfangen hat. 

Tabelle 11.4 zeigt die Syntax und Parameter bei Verwenden des Tools Gpupdate. 

Tabelle 11.4 

Gpupdate: Syntax und Parameter 

gpupdate [/target:{computer | user}] [/force] [/wait:Wert] [/logoff] [/boot] 

/target:{computer | user} Verarbeitet nur die Änderungen an den Computer- oder Benutzereinstellungen. Wenn Sie den 

Computer- oder Benutzerparameter nicht angeben, werden beide Einstellungen verarbeitet. 

/force 

Aktualisiert sämtliche Einstellungen des Gruppenrichtlinienobjekts, ob geändert oder nicht. 

/wait:Wert 

Anzahl der Sekunden, die bis zur Beendigung der Richtlinienverarbeitung gewartet wird. Der 

Standardwert ist 600 Sekunden. 0 entspricht keiner Wartezeit, –1 einer unbegrenzten Wartezeit. 

/logoff 

Meldet den Benutzer ab, nachdem die Richtlinienaktualisierung abgeschlossen wurde. Dies ist 

für clientseitige Erweiterungen erforderlich, die nicht während eines Hintergrundaktualisierungszyklus, 

sondern bei der Benutzeranmeldung verarbeitet werden, z.B. Softwareinstallation oder 

Ordnerumleitung. Diese Option hat keine Auswirkungen, falls keine Erweiterungen aufgerufen 

werden, die eine Abmeldung des Benutzers verlangen. 

/boot 

Führt nach Abschluss der Aktualisierung einen Neustart des Computers durch. Dies ist für 

clientseitige Erweiterungen wie Softwareinstallation erforderlich, die nicht während eines Hintergrundaktualisierungszyklus, 

sondern beim Computerstart verarbeitet werden. Diese Option hat 

keine Auswirkungen, falls keine Erweiterungen aufgerufen werden, die einen Neustart des 

Computers verlangen. 

/? Zeigt die Gpupdate-Hilfe an. 

Hinweis Gpupdate ersetzt den Befehl secedit /refreshpolicy, der unter Windows 2000 verwendet wurde. 

Unter Windows 2000 müssen Sie zum Aktualisieren von Richtlinieneinstellungen weiter secedit verwenden.


Verarbeiten von Gruppenrichtlinienobjekten bei sich ändernden Netzwerkbedingungen 

Windows Server 2008 und Windows Vista bieten eine neue Methode zum Reagieren auf sich 

ändernde Netzwerkbedingungen. Der Dienst für Netzwerkadressinformationen wurde eingeführt, 

damit kompatible Anwendungen Änderungen an den Netzwerkbedingungen und der Verfügbarkeit 

von Ressourcen erkennen und darauf reagieren können. Der Dienst für Netzwerkadressinformationen 

(NlaSvc) bietet für die Gruppenrichtlinienfunktionalität mehrere Vorteile: 

• Die Möglichkeit zu bestimmen, ob die Netzwerkkarte deaktiviert oder vom Netzwerk getrennt ist. 

Dadurch ergeben sich schnellere Startzeiten und kürzere Wartezeiten beim Ermitteln, ob das Netzwerk 

verfügbar ist. 

• Sofortige Aktualisierung von Richtlinieneinstellungen, sobald Domänencontroller wieder verfügbar 

sind. Computer, die beispielsweise aus dem Ruhezustand oder Standbymodus reaktiviert 

werden, müssen zum Verarbeiten von Richtlinieneinstellungen nicht auf das nächste Aktualisierungsintervall 

warten. Sobald die Verfügbarkeit von Domänencontrollern erkannt wird, lösen 

Richtlinieneinstellungen einen Aktualisierungszyklus aus. Die Gruppenrichtlinienverarbeitung 

wird außerdem ausgelöst, indem VPN- oder drahtlose Sitzungen eingerichtet werden, die Quarantäne 

erfolgreich beendet wird und ein Laptop an eine mit dem Netzwerk verbundene Dockingstation 

angedockt wird. Dadurch ergibt sich potenziell ein höherer Grad an Sicherheit auf 

Arbeitsstationen, indem Gruppenrichtlinienänderungen schneller umgesetzt werden. 

• Die Möglichkeit der Bestimmung von Bandbreitenbedingungen für die Verarbeitung von Gruppenrichtlinienobjekten 

und Aufhebung der Abhängigkeit vom ICMP-Protokoll (PING). Hierdurch 

können Unternehmen ihre Netzwerke mit Firewalls absichern und das ICMP-Protokoll 

filtern und dennoch weiterhin Gruppenrichtlinien anwenden. 


Verbindungen 

Konfigurieren der Richtlinieneinstellung Gruppenrichtlinien zur Erkennung von langsamen


Solange das Gruppenrichtlinienmodul erkennt, dass die Netzwerkbandbreite mindestens 500 KBit/s 

beträgt, werden alle Richtlinien wie erwartet verarbeitet. Wenn ermittelt wird, dass die Netzwerkbandbreite 

weniger als 500 KBit/s beträgt, werden nur clientseitige Erweiterungen verarbeitet, die als 

wichtig eingestuft werden. Sie können dieses Verhalten ändern, indem Sie die Gruppenrichtlinieneinstellung 

Gruppenrichtlinien zur Erkennung von langsamen Verbindungen unter Computerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Gruppenrichtlinie oder Benutzerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Gruppenrichtlinie konfigurieren. Abbildung 11.8 zeigt das 

Eigenschaftendialogfeld für Gruppenrichtlinien zur Erkennung von langsamen Verbindungen. Ist 

diese Einstellung deaktiviert oder nicht konfiguriert, wird der Standardwert 500 KBit/s verwendet. Sie 

können diese Einstellung auch deaktivieren, indem Sie die Verbindungsgeschwindigkeit auf 0 festlegen. 

So funktioniert es: Gruppenrichtlinien zur Erkennung von langsamen Verbindungen 

Der Gruppenrichtliniendienst bestimmt die Verbindungsgeschwindigkeit mithilfe des Dienstes für 

Netzwerkadressinformationen (NlaSvc), der den aktuellen TCP-Datenverkehr zwischen Client und 

Domänencontroller untersucht. Diese Untersuchung erfolgt in der Vorverarbeitungsphase von 

Gruppenrichtlinien, in der der Gruppenrichtliniendienst von der Kommunikation mit einem Domänencontroller 

abhängt, um computerund benutzerspezifische Informationen und Gruppenrichtlinienobjekte 

im Geltungsbereich des Computers oder Benutzers abzurufen. Der Gruppenrichtliniendienst 

fordert den Dienst für Netzwerkadressinformationen auf, die TCP-Bandbreite an der 

Netzwerkschnittstelle zu untersuchen, die als Host des Domänencontrollers dient, kurz nachdem 

der Gruppenrichtliniendienst einen Domänencontroller erkannt hat. Der Gruppenrichtliniendienst 

setzt die Vorverarbeitungsphase fort, indem mit dem Domänencontroller kommuniziert wird, um 

die Rolle des aktuellen Computers (Mitglied oder Domänencontroller), den angemeldeten Benutzer 

und Gruppenrichtlinienobjekte im Geltungsbereich des Computers oder Benutzers zu ermitteln. 

Anschließend fordert der Gruppenrichtliniendienst den Dienst für Netzwerkadressinformationen 

auf, die Untersuchung des TCP-Datenverkehrs zu beenden und eine geschätzte Bandbreite 

zwischen dem Computer und dem Domänencontroller basierend auf dieser Untersuchung anzugeben. 

Der Gruppenrichtliniendienst stuft eine Verbindung als langsam ein, wenn die ermittelte Verbindungsgeschwindigkeit 

unter 500 KBit/s liegt. Administratoren können mithilfe einer Richtlinieneinstellung 

festlegen, was im Rahmen der Anwendung von Gruppenrichtlinien als langsame 

Verbindung gelten soll. 

Mike Stephens 


Management and Solutions Division UA 

Zu Problembehandlungszwecken ist es wichtig zu verstehen, wie die einzelnen clientseitigen Erweiterungen 

von der Erkennung einer langsamen Verbindung betroffen sind (siehe dazu Tabelle 11.5). 

Tabelle 11.5 

Standardeinstellungen für die Verarbeitung bei erkannter langsamer Verbindung 




Sicherheit 


Standardverhalten bei langsamer Verbindung 

Wird verarbeitet (kann nicht deaktiviert werden) 

Wird nicht verarbeitet 


Wird nicht verarbeitet


Tabelle 11.5 

Standardeinstellungen für die Verarbeitung bei erkannter langsamer Verbindung (Fortsetzung) 


Skripts 

IP-Sicherheit 

Internet Explorer-Wartung und -Zonenzuordnung 

Microsoft-Datenträgerkontingente 

EFS-Wiederherstellung 

Gruppenrichtlinienerweiterung für Windows-Suchdienst 

QoS-Paketplaner und Enterprise QoS 

Gruppenrichtlinie für Drahtlosnetzwerk 

Bereitgestellte Druckerverbindungen 

802.3-Gruppenrichtlinie 

Microsoft-Offlinedateien 

Richtlinien für Softwareeinschränkung 

Gruppenrichtlinieneinstellungen 

Standardverhalten bei langsamer Verbindung 



Wird verarbeitet 

Wird nicht verarbeitet (aktuell zwischengespeicherte Kontingenteinstellungen 

werden jedoch erzwungen) 










Hinweis Sie können das Verhalten in Bezug auf die Verarbeitung von Gruppenrichtlinien für langsame 

Verbindungen für jede clientseitige Erweiterung in Tabelle 11.5 über die entsprechende Richtlinieneinstellung 

unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Gruppenrichtlinie ändern. 

Abbildung 11.9 zeigt beispielsweise die aktivierte clientseitige Erweiterung Verarbeitung der Richtlinie für die 

Internet Explorer-Wartung, die hier eine Verarbeitung über eine langsame Verbindung zulässt. 


Konfigurieren des Verhaltens von Gruppenrichtlinien zur Erkennung von langsamen Verbindungen


Loopbackverarbeitung von Gruppenrichtlinien 

Sobald sich ein Benutzer an einem Computer anmeldet, werden die für diesen Benutzer geltenden 

Richtlinieneinstellungen angewendet. Es kann jedoch Situationen geben, in denen dies nicht 

gewünscht ist. Wenn Sie die Loopbackverarbeitung aktivieren, bleiben die Computereinstellungen 

unabhängig davon, wer sich am Computer anmeldet, unverändert. 

Die Loopbackverarbeitung kann über die Option Loopbackverarbeitungsmodus für Benutzergruppenrichtlinie 

im Container Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Gruppenrichtlinie 

konfiguriert werden. Abbildung 11.10 zeigt die Konfigurationsoptionen. 


Konfigurieren der Loopbackverarbeitung von Gruppenrichtlinien 

Bei aktivierter Loopbackverarbeitung haben Sie zwei Konfigurationsoptionen. Im Modus Zusammenführen 

wird die Liste der Gruppenrichtlinienobjekte für den Benutzer während des Anmeldeprozesses 

erfasst. Anschließend werden die Gruppenrichtlinienobjekte für das Computerkonto erfasst. Schließlich 

wird die Liste der Gruppenrichtlinienobjekte für das Computerkonto an die Liste der Gruppenrichtlinienobjekte 

für den Benutzer angehängt, wodurch die Gruppenrichtlinienobjekte des Computers 

eine höhere Priorität haben als die des Benutzers. 

Im Modus Ersetzen werden die Gruppenrichtlinienobjekte für das Benutzerkonto nicht erfasst. Nur 

die Liste der Gruppenrichtlinienobjekte, die auf dem Computerobjekt basiert, wird verarbeitet. Die 

Benutzerkonfigurationseinstellungen in dieser Liste werden auf den Benutzer angewendet. 

Die Loopbackverarbeitung von Gruppenrichtlinien ist in verschiedenen Szenarien nützlich, z.B. wenn 

Sie die Einstellungen eines Computers sperren müssen, der sich an einem öffentlichen Ort befindet. 

Angenommen, Sie betreuen einen Computer in einem öffentlichen Empfangsbereich, an dem sich 

Kunden anmelden dürfen. Da der Computer öffentlich zugänglich ist, soll sichergestellt sein, dass die 

Einstellungen des Computers unabhängig von der Person, die sich an ihm anmeldet, stets gesperrt 

sind. Sie können eine Sperrung aktivieren, indem Sie die öffentlichen Computer einer entsprechenden 

Organisationseinheit zuweisen und für diese eine restriktive Gruppenrichtlinie konfigurieren.


Anschließend können Sie die Loopbackverarbeitung für diese Organisationseinheit konfigurieren. 

Wenn sich nun ein Benutzer am Computer anmeldet, wird dem Benutzer ein eingeschränkter Desktop 

auf dem öffentlichen Computer angezeigt, der auf administrativen Vorlagen und der Loopbackverarbeitung 

basiert. 

Implementieren von Gruppenrichtlinien 

Windows Server 2008 weist verschiedene Änderungen auf, wie Gruppenrichtlinien in Active Directory 

implementiert werden. Ein Hauptunterschied ist, dass Gruppenrichtlinien nicht mehr über die 

Konsole Active Directory-Benutzer und -Computer verwaltet werden. Das Standardtool für die Verwaltung 

von Gruppenrichtlinien ist nun die Konsole Gruppenrichtlinienverwaltung, die unter den 

Betriebssystemen Windows Server 2008 und Windows Vista SP1 als installierbare Komponente zur 

Verfügung steht. Die Konsole Gruppenrichtlinienverwaltung dient als Zentrale für die Bereitstellung, 

Verwaltung, Bearbeitung von bzw. Berichterstellung zu Gruppenrichtlinieneinstellungen im gesamten 

Unternehmen. 

Wenn die Serverrolle Active Directory-Domänendienste (AD DS) installiert wird, ist das Feature 

Gruppenrichtlinienverwaltung automatisch enthalten, das Zugriff auf die Konsole Gruppenrichtlinienverwaltung 

bietet. Sie können das Feature Gruppenrichtlinienverwaltung auch über den Assistenten 

zum Hinzufügen von Features in der Konsole Server-Manager auf beliebigen Mitgliedsservern 

installieren. 

Hinweis Unter Windows Vista ist die Konsole Gruppenrichtlinienverwaltung bereits installiert, auf die über 

Eingabe von gpmc.msc in das Feld Suche starten oder an der Eingabeaufforderung zugegriffen wird. Wenn 

Sie allerdings Windows Vista SP1 installieren, wird die Konsole Gruppenrichtlinienverwaltung entfernt und 

muss anschließend im Paket mit den Remoteserver-Verwaltungstools aus dem Microsoft Download Center 

heruntergeladen werden. 

Nach der Installation der Konsole Gruppenrichtlinienverwaltung kann auf diese zugegriffen werden, 

indem Sie auf die Schaltfläche Start klicken, auf Verwaltung zeigen und dann auf Gruppenrichtlinienverwaltung 

klicken. Sie können die Konsole Gruppenrichtlinienverwaltung auch starten, indem Sie 

gpmc.msc in das Dialogfeld Ausführen oder an der Befehlszeile eingeben. Abbildung 11.4 zeigt die 

Oberfläche der Konsole Gruppenrichtlinienverwaltung. 


Verwalten von Gruppenrichtlinien in der Konsole Gruppenrichtlinienverwaltung

Übersicht über die Konsole Gruppenrichtlinienverwaltung 

Implementieren von Gruppenrichtlinien 417 

Wie Abbildung 11.11 zeigt, besteht die Konsole Gruppenrichtlinienverwaltung aus verschiedenen 

Knoten, die verschiedene Grade an Funktionalität bereitstellen. Der Knoten auf oberster Ebene gibt 

die Gesamtstruktur an, die im Fokus der Gruppenrichtlinienverwaltung steht. Wenn Sie Gruppenrichtlinieneinstellungen 

mehrerer Gesamtstrukturen verwalten möchten, können Sie weitere Gesamtstrukturknoten 

hinzufügen, indem Sie mit der rechten Maustaste auf den Knoten Gruppenrichtlinienverwaltung 

klicken und anschließend auf Gesamtstruktur hinzufügen klicken. Das Dialogfeld 

Gesamtstruktur hinzufügen bietet ein Feld zum Eingeben des Namens einer Domäne in der Gesamtstruktur, 

die Sie hinzufügen möchten. Solange ein Vertrauensverhältnis zur neuen Domäne besteht, 

wird die Verbindung gemeinsam mit Gesamtstrukturinformationen eingerichtet, die in der Konsole 

Gruppenrichtlinienverwaltung angezeigt werden sollen. 

Beim Erweitern des Knotens Gesamtstruktur werden vier weitere Knoten angezeigt. In der folgenden 

Aufstellung finden Sie eine Erläuterung zu jedem Knoten: 

• Domänen Der Knoten Domänen enthält eine Liste der Domänen, die für Gruppenrichtlinien verwaltet 

werden. Standardmäßig wird nur Ihre Anmeldedomäne gezeigt. Sie können jedoch weitere 

Domänen hinzufügen, indem Sie mit der rechten Maustaste auf den Knoten Domänen klicken und 

dann auf Domänen anzeigen klicken. Das Dialogfeld Domänen anzeigen bietet die Möglichkeit, 

in der Konsole Gruppenrichtlinienverwaltung Domänen auszuwählen oder zu entfernen. 

• Standorte Der Knoten Standorte enthält eine Liste der Standorte in der Active Directory-Gesamtstruktur. 

Standardmäßig wird Standorte in der Konsole nicht angezeigt. Sie können jedoch Standorte 

hinzufügen, indem Sie mit der rechten Maustaste auf den Knoten Standorte klicken und dann 

auf Standorte anzeigen klicken. Das Dialogfeld Standorte anzeigen bietet die Möglichkeit, in der 

Konsole Gruppenrichtlinienverwaltung Standorte auszuwählen oder zu entfernen. 

Hinweis Um tatsächlich Standorte für bestimmte Subnetze zu erstellen, müssen Sie die Konsole 

Active Directory-Standorte und -Dienste verwenden. 

• Gruppenrichtlinienmodellierung Der Knoten Gruppenrichtlinienmodellierung ermöglicht den Einsatz 

des Gruppenrichtlinienmodellierungs-Assistenten zum Erstellen und Speichern simulierter 

Szenarien für die Anwendung und Verarbeitung von Gruppenrichtlinien in Ihrem Unternehmen. 

Sie können hiermit ferner „Was wäre, wenn?“-Szenarien testen, z.B. Computer oder Benutzer in 

andere Container verschieben und andere Filteroptionen anwenden, z.B. Sicherheitsgruppen und 

WMI-Filter (Windows Management Instrumentation). Hinweis: Das Modellierungstool berücksichtigt 

keine lokalen Richtlinieneinstellungen auf einem Computer. Aus diesem Grund können 

sich Ihre Ergebnisse von den tatsächlichen Ergebnissen nach der Bereitstellung unterscheiden, 

wenn Sie in Ihrer Umgebung mit lokalen Gruppenrichtlinienobjekten arbeiten. 

• Gruppenrichtlinienergebnisse Der Knoten Gruppenrichtlinienergebnisse ermöglicht den Einsatz 

des Gruppenrichtlinienergebnis-Assistenten zum Bestimmen aktueller Ergebnisse der Richtlinienverarbeitung 

für Benutzer und Computer in der Active Directory-Umgebung. 

Nachdem die Konsole Gruppenrichtlinienverwaltung gestartet wurde, erfolgen standardmäßig sämtliche 

Verwaltungsaufgaben auf dem Domänencontroller mit der Rolle PDC-Emulator. In den meisten 

Fällen sollten Sie diese Standardeinstellung übernehmen, um zu verhindern, dass mehrere Administratoren 

nicht kompatible Änderungen an den Gruppenrichtlinieneinstellungen vornehmen.


Sollte der PDC-Emulator jedoch nicht verfügbar sein, wenn Sie eine Änderung durchführen möchten, 

können Sie den Domänencontroller auswählen, mit dem Sie eine Verbindung herstellen möchten. 

Wenn Sie nur über eine langsame Verbindung zum PDC-Emulator gelangen, können Sie eine Umleitung 

zu einem lokalen Domänencontroller wählen. Dabei kann es allerdings vorkommen, dass neu 

erstellte Container und Objekte erst mit Verzögerung angezeigt werden. Eine weitere Möglichkeit ist 

das Verwenden von Remotedesktop zum Herstellen einer Verbindung mit dem Domänencontroller mit 

der Rolle PDC-Emulator und das direkte Konfigurieren von Gruppenrichtlinieneinstellungen auf dem 

Domänencontroller. 

Wie Abbildung 11.11 zeigt, können Sie prüfen, welcher Domänencontroller den Fokus hat, indem Sie 

auf der Registerkarte Inhalt des Knotens Domänen die Spalte Aktueller Domänencontroller untersuchen. 

Sie können auch den Domänencontroller ändern, der im Fokus der Konsole Gruppenrichtlinienverwaltung 

ist, indem Sie mit der rechten Maustaste auf den Domänennamen klicken und dann auf 

Domänencontroller ändern klicken. Abbildung 11.12 zeigt die Optionen im Dialogfeld Domänencontroller 

ändern. 


Ändern des Domänencontrollers im Fokus der Konsole Gruppenrichtlinienverwaltung 

Erstellen und Verknüpfen von Gruppenrichtlinienobjekten in der Konsole 

Gruppenrichtlinienverwaltung 

Das Erstellen eines Gruppenrichtlinienobjekts umfasst zwei getrennte Aufgaben. Das Gruppenrichtlinienobjekt 

muss zuerst erstellt, mit den gewünschten Richtlinieneinstellungen konfiguriert und 

anschließend mit dem Domänen-, Standort- oder Organisationseinheitscontainer in Active Directory 

verknüpft werden.


Hinweis Ein einzelnes Gruppenrichtlinienobjekt kann in Active Directory mit mehreren Containern auf verschiedenen 

Stufen von Active Directory verknüpft werden. Doch aufgrund potenzieller Leistungsengpässe 

werden Kreuzverknüpfungen von Gruppenrichtlinienobjekten mit anderen Domänen meist nicht empfohlen. 

Ihre IT-Verwaltungsstrategie oder persönlichen Vorlieben bestimmen, wie Sie Gruppenrichtlinienobjekte 

in der Active Directory-Umgebung erstellen und verknüpfen. Eine Methode sieht vor, zuerst 

im Container Gruppenrichtlinienobjekte alle benötigten Gruppenrichtlinienobjekte zu erstellen, ohne 

diese tatsächlich mit einer Domäne, einem Standort oder einer Organisationseinheit zu verknüpfen. 

Der Hauptvorteil dieser Methode besteht darin, dass Sie eine Gruppe von Administratoren für das 

Planen und Erstellen von Gruppenrichtlinienobjekten für eine bestimmte Domäne einteilen können, 

während sich eine zweite delegierte Gruppe um das Verknüpfen der konfigurierten Gruppenrichtlinienobjekte 

mit spezifischen Objekten in Active Directory kümmert. Führen Sie die folgenden Schritte 

aus, um Gruppenrichtlinienobjekte zu erstellen und zu verknüpfen: 

1. Erweitern Sie den Knoten Gesamtstruktur und dann den Knoten Domänen. Außerdem müssen Sie 

den Knoten mit dem Namen Ihrer Domäne erweitern. 

2. Markieren Sie den Container Gruppenrichtlinienobjekte. Beachten Sie, dass alle in der Domäne 

erstellten Gruppenrichtlinienobjekte im Detailbereich aufgeführt werden. 

3. Klicken Sie mit der rechten Maustaste auf den Container Gruppenrichtlinienobjekte, und wählen 

Sie Neu. 

4. Geben Sie in das Dialogfeld Neues Gruppenrichtlinienobjekt den Namen des Gruppenrichtlinienobjekts 

ein. Sie können auch ein Quell-Starter-Gruppenrichtlinienobjekt angeben. Ein Starter- 

Gruppenrichtlinienobjekt ist ein vorkonfiguriertes Gruppenrichtlinienobjekt mit Gruppenrichtlinieneinstellungen, 

die Sie als Ausgangsvorlage für das neue Gruppenrichtlinienobjekt 

verwenden können. Abbildung 11.13 zeigt das Dialogfeld Neues Gruppenrichtlinienobjekt. 


Erstellen eines neuen Gruppenrichtlinienobjekts 

5. Klicken Sie auf OK, um das Dialogfeld Neues Gruppenrichtlinienobjekt zu schließen. Das neue 

Gruppenrichtlinienobjekt wird nun im Container Gruppenrichtlinienobjekte angezeigt. 

6. Um das Gruppenrichtlinienobjekt mit der Domäne, einem Standort oder einer bestimmten Organisationseinheit 

zu verknüpfen, klicken Sie mit der rechten Maustaste auf den Zielcontainer und klicken 

anschließend auf Vorhandenes Gruppenrichtlinienobjekt verknüpfen. Das in Abbildung 11.4 

gezeigte Dialogfeld Gruppenrichtlinienobjekt auswählen wird geöffnet. 

7. Wählen Sie das zu verknüpfende Gruppenrichtlinienobjekt aus, und klicken Sie dann auf OK.



Verknüpfen eines Gruppenrichtlinienobjekts 

8. Wählen Sie den Container aus, mit dem Sie das Gruppenrichtlinienobjekt verknüpft haben. Im 

Detailbereich finden Sie Informationen zum verknüpften Gruppenrichtlinienobjekt, z.B. die Verknüpfungsreihenfolge, 

den Status der Verknüpfung und des Gruppenrichtlinienobjekts und ob die 

Verknüpfung erzwungen wird oder nicht. 

Die zweite Methode sieht vor, ein Gruppenrichtlinienobjekt für eine ausgewählte Domäne, einen 

Standort oder eine Organisationseinheit zu erstellen und dieses automatisch mit diesem bestimmten 

Active Directory-Objekt verknüpfen zu lassen. Der Hauptvorteil dieser Methode besteht darin, dass 

Erstellung und Verknüpfung in einem Schritt erfolgen, der für eine sofortige Anwendung der Richtlinieneinstellungen 

auf das Zielobjekt sorgt. Um ein verknüpftes Gruppenrichtlinienobjekt zu erstellen, 

klicken Sie mit der rechten Maustaste auf das Zielobjekt (Domäne, Standort oder Organisationseinheit), 

und wählen Sie Gruppenrichtlinienobjekt hier erstellen und verknüpfen aus. Sie können 

einen Namen und ein Quell-Starter-Gruppenrichtlinienobjekt mit dem zusätzlichen Vorteil angeben, 

dass das Gruppenrichtlinienobjekt automatisch mit dem Zielobjekt verknüpft wird. 

Hinweis Die Option Gruppenrichtlinienobjekt hier erstellen und verknüpfen steht für Standorte nicht zur 

Verfügung. Sie müssen das Gruppenrichtlinienobjekt vorab erstellen und für Standorte die Option Vorhandenes 

Gruppenrichtlinienobjekt verknüpfen auswählen. 

Ändern des Verarbeitungsbereichs von Gruppenrichtlinienobjekten 

Der Verwaltungsbereich eines Gruppenrichtlinienobjekts kann durch Konfiguration verschiedener 

Einstellungen geändert werden: 

• Ändern der Verknüpfungsreihenfolge 

• Deaktivieren des Gruppenrichtlinienobjekts bzw. von dessen Verknüpfung 

• Erzwingen oder Sperren einer Gruppenrichtlinienobjekt-Verknüpfung


• Filtern der Anwendung eines Gruppenrichtlinienobjekts mithilfe von Sicherheitsgruppen oder 

WMI-Filtern (Windows Management Instrumentation) 

Ändern der Verknüpfungsreihenfolge von Gruppenrichtlinienobjekt-Verknüpfungen 

Wie zuvor erwähnt, übernehmen untergeordnete Container Gruppenrichtlinieneinstellungen standardmäßig 

von übergeordneten Containern. Sie erinnern sich, dass beim Start eines Computers oder der 

Anmeldung eines Benutzers Richtlinieneinstellungen in der folgenden Reihenfolge angewendet 

werden: 

1. Richtlinien der lokalen Gruppe Die erste Richtlinieneinstellung, die angewendet wird, ist stets die 

Richtlinie der lokalen Gruppe auf dem lokalen Computer. 

2. Auf Standortebene zugewiesene Gruppenrichtlinienobjekte Die zweiten anzuwendenden Richtlinieneinstellungen 

stammen aus Gruppenrichtlinienobjekten, die mit dem Standortobjekt in Active 

Directory verknüpft sind. 

3. Auf Domänenebene zugewiesene Gruppenrichtlinienobjekte Die nächsten zu verarbeitenden Richtlinieneinstellungen 

stammen aus Gruppenrichtlinienobjekten, die dem Domänenobjekt in Active 

Directory zugewiesen sind. 

4. Auf Organisationseinheitsebene zugewiesene Gruppenrichtlinienobjekte Wenn die Domäne mehrere 

Ebenen mit Organisationseinheiten enthält, werden schließlich die Gruppenrichtlinieneinstellungen 

für die Organisationseinheiten auf übergeordneter Ebene zuerst und anschließend die Gruppenrichtlinieneinstellungen 

für Organisationseinheiten auf untergeordneter Ebene angewendet. 

Häufig sind mehrere Gruppenrichtlinienobjekte mit mehreren Active Directory-Ebenen verknüpft. In 

diesem Fall bestimmt die Verknüpfungsreihenfolge die Reihenfolge, in der die Gruppenrichtlinienobjekte 

angewendet werden. Sie können die Verknüpfungsreihenfolge für einen bestimmten Container 

anzeigen und ändern (siehe Abbildung 11.15). Wichtig ist noch einmal der Hinweis, dass Gruppenrichtlinienobjekte 

in der Liste von unten nach oben verarbeitet werden. Eine 

Verknüpfungsreihenfolge mit höherer Nummer wird also von einer mit niedrigerer Nummer verarbeitet. 

Abbildung 11.15 zeigt beispielsweise drei mit der Organisationseinheit Vertrieb verknüpfte Gruppenrichtlinienobjekte. 

In diesem Fall wird zuerst die Skriptrichtlinie, dann die Ordnerumleitungsrichtlinie 

und schließlich die Desktoprichtlinie angewendet. In Konflikt stehende Richtlinieneinstellungen 

werden durch Einstellungen überschrieben, die in einem Gruppenrichtlinienobjekt mit niedrigerer 

Verknüpfungsreihenfolge (in diesem Fall die Desktoprichtlinie) konfiguriert sind. Sie können die Verknüpfungsreihenfolge 

ändern, indem Sie die Gruppenrichtlinienobjekt-Verknüpfung auswählen und 

anschließend links im Detailbereich auf einen der Pfeile klicken. 

Um besser nachvollziehen zu können, wie bei mehreren Gruppenrichtlinienobjekten Richtlinieneinstellungen 

verarbeitet werden, können Sie auch auf die Registerkarte Gruppenrichtlinienvererbung 

klicken. Die Spalte Rangfolge zeigt die Reihenfolge, in der Gruppenrichtlinienobjekte für einen 

Standort, eine Domäne oder Organisationseinheit verarbeitet werden (siehe Abbildung 11.16). Gruppenrichtlinienobjekte 

mit höherer Nummer werden vor Gruppenrichtlinienobjekten mit niedrigerer 

Nummer verarbeitet, was bedeutet, dass Gruppenrichtlinienobjekten mit niedrigerer Nummer bei in 

Konflikt stehenden Einstellungen Vorrang haben.



Ändern der Verknüpfungsreihenfolge von Gruppenrichtlinienobjekten 


Anzeigen der Rangfolge von Gruppenrichtlinienobjekten 

Aktivieren und Deaktivieren der Richtlinienverarbeitung 

Auf der Registerkarte Details eines bestimmten Gruppenrichtlinienobjekts können Sie Gruppenrichtlinienobjekte 

durch Ändern ihres Status aktivieren bzw. deaktivieren. Abbildung 11.17 zeigt die verfügbaren 

Optionen zum Ändern des Status von Gruppenrichtlinienobjekten sowie die Optionen und 

ihren Zweck: 

• Alle Einstellungen deaktiviert Diese Option deaktiviert das Gruppenrichtlinienobjekt und beendet 

die Verarbeitung konfigurierter Richtlinieneinstellungen. 

• Computerkonfigurationseinstellungen deaktiviert Diese Option deaktiviert die Computereinstellungen 

des Gruppenrichtlinienobjekts. Sie können diesen Abschnitt deaktivieren, wenn es bezüglich 

der Computerkonfiguration im Gruppenrichtlinienobjekt keine zu verarbeitenden Einstellungen gibt.


• Aktiviert Diese Option aktiviert die Verarbeitung des gesamten Gruppenrichtlinienobjekts. 

• Benutzerkonfigurationseinstellungen deaktiviert Diese Option deaktiviert nur die Benutzereinstellungen 

des Gruppenrichtlinienobjekts. Sie können diesen Abschnitt deaktivieren, wenn es 

bezüglich der Benutzerkonfiguration im Gruppenrichtlinienobjekt keine zu verarbeitenden Einstellungen 

gibt. 


Ändern des Status eines Gruppenrichtlinienobjekts 

Es kann vorkommen, dass Sie die Verarbeitung von Gruppenrichtlinienobjekten für eine bestimmte 

Organisationseinheit deaktivieren müssen. Sie können jedoch nicht das gesamte Gruppenrichtlinienobjekt 

deaktivieren, da es mit anderen Containern in Active Directory verknüpft ist. In diesem Fall 

können Sie die zur Organisationseinheit gehörende Gruppenrichtlinienobjekt-Verknüpfung deaktivieren. 

Klicken Sie dazu mit der rechten Maustaste auf die zum Container gehörende Gruppenrichtlinienobjekt-Verknüpfung 

(Organisationseinheit, Domäne, Standort), und deaktivieren Sie das 

Kontrollkästchen Verknüpfung aktiviert. Dadurch wird die Verknüpfung ausschließlich für den ausgewählten 

Container deaktiviert. Alle anderen Gruppenrichtlinienobjekt-Verknüpfungen mit anderen 

Containern werden wie gewohnt weiter verarbeitet. 

Sperren und Erzwingen der Verarbeitung von Gruppenrichtlinienobjekten 

Es kann auch vorkommen, dass Sie die Vererbung verhindern möchten, damit keine Richtlinieneinstellungen 

auf höheren Active Directory-Ebenen angewendet werden. Angenommen, Sie haben eine 

domänenbasierte Richtlinieneinstellung eingerichtet, die den Befehl Ausführen von allen Computern 

entfernt. Diese Einstellung gilt standardmäßig für alle Computer in der Domäne. Es kann jedoch 

Benutzer geben, die den Befehl Ausführen benötigen, z.B. IT-Administratoren oder Helpdeskgruppen. 

Um diese Domänenrichtlinie außer Kraft zu setzen, können Sie diese Gruppen eigenen Organisationseinheiten 

zuordnen. Sie können anschließend die Richtlinienvererbung aufheben, indem Sie mit 

der rechten Maustaste auf die Organisationseinheit klicken und Vererbung deaktivieren auswählen. Ist 

Vererbung deaktivieren aktiviert, werden nur direkt mit dem Container verknüpfte Richtlinieneinstellungen 

angewendet.


Hinweis Wenn eine Organisationseinheit mit deaktivierter Vererbung konfiguriert ist, befindet sich ein 

blauer Kreis mit einem Ausrufezeichen auf dem Container, um Sie daran zu erinnern, dass die Vererbung ab 

dieser Stelle deaktiviert ist. Wenn der Container untergeordnete Container enthält, wird die Vererbung, falls 

nichts anderes konfiguriert ist, ab dieser Stelle fortgesetzt. 

Abbildung 11.18 zeigt die Organisationseinheit Marketing mit aktivierter Option Vererbung 

deaktivieren. 


Deaktivieren der Gruppenrichtlinienvererbung 

Möglich ist auch, dass es verbindliche Richtlinieneinstellungen gibt, die auf alle Benutzer bzw. 

Computer in der Active Directory-Struktur angewendet werden müssen. Um zu verhindern, dass 

Administratoren verbindliche Richtlinien deaktivieren, können Sie die Vererbung erzwingen. Wird 

eine Gruppenrichtlinienobjekt-Verknüpfung erzwungen, werden sämtliche Richtlinieneinstellungen 

im erzwungenen Gruppenrichtlinienobjekt ungeachtet der Einstellung Vererbung deaktivieren angewendet. 

Um die Verarbeitung von Gruppenrichtlinienobjekten zu erzwingen, klicken Sie mit der rechten 

Maustaste auf die Gruppenrichtlinienobjekt-Verknüpfung des Containers, ab dem die Erzwingung 

erfolgen soll, und klicken Sie dann auf Erzwungen. Wenn die Erzwingung einer Gruppenrichtlinienobjekt-Verknüpfung 

konfiguriert ist, wird ein Schlosssymbol zur Kennzeichnung angezeigt. Sie können 

auch die Registerkarte Gruppenrichtlinienvererbung für untergeordnete Containerobjekte anzeigen, 

um eine erzwungene Gruppenrichtlinienobjekt-Verknüpfung zu überprüfen. Abbildung 11.19 

zeigt die Registerkarte Gruppenrichtlinienvererbung der Organisationseinheit Marketing. Wie Sie 

sehen, wird die Standarddomänenrichtlinie auch dann erzwungen, wenn Vererbung deaktivieren aktiviert 

ist (was durch das Ausrufezeichen angezeigt wird).



Anzeigen der Erzwingung von Gruppenrichtlinien 

Filtern der Verarbeitung von Gruppenrichtlinienobjekten mithilfe von Sicherheitsgruppen 

und WMI 

Eine weitere Möglichkeit zum Ändern des Verarbeitungsbereichs von Gruppenrichtlinienobjekten ist 

das Filtern der Anwendung von Gruppenrichtlinieneinstellungen. Dies kann durch das Implementieren 

von Sicherheitsfilterung oder Verknüpfen eines WMI-Filters mit einem Gruppenrichtlinienobjekt 

erreicht werden. 

Übersicht über Sicherheitsfilterung Wenn Sie ein Gruppenrichtlinienobjekt erstellen, gelten die Richtlinieneinstellungen 

standardmäßig für alle authentifizierten Benutzer. Sie können diese Einstellung 

anzeigen, indem Sie ein Gruppenrichtlinienobjekt auswählen und auf die Registerkarte Bereich klicken. 

Wie Abbildung 11.20 zeigt, gibt der Abschnitt Sicherheitsfilterung an, dass die Richtlinieneinstellungen 

im Gruppenrichtlinienobjekt Desktoprichtlinie für alle Mitglieder der Gruppe Authentifizierte 

Benutzer gelten (zu der Standardbenutzer, -computer und -administratoren gehören). 

Mithilfe von Sicherheitsfilterung können Sie die Verarbeitung von Gruppenrichtlinienobjekten auf 

bestimmte Sicherheitsgruppen, Benutzer oder Computer abstimmen. 

Sie können angeben, welche Benutzer oder Computer dem Gruppenrichtlinienobjekt unterliegen sollen, 

indem Sie die Konten in der Liste Sicherheitsfilterung bearbeiten. Zum Konfigurieren dieser Einstellung 

müssen Sie zuerst die Gruppe Authentifizierte Benutzer aus der Liste entfernen. Fügen Sie 

anschließend der Liste die gewünschten Konten durch Klicken auf die Schaltfläche Hinzufügen hinzu. 

Wenngleich Sie beliebige Sicherheitsprinzipale hinzufügen können, wird empfohlen, stets Active 

Directory-Sicherheitsgruppen und keine einzelnen Benutzer- oder Computerkonten zu wählen.



Anzeigen der Sicherheitsfilterung von Gruppenrichtlinienobjekten 

Hinweis Sie können die tatsächliche Zugriffssteuerungsliste anzeigen, indem Sie zuerst auf die Registerkarte 

Delegierung und anschließend auf die Schaltfläche Erweitert klicken. In der Zugriffssteuerungsliste 

werden Sie bemerken, dass jedem Sicherheitsprinzipal, den Sie der Liste Sicherheitsfilterung hinzufügen, 

die Gruppenrichtlinienberechtigungen Zulassen: Lesen und Zulassen: Gruppenrichtlinie übernehmen hinzugefügt 

werden. Abbildung 11.21 zeigt die Marketingabteilung mit den aktivierten Berechtigungen Lesen 

und Gruppenrichtlinie übernehmen. 

Die Möglichkeit der Anwendung von Gruppenrichtlinieneinstellungen auf eine ausgewählte Gruppe 

ist in verschiedenen Situationen hilfreich. Angenommen, Sie müssen ein bestimmtes Softwarepaket 

für Benutzer installieren, die einer gemeinsamen Sicherheitsgruppe angehören, deren Benutzerkonten 

jedoch auf verschiedene Organisationseinheiten in der gesamten Domäne verteilt sind. Um diese 

Anwendung mithilfe von Gruppenrichtlinien zu installieren, können Sie das Gruppenrichtlinienobjekt 

mit einem übergeordneten Containerobjekt verknüpfen, das alle Benutzerkonten enthält (z.B. das 

Domänenobjekt) und anschließend den Sicherheitsfilter des Gruppenrichtlinienobjekts so ändern, dass 

die Richtlinie nur für die angegebene Gruppe gilt, die das Softwarepaket empfangen soll. Denkbar ist 

auch, dass ein Gruppenrichtlinienobjekt mit einer Organisationseinheit verknüpft ist, das nicht für alle 

Benutzer in dieser Organisationseinheit gelten soll. Sie haben nun zwei Optionen: Erstens können Sie 

eine Gruppe erstellen, die alle Benutzerkonten enthält, die Gruppenrichtlinieneinstellungen benötigen, 

und die Berechtigung Gruppenrichtlinien übernehmen für ausschließlich diese Gruppe konfigurieren. 

Zweitens können Sie eine Gruppe erstellen, die alle Benutzerkonten enthält, die die Gruppenrichtlinieneinstellungen 

nicht benötigen, und die Einstellung Verweigern für die Berechtigung 

Gruppenrichtlinien übernehmen auswählen, damit die Richtlinie für diese Benutzer nicht gilt.



Filter von Gruppenrichtlinienobjekten mithilfe der Zugriffssteuerungsliste 

Anwenden von WMI-Filtern auf Gruppenrichtlinienobjekte Windows Server 2008 bietet auch die Möglichkeit, 

die Anwendung von Gruppenrichtlinieneinstellungen basierend auf WMI-Filtern (Windows 

Management Instrumentation) zu filtern. Die WMI-Filter, die in WQL (WMI Query Language) 

geschrieben sind, dienen zur präziseren Angabe, welche Computer Gruppenrichtlinieneinstellungen 

empfangen sollen. Sie können beispielsweise mithilfe von WMI-Filtern angeben, dass ein Softwarepaket 

nur auf Computern mit mehr als 200 MB freiem Festplattenspeicher oder Computern mit mehr 

als 512 MB Arbeitsspeicher installiert werden soll. WMI-Filter werden von Windows XP, Windows 

Server 2003, Windows Vista und Windows Server 2008 unterstützt und von allen früheren Windows- 

Versionen ignoriert. Dies bedeutet, dass unter früheren Betriebssystemen alle Gruppenrichtlinienobjekte 

mit WMI-Filtern stets ungeachtet der zugewiesenen WMI-Abfrage angewendet werden. 

Der erste Schritt beim Verwenden von WMI-Filtern ist das Erstellen oder Abrufen einer WQL- 

Abfrage, die Ihre Anforderungen an das Gruppenrichtlinienobjekt erfüllt. Angenommen, Sie möchten 

mithilfe der gruppenrichtliniengesteuerten Softwareinstallation eine neue Anwendung nur auf Computern 

mit mindestens 100 MB freiem Speicherplatz auf Laufwerk C: bereitstellen. Die folgende Syntax 

enthält die WQL-Abfrage für dieses Szenario: 

Select * from Win32_LogicalDisk where FreeSpace > 104857600 AND Caption = "C:" 

Scriptomatic.exe ist ein Tool für das Erstellen von WQL-Abfragen, die anschließend kopiert und in 

einen WMI-Filter für die Gruppenrichtlinienfunktion und eingefügt werden können. Im Abschnitt 

„Weitere Ressourcen“ dieses Kapitels finden Sie Links zu Informationen zu diesem Dienstprogramm. 

Der zweite Schritt ist das Erstellen des WMI-Filters mithilfe der Konsole Gruppenrichtlinienverwaltung. 

Klicken Sie dazu mit der rechten Maustaste auf den Knoten WMI-Filter und anschließend auf 

Neu. Geben Sie anschließend einen Namen, eine Beschreibung und die dazugehörige Abfrage für den 

neuen WMI-Filter ein (siehe Abbildung 11.22).



Filtern von Gruppenrichtlinienobjekten mithilfe von WMI-Filtern 

Der letzte Schritt ist das Verknüpfen des WMI-Filters mit einem Gruppenrichtlinienobjekt. Wählen 

Sie dazu das zu filternde Gruppenrichtlinienobjekt aus, und konfigurieren Sie danach unten auf der 

Registerkarte Bereich den WMI-Filter (siehe Abbildung 11.23). 


Verknüpfen eines WMI-Filters mit einem Gruppenrichtlinienobjekt


Gruppenrichtlinien und Entwurf von Organisationseinheiten 

Wie in Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, besprochen, ist einer 

der Faktoren beim Erstellen des Entwurfs von Organisationseinheiten die Berücksichtigung der 

Gruppenrichtlinienverarbeitung. Dies ist besonders für Organisationseinheiten auf niedrigeren Ebenen 

wichtig, auf denen die Gruppenrichtlinienanforderungen wohl der wichtigste Faktor mit Einfluss 

auf den Entwurf sind. In den meisten Fällen sollte der Entwurf die Standardvererbung der 

Richtlinieneinstellungen ausnutzen. 

Auch wenn der Einsatz der Standardvererbung eines Ihrer Entwurfsziele ist, sind die meisten Großunternehmen 

einfach zu komplex, um damit in allen Situationen zurechtzukommen. Sie können 

beispielsweise einen Organisationseinheitsentwurf basierend auf Geschäftsbereichen oder Abteilungen 

einrichten, da die meisten Benutzer im selben Geschäftsbereich voraussichtlich dieselben 

Desktopeinstellungen und Anwendungszusammenstellungen nutzen. Doch einige der Benutzer in 

den einzelnen Geschäftsbereichen gehören aller Wahrscheinlichkeit nach einem Team an, das 

Abteilungsgrenzen überschreitet, entweder ständig oder für bestimmte Projekte. Die anderen Abteilungen 

haben ggf. unterschiedliche Softwareanforderungen, weshalb der Benutzer auf Anwendungen 

aller Abteilungen zugreifen können muss. Da diese Typen komplexer Konfigurationen in 

den meisten Unternehmen vorkommen, bietet Windows Server 2008 die in diesem Abschnitt 

beschriebenen Optionen zum Ändern der Standardanwendung von Gruppenrichtlinieneinstellungen. 

Delegieren der Verwaltung von Gruppenrichtlinienobjekten 

Wie in Kapitel 9, „Entwerfen der Active Directory-Domänendienstestruktur“, besprochen, ist einer 

der Hauptvorteile von Active Directory die Möglichkeit, viele der administrativen Aufgaben innerhalb 

des Unternehmens zu delegieren. Die Verwaltung von Gruppenrichtlinien bildet keine Ausnahme, 

denn Sie können auch die Verwaltung dieses wichtigen Verwaltungsinstruments delegieren. 

Für die Delegierung der Verwaltung von Gruppenrichtlinien gibt es drei Optionen. Erstens können Sie 

die Berechtigung zum Erstellen, Löschen und Ändern von Gruppenrichtlinienobjekten delegieren. 

Standardmäßig haben nur die Gruppen Domänen-Admins und Richtlinien-Ersteller-Besitzer und das 

Konto System dieses Recht. Für die Gruppe Richtlinien-Ersteller-Besitzer gilt die zusätzliche Einschränkung, 

dass die Mitglieder dieser Gruppe nur die Einstellungen von Gruppenrichtlinienobjekten 

ändern können, die sie selbst erstellen. 

Sie können das Recht zum Erstellen und Löschen von Gruppenrichtlinienobjekten anderen Gruppen 

oder Benutzern erteilen, indem Sie auf der Registerkarte Delegierung des Containers Gruppenrichtlinienobjekte 

auf Hinzufügen klicken. Abbildung 11.24 zeigt die Registerkarte Gruppenrichtlinienobjekte. 

Die zweite Option zum Delegieren der Verwaltung von Gruppenrichtlinien ist die Delegierung des 

Rechts zum Verwalten von Gruppenrichtlinienobjekt-Verknüpfungen. Diese Option erteilt nicht die 

Administratorberechtigung zum Ändern von Gruppenrichtlinienobjekten, sondern das Recht zum 

Hinzufügen oder Entfernen von Gruppenrichtlinienobjekt-Verknüpfungen für ein Containerobjekt. 

Die einfachste Möglichkeit zum Erteilen dieser Berechtigungsstufe bietet der Assistent zum Zuweisen 

der Objektverwaltung. Klicken Sie in der Konsole Active Directory-Benutzer und -Computer mit 

der rechten Maustaste auf das Objekt, dessen Verwaltung delegiert werden soll, und klicken Sie 

anschließend auf Objektverwaltung zuweisen, um den Assistenten zu starten.


Wenn Sie den Assistenten auf einer Organisationseinheitsebene starten, ist eine der Standardaufgaben, 

die delegiert werden kann, die Berechtigung zum Verwalten von Gruppenrichtlinienverknüpfungen. 

Die Benutzeroberfläche wird in Abbildung 11.25 gezeigt. 


Delegieren der Berechtigung zum Verwalten von Gruppenrichtlinienobjekten 

Die dritte Möglichkeit zum Delegieren der Verwaltung von Gruppenrichtlinien besteht darin, Benutzern 

das Recht zum Generieren von Richtlinienergebnissatz-Informationen zu erteilen. Sie können 

wiederum den Assistenten zum Zuweisen der Objektverwaltung verwenden, um das Recht zum 

Generieren von Richtlinienergebnissätzen im Protokollier- oder Planungsmodus zu erteilen. 

Abbildung 11.25 zeigt diese Delegierungsoption. 

Abbildung 11.25 Delegieren der Berechtigung zum Verwalten von Gruppenrichtlinienverknüpfungen und Erstellen 

von Richtlinienergebnissätzen


Sie können auch in der Konsole Gruppenrichtlinienverwaltung das Recht zum Verwalten von 

Gruppenrichtlinienobjekt-Verknüpfungen, der Gruppenrichtlinienmodellierung und von Gruppenrichtlinienergebnissen 

delegieren. Die Registerkarte Delegierung für die Domänen- oder Organisationseinheitscontainer 

bietet die Möglichkeit, Benutzer und Gruppen hinzuzufügen und zu entfernen 

sowie eine bestimmte Berechtigung anzuwenden (siehe Abbildung 11.26). 

Abbildung 11.26 Delegieren der Berechtigung zum Verwalten von Gruppenrichtlinienverknüpfungen und 

Richtlinienergebnissätzen in der Konsole Gruppenrichtlinienverwaltung 

Implementieren von Gruppenrichtlinien zwischen Domänen und 


Mithilfe von Gruppenrichtlinien können Sie Richtlinieneinstellungen zwischen Domänen und sogar 

zwischen vertrauenswürdigen Gesamtstrukturen erzwingen. In beiden Fällen gibt es verschiedene 

signifikante Einschränkungen und Problematiken, mit denen Sie sich von der Implementierung solcher 

Richtlinieneinstellungen beschäftigen müssen. 

Nach Erstellen eines Gruppenrichtlinienobjekts in einem Windows Server 2008 Active Directory können 

Sie das Gruppenrichtlinienobjekt mit beliebigen Standorten, Domänen oder Organisationseinheiten 

in der Gesamtstruktur verknüpfen. Die Haupteinschränkung beim Verknüpfen von Gruppenrichtlinienobjekten 

zwischen Domänen besteht darin, dass die Gruppenrichtlinienobjekte nur auf den 

Domänencontrollern in der Domäne gespeichert werden, auf denen Sie erstellt wurden. Wenn Sie ein 

Gruppenrichtlinienobjekt mit einem Container in einer anderen Domäne verknüpfen möchten, sehen 

Sie sich ggf. signifikanten Problemen bei Netzwerkbandbreite und Sicherheit gegenüber. Beispiel: 

Wenn ein Gruppenrichtlinienobjekt mit einer Organisationseinheit in einer Domäne verknüpft ist, die 

sich von der unterscheidet, in der das Gruppenrichtlinienobjekt erstellt wurde, müssen alle Computer 

in der Organisationseinheit in der Lage sein, sich mit einem Domänencontroller in der Quelldomäne 

des Gruppenrichtlinienobjekts zu verbinden, um die Gruppenrichtlinie herunterzuladen. Wenn einer 

dieser Domänencontroller sich am selben Standort wie die Clientcomputer befindet, wird die Netzwerkbandbreite 

nicht wesentlich beeinträchtigt.


Wenn sich dagegen alle Domänencontroller, die über eine Kopie des Gruppenrichtlinienobjekts verfügen, 

an verschiedenen Standorten befinden und über eine langsame WAN-Verbindung verbunden 

sind, kann die Anwendung der Richtlinieneinstellungen sehr langsam erfolgen und die verfügbare 

Bandbreite beträchtlich beeinträchtigen. Wenn zudem die Benutzer in einer Domäne ein Gruppenrichtlinienobjekt 

aus einer anderen Domäne anwenden müssen, benötigen die Benutzer und Computer 

in der Zieldomäne Lesezugriff auf sowohl den Gruppenrichtliniencontainer in Active Directory als 

auch die Gruppenrichtlinienvorlage im Ordner SYSVOL. In den meisten Fällen ist es besser, Gruppenrichtlinienobjekte 

für jede einzelne Domäne zu erstellen, anstatt ein Gruppenrichtlinienobjekt in 

mehreren Domänen einzusetzen. 

Diese Probleme gelten auch bei Verwenden von Gruppenrichtlinien zwischen vertrauenswürdigen 

Gesamtstrukturen. Windows Server 2008 Active Directory bietet die Möglichkeit, dass vertrauenswürdige 

Gesamtstrukturen Gruppenrichtlinienobjekte gemeinsam nutzen. Diese Option kann hilfreich 

sein, wenn mobile Benutzer an verschiedenen Unternehmensstandorten in getrennten Gesamtstrukturen 

arbeiten. In diesem Szenario können für Benutzer, die sich an einem Computer in einer 

anderen Gesamtstruktur anmelden, weiterhin die Gruppenrichtlinieneinstellungen ihrer Stammdomäne 

gelten. Es folgen andere Features, die zwischen Gesamtstrukturen zur Verfügung stehen: 

• Die für die Softwareverteilung verwendeten Freigaben können sich in einer getrennten Gesamtstruktur 

befinden. 

• Anmeldeskripts auf einem Domänencontroller in einer anderen Gesamtstruktur können gelesen 

werden. 

• Umgeleitete Ordner und servergespeicherte Benutzerprofile können sich auf einem Computer in 

einer anderen Gesamtstruktur befinden. 

In allen Fällen können die Probleme bei Netzwerkbandbreite und Sicherheit bedeuten, dass es sinnvoller 

ist, in jeder Gesamtstruktur eigene Gruppenrichtlinienobjekte einzurichten, anstatt diese 

gesamtstrukturübergreifend zu implementieren. 

Verwalten von Gruppenrichtlinienobjekten 

In der Konsole Gruppenrichtlinienverwaltung können verschiedene Aufgaben zum Verwalten und 

Pflegen der Gruppenrichtlinieninfrastruktur ausgeführt werden, so z.B. die Folgenden: 

• Sichern und Wiederherstellen von Gruppenrichtlinienobjekten 

• Kopieren von Gruppenrichtlinienobjekten 

• Importieren von Einstellungen aus einem Gruppenrichtlinienobjekt 

• Modellieren von und Erstellen von Berichten zu Gruppenrichtlinienergebnissen 

Sichern und Wiederherstellen von Gruppenrichtlinienobjekten 

Sicherheit und Verwaltung Ihrer Active Directory-Infrastruktur hängen sehr stark von der Gruppenrichtlinienfunktion 

ab. Aus diesem Grund müssen Sie eine Sicherungsstrategie für die Gruppenrichtlinienobjekte 

in Ihrer Umgebung einrichten und verwalten. Die Konsole Gruppenrichtlinienverwaltung 

bietet eine Sicherungsfunktion, mit der Sie einzelne Gruppenrichtlinienobjekte bzw. alle in Ihrer 

Domäne konfigurierten Gruppenrichtlinienobjekte sichern können. Die Sicherungsfunktion kann auch 

zum Exportieren von Gruppenrichtlinienobjekten verwendet werden, die in andere Domänen oder 

Active Directory-Gesamtstrukturen migriert oder importiert werden sollen.

Verwalten von Gruppenrichtlinienobjekten 433 

Die Sicherungsfunktion in der Konsole Gruppenrichtlinienverwaltung sichert Gruppenrichtlinienobjekte 

in einem Ordner, der während des Sicherungsprozesses angegeben wird. Um die Sicherung 

durchführen zu können, benötigen Sie Leseberechtigungen für das Gruppenrichtlinienobjekt und 

Schreibberechtigungen für den Ordner, den die Sicherung als Zielspeicherort verwendet. 

Wichtig Es wird empfohlen, dass der Zielordner abgesichert wird und nur autorisierte Administratoren 

Zugriff auf die gesicherten Gruppenrichtlinienobjekte erhalten. 

Führen Sie die folgenden Schritte aus, um ein einzelnes Gruppenrichtlinienobjekt bzw. alle Gruppenrichtlinienobjekte 

in der Domäne zu sichern: 

1. Wechseln Sie in der Konsole Gruppenrichtlinienverwaltung zum Container Gruppenrichtlinienobjekte. 

2. Zum Sichern aller Gruppenrichtlinienobjekte in der Domäne klicken Sie mit der rechten Maustaste 

auf den Container Gruppenrichtlinienobjekte und wählen Alle sichern aus. Um nur ein 

einzelnes Gruppenrichtlinienobjekt zu sichern, klicken Sie mit der rechten Maustaste auf das 

Gruppenrichtlinienobjekt, und wählen anschließend Sichern aus. Bei beiden Vorgehensweisen 

wird das in Abbildung 11.27 gezeigte Dialogfeld geöffnet. 


Sichern von Gruppenrichtlinienobjekten in der Konsole Gruppenrichtlinienverwaltung 

3. Geben Sie in das Feld Pfad den Pfad des Ordners ein, in dem die Gruppenrichtlinienobjekt-Sicherung 

gespeichert wird. Sie können auch eine Beschreibung des Sicherungsauftrags eingeben. 

4. Klicken Sie auf die Schaltfläche Sichern, um den Sicherungsvorgang zu starten. 

Über die Konsole Gruppenrichtlinienverwaltung können Sie Gruppenrichtlinienobjekte verwalten 

und wiederherstellen. Technisch wird jedes Gruppenrichtlinienobjekt mit Versionsinformationen, 

Zeitstempel der Sicherung und einer Beschreibung einzeln gesichert. Dadurch können Sie entweder 

die neueste Version eines bestimmten Gruppenrichtlinienobjekts oder bei Bedarf frühere Versionen 

wiederherstellen. Um ein Gruppenrichtlinienobjekt wiederherstellen zu können, benötigen Sie 

Berechtigungen zum Erstellen von Gruppenrichtlinienobjekten in der Domäne und Leseberechtigungen 

für den Ordner mit den gesicherten Gruppenrichtlinienobjekten.


Führen Sie zum Wiederherstellen von Gruppenrichtlinienobjekten in der Domäne die folgenden 

Schritte aus: 

1. Wechseln Sie in der Konsole Gruppenrichtlinienverwaltung zum Container Gruppenrichtlinienobjekte. 

2. Um die gesicherten Gruppenrichtlinienobjekte zu verwalten, klicken Sie mit der rechten Maustaste 

auf den Container Gruppenrichtlinienobjekte, und wählen Sie Sicherungen verwalten. Das in 

Abbildung 11.28 gezeigte Dialogfeld Sicherungen verwalten wird geöffnet. 

3. Wählen Sie das wiederherzustellende Gruppenrichtlinienobjekt aus, und klicken Sie dann auf die 

Schaltfläche Wiederherstellen. Sie können auch auf die Schaltfläche Einstellungen anzeigen klicken, 

um einen Bericht zu den Einstellungen anzuzeigen, die im Gruppenrichtlinienobjekt konfiguriert 

sind. 

Hinweis Sie können auch mit der rechten Maustaste auf ein einzelnes Gruppenrichtlinienobjekt klicken 

und dann auf Von Sicherung wiederherstellen klicken, wodurch der Assistent zum Wiederherstellen 

von Gruppenrichtlinienobjekten gestartet wird. Der einzige Unterschied ist, dass der Assistent nur 

das Gruppenrichtlinienobjekt wiederherstellt, das Sie ausgewählt hatten, und nicht das Dialogfeld Sicherungen 

verwalten anzeigt. 

Abbildung 11.28 Verwalten der Sicherungen von Gruppenrichtlinienobjekten in der Konsole 

Gruppenrichtlinienverwaltung

Kopieren von Gruppenrichtlinienobjekten 


Über die in die Konsole Gruppenrichtlinienverwaltung integrierte Funktion Kopieren können Sie 

Gruppenrichtlinieneinstellungen aus einer Domäne in eine andere überführen. Für Kopiervorgänge 

benötigen Sie Leseberechtigungen für das Gruppenrichtlinienobjekt in der Quelldomäne und Schreibberechtigungen 

in der Zieldomäne zum Erstellen des neuen Gruppenrichtlinienobjekts. Klicken Sie 

zum Kopieren eines Gruppenrichtlinienobjekts mit der rechten Maustaste auf dasselbige, und klicken 

Sie anschließend auf Kopieren. Wechseln Sie anschließend zur Zieldomäne, klicken Sie mit der rechten 

Maustaste auf den Container Gruppenrichtlinienobjekte, und wählen Sie Einfügen aus. Der Assistent 

zum domänenübergreifenden Kopieren unterstützt Sie anschließend beim Kopiervorgang. Der 

Assistent befragt Sie ggf. nach der Konfiguration einer Migrationstabelle, um den Kopiervorgang in 

eine andere Domäne abzuschließen. Eine Migrationstabelle dient zum Übersetzen bestimmter Gruppenrichtlinienobjekt-Informationen, 

die ggf. in der neuen Domäne nicht geeignet sind. Sie können 

beispielsweise über ein Gruppenrichtlinienobjekt verfügen, das die Ordnerumleitung für Benutzer in 

der Quelldomäne ermöglicht. Wenn Sie versuchen, das Gruppenrichtlinienobjekt in eine neue Zieldomäne 

zu kopieren, kann eine Migrationstabelle zum Angeben neuer URL-Informationen für die 

Anforderungen an die Ordnerumleitung in der neuen Domäne verwendet werden. 

Importieren der Einstellungen von Gruppenrichtlinienobjekten 

In bestimmten Situationen müssen Sie ggf. Konfigurationen von Gruppenrichtlinienobjekten zwischen 

zwei nicht miteinander verbundenen Umgebungen kopieren. Um beispielsweise Gruppenrichtlinien 

in einer Testumgebung zu testen, müssen Sie ggf. die genehmigten Konfigurationen von Gruppenrichtlinienobjekten 

in Ihre Produktionsumgebung überführen. Der erste Schritt ist das Erstellen 

einer Sicherung der Gruppenrichtlinienobjekte (siehe „Sichern und Wiederherstellen von Gruppenrichtlinienobjekten“ 

weiter oben in diesem Kapitel). Anschließend können Sie die Sicherungsdateien 

auf einen Wechseldatenträger oder an einen freigegebenen Netzwerkspeicherort kopieren. Der letzte 

Schritt besteht im Erstellen eines neuen Gruppenrichtlinienobjekts oder Überschreiben eines vorhandenen 

Gruppenrichtlinienobjekts, indem die gesicherten Gruppenrichtlinienobjekt-Einstellungen vom 

Wechseldatenträger oder aus dem freigegebenen Netzwerkspeicherort importiert werden. In diesem 

Szenario wird u. U. auch eine Migrationstabelle zum Angeben domänenspezifischer Einstellungen 

wie Sicherheitsgruppen und UNC-Pfade verwendet. 

Modellieren von und Erstellen von Berichten zu 

Gruppenrichtlinienergebnissen 

Windows Server 2008 erfasst Daten zur Gruppenrichtlinienverarbeitung und speichert diese in einer 

WMI-Datenbank auf dem lokalen Computer. Diese Daten enthalten die Liste, den Inhalt und Protokollinformationen 

jedes verarbeiteten Gruppenrichtlinienobjekts und dienen zum Bestimmen, wie 

Richtlinieneinstellungen auf Benutzer und Computer angewendet werden. Das dazugehörige Feature 

heißt Richtlinienergebnissatz. Richtlinienergebnissatz kann im Protokollierungsmodus und im Planungsmodus 

ausgeführt werden. Der Protokollierungsmodus liefert Informationen zu allgemeinen 

Richtlinienergebniseinstellungen, die für einen vorhandenen Benutzer oder Computer gelten. Der 

Planungsmodus ermöglicht das Simulieren der Richtlinienergebniseinstellungen, die basierend auf 

bestimmten Variablen ggf. auf einen Benutzer oder Computer angewendet werden sollen. 

Die Konsole Gruppenrichtlinienverwaltung integriert die Protokollier- und Planungsmodi von Richtlinienergebnissatz. 

Der Planungsmodus wird als Gruppenrichtlinienmodellierung, der Protokolliermodus 

als Gruppenrichtlinienergebnisse bezeichnet.


Gruppenrichtlinienmodellierung 

Das Feature Gruppenrichtlinienmodellierung ermöglicht basierend auf Ihrer aktuellen Gruppenrichtlinieninfrastruktur 

„Was-wäre-wenn?-Szenarien“. Angenommen, ein Benutzer wird innerhalb Ihres 

Unternehmens in eine andere Abteilung versetzt. Sie möchten vorab bestimmen, was mit dem Benutzerobjekt 

geschieht, wenn es aus der aktuellen Organisationseinheit in die der neuen Abteilung verschoben 

wird. Der Gruppenrichtlinienmodellierungs-Assistenten dient zum Simulieren und Melden 

der Richtlinienergebnisse, ohne dass Sie die Verschiebung tatsächlich mit dem realen Konto durchführen 

müssen. 

Um mit Gruppenrichtlinienmodellierung arbeiten zu können, benötigen Sie die Berechtigung Richtlinienergebnissatz 

erstellen für die Domäne oder Organisationseinheit mit den Objekten, auf die Sie 

die Abfrage anwenden möchten. Ein Domänencontroller mit mindestens Windows Server 2003 muss 

außerdem in der Umgebung vorhanden sein, um die für die Abfrage benötigten Informationen bereitzustellen. 

Es gibt zwei Wege, ein Modellierungsszenario einzuleiten. Der erste sieht das Verwenden der Konsole 

Active Directory-Benutzer und -Computer vor, in der Sie mit der rechten Maustaste auf die 

Domäne oder Organisationseinheit klicken, dann auf Alle Aufgaben zeigen und schließlich auf Richtlinienergebnissatz 

erstellen (Planung) klicken. Der zweite sieht den Einsatz der Konsole Gruppenrichtlinienverwaltung 

vor. Klicken Sie mit der rechten Maustaste auf Gruppenrichtlinienmodellierung, 

und klicken Sie auf Gruppenrichtlinienmodellierungs-Assistent, um den Assistenten zu starten. 

Anschließend wird jeweils ein einleitendes Dialogfeld angezeigt, in das Sie die Benutzer- und Computerinformationen 

eingeben können, die an der Simulation teilnehmen sollen. Abbildung 11.29 zeigt, 

dass der Benutzer Adatum\Don und der Computer Adatum\SEA-CL1 an der Modellierungssimulation 

teilnehmen. 


Konfigurieren der Gruppenrichtlinienmodellierung


Beim Durchlaufen des Modellierungsszenarios fordert der Assistent verschiedene Angaben an, z.B.: 

• Möchten Sie eine langsame Netzwerkverbindung simulieren? 

• Möchten Sie die Loopbackverarbeitung aktivieren? 

• Den neuen Speicherort, der für Benutzer- und Computerkonten simuliert werden soll 

• Änderungen an der Mitgliedschaft des Benutzers in Sicherheitsgruppen 

• Änderungen an der Mitgliedschaft des Computers in Sicherheitsgruppen 

• WMI-Filter, die für Benutzer und Computer verknüpft werden sollen 

Die Ergebnisse des Szenarios für die Gruppenrichtlinienmodellierung werden in einem ausführlichen 

Berichtsformat angezeigt (siehe Abbildung 11.30). 

Der Bericht Gruppenrichtlinienmodellierung enthält drei Registerkarten, die jeweils detaillierte Informationen 

zu den Ergebnissen des Szenarios enthalten. Der Registerkarte Zusammenfassung enthält 

allgemeine Details zur Computer- und Benutzerkonfiguration, z.B. die basierend auf der Simulation 

angewendeten und verweigerten Gruppenrichtlinienobjekt-Einstellungen. Die Registerkarte Einstellungen 

zeigt eine Liste aller Einstellungen, die von den simulierten Gruppenrichtlinienobjekten angewendet 

wurden. Die Registerkarte Abfrage bietet statistische Informationen, z.B. Zeitpunkt der Ausführung 

der letzten Abfrage, Domänencontroller, der die Simulation verarbeitet hat, und für die 

Simulation verwendete Kriterien. 


Anzeigen der Ergebnisse der Gruppenrichtlinienmodellierung 

Gruppenrichtlinienergebnisse 

Das Feature Gruppenrichtlinienergebnisse bietet eine nützliche Methode zum Beheben von Problemen 

bei der Anwendung von Richtlinieneinstellungen für einen bestimmten Benutzer oder Computer. 

Wenn beispielsweise ständig die falschen Richtlinieneinstellungen auf einen Benutzer angewendet 

werden, können mithilfe von Gruppenrichtlinienergebnisse die angewendeten Richtlinieneinstellungen 

samt Reihenfolge der Anwendung überprüft werden.


Gruppenrichtlinienergebnisse kann über die Konsolen Active Directory-Benutzer und -Computer oder 

Gruppenrichtlinienverwaltung gestartet werden. Klicken Sie in Active Directory-Benutzer und -Computer 

mit der rechten Maustaste auf ein bestimmtes Computer- oder Benutzerobjekt, zeigen Sie auf 

Alle Aufgaben und klicken Sie auf Richtlinienergebnissatz erstellen (Protokollierung). Klicken Sie in 

der Konsole Gruppenrichtlinienverwaltung mit der rechten Maustaste auf Gruppenrichtlinienergebnisse, 

und klicken Sie auf Gruppenrichtlinienergebnis-Assistent, um den Assistenten zu starten. Im 

gestarteten Assistenten müssen Sie den abzufragenden Computer (lokal oder remote) angeben. 

Anschließend wird eine Liste mit auf dem Computer zwischengespeicherten Benutzerkonten angezeigt, 

für die Sie Richtlinieneinstellungen abrufen können. 

Achtung Vorzugsweise sollten Sie in der Konsole Gruppenrichtlinienverwaltung den Ergebnissatz der 

Richtlinieneinstellungen überprüfen, da das Tool in Active Directory-Benutzer und -Computer ggf. nicht alle 

Ergebnisse für sämtliche Erweiterungen anzeigt. 

Der Bericht Gruppenrichtlinienergebnisse enthält drei Registerkarten zu den Verarbeitungsergebnissen 

von Gruppenrichtlinienobjekten. Auf der Registerkarte Zusammenfassung finden Sie eine allgemeine 

Übersicht zu den Gruppenrichtlinienobjekten, die für den getesteten Benutzer bzw. Computer 

angewendet oder verweigert wurden. Die Registerkarte Einstellungen zeigt eine Liste aller Einstellungen, 

die über Gruppenrichtlinien angewendet wurden. Die Registerkarte Richtlinienereignisse enthält 

Ereignisinformationen zu Gruppenrichtlinien, die auf dem Zielcomputer gemeldet wurden. 

Um Gruppenrichtlinienergebnis-Informationen erfolgreich abzurufen, müssen folgende Anforderungen 

erfüllt sein: 

• Sie benötigen die Berechtigung Gruppenrichtlinienergebnisse lesen für die Domäne oder Organisationseinheit 

mit dem Computer bzw. Benutzer oder müssen Mitglied der lokalen Gruppe Administratoren 

auf dem Zielcomputer sein. 

• Der abgefragte Computer muss das Betriebssystem Windows XP, Windows Vista, Windows 2003 

oder Windows Server 2008 haben. 

• Der abgefragte Computer muss eingeschaltet und an das Netzwerk angeschlossen sein. 

• Der Dienst Windows Management Instrumentation muss aktiviert sein. 

• Um Gruppenrichtlinienergebnisse remote zu generieren, muss die Ausnahme Remoteverwaltung 

in den Windows Firewall-Einstellungen des Zielcomputers aktiviert sein. 

• Der Benutzer, dessen Probleme Sie behandeln oder dessen Daten Sie abfragen, muss sich mindestens 

einmal am Zielcomputer angemeldet haben. 

Hinweis Sie können die Ergebnisse für Gruppenrichtlinienmodellierung und Gruppenrichtlinienergebnisse 

als eigenständige interaktive und webbasierte Berichte speichern. Dadurch können Sie Informationen zur 

Modellierung und Verarbeitung mühelos in Ihrem Unternehmen verteilen. Die einzige Anforderung für die 

Anzeige der gespeicherten Berichte ist Microsoft Internet Explorer 6 oder höher. 

Hinweis Gruppenrichtlinienergebnisse können auch mit dem Befehlszeilenprogramm Gpresult für einen 

lokalen oder Remotecomputer abgerufen werden. Geben Sie an der Eingabeaufforderung gpresult ein, um 

weitere Informationen zu erhalten.


So funktioniert es: Gpresult.exe 

Gpresult.exe zeigt Gruppenrichtlinieneinstellungen und den Richtlinienergebnissatz für einen 

Benutzer oder Computer an. Wählen Sie auf einem lokalen Computer folgende Syntax: 

gpresult [/s Computer [/u Domäne\Benutzer [/p Kennwort]]] [/scope {user|computer] 

[/user Zielbenutzername] [/r | /v | /z] [/x | /h Dateiname [/f]] 

Parameter: 

Parameter 

Beschreibung 

/s Gibt den Namen oder die IP-Adresse eines Remotecomputers an. Verwenden Sie 

keine umgekehrten Schrägstriche. Die Standardeinstellung ist der lokale Computer. 

/u Führt den Befehl unter Verwendung der Kontoberechtigungen des Benutzers aus, 

der durch Benutzer oder Domäne\Benutzer angegeben ist. Per Voreinstellung werden 

die Berechtigungen des am Computer angemeldeten Benutzers verwendet, 

der den Befehl aufruft. 

/p Gibt das Kennwort des Benutzerkontos an, das mit dem Parameter /u angegeben 

wird. 

/scope {user|computer} 

Zeigt entweder Benutzer- oder Computerergebnisse an. Gültige Werte für den Parameter 

/scope sind user oder computer. Wenn Sie den Parameter /scope weglassen, 

zeigt Gpresult.exe sowohl Benutzer- als auch Computereinstellungen an. 

/user 

Gibt den Namen des Benutzers an, für den die Richtlinienergebnissatz-Daten angezeigt 

werden. 

/r Zeigt eine Zusammenfassung der Richtlinienergebnissatz-Daten an. 

/v Legt fest, dass die Ausgabe ausführliche Richtlinieninformationen enthält. 

/z Legt fest, dass die Ausgabe alle verfügbaren Informationen über Gruppenrichtlinien 

umfasst. Da dieser Parameter mehr Informationen als der Parameter /v generiert, 

sollten Sie bei Verwenden dieses Parameters die Ausgabe in eine Textdatei 

umleiten, z.B. gpresult /z >policy.txt). 

/x Speichert den Bericht im XML-Format im Pfad und mit dem Dateinamen, der vom 

Parameter angegeben wird (gilt für Windows Server 2008 und Windows 

Vista mit Service Pack 1). 

/h Speichert den Bericht im HTML-Format im Pfad und mit dem Dateinamen, der vom 

Parameter angegeben wird (gilt für Windows Server 2008 und Windows 

Vista mit Service Pack 1). 

/f Zwingt Gpresult zum Überschreiben des im Parameter /x oder /h angegebenen 

Dateinamens. 

/? Zeigt an der Eingabeaufforderung Hilfeinformationen an. 

Beispiele 

Die folgenden Beispiele zeigen, wie Sie mit Gpresult.exe arbeiten können: 

gpresult /user Zielbenutzername /scope Computer 

gpresult /s srvmain /u maindom\hiropln /p p@ssW23 /user Zielbenutzername /scope USER gpresult /s srvmain / 

u maindom\hiropln /p p@ssW23 /user Zielbenutzername /z >policy.txt gpresult /h gpresult.html /f 

Judith Herman, Group Policy Programming Writer 

Windows Enterprise Management Division UA


Erstellen von Skripts für die Gruppenrichtlinienverwaltung 

Die Konsole Gruppenrichtlinienverwaltung bietet COM-Schnittstellen, die den Einsatz verschiedener 

Skripttechnologien bzw. Skriptsprachen wie JScript, VBScript, Visual Basic und VC++ ermöglichen. 

Dank dieser Funktionalität können Sie viele der Standardverwaltungsaufgaben für Gruppenrichtlinien 

automatisieren: 

• Erstellen, Löschen und Umbenennen von Gruppenrichtlinienobjekten 

• Verknüpfen von Gruppenrichtlinienobjekten und WMI-Filtern bzw. Aufheben der Verknüpfung 

• Delegieren der Sicherheitsadministration 

• Erstellen von Berichten zu Gruppenrichtlinienobjekt-Einstellungen 

• Erstellen von Berichten zu Richtlinienergebnissatz-Daten 

• Sichern und Wiederherstellen/Importieren von Gruppenrichtlinienobjekten 

• Kopieren und Einfügen von Gruppenrichtlinienobjekten 

• Suchen nach Gruppenrichtlinienobjekten, WMI-Filtern und Sicherungen 

Hinweis Sie können nur basierend auf gesamten Gruppenrichtlinienobjekten Skripts für Verwaltungsaufgaben 

und nicht zum Ändern von Richtlinieneinstellungen in Gruppenrichtlinienobjekten erstellen. 

Auf der DVD Auf der Begleit-CD zu diesem Buch finden Sie die ausführbare Datei GPMCSample- 

Scripts.msi, die verschiedene Skripts zum Verwalten von Gruppenrichtlinien enthält. 

Die Beispielskripts in GPMCSampleScripts.msi auf der Begleit-CD zu diesem Buch müssen in einer 

Testumgebung getestet werden, bevor Sie sie in Ihre Produktionsumgebung implementieren. Die enthaltenen 

Beispielskripts werden in Tabelle 11.6 vorgestellt. 

Tabelle 11.6 

Beispielskripts in GPMCSampleScripts.msi 

Verwaltungsaufgabe Skriptname Beschreibung 

Sichern eines Gruppenrichtlinienobjekts 

BackupGPO.wsf 

Dient zum Sichern aller Gruppenrichtlinienobjekte in einer 

Domäne im angegebenen 

Sicherungsverzeichnis. 

Sichern aller Gruppenrichtlinienobjekte 

in einer Domäne 

Erstellen eines Gruppenrichtlinienobjekts 

mit Standardoptionen 

BackupAllGPOs.wsf 

CreateGPO.wsf 

Sichert bei Angabe von Gruppenrichtlinienobjekt-Name bzw. 

-GUID das Gruppenrichtlinienobjekt im angegebenen Sicherungsverzeichnis. 

Dient zum Erstellen eines Gruppenrichtlinienobjekts mit dem 

angegebenen Namen in der aktuellen Domäne unter Verwendung 

der Standardoptionen. 

Erstellen einer Migrationstabelle CreateMigrationTable.wsf Füllt die Einträge einer Migrationstabelle mit Sicherheitsprinzipalen 

und UNC-Pfaden auf, auf die in einem Gruppenrichtlinienobjekt 

oder einer Sicherung verwiesen wird. 

Kopieren eines Gruppenrichtlinienobjekts 

CopyGPO.wsf 

Dient zum Erstellen eines neuen Gruppenrichtlinienobjekts 

und Kopieren der Einstellungen aus dem Quell-Gruppenrichtlinienobjekt 

in das neue Ziel-Gruppenrichtlinienobjekt bei 

Angabe des Namens oder der GUID des Quell-Gruppenrichtlinienobjekts 

und dem eines neuen Ziel-Gruppenrichtlinienobjekts.

Erstellen von Skripts für die Gruppenrichtlinienverwaltung 441 

Tabelle 11.6 

Beispielskripts in GPMCSampleScripts.msi (Fortsetzung) 


Erstellen einer Richtlinienumgebung 

mithilfe einer XML-Abbildung 

Erstellen einer XML-Abbildung 

einer Richtlinienumgebung 

Löschen eines Gruppenrichtlinienobjekts 

Gewährt Berechtigungen für alle 

Gruppenrichtlinienobjekte in einer 

Domäne 

Erstellen eines Berichts für ein 

Gruppenrichtlinienobjekt 

Erstellt einen Bericht für alle 

Gruppenrichtlinienobjekte in der 

Domäne 

Importieren von Einstellungen in 

ein Gruppenrichtlinienobjekt 

Importieren mehrerer Gruppenrichtlinienobjekte 

in eine Domäne 

Wiederherstellen eines Gruppenrichtlinienobjekts 

Wiederherstellen aller Gruppenrichtlinienobjekte 

Erteilen von Berechtigungen für mit 

einer Domäne, einer Organisationseinheit 

oder einem Standort 

verknüpfte Gruppenrichtlinienobjekte. 

CreateEnvironment- 

FromXML.wsf 

CreateXMLFromEnvironment.wsf 

DeleteGPO.wsf 

GrantPermissionOn- 

AllGPOs.wsf 

GetReportsForGPO.wsf 

GetReportsFor- 

AllGPOs.wsf 

ImportGPO.wsf 

ImportAllGPOs.wsf 

RestoreGPO.wsf 

RestoreAllGPOs.wsf 

SetGPOSecurity- 

BySOM.wsf 

Liest eine XML-Datei, die eine Richtlinienumgebung angibt, 

z.B. Organisationseinheiten, Gruppenrichtlinienobjekte, Links 

und Sicherheitsgruppen. Das Skript kann entweder die Umgebung 

in einer Domäne einrichten, indem die Objekte erstellt 

werden, oder die Umgebung löschen, indem in der 

XML-Datei angegebene Objekte gelöscht werden. 

Liest eine vorhandene Richtlinienumgebung und erstellt 

eine XML-Datei, die diese Umgebung abbildet. In der XML- 

Datei werden Informationen zu Organisationseinheiten, 

Gruppenrichtlinienobjekten und Gruppenrichtlinienobjekt-Verknüpfungen 

sowie Sicherheitseinstellungen für Gruppenrichtlinienobjekte 

erfasst. Sie können dieses Skript zusammen mit 

dem Skript CreateEnvironmentFromXML.wsf verwenden, um 

für Bereitstellungszwecke ein Replikat der Domäne zu erstellen. 

Löscht das Gruppenrichtlinienobjekt mit dem angegebenen 

Namen bzw. der angegebenen GUID. Das Skript löscht standardmäßig 

Verknüpfungen mit diesem Gruppenrichtlinienobjekt 

in derselben Domäne. 

Gewährt einem Benutzer oder einer Gruppe den angegebenen 

Berechtigungsgrad für alle Gruppenrichtlinienobjekte 

in der angegebenen Domäne. 

Erstellt einen HTML- und XML-Bericht für ein angegebenes 

Gruppenrichtlinienobjekt an einem angegebenen Speicherort 

im Dateisystem. 

Erstellt HTML- und XML-Berichte für alle Gruppenrichtlinienobjekte 

in der Domäne an einem angegebenen Speicherort 

im Dateisystem. 

Importiert die Einstellungen aus der angegebenen Sicherung 

in ein in der Domäne vorhandenes Gruppenrichtlinienobjekt. 

Erstellt ein neues Gruppenrichtlinienobjekt und importiert Einstellungen 

in dieses Gruppenrichtlinienobjekt für jedes gesicherte 

Gruppenrichtlinienobjekt, das an einem bestimmten 

Speicherort im Dateisystem gespeichert ist. 

Stellt ein gesichertes Gruppenrichtlinienobjekt wieder her. 

Stellt alle Gruppenrichtlinienobjekte wieder her, die an einem 

angegebenen Speicherort im Dateisystem gespeichert sind. 

Gewährt einem Benutzer oder einer Gruppe den angegebenen 

Berechtigungsgrad für alle Gruppenrichtlinienobjekte, 

die mit einer angegebenen Domäne, Organisationseinheit 

oder einem Standort verknüpft sind. Sie können als Berechtigungsgrad 

Read, Apply, EditFullEdit oder None angeben.


Tabelle 11.6 



SetGPOPermissions.wsf 

Festlegen von Berechtigungen für 

Gruppenrichtlinienobjekte 

Auflisten von Informationen zum 

Verwaltungsbereich 

Auflisten von Gruppenrichtlinienobjekten 

nach Sicherheitsgruppe 


mit doppelt vorhandenen 

Namen 


ohne die Berechtigung 

Übernehmen 

Auflisten von in SYSVOL verwaisten 

Gruppenrichtlinienobjekten 

Festlegen von Berechtigungen zum 

Erstellen von Gruppenrichtlinienobjekten 

Festlegen richtlinienbezogener Berechtigungen 

für eine angegebene 

Domäne, Organisationseinheit oder 

einen Standort 

Auflisten aller Gruppenrichtlinienobjekte 


Auflisten deaktivierter Gruppenrichtlinienobjekte 

Auflisten von Gruppenrichtlinienobjekt-Informationen 

SetGPOCreation- 

Permissions.wsf 

SetSOMPermissions.wsf 

ListAllGPOs.wsf 

FindDisabledGPOs.wsf 

DumpGPOInfo.wsf 

DumpSOMInfo.wsf 


nach Richtlinienerweiterung 

FindGPOsByPolicy- 

Extension.wsf 

FindGPOsBySecurity- 

Group.wsf 

FindDuplicateNamed- 

GPOs.wsf 

GPOsWithNoSecurity- 

Filtering.wsf 

FindOrphanedGPOs- 

InSYSVOL.wsf 

Legt den Berechtigungsgrad eines Sicherheitsprinzipals für 

ein angegebenes Gruppenrichtlinienobjekt fest. Sie können 

als Berechtigungsgrad Read, Apply, EditFullEdit oder None 

angeben. 

Erteilt oder entfernt die Berechtigung zum Erstellen von Gruppenrichtlinienobjekten 

in einer Domäne für einen angegebenen 

Sicherheitsprinzipal. 

Legt richtlinienbezogene Berechtigungen für einen angegebenen 

Verwaltungsbereich fest. Ein Verwaltungsbereich ist 

eine beliebige Domäne, Organisationseinheit oder ein 

Standort. 

Listet alle Gruppenrichtlinienobjekte in der angegebenen 

Domäne auf. 


Domäne auf, die deaktiviert oder teilweise deaktiviert sind. 

Gibt Informationen zu einem bestimmten Gruppenrichtlinienobjekt 

aus. Dazu zählen Erstellungszeitpunkt, Änderungszeitpunkt, 

Besitzer, Status, Versionsnummer, Verknüpfungen, 

Sicherheitsgruppen zum Filtern des Gruppenrichtlinienobjekts 

und Sicherheitsgruppen mit Vollzugriffs-, Bearbeitungs-, 

Lese- oder benutzerdefinierten Berechtigungen. 

Gibt alle Informationen zu einem bestimmten Verwaltungsbereich 

aus, einschließlich Gruppenrichtlinienobjekt-Verknüpfungen 

und richtlinienbezogener Berechtigungen für den 

Verwaltungsbereich. 

Gibt alle Gruppenrichtlinienobjekte in der angegebenen 

Domäne aus, für die eine bestimmte Richtlinienerweiterung 

konfiguriert ist. Findet z.B. alle Gruppenrichtlinienobjekte 

mit Richtlinieneinstellungen für Softwareinstallation und 

Ordnerumleitung. 

Gibt alle Gruppenrichtlinienobjekte aus, für die ein angegebener 

Sicherheitsprinzipal über die angegebene Berechtigung 

für das jeweilige Gruppenrichtlinienobjekt verfügt. Sie 

können als Berechtigungsgrad Read, Apply, Edit, FullEdit 

oder None angeben. 


Domäne mit doppelten Namen auf. 

Gibt alle Gruppenrichtlinienobjekte in der angegebenen Domäne 

aus, die für niemanden gelten, da die Berechtigung 

Übernehmen nicht im Gruppenrichtlinienobjekt festgelegt ist. 

Dient zum Suchen und Ausgeben aller Gruppenrichtlinienobjekte 

in SYSVOL ohne entsprechende Komponente in 

Active Directory.

Planen einer Gruppenrichtlinienimplementierung 443 

Tabelle 11.6 



Ausgeben der Richtlinienstruktur 

des Verwaltungsbereichs 

Auflisten von Sicherungen von 

Gruppenrichtlinienobjekten an 

einem angegebenen Speicherort 

im Dateisystem 

Auflisten von Domänen und Organisationseinheiten 

mit externen 

Gruppenrichtlinienobjekt-Verknüpfungen 

Auflisten unverknüpfter Gruppenrichtlinienobjekte 


FindSOMsWithExternal- 

GPOLinks.wsf 

FindUnlinkedGPOs.wsf 

ListSOMPolicyTree.wsf 

QueryBackup- 

Location.wsf 

Gibt alle Domänen und Organisationseinheiten in der angegebenen 

Domäne aus, die mit einem Gruppenrichtlinienobjekt 

in einer anderen Domäne verknüpft sind. 

Listet alle Gruppenrichtlinienobjekte in der angegebenen Domäne 

ohne Verknüpfungen auf. Verknüpfungen außerhalb 

der Domäne, einschließlich Standortverknüpfungen, werden 

nicht überprüft. 

Gibt alle Verwaltungsbereiche in der angegebenen Domäne 

mit einer Liste der Gruppenrichtlinienobjekte aus, die mit der 

Domäne und einzelnen Organisationseinheiten verknüpft 

sind. 

Gibt Informationen zu allen gesicherten Gruppenrichtlinienobjekten 

an dem vom Benutzer angegebenen Speicherort im 

Dateisystem aus. 

Planen einer Gruppenrichtlinienimplementierung 

Das Feature Gruppenrichtlinien ist ein leistungsstarkes Tool zum Verwalten von Computerkonfigurationen 

in Ihrem Netzwerk. Das Implementieren von Gruppenrichtlinien kann leider sehr kompliziert 

sein und sich bei fehlerhafter Vorgehensweise sehr nachteilig auf die Arbeitsumgebung aller Benutzer 

im Unternehmen auswirken. In diesem Abschnitt werden die empfohlenen Vorgehensweisen zum Entwerfen 

der Gruppenrichtlinienimplementierung in Ihrem Netzwerk beschrieben. 

Weitere Informationen Weitere Informationen zum Verwenden von Gruppenrichtlinien zum Verwalten von 

Computerkonfigurationen finden Sie in Kapitel 12, „Einsetzen von Gruppenrichtlinien zum Verwalten von 

Benutzerdesktops“, und Kapitel 13, „Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit“, in 

denen weitere empfohlene Vorgehensweisen zum Verwenden dieses leistungsstarken Tools beschrieben 

werden. 

Einer der wichtigsten Punkte beim Entwerfen einer Gruppenrichtlinienstrategie ist die Anzahl der zu 

implementierenden Gruppenrichtlinienobjekte. Da in jedem Gruppenrichtlinienobjekt sämtliche 

Richtlinieneinstellungen verfügbar sind, können Sie theoretische alle erforderlichen Einstellungen in 

einem einzigen Gruppenrichtlinienobjekt konfigurieren. Oder Sie können ein eigenes Gruppenrichtlinienobjekt 

für jede Einstellung bereitstellen, die Sie konfigurieren möchten. Doch fast immer liegt 

die optimale Anzahl von Gruppenrichtlinienobjekten irgendwo in der Mitte, und es gibt keine Lösung, 

die in allen Situationen richtig ist. Nach dem Start des Clientcomputers und der Anmeldung des 

Benutzers müssen alle in Frage kommenden Gruppenrichtlinienobjekte verarbeitet und auf den lokalen 

Computer angewendet werden. Demzufolge beschleunigt eine niedrige Anzahl von Gruppenrichtlinienobjekten 

zumeist den Computerstart und die Benutzeranmeldung. Doch wenn Sie nur mit wenigen 

Gruppenrichtlinienobjekten arbeiten, die verschiedene Aufgaben erledigen müssen, kann die 

Dokumentation und Verwaltung schwieriger werden. Außerdem bietet sich bei Verwenden von Gruppenrichtlinienobjekten 

mit nur einigen wenigen Einstellungen deren Wiederverwendung für andere 

Organisationseinheiten an.


Allgemein wird empfohlen, mithilfe eines Gruppenrichtlinienobjekts nur eine Einstellungsgruppe zu 

konfigurieren. Sie können beispielsweise ein Gruppenrichtlinienobjekt zum Festlegen der Sicherheitskonfiguration, 

ein anderes zum Bestimmen der administrativen Vorlagen und ein weiteres zum Installieren 

eines Softwarepakets verwenden. 

Ein weiterer Entwurfsaspekt dreht sich darum, wo die Richtlinienobjekte bereitgestellt werden sollen. 

Sie können Gruppenrichtlinienobjekte entweder hoch in der Organisationseinheitsstruktur zuweisen 

und anschließend mit der Sicherheitsfilterung oder Deaktivierung arbeiten, um sicherzustellen, dass 

die Richtlinieneinstellungen auf die entsprechenden Computer oder Benutzer angewendet werden. 

Oder Sie können die Mehrzahl der Gruppenrichtlinienobjekte auf einer niedrigen Ebene der Hierarchie 

verknüpfen, damit Sie jede Richtlinie am gewünschten Punkt in der Hierarchie anwenden und 

eine komplizierte Vererbungskonfiguration vermeiden können. In den meisten Fällen ist ein Mittelweg 

ratsam. Wenn es Richtlinieneinstellungen gibt, die für alle Benutzer in der Domäne gelten sollen, 

legen Sie diese Richtlinien so hoch wie möglich fest, denn je weiter Sie in der Hierarchie nach 

unten gelangen, desto spezifischer werden die Richtlinieneinstellungen. 

Fehlerbehebung bei Gruppenrichtlinien 

Windows Server 2008 und Windows Vista bieten neue Methoden zum Beheben von Problemen bei 

der Anwendung von Gruppenrichtlinieneinstellungen. Eine davon ist der Einsatz des Gruppenrichtlinien-Ereignisprotokolls 

Betriebsbereit für die Erstellung von Ereignisberichten. Dieses Protokoll 

ersetzt die USERENV-Protokollierung in früheren Windows-Versionen. 

Sie können das Gruppenrichtlinienprotokoll Betriebsbereit anzeigen, indem Sie die Ereignisanzeige 

öffnen, zu Anwendungs- und Dienstprotokolle\Microsoft\Windows\Gruppenrichtlinie wechseln und 

Betriebsbereit auswählen. Abbildung 11.31 zeigt die Ereignisanzeige mit ausgewähltem Gruppenrichtlinienprotokoll 

Betriebsbereit. 


Anzeigen des Gruppenrichtlinienprotokolls Betriebsbereit

Fehlerbehebung bei Gruppenrichtlinien 445 

GPLogView.msi ist ein Tool zur Fehlerbehebung unter Windows Vista, mit dem Sie eine Ausgabedatei 

für gruppenrichtlinienbezogene Ereignisse erstellen können, die im Ereignisprotokoll System 

und im Gruppenrichtlinien-Ereignisprotokoll Betriebsbereit aufgezeichnet werden. Das Tool kann von 

der Website http://go.microsoft.com/fwlink/?LinkID7500475627 heruntergeladen werden. 

Das Beheben spezifischer Gruppenrichtlinienprobleme kann aufgrund der schieren Anzahl von Komponenten 

recht schwierig sein, die an diesem Kontext beteiligt sind. Doch die meisten Probleme können 

den folgenden Punkten zugeordnet werden, über die Sie meist zur Ursache des Problems gelangen: 

• Status von Gruppenrichtlinienobjekt und -verknüpfung Stellen Sie sicher, dass das Gruppenrichtlinienobjekt 

bzw. die Gruppenrichtlinienobjekt-Verknüpfung aktiviert ist und eine Verknüpfung 

zur/m entsprechenden Domäne, Organisationseinheit oder Standort besteht. Vergegenwärtigen Sie 

sich auch, dass bei Aktualisierungen nur geänderte Gruppenrichtlinienobjekte tatsächlich verarbeitet 

werden. 

• Pfad des Benutzer- bzw. Computerobjekts Sorgen Sie dafür, dass sich das Benutzer- oder 

Computerobjekt im Container befindet, mit dem das Gruppenrichtlinienobjekt verknüpft ist. 

• Replikationsproblem Falls das Gruppenrichtlinienobjekt kurz zuvor erstellt wurde, haben einige 

Domänencontroller möglicherweise die replizierten Informationen von Gruppenrichtlinienvorlage 

und -container noch nicht empfangen. Sie müssen ggf. auch DFS- oder FRS-Replikationsprobleme 

beheben, wenn Sie bemerken, dass die SYSVOL-Informationen nicht wie erwartet 

repliziert werden. 

• Vererbung von Gruppenrichtlinienobjekten Über das Feature Gruppenrichtlinienergebnisse können 

Sie prüfen, wie Gruppenrichtlinieneinstellungen für einen bestimmte Benutzer vererbt werden. 

Überprüfen Sie sehr sorgfältig die Erzwingung bzw. Deaktivierung der Vererbung sowie die Verknüpfungsreihenfolge, 

um sicherzustellen, dass Gruppenrichtlinienobjekte wie erwartet verarbeitet 

werden. 

• Sicherheitsfilterung Überprüfen Sie die Sicherheitsfilterung für das Gruppenrichtlinienobjekt 

sorgfältig. Denken Sie daran, dass dem Filter standardmäßig authentifizierte Benutzer hinzugefügt 

werden, wozu Standardbenutzer, -computer und -administratoren zählen. Sie müssen ggf. die 

Benutzer oder Gruppen für den Filter ändern, um eine ordnungsgemäße Verarbeitung zu gewährleisten. 

• Verarbeitung bei langsamen Verbindungen und Loopbackverarbeitung Sie müssen ggf. prüfen, ob 

der Clientcomputer mit den Problemen über eine langsame Netzwerkanbindung verfügt. Wie Sie 

wissen, werden nicht alle clientseitigen Erweiterungen von Gruppenrichtlinien über langsame 

Verbindungen verarbeitet. Außerdem muss bestimmt werden, ob sich der Computer im Loopbackverarbeitungsmodus 

befindet. Beides lässt sich mit Gruppenrichtlinienergebnisse feststellen, 

wenn der Computer mit dem Problem im Fokus dieses Tools ist. 

• Netzwerkverbindungen Damit die Liste der Gruppenrichtlinienobjekte abgerufen wird und Gruppenrichtlinieneinstellungen 

ordnungsgemäß verarbeitet werden, müssen alle Computer den Active 

Directory-Domänencontroller kontaktieren können. Um einen Domänencontroller finden zu können, 

muss DNS in der Netzwerkumgebung ordnungsgemäß funktionieren. Stellen Sie sicher, dass 

Ihre Netzwerkumgebung wie erwartet funktioniert. Sorgen Sie ferner dafür, dass die Uhrzeit auf 

allen Computern synchron ist. Eine fehlende Synchronisierung kann auch die Ursache von Problemen 

bei der Gruppenrichtlinienverarbeitung sein (ebenso wie viele andere Probleme mit der Netzwerkkonnektivität).



Dieses Kapitel bildet die Grundlage für die nächsten beiden Kapitel und beschäftigte sich mit der 

Architektur und den Konfigurationsoptionen für Gruppenrichtlinien unter Windows Server 2008. In 

diesem Kapitel wurde beschrieben, wie Gruppenrichtlinienobjekte mithilfe der Konsole Gruppenrichtlinienverwaltung 

erstellt und verwaltet werden. Weiterhin wurde erklärt, wie Richtlinieneinstellungen 

vererbt und auf Benutzer- und Computerobjekte in der Active Directory-Struktur angewendet 

werden. Außerdem haben Sie erfahren, dass Sie die Standardvererbung bei der Richtlinienverarbeitung 

durch Deaktivieren oder Filtern der Vererbung ändern können. In den Kapiteln 12 und 13 wird 

erläutert, was mit Gruppenrichtlinieneinstellungen erreicht werden kann. Kapitel 12 beschäftigt sich 

damit, wie mit Gruppenrichtlinien Clientcomputer verwaltet werden. In Kapitel 13 wird erklärt, wie 

Sie mithilfe von Gruppenrichtlinien die Sicherheit in der gesamten Active Directory-Umgebung verwalten 

können. 



Kapitel. 


• In Kapitel 5, „Entwerfen der Active Directory-Domänendienstestruktur“, finden Sie Einzelheiten 

zum Planen der Active Directory-Struktur, d.h. Entwürfe für Standorte, Domänen, Organisationseinheiten 

und Gesamtstrukturen. 

• In Kapitel 9, „Delegieren der Active Directory-Domänendiensteverwaltung“, finden Sie weitere 

Einzelheiten zum Verwenden des Assistenten zum Zuweisen der Objektverwaltung zum Delegieren 

von Verwaltungsaufgaben in Active Directory. 

• „Windows Server Group Policy“ (englischsprachig) unter http://technet.microsoft.com/en-us/ 

windowsserver/grouppolicy/default.aspx 

• „Loopbackverarbeitung von Gruppenrichtlinien“ unterhttp://support.microsoft.com/?id=231287 

• „Group Policy Wiki“ (englischsprachig) unter http://grouppolicy.editme.com/ 

• „Group Policy Team Blog“ (englischsprachig) unter http://blogs.technet.com/GroupPolicy/ 

• „HOWTO: Leverage Group Policies with WMI Filters“ (englischsprachig) unter http://support.microsoft.com/kb/555253 

• „WMI Filters“ (englischsprachig) unterhttp://technet2.microsoft.com/windowsserver/en/library/ 

dfba1dc6-6848-4ed8-96da-f4241c1acfbd1033.mspx?mfr=true 

• „Scriptomatic Tool“ (englischsprachig) unter http://www.microsoft.com/technet/scriptcenter/tools/ 

wmimatic.mspx 

• „Writing WMI Scripts Using the Scriptomatic Utility“ (englischsprachig) unter http://www.micro- 

soft.com/downloads/details.aspx?displaylang=en&familyid=9ef05cbd-c1c5-41e7-9da8- 

212c414a7ab0 

• „Troubleshooting Group Policy Using Event Logs“ (englischsprachig) unter http://technet2.microsoft.com/WindowsVista/en/library/7e940882-33b7-43db-b097-f3752c84f67f1033.mspx?mfr=true 

• “„Group Policy Script Center“ (englischsprachig) unter http://www.microsoft.com/technet/scriptcenter/ 

hubs/gp.mspx


• „Introduction to Group Policy in Windows Server 2003“ (englischsprachig) unter 

http://www.microsoft.com/windowsserver2003/techinfo/overview/gpintro.mspx 

• „Microsoft IT Showcase: Group Policy Object Infrastructure Management“ (englischsprachig) 

unter http://www.microsoft.com/downloads/details.aspx?FamilyID=43090fae-e22a-4b6f-abc7- 

487a58b303a5&DisplayLang=en 

• „Administering Group Policy with Group Policy Management Console“ (englischsprachig) unter 

http://www.microsoft.com/downloads/details.aspx?familyid=D8291B79-922A-439C-88E9- 

54041A2953DD&displaylang=en 

• „Migrating GPOs Across Domains with GPMC“ (englischsprachig) unter http://www.microsoft.com/windowsserver2003/gpmc/migrgpo.mspx

449 

K A P I T E L 1 2 

Einsetzen von Gruppenrichtlinien zum 

Verwalten von Benutzerdesktops 


Desktopverwaltung mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 

Verwalten von Benutzerdaten und Profileinstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 

Administrative Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 

Verwalten der Benutzerumgebung mithilfe von Skripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 

Bereitstellen von Software mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 

Übersicht über Gruppenrichtlinieneinstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 



Einer der Hauptvorteile von Gruppenrichtlinien ist die Möglichkeit, Desktops in der Active Directory- 

Umgebung zentral zu verwalten. Bislang wurde die Gruppenrichtlinienfunktion hauptsächlich zum 

Vereinfachen von Verwaltungsaufgaben, z.B. Verwalten der Konfiguration von Windows-Komponenten, 

Implementieren von Sicherheitseinstellungen, Steuern von Benutzereinstellungen und Datenzugriff 

sowie für die Softwarebereitstellung und -wartung genutzt. Windows Server 2008 erweitert diese 

Funktionalität und bietet zusätzliche Verwaltungsoptionen durch Einführung neuer Benutzerprofilformate, 

neuer XML-basierter administrativer Vorlagendateien, verschiedener neuer und aktualisierter 

Richtlinieneinstellungen und der neuen Gruppenrichtlinienfunktion Gruppenrichtlinieneinstellungen. 

In diesem Kapitel wird erläutert, wie Sie mit Gruppenrichtlinien Desktopkonfigurationseinstellungen 

verwalten können. Ferner werden neue Features hinsichtlich Gruppenrichtlinienverwaltung und -funktionalität 

behandelt. 

Hinweis Gruppenrichtlinieneinstellungen können sowohl auf Benutzerdesktops als auch auf Server angewendet 

werden. In diesem Kapitel liegt der Schwerpunkt ausschließlich auf der Verwaltung von Benutzerdesktops 

in der Active Directory-Umgebung.

450 Kapitel 12: Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops 

0 

Vergleich zwischen der individuellen und zentralen Steuerung von Computerdesktops 

Die Verwaltung von Benutzerdesktops erfordert eine kritische Abwägung zwischen einer streng 

zentralen Steuerung von Computern und den Benutzern, die zur Anpassung ihres eigenen Desktops 

einen Vollzugriff benötigen. Wenn Sie alle in der Gruppenrichtlinienfunktion verfügbaren 

Richtlinieneinstellungen implementieren würden, könnten Sie Benutzerdesktops umfassend sperren 

und sicherstellen, dass Benutzer nur autorisierte Änderungen vornehmen. Viele Administratoren 

sind der Ansicht, dass das Bereitstellen von Möglichkeiten zum Ändern von Einstellungen für 

die Benutzer nur dazu führt, dass diese Einstellungen falsch konfigurieren, was wiederum mehr 

Arbeit für die Administratoren bedeutet. Viele Benutzer betrachten dagegen sämtliche Versuche zur 

Übernahme der Steuerung ihrer Desktops als überflüssige Einflussnahme. Aus Sicht der Benutzer 

ist der Computer ein wichtiger Teil ihrer individuellen Arbeitsumgebung, weshalb alle Versuche, 

die Verwaltung dieser Arbeitsumgebung zu übernehmen, strikt abgelehnt werden. 

Das Finden der richtigen Balance zwischen zentraler Desktopsteuerung und Steuerung durch den 

Endbenutzer erfolgt in jedem Unternehmen anders. In einigen wurden Gruppenrichtlinien ggf. in 

Active Directory-Umgebungen unter Windows 2000 und Windows Server 2003 genutzt, weshalb 

die Endbenutzer bereits an einen gewissen Grad von Desktopsteuerung gewohnt sind. In diesen 

Umgebungen können Sie neue Einschränkungen ohne große Umschweife implementieren. In anderen 

Unternehmen wurden ggf. noch keine Einschränkungen implementiert. In diesen Umgebungen 

kann der erste Versuch zur Einführung von Einschränkungen auf große Widerstände stoßen. 

Der beste Ansatz bei der Einführung der Desktopsteuerung ist ein behutsamer Start, um einen 

guten ersten Eindruck zu erwecken. Dies bedeutet in der Regel, dass Sie mithilfe von Gruppenrichtlinien 

bestimmte Problemstellungen angehen. Wenn Sie für die Endbenutzer nachvollziehbar 

machen können, dass die Desktopverwaltung ihnen die Arbeit erleichtert, werden sie diese zusätzlichen 

Verwaltungseingriffe schneller akzeptieren. Wenn Sie dagegen versuchen, die Desktopsteuerung 

einzufügen und der erste Versuch zu Hunderten von Anrufen beim Helpdesk führt, wird Ihnen 

keine Unterstützung bei der Implementierung der zentralen Desktopverwaltung gewiss sein. Ein 

weiterer wichtiger Bestandteil einer erfolgreichen Implementierung von Gruppenrichtlinien ist die 

Unterstützung durch die Unternehmensführung. In den meisten Unternehmen unterstützt die Führungsebene 

alle Anstrengungen, die zu einer Senkung der Verwaltungskosten von Arbeitsstationen 

beitragen. Wenn Sie aufzeigen können, dass das Ergebnis der Implementierung der Desktopverwaltung 

sinkende Kosten sind, können Sie mit überaus großer Wahrscheinlichkeit bei Beschwerden 

von Mitarbeitern, die nicht wollen, dass Sie ihren Desktop verwalten, auf Unterstützung seitens der 

Unternehmensführung setzen. 

Desktopverwaltung mithilfe von Gruppenrichtlinien 

Ein großer Teil einer effektiven Desktopverwaltung ist die Einführung einer Standardrichtlinie dazu, 

wie Desktops in Ihrer Active Directory-Umgebung konfiguriert werden sollen. Eine Standardisierung 

kann mithilfe verschiedener Gruppenrichtlinienfeatures erreicht werden. In der Konsole Gruppenrichtlinienverwaltung 

können Sie die verschiedenen Features und Komponenten anzeigen, die in 

einem Gruppenrichtlinienobjekt verwaltet werden können. Wenn Sie ein Gruppenrichtlinienobjekt 

bearbeiten möchten, wird das Fenster Gruppenrichtlinienverwaltungs-Editor geöffnet. Wie 

Abbildung 12.1 zeigt, ist das Fenster Gruppenrichtlinienverwaltungs-Editor in verschiedene Bereiche 

entsprechend den computer- oder benutzerbasierten Richtlinien und Einstellungen unterteilt.

Desktopverwaltung mithilfe von Gruppenrichtlinien 451 


Anzeigen der Komponenten für die Gruppenrichtlinienverwaltung 

In Tabelle 12.1 werden kurz die Container auf oberster Ebene erläutert, die im Fenster Gruppenrichtlinienverwaltungs-Editor 

angezeigt werden. 

Tabelle 12.1 

Gruppenrichtliniencontainer 

Container auf oberster Ebene Untergeordnete Container Inhalt 

Computerkonfiguration und 

Benutzerkonfiguration 

Richtlinien 

Enthält die Container Softwareeinstellungen, 

Windows-Einstellungen und Administrative Vorlagen 

zum Konfigurieren standardmäßiger 

Gruppenrichtlinieneinstellungen. 







Richtlinien\Softwareeinstellungen 

Richtlinien\Windows-Einstellungen\ 

Skripts 


Sicherheitseinstellungen 

Enthält die Konfiguration für zu verteilende Softwarepakete. 

Enthält die Skripts zum Starten und Herunterfahren 

von Computern und An- und Abmelden 

von Benutzern. 

Enthält die Einstellungen zum Konfigurieren der 

Computersicherheit. Einige Einstellungen gelten 

spezifisch auf Domänenebene, andere können 

auf Containerebene festgelegt werden. Die 

meisten Sicherheitseinstellungen werden unter 

Computerkonfiguration festgelegt.


Tabelle 12.1 

Gruppenrichtliniencontainer (Fortsetzung) 

Container auf oberster Ebene Untergeordnete Container Inhalt 















Richtlinienbasierter QoS 




Remoteinstallationsdienste 


Internet Explorer-Wartung 

Richtlinien\Administrative Vorlagen 

Einstellungen 

Enthält die Einstellungen zum Konfigurieren benutzer- 

oder computerbasierter Datenverkehrspriorisierungen 

und -einschränkungen für 

bestimmte Anwendungen, IP-Adressen, Protokolle 

und Ports. 

Enthält Einstellungen zum Umleiten von Benutzerordnern, 

z.B. des Ordners Dokumente, zu 

einer Netzwerkfreigabe. 

Enthält eine einzelne Konfigurationsoption für 

die Remoteinstallationsdienste. 

Enthält Einstellungen zum Verwalten der Konfiguration 

von Microsoft Internet Explorer auf 

Benutzerdesktops. 

Enthält viele Konfigurationseinstellungen zum 

Konfigurieren der Registrierung auf Zielcomputern. 

Ermöglicht die Konfiguration von Windows- und 

Systemsteuerungseinstellungen. 

Enthält Einstellungen für Windows-Konfigurationen, 

z.B. Umgebungsvariablen, Verknüpfungen, 

Registrierungs- und INI-Dateien, 

Laufwerkzuordnungen (nur Benutzer), Anwendungseinstellungen 

(nur Benutzer) sowie viele 

andere Einstellungen. 

Enthält Einstellungen für die Windows- 

Systemsteuerung, z.B. zum Steuern von lokalen 

Benutzern und Gruppen, Energieverwaltungsoptionen, 

Druckern, Ordneroptionen und 

vielen weiteren Einstellungen. 

Einstellungen\Windows- 

Einstellungen 

Einstellungen\Systemsteuerungseinstellungen 

Der Rest dieses Kapitels bietet Details zu vielen dieser übergeordneten Container. 

Verwalten von Benutzerdaten und Profileinstellungen 

Eine häufig anspruchsvolle Aufgabe vieler Netzwerkadministratoren ist die Verwaltung von Benutzerdaten 

und Profileinstellungen. Endbenutzer erwarten zumeist, dass ihre Computerumgebung unabhängig 

davon, wie und wann sie sich am Netzwerk anmelden, immer gleich aussieht und dass ihre 

Daten zur Verfügung stehen, wenn sie diese benötigen. 

Die Daten, mit denen Benutzer arbeiten, sind oft geschäftswichtig und müssen ordnungsgemäß abgesichert 

und verwaltet werden. In vielen Fällen werden Unternehmensdaten zentral in freigegebenen 

Netzwerkordnern gespeichert und regelmäßig gesichert. Die Benutzer werden aufgefordert, alle 

Unternehmensdaten in diesen freigegebenen Ordnern zu speichern. Doch bei steigender Mobilität der 

Mitarbeiterschaft speichern viele Benutzer Daten auch lokal auf ihren tragbaren Computern, um 

Zugriff darauf zu haben, wenn sie nicht mit dem Netzwerk verbunden sind.

Verwalten von Benutzerdaten und Profileinstellungen 453 

Die Verwaltung von Benutzerprofilen beschäftigt Endbenutzer meist mehr als Administratoren. 

Einige Benutzer wenden recht viel Zeit auf, um Anwendungen und Desktop ihren Vorstellungen entsprechend 

zu konfigurieren. Für diese Benutzer sind ihre persönlichen Einstellungen wichtig, und sie 

möchten, dass unabhängig davon, an welchem Computer sie sich anmelden, die Desktopkonfiguration 

stets identisch ist. Um dies zu ermöglichen, haben viele Unternehmen servergespeicherte Benutzerprofile 

eingeführt, bei denen das Benutzerprofil in einer Netzwerkfreigabe gespeichert wird, auf 

die von allen Computern in der Domäne aus zugegriffen werden kann. Um standardisierte Desktopkonfigurationen 

zu erreichen, legen einige Unternehmen ihren Benutzerprofilen Einschränkungen 

auf, indem verbindliche Profile implementiert werden. Bei einem verbindlichen Profil kann ein Administrator 

ein Standardprofil für einen Benutzer oder eine Benutzergruppe erstellen und das Profil 

anschließend so konfigurieren, dass die Benutzer keine Änderungen am Profil speichern können. Dies 

gewährleistet, dass die IT-Umgebung für alle Benutzer einheitlich bleibt, denen ein bestimmtes Profil 

zugewiesen ist. 

Servergespeicherte und verbindliche Benutzerprofile können mithilfe von Active Directory eingeführt 

werden, und einige der Einstellungen zu deren Steuerung können mithilfe von Gruppenrichtlinien 

konfiguriert werden. Zusätzlich zu Benutzerprofilen bietet Active Directory Funktionen für die 

Ordnerumleitung und Offlinedateien, um die Verwaltung von Benutzerdaten und -einstellungen zu 

optimieren. Die Ordnerumleitung bietet einige signifikante Vorteile bei der Verwaltung von Größe 

und Verfügbarkeit bestimmter herkömmlicher Ordner in Benutzerprofilen, während Offlinedateien 

von Nutzen für mobile Benutzer sind, die vom Netzwerk getrennt sind. 

Verwalten von Benutzerprofilen 

Windows Server 2008 und Windows Vista zeichnen sich bei durch wesentliche Änderungen an der 

Struktur von Benutzerprofilen aus. Diese Änderungen müssen sorgfältig berücksichtigt werden, wenn 

servergespeicherte Benutzerprofile in einer heterogenen Umgebung mit Computern mit Windows 

Server 2008, Windows Vista und früheren Windows-Versionen bereitgestellt werden. 

Ein Benutzerprofil enthält Informationen, die der Struktur HKEY_CURRENT_USER in der Registrierung 

zugeordnet sind, und wird am Stamm des Benutzerprofilordners als NTUSER.DAT gespeichert. 

Diese Datei dient der Verwaltung verschiedener Informationstypen wie Anwendungs- und Desktopkonfigurationseinstellungen. 

Ein Benutzerprofil enthält ferner verschiedene sichtbare und ausgeblendete 

Ordner, in denen Informationen wie Anwendungseinstellungen, die Konfiguration des Menüs 

Start und des Desktops und verschiedene Ordnertypen für persönliche Daten gespeichert werden. 

Abbildung 12.2 zeigt den Inhalt eines Benutzerprofils auf einem Server mit Windows Server 2008. 

In früheren Windows-Versionen wurden Benutzerprofile im Ordner Dokumente und Einstellungen 

gespeichert. Unter Windows Server 2008 heißt dieser Ordner nun Benutzer. Im Benutzerprofilordner 

wurden viele Namen und Pfade bestimmter profilbezogener Ordner ebenfalls geändert. In 

Tabelle 12.2 finden Sie die Unterschiede zwischen früheren Windows-Versionen und Windows 

Server 2008. 

Hinweis 

Die für Windows Server 2008 genannten Profiländerungen gelten auch für Windows Vista. 

Zusätzlich zu den Standardprofilordnern gibt es verschiedene ausgeblendete Ordner mit Verknüpfungspfeilen 

(siehe Abbildung 12.2). Diese Verknüpfungspunkte genannten Ordner werden von 

älteren Anwendungen zum Auflösen des Speicherortes der in früheren Windows-Versionen verwendeten 

allgemeinen Ordner verwendet und sind in Tabelle 12.3 beschrieben.



Das Benutzerprofil enthält sämtliche Benutzerdesktopeinstellungen und Ordner für Benutzerdaten 

Tabelle 12.2 

Vergleichen von Profilordnern zwischen Windows-Versionen 

Windows Server 2008/ 

Vista 

Windows 2003/ 

XP 

Beschreibung 

AppData – Dieser ausgeblendete Ordner dient als Standardspeicherort für Benutzeranwendungsdaten 

und enthält die folgenden Ordner: 

Local: Dient zum Speichern computerund benutzerspezifischer Anwendungseinstellungen, 

die bei Implementierung servergespeicherter Profile nicht 

auf dem Server gespeichert werden sollen. 

Roaming: Dient zum Speichern von Anwendungsdaten und -einstellungen, 

die bei Implementierung servergespeicherter Profile auf dem Server gespeichert 

werden sollen. 

LocalLow: Dient zum Speichern von Daten und Einstellungen für Prozesse 

mit niedriger Integritätsebene, z.B. der geschützte Modus in Internet Explorer. 

Diese Daten werden bei Implementierung servergespeicherter Profile 

nicht auf dem Server gespeichert.


Tabelle 12.2 

Vergleichen von Profilordnern zwischen Windows-Versionen (Fortsetzung) 

Windows Server 2008/ 

Vista 

Windows 2003/ 

XP 

Beschreibung 

Kontakte – Dies ist der Standardspeicherort für Benutzerkontakte. 

Desktop Desktop Dient zum Speichern von Elementen, die auf dem Desktop angezeigt werden, 

z.B. Verknüpfungen und Dateien. 

Dokumente Eigene Dateien Dies ist der Standardspeicherort für alle vom Benutzer erstellten Dokumente. 

Downloads – Dies ist der Standardspeicherort für alle vom Benutzer heruntergeladenen 

Dateien. 

Favoriten – Internet Explorer-Favoriten. 

Links – Internet Explorer-Linkfavoriten. 

Musik Eigene Musik Standardspeicherort für vom Benutzer gespeicherte Musikdateien. 

Bilder Eigene Bilder Standardspeicherort für vom Benutzer gespeicherte Bilddateien. 

Gespeicherte Spiele – Standardspeicherort für vom Benutzer gespeicherte Spiele. 

Suchen – Standardspeicherort für gespeicherte Suchen. 

Videos Eigene Videos Standardspeicherort für vom Benutzer gespeicherte Videos. 

Tabelle 12.3 

Windows Server 2008-Verknüpfungspunkte 

Verknüpfungspunkt 

Anwendungsdaten 

Cookies 

Lokale Einstellungen 

Eigene Dateien 

Netzwerkumgebung 

Druckumgebung 

Recent 

SendTo 

Menü Start 

Vorlagen 

Zeigt auf neuen Speicherort unter Windows Server 2008/Vista 

.. \AppData\Roaming 

.. \AppData\Roaming\Microsoft\Windows\Cookies 

…\AppData\Local 

…\AppData\Local\Microsoft\Windows\History 

…\AppData\Local\Temp 

…\AppData\Local\Microsoft\Windows\Temporary Internet Files 

...\Documents 

…\AppData\Roaming\Microsoft\Windows\Network Shortcuts 

…\AppData\Roaming\Microsoft\Windows\Printer Shortcuts 

…\AppData\Roaming\Microsoft\Windows\Recent 

…\AppData\Roaming\Microsoft\Windows\Send To 

…\AppData\Roaming\Microsoft\Windows\Start Menu 

…\AppData\Roaming\Microsoft\Windows\Templates 

Die neue Ordnerstruktur bietet ein übersichtlicheres und logischeres Format, aus dem Zweck und 

Funktion jedes Ordners eindeutig hervorgeht. Die neue Struktur optimiert ferner Aufgaben bei der 

Ordnerumleitung, indem die Menge der mit servergespeicherten Profilen übertragenen Daten minimiert 

wird.


So funktioniert es: Verknüpfungspunkte und ihre Ziele 

Die neue Ordnerstruktur für Benutzerprofile mit servergespeicherten Profilen der Version 2 unter 

Windows Server 2008 und Windows Vista vereinfacht das Auffinden von Benutzerdaten. Doch 

Anwendungen, die vor Windows Server 2008 und Windows Vista entwickelt wurden, enthalten 

ggf. hart codierte Namen in der Ordnerstruktur, die vor Windows Server 2008 und Windows Vista 

verwendet wurde. Profilentwickler haben vorausschauend versucht, Probleme bei der Kompatibilität 

von Anwendungen zwischen Benutzerprofilen der Versionen 1 und 2 abzufedern, indem Verknüpfungspunkte 

mit den Namen von Benutzerdatenordnern in früheren Windows-Versionen 

erstellt wurden. 

Verknüpfungspunkte sehen in Windows Explorer wie Ordner aus. Sie enthalten jedoch eigentlich 

einen Link, der die Dateianforderung an eine andere Stelle auf der Festplatte umleitet. Verknüpfungspunkte 

ermöglichen Anwendungen, die mit früheren Namen von Benutzerdatenordner arbeiten, 

das Schreiben von Daten in Ordner, welche die neuen Namen von Benutzerdatenordnern in 

Benutzerprofilen der Version 2 verwenden. Windows Server 2003 und Windows XP verwenden 

beispielsweise beide Benutzerprofile der Version 1. Der Ordner Eigene Dateien ist einer der Benutzerdatenordner 

im Benutzerprofil der Version 1. Windows Server 2008 und Windows Vista (mit 

Benutzerprofilen der Version 2) verwenden jedoch den Ordner Dokumente als Gegenstück des 

Benutzerdatenordners Eigene Dateien. Windows Server 2008 erstellt einen ausgeblendeten Verknüpfungspunkt 

in Benutzerprofilen der Version 2 mit dem Namen Eigene Dateien. Das Ziel des 

Verknüpfungspunkts Eigene Dateien ist der Speicherort des neuen Benutzerdatenordners Dokumente. 

Eine Anwendung, die spezifisch für das Schreiben von Daten in den Ordner Eigene Dateien 

erstellt wurde, würde unter Windows Vista fehlschlagen, gäbe es nicht den Verknüpfungspunkt, der 

den Dateivorgang zum ordnungsgemäßen Benutzerdatenordner umleitet. 

Sie können die Verknüpfungpunkte in Benutzerprofilen der Version 2 durch Eingeben von Dir an 

der Eingabeaufforderung anzeigen. Öffnen Sie dazu eine Eingabeaufforderung. Das Eingabeaufforderungsfenster 

wird im Benutzerprofilordner des aktuell angemeldeten Benutzers geöffnet. Geben 

Sie Dir /al ein, und drücken Sie die EINGABETASTE. Windows zeigt die Liste der ausgeblendeten 

Verknüpfungspunkte im Benutzerprofilordner und deren Zielspeicherorte an. 

Mike Stephens 

Support Escalation Engineer 

Funktionsweise lokaler Profile 

Ein lokales Profil wird standardmäßig auf jedem Computer erstellt, wenn sich ein Benutzer erstmals 

an dem Computer anmeldet. Das Anfangsprofil basiert auf dem versteckten Profil Default, das im 

Ordner %SystemDrive%\Benutzer gespeichert wird. Wenn ein Computer einer Domäne beitritt, prüft 

er zuerst, ob eine Netzwerkversion des Standardbenutzerprofils vorhanden ist, die in der Freigabe 

NETLOGON von Domänencontrollern enthalten ist. 

Wenn sich der Benutzer abmeldet, werden sein Profil sowie etwaige Änderungen daran in einem Ordner 

gespeichert, dessen Name dem Anmeldenamen des Benutzers im Ordner Benutzer entspricht. 

Wenn sich der Benutzer nochmals am selben Computer anmeldet, wird das Profil abgerufen und dem 

Benutzer derselbe Desktop angezeigt, der bei der Abmeldung gespeichert wurde. Benutzerprofile sind 

mit der Sicherheits-ID des Benutzers verknüpft. Aus diesem Grund wird bei zwei Benutzern mit demselben 

Anmeldenamen nicht dasselbe Profil geladen. Jedem Benutzer wird ein eigenes Profil zugewiesen.


Der Hauptvorteil eines lokalen Profils ist, dass jeder Benutzer, der sich an dem Computer anmeldet, 

seine persönlichen Einstellungen behält. Benutzer, die wechselweise an mehreren Arbeitsstationen 

tätig sind, müssen hingegen mit mehreren Profilen arbeiten, die getrennt auf jeder einzelnen Arbeitsstation 

gespeichert werden. Um dieses Problem in den Griff zu bekommen, arbeiten viele Unternehmen 

mit servergespeicherten Benutzerprofilen. 

Funktionsweise servergespeicherter Profile 

Servergespeicherte Benutzerprofile werden in einer Netzwerkfreigabe gespeichert, damit das Profil 

zur Verfügung steht, wenn der Benutzer an mehreren Arbeitsstationen arbeitet. Aufgrund der Änderungen 

an der Profilordnerstruktur unter Windows Server 2008 und Windows Vista müssen bei der 

Implementierung servergespeicherter Profile in einer heterogenen Umgebung bestimmte Aspekte 

berücksichtigt werden. Denn für Clients mit Windows Vista oder Windows Server 2008 erstellte servergespeicherte 

Profile sind nicht mit servergespeicherten Profilen für Windows XP und Windows 

Server 2003 kompatibel. 

Hinweis Windows Vista und Windows Server 2008 können Windows XP- und Windows 2003-Benutzerprofile 

der Version 1 nicht lesen. Dies ist im Vergleich zu früher, als das neuere Betriebssystem die servergespeicherten 

Profile des älteren Betriebssystems lesen konnte und einfache Updates möglich waren, ein 

wesentlicher Unterschied. Bei Benutzerprofilen der Version 2 ist dies nicht mehr möglich. 

Wenn sich ein Benutzer, der sich mit einem unter Windows Server 2008/Windows Vista servergespeicherten 

Profil erstmals an einem Computer anmeldet, wird ein Standardprofil basierend auf einem von 

zwei Elementen generiert und auf den Computer angewendet: 

• Einem vorkonfigurierten Benutzerprofil in der Freigabe NETLOGON Wenn Sie ein Standardbenutzerprofil 

wünschen, das bereits mit bestimmten Voreinstellungen vorkonfiguriert ist, können Sie auf 

einem Computer mit Windows Server 2008 oder Windows Vista ein Benutzerprofil mit eindeutigen 

Benutzereinstellungen wie Hintergrundfarben, Bildschirmschoner und Desktopeinstellungen 

konfigurieren. Sie können dieses Profil anschließend in den Ordner Default User.v2 der 

Freigabe NETLOGON eines Domänencontrollers kopieren. Das Suffix v2 bedeutet, dass es sich 

um ein unter Windows Vista und Windows Server 2008 verwendetes Benutzerprofil der Version 2 

handelt. 

• Dem lokalen Standardprofil Falls der Ordner Default User.v2 nicht in der Freigabe NETLOGON 

vorhanden oder der Computer keiner Domäne beigetreten ist, wird das lokale Standardprofil als 

Ausgangsprofil des Benutzers verwendet. 

Wenn sich der Benutzer abmeldet, werden die Änderungen am Benutzerprofil ausgewertet und zurück 

in die Netzwerkfreigabe NETLOGON kopiert. Eine Kopie des Profils wird außerdem standardmäßig 

auf der lokalen Arbeitsstation gespeichert. Wenn sich ein Benutzer zuvor an einer Arbeitsstation 

angemeldet hat, wird der Zeitstempel der lokalen Arbeitsstation mit dem Zeitstempel des Profils 

verglichen, das in der Netzwerkfreigabe NETLOGON gespeichert ist. Der Zeitstempel für einzelne 

Dateien dient zum Bestimmen, welche Dateien im Profil neuer sind. Ist das Profil auf dem Server 

neuer als das lokale Profil, wird das gesamte Profil vom Server auf die lokale Arbeitsstation kopiert. 

Konfigurieren servergespeicherte Profile 

Zum Konfigurieren servergespeicherter Profile müssen Sie einen Netzwerkspeicherort einrichten, an 

dem die einzelnen Benutzerprofile gespeichert werden sollen. Als Nächstes müssen Sie die einzelnen 

Benutzerkonten mit einer Zuordnung zu diesem Netzwerkspeicherort konfigurieren, damit das jeweilige 

Profil abgerufen wird und Änderungen daran gespeichert werden.


Führen Sie zum Konfigurieren servergespeicherter Benutzerprofile die folgenden Schritte aus: 

1. Erstellen Sie auf einem Datei- oder Profilserver für die Speicherung servergespeicherter Profile 

einen freigegebenen Ordner. In vielen Fällen wird der Ordner Profile genannt. 

2. Geben Sie den Ordner so frei, dass die Gruppe Authentifizierte Benutzer die Berechtigung Vollzugriff 

für die Freigabe hat. Dies stellt sicher, dass sowohl Computer als auch Benutzer auf diese 

Freigabe zugreifen können, um den Anforderungen entsprechend Profilordner zu erstellen. Sie 

müssen ferner sicherstellen, dass in den lokalen (NTFS-) Berechtigungen für die Gruppe Benutzer 

die Berechtigungen Zulassen: Ändern festgelegt sind. 

3. Erstellen Sie optional ein Standardnetzwerkprofil, und speichern Sie es in der Freigabe NET- 

LOGON auf einem Domänencontroller. Der Ordner, in dem das benutzerdefinierte Profil gespeichert 

wird, muss den Namen Default User.v2 tragen. Die Gruppe Jeder benötigt Vollzugriff auf 

das Standardbenutzerprofil. Wenn Sie kein Standardnetzwerkprofil erstellen, wird stattdessen das 

Profil %SystemRoot%\Users\Default verwendet. 

4. In der Konsole Active Directory-Benutzer und -Computer können Sie den Profilpfad für jeden 

Benutzer konfigurieren, der das servergespeicherte Profil nutzen soll. Wie Abbildung 12.3 zeigt, 

müssen Sie den Server und freigegebenen Ordner angeben, in dem die Profile gespeichert werden. 

Sie können auch die Umgebungsvariable %UserName% als Platzhalter für den im Profilpfad 

angegebenen Anmeldenamen verwenden. Nachdem sich der Benutzer angemeldet hat, wird der 

Profilordner automatisch im Benutzername.v2-Format erstellt, und die entsprechenden Berechtigungen 

werden automatisch zugewiesen. 


Konfigurieren eines servergespeicherten Benutzerprofils


Verbindliche und „superverbindliche“ Profile 

Verbindliche Profile werden in Kombination mit servergespeicherten Profilen zum Erstellen einer 

gespeicherten Standarddesktopkonfiguration für eine Benutzergruppe genutzt. Angenommen, Sie 

haben eine Gruppe von Benutzern, die alle dieselben Aufgaben ausführen und nur eine sehr begrenzte 

Desktopkonfiguration benötigen. Sie können einen Standarddesktop für diese Benutzergruppe erstellen 

und mit verbindlichen Profilen arbeiten, um die Benutzer am Ändern der Konfiguration zu 

hindern. Um verbindliche Profile zu aktivieren, müssen Sie zuerst das standardmäßige servergespeicherte 

Benutzerprofil erstellen und über die Registerkarte Profile im Dialogfeld Computereigenschaften 

das Profil in die Freigabe NETLOGON kopieren und für die Profilnutzung die entsprechenden 

Berechtigungen zuweisen. Anschließend müssen Sie die Datei NTUSER.DAT in 

NTUSER.MAN umbenennen und als schreibgeschützt konfigurieren. Schließlich müssen Sie alle vorgesehenen 

Benutzer für die Verwendung dieses Profils als servergespeichertes Benutzerprofil einrichten. 

Wenn sich ein mit dem verbindlichen Profil konfigurierter Benutzer am Netzwerk anmeldet, wird 

das Profil angewendet. Da es als verbindliches Profil konfiguriert ist, werden Änderungen am Profil 

bei der Abmeldung des Benutzers nicht im Profilserver gespeichert. 

Hinweis Für Ordner für die Speicherung verbindlicher Profile müssen Freigabeberechtigungen gelten, die 

der Gruppe Authentifizierte Benutzer die Berechtigung Lesen und der Gruppe Administratoren die Berechtigung 

Vollzugriff zuweisen. 

Wenn ein servergespeichertes Profil bzw. verbindliches Benutzerprofil aufgrund von Netzwerkproblemen 

nicht verfügbar ist, erstellt Windows normalerweise basierend auf dem standardmäßigen Netzwerk- 

oder lokalen Profil ein temporäres Profil, das bei der Abmeldung des Benutzers gelöscht wird. 

Wenn jedoch angefordert wird, dass verbindliche Profile stets zu verwenden sind, wird die Anmeldung 

nicht zugelassen, wenn die Profile nicht verfügbar sind. Hierfür müssen Sie ein sogenanntes 

„superverbindliches“ Profil erzeugen. Superverbindliche Profile lassen die Benutzeranmeldung an 

einer Arbeitsstation nicht zu, wenn das servergespeicherte Profil nicht verfügbar ist. Dies kann die 

Sicherheit der Arbeitsstation weiter verbessern, aber auch zu erhöhtem Aufwand bei der Fehlerbehebung 

und einem Verlust an Benutzerproduktivität führen, wenn ein Benutzer nicht auf das servergespeicherte 

Profil zugreifen kann. 

Führen Sie zum Konfigurieren superverbindlicher servergespeicherter Benutzerprofile die folgenden 

Schritte aus: 

1. Erstellen Sie, wie zuvor erklärt, ein verbindliches Benutzerprofil. 

2. Verbinden Sie sich mit der Netzwerkfreigabe, in der der Benutzerprofilordner gespeichert ist. 

Benennen Sie den Benutzerordner, der ein superverbindliches Benutzerprofil enthalten soll, durch 

Hinzufügen von .man.v2 am Ende des Ordnernamens um. 

3. In der Konsole Active Directory-Benutzer und -Computer können Sie den Profilpfad für jeden 

Benutzer konfigurieren, der das superverbindliche servergespeicherte Profil nutzen soll. Fügen 

Sie .man am Ende des Profilpfads hinzu. Der Pfad in Abbildung 12.3 würde dann \\SEA-DC1\ 

Profiles\Don.man lauten. 

Mit einem superverbindlichen Benutzerprofil konfigurierte Benutzer können keine Einstellungen auf 

den Profilserver zurückspeichern. Darüber hinaus lässt Windows nicht die Benutzeranmeldung am 

Computer zu, wenn das verbindliche Benutzerprofil nicht geladen werden kann.


Einsetzen von Gruppenrichtlinien zum Verwalten servergespeicherter 


Mithilfe von Gruppenrichtlinien können Sie viele Aspekte von Benutzerprofilen verwalten. Beim 

Bearbeiten eines domänenbasierten Gruppenrichtlinienobjekts finden Sie Benutzerprofileinstellungen 

an folgenden Stellen: 

• Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Benutzerprofile 

• Benutzerkonfiguration\Richtlinien\Administrative Vorlagen\System\Benutzerprofile 

In Tabelle 12.4 werden die Konfigurationsoptionen an diesen beiden Stellen erläutert. 

Tabelle 12.4 

Konfigurieren von Benutzerprofilen mithilfe von Gruppenrichtlinieneinstellungen 

Richtlinieneinstellung 

Sicherheitsgruppe Administratoren zu 

servergespeicherten Profilen hinzufügen 

Benutzerprofile, die älter als eine bestimmte 

Anzahl von Tagen sind, beim 

Systemneustart löschen 

Eigentümer von servergespeicherten 

Profilen nicht prüfen 

Zwischengespeicherte Kopien von servergespeicherten 

Profilen löschen 

Die Registrierung der Benutzer bei der 

Benutzerabmeldung nicht zwangsweise 

entladen 

Langsame Netzwerkverbindungen nicht 

erkennen 

Erläuterung 

Über diese Option können Sie die Sicherheitsgruppe Administratoren zur Profilfreigabe 

des servergespeicherten Benutzerprofils hinzufügen und die Berechtigung 

Vollzugriff erteilen. Ist diese Einstellung nicht konfiguriert bzw. deaktiviert, hat nur 

der Benutzer Vollzugriff auf sein Profil (Standardeinstellung). Diese Einstellung 

muss vor Erstellung des Profils aktiviert werden. Wird sie anschließend aktiviert, 

hat sie keine Auswirkung. 

Hinweis: Diese Einstellung muss auf dem Clientcomputer, nicht auf dem Profilserver 

konfiguriert werden. Der Clientcomputer legt die Dateifreigabeberechtigungen 

für das servergespeicherte Profil zum Zeitpunkt der Erstellung fest. 

Diese Windows Vista-Einstellung ermöglicht das automatische Löschen von Windows 

Vista-Clientbenutzerprofilen, die eine angegebene Anzahl von Tagen nicht 

genutzt wurden, beim Neustart des Systems. 

Über diese Option können Sie die auszuführende Aktion bestimmen, wenn ein servergespeicherter 

Benutzerprofilordner bereits vorhanden ist und die Arbeitsstationen 

auf Microsoft Windows 2000 Service Pack 4 oder Microsoft Windows XP 

Professional Service Pack 1 aktualisiert wurden. Diese aktuellen Service Packs 

verbessern die Standardsicherheitseinstellungen für die Benutzerprofile. Durch 

Aktivieren dieser Option bleiben die früheren Sicherheitseinstellungen erhalten. 

Aktivieren Sie diese Option, um die lokale zwischengespeicherte Kopie des servergespeicherten 

Benutzerprofils bei Abmeldung des Benutzers zu löschen. Aktivieren 

Sie diese Option nicht, wenn Sie mit der Windows 2000- oder Windows XP 

Professional-Funktion zur Erkennung langsamer Verbindungen arbeiten, da diese 

eine lokale zwischengespeicherte Kopie des Benutzerprofils benötigt. 

Unter Windows Vista wird die Registrierung des Benutzers bei der Benutzerabmeldung 

zwangsweise entladen. Diese Richtlinieneinstellung kann Windows daran 

hindern. Diese Einstellung darf nur aktiviert werden, um Probleme bei der Kompatibilität 

von Anwendungen im Zusammenhang mit diesem Standardverhalten zu 

beheben. 

Bei Aktivierung dieser Option arbeitet der Computer bei der Konfiguration der Verwaltung 

servergespeicherter Benutzerprofile nicht mit der Erkennung langsamer 

Verbindungen. Wenn Sie diese Option aktivieren, werden servergespeicherte Benutzerprofile 

unabhängig von der Netzwerkgeschwindigkeit stets heruntergeladen.


Tabelle 12.4 

Konfigurieren von Benutzerprofilen mithilfe von Gruppenrichtlinieneinstellungen (Fortsetzung) 


Benutzer bei langsamer Netzwerkverbindung 

zum Bestätigen auffordern 

Windows Installer- und Gruppenrichtliniensoftware-Installationsdaten 

belassen 

Nur lokale Benutzerprofile zulassen 

Pfad des servergespeicherten Profils für 

alle Benutzer festlegen, die sich an 

diesem Computer anmelden 

Zeitlimit für Dialogfelder 

Benutzer mit temporären Profilen nicht 

anmelden 

Maximale Wiederholungsversuche zum 

Entladen und Aktualisieren des Benutzerprofils 

Erläuterung 

Aktivieren Sie diese Option, um dem Benutzer anzuzeigen, dass eine langsame 

Netzwerkverbindung erkannt wurde, und ihm eine Wahlmöglichkeit zu geben, entweder 

das lokale oder das Serverprofil zu laden. Wird diese Option nicht aktiviert, 

wird das lokale Profil ohne Nachfrage beim Benutzer geladen. 

Beim Löschen eines Benutzerprofils werden alle profilbezogenen Informationen 

wie Benutzererstellungen, Daten, Windows Installer-Informationen und Installationsdaten 

der Gruppenrichtliniensoftware standardmäßig gelöscht. Wenn sich ein 

Benutzer anschließend an dem Computer anmeldet, dessen Profil zuvor gelöscht 

wurde, müssen alle über Gruppenrichtlinien installierte Anwendungen erneut installiert 

werden. Bei Aktivierung dieser Richtlinieneinstellung löscht Windows beim 

Löschen eines servergespeicherten Benutzerprofils nicht die Windows Installer- 

Daten und Installationsdaten der Gruppenrichtliniensoftware. Dies optimiert die 

Systemleistung und verkürzt die Anmeldedauer, wenn sich ein Benutzer später an 

dem Computer anmeldet. 

Aktivieren Sie diese Option, um zu bestimmen, ob servergespeicherte Benutzerprofile 

auf einem bestimmten Computer verfügbar sein sollen. Wenn Sie diese 

Option aktivieren, wird das servergespeicherte Benutzerprofil nicht angewendet 

und nur das lokale Profil genutzt. 

Über diese Richtlinieneinstellung können Sie einen Netzwerkpfad angeben, um auf 

servergespeicherte Profile für alle Benutzer zuzugreifen, die sich an einem bestimmten 

Computer anmelden. Der Pfad muss das Format \\Computername\ 

Freigabename\%USERNAME% aufweisen. Wichtig ist der Hinweis, dass es vier 

Möglichkeiten gibt, ein servergespeichertes Profil für einen Benutzer zu konfigurieren. 

Dabei wird folgende Reihenfolge beachtet und die erste konfigurierte Einstellung 

verwendet: 

1. Pfad eines servergespeicherten Terminaldiensteprofils, der von einer Terminaldienste-Richtlinieneinstellung 

angegeben wird 

2. Pfad eines servergespeicherten Terminaldiensteprofils, der in den Eigenschaften 

des Benutzerobjekts angegeben wird 

3. Pfad eines computerbezogenen servergespeicherten Profils, der in dieser 

Richtlinieneinstellung angegeben wird 

4. Pfad eines benutzerbezogenen servergespeicherten Profils, der in den Eigenschaften 

des Benutzerobjekts angegeben wird 

Über diese Option können Sie festlegen, wie lange das System warten soll, nachdem 

der Benutzer informiert wurde, dass eine langsame Netzwerkverbindung 

erkannt wurde. Wenn das Zeitlimit überschritten werden darf, werden der Standardwert 

bzw. die Standardaktion des Dialogfelds angewendet. 

Diese Richtlinieneinstellung sorgt automatisch für eine Abmeldung von Benutzern, 

wenn Windows ihr Profil nicht laden kann. Wenn Windows nicht auf den Benutzerprofilordner 

zugreifen oder das Profil nicht gefunden werden kann, erlaubt Windows 

dem Benutzer standardmäßig die Anmeldung mit einem temporären 

Benutzerprofil. 

Legen Sie über diese Einstellung fest, wie oft das System versuchen soll, die Datei 

NTUSER.DAT zu aktualisieren, wenn sich der Benutzer abmeldet und die Aktualisierung 

fehlschlägt. Standardmäßig versucht das System, die Datei einmal alle 

60 Sekunden zu aktualisieren.


Tabelle 12.4 

Konfigurieren von Benutzerprofilen mithilfe von Gruppenrichtlinieneinstellungen (Fortsetzung) 


Propagierung von Änderungen an servergespeicherten 

Profilen auf den Server 

verhindern 

Remotebenutzerprofil abwarten 

Zeitlimit für langsame Verbindungen für 


Maximale Wartezeit für das Netzwerk 

festlegen, wenn ein Benutzer über ein 

servergespeichertes Benutzerprofil oder 

ein Remotestammverzeichnis verfügt 

Basisverzeichnis mit dem Freigabestamm 

verbinden (unter Benutzerkonfiguration) 

Nur bei der An-/Abmeldung zu synchronisierende 

Netzwerkverzeichnisse 

(unter Benutzerkonfiguration) 

Verzeichnisse aus servergespeichertem 

Profil ausschließen (unter Benutzerkonfiguration) 

Profilgröße beschränken (unter Benutzerkonfiguration) 

Erläuterung 

Über diese Option können Sie bestimmen, was passieren soll, wenn sich der Benutzer 

vom Computer abmeldet. Ist diese Option aktiviert, wird das servergespeicherte 

Profil auf dem Server bei Abmeldung des Benutzers nicht aktualisiert. 

Aktivieren Sie diese Option, damit das servergespeicherte Benutzerprofil stets vom 

Server geladen wird. Bei Aktivierung dieser Option lädt die Arbeitsstation das Benutzerprofil 

auch dann, wenn eine langsame Netzwerkverbindung erkannt wird. 

Aktivieren Sie diese Option, um eine langsame Netzwerkverbindung zu bestimmen. 

Wenn Sie diese Option aktivieren, beträgt die Standarddefinition einer langsamen 

Netzwerkverbindung weniger als 500 KBit/s und für Nicht-IP-Computer 

120 Millisekunden, bis der Server reagiert. 

Wenn der Benutzer ein servergespeichertes Benutzerprofil oder Remotestammverzeichnis 

hat und das Netzwerk nicht verfügbar ist, wartet Windows 30 Sekunden 

ab. Steht das Netzwerk nach Ablauf der maximalen Wartezeit nicht zur Verfügung, 

wird der Benutzer ohne Netzwerkverbindung angemeldet. Sie können die standardmäßige 

Wartezeit mithilfe dieser Richtlinie ändern, was bei langsameren Verbindungen 

wie drahtlosen Verbindungen nützlich sein kann. 

Bei Aktivierung dieser Option ist das Stammverzeichnis aller Benutzer die Netzwerkfreigabe, 

in der sich die Stammordner der Benutzer befinden. Wenn Sie die 

Option nicht aktivieren (Standardeinstellung), werden die Stammlaufwerke dem 

benutzerbezogenen Ordner und nicht der übergeordneten Freigabe zugeordnet. 

Über diese Richtlinieneinstellung können Sie angeben, welche Netzwerkverzeichnisse 

nur bei der An- und Abmeldung mithilfe von Offlinedateien synchronisiert 

werden. 

Wählen Sie diese Option aus, um zu verhindern, dass angegebene Benutzerverzeichnisse 

in das servergespeicherte Benutzerprofil einbezogen werden. 

Über diese Option können Sie die maximale Größe des servergespeicherten Profils 

eines Benutzers festlegen. Außerdem können Sie hiermit bestimmen, welche 

Eingabeaufforderung dem Benutzer angezeigt wird, wenn der Profilspeicherplatz 

überschritten wird. 


Bei einem servergespeicherten Profil ist die Arbeitsumgebung des Benutzers unabhängig vom Computer, 

an dem er sich anmeldet, stets gleich. Doch servergespeicherte Benutzerprofile unterliegen auch 

gewissen Einschränkungen. Das größte Problem ist zumeist, dass das Benutzerprofil sehr groß werden 

kann, wenn der Benutzer beispielsweise sehr viele Daten im Ordner Dokumente oder große 

Dateien auf dem Desktop speichert. Häufig haben Dateien in den Ordnern Musik und Videos eine 

Größe von mehreren Megabytes. Alle diese Dateien werden im Benutzerprofil gespeichert. Das Problem 

bei großen servergespeicherten Profilen ist, dass das gesamte Profil immer dann auf die lokale 

Arbeitsstation kopiert werden muss, wenn sich der Benutzer anmeldet und der Computer erkennt, 

dass das Profil auf dem Server neuer als das Profil auf der lokalen Arbeitsstation ist. Wenn der Benutzer 

Änderungen an den Profildaten vornimmt, muss das Profil bei Abmeldung des Benutzers zurück 

auf den Server kopiert werden. Dieser Vorgang kann sehr viel Netzwerkdatenverkehr verursachen und 

die Anmeldezeiten verlängern.


Die Gruppenrichtlinienfunktion bietet die Ordnerumleitung als Möglichkeit an, in den Genuss einiger 

Vorteile servergespeicherter Profile zu kommen und gleichzeitig die Nachteile für Netzwerkbandbreite 

und Anmeldegeschwindigkeit zu minimieren. Bei Aktivierung der Ordnerumleitung werden 

Ordner, die normalerweise Teil des lokalen Benutzerprofils sind, aus dem Profil umgeleitet und in 

einer Netzwerkfreigabe gespeichert. Einer der gängigsten Ordner für die Ordnerumleitung ist beispielsweise 

der Ordner Dokumente, was logisch ist, denn dies ist der Standardspeicherort, an dem die 

meisten Benutzer Dateien speichern. Wenn Sie die Ordnerumleitung konfigurieren, können Sie den 

Ordner Dokumente auf einem Computer zu einer Netzwerkfreigabe umleiten, in der er zentral gesichert 

werden kann. Diese Ordnerumleitung erfolgt für den Endbenutzer nahezu unbemerkt. Die einzige 

Möglichkeit festzustellen, dass der Ordner umgeleitet wurde, ist die Untersuchung der Eigenschaften 

zum Bestimmen des Pfades des Ordners Dokumente. 

Ein weiterer Grund für die Verwendung der Ordnerumleitung ist, dass Sie über diese Option eine 

standardmäßige Desktopumgebung bereitstellen können, ohne verbindliche Benutzerprofile zu verwenden. 

Sie können beispielsweise Ordner wie Startmenü oder Desktop zu einer Netzwerkfreigabe 

umleiten. Anschließend können Sie eine Benutzergruppe für die Nutzung derselben Ordner konfigurieren. 

Indem Sie allen Benutzern nur Leseberechtigungen für diese Ordner erteilten, können Sie 

einen standardmäßigen verbindlichen Desktop für eine Benutzergruppe konfigurieren. 

Wie Abbildung 12.4 zeigt, bieten Windows Server 2008 und Windows Vista sehr viele Ordner, die 

aus dem Benutzerprofil umgeleitet werden können. 


Für die Ordnerumleitung verfügbare Ordner


Konfigurieren der Ordnerumleitung 

Die Ordnerumleitung wird in einem domänenbasierten Gruppenrichtlinienobjekt unter Benutzerkonfiguration\Windows-Einstellungen\Ordnerumleitung 

konfiguriert. 

Zum Einrichten eines bestimmten Ordners für die Umleitung klicken Sie mit der rechten Maustaste 

auf den Ordner, um anschließend Eigenschaften auszuwählen. Die erste Seite der Eigenschaftenseite 

des Objekts ist die Seite Ziel mit folgenden Optionen: 

• Nicht konfiguriert Die Option Einstellung ist standardmäßig auf Nicht konfiguriert festgelegt, was 

bedeutet, dass der Ordner nicht zu einer Netzwerkfreigabe umgeleitet wird. 

• Standard - Leitet alle Ordner auf den gleichen Pfad um Diese Einstellung wird verwendet, wenn Sie 

einen zentralen Speicherort erstellen möchten, an den alle Ordner umgeleitet werden. Sie können 

beispielsweise festlegen, dass sich die Ordner aller von dieser Richtlinie betroffenen Benutzer in 

der Netzwerkfreigabe \\Servername\Freigabename befinden sollen. 

• Erweitert - Gibt Pfade für verschiedene Benutzergruppen an Diese Einstellung dient zum Konfigurieren 

alternativer Speicherorte für den umgeleiteten Ordner abhängig von der Active Directory- 

Sicherheitsgruppe, zu welcher der Benutzer gehört. Bei Wahl dieser Option können Sie jeder 

Sicherheitsgruppe einen anderen Zielordner zuweisen. 

Konfigurieren der Standardumleitung Bei Wahl der Option Standard können Sie anschließend den 

Zielordner konfigurieren. Für die Speicherung des Ordners gibt es mehrere Optionen: 

• In das Basisverzeichnis des Benutzers kopieren Diese Einstellung dient zum Umleiten des Ordners 

Dokumente zum Basisverzeichnis des Benutzers, das in den Benutzerkontoeigenschaften angegeben 

ist. Wählen Sie diese Option nur dann, wenn Sie für das Benutzerobjekt bereits das Basisverzeichnis 

konfiguriert haben. Wurde das Basisverzeichnis noch nicht erstellt, wird durch 

Konfigurieren dieser Option kein Basisverzeichnis eingerichtet. Diese Option steht nur für den 

Ordner Eigene Dateien zur Verfügung. 

• Einen Ordner für jeden Benutzer im Stammpfad erstellen Diese Einstellung dient zum Angeben 

eines Stammpfads, in dem Ordner gespeichert werden sollen. Bei Wahl dieser Option wird unter 

dem Stammpfad jedes Benutzers ein Ordner erstellt. Der Ordnername basiert auf der Umgebungsvariablen 

%username%. 

• An folgenden Pfad umleiten Diese Einstellung dient zum Angeben eines Stamm- und Ordnerpfads 

für jeden Benutzer. Sie können einen UNC- (Universal Naming Convention) oder lokalen Laufwerkspfad 

wählen. Mithilfe der Variablen %username% können Sie einzelne Ordner erstellen. 

Diese Option kann auch zum Umleiten mehrerer Benutzer zum selben Ordner verwendet werden. 

Wenn Sie beispielsweise ein standardmäßiges Startmenü für eine Benutzergruppe einrichten 

möchten, müssen Sie alle auf dieselbe Datei verweisen. 

• An lokalen Benutzerprofilpfad umleiten Dies ist die Standardeinstellung, wenn keine Richtlinien 

aktiviert sind. Bei Festlegung dieser Option werden die Ordner nicht zu einer Netzwerkfreigabe 

umgeleitet. 

Abbildung 12.5 zeigt ein Beispiel des Ordners Dokumente mit ausgewählter Option Standard.



Konfigurieren der Standardordnerumleitung 

Zusätzlich zum Konfigurieren des Zielpfads für die umgeleiteten Ordner können Sie noch weitere 

Einstellungen für die umgeleiteten Ordner festlegen. Klicken Sie dazu in der Eigenschaftenseite des 

Objekts auf die Registerkarte Einstellungen (siehe Abbildung 12.6). 


Konfigurieren der Ordnerumleitungseinstellungen


Die Registerkarte Einstellungen bietet mehrere Konfigurationsoptionen: 

• Dem Benutzer exklusive Zugriffsrechte für Ordnername erteilen Diese Einstellung erteilt dem Benutzer- 

und dem Systemkonto Vollzugriff auf den Ordner. Administratorkonten haben keinen Zugriff. 

Wenn Sie das Kontrollkästchen deaktivieren, werden die Ordnerberechtigungen basierend auf den 

vererbten Berechtigungen konfiguriert. 

Hinweis Diese Einstellung steuert die Berechtigungen für neu erstellte Ordner. Wenn der Zielordner 

nicht vorhanden ist, erstellt die Funktion Ordnerumleitung den Ordner und legt die Berechtigungen so 

fest, dass nur das Benutzer- und lokale Systemkonto Vollzugriffsberechtigungen haben. Das heißt, dass 

der Administrator und andere Benutzer keine Berechtigungen für den Ordner haben. Ist der Zielordner 

vorhanden, überprüft die Funktion Ordnerumleitung den Besitzer des Ordners. Wenn der Ordner im 

Besitz eines anderen Benutzers ist, schlägt die Ordnerumleitung für den angegebenen Ordner fehl. Die 

Funktion Ordnerumleitung überprüft bei Deaktivierung dieses Kontrollkästchens nicht den Besitzer des 

Ordners. 

• Den Inhalt von Ordnername an den neuen Ort verschieben Diese Einstellung verschiebt den aktuellen 

Inhalt des umgeleiteten Ordners an den Zielspeicherort. Wird diese Option nicht ausgewählt, 

wird der Inhalt des aktuellen Ordners nicht an den Zielspeicherort verschoben. 

• Umleitungsrichtlinie auch auf die Betriebssysteme Windows 2000, Windows 2000 Server, Windows XP 

und Windows Server 2003 anwenden Diese Option bietet die Möglichkeit, Ordner in früheren Versionen 

von Windows umzuleiten, z.B. Eigene Dateien, Eigene Bilder, Desktop, Startmenü und 

Anwendungsdaten. Bei Aktivierung dieser Option können frühere Windows-Versionen diese 

bekannten Ordner umleiten. 

• Richtlinienentfernung Über diese Einstellung können Sie festlegen, was bei Entfernen der Richtlinie 

passieren sollen. Wenn Sie die Standardeinstellung Ordner nach Entfernen der Richtlinie 

am neuen Ort belassen übernehmen, wird bei Entfernen der Richtlinie der Inhalt des umgeleiteten 

Ordners nicht in das lokale Benutzerprofil verschoben. Bei Wahl von Ordner nach Entfernen 

der Richtlinie zurück an den Ort des lokalen Benutzerprofils umleiten wird der 

Ordnerinhalt bei Entfernung der Richtlinie verschoben. 

Konfigurieren der erweiterten Ordnerumleitung Bei Wahl der Option Erweitert können Sie anschließend 

den Zielordner basierend auf der Mitgliedschaft in Sicherheitsgruppen konfigurieren (siehe 

Abbildung 12.7). 

Wenn Sie auf die Schaltfläche Hinzufügen klicken, können Sie (wie zuvor erwähnt) die Sicherheitsgruppe 

auswählen und den Zielordner konfigurieren. Das entsprechende Dialogfeld wird in 

Abbildung 12.8 gezeigt.



Konfigurieren der erweiterten Ordnerumleitung 


Auswählen der Mitgliedschaft in Sicherheitsgruppen und des Zielordnerpfads


Verwalten von Offlinedateien für die Ordnerumleitung 

Bei der Implementierung der Ordnerumleitung stehen alle umgeleiteten Ordner standardmäßig offline 

zur Verfügung. Nachdem die Ordnerumleitung implementiert wurde und ein Benutzer sich an 

einem Computer mit Windows Vista angemeldet hat, wird im Benachrichtigungsbereich des Synchronisierungscenters 

die Meldung angezeigt, dass Offlinedateien für die Synchronisierung konfiguriert 

wurden. Durch Doppelklicken auf das Benachrichtigungssymbol wird das Synchronisierungscenter 

geöffnet, in dem Sie Synchronisierungsoptionen konfigurieren und Synchronisierungsergebnisse 

anzeigen können. Abbildung 12.9 zeigt das Synchronisierungscenter von Windows Vista. 


Anzeigen des Synchronisierungscenters von Windows Vista nach Aktivierung der Ordnerumleitung 

Wenn auf einem Clientcomputer mit Windows Vista ein umgeleiteter Ordner geöffnet wird, zeigen 

Informations- und Synchronisierungsindikatoren den Status und die Verfügbarkeit von Daten im Ordner 

an. Sie können auch die Synchronisierung erzwingen und zwischen dem Offline- und Onlinemodus 

umschalten (siehe Abbildung 12.10). 



Anzeigen des Synchronisierungscenters von Windows Vista nach Aktivierung der


Gruppenrichtlinieneinstellungen für die Ordnerumleitung 

Windows Server 2008 bietet zusätzliche Gruppenrichtlinieneinstellungen für die Ordnerumleitung 

(siehe Tabelle 12.5), die Sie im Gruppenrichtlinienverwaltungs-Editor an folgenden Stellen finden: 

• Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Ordnerumleitung 

• Benutzerkonfiguration\Richtlinien\Administrative Vorlagen\System\Ordnerumleitung 

Tabelle 12.5 

Richtlinien für die Ordnerumleitung 


Bei der Umleitung von Start und Eigene 

Dateien lokalisierte Unterordnernamen 

verwenden 

Umgeleitete Ordner nicht automatisch 

offline verfügbar machen (unter Benutzerkonfiguration) 

Erläuterung 

Diese Windows Vista-Richtlinie ermöglicht die Festlegung, ob bei der Ordnerumleitung 

lokalisierte Namen für die Unterordner Alle Programme, Autostart, 

Eigene Musik, Eigene Bilder und Eigene Videos verwendet werden sollen, wenn 

das übergeordnete Menü Start und ältere Ordner vom Typ Eigene Dateien umgeleitet 

werden. 

Wenn Sie diese Einstellung deaktivieren oder nicht konfigurieren, werden standardmäßige 

englische Namen für diese Unterordner verwendet. 

Über diese Einstellung kann verhindert werden, dass die umgeleiteten Ordner 

automatisch offline zur Verfügung stehen. Die Benutzer können jedoch die 

Dateien und Ordner weiterhin manuell verfügbar machen. 

Direkt von der Quelle: Arbeiten mit der Ordnerumleitung für die Interoperabilität von 

Benutzerprofilen 

In Windows Server 2008 wurden Benutzerprofile der Version 2 eingeführt, was zu Problemen bei 

der Bereitstellung von Benutzerdaten für Benutzer führen kann, die vorübergehend mit Benutzerprofilen 

der Version 2 und der Version 1 (Windows Server 2003) arbeiten müssen. Sie können diese 

Probleme teilweise abfedern, indem Sie mit der Gruppenrichtlinienfunktion Ordnerumleitung von 

Windows Server 2008 arbeiten, um Benutzerdatenordner in Benutzerprofile der Version 1 umzuleiten. 

Anwendungsdaten 

Wählen Sie die Option An folgenden Pfad umleiten aus, und leiten Sie Anwendungsdaten an \\Servername\Freigabename\%username%\Anwendungsdaten 

um, den zentralen Speicherort der Benutzerprofile 

der Version 1 des Benutzers. Wenn Sie den Ordner Anwendungsdaten bereits umgeleitet 

haben, stellen Sie sicher, dass der eingegebene Pfad dem des vorhandenen umgeleiteten Ordners 

Anwendungsdaten entspricht. 

Desktop 

Wählen Sie die Option An folgenden Pfad umleiten aus, und leiten Sie den Ordner Desktop an \\ 

Servername\Freigabename\%username%\Desktop um, den zentralen Speicherort der Benutzerversion 

des Benutzerprofils. Wenn Sie den Ordner Desktop bereits umgeleitet haben, stellen Sie sicher, 

dass der eingegebene Pfad dem des vorhandenen umgeleiteten Ordners Desktop entspricht. Aktivieren 

Sie außerdem das Kontrollkästchen Umleitungsrichtlinie auch auf die Betriebssysteme Windows 

2000, Windows 2000 Server, Windows XP und Windows Server 2003 anwenden.


Dokumente 

Wählen Sie die Option An folgenden Pfad umleiten aus, und leiten Sie den Ordner Dokumente zu 

einem zentralen Speicherort um, der sich nicht im Benutzerprofil der Version 1 befindet. Wenn Sie 

den Ordner Dokumente bereits umgeleitet haben, stellen Sie sicher, dass der eingegebene Pfad dem 

des vorhandenen umgeleiteten Ordners Dokumente entspricht. Aktivieren Sie außerdem das Kontrollkästchen 

Umleitungsrichtlinie auch auf die Betriebssysteme Windows 2000, Windows 2000 

Server, Windows XP und Windows Server 2003 anwenden. 

Favoriten 

Wählen Sie die Option An folgenden Pfad umleiten aus, und leiten Sie Favoriten an \\Servername\ 

Freigabename\%username%\Favoriten um, den zentralen Speicherort des Benutzerprofils der 

Version 1 des Benutzers. 

Musik 

Wählen Sie Einstellung: Folgen Sie dem Ordner "Dokumente", um sicherzustellen, dass Sie den 

Ordner Musik als Unterordner des Ordners Dokumente umleiten. 

Bilder 


Ordner Bilder als Unterordner des Ordners Dokumente umleiten. Wenn Sie den Ordner Bilder 

bereits umgeleitet haben, stellen Sie sicher, dass der eingegebene Pfad dem des vorhandenen umgeleiteten 

Ordners Bilder entspricht. 

Startmenü 

Wählen Sie die Option An folgenden Pfad umleiten aus, und leiten Sie den Ordner Startmenü zu an 

\\Servername\Freigabename\%username%\Startmenü um, den zentralen Speicherort des Benutzerprofils 

der Version 1 des Benutzers. Wenn Sie den Ordner Startmenü bereits umgeleitet haben, stellen 

Sie sicher, dass der eingegebene Pfad dem des vorhandenen umgeleiteten Ordners Startmenü 

entspricht. 

Videos 


Ordner Videos als Unterordner des Ordners Videos umleiten. 

Das Umleiten von Benutzerdatenordner der Version 2 in Benutzerprofile der Version 1 bietet eine 

gewissen Grad an Interoperabilität, unterliegt aber auch bestimmten Einschränkungen. Windows 

lädt beispielsweise servergespeicherte Benutzerprofile bei der Anmeldung herunter und gleicht die 

Dateien bei der Abmeldung ab. Daten, die während der Anmeldung mit einem Benutzerprofil der 

Version 1 geändert wurden, stehen über die Umleitung erst dann zur Verfügung, wenn Windows 

das Profil der Version 1 bei der Abmeldung abgleicht. 

Weitere englischsprachige Informationen zur Interoperabilität von Profilen finden Sie im „Managing 

Roaming User Data Deployment Guide“ unter http://go.microsoft.com/fwlink/?LinkId=73760. 

Mike Stephens 

Support Escalation Engineer


Administrative Vorlagen 471 

Unter dem Knoten Administrative Vorlagen befinden sich über 1300 registrierungsbasierte Richtlinieneinstellungen 

zum Verwalten verschiedener Komponenten wie Systemsteuerung, Desktop, Netzwerk- 

und Druckereinstellungen, Menü Start, Taskleiste u.v.m. Eine vollständige Liste aller Richtlinieneinstellungen 

finden Sie in der Referenztabelle zu den Gruppenrichtlinieneinstellungen unter 

http://www.microsoft.com/downloads/details.aspx?familyid=2043b94e-66cd-4b91-9e0f- 

68363245c495&displaylang=en. 

Diese Referenztabelle beschreibt Richtlinieneinstellungen für Windows Server 2008, Windows Vista, 

Windows Server 2003, Windows XP Professional und Windows 2000 und enthält für die meisten 

Kategorien unter dem Knoten Sicherheitseinstellungen eine Erläuterung. 

Wenn eine auf administrativen Vorlagen basierende Gruppenrichtlinieneinstellung angewendet 

wird, werden die Änderungen in bestimmte Unterschlüssel in der Registrierung geschrieben. 

Änderungen an der Benutzerkonfiguration werden in HKEY_CURRENT_USER geschrieben und 

entweder unter \Software\Policies oder \Software\Microsoft\Windows\CurrentVersion\Policies gespeichert. 

Änderungen an der Computerkonfiguration werden unter denselben Unterschlüsseln unter 

HKEY_LOCAL_MACHINE gespeichert. Wenn der Computer gestartet wird und der Benutzer sich 

anmeldet, werden die normalen Registrierungseinstellungen geladen und diese Schlüssel anschließend 

auf zusätzliche Einstellungen untersucht. Wenn diese Stellen zusätzliche Einstellungen aufweisen, 

werden diese in die Registrierung geladen, wobei, falls vorhanden, bestehende Einträge überschrieben 

werden. Wenn die administrative Vorlage entfernt oder der Computer bzw. Benutzer in 

einen anderen Container verschoben wird, in dem die Vorlage nicht gilt, werden die Informationen in 

dem entsprechenden Schlüssel vom Typ Policies gelöscht. Dieses Entfernen der Informationen aus 

den Policies-Schlüsseln bedeutet, dass die administrativen Vorlagen nicht mehr gelten, während die 

normalen Registrierungseinstellungen weiter gelten. 

Grundlegendes zu administrativen Vorlagendateien 

Administrative Vorlagendateien dienen zum Angeben der Richtlinieneinstellungsinformationen für 

alle Elemente unter dem Knoten Administrative Vorlagen. In früheren Microsoft Windows-Versionen 

wurden mehrere ADM-Dateien zum Offenlegen der verschiedenen registrierungsbasierten Konfigurationseinstellungen 

verwendet, die sich standardmäßig im Ordner %SystemRoot%\Inf befinden. 

Tabelle 12.6 enthält die administrativen Vorlagendateien, die unter Windows Server 2003 standardmäßig 

installiert und verwendet werden. 

Tabelle 12.6 

Unter Windows Server 2003 geladene Standardvorlagen 

Administrative Vorlage 

System.adm 

Inetres.adm 

Wmplayer.adm 

Conf.adm 

Wuau.adm 

Konfigurationseinstellungen 

Systemeinstellungen 

Internet Explorer-Einstellungen 

Microsoft Windows Media Player-Einstellungen 

Microsoft NetMeeting-Einstellungen 

Windows Update-Einstellungen 

Die administrativen Vorlagendateien bestehen aus einer Folge von Einträgen, welche die Optionen 

bestimmen, die über die Vorlage verfügbar sind. Jeder Eintrag in der ADM-Datei sieht wie in 

Abbildung 12.11 gezeigt aus.



Struktur einer ADM-Vorlagendatei 

In Tabelle 12.7 wird die Struktur einer typischen ADM-Vorlage erläutert. 

Tabelle 12.7 

Komponenten einer Vorlagenoption 

Vorlagenkomponente 

POLICY 

KEYNAME 

SUPPORTED 

EXPLAIN 

PART 

VALUENAME 

Erläuterung 

Gibt den Richtliniennamen an. 

Gibt den von dieser Einstellung geänderten Registrierungsschlüssel an. 

Gibt die unterstützten Arbeitsstationen bzw. die erforderliche Softwareversion für diese Einstellung 

an. Zu den Beispielen gehören Windows XP Professional, Windows 2000, Windows 

2000 mit angegebenem Service Pack und Microsoft Windows Media Player 9. 

Gibt den Text an, der die Richtlinieneinstellung erläutert. Der tatsächliche Text wird später in 

der ADM-Datei aufgelistet. 

Gibt die Einträge an, die für diese Richtlinie konfiguriert werden können. 

Gibt den Registrierungsschlüssel an, der mit den Informationen aus dieser Einstellung aufgefüllt 

wird. 

Windows Server 2008 und Windows Vista bieten neue XML-basierte ADMX-Vorlagen, welche die 

ADM-Vorlagen in früheren Windows-Versionen ersetzen. ADMX-Vorlagen bieten Vorteile bei der 

Vorlagenverwaltung und -entwicklung sowie neue Sprachlokalisierungsfunktionen. 

ADMX-Vorlagen bestehen aus zwei Hauptkomponenten, die zum Anzeigen von Registrierungseinstellungen 

im Gruppenrichtlinienverwaltungs-Editor verwendet werden: 

• ADMX-Dateien ADMX-Dateien sind die primären sprachneutralen Dateien, die über die Konsole 

Gruppenrichtlinienverwaltung Zugriff auf die registrierungsbasierten Richtlinieneinstellungen 

bieten. Diese Dateien befinden sich im Ordner %SystemRoot%\PolicyDefinitions. 

• ADML-Dateien ADML-Dateien sind sprachspezifische Dateien, die es Tools für die Gruppenrichtlinienverwaltung 

ermöglichen, die lokalisierte Sprache der grafischen Benutzeroberfläche basierend 

auf der für den Administrator konfigurierten Sprache anzupassen. Jeder ADMX-Datei 

können eine oder mehrere ADML-Dateien für jede Sprache zugewiesen sein, die von den Gruppenrichtlinienadministratoren 

benötigt werden. ADML-Dateien befinden sich im Ordner 

%SystemRoot%\PolicyDefinitions\[MUIculture].


Abbildung 12.12 zeigt den Ordner PolicyDefinitions auf einem Computer mit Windows Server 2008. 

Wie Sie sehen, gibt es für viele der Windows-Komponenten spezifische ADMX-Dateien. Der Unterordner 

en-US enthält die entsprechenden englischsprachigen ADML-Dateien. 


Anzeigen des Ordners PolicyDefinitions 

Wenn Sie auf einem Computer mit Windows Server 2008 oder Windows Vista in der Konsole Gruppenrichtlinienverwaltung 

ein domänenbasiertes Gruppenrichtlinienobjekt bearbeiten, liest der Editor 

automatisch alle im lokalen Ordner PolicyDefinitions gespeicherten ADMX-Dateien und zeigt 

anschließend die Richtlinienkategorien und -einstellungen unter dem Knoten Richtlinien\Administrative 

Vorlagen für die Computer- und Benutzerkonfigurationsabschnitte der Richtlinie an. Wie in 

Abbildung 12.13 zu sehen, zeigt der Gruppenrichtlinienverwaltungs-Editor an, dass die Richtliniendefinitionen 

(ADMX-Dateien) gegenwärtig vom lokalen Computer abgerufen werden. 

Hinweis Unter Windows Vista RTM wird die Konsole Gruppenrichtlinienverwaltung im Gegensatz zu Windows 

Vista SP1 installiert. Sie müssen die Remoteserver-Verwaltungstools unter Windows Vista SP1 installieren, 

um die Konsole Gruppenrichtlinienverwaltung verwenden zu können. 

Beachten Sie ferner, dass sich die Konsole Gruppenrichtlinienverwaltung unter Windows Vista RTM von der 

Konsole Gruppenrichtlinienverwaltung unterscheidet, die über die Remoteserver-Verwaltungstools installiert 

wird. Die Konsole Gruppenrichtlinienverwaltung von Windows Vista RTM bietet keine Filter, Kommentare, 

Starter-Gruppenrichtlinienobjekte und nicht die Funktion Einstellungen.



Bestimmen des Speicherorts, aus dem die ADMX-Dateien abgerufen werden 

Windows Server 2008 enthält keine vorherigen ADM-Dateien. Die Windows Server 2008- und Windows 

Vista-Versionen des Gruppenrichtlinienobjekt-Editors können dennoch weiter verwendet werden, 

um alle früheren Betriebssysteme mit Gruppenrichtlinienunterstützung zu verwalten, z.B. Windows 

2000, Windows Server 2003 und Windows XP. Über die Option Vorlagen hinzufügen/entfernen 

können Sie ein Gruppenrichtlinienobjekt bearbeiten, d.h. benutzerdefinierte ADM-Dateien hinzufügen 

oder entfernen. Es gibt jedoch keine grafische Benutzeroberfläche zum Hinzufügen oder 

Entfernen von ADMX-Dateien. Selbstdefinierte ADMX-Dateien können manuell in den Ordner 

%SystemRoot%\PolicyDefinitions kopiert werden, in dem sie beim Neustart der Konsole Gruppenrichtlinienverwaltung 

automatisch erkannt werden. 

Verwalten domänenbasierter Vorlagendateien 

In den meisten Großunternehmen sind mehrere Mitarbeiter für die Konfiguration und Bereitstellung 

von Gruppenrichtlinieneinstellungen in der Active Directory-Umgebung zuständig. Um sicherzustellen, 

dass alle Administratoren Zugriff auf dieselben ADMX-Dateien haben, können Sie im Verzeichnis 

SYSVOL eines Domänencontrollers für jede Domäne im Unternehmen einen zentralen Speicher 

einrichten. Der zentrale Speicher wird anschließend auf alle Domänencontroller in der Domäne repliziert.


Hinweis Es wird empfohlen, dass Sie den zentralen Speicher auf dem Domänencontroller mit der Rolle 

PDC-Emulator einrichten. Die Konsole Gruppenrichtlinienverwaltung verbindet sich standardmäßig mit dem 

PDC-Emulator, der ein schnelleres Lesen der ADMX-Dateien ermöglicht, ohne auf den Abschluss von Replikationsaufgaben 

warten zu müssen. 

Führen Sie zum Konfigurieren eines zentralen ADMX-Speichers die folgenden Schritte aus: 

1. Erstellen Sie auf einem Domänencontroller unter %SystemRoot%\sysvol\domain\policies\Policy- 

Definitions den Stammordner für den zentralen Speicher. 

2. Erstellen Sie auf dem Domänencontroller im Ordner PolicyDefinitions einen Unterordner für jede 

Sprache, die von Ihren Gruppenrichtlinienadministratoren benötigt wird. Jeder Unterordner muss 

gemäß der ISO-Sprachkonvention benannt werden. Der Unterordner für US-Englisch heißt beispielsweise 

%SystemRoot%\sysvol\domain\policies\PolicyDefinitions\EN-US. 

3. Kopieren Sie auf Ihrer Arbeitsstation mit Windows Vista mit folgendem Befehl alle ADMX- 

Dateien in den Ordner PolicyDefinitions auf dem Domänencontroller: 

copy %systemroot%\PolicyDefinitions\*%logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\ 

4. Kopieren Sie auf Ihrer Verwaltungsarbeitsstation mit Windows Vista mit folgendem Befehl alle 

ADML-Dateien in den Sprachunterordner auf dem Domänencontroller: 

copy %systemroot%\PolicyDefinitions\[MUIculture]\*%logonserver%\sysvol\%userdnsdomain%\policies\ 

PolicyDefinitions\[MUIculture]\ 

Wenn ein Administrator die Konsole Gruppenrichtlinienverwaltung auf einem Computer mit Windows 

Vista oder Windows Server 2008 öffnet, werden automatisch alle im zentralen Speicher gespeicherten 

ADMX-Dateien gelesen und alle Richtlinieneinstellungen in der entsprechenden Sprache der 

Arbeitsstation angezeigt. Nach der Konfiguration eines zentralen Speichers im Ordner SYSVOL lesen 

die Tools zur Gruppenrichtlinienverwaltung nur die ADMX-Dateien im zentralen Speicher und ignorieren 

die lokal auf der Verwaltungsarbeitsstation gespeicherten ADMX-Dateien. 

Empfohlene Vorgehensweisen für die Verwaltung von ADMX- 

Vorlagendateien 

Berücksichtigen Sie beim Verwenden von ADMX-Vorlagendateien zum Bereitstellen von Gruppenrichtlinieneinstellungen 

die folgenden Empfehlungen: 

• Verwenden Sie nur die Konsole Gruppenrichtlinienverwaltung unter Windows Vista SP1 (Remoteserver-Verwaltungstools) 

und Windows Server 2008 zum Konfigurieren domänenbasierter 

Gruppenrichtlinieneinstellungen. Dies stellt sicher, dass alle Einstellungen angezeigt und in Gruppenrichtlinienobjekten 

genutzt werden können. Außerdem können Sie dadurch die Größe der einzelnen 

Gruppenrichtlinienobjekt-Ordner im Ordner SYSVOL verringern. Wenn Sie beispielsweise 

auf einem Computer mit Windows Vista SP1 mithilfe der Konsole Gruppenrichtlinienverwaltung 

in den Remoteserver-Verwaltungstools ein neues Gruppenrichtlinienobjekt erstellen und anschließend 

dieses Gruppenrichtlinienobjekt unter einer früheren Windows-Version bearbeiten, werden 

die ADM-Vorlagendateien im Ordner %Windir%\inf in den Gruppenrichtlinienobjekt-Ordner 

kopiert und auf alle Domänencontroller in der Domäne repliziert. Dadurch kann sich die Größe 

der einzelnen Gruppenrichtlinienobjekt-Ordner um ca. 4 MB pro Gruppenrichtlinienobjekt erhöhen.


• Viele Anwendungen enthalten ADM-Dateien für die Verwaltung von Anwendungseinstellungen 

mithilfe von Gruppenrichtlinien. Über den Befehl Vorlagen hinzufügen/entfernen können Sie 

diese Dateien weiterhin in den Ordner %Windir%\inf auf der Verwaltungsarbeitsstation importieren. 

Die Office 2003-ADM-Vorlagen stehen unter folgender Adresse zum Download bereit: 

http://www.microsoft.com/downloads/details.aspx?FamilyID=BA8BC720-EDC2-479B-B115- 

5ABB70B3F490&displaylang=en 

• Wenn Sie Gruppenrichtlinieneinstellungen für das 2007 Microsoft Office System verwalten müssen, 

können Sie ADM- bzw. ADMX-Vorlagendateien an folgender Internetadresse herunterladen: 

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=92d8519a-e143- 

4aee-8f7a-e4bbaeba13e7 

• Mit dem ADMX Migrator können Sie benutzerdefinierte ADM-Dateien in das neue ADMX-Format 

umwandeln. Sie können den ADMX Migrator auch als Editor mit grafischer Benutzeroberfläche 

nutzen, um eigene administrative Vorlagen besser erstellen und bearbeiten zu können. Der 

ADMX Migrator steht unter folgender Adresse zum Download bereit: http://www.microsoft.com/ 

downloads/details.aspx?familyid=0F1EEC3D-10C4-4B5F-9625-97C2F731090C&displaylang=en 

Direkt von der Quelle: Verwalten von ADMX-/ADM-Dateien in einer heterogenen 

Betriebssystemumgebung 

Die Konsole Gruppenrichtlinienverwaltung dient zum Auslesen und Anzeigen der Richtlinieneinstellungen 

in Administrative Vorlagen in den ADMX-Dateien, die entweder lokal oder im zentralen 

ADMX-Speicher gespeichert sind. Wenn Sie eigene ADM-Dateien entwickelt haben, kann die 

Konsole Gruppenrichtlinienverwaltung zum automatischen Lesen und Anzeigen der Richtlinieneinstellungen 

in Administrative Vorlagen in selbstdefinierten ADM-Dateien verwendet werden, die 

im Gruppenrichtlinienobjekt gespeichert sind. Alle Gruppenrichtlinieneinstellungen, die zur Zeit in 

ADM-Dateien enthalten sind und die von Windows Server 2003, Windows XP und Windows 2000 

zur Verfügung gestellt werden, stehen auch in ADMX-Dateien unter Windows Vista und Windows 

Server 2008 zur Verfügung. 

Neue auf Windows Vista oder Windows Server 2008 basierende Richtlinieneinstellungen können 

nur über Verwaltungscomputer mit Windows Vista oder Windows Server 2008 verwaltet werden, 

auf denen die Konsole Gruppenrichtlinienverwaltung ausgeführt wird. Solche Richtlinieneinstellungen 

werden nur in ADMX-Dateien definiert, die als solche nicht in den Windows Server 2003-, 

Windows XP- und Windows 2000-Versionen dieser Tools offen gelegt werden. 

Die Windows Vista- und Windows Server 2008-Versionen der Konsole Gruppenrichtlinienverwaltung 

dienen zum Verwalten aller Betriebssysteme mit Gruppenrichtlinienunterstützung (Windows 

Vista, Windows Server 2008, Windows Server 2003, Windows XP und Windows 2000). 

Die Windows Vista- und Windows Server 2008-Versionen des Gruppenrichtlinienobjekt-Editors 

und der Konsole Gruppenrichtlinienverwaltung unterstützen die Interoperabilität mit Versionen 

dieser Tools unter Windows Server 2003 und Windows XP. In Gruppenrichtlinienobjekten gespeicherte 

benutzerdefinierte ADM-Dateien werden beispielsweise vom Gruppenrichtlinienobjekt-Editor 

und der Konsole Gruppenrichtlinienverwaltung unter Windows Vista, Windows Server 2008, 

Windows Server 2003 und Windows XP genutzt.

Verwalten der Benutzerumgebung mithilfe von Skripts 477 

Die Windows Vista- und Windows Server 2008-Versionen des Gruppenrichtlinienobjekt-Editors 

unterstützen die Interoperabilität mit Versionen des Gruppenrichtlinienobjekt-Editors unter Windows 

Server 2000. In Gruppenrichtlinienobjekten gespeicherte benutzerdefinierte ADM-Dateien 

werden vom Gruppenrichtlinienobjekt-Editor und unter Windows Vista, Windows Server 2008 und 

Windows Server 2003 genutzt. (Die Konsole Gruppenrichtlinienverwaltung kann unter Windows 

2000 nicht ausgeführt werden.) 

Christiane Soumahoro 


Verwalten der Benutzerumgebung mithilfe von Skripts 

Schon seit geraumer Zeit nutzen Administratoren Anmeldeskripts, um die Benutzerumgebung besser 

zu konfigurieren und zu verwalten. Der gängigste Zweck von Skripts war stets, den Benutzern eine 

unkomplizierte Arbeitsumgebung zur Verfügung zu stellen, z.B. durch zugeordnete Netzwerklaufwerke 

und Drucker. Windows Server 2008 bietet die folgenden Möglichkeiten für den Einsatz von 

Skripts mit Gruppenrichtlinieneinstellungen: 

• Möglichkeit der Zuweisung von Skripts zum Starten und Herunterfahren Mithilfe von Gruppenrichtlinien 

können Sie Skripts so zuweisen, dass sie beim Hoch- und Herunterfahren von Computern 

im Sicherheitskontext des Kontos LocalSystem ausgeführt werden. 

• Möglichkeit der Zuweisung von Skripts für die An- und Abmeldung von Benutzern Unter Windows 

Server 2008 können Sie Skripts für die An- und Abmeldung von Benutzern zuweisen. 

• Möglichkeit, Skripts Containern anstatt Einzelpersonen zuzuweisen Einer der größten Vorteile beim 

Arbeiten mit domänenbasierten Gruppenrichtlinien für die Zuweisung von Skripts besteht darin, 

dass Sie ein Skript einem Containerobjekt wie beispielsweise einer Organisationseinheit zuweisen 

können. Wenn Sie ein Skript einem Container in Active Directory zuweisen, gilt das Skript für 

alle Benutzer bzw. Computer im Container. 

• Systeminhärente Unterstützung von Windows Script Host-Skripts Die meisten Windows-Clients bieten 

eine systeminhärente Unterstützung von WSH-Skripts (Windows Script Host), die bei der 

Konfiguration von Benutzerdesktops mithilfe von Skripts wesentlich flexibler und leistungsfähiger 

sind. Bei Verwenden von WSH können Skripts für weitaus komplexere Aufgaben als das 

Zuordnen von Netzwerklaufwerken genutzt werden. 

Die Active Directory-Domänendienste unter Windows Server 2008 unterstützen weiterhin persönliche 

Anmeldeskripts, die den einzelnen Benutzerkonten zugewiesen sind. Wenn Sie noch über einzelne 

Anmeldeskripts verfügen, die Benutzerkonten zugewiesen sind, werden diese ausgeführt, nachdem 

die von Gruppenrichtlinien zugewiesenen Benutzeranmeldeskripts ausgeführt wurden. 

Zum Bereistellen auf Gruppenrichtlinien basierender Skripts müssen Sie die Skripts zuerst in einer 

unterstützten Skriptsprache erstellen, z.B. als Batchdateien (.cmd) oder in Microsoft JScript oder 

VBScript, und die Skripts anschließend auf die Domänencontroller kopieren. Sie können die Skripts 

in einem beliebigen Speicherort auf dem Server speichern, solange die Clients auf diesen zugreifen 

können. Ein gängiger Ablageort zum Speichern eines Skripts ist der Ordner %SystemRoot%\SYSVOL\ 

sysvol\Domänenname\Globale_Richtlinien-GUIDS\Machine\Scripts oder der Ordner %SystemRoot%\ 

SYSVOL\sysvol\Domänenname\Globale_Richtlinien-GUIDS\User\Scripts. Sie können die Anmeldeskripts 

auch im Ordner %SystemRoot%\SYSVOL\sysvol\Domänenname\scripts speichern.


Dieser Ordner wird mit dem Freigabenamen NETLOGON freigeben und dient als Standardspeicherort, 

den untergeordnete Clients auf Anmeldeskripts durchsuchen. Erstellen oder ändern Sie nach dem 

Kopieren der Skriptdateien auf den Server das Gruppenrichtlinienobjekt, und suchen Sie unter dem 

Ordner Computerkonfiguration\Richtlinien\Windows-Einstellungen den Ordner Skripts (Starten/ 

Herunterfahren) oder unter dem Ordner Benutzerkonfiguration\Richtlinien\Windows-Einstellungen 

den Ordner Skripts (Anmelden/Abmelden). 

Sie können beispielsweise zum Erstellen eines Eintrags für ein Startskript den Ordner Skripts (Starten/ 

Herunterfahren) erweitern und auf Starten doppelklicken. Anschließend können Sie dem Gruppenrichtlinienobjekt 

die gewünschten Startskripts hinzufügen. 

Windows Server 2008 bietet eine Vielzahl administrativer Vorlagen zum Konfigurieren, wie Skripts 

auf Clientarbeitsstationen verarbeitet werden sollen. Die meisten Einstellungen finden Sie unter Computerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Skripts, einige wenige unter Benutzerkonfiguration\Richtlinien\Administrative 

Vorlagen\System\Skripts. In den Konfigurationsoptionen 

können Sie auswählen, ob Startskripts asynchron ausgeführt werden sollen oder nicht. Bei Wahl der 

asynchronen Option können mehrere Startskripts gleichzeitig ausgeführt werden. Wenn Sie sich für 

die synchrone Ausführung von Anmeldeskripts entscheiden, müssen alle Startskripts ausgeführt worden 

sein, bevor dem Benutzer der Windows-Desktop angezeigt wird. Sie können auch eine maximale 

Wartezeit für das Abschließen der Ausführung aller Skripts festlegen. Und schließlich können Sie 

bestimmen, ob die Skripts unsichtbar im Hintergrund oder sichtbar im Vordergrund ausgeführt werden 

sollen. 

Hinweis Windows Server 2008 bietet mit Gruppenrichtlinieneinstellungen ein neues Feature, über das 

Aufgaben erledigt werden können, die bislang von Anmeldeskripts übernommen wurden. Mithilfe dieses 

Features können Sie Anmeldeskripts ggf. vollständig oder teilweise überflüssig machen. Das entsprechende 

Feature Gruppenrichtlinieneinstellungen wird weiter unten in diesem Kapitel behandelt. 

Bereitstellen von Software mithilfe von Gruppenrichtlinien 

Das Verwalten der Software auf Benutzerdesktops kann sehr arbeitsintensiv sein, wenn sich ein 

Administrator immer dann zu jedem einzelnen Desktopcomputer begeben muss, wenn ein Softwarepaket 

installiert oder aktualisiert werden muss. Das Feature Gruppenrichtlinie für die Softwareinstallation 

kann den Verwaltungsaufwand für Benutzerdesktops spürbar verringern. Und tatsächlich ergibt 

sich eine der größten Kosteneinsparungen, die sich durch eine Bereitstellung von Active Directory- 

Domänendiensten und Gruppenrichtlinien erzielen lassen, im Bereich der Softwareverwaltung. 

Das Verwalten von Software in einer Unternehmensumgebung umfasst weitaus mehr als das reine 

Bereitstellen von Software. Viele Unternehmen arbeiten mit einem klar definierten Lebenszyklus-Verwaltungsprozess 

für Software, der den Erwerb bzw. das Entwickeln und Testen der Anwendung, den 

Piloteinsatz der Anwendung in einer kleinen Benutzergruppe, die großflächige Bereitstellung der 

Anwendung, die Wartung der Anwendung nach der Bereitstellung und schließlich die Entfernung der 

Anwendung vorsieht. Dank dem Feature Gruppenrichtlinie für die Softwareinstallation können viele 

dieser Aufgaben effizienter erfolgen. 

Windows Installer-Technologie 

Zumeist basiert die Softwareverwaltung mithilfe von Gruppenrichtlinien auf Microsoft Windows 

Installer-Technologie, die zum Installieren, Verwalten und Entfernen von Software auf Windows- 

Arbeitsstationen genutzt wird. Die Windows Installer-Technologie umfasst zwei Komponenten:

Bereitstellen von Software mithilfe von Gruppenrichtlinien 479 

• Eine Paketdatei für die Softwareinstallation (MSI-Datei) Die MSI-Paketdatei enthält sämtliche 

Anweisungen zum Installieren und Entfernen von Anwendungen. 

• Den Windows Installer-Dienst (Msiexec.exe) Dieser Dienst verwaltet die eigentliche Installation von 

Software auf der Arbeitsstation. Der Dienst nutzt die DLL-Datei (Dynamic Link Library) Msi.dll 

zum Lesen der MSI-Paketdateien. Basierend auf dem Inhalt der Paketdatei für die Softwareinstallation 

kopiert der Dienst anschließend die Anwendungsdateien auf die lokale Festplatte, erstellt 

Verknüpfungen, ändert Registrierungseinträge und führt alle in der MSI-Datei enthaltenen Anweisungen 

aus. 

Windows Installer-Technologie bietet diverse Vorteile. Einer davon ist, dass Anwendungen größtenteils 

selbstreparierend sein können. Da die MSI-Datei sämtliche für die Installation der Anwendung 

benötigten Informationen enthält, kann dieselbe Datei auch zum Reparieren einer fehlerhaften 

Anwendung genutzt werden. Wenn eine Anwendung beispielsweise fehlerhaft wird, weil eine wichtige 

Datei gelöscht wurde, kann die Anwendung beim nächsten Öffnungsversuch durch den Benutzer 

nicht gestartet werden. Wurde die Anwendung mit Windows Installer installiert, kann die MSI-Datei, 

die zum Installieren der Anwendung genutzt wurde, auch zum Reparieren der Anwendung verwendet 

werden, indem die fehlende Datei neu installiert wird. Die MSI-Datei ermöglicht auch einen besseren 

Deinstallationsprozess für Anwendungen, die Sie von einer Clientarbeitsstation entfernen möchten. 

Die meisten Softwarehersteller stellen mittlerweile mit neuer Software eine MSI-Paketdatei für die 

Softwareinstallation zur Verfügung, die als systemeigene Windows Installer-Datei bezeichnet wird. 

Enthält die Software eine MSI-Datei, können Sie mit deren Hilfe die Software installieren. Wenn Sie 

keine systemeigene Windows Installer-Datei haben, können Sie sich ein Tool zum Erstellen von Softwarepaketen 

beschaffen, um eine MSI-Datei zu erstellen, die für die Bereitstellung mithilfe von Gruppenrichtlinien 

verwendet werden kann. 

Bereitstellen von Anwendungen 

Mithilfe von Gruppenrichtlinie für die Softwareinstallation können Sie die Installation einer Anwendung 

ankündigen oder die Installation Computern bzw. Benutzern zur Verfügung stellen. Nachdem 

Sie die Richtlinieneinstellung für die Softwareinstallation konfiguriert haben, wird die Information, 

dass das neue Softwarepaket verfügbar ist, dem Computer angekündigt, wenn dieser das nächste Mal 

gestartet wird oder der Benutzer sich das nächste Mal anmeldet. Die Anwendung ist dann zur Installation 

auf diesem Computer bereit. 

Bevor Sie Benutzern im Netzwerk eine Anwendung ankündigen können, müssen Sie die Softwareinstallationsdateien 

samt MSI-Datei in eine Netzwerkfreigabe kopieren, auf die alle Benutzer Zugriff 

haben. Wenn Sie die Netzwerkfreigabe erstellen, müssen Sie sicherstellen, dass alle Benutzer bzw. 

Computer Zugriff darauf haben. Wenn Sie Anwendungen Computern zuweisen, müssen die Computerkonten 

Lesezugriff haben. Wenn Sie für Benutzer Anwendungen zuweisen oder veröffentlichen, 

müssen die Benutzerkonten Lesezugriff haben. 

Nach Erstellen der Netzwerkfreigabe und Kopieren der Installationsdateien in die Freigabe können 

Sie das Gruppenrichtlinienobjekt implementieren, das den Clients die Anwendung ankündigt. Sie 

können ein neues Gruppenrichtlinienobjekt erstellen oder ein vorhandenes Gruppenrichtlinienobjekt 

bearbeiten. Beim Konfigurieren des Gruppenrichtlinienobjekts müssen Sie zuerst entscheiden, ob die 

Anwendung Computern oder Benutzern angekündigt werden soll. Wenn Sie die Anwendung Computern 

ankündigen wollen, müssen Sie den Container Computerkonfiguration\Richtlinien\Softwareeinstellungen 

im Gruppenrichtlinienverwaltungs-Editor verwenden. Die Anwendung wird anschließend 

auf der Arbeitsstation installiert, wenn sie das nächste Mal neu gestartet wird.


Wenn Sie die Anwendung Benutzern ankündigen wollen, müssen Sie den Container Benutzerkonfiguration\Richtlinien\Softwareeinstellungen 

im Gruppenrichtlinienverwaltungs-Editor verwenden. Die 

Anwendung steht dem Benutzer nach seiner nächsten Anmeldung zur Verfügung. 

Bei Verwenden der Gruppenrichtlinie für die Softwareinstallation zur Bereitstellung von Anwendungen 

gibt es zwei Optionen, wie die Anwendung dem Client angekündigt werden soll. Die erste 

Option ist das Zuweisen der Anwendung zu entweder einem Computer oder einem Benutzer. Die 

zweite Option ist das Veröffentlichen, bei dem die Anwendung ausschließlich Benutzerkonten zur 

Verfügung gestellt wird. 

Beim Zuweisen einer Anwendung zu einem Computer wird die Anwendung beim nächsten Neustart 

des Computers vollständig installiert, was bedeutet, dass die Anwendung für alle Benutzer eines 

Computers installiert wird, wenn sie sich das nächste Mal an diesem Computer anmelden. 

Wenn Sie eine Anwendung einem Benutzer zuweisen, wird sie dem Benutzer angekündigt, wenn er 

sich das nächste Mal am Netzwerk anmeldet. Sie können festlegen, wie die Anwendung angekündigt 

wird, doch zumeist wird sie dem Menü Start hinzugefügt. Die Anwendung wird ferner der Liste Programme 

beziehen in der Windows Vista- und Windows Server 2008-Anwendung Programme und 

Funktionen hinzugefügt. Die Anwendung wird standardmäßig nicht installiert, wenn der Benutzer 

sich anmeldet, wird aber installiert, wenn der Benutzer die Anwendung im Menü Start aktiviert oder 

sich für die Installation der Anwendung über Programme und Funktionen entscheidet. Sie können die 

Installationslogik auch so konfigurieren, dass eine Anwendung installiert werden kann, wenn der 

Benutzer versucht, eine Datei mit einer Erweiterung zu öffnen, die der Anwendung zugeordnet ist. 

Wenn beispielsweise Microsoft Word gegenwärtig nicht auf dem Computer des Benutzers installiert 

ist, wird bei einem Doppelklick des Benutzers auf eine Datei mit der Erweiterung .doc Word automatisch 

installiert. Dieser Vorgang wird auch als Erweiterungsaktivierung bezeichnet. 

Ein Feature, das unter Windows Server 2003 und Windows Server 2008, jedoch nicht unter Windows 

2000 zur Verfügung steht, ist die vollständige Installation der Softwareanwendung, wenn sich der 

Benutzer anmeldet, anstatt nach Aktivierung durch den Benutzer. Die Wahl dieser Option bedeutet, 

dass der Anmeldeprozess länger dauert, da die Anwendung installiert wird, doch die Anwendung 

steht anschließend dem Client zur Verfügung. Diese Option ist nur verfügbar, wenn die Anwendung 

einem Benutzer zugewiesen ist. Veröffentlichte Anwendungen können erst vollständig installiert werden, 

nachdem sie über die Systemsteuerungsoption Software (unter Windows Vista Programme beziehen) 

oder die Erweiterungsaktivierung installiert wurden. Diese Option entfällt auch, wenn die 

Anwendung Computern zugewiesen ist, da sie beim nächsten Neustart des Computers vollständig 

installiert wird. 

Wenn Sie eine Anwendung für einen Benutzer veröffentlichen, wird sie dem Benutzer angekündigt, 

wenn er sich das nächste Mal am Netzwerk anmeldet. In diesem Fall wird die Anwendung allerdings 

nur in der Systemsteuerungsoption Software angekündigt. Um die Anwendung zu installieren, müssen 

die Benutzer diese Option in Software auswählen. Veröffentlichte Anwendungen werden standardmäßig 

auch über die Erweiterungsaktivierung installiert. 

Meist empfiehlt sich die Veröffentlichung einer Anwendung, wenn nur bestimmte Benutzer diese 

benötigen. Angenommen, Sie haben eine Anwendung wie Microsoft Visio, die nur von Netzwerkarchitekten 

ständig und von anderen Benutzern gegebenenfalls benötigt wird. Durch Veröffentlichen der 

Anwendung für Benutzer wird diese nicht auf deren Desktops installiert oder ihren Verknüpfungen 

hinzugefügt, sondern den Benutzern zur Verfügung gestellt, die sie benötigen. 

Führen Sie zum Ankündigen einer Anwendung mithilfe von Gruppenrichtlinien die folgenden 

Schritte aus:


1. Kopieren Sie die Softwareinstallationsdateien in eine Netzwerkfreigabe. Legen Sie die Berechtigungen 

für die Freigabe so fest, dass alle betreffenden Benutzer und Computer Lesezugriff auf die 

Installationsdateien haben. 

2. In der Konsole Gruppenrichtlinienverwaltung müssen Sie ein neues Gruppenrichtlinienobjekt 

erstellen oder ein vorhandenes bearbeiten. Verknüpfen Sie das Gruppenrichtlinienobjekt den 

Anforderungen entsprechend. 

3. Wenn Sie die Anwendung Benutzern ankündigen, erweitern Sie im Gruppenrichtlinienverwaltungs-Editor 

den Container Benutzerkonfiguration\Richtlinien\Softwareeinstellungen. Klicken Sie 

mit der rechten Maustaste auf Softwareinstallation, klicken Sie auf Neu und anschließend auf 

Paket. Wenn Sie die Anwendung Computerkonten ankündigen, erweitern Sie den Container Computerkonfiguration\Richtlinien\Softwareeinstellungen. 

Klicken Sie mit der rechten Maustaste auf 

Softwareinstallation, klicken Sie auf Neu und anschließend auf Paket. 

4. Wechseln Sie zum Netzwerkspeicherort, oder geben Sie den Netzwerkpfad ein, in dem sich die 

Installationsdateien befinden. Sie müssen einen Netzwerkpfad und dürfen keinen lokalen Laufwerksbuchstaben 

auf dem Server auswählen, da der Netzwerkpfad den Clientcomputern angekündigt 

wird. Wählen Sie die entsprechende MSI-Datei aus. 

Hinweis Wenn Sie den falschen Netzwerkpfad auswählen oder den Netzwerkpfad nach der Bereitstellung 

ändern möchten, müssen Sie das Softwarepaket neu erstellen, da es keine Möglichkeit gibt, 

den Installationspfad des Softwarepakets zu ändern. 

5. Bei Wahl der MSI-Datei können Sie angeben, wie Sie das Softwarepaket ankündigen möchten. 

Abbildung 12.14 zeigt die Optionen, wenn Sie die Anwendung Benutzerkonten ankündigen. 

Wenn Sie die Anwendung Computern ankündigen, können Sie die Anwendung nur zuweisen. 


Optionen für die Ankündigung des Softwarepakets 

6. Wenn Sie die Anwendung zuweisen oder veröffentlichen möchten, klicken Sie auf OK. Bei Wahl 

der Option Erweitert wird die Eigenschaftenseite für das Paket angezeigt, das weiter unten in diesem 

Kapitel im Abschnitt „Konfigurieren von Softwarepaketeigenschaften“ besprochen wird. 

Nachdem das Gruppenrichtlinienobjekt konfiguriert und mit dem gewünschten Container verknüpft 

wurde, wird die Anwendung allen Clients im Containerobjekt angekündigt. Standardmäßig wird die 

Softwareinstallationskomponente eines Gruppenrichtlinienobjekts nur angewendet, wenn sich der 

Benutzer anmeldet (wenn die Richtlinie für Benutzerkonten gilt) oder der Computer neu startet (wenn 

die Richtlinie für Computerkonten gilt).


Mit dem Befehlszeilenprogramm GPUpdate kann eine Abmeldung oder ein Neustart im Rahmen der 

Gruppenrichtlinienaktualisierung auf der Arbeitsstation erzwungen werden. Um eine Abmeldung oder 

einen Neustart zu erzwingen, wählen Sie den Befehl gpupdate /force /logoff oder gpupdate /force / 

boot. 

Softwareverteilung und Netzwerkbandbreite 

Einer der schwierigsten Aspekte bei der Verwaltung der Softwareverteilung mithilfe von Gruppenrichtlinien 

ist die Nutzung der Netzwerkbandbreite. Wenn Sie eine Anwendung mit Hunderten von 

Megabytes einer großen Benutzergruppe zuweisen und alle Benutzer die Anwendung gleichzeitig 

installieren, kann die Installation aufgrund des drastisch ansteigenden Netzwerkdatenverkehrs 

Stunden dauern. Es gibt verschiedene Möglichkeiten, die Netzwerkbandbreite überlegt zu nutzen. 

Eine Option ist das Zuweisen von Anwendungen zu Computern und die Benutzer zu bitten, ihre 

Computer am Ende des Tages neu zu starten. Über den Befehl GPUpdate können Sie auch einen 

Neustart der Arbeitsstation erzwingen. Wenn Sie diesen Befehl auf nur wenige Arbeitsstationen 

gleichzeitig anwenden, kann die Auswirkung auf das Netzwerk minimiert werden. 

Eine weitere Möglichkeit ist das gleichzeitige Zuweisen von Anwendungen zu kleinen Benutzergruppen. 

Zumeist ist es auch ratsam, das Zuweisen von Anwendungen zu vermeiden, die vollständig 

installiert werden, wenn der Benutzer sich anmeldet. Wenn Sie eine Anwendung ankündigen, 

dem Benutzer aber erlauben, die Installation auszulösen, können Sie die Softwareinstallation über 

einen gewissen Zeitraum verteilen. Wenngleich keine dieser Optionen ideal ist, können Sie die 

Nutzung der Netzwerkbandbreite zu einem bestimmten Grad steuern. 

Eine weitere Möglichkeit zur Steuerung der Netzwerknutzung, wenn es mehrere Standorte gibt, 

bietet das verteilte Dateisystem (Distributed File System, DFS). Mithilfe des DFS können Sie eine 

logische Verzeichnisstruktur einrichten, die unabhängig von den tatsächlichen Speicherortorten der 

Dateien im Netzwerk ist. Sie können beispielsweise einen DFS-Stammordner mit dem Namen \\ 

Server1\softinst einrichten und anschließend unter diesem Freigabepunkt Unterverzeichnisse für 

sämtliche Anwendungen erstellen. Im DFS können Sie die Unterverzeichnisse auf mehreren Servern 

finden und mehrere physische Verknüpfungen zu denselben logischen Verzeichnissen konfigurieren. 

Bei Verwenden der DFS-Replikation können Sie sogar eine automatische Replikation des 

Ordnerinhalts zwischen Kopien desselben Verzeichnisses konfigurieren. Das DFS ist eine standortabhängige 

Anwendung, was bei mehreren Standorten bedeutet, dass sich die Clientcomputer stets 

mit einer Kopie des DFS-Ordners an ihrem Standort anstatt über eine WAN-Verbindung verbinden, 

um auf den Ordner an einem anderen Standort zuzugreifen. 

Die genauen Auswirkungen einer Installation über das Netzwerk sind schwer vorherzusagen. Einer 

der Vorteile von Gruppenrichtlinien für das Installieren von Software ist, dass Sie mühelos einen 

Test durchführen können, um die voraussichtlichen Auswirkungen zu ermitteln. Sie können beispielsweise 

ein Gruppenrichtlinienobjekt mit dem Softwarepaket konfigurieren und dafür sorgen, 

dass das Gruppenrichtlinienobjekt mit keiner Organisationseinheit verbunden ist. Sie können 

anschließend eine temporäre Organisationseinheit erstellen, dieser einige Benutzer- oder Computerkonten 

hinzufügen und das Gruppenrichtlinienobjekt mit der Organisationseinheit verknüpfen. 

Anhand dieser Konfiguration kann getestet werden, wie lange es dauert, bis die Anwendungen in 

einer kleinen Benutzergruppe installiert sind. Sie können auch einen Pilottest für die Softwareverteilung 

einrichten, indem Sie das Gruppenrichtlinienobjekt mit einer Organisationseinheit in der 

Produktionsumgebung verknüpfen und anschließend über die Gruppenrichtlinienfilterung 

beschränken, auf welche Benutzer oder Computer das Gruppenrichtlinienobjekt angewendet 

werden soll.


Ungeachtet der Anstrengungen, die Sie zum Minimieren der Auswirkungen auf das Netzwerk 

unternehmen, hat die Bereitstellung einer großen Anwendung für sehr viele Benutzer stets Einfluss 

auf das Netzwerk. Da dies unabänderlich ist, sollten Sie die Installation auf mehrere Tage verteilen. 

Verteilen von nicht mit Windows Installer installierten Anwendungen 

mithilfe von Gruppenrichtlinien 

Mitunter möchten Sie ggf. nicht den Aufwand betreiben, eine MSI-Datei zum Installieren einer 

Anwendung zu erstellen, diese aber dennoch mit Gruppenrichtlinien verteilen. Angenommen, Sie 

haben eine einfache Anwendung, die auf mehreren Arbeitsstationen installiert werden muss, jedoch 

keine Anpassungen erfordert und auch nicht aktualisiert wird. In diesem Fall können Sie zum Installieren 

dieser Anwendung eine ZAP-Datei (Zero Administration for Windows [ZAW] Down-Level 

Applications Package) erstellen und verwenden. 

Eine ZAP-Datei ist eine Textdatei mit Setupanweisungen zum Installieren einer Anwendung. Eine 

ZAP-Datei enthält zumeist nur die folgenden Zeilen: 

[Application] FriendlyName = "Anwendungsname" SetupCommand = ""\\Servername\Freiagabename\ 

installapplication.exe"" 

Der Wert FriendlyName ist der Name, der in der Systemsteuerungsoption Software auf dem Clientcomputer 

angezeigt wird. Der Wert SetupCommand ist der Pfad zur Installationsdatei der Anwendung. 

Für SetupCommand können Sie einen UNC-Pfad (Universal Naming Convention) oder ein 

zugeordnetes Laufwerk wählen. Falls die Anwendung eine Möglichkeit zum Anpassen der Installation 

mithilfe von Setupparametern bietet, können Sie im Anschluss an die schließenden doppelten 

Anführungszeichen des Setuppfads die Parameter dem Wert SetupCommand hinzufügen. Der Wert 

kann beispielsweise wie folgt aussehen: 

SetupCommand = "\\Servername\Freigabename\setup.exe" /parameter 

Wenn die Befehlszeile einen Parameter aufweist, enthält der Setuppfad einen einzelnen Satz doppelter 

Anführungszeichen anstatt die beiden Sätze doppelter Anführungszeichen, die im vorherigen Beispiel 

erforderlich waren. 

Nach Erstellen der ZAP-Datei und Kopieren der Anwendungsinstallationsdateien in die Netzwerkfreigabe, 

können Sie die Anwendung für Benutzer veröffentlichen. Die Anwendung wird in der Systemsteuerungsoption 

Software der Liste der verfügbaren Anwendungen hinzugefügt. Die Benutzer können 

anschließend die zu installierende Anwendung auswählen. Anwendungen, die über ZAP-Dateien 

verteilt werden, können weder Computern noch Benutzern zugewiesen werden und werden nicht über 

die Erweiterungsaktivierung installiert. 

ZAP-Dateien unterliegen im Vergleich mit Windows Installer-Dateien mehreren wesentlichen Einschränkungen. 

Erstens wird bei der Installation der Anwendung mithilfe der ZAP-Datei das normale 

Installationsprogramm der Anwendung ausgeführt, was bedeutet, dass Sie die Installation nur dann 

anpassen können, wenn die Anwendung Setupparameter zum Anpassen der Installation bietet. Zweitens 

kann die Installation mithilfe von ZAP-Dateien nicht mit erhöhten Berechtigungen ausgeführt 

werden, was bedeutet, dass ein Benutzer zum Installieren der Anwendung lokale Administratorrechte 

benötigt. Drittens sind über ZAP-Dateien installierte Anwendungen nicht selbstreparierend. Wenn die 

Anwendung ausfällt, weil eine Datei zuvor beschädigt oder gelöscht wurde, muss der Benutzer zur 

Neuinstallation der Anwendung die ursprüngliche Installationsprozedur nochmals manuell ausführen. 

Viertens kann eine mithilfe einer ZAP-Datei installierte Anwendung nicht ohne weiteres aktualisiert 

oder mit Patches versehen werden.


Aufgrund dieser Nachteile ist diese Methode der Softwareinstallation nur bedingt brauchbar und 

sollte auf einfache Anwendungen beschränkt werden, die voraussichtlich nicht aktualisiert werden. 

Konfigurieren von Softwarepaketeigenschaften 

Nachdem Sie das Softwarepaket erstellt haben, können Sie die Paketeigenschaften ändern. 

Klicken Sie dazu mit der rechten Maustaste auf das Paket, und wählen Sie Eigenschaften aus. 

Abbildung 12.15 zeigt die Registerkarte Bereitstellung. In Tabelle 12.8 werden die verfügbaren 

Optionen auf dieser Registerkarte erläutert. 


Ändern der Bereitstellungseigenschaften eines Softwarepakets 

Tabelle 12.8 

Bereitstellungsoptionen für ein Softwarepaket 

Einstellung 

Bereitstellungsart 

Automatisch installieren, wenn die 

Dateierweiterung aktiviert wird 

Anwendung deinstallieren, wenn 

sie außerhalb des Verwaltungsbereichs 

liegt 

Paket in der Systemsteuerung 

unter Software nicht anzeigen 

Erläuterung 

Dient zum Angeben, wie die Anwendung Clients angekündigt wird. 

Dient zum Aktivieren oder Deaktivieren der Option zum Installieren von Software, wenn 

ein Benutzer eine Datei mit einer ausgewählten Erweiterung öffnet. Diese Option ist nicht 

verfügbar, wenn Sie eine Anwendung zuweisen. 

Über diese Option können Sie bestimmen, was passieren soll, wenn die Gruppenrichtlinie 

nicht mehr für den Benutzer oder Computer gilt. Wenn die Gruppenrichtlinie beispielsweise 

mit Benutzerkonten in einer Organisationseinheit verknüpft ist, bedeutet die 

Wahl dieser Option, dass die Anwendung deinstalliert wird, wenn das Benutzerkonto aus 

der Organisationseinheit verschoben wird. 

Dient zum Festlegen, ob die Anwendung in der Systemsteuerungsoption Software angezeigt 

wird oder nicht.


Tabelle 12.8 

Bereitstellungsoptionen für ein Softwarepaket (Fortsetzung) 

Einstellung 

Anwendung bei Anmeldung 

installieren 

Benutzeroberflächenoptionen für 

die Installation 

Erweitert 

Erläuterung 

Dient zum vollständigen Installieren einer Anwendung, wenn sich der Benutzer anmeldet, 

anstatt abzuwarten, dass der Benutzer die Installation auslöst. Diese Option ist nicht verfügbar, 

wenn Sie eine Anwendung veröffentlichen. 

Über diese Option können Sie bestimmen, was dem Benutzer angezeigt werden soll, 

wenn die Software installiert wird. Bei Wahl von Standard werden nur Fehler- und Fertigstellungsmeldungen 

angezeigt. Bei Wahl von Maximal werden alle Bildschirme zum 

Setup der Software angezeigt. 

Dient zum Konfigurieren weiterer Einstellungen für das Softwarepaket. Zu den Optionen 

zählen die Installation von 32-Bit-Anwendungen unter 64-Bit-Betriebssystemen, die Installation 

einer Anwendung mit im Vergleich zum Zielbetriebssystem anderer Sprache und 

die Einbeziehung von COM-Komponenten (Component Object Model) in das Paket, damit 

der Client die Komponenten aus Active Directory installieren kann. Abbildung 12.16 

zeigt das Dialogfeld. 

Abbildung 12.16 Konfigurieren der gruppenrichtlinienbasierten Softwareinstallation auf der Seite Erweiterte 

Bereitstellungsoptionen 

Festlegen der standardmäßigen Softwareinstallationseigenschaften 

Wenn Sie die Bereitstellung von Software mithilfe von Gruppenrichtlinien vorbereiten, können Sie 

die Standardeinstellungen für alle Softwarepakete konfigurieren, die mithilfe eines bestimmten Gruppenrichtlinienobjekts 

bereitgestellt werden. Sie können auf dieses Dialogfeld zugreifen, indem Sie mit 

der rechten Maustaste auf den Container Softwareinstallation klicken und dann Eigenschaften auswählen. 

Abbildung 12.17 zeigt das Dialogfeld.



Festlegen der standardmäßigen Softwareinstallationseigenschaften 

Befolgen Sie dieses Verfahren, um die Optionen festzulegen, die angezeigt werden, wenn Sie in diesem 

Gruppenrichtlinienobjekt ein neues Softwarepaket erstellen. Sie können ferner den Standardpfad 

für die Softwareinstallationsdateien festlegen und die Benutzeroberflächeneinstellungen für die Installation 


Installieren angepasster Softwarepakete 

Es kann vorkommen, dass Sie die Installation eines Windows Installer-Softwarepakets anpassen müssen. 

So kann es beispielsweise erforderlich sein, dass Sie eine angepasste Installation Ihrer Textverarbeitungsanwendung 

erstellen müssen, die benutzerdefinierte Wörterbücher oder Vorlagen umfasst. 

Oder Sie müssen ggf. die Installation von Microsoft Office so anpassen, dass auf jedem Desktopcomputer 

nur Microsoft Word und Microsoft Excel installiert werden, während das komplette Office- 

Paket nur ausgewählten Benutzern bereitgestellt wird. Wenn Sie für ein internationales Unternehmen 

arbeiten, müssen Sie ggf. dieselbe Anwendung in mehreren Sprachen bereitstellen. 

Sie können die Installation eines Softwarepakets anpassen, indem Sie eine Transformationsdatei (mit 

der Erweiterung .mst) erstellen oder abrufen. Die Transformationsdatei enthält zusätzlich zur MSI- 

Datei Anweisungen, mit denen die Installation angepasst wird. Die einfachste Möglichkeit zum 

Erstellen einer MST-Datei ist das Verwenden einer Softwarepaket- oder benutzerdefinierten Anwendung, 

die vom Softwarehersteller bereitgestellt wird. Microsoft bietet beispielsweise für die meisten 

Versionen von Microsoft Office (vor Office 2007) in den Tools zur technischen Referenz einen Assistenten 

für benutzerdefinierte Installationen. Nach Start dieses Assistenten wählen Sie eine MSI-Datei, 

einen Namen und einen Pfad für die MST-Datei aus. Anschließend zeigt der Assistent sämtliche 

Optionen für die Anpassung der Standardinstallation der Software an. Sie können nahezu jeden 

Aspekt der Installation anpassen, so z.B. frühere Versionen von Office entfernen lassen, die zu installierenden 

Komponenten auswählen und den Pfad dieser Komponenten bestimmen.


Sie können Benutzereinstellungen migrieren, falls die Installation vorhandene Software aktualisiert, 

oder Sie können persönliche und Sicherheitseinstellungen nach Wunsch konfigurieren. Sie können der 

Installation weitere Dateien hinzufügen (z.B. benutzerdefinierte Vorlagen), Registrierungsschlüssel 

hinzufügen oder entfernen, Verknüpfungen zu Office-Anwendungen hinzufügen oder entfernen sowie 

E-Mail-Clienteinstellungen konfigurieren. 

Nach Erstellung der Transformationsdatei müssen Sie ein neues Softwarepaket erstellen, um die 

benutzerdefinierte Installation bereitzustellen. Wenn Sie das neue Softwarepaket erstellen, wählen Sie 

bei Auswahl der Bereitstellungsmethode die Option Erweitert aus, damit Sie die Transformationsdatei 

hinzufügen können, bevor das Paket fertiggestellt wird. Klicken Sie in der Eigenschaftenseite des 

Softwarepakets auf die Registerkarte Änderungen, und fügen Sie anschließend die Transformationsdateien 

hinzu. Abbildung 12.18 zeigt die Registerkarte Änderungen. 


Hinzufügen von Transformationsdateien zu einem Softwarepaket 

Wenn Sie die Transformationsdatei auf das Softwarepaket anwenden, wird auf allen Clients im Geltungsbereich 

des Gruppenrichtlinienobjekts, auf denen die Anwendung installiert wird, die angepasste 

Version installiert. Sie können dem Softwarepaket mehrere Transformationsdateien hinzufügen. 

In diesem Fall werden die Transformationsdateien von oben nach unten in der Liste angewendet, 

was bedeutet, dass im Installationsprozess später angewendete Transformationsdateien frühere Änderungen 

ggf. überschreiben. 

Aktualisieren eines vorhandenen Softwarepakets 

Eine weitere nützliche Funktion bei Verwenden von Gruppenrichtlinien zum Bereitstellen von Software 

ist die Möglichkeit der Aktualisierung vorhandener Softwarepakete. Es gibt in Wesentlichen 

zwei Methoden zum Aktualisieren vorhandener Softwarepakete: Aktualisieren oder Installieren eines 

Service Pack für eine vorhandene Anwendung oder Aktualisieren einer Anwendung auf eine neue 

Version.


Für beide Methoden zur Softwareaktualisierung sind unterschiedliche Vorgehensweisen erforderlich. 

Wenn Sie auf eine vorhandene Anwendung Updates oder ein Service Pack anwenden, müssen Sie 

zuerst eine MSI-Datei oder Patchdatei (.msp) für die zu aktualisierende Anwendung abrufen. (Im Idealfall 

stammt diese Datei vom Softwarehersteller, Sie können aber auch eine eigene erstellen.) Kopieren 

Sie die neue MSI-Datei und die anderen neuen Softwareinstallationsdateien in den Ordner der 

ursprünglichen MSI-Dateien, und überschreiben Sie duplizierte Dateien. Stellen Sie anschließend die 

Anwendung erneut bereit. Klicken Sie dazu im Gruppenrichtlinienverwaltungs-Editor mit der rechten 

Maustaste auf das Softwarepaket, wählen Sie Alle Aufgaben, und klicken Sie anschließend auf 

Anwendung erneut bereitstellen. Das Softwarepaket wird für alle Benutzer und Computer erneut 

bereitgestellt, die mit dem Gruppenrichtlinienobjekt verknüpft sind. 

Wenn Sie eine vorhandene Anwendung auf eine neue Version der Software aktualisieren, müssen Sie 

eine andere Methode wählen. In diesem Fall müssen Sie ein neues Softwarepaket erstellen, um die 

Anwendung bereitzustellen. Sie können anschließend auf die Eigenschaften des Softwarepakets für 

die neue Anwendung zugreifen und die Registerkarte Aktualisierungen öffnen. Mithilfe der Einstellungen 

auf dieser Registerkarte können Sie eine Verknüpfung zwischen dem neuen Softwareverteilungspaket 

und einem vorhandenen Paket herstellen. Wenn Sie auf der Registerkarte Aktualisierungen 

auf Hinzufügen klicken, können Sie auswählen, welches Softwarepaket von diesem Paket 

aktualisiert werden soll. Sie können außerdem angeben, ob die alte Anwendung zuerst deinstalliert 

werden muss, bevor die neue Anwendung installiert wird. Abbildung 12.19 zeigt ein Beispiel für die 

Aktualisierung von Microsoft Office Excel Viewer 2003. 


Aktualisieren eines vorhandenen Softwarepakets 

Nachdem Sie die Aktualisierungsverknüpfung erstellt haben, zeigt die Registerkarte Aktualisierungen 

neue Informationen an (siehe Abbildung 12.20). Auf der Registerkarte Aktualisierungen können Sie 

auch die Option Vorhandene Pakete aktualisieren auswählen. Bei Wahl dieser Option wird sämtliche 

vom vorherigen Gruppenrichtlinienobjekt verteilte Software beim nächsten Mal aktualisiert, wenn der 

Computer neu gestartet wird oder der Benutzer sich anmeldet. Wenn Sie diese Option nicht aktivieren, 

kann der Benutzer auswählen, wann die neue Anwendung installiert werden soll: Entweder durch 

Aktivieren der Anwendung über das Menü Start oder über die Systemsteuerungsoption Programme 

und Funktionen.


Wenn Sie für die Aktualisierung des Softwarepakets das Gruppenrichtlinienobjekt verwenden, das Sie 

auch für die vorherigen Anwendungsinstallation genutzt haben, zeigt das ursprüngliche Softwarepaket 

an, das es vom neuen Paket aktualisiert wird. 


Die Registerkarte Aktualisierungen in der Eigenschaftenseite eines Softwarepakets 

Hinweis Die Tatsache, dass die Aktualisierung einer Anwendung mithilfe von Gruppenrichtlinien so einfach 

ist, heißt nicht, dass die Aktualisierung auf die leichte Schulter genommen werden sollte. Vor Bereitstellung 

der Aktualisierung müssen Sie diese testen, um sicherzustellen, dass keine Probleme mit vorhandenen 

Anwendungen vorliegen. Außerdem müssen Sie auch den Aktualisierungsprozess testen, um sicherzustellen, 

dass alles reibungslos funktioniert. Nachdem dies sichergestellt wurde, müssen Sie auch noch die 

Bereitstellung verwalten. Wenn die Anwendung, die Sie aktualisieren, Tausenden von Benutzer bereitgestellt 

wurde, und Sie festlegen, dass die Aktualisierung eine erforderliche Aktualisierung ist, müssen die 

Benutzer ggf. lange warten, bis die Installation abgeschlossen ist. Sie müssen weiterhin die Bereitstellung 

der Aktualisierung sorgfältig betreuen, um negative Auswirkungen auf die Netzwerkbandbreite zu minimieren. 

Konfigurieren der Dateierweiterungsaktivierung 

Eine Möglichkeit, die ein Benutzer zum Auslösen der Installation einer Anwendung hat, ist die Dateierweiterungsaktivierung. 

Es gibt meist nur eine Anwendung, die einer bestimmten Dateierweiterung 

zugeordnet ist. Es gibt jedoch auch Ausnahmen. Angenommen, Sie aktualisieren Word 2000 auf 

Word 2003 und für mehrere Monate stehen ggf. beide Versionen der Software zur Installation zur Verfügung. 

In diesem Fall können Sie konfigurieren, welche der Anwendungsversionen installiert werden 

soll, wenn ein Benutzer die Installation über die Dateierweiterungsaktivierung auslöst. 

Öffnen Sie zum Konfigurieren dieser Option im Gruppenrichtlinienverwaltungs-Editor die Eigenschaftenseite 

Softwareinstallation unter Computerkonfiguration oder Benutzerkonfiguration. Klicken 

Sie auf die Registerkarte Dateierweiterungen (siehe Abbildung 12.21). Die zuerst aufgeführte 

Anwendung wird installiert, wenn die Dateierweiterung aktiviert wird.



Konfigurieren der Dateierweiterungsaktivierung 

Weitere Informationen Bei Verwenden der Gruppenrichtlinie für die Softwareinstallation für die Bereitstellung 

von 2007 Office System müssen verschiedene wichtige Aspekte beachtet werden. Weitere (englischsprachige) 

Informationen finden Sie in „Use Group Policy Software Installation to Deploy the 2007 Office 

System“ unter http://technet2.microsoft.com/Office/en-us/library/efd0ee45-9605-42d3-9798- 

3b698fff3e081033.mspx?mfr=true. 

Entfernen von mit Gruppenrichtlinien bereitgestellter Software 

Die Gruppenrichtlinie für die Softwareinstallation kann zum Bereitstellen von Anwendungen und 

Entfernen zuvor installierter Anwendungen genutzt werden. Für die Entfernung von Software mithilfe 

von Gruppenrichtlinien gibt es drei Optionen: 

• Entfernen von Software als einleitender Schritt zum Installieren einer neueren Version der Software 

• Entfernen von Software, wenn der Benutzer oder Computer den Verwaltungsbereich verlässt 

• Entfernen von Software bei Entfernung des Softwarepakets 

Die ersten beiden Optionen wurden bereits zuvor in diesem Kapitel behandelt. Die letzte Option muss 

näher erklärt werden. Wenn Sie ein Softwarepaket aus einem Gruppenrichtlinienobjekt entfernen, 

können Sie bestimmen, wie die vom Gruppenrichtlinienobjekt installierte Software verwaltet werden 

soll. Klicken Sie dazu in der Auflistung Softwareinstallation mit der rechten Maustaste auf das Softwarepaket, 

wählen Sie Alle Aufgaben, und klicken Sie anschließend auf Entfernen. Abbildung 12.22 

zeigt das Dialogfeld, das geöffnet wird, wenn Sie ein Softwareinstallationspaket entfernen möchten. 

Bei Wahl von Software sofort von Benutzern und Computern deinstallieren wird die Software beim 

nächsten Neustart des Computers bzw. der nächsten Anmeldung des Benutzers deinstalliert. Bei Wahl 

von Benutzer dürfen die Software weiterhin verwenden, aber Neuinstallationen sind nicht zugelassen 

steht die Anwendung auf den Arbeitsstationen weiter zur Verfügung, doch neue Benutzer können die 

Anwendung nicht weiter mithilfe dieses Gruppenrichtlinienobjekts installieren.



Konfigurieren der Entfernung von Software bei Entfernung eines Softwarepakets 

Konfigurieren von Windows Installer mithilfe von Gruppenrichtlinien 

Da die meisten Anwendungen, die Sie über das Feature Gruppenrichtlinie für die Softwareinstallation 

installieren, mit der Windows Installer-Technologie arbeiten, müssen Sie auch bestimmen, wie 

Windows Installer-Anwendungen installiert werden sollen, wozu mehrere Richtlinieneinstellungen 

genutzt werden. Die meisten dieser Einstellungen finden Sie an folgenden Stellen: 

• Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows 

Installer 

• Benutzerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows 

Installer 

In Tabelle 12.9 werden die konfigurierbaren Optionen an diesen beiden Stellen erläutert. 

Tabelle 12.9 

Gruppenrichtlinieneinstellungs-Optionen für Windows Installer 

Einstellung 

Durchsuchen für Benutzer mit erhöhten 

Rechten aktivieren (nur Computerkonfiguration) 

Verwenden von Medienquellen für Benutzer 

mit erhöhten Rechten aktivieren (nur Computerkonfiguration) 

Patchverwendung für Programme mit erhöhter 

Sicherheit zulassen (nur Computerkonfiguration) 

Administrator erlauben, Installationen von 

Terminaldienstesitzungen auszuführen (nur 

Computerkonfiguration) 

Immer mit erhöhten Rechten installieren 

(Computerkonfiguration und Benutzerkonfiguration) 

Windows Installer deaktivieren (nur 


Erläuterung 

Über diese Option können Sie nach anderen Installationsquellen suchen, 

wenn die Anwendung mit erhöhten Berechtigungen installiert wird. 

Über diese Option können Sie dem Benutzer erlauben, Wechseldatenträger 

als Installationsquelle zu nutzen, wenn die Anwendung mit erhöhten Berechtigungen 

installiert wird. 

Über diese Option können Sie dem Benutzer die Installation von Patches erlauben, 

wenn die Anwendung mit erhöhten Berechtigungen ausgeführt wird. 

Über diese Optionen können Sie Administratoren von Terminaldiensten erlauben, 

Software im Rahmen einer Terminaldienstesitzung zu installieren und zu 


Über diese Option können Sie Benutzern erlauben, Anwendungen zu installieren, 

die Zugriff auf Verzeichnisse oder Registrierungsschlüssel benötigen, auf 

die der Benutzer normalerweise nicht zugreifen kann. Das Aktivieren dieser 

Option bedeutet, dass Windows Installer die Systemberechtigungen für die 

Installation von Software nutzt. 

Diese Option ermöglicht das Aktivieren bzw. Deaktivieren der Installation von 

Software mit Windows Installer. Bei Aktivierung der Richtlinie können Sie Windows 

Installer vollständig deaktivieren, Windows Installer für alle Anwendungen 

aktivieren oder Windows Installer für die Anwendungen deaktivieren, 

die nicht über Gruppenrichtlinien verteilt werden.


Tabelle 12.9 

Gruppenrichtlinieneinstellungs-Optionen für Windows Installer (Fortsetzung) 

Einstellung 

Zurücksetzen nicht zulassen (Computerkonfiguration 

und Benutzerkonfiguration) 

Dialog Durchsuchen für die Suche nach einer 

neuen Quelle entfernen (nur Computerkonfiguration) 

Patchverwendung nicht zulassen (nur 


IE-Sicherheitshinweis für Windows Installer- 

Skripts deaktivieren (nur Computerkonfiguration) 

Benutzersteuerung bei Installationen zulassen 

(nur Computerkonfiguration) 

Transformationen an einem sicheren Ort auf 

der Arbeitsstation zwischenspeichern (nur 


Protokollierung (nur Computerkonfiguration) 

Benutzerinstallationen nicht zulassen (nur 


Erstellung von Systemwiederherstellungsprüfpunkten 

deaktivieren (nur Computerkonfiguration) 

Suchreihenfolge (nur Benutzerkonfiguration) 

Wechselmedienquellen für alle Installationen 

verhindern (nur Benutzerkonfiguration) 

Erläuterung 

Über diese Option können Sie das standardmäßige Windows Installer-Verhalten 

beim Erstellen von Dateien deaktivieren, über das eine unvollständige Installation 

zurückgesetzt werden kann. 

Über diese Option können Sie die Schaltfläche Durchsuchen deaktivieren, 

wenn ein Benutzer ein neues Feature mithilfe von Windows Installer installieren 

möchte. Bei Aktivierung dieser Option wird die Schaltfläche Durchsuchen 

deaktiviert, was bedeutet, dass der Benutzer Features nur aus vom Administrator 

konfigurierten Quellen installieren kann. 

Diese Option hindert den Benutzer an der Installation von Patches für Programme 

mithilfe von Windows Installer. Die Aktivierung dieser Option erhöht 

die Sicherheit, da Benutzer am Installieren von Patches gehindert werden, die 

ggf. Systemdateien verändern. 

Über diese Option können Sie die Warnung deaktivieren, die dem Client angezeigt 

wird, wenn Software über eine Browseroberfläche wie beispielsweise 

Microsoft Internet Explorer installiert wird. Sie können diese Option verwenden, 

wenn Ihre Software zumeist über eine Website verteilt wird. 

Diese Option versieht den Benutzer mit mehr Steuerungsmöglichkeiten bei 

der Installation von Anwendungen. Bei Aktivierung dieser Option wird der Installationsvorgang 

bei jedem Installationsbildschirm angehalten, sodass der 

Benutzer die Einstellungen ändern kann. 

Über diese Option können die Transformationsdateien zwischengespeichert 

werden, um auf der lokalen Arbeitsstation eine angepasste Anwendung zu installieren. 

Diese Transformationsdatei wird zum Reparieren oder Wiederholen 

der Softwareinstallation benötigt. 

Über diese Option können Sie Windows Installer so konfigurieren, dass die 

Standardstufe der Protokollierung der Softwareinstallation erhöht wird. 

Über diese Option können Sie festlegen, ob die einem Benutzer zugewiesenen 

Anwendungen installiert werden oder nicht. Wenn Sie diese Option 

aktivieren, können Sie die Einstellung so konfigurieren, dass nur dem Computer 

zugewiesene Anwendungen installiert werden. Diese Einstellung ist auf öffentlich 

zugänglichen und freigegebenen Computern nützlich. Sie gilt nur für 

Clients mit installiertem Windows Installer 2.0 oder höher. 

Mit dieser Option können Sie das Standardverhalten von Computern mit Windows 

XP Professional ändern, gemäß dem ein Systemwiederherstellungsprüfpunkt 

automatisch erstellt wird, bevor eine Anwendung installiert wird. 

Über diese Option können Sie die standardmäßige Suchreihenfolge ändern, 

gemäß der Windows Installer nach Installationsdateien sucht. Windows Installer 

durchsucht standardmäßig zuerst das Netzwerk, dann Wechseldatenträger 

und schließlich eine Internet-URL. 

Über diese Option können Sie Benutzer am Verwenden von Windows Installer 

hindern, um Anwendungen von Wechseldatenträgern zu installieren.


Planen der Gruppenrichtlinie für die Softwareinstallation 

Der Einsatz von Gruppenrichtlinien zum Bereistellen und Verwalten von Softwareinstallationen kann 

den Aufwand zur Verteilung und Wartung von Software auf Clientcomputern stark mindern. Doch die 

Nutzung dieses Instruments kann kompliziert sein, insbesondere in Großunternehmen mit vielen verschiedenen 

Softwarekonfigurationen für Benutzerdesktops. Die effektive Verwaltung von Software 

mithilfe von Gruppenrichtlinien erfordert eine sorgfältige Planung. In diesem Abschnitt werden verschiedene 

Aspekte behandelt, die Sie beim Planen von Gruppenrichtlinien für die Softwareinstallation 

berücksichtigen müssen. 

Einer der zu berücksichtigenden Aspekte bei der Bereitstellung von Anwendungen ist, ob die Anwendungen 

Benutzern oder Computern angekündigt werden sollen. Wenn die meisten Computer von 

mehreren Benutzern genutzt werden und jeder Benutzer ein bestimmtes Softwarepaket benötigt, sollten 

Sie die Richtlinie Computern zuweisen. Durch Zuweisen der Richtlinie zu Computern wird die 

Software beim nächsten Neustart der Arbeitsstation vollständig installiert und allen Benutzern zur 

Verfügung gestellt. Das Zuweisen des Softwarepakets zu Computern bietet auch mehr Optionen für 

das Steuern der Netzwerkbandbreite. Bei Wahl dieser Option können Sie ein Gruppenrichtlinienobjekt 

für die Softwareinstallation am Tag konfigurieren und anschließend die Benutzer auffordern, 

die Arbeitsstationen nach der Bürozeit neu zu starten (oder dazu ein Remotetool einsetzen). 

Wenn nur einige Benutzer ein Softwarepaket benötigen, bietet es sich meist an, die Anwendung 

Benutzerkonten zuzuweisen oder für diese zu veröffentlichen. Mitunter muss ein Softwarepaket an 

Benutzer in mehreren Organisationseinheiten verteilt werden. Die beste Möglichkeit ist hierzu das 

Zuweisen eines Gruppenrichtlinienobjekts an einer hohen Stelle in der Active Directory-Hierarchie 

und anschließende Filtern der Anwendung des Gruppenrichtlinienobjekts mithilfe von Sicherheitsgruppen. 

Eine weitere wichtige Entscheidung beim Planen der Softwareverteilung ist die Anzahl der zu 

verwendenden Gruppenrichtlinienobjekte. Das eine Extrem ist der Einsatz nur eines Gruppenrichtlinienobjekts 

zum Verteilen sämtlicher Software für einen bestimmten Container, wodurch die 

Clientanmeldezeiten beschleunigt werden, was aber zu umfangreichen und komplizierten Gruppenrichtlinienobjekt-Konfigurationen 

führen kann. Das andere Extrem ist der Einsatz vieler Gruppenrichtlinienobjekte, 

wobei mit jedem nur eine Anwendung verteilt wird. In diesem Fall wird ggf. die 

Clientanmeldung verlangsamt, da der Computer viele Gruppenrichtlinienobjekte lesen muss. Unternehmen 

arbeiten mit verschiedenen Ansätzen, um den passenden Mittelweg zu finden. Einer davon ist 

die Einrichtung eines Gruppenrichtlinienobjekts zum Installieren eines Standardsatzes von Anwendungen, 

die alle Benutzer benötigen und die selten geändert werden. Zusätzliche Gruppenrichtlinienobjekte 

werden für Anwendungen erstellt, die häufig aktualisiert (z.B. Antivirensoftware) bzw. von 

kleinen Benutzergruppen verwendet werden. 

Sie müssen ggf. auch die Softwareverteilung über langsame Netzwerkverbindungen planen. In vielen 

Unternehmen gibt es Zweigstellen mit Benutzern, die sich über langsame Netzwerkverbindungen mit 

Active Directory verbinden. Standardmäßig kommt die Softwareverteilungskomponente von Gruppenrichtlinien 

nicht zum Einsatz, wenn sich der Client über eine Netzwerkverbindung mit weniger als 

500 KBit/s verbindet. Falls sich die Arbeitsstationen in Ihrem Netzwerk normalerweise mit einem 

lokalen Netzwerk (LAN) und nur gelegentlich über eine langsame Netzwerkverbindung verbinden, ist 

diese Standardeinstellung meist akzeptabel. Wenn es hingegen Netzwerkclients gibt, die sich nahezu 

immer über eine langsame Verbindung mit dem Netzwerk verbinden, können Sie diese Clients gesondert 

konfigurieren.


Eine Möglichkeit besteht darin, die standardmäßige Softwareverteilung zu belassen wie sie ist, jedoch 

eine vollständige Installation der Software zu erzwingen, wenn sich der Benutzer mit dem LAN 

verbindet. Sie können diese Option wählen, wenn sich Clients gelegentlich mit Ihrem LAN verbinden. 

Wenn sich Clients nie mit dem LAN verbinden, müssen Sie zur Verteilung von Software eine 

Methode außerhalb von Active Directory wählen. Sie können beispielsweise Software mithilfe von 

Wechseldatenträgern oder über eine sichere Website verteilen, wenn die Clients eine schnelle Internetverbindung 

haben und sich normalerweise über eine langsame VPN-Verbindung (Virtuelles privates 

Netzwerk) mit Active Directory verbinden. 

Die meisten Großunternehmen verfügen für die Einrichtung von Arbeitsstationen über einen automatisierten 

Prozess. Zum schnellen Einrichten eines Standarddesktops für Benutzer können Technologien 

zum Klonen von Datenträgern oder die Windows-Bereitstellungsdienste eingesetzt werden. Sie 

können diesen Ansatz mit Gruppenrichtlinien kombinieren, um die Verteilung von Software umfassend 

zu optimieren. Wenn Sie beispielsweise mit einem Tool zum Klonen von Datenträgern zum Einrichten 

von Clientarbeitsstationen arbeiten, können Sie den Clientcomputer einrichten und anschließend 

mithilfe eines Gruppenrichtlinienobjekts auf jeder Arbeitsstation einen Standardsatz von 

Anwendungen installieren. Wenn dieses Image auf Arbeitsstationen bereitgestellt wird, können diese 

Anwendungen mithilfe von Gruppenrichtlinien verwaltet werden. Wenn Sie Clientcomputer über die 

Windows-Bereitstellungsdienste installieren, können Sie die verwaltete Anwendung in das dazugehörige 

Image für jede Abteilung einbeziehen. 

Der wichtigste Schritt bei der Vorbereitung eines Gruppenrichtlinienobjekts zum Bereitstellen von 

Software ist das sorgfältige Testen jeder Softwareverteilung vor der Bereitstellung. Viele Unternehmen, 

die Software mithilfe von Gruppenrichtlinien verteilen, arbeiten mit einer Verteilungstestumgebung 

mit Arbeitsstationen, die für die Arbeitsstationen in der Produktionsumgebung repräsentativ 

sind. Sie können in Active Directory problemlos eine Testorganisationseinheit erstellen und diese 

Computerkonten und verschiedene Testbenutzerkonten in diese Organisationseinheit verschieben. 

Anschließend können Sie in dieser Testumgebung jede Softwareverteilung testen. 

Einschränkungen beim Einsatz von Gruppenrichtlinien zum Verwalten 

von Software 

Wenngleich Gruppenrichtlinien leistungsstarke Instrumente zum Verwalten von Software auf Clientcomputern 

sind, unterliegt diese Technologie gewissen Einschränkungen, die insbesondere beim Vergleich 

mit Softwareverwaltungstools wie Microsoft Systems Management Server (SMS) oder System 

Center Configuration Manager (SCCM) offenkundig werden. 

Eine der stärksten Einschränkungen für viele Unternehmen ist, dass Gruppenrichtlinien nur zum Verteilen 

von Software an Active Directory-fähige Windows-Betriebssysteme genutzt werden können. 

Wenngleich diese Einschränkung immer weniger einschneidend ist, da viele Unternehmen zu den 

neuesten Betriebssystemen wechseln, gibt es in vielen Großunternehmen immer noch Clientcomputer 

mit Windows NT Workstation, Windows 95 oder Windows 98. Wenn Unternehmen mit solchen 

Clientcomputern Software mithilfe von Gruppenrichtlinien an neuere Clients verteilen möchten, 

benötigen sie weiterhin eine alternative Methode für ältere Clients. 

Eine weitere bedeutende Einschränkung für Unternehmen, die über die benötigten Clients verfügen, 

ist der Mangel an Flexibilität beim zeitlichen Planen einer Softwareinstallation. Anwendungen werden 

der Arbeitsstation erst angekündigt, nachdem sich der Benutzer erneut angemeldet hat oder der 

Computer neu gestartet wurde. Vollständig ausgestattete Softwareverteilungsprogramme wie SCCM 

bieten da andere Optionen.


Sie können SCCM beispielsweise so konfigurieren, dass ein Computer nachts mithilfe der Remoteaktivierung 

über LAN gestartet, die Software installiert und der Computer danach wieder heruntergefahren 

wird. Oder die Softwareverteilung kann für einen beliebigen Zeitpunkt am Tag geplant werden, 

ohne dass sich der Benutzer abmelden muss oder unbedingt merkt, dass die Softwareverteilung 

stattfindet. 

Eine weitere Einschränkung beim Arbeiten mit Gruppenrichtlinien zum Verteilen von Software ist, 

dass die Multicastingfähigkeiten des Netzwerks nicht unterstützt werden. Der meiste Netzwerkdatenverkehr 

erfolgt „unicast“, d.h. zwischen zwei bestimmten Computern. Beim Multicasting kann ein 

Server einen Datenstrom über das Netzwerk senden, der von mehreren Clientcomputern empfangen 

werden kann. Da die Softwareverteilung von einer Aktion auf dem Client ausgelöst wird, kann bei der 

Verteilung von Software mithilfe einer Gruppenrichtlinie Multicasting nicht verwendet werden. Durch 

Arbeiten mit Multicasting kann die Bandbreite besser genutzt werden. Wenn es beispielsweise Tausende 

von Clients in Ihrem Unternehmen gibt und Sie ein dringendes Virenschutzupdate schnell verteilen 

müssen, wird bei Wahl einer Unicastlösung auch bei einem noch so schnellen Netzwerk die 

gesamte Bandbreite belegt. Beim Multicasting wird das Softwarepaket nur einmal gesendet, woraufhin 

alle Clients im Netzwerk das Update empfangen. 

Das Nutzen eines Gruppenrichtlinienobjekts zum Verteilen von Software unterliegt ferner der 

Beschränkung, dass nur über die Zuweisung des Gruppenrichtlinienobjekts auf Containerebene oder 

durch eine auf Gruppen basierende Filterung bestimmt werden kann, welche Clients ein Softwarepaket 

empfangen sollen. Vollständig ausgestattete Softwareverteilungsprogramme wie SCCM erstellen 

eine Bestandsliste aller Clientcomputer. Diese Bestandsliste enthält Computerattribute wie Festplattenspeicher, 

CPUs und Arbeitsspeicher sowie auf den Computern installierte Software. Sie können 

anschließend mithilfe dieser Bestandsliste bestimmen, welche Clientcomputer ein bestimmtes Softwarepaket 

empfangen sollen. Sie können beispielsweise die neueste Version von Office ausschließlich 

auf den Arbeitsstationen installieren, die die Anforderung an Festplatten- und Arbeitsspeicher 

erfüllen. 

Ein weiterer wichtiger Aspekt bei der Softwareverteilung ist in einigen Unternehmen der Umgang mit 

vom Netzwerk getrennten Clients. Diese Unternehmen haben sehr viele Clientcomputer, die sich nur 

gelegentlich mit dem Unternehmensnetzwerk verbinden, und zwar nur über eine DFÜ- oder VPN- 

Verbindung. Ein vollständig ausgestattetes Softwareverteilungstool kann mit diesen Clients auf verschiedene 

Weisen umgehen. Eine Option ist das Bereitstellen einer Website, die zum Installieren der 

Software und ihrer Verwaltung nach der Installation genutzt werden kann. Eine weitere Möglichkeit 

ist das Bereitstellen einer sehr intelligenten Verwaltung der Softwareverteilung, wenn der Client mit 

dem Netzwerk verbunden ist. Sie können beispielsweise Software an alle DFÜ-Clients verteilen und 

damit die Größe der Bandbreite strikt begrenzen, die der Softwareverteilungsprozess nutzen kann. 

Der Softwareverteilungsprozess kann ferner erkennen, ob die Netzwerkverbindung unterbrochen ist, 

und die Softwareverteilung an der Stelle neu starten, an der die Verbindung unterbrochen wurde, 

wenn sich der Benutzer das nächste Mal mit dem Netzwerk verbindet. 

Wie diese Übersicht der Einschränkungen zeigt, steht beim Einsatz von Gruppenrichtlinien zur Verwaltung 

von Software nicht die umfassende Funktionalität zur Verfügung, die Sie sich ggf. von einem 

Tool für die Softwareverteilung wünschen. Doch in kleinen und mittelgroßen Unternehmen können 

mit Gruppenrichtlinien viele Softwareverteilungsaufgaben erledigt werden. In vielen Unternehmen 

steht deshalb der Kosten-/Nutzen-Aspekt von Gruppenrichtlinien im Vordergrund, insbesondere im 

Vergleich zu den rechten hohen Clientlizenzierungskosten der beiden anderen Tools.


Übersicht über Gruppenrichtlinieneinstellungen 

Gruppenrichtlinieneinstellungen ist eine Zusammenstellung verschiedener neuer clientseitiger Erweiterungen 

unter Windows Server 2008, die eine zentrale Konfiguration und Verwaltung von Betriebssystem- 

und Anwendungseinstellungen ermöglicht. Viele dieser Einstellungen wurden bislang nicht 

mithilfe von Gruppenrichtlinien konfiguriert und mussten über andere Methoden wie Anmeldeskripts 

aktiviert werden. Wenn Sie beispielsweise eine Laufwerkzuordnung zu einer Netzwerkfreigabe konfigurieren 

oder einer Arbeitsstation bestimmte Umgebungsvariablen zuweisen wollten, mussten Sie 

Anmeldeskripts erstellen, testen und anschließend Benutzerkonten zuweisen oder ein Gruppenrichtlinienobjekt 

für die Skripterstellung mit einem Active Directory-Container verknüpfen. Der Hauptnachteil 

von Skripts ist, dass viele Unternehmen am Ende mit komplexen Anmeldeskripts dastehen, 

die ständig geändert und korrigiert werden müssen. Und in den meisten Unternehmen gibt es meist 

nur ein oder zwei Mitarbeiter, die überhaupt wissen, welche Aufgaben die Skripts haben, sowie nur 

eine sehr minimale Dokumentation zur Beschreibung der Skriptaktionen. Das Feature Gruppenrichtlinieneinstellungen 

hat die Aufgabe, Anmeldeskripts in Ihrem Unternehmen vollständig oder zumindest 

teilweise überflüssig zu machen. 

Das Feature Gruppenrichtlinieneinstellungen im Vergleich zu 

Richtlinieneinstellungen 

Um bestimmen zu können, ob die Funktion Einstellungen oder die Funktion Richtlinieneinstellungen 

zum Verwalten eines Clientcomputers verwendet werden soll, müssen Sie mit den Unterschieden zwischen 

diesen Funktionen vertraut sein, die sich vor allem auf zwei Bereiche beziehen: 

• Erzwingung Wenn Sie eine Gruppenrichtlinieneinstellung konfigurieren, wird sie für alle dem 

Gruppenrichtlinienobjekt zugewiesenen Benutzer bzw. Computer erzwungen. In der Regel deaktiviert 

jedes gruppenrichtlinienfähige Anwendungs- oder Betriebssystemfeature die Benutzeroberfläche 

so, dass Benutzer am Ändern der verwalteten Einstellungen gehindert werden. Diese 

Erzwingung wird in regelmäßigen Abständen aktualisiert. Wenn Sie hingegen eine Einstellung in 

Gruppenrichtlinieneinstellung konfigurieren, wird die Konfiguration nicht streng erzwungen, 

sodass Benutzer ihren Anforderungen entsprechend Änderungen vornehmen können. Sie können 

Einstellungen so konfigurieren, dass sie einmal angewendet oder während des standardmäßigen 

Aktualisierungsintervalls des Features Gruppenrichtlinie erneut angewendet werden. 

• Zielgruppenadressierung Eine der Einschränkungen von Gruppenrichtlinieneinstellungen besteht 

darin, dass Sie in einem Gruppenrichtlinienobjekt einzelne Einstellungen nicht filtern können. Die 

einzige Möglichkeit ist das Erstellen spezifischer Gruppenrichtlinienobjekte pro Richtlinieneinstellung 

und anschließende Anwenden des Gruppenrichtlinienobjekts über die WMI- (Windows 

Management Instrumentation) oder Sicherheitsgruppenfilterung. Das Feature Einstellungen bietet 

jedoch die Möglichkeit, die Zielgruppe auf Elementebene zu bestimmen. Angenommen, Sie 

haben eine Einstellung, über die Laufwerkzuordnungen zwei getrennten Abteilungen zugewiesen 

werden sollen. Sie können in einem einzelnen Gruppenrichtlinienobjekt eine Einstellung für die 

eine Abteilung und eine zweite Einstellung für die zweite Abteilung konfigurieren.

Übersicht über Gruppenrichtlinieneinstellungen 497 

Tabelle 12.10 zeigt eine Übersicht der Unterschiede zwischen Richtlinieneinstellungen und der 

Funktion Einstellungen. 

Tabelle 12.10 

Vergleich zwischen Richtlinieneinstellungen und der Funktion Einstellungen 

Funktionalität Richtlinieneinstellungen Einstellungen 

Erzwingung 

• Einstellungen werden erzwungen 

• Die Benutzeroberfläche wird deaktiviert 

• Einstellungen werden aktualisiert 

• Erfordert gruppenrichtlinienfähige 

Features und Anwendungen 

• Einstellungen werden nicht erzwungen 

• Die Benutzeroberfläche wird nicht 

deaktiviert 

• Kann so konfiguriert werden, dass die 

Einstellungen nur einmal angewendet 

oder in regelmäßigen Abständen aktualisiert 

werden 

• Erfordert keine gruppenrichtlinienfähigen 

Features und Anwendungen 

Unterstützung lokaler Gruppenrichtlinienobjekte 

Zielgruppenadressierung und 

Filterung 

Lokale Gruppenrichtlinien werden unterstützt 

Unterstützt die Filterung nur auf Gruppenrichtlinienobjekt-Ebene 

(über WMIoder 

Sicherheitsgruppenfilterung) 

Gruppenrichtlinieneinstellungen in Einstellungen 

Lokale Gruppenrichtlinien werden nicht 

unterstützt 

Unterstützt die Zielgruppenadressierung 

auf Elementebene 

Gruppenrichtlinieneinstellungen stellen Windows- und Systemsteuerungseinstellungen bereit. 

Windows-Einstellungen bestehen aus vielen Optionen, die zuvor mithilfe von Skripts konfiguriert 

wurden, z.B. Laufwerkzuordnungen, Registrierungseinstellungen und Umgebungsvariablen. Systemsteuerungseinstellungen 

sind Optionen, die normalerweise in der Systemsteuerung eines Windows- 

Computers konfiguriert werden, z.B. Ordner- und Energieverwaltungsoptionen, lokale Benutzer und 

Gruppen sowie Einstellungen im Menü Start. 

Windows-Einstellungen 

In Tabelle 12.11 und Abbildung 12.23 finden Sie eine Beschreibung und Darstellung der unter Windows-Einstellungen 

verfügbaren Einstellungen. 

Tabelle 12.11 

Einstellung 

Umgebung 

Dateien 

Ordner 

Für Windows-Einstellungen verfügbare Einstellungen 

Beschreibung 

Dient zum Erstellen von Benutzer- oder Systemumgebungsvariablen sowie zum 

Ändern oder Ersetzen vorhandener Umgebungsvariablen. 

Dient zum Kopieren von Dateien an einen neuen Speicherort und Konfigurieren 

von Attributen. Sie können auch vorhandene Dateien und Dateiattribute ändern 

oder löschen. 

Dient zum Erstellen, Ändern oder Löschen von Ordnern und Ordnerattributen. Sie 

können diese Einstellung so konfigurieren, dass alle Dateien in einem bestimmten 

Ordner gelöscht werden, ohne den Ordner zu löschen (nützlich für das Verwalten 

des Ordners mit den temporären Dateien).


Tabelle 12.11 

Für Windows-Einstellungen verfügbare Einstellungen (Fortsetzung) 

Einstellung 

INI-Dateien 

Registrierung 

Netzwerkfreigaben (nur unter Computerkonfiguration) 

Verknüpfungen 

Anwendungen (nur unter Benutzerkonfiguration) 

Laufwerkzuordnungen (nur unter Benutzerkonfiguration) 

Beschreibung 

Dient zum Hinzufügen, Ersetzen oder Löschen von Abschnitten oder Eigenschaften 

in bestimmten INI- oder INF-Dateien. Über diese Einstellung können Sie 

auch eine gesamte INI- oder INF-Datei löschen. 

Diese Einstellung dient zum Kopieren, Erstellen, Ersetzen oder Löschen von Registrierungsschlüsseln 

oder -werten. 

Diese Einstellung dient zum Erstellen, Ändern oder Angeben von Einstellungen 

wie Benutzerbegrenzungen, zugriffsbasierte Aufzählung und Kommentare für 

Netzwerkfreigaben. 

Dient zum Erstellen, Ändern oder Löschen von Verknüpfungen auf dem Computer 

eines Benutzers. Verknüpfungen können herkömmliche Verknüpfungen, URLs 

oder Verknüpfungen zu Shellobjekten wie der Systemsteuerung enthalten. 

Ermöglich die Konfiguration von Einstellungen für Anwendungen. Diese Einstellung 

erfordert ein vom Anwendungshersteller bereitgestelltes oder Ihrem Softwareentwickler 

entwickeltes Anwendungs-Plug-In. 

Ermöglicht das Erstellen, Ändern oder Löschen von Laufwerkzuordnungen. 


Anzeigen von Einstellungen unter Windows-Einstellungen


Systemsteuerungseinstellungen 

Tabelle 12.12 und Abbildung 12.24 zeigen die unter Systemsteuerungseinstellungen verfügbaren Einstellungen. 

Tabelle 12.12 

Für Systemsteuerungseinstellungen verfügbare Einstellungen 

Einstellung 

Datenquellen 

Geräte 

Ordneroptionen 

Interneteinstellungen (nur Benutzerkonfiguration) 

Lokale Benutzer und Gruppen 

Netzwerkoptionen 

Energieoptionen 

Drucker 

Regionale Einstellungen (nur Benutzerkonfiguration) 

Geplante Aufgaben 

Startmenü (nur Benutzerkonfiguration) 

Dienste (nur Computerkonfiguration) 

Beschreibung 

Ermöglicht die zentrale Konfiguration von ODBC-Datenquellennamen (Open 

Database Connectivity) für Benutzer oder Computer. 

Ermöglicht das Aktivieren bzw. Deaktivieren bestimmter Typen von Hardwaregeräten, 

z.B. USB-Ports oder Diskettenlaufwerke. 

Ermöglicht die Konfiguration verschiedener Windows Explorer-Einstellungen, 

z.B. Dateiverknüpfungen und Ordneransichtsoptionen. 

Dient zum Konfigurieren von Ausgangseinstellungen für Internet Explorer. 

Ermöglicht die zentrale Verwaltung lokaler Benutzer sowie von Mitgliedern 

lokaler Gruppen auf Domänenmitgliedscomputern. 

Dient zum Konfigurieren von VPN- und DFÜ-Netzwerkverbindungseinstellungen. 

Dient zum Konfigurieren von Windows Server 2003- und Windows XP-Energieverwaltungseinstellungen. 

Dient zum Erstellen, Konfigurieren und Löschen von lokalen, freigegebenen 

und Netzwerkdruckern. 

Ermöglicht die Konfiguration regionaler Einstellungen für Anwendungen, z.B. 

Zahlen-, Währungs-, Datums- und Uhrzeitformate. 

Ermöglicht das Erstellen, Ändern oder Löschen einer geplanten Aufgabe. Sie 

können auch angeben, dass beim nächsten Aktualisierungsintervall von 

Gruppenrichtlinien oder bei jedem Aktualisierungszyklus ein Befehl ausgeführt 

werden soll. 

Dient zum Konfigurieren von Startmenüeinstellungen für Windows XP- und 

Windows Vista-Computer. 

Dient zum Konfigurieren und Verwalten von Diensten, die auf dem Computer 

verfügbar sind.



Anzeigen von Einstellungen unter Systemsteuerungseinstellungen 

Optionen für das Feature Gruppenrichtlinieneinstellungen 

Viele der Objekte in Gruppenrichtlinieneinstellungen enthalten allgemeine Aktionen und Optionen 

zur Verarbeitung des jeweiligen Einstellungselements. Sie können beispielsweise Einstellungselemente 

erstellen, die bei Verarbeitung während des Aktualisierungszyklus von Gruppenrichtlinieneinstellungen 

eine der folgenden Aktionen ausführen: 

• Erstellen Ein neues Element bzw. eine neue Einstellung wird erstellt und angewendet. 

• Ersetzen Ein vorhandenes Element wird entfernt und durch das konfigurierte Einstellungselement 

ersetzt. 

• Aktualisieren Ein vorhandenes Einstellungselement wird geändert bzw. erstellt, falls es nicht vorhanden 

ist. 

• Löschen Ein vorhandenes Element bzw. eine vorhandene Einstellung wird entfernt. 

Jedes Einstellungselement weist auch die Registerkarte Gemeinsam auf, die verschiedene Optionen 

für die Verarbeitung enthält (siehe Abbildung 12.25).



Anzeigen der Einstellungen auf der Registerkarte Gemeinsam 

Tabelle 12.13 beschreibt die Optionen auf der Registerkarte Gemeinsam, die es für jedes Einstellungselement 

gibt. 

Tabelle 12.13 

Gemeinsame Optionen für Gruppenrichtlinieneinstellungen 

Option 

Elementverarbeitung in dieser Erweiterung 

bei Fehler stoppen 

Im Sicherheitskontext des angemeldeten Benutzers 

ausführen (Benutzerrichtlinienoption) 

Element entfernen, wenn es nicht mehr angewendet 

wird 

Nur einmalig anwenden 

Beschreibung 

Diese Option beendet die Verarbeitung dieser bestimmten Erweiterung, wenn 

ein Fehler im Gruppenrichtlinienobjekt selbst auftritt. Wenn eine bestimmte 

Erweiterung nicht verarbeitet werden kann, werden alle anderen Erweiterungen 

standardmäßig der Konfiguration entsprechend weiter verarbeitet. 

Das lokale Konto System wird standardmäßig als Sicherheitskontext für die 

Verarbeitung von Gruppenrichtlinienobjekten verwendet. Wenn Sie Zugriff auf 

Umgebungsvariablen und Netzwerkressourcen benötigen, müssen Sie diese 

Option für die Ausführung im Sicherheitskontext des angemeldeten Benutzers 

aktivieren. 

Einstellungen werden standardmäßig nicht entfernt, wenn ein Gruppenrichtlinienobjekt 

nicht mehr für den Benutzer oder Computer gilt. Bei Wahl dieser 

Option ändert sich dieses Verhalten. 

Gruppenrichtlinieneinstellungen werden standardmäßig alle 90 Minuten aktualisiert. 

Demzufolge werden sämtliche Richtlinieneinstellungen bzw. Einstellungen 

während des Aktualisierungszyklus erneut angewendet. Bei Wahl 

dieser Option wird das Einstellungselement nur während des ersten Richtlinienaktualisierungszyklus 

und anschließend nicht noch einmal angewendet. 

Dadurch können die Endbenutzer die Einstellungen ihren Vorstellungen entsprechend 

ändern.


Tabelle 12.13 

Gemeinsame Optionen für Gruppenrichtlinieneinstellungen (Fortsetzung) 

Option 

Zielgruppenadressierung auf Elementebene 

Beschreibung 

Die Zielgruppenadressierung auf Elementebene ermöglicht das Erstellen von 

Filtern basierend auf verschiedenen Attributen wie Benutzername, Speicherplatz 

und Betriebssystem. Abbildung 12.26 zeigt ein Beispiel eines Ziels für 

alle Computer mit mindestens 80 GB freiem Speicherplatz auf Laufwerk C. 


Konfigurieren der Zielgruppenadressierung auf Elementebene 

Hinweis Sie können die clientseitige Erweiterung Gruppenrichtlinieneinstellungen auf allen Computern 

bereitstellen, auf denen Sie diese Einstellungen nutzen möchten. Die clientseitige Erweiterung ist in Windows 

Server 2008 bereits enthalten, muss aber für Microsoft Windows XP mit SP2, Windows Vista und 

Windows Server 2003 mit SP1 getrennt heruntergeladen werden. 

Hinweis In vielen Feldern in Gruppenrichtlinieneinstellungen können Umgebungsvariablen angegeben 

werden. Sie können eine Liste verfügbarer Variablen anzeigen, indem Sie den Cursor in einem Feld platzieren 

und F3 drücken. Das in Abbildung 12.27 gezeigte Dialogfeld Variable auswählen wird geöffnet.



Auswählen vom System definierter Variablen 


Windows Server 2008 bietet zahlreiche aktualisierte und verbesserte Features für die Verwaltung von 

Benutzerdesktops. Mithilfe von Gruppenrichtlinien können Benutzerdaten und Profile so verwaltet 

werden, dass den Benutzern bei zentraler Verwaltung eine vertraute Arbeitsumgebung zur Verfügung 

gestellt wird. Gruppenrichtlinien sind außerdem leistungsstarke Instrumente für die Bereitstellung und 

Verwaltung von Software auf Arbeitsstationen. Mithilfe der Gruppenrichtlinien- und Windows Installer-Technologie 

können Sie Software auf Arbeitsstationen bereitstellen und diese Software anschließend 

in ihrem gesamten Lebenszyklus verwalten. Gruppenrichtlinieneinstellungen bieten eine einfache 

Möglichkeit zum Konfigurieren von Betriebssystem- und Anwendungseinstellungen, die zuvor 

mithilfe von Anmeldeskripts angewendet werden mussten. Dieses Kapitel bot einen Überblick darüber, 

wie Sie diese Optionen zur Verwaltung von Benutzerdesktops implementieren können.




Kapitel. 


• Kapitel 11, „Einführung in Gruppenrichtlinien“, bietet Einzelheiten zur Architektur und Konfiguration 

von Gruppenrichtlinienobjekten. 

• „Managing Group Policy ADMX Files Step-by-Step Guide“ (englischsprachig) unter 

http://go.microsoft.com/fwlink/?LinkId=75124 

• „Group Policy Preferences Overview“ (englischsprachig) unter http://www.microsoft.com/downloads/details.aspx?familyid=42E30E3F-6F01-4610-9D6E-F6E0FB7A0790&displaylang=en 

• „Group Policy Wiki“ (englischsprachig) unter http://grouppolicy.editme.com/ 

• „Group Policy Team Blog“ (englischsprachig) unter http://blogs.technet.com/GroupPolicy/ 

• „Deploying a Managed Software Environment“ (englischsprachig) unter http://technet2.microsoft.com/windowsserver/en/library/3ddda5bf-cf67-4408-b68c-7e1fcb5e47ee1033.mspx?mfr=true 

• „Use Group Policy Software Installation to Deploy the 2007 Office System“ (englischsprachig) 

unter http://technet2.microsoft.com/Office/en-us/library/efd0ee45-9605-42d3-9798- 

3b698fff3e081033.mspx?mfr=true 

• „Managing Roaming User Data Deployment Guide“ (englischsprachig) unter http://www.micro- 

soft.com/downloads/details.aspx?\1displaylang=en&familyid=311f4be8-9983-4ab0-9685- 

f1bfec1e7d62&displaylang=en 

• „Windows Server Group Policy“ (englischsprachig) unter http://technet.microsoft.com/en-us/ 

windowsserver/grouppolicy/default.aspx 

• „ADMX Migrator“ (englischsprachig) unter http://www.microsoft.com/downloads/ 

details.aspx?FamilyId=0F1EEC3D-10C4-4B5F-9625-97C2F731090C&displaylang=en 

Auf der Begleit-CD 

• LonghornGPSettings.xls: Enthält alle Gruppenrichtlinieneinstellungen, die seit Windows Server 

2008 Beta 3 zur Verfügung stehen.

505 

K A P I T E L 1 3 

Einsetzen von Gruppenrichtlinien zum 

Verwalten der Sicherheit 


Konfigurieren der Domänensicherheit mit Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 

Verstärken der Serversicherheit mithilfe von Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 

Konfigurieren der Netzwerksicherheit mit Gruppenrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 

Konfigurieren von Sicherheitseinstellungen anhand von Sicherheitsvorlagen. . . . . . . . . . . . . . . . . . . . . . . . 534 



Eine der wichtigsten Verwaltungsaufgaben in der Desktop- und Serververwaltung ist das Konfigurieren 

sowie Gewährleisten der Sicherheit. Die Gewährleistung einer konsistenten Sicherheitskonfiguration 

für Tausende von Computern innerhalb einer Organisation ist ohne eine Form der zentralen Verwaltung 

nahezu unmöglich. Mithilfe der Gruppenrichtlinien kann diese zentrale Verwaltung zum 

Schützen der Einstellungen auf Domänenebene, serverbasierter Sicherheitseinstellungen und Netzwerkkommunikations-Sicherheitseinstellungen 

eingerichtet werden. 

In diesem Kapitel erfahren Sie, wie Sie die Gruppenrichtlinien zum Konfigurieren und Bereitstellen 

domänenbasierter Sicherheitseinstellungen wie etwa Konto- und Kennwortrichtlinien einsetzen können. 

Zunächst werden die Standarddomänenrichtlinie sowie die Standardrichtlinie für Domänencontroller 

beschrieben. Anschließend wird erörtert, wie Sicherheit und Verwaltbarkeit mithilfe fein 

abgestimmter Kennwortrichtlinien gesteigert werden. Darüber hinaus werden in diesem Kapitel 

zusätzliche Sicherheitsszenarien auf Gruppenrichtlinienbasis beschrieben, z.B. das Sichern von verkabelten 

und drahtlosen Netzwerken sowie das Konfigurieren von Windows-Firewall und IPsec-Sicherheitsfunktionen. 

Schließlich liefert dieses Kapitel Informationen zum Konfigurieren und Bereitstellen 

von Sicherheitsvorlagen zur Unterstützung der Verwaltung von Sicherheitseinstellungen in der 

gesamten Netzwerkumgebung. 

Konfigurieren der Domänensicherheit mit Gruppenrichtlinien 

Während der Installation der Active Directory-Domänendienste werden zwei standardmäßige Gruppenrichtlinienobjekte 

(Group Policy Objects, GPOs) zum Bereitstellen der anfänglichen Sicherheitskonfigurationen 

für die Domäne und die Domänencontroller in der Umgebung erstellt. In den nächsten 

beiden Abschnitten werden die innerhalb dieser Gruppenrichtlinienobjekte konfigurierten 

Sicherheitseinstellungen beschrieben.

506 Kapitel 13: Einsetzen von Gruppenrichtlinien zum Verwalten der Sicherheit 

Übersicht über die Standarddomänenrichtlinie 

Das GPO Default Domain Policy liefert die anfänglichen Sicherheitseinstellungen für die gesamte 

Domäne. Diese anfänglichen Sicherheitseinstellungen beziehen sich speziell auf die Knoten Kontorichtlinien 

und Lokale Richtlinien unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\ 

Sicherheitseinstellungen. Abbildung 13.1 zeigt die in diesen beiden Knoten enthaltenen Einstellungen 

an. 


Anzeigen der Knoten Kontorichtlinien und Lokale Richtlinien 

Kontorichtlinien 

Der Abschnitt Kontorichtlinien umfasst drei Kategorien: Kennwortrichtlinie, Kontosperrungsrichtlinie 

und Kerberos-Richtlinie. Mit Ausnahme der Kerberos-Richtlinie gelten diese Richtlinien für alle 

Benutzer in der Domäne, unabhängig davon, an welchem Arbeitsstationstyp sich die Benutzer anmelden. 

Die Kerberos-Richtlinieneinstellungen gelten nur für Computer in der Domäne, auf denen 

Windows 2000, Windows XP Professional, Windows Server 2003/2008 sowie Business- und Enterprise-Versionen 

von Windows Vista ausgeführt werden. 

Kennwortrichtlinie 

Die Konfigurationsoptionen für die Kennwortrichtlinie enthalten in der gesamten Domäne gültige 

Einstellungen für Kennwortchronik, Alter, Länge und Komplexität der Kennwörter. In Tabelle 13.1 

wird jede Einstellung beschrieben. 

Tabelle 13.1 

Kennwortrichtlinie 

Konfigurationseinstellung Beschreibung Standardwert 

Kennwortchronik erzwingen Definiert die Anzahl neuer Kennwörter, die eindeutig 

sein müssen, bevor ein Benutzer ein altes 

Kennwort wiederverwenden kann. 

Mögliche Werte: 0 bis 24 

24 gespeicherte Kennwörter für 

Domänencontroller und Computer von 

Mitgliedern der Domäne; 0 für eigenständige 

Server. 

Maximales Kennwortalter Legt fest, wie viel Tage ein Kennwort verwendet 

werden kann, bevor der Benutzer es ändern 

muss. Um Kennwörter zu konfigurieren, die nie 

ablaufen, setzen Sie die Anzahl der Tage auf 0. 


42 Tage

Konfigurieren der Domänensicherheit mit Gruppenrichtlinien 507 

Tabelle 13.1 

Kennwortrichtlinie (Fortsetzung) 


Minimales Kennwortalter 

Minimale Kennwortlänge 

Kennwörter müssen den 

Komplexitätsanforderungen 

entsprechen 

Kennwort mit umkehrbarer 

Verschlüsselung speichern 

Legt fest, wie viel Tage ein Kennwort verwendet 

werden muss, bevor ein Benutzer es ändern 

kann. Um sofortige Änderungen zu ermöglichen, 

legen Sie den Wert 0 fest. 


Definiert die minimale Zeichenanzahl für Kennwörter. 

Ist kein Kennwort erforderlich, setzen Sie 

den Wert auf 0. 


Steigert die Kennwortkomplexität, indem erzwungen 

wird, dass Kennwörter keinen Teil des Benutzerkontennamens 

oder Teile des vollständigen 

Benutzernamens enthalten, die aus mehr als zwei 

aufeinander folgenden Zeichen bestehen; Kennwörter 

mindestens 6 Zeichen lang sind und Zeichen 

aus drei der vier folgenden Kategorien 

enthalten: 

Großbuchstaben (A-Z) 

Kleinbuchstaben (a-z) 

Ziffern zur Basis 10 (0-9) 

Sonderzeichen (z.B.: !, $, #, %) 

Die Anforderungen werden beim Erstellen oder 

Ändern von Kennwörtern erzwungen. 

Die Verwendung dieser Einstellung entspricht 

dem Speichern von Kennwörtern in Klartext. 

Diese Richtlinie unterstützt Anwendungen mit 

Verwendung von Protokollen, die zur Authentifizierung 

Zugriff auf Benutzerkennwörter erfordern. 

Diese Einstellung wird in der Regel bei der Implementierung 

von CHAP (Challenge-Handshake 

Authentication Protocol) mittels Remotezugriff 

oder Internetauthentifizierungsdiensten verwendet 

und ist ebenfalls erforderlich, wenn Sie in 

den Internetinformationsdiensten (Internet 

Information Services, IIS) die Digestauthentifizierung 

verwenden. 

1 Tag für Domänencontroller und Mitgliedscomputern 

der Domäne; 0 für 

eigenständige Server. 

7 Zeichen für Domänencontroller und 

Mitgliedscomputer der Domäne; 0 für 

eigenständige Server. 

Für Domänencontroller und Mitgliedscomputer 

der Domäne; für eigenständige 

Server deaktiviert. 

Deaktiviert 

Direkt von der Quelle: Verwenden benutzerdefinierter Kennwortfilter 

Sie können benutzerdefinierte Kennwortfilter verwenden, um zu definieren, was ein komplexes 

Kennwort ausmacht. Sie können z.B. verhindern, dass bestimmte Schlüsselwörter (etwa Name 

oder Standort eines Unternehmens) in Kennwörter einbezogen werden. Sie können ferner den 

Komplexitätsgrad zur Definition eines komplexen Kennworts steigern oder senken.


Diese Kennwortfilter sind mit den in Windows Server 2008 neu eingeführten fein abgestimmten 

Kennwortrichtlinien einsetzbar. Das Plattform-SDK umfasst eine Beispiel-DLL für benutzerdefinierte 

Kennwörter. Weitere Informationen (in englischer Sprache) finden Sie im Artikel unter http:/ 

/msdn2.microsoft.com/en-us/library/ms721884.aspx. 

Gautam Anand 

Technical Lead – Directory Services 

Premier Enterprise Platforms Support 

Kontosperrungsrichtlinien Die Konfigurationsoptionen der Kontosperrungsrichtlinien enthalten Einstellungen 

für die Kennwortsperrdauer und den Schwellenwert sowie für das Zurücksetzen des Kontosperrungszählers. 

In Tabelle 13.2 wird jede Einstellung beschrieben. 

Tabelle 13.2 

Kontosperrungsrichtlinien 


Kontosperrdauer 

Legt fest, für wie viel Minuten ein gesperrtes 

Konto gesperrt bleibt. Nach Ablauf der festgelegten 

Anzahl an Minuten wird das Konto automatisch 

entsperrt. Um festzulegen, dass ein 


Legen Sie als Wert 30 Minuten fest, 

falls Kontensperrungsschwelle auf 1 

oder höher gesetzt ist. 

Administrator das Konto entsperren muss, setzen 

Sie den Wert auf 0. Jeder Wert ungleich Null 

muss mindestens so groß sein wie der Wert für 

Kontosperrungszähler zurücksetzen nach. 

Mögliche Werte: 0 bis 99.999 

Kontensperrungsschwelle Legt die Anzahl zulässiger fehlgeschlagener 

Anmeldeversuche vor dem Sperren eines Benutzerkontos 

fest. Der Wert 0 bedeutet, dass das 

Konto nie gesperrt wird. 


0 ungültige Anmeldeversuche 

Kontosperrungszähler zurücksetzen 

nach 

Legt fest, wie viel Minuten nach einem fehlgeschlagenen 

Anmeldeversuch verstreichen 

müssen, bevor der Zähler für ungültige Anmeldeversuche 

auf 0 zurückgesetzt wird. Jeder Wert 

ungleich Null darf höchstens so groß sein wie 

der Wert für Kontosperrdauer. 



Legen Sie als Wert 30 Minuten fest, 

falls Kontensperrungsschwelle auf 1 

oder höher gesetzt ist. 

Kerberos-Richtlinie Die Konfigurationsoptionen für die Kerberos-Richtlinie enthalten Einstellungen 

für das Kerberos-TGT (Ticket-Granting Ticket) sowie die Gültigkeitsdauer von Sitzungstickets und 

Zeitstempeleinstellungen. In Tabelle 13.3 wird jede Einstellung beschrieben. 

Tabelle 13.3 

Kerberos-Richtlinien 


Benutzeranmeldeeinschränkungen 

erzwingen 

Weist das Schlüsselverteilungscenter (Key Distribution 

Center, KDC) zum Überprüfen jeder Anforderung eines 

Sitzungsticket anhand der Richtlinie Benutzerrechte des 

Zielcomputers an. 

Aktiviert


Tabelle 13.3 

Kerberos-Richtlinien (Fortsetzung) 


600 Minuten (10 Stunden) 

Maximale Gültigkeitsdauer des 

Diensttickets 

Max. Gültigkeitsdauer des 

Benutzertickets 

Max. Zeitraum, in dem ein 

Benutzerticket erneuert werden 

kann 

Max. Toleranz für die Synchronisation 

des Computertakts 

Legt fest, wie viel Minuten lang ein Dienstticket maximal 

für den Zugriff auf eine Ressource gültig ist. Mögliche 

Werte: mehr als 10 Minuten bis zu einem Wert, der (in Minuten) 

höchstens der Einstellung Maximale Gültigkeitsdauer 

des Benutzertickets entspricht, jedoch 99.999 nicht 

übersteigt. Die Festlegung des Wertes 0 hat zur Folge, 

dass das Ticket niemals abläuft, der Wert für Maximale 

Gültigkeitsdauer des Benutzertickets auf 1 und Max. Zeitraum, 

in dem ein Benutzerticket erneuert werden kann auf 

23 gesetzt wird. 

Legt den maximalen Zeitraum für die Nutzung eines TGT 

in Stunden fest. Nach Ablauf muss die Arbeitsstation ein 

neues TGT abrufen. 


Der Wert 0 gibt an, dass das Ticket nicht abläuft, und 

setzt Max. Zeitraum, in dem ein Benutzerticket erneuert 

werden kann auf Nicht definiert. 

Legt den maximalen Zeitraum für die Erneuerung des 

TGT eines Benutzers in Tagen fest. Während dieses Zeitraums 

kann ein TGT erneuert werden, sodass kein neues 

Ticket erforderlich ist. Der Wert 0 gibt an, dass die Ticketerneuerung 

deaktiviert ist. 

Legt in Minuten fest, welchen Zeitunterschied Kerberos 

zwischen der Uhr des Clientcomputers und der Uhr des 

Domänencontrollers toleriert. Beachten Sie, dass diese 

Einstellung bei jedem Neustart des Computers auf den 

Standardwert zurückgesetzt wird. 

10 Stunden 

7 Tage 

5 Minuten 

Kontorichtlinien, die im GPO Default Domain Policy konfiguriert werden, betreffen alle Benutzer 

und Computer in der Domäne. Es ist möglich, ein mit Kontorichtlinieneinstellungen konfiguriertes 

benutzerdefiniertes GPO zu erstellen und mit einer Organisationseinheit (Organization Unit, OU) zu 

verknüpfen; die konfigurierten Einstellungen wirken sich jedoch nicht auf Benutzer aus, die sich an 

der Domäne anmelden. Falls Sie die Kontorichtlinieneinstellungen in einem spezifischen GPO konfigurieren 

und dieses mit einer OU verknüpfen, werden die Einstellungen nur auf die lokale Sicherheitsdatenbank 

für die Computer in der OU angewendet. Bei einer Konfiguration auf OU-Ebene werden 

Kontorichtlinieneinstellungen nur angewendet, wenn ein Benutzer sich lokal an einem Computer 

anmeldet. Meldet sich ein Benutzer an einer Domäne an, setzt das GPO Default Domain Policy stets 

die lokalen Richtlinieneinstellungen außer Kraft. 

Lokale Richtlinien 

Der Abschnitt Lokale Richtlinien steuert die lokalen Sicherheitseinstellungen für Computer, die sich 

innerhalb des GPOs befinden. Dazu zählen die folgenden Sicherheitseinstellungen: 

• Überwachungsrichtlinie Dieser Knoten wird zum Konfigurieren von Überwachungseinstellungen 

verwendet. Sie können Überwachungsrichtlinien für Optionen wie Kontenverwaltungsaktivitäten, 

Anmeldeereignisse, Richtlinienänderungen, Rechteverwendung und Systemereignisse festlegen.


• Zuweisen von Benutzerrechten Dieser Knoten wird zum Konfigurieren der Rechte verwendet, die 

Benutzer auf von dieser Richtlinie betroffenen Computern haben. Sie können zahlreiche Einstellungen 

vornehmen, z.B. können Sie festlegen, welche Benutzer Aktionen wie lokale Anmeldung, 

Netzwerkzugriff auf den Computer, Sichern von Dateien und Ordnern, Anmeldung als Dienst 

usw. durchführen können. 

• Sicherheitsoptionen Dieser Knoten wird zum Konfigurieren der Sicherheitsoptionen für von dieser 

Richtlinie betroffene Computer verwendet. Sie können Optionen wie die Umbenennung der 

lokalen Administrator- oder Gastkonten, die Verwaltung der zum Installieren von Druckertreibern 

berechtigten Benutzer, die Steuerung der Genehmigung zum Installieren nicht signierter Treiber 

sowie die Art und Weise der Verwaltung der Benutzerkontensteuerung auf Computern konfigurieren. 

Die Standarddomänenrichtlinie enthält nur einen kleinen Teilsatz der im Knoten Lokale Richtlinien 

definierten Einstellungen. Diese Standardeinstellungen befinden sich im Knoten Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale 

Richtlinien\Sicherheitsoptionen 

und umfassen die folgenden Einstellungen: 

• Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen Diese Einstellung ist standardmäßig 

definiert und deaktiviert. Ist diese Richtlinie aktiviert, kann ein anonymer Benutzer SID-Informationen 

über einen anderen Benutzer anfordern und dann die Sicherheitskennung (Security 

Identifier, SID) dazu verwenden, den Namen des Benutzers zu ermitteln. Dies kann zu einem 

Sicherheitsproblem werden und dazu führen, dass Informationen zu Verwaltungskonten offengelegt 

werden. 

• Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern Diese 

Einstellung ist standardmäßig definiert und aktiviert. Diese Einstellung ist aktiviert, um die 

Sicherheit zu steigern und zu verhindern, dass der LM-Hash zum Speichern von Kennwortinformationen 

verwendet wird. Beachten Sie, dass diese Einstellung die Fähigkeit zur Kommunikation 

mit Windows 95- und Windows 98-Computern beeinträchtigen kann. 

• Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit erzwingen Diese Einstellung ist standardmäßig 

definiert und deaktiviert. Mit dieser Einstellung werden Benutzer getrennt, die nach 

Ablauf ihrer gültigen Anmeldezeiten mit dem lokalen Computer verbunden sind. Ist die Richtlinie 

(wie standardmäßig) deaktiviert, kann eine eingerichtete Clientsitzung nach Ablauf der 

Anmeldezeiten aufrechterhalten werden. 

Denken Sie daran, dass auf Domänenebene konfigurierte Einstellungen alle Computer in der Domäne 

betreffen. Die meisten Organisationen benötigen unterschiedliche Überwachungsrichtlinien, Benutzerrechtezuweisungen 

oder Sicherheitsoptionen gemäß Rolle oder Typ des Computers. Aus diesem 

Grund werden die lokalen Richtlinien in der Regel auf OU-Ebene konfiguriert, damit sie ausschließlich 

auf spezifische Computer in der Domäne angewendet werden. Der nächste Abschnitt erläutert, 

wie im GPO Default Domain Controllers Policy spezifische lokale Richtlinien konfiguriert werden, 

damit diese auf alle Domänencontroller in der Domäne angewendet werden. 

Hinweis Für die domänenbasierten Sicherheitseinstellungen sollte ausschließlich die Standarddomänenrichtlinie 

(GPO Default Domain Policy) verwendet werden. Falls Sie zusätzliche Richtlinieneinstellungen auf 

Domänenebene hinzufügen müssen, erstellen und verknüpfen Sie neue, die erforderlichen Richtlinieneinstellungen 

enthaltende GPOs auf Aufgabenebene.


Übersicht über die Standardrichtlinie für Domänencontroller 

Das GPO Default Domain Controllers Policy stellt die anfänglichen Sicherheitseinstellungen für alle 

Domänencontroller in der OU Domain Controllers bereit. Im Einzelnen stellt dieses GPO Sicherheitseinstellungen 

in Verbindung mit den Knoten Zuweisen von Benutzerrechten und Sicherheitsoptionen 

unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale 

Richtlinien bereit. Abbildung 13.2 zeigt das GPO Default Domain Controllers Policy, wobei der Knoten 

Zuweisen von Benutzerrechten hervorgehoben ist. 


Anzeigen des Knotens Zuweisen von Benutzerrechten der Standardrichtlinie für Domänencontroller 

Zuweisen von Benutzerrechten 

Über die Einstellungen im Knoten Zuweisen von Benutzerrechten wird definiert, welche Konten spezifische 

Aufgaben auf dem Computer ausführen können. Wenn ein Benutzer bzw. eine Sicherheitsgruppe 

die Möglichkeit haben soll, sich lokal an Domänencontrollern anzumelden, können Sie dies 

innerhalb dieses Knotens konfigurieren. Tabelle 13.4 enthält eine Übersicht der unter Zuweisen von 

Benutzerrechten verfügbaren Richtlinien sowie der Standardrichtlinieneinstellungen für das GPO 

Default Domain Controllers Policy. 

Tabelle 13.4 

Richtlinieneinstellungen im Knoten Zuweisen von Benutzerrechten 

Richtlinie Beschreibung Standardeinstellung für das GPO 

Default Domain Controllers Policy 

Auf Anmeldeinformations-Manager als 

vertrauenswürdigem Aufrufer zugreifen 

Wird nur von der Anmeldeinformationsverwaltung 

für Sicherungs- und Wiederherstellungsverfahren 

verwendet. Kein Konto sollte dieses 

Benutzerrecht erhalten. 

Nicht definiert


Tabelle 13.4 

Richtlinieneinstellungen im Knoten Zuweisen von Benutzerrechten (Fortsetzung) 



Auf diesen Computer vom Netzwerk 

aus zugreifen 

Einsetzen als Teil des Betriebssystems 

Hinzufügen von Arbeitsstationen zur 

Domäne 

Anpassen von Speicherkontingenten 

für einen Prozess 

Lokal anmelden zulassen 

Anmelden über Terminaldienste 

zulassen 

Sichern von Dateien und 

Verzeichnissen 

Auslassen der durchsuchenden Überprüfung 

Legt fest, welche Benutzer und Gruppen sich 

mit diesem Computer über das Netzwerk verbinden 

können. Beachten Sie, dass Terminaldienste 

von diesem Benutzerrecht nicht 

betroffen sind. 

Ermöglicht einem Prozess, ohne Authentifizierung 

die Identität jedes Benutzers anzunehmen 

und Zugriff auf lokale Ressourcen zu 

erhalten. Wird nur verwendet, wenn Ihre Organisation 

Windows NT- oder Windows 2000-Server 

einsetzt, die Legacyanwendungen 

enthalten. 

Legt fest, welche Gruppen oder Benutzer einer 

Domäne Arbeitsstationen hinzufügen dürfen. 

Beachten Sie, dass diese Einstellung nur auf 

Domänencontrollern gültig ist. Benutzer, die 

dieses Recht erhalten, können bis zu zehn 

Computerkonten in der Domäne erstellen. 

Legt fest, wer die Größe des einem Prozess 

zugewiesenen Arbeitsspeichers ändern darf. 

Legt fest, welche Benutzer sich interaktiv am 

Server anmelden können. 

Legt fest, welche Benutzer oder Gruppen sich 

an einem Terminaldiensteclient anmelden 

können. 

Legt fest, welche Benutzer andere 

Objektberechtigungen zum Zweck der 

Systemsicherung umgehen können. 

Legt fest, welche Benutzer auch dann innerhalb 

einer Verzeichnisstruktur auf Ordner zugreifen 

können, wenn spezifische Berechtigungen nicht 

auf übergeordnete Ordner innerhalb der Struktur 

angewendet werden können. 



Domänencontroller der Organisation 

Jeder 

Prä-Windows 2000-kompatibler 

Zugriff 




Lokaler Dienst 













Jeder 



Prä-Windows 2000-kompatibler 

Zugriff


Tabelle 13.4 




Ändern der Systemzeit 

Ändern der Zeitzone 

Erstellen einer Auslagerungsdatei 

Erstellen eines Tokenobjekts 

Erstellen globaler Objekte 

Erstellen von dauerhaft freigegebenen 

Objekten 

Erstellen symbolischer Verknüpfungen 

Debuggen von Programmen 

Zugriff vom Netzwerk auf diesen Computer 

verweigern 

Anmelden als Batchauftrag verweigern 

Anmelden als Dienst verweigern 

Lokal anmelden verweigern 

Anmelden über Terminaldienste 

verweigern 

Ermöglichen, dass Computer- und Benutzerkonten 

für Delegierungszwecke 

vertraut wird 

Legt fest, welcher Benutzer oder welche Gruppe 

die Systemzeit auf dem Server ändern kann. 


die Zeitzone auf dem Server ändern kann. 


eine API zum Erstellen einer Auslagerungsdatei 

aufrufen kann. 

Legt fest, welche Konten von spezifischen 

Prozessen zum Erstellen eines Zugriffstokenobjekts 

verwendet werden können. Wird in der 

Regel nur vom Betriebssystem verwendet. 

Legt fest, welcher Benutzer oder welche 

Gruppen globale Objekte während 

Terminaldienstesitzungen erstellen können. 

Legt fest, welche Konten von Prozessen zum 

Erstellen eines Verzeichnisobjekts verwendet 

werden können. Wird in der Regel nur vom 

Betriebssystem verwendet. 

Legt fest, welcher Benutzer oder welche Gruppen 

eine symbolische Verknüpfung von dem 

Computer erstellen können, an dem der Benutzer 

angemeldet ist. 

Legt fest, welche Benutzer einen Debugger 

einem Prozess oder Kernel zuordnen können. 

Dieses Recht bietet vollständigen Zugriff auf 

wichtige Betriebssystemkomponenten und 

sollte mit Vorsicht genutzt werden. 

Legt fest, welche Benutzer oder Computer nicht 

vom Netzwerk auf diesen Computer zugreifen 

dürfen. 

Legt fest, welche Konten sich nicht als Stapelverarbeitungsauftrag 

anmelden dürfen. 

Legt fest, welche Konten sich nicht als Dienst 


Legt fest, welche Konten sich nicht interaktiv 

am Computer anmelden dürfen. 

Legt fest, welche Konten sich nicht als Terminaldiensteclient 


Ein Prozess, dem für Delegierungszwecke vertraut 

wird, kann mithilfe der Anmeldeinformationen 

eines Clients auf einen anderen 

Computer zugreifen. 
















Administratoren


Tabelle 13.4 




Erzwingen des Herunterfahrens von 

einem Remotesystem aus 

Generieren von Sicherheitsüberwachungen 

Annehmen der Clientidentität nach 


Arbeitssatz eines Prozesses 

vergrößern 

Anheben der Zeitplanungspriorität 

Laden und Entfernen von Gerätetreibern 

Sperren von Seiten im Speicher 

Anmelden als Stapelverarbeitungsauftrag 

Anmelden als Dienst 

Verwalten von Überwachungs- und 

Sicherheitsprotokollen 


einen Computer von einem Remotestandort 

aus über das Netzwerk herunterfahren kann. 

Legt fest, welche Konten von einem Prozess 

zum Hinzufügen von Einträgen zum Sicherheitsprotokoll 

verwendet werden können. 

Legt fest, welche Konten ein Programm verwenden 

kann, um die Identität eines Clients 

anzunehmen. Verwenden Sie dieses Recht mit 

Vorsicht, da es ein Sicherheitsrisiko darstellen 

kann. 

Legt fest, welche Benutzerkonten die Größe 

des Arbeitssatzes eines Prozesses, d.h. des 

Satzes derzeit im physischen RAM sichtbarer 

Speicherseiten, heraufsetzen bzw. reduzieren 

können. 

Legt fest, welche Konten einen Prozess verwenden 

können, der Eigenschaftenschreibzugriff 

auf einen anderen Prozess besitzt, um die 

dem anderen Prozess zugewiesene Ausführungspriorität 

zu steigern. Die Änderung der 

Planungspriorität wird in der Regel vom Task- 

Manager durchgeführt. 

Legt fest, welche Konten dynamisch Gerätetreiber 

in den Kernelmodus laden und daraus entfernen 

können. Beachten Sie, dass dies nicht 

für Plug & Play-Gerätetreiber gilt. 

Legt fest, welche Konten einen Prozess verwenden 

können, um Daten im physischen 

Speicher des Computers zu halten und das 

Auslagern der Daten in den virtuellen Speicher 

auf der Festplatte zu verhindern. 

Ermöglicht einem Benutzer, als Stapelverarbeitungs- 

anstatt als interaktiver Benutzer angemeldet 

zu sein. Wird in der Regel nur mit 

älteren Versionen von Windows verwendet. 

Legt fest, welche Konten einen Prozess als 

Dienst registrieren können. 

Legt fest, welche Benutzer Überwachungsoptionen 

für den Objektzugriff konfigurieren und 

das Sicherheitsprotokoll anzeigen und löschen 

können. 













Leistungsprotokollbenutzer 


Administratoren


Tabelle 13.4 




Verändern einer Objektbezeichnung 

Verändern der Firmwareumgebungsvariablen 

Durchführen von Volumewartungsaufgaben 

Erstellen eines Profils für einen Einzelprozess 

Erstellen eines Profils der Systemleistung 

Entfernen des Computers von der 

Dockingstation 

Ersetzen eines Tokens auf 

Prozessebene 

Wiederherstellen von Dateien und 

Verzeichnissen 

Herunterfahren des Systems 

Synchronisieren von Verzeichnisdienstdaten 

Übernehmen des Besitzes von Dateien 

und Objekten 

Sicherheitsoptionen 

Legt fest, welches Benutzerkonto die Integritätsbezeichnung 

von Objekten wie Dateien, Registrierungsschlüsseln 

oder im Besitz anderer 

Benutzer befindlicher Prozesse ändern kann. 

Legt fest, welche Konten Firmwareumgebungswerte 

wie z.B. im nicht flüchtigen Arbeitsspeicher 

(RAM) gespeicherte Einstellungen ändern 

können. 

Legt fest, welche Benutzer oder Gruppen Wartungsaufgaben 

wie die Remotedefragmentierung 

auf einem Volume ausführen können. 

Legt fest, welche Konten Leistungsüberwachungstools 

zur Überwachung der Leistung 

nicht systembezogener Prozesse verwenden 

können. 

Legt fest, welche Konten Leistungsüberwachungstools 

zur Überwachung der Leistung von 

Systemprozessen verwenden können. 

Legt fest, welche Konten einen Computer von 

seiner Dockingstation abdocken können. 

Legt fest, welches Konto die CreateProcess- 

AsUser()-API aufrufen kann, damit ein Dienst 

einen anderen Dienst starten kann. 

Legt fest, welche Konten Datei- und Objektberechtigungen 

umgehen können, um Wiederherstellungsaufgaben 

an gesicherten Daten 

durchzuführen. 

Legt fest, welche Konten den Computer mithilfe 

des Befehls Herunterfahren herunterfahren 

können. 

Legt fest, welche Konten die Active Directory- 

Synchronisierung durchführen dürfen. 

Legt fest, welche Konten den Besitz für zu 

schützende Objekte übernehmen können. 


















Der Knoten Sicherheitsoptionen des GPOs Default Domain Controllers Policy enthält eine Reihe 

definierter Standardeinstellungen. Die meisten Standardeinstellungen beziehen sich darauf, wie der 

Domänencontroller Einstellungen in Bezug auf Netzwerksicherheit und die Kommunikation mit 

Clients anwendet. In Tabelle 13.5 sind die standardmäßig im GPO Default Domain Controllers Policy 

definierten Sicherheitsoptionen aufgelistet.


Tabelle 13.5 

Im GPO Default Domain Controllers Policy definierte Sicherheitsoptionen 

Sicherheitsoption Beschreibung Standardeinstellung 

Domänencontroller: Signaturanforderungen Legt fest, ob ein LDAP-Server Signierungsverhandlungen 

Keine 

für LDAP-Server 

mit einem LDAP-Client durchführen 

muss. 

Domänenmitglied: Daten des sicheren 

Kanals digital verschlüsseln oder signieren 

(immer) 

Microsoft-Netzwerk (Server): Kommunikation 

digital signieren (immer) 

Microsoft-Netzwerk (Server): Kommunikation 

digital signieren (wenn Client zustimmt) 

Netzwerksicherheit: LAN Manager- 

Authentifizierungsebene 

Legt fest, ob der gesamte vom Domänenmitglied initiierte 

Datenverkehr über einen sicheren Kanal signiert 

oder verschlüsselt werden muss. 

Legt fest, ob die SMB-Komponente (Server Message 

Block) eine Paketsignatur erfordert. 

Legt fest, ob die Paketsignierung auf Anforderung 

des Clients ausgehandelt wird. 

Legt fest, welches Herausforderung/Antwort-Authentifizierungsprotokoll 

für Netzwerkanmeldungen verwendet 

wird. 

Neuerstellen der Standard-GPOs für eine Domäne 

Aktiviert 

Aktiviert 

Aktiviert 

Nur NTLMv2- 

Antwort senden 

Falls undokumentierte Änderungen auf die Standard-GPOs angewendet wurden und Sie die Standardeinstellungen 

wiederherstellen müssen, haben Sie zwei Möglichkeiten. Wenn Sie das Sicherungsfeature 

aus der Konsole Gruppenrichtlinienverwaltung zum Sichern der GPOs Default Domain Policy 

und Default Domain Controllers Policy verwendet haben, können Sie die GPOs anhand der Sicherung 

wiederherstellen. Voraussetzung ist, dass die gesicherten Versionen die ursprünglichen Einstellungen 

enthalten, die Sie benötigen. Die zweite Option ist der Einsatz des Befehlszeilentools Dcgpofix. 

Dieses Befehlszeilentool ermöglicht, die ursprünglichen Einstellungen der GPOs Default Domain 

Policy oder Default Domain Controllers Policy bzw. beide GPOs wiederherzustellen. Sie können z.B. 

die Standardrichtlinie für Domänencontroller durch Eingabe des folgenden Befehls wiederherstellen: 

dcgpofix /Target: Domäne 

Weitere Informationen über den Befehl Dcgpofix erhalten Sie bei Eingabe von dcgpofix /? (wie in 

Abbildung 13.3 gezeigt). 


Anzeigen der Dcgpofix-Befehlszeilenoptionen


Direkt von der Quelle: Auswirkung der Verwendung von Dcgpofix 

Sichern Sie vor der Ausführung von Dcgpofix unbedingt die GPOs Default Domain Policy und 

Default Domain Controllers Policy. Unter anderem in folgenden Fällen kann die Verwendung von 

Dcgpofix unbeabsichtigte Auswirkungen haben: 

• Der in der Standarddomänenrichtlinie gespeicherte EFS-Datenwiederherstellungs-Agent geht 

verloren. Der Datenwiederherstellungs-Agent wird am folgenden Speicherort des Gruppenrichtlinienobjekts 

angegeben: Computerkonfiguration\Richtlinien\Sicherheitseinstellungen\ 

Richtlinien für öffentliche Schlüssel\Verschlüsseltes Dateisystem. 

Weitere Informationen finden Sie in „Sichern des privaten EFS-Schlüssels für den Wiederherstellungs-Agent 

in Windows Server 2003, Windows 2000 und Windows XP“ unter http://support.microsoft.com/kb/241201. 

Darüber hinaus können benutzerdefinierte Einstellungen in Einstellungen der automatischen 

Zertifikatanforderung, Vertrauenswürdige Stammzertifizierungsstellen, Organisationsvertrauen 

und Einstellung für die automatische Registrierung verloren gehen, die im GPO Default 

Domain Controllers Policy und/oder im GPO Default Domain Policy konfiguriert wurden. 

• Die Verwendung von Dcgpofix zum Neuerstellen des GPOs Default Domain Controllers Policy 

kann Auswirkungen auf Exchange 2000 und 2003 haben. Das Exchange Server-Tool Domain- 

Prep fügt der Benutzerrechtezuweisung Verwalten von Überwachungs- und Sicherheitsprotokollen 

für das GPO Default Domain Controllers Policy die Sicherheitsgruppe Exchange 

Enterprise Servers für die Domäne hinzu. Ist diese nicht vorhanden, werden Informationsspeicher 

und MTA auf Exchange-Servern nicht gestartet Als Lösung können Sie setup /domainprep 

erneut ausführen oder die Einträge nach Neuerstellung der Richtlinie manuell wieder 

hinzufügen. 

• Dienste auf Domänencontrollern, die als Domänenbenutzer ausgeführt werden, starten möglicherweise 

nicht. Anwendungen wie IIS erstellen Konten auf Domänencontrollern und fügen 

Benutzerrechtszuweisungen für diese Konten hinzu, sodass diese als Dienst ausgeführt werden, 

über das Netzwerk zugreifen usw. Falls diese Einträge nicht vorhanden sind, starten die 

Dienste möglicherweise nicht. Dies kann sowohl das GPO Default Domain Policy als auch das 

GPO Default Domain Controllers Policy betreffen. 

• Überwachungseinstellungen und Benutzerrechte werden geändert. Weitere Informationen über 

diese Änderungen finden Sie (in englischer Sprache) im Knowledge Base-Artikel 833783 unter 

http://support.microsoft.com/default.aspx?scid=kb;EN-US;833783. 

Michael Hunter 


Directory Services Team 

Fein abgestimmte Kennwortrichtlinien 

In früheren Versionen von Active Directory müssen domänenbasierte Kontorichtlinien über das GPO 

Default Domain Policy konfiguriert werden. Daraus resultiert, dass jeder Benutzer in der Domäne über 

dieselbe Kennwortrichtlinie und dieselben Kontosperrrichtlinien verfügt. Es kann jedoch vorkommen, 

dass Sie für eine bestimmte Benutzergruppe (z.B. die Domänenadministratoren) eine striktere Kennwortrichtlinie 

anwenden möchten als für normale Domänenbenutzer. Frühere Implementierungen von 

Active Directory boten nur sehr begrenzte Optionen, um dieser Anforderung gerecht zu werden.


Mit den Active Directory-Domänendiensten von Windows Server 2008 werden die sogenannten fein 

abgestimmten Kennwortrichtlinien eingeführt. Sie können mittels dieser Funktion in einer Domäne 

mehrere Kennwortrichtlinien und Kontosperreinstellungen für verschiedene Benutzer oder Sicherheitsgruppen 

festlegen. Jetzt ist es möglich, eine striktere Kennwortrichtlinie für einzelne Sicherheitsgruppen 

oder Benutzer anzuwenden, ohne die Kennwort- oder Kontosperreinstellungen der Standardbenutzer 

in der übrigen Domäne zu ändern. 

Planen von fein abgestimmten Kennwortrichtlinien 

Um fein abgestimmte Kennwortrichtlinien zu implementieren, sind einige Überlegungen anzustellen: 

• Fein abgestimmte Kennwortrichtlinien können sowohl auf Benutzerobjekte als auch auf globale 

Sicherheitsgruppen angewendet werden. 

• Sie können eine fein abgestimmte Kennwortrichtlinie nicht auf eine Organisationseinheit anwenden. 

Es ist jedoch eine gängige Vorgehensweise, eine globale Sicherheitsgruppe zu erstellen, die 

denselben Namen und dieselbe Mitgliedschaft wie eine spezifische OU enthält (üblicherweise als 

Schattengruppe bezeichnet). Anschließend können Sie die fein abgestimmte Kennwortrichtlinie 

auf die Sicherheitsgruppe anwenden. 

• Wenn Sie benutzerdefinierte Kennwortfilter in einer Domäne bereitgestellt haben, können Sie 

diese Filter weiterhin im Rahmen der zusätzlichen, durch die fein abgestimmten Kennwortrichtlinien 

gebotenen Sicherheit verwenden. 

• Die Funktionsebene der Domäne muss auf Windows Server 2008 festgelegt werden. 

Darüber hinaus sollten Sie einen dokumentierten Plan entwickeln, der folgende Fragen behandelt: 

• Wie viele verschiedene Kennwortrichtlinien sind erforderlich? Dies ist nicht nur zur Bestimmung der 

zusätzlichen Sicherheitsgruppen wichtig, die möglicherweise in ihrer Active Directory-Umgebung 

erstellt werden müssen, sondern spielt außerdem für die Anwendungsreihenfolge eine Rolle, 

wenn mehrere Kennwortrichtlinien für einen spezifischen Benutzer ausgewertet werden. 

• Welche spezifischen Kennwort- und Kontosperreinstellungen sind erforderlich? Im Rahmen der Konfiguration 

der Kennwortrichtlinie werden Sie gemäß der Liste in Tabelle 13.6 zur Eingabe verschiedener 

Attribute aufgefordert. 

• Welche Sicherheitsgruppen werden mit den neuen Kennwortrichtlinien verknüpft? Sie müssen spezifische 

Sicherheitsgruppen mit den Benutzern erstellen, die eindeutige Kennwortrichtlinien benötigen. 

Implementieren fein abgestimmter Kennwortrichtlinien 

Zur Unterstützung fein abgestimmter Kennwortrichtlinien enthält Windows Server 2008 Active 

Directory zwei zusätzliche Objekttypen: 

• Container für Kennworteinstellungen Dieser standardmäßig erstellte Container trägt den Namen 

Password Settings Container und kann unterhalb des Containers System in der Domäne angezeigt 

werden. Er wird zum Speichern der Kennworteinstellungsobjekte verwendet, die Sie erstellen und 

mit globalen Sicherheitsgruppen oder Benutzern verknüpfen. 

• Kennworteinstellungsobjekt Kennworteinstellungsobjekte (Password Settings Objects, PSOs) 

werden von Mitgliedern der Gruppe Domänen-Admins erstellt und zum Definieren spezifischer 

Kennwort- und Kontosperreinstellungen verwendet, die mit einer spezifischen Sicherheitsgruppe 

oder einem spezifischen Benutzer verknüpft werden.


Wie in Abbildung 13.4 gezeigt, speichert der Password Settings Container alle für die Domäne konfigurierten 

benutzerdefinierten Kennworteinstellungsobjekte. In diesem Beispiel werden die leitenden 

Angestellten der Personalabteilung mit spezifischen Kennworteinstellungen konfiguriert, die vom 

übrigen Teil der Domäne abweichen. 


Anzeigen des Containers für Kennworteinstellungen 

Mit dem ADSI-Editor (Active Directory Services Interfaces Editor, ADSI Edit) erhalten Sie eine grafische 

Benutzeroberfläche zum Erstellen der PSOs. Sie können auch mithilfe des Befehls Ldifde in 

Form eines Skripts mehrere PSOs zum Password Settings Container hinzufügen. 

Weitere Informationen Weitere Informationen zum Erstellen von PSOs mittels eines Skripts mithilfe von 

Ldifde finden Sie (in englischer Sprache) in „Creating a PSO using Ldifde“ unter http://technet2.microsoft.com/windowsserver2008/en/library/67dc7808-5fb4-42f8-8a48-7452f59672411033.mspx?mfr=true. 

Führen Sie zum Erstellen und Konfigurieren von PSOs mit ADSI Edit die folgenden Schritte aus: 

1. Öffnen Sie ADSI Edit, und verbinden Sie sich mit dem vollständig qualifizierten Domänennamen 

der Domäne, in der Sie das PSO erstellen möchten. 

2. Wechseln Sie zu DC=\CN=System\CN=Password Settings Container. 

3. Klicken Sie mit der rechten Maustaste auf CN=Password Settings Container, zeigen Sie auf Neu, 

und klicken Sie auf Objekt. 

4. Stellen Sie im Feld Objekt erstellen sicher, dass msDS-PasswordSettings ausgewählt ist, und klicken 

Sie auf Weiter. 

5. Tragen Sie die entsprechenden Werte für jedes der Attribute ein, wie in Tabelle 13.6 beschrieben.


Tabelle 13.6 

PSO-Attribute 

Attributname Beschreibung Wertebereich 

Common-Name Name für das neue PSO. Standardmäßige Unicode-Zeichenfolge 

msDS-PasswordSettingsPrecedence 

msDS-PasswordReversible 

EncryptionEnabled 

msDS-PasswordHistoryLength 

Rangfolge der Kennworteinstellung, die 

verwendet wird, wenn Benutzer mehreren 

PSOs zugewiesen werden. 

Kennwort hat für Benutzer den Status 

umkehrbarer Verschlüsselung. 

Länge der Kennwortchronik für Benutzer. 

Kennwortkomplexitätsstatus. 

msDS-Passwordcomplexity- 

Enabled 

Jeder Wert höher als 10. 

Niedrigere Werte haben 

Vorrang gegenüber höheren Werten. 

FALSE/TRUE 

Empfohlen: FALSE 

0–1024 

FALSE/TRUE 

Empfohlen: TRUE 

msDS-MinimumPasswordLength Minimale Kennwortlänge. 0–255 

msDS-MinimumPasswordAge Minimales Kennwortalter für Änderung 

des Kennworts durch Benutzer. 

Beachten Sie, dass dieser Wert höchstens 

dem Wert von msDS- 

MaximumPasswordAge entsprechen 

darf. 

(Keine) 

00:00:00:00 bis Wert von 

msDS-MaximumPasswordAge 

Beispiel 1:00:00:00 (1 Tag) 

msDS-MaximumPasswordAge 

msDS-LockoutThreshold 

msDS-LockoutObservationWindow 

msDS-LockoutDuration 

msDS-PSOAppliesTo 

Maximales Kennwortalter für Änderung 

des Kennworts durch Benutzer. 

Beachten Sie, dass dieser Wert nicht 

auf Null gesetzt werden kann. 

Schwellenwert, ab dem ein Benutzer 

gesperrt wird. 

Zeit, die vor dem Zurücksetzen der 

Sperrungsschwelle verstreicht. 

Beachten Sie, dass dieser Wert nicht 

kleiner sein darf als der Wert von 

msDS-LockoutDuration. 

Zeitraum, für den ein Benutzer gesperrt 

ist. 

Wird verwendet, um das PSO mit 

Sicherheitsgruppen oder Benutzern zu 

verknüpfen. 

(Nie) 

Wert von msDS-MinimumPassword- 

Age bis (Nie) 

Beispiel: 30:00:00:00 (30 Tage) 

0–65535 

(Keine) 

00:00:00:01 bis Wert von 

msDS-LockoutDuration 

Beispiel 0:00:30:00 (30 Minuten) 

(Keine) 

(Nie) 

Wert von msDS-Lockout Observation- 

Window bis (Nie) 

Beispiel: 0:00:30:00 

(30 Minuten) 

0 oder mehrere definierte Namen von 

Benutzern oder globalen Sicherheitsgruppen.


Hinweis Geben Sie beim Erstellen von PSOs mittels ADSI Edit die Werte für msDS-Maximum- 

PasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow und msDS-Lockout- 

Duration im Format T:HH:MM:SS ein. 

6. Ändern Sie Eigenschaften durch Klicken auf die Schaltfläche Weitere Attribute. 

Grundlegendes zum resultierenden PSO für einen Benutzer 

Ein Benutzer oder eine Sicherheitsgruppe kann mit mehr als einem PSO verknüpft sein. Dies kann der 

Fall sein, wenn ein Benutzer Mitglied mehrerer Sicherheitsgruppen ist, denen jeweils ein PSO zugewiesen 

ist, oder wenn einem Benutzerobjekt mehrere PSOs direkt zugewiesen wurden. In jedem Fall 

ist es wichtig zu wissen, dass nur ein einziges PSO als effektive Kennwortrichtlinie angewendet werden 

kann. 

Erinnern Sie sich daran, dass in Tabelle 13.6 ein PSO-Attribut mit Namen msDS-PasswordSettingsPrecedence 

aufgeführt wird. Wenn mehrere PSOs einem Benutzer oder einer Gruppe zugewiesen 

wurden, hilft dieses Attribut beim Bestimmen des resultierenden PSOs. Ein PSO mit niedrigerem 

Wert hat Vorrang vor einem PSO mit einem höheren Wert. 

Wenn mehrere PSOs mit einem Benutzer oder einer Gruppe verknüpft sind, wird das resultierende 

PSO auf die folgende Weise bestimmt: 

1. Jedes direkt mit einem Benutzerobjekt verknüpfte PSO ist das resultierende PSO. Sind mehrere 

PSOs direkt mit dem Benutzerobjekt verknüpft, wird das PSO mit dem niedrigsten Wert fürmsDS- 

PasswordSettingsPrecedence das resultierende PSO. 

2. Sind keine PSOs direkt mit dem Benutzer verknüpft, werden die PSOs für alle globalen Sicherheitsgruppen 

verglichen, die den Benutzer enthalten. Das PSO mit dem niedrigsten Wert für 

msDS-PasswordSettingsPrecedence wird das resultierende PSO. 

Hinweis Werden nach Schritt 1 und 2 weiterhin mehrere PSOs mit identischem Wert für msDS-PasswordSettingsPrecedence 

ermittelt, wird das PSO mit der kleinsten global eindeutigen Kennung (Globally 

Unique Identifier, GUID) angewendet. 

3. Sind keine PSOs direkt oder indirekt (durch Gruppenmitgliedschaft) mit dem Benutzer verknüpft, 

finden die Einstellungen der Standarddomänenrichtlinie (GPO Default Domain Policy) Anwendung. 

Alle Benutzerobjekte enthalten ein neues Attribut mit Namen msDS-ResultantPSO. Mithilfe dieses 

Attributs kann der definierte Name des auf den Benutzer angewendeten PSOs bestimmt werden. Ist 

kein PSO-Objekt mit dem Benutzer verknüpft, enthält dieses Attribut keinen Wert. In diesem Fall 

wird die im GPO Default Domain Policy enthaltene Richtlinie zur effektiven Kennwortrichtlinie. 

Sie können das Attibut msDS-ResultantPSO mithilfe einer der beiden folgenden Methoden anzeigen: 

• Windows-Oberfläche Stellen Sie in der Konsole Active Directory-Benutzer und -Computer sicher, 

dass im Menü Ansicht die Option Erweiterte Features aktiviert ist, und öffnen Sie die Eigenschaften 

eines Benutzerkontos. Das Attribut msDS-ResultantPSO wird auf der Registerkarte 

Attribut-Editor angezeigt. Möglicherweise müssen Sie im Filter die Option Schreibgeschützte 

Attribute anzeigen\Erzeugt aktivieren.


• Befehlszeilentool DSGET Öffnen Sie eine Eingabeaufforderung, und geben Sie folgenden Befehl 

ein: 

dsget user -effectivepso 

Abbildung 13.5 zeigt das Attribut msDS-ResultantPSO für Don Hall. Beachten Sie, dass das PSO für 

die leitenden Angestellten der Personalabteilung die effektive, auf dieses Benutzerobjekt angewendete 

Richtlinie ist. 


Anzeigen des resultierenden PSOs 

Verstärken der Serversicherheit mithilfe von 

Gruppenrichtlinien 

Ergänzend zu Sicherheitsrichtlinien auf Domänenebene bieten die Gruppenrichtlinien eine Vielzahl 

von Einstellungen, die die Verstärkung der Sicherheitseinstellungen für Domänenmitglieder unterstützen. 

Ebenso wie die Kontorichtlinien und die lokalen Richtlinien werden viele dieser Einstellungen in 

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen konfiguriert. 

Zusätzliche Einstellungen werden in Benutzerkonfiguration\Richtlinien\Windows-Einstellungen\ 

Sicherheitseinstellungen festgelegt. Abbildung 13.6 zeigt die jeweiligen Optionen in den Ordnern 

Sicherheitseinstellungen. In Tabelle 13.7 werden die Konfigurationsoptionen unter der jeweiligen 

Überschrift zusammengefasst.

Verstärken der Serversicherheit mithilfe von Gruppenrichtlinien 523 


Unterhalb von Sicherheitseinstellungen verfügbare zusätzliche Richtlinien 

Wenn Sie die Sicherheitseinstellungen für die Computer in ihrem Netzwerk mit Gruppenrichtlinien 

verstärken, ist es weitaus leichter, eine sichere Netzwerkumgebung zu erstellen und zu verwalten. Die 

Konfiguration der Sicherheit mittels Gruppenrichtlinieneinstellungen ist einfacher, als sich mit jeder 

einzelnen Arbeitsstation zu befassen. Sie müssen lediglich die zentralen Sicherheitsrichtlinien erstellen, 

in einem GPO konfigurieren und das GPO mit einem Active Directory-Containerobjekt verknüpfen. 

Bei der nächsten Anwendung des GPOs wird die Sicherheit auf allen Computern im Container 

konfiguriert. Die Nutzung von Gruppenrichtlinien erleichtert auch die kontinuierliche Verwaltung der 

Sicherheitseinstellungen für Ihre Computer. Die Sicherheitseinstellungen der Richtlinie werden fortlaufend 

aktualisiert. Auch wenn ein Benutzer die Sicherheitskonfiguration auf einer Arbeitsstation 

ändern könnte, würde die Richtlinie beim nächsten Aktualisierungszyklus erneut angewendet. 

Tabelle 13.7 

Zusätzliche Einstellungen zur Verstärkung der Sicherheit in Gruppenrichtlinien 

Konfigurationsoption 

Lokale Richtlinien\ 

Überwachungsrichtlinie 

Erläuterung 

Wird zum Konfigurieren der Überwachungseinstellungen verwendet. Sie können Überwachungsrichtlinien 

für Optionen wie Kontenverwaltungsaktivitäten, Anmeldeereignisse, 

Richtlinienänderungen, Rechteverwendung und Systemereignisse festlegen. Weitere Informationen 

zur Konfiguration von Überwachungsrichtlinieneinstellungen finden Sie im Abschnitt 

„Überwachen der Verwendung von Administratorrechten“ in Kapitel 9, „Delegieren 

der Active Directory-Domänendiensteverwaltung.“


Tabelle 13.7 

Zusätzliche Einstellungen zur Verstärkung der Sicherheit in Gruppenrichtlinien (Fortsetzung) 


Ereignisprotokoll 

Eingeschränkte Gruppen 

Systemdienste 

Registrierung 

Dateisystem 


(Diese Einstellung ist 

sowohl im Knoten Computerkonfiguration 

als auch im Knoten Benutzerkonfiguration 

enthalten.) 

Erläuterung 

Wird zum Konfigurieren von Ereignisprotokolleinstellungen für alle Computer im Rahmen 

der Richtlinienverwaltung verwendet. Sie können Optionen wie etwa die maximale Größe 

für Ereignisprotokolle, die Berechtigung zur Anzeige von Ereignisprotokollen und die Beibehaltung 

aller Ereignisprotokolle konfigurieren. 

Wird zur Einschränkung der Mitgliedschaft lokaler Gruppe auf Computern verwendet, die 

von der Richtlinie betroffen sind. Diese Einstellung wird am häufigsten zur Konfiguration 

der Mitgliedschaft des lokalen Administratorkontos auf Computern verwendet, auf denen 

Windows 2000 oder höher ausgeführt wird. Wenn Sie diese Option zur Konfiguration der 

Mitgliedschaft der lokalen Gruppe verwenden, werden alle Benutzer oder Gruppen, die 

zur lokalen Gruppe gehören, aber nicht in der Mitgliederliste dieser Richtlinie enthalten 

sind, bei der nächsten Aktualisierung der Richtlinie entfernt. 

Wird zur Verwaltung von Diensten auf Computern verwendet. Sie können mithilfe dieser 

Richtlinie definieren, welche Dienste automatisch auf den Computern starten, oder Sie 

können Dienste deaktivieren. 

Wird zum Konfigurieren der Sicherheit in Registrierungsschlüsseln verwendet. Sie können 

der Richtlinie beliebige Registrierungsschlüssel hinzufügen und dann spezifische 

Sicherheitseinstellungen auf den Schlüssel anwenden. 

Wird zum Konfigurieren der Sicherheit in Dateien und Ordnern verwendet. Sie können der 

Richtlinie beliebige Dateien oder Ordner hinzufügen und dann Zugriffssteuerung und 

Überwachung auf diese Dateisystemobjekte anwenden. 

Hiermit wird gesteuert, welche Programme oder Dateien auf einem Computer ausgeführt 

werden können. Weitere Informationen zu dieser Richtlinieneinstellung finden Sie im 

nächsten Abschnitt. 

Direkt von der Quelle: Gruppenrichtlinieneinstellungen 

Mit Windows Server 2008 führt Microsoft Gruppenrichtlinieneinstellungen ein, die im Wesentlichen 

eine Erweiterung der vormals verfügbaren clientseitigen Erweiterungen (Client-side Extensions, 

CSE) für Gruppenrichtlinien darstellen. Mit Gruppenrichtlinieneinstellungen können Sie 

die Gesamtbetriebskosten (Total Cost of Ownership, TCO) Ihrer Windows-Server durch Erweiterung 

der Gruppenrichtlinienverwaltbarkeit weiter reduzieren. Nachstehend finden Sie einige der 

vielen verfügbaren Einstellungen: 

• Laufwerkzuordnungen Erstellen, ändern oder löschen Sie zugeordnete Laufwerke, und konfigurieren 

Sie die Sichtbarkeit aller Laufwerke. 

• Umgebung Erstellen, ändern oder löschen Sie Umgebungsvariablen. 

• Netzwerkfreigaben Erstellen, ändern oder löschen Sie Freigaben. 

• Geräte Aktivieren bzw. deaktivieren Sie Hardwaregeräte oder Geräteklassen. 

• Lokale Benutzer und Gruppen Erstellen, ändern oder löschen Sie lokale Benutzer und Gruppen. 

• Energieoptionen Ändern Sie Energieoptionen und erstellen, ändern oder löschen Sie Energieschemata.


Weitere Informationen über Gruppenrichtlinieneinstellungen finden Sie (in englischer Sprache) im 

Whitepaper unter http://go.microsoft.com/fwlink/?LinkId=103735. 

Gautam Anand 

Technical Lead – Directory Services 

Premier Enterprise Platforms Support 


Eines der größten Sicherheitsrisiken stellen in den letzten Jahren Benutzer dar, die unbekannte oder 

nicht vertrauenswürdige Software auf ihren Computern ausführen. In vielen Fällen führen die Benutzer 

versehentlich potenziell unsichere Software aus. Millionen von Benutzern haben z.B. Viren 

gestartet oder Trojaneranwendungen installiert, ohne absichtlich unsichere Software ausführen zu 

wollen. Die Richtlinien für die Softwareeinschränkung sollen dies verhindern. 

Die Richtlinien zur Softwareeinschränkung schützen Ihre Benutzer vor der Ausführung unsicherer 

Software, indem sie definieren, welche Anwendungen auf ihren Arbeitsstationen ausgeführt werden 

dürfen und welche nicht. Über eine Richtlinie für Softwareeinschränkung können Sie eine Richtlinie 

definieren, welche die Ausführung sämtlicher Software mit Ausnahme der von Ihnen spezifisch blockierten 

zulässt. Oder Sie definieren, dass die Richtlinie für Softwareeinschränkung nur die Ausführung 

der explizit von Ihnen erlaubten Software zulässt. Die zweite Option ist zwar sicherer, doch der 

zur Definition aller zur Ausführung in einer komplexen Unternehmensumgebung zugelassenen 

Anwendungen erforderliche Aufwand könnte zu groß sein. Die meisten Unternehmen entscheiden 

sich für die weniger sichere, jedoch verwaltungsfreundlichere Option, sämtliche Software zuzulassen 

und nur ausgewählte Software zu blockieren. Wenn Sie jedoch eine Gruppe von Arbeitsstationen in 

einer Umgebung mit hohen Sicherheitsanforderungen einsetzen, sollten Sie möglicherweise die 

sicherere Option wählen. 

Wenn Sie eine Richtlinie für Softwareeinschränkung erstellen, können Sie fünf Typen von Regeln 

konfigurieren, um die von der Richtlinie betroffenen Anwendungen zu bestimmen: 

• Hashregeln Eine Hashregel ist eine kryptografische Kennung, die eine spezifische Anwendungsdatei 

unabhängig von Dateiname oder Speicherort eindeutig identifiziert. Wurde im Ordner 

Sicherheitsstufen die Option Nicht eingeschränkt als Standardsicherheitsstufe ausgewählt, und 

möchten Sie die Ausführung einer bestimmten Anwendung einschränken, können Sie mithilfe der 

Richtlinie für Softwareeinschränkung eine Hashregel erstellen. Wenn ein Benutzer versucht, die 

Anwendung auszuführen, führt die Arbeitsstation eine Hashüberprüfung durch und verhindert die 

Ausführung der Anwendung. Wenn Sie die Richtlinie für Softwareeinschränkung so konfiguriert 

haben, dass die Ausführung aller Anwendungen blockiert wird (durch Konfiguration der Sicherheitsstufe 

Nicht erlaubt), können Sie die Hashregel zum Aktivieren einer spezifischen Anwendung 

verwenden. 

• Zertifikatregeln Sie können Zertifikatregeln erstellen, sodass die Auswahlkriterien für Anwendungen 

auf dem Softwareherausgeberzertifikat basieren. Wenn Sie z.B. eine benutzerdefinierte 

Anwendung entwickelt haben, können Sie dieser Anwendung ein Zertifikat zuweisen und die 

Softwareeinschränkungsregel dann so konfigurieren, dass dem entsprechenden Zertifikat vertraut 

wird.


• Pfadregeln Sie können Regeln basierend auf dem Pfad erstellen, in dem sich die ausführbare 

Datei der Anwendung befindet. Wenn Sie einen Ordner auswählen, sind alle Anwendungen in 

dem Ordner von der Regel betroffen. Sie können auch Umgebungsvariablen (z.B. %systemroot%) 

zur Angabe von Pfaden verwenden. Darüber hinaus können Sie Platzhalter in der Pfadregel 

verwenden (z.B. *.vbs). 

• Registrierungspfadregeln Sie können Regeln auch basierend auf den Speicherorten der Registrierung 

erstellen, welche die Anwendung verwendet. Nahezu jede Anwendung hat in der Registrierung 

einen Standardspeicherort, in dem sie anwendungsspezifische Informationen speichert. Dies 

ermöglicht Ihnen das Erstellen einer Regel, die eine Anwendung auf der Basis dieser Registrierungsschlüssel 

blockiert oder aktiviert. Im Menü zum Erstellen der Registrierungspfadregeln wird 

keine registrierungsspezifische Option angezeigt, aber die Option Neue Pfadregel ermöglicht 

Ihnen, diesen eindeutigen Satz von Regeln zu erstellen. Wenn Sie eine neue Richtlinie für Softwareeinschränkung 

erstellen, werden vier standardmäßige Registrierungspfadregeln erstellt. Diese 

Regeln konfigurieren eine uneingeschränkte Softwarerichtlinie für Anwendungen im Systemstammordner 

und dem standardmäßigen Verzeichnis der Programmdateien. 

• Netzwerkzonenregeln Der letzte Regeltyp basiert auf der Internetzone, aus der die Software heruntergeladen 

wurde. Vielleicht möchten Sie z.B. eine Regel konfigurieren, um die Ausführung 

aller aus der Zone der vertrauenswürdigen Sites heruntergeladenen Anwendungen zuzulassen, 

oder eine Regel, um die Ausführung aller aus der Zone der eingeschränkten Sites heruntergeladenen 

Anwendungen zu verhindern. 

Wenn Sie Ihre standardmäßige Softwareeinschränkung so konfigurieren, dass alle Anwendungen mit 

Ausnahme bestimmter Anwendungen ausgeführt werden sollten, definieren diese Regeln, welche 

Anwendungen nicht ausgeführt werden. Falls Sie die restriktivere Regel zur Deaktivierung aller 

Anwendungen festgelegt haben, bestimmen diese Regeln, welche Anwendungen ausgeführt werden 

dürfen. 

Standardmäßig werden mit Active Directory keine Richtlinien zur Softwareeinschränkung konfiguriert. 

Klicken Sie zum Definieren einer Richtlinie mit der rechten Maustaste auf den Ordner Richtlinien 

für Softwareeinschränkung, und wählen Sie Neue Richtlinien für Softwareeinschränkung. Auf 

diese Weise wird eine Standardrichtlinie erstellt. Abbildung 13.7 zeigt die erstellten Objekte. 

Der Ordner Sicherheitsstufen wird zum Definieren der Standardsicherheitsstufe verwendet. Der Ordner 

enthält drei Objekte: Nicht erlaubt, Standardbenutzer und Nicht eingeschränkt. Wenn Sie die 

Sicherheit so konfigurieren möchten, dass alle Anwendungen mit Ausnahme der angegebenen 

Anwendung ausgeführt werden können, klicken Sie mit der rechten Maustaste auf das Objekt Nicht 

eingeschränkt, und klicken Sie auf Als Standard. Wenn Sie die Ausführung aller Software mit Ausnahme 

der angegebenen Anwendungen verhindern möchten, klicken Sie mit der rechten Maustaste 

auf Nicht erlaubt und legen diese Einstellung als Standard fest. Die Sicherheitsstufe Nicht eingeschränkt 

ist die Standardeinstellung. 

Der Ordner Zusätzliche Regeln wird zum Konfigurieren der Softwareeinschränkungsregeln verwendet. 

Klicken Sie zum Konfigurieren einer Regel mit der rechten Maustaste auf den Ordner Zusätzliche 

Regeln, und wählen Sie den Typ der Regel aus, die Sie erstellen möchten. Wenn Sie zum Beispiel 

eine neue Hashregel erstellen möchten, wählen Sie Neue Hashregel. Klicken Sie zum Erstellen 

der neuen Hashregel auf Durchsuchen, und wählen Sie die Datei, die Sie mit dem Hash identifizieren 

möchten. Wenn Sie die Datei auswählen, wird der Dateihash automatisch erstellt. Dann können Sie 

konfigurieren, ob diese Anwendung Nicht eingeschränkt oder Nicht erlaubt ist oder mit der Sicherheitsstufe 

Standardbenutzer ausgeführt werden kann. Die Oberfläche zum erneuten Konfigurieren 

einer vorhandenen Hashregel ist in Abbildung 13.8 dargestellt.



Erstellen einer neuen Richtlinie für die Softwareeinschränkung 


Konfigurieren einer Hashregel 

Das Objekt Erzwingen wird zum spezifischeren Definieren der betroffenen Anwendungen verwendet. 

Sie können konfigurieren, dass die Regeln für alle Anwendungen oder alle Anwendungen mit Ausnahme 

von DLLs gelten. Außerdem können Sie festlegen, dass die Regeln für alle Benutzer oder alle 

Benutzer mit Ausnahme lokaler Administratoren gelten.


Das Objekt Designierte Dateitypen definiert alle Dateinamenerweiterungen, die potenziell ausführbaren 

Code enthalten und deshalb unter dieser Richtlinie verwaltet werden. Sie können dieser Liste 

Dateierweiterungen hinzufügen oder Erweiterungen daraus entfernen. 

Über das Objekt Vertrauenswürdige Herausgeber wird definiert, wer festlegen kann, ob ein Herausgeber 

vertrauenswürdig ist oder nicht. Sie können alle Benutzer, nur lokale Administratoren oder nur 

Organisationsadministratoren auswählen. Ferner können Sie festlegen, ob eine Arbeitsstation ein 

angebotenes Zertifikat vor Ausführung der Anwendung auf eine Sperrung prüfen soll. 

Konfigurieren der Netzwerksicherheit mit Gruppenrichtlinien 

Die in einer Windows Server 2008 Active Directory-Infrastruktur implementierten Gruppenrichtlinien 

sind ein leistungsfähiges Instrument zum Zentralisieren der Netzwerksicherheit für Ihre 

Netzwerkclients. Tabelle 13.8 bietet eine Übersicht der Richtlinieneinstellungen, die mit der Netzwerksicherheit 

in Zusammenhang stehen. 

Tabelle 13.8 

Netzwerksicherheitseinstellungen in der Gruppenrichtlinienkonsole 


Richtlinien für verkabelte Netzwerke 

(IEEE 802.3) 

Windows-Firewall mit erweiterter 

Sicherheit 

Netzwerklisten-Manager-Richtlinien 

Drahtlosnetzwerkrichtlinien (IEEE 

802.11) 

Richtlinien für öffentliche Schlüssel 

(Diese Einstellung ist sowohl in Computerkonfiguration 

als auch in Benutzerkonfiguration 

enthalten. Die 

Benutzerkonfiguration enthält eine 

kleinere Teilmenge von Optionen.) 

Network Access Protection (Netzwerkzugriffsschutz) 

IP-Sicherheitsrichtlinien auf Active 

Directory (Domänenname) 

Erläuterung 

Wird zur Bereitstellung von Netzwerkkonnektivität und Sicherheitseinstellungen für 

Computer verwendet, die über einen 802.1X-kompatiblen Switch mit dem Netzwerk 

verbunden sind. 

Wird zur zentralen Konfiguration der integrierten Features in Zusammenhang mit 

Windows-Firewall und IPSec verwendet. 

Wird zum Angeben von Standardspeicherort und Benutzerberechtigungen für verschiedene 

Netzwerkstatus verwendet. Verfügbare Einstellungen lauten Netzwerke 

werden identifiziert, Nicht identifizierte Netzwerke und Alle Netzwerke. 

Wird zum Erstellen von Richtlinien für Drahtlosnetzwerke verwendet. Anschließend 

können die Richtlinien zum Steuern der Sicherheitsanforderungen für Computer verwendet 

werden, die drahtlose Netzwerkverbindungen nutzen. 

Wird zum Konfigurieren einiger Richtlinien im Zusammenhang mit digitalen Zertifikaten 

und der Zertifikatverwaltung verwendet. Sie können diese Richtlinien auch zum 

Erstellen von Datenwiederherstellungs-Agents zum Wiederherstellen von Dateien verwenden, 

die auf lokalen Arbeitsstationen mittels des verschlüsselnden Dateisystems 

(Encrypting File System, EFS) verschlüsselt wurden. 

Wird zum zentralen Konfigurieren der NAP Client-Einstellungen wie beispielsweise 

zum Aktivieren und Verwalten von NAP-Erzwingungsclients, zum Konfigurieren von 

Benutzeroberflächeneinstellungen und zum Konfigurieren von Einstellungen für vertrauenswürdige 

Servergruppen verwendet. 

Wird zum Konfigurieren der IPSec-Richtlinien (IP Security) für frühere Versionen von 

Windows (vor Windows Vista und Windows Server 2008) verwendet. Sie können 

Richtlinien konfigurieren, die präzise definieren, welcher Netzwerkdatenverkehrstyp 

mit IPSec geschützt werden muss, und Sie können festlegen, für welche Computer 

die Richtlinie erzwungen werden soll. Für Windows Vista und Windows Server 2008 

sollten Sie für IPsec-bezogene Einstellungen die Richtlinie Windows-Firewall mit erweiterter 

Sicherheit verwenden.

Konfigurieren der Netzwerksicherheit mit Gruppenrichtlinien 529 

Konfigurieren der Sicherheit für verkabelte Netzwerke 

Windows Server 2008 enthält eine neue Funktion Richtlinien für verkabelte Netzwerke (IEEE 802.3), 

um die automatisierte Konfiguration für Windows Vista- oder Windows Server 2008-Computer zu 

ermöglichen, die über einen 802.1X-kompatiblen Switch mit dem Netzwerk verbunden sind. Diese 

Funktion bietet nicht nur eine komfortable Möglichkeit, 802.1X-basierte Konnektivität zu konfigurieren, 

sondern bietet darüber hinaus zusätzliche Sicherheitsvorteile durch Integration in die neue Funktion 

Netzwerkzugriffsschutz (Network Access Protection, NAP) von Windows Server 2008. 

Um eine neue Richtlinie für verkabelte Netzwerke zu erstellen, klicken Sie mit der rechten Maustaste 

auf den Knoten Richtlinien für verkabelte Netzwerke (IEEE 802.3) und wählen die Option Eine neue 

Windows Vista-Richtlinie erstellen. Wie in Abbildung 13.9 gezeigt, können Sie dann einen Namen 

und eine Beschreibung für die Richtlinie für verkabelte Netzwerke angeben. 

Abbildung 13.9 Konfigurieren des Features Richtlinien für verkabelte Netzwerke (IEEE 802.3) 

Die Option Windows-Dienst für automatische Konfiguration verkabelter Netzwerke für Clients verwenden 

ist ein wichtiges Feature, das die eigentliche Konfiguration durchführt und Clients mit dem 

verkabelten 802.3-Netzwerk verbindet. Wenn Sie diese Option deaktivieren, führt Windows keine 

Steuerung der verkabelten LAN-Verbindung durch, und die Richtlinieneinstellungen haben keine 

Wirkung. 

Schutz des Dienstes für die automatische Konfiguration von Kabelnetzwerken 

Das Implementieren der Sicherheitseinstellungen für verkabelte Netzwerke mithilfe von Gruppenrichtlinien 

basiert auf dem Dienst für die automatische Konfiguration von Kabelnetzwerken 

(dot3svc).


Dieser Dienst (im System unter dem Dienstnamen Automatische Konfiguration (verkabelt) angezeigt) 

verwaltet Verbindungen mit Ethernet-Netzwerken über 802.1X-kompatible Switches sowie 

das zum Konfigurieren eines Netzwerkclients für den authentifizierten Netzwerkzugriff verwendete 

Profil. Um eine ordnungsgemäße Authentifizierung und Sicherheit für Ihre Netzwerkclients zu 

gewährleisten, müssen Sie verhindern, dass Mitglieder der Domäne den Startmodus des Dienstes 

für die automatische Konfiguration von Kabelnetzwerken ändern. Mit den Einstellungen der Gruppenrichtlinien 

können Sie den Starttyp des Dienstes für die automatische Konfiguration von Kabelnetzwerken 

festlegen. Wechseln Sie zum Zugriff auf diese Einstellung zu Computerkonfiguration\ 

Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Systemdienste. Anschließend können 

Sie die Sicherheitsrichtlinieneinstellung wie in Abbildung 13.10 gezeigt konfigurieren. 


Konfigurieren der Eigenschaften für den Dienst Automatische Konfiguration (verkabelt) 

Auf der Registerkarte Sicherheit können Sie Konfigurationseinstellungen für die Authentifizierungsmethode 

und den Modus für die Kabelverbindung festlegen. Tabelle 13.9 beschreibt die Optionen 

ausführlicher. 

Tabelle 13.9 

Optionen der Richtlinie für verkabelte Netzwerke 

Element 

IEEE 802.1X-Authentifizierung 

für Netzwerkzugriff aktivieren 

Netzwerkauthentifizierungsmethode 

auswählen 

Beschreibung 

Wird zum Aktivieren bzw. Deaktivieren der 802.1X-Authentifizierung für den Netzwerkzugriff 

verwendet. Diese Einstellung ist standardmäßig aktiviert. 

Über diese Dropdownliste kann die zum Authentifizieren von Netzwerkclients verwendeten 

Methode festgelegt werden. 

Zu den verfügbaren Optionen zählen: 

Microsoft: Geschütztes EAP (PEAP). Auf der Eigenschaftenseite für diese Option können 

Sie Konfigurationseinstellungen im Zusammenhang mit der Authentifizierungsmethode sowie 

Quarantäneprüfungen zur Nutzung mit NAP aktivieren. 

Microsoft: Smartcard- oder anderes Zertifikat. Auf der Eigenschaftenseite für diese Option 

können Sie u.a. das beim Herstellen der Verbindung zu verwendende Zertifikat sowie eine 

Liste der vertrauenswürdigen Stammzertifizierungsstellen festlegen.


Tabelle 13.9 

Optionen der Richtlinie für verkabelte Netzwerke 

Element 

Authentifizierungsmodus 

Beschreibung 

Über diese Einstellung können Sie festlegen, wie die Netzwerkauthentifizierung durchgeführt 

wird. Zu den verfügbaren Optionen zählen: 

Wiederholte Benutzerauthentifizierung. Diese Einstellung gewährleistet, dass Sicherheitsanmeldeinformationen 

auf Basis des aktuellen Status des Computers ausgewertet werden. 

Ist kein Benutzer angemeldet, werden die Computeranmeldeinformationen authentifiziert. 

Wenn sich ein Benutzer anmeldet, werden die Benutzeranmeldeinformationen ausgewertet. 

Diese Einstellung wird empfohlen. 

Nur Computer. Nur die Computeranmeldeinformationen werden zur Authentifizierung herangezogen. 

Benutzerauthentifizierung. Diese Einstellung erzwingt nur dann die Benutzerauthentifizierung, 

wenn der Benutzer sich mit einem neuen 802.1X-kompatiblen Gerät verbindet. 

Andernfalls basiert die Authentifizierung hauptsächlich auf den Computeranmeldeinformationen. 

Gastauthentifizierung. Ermöglicht Verbindungen auf Basis des Benutzerkontos Gast. 

Konfigurieren der Sicherheit für drahtlose Netzwerke 

Ähnlich wie Windows Server 2008 Features für die Sicherheit verkabelter Netzwerke bietet, ermöglicht 

Windows Server 2008 Gruppenrichtlinieneinstellungen zur Konfiguration von Clients für die 

sichere Verbindung mit 802.1X-kompatiblen drahtlosen Zugriffspunkten. Dieses Feature verhindert, 

dass unberechtigte und nicht authentifizierte Benutzer und Computer sich mit Ihrem drahtlosen Netzwerk 

verbinden, und unterstützt Computer, auf denen Windows XP, Windows Server 2003, Windows 

Vista und Windows Server 2008 ausgeführt wird. 

Um eine Richtlinie für Drahtlosnetzwerke zu erstellen, klicken Sie mit der rechten Maustaste auf den 

Knoten Drahtlosnetzwerkrichtlinien (IEEE 802.11). Beachten Sie, dass Sie zwei Typen von Netzwerkrichtlinien 

erstellen können. Die Option Eine neue Windows XP-Richtlinie erstellen ähnelt den in 

früheren Versionen von Windows verfügbaren Konfigurationsmethoden und Funktionen. Die Option 

Eine neue Windows Vista-Richtlinie erstellen ermöglicht es, Einstellungen für drahtlose Netzwerke, 

Sicherheit und Verwaltung zu konfigurieren, die nur in Windows Vista verfügbar sind. 

Die Richtlinien für Windows Vista-Drahtlosnetzwerke (IEEE 802.11) bieten unter anderem die folgenden 

Verbesserungen: 

• Möglichkeit zum Konfigurieren mehrerer Profile unter Angabe derselben SSID (Service Set 

Identifier), aber mit verschiedenen Authentifizierungsmethoden 

• Möglichkeit zum Konfigurieren des Zulassens und Ablehnens von Listen für drahtlose Netzwerke, 

die nicht vom Administrator kontrolliert werden 

• Unterstützung der aktuellsten Authentifizierungsoptionen inklusive WPA2 (Wi-Fi Protected 

Access 2) 

• Integration in den Netzwerkzugriffsschutz (Network Access Protection, NAP) zur Einschränkung 

von drahtlosen Clients, die spezifischen Konfigurations- oder Statusanforderungen nicht gerecht 

werden


Konfigurieren von Windows-Firewall und IPsec-Sicherheit 

Windows Server 2008 und Windows Vista weisen eine bedeutende Verbesserung bezüglich der Verwendung 

der Richtlinien für Windows-Firewall und IPsec für die sichere Netzwerkkommunikation auf. Die 

Windows-Firewall mit erweiterter Sicherheit kombiniert die Funktionalität einer Hostfirewall mit den 

Authentifizierungs- und Verschlüsselungsfunktionen von IPsec. Dieses Features bietet eine leistungsfähige 

Hostfirewall, die zum Prüfen und Filtern des ein- und abgehenden IPv4- und IPv6-Datenverkehrs 

verwendet werden kann. IPsec-Funktionen beinhalten die Möglichkeit zur Anforderung einer 

gegenseitigen Authentifizierung von Computern vor der Kommunikation sowie die Verwendung von 

Datenintegrität oder -verschlüsselung bei der Kommunikation mit anderen Netzwerkhosts. 

Die Windows-Firewall mit erweiterter Sicherheit weist drei Hauptkomponenten auf, die direkt auf 

dem Hostcomputer konfiguriert und verwaltet oder zentral konfiguriert und mittels eines Gruppenrichtlinienobjekts 

auf einen Active Directory-Container angewendet werden können. Zu diesen Komponenten 

gehören: 

• Firewallregeln Firewallregeln können sowohl für den ein- als auch für den ausgehenden Datenverkehr 

erstellt werden. Sie können Regeln erstellen, die bestimmen, welche Computer, Benutzer, 

Programme, Dienste, Ports oder Protokolle sich mit dem geschützten Computer verbinden können. 

Außerdem können Sie festlegen, auf welche Netzwerkverbindung die Regel angewendet 

wird, z.B. auf ein lokales Netzwerk, ein drahtloses LAN, ein virtuelles privates Netzwerk oder 

alle Typen. 

• Verbindungssicherheitsregeln Verbindungssicherheitsregeln werden zum Konfigurieren von 

IPsec-Einstellungen für die Verbindung zwischen dem Hostcomputer und anderen Computern verwendet. 

Die Verbindungssicherheit bezieht sich in der Regel auf die Authentifizierung zwischen 

zwei Computern, bevor diese beginnen, Daten auszutauschen. Sie können jedoch auch Datenintegrität 

und -verschlüsselung konfigurieren, um zusätzliche Sicherheit zu gewährleisten. 

• Profile Dem Hostcomputer wird ein spezifisches Profil zugewiesen, um eindeutige Firewall- und 

Verbindungssicherheitsregeln bereitzustellen. Maßgeblich für das Profil ist, von wo aus der Computer 

die Verbindung herstellt. Drei Profilen von Windows Vista und Windows Server 2008 können 

Firewall- und Verbindungssicherheitsregeln zugewiesen werden: 

Domäne Dieses Profil wird angewendet, wenn ein Computer mit der zugehörigen Unternehmensdomäne 

verbunden wird. 

Privat Dieses Profil wird angewendet, wenn ein Computer mit einem Netzwerk verbunden 

wird, welches nicht das residente Domänenkonto des Computers enthält (z.B. ein Heimnetzwerk). 

Diese Einstellung ist restriktiver als das Domänenprofil. 

Öffentlich Dieses Profil wird angewendet, wenn ein Computer mit einem öffentlichen Netzwerk 

verbunden wird (z.B. einem Flughafen oder Café). Diese Profileinstellung muss so restriktiv 

wie möglich sein. 

Wie in Abbildung 13.11 gezeigt, bietet der Knoten Windows-Firewall mit erweiterter Sicherheit im 

Gruppenrichtlinienverwaltungs-Editor eine allgemeine Übersicht der aktuellen GPO-Konfiguration 

für jedes Profil und eine assistentenbasierte Methode zum Konfigurieren von Verbindungssicherheitsregeln 

sowie eingehenden und ausgehenden Regeln.



Konfigurieren der Windows-Firewall mit erweiterter Sicherheit 

Sie können den Standardstatus jedes Profils konfigurieren, indem Sie mit der rechten Maustaste auf 

Windows-Firewall mit erweiterter Sicherheit klicken und dann Eigenschaften wählen. Wie in 

Abbildung 13.12 gezeigt, hat jedes Profil spezifische Einstellungen hinsichtlich Firewallstatus, Einstellungen 

sowie Protokollierung. Die standardmäßigen IPsec-Einstellungen wie Schlüsselaustausch-, 

Datenschutz- und Authentifizierungsmodus können auch zur Anwendung auf gruppenrichtlinienbasierte 

Clients konfiguriert werden. 

Weitere Informationen Weitere Informationen zum Erstellen von Firewall- und Verbindungssicherheitsregeln 

finden Sie (in englischer Sprache) im Artikel „Introduction to Windows Firewall with Advanced 

Security“ unter http://www.microsoft.com/downloads/details.aspx?familyid=df192e1b-a92a-4075-9f69- 

c12b7c54b52b&displaylang=en.



Konfigurieren von Profil- und IPsec-Standardeinstellungen 

Konfigurieren von Sicherheitseinstellungen anhand von 

Sicherheitsvorlagen 

Wie bereits erörtert, stehen Hunderte von Optionen zur Konfiguration der Sicherheit mit Gruppenrichtlinien 

zur Verfügung. Auf den ersten Blick wirken die Optionen in ihrer Vielzahl vielleicht überwältigend, 

sodass der Benutzer kaum erkennt, wo er mit der Konfiguration der Sicherheitsoptionen 

beginnen kann. Glücklicherweise erlaubt Microsoft das Erstellen und Anwenden von Sicherheitsvorlagen, 

um diese Aufgabe ein wenig zu erleichtern. 

Hinweis Frühere Versionen von Windows Server enthalten Beispiele vordefinierter Sicherheitsvorlagen. 

Windows Server 2008 enthält keine Beispielvorlagen. 

Sicherheitsvorlagen sind vordefinierte Sätze von Sicherheitskonfigurationen, die Sie auf Computer in 

Ihrem Netzwerk anwenden können. Anstatt jede der in diesem Kapitel erläuterten Sicherheitseinstellungen 

erneut durchgehen zu müssen, können Sie eine Ihrem Vorhaben entsprechende Sicherheitsvorlage 

auswählen und diese Vorlage mithilfe von Gruppenrichtlinien anwenden. Wenn Sie z.B. Arbeitsstationen 

in einer Umgebung einrichten, wo Sie strikte Sicherheitseinstellungen umsetzen möchten, 

können Sie eine Sicherheitsvorlage mit Hochsicherheitseinstellungen anwenden. Wenn Sie Arbeitsstationen 

mit geringerer Sicherheitsstufe einrichten, können Sie eine andere Vorlage anwenden, die 

weniger strikte Sicherheitseinstellungen für diese Arbeitsstationen konfiguriert. Sicherheitsvorlagen 

können den spezifischen Anforderungen Ihres Unternehmens angepasst werden. 

Sicherheitsvorlagen enthalten nicht alle, jedoch die gängigsten Sicherheitseinstellungen, die viele 

Unternehmen als Standardeinstellungen anwenden. Diese Optionen können in einer Sicherheitsvorlage 

konfiguriert werden:

Konfigurieren von Sicherheitseinstellungen anhand von Sicherheitsvorlagen 535 

• Kontorichtlinien 

• Lokale Richtlinien 

• Ereignisprotokoll 

• Eingeschränkte Gruppen 

• Systemdienste 

• Registrierung 

• Dateisystem 

Sie können Ihre eigene Sicherheitsvorlage erstellen oder eine vordefinierte Vorlage aus Drittanbieterquellen 

verwenden. Wenn Sie eine neue Vorlage erstellen, können Sie diese als textbasierte .inf-Datei 

speichern, sodass sie zur Anwendung auf Computer in ein Gruppenrichtlinienobjekt importiert werden 

kann. Öffnen Sie zum Erstellen einer neuen Sicherheitsvorlage eine MMC-Konsolenshell, und 

fügen Sie das Snap-In Sicherheitsvorlagen hinzu. Anschließend können Sie mit der rechten Maustaste 

auf den Pfadknoten klicken und Neue Vorlage wählen. Abbildung 13.13 zeigt zwei in der Konsole 

Sicherheitsvorlagen erstellte benutzerdefinierte Vorlagen. Beachten Sie, dass jede Vorlage auf 

den Anforderungen der Vorlage basierende eindeutige Einstellungen für jede Konfigurationseinstellung 

aufweisen kann. 


Erstellen einer benutzerdefinierten Sicherheitsvorlage 

Hinweis Der Windows Server 2008 Security Guide bietet spezifische Anleitungen und Beispielvorlagen 

zum Schutz von Serverrollen mithilfe von Sicherheitsvorlagen. Sie können den in englischer Sprache bereitgestellten 

Windows Server 2008 Security Guide unter http://www.microsoft.com/downloads/ 

details.aspx?familyid=FB8B981F-227C-4AF6-A44B-B115696A80AC&displaylang=en herunterladen.


Bereitstellen von Sicherheitsvorlagen 

Nachdem Sie eine Sicherheitsvorlage erhalten oder erstellt haben, können Sie sie mittels verschiedener 

Methoden bereitstellen: 

• Importieren der Sicherheitsvorlage in ein Gruppenrichtlinienobjekt 

• Verwenden des Tools Sicherheitskonfiguration und -analyse 

• Verwenden des Befehlszeilentools Secedit.exe 

• Verwenden des Sicherheitskonfigurations-Assistenten 

Verwenden von Gruppenrichtlinien zum Bereitstellen von Sicherheitsvorlagen 

Gruppenrichtlinien bieten eine praktische Möglichkeit, benutzerdefinierte Sicherheitsvorlagen für 

Ziel-OUs in Active Directory bereitzustellen. Die folgenden Schritte zeigen, wie Sicherheitsvorlagen 

mithilfe von GPOs bereitgestellt werden: 

1. Bearbeiten oder erstellen Sie von der Konsole Gruppenrichtlinienverwaltung aus eine neue GPO. 

2. Wechseln Sie zu Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen. 

3. Klicken Sie mit der rechten Maustaste auf Sicherheitseinstellungen, und klicken Sie dann auf 

Richtlinie importieren. 

4. Wählen Sie im Feld Richtlinie importieren von die Sicherheitsrichtlinie aus, die Sie importieren 

möchten, und klicken Sie auf Öffnen. 

5. Vergewissern Sie sich, dass die Sicherheitseinstellungen im GPO richtig sind, schließen Sie das 

GPO, und verknüpfen sie es mit dem entsprechenden Container in Active Directory. 

Verwenden des Tools Sicherheitskonfiguration und -analyse zum Anwenden von 

Sicherheitsvorlagen 

Das Tool Sicherheitskonfiguration und -analyse kann zum Erstellen bzw. Ändern bestehender Sicherheitsvorlagen 

verwendet werden. Eine Sicherheitsvorlage kann in das Tool Sicherheitskonfiguration 

und -analyse geladen und zum Analysieren und Vergleichen eines Zielcomputers verwendet werden. 

Sie können z.B. eine vorkonfigurierte Vorlage laden und dann einen Computer analysieren, um die 

Unterschiede zwischen der Vorlage und der aktuellen Computerkonfiguration festzustellen. 

Abbildung 13.14 zeigt ein Beispiel dieses Analyseergebnisses. 

Sie können mithilfe dieses Tools auch die Sicherheitsvorlage auf den Computer anwenden. Falls Sie 

sich dazu entschließen, die benutzerdefinierte Vorlage auf den Computer anzuwenden, können Sie mit 

der rechten Maustaste auf Sicherheitskonfiguration und -analyse klicken und Computer jetzt konfigurieren 

auswählen. Alle Sicherheitseinstellungen des Computers werden dann entsprechend der Sicherheitsvorlage 

geändert. 

Das Tool Sicherheitskonfiguration und -analyse ist nicht zur Verwendung mit Gruppenrichtlinien 

bestimmt. Dieses Tool kann dieselben vordefinierten Sicherheitsvorlagen wie der Gruppenrichtlinienverwaltungs-Editor 

verwenden, bietet jedoch eine alternative Möglichkeit zum Bereitstellen der Vorlage. 

Es ist primär zur Verwendung mit eigenständigen Computern vorgesehen.

Konfigurieren von Sicherheitseinstellungen anhand von Sicherheitsvorlagen 537 


-analyse 

Analyse einer Computersicherheitskonfiguration mithilfe des Tools Sicherheitskonfiguration und 

Verwenden des Tools Secedit.exe zum Anwenden von Sicherheitsvorlagen 

Das Befehlszeilentool Secedit weist eine ähnliche Funktionalität auf wie das Tool Sicherheitskonfiguration 

und -analyse. Mit Secedit können Sie die Computereinstellungen auf der Basis einer Vorlage 

analysieren und dann anwenden. Eine der nützlichen Features des Befehlszeilentools Secedit ist, dass 

Sie mit seiner Hilfe eine Rollbackkonfiguration generieren können, bevor Sie eine Sicherheitsvorlage 

anwenden. Diese Option ermöglicht das mühelose Wiederherstellen der vorherigen Einstellungen für 

den Fall, dass die von Ihnen angewendete Sicherheitsvorlage nicht geeignet ist. Wie das Tool Sicherheitskonfiguration 

und -analyse wird Secedit in der Regel nicht in einer Active Directory-Umgebung, 

sondern in eigenständigen Konfigurationen verwendet. Sie können Secedit jedoch in Anmelde- oder 

Startskripts verwenden, um spezifische sicherheitsbezogene Einstellungen auf eine Arbeitsstation 

anzuwenden. 

Integrieren des Sicherheitskonfigurations-Assistenten in Sicherheitsvorlagen und 


Wie in Kapitel 8, „Active Directory-Domänendienstsicherheit,“ beschrieben, kann der Sicherheitskonfigurations-Assistent 

(Security Configuration Wizard, SCW) zum Generieren und Konfigurieren 

XML-basierter Richtliniendateien verwendet werden, um zur Reduzierung der Angriffsfläche eines 

Domänencontrollers beizutragen.


Der Sicherheitskonfigurations-Assistent verfügt über einige zusätzliche Features, die zum Integrieren 

in Sicherheitsvorlagen und Gruppenrichtlinieneinstellungen verwendet werden können: 

• Einbeziehen vorkonfigurierter Sicherheitsvorlagen in die SCW-generierte Richtlinie 

• Möglichkeit zur Verwendung des Befehlszeilentools Scwcmd zum Umwandeln einer SCW-generierten 

Richtlinie in ein Gruppenrichtlinienobjekt 

Wenn Sie die Konfiguration einer Sicherheitsrichtlinie mit dem Sicherheitskonfigurations-Assistenten 

abschließen, müssen Sie einen Richtliniendateinamen und eine Beschreibung der Richtlinie angeben 

sowie vorkonfigurierte Sicherheitsvorlagen einbeziehen. Wenn Sie der SCW-Richtlinie Sicherheitsvorlagen 

hinzufügen, werden alle konfigurierten Einstellungen zusammen mit den weiteren 

Inhalten der SCW-Richtlinie angewendet. Sie müssen unbedingt beachten, dass jegliche auf die 

Registrierung oder Dateisystemobjekte bezogenen, in der Sicherheitsvorlage definierten Sicherheitsinformationen 

nicht mittels der SCW-Rollbackfunktion entfernt werden können, sobald sie angewendet 

wurden. Abbildung 13.15 zeigt ein Beispiel der Einbeziehung von Sicherheitsvorlagen in eine 

Richtlinie des Sicherheitskonfigurations-Assistenten. 


Einbeziehen von Sicherheitsvorlagen in eine SCW-Sicherheitsrichtlinie 

Auch im Sicherheitskonfigurations-Assistenten ist das Befehlszeilentool Scwcmd verfügbar, das zum 

Konvertieren einer SCW-basierten Richtlinie in ein nicht verknüpftes Gruppenrichtlinienobjekt verwendet 

werden kann. Führen Sie die Konvertierung mittels folgender Syntax durch: 

scwcmd transform /p:Richtliniendatei.xml /g:g:GPO-Anzeigename 

Das konvertierte GPO wird im Container Gruppenrichtlinienobjekte gespeichert und kann mithilfe 

der Konsole Gruppenrichtlinienverwaltung angezeigt und verwaltet werden. Anschließend können 

Sie das GPO über die Konsole Gruppenrichtlinienverwaltung mit Active Directory-Zielcontainern 

verknüpfen.



Der Active Directory-Domänendienst stützt sich darauf, dass mithilfe von Gruppenrichtlinien Standardsicherheitseinstellungen 

sowohl für die Domäne als auch die Domänencontroller innerhalb der 

Domäne bereitgestellt werden. Ein von Domänenadministratoren sicherlich begrüßtes neues Feature 

ist die Möglichkeit zur Implementierung fein abgestimmter Kennwortrichtlinien. Es ermöglicht die 

Implementierung verschiedener Kennworteinstellungen (z.B. Alter oder Länge des Kennworts) auf 

der Basis von Abteilungen oder Rollen innerhalb der Organisation. Neben domänenbasierten Sicherheitseinstellungen 

bieten die Gruppenrichtlinien auch eine Möglichkeit, die Verstärkung der Serversicherheit 

sowie Konfigurations- und Sicherheitseinstellungen für verkabelte und drahtlose Netzwerkkonfigurationen 

zentral zu verwalten. Zur Unterstützung der Verwaltung und Bereitstellung 

bestimmter Sicherheitseinstellungen können Sicherheitsvorlagen konfiguriert und entweder direkt auf 

einen Computer angewendet oder zur Anwendung auf mehrere Computer in ein Gruppenrichtlinienobjekt 

importiert werden. 



Kapitel. 


• In Kapitel 8, „Active Directory-Domänendienstsicherheit“, finden Sie nähere Informationen zum 

Schutz von Active Directory sowie zusätzliche Details zur Domänencontrollersicherheit. 

• Kapitel 9, „Delegieren der Active Directory-Domänendiensteverwaltung“, enthält Einzelheiten 

zur Überwachung von Active Directory-Objekten. 

• Kapitel 11, „Einführung in Gruppenrichtlinien“, stellt Einzelheiten zur Architektur und Konfiguration 

von Gruppenrichtlinienobjekten bereit. 

• Kapitel 12, „Einsetzen von Gruppenrichtlinien zum Verwalten von Benutzerdesktops“, enthält 

detaillierte Informationen zu verschiedenen Gruppenrichtlinieneinstellungen. 

• „Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration“ in 

englischer Sprache unter http://technet2.microsoft.com/windowsserver2008/en/library/2199dcf7- 

68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true. 

• „SO WIRD'S GEMACHT: Verwendung von Richtlinien für Softwareeinschränkung in Windows 

Server 2003“ unter http://support.microsoft.com/kb/324036. 

• „Introduction to Windows Firewall with Advanced Security“ in englischer Sprache unter http:// 

www.microsoft.com/downloads/details.aspx?familyid=df192e1b-a92a-4075-9f69- 

c12b7c54b52b&displaylang=en. 

• „Group Policy Wiki“ in englischer Sprache unter http://grouppolicy.editme.com/. 

• „Group Policy Team Blog“ in englischer Sprache unter http://blogs.technet.com/GroupPolicy/. 

• „Windows Server Group Policy“ in englischer Sprache unter http://technet.microsoft.com/en-ca/ 

windowsserver/grouppolicy/default.aspx. 

• „Windows Server 2008 Security Guide“ in englischer Sprache unter http://www.microsoft.com/ 

downloads/details.aspx?familyid=FB8B981F-227C-4AF6-A44B-B115696A80AC&displaylang=en.

T E I L I V 

Warten von Windows Server 2008 Active 



Kapitel 14: Überwachen und Warten von Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 

Kapitel 15: Active Directory-Notfallwiederherstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

543 

K A P I T E L 1 4 

Überwachen und Warten von Active Directory 


Überwachen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 

Verwalten der Active Directory-Datenbank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 



Ein wichtiger Bestandteil einer umsichtig entworfenen, geplanten und implementierten Active Directory-Infrastruktur 

und gleichzeitig die Voraussetzung zur Optimierung der Leistung und Zuverlässigkeit 

ist eine regelmäßige Überwachung und Wartung von Active Directory. Bei den Active Directory- 

Domänendiensten (Active Directory Domain Services, AD DS) handelt es sich um einen verteilten 

Netzwerkdienst, der in größeren Unternehmen sehr komplex sein kann und an dem täglich Tausende 

Änderungen vorgenommen werden, wie z.B. das Erstellen oder Löschen von Benutzerkonten oder 

das Ändern von Objektattributen, Gruppenmitgliedschaften und Berechtigungen. Um sicherzustellen, 

dass sich diese Änderungen sowie die sich stets ändernde Netzwerk- und Serverumgebung, in welcher 

der Dienst ausgeführt wird, nicht negativ auf die Leistung von Active Directory auswirken, 

müssen proaktive Maßnahmen ergriffen werden. In diesem Kapitel werden die beiden wesentlichen 

Bestandteile der Unterstützung Ihrer AD DS-Infrastruktur erläutert: die Überwachung von Domänencontrollern 

und die Wartung der Active Directory-Datenbank. 

Überwachen von Active Directory 

Um in Ihrer Organisation stets einen zuverlässigen Verzeichnisdienst bereitzustellen, ist die Überwachung 

des AD DS-Status unerlässlich. Ihre Benutzer vertrauen auf die effiziente Ausführung des Verzeichnisdienstes 

– sei es zur Anmeldung am Netzwerk, zum Zugreifen auf freigegebene Ressourcen 

oder zum Abrufen und Versenden von E-Mails. Sämtliche Aktivitäten, die Ihre Benutzer als kritisch 

einstufen würden, sind vom Status und der Verfügbarkeit von Active Directory abhängig. 

Die Überwachung der AD DS umfasst mehrere Aufgaben, die alle mit dem gleichen Ziel durchgeführt 

werden: die Messung des aktuellen Status und der Leistung verschiedener Schlüsselkomponenten 

(Speicherkapazität, Prozessorauslastung, Konfiguration usw.) im Vergleich zu einer sogenannten 

Baseline, welche die Standardanforderungen darstellt. Jede einzelne Komponente kann unterschiedliche 

Indikatoren umfassen, beispielsweise Leistungsindikatoren, Systemereignisse und -protokolle 

(auch als Ablaufverfolgungsdaten bezeichnet) sowie Konfigurationsinformationen. Angesichts dieses 

großen Umfangs an Informationen, die zusammengetragen werden können, ist die Implementierung 

einer Überwachungslösung für die Zusammenführung all dieser Indikatoren erforderlich, um Informationen 

bereitzustellen, mit denen Sie Ihre Servicelevelziele vorausschauend und effizient umsetzen 

können. Windows Server 2008 stellt zu diesem Zweck einen verbesserten Toolsatz bereit, die Zuverlässigkeits- 

und Leistungsüberwachung.

544 Kapitel 14: Überwachen und Warten von Active Directory 

Diese neue Überwachungskonsole kann für die Untersuchung vieler unterschiedlicher Komponenten 

verwendet werden, die mit der Serverleistung verbunden sind. Diese Untersuchungen können entweder 

in Echtzeit durchgeführt werden, oder es werden Protokolldaten für eine spätere Analyse gesammelt. 

Hinweis Viele auf dem Markt erhältliche und für große Unternehmen wohl unerlässliche Dienstprogramme 

ermöglichen eine Überwachung dieser Schlüsselindikatoren über eine einfach zu verwaltende 

Schnittstelle. Diese Dienstprogramme sind jedoch häufig nicht nur kosten- und ressourcenintensiv, sondern 

auch sehr komplex. Die Zuverlässigkeits- und Leistungsüberwachung von Windows umfasst zahlreiche 

wesentliche Features, wodurch für kleinere Unternehmen nicht mehr unbedingt die Notwendigkeit zum 

Erwerb hochentwickelter Überwachungslösungen von Drittanbietern besteht. 

Für ein umfassendes Verständnis der Active Directory-Überwachung ist es unerlässlich zu wissen, aus 

welchem Grund eine Überwachung erforderlich ist, auf welche Weise Active Directory überwacht 

wird und welche Komponenten innerhalb der Active Directory-Umgebung überwacht werden sollten. 

Um Ihren Verzeichnisdienst auch bei höchsten Leistungsanforderungen weiterhin zuverlässig ausführen 

zu können, müssen Sie außerdem wissen, welche Maßnahmen Sie im Rahmen der Überwachung 

ggf. ergreifen müssen. Dieses Kapitel liefert Antworten auf diese Fragen und unterstützt Sie dabei, die 

beste Methode zum Überwachen und Warten Ihrer AD DS-Umgebung zu ermitteln. 

Direkt von der Quelle: Überwachen von Active Directory, Teil 1 

Ein umfassendes Verständnis für die Bedeutung der Überwachung von Active Directory in einem 

Verwaltungszusammenhang ist unerlässlich. Beispielsweise kann das Messen der LDAP-Lookupleistung 

nützlich sein, bietet jedoch keinen vollständigen Überblick. In diesem Zusammenhang 

bedeutet ein erfolgreicher LDAP-Lookup nicht, dass das erwartete Gruppenrichtlinienobjekt angewendet 

werden kann oder dass Sie den nächstgelegenen Active Directory-Domänencontroller zum 

Authentifizieren ermitteln können. Die Verwendungsweise von Active Directory bietet viele Funktionalitäten, 

die über das gesamte Windows-System verteilt und eng mit dem Active Directory- 

Inhalt verknüpft sind. Beispielsweise werden durch eine Authentifizierungsanforderung nachfolgende 

Prozesse gestartet und zahlreiche Features in Active Directory oder in Zusammenhang mit 

Active Directory genutzt, wie z.B. DNS-Lookups, LDAP-Anforderungen, Kerberos-Anforderungen, 

Gruppenrichtlinienobjekteinstellungen, Netzwerkzugriffe auf SYSVOL und Basisverzeichnisse 

usw. Daher ist es wichtig, dass die Überwachung von Active Directory auf ganzheitlicher 

Basis und nicht komponentenbasiert durchgeführt wird, auch wenn es letztlich die Summe und 

Korrelation der überwachten Komponenten ist, die eine ganzheitliche Überwachung und den Status 

von Active Directory als Ganzes ausmacht. Durch eine ganzheitliche Überwachung des Active 

Directory-Status erhalten Sie einen realistischen Überblick über die Verfügbarkeit und Zuverlässigkeit 

Ihrer Active Directory-Implementierung zur Unterstützung Ihres gesamten Unternehmens. 

Alain Lissoir 

Senior Program Manager 

Active Directory – Connected System Division 

Gründe für die Überwachung von Active Directory 

Ein guter Grund für die Überwachung von Active Directory besteht darin, dass mögliche Probleme 

erkannt werden, bevor diese lange Dienstunterbrechungen verursachen.

Überwachen von Active Directory 545 

Aus geschäftlicher Sicht ermöglicht Ihnen die Überwachung die Einhaltung Ihrer Vereinbarung zum 

Servicelevel (Service Level Agreement, SLA) mit Ihren Kunden (den Netzwerkbenutzern). Sie sollten 

auf jeden Fall den Status von Active Directory überwachen, um Probleme schnellstmöglich vor 

dem Auftreten von Dienstunterbrechungen zu ermitteln. 

Hinweis Bei einer SLA handelt es sich um einen Vertrag zwischen einem Dienstanbieter (Ihnen) und den 

Benutzergruppen, in dem die Verantwortlichkeiten jeder Partei definiert werden und aus dem sich die Verpflichtung 

zur Bereitstellung eines bestimmten Servicelevels in festgelegtem Umfang und zu festgelegter 

Qualität ergibt. Im Kontext von Active Directory würde eine SLA zwischen der IT-Abteilung und den Benutzergruppen 

den höchsten Grad an annehmbaren Systemausfallzeiten sowie Leistungsmesswerte umfassen, wie 

beispielsweise die Zeit, die bei Supportanforderungen zwischen Anmeldung und Antwort vergeht. Als Gegenleistung 

dazu, dass sich der Dienstanbieter zur Einhaltung bestimmter Leistungs- und Betriebsstandards verpflichtet, 

erklären sich die Benutzergruppen dazu bereit, einen bestimmten Grad an Auslastung einzuhalten, 

z.B. dass die Active Directory-Gesamtstruktur nicht mehr als 10.000 Benutzer umfassen kann. 

Die Möglichkeit, Änderungen an der Infrastruktur nachverfolgen zu können, ist ein weiterer Grund, 

der für die Überwachung des Systemstatus von Active Directory spricht. Hat die Größe Ihrer Active 

Directory-Datenbank seit dem vergangenen Jahr zugenommen? Sind alle Ihre globalen Katalogserver 

(Global Catalog, GC) online? Wie lange dauert es, bis an einem Domänencontroller in Frankreich 

vorgenommene Änderungen auf einen Domänencontroller in Australien repliziert werden? Antworten 

auf all diese Fragen können zwar nicht verhindern, dass heute ein Fehler auftritt, Sie erhalten 

jedoch wertvolle Informationen, die Sie für zukünftige Planungen verwenden können. 

Vorteile der Überwachung von AD DS 

Die Überwachung von Active Directory bringt zahlreiche Vorteile mit sich: 

• Die Möglichkeit zur Einhaltung der mit Benutzern geschlossenen SLAs durch die Vermeidung 

von Dienstausfallzeiten 

• Erhöhte Leistungsfähigkeit von Active Directory durch die Behebung ansonsten unentdeckter 

Dienstengpässe 

• Geringere Verwaltungskosten durch proaktive Systemwartung 

• Verbesserte Möglichkeiten zum Skalieren und Planen zukünftiger Infrastrukturänderungen durch 

ein fundiertes Wissen über Komponenten, Kapazitäten und Auslastung von Active Directory 

• Erhöhte Wertschätzung der IT-Abteilung aufgrund von Kundenzufriedenheit 

Kosten der Active Directory-Überwachung 

Die Überwachung Ihrer Active Directory-Infrastruktur ist mit Kosten verbunden. Im Folgenden werden 

einige Kostenfaktoren aufgeführt, die mit der Implementierung einer effektiven Überwachungslösung 

verbunden sind: 

• Arbeitsstunden, die für Entwurf, Bereitstellung und Verwaltung einer Überwachungslösung anfallen. 

• Ausreichend finanzielle Mittel, die für den Erwerb der erforderlichen Verwaltungstools, Schulungen 

und der zum Implementieren der Dienstüberwachung benötigten Hardware erforderlich sind. 

• Ein Teil der Netzwerkbandbreite wird für die Überwachung des Active Directory-Status auf allen 

Domänencontrollern im Unternehmen genutzt. 

• Speicher- und Prozessorressourcen werden zum Ausführen von Agent-Anwendungen auf 

Zielservern und auf dem Computer der zentralen Überwachungskonsole genutzt.


Es sollte ebenfalls erwähnt werden, dass ein Wechsel auf eine unternehmensweite Überwachungsplattform 

wie beispielsweise Microsoft System Center Operations Manager mit relativ hohen 

Anfangskosten verbunden ist. Bei einer solchen Lösung fallen zusätzliche Softwarekosten an, es sind 

Operatorschulungen erforderlich, und unter Umständen werden mehr Systemressourcen genutzt, als 

bei vielen systemeigenen Windows Server 2008-Überwachungstools. Dennoch handelt es sich bei 

diesen Unternehmensüberwachungssystemen um bewährte, integrierte sowie unterstützte Produkte 

mit Features, die langfristig eine Kosteneinsparung und eine erhöhte Betriebseffizienz für die Verwaltungs- 

und Überwachungsumgebung sicherstellen. 

In welchem Umfang Sie Ihre Überwachung planen, ist von Ihrer Kosten-Nutzen-Analyse abhängig. 

Die für die Überwachungslösung bereitgestellten Ressourcen sollten allerdings nicht die Einsparungen 

übersteigen, die Sie voraussichtlich durch die Überwachung erzielen. Aus diesem Grund stellt 

für größere Unternehmen die Investition in Unternehmensüberwachungslösungen die kosteneffektivste 

Möglichkeit dar. Für kleinere Unternehmen ist es jedoch oftmals sinnvoller, die in Windows 

Server 2008 integrierten Überwachungstools zu verwenden. 

Hinweis System Center Operations Manager bietet eine Ereignisverwaltung, Dienstüberwachung und ein 

Warnungssystem, eine Berichterstellung sowie Trendanalysen. Diese Lösung arbeitet mit Agents, die auf 

den verwalteten Knoten (überwachte Server) ausgeführt werden und Daten zur Analyse, Verfolgung und 

Anzeige an eine zentrale Verwaltungskonsole senden. Durch diese Zentralisierung kann ein Netzwerkadministrator 

die Verwaltung einer umfassenden Sammlung an unterschiedlichsten Servern von einem einzigen 

Standort mithilfe von leistungsstarken Verwaltungstools zur Remoteverwaltung bewerkstelligen. Operations 

Manager verwendet Management Packs, um die Knowledge Base für Daten bestimmter Netzwerkdienste 

sowie serverbasierter Anwendungen zu erweitern. Management Packs sind für viele Dienste und Anwendungen 

erhältlich, wie beispielsweise für Active Directory, DNS (Domain Name System), die Microsoft 

Internetinformationsdienste (Internet Information Services, IIS) und Microsoft Exchange Server. Weitere 

Informationen zu Operations Manager finden Sie unter http://www.microsoft.com/systemcenter/opsmgr/ 

default.mspx (in englischer Sprache). 

Überwachen von Serverzuverlässigkeit und -leistung 

Windows Server 2008 umfasst die Zuverlässigkeits- und Leistungsüberwachung, die zum Analysieren 

der Systemleistung sowie zum Bereitstellen von Informationen zur Zuverlässigkeit zahlreicher 

Windows- und anwendungsbezogener Komponenten verwendet wird. Die Zuverlässigkeits- und Leistungsüberwachung 

wird über das Menü Verwaltung gestartet und umfasst drei Überwachungstools, 

die im Rahmen bestimmter Überwachungs- und Fehlerbehebungsanforderungen genutzt werden können: 

den Ressourcenmonitor, den Systemmonitor sowie die Zuverlässigkeitsüberwachung. 

Ressourcenübersicht 

Auf der Startseite der Ressourcenübersicht wird eine Zusammenfassung der Auslastung und Leistung 

von CPU, Festplatte, Netzwerk und Arbeitsspeicher des Servers angezeigt. Die Daten werden in Echtzeit 

bereitgestellt und in Form von vier Diagrammen dargestellt. Wie in Abbildung 14.1 dargestellt, 

wird bei Auswahl des Stammknotens in der Zuverlässigkeits- und Leistungsüberwachung die Ressourcenübersicht 

dargestellt. Sie können zusätzliche Informationen zu jeder Komponente anzeigen, 

indem Sie die den jeweiligen Detailbereich erweitern. Wenn Sie beispielsweise ermitteln möchten, 

welche Prozesse derzeit ausgeführt werden und welche durchschnittliche CPU-Auslastung jeder Prozess 

erzeugt, können Sie den Bereich CPU erweitern, in dem Ihnen die erforderlichen Informationen 

bereitgestellt werden.



Anzeigen von Details in der Ressourcenübersicht 

Hinweis Sie können den Ressourcenmonitor in einem eigenständigen Fenster öffnen, indem Sie über das 

Startmenü den Befehl perfmon /res eingeben. Wenn in der Ressourcenübersicht keine Echtzeitdaten angezeigt 

werden, starten Sie den Monitor durch Klicken auf die grüne Startschaltfläche (nur in der Konsole 

Zuverlässigkeit und Leistung) oder indem Sie im Menü Überwachen auf Starten klicken (nur in der Darstellung 

Ressourcenmonitor). 

Systemmonitor 

Der Systemmonitor kann zur Echtzeitanzeige von Leistungsdaten auf einem lokalen Computer oder 

mehreren Remotecomputern verwendet werden. Darüber hinaus können Sie den Systemmonitor zur 

Anzeige gespeicherter Protokolldateien verwenden, was die Ermittlung von Leistungstrends erheblich 

vereinfacht. Die Grundfunktionen des Systemmonitors haben sich im Vergleich zu Windows-Vorgängerversionen 

nur wenig verändert, es werden unter anderem die folgenden nützlichen Optionen 

bereitgestellt: 

• Wählen Sie zum Anpassen der Ansicht eines bestimmten Indikators den Indikator im unteren 

Bereich des Detailbereichs aus, und klicken Sie in der Symbolleiste auf die Schaltfläche Markierung 

(oder drücken Sie STRG + H). Dadurch wird die Diagrammlinie des ausgewählten Indikators 

hervorgehoben und ist innerhalb des Diagramms leichter erkennbar.


• Sie können zwischen den Ansichten Linie, Histogrammleiste oder Bericht wechseln, indem Sie 

auf der Symbolleiste die entsprechende Schaltfläche auswählen. 

• Sie können Diagrammeinstellungen des Systemmonitors als .html-Seite speichern. Konfigurieren 

Sie hierzu ein Diagramm mit den erforderlichen Indikatoren, klicken Sie mit der rechten Maustaste 

auf das Diagramm, und wählen Sie Einstellungen speichern unter. Das Diagramm wird als 

.html-Datei gespeichert, die Sie in einem Browser öffnen können. Beim Öffnen der .html-Version 

des Diagramms ist die Anzeige fixiert. Klicken Sie in der Leistungssymbolleiste des Browsers auf 

die Schaltfläche Fixierung der Anzeige aufheben, um die Überwachung erneut zu starten. 

• Sie können ein gespeichertes Diagramm in den Systemmonitor importieren, indem Sie die .html- 

Datei auf das Fenster des Systemmonitors ziehen. Auf diese Weise können Sie häufig verwendete 

Leistungsdiagramme einfach speichern und erneut laden. 

• Durch die beiden neuen Sicherheitsgruppen in Windows Server 2008 wird sichergestellt, dass nur 

vertrauenswürdige Benutzer auf vertrauliche Leistungsdaten zugreifen und diese bearbeiten können: 

Die Gruppe Leistungsprotokollbenutzer und die Gruppe Systemmonitorbenutzer. 

Hinweis Sie können den Systemmonitor in einem eigenen Fenster öffnen, indem Sie über das Startmenü 

den Befehl perfmon /sys eingeben. 

Standardmäßig ist der Indikator Prozessorzeit (%) im Systemmonitor geladen. Um der Systemmonitorkonsole 

zusätzliche Indikatoren hinzuzufügen, führen Sie die folgenden Schritte aus: 

1. Klicken Sie mit der rechten Maustaste auf den Detailbereich des Systemmonitors, und klicken Sie 

auf Leistungsindikatoren hinzufügen. 

2. Klicken Sie im Dialogfeld Leistungsindikatoren hinzufügen auf , um den 

Computer zu überwachen, auf dem die Überwachungskonsole ausgeführt wird. Um einen 

bestimmten Computer unabhängig vom Standort der Überwachungskonsole zu überwachen, klicken 

Sie auf Durchsuchen, um einen Computernamen anzugeben. 

3. Erweitern Sie das gewünschte Leistungsobjekt, und klicken Sie dann auf den gewünschten Indikator. 

4. Klicken Sie auf Hinzufügen und dann auf OK. 

Wenngleich sich die grundlegenden Funktionen nicht verändert haben, wurden einige Verbesserungen 

an der Leistungskonsole vorgenommen. In Abbildung 14.2 werden einige dieser Verbesserungen 

dargestellt: 

• Verbesserte Indikatoroptionen Der Systemmonitor stellt verbesserte Steuermöglichkeiten für die 

Anzeige der Indikatoren innerhalb des Detailbereichs bereit. Für die beiden Balkendiagrammtypen 

Linie und Histogrammleiste haben Sie die Möglichkeit, ausgewählte Indikatoren schnell 

anzuzeigen oder auszublenden, indem Sie einfach das Kontrollkästchen unterhalb der Spalte 

Anzeigen aktivieren. Darüber hinaus können Sie ausgewählte Indikatoren einfach skalieren, um 

sicherzustellen, dass Daten innerhalb des Diagramms weiterhin angezeigt werden. In 

Abbildung 14.2 wurde für den Indikator Prozessorzeit (%) der Skalierungswert 10 festgelegt. 

• QuickInfos In Liniendiagrammen können Sie mithilfe des Mauszeigers genaue Leistungsindikatordaten 

ermitteln. In Abbildung 14.2 wird dargestellt, wie in einer QuickInfo Indikatorname, 

Wert und Zeit für den Datenpunkt angezeigt wird, auf den der Mauszeiger gerichtet ist.


• Zoom Im Systemmonitor können Sie durch Vergrößern eines bestimmten Zeitraums detailliertere 

Informationen zu Protokolldaten anzeigen. Beachten Sie, dass das Zoomfeature beim Erfassen 

von Daten in Echtzeit nicht zur Verfügung steht. 

• Vergleich mehrerer Protokolldateien In der eigenständigen Version des Systemmonitors wird ein 

Feature bereitgestellt, mit dem Sie anhand einer transparenten Überlagerung mehrere Protokolldateien 

mit einer Standardansicht vergleichen können. Öffnen Sie hierzu mehrere eigenständige 

Fenster des Systemmonitors, fügen Sie die Protokolldateien für den Vergleich zu jedem Fenster 

hinzu, und wählen Sie dann die Optionen im Menü Vergleichen aus. 


Anzeigen von Leistungsdaten 

Zuverlässigkeitsüberwachung 

In der Zuverlässigkeitsüberwachung werden Informationen zur Gesamtstabilität eines Servers bereitgestellt. 

Ein Systemstabilitätsindex wird auf der Grundlage von Daten berechnet, die beim Auftreten 

bestimmter Ereignisse innerhalb eines Servers während eines bestimmten Zeitraums gesammelt wurden. 

Zu diesen Ereignissen zählen: 

• Softwareinstallationen und -deinstallationen In dieser Kategorie werden Anwendungen aufgeführt, 

die mithilfe eines .msi-Installationspakets, einer Treiberinstallation und -deinstallation oder einer 

Softwareupdateinstallation oder -deinstallation installiert bzw. deinstalliert wurden, sowie 

Betriebssystemupdates wie beispielsweise Service Packs oder Hotfixes.


• Anwendungsfehler In dieser Kategorie wird über Ereignisse berichtet, die mit Anwendungsabstürzen 


• Hardwarefehler In dieser Kategorie wird über Ereignisse berichtet, die mit Festplatten- und Speicherfehlern 


• Windows-Fehler In dieser Kategorie wird über Startfehler, Betriebssystemabstürze und über Fehler 

im Ruhezustand berichtet. 

• Verschiedene Fehler In dieser Kategorie wird festgehalten, wenn das System unerwartet heruntergefahren 

wurde. 

• Systemzeitänderungen In dieser Kategorie wird über Änderungen an der Systemuhr des Servers 

berichtet. Diese Kategorie wird nicht im Systemstabilitätsbericht aufgeführt – es sei denn, Sie 

wählen einen Tag aus, an dem eine bedeutende Uhrzeitänderung vorgenommen wurde. Im Diagramm 

werden Tage mit einer bedeutenden Uhrzeitänderung mit einem Informationssymbol 

gekennzeichnet. 

Hinweis Sie können die Zuverlässigkeitsüberwachung in einem eigenen Fenster öffnen, indem Sie über 

das Startmenü den Befehl perfmon /rel eingeben. 


Anzeigen von Daten in der Zuverlässigkeitsüberwachung


Die Gesamtsystemstabilität kann ermittelt werden, indem Sie entweder das Systemstabilitätsdiagramm 

anzeigen oder mehrere Systemstabilitätsberichte überprüfen. Im Systemstabilitätsdiagramm wird täglich 

ein Stabilitätsindex mit einer Bewertung im Bereich von 1 bis 10 angezeigt. Eine Bewertung von 

10 verweist auf ein stabiles System, eine Bewertung von 1 verweist hingegen auf ein sehr instabiles System. 

Wenn Sie einen bestimmten Tag innerhalb des Diagramms hervorheben, können Sie den Durchschnittsindex 

anzeigen. In den im unteren Bereich des Detailbereichs aufgeführten Berichten werden ausführliche 

Informationen bereitgestellt. 

Wie in Abbildung 14.3 dargestellt, weist das hervorgehobene Datum einen Index von 8,81 auf, was im 

Vergleich zu den vorangegangenen Tagen, die im Systemstabilitätsdiagramm aufgeführt werden, auf 

eine Systeminstabilität hinweist. Für die Kategorie Softwareinstallationen/-deinstallationen wird ein 

Warnindikator angezeigt, und für die Kategorien Anwendungsfehler und Verschiedene Fehler wird ein 

Fehlerindikator angezeigt. Im Abschnitt Systemstabilitätsbericht werden die Informationen zu den an 

diesem speziellen Tag aufgetretenen Fehlern aufgeführt. 

Hinweis Bevor der Systemstabilitätsindex berechnet oder Informationen für den Systemstabilitätsbericht 

erstellt werden können, muss die Zuverlässigkeitsüberwachung über 24 Stunden hinweg Daten sammeln. 

Überblick über Sammlungssätze und Berichte 

Windows Server 2008 (wie auch Windows Vista) führt das Konzept der Sammlungssätze ein. Ein 

Sammlungssatz kann mehrere Datensammelpunkte (auch als Datensammler bezeichnet) enthalten, 

um eine einzelne konfigurierbare Komponente zu bilden. Diese Komponente kann dann konfiguriert 

werden, um Einstellungen bereitzustellen, wie z.B. das Planen des vollständigen Sammlungssatzes, 

die Sicherheit zum Ausführen oder Anzeigen des Sammlungssatzes sowie zum Ausführen bestimmter 

Aufgaben, nachdem der Sammlungssatz die Datenerfassung beendet hat. 

Ein Sammlungssatz kann viele unterschiedliche Datensammlertypen umfassen: 

• Leistungsindikatoren Dienen der Protokollierung von Systemleistungsdaten. Sie können die gleichen 

Indikatoren hinzufügen, die auch für die Anzeige von Echtzeitdaten im Systemmonitor verwendet 

werden. 

• Daten der Ereignisablaufverfolgung Dienen der Protokollierung von Informationen auf Grundlage 

von system- und anwendungsbasierten Ereignissen. Ereignisablaufverfolgungsanbieter werden in 

der Regel mit dem Betriebssystem installiert. Sie können außerdem von Anwendungsherstellern 

bereitgestellt werden. 

• Systemkonfigurationsinformationen Dienen der Protokollierung von Informationen, die mit der 

Konfiguration und Änderungen an Registrierungsschlüsseln in Zusammenhang stehen. Sie müssen 

genau wissen, welche Registrierungsschlüssel Sie in den zu überwachenden Sammlersatz 

integrieren möchten. 

• Leistungsindikatorenwarnungen Dienen der Konfiguration von Warnereignissen, die ausgelöst 

werden, wenn ein bestimmter Leistungsindikator einen festgelegten Schwellenwert erreicht oder 

diesen überschreitet. Sie können beispielsweise eine Warnung zum Durchführen einer Warnungsaktion 

oder -task konfigurieren, für den Fall, dass der Wert für % freier Speicherplatz auf einem 

Laufwerk 20 % unterschreitet. Eine Warnungsaktion kann einfach darin bestehen, einen Eintrag 

im Anwendungsereignisprotokoll zu protokollieren, oder sie kann darin bestehen, einen nachfolgenden 

Sammlungssatz zu starten, um zusätzliche Überwachungs- und Nachverfolgungsmöglichkeiten 

bereitzustellen.


So können auch einen Warnungstask konfigurieren, um eine bestimmte Anwendung beim Auslösen 

einer Warnung auszuführen, wie beispielsweise eine E-Mail-Benachrichtigung oder ein Verwaltungsdienstprogramm. 

Beachten Sie, dass diese Option beim manuellen Erstellen eines 

Sammlungssatzes verfügbar ist. 

Der Knoten Sammlungssätze befindet sich in der Zuverlässigkeits- und Leistungsüberwachung und 

besteht aus vier Containern, die zum Speichern unterschiedlicher Typen von Sammlungssätzen verwendet 

werden: 

• Benutzerdefiniert In diesem Container können Sie benutzerdefinierte Sammlungssätze entweder 

manuell oder anhand von vordefinierten Vorlagen erstellen und speichern. 

• System Abhängig von den dem Server hinzugefügten Serverrollen werden in diesem Container 

systembasierte Standardsammlungssätze gespeichert, die für die Bereitstellung von Active Directory-Diagnose, 

LAN-Diagnose, Systemdiagnose oder Systemleistung verwendet werden. An diesen 

Datensammlersätzen können zwar keine direkten Änderungen vorgenommen werden, aber sie 

können als Vorlage zum Erstellen eines neuen benutzerdefinierten Sammlungssatzes verwendet 

werden. 

• Ereignisablaufverfolgungssitzungen Dienen der Speicherung von Sammlungssätzen auf Grundlage 

von aktivierten Ereignisablaufverfolgungsanbietern. 

• Startereignis-Ablaufverfolgungssitzungen Dienen zum Speichern von Sammlungssätzen, die Ereignisablaufverfolgungsanbieter 

zum Überwachen von Startereignissen enthalten. 

In Abbildung 14.4 wird ein benutzerdefinierter Sammlungssatz dargestellt. In diesem Sammlungssatz 

sind zwei Sammlungen enthalten, die für die Basisleistungsermittlung für zahlreiche Indikatoren und 

NT-Kernel-Verfolgungsdaten verwendet werden. 


Anzeigen eines benutzerdefinierten Sammlungssatzes


Die folgenden Schritte beschreiben das Verfahren zum Erstellen eines Sammlungssatzes: 

1. Klicken Sie in der Zuverlässigkeits- und Leistungsüberwachung mit der rechten Maustaste auf 

Benutzerdefiniert, wählen Sie Neu, und klicken Sie dann auf Sammlungssatz. 

2. Geben Sie einen Namen für den Sammlungssatz an, und legen Sie fest, ob Sie den Sammlungssatz 

anhand einer Vorlage oder manuell erstellen möchten. 

3. Wenn Sie sich für die Verwendung einer Vorlage entscheiden, können Sie eine auf den Systemdatensammlungssätzen 

basierende Vorlage auswählen, oder Sie klicken auf Durchsuchen und 

wählen eine vorkonfigurierte .xml-basierte Vorlage aus. 

4. Wenn Sie sich für die manuelle Erstellung eines neuen Sammlungssatzes entscheiden, können Sie 

auswählen, welche Datenprotokolltypen Sie einschließen möchten (Leistungsindikator, Ereignisablaufverfolgung 

oder Systemkonfigurationsinformationen). Sie können außerdem eine Leistungsindikatorenwarnung 

erstellen. Abhängig von den gewählten Optionen werden bestimmte 

Konfigurationsseiten für jeden Datenprotokolltyp angezeigt. 

5. Wählen Sie ein Verzeichnis zum Speichern des neuen Sammlungssatzes. Standardmäßig werden 

Sammlungssätze unter %systemdrive%\PerfLogs\Admin\ gespeichert. 

6. Geben Sie das Konto an, das zum Ausführen des Sammlungssatzes verwendet werden soll. Standardmäßig 

werden Sammlungssätze als Systembenutzer ausgeführt. 

7. Klicken Sie auf Fertig stellen, um zur Konsole Zuverlässigkeits- und Leistungsüberwachung 

zurückzukehren. 


Berichtsergebnisse einer Datenerfassungsaufgabe


8. Klicken Sie mit der rechten Maustaste auf den Sammlungssatz, und klicken Sie anschließend auf 

Eigenschaften, um Änderungen an den Einstellungen für die gesamte Sammlung vorzunehmen. 

Sie können beispielsweise einen Zeitplan oder eine Stoppbedingung festlegen, um die Datenerfassung 

nach einem bestimmten Zeitraum anzuhalten. 

9. Um den Sammlungssatz zu starten, klicken Sie mit der rechten Maustaste auf den Sammlungssatz, 

und klicken Sie dann auf Starten. Die Sammlungen innerhalb des Satzes beginnen entsprechend 

der Konfiguration mit der Informationserfassung. Nach Ablauf des Zeitraums für die 

Datenerfassung wird automatisch ein Bericht erstellt und unterhalb des Knotens Berichte aufgeführt, 

wie in Abbildung 14.5 dargestellt. 

Überwachen von Active Directory 

In der Zuverlässigkeits- und Leistungsüberwachung werden viele Active Directory-Indikatoren und 

Ablaufverfolgungsereignisse aufgeführt, mit der eine effektive Systemüberwachung erzielt werden 

kann. Der Active Directory-Überwachungsvorgang besteht darin, die wichtigsten Leistungsindikatoren 

zu verfolgen und diese mit einer Baseline zu vergleichen, welche die Serviceausführung im 

Rahmen normaler Parameter darstellt. Anhand der Unterschiede zwischen den aktuellen Überwachungsergebnissen 

im Vergleich zu den Baselinewerten können Sie aktuelle oder potenzielle Probleme 

im Zusammenhang mit dem Verzeichnisdienst ermitteln. 

Wie bereits erwähnt, kann ein Sammlungssatz auch Leistungsindikatorenwarnungen enthalten. Wenn 

ein Leistungsindikator einen festgelegten Schwellenwert überschreitet, kann eine Warnung konfiguriert 

werden, um den Netzwerkadministrator (oder in größeren Unternehmen die für die Überwachung 

zuständige Person) über den Zustand zu informieren. Durch das Überschreiten eines Schwellenwerts 

kann auch ein innerhalb des Sammlungssatzes konfigurierter automatischer Vorgang 

gestartet werden, um das Problem zu beheben oder um eine weitere Verschlechterung der Leistung 

oder des Systemstatus weitestgehend einzuschränken. 

Im Folgenden werden die wesentlichen Schritte des Active Directory-Überwachungsverfahrens 

beschrieben: 

1. Ermitteln Sie, welche Sammlungen Sie für die Überwachung benötigen und welche Messwerte in 

Ihrem Unternehmen erforderlich sind. Dazu gehören Leistungsindikatoren, Ablaufverfolgungsinformationen 

und Registrierungseinstellungen. Die SLA Ihres Unternehmens stellt einen guten 

Anfang für die Bereitstellung von Informationen zu erwarteten Mess- und Schwellenwerten für 

die Leistungsindikatoren dar. 

2. Erstellen Sie einen Sammlungssatz, in dem alle erforderlichen Sammlungen enthalten sind. 

3. Führen Sie den Sammlungssatz aus, um eine Baseline zur Leistung zu ermitteln und zu dokumentieren. 

4. Ermitteln Sie die Schwellenwerte für diese Leistungsindikatoren. (Anders ausgedrückt: Ermitteln 

Sie, ab wann Maßnahmen erforderlich sind, um eine Dienstunterbrechung zu verhindern.) 

5. Entwerfen Sie das erforderliche Warnsystem, um bei Erreichen von Schwellenwerten entsprechende 

Maßnahmen einzuleiten. Ihr Warnsystem sollte folgende Komponenten umfassen: 

Operatorbenachrichtigungen 

Automatische Vorgänge, sofern geeignet 

Operator-initiierte Vorgänge


6. Entwerfen Sie ein Berichtssystem, um Verlaufsdaten zum Systemstatus von Active Directory zu 

erfassen. Sie können im Knoten Berichte Berichte auf Grundlage des Datums speichern, an dem 

der Sammlungssatz ausgeführt wurde. 

7. Implementieren Sie Ihre Überwachungslösung zum Messen der Leistung dieser Schlüsselindikatoren 

basierend auf einer Planung, die der Variabilität dieser Indikatoren und den Auswirkungen 

jedes einzelnen dieser Indikatoren auf den Active Directory-Status Rechnung trägt. 

Im verbleibenden Teil dieses Abschnitts werden die Einzelheiten des Überwachungsprozesses erläutert. 

Festlegen von Baselines und Schwellenwerten 

Nachdem Sie ermittelt haben, welche Sammlungen und Leistungsindikatoren für die Überwachung 

benötigt werden, sollten Sie Baselinedaten für diese Indikatoren sammeln, indem Sie einen Baselinesammlungssatz 

erstellen und ausführen. Der Baselinesammlungssatz stellt jeden Sammlungstyp dar, der 

im Rahmen des normalen Betriebs ausgeführt wird. Der Betrieb innerhalb normaler Parameter sollte 

sowohl die zu erwartenden niedrigsten als auch die höchsten Werte für einen bestimmten Leistungsindikator 

oder ein bestimmtes Ablaufverfolgungsereignis umfassen. Für die Erfassung besonders präziser 

Baselinedaten sollten Sie Leistungsinformationen über einen angemessenen Zeitraum hinweg sammeln, 

um den Wertebereich für einen bestimmten Parameter während ausgeprägter und geringer Aktivität zu 

erfassen. Wenn Sie beispielsweise die Baseline für die Authentifizierungsanforderungsleistung ermitteln, 

stellen Sie sicher, dass der Indikator während eines Zeitraums überwacht wird, in dem sich die 

meisten Benutzer anmelden. 

Zeichnen Sie während der Ermittlung der Baselinewerte diese Informationen auf, und vermerken Sie 

das Erstellungsdatum des Dokuments. Diese Werte werden nicht nur zum Festlegen von Schwellenwerten 

verwendet, sondern darüber hinaus auch zum Ermitteln von Leistungstrends über die Zeit. Zu 

diesem Zweck eignet sich besonders ein Tabellenkalkulationsblatt mit Spalten für Niedrig-, Durchschnitts- 

und Höchstwerten für jeden Indikator sowie für Schwellenwerte für Warnungen. 

Hinweis Legen Sie bei Änderungen an Ihrer Active Directory-Umgebung (wenn z.B. die Anzahl an Benutzern 

zunimmt oder Hardwareänderungen am Domänencontroller vorgenommen werden) Ihre Baselines 

erneut fest. Die Baseline sollte immer dem aktuellen Stand von Active Directory im Rahmen der normalen 

Leistungsgrenzen entsprechen. Für die Analyse aktueller Leistungsdaten ist eine veraltete Baseline nicht 

hilfreich. 

Nach der Ermittlung der Baseline werden als Nächstes die Schwellenwerte zum Erstellen eines Warnungs- 

oder Ereignistasks festgelegt. Abgesehen von den Empfehlungen von Microsoft gibt es keine 

allgemeinem Formel zum Ermitteln von Schwellenwerten. Da die jeweiligen Situationen sehr unterschiedlich 

sein können, ist es erforderlich, auf Grundlage Ihrer Netzwerkinfrastruktur zu ermitteln, 

welcher Leistungsgrad für einen Leistungsindikator auf eine Entwicklung in Richtung Serviceunterbrechung 

hinweist. Verfolgen Sie bei der Festlegung der Schwellenwerte einen konservativen Ansatz. 

(Verwenden Sie die von Microsoft empfohlenen oder sogar niedrigere Werte.) Auf diese Weise werden 

zunächst sehr viele Warnungen erzeugt. Wenn Sie im Laufe der Zeit mehr Daten über einen Indikator 

gesammelt haben, können Sie den Schwellenwert nach oben setzen, um die Anzahl an Warnungen 

zu verringern. Dieses Verfahren kann einige Monate dauern, ist schließlich jedoch genau auf 

Ihre Implementierung von Active Directory abgestimmt.


Es ist unerlässlich, im Voraus zu planen, welche Maßnahmen als Reaktion auf eine Warnung zu 

ergreifen sind. Stellen Sie sicher, dass Sie während der Festlegung Ihrer Indikatoren, Baselines und 

Schwellenwerte festlegen, welche Abhilfemaßnahme ergriffen wird, um den Indikator in seine normalen 

Grenzen zurückzubringen. Diese Maßnahmen können die Korrektur einer Fehlerbedingung (wie 

z.B. das erneute Onlineschalten eines Domänencontrollers) oder die Übertragung einer Betriebsmasterrolle 

umfassen. Wenn Ihr System die Höchstkapazität erreicht hat, ist zum Beheben der Bedingung 

eventuell eine Erweiterung des Festplatten- oder Arbeitsspeichers erforderlich. Durch andere Warnungen 

werden Sie aufgefordert, eine Active Directory-Wartung durchzuführen, beispielsweise durch 

die Defragmentierung Ihrer Active Directory-Datenbankdatei. Solche Situationen werden in diesem 

Kapitel im Abschnitt „Offlinedefragmentierung der Active Directory-Datenbank“ erläutert. 

Leistungsindikatoren und Schwellenwerte 

In den folgenden Tabellen werden die wichtigsten Leistungsindikatoren und Schlüsselwerte aufgeführt, 

die für die Überwachung und Protokollierung der Active Directory-Leistung hilfreich sind. Da 

jede Unternehmensumgebung eigene Besonderheiten aufweist, sind diese Werte nicht immer allgemein 

anwendbar. Diese Schwellenwerte sollten als Startpunkt betrachtet werden, die im Rahmen Ihrer 

Anforderungen für Ihre Umgebung weiter angepasst werden müssen. 

Active Directory-Leistung Anhand der in Tabelle 14.1 aufgeführten Leistungsindikatoren werden die 

wichtigsten Active Directory-Funktionen und -Dienste überwacht. Sofern nicht anderweitig angegeben, 

werden Schwellenwerte durch eine Baselineüberwachung ermittelt. Diese Indikatoren können für 

die Bereitstellung von Echtzeitdaten zum Systemmonitor hinzugefügt werden, oder Sie können eine 

Leistungsindikatorsammlung oder eine Leistungsindikatorwarnung zu einem Sammlungssatz hinzufügen, 

um eine Active Directory-Leistungsprotokollierung und Warnungsfunktionen zu ermöglichen. 

Tabelle 14.1 

Wichtige Active Directory-Funktionen und -Dienste 

Objekt Leistungsindikator Intervall Bedeutung des Leistungsindikators 

Verzeichnisdienste/NTDS DS-Suchunteroperationen/s 

Alle 15 Minuten Unterstruktursuchanforderungen sind besonders 

systemressourcenintensiv. Jeder bedeutende Anstieg 

kann auf Leistungsprobleme des Domänencontrollers 

hinweisen. Überprüfen Sie, ob 

Anwendungen diesen Domänencontroller fälschlicherweise 

adressieren. 

Prozess Prozessorzeit (%) 

(Instanz=lsass) 

Jede 

Minute 

Durch diesen Indikator wird die vom Active Directory-Dienst 

genutzte CPU-Zeit in Prozent angegeben. 

Verzeichnisdienste/NTDS LDAP-Suchzugriffe/s Alle 15 Minuten Dieser Indikator ist gut geeignet, um die Gesamtnutzung 

eines Domänencontrollers anzugeben. 

Im Idealfall ist der Wert für diesen Indikator für alle 

Domänencontroller nahezu gleich. Ein Anstieg 

dieses Indikatorwerts kann darauf hinweisen, 

dass eine neue Anwendung diesen Domänencontroller 

adressiert oder dass diesem Netzwerk 

mehrere Clients hinzugefügt wurden.


Tabelle 14.1 

Wichtige Active Directory-Funktionen und -Dienste (Fortsetzung) 

Objekt Leistungsindikator Intervall Bedeutung des Leistungsindikators 

Verzeichnisdienste/NTDS LDAP-Clientsitzungen Alle 5 Minuten Dieser Indikator gibt die Anzahl an Clients an, die 

derzeit mit dem Domänencontroller verbunden 

sind. Ein erheblicher Anstieg kann darauf hinweisen, 

dass andere Computer zu diesem Domänencontroller 

wechseln. Wenn Sie für diesen Indikator 

eine Hochrechnung erstellen, können Sie nützliche 

Informationen dazu erhalten, zu welcher Tageszeit 

Mitarbeiter Verbindungen herstellen oder 

zur Höchstzahl an täglich verbundenen Clients. 

Prozess 

Prozess 

Prozess 

Private Bytes 


Handleanzahl 


Virtuelle Bytes 


Alle 15 Minuten 



Dieser Indikator ist zum Hochrechnen des 

Speicherbedarfs von Domänencontrollern geeignet. 

Eine stetige Zunahme des Indikators weist 

entweder auf einen gestiegenen Bedarf an Arbeitsstationen, 

mehr Anwendungsfehlfunktionen 

(nicht schließende Handles) oder eine gestiegene 

Anzahl an Arbeitsstationen hin, die diesen Domänencontroller 

adressieren. Weichen die Werte für 

diesen Indikator wesentlich vom gewöhnlichen 

Wert anderer Peerdomänencontroller ab, sollten 

Sie die Ursache für diesen Bedarf ermitteln. 

Diese Trendstatistik ist hilfreich bei der Ermittlung, 

ob Anwendungen sich erwartungsgemäß 

verhalten und Handles nicht ordnungsgemäß geschlossen 

werden. Der Wert dieses Indikators 

steigt durch das Hinzufügen von Clientarbeitsstationen 

linear an. 

Dieser Indikator kann verwendet werden, um zu 

ermitteln, ob die Kapazitäten des virtuellen Speicheradressbereichs 

von Active Directory gering 

sind, da dies auf ein Speicherleck hinweisen 

kann. Überprüfen Sie, ob Sie das aktuelle Service 

Pack ausführen, und planen Sie einen Neustart 

außerhalb der Geschäftszeiten, um einen 

Systemausfall zu verhindern. Mithilfe dieses Indikators 

können Sie ermitteln, ob weniger als 2 GB 

an virtuellem Speicher verfügbar sind. 

Replikationsleistungsindikatoren Die in Tabelle 14.2 aufgeführten Leistungsindikatoren werden für 

die Überwachung der Menge an Replikationsdaten verwendet. Schwellenwerte werden durch die von 

Ihnen zuvor festgelegten Baselines bestimmt, sofern nicht anderweitig angegeben.


Tabelle 14.2 

Replikationsleistungsindikatoren 

Objekt Leistungsindikator Empfohlenes 

Intervall 

Verzeichnisdienste/NTDS Eingehende komprimierte 


DRA-Bytes 

(zwischen Standorten, 

vor Komprimierung)/ 

Sek. 

Verzeichnisdienste/NTDS 



Ausgehende komprimierte 

DRA-Bytes 

(zwischen Standorten, 

nach Komprimierung)/ 

s. 

Ausgehende nicht 

komprimierte DRA- 

Bytes 

Ausgehende DRA- 

Bytes insgesamt/s 




Bedeutung des Leistungsindikators 

Gibt die Menge an Replikationsdaten an, die an 

diesen Standort gesendet werden. Eine wesentliche 

Änderung dieses Indikators weist auf eine 

Änderung der Replikationstopologie hin oder dass 

dem Active Directory Daten in erheblichem Umfang 

hinzugefügt wurden bzw. dass sich Daten in 

erheblichem Umfang geändert haben. 

Gibt die Menge an Replikationsdaten an, die von 

diesem Standort gesendet werden. Eine wesentliche 

Änderung dieses Indikators weist auf eine 

Änderung der Replikationstopologie hin oder darauf, 

dass Active Directory Daten in erheblichem 

Umfang hinzugefügt wurden bzw. dass sich Daten 

in erheblichem Umfang geändert haben. 


diesem Domänencontroller an Ziele innerhalb des 

Standorts gesendet werden. 


diesem Domänencontroller gesendet werden. 

Eine wesentliche Änderung dieses Indikators 

weist auf eine Änderung der Replikationstopologie 

hin oder darauf, dass Active Directory Daten in 

erheblichem Umfang hinzugefügt wurden bzw. 

dass sich Daten in erheblichem Umfang geändert 

haben. Die Überwachung dieses Leistungsindikators 

ist besonders wichtig. 

Leistung des Sicherheitssubsystems Mithilfe der in Tabelle 14.3 aufgeführten Indikatoren werden die 

wichtigsten Sicherheitsvolumes überwacht. Sofern nicht anderweitig angegeben, werden Schwellenwerte 

durch Baselineüberwachung ermittelt. 

Tabelle 14.3 

Wichtige Sicherheitsvolumes 


Intervall 

Sicherheitssystemweite 

Statistiken 


Statistiken 

NTLM- 


KDC-AS- 

Anforderungen 




Gibt die Anzahl an Clients an, die pro Sekunde 

mithilfe von NTLM und nicht mit Kerberos (Clients 

vor Windows 2000 oder Authentifizierungen innerhalb 

der Gesamtstruktur) eine Authentifizierung 

am Domänencontroller durchführen. 

Gibt die Anzahl an Sitzungstickets an, die pro 

Sekunde durch das Schlüsselverteilungscenter 

(Key Distribution Center, KDC) ausgegeben werden. 

Dieser Indikator ist besonders geeignet, um 

die Auswirkungen einer Änderung der Ticketgültigkeitsdauer 

zu ermitteln.


Tabelle 14.3 

Wichtige Sicherheitsvolumes (Fortsetzung) 


Intervall 


Statistiken 


Statistiken 

Kerberos-Authentifizierungen 

KDC-TGS- 

Anforderungen 




Gibt die Authentifizierungslast für das KDC an. 

Dieser Indikator ist besonders geeignet, um Entwicklungen 

vorherzusagen. 

Gibt die Anzahl der vom KDC ausgegebenen 

ticketerteilenden Tickets (Ticket Granting Tickets, 

TGT) an. Dieser Indikator ist besonders geeignet, 

um die Auswirkungen einer Änderung der Ticketgültigkeitsdauer 

zu ermitteln. 

Leistung des Betriebssystems Anhand der in Tabelle 14.4 aufgeführten Leistungsindikatoren werden 

die wichtigsten Betriebssystemindikatoren überwacht, die direkte Auswirkung auf die Active Directory-Leistung 

haben. 

Tabelle 14.4 

Wichtige Betriebssystemindikatoren 

Objekt Leistungsindikator Intervall Schwellenwert Bedeutung der Überschreitung des 

Schwellenwerts 

Arbeitsspeicher 

Physikalischer 

Datenträger 

Seitenfehler/s Alle 5 Minuten 700/Sekunde Eine hohe Anzahl an Seitenfehlern weist 

auf unzureichenden physischen Arbeitsspeicher 

hin. 

Aktuelle Warteschlangenlänge 

Prozessor DPC-Zeit (%) 

(Instanz=_Gesamt) 

System 

Arbeitsspeicher 

Prozessor-Warteschlangenlänge 

Jede Minute Durchschnittlich 2 

über 3 Intervalle 

Überwachung von Volumes, die die Datei 

Ntds.dit und Protokolldateien enthalten. 

Durch diesen Indikator wird angegeben, 

dass ein Rückstand der E/A-Anforderungen 

der Festplatte besteht. In diesem 

Fall ist eine Erhöhung des Festplatten- und 

Controllerdurchsatzes empfehlenswert. 

Alle 15 Minuten 10 Weist auf die Arbeit hin, die aufgrund des 

überlasteten Domänencontrollers zurückgestellt 

wurde. Eine Überschreitung des 

Schwellenwerts weist auf eine mögliche 

Prozessorüberlastung hin. 

Jede Minute Durchschnittlich 6 

über 5 Intervalle 

Die CPU ist zum Verarbeiten der Anforderungen 

bei deren Auftreten nicht schnell 

genug. Wenn die Replikationstopologie 

keine Fehler aufweist und die Bedingung 

nicht durch einen Ausfall eines anderen 

Domänencontrollers verursacht wurde, 

sollten Sie ein Upgrade der CPU in Betracht 

ziehen. 

Verfügbare MB Alle 15 Minuten 4 MB Gibt an, dass für das System kein Arbeitsspeicher 

mehr verfügbar ist. Es ist ein 

Dienstausfall zu erwarten.


Tabelle 14.4 

Wichtige Betriebssystemindikatoren (Fortsetzung) 

Objekt Leistungsindikator Intervall Schwellenwert Bedeutung der Überschreitung des 

Schwellenwerts 

Prozessor Prozessorzeit (%) 

(Instanz=_Gesamt) 

Jede Minute 

Durchschnittlich 

85 % über 

3 Intervalle 

Überwachen von Active Directory mit der Ereignisanzeige 

Weist auf eine Überlastung der CPU hin. 

Ermitteln Sie, ob die CPU-Last durch 

Active Directory verursacht wird, indem Sie 

das Prozessobjekt, den Indikator Prozessorzeit 

(%) und die lsass-Instanz überprüfen. 

System Kontextwechsel/s Alle 15 Minuten 70,000 Weist auf besonders viele Transaktionen 

hin. Unter Umständen werden zu viele Anwendungen 

oder Dienste ausgeführt, oder 

deren Systembelastung ist zu hoch. Es 

empfiehlt sich, einen Teil dieser Anforderung 

auszulagern. 

System Systembetriebszeit Alle 15 Minuten Wesentlicher Indikator für die Messung der 

Domänencontrollerzuverlässigkeit. 

Neben der Überwachung von Active Directory mithilfe der Zuverlässigkeits- und Leistungsüberwachung 

sollten Sie den Inhalt der Ereignisprotokolle ebenfalls mithilfe des Verwaltungsprogramms 

Ereignisanzeige überprüfen. Standardmäßig werden in der Ereignisanzeige die folgenden fünf Protokolle 

angezeigt: 

• Anwendung Enthält Ereignisse, die von Anwendungen oder Programmen protokolliert wurden. 

• Sicherheit Enthält Ereignisse wie beispielsweise gültige und ungültige Anmeldeversuche sowie 

Ereignisse, die mit einer Ressourcennutzung wie z.B. dem Erstellen, Öffnen oder Löschen von 

Dateien oder anderen Objekten verbunden sind. 

• Einrichtung Enthält Ereignisse, die während der Einrichtung von Betriebssystem und Anwendungen 

protokolliert wurden. 

• System Enthält Ereignisse, die von Windows-Systemkomponenten protokolliert wurden. 

• Weitergeleitete Ereignisse Wird zum Speichern von Ereignissen verwendet, die von anderen 

Remotecomputern gesammelt wurden. Um Ereignisse von Remotecomputern zu sammeln, ist die 

Konfiguration eines Abonnements erforderlich. 

Zusätzlich zu Servern, die unter Windows Server 2008 ausgeführt werden und als Domänencontroller 

konfiguriert wurden, werden die folgenden Ereignisprotokolle unterhalb des Knotens Anwendungsund 

Dienstprotokolle der Ereignisanzeige angezeigt: 

• Verzeichnisdienst Enthält Ereignisse, die von Active Directory protokolliert wurden. 

• DFS-Replikation Enthält Ereignisse, die vom verteilten Dateisystem protokolliert wurden. In diesem 

Protokoll werden mit der Replikation des Ordners SYSVOL verbundene Informationen aufgeführt.


Fungiert der Windows Server 2008-Domänencontroller ebenfalls als DNS-Server, wird zusätzlich das 

folgende Protokoll angezeigt: 

• DNS-Server Enthält Ereignisse, die durch den DNS-Serverdienst protokolliert wurden. 

Klicken Sie zum Anzeigen der Protokolle im Ordner Verwaltung auf Ereignisanzeige. Wählen Sie das 

Ereignisprotokoll für den Dienst, den Sie überwachen möchten. Im linken Fensterbereich von 

Abbildung 14.6 werden alle Ereignisprotokolle für einen Domänencontroller aufgeführt, der unter 

Windows Server 2008 ausgeführt wird und als DNS-Server fungiert. 


Die Ereignisanzeige mit Ereignisprotokollen 

Überprüfen Sie im Ereignisprotokoll die Ereignistypen Fehler und Warnung. Um Details zu einem 

Ereignis im Protokoll anzuzeigen, doppelklicken Sie auf das Ereignis. In Abbildung 14.7 werden die 

Details zu einem Warnungsereignis (Ereigniskennung 2886) aus dem Verzeichnisdienstprotokoll dargestellt.



Die Seite Ereigniseigenschaften eines Ereignisprotokolleintrags 

Zu überwachende Elemente 

Für die Überwachung des gesamten Systemstatus von Active Directory sollten Sie dienstbezogene 

und serverbezogene Leistungsindikatoren überwachen. Sie müssen sicherstellen, dass Active Directory 

und die Domänencontroller, auf denen Active Directory ausgeführt wird, die optimale Leistung 

erbringen. Beziehen Sie beim Entwurf Ihrer Überwachungslösung die Überwachung der folgenden 

Leistungsbereiche mit ein: 

• Active Directory-Dienst Diese Leistungsindikatoren werden mithilfe der Verzeichnisdienstindikatoren 

überwacht und für die Ereignisverfolgung in der Zuverlässigkeits- und Leistungsüberwachung 

verwendet. 

• Active Directory-Replikation Die Replikationsleistung ist grundlegend, um die Aufrechterhaltung 

der Datenintegrität innerhalb der Domäne sicherzustellen. 

• Active Directory-Datenbankspeicher Die Volumes, auf denen die Active Directory-Datenbankdatei 

Ntds.dit sowie die Protokolldateien gespeichert sind, müssen über ausreichend Speicherplatz verfügen, 

um ein Wachstum im normalen Rahmen sowie den Betrieb zu ermöglichen. 

• DNS-Leistung und Serverstatus Da Active Directory für die Dienstermittlung auf DNS zurückgreift, 

müssen der DNS-Server und -Dienst für Active Directory innerhalb normaler Grenzen ausgeführt 

werden, um dessen Servicelevelanforderungen zu entsprechen. 

• Dateireplikationsdienst (File Replication Service, FRS) und die DFS-Replikation (Distributed File System 

Replication, DFSR) Der FRS muss im Rahmen normaler Grenzen ausgeführt werden, um sicherzustellen, 

dass das freigegebene Systemvolume (SYSVOL) innerhalb der Domäne repliziert wird. 

Wenn Sie die Funktionsebene Windows Server 2008 ausführen, können Sie DFSR für die Replikation 

des Ordners SYSVOL verwenden. Dieser Vorgang muss ebenfalls überwacht werden, um eine 

ordnungsgemäße Leistung sicherzustellen.


• Systemstatus des Domänencontrollers Die Überwachung dieses Bereichs sollte den gesamten Serverstatus 

einschließlich Speicherindikatoren, Prozessorauslastung und Auslagerung umfassen. 

Darüber hinaus müssen Sie sicherstellen, dass die Uhrzeit- und Zeitzoneneinstellungen zwischen 

allen Servern ordnungsgemäß synchronisiert sind, da dies für die Replikation und ordnungsgemäße 

Authentifizierung besonders wichtig ist. 

• Gesamtstrukturstatus Dieser Bereich sollte überwacht werden, um Vertrauensstellungen sowie 

die Standortverfügbarkeit zu überprüfen. 

• Betriebsmaster- und globale Katalogrollen Überwachen Sie jede Betriebsmasterrolle, um den Serverstatus 

zu gewährleisten. Überwachen Sie darüber hinaus die globale Katalogverfügbarkeit, um 

eine Benutzeranmeldung sowie die Auflistung universeller Gruppenmitgliedschaften zu ermöglichen. 

Direkt von der Quelle: Überwachen von Active Directory, Teil 2 

Die Überwachung von Active Directory ist ein sehr vielschichtiges Thema. Wie bereits zuvor 

erläutert, ist die Überwachung von Active Directory auf ganzheitlicher Basis von zentraler Bedeutung. 

Wenngleich in diesem Kapitel hauptsächlich auf die von Active Directory bereitgestellten 

Informationen eingegangen wird, gibt es einige Elemente in Windows, die zwar nicht in direktem 

Zusammenhang mit Active Directory stehen, die aber dennoch überwacht werden sollten. Die 

Überwachung dieser zusätzlichen Elemente ermöglicht es Ihnen, den allgemeinen Status des Active 

Directory-Ökosystems nachzuverfolgen. Beispielsweise sollten Sie die Uhrzeitsynchronisierung 

überwachen, um Zeitunterschiede von mehr als 5 Minuten zwischen Domänencontrollern zu verhindern 

(Zeitunterschiede von mehr als 5 Minuten können dazu führen, dass das Kerberos-Ticket 

ungültig wird und dass Domänencontroller und Benutzer keine Authentifizierung mehr durchführen 

können). Des Weiteren sollten Sie eine Überwachung von Diensten wie z.B. NTFRS, DFSR 

und KDC-W32Time erwägen, die für Active Directory von grundlegender Bedeutung sind. Sämtliche 

dieser Dienste bieten entweder Unterstützung für Active Directory oder sind von Active 

Directory abhängig, und sie sind im Gesamtstatus des Active Directory-Ökosystems von zentraler 

Bedeutung. Darüber hinaus ist es ebenfalls ratsam, allgemeine Aspekte wie beispielsweise die 

Speicherkapazität der Systemfestplatte und die Active Directory-Datenbankgröße nachzuverfolgen. 

Ein Aspekt, der oftmals übersehen wird, dessen Überwachung jedoch unter Umständen nützlich 

sein kann – vor allem in besonders großen Active Directory-Infrastrukturen –, ist die KCC-CPU- 

Auslastung. Die Konsistenzüberprüfung (Knowledge Consistency Checker, KCC) ist verantwortlich 

für die Überprüfung und den Aufbau der Active Directory-Topologie, indem die erforderlichen 

Verbindungsobjekte erstellt werden. Wenngleich die KCC-Leistung seit Windows 2000 

erheblich verbessert wurde, kann die Überwachung der CPU-Auslastung Ihrer KCC auf Ihren 

Domänencontrollern von Interesse sein – dies gilt vor allem für die Domänencontroller, die sich an 

den Hubstandorten Ihrer Active Directory-Infrastruktur befinden. 

Sie können die KCC-Aktivität auf einfache Weise ermitteln, indem Sie für die KCC-Diagnoseebene 

den Wert 3 festlegen. Legen Sie hierfür für den Registrierungsschlüssel 1 Knowledge Consistency 

Checker den Wert 3 fest. Der Registrierungsschlüssel befindet sich in der Registrierungsstruktur 

unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Nachdem Sie den 

Wert auf 3 gesetzt haben, erstellt die KCC bei jeder Ausführung Ereignisprotokolleinträge im Verzeichnis 

für das Ereignisprotokoll des Dienstes.


Die Ereignisse 1009 und 1013 mit dem Namen NTDS-KCC als Quelle geben die KCC-Start- und 

Stoppzeit an. Wenn Sie gleichzeitig die CPU-Auslastung überwachen, können Sie überprüfen, welche 

Auswirkungen die KCC während ihrer Ausführung auf die CPU hat. Anhand dieser Informationen 

können Sie beispielsweise die Lastaufteilung zwischen den Servern für die Topologieberechnung 

und den Servern zur Verarbeitung von Authentifizierungsanforderungen ermitteln. 

Zusammengefasst gesagt, sollten Sie bei der Überwachung von Active Directory das Gesamtbild 

im Auge behalten. Sie ersparen sich böse Überraschungen, wenn Sie Ihr Active Directory-Ökosystem 

als Ganzes betrachten, statt mit einzelnen Softwarekomponenten zu arbeiten. 

Alain Lissoir 



Überwachen der Replikation 

Wenn Sie in Ihrem Unternehmen mehrere Domänencontroller ausführen, ist eine der wichtigsten 

Komponenten für die Überwachung die Active Directory-Replikation. Die Replikation zwischen 

Domänencontrollern wird für gewöhnlich mit Verwaltungsprogrammen wie beispielsweise Repadmin.exe, 

Dcdiag.exe und dem Verzeichnisdienstprotokoll (zuvor im Rahmen der Ereignisanzeige 

beschrieben) überwacht. 

Bei Repadmin handelt es sich um ein Befehlszeilenprogramm, das über Fehler in einer Replikationsverknüpfung 

zwischen zwei Replikationspartnern berichtet. Über den folgenden Befehl werden die 

Replikationspartner und alle Replikationsverknüpfungsfehler für den DC1-Domänencontroller in der 

Domäne Contoso.com aufgeführt: 

repadmin /showrepl dc1.contoso.com 

Das Befehlszeilenprogramm Dcdiag kann die DNS-Registrierung eines Domänencontrollers prüfen 

und feststellen, ob die Sicherheitskennungen (Security Identifiers, SIDs) im NC-Kopf (Naming Context, 

Namenskontext) über geeignete Replikationsberechtigungen verfügen. Außerdem kann es zur 

Analyse des Domänencontrollerstatus in einer Unternehmensgesamtstruktur verwendet werden. Um 

eine vollständige Liste der Dcdiag-Optionen zu erhalten, geben Sie die Zeichenfolge dcdiag /? ein. 

Mit dem folgenden Befehl wird auf Replikationsfehler zwischen Domänencontrollern geprüft: 

dcdiag /test:replications 

Das Verzeichnisdienstprotokoll schließlich berichtet über Replikationsfehler, die nach der Erstellung 

einer Replikationsverknüpfung aufgetreten sind. Sie sollten das Verzeichnisdienstprotokoll insbesondere 

auf Replikationsereignisse vom Typ Fehler oder Warnung prüfen. Im Folgenden werden zwei 

Beispiele für häufige Replikationsfehler und deren Anzeige im Verzeichnisdienstprotokoll dargestellt: 

• Ereignis-ID 1311 Die Replikationskonfigurationsinformationen im Verwaltungsprogramm Active 

Directory-Standorte und -Dienste stellen die physische Netzwerktopologie nicht präzise dar. Dieser 

Fehler weist darauf hin, dass mindestens ein Domänencontroller oder Bridgeheadserver offline 

ist, oder dass die Bridgeheadserver nicht die erforderlichen NCs hosten. 

• Ereignis-ID 1265 (Zugriff verweigert) Dieser Fehler kann auftreten, wenn die Authentifizierung des 

Replikationspartners durch den Domänencontroller beim Erstellen der Replikationsverknüpfung 

oder bei dem Versuch, eine Replikation über eine bestehende Verknüpfung durchzuführen, fehlschlägt.


Dieser Fehler tritt in der Regel dann auf, wenn die Verbindung des Domänencontrollers mit dem 

übrigen Netzwerk für lange Zeit unterbrochen wurde und das Kennwort des Computerkontos des 

Domänencontrollers nicht mit dem Kennwort des Computerkontos übereinstimmt, das im Verzeichnis 

des Replikationspartners gespeichert ist. 

Direkt von der Quelle: Überwachen der Active Directory-Replikation 

Eine Active Directory-Replikation kann auf verschiedene Weise überwacht werden. Wie in diesem 

Abschnitt beschrieben, können Sie eine Validierung der Konfiguration vornehmen, um sicherzustellen, 

dass Active Directory alle erforderlichen Bedingungen für eine erfolgreiche Replikation 

erfüllt. Wie bereits erwähnt, können Sie dies mithilfe von Tools wie Dcdiag erreichen. Hierbei handelt 

es sich eher um eine proaktive Verifizierung, bei der eine Überwachung vor dem Auftreten von 

Problemen durchgeführt wird. Sie können jedoch auch eine „problembasierte“ Überwachung der 

Active Directory-Replikation durchführen, indem Sie alle während der Replikation auftretenden 

Fehler überprüfen. Diese problembasierte Überwachung können Sie durchführen, indem Sie die 

im Ereignisprotokoll aufgeführten Ereignisse oder bestimmte Replikationsfehler mithilfe von 

REPADMIN prüfen. 

Eine weitere Möglichkeit zur Überprüfung der Active Directory-Replikation besteht darin, verschiedene 

gemeinsam genutzte Einstellungen eines Active Directory-Domänencontrollers zu untersuchen, 

wie beispielsweise die FSMO-Rollen. Im Idealfall sollten die für eine bestimmte Domäne 

in einer bestimmten Gesamtstruktur gemeldeten FSMO-Rollen für alle Domänencontroller innerhalb 

dieser Domäne in der Gesamtstruktur gleich sein. Wenn Sie diese Informationen für jeden 

Domänencontroller sammeln und an einer zentralen Stelle ausweisen (d.h. die gesammelten Ergebnisse 

in einer Freigabe ausgeben), kann die von allen Domänencontrollern gemeldete FSMO-Rolle 

einfach verglichen werden. Jede gemeldete Abweichung für die FSMO-Rolle weist auf einen Replikationsfehler 

für den Domänencontroller hin, der andere Ergebnisse gemeldet hat. 

Zu guter Letzt kann die Active Directory-Replikation auch basierend auf Änderungen überwacht 

werden. Bei diesem Ansatz wird ein vorgegebenes dediziertes AD-Objekt (Active Directory) zur 

Überwachung der Replikation geändert. Sie können z.B. ein ADSI-basiertes Skript schreiben, das 

Änderungen an einem AD-Objekt auf einem ausgewählten Domänencontroller vornimmt. (Dieses 

Skript kann im Rahmen der Aufgabenplanung regelmäßig ausgeführt werden.) Die Änderung kann 

beispielsweise einfach in einem Schreibvorgang von Datum und Uhrzeit in ein Zeichenfolgenattribut 

wie der Beschreibung eines Benutzerobjekts bestehen. Da diese Art von Änderung von Active 

Directory automatisch repliziert wird, sollten diese Informationen zu einem gewissen Zeitpunkt auf 

allen anderen Active Directory-Domänencontrollern aktualisiert dargestellt werden. Gleichzeitig können 

Sie auf allen anderen Domänencontrollern regelmäßig ein zusätzliches Skript ausführen, das 

dieses Objekt liest und das Datum und die Uhrzeit des Attributs description mit dem Wert des Attributs 

whenChanged vergleicht. 

Anhand dieses Skripts können zwei Dinge ermittelt werden: Zum einen können Sie feststellen, ob 

die letzte Änderung erfolgreich repliziert wurde (Attribut description mit einem aktualisierten Wert 

für Datum/Uhrzeit). Zum anderen können Sie die Dauer der Replikationsänderung feststellen, 

indem Sie den Zeitunterschied zwischen dem Attribut description mit dem ursprünglichen Wert für 

Datum/Uhrzeit und dem Wert für Datum/Uhrzeit des Attributs whenChanged ermitteln.


Auf diese Weise können Sie die sogenannte Replikationsverzögerung des Verzeichnisses ermitteln. 

Neben der Bestätigung, dass die Replikationen funktioniert, können Sie anhand der Replikationsverzögerung 

außerdem feststellen, ob Ihr Entwurf und Ihre Infrastruktur von Active Directory im 

Hinblick auf die Schnelligkeit von Replikationsänderungen Ihren Erwartungen entspricht, denn 

dieser Aspekt wird beim Active Directory-Entwurf in der Regel als Anforderung festgelegt. Diese 

Methode ist daher geeignet, Ihre Entwurfsentscheidungen zu bewerten und ggf. Maßnahmen zu 

ergreifen, um Ihrer Replikations-SLA zu entsprechen. 

Für diese Überwachung ist natürlich die Erstellung eines Skripts erforderlich. Auf meiner Website 

http://www.lissware.net finden Sie im Bereich der Whitepaper einige ADSI-Skript-basierte Beispiele, 

die Sie als Vorlage für Ihre eigenen Skripts verwenden können. 

Darüber hinaus implementiert das Microsoft Active Directory Management Pack für Microsoft 

Operations Manager (MOM) 2005 und Operations Manager 2007 genau diese Logik und nutzt 

MOM zum Konsolidieren und Vergleichen der Ergebnisse, die von allen Domänencontrollern in 

Ihrer Gesamtstruktur zur Ermittlung der Replikationsverzögerung gesammelt werden. 

Alain Lissoir 



Verwalten der Active Directory-Datenbank 

Die Wartung der Active Directory-Datenbank ist ein besonders wichtiger Aspekt der Active Directory-Verwaltung. 

Unter normalen Umständen ist eine direkte Verwaltung der Active Directory-Datenbank 

eher unüblich, da der Status der Datenbank regelmäßig und automatisch überprüft wird. Diese 

automatischen Verfahren umfassen eine Onlinedefragmentierung der Active Directory-Datenbank 

sowie ein Verfahren zum Sammeln veralteter Objekte, um gelöschte Objekte zu entfernen. Für den 

Fall, dass eine direkte Verwaltung der Active Directory-Datenbank erforderlich ist, stellt Windows 

Server 2008 das Tool Ntdsutil bereit. 

Sammeln veralteter Objekte 

Eines der automatisierten Verfahren im Rahmen der Active Directory-Datenbankwartung ist die 

Sammlung veralteter Objekte. Bei der Sammlung veralteter Objekte handelt es sich um ein Verfahren, 

das im 12-Stunden-Takt für jeden Domänencontroller durchgeführt wird. Während des Sammelns 

veralteter Objekte wird freier Speicherplatz innerhalb der Active Directory-Datenbank wieder 

freigegeben. 

Das Verfahren wird gestartet, indem zunächst Tombstones aus der Datenbank entfernt werden. Als 

Tombstones werden die Artefakte von Objekten bezeichnet, die aus Active Directory gelöscht wurden. 

Beim Löschen eines Objekts, z.B. einem Benutzerkonto, wird dieses nicht sofort gelöscht. Vielmehr 

wird das Attribut isDeleted des Objekts auf den Wert true gesetzt, d.h. das Objekt wird als 

Tombstone markiert, und ein Großteil der Attribute für dieses Objekt werden aus dem Objekt entfernt. 

Es werden nur wenige Attribute beibehalten, die für die Ermittlung des Objekts benötigt werden, 

wie z.B. die GUID (Global Unique Identifier, Global eindeutige Kennung), die SID (Security ID, 

Sicherheitskennung), die USN (Update Sequence Number) sowie der DN (Distinguished Name, definierter 

Name). Dieser Tombstone wird dann auf alle weiteren Domänencontroller der Domäne repliziert. 

Jeder Domänencontroller behält bis zum Ablauf der Tombstone-Ablaufzeit eine Kopie des ver-

Verwalten der Active Directory-Datenbank 567 

alteten Objekts. Standardmäßig sind für die Tombstone-Ablaufzeit 180 Tage festgelegt. Bei der 

nächsten Sammlung veralteter Objekte nach der Tombstone-Ablaufzeit wird das Objekt aus der 

Datenbank gelöscht. 

Nach dem Löschen der Tombstones werden durch das Verfahren zum Sammeln veralteter Objekte alle 

unnötigen Transaktionsprotokolldateien gelöscht. Bei jeder an der Active Directory-Datenbank vorgenommenen 

Änderung wird diese zuerst in ein Transaktionsprotokoll geschrieben und dann in die 

Datenbank übernommen. Durch das Verfahren zum Sammeln veralteter Objekte werden alle Transaktionsprotokolle 

entfernt, in denen keine noch nicht übernommenen Transaktionen enthalten sind. 

Wie bereits erwähnt, wird das Verfahren zum Sammeln veralteter Objekte im 12-Stunden-Takt für 

jeden Domänencontroller durchgeführt. Dieses Intervall können Sie anpassen, indem Sie das Attribut 

garbageCollPeriod ändern. Sie können zum Ändern dieser Einstellung das Tool Adsiedit.msc verwenden. 

Öffnen Sie über das Menü Verwaltung den ADSI-Editor, und stellen Sie dann eine Verbindung 

mit dem Configuration-Namenskontext her. Erweitern Sie anschließend CN=Configuration, CN=Services 

und CN=Windows NT, und wählen Sie CN=Directory Service. Klicken Sie mit der rechten 

Maustaste auf CN=Directory Service, ermitteln Sie das Attribut garbageCollPeriod, und konfigurieren 

Sie den Wert entsprechend Ihren Anforderungen. In den meisten Fällen ist eine Änderung dieser 

Einstellung nicht erforderlich. In Abbildung 14.8 wird dieses Attribut im ADSI-Editor dargestellt. 


Das Attribut garbageCollPeriod im ADSI-Editor 

Onlinedefragmentierung 

Als letzter Schritt des Verfahrens zum Sammeln veralteter Objekte wird eine Onlinedefragmentierung 

der Active Directory-Datenbank durchgeführt. Durch diese Onlinedefragmentierung wird Speicherplatz 

innerhalb der Datenbank freigegeben, und die Speicherplatzbelegung von Active Directory- 

Objekten innerhalb der Datenbank wird neu angeordnet, um die Effizienz der Datenbank zu verbessern. 

Die Onlinedefragmentierung ist aufgrund des Verfahrens erforderlich, das von Active Directory 

beim Bearbeiten von Objekten in der Datenbank verwendet wird.


Während des normalen Betriebs ist das Datenbanksystem für Active Directory dahingehend optimiert, 

dass Änderungen an der Active Directory-Datenbank schnellstmöglich vorgenommen werden 

können. Wird ein Objekt aus Active Directory gelöscht, wird die Datenbankseite, auf der das Objekt 

gespeichert ist, in den Computerspeicher geladen und das Objekt von der Seite gelöscht. Beim Hinzufügen 

von Objekten zu Active Directory werden diese auf Datenbankseiten geschrieben, ohne dabei 

eine Speicheroptimierung zum späteren Abrufen dieser Informationen zu berücksichtigen. Wenn auf 

diese Weise über mehrere Stunden hinweg schnellstmöglich Änderungen an der Datenbank vorgenommen 

wurden, ist der Datenbankspeicher unter Umständen nicht optimiert. Die Datenbank kann 

beispielsweise leere Seiten enthalten, von denen Objekte gelöscht wurden, es können zahlreiche Seiten 

vorhanden sein, von denen Objekte gelöscht wurden, oder es sind Active Directory-Objekte vorhanden, 

die logisch gemeinsam gespeichert werden sollten, sich aber auf mehreren Seiten innerhalb 

der Datenbank befinden. 

Durch das Verfahren der Onlinedefragmentierung wird die Datenbank bereinigt und in einen optimierten 

Zustand überführt. Wurden einige der Einträge auf einer Datenbankseite gelöscht, können 

Einträge von anderen Seiten auf diese Seite verschoben werden, um das Speichern und Abrufen von 

Informationen zu optimieren. Objekte, die logisch gemeinsam gespeichert werden sollten, da sie 

gemeinsam angezeigt werden, werden auf die gleiche oder nebeneinanderliegende Datenbankseiten 

verschoben. Eine Beschränkung des Onlinedefragmentierungsverfahrens besteht darin, dass die Größe 

der Active Directory-Datenbank nicht verringert werden kann. Wenn Sie viele Objekte aus Active 

Directory gelöscht haben, ergeben sich durch das Verfahren zur Onlinedefragmentierung unter 

Umständen viele leere Seiten in der Datenbank, da Objekte innerhalb der Datenbank verschoben werden. 

Diese leeren Seiten können jedoch durch die Onlinedefragmentierung nicht aus der Datenbank 

entfernt werden. Um diese leeren Seiten zu entfernen, ist die Durchführung einer Offlinedefragmentierung 

erforderlich. 


Meldung im Verzeichnisdienstprotokoll zur Angabe einer erfolgreichen Onlinedefragmentierung


Die Onlinedefragmentierung wird als Bestandteil der Sammlung veralteter Objekte alle 12 Stunden 

durchgeführt. Nach Abschluss der Onlinedefragmentierung wird ein Ereignis in das Verzeichnisdienstprotokoll 

geschrieben, um anzugeben, dass die Defragmentierung erfolgreich abgeschlossen 

wurde. In Abbildung 14.9 wird ein Beispiel einer solchen Ereignisprotokollmeldung dargestellt. 

Offlinedefragmentierung der Active Directory-Datenbank 

Wie zuvor bereits erwähnt, kann durch eine Onlinedefragmentierung die Größe der Active Directory- 

Datenbank nicht verringert werden. Unter normalen Umständen stellt dies kein Problem dar, da die 

während der Onlinedefragmentierung bereinigten Datenbankseiten beim erneuten Hinzufügen von 

Objekten zu Active Directory wieder verwendet werden. In einigenFällen kann es jedoch erforderlich 

sein, die Gesamtgröße der Datenbank durch eine Offlinedefragmentierung zu verringern. Wenn Sie 

z.B. einen globalen Katalog von einem Domänencontroller entfernen, sollten Sie eine Offlinedefragmentierung 

der Datenbank durchführen, um den zum Speichern der GC-Informationen in der Datenbank 

verwendeten Bereich zu bereinigen. Das Durchführen einer Offlinedefragmentierung nach dem 

Entfernen eines globalen Katalogs ist vor allem in einer Umgebung mit mehreren Domänen besonders 

wichtig, da ein GC in solchen Umgebungen sehr groß werden kann. Eine Offlinedefragmentierung 

kann auch empfehlenswert sein, wenn eine große Anzahl an Objekten aus der Active Directory- 

Domäne entfernt wurde. 

Führen Sie für eine Offlinedefragmentierung die folgenden Schritte aus: 

1. Sichern Sie die Active Directory-Informationen auf dem Domänencontroller. Dieses Verfahren 

wird in Kapitel 15, „Active Directory-Notfallwiederherstellung“, beschrieben. 

2. Öffnen Sie für Windows Server 2008-Domänencontroller die Konsole Dienste, und halten Sie den 

Dienst Active Directory-Domänendienste und bei Aufforderung alle verknüpften Dienste an 

(oder geben Sie an der Eingabeaufforderung die Zeichenfolge net stop ntds ein). 

Hinweis Starten Sie bei Verwendung von Windows Server 2000/2003 den Domänencontroller neu. 

Drücken Sie beim Neustart des Servers die Taste F8, um den Bildschirm Erweiterte Startoptionen 

anzuzeigen, und wählen Sie anschließend Verzeichnisdienstwiederherstellung. Melden Sie sich nach 

dem Serverneustart mit dem lokalen Administratorkonto an. Verwenden Sie das Kennwort, das Sie beim 

Heraufstufen des Domänencontrollers als Kennwort für den Wiederherstellungsmodus für Verzeichnisdienste 

eingegeben haben. 

3. Öffnen Sie eine Eingabeaufforderung, und geben Sie den Befehl ntdsutil ein. 

4. Geben Sie an der Ntdsutil-Eingabeaufforderung die Zeichenfolge Activate Instance NTDS ein. 

5. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl files ein. 

6. Geben Sie an der File Maintenance-Eingabeaufforderung den Befehl info ein. Mithilfe dieser 

Option werden aktuelle Informationen zum Pfad und der Größe der Active Directory-Datenbank 

sowie der zugehörigen Protokolldateien angezeigt. 

7. Geben Sie den Befehl compact to Laufwerk:\Verzeichnis ein. Wählen Sie ein Laufwerk und Verzeichnis 

mit ausreichend Platz zum Speichern der gesamten Datenbank. Wenn im Namen des Verzeichnispfads 

Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. 

8. Bei der Offlinedefragmentierung wird eine neue Datenbank mit dem Namen Ntds.dit in dem von 

Ihnen angegebenen Pfad erstellt. Sobald die Datenbank in das neue Verzeichnis kopiert wurde, ist 

sie defragmentiert.


9. Geben Sie, sobald die Defragmentierung abgeschlossen ist, zweimal quit ein, um zur Eingabeaufforderung 

zurückzugelangen. 

10. Kopieren Sie die defragmentierte Datei Ntds.dit über die alte Datei Ntds.dit im Pfad der Active 

Directory-Datenbank, und löschen Sie die alten Protokolldateien. 

11. Starten Sie den Domänencontroller neu. 

Hinweis Wenn Sie eine Datenbankdefragmentierung durchführen, da Sie eine große Anzahl an Objekten 

aus Active Directory gelöscht haben, müssen Sie dieses Verfahren für jeden Domänencontroller durchführen. 

Verwalten der Active Directory-Datenbank mithilfe des Tools Ntdsutil 

Sie können Ntdsutil nicht nur zum Defragmentieren Ihrer Active Directory-Datenbank im Offlinestatus 

verwenden, sondern mit diesem Tool auch verschiedene Verwaltungsaufgaben für die Active 

Directory-Datenbank ausführen. Das Tool Ntdsutil kann ferner zur Durchführung verschiedener 

Active Directory-Wiederherstellungsaufgaben verwendet werden. Die Optionen für die Datenbankwiederherstellung 

sind nicht destruktiv, d.h. es wird zwar der Versuch unternommen, vorliegende 

Probleme mit der Active Directory-Datenbank zu beheben, dies jedoch ohne dabei jemals Daten zu 

löschen. 

Wiederherstellen der Transaktionsprotokolle 

Bei der Wiederherstellung der Transaktionsprotokolle wird der Domänencontroller zum erneuten 

Ausführen der Transaktionsprotokolle gezwungen. Diese Option wird vom Domänencontroller automatisch 

beim Neustart des Domänencontrollers nach einem erzwungenen Herunterfahren ausgeführt. 

Sie können während der Wiederherstellung auch die Verwendung des Tools Ntdsutil erzwingen. 

Weitere Informationen In Kapitel 15 wird die Verwendungsweise von Transaktionsprotokollen in Active 

Directory ausführlich beschrieben. 

Führen Sie für eine Wiederherstellung der Transaktionsprotokolle die folgenden Schritte aus: 

1. Starten Sie den Server neu, und wählen Sie die Option zum Starten im Wiederherstellungsmodus 

für Verzeichnisdienste. Optional können Sie den Dienst Active Directory-Domänendienste für 

Windows Server 2008-Domänencontroller anhalten. Es ist für alle Ntdsutil-Datenbankvorgänge 

erforderlich, die AD DS anzuhalten. 


3. Geben Sie an der Ntdsutil-Eingabeaufforderung die Zeichenfolge Activate Instance NTDS ein. 


5. Geben Sie an der File Maintenance-Eingabeaufforderung den Befehl recover ein. 

Die Wiederherstellungsoption sollte bei einer Datenbankwiederherstellung immer als Erstes ausgeführt 

werden, da so die Konsistenz der Datenbank mit den Transaktionsprotokollen gewährleistet 

wird. Nach Abschluss der Wiederherstellung können Sie bei Bedarf weitere Datenbankoptionen ausführen. 

Überprüfen der Datenbankintegrität 

Eine Integritätsüberprüfung der Datenbank bedeutet, dass die Datenbank bis zur untersten Ebene 

(Binärebene) auf Beschädigungen überprüft wird.


Während dieses Verfahrens werden auch die Datenbankheader und alle Tabellen auf Konsistenz überprüft. 

Da diese Überprüfung jedes Byte der Datenbank einbezieht, kann dieses Verfahren für große 

Datenbanken sehr viel Zeit in Anspruch nehmen. Um eine Integritätsprüfung durchzuführen, geben 

Sie in Ntdsutil an der File Maintenance-Eingabeaufforderung den Befehl integrity ein. 

Semantische Datenbankanalyse 

Die semantische Datenbankanalyse unterscheidet sich von der Integritätsüberprüfung dahingehend, 

dass die Datenbank nicht auf Binärebene überprüft wird. Bei einer Semantikanalyse wird vielmehr die 

Konsistenz der Datenbank in Bezug auf die Active Directory-Semantik überprüft. Bei einer semantischen 

Datenbankanalyse wird jedes Objekt in der Datenbank überprüft, um sicherzustellen, dass 

jedes Objekt über eine GUID, eine eigene SID sowie über ordnungsgemäße Replikationsmetadaten 

verfügt. 

Führen Sie für eine semantische Datenbankanalyse die folgenden Schritte aus: 


2. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl Activate Instance NTDS ein. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl semantic database analysis ein. 

4. Geben Sie an der semantic checker-Eingabeaufforderung den Befehl verbose on ein. Durch diese 

Einstellung wird Ntdsutil angewiesen, während der Semantikprüfung zusätzliche Informationen 

auf dem Bildschirm auszugeben. 

5. Geben Sie an der semantic checker-Eingabeaufforderung den Befehl go ein. 

Verschieben von Datenbank- und Transaktionsprotokollverzeichnissen 

Sie können das Tool Ntdsutil auch zum Verschieben von Active Directory-Datenbank- und Transaktionsprotokollen 

verwenden. Wenn sich die Transaktionsprotokolle und die Datenbank beispielsweise 

auf derselben Festplatte befinden, möchten Sie vielleicht eine der Komponenten auf einen anderen 

Datenträger verschieben. Wird der Speicherplatz auf der Festplatte mit der Datenbankdatei knapp, so 

muss die Datenbank verschoben werden. 

Führen Sie zum Verschieben der Datenbank und Transaktionsprotokolle in neue Verzeichnisse, während 

sich der Server im Wiederherstellungsmodus für Verzeichnisdienste befindet (oder der Dienst 

Active Directory-Domänendienste angehalten wurde), die folgenden Schritte aus: 


2. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl Activate Instance NTDS ein. 


4. Um zu ermitteln, an welcher Stelle sich die Dateien derzeit befinden, geben Sie an der Ntdsutil- 

Eingabeaufforderung den Befehl info ein. Über diesen Befehl werden die Verzeichnisse der 

Datenbank und aller Protokolle aufgelistet. 

5. Um die Datenbankdatei zu verschieben, geben Sie an der File Maintenance-Eingabeaufforderung 

den Befehl move db to Verzeichnis ein, wobei Verzeichnis für das Zielverzeichnis der Dateien 

steht. Durch die Ausführung dieses Befehls wird die Datenbank in das angegebene Verzeichnis 

verschoben, und die Registrierung wird für den Zugriff auf die Datei im aktuellen Verzeichnis 

erneut konfiguriert. 

6. Um die Transaktionsprotokolle zu verschieben, geben Sie an der File Maintenance-Eingabeaufforderung 

den Befehl move logs to Verzeichnis ein.



In diesem Kapitel wurden die Verfahren und einige der erforderlichen Tools zum Überwachen von 

Active Directory und dem Systemstatus von Domänencontrollern vorgestellt. Durch die Implementierung 

einer Überwachungslösung können Sie mögliche Systemengpässe sowie Leistungsprobleme, die 

Unterbrechungen und hohe Kosten verursachen können, bereits vor deren Auftreten ermitteln. Durch 

eine effektive Überwachung von Active Directory können Sie darüber hinaus wertvolle Leistungstrenddaten 

sammeln, um sich auf zukünftige Systemverbesserungen vorzubereiten. Mithilfe der Überwachung 

können Sie die Supportmaßnahmen ergreifen, die zur Gewährleistung eines einwandfreien 

Status Ihrer Active Directory-Infrastruktur erforderlich sind. Auch wenn keine Ereignisprotokollfehler 

auftreten und keine Warnungsbenachrichtigungen ausgegeben werden, ist es dennoch erforderlich, 

eine regelmäßige Datenbankwartung durchzuführen, um die effiziente Funktion der Active Directory- 

Datenbank aufrechtzuerhalten. In diesem Kapitel wurden ferner die Verfahren zur Online- und Offlinedefragmentierung 

sowie zur Sammlung veralteter Objekte zum Entfernen gelöschter Active 

Directory-Objekte (Tombstones) beschrieben. 





• In Kapitel 15, „Active Directory-Notfallwiederherstellung“, werden Informationen zur Active 

Directory-Datenspeicherung und zum Wiederherstellen der Active Directory-Datenbank bereitgestellt. 

• Der Artikel „Windows Reliability And Performance Monitor“ (in englischer Sprach) unter 

http://technet2.microsoft.com/windowsserver2008/en/library/ec5b5e7b-5d5c-4d04-98ad- 

55d9a09677101033.mspx?mfr=true 

• Der Artikel „AD DS: Restartable Active Directory Domain Services“ (in englischer Sprache) 

unter http://technet2.microsoft.com/windowsserver2008/en/library/822ff47d-bd55-4c08-abc1- 

2d66336e33e51033.mspx?mfr=true 

• Der Artikel „Windows Vista: Zuverlässigkeit und Leistung“ unter http://technet.microsoft.com/dede/windowsvista/aa905077.aspx 

• Der Artikel „Active Directory Directory Services Maintenance Utility (Ntdsutil.exe)“ (in englischer 

Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/819bea8b-3889- 

4479-850f-1f031087693d1033.mspx?mfr=true 

• Der Artikel „Relocating Active Directory Database Files“ (in englischer Sprache) unter 

http://technet2.microsoft.com/windowsserver/en/library/af6646aa-2360-46e4-81cad51707bf01eb1033.mspx?mfr=true 

• Der Artikel „Relocating SYSVOL Manually“ (in englischer Sprache) unter http://technet2.microsoft.com/windowsserver/en/library/300796c6-8148-49af-a327-b5dca853ac4f1033.mspx?mfr=true 

• Der Artikel „Best Practices for SYSVOL Maintenance“ (in englischer Sprache) unter 

http://support.microsoft.com/kb/324175


• Der Artikel „Microsoft Active Directory Management Pack-Handbuch“ unter http://www.microsoft.com/downloads/details.aspx?familyid=2B9D3613-5516-4F44-8550-B21E054F5047&displaylang=de 

• Der Artikel „Monitoring Active Directory with MOM“ (in englischer Sprache) unter 

http://download.microsoft.com/documents/uk/technet/downloads/technetmagazine/issue4/ 

36_monitoring_ad_with_mom.pdf

575 

K A P I T E L 1 5 

Active Directory-Notfallwiederherstellung 


Vorbereiten auf einen Ausfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 

Active Directory-Datenspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 

Sichern von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 

Wiederherstellen von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 




Die Active Directory-Domänendienste (Active Directory Domain Services, AD DS) sind wahrscheinlich 

die wichtigsten Netzwerkdienste, die in einem Netzwerk bereitgestellt werden. Bei einem 

Ausfall der Active Directory-Infrastruktur steht Benutzern im Netzwerk nur noch ein äußerst eingeschränkter 

Funktionsumfang zur Verfügung. Für beinahe alle Netzwerkdienste in einem Windows 

Server 2008-Netzwerk ist vor dem Zugriff auf eine Netzwerkressource eine Benutzerauthentifizierung 

gegenüber Active Directory erforderlich. Da Active Directory so wichtig ist, sind zumindest 

dieselben vorbeugenden Maßnahmen zur Vermeidung eines Active Directroy-Ausfalls und einer 

anschließenden Wiederherstellung zu treffen, wie dies auch bei jeder anderen Netzwerkressource der 

Fall ist. Bei der Bereitstellung von Windows Server 2008 Active Directory ist es unerlässlich, sich auf 

den Schutz der Active Directory-Datenbank vorzubereiten und einen Plan für die Notfallwiederherstellung 

der Datenbank zu erarbeiten, falls ein schwerwiegender Fehler auftritt. 

Zu Beginn dieses Kapitels werden einige empfohlene Vorgehensweisen beschrieben, über die Redundanz 

und Schutz für Active Directory sichergestellt werden kann. Anschließend werden die Komponenten 

der Active Directory-Datenbank sowie deren optimale Konfiguration zur Bereitstellung der 

Notfallwiederherstellungsfunktion erläutert. Optionen und Vorgehensweisen zur Sicherung und Wiederherstellung 

der Active Directory-Datenbank finden sich im Hauptteil dieses Kapitels. 

Weitere Informationen Dieses Kapitel enthält keine Informationen zur Wiederherstellung einer vollständigen 

Active Directory-Gesamtstruktur aus einer Sicherungsdatei, sondern lediglich zur Wiederherstellung 

einzelner Domänencontroller und Active Directory-Objekte in einer Domäne. Informationen zur Wiederherstellung 

einer vollständigen Active Directory-Gesamtstruktur finden Sie unter dem Titel „Planning for Active 

Directory Forest Recovery“ im Microsoft Download Center auf der englischsprachigen Website unter 

http://www.microsoft.com/downloads/details.aspx?FamilyID=AFE436FA-8E8A-443A-9027- 

C522DEE35D85&displaylang=en.

576 Kapitel 15: Active Directory-Notfallwiederherstellung 

Vorbereiten auf einen Ausfall 

Lange bevor es zu einem Ausfall kommt, müssen bereits die Vorbereitungen für eine Notfallwiederherstellung 

getroffen werden. Wenn kein umfassender Plan für einen potenziellen Ausfall erarbeitet 

wurde, kann bereits ein Problem wie z.B. der Ausfall einer Hardwarekomponente auf einem Domänencontroller 

nicht nur zu Unannehmlichkeiten, sondern zu einer regelrechten Katastrophe führen. 

Bei der Vorbereitung auf einen Ausfall müssen alle Elemente einer normalen Netzwerkinfrastruktur 

sowie ein Active Directory-spezifischer Plan berücksichtigt werden. Die folgenden Vorgehensweisen 

werden dringend empfohlen: 

• Entwickeln Sie einen konsistenten Sicherungs- und Wiederherstellungsplans für die Domänencontroller. 

Der erste Schritt jedes Wiederherstellungsplans ist die Installation einer geeigneten 

Sicherungshardware und -software zur Sicherung der Domänencontroller. Als Nächstes sollte ein 

Sicherungs- und Wiederherstellungsplan erstellt und getestet werden. Darüber hinaus wird empfohlen, 

Active Directory vor jeder größeren Statusänderung, wie einem Schema-Update oder 

Massenimport, zu sichern. 

• Testen Sie Ihren Sicherungsplan vor der Active Directory-Bereitstellung, und führen Sie nach der 

Bereitstellung regelmäßige Tests durch. Active Directory muss nach der Bereitstellung für Benutzer 

jederzeit verfügbar sein. Der Wiederherstellungsplan sollte ebenfalls wiederholt getestet werden. 

Gut verwaltete Netzwerkumgebungen verfügen über ein einheitliche 

Testwiederherstellungsverfahren, bei denen jede Woche eine Komponente der Wiederherstellungsverfahren 

getestet wird. Bei einem tatsächlichen Ausfall besteht ein großer Zeitdruck, da 

Active Directory schnellstmöglich wiederhergestellt werden muss – bei dieser Gelegenheit sollte 

das Active Directory-Wiederherstellungsverfahren nicht zum ersten Mal angewendet werden. 

• Testen Sie Änderungen an Active Directory in einer Testumgebung. Auf diese Weise wird das 

Risiko minimiert, dass größere Active Directory-Updates zu Problemen in der Produktionsumgebung 

führen. Wurde das Update in der Testumgebung erfolgreich ausgeführt, kann es in der Produktionsumgebung 

implementiert werden. 

• Stellen Sie Active Directory-Domänencontroller mit Hardwareredundanz bereit. Die meisten 

Server bieten bei nur geringem Kostenaufschlag bereits einen gewissen Grad an Hardwareredundanz. 

Ein Server sollte zum Beispiel für Domänencontroller standardmäßig mit zwei Netzteilen, 

redundanten Netzwerkkarten und einem hardwarebasierten redundanten Festplattensystem ausgestattet 

sein. Wenn Ihnen diese Redundanz den Aufwand einer nächtlichen Wiederherstellung des 

Domänencontrollers erspart, hat sich die Investition in jedem Fall gelohnt. In vielen großen 

Umgebungen wird Hardwareredundanz auf einer höherer Ebene bereitgestellt, indem einzelne 

Domänencontroller an verschiedene Stromkreise und Ethernet-Switches oder Netzwerksegmente 

angeschlossen werden. 

• Stellen Sie – abgesehen von sehr kleinen Netzwerken – mindestens zwei Domänencontroller 

bereit. Active Directory verwendet eine zirkuläre Protokollierung für die Protokolldateien, und 

diese Standardeinstellung kann nicht geändert werden. Dies bedeutet Folgendes: Wenn Sie nur 

einen Domänencontroller einsetzen, können Active Directory-Daten verloren gehen, wenn der 

Domänencontroller ausfällt und die Daten aus einer Sicherung wiederhergestellt werden müssen. 

Selbst in einem kleinen Unternehmen ist die Verwendung mehrerer Domänencontroller unerlässlich.

Active Directory-Datenspeicher 577 

Sollen alle Benutzer vorwiegend nur einen Domänencontroller nutzen, kann in den DNS-Datensätzen 

(Domain Name System) für jeden Domänencontroller die gewünschte Priorität festgelegt 

werden. Der zweite Domänencontroller kann dann eine andere Funktion übernehmen und ausschließlich 

als Reservedomänencontroller eingesetzt werden, wenn der erste Domänencontroller 

ausfällt. 

Active Directory-Datenspeicher 

Die Active Directory-Datenbank wird in einer als Ntds.dit bezeichneten Datei gespeichert, die sich 

standardmäßig im Ordner %systemroot%\NTDS befindet. Die Dateien in diesem Ordner werden in 

Abbildung 15.1 dargestellt. Dieser Ordner enthält darüber hinaus die folgenden Dateien: 

• Edb.chk Bei dieser Datei handelt es sich um eine Prüfpunktdatei, die anzeigt, welche Transaktionen 

aus den Protokolldateien in die Active Directory-Datenbank geschrieben wurden. 

• Edb.log Diese Datei ist das aktuelle Transaktionsprotokoll, eine Datei fester Länge mit einer 

Größe von genau 10 MB (Megabyte). 

• Edbxxxxx.log Wenn Active Directory über einen längeren Zeitraum ausgeführt wurde, sind möglicherweise 

eine Protokolldatei oder mehrere Protokolldateien vorhanden, die nach dem Muster 

xxxxx Dateiname benannt sind. Hierbei steht xxxxx für einen aufsteigenden Wert im Hexadezimalformat. 

Diese Protokolldateien sind vorherige Protokolldateien. Sobald die maximale Größe 

der aktuellen Protokolldatei erreicht ist, wird diese in die nächste vorherige Protokolldatei 

umbenannt, und es wird eine neue Edb.log-Datei erstellt. Die alten Protokolldateien werden 

automatisch gelöscht, wenn die Änderungen in den Protokolldateien in die Active Directory- 

Datenbank übernommen wurden. Die Größe dieser Protokolldateien beträgt je 10 MB. 

• Edbtmp.log Dieses temporäre Protokoll wird verwendet, wenn die aktuelle Protokolldatei 

(Edb.log) voll ist. Zum Speichern der Transaktionen wird eine neue Datei mit dem Namen 

Edbtemp.log erstellt, und die Datei Edb.log wird in die nächste vorherige Protokolldatei 

umbenannt. Anschließend wird der Name der Datei Edbtemp.log in Edb.log geändert. Da dieser 

Dateiname vorübergehend verwendet wird, ist er normalerweise nicht sichtbar. 

• Edbres00001.jrs und edbres00002.jrs Diese reservierten Protokolldateien werden ausschließlich 

verwendet, wenn auf der Festplatte, auf der sich die Protokolldateien befinden, nicht mehr genügend 

Speicherplatz vorhanden ist. Wenn die aktuelle Protokolldatei voll ist und der Server aus 

Speicherplatzgründen keine neue Protokolldatei erstellen kann, werden alle derzeit gespeicherten 

Active Directory-Transaktionen in die beiden reservierten Protokolldateien verschoben. Anschließend 

wird Active Directory beendet. Die Größe dieser Protokolldateien beträgt je 10 MB. 

• Temp.edb Diese temporäre Datei wird während der Datenbankwartung verwendet, um Informationen 

zu derzeit ausgeführten Transaktionen zu speichern. 

Hinweis Wenn Sie bereits mit neueren Versionen von Microsoft Exchange Server vertraut sind, werden 

Ihnen die hier beschriebenen Active Directory-Datenbankkomponenten und -prozesse sehr bekannt vorkommen. 

Die Active Directory-Datenbank ist dieselbe Datenbank, die von Servern mit Exchange Server 4 oder 

höher bereitgestellt wird.



Im Ordner %systemroot%\NTDS gespeicherte Active Directory-Dateien 

Jede an der Active Directory-Datenbank vorgenommene Änderung wird als Transaktion bezeichnet. 

Eine Transaktion kann aus mehreren Schritten bestehen. Wenn ein Benutzer beispielsweise von einer 

Organisationseinheit (Organizational Unit, OU) in eine andere verschoben wird, muss das Objekt in der 

Zielorganisationseinheit erstellt und in der Quellorganisationseinheit gelöscht werden. Die Transaktion 

ist erst abgeschlossen, wenn beide Schritte erfolgreich durchgeführt wurden. Falls eine Schritt 

fehlschlägt, muss ein Rollback der Transaktion ausgeführt werden, um beide Schritte vollständig 

rückgängig zu machen. Wenn alle Schritte in einer Transaktion abgeschlossen wurden, wird die 

Transaktion übernommen bzw. es wird ein Commit ausgeführt. Durch die Verwendung eines transaktionsbasierten 

Modells in Active Directory wird sichergestellt, dass die Datenbank sich stets in einem 

konsistenten Zustand befindet. 

Jede an der Active Directory-Datenbank vorgenommene Änderung (z.B. eine geänderte Telefonnummer 

eines Benutzers) wird zunächst in eine Transaktionsprotokolldatei geschrieben. Bei der 

Transaktionsprotokolldatei handelt es sich im Grunde genommen um eine Textdatei, in der Änderungen 

nacheinander aufgelistet werden. Daher können Schreibvorgänge in einem Transaktionsprotokoll 

wesentlich schneller ausgeführt werden als in eine Datenbank. Folglich wird die Leistung des 

Domänencontrollers durch die Verwendung von Transaktionsprotokollen verbessert. 

Nach dem Erfassen der Transaktion im Transaktionsprotokoll lädt der Domänencontroller die Datenbankseite, 

die das Benutzerobjekt enthält, in den Arbeitsspeicher (falls sich diese noch nicht im 

Arbeitsspeicher befindet). Alle Änderungen an der Active Directory-Datenbank werden im Arbeitsspeicher 

des Domänencontroller erfasst. Der Domänencontroller verwendet hierbei so viel Arbeitsspeicher 

wie möglich und legt möglichst viele Active Directory-Datenbankdaten im Arbeitsspeicher 

ab. Datenbankseiten werden nur dann vom Domänencontroller aus dem Arbeitsspeicher gelöscht, 

wenn der verfügbare Arbeitsspeicher nicht mehr ausreicht oder der Domänencontroller heruntergefahren 

wird. Bei geringer Serverauslastung oder beim Herunterfahren des Servers werden Änderungen 

an den Datenbankseiten in der Datenbank gespeichert. 

Transaktionsprotokolle verbessern die Leistung des Domänencontrollers nicht nur, indem sie eine 

schnelle Erfassung von Änderungen, sondern ebenfalls bestimmte Systemwiederherstellungsfunktionen 

bei einem Serverausfall bieten. Werden beispielsweise Änderungen in Active Directory vorgenommen, 

werden diese in die Transaktionsprotokolle geschrieben und anschließend auf der Datenbankseite 

im Serverarbeitsspeicher erfasst.

Sichern von Active Directory 579 

Sollte der Server zu diesem Zeitpunkt unerwartet heruntergefahren werden, wurden die Änderungen 

im Serverarbeitsspeicher noch nicht in die Datenbank übernommen. Beim Neustart des Domänencontrollers 

überprüft dieser die Transaktionsprotokolle auf Transaktionen, die noch nicht in die Datenbank 

übernommen wurden. Diese Änderungen werden beim Neustart des Domänencontrollerdienstes 

auf die Datenbank angewendet. Für diesen Wiederherstellungsprozesses wird die Prüfpunktdatei verwendet. 

Bei dieser Prüfpunktdatei handelt es sich um einen Zeiger auf die Transaktionen in den 

Transaktionsprotokollen, die in die Datenbank geschrieben wurden. Während des Wiederherstellungsprozesses 

ermittelt der Domänencontroller beim Lesen der Prüfpunktdatei, welche Transaktionen 

bereits in die Datenbank übernommen wurden. Anschließend werden sämtliche Änderungen angewendet, 

die noch nicht übernommen wurden. 

Hinweis Die Verwendung von Transaktionsprotokollen verbessert die Leistung des Domänencontrollers 

sowie die Datenwiederherstellung beim unerwarteten Herunterfahren. Zur optimalen Nutzung dieser Vorteile 

sollten sich die Transaktionsprotokolle und die Datenbank auf separaten Festplatten befinden, da so Leistungsengpässe 

der Festplatten vermieden werden. 

Active Directory in Windows Server 2008 verwendet eine zirkuläre Protokollierung, und diese Standardeinstellung 

kann nicht geändert werden. Bei der zirkulären Protokollierung werden ausschließlich 

vorherige Protokolldateien beibehalten, die noch nicht in der Datenbank erfasste Transaktionen 

beinhalten. Sobald die Informationen aus der vorherigen Protokolldatei in die Datenbank übernommen 

wurden, wird die Protokolldatei gelöscht. Das wiederholte Übernehmen von Transaktionen aus 

Protokolldateien bei der Aktualisierung einer wiederhergestellten Datenbank lässt sich mithilfe der 

zirkulären Protokollierung vermeiden. Stattdessen wird die wiederhergestellte Active Directory- 

Datenbank mit einer auf einem zweiten Domänencontroller gespeicherten Kopie auf den aktuellen 

Stand gebracht. 

Sichern von Active Directory 

Die Vorgehensweise zur Sicherung von Active Directory in Windows Server 2008 unterscheidet sich 

im Wesentlichen von der in Windows Server 2003 und Windows 2000 Server. Die Windows Server- 

Sicherung und das Befehlszeilenprogramm Wbadmin.exe ersetzen das Sicherungsdienstprogramm 

Ntbackup.exe. Im neuen Dienstprogramm für die Sicherung sind folgende Änderungen zu beachten: 

• Die Windows Server-Sicherung und Wbadmin.exe sind standardmäßig nicht installiert. Zur Verwendung 

dieser Dienstprogramme muss zunächst das Windows Server-Sicherungsfeature installiert 

werden. 

• Nur ganze Volumes können gesichert werden. Es gibt keine Option, über die ausschließlich Systemstatusdaten 

gesichert werden können, zu denen Active Directory gehört. Daher sollten wichtige 

Volumes gesichert werden, um die Systemstatusdaten zu sichern. 

• Sicherungen werden nur auf Festplatte oder DVD durchgeführt. Das Durchführen von Bandsicherungen 

ist mit der Windows Server-Sicherung nicht möglich. Hierzu muss eine Sicherungslösung 

eines Drittanbieters verwendet werden. Sicherungen können auf einer lokalen Festplatte, externen 

Festplatte, Remotefreigabe oder DVD gespeichert werden. 

• Sicherungen lassen sich schneller durchführen. Die Windows Server-Sicherung führt Sicherungen 

mit dem Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) durch und 

überwacht Änderungen auf Blockebene. Auf diese Weise lassen sich sowohl inkrementelle als 

auch vollständige Sicherungen schneller durchführen.


Bei den Systemstatusdaten handelt es sich um eine Sammlung von Konfigurationsdaten auf einem 

Server. Diese Daten sind eng integriert und müssen als einzelne Einheit gesichert und wiederhergestellt 

werden. Unter Windows Server 2003 und Windows 2000 konnten ausschließlich Systemstatusdaten 

gesichert werden. Bei Verwendung der Windows Server-Sicherung oder des Dienstprogramms 

Wbadmin.exe unter Windows Server 2008 müssen wichtige Volumes gesichert werden, die Systemstatusdaten 

enthalten. Bei Aktivierung der Windows Server-Sicherungsoption Systemwiederherstellung 

aktivieren werden alle wichtigen Volumes automatisch ausgewählt (siehe Abbildung 15.2). 


Sicherung wichtiger Volumes mithilfe der Windows Server-Sicherung 

Welche Volumes für einen Server wichtig sind, hängt von den auf dem Server installierten Rollen ab. 

Das Systemvolume, das als Host für die Startdateien, wie dem Startkonfigurations-Datenspeicher 

(Boot Configuration Data, BCD) und dem Start-Manager (Bootmgr) dient, ist ein wichtiges Volume. 

Das Startvolume mit dem Windows-Betriebssystem ist ebenfalls ein wichtiges Volume. Darüber 

hinaus befinden sich auf weiteren wichtigen Volumes die folgenden zusätzlichen Daten: 

• SYSVOL-Verzeichnis 

• Active Directory-Datenbank und Protokolldateien 

• Registrierung 

• COM+-Klassenregistrierungsdatenbank 

• Datenbank der Active Directory-Zertifikatdienste 

• Clusterdienstinformationen 

• Systemdateien, die dem Windows-Ressourcenschutz unterliegen 

Windows Server 2008 verfügt über ein IFM-Feature (Install From Media) zum Installieren von einem 

Medium, dass bei der Installation neuer Domänencontroller verwendet werden kann.

Sichern von Active Directory 581 

Anstatt die gesamte Active Directory-Datenbank zu replizieren, verwendet das IFM-Feature eine wiederhergestellte 

Active Directory-Kopie als Ausgangspunkt für die Replikation auf neuen Domänencontrollern. 

Dies ist besonders für Server in Zweigstellen mit einer niedrigen Breitbandverbindung 

sinnvoll. Der Sicherungssatz für das IFM-Feature wird nicht über die Windows Server-Sicherung oder 

Wbadmin.exe, sondern über Ntdsutil erstellt. 

Hinweis Mitglieder der Gruppen Administratoren und Sicherungs-Operatoren verfügen über die erforderlichen 

Rechte zur Durchführung einer manuellen Sicherung. Eine geplante Sicherung können ausschließlich 

Mitglieder der Gruppe Administratoren durchführen, da diese über die erforderlichen Rechte verfügen. Diese 

Rechte können nicht delegiert werden. 

Notwendigkeit von Sicherungen 

Das Standardverfahren bei der Sicherung von Active Directory ist die Replikation auf einem zweiten 

Domänencontroller. Beim Ausfall eines Domänencontrollers in einer Domäne verfügen die anderen 

Domänencontroller über dieselben Informationen und können die Aufgabe der Clientanmeldung oder 

eine Verarbeitung von Clientanforderungen übernehmen. Aus diesem Grund sollten stets mindestens 

zwei Domänencontroller pro Domäne vorhanden sein. 

Obwohl die Domäneninformationen zwischen Domänencontrollern repliziert werden, sollte ein Domänencontroller 

dennoch regelmäßig gesichert werden. In folgenden Fällen kann das Wiederherstellen 

von vorhandenen Domänencontrollern oder Active Directory erforderlich sein: 

• Anwendungen sind so konfiguriert, dass diese einen bestimmten Domänencontroller verwenden Einige 

Anwendungen sind so konfiguriert, dass diese für den Zugriff auf Active Directory einen 

bestimmten Domänencontroller verwenden. In einem solchen Fall wird durch das Wiederherstellen 

eines Domänencontrollers die Neukonfiguration der Anwendung vermieden. 

• Alle Domänencontroller einer Domäne sind ausgefallen Falls es zu einer größeren Katastrophe 

kommt, z.B. zu einem Feuer im Gebäude, können alle Domänencontroller einer Domäne ausfallen. 

In diesem Fall muss Active Directory über eine Sicherung wiederhergestellt werden. 

• Objekte werden gelöscht Falls Active Directory-Objekte versehentlich gelöscht werden, können 

die gelöschten Objekte über eine Sicherung wiederhergestellt werden. Abhängig von der Anzahl 

an Objekten ist diese Vorgehensweise möglicherweise schneller als das erneute Erstellen der 

Objekte. 

Tombstone-Ablaufzeit 

Die Tombstone-Ablaufzeit legt fest, wie lange ein gelöschtes Objekt in Active Directory gespeichert 

wird. Wie bereits in Kapitel 14, „Überwachen und Warten von Active Directory“, beschrieben, wird 

ein Active Directory-Objekt nach dem Löschen nicht aus Active Directory entfernt. Das Objekt wird 

stattdessen als gelöscht gekennzeichnet, die meisten Attribute werden entfernt, das Objekt wird 

umbenannt und schließlich in den Container Gelöschte Objekte verschoben. Anschließend wird dieses 

Objekt als Tombstone bezeichnet. Diese Änderungen werden auf alle anderen Domänencontroller 

repliziert, und der Tombstone wird erst nach der Tombstone-Ablaufzeit aus Active Directory entfernt. 

Eine Sicherung ist nur für die Dauer der in Active Directory festgelegten Tombstone-Ablaufzeit gültig. 

Nach der Tombstone-Ablaufzeit ist eine Wiederherstellung von Active Directory-Sicherungen nicht 

mehr möglich. Auf diese Weise wird sichergestellt, dass nicht autorisierende Wiederherstellungen von 

Active Directory wie erwartet funktionieren.


Wenn zum Beispiel eine Sicherung, die den Benutzer Paul umfasst, zur Wiederherstellung eines 

Domänencontrollers verwendet wird, nachdem das Objekt Paul gelöscht wurde, wird der gelöschte 

Status von Paul zurück auf den wiederhergestellten Domänencontroller repliziert. Der gelöschte Status 

von Paul bleibt unverändert, da die Sicherung innerhalb der für Active Directory festgelegten 

Tombstone-Ablaufzeit durchgeführt wurde. Wäre der Domänencontroller nach der Tombstone-Ablaufzeit 

wiederhergestellt worden, wäre Paul wiederhergestellt worden. Der gelöschte Status von Paul 

wäre auf keinem anderen Domänencontroller vorhanden und könnte daher auch nicht zurück repliziert 

werden. Obwohl es gelöscht wurde, bleibt das Objekt Paul weiterhin in Active Directory erhalten. 

Dies führt zu einer Inkonsistenz in Active Directory, und das Objekt muss entfernt werden. 

Die Tombstone-Ablaufzeit wird für eine ganze Gesamtstruktur konfiguriert. Der Wert für die Tombstone-Ablaufzeit 

wird im Attribut tombstoneLifetime des Objekts CN=Directory Service,CN= 

Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain gespeichert, wie in 

Abbildung 15.3 gezeigt. Der Standardwert hängt vom Betriebssystem ab, auf dem sich die Gesamtstruktur 

befindet (siehe Tabelle 15.1). Diese Werte gelten nur beim Erstellen einer neuen Active 

Directory-Gesamtstruktur. Upgrades oder Service Packs haben keine Auswirkungen auf die Werte. 

Der Standardwert für die Tombstone-Ablaufzeit lässt sich mithilfe von ADSIEdit.msc anpassen. 


Das tombstoneLifetime-Attribut für eine Active Directory-Gesamtstruktur 

Tabelle 15.1 

Standard-Tombstone-Ablaufzeiten für neue Active Directory-Gesamtstrukturen 

Betriebssystem 

Windows 2000 Server 

Windows Server 2003 ohne Service Pack 

Windows Server 2003 SP1 

Windows Server 2003 R2 

Windows Server 2003 SP2 


Standard-Tombstone-Ablaufzeit 

60 Tage 

60 Tage 

180 Tage 

60 Tage 

180 Tage 

180 Tage

Sicherungshäufigkeit 

Wiederherstellen von Active Directory 583 

Wenngleich die Sicherungshäufigkeit durch die Tombstone-Ablaufzeit festgelegt ist, sollten die 

Domänencontroller während der Dauer der Tombstone-Ablaufzeit häufiger gesichert werden. Zusätzlich 

zum Tombstone-Problem muss eine Vielzahl an Aspekten berücksichtigt werden, wenn der 

Domänencontroller über eine Sicherung wiederhergestellt werden soll, die bereits älter als ein paar 

Tage ist. Da die Wiederherstellung von Active Directory alle Informationen auf wichtigen Volumes 

umfasst, werden diese mit einem vorherigen Status wiederhergestellt. Wenn auf dem Server die Rolle 

Active Directory-Zertifikatdienste installiert ist, wird keines der seit der Sicherung ausgegebenen Zertifikate 

in der Datenbank der Active Directory-Zertifikatdienste enthalten sein. Wenn Treiber aktualisiert 

oder neue Anwendungen installiert wurden, funktionieren diese möglicherweise nicht, da ein 

Rollback der Registrierung auf einen vorherigen Status durchgeführt wurde. Fast alle Unternehmen 

gehen nach einen Sicherungsplan vor, bei dem zumindest einige der Server nachts gesichert werden. 

Auch die Domänencontroller sollten Teil dieser nächtlichen Sicherungen sein. 

Wiederherstellen von Active Directory 

Die Wiederherstellung von Active Directory kann aus zwei Gründen erforderlich sein. Der erste 

Grund ist eine unbrauchbare Datenbank. Die Ursache hierfür kann ein Festplattenausfall eines Domänencontrollers 

oder eine beschädigte Datenbank sein, die nicht mehr geladen werden kann. Als zweite 

Fehlerursache kommen menschliche Fehler in Betracht, die zu Problemen mit Verzeichnisinformationen 

führen. Wenn ein Benutzer zum Beispiel eine Organisationseinheit mit mehreren Hundert Benutzer- 

und Gruppenkonten gelöscht hat, sollten die Informationen nicht neu eingegeben werden müssen, 

sondern wiederhergestellt werden können. 

Bei einer Active Directory-Wiederherstellung, die auf eine unbrauchbare Datenbank auf einem der 

Domänencontroller zurückzuführen ist, gibt es zwei Möglichkeiten. Bei der ersten Möglichkeit wird 

Active Directory nicht auf dem ausgefallenen Server wiederhergestellt. Stattdessen wird ein anderer 

Domänencontroller erstellt, indem ein anderer Windows Server 2008-Server zu einem Domänencontroller 

heraufgestuft wird. Bei dieser Vorgehensweise stellen Sie nicht Active Directory auf einen 

bestimmten Domänencontroller, sondern die Domänencontrollerfunktionalität wieder her. Die zweite 

Wiederherstellungsmöglichkeit ist die Reparatur des ausgefallenen Servers und die anschließende 

Wiederherstellung der Active Directory-Datenbank auf diesem Server. In diesem Fall führen Sie eine 

nicht autorisierende Wiederherstellung aus. Bei einer nicht autorisierenden Wiederherstellung wird 

zunächst die Active Directory-Datenbank auf dem Domänencontroller wiederhergestellt. Im 

Anschluss werden alle seit der Sicherung an Active Directory vorgenommenen Änderungen auf den 

wiederhergestellten Domänencontroller repliziert. 

Beim Wiederherstellen von Active Directory aufgrund einer großen Anzahl an gelöschten Objekten 

gibt es nur eine Vorgehensweise. Sie stellen die Active Directory-Datenbank auf einem der Domänencontroller 

wieder her und verwenden hierbei eine Sicherung, welche die gelöschten Objekte enthält. 

Anschließend wird eine autorisierende Wiederherstellung durchgeführt. Während der autorisierenden 

Wiederherstellung werden die wiederhergestellten Daten gekennzeichnet, sodass deren 

Replikation auf alle anderen Domänencontroller den Löschvorgang der Informationen rückgängig 

macht.


Wiederherstellen von Active Directory durch Erstellen eines neuen 

Domänencontrollers 

Bei der Wiederherstellung eines Domänencontrollers nach einem Ausfall gibt es die Möglichkeit, 

einen ausgefallenen Domänencontroller durch einen neu erstellten Domänencontroller zu ersetzen. 

Bei einem Domänencontrollerausfall kann entweder ein neuer Server, auf dem Windows Server 2008 

und Active Directory ausgeführt wird, eingerichtet oder ein vorhandener Server verwendet werden, 

der zu einem Domänencontroller heraufgestuft wurde. Anschließend kann die Active Directory- 

Datenbank auf dem neuen Domänencontroller mithilfe einer normalen Active Directory-Replikation 

gefüllt werden. 

Hinweis Beim Erstellen eines neuen Domänencontrollers, auf den die Replikation über eine langsame 

Verbindung erfolgt (z.B. in einer Zweigstelle), sollte zur Verkürzung der Replikationszeit eine IFM-Installation 

verwendet werden. Als Ausgangspunkt für die Replikation verwendet eine IFM-Installation eine über 

Ntdsutil erstellte Active Directory-Sicherung. 

In den folgenden Fällen ist das Erstellen eines neuen Domänencontrollers die beste Lösung: 

• Zusätzlich zum ausgefallenen Server ist ein verfügbarer Domänencontroller vorhanden. Dies ist 

eine absolute Voraussetzung. Wenn ein weiterer Domänencontroller vorhanden ist, der als Replikationspartner 

verwendet werden kann, lässt sich die Active Directory-Datenbank ausschließlich 

auf einem neuen oder reparierten Domänencontroller wiederherstellen. 

• Der zum Einrichten des neuen Domänencontrollers und Replizieren der Informationen von einem 

anderen Domänencontroller benötigte Zeitaufwand ist wesentlich geringer als der Zeitaufwand, 

der zur Reparatur des ausgefallenen Domänencontrollers und zur Wiederherstellung der Datenbank 

erforderlich wäre. Diese Rechnung hängt von der Größe der Active Directory-Datenbank, 

der Geschwindigkeit der Netzwerkverbindung zwischen den Domänencontrollern und dem Zeitaufwand 

zum erneuten Erstellen und Wiederherstellen eines Domänencontrollers ab. Wenn die 

Active Directory-Datenbank nicht sehr groß ist (kleiner als 100 MB) und sich ein anderer Domänencontroller 

im selben lokalen Netzwerk (Local Area Network, LAN) befindet, kann das Erstellen 

eines weiteren Domänencontrollers und die Datenbankreplikation schneller durchgeführt 

werden als die Reparatur und Wiederherstellung des ausgefallenen Domänencontrollers. Wenn es 

sich um eine große Datenbank handelt oder der einzige verfügbare Replikationspartner nur über 

eine langsame WAN-Verbindung (Wide Area Network) erreicht werden kann, ist die Reparatur 

des ausgefallenen Domänencontrollers und die Wiederherstellung der Datenbank üblicherweise 

die schnellere Methode. 

• Eine Reparatur des ausgefallenen Domänencontrollers ist nicht möglich. Obwohl Windows Server 

2008 und die Active Directory-Datenbank theoretisch auf einem Server mit einer anderen 

Hardware als der des ursprünglichen Domänencontroller wiederhergestellt werden können, gestaltet 

sich dieses Verfahren häufig schwierig und kann sehr zeitaufwendig sein. Wenn der ausgefallene 

Server mit ähnlicher Hardware nicht neu eingerichtet werden kann, ist das Erstellen eines 

anderen Domänencontrollers in der Regel schneller. 

Das Erstellen eines neuen Domänencontrollers wird nicht empfohlen, wenn zur Unterstützung des 

neuen Domänencontrollers weit reichende Änderungen vorgenommen werden müssen. Ein Beispiel 

hierfür wäre die Konfiguration einer Vielzahl von Anwendungen, die einen bestimmten Domänencontroller 

verwenden.


Die Neukonfiguration dieser Anwendungen, sodass diese einen neuen Domänencontroller verwenden, 

kann länger dauern als die Reparatur oder Wiederherstellung des Domänencontrollers. Anwendungskonfigurationsprobleme 

lassen sich durch die Verwendung eines Hostnamens anstelle einer 

IP-Adresse in der Anwendungskonfiguration vermeiden. Durch das Rekonfigurieren eines DNS-Eintrags 

für den Hostnamen kann die IP-Adresse eines neuen oder alternativen Domänencontrollers 

schnell eingesetzt werden. 

Um einen weiteren Domänencontroller als Ersatz für den ausgefallenen Server zu erstellen, kann ein 

vorhandener Server, auf dem Windows Server 2008 ausgeführt wird, (oder ein neuer Server) erstellt 

und anschließend zu einem Domänencontroller heraufgestuft werden. Beim Heraufstufen wird das Verzeichnis 

von einem der anderen Domänencontroller repliziert. Falls es sich bei dem ausgefallenen 

Domänencontroller um einen globalen Katalogserver oder einen Server mit Betriebsmasterrolle handelt, 

muss eine geeignete Methode gefunden werden, um diese Funktion wiederherzustellen. Die Wiederherstellung 

von globalen Katalogservern und Betriebsmasterservern wird in diesem Kapitel im 

Abschnitt „Wiederherstellen von Betriebsmastern und globalen Katalogservern“ beschrieben. 

Wenn die Active Directory-Funktionalität durch das Erstellen eines neuen Domänencontrollers wiederhergestellt 

werden soll, muss der alte Domänencontroller noch aus dem Verzeichnis und aus dem 

DNS entfernt werden. Um den Namen des ausgefallenen Domänencontrollers für den wiederhergestellten 

Domänencontroller verwenden zu können, muss vor der Wiederherstellung zunächst das Verzeichnis 

mithilfe von Ntdsutil bereinigt werden (siehe Abbildung 15.4). Das Verzeichnis kann nach 

der Installation bereinigt werden, wenn für den neuen Domänencontroller ein anderer Namen gewählt 

wird. 


Verwenden von Ntdsutil 

So bereinigen Sie das Verzeichnis von einem ausgefallenen Domänencontroller: 

1. Öffnen Sie eine Eingabeaufforderung. 

2. Geben Sie ntdsutil ein, und drücken Sie die EINGABETASTE. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl metadata cleanup ein, und drücken 


4. Geben Sie an der Metadata Cleanup-Eingabeaufforderung den Befehl connections ein, und drücken 

Sie die EINGABETASTE. Über diesen Befehl wird die Verbindung mit einem aktuellen 

Domänencontroller hergestellt, um Änderungen an Active Directory vorzunehmen.


5. Geben Sie an der Server Connections-Eingabeaufforderung den Befehl connect to server Servername 

ein, wobei Servername für den Namen eines verfügbaren Domänencontrollers steht, und 

drücken Sie anschließend die EINGABETASTE. Wenn Sie als Benutzer mit Administratorrechten 

an Active Directory angemeldet sind, wird eine Verbindung mit diesem Domänencontroller 

hergestellt. Falls Sie keine Administratorrechte besitzen, können Sie über den Befehl set creds 

Domäne Benutzername Kennwort die Anmeldeinformationen eines Benutzers mit Berechtigungen 

auf Domänenebene eingeben. 

6. Geben Sie an der Server Connections-Eingabeaufforderung den Befehl quit ein, und drücken Sie 

die EINGABETASTE. Auf diese Weise gelangen Sie zurück zur Metadata Cleanup-Eingabeaufforderung. 

7. Geben Sie an der Metadata Cleanup-Eingabeaufforderung den Befehl select operation target ein, 

und drücken Sie die EINGABETASTE. Über diesen Befehl werden die Domäne, der Standort und 

der Domänencontroller ausgewählt, sodass der Domänencontroller entfernt werden kann. 

8. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl list domains ein, und 

drücken Sie die EINGABETASTE. Alle Domänen in der Gesamtstruktur werden mit der jeweils 

zugewiesenen Nummer aufgelistet. 

9. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl select domainNummer 

ein, wobei Nummer für die Domäne mit dem ausgefallenen Domänencontroller steht, und 

drücken Sie die EINGABETASTE. 

10. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl list sites ein, und drücken 

Sie die EINGABETASTE. Alle Standorte in der Gesamtstruktur werden mit der jeweils 

zugewiesenen Nummer aufgelistet. 

11. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl select site Nummer 

ein, wobei Nummer für den Standort mit dem ausgefallenen Domänencontroller steht, und drücken 


12. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl list servers in site 

ein, und drücken Sie die EINGABETASTE. 

13. Geben Sie an der Select Operations Target-Eingabeaufforderung den Befehl select server Nummer 

ein, wobei Nummer für den ausgefallenen Domänencontroller steht, und drücken Sie die 

EINGABETASTE. 

14. Geben Sie quit ein, und drücken Sie die EINGABETASTE. Auf diese Weise gelangen Sie zurück 

zur Metadata Cleanup-Eingabeaufforderung. 

15. Geben Sie remove selected server ein, und drücken Sie die EINGABETASTE. 

16. Klicken Sie auf Ja, um das Entfernen des Servers zu bestätigen. 

17. Geben Sie an jeder Eingabeaufforderung quit ein, um Ntdsutil zu beenden. 

Hinweis Dieses Verfahren mit Ntdsutil wird ebenfalls verwendet, wenn das Entfernen von Active Directory 

von einem Server über den Befehl Dcpromo /forceremoval erzwungen wurde. Durch diesen Befehl wird ein 

Domänencontroller ohne Bereinigung der Active Directory-Metadaten herabgestuft. Wird Active Directory 

aus einem unbestimmten Grund unbrauchbar, stellt dieser Befehl eine Alternative zur vollständigen Neuerstellung 

eines Servers dar.


Mithilfe von Ntdsutil sollte nicht nur das Verzeichnisobjekt, sondern auch die DNS-Einträge für den 

ausgefallenen Domänencontroller bereinigt werden. Hierzu müssen alle DNS-Einträge, einschließlich 

aller Einträge des Domänencontrollers, globalen Katalogservers und primären Domänencontrollers, 

aus DNS entfernt werden. (Die letzten beiden sind nur dann vorhanden, wenn der Domänencontroller 

mit diesen Rollen konfiguriert wurde.) Werden die DNS-Einträge nicht bereinigt, erhalten Clients 

auch weiterhin die DNS-Informationen und versuchen, eine Verbindung mit dem Domänencontroller 

herzustellen. Da es den Clients nicht möglich ist, andere Domänencontroller zu verwenden, kann dies 

zu langsameren Verbindungen zu Active Directory führen. 

Einige Active Directory-Bereinigungsaufgaben, die in früheren Versionen manuell ausgeführt werden 

mussten, werden von der in Windows Server 2008 und Windows Server 2003 SP1enthaltenen 

Ntdsutil-Version automatisch ausgeführt: 

• Entfernen des NTDSA- oder NTDS-Einstellungsobjekts 

• Entfernen von Objekten für eingehende AD-Verbindungen für die Replikation 

• Entfernen des Computerkontos 

• Entfernen des vom Dateireplikationsdienst (File Replication Service, FRS) verwendeten FRS- 

Mitgliedobjekts 

• Entfernen des vom Dateireplikationsdienst verwendeten FRS-Abonnentenobjekts 

• Übernehmen von FSMO-Rollen des ausgefallenen Domänencontrollers 

Nicht autorisierende Wiederherstellung von Active Directory 

Eine nicht autorisierende Wiederherstellung von Active Directory wird in zwei Fällen durchgeführt. 

Wenn die Active Directory-Datenbank auf einem Server beschädigt wird, kann die Datenbank anhand 

einer nicht autorisierende Wiederherstellung neu erstellt und wieder funktionstüchtig gemacht werden. 

Bei einer vollständigen Wiederherstellung eines Domänencontrollers wird ebenfalls eine nicht 

autorisierende Wiederherstellung von Active Directory durchgeführt. Eine vollständige Wiederherstellung 

eines Domänencontrollers ist beim Ausfall des einzigen Domänencontrollers in der Domäne 

erforderlich. Zudem kann eine vollständige Wiederherstellung eines Domänencontrollers durchgeführt 

werden, wenn die Identität eines ausgefallenen Domänencontrollers beibehalten werden soll. 

Wurden seit der Sicherung Änderungen in Active Directory vorgenommen, sind diese nicht auf dem 

Sicherungsband vorhanden. Die aktuellen Informationen sind jedoch auf den weiteren Domänencontrollern 

der Domäne gespeichert. Wenn der Domänencontroller aufgrund eines Serverausfalls neu 

erstellt wird, sollte dieser nach der Wiederherstellung die Änderungen von seinen Replikationspartnern 

übernehmen. Hierzu muss eine nicht autorisierende Wiederherstellung durchgeführt werden. 

Nicht autorisierende Wiederherstellung auf einem vorhandenen Server 

Für eine nicht autorisierende Wiederherstellung von Active Directory wird eine zuverlässige Sicherung 

der wichtigen Volumes auf dem Domänencontroller benötigt. Das System wird im Modus für die 

Verzeichnisdienstwiederherstellung (Directory Services Restore Mode, DSRM) gestartet (siehe 

Abbildung 15.5), der Systemstatus aus den wichtigen Volumes wird über Wbadmin.exe wiederhergestellt, 

und anschließend wird Windows Server 2008 normal neu gestartet. Nach dem Neustart des 

Domänencontrollers stellt dieser eine Verbindung zu seinen Replikationspartnern her, um die eigene 

Datenbank mit den seit der Sicherung geänderten Domäneninformationen zu aktualisieren.



Das Menü Erweiterte Startoptionen mit DSRM 

Der DSRM ist eine Version des abgesicherten Modus für Domänencontroller, bei dem Active Directory 

angehalten wird. Dieser Modus wird für die Wiederherstellung von Active Directory benötigt. 

Die Anmeldung am DSRM ist nur über ein DSRM-Administratorkonto möglich, bei dem es sich um 

ein lokales Administratorkonto handelt, das während der Active Directory-Installation auf dem 

Domänencontroller erstellt wurde. Das bei der Installation festgelegte Kennwort ist mit dem Kennwort 

des Domänenadministrators nicht identisch. 

Hinweis Unter Windows Server 2003 und Windows Server 2008 wird Ntdsutil verwendet, um das Kennwort 

des DSRM-Administratorkontos zurückzusetzen. Verwenden Sie im Set Dsrm Password-Kontext den 

Befehl reset password of server Server, wobei Server für den Namen des Domänencontrollers steht, auf 

dem das Kennwort des DSRM-Administratorkontos zurückgesetzt werden soll. Der lokale Server kann durch 

den Wert null dargestellt werden. 

So führen Sie eine nicht autorisierende Wiederherstellung von Active Directory durch: 

1. Reparieren Sie den ausgefallenen Domänencontroller. Nun ist der Server, mit Ausnahme von 

Active Directory, funktionsfähig. 

2. Starten Sie den Server neu, und drücken Sie F8, um das Menü Erweiterte Startoptionen zu öffnen. 

3. Wählen Sie den Verzeichnisdienst-Wiederherstellungsmodus aus.


Hinweis Anstatt über das Menü Erweiterte Startoptionen kann die Standardstartoption auch über den 

Befehl bcdedit /set safeboot dsrepair auf den Verzeichnisdienst-Wiederherstellungsmodus gesetzt werden. 

Geben Sie nach Abschluss der Installation den Befehl bcdedit /deletevalue safeboot ein, und führen 

Sie einen Neustart durch, um Windows normal zu starten. 

4. Melden Sie sich über das DSRM-Administratorkonto an. Geben Sie hierzu als Benutzername .\ 

Administrator ein. 


6. Geben Sie wbadmin get versions –backuptarget:Speicherort_der_Sicherung ein, wobei 

Speicherort_der_Sicherung für den Laufwerkbuchstaben oder UNC-Pfad steht, unter dem die 

Sicherung gespeichert ist, und drücken Sie die EINGABETASTE. Anschließend wird die Liste 

der dort gespeicherten Sicherungsdateien angezeigt. 

7. Notieren Sie sich die Versionskennung der wiederherzustellenden Sicherung. Bei dieser Kennung 

handelt es sich um den Zeitpunkt, an dem die Sicherung durchgeführt wurde. 

8. Geben Sie wbadmin start systemstaterecovery –version:Kennung –backuptarget: 

Speicherort_der_Sicherung ein, wobei Kennung für die in Schritt 7 notierte Versionskennung 

und Speicherort_der_Sicherung für den Laufwerkbuchstaben oder UNC-Pfad steht, unter dem die 

Sicherung gespeichert ist, und drücken Sie die EINGABETASTE. Abbildung 15.6 zeigt eine Systemstatuswiederherstellung 

über Wbadmin. 


Systemstatuswiederherstellung über Wbadmin.exe 

9. Geben Sie Y ein, und drücken Sie die EINGABETASTE, um mit der Systemstatuswiederherstellung 

zu beginnen. 

10. Starten Sie den Domänencontroller nach Abschluss der Wiederherstellung neu. 

Vollständige Serverwiederherstellung eines Domänencontrollers 

Bei der vollständigen Serverwiederherstellung eines Domänencontrollers handelt es sich ebenfalls um 

eine nicht autorisierende Wiederherstellung von Active Directory. Zusätzlich umfasst diese jedoch 

eine vollständige Wiederherstellung des Betriebssystems sowie anderen Daten.


Dies ist sinnvoll, wenn der Systemdatenträger verloren gegangen ist und das Betriebssystem nicht 

mehr funktioniert. Für eine vollständige Serverwiederherstellung eines Domänencontrollers wird eine 

vollständige Sicherung des Servers benötigt. 

In einigen Fällen kann es erforderlich sein, den Domänencontroller auf einem Server wiederherzustellen, 

der eine andere Hardware als der Ausgangsserver verwendet. Wenngleich die Wiederherstellung 

von Windows Server 2008 auch auf einer anderen Hardware als der des Servers möglich ist, auf dem 

die Sicherung durchgeführt wurde, können bei diesem Vorgang Probleme auftreten. Falls die Wiederherstellung 

von Windows Server 2008 dennoch auf einem Server mit anderer Hardware durchgeführt 

werden muss, sollte möglichst kompatible Hardware gewählt werden. Darüber hinaus müssen Sie 

sicherstellen, dass die Festplattenkonfiguration auf dem neuen Server mit der auf dem ausgefallenen 

Server übereinstimmt. 

Bei einer vollständigen Serverwiederherstellung ist das Betriebssystem des Servers nicht funktionsfähig. 

Die für eine Wiederherstellung erforderlichen Funktionen werden über die Windows-Wiederherstellungsumgebung 

bereitgestellt. Die Windows-Wiederherstellungsumgebung kann von der 

Windows Server 2008-Installations-DVD gestartet werden. Um die Windows-Wiederherstellungsumgebung 

unabhängig von der Windows Server 2008-Installations-DVD verwenden zu können, kann sie 

auf der lokalen Festplatte installiert und im Menü Erweiterte Startoptionen als Option hinzugefügt 

werden, damit diese während des Startvorgangs ausgewählt werden kann. 

So führen Sie eine vollständige Serverwiederherstellung auf einem Domänencontroller durch: 

1. Starten Sie den Computer mit eingelegter Windows Server 2008-Installations-DVD, und drücken 

Sie eine Taste, um von der DVD zu starten. 

2. Wählen Sie die entsprechenden Spracheinstellungen, Datums- und Zeitformat, Währungsformat 

und Tastaturlayout, und klicken Sie anschließend auf Weiter. 

3. Klicken Sie im Dialogfeld Windows installieren auf Computer reparieren. 

4. Laden Sie im Dialogfeld Systemwiederherstellungsoptionen ggf. erforderliche Festplattentreiber, 

und klicken Sie anschließend auf Weiter. 

5. Klicken Sie auf Windows Complete PC-Wiederherstellung (siehe Abbildung 15.7). 

Hinweis Falls keine lokale Sicherung gefunden werden kann, werden Fehlermeldungen ausgegeben. 

Dies ist normalerweise beim Wiederherstellen aus einem Netzwerkspeicherort der Fall. 


Systemwiederherstellungsoptionen in der Windows-Wiederherstellungsumgebung


6. Wählen Sie den Speicherort der Sicherung, die Sie wiederherstellen möchten. Dieser kann eine 

DVD, eine lokale Festplatte oder ein Netzwerkspeicherort sein. 

7. Aktivieren Sie das Kontrollkästchen Datenträger formatieren und neu partitionieren, um alle vorhandenen 

Daten vom Server zu löschen. 

8. Um das Löschen und Neuerstellen von Datenträgern zu verhindern, die nicht Teil der Wiederherstellung 

sind, klicken Sie auf Datenträger ausschließen, und wählen die auszuschließenden 

Datenträger aus. 

9. Klicken Sie auf Weiter und dann auf Fertig stellen. 

10. Aktivieren Sie das Kontrollkästchen Ich bestätige, dass ich die Datenträger formatieren und die 

Sicherung wiederherstellen möchte., und klicken Sie anschließend auf OK. 

Autorisierendes Wiederherstellen von Active Directory 

Eine autorisierende Wiederherstellung ist erforderlich, um gelöschte Objekte wiederherzustellen. 

Wenn ein Benutzer beispielsweise eine Organisationseinheit gelöscht hat, die mehrere Hundert Benutzer 

enthält, soll der Domänencontroller nach der Wiederherstellung nicht lediglich neu gestartet werden 

und mit der Replikation der Informationen von anderen Domänencontrollern beginnen. In diesem 

Fall würde der Domänencontroller von seinen Replikationspartnern die Information erhalten, 

dass die Organisationseinheit gelöscht wurde, und beim Öffnen des Verwaltungstools Active Directory-Benutzer 

und -Computer würde die Organisationseinheit erneut gelöscht. 

In diesem Szenario muss eine autorisierende Wiederherstellung durchgeführt werden, um sicherzustellen, 

dass die Organisationseinheit auf den weiteren Domänencontrollern wiederhergestellt wird. 

Bei einer autorisierende Wiederherstellung wird eine Sicherungskopie von Active Directory wiederhergestellt, 

die vor dem Löschen der Daten erstellt wurde. Anschließend wird eine Replikation der 

Daten auf alle anderen Domänencontroller erzwungen. Eine erzwungene Replikation lässt sich durch 

das Ändern des USN-Wertes (Update Sequence Number) der wiederhergestellten Informationen 

durchführen. Standardmäßig wird bei einer autorisierenden Wiederherstellung der USN-Wert der wiederhergestellten 

Objekte um 100.000 erhöht, sodass das wiederhergestellte Objekt zu einer autorisierenden 

Kopie für die ganze Domäne wird. 

Wiederherstellen von Computerkonten 

Eine autorisierende Wiederherstellung kann zu fehlerhaften Vertrauensstellungen zwischen Domänen 

und Computerkonten führen. Beim Hinzufügen eines Microsoft Windows NT-, Windows 2000-, 

Windows XP Professional- oder Windows Server 2003-Computers zur Domäne wird ein nur den 

Domänencontrollern und dem Mitgliedscomputer bekanntes Kennwort erstellt. Dieses Kennwort wird 

verwendet, um die Vertrauensstellung zwischen dem Computer und der Domäne zu erhalten. Dieses 

Kennwort wird jedoch standardmäßig alle 30 Tage geändert. 

Wenn Sie eine autorisierende Wiederherstellung durchführen, werden die Vertrauensstellungskennwörter 

wiederhergestellt, die zum Zeitpunkt der Sicherungserstellung gültig waren. Wenn der Mitgliedscomputer 

ein anderes Kennwort für die Vertrauensstellung verwendet, schlägt die Vertrauensstellung 

zwischen der Domäne und dem Mitgliedscomputer fehl. Für NTLM-Vertrauensstellungen 

(NT LAN Manager) zwischen Active Directory-Domänen und Windows NT-Domänen wird ein ähnliches 

Verfahren verwendet, um die Vertrauensstellung zu erhalten. Auch diese Vertrauensstellungen 

können fehlschlagen, wenn das ältere Kennwort wiederhergestellt wurde. In beiden Fällen muss die 

Vertrauensstellung neu erstellt werden. Eine Domänenvertrauensstellung kann neu erstellt werden, 

indem die Domänenvertrauensstellung gelöscht und anschließend neu erstellt wird.


Vertrauensstellungen mit der Domäne können über das Befehlszeilenprogramm NetDom oder durch 

Entfernen der Arbeitsstation aus der Domäne und erneutes Hinzufügen zur Domäne wiederhergestellt 

werden. 

Durchführen einer autorisierenden Wiederherstellung 

Die grundlegende Vorgehensweise bei einer autorisierenden Wiederherstellung von Active Directory 

entspricht der einernicht autorisierenden Wiederherstellung, mit Ausnahme eines Schrittes. Nach der 

Active Directory-Wiederherstellung im DSRM werden mithilfe von Ntdsutil die autorisierenden 

Objekte festgelegt (siehe Abbildung 15.8). Hierbei können einzelne Objekte oder eine Unterstruktur 

in der Domäne angegeben werden. 


Verwenden von Ntdsutil zur Angabe autorisierender Objekte nach einer Wiederherstellung 

Gruppenmitgliedschaften werden nach einer autorisierenden Wiederherstellung nicht ordnungsgemäß 

aktualisiert. Eine Beschreibung der Vorgehensweise finden Sie im nächsten Abschnitt, „Wiederherstellen 

von Gruppenmitgliedschaften“. Ntdsutil erstellt eine für diesen Vorgang erforderliche LDIF-Datei 

(LDAP Interchange Format). Während der autorisierenden Wiederherstellung sollte dieser Dateiname 

notiert werden. 

Die Inhalte des SYSVOL-Ordners werden beim Durchführen einer autorisierenden Wiederherstellung 

von Active Directory nicht als autorisierend gekennzeichnet. Anweisungen zum Durchführen 

einer autorisierenden Wiederherstellung von SYSVOL-Inhalten finden Sie im Abschnitt „Wiederherstellen 

von SYSVOL-Informationen“.


So führen Sie eine autorisierende Wiederherstellung durch: 

1. Reparieren Sie den ausgefallenen Domänencontroller. Der Server sollte zu diesem Zeitpunkt – mit 

Ausnahme von Active Directory – funktionsfähig sein. 

2. Starten Sie den Server neu, und drücken Sie F8, um das Menü Erweiterte Startoptionen zu öffnen. 

3. Wählen Sie den Modus für die Verzeichnisdienstwiederherstellung aus. 

4. Melden Sie sich über das DSRM-Administratorkonto an. Geben Sie hierzu als Benutzername .\ 

Administrator ein. 


6. Geben Sie wbadmin get versions –backuptarget:Speicherort_der_Sicherung ein, wobei 


Sicherung gespeichert ist, und drücken Sie die EINGABETASTE. Anschließend wird die Liste 

der gespeicherten Sicherungsdateien angezeigt. 

7. Notieren Sie sich die Versionskennung der wiederherzustellenden Sicherung. Die Kennung gibt 

an, wann die Sicherung durchgeführt wurde. 

8. Geben Sie wbadmin start systemstaterecovery –version:Kennung –backuptarget: 

Speicherort_der_Sicherung ein, wobei Kennung für die in Schritt 7 notierte Versionskennung und 


Sicherung gespeichert ist, und drücken Sie die EINGABETASTE. 

9. Geben Sie Y ein, und drücken Sie die EINGABETASTE, um mit der Systemstatuswiederherstellung 

zu beginnen. 

10. Geben Sie nach der Wiederherstellung den Befehl ntdsutil ein, und drücken Sie die 

EINGABETASTE. 

11. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl activate instance ntds ein, und 


12. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl authoritative restore ein, und 


13. Geben Sie zur Wiederherstellung eines einzelnen Objekts an der Authoritative Restore-Eingabeaufforderung 

den Befehl restore object "DN" ein, wobei DN für den definierten Namen (Distinguished 

Name, DN) des Objekts steht, das autorisierend wiederhergestellt werden soll. Bei der 

Wiederherstellung wird der Speicherort einer LDIF-Datei für die Reparatur von Backlink- 

Objekten festgelegt, falls solche Objekte wiederhergestellt werden. 

14. Geben Sie zur Wiederherstellung einer Hierarchie aus Organisationseinheiten an der Authoritative 

Restore-Eingabeaufforderung den Befehl restore subtree "DN" ein, wobei DN für den definierten 

Namen (Distinguished Name, DN) der ersten Organisationseinheit der Hierarchie steht, 

die autorisierend wiederhergestellt werden soll. Bei der Wiederherstellung wird der Speicherort 

einer LDIF-Datei für die Reparatur von Backlink-Objekten festgelegt, falls solche Objekte wiederhergestellt 

werden. 

15. Beenden Sie Ntdsutil, und starten Sie den Server neu. 

Hinweis 

Eine autorisierende Wiederherstellung der Schemapartition ist nicht möglich.


Wiederherstellen von Gruppenmitgliedschaften 

Die Wiederherstellung von Gruppenmitgliedschaften in Active Directory ist ein komplexer Vorgang. 

Dieser Vorgang wurde seit Einführung von Windows Server 2003 verbessert, dennoch müssen Sie 

weiterhin darauf achten, wo sich die Gruppenmitglieder befinden und wie die Funktionsebene der 

Gesamtstruktur beim Zuweisen der Gruppenmitglieder aufgebaut war. Um den Wiederherstellungsvorgang 

zu verstehen, müssen Sie ebenfalls wissen, wie Gruppenmitglieder verwaltet und Gruppenmitgliedschaften 


Verwaltung von Gruppenmitgliedschaften 

In Active Directory werden Gruppenmitgliedschaften durch Links zwischen dem Benutzerobjekt und 

dem Gruppenobjekt verwaltet. Diese Links werden basierend auf einem DNT (Distinguished Name 

Tag) erstellt. Das DNT ist eine lokal eindeutige Kennung für jedes Domänenobjekt auf einem Domänencontroller. 

Da es sich um eine lokale Kennung handelt, ist das DNT für das jeweilige Objekte auf 

jedem Domänencontroller unterschiedlich. 

Die Mitgliederliste eines Gruppenobjekts umfasst die DNTs für Mitglieder der Gruppe. Da die Links 

anfangs auf dem Gruppenobjekt erstellt wurden, werden diese als Forwardlinks bezeichnet. Um auf 

die Gruppe zu verweisen, wird auf dem Benutzerobjekt ein Backlink erstellt. Backlinks werden von 

Active Directory verwaltet und können von Administratoren nicht geändert werden. Darüber hinaus 

werden Backlinks, im Gegensatz zu Forwardlinks, nicht repliziert. Jeder Domänencontroller verfügt 

über einen eigenen Satz an auf den Forwardlinks basierenden Backlinks. 

Enthält eine Gruppenmitgliederliste ein Mitglied, das nicht zur lokalen Domäne gehört, wird in der 

lokalen Kopie von Active Directory ein Phantomobjekt erstellt. Das Phantomobjekt umfasst die Gruppenmitgliedsattribute 

objectGUID, SID und DN. Dieses Objekt ermöglicht die DNT-Erstellung. Das 

DN-Attribut des Phantomobjekts wird in regelmäßigen Abständen von der FSMO-Rolle Infrastrukturmaster 

in der Domäne aktualisiert. Das Phantomobjekt wird nicht auf Domänencontrollern erstellt, 

bei denen es sich um globale Kataloge handelt, die bereits über Kopien des ursprünglichen Mitgliedobjekts 

verfügen. 

Weitere Informationen Weitere Informationen zu Links und Phantomobjekten finden Sie im Artikel „Notfallwiederherstellung: 

Active Directory-Benutzer und -Gruppen“ auf der Technet Magazine-Website unter 

http://www.microsoft.com/technet/technetmag/issues/2007/04/ADRecovery/. 

Replikation verknüpfter Werte 

Unter Windows Server 2003 wurde die Replikation verknüpfter Werte (Linked Value Replication, 

LVR) für mehrwertige Attribute eingeführt, die nach dem Heraufstufen der Gesamtstrukturfunktionsebene 

auf Windows Server 2003 oder Windows Server 2003-interim verwendet werden kann. Die 

Replikation verknüpfter Werte ermöglicht das Replizieren einzelner Änderungen an Gruppenmitgliedschaften 

anstelle der gesamten Gruppenmitgliederliste. Auf diese Weise wird der Datenverkehr bei 

der Replikation verringert, und es werden zusätzliche Metadaten gespeichert, welche die Wiederherstellung 

von Gruppenmitgliedschaften vereinfachen. 

Wenn die Gesamstrukturfunktionsebene zur LVR-Unterstützung angehoben wird, werden die Mitgliedschaften 

vorhandener Gruppen für die Replikation verknüpfter Werte nicht automatisch aktualisiert. 

Bei der Replikation verknüpfter Werte werden nur Änderungen an Gruppenmitgliedschaften 

aktualisiert. Beispielsweise wird ein neues Gruppenmitglied über die Replikation verknüpfter Werte 

gespeichert, wohingegen bestehende Mitglieder nicht gespeichert werden.


Bei der autorisierende Wiederherstellung eines Benutzers verwenden die Ntdsutil-Versionen in Windows 

Server 2003 SP1 und Windows Server 2008 das Backlink-Attribut des wiederhergestellten 

Benutzerobjekts, um die Mitgliedschaft in Gruppen zu aktualisieren, die nach Aktivierung der Replikation 

verknüpfter Werte erstellt wurden. Wenn die Mitgliedschaft des wiederhergestellten Benutzers 

ohne Aktivierung der Replikation verknüpfter Werte gespeichert wurde, wird die Gruppenmitgliedschaft 

nicht automatisch durch Ntdsutil aktualisiert. Stattdessen erstellt Ntdsutil eine Textdatei mit 

einer Liste der wiederhergestellten Backlink-Objekte sowie eine LDIF-Datei, die zur entsprechenden 

Aktualisierung der lokalen Domäne für diese Backlink-Objekte verwendet werden kann. Vor Windows 

Server 2003 SP1 waren noch keine Ntdsutil-Funktionen zum Speichern von Backlink-Objekten 

verfügbar. 

Wichtig Beim Durchführen einer autorisierenden Wiederherstellung auf einem globalen Katalogserver werden 

mehrere LDIF-Dateien erstellt. Dabei wird eine LDIF-Datei für die domänenlokale Gruppe und eine weitere 

für jede Domäne erstellt, in der der Benutzer Mitglied einer universellen Gruppe war. 

Wiederherstellen von Gruppenmitgliedschaften aus Backlinks 

Nach einer autorisierenden Wiederherstellung kann die Gruppenmitgliedschaft für Benutzer wiederhergestellt 

werden, die bereits vor Aktivierung der Replikation verknüpfter Werte Mitglieder in Gruppen 

waren. Hierzu werden die durch Ntdsutil erstellten LDIF-Dateien verwendet. Dieser Vorgang 

wird erst im Anschluss an die Replikation der autorisierenden Wiederherstellung auf allen Replikationspartnern 

durchgeführt. Dabei werden nicht nur die mit der Gruppenmitgliedschaft verknüpften, 

sondern alle Backlinks wiederhergestellt. 

Hinweis Bei diesem Vorgang werden keine Backlinks für domänenlokale Gruppen in anderen Domänen 

wiederhergestellt. Gruppen in der lokalen Domäne und universelle Gruppen werden repariert. 

Führen Sie zum Wiederherstellen von Gruppenmitgliedschaften aus Backlinks die folgenden Schritte 

aus: 

1. Öffnen Sie nach einer autorisierenden Wiederherstellung und dem normalen Neustart des Domänencontrollers 

eine Eingabeaufforderung. 

2. Geben Sie an der Eingabeaufforderung den Befehl repadmin /syncall DC-Name /a /d /A /P /q 

ein, wobei DC-Name für den Namen des wiederhergestellten Domänencontrollers steht, und drücken 

Sie anschließend die EINGABETASTE. Auf diese Weise wird die Replikation auf allen 

Replikationspartnern erzwungen. 

3. Wechseln Sie zum Verzeichnis mit der LDIF-Datei, die von Ntdsutil während der autorisierenden 

Wiederherstellung erstellt wurde. 

4. Geben Sie an der Eingabeaufforderung den Befehl ldifde –i –k –f Dateiname ein, wobei 

Dateiname für die von Ntdsutil erstellte LDIF-Datei steht, und drücken Sie anschließend die 

EINGABETASTE. Wiederholen Sie diesen Schritt für alle von Ntdsutil erstellten LDIF-Dateien. 

Hinweis In Versionen vor Windows Server 2003 SP1 wurden zur Wiederherstellung von Backlinks die 

Dienstprogramme Groupadd und Ldifde verwendet.


Wiederherstellen der Mitgliedschaften domänenlokaler Gruppen in Remotedomänen 

Um Mitgliedschaften von domänenlokalen Gruppen in Remotedomänen wiederherzustellen, sind 

in jeder Remotedomäne weitere Schritte erforderlich. Dabei wird die Textdatei verwendet, die von 

Ntdsutil in der Domäne erstellt wurde, in der der Benutzer autorisierend wiederhergestellt wurde. 

Diese Textdatei enthält eine Liste der Backlink-Objekte. Anhand dieser Liste wird, speziell für diese 

Domäne, in der Remotedomäne eine LDIF-Datei generiert. Zudem ist eine nicht autorisierende Wiederherstellung 

eines Domänencontrollers in der Remotedomäne erforderlich. 

Führen Sie zum Wiederherstellen von Mitgliedschaften der domänenlokalen Gruppen in einer 

Remotedomäne die folgenden Schritte aus: 

1. Kopieren Sie die Textdatei, die von Ntdsutil in der Domäne erstellt wurde, in der die Benutzerkonten 

autorisierend wiederhergestellt wurden, auf einen Domänencontroller in einer Remotedomäne. 

2. Führen Sie auf dem Domänencontroller in der Remotedomäne eine nicht autorisierende Wiederherstellung 

durch, und starten Sie den Server neu. 

3. Öffnen Sie im DSRM eine Eingabeaufforderung. 

4. Geben Sie an der Eingabeaufforderung den Befehl ntdsutil ein, und drücken Sie die 

EINGABETASTE. 

5. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl authoritative restore ein, und 


6. Geben Sie an der Authoritative Restore-Eingabeaufforderung den Befehl create ldif file from 

Dateiname ein, wobei Dateiname für den Namen der kopierten Textdatei auf dem Domänencontroller 

in der Remotedomäne steht, und drücken Sie die EINGABETASTE. 

7. Lesen Sie die in Schritt 6 erzeugte Ausgabe, und notieren Sie den LDIF-Dateinamen. 

8. Starten Sie den Domänencontroller in der Remotedomäne neu, und starten Sie Windows normal. 

9. Öffnen Sie eine Eingabeaufforderung, und wechseln Sie zum Verzeichnis, indem sich die in 

Schritt 6 von Ntdsutil erstellte LDIF-Datei befindet. 

10. Geben Sie an der Eingabeaufforderung den Befehl ldifde –i –k –f Dateiname ein, wobei 

Dateiname für die von Ntdsutil erstellte LDIF-Datei steht, und drücken Sie anschließend die 

EINGABETASTE. Wiederholen Sie diesen Schritt für alle von Ntdsutil erstellten LDIF-Dateien. 

Wiederherstellen von Gruppen 

Beim autorisierenden Wiederherstellen von Gruppen wird die Gruppenmitgliedschaft auf den Status 

zurückgesetzt, in dem sie sich bei Erstellung der Sicherung befand. Alle seit der Sicherung vorgenommenen 

Änderungen werden durch die autorisierend wiederhergestellte Gruppenmitgliedschaft überschrieben. 

Dies kann dazu führen, dass Benutzer über andere Rechte und Berechtigungen verfügen als 

erwartet. Daher sollten die Gruppenmitgliedschaften nach einer Wiederherstellung überprüft werden. 

Bei einer gleichzeitigen autorisierenden Wiederherstellung von Benutzern und Gruppen kann es vorkommen, 

dass die Gruppenmitgliedschaft fehlerhaft ist. Die geschieht, wenn die Gruppeninformationen 

auf einem Zieldomänencontroller vor der Replikation der Benutzerinformationen wiederhergestellt 

wurden. Empfängt der Zieldomänencontroller eine Gruppe und ermittelt, dass in der Gruppe 

aufgelistete Benutzer über nicht zulässige Benutzerkonten verfügen, werden diese Benutzer aus der 

Gruppe gelöscht. Bei der anschließenden Replikation des Benutzerkontos auf den Zieldomänencontroller 

wird dieses nicht wieder zur Gruppe hinzugefügt.


Erfolgt die Replikation der Benutzerinformationen vor der Replikation der Gruppeninformationen, werden 

die Gruppenmitgliedschaften ordnungsgemäß zugewiesen. Leider kann nicht gesteuert werden, 

welche Objekte zuerst repliziert werden. 

Um eine ordnungsgemäße Gruppenmitgliedschaft sicherzustellen, sollten zwei autorisierende Wiederherstellungen 

durchgeführt werden. Die erste autorisierende Wiederherstellung gewährleistet, dass alle 

Benutzer- und Gruppenobjekte vorhanden sind. Nach der Replikation der ersten Wiederherstellung ist 

eine zweite autorisierende Wiederherstellung der Gruppenobjekte erforderlich, bei der die ordnungsgemäße 

Gruppenmitgliedschaft sichergestellt wird. 

Weitere Informationen Weitere Informationen zum Wiederherstellen von Benutzern und Gruppen finden 

Sie im Microsoft Knowledge Base-Artikel „Wiederherstellen gelöschter Benutzerkonten und ihrer Gruppenmitgliedschaften 

in Active Directory“ unter http://support.microsoft.com/kb/840001/. 

Wiederbeleben von Tombstone-Objekten 

Das Wiederbeleben eines Tombstone-Objekts ermöglicht die Wiederherstellung eines Active Directory-Objekts, 

ohne dass dieses über eine Sicherung wiederhergestellt werden muss. Auf diese Weise 

muss der Domänencontroller nicht offline geschaltet werden. Beim Erstellen eines Tombstone- 

Objekts werden jedoch Attribute entfernt. Folglich verfügt ein wiederbelebtes Tombstone-Objekt 

nicht über alle Attribute, die in einem autorisierend wiederhergestellten Objekt vorhanden wären. Beispielsweise 

werden beim Löschen eines Benutzerobjekts verschiedene Attribute wie z.B. Adressinformationen 

entfernt. Diese Informationen werden durch das Wiederbeleben eines Tombstone-Benutzerobjekts 

nicht wiederhergestellt. 

Beim Wiederbeleben eines Benutzerobjekts bleibt eine Vielzahl an wichtigen Attributen erhalten. Die 

Beibehaltung des objectSID-Attributs bietet die Möglichkeit, alle dem Benutzer direkt zugewiesenen 

Berechtigungen beizubehalten. Dies ist ein entscheidender Vorteil gegenüber der Neuerstellung eines 

gelöschten Benutzerkontos. Zudem wird das objectGUID-Attribut beibehalten, das jedes Active 

Directory-Objekt eindeutig identifiziert. Dieses Attribut wird zum Erhalten der Beziehungen zwischen 

Objekten und für Anwendungen benötigt, die dieses Attribut verwenden. 

Die in Tombstone-Objekten beibehaltenen Attribute lassen sich durch Änderungen am Schema festlegen. 

Für jedes zu speichernde Attribut muss das dritte Bit des searchFlags-Attributs des entsprechendenattributeSchema-Objekts 

gesetzt werden. Verknüpfte Attribute wie Gruppenmitgliedschaften 

können jedoch nicht beibehalten werden, selbst wenn dieses Bit gesetzt wurde. 

Wichtig Bei der Wiederbelebung eines Tombstone-Benutzerobjekts werden keine Gruppenmitgliedschaften 

wiederhergestellt. Zum Wiederherstellen von Gruppenmitgliedschaften muss eine andere Methode verwendet 

werden. Wenn Gruppenmitgliedschaften in der Organisation dokumentiert wurden, können diese manuell neu 


Der Wiederbelebungsvorgang 

An einem wiederbelebten Tombstone-Objekt müssen verschiedene Änderungen vorgenommen werden. 

Zunächst muss das idDeleted-Attribut entfernt werden. Anschließend muss das distinguishedName- 

Attribut geändert werden, über das das Objekt an den neuen Speicherort verschoben wird. Typischerweise 

basiert der neue Speicherort des Objekts auf dem lastKnownParent-Attribut, über das das 

Objekt wieder derselben Organisationseinheit zugewiesen wird, aus der es gelöscht wurde. Das 

objectCategory-Attribut für das neue Objekt wird als spezifisches objectClass -Attribut im Tombstone-Objekt 

konfiguriert.


Zur Wiederbelebung eines Tombstone-Objekt wird ein Tool benötigt, mit dem Active Directory- 

Objekte bearbeitet werden können. Mit dem Programm Ldp.exe lassen sich sowohl Active Directory- 

Objekte bearbeiten als auch Tombstone-Objekte wiederbeleben (siehe Abbildung 15.9). Zusätzlich 

steht AdRestore zur Verfügung, das speziell zur Wiederbelebung von Objekten konzipiert ist. Mit diesem 

Tool wird die Wiederbelebung so ausgeführt, dass sich die Objekte anschließend stets an dem 

Speicherort befinden, der im lastKnownParent-Attribut festgelegt wurde. 

Hinweis AdRestore steht auf der Windows Sysinternals-Website unter 

http://www.microsoft.com/technet/sysinternals/utilities/AdRestore.mspx zum Download zur Verfügung. 


Verwenden von Ldp.exe zum Wiederbeleben eines Tombstone-Objekts 

Hinweis In älteren Versionen von Windows Server war der Download von Ldp.exe erforderlich. In Windows 

Server 2008 wird Ldp.exe zusammen mit der Rolle Active Directory-Domänendienste installiert. 

So führen Sie mit Ldp.exe die Wiederbelebung eines Tombstone-Objekts durch: 

1. Klicken Sie auf Start und Ausführen, geben Sie ldp ein, und drücken Sie die EINGABETASTE. 

2. Klicken Sie auf das Menü Remotedesktopverbindung und anschließend auf Verbinden. 

3. Geben Sie den Servernamen ein, und klicken Sie auf OK. 

4. Klicken Sie auf das Menü Remotedesktopverbindung und anschließend auf Gebunden. 

5. Aktivieren Sie die Option Bindung mit Anmeldeinformationen, und wählen Sie ein Anmeldekonto 

mit ausreichenden Rechten zur Durchführung einer Wiederbelebung. Klicken Sie 

anschließend auf OK. 

6. Klicken Sie auf das Menü Optionen und anschließend auf Steuerelemente. 

7. Wählen Sie in der Dropdownliste Vordefiniert laden die Option Return Deleted Objects, und 

klicken Sie auf OK. Dies ist erforderlich, um den Container Gelöschte Objekte anzuzeigen. 

8. Klicken Sie auf das Menü Ansicht und anschließend auf Struktur.


9. Wählen Sie in der Dropdownliste Basis-DN die Domäne aus, und klicken Sie auf OK. 

10. Erweitern Sie die Domäne, und doppelklicken Sie auf CN=Deleted Objects. Es werden alle 

gelöschten Objekte in der Domäne aufgelistet. Diese Suche können Sie auch auf z.B. Benutzerobjekte 

einschränken. 

11. Klicken Sie mit der rechten Maustaste auf das wiederzubelebende Objekt, und klicken Sie auf 

Ändern. 

12. Geben Sie im Feld Attribut den Wert isDeleted ein, klicken Sie auf Löschen und anschließend auf 

die Schaltfläche Eingabe. 

13. Geben Sie im Feld Attribut distinguishedName ein. 

14. Geben Sie im Feld Werte den neuen definierten Namen des Benutzerobjekts ein. Beispiel: 

CN=Paul West,OU=Buchhaltung,DC=Adatum,DC=com. 

15. Klicken Sie auf Ersetzen und anschließend auf Eingabe. 

16. Aktivieren Sie das Kontrollkästchen Erweitert. Diese Einstellung ist für die Bearbeitung 

gelöschter Objekte erforderlich. 

17. Klicken Sie auf Ausführen, um das Objekt zu bearbeiten. 

18. Klicken Sie auf Schließen, und schließen Sie das Ldp-Programm. 

So führen Sie mit AdRestore die Wiederbelebung eines Tombstone-Objekts durch: 


2. Geben Sie adrestore ein, und drücken Sie die EINGABETASTE. Es werden alle Objekte aufgelistet, 

die wiederhergestellt werden können. 

3. Geben Sie adrestore Text ein, wobei Text für einen Bestandteil des Objektnamens steht. Drücken 

Sie die EINGABETASTE. Dieser Befehl zur Suche nach bestimmten Objekten verwendet. 

4. Geben Sie adrestore –r Text ein, wobei Text für einen Bestandteil des Objektnamens steht. 

Drücken Sie dann die EINGABETASTE. 

5. Bei jedem von AdRestore gefundene Objekt müssen Sie angeben, ob das Objekt wiederbelebt 

werden soll. 

Weitere Informationen Weitere Informationen zum Wiederbeleben von Tombstone-Objekten finden Sie 

im Artikel „Tombstone-Wiederbelebung in Active Directory“ auf der Technet Magazine-Website unter 

http://www.microsoft.com/technet/technetmag/issues/2007/09/Tombstones/default.aspx. 

Verwenden des Active Directory-Datenbankbereitstellungstools 

Windows Server 2008 umfasst ein neues Active Directory-Datenbankbereitstellungstool 

(Dsamain.exe). Mit diesem Tool wird ein Snapshot von Active Directory angezeigt, ohne dass hierfür 

ein Domänencontroller im DSRM neu gestartet werden muss. Das Active Directory-Datenbankbereitstellungstool 

fungiert als LDAP-Server (Lightweight Directory Access Protocol), um den 

Zugriff auf den Snapshot zu ermöglichen. LDAP-Anzeigetools wie Ldp.exe und ADSI Edit werden 

zur Anzeige von Snapshotinhalten verwendet. 

Wenn Active Directory-Informationen gespeichert werden, muss möglicherweise der Inhalt mehrerer 

Sicherungen überprüft werden, um zu bestimmen, welche Sicherung am besten geeignet ist. Die 

Durchsicht mehrerer Sicherungen kann zum Beispiel erforderlich sein, um den Zeitpunkt festzustellen, 

an dem ein bestimmtes Objekt gelöscht wurde.


Unter den Vorgängerversionen von Windows Server mussten die Systemstatusdaten im DSRM wiederhergestellt 

werden, um den Inhalt einer Active Directory-Sicherung anzuzeigen. Mit Windows 

Server 2008 ist es möglich, die Active Directory-Datenbank an einem anderen Speicherort wiederherzustellen 

und den Datenbankinhalt mit dem Active Directory-Datenbankbereitstellungstool anzuzeigen. 

Darüber hinaus lassen sich mit Ntdsutil Snapshots von Active Directory erstellen und anschließend 

mit Dsamain.exe anzeigen. Ein auf diese Weise erstellter Snapshot nimmt weitaus weniger Speicherplatz 

in Anspruch als die Sicherung eines wichtigen Volumes. Zudem sind Snapshots zur Überwachung 

bearbeiteter und gelöschter Objekte hilfreich. Mit Ntdsutil erstellte Snapshots können zum 

Wiederherstellen von Active Directory-Objekten verwendet werden. Um Informationen über einen 

längeren Zeitraum zu überwachen, können Active Directory-Snapshots mithilfe einer geplanten Aufgabe 

automatisch erstellt werden. 

Verwalten von Active Directory-Snapshots 

Active Directory-Snapshots lassen sich mit Ntdsutil erstellen und verwalten. Zur Verwaltung der 

Snapshots wird der Snapshotkontext genutzt. Snapshots können auf Domänencontrollern und Active 

Directory Lightweight Directory Services-Servern erstellt werden. 

Führen Sie zum Erstellen eines Active Directory-Snapshots mit Ntdsutil die folgenden Schritte aus: 


2. Geben Sie an der Eingabeaufforderung den Befehl ntdsutil ein, und drücken Sie die 

EINGABETASTE. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl snapshot ein, und drücken Sie die 

EINGABETASTE. 

4. Geben Sie an der Snapshot-Eingabeaufforderung den Befehl activate instance ntds ein, und 


5. Geben Sie an der Snapshot-Eingabeaufforderung den Befehl create ein, und drücken Sie die EIN- 

GABETASTE. Auf diese Weise wird eine neuer Snapshot erstellt. Eine Kennung wird aufgelistet. 

Führen Sie zum Bereitstellen eines Active Directory-Snapshots mit Ntdsutil die folgenden Schritte 

aus: 


2. Geben Sie an der Eingabeaufforderung den Befehl ntdsutil ein, und drücken Sie die EINGABE- 

TASTE. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl snapshot ein, und drücken Sie die 

EINGABETASTE. 

4. Geben Sie an der Snapshot-Eingabeaufforderung den Befehl activate instance ntds ein, und 


5. Geben Sie an der Snapshot-Eingabeaufforderung den Befehl list all ein, und drücken Sie die 

EINGABETASTE. Auf diese Weise werden alle verfügbaren Snapshots angezeigt. 

6. Geben Sie an der Snapshot-Eingabeaufforderung den Befehl mount Nummer ein, wobei Nummer 

für den Snapshot steht, der mit dem Active Directory-Datenbankbereitstellungstool angezeigt 

werden soll. Drücken Sie anschließend die EINGABETASTE. 

7. Notieren Sie die für den bereitgestellten Snapshot angezeigte Update-Nummer. Diese wird zur 

Anzeige des Snapshots mit dem Active Directory-Datenbankbereitstellungstool benötigt.

Anzeigen von und Zugreifen auf Active Directory-Snapshots 


Hinweis Über den Befehl unmount Nummer command wird die Bereitstellung der Datenbank nach 

Überprüfung der Daten aufgehoben. Um einen nicht mehr benötigten Snapshot zu löschen, wird der Befehl 

delete Nummer verwendet. 

Mit dem Active Directory-Datenbankbereitstellungstool können die Active Directory-Snapshots 

angezeigt werden, die entweder mit Ntdsutil erstellt und bereitgestellt oder über die Windows Server- 

Sicherung an einem anderen Speicherort wiederhergestellt wurden. In beiden Fällen ist die Angabe 

des Pfades zu Ntds.dit sowie eine Portnummer für den LDAP-Server erforderlich. Die Portnummer 

darf nicht von anderen auf dem Server ausgeführten Diensten verwendet werden. Normalerweise ist 

Port 51389 verfügbar. 

Standardmäßig können ausschließlich Mitglieder der Gruppen Organisations-Admins und Domänen- 

Admins auf die mit dem Active Directory-Datenbankbereitstellungstool angezeigten Daten zugreifen. 

Diese Einstellung kann über den Parameter /allowNonAdminAccess überschrieben werden. 

Dsamain.exe verwendet die folgende Syntax: 

Dsamain /dbpath Pfad_zur_Datenbankdatei /ldapport Portnummer 

Beim Zugriff auf den mit dem Active Directory-Datenbankbereitstellungstool angezeigten Datenbankinhalt 

muss eine Verbindung mit dem Port hergestellt werden, auf dem das Active Directory- 

Datenbankbereitstellungstool ausgeführt wird. Dies ist in der Regel ein nicht standardmäßiger Port, 

der in Ldp.exe oder ADSI Edit beim Erstellen der Verbindung manuell eingegeben werden muss. Zur 

Anzeige der Datenbank kann auch das Snap-In Active Directory-Benutzer und -Computer verwendet 

werden, indem zu einem bestimmten Domänencontroller gewechselt und die entsprechende Portnummer 

angegeben wird (siehe Abbildung 15.10). 


Zugriff auf einen bereitgestellten Datenbanksnapshot 

Während das Active Directory-Datenbankbereitstellungstool ausgeführt wird, bleibt die Eingabeaufforderung 

geöffnet. Zum Schließen des Active Directory-Datenbankbereitstellungstool drücken Sie 

Strg+C.


Wiederherstellen von SYSVOL-Informationen 

Bisher lag der Schwerpunkt in diesem Kapitel auf der Wiederherstellung der Active Directory-Datenbank 

– der Datenbank, in der sich die Konten und Einstellungen für die Domäne oder die Gesamtstruktur 

befinden. Der SYSVOL-Ordner auf jedem Domänencontroller enthält jedoch ebenfalls wichtige 

Informationen, wie Gruppenrichtlinienvorlagen und Skripts, die von Computern oder Benutzern 

im Netzwerk verwendet werden. Deshalb kann die Wiederherstellung der SYSVOL-Informationen 

genauso entscheidend sein wie die Wiederherstellung der Active Directory-Datenbank. 

Die Wiederherstellung von Systemstatusinformationen wichtiger Volumes umfasst auch den SYS- 

VOL-Ordner. Dieser SYSVOL-Ordner wird jedoch nicht von Active Directory repliziert und wird 

bei Bedarf über einen separaten Vorgang als autorisierend festgelegt. SYSVOL kann als autorisierend 

gekennzeichnet werden, wenn beispielsweise nicht autorisierte Gruppenrichtlinienänderungen zurückgenommen 

werden müssen oder Anmeldeskripts gelöscht wurden. 

In allen Vorgängerversionen von Windows Server 2008 wird SYSVOL durch den Dateireplikationsdienst 

repliziert und in gemischten Umgebungen mit Windows Server 2008-Domänencontrollern 

verwendet. Windows Server 2008 verwendet zur SYSVOL-Replikation das verteilte Dateisystem 

(Distributed File System, DFS), wenn die Domäne die Funktionsebene Windows Server 2008 aufweist. 

Erfolgt die SYSVOL-Replikation über den Dateireplikationsdienst, wird der BurFlags-Registrierungsschlüssel 

automatisch so konfiguriert, dass die wiederhergestellten replizierten Ordner als 

autorisierend gekennzeichnet werden. Wenn die SYSVOL-Replikation über DFS durchgeführt wird, 

werden die wiederhergestellten replizierten Ordner durch die Verwendung der 

–authsysvol-Option mit Wbadmin.exe als autorisierend gekennzeichnet. Die Option –authsysvol wird 

während der nicht autorisierenden Wiederherstellung von Active Directory verwendet. In beiden Fällen 

wird nicht nur der SYSVOL-Ordner als autorisierend gekennzeichnet, sondern auch andere replizierte 

Dateien, die gleichzeitig wiederhergestellt wurden. 

Weitere Informationen Weitere Informationen zum BurFlags-Registrierungsschlüssel und zum Dateireplikationsdienst 

(FRS) finden Sie im Artikel „Verwenden des BurFlags-Registrierungsschlüssels zur erneuten 

Initialisierung der Replikatsätze des Dateireplikationsdiensts“ auf der Hilfe- und Supportwebsite von Microsoft 

unter http://support.microsoft.com/default.aspx/kb/290762. 

In einigen Fällen ist nur die Wiederherstellung bestimmter Dateien aus dem SYSVOL-Ordner erforderlich, 

z.B. ein Anmeldeskript. Hierbei wird empfohlen, nicht den gesamten SYSVOL-Ordner als 

autorisierend zu kennzeichnen, sondern nur die benötigten Dateien wiederherzustellen. Dies ist möglich, 

indem SYSVOL an einem anderen Speicherort wiederhergestellt und anschließend die erforderlichen 

Dateien in den SYSVOL-Ordner kopiert werden. In den SYSVOL-Ordner kopierte Dateien 

werden wie normale Änderungen behandelt und auf andere Domänencontroller repliziert. 

Wiederherstellen von Betriebsmaster- und globalen Katalogservern 

Die Betriebsmasterrollen müssen bei der Planung einer Notfallwiederherstellung besonders berücksichtigt 

werden. Die Betriebsmasterrollen können auf mehrere Domänencontroller verteilt sein, jede 

Rolle kann jedoch nur von jeweils einem Domänencontroller in einer Domäne oder Gesamtstruktur 

übernommen werden. Daher unterscheidet sich der Wiederherstellungsvorgang für diese Rollen von 

der Wiederherstellung der Domänencontroller, die keine dieser Rollen innehaben. Die eigentliche 

Vorgehensweise zur Wiederherstellung der Domänencontroller entspricht im Wesentlichen der eines 

beliebigen Domänencontrollers – diese muss jedoch in der Notfallwiederherstellung eingeplant werden.


Da zum Beispiel nur ein Domänencontroller eine bestimmte Rolle innehaben kann, muss die mögliche 

Betriebsdauer des Netzwerks ohne diesen Betriebsmaster ermittelt werden. In einigen Fällen treten 

selbst durch eine mehrtägige Abwesenheit des Betriebsmasters möglicherweise keine Probleme 

auf; in anderen Fällen kann ein Ausfall jedoch nahezu sofortige Auswirkungen haben. Wenn der 

Domänencontroller wiederhergestellt werden kann, bevor die Betriebsmasterrolle benötigt wird, kann 

der Domänencontroller repariert und eine nicht autorisierende Wiederherstellung des Servers durchgeführt 

werden. Bei der Wiederherstellung des Servers wird auch der Betriebsmaster wiederhergestellt. 

In einigen Situationen würde die Wiederherstellung des ausgefallenen Domänencontrollers länger 

dauern, als das Netzwerk ohne Betriebsmaster betrieben werden könnte. Oder Sie haben möglicherweise 

entschieden, den Domänencontroller nicht wiederherzustellen, sondern stattdessen einen neuen 

Domänencontroller zu erstellen und die Betriebsmasterrolle auf den neuen Domänencontroller zu 

übertragen. Wenn beide Domänencontroller online sind, stellt die Übertragung der Betriebsmasterrolle 

stellt kein Problem dar, da die Domänencontroller sicherstellen können, dass die Replikation vor 

dem Übertragen der Rolle abgeschlossen wurde. Wenn der Betriebsmaster jedoch ausgefallen ist und 

die Rolle auf einen anderen Domänencontroller verschoben werden muss, muss die Rolle übernommen 

werden. 

Platzierung der Betriebsmaster 

Da die Betriebsmasterserver im Netzwerk eine wichtige Rolle spielen, sollte deren Platzierung und 

Verwaltung sorgfältig geplant werden. Die Betriebsmaster sollten in einem regulären Sicherungsplan 

stets enthalten sein. Zudem sollten sich die Betriebsmaster sowie mindestens ein anderer 

Domänencontroller am selben Standort befinden, um sicherzustellen, dass mindestens ein anderer 

Domänencontroller dieselben Informationen wie der Betriebsmaster enthält. 

Wenn beispielsweise ein Benutzer sein oder ihr Kennwort auf einem kompatiblen Client geändert 

hat, wird diese Änderung auf dem PDC-Emulator erfasst. Diese Änderung wird anschließend innerhalb 

von 15 Sekunden durch den PDC-Emulator auf einen Replikationspartner am selben Standort 

repliziert. Befindet sich am selben Standort kein Replikationspartner, findet die Kennwortreplikation 

erst bei der nächsten geplanten Replikation zwischen Standorten statt. Wenn der Domänencontroller 

vor diesem geplanten Zeitpunkt ausfällt, ist die Replikation der Kennwortänderung zwischen 

den Standorten nicht mehr möglich. Das Risiko einer unvollständigen Replikation ist 

wesentlich geringer, wenn sich der Domänencontroller und der Betriebsmasterserver an einem 

Standort befinden. Darüber hinaus ist der Domänencontroller am Standort des Betriebsmasterservers 

am besten für die Übernahme der Betriebsmasterrolle geeignet, da er über die neuesten Informationen 

vom Betriebsmaster verfügt. Wenn sich am Standort des ausgefallenen Betriebsmasters 

mehr als ein weiterer Domänencontroller befindet, kann mithilfe des Befehls repadmin /showvector 

namingcontext ermittelt werden, welcher Domänencontroller über die aktuellen Updates vom 

ausgefallenen Domänencontroller verfügt. 

Führen Sie zum Übernehmen von Betriebsmasterrollen mit Ntdsutil die folgenden Schritte aus: 


2. Geben Sie an der Eingabeaufforderung den Befehl ntdsutil ein, und drücken Sie die EINGABE- 

TASTE. 

3. Geben Sie an der Ntdsutil-Eingabeaufforderung den Befehl roles ein, und drücken Sie die 

EINGABETASTE.


4. Geben Sie an der Fsmo Maintenance-Eingabeaufforderung den Befehl connections ein, und drücken 


5. Geben Sie an der Server Connections-Eingabeaufforderung den Befehl connect to server Servername 

ein, wobei Servername für den Namen des Servers steht, auf dem die Betriebsmasterrolle 

platziert werden soll. Drücken Sie anschließend die EINGABETASTE. 

6. Geben Sie an der Server Connection-Eingabeaufforderung den Befehl quit ein, und drücken Sie 

die EINGABETASTE. 

7. Geben Sie an der Fsmo Maintenance-Eingabeaufforderung den Befehl seize Rolle ein, wobei 

Rolle für die zu übernehmende Betriebsmasterrolle steht, und drücken Sie die EINGABETASTE. 

Die zulässigen Werte für Rolle sind schema master, domain naming master, infrastructure master, 

RID master, and PDC. 

8. Akzeptieren Sie die Warnung. Der Server versucht zunächst, eine normale Übertragung der angegebenen 

Betriebsmasterrolle durchzuführen. Sollte dieser Vorgang fehlschlagen, da keine Verbindung 

mit dem Domänencontroller hergestellt werden kann, wird die Rolle übernommen. 

9. Verwenden Sie den Befehl quit, um Ntdsutil zu beenden. 

Hinweis Zum Übernehmen der Betriebsmasterrollen PDC-Emulator und Infrastrukturmaster kann auch 

das Snap-In Active Directory-Benutzer und -Computer verwendet werden. 

PDC-Emulator 

Bei einem Ausfall des PDC-Emulators können Benutzer nahezu sofort betroffen sein. Aus diesem 

Grund sollte die Rolle des PDC-Emulators schnell übernommen werden, wenn diese voraussichtlich 

für einen bestimmten Zeitraum nicht verfügbar ist. Ist der PDC-Emulator nicht verfügbar, können die 

Windows NT 4.0-Reservedomänencontroller keine Synchronisierung von Verzeichnisänderungen und 

Prä-Windows 2000-Clients keine Kennwortänderungen durchführen. Der PDC-Emulator ist zudem 

der bevorzugte Speicherort für Gruppenrichtlinienänderungen und wird für die Replikation von Kennwortänderungen 

verwendet. 

Das Übernehmen des PDC-Emulators hat keine negativen Auswirkungen. Wenn Sie den ursprünglichen 

PDC-Emulator und dessen Verbindung zum Netzwerk wiederherstellen, erkennt dieser den 

neuen PDC-Emulator gibt die Rolle als PDC-Emulator auf. Nach der Wiederherstellung kann die 

Rolle des PDC-Emulators wieder auf den ursprünglichen Server zurückübertragen werden, dies ist 

jedoch nicht erforderlich. 

Schemamaster 

Der Schemamaster spielt in einer Windows Server 2008-Domäne eine entscheidende Rolle, wenngleich 

er nur selten verwendet wird. Der Schemamaster ist der einzige Domänencontroller, auf dem 

das Schema geändert werden kann. Bei einem Ausfall dieses Servers können Änderungen am Schema 

erst wieder vorgenommen werden, wenn der Server wiederhergestellt oder die Rolle von einem anderen 

Domänencontroller übernommen wurde. 

Auf Benutzer hat der Ausfall eines Schemamasters keine Auswirkungen. In den meisten Fällen ist es 

sinnvoll, nicht die Schemamasterrolle zu übernehmen, sondern zu warten und den Schemamaster wiederherzustellen. 

Wenn die Schemamasterrolle von einem anderen Domänencontroller übernommen 

wird, sollte der ursprüngliche Schemamaster nicht mehr im Netzwerk wiederhergestellt werden.



Der Domänennamenmaster ist eine weitere, selten verwendete Rolle. Dieser Betriebsmaster wird nur 

zum Hinzufügen oder Entfernen von Domänen benötigt. Auf Benutzer hat der Ausfall dieser Rolle 

keine Auswirkungen. Administratoren sind nur betroffen, wenn eine neue Domäne zur Gesamtstruktur 

hinzugefügt oder eine alte Domäne aus dieser entfernt wird. 

In den meisten Fällen ist es sinnvoll, zu warten, bis der ursprüngliche Domänennamenmaster wiederhergestellt 

ist. Die Rolle kann jedoch auch übernommen werden, wenn das Hinzufügen oder Entfernen 

einer Domäne erforderlich und für die Wiederherstellung des Domänennamenmasters keine Zeit 

ist. Wenn die Rolle des Domänennamenmasters von einem anderen Domänencontroller übernommen 

wird, sollte der ursprüngliche Domänennamenmaster nicht mehr im Netzwerk wiederhergestellt werden. 

Infrastrukturmaster 

In Hinblick auf eine Notfallwiederherstellung hat die Infrastrukturmasterrolle wahrscheinlich die 

niedrigste Priorität. Über den Infrastrukturmaster werden Änderungen von Anzeigenamen für Benutzer- 

und Gruppenkonten in mehreren Domänen überwacht. Dies stellt nur dann ein Problem dar, wenn 

Administratoren Gruppenmitgliedschaften anzeigen möchten. Selbst Netzwerkadministratoren stellen 

den Ausfall wahrscheinlich erst dann fest, wenn eine große Anzahl an Konten verschoben oder 

umbenannt wurde. 

In den meisten Fällen ist es sinnvoll, nicht die Infrastrukturmasterrolle zu übernehmen, sondern zu 

warten und die Infrastrukturmasterrolle wiederherzustellen. Wenn die Infrastrukturmasterrolle in einer 

Umgebung mit mehreren Domänen von einem anderen Domänencontroller übernommen werden soll, 

darf der Zieldomänencontroller kein globaler Katalogserver sein. Ein auf einem globalen Katalogserver 

platzierter Infrastrukturmaster funktioniert nicht ordnungsgemäß. Wenn die Rolle übernommen wird, 

kann der ursprüngliche Infrastrukturmaster anschließend wiederhergestellt werden. 

RID-Master 

Der RID-Master (Relative ID, relative Kennungen) ist ein Betriebsmaster auf Domänenebene, der 

anderen Domänencontrollern RID-Pools zuweist, wenn neue Sicherheitsprinzipale erstellt werden. 

Wenn der RID-Master für einen längeren Zeitraum nicht verfügbar ist, stehen auf den Domänencontrollern 

möglicherweise keine RIDs mehr zur Verfügung, die neuen Sicherheitsprinzipals zugewiesen 

werden können.Sobald ein Domänencontroller keine RIDs mehr vergeben kann, ist das Erstellen 

neuer Sicherheitsprinzipale (z.B. Benutzer und Sicherheitsgruppen) nicht mehr möglich. 

Auf Benutzer hat der Ausfall eines RID-Masters keine Auswirkungen. Diese Rolle muss nur dann 

übernommen werden, wenn eine große Anzahl an Sicherheitsprinzipalen erstellt werden soll, bevor der 

ursprüngliche RID-Master wiederhergestellt wird, oder der ursprüngliche RID-Master nicht wiederhergestellt 

werden soll. Wenn die RID-Masterrolle von einem anderen Domänencontroller übernommen 

wird, sollte der ursprüngliche RID-Master nicht mehr im Netzwerk wiederhergestellt werden. 

Globale Katalogserver 

Bei globalen Katalogservern müssen abgesehen von den Anforderungen in Bezug auf Domänencontroller 

keine zusätzlichen Sicherungs- und Wiederherstellungsaspekte berücksichtigt werden. Nach 

der Wiederherstellung eines ausgefallenen Domänencontrollers, der als globaler Katalog konfiguriert 

ist, fungiert dieser weiterhin als globaler Katalogserver, ohne dass eine zusätzliche Konfiguration 

erforderlich ist.


Für einige Anwendungen und Anmeldeprozesse ist ein schneller Zugriff auf globale Katalogserver 

entscheidend. Wenn ein Standort über keinen globalen Katalogserver verfügt, führt dies zu einem Leistungsabfall 

und möglicherweise zu Fehlern. Idealerweise befinden sich an einem Standort mehrere 

globale Katalogserver. In diesem Fall verwenden Clients automatisch die verbleibenden globalen Katalogserver, 

sobald ein globaler Katalog ausfällt. Darüber hinaus können Sie nach einem Ausfall manuell 

einen weiteren Domänencontroller als globalen Katalogserver hinzufügen. 


In diesem Kapitel wurden die grundlegenden Schritte und Aspekte einer Notfallwiederherstellung in 

Windows Server 2008 Active Directory beschrieben. Die Notfallwiederherstellung ist eine der Netzwerkadministrationsaufgaben, 

die Sie hoffentlich nie benötigen werden. Dennoch kann ein solcher 

Fall eintreten, und Sie müssen als Administrator wissen, welche Maßnahmen im Notfall einzuleiten 

sind. Zu Beginn dieses Kapitels wurden zunächst die grundlegenden Datenelemente in Active Directory 

und anschließend die Vorgehensweisen bei der Sicherung von Active Directory beschrieben. Im 

verbleibenden Teil dieses Kapitels wurden die Vorgehensweisen bei der Wiederherstellung von Active 

Directory sowohl im autorisierenden als auch im nicht autorisierenden Modus erläutert. Zudem wurde 

die Wiederbelebung von Tombstone-Objekten und die SYSVOL-Wiederherstellung beschrieben. Den 

Abschluss bildeten die Verwaltung der Betriebsmasterrollen und besondere Planungsaspekte bei der 

Wiederherstellung dieser Rollen im Netzwerk. 


• Um die Größe wichtiger Volumesicherungen zu minimieren, sollten Sie auf wichtigen Volumes 

keine Anwendungs- oder Benutzerdaten speichern. 

• Führen Sie in regelmäßigen Abständen Sicherungen von wichtigen Volumes auf Domänencontrollern 

durch. Auf diese Weise können Active Directory- oder SYSVOL-Informationen wiederhergestellt 

werden. Planen Sie Sicherungen, um sicherzustellen, dass diese durchgeführt werden. 

• Verwenden Sie für Sicherungen ein bestimmtes Volume oder eine bestimmte interne oder externe 

Festplatte. 

• Installieren Sie die Windows-Wiederherstellungsumgebung auf einer separaten Partition, um die 

Wiederherstellung zu vereinfachen. Wenn die Windows-Wiederherstellungsumgebung auf dem 

lokalen Server installiert ist, benötigen Sie für eine vollständige Wiederherstellung keine CD. 

• Testen Sie Ihre Wiederherstellungsstrategie in einer Testumgebung, um vor einem Ausfall sicherzustellen, 

dass diese ordnungsgemäß funktioniert. 

• Geben Sie eine angemessene Tombstone-Ablaufzeit für die Umgebung an. Die Tombstone- 

Ablaufzeit legt die Gültigkeitsdauer einer Active Directory-Sicherung fest. 

• Implementieren Sie mehrere Domänencontroller in jeder Domäne, damit keine autorisierende 

Wiederherstellung von Active Directory durchgeführt werden muss. 

• Verwenden Sie das Active Directory-Datenbankbereitstellungswerkzeug, um den Inhalt von 

Active Directory-Sicherungen anzuzeigen, ohne eine Wiederherstellung durchführen zu müssen.






• Informationen zur Wiederherstellung einer vollständigen Active Directory-Gesamtstruktur finden 

Sie unter dem Titel „Planning for Active Directory Forest Recovery“ im Microsoft Download 

Center auf der englischsprachigen Website unter http://www.microsoft.com/downloads/ 

details.aspx?FamilyID=AFE436FA-8E8A-443A-9027-C522DEE35D85&displaylang=en. 

• Weitere Informationen zu Links und Phantomobjekten finden Sie im Artikel „Notfallwiederherstellung: 

Active Directory-Benutzer und -Gruppen“ auf der Technet Magazine-Website unter 

http://www.microsoft.com/technet/technetmag/issues/2007/04/ADRecovery/. 

• Weitere Informationen zum Wiederherstellen von Benutzern und Gruppen finden Sie im Microsoft 

Knowledge Base-Artikel „Wiederherstellen gelöschter Benutzerkonten und ihrer Gruppenmitgliedschaften 

in Active Directory“ unter http://support.microsoft.com/kb/840001/. 

• Weitere Informationen zum Wiederbeleben von Tombstone-Objekten finden Sie im Artikel 

„Tombstone-Wiederbelebung in Active Directory“ auf der Technet Magazine-Website unter 

http://www.microsoft.com/technet/technetmag/issues/2007/09/Tombstones/default.aspx 

• Weitere Informationen zum BurFlags-Registrierungsschlüssel und zum Dateireplikationsdienst 

(FRS) finden Sie im Artikel „Verwenden des BurFlags-Registrierungsschlüssels zur erneuten Initialisierung 

der Replikatsätze des Dateireplikationsdiensts“ auf der Hilfe- und Supportwebsite von 

Microsoft unter http://support.microsoft.com/default.aspx/kb/290762. 


Windows Server 2008 stellt verschiedene Tools bereit, die bei der Active Directory-Notfallwiederherstellung 

eingesetzt werden können. In Tabelle 15.2 finden Sie einige dieser Tools und ihre Einsatzmöglichkeiten. 

Tabelle 15.2 

Tools für die Active Directory-Notfallwiederherstellung 

Toolname 

Active Directory-Datenbankbereitstellungstool 

(Dsamain.exe) 

AdRestore 

ADSIEdit.msc 

Ldifde.exe 


Wird als LDAP-Server zum Bereitstellen von Active Directory-Sicherungen und -Snapshots 

verwendet. Dieses Tool kann zur Anzeige von Sicherungsinhalten ohne Durchführung einer 

Wiederherstellung verwendet werden. 

Wird zur Wiederbelebung von Tombstone-Objekten verwendet. Dieses Tool steht auf der 

Windows Sysinternals-Website unter http://www.microsoft.com/technet/sysinternals/utilities/ 

AdRestore.mspx zum Download zur Verfügung. 

Ein MMC-Snap-In (Microsoft Management Console) zur Anzeige von Active Directory. Es 

dient auch zur Anzeige der Inhalte von Active Directory-Snapshots, die mit dem Active 

Directory-Datenbankbereitstellungstool bereitgestellt werden. 

Wird zum Importieren und Exportieren von LDIF-Dateien aus Active Directory verwendet.


Tabelle 15.2 

Tools für die Active Directory-Notfallwiederherstellung (Fortsetzung) 

Toolname 

Ldp.exe 

Ntdsutil.exe 

Repadmin.exe 

Wbadmin.exe 

Windows-Wiederherstellungsumgebung 

(Windows RE) 


Ein Tool, das LDAP für den Zugriff auf Active Directory verwendet. Über dieses Tool können 

Objekteigenschaften angezeigt und geändert werden, auf die mit dem Snap-In Active Directory-Benutzer 

und -Computer nicht zugegriffen werden kann. Es dient insbesondere der 

Wiederbelebung von Tombstone-Objekten. Zudem ermöglicht Ldp.exe die Anzeige der Inhalte 

von Active Directory-Snapshots, die mit dem Active Directory-Datenbankbereitstellungstool 

bereitgestellt werden. 

Wird zur Verwaltung von Active Directory über eine Befehlszeile verwendet. Es ermöglicht 

das Kennzeichnen einer Active Directory-Wiederherstellung als autorisierend, das Entfernen 

von Active Directory-Objekten nach Domänencontrollerausfällen sowie das Übertragen 

von Betriebsmasterrollen. 

Dient der Überwachung und Verwaltung von Active Directory-Replikationen. 

Wird zur Sicherung und Wiederherstellung von Windows Server 2008 verwendet. Dieses 

Tool wird für Systemstatuswiederherstellungen benötigt und zusammen mit dem Windows 

Server-Sicherungsfeature installiert. 

Eine Wiederherstellungsumgebung für Windows Server 2008, mit deren Hilfe eine vollständige 

Wiederherstellung von Windows Server 2008 über eine Sicherung durchgeführt werden 

kann. Die Windows-Wiederherstellungsumgebung kann von der Windows Server 2008- 

Installations-DVD oder von einer lokalen Festplatte gestartet werden, wenn diese vorinstalliert 

wurde. 

Windows Server-Sicherung Ein grafisches Tool, das zur Sicherung und Wiederherstellung von Windows Server 2008 

verwendet wird. Dieses Tool ist erst nach der Installation des Windows Server-Sicherungsfeatures 

funktionsbereit.

T E I L V 

Identitäts- und Zugriffsverwaltung mit Active 



Kapitel 16: Active Directory Lightweight Directory Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611 

Kapitel 17: Active Directory-Zertifikatdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 

Kapitel 18: Active Directory-Rechteverwaltungsdienste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691 

Kapitel 19: Active Directory-Verbunddienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

611 

K A P I T E L 1 6 

Active Directory Lightweight Directory 

Services 


AD LDS – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 

AD LDS – Architektur und Komponenten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614 

Implementieren der AD LDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630 

Konfigurieren der AD DS- und AD LDS-Synchronisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 




Die Active Directory-Domänendienste (AD DS) stellen einen flexiblen und leistungsstarken Verzeichnisdienst 

dar, mit dem viele Verzeichnisdienstanforderungen von Unternehmen erfüllt werden 

können. Die AD DS weisen jedoch zahlreiche Abhängigkeiten auf, wodurch ihre Bereitstellung und 

Verwaltung zu einer komplexen Aufgabe wird. Da die AD DS die zentralen Authentifizierungs- und 

Autorisierungsdienste für die meisten Unternehmen bereitstellen, können Änderungen, z.B. am 

Schema des Verzeichnisses, sehr schwierig werden. Zugleich führen viele Unternehmen Anwendungen 

ein, die einen externen Verzeichnisdienst nutzen. Diese Anwendungen machen es ggf. erforderlich, 

dass der Verzeichnisdienst Authentifizierungsdienste bereitstellt oder Anwendungskonfigurationsinformationen 

speichert. 

Obwohl die AD DS zur Unterstützung dieser Anwendung konfiguriert werden können, ist dies nicht 

unbedingt die optimale Lösung aufgrund von Problemen hinsichtlich inkompatibler Schemaänderungen, 

des Replikationsdatenverkehrs oder der Risiken von Änderungen am Infrastrukturverzeichnis. 

Als Alternative bietet Windows Server 2008 die Serverrolle Active Directory Lightweight Directory 

Services (AD LDS), über die Sie einen LDAP–konformen (Lightweight Directory Access 

Protocol) Verzeichnisdienst bereitstellen können, um Unterstützung für diese verzeichnisfähigen 

Anwendungen zu bieten. Die AD LDS bieten nahezu dieselbe Verzeichnisdienstfunktionalität wie die 

AD DS, erfordern aber nicht die Bereitstellung von Domänen bzw. Domänencontrollern. Die AD 

LDS stellen ein wesentlich flexibleres Bereitstellungsmodell zur Verfügung, denn Sie können beispielsweise 

mehrere Instanzen der AD LDS gleichzeitig auf einem einzelnen Computer mit einem 

unabhängig verwalteten Schema für jede AD LDS-Instanz ausführen. Sie können ferner die AD LDS- 

Replikation so konfigurieren, dass dieselben AD LDS-Daten auf mehrere Computer verteilt werden.

612 Kapitel 16: Active Directory Lightweight Directory Services 

AD LDS – Übersicht 

Die AD LDS wurden speziell entwickelt, um verzeichnisfähigen Anwendungen Verzeichnisdienste 

bereitzustellen. Eine verzeichnisfähige Anwendung nutzt zum Speichern ihrer Daten ein Verzeichnis, 

anstatt (oder als Ergänzung) eine Datenbank, Flatfile oder andere Datenspeicherstruktur. Die Anwendung 

speichert ggf. Konfigurations- oder Anwendungsdaten im Verzeichnis oder nutzt das Verzeichnis 

für Authentifizierungszwecke. Die AD LDS stellen diese Funktionalität bereit. 

AD LDS – Features 

Um die von verzeichnisfähigen Anwendungen benötigten Features bereitzustellen, bieten die AD 

LDS Folgendes: 

• Dieselbe Architektur und Codebasis wie die AD DS Die AD LDS bieten einen hierarchischen Datenspeicher, 

eine Verzeichnisdienstkomponente und Schnittstellen, über die Clients mit dem Verzeichnisdienst 

kommunizieren können. Dies bedeutet, dass Entwickler und Administratoren, 

die das Arbeiten mit den AD DS gewöhnt sind, diese Kenntnisse auch bei den AD LDS nutzen 

können. 

• Unterstützung mehrerer AD LDS-Instanzen auf einem Computer Eine AD LDS-Instanz ist eine einzelne 

ausgeführte Kopie des AD LDS-Verzeichnisdienstes. Auf demselben Computer können 

mehrere Instanzen der AD LDS gleichzeitig ausgeführt werden. Jede Instanz des AD LDS-Verzeichnisdienstes 

hat einen eigenen Verzeichnisdatenspeicher, einen eindeutigen Dienstnamen, eine 

eindeutige Dienstbeschreibung und einen eindeutigen Port, damit Clients auf die jeweilige Instanz 

zugreifen können. Jede Instanz hat auch ein eigenes Schema, sodass Sie bei Bereitstellung 

mehrerer Instanzen mehrere Verzeichnisse mit unterschiedlichen Schemas auf einem einzelnen 

Server unterstützen können. 

• Unterstützung mehrerer Anwendungsverzeichnispartitionen Anwendungsverzeichnispartitionen 

enthalten die von Ihren Anwendungen verwendeten Daten. Sie können eine Anwendungsverzeichnispartition 

während des Setups der AD LDS oder zu einem beliebigen Zeitpunkt nach der 

Installation erstellen. Sie können mehrere Anwendungsverzeichnispartitionen in einer einzelnen 

Instanz speichern oder Kopien von Anwendungsverzeichnispartitionen auf mehrere Instanzen verteilen. 

• Unterstützung erweiterbarer Schemas Die AD LDS bieten mehrere Optionen für die Konfiguration 

des Schemas in den einzelnen AD LDS-Instanzen. Darüber hinaus können Sie das Schema 

jeder Instanz modifizieren, um Anforderungen von Anwendungen zu unterstützen. 

• Unterstützung der Verzeichnisreplikation Die AD LDS unterstützen die Replikation von Verzeichnisinformationen 

zwischen auf mehreren Computern installierten AD LDS-Instanzen. Auf diese 

Weise können Sie für eine hohe Verfügbarkeit sorgen oder an geografisch verteilten Standorten 

einen Zugriff auf Verzeichnisinformationen bereitstellen. 

AD LDS – Bereitstellungsszenarien 

Die AD LDS sind eher als Ergänzung zu den AD DS und nicht als Ersatz gedacht. Die AD DS stellen 

ein Netzwerkauthentifizierungs- und -verwaltungsverzeichnis zur Verfügung, während die AD LDS 

ausschließlich als Verzeichnisdienst für Anwendungen vorgesehen sind. Die AD LDS können in den 

folgenden Szenarien bereitgestellt werden:

AD LDS – Übersicht 613 

• Unternehmensverzeichnisspeicher Die AD LDS können Anwendungsdaten in einem lokalen Verzeichnisdienst 

entweder auf demselben Computer wie die Anwendung oder auf einem anderen 

Computer speichern. Ein Beispiel eines Anwendungstyps, der die AD LDS nutzen kann, ist eine 

Unternehmensanwendung, in der personalisierte Daten gespeichert werden, die mit Unternehmensbenutzern 

verknüpft sind, die auf eine Website zugreifen. Für die Speicherung dieser personalisierten 

Daten in den AD DS müsste das AD DS-Schema geändert werden. Durch Verwenden 

der AD LDS zum Speichern anwendungsspezifischer Daten und von Benutzerprinzipalnamen in 

den AD DS für die Authentifizierung und Steuerung des Zugriffs auf Objekte in den AD LDS 

können Sie die starke Zunahme von Benutzer-IDs und -kennwörtern für Endbenutzer vermeiden, 

wann immer eine neue verzeichnisfähige Anwendung in das Netzwerk eingeführt wird. 

• Authentifizierungsspeicher im Extranet Viele Unternehmen stellen Webportalanwendungen bereit, 

die einen Extranetzugriff auf Unternehmensanwendungen erfordern, jedoch einen Zugriff für 

unternehmensexterne Benutzer bereitstellen. Diese Server und Portalanwendungen benötigen 

einen Authentifizierungsspeicher zum Speichern der Authentifizierungsdaten der Benutzer. Die 

AD LDS können diesen Authentifizierungsspeicher bereitstellen, da Benutzerobjekte unterstützt 

werden können, die keine Windows-Sicherheitsprinzipale sind, jedoch mithilfe einfacher LDAP- 

Bindungen authentifiziert werden können. 

Sie können die AD LDS auch gemeinsam mit den Active Directory-Verbunddiensten (AD FS) als 

Authentifizierungsspeicher im Extranet bereitstellen. Diese Konfiguration ermöglicht Technologien 

für die einmalige Webanmeldung (Single-Sign-On, SSO) die Authentifizierung von Benutzern 

bei mehreren Webanwendungen über ein einzelnes Benutzerkonto. 

Sie können mithilfe der AD LDS auch ein Verzeichnis für verteilte Anwendungen bereitstellen, 

die einen Konfigurationsspeicher mit Multimasteraktualisierung und -replikation benötigen. 

Weitere Informationen Weitere Informationen zur Integration der AD LDS und AD FS finden Sie in 

Kapitel 19, „Active Directory-Verbunddienste“. 

• Als Teil einer Verzeichniskonsolidierungslösung In Großunternehmen sind häufig mehrere Verzeichnisse 

im Einsatz. Benutzerkonten können sich in mehreren Active Directory-Gesamtstrukturen, 

-Domänen und -Organisationseinheiten bzw. mehreren Identitätssystemen und anderen 

Verzeichnissen befinden, z.B. Personaldatenbanken, SAP-Datenbanken und Telefonbüchern. Um 

diese Vielzahl von Verzeichnissen in den Griff zu bekommen, haben viele Unternehmen die Identitäten 

durch Bereitstellung eines Metaverzeichnisses wie Microsoft Identity Integration Server 

(MIIS) oder Microsoft Identity Lifecycle Manager 2007 integriert, um die Benutzerumgebung und 

administrativen Prozesse zu vereinfachen. Die AD LDS können dahingehend mit einem Metaverzeichnis 

integriert werden, dass in den AD LDS erstellte Identitäten mit dem Metaverzeichnis 

synchronisiert werden können. Zudem können die AD LDS Anforderungen zur Identitätssynchronisierung 

vom Metaverzeichnis akzeptieren. 

• Als Entwicklungsumgebung für die AD DS und AD LDS Da die AD LDS dasselbe Programmiermodell 

wie die AD DS nutzen und praktisch dieselbe Verwaltungsumgebung wie die AD DS 

bereitstellen, können Entwickler die AD LDS für das Staging und Testen verschiedener mit 

Active Directory integrierten Anwendungen verwenden. Wenn eine in der Entwicklung befindliche 

Anwendung beispielsweise ein anderes Schema als das aktuelle AD DS-Schema benötigt, 

kann der Anwendungsentwickler mithilfe der AD LDS die Anwendung erstellen und einen Schemaaktualisierungsprozess 

testen. Nachdem die Anwendung und der Schemaaktualisierungsprozess 

sorgfältig getestet wurden, kann die Anwendung in die AD DS portiert werden.


AD LDS – Architektur und Komponenten 

Da die AD LDS nahezu denselben Code wie die AD DS nutzen, sind sich viele AD LDS- und AD 

DS-Komponenten ähnlich. 

AD LDS – Server 

Ein Server mit Windows Server 2008 mit installierter Serverrolle AD LDS wird AD LDS-Server 

genannt. Die Serverrolle AD LDS kann unter den folgenden Betriebssystemen installiert werden: 

• Windows Server 2008, Standard Edition, Enterprise Edition und Datacenter Edition 

• Windows Server 2008 Server Core Installation Option, Standard Edition, Enterprise Edition und 

Datacenter Edition 

Die AD LDS können nicht unter Windows Server 2008 Web Edition oder Windows Server 2008 für 

Itanium-basierte Systeme installiert werden. 

Jeder AD LDS-Server dient als Host des AD LDS-Datenspeichers. Tabelle 16.1 enthält Beschreibungen 

der Datenspeicherkomponenten: 

Tabelle 16.1 

Datenspeicherkomponenten 

Komponente 


Verzeichnisdienst-Agent 

(DSA) – (Adamdsa.dll) 

Beschreibung 

Clientcomputer, Administratoren und andere Server, auf denen die AD LDS ausgeführt werden, 

können nicht direkt mit dem Datenspeicher kommunizieren. Der Datenspeicher unterstützt die folgenden 

Schnittstellen für Verzeichnisclients und andere Verzeichnisserver zur Kommunikation mit 

dem Datenspeicher: 

• Lightweight Directory Access Protocol (LDAP) – LDAP v3 ist die von Verzeichnisclients am 

meisten verwendete Schnittstelle zum Auffinden von Informationen im Verzeichnisspeicher. Die 

LDAP-Schnittstelle ist Teil von Wldap32.dll. Die AD LDS unterstützen LDAP v2 („Request for 

Comments [RFC] 1777–Lightweight Directory Access Protocol“ unter http://www.ietf.org/rfc/ 

rfc1777.txt) und LDAP v3 („RFC 2251–Lightweight Directory Access Protocol v3“ unter http:// 

www.ietf.org/rfc/rfc2251.txt). Die AD LDS unterstützen sowohl LDAP- als auch SLDAP-Verbindungen 

(Secure LDAP). Für jede Instanz auf einem AD LDS-Server ist eine eindeutige Portnummer 

erforderlich. Wenn die Serverrolle AD LDS auf einem AD DS-Domänencontroller 

installiert ist, müssen sich die AD LDS-Portnummern von der AD DS-Portnummer unterscheiden. 

• REPL-Schnittstelle (Replikation) – Die REPL-Schnittstelle wird von den AD LDS während des 

Verwaltungszugriffs und zur Replikation zwischen Domänencontrollern verwendet. Auf diese 

Schnittstelle kann über RPCs (Remote Procedure Calls) zugegriffen werden. 

Der Verzeichnisdienst-Agent, der als Adamdsa.dll auf jeder AD LDS-Instanz ausgeführt wird, bietet 

die Schnittstellen, über die Verzeichnisclients und andere AD LDS-Instanzen Zugriff auf die Verzeichnisdatenbank 

erhalten. Darüber hinaus sorgt der Verzeichnisdienst-Agent für eine Erzwingung 

von Verzeichnissemantik, eine Verwaltung des Schemas, eine Sicherstellung der Objektidentität 

und die Anwendung bestimmter Datentypen auf Attribute. 

Wenn Clients oder andere AD LDS-Server auf den Verzeichnisspeicher zugreifen müssen, nutzen 

sie eine der unterstützten Schnittstellen zum Verbinden mit dem Verzeichnisdienst-Agent und zum 

anschließenden Suchen, Lesen und Schreiben von AD LDS-Objekten und ihrer Attribute.

AD LDS – Architektur und Komponenten 615 

Tabelle 16.1 

Datenspeicherkomponenten (Fortsetzung) 

Komponente 

Datenbankschicht 


Datenbankdateien 

Beschreibung 

Die Datenbankschicht befindet sich in Adamdsa.dll und stellt eine Schnittstelle zwischen dem Verzeichnisdienst-Agent 

und der Verzeichnisdatenbank bereit. Der Verzeichnisdienst-Agent und andere 

Anwendungen können sich nicht direkt mit der Datenbank verbinden, sondern werden über die 

Datenbankschicht geleitet. Die Datenbankschicht bietet auch eine Objektansicht der Verzeichnisdatenbank, 

um dem Verzeichnisdienst-Agent den Zugriff auf Daten in Form hierarchischer Container 

zu ermöglichen. 

Die Datenbankschicht ist auch für das Erstellen, Abrufen und Löschen einzelner Datensätze 

(Objekte), von Attributen in Datensätzen und von Werten in Attributen zuständig. 

Die Extensible Storage Engine (ESE) ist eine Windows-Komponente, die von den AD LDS als 

Schnittstelle zur Datenbank verwendet wird. Die ESE ist zuständig für die Indizierung der Daten in 

der Datenbankdatei und die Übertragung der Daten in die und aus der Datenbank. Ihre Aufgabe ist 

es, Anwendungen das Speichern und Abrufen von Daten zu ermöglichen. Die ESE implementiert 

auch den Transaktionsprozess für das Übernehmen von Änderungen in die Datenbank. 

Der Datenspeicher speichert Verzeichnisinformationen in der Datenbankdatei Adamntds.dit. Darüber 

hinaus verwendet der Datenspeicher auch Protokolldateien, in die Transaktionen vorübergehend 

geschrieben werden, bevor sie in die Datenbank übernommen werden. AD LDS-Daten 

werden standardmäßig in %ProgramFiles%\Microsoft ADAM\Instanzname\data installiert, wobei 

Instanzname der AD LDS-Instanzname ist, den Sie beim Erstellen der Instanz angegeben haben. 

AD LDS – Instanzen 

Bei jeder Installation von AD LDS erstellen Sie eine eindeutige AD LDS-Instanz. Jede AD LDS- 

Instanz umfasst eine Konfigurations- und Schemapartition und kann ferner eine oder mehrere Anwendungspartitionen 

enthalten. Jede AD LDS-Instanz besteht aus Folgendem: 

• Programmdateien Nach der Installation der AD LDS befinden sich die Programmdateien und 

Tools einer AD LDS-Instanz im Verzeichnis %windir%\ADAM. Wenn Sie mehrere Instanzen der 

AD LDS auf einem einzelnen Computer installieren, werden die Programmdateien und Tools im 

Verzeichnis windir\ADAM von allen AD LDS-Instanzen gemeinsam genutzt, die auf diesem 

Computer ausgeführt werden. Dies bedeutet, dass beim Aufspielen eines Updates für die AD LDS 

alle AD LDS-Instanzen betroffen sind. 

• Datendateien Die Datendateien für eine AD LDS-Instanz werden standardmäßig in den Ordner 

%ProgramFiles%\Microsoft ADAM\Instanzname\Data installiert, wobei Instanzname der AD 

LDS-Instanzname ist, den Sie bei der Installation angegeben haben. Wenn Sie mehrere AD LDS- 

Instanzen auf einem einzelnen Computer installieren, verfügt jede installierte Instanz über ein 

eigenes Datenverzeichnis. 

• Registrierungsschlüssel Registrierungsschlüssel der AD LDS haben den folgenden Speicherort: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADAM_Instanzname 

• Dienstname Während des Setups weisen Sie der AD LDS-Instanz einen Namen zu. Dieser Name 

wird bei der Erstellung der Dateiverzeichnisstruktur und Registrierungsschlüssel für die AD LDS 

verwendet. Darüber hinaus dient der zugewiesene Name zum Erstellen des Dienstnamens und 

Dienstanzeigenamens. Wenn Sie beispielsweise eine neue Instanz mit dem Name Anw1 erstellen, 

lauten der Dienstname Anw1 und der Dienstanzeigename ADAM_Anw1.


• Dienstkonto Jede AD LDS-Instanz wird als Benutzerdienst im Sicherheitskontext des Dienstkontos 

ausgeführt, das für die jeweilige Instanz angegeben ist. Das Dienstkonto für eine AD LDS- 

Instanz wird bei der Installation angegeben und darf nur mit dem Befehlszeilenprogramm 

Dsdbutit geändert werden. 

Achtung Ändern Sie das AD LDS-Dienstkonto nur mit dem Befehlszeilenprogramm Dsdbutit, da beim 

Ändern des AD LDS-Dienstkontos über das Snap-In Dienste Fehler auftreten. Einzelheiten zu den für 

die Konfiguration von Dienstkonten verfügbaren Optionen finden Sie weiter unten in diesem Kapitel im 

Abschnitt „Implementieren der AD LDS“. 

• Ereignisprotokolle Jede AD LDS-Instanz, die auf einem Computer installiert ist, schreibt Ereignisse 

in ein eindeutiges Ereignisprotokoll. Diese Ereignisse werden in der Ereignisanzeige im 

Ordner Anwendungen und Dienste unter ADAM (Instanzname) angezeigt. 

• Name:Port Damit eine verzeichnisfähige Anwendung mit einer AD LDS-Instanz kommunizieren 

kann, muss die Anwendung den NetBIOS-Namen, DNS-Namen oder die IP-Adresse des Computers 

angeben, auf dem die AD LDS ausgeführt werden. Darüber hinaus muss die Anwendung den 

LDAP- oder SSL-Kommunikationsport (Secure Sockets Layer) angeben, der von der AD LDS- 

Instanz verwendet wird. Wenn Sie mehrere Instanzen der AD LDS auf einem Computer ausführen, 

müssen Sie für jede Instanz eindeutige Portnummern angeben. 

Verzeichnispartitionen 

Jede AD LDS-Instanz nutzt einen einzelnen Verzeichnisspeicher, der in logische Verzeichnispartitionen 

bzw. Namenskontexte unterteilt ist. Jeder AD LDS-Verzeichnisspeicher muss eine einzelne Konfigurationsverzeichnis- 

und eine einzelne Schemaverzeichnispartition enthalten. Der Verzeichnisspeicher 

kann keine bzw. mehrere Verzeichnispartitionen enthalten. 

Konfigurationsverzeichnispartition 

Die Konfigurationsverzeichnispartition enthält Informationen zur AD LDS-Replikationsplanung und 

-Replikatsätzen, zur Definition der anderen Partitionen im Replikatsatz, zu den Benutzern und Gruppen 

im Replikatsatz und weitere Informationen. In Tabelle 16.2 werden die Standardcontainer in der 

Konfigurationsverzeichnispartition beschrieben. 

Tabelle 16.2 

Standardcontainer in der Konfigurationsverzeichnispartition 

Container 

CN=DirectoryUpdates, 

CN=Configuration,CN={GUID} 

CN=Extended-Rights, 


CN=ForeignSecurityPrincipals, 


CN=LostAndFoundConfig, 


Zweck 

Gegenwärtig nicht verwendet. 

Speichert Objekte der Klasse controlAccessRight, über die Anwendungen die standardmäßige 

Zugriffssteuerung erweitern können. 

Speichert Proxyobjekte für Sicherheitsprinzipale aus AD DS-Domänen. Standardmäßig 

werden diesem Container die SID des Kontos Netzwerkdienst (wenn Sie 

dieses Konto als Instanzdienstkonto verwenden) und die SID des Administrators 

hinzugefügt, der die Instanz erstellt hat. 

Speichert Objekte in der Konfigurationsverzeichnispartition, die in Containern erstellt 

werden, die gleichzeitig aus anderen AD LDS-Instanzen im selben Konfigurationssatz 

gelöscht werden.


Tabelle 16.2 

Standardcontainer in der Konfigurationsverzeichnispartition (Fortsetzung) 

Container 

CN=NTDS Quotas, 


CN=Partitions, 


CN=Roles, 


CN=Services,CN=Configuration, 

CN={GUID} 

CN=Sites,CN=Configuration, 

CN={GUID} 

Zweck 

Speichert Objekte der Klasse msDS-QuotaControl mit Kontingentzuweisungen für 

den Objektbesitz für die Konfigurationsverzeichnispartition. Kontingente begrenzen 

die Anzahl der Objekte eines Benutzers (einschließlich inetOrgPerson), einer Gruppe, 

eines Computers oder Dienstes in einer Konfigurations- oder Anwendungsverzeichnispartition. 

Speichert die Querverweise auf alle Verzeichnispartitionen im Konfigurationssatz, 

einschließlich der Konfigurationspartition, der Schemapartition und aller Anwendungspartitionen. 

Bei LDAP-Suchläufen verweisen diese Querverweise auf Verzeichnispartitionen 

auf andere mögliche Domänen. 

Speichert die Standardgruppen einer bestimmten Partition. 

Speichert Daten für verschiedene Netzwerkdienste und -anwendungen. 

Bestimmt alle Standorte im Netzwerk, die AD LDS-Instanzen an diesen Standorten 

und die Replikationstopologie. Der Inhalt dieses Containers sind Replikationstransporte, 

Subnetze sowie der erste erstellte Standort (Default-First-Site-Name) und die 

erste erstellte Standortverknüpfung (DEFAULTIPSITELINK). 

Hinweis Wenn Sie der Instanz das Schema Display Specifier hinzufügen, wird das weitere Containerobjekt 

CN=DisplaySpecifiers im Container Configuration erstellt. Dieser Container enthält die Informationen, 

die zum Anzeigen von AD LDS-Informationen in Verwaltungsprogrammen wie Active Directory-Standorte 

und -Dienste benötigt werden. 

Schemaverzeichnispartition 

Die Schemaverzeichnispartition enthält die Definitionen für die Datentypen, die in der Verzeichnisdatenbank 

enthalten sein dürfen. Die Definitionen in der Schemapartition erhalten die Datenkonsistenz 

des AD LDS-Verzeichnisdienstes. Sie können das Schema auch so erweitern, dass die AD LDS Daten 

enthalten, die für eine bestimmte Anwendung spezifisch sind. 

Wie das AD DS-Schema arbeitet das AD LDS-Schema mit Objektklassen und -attributen, um Objekttypen 

und Daten zu bestimmen, die in einem AD LDS-Verzeichnis erstellt und gespeichert werden 

können. Einer der wichtigen Unterschiede zwischen den AD DS und AD LDS ist jedoch, dass jede 

AD LDS-Instanz ein eindeutiges Schema haben kann. Das AD LDS-Basisschema enthält nur die 

Klassen und Attribute, die zum Starten einer AD LDS-Instanz benötigt werden. Da Schema kann von 

Administratoren oder den Anwendungen selbst durch neue Klassen und Attribute erweitert werden. 

Darüber hinaus können nicht benötigte Schemaklassen und -attribute deaktiviert werden. Wie bei 

allen Objekten im Verzeichnis werden Schemaobjekte durch Zugriffssteuerungslisten geschützt, 

sodass nur autorisierte Benutzer das Schema ändern können. 

Ebenso wie das AD DS-Schema kann das AD LDS-Schema manuell oder durch Importieren von 

LDF-Dateien in das Schema erweitert werden. Wenn Sie eine AD LDS-Instanz durch Ausführen des 

Active Directory-Anwendungsmodus-Setup-Assistenten erstellen, können Sie beim Erstellen der 

Instanz das Standardschema durch Importieren von LDF-Dateien ändern. In Tabelle 16.3 werden die 

optionalen LDF-Dateien für die AD LDS beschrieben.


Tabelle 16.3 

LDF-Dateien für die AD LDS 

LDF-Dateiname 

MS-adamschemaw2k3.ldf 

MS-adamschemaw2k8.ldf 

MS-AdamSyncMetadata.ldf 

MS-ADLDS-DisplaySpecifiers.ldf 

MS-User.ldf 

MS-InetOrgPerson.ldf 

MS-UserProxy.ldf 

MS-UserProxyFull.ldf 

MS-AZMan.ldf 

Beschreibung 

Dient zum Importieren des gesamten Windows Server 2003-Schemas. 

Dient zum Importieren des gesamten Windows Server 2008-Schemas. 

Dient zum Vorbereiten des AD LDS-Schemas für die Synchronisierung mit den AD 

DS mithilfe von ADAMSync. 

Dient zum Hinzufügen von Display Specifier-Einträgen zum AD LDS-Schema. Erforderlich, 

wenn Sie Snap-Ins wie Active Directory-Standorte und -Dienste zum 

Verwalten der AD LDS verwenden möchten. 

Dient zum Erstellen von Benutzerobjekten im AD LDS-Verzeichnis. 

Dient zum Erstellen von Benutzerobjekten im AD LDS-Verzeichnis der Klasse 

inetOrgPerson. 

Dient zum Erstellen von Proxyobjekten in den AD LDS für die Verwendung bei der 

Bindungsumleitung. 

Dient zum Erstellen der vollständigen Proxyobjekte in den AD LDS für die Verwendung 

bei der Bindungsumleitung. Bei Auswahl dieser Datei müssen Sie auch entweder 

MS-User.ldf oder MS-InetOrgPerson.ldf auswählen. 

Dient zum Vorbereiten der AD LDS für die Verwendung mit dem Autorisierungs- 

Manager von Windows. 

Hinweis 

Diese LDF-Dateien befinden sich im Verzeichnis %windir%\ADAM auf dem AD LDS-Server. 

Sie können diese LDF-Dateien der AD LDS-Instanz hinzufügen, wenn Sie die Instanz mit dem Setup- 

Assistenten für Active Directory Lightweight Directory Services erstellen, oder Sie können die 

Dateien nach dem Erstellen der Instanz mit dem Dienstprogramm Ldifde importieren. Führen Sie zum 

Importieren der Dateien mit dem Dienstprogramm Ldifde folgenden Befehl aus: 

Ldifde –i –u –f LDF-Dateiname –s Servername:port –b Benutzername Domäne Kennwort 

–j . –c "cn=Configuration,dc=x" #configurationNamingContext 

Dieser Befehl führt einen LDF-Dateiimport (-i) im Unicode-Format (-u) aus und erzeugt 

eine Protokolldatei (-j) im aktuellen Verzeichnis. Der Servername und die Portnummer geben die 

Instanz an, die Sie bearbeiten. Wenn Sie den Befehl in einem anderen Kontext als dem Verzeichnis 

%windir%\ADAM ausführen, müssen Sie den vollständigen Pfad zur LDF-Datei angeben. Die Benutzeranmeldeinformationen 

sind nicht erforderlich, wenn Sie den Befehl ausführen und mit einem 

Konto angemeldet sind, das die Berechtigung zum Ändern des Schemas hat. Standardmäßig verfügt 

der Administrator, der die AD LDS-Instanz installiert hat, über das einzige Konto mit dieser Berechtigungsstufe. 

Der letzte Teil des Befehls ersetzt alle Vorkommen von cn=Configuration,dc=x durch den tatsächlichen 

Konfigurationsnamenskontext der AD LDS-Instanz. Mit AD LDS können Sie die Konstanten 

#schemaNamingContext und #configurationNamingContext anstelle der definierten Namen der 

Schema- und Konfigurationsverzeichnispartition beim Austauschen von Zeichenfolgen in LDF- 

Dateien verwenden. 

Die Befehlszeilensyntax zum Importieren der LDF-Dateien ist am Anfang aller LDF-Dateien ent- 

Hinweis 

halten.


Anwendungsverzeichnispartitionen 

Anwendungsverzeichnispartitionen enthalten die von Ihren Anwendungen verwendeten Daten. Sie 

können eine Anwendungsverzeichnispartition während des Setups der AD LDS oder zu einem beliebigen 

Zeitpunkt nach der Installation erstellen. Nach Erstellen der Anwendungsverzeichnispartition 

enthalten die AD LDS in CN=Configuration,CN=Partitions die Referenzobjekte der Anwendungspartition. 

Die eigentlichen Anwendungspartitionen werden anhand der vollständig qualifizierten 

Namen bestimmt, die Sie beim Erstellen der Partition zugewiesen haben. 

Jede AD LDS-Verzeichnispartition hat einen eigenen eindeutigen definierten Namen. Im Gegensatz 

zu den AD DS, die für Verzeichnispartitionen auf oberster Ebene nur Namen im DNS-Format (DC=) 

zulassen, unterstützen die AD LDS für Verzeichnispartitionen auf oberster Ebene Namen sowohl im 

DNS- als auch X.500-Format. Tabelle 16.4 enthält die von AD LDS-Partitionen unterstützten Typen 

definierter Namen. 

Tabelle 16.4 

AD LDS-Verzeichnispartitionsnamen 

Definierter Name 

Beschreibung 

C= Land/Region 

CN= 

Allgemeiner Name (Common Name) 

DC= 

Domänenkomponente 

L= Speicherort 

O= Organisation 

OU= 

Organisationseinheit (Hinweis: Organisationseinheitscontainer können nur in den Containern 

OU, C, O und DC und nicht im Container L erstellt werden.) 

Hinweis Wenn Sie die AD LDS zum Erstellen und Testen einer Anwendung einsetzen, die in den AD DS 

bereitgestellt werden soll, verwenden Sie in Verzeichnispartitionsnamen nur DC=-Benennungskomponenten. 

Das ausschließliche Verwenden von DC=-Benennungskomponenten bewirkt, dass die Benennung des 

Verzeichnisses konsistent bleibt, wenn Sie die Anwendung von den AD LDS auf die AD DS migrieren. 

Sie können in einer einzelnen AD LDS-Instanz eine oder mehrere Anwendungsverzeichnispartitionen 

erstellen. Wenn Sie mehrere Anwendungsverzeichnispartitionen in einer Instanz erstellen, stellen 

Sie sicher, dass die Anwendungen, welche die Instanz nutzen, ein kompatibles Schema benötigen. Da 

jede Instanz nur ein Schema hat, verwenden alle Anwendungspartitionen dieses eine Schema. 

Wenngleich Sie die Daten in der Anwendungspartition mit Tools wie ADSI Edit oder Ldp.exe erstellen 

und bearbeiten können, erstellen Sie die Anwendungspartition normalerweise in der Anwendung 

selbst, in der Sie auch die Daten in einer Anwendungsverzeichnispartition verwalten. Während der 

Installation der Anwendung muss diese eine LDF-Datei zum Erstellen der Anwendungspartition und 

Konfigurieren der benötigten Einstellungen für die Partitionsobjekte bereitstellen. Die Anwendung 

kann anschließend Partitionsdaten lesen und schreiben. 

Das Objekt rootDSE in den AD LDS 

Am Stamm der AD LDS-Verzeichnisstruktur befindet sich das Objekt rootDSE, das zu keiner Verzeichnispartition 

gehört. Das Objekt rootDSE repräsentiert das obere Ende des logischen Namespace 

einer AD LDS-Instanz.


Die Attribute von rootDSE enthalten die folgenden Informationen zur AD LDS-Instanz: 

• Unterstützte LDAP-Versionen 

• Namenskontexte (Verzeichnispartitionen) auf dem Server 

• Alternative URLs für andere Server, sollte dieser Server nicht verfügbar sein 

• Unterstützte Erweiterungen, LDAP-Steuerelemente und SASL-Mechanismen (Simple Authentication 

and Security Layer) 

• Konfigurationsnamenskontext 

• Die höchste vergebene USN (Update Sequence Number) und andere Replikationsinformationen 

Zum Anzeigen des Objekts rootDSE können Sie sich über ADSI Edit mit rootDSE verbinden. Das 

in Abbildung 16.1 gezeigte Dialogfeld Eigenschaften von RootDSE wird geöffnet. 


Das Objekt rootDSE enthält Konfigurationseinstellungen für die AD LDS-Instanz. 

Auf der DVD Um alle Namenskontexte auf einem Server anzuzeigen, auf dem die AD LDS ausgeführt werden, 

verwenden Sie das Skript DisplayADLDSInstances.ps1 auf der Begleit-CD. 

AD LDS – Replikation 

Wie in den AD DS können Sie mehrere AD LDS-Server bereitstellen und die Replikation zwischen 

Instanzen konfigurieren, die auf verschiedenen Servern ausgeführt werden. Über die Replikation 

kopieren die AD LDS Änderungen von Verzeichnisdaten in einer Verzeichnispartition in einer AD 

LDS-Instanz in andere AD LDS-Instanzen, die Kopien derselben Verzeichnispartition enthalten. Auf 

diese Weise können Sie für Fehlertoleranz und einen Lastenausgleich für Verzeichnisdienste sorgen 

und Anwendungen an verschiedenen Speicherorten ermöglichen, dieselben Verzeichnisinformationen 

zu verwenden.


Bei der AD LDS-Replikation werden dieselben zugrunde liegenden Prozesse und Konzepte wie bei 

der AD DS-Replikation verwendet: 

• Multimasterreplikation Über die Multimasterreplikation können Sie Änderungen an Verzeichnisdaten 

in beliebigen AD LDS-Instanzen vornehmen. AD LDS repliziert diese Änderungen automatisch 

in andere Mitglieder des Konfigurationssatzes. 

• Behebung von Replikationskonflikten Wenn zwei Benutzer Änderungen an denselben Daten in 

Replikaten derselben Verzeichnispartition in zwei verschiedenen AD LDS-Instanzen vornehmen, 

versuchen beide AD LDS-Instanzen, die Änderungen zu replizieren, was zu einem Konflikt führt. 

Um diesen Konflikt zu beheben, verwenden Replikationspartner, die diese in Konflikt stehenden 

Änderungen empfangen, die Version und einen Zeitstempel für die Änderung. AD LDS-Instanzen 

übernehmen die Änderung mit der höheren Version und verwerfen die andere Änderung. Sind die 

Versionen identisch, übernehmen AD LDS-Instanzen die Änderung mit dem neueren Zeitstempel. 

• Standortbasierte Replikation Wie die AD DS nutzen die AD LDS Standorte zum Definieren 

der Replikationstopologie zum Replizieren von Verzeichnisaktualisierungen unter den AD LDS- 

Instanzen in einem Konfigurationssatz. Wenn Sie eine AD LDS-Instanz installieren, wird standardmäßig 

ein Standardstandort mit dem Namen Default-First-Site-Name und ein Standortconnector 

mit dem Namen DEFAULTIPSITELINK erstellt. Alle AD LDS-Replikate werden am 

Standardstandort abgelegt. Die AD LDS erhalten die Bandbreite zwischen Standorten, indem die 

Häufigkeit der Replikation minimiert wird und Sie die Verfügbarkeit von Standortverknüpfungen 

für die Replikation zeitlich planen können. Standardmäßig erfolgt die Replikation zwischen 

Standorten über die einzelnen Standortverknüpfungen alle 180 Minuten (3 Stunden). Durch das 

Erstellen weiterer Standorte können Sie den Replikationsdatenverkehr zwischen Unternehmensstandorten 

steuern, indem Sie einen Replikationszeitplan einrichten und die Häufigkeit der Replikation 

festlegen. 

• Erstellen einer Replikationstopologie Ebenso wie die AD DS nutzen AD LDS-Server die Konsistenzprüfung 

(Knowledge Consistency Checker, KCC) und die Funktion Standortübergreifende 

Topologie erstellen (Inter-Site Topology Generator, ISTG) zum Erstellen der Replikationstopologie. 

Die Konsistenzprüfung erstellt die effizienteste Replikationstopologie für die standortinterne 

Replikation mittels einer bidirektionalen Ringtopologie. Diese bidirektionale Ringtopologie versucht 

(zu Fehlertoleranzzwecken), mindestens zwei Verbindungen mit jeder AD LDS-Instanz 

und nicht mehr als drei Hops zwischen beliebigen zwei AD LDS-Instanzen (zur Verkürzung der 

Wartezeiten bei der Replikation) herzustellen. Die Funktion Standortübergreifende Topologie 

erstellen, die auf einem Domänencontroller an einem Standort ausgeführt wird, erstellt die Replikationstopologie 

zwischen Standorten. 

Hinweis Ein AD LDS-Konfigurationssatz verwaltet seine eigene Replikationstopologie, die von der ggf. 

ebenfalls vorhandenen AD DS-Replikationstopologie getrennt ist. Verzeichnispartitionen können nicht zwischen 

AD LDS-Instanzen und AD DS-Domänencontrollern repliziert werden. 

• Optimieren der standortinternen Replikation Die standortinterne Replikation wurde hinsichtlich 

Geschwindigkeit und nicht Bandbreite optimiert, da die Bandbreite innerhalb eines Standorts 

ohnehin sehr hoch sein sollte. Die standortinterne Replikation erfolgt automatisch basierend auf 

Benachrichtigungen zu Änderungen und beginnt, wenn eine Verzeichnisaktualisierung stattfindet. 

Die AD LDS-Quellinstanz wartet standardmäßig 15 Sekunden und sendet anschließend eine 

Aktualisierungsbenachrichtigung an ihren geografisch nächsten Replikationspartner. Wenn die 

AD LDS-Quellinstanz mehrere Replikationspartner hat, gehen nachfolgende Benachrichtigungen 

standardmäßig alle drei Sekunden an jeden Partner heraus.


Wenn keine Verzeichnisaktualisierungen in einem bestimmten Zeitraum vorkommen, erfolgt die 

standortinterne Replikation gemäß einem geplanten Intervall weiter. Dieses geplante Intervall ist 

standardmäßig einmal pro Stunde. 

Weitere Informationen Detaillierte Informationen zur AD DS-Replikation finden Sie in Kapitel 4, „Active 

Directory-Domänendienstreplikation“. Mit Ausnahme von Konfigurationssätzen und der Replikationssicherheit 

sind die Replikationskonzepte und -prozesse in den AD DS und AD LDS identisch. 

Konfigurationssätze 

Einer der Unterschiede zwischen der AD LDS- und AD DS-Replikation besteht beim Festlegen des 

Replikationsbereichs für eine bestimmte Partition. In den AD DS wird die Domänenpartition automatisch 

auf alle Domänencontroller in derselben Domäne repliziert, und die Konfigurations- und Schemapartitionen 

werden automatisch auf alle Domänencontroller in derselben Gesamtstruktur repliziert. 

In den AD LDS verfügen Sie wie bei benutzerdefinierten Anwendungsverzeichnispartitionen in den 

AD DS über mehr Flexibilität beim Konfigurieren des Replikationsbereichs. 

In den AD LDS basiert der Replikationsbereich auf der Beteiligung an einem Konfigurationssatz. Ein 

Konfigurationssatz ist eine Gruppe von AD LDS-Instanzen, die eine gemeinsame Schema- und Konfigurationspartition 

replizieren. Sie können auch die AD LDS-Instanzen in einem Konfigurationssatz 

so konfigurieren, dass eine oder mehrere Anwendungsverzeichnispartitionen repliziert werden. Wenn 

die AD LDS-Instanzen mehrere Anwendungspartitionen enthalten, müssen Sie dem Konfigurationssatz 

nicht alle Anwendungspartitionen hinzufügen. Sie können jedoch keine Replikation zwischen 

Anwendungsverzeichnispartitionen in verschiedenen Konfigurationssätzen konfigurieren. 

Konfigurationssatz 1 Konfigurationssatz 2 

Konfigurationspartition 




Schemapartition 




Anw1Partition 

Anw4Partition 

Anw2Partition 

Anw2Partition 

Anw3Partition 

Anw3Partition 

InstanzA 

InstanzB 

InstanzC 

InstanzD 

ADLDS-SVR1 ADLDS-SVR2 ADLDS-SVR3 


Mithilfe von Konfigurationssätzen wird der Bereich der AD LDS-Replikation festgelegt.


Da Sie mehrere AD LDS-Instanzen auf einem Server installieren können, kann ein Server an mehreren 

Konfigurationssätzen mit Replikationsverbindungen zu mehreren anderen Servern mit gemeinsam 

genutzten Konfigurationssätzen beteiligt sein. Abbildung 16.2 zeigt ein Beispiel der Funktionsweise 

von Konfigurationssätzen. 

Wenn Sie eine AD LDS-Instanz mit dem Active Directory-Anwendungsmodus-Setup-Assistent 

installieren, können Sie eine eindeutige Instanz oder ein Replikat einer vorhandenen Instanz installieren. 

Beim Installieren eines Replikats einer vorhandenen Instanz fügen Sie diese Instanz einem auf 

einem anderen Server definierten Konfigurationssatz hinzu. Sie können eine AD LDS-Instanz nur 

während der Installation der Instanz einem Konfigurationssatz hinzufügen. Nachdem eine AD LDS- 

Instanz erstellt wurde, kann Sie einem Konfigurationssatz weder hinzugefügt noch aus diesem entfernt 

werden. 

Hinweis Konfigurationssätze sind dahingehend rein konzeptuell, dass Sie einem Konfigurationssatz keinen 

Namen zuweisen müssen und keinen Konfigurationssatz erstellen können, um ihm später Instanzen 

hinzuzufügen. Zum Verwalten von Konfigurationssätzen müssen Sie die Instanzen verwalten, die den Konfigurationssatz 

bilden. 

AD LDS – Replikationssicherheit 

Ein weiterer Punkt, bei dem sich die AD LDS- von der AD DS-Replikation unterscheidet, ist die 

Absicherung der Replikationsverbindungen und des dazugehörigen Datenverkehrs. Da sämtliche AD 

DS-Domänencontroller Mitglieder derselben Gesamtstruktur sind, können Sie das Kerberos-Sicherheitsprotokoll 

zum Authentifizieren und Absichern des Replikationsdatenverkehrs nutzen. Sie können 

die Serverrolle AD LDS auf Computern bereitstellen, die Mitglied derselben Domäne oder 

Gesamtstruktur sind, die sich in verschiedenen Gesamtstrukturen befinden oder die Mitglied keiner 

Domäne sind. 

Dies bedeutet, dass die AD LDS-Server ggf. in allen Szenarien nicht dieselben Authentifizierungsund 

Sicherheitsmechanismen nutzen können. Um die Sicherheit der Replikation zu gewährleisten, 

authentifizieren die AD LDS Replikationspartner vor der Replikation, wobei die Replikationsauthentifizierung 

stets über einen sicheren Kanal erfolgt. Nach der Authentifizierung der Replikationspartner 

wird der gesamte Replikationsdatenverkehr zwischen den beiden Partnern verschlüsselt. AD 

LDS-Replikationspartner authentifizieren sich gegenseitig über das Dienstkonto, das für die jeweilige 

AD LDS-Instanz angegeben ist. Die Methode, die zur Replikationsauthentifizierung innerhalb eines 

Konfigurationssatzes verwendet wird, hängt vom Wert des Attributs msDS-ReplAuthenticationMode 

für die Konfigurationsverzeichnispartition ab. 

Tabelle 16.5 enthält die verfügbaren Optionen für das Konfigurieren der Sicherheit für die AD LDS- 

Replikation und des entsprechenden Attributwerts (msDS-ReplAuthenticationMode) des Authentifizierungsmodus 

für die jeweilige Sicherheitsstufe. Die standardmäßige Replikationssicherheitsstufe für 

eine neue, eindeutige AD LDS-Instanz ist 1, es sei denn, als AD LDS-Dienstkonto ist ein lokales 

Benutzerkonto angegeben. In diesem Fall ist die Replikationssicherheitsstufe 0.


Tabelle 16.5 

AD LDS – Replikationssicherheitsstufen 

Wert msDS-Repl 

AuthenticationMode 

AD LDS – Sicherheit 

Authentifizierungsmethode 

0 Ausgehandelter 

Durchsatz 

Beschreibung 

Alle ADAM-Instanzen im Konfigurationssatz verwenden als ADAM- 

Dienstkonto einen identischen Kontonamen mit identischem Kennwort. 

Der Konfigurationssatz kann Computer umfassen, die einer oder mehreren 

Arbeitsgruppen bzw. mehreren Domänen oder Gesamtstrukturen 

ohne Vertrauensstellungen beigetreten sind. 

1 Ausgehandelt Zuerst wird die Kerberos-Authentifizierung (mithilfe von Dienstprinzipalnamen, 

SPNs) versucht. Schlägt Kerberos fehl, wird die NTLM-Authentifizierung 

versucht. Schlägt NTLM fehl, werden die ADAM-Instanzen 

nicht repliziert. 

2 Gegenseitige Authentifizierung 

mit Kerberos 

Die Kerberos-Authentifizierung mithilfe von Dienstprinzipalnamen (Service 

Principal Names, SPNs) ist erforderlich. Schlägt die Kerberos-Authentifizierung 

fehl, werden die ADAM-Instanzen nicht repliziert. Der 

Konfigurationssatz muss vollständig in einer Active Directory-Domäne, 

-Gesamtstruktur oder -Gesamtstrukturvertrauensstellung enthalten 

sein. 

Eine der Anforderung an ein Anwendungsverzeichnis ist das Gewährleisten von Sicherheit. Anwendungen 

schreiben ggf. vertrauliche Informationen, z.B. Kundendaten, in das Verzeichnis, oder Unternehmen 

möchten Daten im Verzeichnis beschränken, die die Benutzer anzeigen oder bearbeiten können. 

Da die AD LDS auf demselben Code wie die AD DS basieren, gelten viele der Konzepte für 

Authentifizierung, Autorisierung, Benutzer, Gruppen, Zugriffssteuerungslisten und Sicherheitstoken 

für die AD DS ebenso für die AD LDS. 

Sicherheitsprinzipale in den AD LDS 

AD LDS-Sicherheitsprinzipale sind alle Objekte mit einer eindeutigen SID, denen Berechtigungen für 

Verzeichnisobjekte zugewiesen werden können. In den AD LDS sind folgende Sicherheitsprinzipale 

möglich: 

• AD LDS-Sicherheitsprinzipale, die in einer AD LDS-Verzeichnispartition erstellt werden. Ein AD 

LDS-Sicherheitsprinzipal ist ein Benutzer oder anderes Objekt mit möglichen Bindungen, das in 

den AD LDS erstellt wird. Das AD LDS-Schema enthält standardmäßig keine Benutzerobjektklassen, 

weshalb es keine AD LDS-Sicherheitsprinzipale enthalten kann. Wenn Sie die Datei msuser.ldf 

oder ms-inetorgperson.ldf dem Schema hinzufügen, können Sie andere Benutzer- oder 

inetOrgPerson-Objekte erstellen. Wenn Sie diese Objekte hinzufügen, wird ihnen automatisch 

eine SID zugewiesen. 

Hinweis In einer AD LDS-Instanz oder -Anwendungspartition werden standardmäßig keine AD LDS- 

Benutzerkonten erstellt. AD LDS-Benutzerkonten können nur in Anwendungsverzeichnispartitionen und 

nicht in Konfigurations- oder Schemapartitionen erstellt werden. Darüber hinaus können AD LDS-Benutzern 

nur Berechtigungen für Objekte in ihrer eigenen Verzeichnispartition zugewiesen werden. Diese 

Benutzer können ferner nur Mitglied der Gruppe in der Verzeichnispartition sein, in der ihr Benutzerkonto 

vorhanden ist.


• Auf einem lokalen Computer definierte Windows-Benutzer. Benutzerkonten auf dem lokalen 

Computer können Berechtigungen für AD LDS-Objekte zugewiesen werden und können AD 

LDS-Gruppen hinzugefügt werden. 

• In einer AD DS-Domäne definierte Windows-Benutzer. Benutzerkonten in der AD DS-Domäne, 

zu welcher der AD LDS-Server gehört, oder anderen vertrauenswürdigen Domänen können auch 

Berechtigungen für AD LDS-Objekte zugewiesen werden und können AD LDS-Gruppen hinzugefügt 

werden. 

Hinweis Das Windows-Konto des Administrators, der die AD LDS-Instanz installiert hat, wird der Gruppe 

Administratoren in der Partition Konfiguration hinzugefügt. Wenn Sie die AD LDS für die Verwendung eines 

Windows-Kontos als Dienstkonto einrichten, wird dieses Konto der Gruppe Instanzen im Container Konfiguration 

hinzugefügt. 

Windows-Benutzerkonten können Gruppen in mehreren Verzeichnispartitionen hinzugefügt werden, 

auch der Konfigurationsverzeichnispartition. Darüber hinaus können Windows-Benutzern Berechtigungen 

für Objekte in mehreren Partitionen zugewiesen werden. 

Hinweis Um einen AD LDS-Benutzer oder ein Windows-Benutzerkonto einer AD LDS-Gruppe hinzuzufügen, 

müssen Sie das Benutzerkonto dem Attribut multivalue member des entsprechenden Gruppenobjekts 

hinzufügen. Führen Sie diesen Schritt mit ADSI Edit aus. Weitere Informationen finden Sie im Artikel 

„Schrittweise Anleitung zu den ersten Schritten mit Active Directory Lightweight Directory Services“ unter 

http://technet2.microsoft.com/windowsserver2008/de/library/682674f4-a652-4772-8567- 

2f27417f4ec81031.mspx?mfr=true. 

Wie bei AD LDS-Benutzerkonten ist der Geltungsbereich einer AD LDS-Gruppe auf die Partition 

beschränkt, in der die Gruppe erstellt wurde. Die einzige Ausnahme dieser Regel ist die Gruppe 

Administratoren in der Konfigurationsverzeichnispartition, deren Mitglieder Vollzugriff auf alle 

Objekte in allen Partitionen haben. 

Standardgruppen in den AD LDS 

Wie die AD DS arbeiten die AD LDS mit Benutzerkonten und Gruppen, um einen Zugriff auf die 

Informationen im Verzeichnisspeicher bereitzustellen. Wenn Sie eine AD LDS-Instanz installieren 

und eine Anwendungspartition erstellen, wird standardmäßig in jeder Verzeichnispartition ein Satz 

mit Standardgruppen erstellt. Darüber hinaus können Sie benutzerdefinierte Gruppen erstellen oder 

AD DS-, lokale oder Gruppenkonten verwenden, um Berechtigungen für AD LDS-Daten zuzuweisen. 

Tabelle 16.6 enthält die in einer AD LDS-Instanz erstellten Standardgruppen. 

Tabelle 16.6 

AD LDS-Standardgruppen 

Partition Gruppe Zweck Standardmitglieder 

Konfiguration Administratoren Diese Gruppe hat Vollzugriffsberechtigungen 

für die Instanz sowie 

alle Verzeichnispartitionen in der 

Instanz. 

Konfiguration Leser Diese Gruppe hat Lesezugriff auf die 

Konfigurationspartition (einschließlich 

Schema). 

Der Administrator, der bei der Erstellung 

der Instanz zugewiesen wird. Dieses Konto 

muss ein Windows-Sicherheitsprinzipal 

(mit entweder einem AD DS- oder 

lokalem Konto) sein. 

Keine


Tabelle 16.6 

AD LDS-Standardgruppen (Fortsetzung) 

Partition Gruppe Zweck Standardmitglieder 

Konfiguration Benutzer Diese Gruppe ist eine berechnete 

Gruppe, die zum Zuweisen von 

Berechtigungen zu allen Benutzerkonten 

dient. 

Alle AD LDS-Benutzer, die in einer beliebigen 

Anwendungsverzeichnispartition 

definiert sind. 

Konfiguration Instanzen Dient zur Replikation. Das AD LDS-Serverkonto und das AD 

LDS-Dienstkonto. Der Gruppe Instanzen 

dürfen keine Benutzer hinzugefügt werden. 

Anwendung Administratoren Diese Gruppe verwaltet die Anwendungspartition, 

in der sich die 

Gruppe befindet. 

Anwendung Leser Diese Gruppe hat Lesezugriff auf die 

Anwendungspartition, in der sich die 

Gruppe befindet. 

Mitglieder der Gruppe Administratoren in 

der Konfigurationspartition. 

Anwendung Benutzer Dies ist eine berechnete Gruppe. Alle AD LDS-Benutzer in der entsprechenden 

Anwendungsverzeichnispartition. 

Mit ADSI Edit können Sie die AD LDS-Gruppen im Container CN=Roles, CN=Configuration anzeigen. 

In Anwendungspartitionen können Sie zusätzliche Gruppen erstellen. In der Konfigurationspartition 

können Sie keine zusätzliche Gruppen erstellen. 

Zuweisen von Berechtigungen in den AD LDS 

Wie die AD DS arbeiten die AD LDS mit Sicherheitsprinzipalen und Zugriffssteuerungslisten, um 

den Zugriff auf Objekte in den AD LDS zu steuern. Wenn Sie die AD LDS installieren und Instanzen 

sowie Partitionen konfigurieren, wird der Partition ein Standardsatz mit Berechtigungen zugewiesen. 

Tabelle 16.7 enthält die Standardberechtigungen, die in der gesamten Partition vererbt werden. 

Keine 

Tabelle 16.7 

Partition 

Konfiguration 

Schema 

Anwendung 

Standardberechtigungen für AD LDS-Partitionen 

Standardberechtigungen 

Administratoren: Vollzugriff 

Leser: Lesen 

Instanzen: Fünf replikationsbezogene Zugriffssteuerungseinträge (Access Control Entries, ACEs) 

Administratoren (in der Konfigurationspartition): Vollzugriff 

Leser: Fünf replikationsbezogene Zugriffssteuerungseinträge (Access Control Entries, ACEs) 

Administratoren: Vollzugriff 

Leser: Lesen 

Instanzen: Fünf replikationsbezogene Zugriffssteuerungseinträge (Access Control Entries, ACEs) 

Um die für einen AD LDS-Container konfigurierte Zugriffsteuerungsliste anzuzeigen, können Sie die 

Befehle Dsacls.exe oder Ldp.exe aufrufen. Um Berechtigungen mithilfe des Befehls Dsacls.exe anzuzeigen, 

geben Sie den folgenden Befehl ein: 

Dsacls \\Servername:Portnummer\Partitionsname /a


Um beispielsweise die Zugriffsteuerungsliste für die Partition Anw2 für eine Instanz über Port 4389 

auf dem Server SEA-SVR1 anzuzeigen, geben Sie den folgenden Befehl ein: 

Dsacls \\sea-svr1:4389\CN=Anw2,dc=Adatum,dc=com /a 

Verbinden Sie sich zum Verwenden von Ldp.exe mit der AD LDS-Instanz, und stellen Sie eine Bindung 

mit einem Konto her, das über Berechtigungen zum Anzeigen der Zugriffsteuerungsliste verfügt. 

Klicken Sie mit der rechten Maustaste auf den anzuzeigenden Container, zeigen Sie auf Erweitert, 

und klicken Sie auf Sicherheitsbeschreibung. Abbildung 16.3 zeigt die Standardberechtigungen 

für eine Anwendungspartition. 

Weitere Informationen Einzelheiten zur Konfiguration von Berechtigungen in den AD LDS finden Sie weiter 

unten in diesem Kapitel im Abschnitt „Konfigurieren der Zugriffsteuerung“. 


Ldp.exe kann zum Anzeigen von Berechtigungen in den AD LDS verwendet werden. 

In den AD LDS wird wie in den AD DS bei der Authentifizierung eines Benutzers von den AD LDS 

(oder der lokalen Sicherheitsautorität [Local Security Authority, LSA]) abhängig vom Typ des Sicherheitsprinzipals) 

ein Sicherheitszugriffstoken für den Benutzer erstellt. Ein Zugriffstoken enthält den 

Benutzernamen, die Gruppen, zu denen der Benutzer gehört, eine SID des Benutzers sowie alle SIDs 

für die Gruppen, denen der Benutzer angehört. Die Informationen im Zugriffstoken dienen zum 

Bestimmen des Zugriffsgrades des Benutzers auf Objekte, wenn der Benutzer versucht, auf diese 

zuzugreifen.


Die SIDs im Zugriffstoken werden mit der Liste der SIDs verglichen, welche die Zugriffsteuerungslisten 

für das Objekt bilden, um sicherzustellen, dass der Benutzer über ausreichende Berechtigungen 

für den Zugriff auf das Objekt verfügt. 

Weitere Informationen Detaillierte Informationen zur Erstellung des Zugriffstoken finden Sie in Kapitel 8, 

„Active Directory-Domänendienstsicherheit“. 

Authentifizierung in den AD LDS 

Wie die AD DS implementieren die AD LDS eine Authentifizierung, um die Identität von Benutzern 

sicherzustellen. Wenn ein Benutzer versucht, sich bei den AD LDS zu authentifizieren, kann der 

Benutzer abhängig vom Typ von den AD LDS, der LSA oder von Active Directory authentifiziert 

werden. Tabelle 16.8 enthält die von den AD LDS unterstützten Authentifizierungstypen, die für jede 

Authentifizierungsmethode geeigneten Benutzertypen und die Authentifizierungsautorität, welche die 

Authentifizierung abwickelt. 

Tabelle 16.8 

Authentifizierungsmethoden in den AD LDS 

Authentifizierungstyp Benutzertyp Beschreibung 

Anonym Anonym Der Benutzer muss kein Kennwort angeben, weshalb er nicht authentifiziert 

wird. Das einzige Objekt in den AD LDS, auf das ein anonymer 

Benutzer standardmäßig Zugriff hat, istrootDSE. 

Einfache LDAP- 

Bindung 

SASL-Bindung (über 

Kerberos, NTLM oder 

Aushandeln) 

Bindungsumleitung 

(einfache LDAP-Bindung 

an die AD LDS, 

anschließende SASL- 

Bindung an die AD 

DS) 

AD LDS–Sicherheitsprinzipal 

Lokaler Windows- oder AD 

DS-Sicherheitsprinzipal 

AD LDS-Proxyobjekt 

AD LDS. AD LDS-Konten haben nur Zugriff auf Daten in derselben 

Anwendungspartition, in der sich das jeweilige Benutzerkonto 

befindet. 

LSA auf dem lokalen Computer oder AD DS. Windows-Konten können 

so konfiguriert werden, dass sie Zugriff auf Daten in allen Partitionen 

der AD LDS-Instanzen haben. 

LSA und AD DS. AD LDS-Proxyobjektkonten haben nur Zugriff auf 

Daten in derselben Anwendungspartition, in der sich das Proxyobjekt 

befindet. 

Einfache LDAP-Bildung für AD LDS-Sicherheitsprinzipale Die einfache LDAP-Bindung erfolgt, wenn ein 

Benutzer als AD LDS-Sicherheitsprinzipal eine Bindung zu den AD LDS herstellt. Diese Authentifizierungsmethode 

verwendet eine einfache LDAP-Bildung. Bei der Standardauthentifizierung sind 

keine SASL-Optionen verfügbar. Diese einfache LDAP-Bildung verwendet den definierten Namen 

oder Benutzerprinzipalnamen (User Principal Name, UPN) des Sicherheitsprinzipals. Bei einer einfachen 

LDAP-Bindung wird das Benutzerkennwort unverschlüsselt gesendet. Um den Authentifizierungsdatenverkehr 

zu schützen, müssen Sie SSL zwischen den Client und den AD LDS-Server schalten. 

Um SSL zu aktivieren, müssen Zertifikate auf dem Computer installiert werden, auf dem die AD 

LDS ausgeführt werden. Darüber hinaus müssen die Clients, die sich mit den AD LDS verbinden, der 

Zertifizierungsstelle vertrauen, die dem AD LDS-Server das Zertifikat ausstellt.


Sicherheitswarnung Sie können die SSL-Anforderung bei der Standardauthentifizierung über die Option 

ds-behavior des Befehlszeilenprogramms Dsmgmt.exe deaktivieren. Dies wird für Produktionsumgebungen 

jedoch nicht empfohlen, da dadurch alle Kennwörter unverschlüsselt gesendet werden. 

Bei Verwenden der Standardauthentifizierung unterstützen und erzwingen die AD LDS die Kennwortrichtlinien- 

und Kontosperreinstellungen von Windows Server 2008. Wenn für den Computer beispielsweise 

in der lokalen Sicherheitsrichtlinie eine Kennwortrichtlinie konfiguriert ist, oder über eine 

Domänensicherheitsrichtlinie werden Kennworteinstellungen wie minimales und maximales Kennwortalter, 

Komplexität und Kennwortchronik erzwungen, wenn Benutzer ihre Kennwörter ändern. 

Hinweis Sie können die Erzwingung von Kennwortrichtlinieneinstellungen in den AD LDS deaktivieren, 

indem Sie ADAMDisablePasswordPolicies, einen Wert des Attributs msDS-Other-Settings on CN=Directory 

Service,CN=Windows NT,CN=Services,CN=Configuration,CN=GUID auf 1 festlegen. 

SASL-Bindung für Windows-Sicherheitsprinzipale Die integrierte Authentifizierung erfolgt, wenn ein 

Windows-Sicherheitsprinzipal versucht, eine Bindung zu einer AD LDS-Instanz herzustellen. Die AD 

LDS authentifizieren Windows-Benutzer nicht selbst. Stattdessen wird der Windows-Sicherheitsprozess 

zum Authentifizieren des Benutzers verwendet. Die integrierte Authentifizierung arbeitet mit 

SASL-Bindungen und unterstützt die Kerberos-, NTLM- und ausgehandelte Authentifizierung (Standardeinstellung) 

sowie die Verwendung des Domänen-\Benutzernamens, des Benutzerprinzipalnamens 

oder definierten Namens als Anmeldeinformationen für die Authentifizierung. 

Wenn die AD LDS eine SASL-Bindungsanforderung empfangen, wird die Anforderung an Active 

Directory oder die LSA weitergeleitet. Wird die Bindungsanforderung erfolgreich authentifiziert, 

wird dem Benutzerkonto ein Sicherheitstoken zugewiesen. Die AD LDS verwenden dieses Token im 

internen Kontext, fügen die SIDs der AD LDS-Gruppen hinzu, zu denen der Benutzer gehört, und 

führen anschließend eine transitive Gruppenerweiterung in allen Anwendungspartitionen aus. Dies 

bedeutet, dass die AD LDS die Gruppenmitgliedschaften für den Windows-Benutzer bestimmen, die 

sich daraus ergeben, dass der Benutzer Mitglied einer Gruppe ist, die selbst zu einer anderen Gruppe 

gehört. Der Zugriff auf AD LDS-Objekte wird basierend auf dem Sicherheitstoken gewährt oder verweigert. 

Bindungsumleitung für AD LDS-Proxyobjekte Eine AD LDS-Bindungsumleitung erfolgt, wenn über ein 

besonderes, Proxyobjekt genanntes Objekt versucht wird, eine Bindung zu den AD LDS herzustellen. 

Ein Proxyobjekt ist ein Objekt in den AD LDS, das einen Sicherheitsprinzipal in Active Directory 

abbildet. Jedes Proxyobjekt in den AD LDS enthält die SID eines Benutzers in Active Directory. 

Wenn ein Benutzer versucht, eine Bindung zu einem Proxyobjekt herzustellen, rufen die AD LDS die 

im Proxyobjekt gespeicherte SID sowie das zum Bindungszeitpunkt angegebene Kennwort ab und 

legen Active Directory die SID und das Kennwort zur Authentifizierung vor. 

Da die einleitende Bindungsanforderung eine einfache LDAP-Bindungsanforderung ist, wird das 

Kennwort den AD LDS unverschlüsselt vorgelegt. Um diese Authentifizierung abzusichern, fordern 

die AD LDS die Verwendung von SSL an. Da das Kennwort, das den AD LDS während der AD 

LDS-Bindungsumleitung vorgelegt wird, unverschlüsselt ist, darf die SSL-Anforderung bei Verwenden 

der Bindungsumleitung nicht aufgehoben werden. 

Die AD LDS-Bindungsumleitung wird verwendet, wenn eine Anwendung eine einfache LDAP-Bindung 

zu den AD LDS herstellen kann, die Anwendung jedoch weiterhin den Benutzer mit einem 

Sicherheitsprinzipal in Active Directory verknüpfen muss.


Proxyobjekte (und Proxyobjektklassen) sind in den AD LDS nicht standardmäßig vorhanden. Während 

der AD LDS-Installation können Sie allerdings eine Proxyobjektklasse in das AD LDS-Schema 

importieren. Aus jeder Objektklasse, die die Erweiterungsklasse msDS-bindProxy enthält, kann ein 

Proxyobjekt erstellt werden. Die Klasse msds-BindProxy weist ein einzelnes Pflichtattribut auf 

(ObjectSid), das die SID des zugeordneten lokalen oder AD DS-Sicherheitsprinzipals enthält. Sie 

können den Wert von ObjectSid nur zum Zeitpunkt der Objekterstellung festlegen. Nach der Erstellung 

eines Proxyobjekts kann der Wert von dessen Attribut ObjectSid nicht geändert werden. Sie können 

den Wert von ObjectSid eines Proxyojekts auf die SID eines beliebigen lokalen Windows-Benutzers 

oder eines beliebigen Benutzers festlegen, der Mitglied einer Domäne oder Gesamtstruktur ist, 

der von dem Computer vertraut wird, auf dem die AD LDS ausgeführt werden. 

Weitere Informationen Detaillierte Anweisungen zum Konfigurieren von Benutzerkonten und Authentifizierungseinstellungen 

finden Sie in „Schritt 7: Verwalten der Authentifizierung (Übungen)“ unter „Schrittweise 

Anleitung zu den ersten Schritten mit Active Directory Lightweight Directory Services“ unter 

http://technet2.microsoft.com/windowsserver2008/de/library/682674f4-a652-4772-8567- 

2f27417f4ec81031.mspx?mfr=true. 

Implementieren der AD LDS 

Die AD LDS werden unter Windows Server 2008 als Serverrolle implementiert. Die Serverrolle kann 

über den Server-Manager hinzugefügt und installiert werden. Um die Serverrolle auf einem Computer 

mit Windows Server 2008 zu installieren, auf dem Server Core ausgeführt wird, führen Sie den 

Befehl start /w ocsetup DirectoryServices-ADAM-ServerCore aus. Während der Installation der Rolle 

müssen Sie außer der Auswahl der zu installierenden Serverrolle keine weiteren Installationsentscheidungen 

treffen. Um die AD LDS installieren zu können, muss Ihr Benutzerkonto der lokalen Gruppe 

Administratoren angehören. 

Konfigurieren von Instanzen und Anwendungspartitionen 

Nach der Installation der Serverrolle AD LDS erstellen Sie mit dem Setup-Assistenten für Active 

Directory Lightweight Directory Services AD LDS-Dienstinstanzen. Auf demselben Computer können 

mehrere Instanzen der AD LDS gleichzeitig ausgeführt werden. Jede Instanz des AD LDS-Verzeichnisdienstes 

hat einen eigenen Verzeichnisdatenspeicher, einen eindeutigen Dienstnamen und eine 

eindeutige Dienstbeschreibung, die bei der Installation zugewiesen wird. Wenn Sie den Assistenten 

ausführen, können Sie auch eine Anwendungsverzeichnispartition anlegen. 

Führen Sie zum Erstellen einer neuen AD LDS-Instanz im Setup-Assistenten für Active Directory 

Lightweight Directory Services die folgenden Schritte aus: 

1. Starten Sie den Setup-Assistenten für Active Directory Lightweight Directory Services. Sie können 

den Assistenten im Menü Verwaltung oder im Server-Manager starten. 

2. Klicken Sie auf dem Begrüßungsbildschirm auf Weiter. 

3. Auf der Seite Setupoptionen können Sie eine neue Instanz oder ein Replikat einer vorhandenen 

Instanz erstellen (siehe Abbildung 16.4). Klicken Sie auf Eine eindeutige Instanz installieren und 

anschließend auf Weiter.

Implementieren der AD LDS 631 


Erstellen einer AD LDS-Instanz 

4. Geben Sie auf der Seite Instanzname einen Namen für zu installierende AD LDS-Instanz ein. Der 

gewählte Name muss die folgenden Anforderungen erfüllen: 

Der Name muss sich von dem anderer AD LDS-Instanzen unterscheiden, die auf demselben 

Computer ausgeführt werden 

Der Name darf maximal 44 Zeichen haben. 

Der Name darf nur Zeichen aus den Bereichen a bis z, A bis Z bzw. 0 bis 9 enthalten. 

Der Name ntds darf nicht gewählt werden. 

5. Geben Sie auf der Seite Ports die Kommunikationsports an, welche die AD LDS-Instanz für die 

Kommunikation verwendet. Die AD LDS können über LDAP und SSL (Secure Sockets Layer) 

kommunizieren. 

Hinweis Wenn Sie die AD LDS auf einem Computer installieren, auf dem einer der Standardports 

belegt sind, findet der Setup-Assistent für Active Directory Lightweight Directory Services automatisch 

den ersten verfügbaren Port (beginnend bei 50000). Wenn Sie die AD LDS auf einem AD DS-Domänencontroller 

installieren, können Sie die Ports 389 und 636 bzw. auf globalen Katalogservern die 

Ports 3268 und 3269 nicht verwenden, da diese Ports für AD DS-Domänencontroller und globale Katalogsuchen 


6. Auf der Seite Anwendungsverzeichnispartition können Sie während der AD LDS-Installation eine 

Anwendungsverzeichnispartition erstellen (siehe Abbildung 16.5). Wenn Sie zu diesem Zeitpunkt 

keine Anwendungsverzeichnispartition installieren, müssen Sie diesen Schritt nach der Installation 

manuell ausführen. Beim Erstellen der Anwendungsverzeichnispartition müssen Sie einen 

vollständig qualifizierten Partitionsnamen angeben.



anlegen. 

Beim Erstellen einer AD LDS-Instanz können Sie eine Anwendungsverzeichnispartition 

7. Auf der Seite Speicherort können Sie die Installationsverzeichnisse für die AD LDS-Daten- und 

Wiederherstellungsdateien (Protokolldateien) anzeigen und ändern. AD LDS-Daten- und Wiederherstellungsdateien 

werden standardmäßig in %ProgramFiles%\Microsoft ADAM\Instanzname\ 

data installiert, wobei Instanzname der AD LDS-Instanzname ist, den Sie auf der Seite Instanzname 

angegeben haben. 

8. Wählen Sie auf der Seite Dienstkontoauswahl ein Konto aus, das als AD LDS-Dienstkonto verwendet 

werden soll. Das ausgewählte Konto bestimmt den Sicherheitskontext, in dem die AD 

LDS-Instanz ausgeführt wird. Die Standardeinstellungen im Setup-Assistenten für Active Directory 

Lightweight Directory Services ist das Konto Netzwerkdienst. 

Hinweis Wenn Sie die AD LDS auf einem Computer installieren, der zu einer Windows Server 2000- 

Domäne oder höher gehört, können Sie das Konto Netzwerkdienst auch verwenden, wenn die Implementierung 

der Replikation geplant ist. Wenn Sie die AD LDS auf einem Computer bereitstellen, der Mitglied 

einer Arbeitsgruppe ist, oder die Replikation zwischen AD LDS-Computern in verschiedenen nicht 

vertrauenswürdigen Domäne ermöglichen möchten, muss auf allen Computern ein mit dem AD LDS- 

Dienstkonto identisches Benutzerkonto verwendet werden. 

9. Wählen Sie auf der Seite AD LDS-Administratoren den Standardadministrator der AD LDS- 

Instanz (Benutzer oder Gruppe) aus. Der Benutzer oder die Gruppe, den/die Sie auswählen, verfügt 

über Vollzugriffsrechte für die AD LDS-Instanz. Standardmäßig wählt der Setup-Assistent 

für Active Directory Lightweight Directory Services den aktuell angemeldeten Benutzer aus. Sie 

können diese Auswahl in ein beliebiges lokales oder Domänenkonto bzw. eine beliebige Gruppe 

in Ihrem Netzwerk ändern. 

10. Auf der Seite Importieren von LDIF-Dateien können Sie LDF-Schemadateien in die AD LDS- 

Instanz importieren (siehe Abbildung 16.6).



Durch Hinzufügen von LDF-Dateien wird das AD LDS-Schema geändert 

11. Prüfen Sie auf der Seite Installationsbereit die gewählten Installationsoptionen. Nach Klicken auf 

Weiter kopiert der Setup-Assistent für Active Directory Lightweight Directory Services Dateien 

und richtet die AD LDS auf Ihrem Computer ein. 

Hinweis Wenn im Setup-Assistenten für Active Directory Lightweight Directory Services vor der Seite mit 

der Zusammenfassung ein Fehler auftritt, können Sie die angezeigte Fehlermeldung überprüfen. Darüber 

hinaus können Sie die Datei adamsetup.log und die adamsetup_loader.log-Dateien im Ordner %windir%\ 

debug auf Gründe untersuchen, warum die Installation fehlgeschlagen ist. 

Hinweis Um eine AD LDS-Instanz zu entfernen, öffnen Sie in der Systemsteuerung die Konsole Programme 

und Funktionen. Alle AD LDS-Instanzen werden als installierte Programme angezeigt, die Sie wie 

andere Programme deinstallieren können. 

AD LDS-Verwaltungstools 

Nach der Installation einer AD LDS-Instanz installieren Sie zumeist die Anwendung, die die Instanz 

verwenden soll (wobei die Anwendung ggf. die AD LDS für Sie installiert und konfiguriert). Sie können 

AD LDS-Instanzen jedoch auch mithilfe der mit den AD LDS bereitgestellten Verwaltungstools 

verwalten. 

Das Tool ADSI Edit 

ADSI Edit ist ein MMC-Snap-In (Microsoft Management Console) für die allgemeine AD LDS-Verwaltung 

und wird als Teil der Serverrollen AD LDS und AD DS installiert. Um eine AD LDS-Instanz 

mit ADSI Edit zu verwalten, müssen Sie zuerst eine Verbindung zur Instanz herstellen. Nach dem ersten 

Öffnen ist ADSI Edit mit keinem Verzeichnis verbunden. Um eine Verbindung zu einem Verzeichnis 

herzustellen, klicken Sie im Menü Aktion auf Verbinden mit. Auf dem Bildschirm Verbindungseinstellungen 

(siehe Abbildung 16.7) müssen Sie die folgenden Informationen eingeben: 

• Einen Namen für diese Verbindung Wenn Sie einen der gängigen Namenskontexte auswählen, wird 

dieser Name für Sie eingegeben.


• Einen Verbindungspunkt Dies kann ein gängiger Namenskontext wie die Konfigurations- oder 

Schemapartition, das Objekt rootDSE oder der Namenskontext Standard sein (was nur für AD 

DS-Domänen oder Anwendungsverzeichnispartitionen gilt). Wenn Sie eine Verbindung zu einer 

Anwendungsverzeichnispartition herstellen möchten, müssen Sie deren definierten Namen eingeben. 

• Den Server, zu dem Sie eine Verbindung herstellen Wenn Sie einen Port wählen, der nicht zu den 

LDAP-Standardports gehört, müssen Sie auch die Portnummer für die Verbindung angeben. 


Verbinden mit einer AD LDS-Instanz mithilfe von ADSI Edit 

Das Tool Ldp.exe 

Ldp.exe ist ein Tool zum Verwalten von LDAP-Verzeichnisdiensten. Um eine AD LDS-Instanz mit 

Ldp.exe zu verwalten, müssen Sie eine Verbindung und eine Bindung mit der Instanz einrichten und 

anschließend die Hierarchie (Struktur) eines definierten Namens der Instanz anzeigen: 

1. Um sich über LDP mit einer Instanz zu verbinden, öffnen Sie eine Eingabeaufforderung, geben 

Ldp.exe ein und drücken die EINGABETASTE. 

2. Klicken Sie dann im Menü Remotedesktopverbindung auf Verbinden. Geben Sie den Servernamen 

und Port für die AD LDS-Instanz an, und wählen Sie, ob SSL verwendet werden soll. 

3. Nach dem Herstellen der Verbindung mit der Instanz müssen Sie Ihre Anmeldeinformationen 

angeben, um eine Bindung mit der Instanz einzurichten. Klicken Sie dann im Menü Remotedesktopverbindung 

auf Gebunden. 

Um eine Bindung mithilfe der Anmeldeinformationen einzurichten, mit denen Sie angemeldet 

sind, klicken Sie auf Bindung als aktuell angemeldeter Benutzer. 

Um eine Bindung über ein Domänenbenutzerkonto einzurichten, klicken Sie auf Bindung mit 

Anmeldeinformationen. Geben Sie anschließend den Benutzernamen, das Kennwort und den 

Domänennamen (bzw. den Computernamen, wenn Sie ein lokales Arbeitsstationskonto verwenden) 

Ihres Kontos ein. 

Um eine Bindung über einen Benutzernamen und ein Kennwort einzurichten, klicken Sie auf 

Einfache Bindung und geben anschließend den Benutzernamen und das Kennwort Ihres Kontos 

ein.


Um eine Bindung mit einer erweiterten Methode einzurichten, (NTLM, verteilte Kennwortauthentifizierung 

[Distributed Password Authentication, DPA], Aushandeln oder Digest), 

klicken Sie auf Erweitert (DIGEST). Klicken Sie anschließend auf Erweitert, wählen Sie im 

Dialogfeld Bindungsoptionen die gewünschte Methode, und legen Sie weitere Optionen den 

Anforderungen entsprechend fest. 

4. Klicken Sie nach Ihrer Authentifizierung im Menü Ansicht auf Struktur. Sie können den definierten 

Namen für die Verzeichnispartition eingeben oder auswählen, mit der Sie sich verbinden 

möchten. 

5. Um Informationen zu den Objekten in der Verzeichnispartition anzuzeigen, klicken Sie auf das 

Objekt im linken Bereich. Detaillierte Informationen zum Objekt werden im rechten Bereich 

angezeigt (siehe Abbildung 16.8). 


Sie können mit Ldp.exe Details aller Objekte in den AD LDS anzeigen. 

6. Um das Objekt zu bearbeiten, klicken Sie mit der rechten Maustaste auf das Objekt und wählen 

eine der Optionen zum Ändern des Objekts oder zum Hinzufügen untergeordneter Objekte. 

Weitere Informationen Einzelheiten zum Arbeiten mit ADSI Edit und Ldp.exe zum Verwalten von AD 

LDS-Objekten wie Organisationseinheiten, Benutzer- und Gruppenkonten finden Sie unter dem Thema zum 

Arbeiten mit Authentifizierung und Zugriffssteuerung in der AD LDS-Onlinehilfe oder „Schrittweise Anleitung 

zu den ersten Schritten mit Active Directory Lightweight Directory Services“ unter http://technet2.microsoft.com/windowsserver2008/de/library/682674f4-a652-4772-8567-2f27417f4ec81031.mspx?mfr=true. 

Das Tool Dsdbutil 

Dsdbutil ist Tool für die Verwaltung von Verzeichnisdiensten mit nahezu demselben Funktionsumfang 

wie Ntdsutil für die AD DS. Mit Dsdbutil können Sie Folgendes ausführen: 

• AD LDS-Daten sichern und autorisierende Wiederherstellungen ausführen 

• Die AD LDS-Datendateien verschieben 

• Das AD LDS-Dienstkonto und Portnummern ändern 

• Alle auf einem Server ausgeführten AD LDS-Instanzen auflisten


Dsdbutil muss an einer Eingabeaufforderung gestartet werden. Verbinden Sie sich anschließend mit 

einer bestimmten Instanz durch Eingabe von Activate Instance Instanzname. Um alle in Dsdbutil 

verfügbaren Befehle anzuzeigen, geben Sie Help ein. Wie Ntdsutil bietet auch Dsdbutil kontextbezogene 

Hilfe, weshalb nach Eingabe von Help an einer beliebigen Eingabeaufforderung alle in diesem 

Kontext verfügbaren Optionen angezeigt werden. 

Hinweis Wenn Sie die Datei MS-ADLDS-DisplaySpecifiers.ldf hinzufügen können Sie AD LDS-Standorte 

mit dem Snap-In Active Directory-Standorte und -Dienste verwalten. Um sich mit einer AD LDS-Instanz zu 

verbinden, müssen Sie den Servernamen und die Portnummer eingeben. 

Konfigurieren der Zugriffssteuerung 

In den AD LDS gibt es für jedes Verzeichnisobjekt eine Zugriffsteuerungsliste, die bestimmt, welche 

Benutzer auf das jeweilige Objekt zugreifen dürfen. Zugriffsteuerungslisten werden standardmäßig 

ganz oben in jeder Verzeichnispartition zugewiesen und von allen Objekten in einer gegebenen Verzeichnispartition 

übernommen. Wenn Ihre Anwendung erfordert, dass spezifische Berechtigungen auf 

verschiedenen Ebenen der Verzeichnisstruktur zugewiesen werden, können Sie mit Dienstprogrammen 

wie Dsacls und Ldp.exe Berechtigungen anzeigen und zuweisen. 

Dsacls ist ein Befehlszeilenprogramm, mit dem Berechtigungen in einem Verzeichnis wie den AD 

LDS angezeigt und geändert werden können. Dsacls verwendet die folgende in Tabelle 16.9 beschriebene 

Syntax: 

dsacls Objekt [/a] [/d {Benutzer | Gruppe}:Berechtigungen [...]] 

[/g {Benutzer | Gruppe}:Berechtigungen [...]] [/i:{p |s|t}][/n] [/p:{y | n}] 

[/r {Benutzer | Gruppe} [...]] [/s [/t]] 

Tabelle 16.9 

Syntax von Dsacls 

Parameter 

Beschreibung 

Objekt 

Dies ist der Pfad zum Verzeichnisdienstobjekt, dessen Zugriffsteuerungslisten angezeigt oder geändert 

werden sollen. Sie müssen den vollständigen LDAP-Namen angeben. Beispiel: CN=App- 

Data,OU=Software,CN=App1,DC=AdatumApps. Um einen Server anzugeben, setzen Sie \\ 

Servername:Portnummer\ vor das Objekt. Beispiel: \\SEA-SVR1:3389\ CN=AppData,OU=Software,CN=App1,DC=AdatumApps 

/a Zeigt die Überwachungsinformationen sowie Berechtigungs- und Besitzinformationen an. 

/d {Benutzer | Gruppen}:Berechtigungen: 

Verweigert die angegebenen Berechtigungen einem Benutzer oder einer Gruppe. 

/g {Benutzer | Gruppen}:Berechtigungen: 

Erteilt die angegebenen Berechtigungen einem Benutzer oder einer Gruppe. 

/i:{p | s | t} : 

Gibt eines der folgenden Vererbungskennzeichen an: 

• p: Dient zum Weitergeben vererbbarer Berechtigungen um nur eine Stufe. 

• s: Dient zum Weitergeben vererbbarer Berechtigungen nur an Unterobjekte. 

• t: Dient zum Weitergeben vererbbarer Berechtigungen an dieses Objekt und Unterobjekte. 

/n: 

Ersetzt den aktuellen Zugriff auf das Objekt, anstatt ihn zu bearbeiten. 

/p:{y | n}: 

Dieser Parameter bestimmt, ob das Objekt Berechtigungen von seinem übergeordneten Objekte 

erbt. Wenn Sie diesen Parameter weglassen, werden die Vererbungseigenschaften des Objekts 

nicht geändert. 

/r {Benutzer | Gruppe}: Entfernt alle Berechtigungen für den angegebenen Benutzer bzw. die angegebene Gruppe.


Tabelle 16.9 

Parameter 

/s: 

/t: 

Syntax von Dsacls (Fortsetzung) 

Beschreibung 

Setzt die Sicherheitseinstellungen für das Objekt auf die Standardsicherheitseinstellungen für 

diese Objektklasse zurück. 

Dieser Parameter dient zum Zurücksetzen der Sicherheitseinstellungen der Objektstruktur auf die 

Standardeinstellungen für die einzelnen Objektklassen. Dieser Parameter ist nur gültig, wenn Sie 

auch den Parameter /s angeben. 

Dsacls verwendet zum Konfigurieren von Berechtigungen für ein Objekt Berechtigungsbits. Dsacls 

stellt beispielsweise die folgenden allgemeinen Berechtigungen bereit: GR – Generic Read (Lesen allgemein), 

GE – Generic Execute (Ausführen allgemein), GW – Generic Write (Schreiben allgemein) 

und GA – (Alle Aktionen allgemein). 

Weitere Informationen Detaillierte Informationen zum Verwenden von Dsacls zum Verwalten von Berechtigungen 

in einem Verzeichnis, einschließlich Einzelheiten zu den Berechtigungsbiteinstellungen, finden Sie 

im Knowledge Base-Artikel „Verwenden von Dsacls.exe in Windows Server 2003 und Windows 2000“ unter 

http://support.microsoft.com/kb/281146. Sie können dsacls /? auch an der Eingabeaufforderung eingeben. 

Einige Dsacls-Beispielbefehle werden in Tabelle 16.10 beschrieben. 

Tabelle 16.10 

Dsacls-Beispielbefehle 

Befehl 

dsacls \\SEA-SVR1:4389\O=App2, DC=Adatum,DC=com 

dsacls \\SEA-SVR1:4389\O=App2, DC=Adatum,DC=com /G “CN= 

Gregory Weber, OU=Users,O=App2, DC=Adatum,DC=com “:SD 

dsacls “\\SEA-SVR1:4389\O=App2, DC=Adatum,DC=com” /D “CN= 

Alice Ciccu, OU=Users,O=App2, DC=Adatum, DC=com “:SDDCDT 

Erläuterung 

Zeigt die der Referenzanwendungspartition zugewiesenen 

Berechtigungen. 

Erteilt dem Benutzer Gregory Weber die besondere 

Löschberechtigung für das Objekt O=App2. 

Verweigert der Benutzerin Alice Ciccu die Berechtigungen 

Löschen, Untergeordnetes Objekt löschen 

und Struktur löschen für das Objekt O=App2. 

Sie können mit Ldp.exe auch Berechtigungen für AD LDS-Objekte konfigurieren. Führen Sie dazu 

die folgenden Schritte aus: 

1. Öffnen Sie Ldp.exe, und stellen Sie eine Verbindung und Bindung mit einer AD LDS-Instanz her. 

2. Klicken Sie im Menü Ansicht auf Strukturansicht, und wählen Sie dann die Verzeichnispartition 

aus, mit der Sie sich verbinden möchten. 

3. Klicken Sie mit der rechten Maustaste auf die Verzeichnispartition, für die Sie die Berechtigungen 

ändern möchten, klicken Sie auf Erweitert, und klicken Sie dann auf Sicherheitsbeschreibung. 

Das Dialogfeld Sicherheitsbeschreibung enthält alle Zugriffsteuerungseinträge (Access 

Control Entries, ACEs) und deren erteilte Zugriffsrechte für das ausgewählte Verzeichnispartitionsobjekt. 

4. Klicken Sie auf eine beliebige Stelle der Zugriffsteuerungsliste und anschließend auf ACE hinzufügen. 

Geben Sie den definierten Namen des Benutzerkontos ein, und wählen Sie die gewünschten 

Berechtigungen aus. Sie können auch Berechtigungen zulassen oder verweigern und die 

Berechtigungsvererbung konfigurieren.



Konfigurieren von Berechtigungen mithilfe von Ldp.exe. 

Konfigurieren der Replikation 

Wie die AD DS arbeiten die AD LDS mit der Replikation, um Redundanz, eine geografische Verteilung 

und einen Lastenausgleich für AD LDS-Instanzen zu ermöglichen. Wie zuvor beschrieben, sind 

die Konzepte und Prozesse bei der Implementierung der Replikation bei den AD LDS und den AD 

DS sehr ähnlich. 

Erstellen von AD LDS-Replikaten 

Die Konfiguration der AD LDS-Replikation beginnt mit dem Erstellen weiterer Replikate der AD 

LDS-Instanz. Ein Replikat kann nur beim Erstellen einer Instanz konfiguriert werden. Alle AD LDS- 

Instanzen in einem Konfigurationssatz replizieren eine gemeinsame Konfigurationsverzeichnispartition 

und eine gemeinsame Schemaverzeichnispartition sowie beliebig viele Anwendungsverzeichnispartitionen. 

Um eine AD LDS-Instanz zu erstellen und einem vorhandenen Konfigurationssatz hinzuzufügen, 

müssen Sie mit dem Setup-Assistenten für Active Directory Lightweight Directory Services ein 

Replikat einer AD LDS-Instanz erstellen. Sie müssen den DSN-Namen des Servers, auf dem eine 

zum Konfigurationssatz gehörende AD LDS-Instanz ausgeführt wird, und die LDAP-Port kennen, der 

bei der Erstellung der Instanz angegeben wurde. Sie können auch die definierten Namen bestimmter 

Anwendungsverzeichnispartitionen angeben, die Sie aus dem Konfigurationssatz in die zu erstellende 

AD LDS-Instanz kopieren möchten. 

Führen Sie zum Erstellen eines Replikats einer AD LDS-Instanz im Setup-Assistenten für Active 

Directory Lightweight Directory Services die folgenden Schritte aus: 

1. Starten Sie den Setup-Assistenten für Active Directory Lightweight Directory Services. Klicken 

Sie auf der Begrüßungsseite auf Weiter. 

2. Klicken Sie auf der Seite Setupoptionen auf Ein Replikat einer vorhandenen Instanz installieren 

(siehe Abbildung 16.4). 

3. Geben Sie auf der Seite Instanznamen einen Instanznamen ein. Die Namen von AD LDS- 

Instanzen müssen auf dem jeweiligen Computer eindeutig sein. Ferner kann der Instanzname dem 

Instanznamen anderer Replikate entsprechen.


4. Legen Sie auf der Seite Ports die Portnummern der Instanz fest. Diese Portnummern geben die 

Ports an, über die sich Clients mit dem Server verbinden. Deshalb wird empfohlen (ohne dass es 

erforderlich ist), dass Sie dieselben Ports wie bei der vorhandenen Instanz angeben. 

5. Geben Sie auf der Seite Einem Konfigurationssatz beitreten den Host- oder DNS-Namen des 

Computers an, auf dem die erste AD LDS-Instanz installiert ist. Geben Sie anschließend die von 

der ersten AD LDS-Instanz verwendete LDAP-Portnummer ein. Diese Portnummer muss der für 

die vorhandene Instanz festgelegten Portnummer entsprechen. 

6. Klicken Sie auf der Seite Administratorberechtigungen für den Konfigurationssatz auf das Konto 

des AD LDS-Administrators der ersten AD LDS-Instanz. 

7. Wählen Sie auf der Seite Kopieren von Anwendungsverzeichnispartitionen die Anwendungsverzeichnispartitionen 

aus, die Sie in die neue AD LDS-Instanz replizieren möchten. Siehe 

Abbildung 16.10. 

Abbildung 16.10 Beim Erstellen eines AD LDS-Instanzreplikats können Sie diesem Anwendungsverzeichnispartitionen 

hinzufügen. 

8. Übernehmen Sie die Standardwerte auf den restlichen Seiten des Setup-Assistenten für Active 

Directory Lightweight Directory Services, indem Sie auf jeder Seite auf Weiter und auf der Seite 

Fertigstellen des Assistenten auf Fertig stellen klicken. 

Hinweis Sie können eine AD LDS-Instanz auch über die Option Installieren von Medium installieren. 

Sichern Sie dazu eine Kopie des AD LDS-Datenspeichers auf dem AD LDS-Quellserver, und stellen Sie die 

Dateien an einem anderen Speicherort wieder her, der auf den Server, auf dem Sie ein Replikat konfigurieren, 

zugreifen kann. Starten Sie anschließend den Setup-Assistenten für Active Directory Lightweight Directory 

Services, indem Sie an einer Eingabeaufforderung %windir%\adam\adaminstall /adv eingeben. Wenn 

Sie den Assistenten im erweiterten Modus starten, können Sie die Anwendungsinformationen aus einer wiederhergestellten 

Kopie des Datenspeichers kopieren.


Konfigurieren von AD LDS-Standorten 

Wie bei den AD DS beginnt die Konsistenzprüfung, sobald Sie ein Replikat einer vorhandenen AD 

LDS-Instanz konfigurieren, auf beiden Servern mit der Einrichtung der Replikationstopologie und 

anschließend mit der Replikation. Und wie auch bei den AD DS können Sie zum Verwalten des 

Replikationsdatenverkehrs zwischen AD LDS-Instanzen Standorte verwenden. Wenn Sie AD LDS- 

Instanzen an geografisch verteilten Standorten bereitstellen, können Sie für jede Niederlassung einen 

eigenen Standort konfigurieren und anschließend Standortverknüpfungen zum Verwalten des Replikationsdatenverkehrs 

zwischen den Standorten verwenden. 

Wichtig Zwei wichtige Unterschiede bei der Verwendung von Standorten zwischen den AD LDS und den 

AD DS sind, dass AD LDS-Clients nicht standortabhängig sind und dass die AD LDS keine Möglichkeiten der 

Automatisierung von Clientverbindungen zu AD LDS-Instanzen am Standort des Clients bieten. Die AD LDS 

nutzen keine SRV-Einträge, um Clients beim Auffinden von AD LDS-Instanzen zu helfen. Wenngleich Sie Subnetze 

für AD LDS-Instanzen konfigurieren und Standorte mit Subnetzen verknüpfen können, sind Clients nicht 

fähig, diese Informationen zu nutzen. Wenn Sie demnach AD LDS-Instanzen an verschiedenen Standorten 

bereitstellen, müssen Sie die AD LDS-Clients so konfigurieren, dass sie sich mit der lokalen AD LDS-Instanz 

verbinden. 

Zum Verwalten von AD LDS-Standorten müssen Sie die Datei MS-ADLDS-DisplaySpecifiers.ldf in 

der Instanz installieren. Anschließend können Sie sich mit dem Snap-In Active Directory-Standorteund 

-Dienste mit Ihrer AD LDS-Instanz verbinden, um Standortobjekte zu definieren und Verzeichnisobjekte 

zwischen Standorten zu verschieben. 

Um sich über Active Directory-Standorte- und -Dienste mit einer AD LDS-Instanz zu verbinden, öffnen 

Sie die MMC, klicken mit der rechten Maustaste auf Active Directory-Standorte- und -Dienste 

und klicken anschließend auf Domänencontroller ändern. Geben Sie den Namen und die Portnummer 

des Servers an, auf dem sich die AD LDS-Instanzen in dem Konfigurationssatz befinden, für den 

Sie Standortobjekte erstellen möchten. 

Nach dem Herstellen der Verbindung zur AD LDS-Instanz können Sie Folgendes: 

• Standortobjekte erstellen 

• AD LDS-Instanzen zwischen Standorten verschieben 

• Die Replikationshäufigkeit innerhalb eines Standorts festlegen 

• Replikationszeitplan und -häufigkeit für die standortinterne Replikation durch Konfiguration von 

Standortverknüpfungen einrichten 

Hinweis Die Schritte zur Konfiguration dieser Objekte sind bei den AD LDS und den AD DS identisch. 

Weitere Informationen zu diesen Schritten finden Sie in der Onlinehilfe zu Active Directory-Standorte und 

-Dienste oder in Kapitel 4. 

Sichern und Wiederherstellen der AD LDS 

Nach der Bereitstellung enthalten die AD LDS wichtige Anwendungsdaten und Konfigurationsinformationen. 

Um sicherzustellen, dass Sie diese Daten nach einem Datenverlust oder Serverausfall wiederherstellen 

können, müssen Sie die AD LDS in Ihre regelmäßigen Sicherungsabläufe einbeziehen, 

um die AD LDS-Daten auf demselben oder einem anderen Server wiederherzustellen.


Sichern der AD LDS 

Sie müssen die AD LDS-Daten und -Protokolldateien regelmäßig sichern, um bei einem Systemausfall 

die Verfügbarkeit von Daten für Anwendungen und Benutzern gewährleisten zu können. 

Hinweis Eine Möglichkeit zum Gewährleisten einer hohen Verfügbarkeit von AD LDS-Instanzen ist die 

Bereitstellung mehrerer Replikate derselben Instanz. Fällt ein Replikat aus, können sich Clients weiterhin mit 

dem zweiten Replikat verbinden. Darüber hinaus können Sie die AD LDS in einem Cluster mit Netzwerklastenausgleich 

bereitstellen, sodass Sie bei einem Serverausfall die AD LDS-Clients nicht neu konfigurieren 

müssen. 

Standardmäßig speichert jede auf einem AD LDS-Server ausgeführte AD LDS-Instanz ihre Datenbankdateien 

Adamntds.dit und die dazugehörigen Protokolldateien im Verzeichnis %Programme%\ 

Microsoft ADAM\Instanzname\data, wobei Instanzname der Name der AD LDS-Instanz ist. Um 

sicherzustellen, dass die AD LDS-Daten ordnungsgemäß gesichert werden, beziehen Sie diese Daten 

in die regelmäßigen Sicherungen in Ihrem Unternehmen ein. 

Wichtig Die AD LDS sind weniger serverabhängig als die AD DS. Sie können AD LDS-Daten auf einem 

Server sichern und auf einem anderen Server wiederherstellen, sollte der ursprüngliche Server ausfallen. 

Außerdem müssen Sie auf einem Server keine Systemstatusdaten sichern oder wiederherstellen, um den AD 

LDS-Datenspeicher wiederherzustellen. 

Sie können das Windows Server-Sicherungsprogramm oder ein anderes Sicherungsprogramm einsetzen, 

mit dem Sie zum Sichern der AD LDS-Daten geöffnete Dateien sichern können. Während der 

Sicherung muss die AD LDS-Instanz weiter ausgeführt werden. 

Sie können die AD LDS-Instanz auch mit dem Befehlszeilenprogramm Dsdbutil.exe sichern. Mit 

Dsdbutil.exe können Sie Installationsmedien für einzelne AD LDS-Instanzen sichern und erstellen, 

anstatt lediglich die AD LDS-Dateien oder gesamte Volumes zu sichern, welche die AD LDS-Instanz 

enthalten. 

Hinweis Wenn Ntdsutil auf dem AD LDS-Server installiert ist, können Sie den Fokus für Ntdsutil auf eine 

AD LDS-Instanz festlegen, indem Sie die Instanz aktivieren. Anschließend können Sie die AD LDS-Instanz 

mit Ntdsutil verwalten. 

Führen Sie zum Sichern einer AD LDS-Instanz mithilfe von Dsdbutil.exe die folgenden Schritte aus: 

1. Öffnen Sie eine Eingabeaufforderung, geben Sie dsdbutil ein, und drücken Sie die EINGABE- 

TASTE. 

2. Geben Sie an der dsdbutil-Eingabeaufforderung Folgendes ein: activate instance Instanzname. 

Drücken Sie dann die EINGABETASTE. Instanzname ist der Name der AD LDS-Instanz, die Sie 

sichern oder für die Sie Installationsmedien erstellen möchten. 

3. Geben Sie an der dsdbutil-Eingabeaufforderung ifm ein, und drücken Sie die EINGABETASTE. 

4. Geben Sie an der ifm-Eingabeaufforderung createfull DateipfadName ein, und drücken Sie 

die EINGABETASTE. Dateipfad ist der Speicherort, an dem die Sicherung gespeichert wird. 

Dsbdutil erstellt einen Snapshot des AD LDS-Datenspeichers und sichert diesen am Speicherort 

der Sicherung. Die Dsbdutil-Sicherung besteht bloß aus der Datei Adamntds.dit.


Wiederherstellen der AD LDS 

Wenn der AD LDS-Server ausfällt oder Datenspeicherdateien verloren gehen oder fehlerhaft sind, 

können Sie mit denselben Sicherungsprogrammen den Datenspeicher wiederherstellen. Je nach Situation 

müssen Sie zum Wiederherstellen der AD LDS-Instanzdaten geringfügig unterschiedliche Vorgehensweisen 

wählen. 

Wiederherstellen einer vorhandenen AD LDS-Instanz Wenn der AD LDS-Server bzw. die Datenbank auf 

dem Server ausfällt, können Sie eine herkömmliche Wiederherstellung der AD LDS-Daten zum Wiederherstellen 

der AD LDS-Instanz in den Zustand zum Zeitpunkt der Sicherung ausführen. Sollte der 

AD LDS-Server ausfallen, müssen Sie zuerst den Server reparieren und anschließend neu starten. Vor 

dem Wiederherstellungsvorgang müssen Sie die AD LDS-Instanz beenden. Da bei der AD LDS-Wiederherstellung 

außerdem alle Dateien im Instanzverzeichnis überschrieben werden, müssen Sie diese 

Dateien aus dem Verzeichnis herauskopieren, bevor Sie die Wiederherstellung ausführen. 

Achtung Sie können eine AD LDS-Instanz mit dem Windows Server-Sicherungsprogramm wiederherstellen, 

ohne die Instanz beenden zu müssen. Dabei belässt das Windows Server-Sicherungsprogramm die 

wiederhergestellten Daten allerdings in einem Schwebezustand und schreibt die Dateien erst nach einem 

Neustart des Computers auf die Festplatte. In diesem Fall gehen Verzeichnisänderungen an der ausgeführten 

AD LDS-Instanz nach Ausführung des Windows Server-Sicherungsprogramms verloren. 

Führen Sie zum Wiederherstellen einer AD LDS-Instanz die folgenden Schritte aus: 

1. Beenden Sie die wiederherzustellende AD LDS-Instanz. Sie können die Instanz im Snap-In 

Dienste oder durch einen Befehl wie sc stop Instanzname beenden. Instanzname ist der Name der 

AD LDS-Instanz. 

2. Stellen Sie die AD LDS-Dateien mit dem Sicherungsprogramm wieder her. Vergewissern Sie sich, 

dass die Dateien am Speicherort der Originaldateien wiederhergestellt und die Originaldateien 

überschrieben werden. 

3. Starten Sie die AD LDS-Instanz. Nach dem Neustart der Instanz werden die wiederhergestellten 

Dateien verwendet. 

Hinweis Mit dem Windows Server-Sicherungsprogramm können Sie keine AD LDS-Instanz wiederherstellen, 

deren Sicherung mit Dsdbutil.exe erstellt wurde. Um eine mit Dsdbutil.exe erstellte Sicherung wiederherzustellen, 

können Sie die AD LDS-Instanz beenden und die von der Dsdbutil-Sicherung erstellte Datei in das 

ursprüngliche Verzeichnis zurückkopieren. 

Wiederherstellen einer AD LDS-Instanz auf einem neuen Server Wenn der AD LDS-Server ausgefallen 

ist und Sie ihn nicht reparieren können, ist es möglich, die AD LDS-Daten auf einem neuen Server 

wiederherzustellen. Dazu müssen Sie zuerst eine neue AD LDS-Instanz auf dem Server mit exakt den 

Einstellungen der ursprünglichen AD LDS-Instanz erstellen. Dabei müssen Sie denselben Instanznamen 

und Speicherort für die Speicherung der Daten auswählen. Legen Sie beim Erstellen der Instanz 

keine Anwendungspartitionen für die Daten an. 

Beenden Sie die Instanz nach ihrer Erstellung, und stellen Sie anschließend mit dem Sicherungsprogramm 

den gesicherten Datenspeicher wieder her. Falls die Sicherung mit Dsbdutil erstellt wurde, 

kopieren Sie die von Dsbdutil erstellte Datei in das entsprechende Verzeichnis, und starten Sie die 

Instanz neu.

Konfigurieren der AD DS- und AD LDS-Synchronisierung 643 

Autorisierendes Wiederherstellen einer AD LDS-Instanz 

Wie bei den AD DS können Sie autorisierende Wiederherstellungen von AD LDS-Daten durchführen, 

die versehentlich gelöscht oder geändert wurden. Wenn die AD LDS-Daten nicht auf einen anderen 

Server repliziert werden, können Sie eine normale Wiederherstellung ausführen. Wenn die AD 

LDS-Daten allerdings auf einen anderen Server repliziert werden, müssen Sie diese Objekte autorisierend 

wiederherstellen, damit die ordnungsgemäße Version der Objekte repliziert wird. 

Führen Sie für eine autorisierende Wiederherstellung von Verzeichnisdaten zuerst eine normale Wiederherstellung 

aus. Führen Sie anschließend vor dem Neustart der AD LDS-Instanz das Programm 

Dsdbutil aus, um Verzeichnisobjekte für die autorisierende Wiederherstellung zu markieren. Wenn ein 

Objekt für die autorisierende Wiederherstellung markiert ist, ändert sich sein USN-Wert (Update 

Sequence Number), sodass der Wert höher als andere USN-Werte im Konfigurationssatz ist. Dies 

stellt sicher, dass Daten, die Sie wiederherstellen, im gesamten Konfigurationssatz ordnungsgemäß 


Führen Sie für eine autorisierende Wiederherstellung die folgenden Schritte aus: 

1. Beenden Sie die AD LDS-Instanz, und stellen Sie die Daten wieder her. Je nachdem, wie die 

Sicherung erfolgt ist, können Sie die Daten mit Ihrem Sicherungsprogramm oder Dsbdutil wiederherstellen. 

2. Starten Sie vor dem Neustart der Instanz das Programm Dsbdutil, und aktivieren Sie die wiederherzustellende 

Instanz durch Eingeben von Dsbdutil activate Instanzname. 

3. Geben Sie authoritative restore ein. 

4. Geben Sie an der Eingabeaufforderung von authoritative restore einen der folgenden Befehle ein: 

restore object dn Dieser Befehl führt eine autorisierende Wiederherstellung eines Verzeichnisobjekts 

aus, dessen definierter Name von dn angegeben wird. Um z.B. ein bestimmtes 

Benutzerkonto wiederherzustellen, können Sie Folgendes eingeben: restore object 

"CN=Gregory Weber,OU=Users,O=App2,DC=Adatum,DC=com". 

restore subtree dn Dieser Befehl führt eine autorisierende Wiederherstellung einer Verzeichnisunterstruktur 

aus, deren definierter Name von dn angegeben wird. Um beispielsweise eine 

Organisationseinheit wiederherzustellen, können Sie Folgendes eingeben: restore subtree 

"OU=Users,O=App2,DC=Adatum, 

DC=com". 

5. Beenden Sie Dsdbutil, und starten Sie die AD LDS-Instanz neu. 

Konfigurieren der AD DS- und AD LDS-Synchronisierung 

Eine der gängigsten Möglichkeiten zum Integrieren der AD DS mit den AD LDS ist das Verwenden 

von AD DS-Benutzerkonten bei der Konfiguration der Autorisierung in den AD LDS. Um diesen 

Grad der Integration zu implementieren, müssen Sie außer der Installation der AD LDS auf einem 

Computer, der entweder Teil derselben AD DS-Domäne wie die Benutzerkonten ist oder sich in einer 

vertrauenswürdigen Domäne befindet, keine weiteren Schritte ausführen. Bei Installation als Domänenmitglied 

können die AD DS-Benutzerkonten Zugriffsteuerungslisten in den AD LSD direkt zugewiesen 

oder AD LDS-Gruppen hinzugefügt werden, die Zugriffsteuerungslisten zugewiesen sind.


Eine weitere Möglichkeit der Integration der AD DS und AD LDS ist die Konfiguration der Synchronisierung 

zwischen den AD DS und AD LDS, wodurch der Verwaltungsaufwand für die AD DS- 

Instanz signifikant reduziert werden kann. Wenn Sie beispielsweise die AD LDS in einem Umkreisnetzwerk 

bereitstellen, sollten Sie die AD LDS nicht auf einem Server installieren, der Mitglied einer 

internen Domäne ist. Sie können jedoch weiter interne Benutzerkonten verwenden, um den AD LDS- 

Daten Berechtigungen zuzuweisen, oder die mit den AD LDS arbeitende Anwendung benötigt ggf. 

die internen Konten. Durch Konfigurieren der Synchronisierung zwischen den AD DS und AD LDS 

können Sie das Erstellen der Benutzerkonten in der AD LDS-Instanz automatisieren. 

Adamsync und Exchange Server 2007 

Eines der interessantesten Szenarien, in denen Adamsync implementiert werden kann, ist die 

Bereitstellung von Servern mit Exchange Server 2007, auf denen die Serverfunktion Edge-Transport 

ausgeführt wird. Die Serverfunktion Edge-Transport wird auf Servern im Umkreisnetzwerk 

und auf Servern bereitgestellt, die kein Mitglied Ihrer AD DS-Domäne sind. Die Edge-Transport- 

Server nutzen die AD LDS zum Speichern von Konfigurationsinformationen für die Implementierung 

der Spamfilterung sowie anderer Konfigurationsdaten. 

Um die Spamfilterung basierend auf bestimmten Benutzernamen oder von einzelnen Benutzern 

konfigurierten Listen sicherer Absender zu implementieren, müssen Sie Daten aus den AD DS in 

die AD LDS-Instanz replizieren, die von der Serverfunktion Edge-Transport verwendet werden. 

Hierzu können Sie Adamsync konfigurieren. Exchange Server 2007 bietet Windows PowerShell- 

Skripts für die Implementierung der Adamsync-Synchronisierung. Wenn Ihr Unternehmen die 

Implementierung der Adamsync-Synchronisierung für eine andere Anwendung plant und die 

Anwendung keine vergleichbaren Skripts bereitstellt, können Sie ggf. die Exchange-Skripts zum 

Automatisieren der Adamsync-Synchronisierung anpassen. 

Um eine AD LDS-Instanz für die Synchronisierung vorzubereiten, müssen Sie zuerst sicherstellen, 

dass die benötigten Schemaerweiterungen in die AD LDS-Instanz installiert wurden. Zum Ermöglichen 

der Synchronisierung müssen Sie die Datei MS-adamschemaw2k3.ldf (für die Synchronisierung 

mit Windows Server 2003 Active Directory) bzw. MS-adamschemaw2k8.ldf (für die Synchronisierung 

mit den Windows Server 2008-AD DS) hinzufügen. Außerdem müssen Sie dem AD LDS- 

Schema die Datei MS-AsamSyncMetadata.ldf hinzufügen. 

Aus der Praxis: Erstellen von LDF-Dateien mit ADSchemaAnaylzer 

Eines der Probleme, die bei der Implementierung von Adamsync auftreten können, ist, dass Sie 

ggf. das AD DS-Schema bearbeitet haben. Die Dateien MS-adamschemaw2k3.ldf und MSadamschemaw2k8.ldf 

enthalten nur die zu Windows Server 2003 bzw. Windows Server 2008 gehörenden 

Standardschemaobjekte. Wenn Sie Änderungen am AD DS-Schema vorgenommen oder 

verzeichnisfähige Anwendungen wie Exchange Server 2007 implementiert haben, können Sie diese 

Dateien nicht ohne Weiteres in die AD LDS importieren. 

Um eine LDF-Datei zu erstellen, die alle Schemaänderungen an Ihrer AD DS-Gesamtstruktur enthält, 

können Sie ADSchemaAnaylzer verwenden. Dieses Programm wird mit den AD LDS-Verwaltungsprogrammen 

installiert und befindet sich im Ordner %windir%/ADAM. Mit ADSchema- 

Anaylzer können Sie das Zielschema von einem Domänencontroller in Ihrer Domäne und 

anschließend das Basisschema aus der AD LDS-Instanz laden.

Konfigurieren der AD DS- und AD LDS-Synchronisierung 645 

Beim Import des AD LDS-Schemas werden beide von ADSchemaAnalyzer verglichen und auf 

Unterschiede untersucht. Fügen Sie anschließend über die Option Alle nicht vorhandenen Elemente 

als eingeschlossen markieren im Menü Schema die Unterschiede einer LDF-Datei hinzu. Sie 

können anschließend die Datei erstellen und speichern und über den Befehl Ldifde in die AD LDS- 

Instanz importieren. 

Weitere Einzelheiten zu ADSchemaAnalyzer finden Sie im ADSchemaAnalyzer-Artikel unter 

http://technet2.microsoft.com/windowsserver/de/library/7fac5191-27d3-43dd-99c6- 

bb8ad044e7b91031.mspx?mfr=true. 

Führen Sie zum Implementieren der Adamsync-Synchronisierung die folgenden Schritte aus: 

1. Um die LDF-Dateien dem Schema hinzuzufügen, öffnen Sie eine Eingabeaufforderung, wechseln 

zum Verzeichnis %windir%\ADAM und rufen dann den folgenden Befehl auf: 

ldifde -i -u -f LDF-Dateiname -s Server:Port -b Benutzername Domäne Kennwort 

-j . -c "cn=Configuration,dc=X" #configurationNamingContext 

Ersetzen Sie bei diesem Befehl Name der LDF-Datei durch MS-adamschemaw2k3.ldf (zum 

Import des Windows Server 2003-Schemas) oder MS-adamschemaw2k8.ldf (zum Import des 

Windows Server 2008-Schemas). 

2. Rufen Sie zum Hinzufügen der Datei


Hinweis Sie können keine weitere Einstellungen in der Datei zum Festlegen der in die AD LDS zu 

replizierenden Attribute definieren. Eine vollständige Beschreibung der Dateisyntax finden Sie in „Referenz 

zu XML-Elementen der "Adamsync"-Konfigurationsdatei“ unter http://technet2.microsoft.com/WindowsServer/de/Library/d4b6dbdc-eb53-4229-9118-b7d80c9125671031.mspx?mfr=true. 

5. Der nächste Schritt ist die Vorbereitung der AD LDS-Instanzen auf die Replikation durch die 

Installation der Adamsync-Instanz. Geben Sie dazu an der Eingabeaufforderung den folgenden 

Befehl ein, wobei XML-Datei der Name der Datei ist, die Sie im vorherigen Schritt erstellt haben: 

adamsync /install Server:Port .\XML-Datei 

Befindet sich diese Datei nicht im Verzeichnis %windir%\ADAM, müssen Sie den vollständigen 

Pfad zu der Datei angeben. 

6. Geben Sie nach Ausführung des Befehls Adamsync /install den folgenden Befehl ein, wobei XML- 

Datei der Name der Datei ist, die Sie im vorherigen Schritt verwendet haben: 

adamsync /delete .\XML-Datei 

Dieser Befehl löscht die Konfigurationsdatei aus der ADAM-Instanz. Dies ist erforderlich, wenn 

der Benutzer die XML-Datei aktualisieren oder den Synchronisierungsprozess neu starten muss. 

7. Nach Vorbereitung der AD LDS-Instanz für die Synchronisierung können Sie die Synchronisierung 

aus der angegebenen AD DS-Gesamtstruktur in die AD LDS-Instanz einleiten. Geben Sie 

dazu den folgenden Befehl ein, wobei configuration_dn der Stamm der Anwendungsverzeichnispartition 

ist, mit der Sie die Datei synchronisieren: 

adamsync /sync Server:Port configuration_dn /log Adamsynclog.txt 

Hinweis Sie können weitere Synchronisierungsaufgaben ausführen, z.B. die AD LDS auf in den AD DS 

gelöschte Objekte durchsuchen oder nur bestimmte Objekte mit Adamsync synchronisieren. Um eine vollständige 

Liste der für Adamsync verfügbaren Optionen zu erhalten, geben Sie Adamsync /? in eine Eingabeaufforderung 

mit Fokus auf %windir%\ADAM ein, oder konsultieren Sie die Onlinehilfe zur AD LDS- 

Verwaltungskonsole. 


Die AD LDS sollen die Funktionalität der AD DS ergänzen, indem ein den AD DS sehr ähnlicher 

Verzeichnisdienst zur Verfügung gestellt wird, der ein anwendungsspezifisches Verzeichnis bereitstellt. 

Die AD LDS bieten wesentlich mehr Flexibilität als die AD DS, da Sie mehrere Instanzen auf 

einem einzelnen Computer ausführen können, wodurch mehrere Schema- und Anwendungspartitionen 

auf nur einem Server möglich werden. 


• Um die AD LDS-Replikationssicherheit zu gewährleisten, wählen Sie die höchsten Grad an 

Replikationssicherheit, den Ihre Umgebung unterstützen kann. Wenn Sie als AD LDS-Dienstkonto 

das Domänenkonto verwenden, müssen Sie sicherstellen, dass es mit einem sehr komplexen 

Kennwort konfiguriert ist. 

• Führen Sie die AD LDS in AD DS-Umgebungen nach Möglichkeit auf Mitgliedsservern und 

nicht auf Domänencontrollern aus. Wenn Sie die AD LDS auf einem Domänencontroller in einer 

Active Directory-Umgebung ausführen, verwenden Sie als AD LDS-Dienstkonto nicht das Konto 

Netzwerkdienst. Wählen Sie stattdessen ein Domänenbenutzerkonto ohne Administratorrechte.





• In Kapitel 4, „Active Directory-Domänendienstreplikation“, wird die AD DS-Replikation im 

Detail behandelt. Die meisten Konzepte und Konfigurationsaufgaben gelten auch für die Konfiguration 

der AD LDS-Replikation. 

• Die Unterwebsite Active Directory Lightweight Directory Services der technischen Bibliothek 

für Windows Server 2008 bietet technische Informationen und schrittweise Anleitungen zur 

Implementierung der AD LDS in einer Testumgebung. Diese Website finden Sie unter 

http://technet2.microsoft.com/windowsserver2008/de/library/9d4b4004-9f26-4545-a1e4- 

8e527102f0a71031.mspx?mfr=true. 

• Die technische Bibliothek zum Active Directory-Anwendungsmodus (ADAM) unter 

http://technet2.microsoft.com/WindowsServer/de/Library/d4b6dbdc-eb53-4229-9118- 

b7d80c9125671031.mspx?mfr=true bietet Einzelheiten zur Implementierung von ADAM unter 

Windows Server 2003. Die meisten dieser Konzepte wurden für Windows Server 2008 nicht 

wesentlich geändert. 

• Der Artikel „Schrittweise Anleitung zu den ersten Schritten mit Active Directory Lightweight 

Directory Services“ unter http://technet2.microsoft.com/windowsserver2008/de/library/9d4b4004- 

9f26-4545-a1e4-8e527102f0a71031.mspx?mfr=true enthält detailliert beschriebene Schritte zur 

Konfiguration von Benutzer- und Gruppenkonten in den AD LDS. 

• Der Knowledge Base-Artikel „Verwenden von Dsacls.exe unter Windows Server 2003 und 

Windows 2000“ unter http://support.microsoft.com/kb/281146, bietet detaillierte Informationen 

zum Verwalten von Berechtigungen mithilfe von Dsacls.exe. 

• Eine vollständige Beschreibung der Dateisyntax von Adamsync finden Sie in „Referenz zu XML- 

Elementen der "Adamsync"-Konfigurationsdatei“ unter http://technet2.microsoft.com/Windows- 

Server/de/Library/d4b6dbdc-eb53-4229-9118-b7d80c9125671031.mspx?mfr=true. 


Windows Server 2008 bietet mehrere Tools, die zur Verwaltung der AD LDS eingesetzt werden können. 

In Tabelle 16-11 finden Sie einige dieser Tools und ihre Einsatzmöglichkeiten. 

Tabelle 16.11 

AD LDS-Verwaltungstools 

Toolname 

Setup-Assistent für Active Directory Lightweight 

Directory Services 

Active Directory-Standorte und -Dienste 

Dsdbutil.exe 

ADSI Edit 

Ldp.exe 


Dient zum Konfigurieren von AD LDS-Instanzen und -Replikaten 

Dient zum Konfigurieren von AD LDS-Standorten und -Replikation 

Dient zum Verwalten der AD LDS-Datenspeicherdateien und Verwalten der 

AD LDS-Servereinstellungen 

Dient zum Anzeigen und Ändern des Inhalts von AD LDS-Partitionen 

Dient zum Anzeigen und Ändern des Inhalts von AD LDS-Partitionen



• DisplayADLDSInstances.ps1 ist ein Windows PowerShell-Skript, das alle Namenskontexte bzw. 

Partitionen auf Ihrem AD LDS-Server angibt. 

• AdatumSync.xml ist eine vorkonfigurierte XML-Datei zur Veranschaulichung des Formats der 

AdamSync-Konfigurationsdatei. 


• „Prüfliste: Verwalten von Gruppenmitgliedschaften” in der Active Directory Lightweight Directory 

Services-Hilfe 

• „Arbeiten mit Authentifizierung und Zugriffssteuerung“ in der Active Directory Lightweight 

Directory Services-Hilfe 

• „Prüfliste: Synchronisieren von Daten von AD DS nach AD LDS“ in der Active Directory Lightweight 

Directory Services-Hilfe

649 

K A P I T E L 1 7 

Active Directory-Zertifikatdienste 


Active Directory-Zertifikatdienste – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 

Implementieren der AD CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658 

Verwalten von Zertifikaten in den AC CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672 

Entwerfen einer AD CS-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 




Die Active Directory-Zertifikatdienste (AD CS) sind die Microsoft-Implementierung einer Public 

Key-Infrastruktur (PKI). Die PKI ist die Basis der Komponenten und Prozesse zum Ausstellen und 

Verwalten digitaler Zertifikate für Verschlüsselungs- und Authentifizierungszwecke. Die AD CS müssen 

nicht als Teil einer Windows Server 2008-Active Directory-Struktur implementiert werden. Doch 

viele Unternehmen finden es nützlich, diese Dienste intern bereitzustellen, anstatt mit einem externen 

Anbieter zusammenzuarbeiten. 

Dieses Kapitel beginnt mit einer Übersicht über die AD CS und ihre Verwendungsmöglichkeiten. 

Anschließend wird die Implementierung der AD CS und die Verwaltung der von den AD CS ausgestellten 

Zertifikaten behandelt. Schließlich wird der allgemeine Entwurf einer AD CS-Implementierung 

untersucht. 

Active Directory-Zertifikatdienste – Übersicht 

Die AD CS sind eine Komponente von Windows Server 2008 zum Ausstellen und Verwalten digitaler 

Zertifikate. Die von den AD CS ausgestellten digitalen Zertifikate können für das verschlüsselnde 

Dateisystem (Encrypting File System, EFS), die E-Mail-Verschlüsselung, SSL (Secure Sockets 

Layer) und die Authentifizierung verwendet werden. Ein Server, auf dem die AD CS installiert sind, 

wird als Zertifizierungsstelle bezeichnet. 

Digitale Zertifikate werden für die asymmetrische Verschlüsselung verwendet, die zwei Schlüssel 

erfordert. Der erste Schlüssel ist der private Schlüssel, der vom Benutzer oder Computer, für den ein 

digitales Zertifikat ausgestellt wurde, sicher gespeichert wird. Der zweite Schlüssel ist der öffentliche 

Schlüssel, der an andere Benutzer und Computer verteilt wird. Die von dem einen Schlüssel verschlüsselten 

Daten können nur mit dem anderen Schlüssel entschlüsselt werden. Diese Beziehung 

gewährleistet den Schutz der verschlüsselten Daten. Jeder Schlüssel ist ausreichend groß, um die 

Berechnung des privaten Schlüssels bei Besitz des öffentlichen Schlüssels zu verhindern.

650 Kapitel 17: Active Directory-Zertifikatdienste 

Komponenten der Public Key-Infrastruktur 

Die Public Key-Infrastruktur (PKI) besteht im Allgemeinen aus verschiedenen Komponenten wie 

Zertifizierungsstellen, Verwaltungsprogrammen und Zertifikatsperrlisten. Zusätzlich zu diesen allgemeinen 

PKI-Komponenten bieten die AD CS auch Zertifikatvorlagen, die zum Automatisieren der 

Ausstellung von Zertifikaten an Benutzer und Computer verwendet werden können. 

Verwaltungsprogramme für Zertifikate und Zertifizierungsstellen 

Windows Server 2008 bietet verschiedene grafische und Befehlszeilenprogramme für die Verwaltung 

von Zertifikaten und Zertifizierungsstellen. Die meisten Aufgaben zur Verwaltung von Clientzertifikaten 

werden mit dem MMC-Snap-In Zertifikate ausgeführt (siehe Abbildung 17.1). Mit diesem 

Snap-In können die Zertifikate für Benutzer, den lokalen Computer oder Dienste verwaltet werden. 

Zu den Verwaltungsaufgaben zählen das Generieren einer Zertifikatsanforderung, das Installieren 

neuer Zertifikate, das Erneuern von Zertifikaten, das Installieren vertrauenswürdiger Stammzertifikate 

und das Exportieren zu sichernder Zertifikate. Das Befehlszeilenprogramm Certreq.exe dient 

zum Automatisieren der Generierung von Zertifikatanforderungen. Dieses Dienstprogramm kann 

auch in Skripts verwendet werden. 

Hinweis Das Snap-In Zertifikate steht auch auf Windows Vista- und Windows XP-Computern zur Verfügung. 

Das Dienstprogramm Certreq.exe gehört zum Funktionsumfang von Windows Vista und Windows 

Server 2003 Service Pack 1 Administration Tools Pack. 


Das MMC-Snap-In Zertifikate

Active Directory-Zertifikatdienste – Übersicht 651 

Direkt von der Quelle: Aktivieren der CryptoAPI 2.0-Diagnoseprotokollierung 

Windows Vista und Windows Server 2008 bieten die neue integrierte Funktion CryptoAPI 2.0- 

Diagnose, mit der Probleme mit der Public Key-Infrastruktur behandelt werden können. In 

früheren Windows-Versionen wurden nur bestimmte Ereignisse hinsichtlich der PKI in den Ereignisprotokollen 

aufgezeichnet. Die neue Diagnoseprotokollierung ermöglicht PKI-Administratoren 

und Anwendungsentwicklern die Erfassung detaillierter Ereignisse bei den APIs (Application Programming 

Interfaces, Schnittstellen für Anwendungsprogrammierung), die von der PKI im Verlauf 

von Vorgängen wie u.a. der Prüfung auf Zertifikatsperren, Zertifikatsverkettung und Öffnung eines 

Zertifikatspeichers verwendet werden. 

Es gibt verschiedene Möglichkeiten zum Aktivieren der Diagnoseprotokollierung. In der Ereignisanzeige 

können Administratoren zum folgenden Speicherort wechseln: 

Klicken Sie hier mit der rechten Maustaste auf Betriebsbereit, und wählen Sie die Option Protokoll 

aktivieren aus. 

Eine weitere Methode zum Aktivieren bzw. Deaktivieren der Protokollierung bietet das Befehlszeilenprogramm 

Wevutil.exe. Um die Protokollierung zu aktivieren, geben Sie folgenden Befehl ein: 

Wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true 

Um die Protokollierung zu deaktivieren, geben Sie folgenden Befehl ein: 

Wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false 

Bei aktivierter Diagnoseprotokollierung werden im Betriebsprotokoll detaillierte Ereignisse angezeigt. 

Ein Administrator kann anschließend das Protokoll nach relevanten Ereignissen filtern oder 

es als benutzerdefinierte Ansicht speichern, um künftige Ereignisse zu überwachen.


Weitere Informationen zu Wevtutil.exe finden Sie unter http://technet2.microsoft.com/ 

windowsserver2008/en/library/d4c791e0-7e59-45c5-aa55-0223b77a48221033.mspx?mfr=true. 

Bob Drake 

Microsoft Directory Services Team 

Das in Abbildung 17.2 gezeigte Snap-In Zertifizierungsstelle dient zum Verwalten von Zertifizierungsstellen, 

die auf den AD CS basieren. In diesem Snap-In können Sie ausgestellte und gesperrte 

Zertifikate, ausstehende und fehlgeschlagene Zertifikatanforderungen und Zertifikatvorlagen anzeigen. 

Sie können auch ausstehende Zertifikatanforderungen anzeigen und genehmigen sowie Zertifikate 

sperren, deren Sicherheit gefährdet ist. Schließlich können Sie die Eigenschaften der Zertifizierungsstelle 

anzeigen und ändern. 


Das MMC-Snap-In Zertifizierungsstelle 

Das in Abbildung 17.3 gezeigte Snap-In Unternehmens-PKI dient zum Anzeigen des Status von Zertifizierungsstellen 

in einem Unternehmen. Der Status mehrerer Zertifizierungsstelle kann schnell 

erfasst, und potenzielle Probleme können detailliert untersucht werden. Dieses Snap-In war in den 

Tools von „Windows Server 2003 – Die technische Referenz“ als PKIView enthalten. 

Mit dem Befehlszeilenprogramm Certutil.exe können Sie nahezu dieselben Aufgaben wie mit den 

Snap-Ins Zertifikate und Zertifizierungsstelle ausführen. Dieses Programm kann jedoch in Skripts eingesetzt 

werden, um die Zertifikatverwaltung auf Servern und Arbeitsstationen zu automatisieren. Mit 

Certutil.exe können auch Aufgaben zur Verwaltung von Zertifizierungsstellen ausgeführt werden.



Das MMC-Snap-In Unternehmens-PKI 

Digitale Zertifikate 

Während die PKI die Verwendung von sowohl einem öffentlichen als auch einem privaten Schlüssel 

erfordert, ist in einem Zertifikat nur der öffentliche Schlüssel enthalten. Dadurch kann das Zertifikat 

öffentlich verteilt und zur Überprüfung zur Verfügung gestellt werden. Der private Schlüssel befindet 

sich in der für öffentliche Schlüssel fähigen Anwendung oder auf dem lokalen Computer. Windows 

speichert private Schlüssel in Benutzerprofilen. 

Das digitale Zertifikat enthält Informationen zum Antragsteller, der das Zertifizierungsstelle angefordert 

hat. Dadurch können Zertifikate zum Überprüfen der Identität der Person oder des Computers 

verwendet werden, zu der/dem der private Schlüssel gehört. Ein digitales Zertifikat für einen Webserver 

enthält beispielsweise den Hostnamen oder die IP-Adresse des Webservers. Informationen zur 

Zertifizierungsstelle, die das Zertifikat ausgestellt hat, sind ebenfalls enthalten, um die Überprüfung 

der Gültigkeit dieser Zertifizierungsstelle zu ermöglichen. 

Zertifikate enthalten auch Informationen zu ihrem Zweck und zum Zeitraum, in dem sie gültig sind. 

Ein Zertifikat kann beispielsweise auf die Nutzung für das verschlüsselnde Dateisystem (EFS) 

beschränkt werden. Zertifikate sind nur für einen bestimmten Zeitraum gültig, der in der Regel 

maximal zwei Jahre beträgt. Nach Ablauf dieses Zeitraums kann ein Zertifikat nicht mehr verwendet 

werden. 

Weitere Informationen Das spezifische Format von Zertifikaten, die von einer Windows Server 2008-Zertifizierungsstelle 

ausgestellt werden, ist X.509, Version 3. Detaillierte Informationen zu X.509, Version 3, und 

zur PKI finden Sie in „RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation 

List (CRL) Profile“ unter http://www.ietf.org/rfc/rfc3280.txt.


Zertifizierungsstellen 

Zertifizierungsstellen sind die PKI-Komponenten, die digitale Zertifikate für Benutzer und Computer ausstellen. 

Wenn Unternehmen digitale Zertifikate implementieren, muss festgelegt werden, ob mithilfe der 

AD CS eine interne Zertifizierungsstelle eingerichtet oder eine externe Zertifizierungsstelle eingesetzt 

werden soll. Der Hauptvorteil einer internen Zertifizierungsstelle ist die Wirtschaftlichkeit, da für jedes 

ausgestellte Zertifikat keine zusätzlichen Kosten anfallen. Im Gegensatz dazu wird bei Verwenden einer 

externen Zertifizierungsstelle eine Gebühr für jedes ausgestellte Zertifikat erhoben. Wenn Hunderte oder 

Tausende von Zertifikaten ausgestellt werden, kann dieser Faktor eine große Rolle spielen. Doch für einfache 

Anwendungsbereiche, z.B. ein SSL-Zertifikat für einen Einzelserver, übersteigen die Verwaltungskosten 

für den Betrieb einer Zertifizierungsstelle zumeist die Kosten des Zertifikats selbst. 

Wenn Sie Dienste unter Verwendung digitaler Zertifikate für externe Clients implementieren, wird einer 

internen Zertifizierungsstelle von externen Clients nicht automatisch vertraut. Wird einer internen Zertifizierungsstelle 

von externen Clients nicht vertraut, zeigt die Anwendung Warnmeldungen an oder funktioniert 

überhaupt nicht. Ein Beispiel einer Warnmeldung sehen Sie in Abbildung 17.4. Internen Zertifizierungsstellen 

wird von internen Clients automatisch vertraut, da das vertrauenswürdige Stammzertifikat der 

internen Zertifizierungsstelle an Domänenmitglieder verteilt wird. Interne und externe Clients vertrauen 

vielen externen Zertifizierungsstellen automatisch. Externe Zertifizierungsstellen, die zum Microsoft- 

Stammzertifikatsprogramm gehören, wird von Windows-Betriebssystemen automatisch vertraut. 


Fehlermeldung aufgrund eines Zertifikats einer nicht vertrauenswürdigen Zertifizierungsstelle

Zertifikatsperrlisten 


Hinweis Das vertrauenswürdige Stammzertifikat einer internen Zertifizierungsstelle wird bei Verwenden 

einer Stammzertifizierungsstelle des Unternehmens über Gruppenrichtlinien automatisch an Clients verteilt. 

Andernfalls können Sie eine Gruppenrichtlinie manuell so konfigurieren, dass das vertrauenswürdige 

Stammzertifikat verteilt wird. 

Eine Zertifikatsperrliste enthält Zertifikate, die vor ihrem Ablaufdatum von einem Administrator 

gesperrt wurden. Dies kann immer dann erfolgen, wenn ein Zertifikat nicht mehr vertrauenswürdig ist 

oder nicht mehr benötigt wird. Bei einem Geschäftspartner, der ein Zertifikat für Authentifizierungszwecke 

nutzt, kann das Zertifikat beispielsweise gesperrt werden, wenn die Geschäftsbeziehung nicht 

mehr besteht. Ein Zertifikat kann auch gesperrt werden, wenn die Sicherheit des privaten Schlüssels 

des Zertifikats gefährdet ist. 

Zertifikatvorlagen 

Zertifikatvorlagen dienen zum Steuern der Erstellung von Zertifikaten. Mithilfe von Zertifikatvorlagen 

wird eine Vielzahl von Zertifikateigenschaften festgelegt, z.B. Zweck, Gültigkeitszeitraum, 

Erneuerungszeitraum, Kryptografiedienstanbieter, Format des Antragstellernamens und hinzugefügte 

Erweiterungen. Zertifikatvorlagen können auch zum Automatisieren des Registrierungsprozesses für 

Zertifikate dienen, indem festgelegt wird, welche Benutzer Zugriff auf die Vorlage haben. Sie können 

auch Regeln für die Erneuerung festlegen. 

Verteilungspunkte für Zertifikate und Zertifikatsperrlisten 

Verteilungspunkte sind Stellen, an denen Benutzer und Computer auf Zertifikate und Zertifikatsperrlisten 

zugreifen können. Für Zertifikate kann Active Directory als Verteilungspunkt dienen, über den 

Zertifikate veröffentlicht werden. Wird das Snap-In Zertifikate zum Anfordern eines Zertifikats von 

einer Unternehmenszertifizierungsstelle verwendet, wird die Antwort automatisch abgerufen und von 

diesem Snap-In installiert. Wenn eine Zertifikatanforderung über die Webregistrierung erfolgt, wird 

die Antwort von der Zertifikatdienstwebsite abgerufen. 

Zertifikatsperrlisten werden regelmäßig von Computern heruntergeladen, um sicherzustellen, dass sie 

über eine aktuelle Liste gesperrter Zertifikate verfügen, denen nicht vertraut werden darf, auch wenn 

die Zertifikate nicht abgelaufen sind. Frühere Windows Server-Versionen verteilten die Zertifikatsperrliste, 

indem diese auf der Zertifikatdienstwebsite und in Active Directory zur Verfügung 

gestellt wurden. Die AD CS unter Windows Server 2008 unterstützen diese beiden Methoden sowie 

das OSCP (Online Certificate Status Protocol). 

Public Key-Infrastrukturfähige Anwendungen 

Um Zertifikate für die Verschlüsselung oder digitale Signaturen verwenden zu können, müssen Ihre 

Anwendungen die PKI unterstützen. Um beispielsweise E-Mails mit einer digitalen Signatur senden 

zu können, muss der E-Mail-Client Zertifikate unterstützen. Darüber hinaus muss der Webserver Zertifikate 

zum Verschlüsseln von Verbindungen mithilfe von SSL (Secure Sockets Layer) unterstützen. 

Ist eine Anwendung nicht PKI-fähig, können Sie für Verschlüsselung und digitale Signaturen keine 

Zertifikate nutzen.


Zertifizierungsstellen 

Eine Zertifizierungsstelle ist für die Ausstellung von Zertifikaten zuständig. Im Rahmen dieses Prozesses 

wird die Identität des Anforderers überprüft, was manuell oder automatisch erfolgen kann. Die 

manuelle Überprüfung verhindert die automatische Ausstellung von Zertifikaten und erfordert das 

Eingreifen eines Administrators. Die manuelle Überprüfung kann beispielsweise erforderlich machen, 

dass ein Administrator vor Ausstellung eines Zertifikats das Beschäftigungsverhältnis überprüft. Windows 

Server 2008-Zertifizierungsstellen können (ebenso wie Windows 2000 Server- und Windows 

Server 2003-Zertifizierungsstellen) in Kombination mit Zertifikatvorlagen den Status automatisch 

überprüfen. Wenn sich ein Benutzer anmeldet und über die benötigten Berechtigungen für den Zugriff 

auf eine Vorlage verfügt, wird der Überprüfungsprozess für den Benutzer und Administrator automatisiert. 

Zertifizierungsstellen sind auch für die Verwaltung der Zertifikatsperrung zuständig. Das Sperren 

eines Zertifikats wird von einem Administrator manuell ausgelöst. Nachdem das Zertifikat gesperrt 

wurde, veröffentlicht die Zertifizierungsstelle diese Sperrung in der Zertifikatsperrliste und stellt den 

Zertifikatstatus über OCSP zur Verfügung. 

Hierarchie von Zertifizierungsstellen 

Das Thema „Vertrauen“ steht bei der Planung der Implementierung der PKI im Mittelpunkt. Insbesondere 

den Zertifikate ausstellenden Zertifizierungsstellen muss von den Clients vertraut werden, die 

diese Zertifikate verwenden. Windows-Clients führen eine Liste vertrauenswürdiger Stammzertifizierungsstellen. 

Von einer vertrauenswürdigen Stammzertifizierungsstelle ausgestellten Zertifikaten wird 

von Windows-Clients vertraut. Windows-Clients vertrauen außerdem Zertifikaten, die von den vertrauenswürdigen 

Stammzertifizierungsstellen autorisierten Zertifizierungsstellen ausgestellt werden. 

Die erste in Ihrem Unternehmen eingerichtete Windows Server 2008-Zertifizierungsstelle ist eine 

Stammzertifizierungsstelle. Wenn die Stammzertifizierungsstelle eine Unternehmenszertifizierungsstelle 

ist, wird das selbst signierte Zertifikat der Stammzertifizierungsstelle automatisch an die Windows-Clients 

in der Active Directory-Gesamtstruktur als vertrauenswürdiges Stammzertifikat verteilt. 

Deshalb vertrauen Windows-Clients in der Active Directory-Gesamtstruktur automatisch den 

von einer internen Zertifizierungsstelle ausgestellten Zertifikaten. Bei Verwenden einer eigenständigen 

Stammzertifizierungsstelle müssen Sie die Verteilung des vertrauenswürdigen Stammzertifikats 

für die Stammzertifizierungsstelle konfigurieren. 

In kleineren Unternehmen ist ggf. nur eine Zertifizierungsstelle erforderlich. In größeren Unternehmen 

sind u. U. viele Zertifizierungsstelle mit spezifischen Funktionen notwendig. Wird eine zweite 

Windows Server 2008 installiert, wird das Zertifizierungsstellenzertifikat für die zweite Zertifizierungsstelle 

von der vertrauenswürdigen Stammzertifizierungsstelle signiert. Deshalb vertrauen alle 

Windows-Clients in der Active Directory-Gesamtstruktur den von der zweiten Zertifizierungsstelle 

ausgestellten Zertifikaten. Die zweite Zertifizierungsstelle kann eine dritte Zertifizierungsstelle autorisieren, 

deren Zertifikaten auch von den Windows-Clients in der Active Directory-Gesamtstruktur 

vertraut wird. Über diesen Prozess können Sie eine Hierarchie aus Zertifizierungsstellen aufbauen, 

welche die Anforderungen Ihres Unternehmens erfüllt. Alle in einer Hierarchie nach der Stammzertifizierungsstelle 

installierten Zertifizierungsstellen sind untergeordnete Zertifizierungsstellen. 

Unternehmens- und eigenständige Zertifizierungsstellen 

Windows Server 2008-Zertifizierungsstellen können nur als eigenständige oder Unternehmenszertifizierungsstellen 

installiert werden, wobei der Hauptunterschied zwischen beiden die Integration in 

Active Directory ist.


Eine Unternehmenszertifizierungsstelle wird automatisch mit Active Directory integriert. Dies ermöglicht 

die Automatisierung der Zertifikatregistrierung und Hinzufügung der Stamm- und untergeordneten 

Zertifizierungsstellen zu den ordnungsgemäßen Zertifizierungsstellenspeichern auf Domänencomputern. 

Eigenständige Zertifizierungsstellen können nur begrenzt mit Active Directory integriert 

werden (beispielsweise können Konfigurationsdaten in Active Directory veröffentlicht werden), 

wobei die Integration manuell erfolgen muss. Tabelle 17.1 zeigt die Eigenschaften im Detail. 

Tabelle 17.1 

Eigenschaften von Zertifizierungsstellen 

Eigenständige Zertifizierungsstelle 

Konfiguration kann in Active Directory gespeichert werden. 

Das Zertifikat der Zertifizierungsstelle und die Zertifikatsperrliste 

können manuell in Active Directory veröffentlich 

werden. 

Zertifikate werden standardmäßig nur über die Webregistrierung 

ausgestellt. 

Die Benutzerkennung wird manuell vom Benutzer eingegeben. 

Zertifikate werden manuell genehmigt. 

Zertifikate können nicht in Active Directory veröffentlicht 

werden. 

Eigenständige Server können verwendet werden. 

Zertifikatvorlagen werden nicht verwendet. 

Mitglieder der lokalen Gruppe Administratoren haben Installationsrechte. 

Unternehmenszertifizierungsstelle 

Konfiguration wird stets in Active Directory gespeichert. 

Das Zertifikat der Zertifizierungsstelle, die Zertifikatsperrliste 

und die Delta-Zertifikatsperrliste werden automatisch in Active 

Directory veröffentlich. 

Zertifikate werden über die Webregistrierung oder das MMC- 

Snap-In Zertifikate ausgestellt. 

Die Benutzerkennung wird aus Active Directory abgerufen. 

Zertifikate können manuell oder automatisch genehmigt 

werden. 

Zertifikate können automatisch in Active Directory veröffentlicht 

werden. 

Domänenserver müssen verwendet werden. 

Zertifikatvorlagen werden verwendet. 

Nur Mitglieder der Gruppe Unternehmensadministratoren oder 

Domänen-Admins der Stammdomäne der Gesamtstruktur 

haben Installationsrechte. 

Offlinezertifizierungsstellen 

Ist die Sicherheit einer Zertifizierungsstelle gefährdet, gelten auch alle von der Zertifizierungsstelle 

ausgestellten Zertifikate als gefährdet, die deshalb gesperrt werden müssen. Demzufolge ist die 

Sicherheit einer Zertifizierungsstelle von sehr großer Bedeutung. Eine Offlinezertifizierungsstelle bietet 

ein Plus an Sicherheit, da sie nicht mit dem Netzwerk verbunden ist. Eine Offlinezertifizierungsstelle 

ist ferner auch kein Domänenmitglied und kann deshalb keine Unternehmenszertifizierungsstelle 

sein. 

Zertifikatanforderungen an eine Offlinezertifizierungsstelle müssen auf physischen Datenträgern wie 

einer Diskette oder einem USB-Laufwerk erfolgen. Aus diesem Grund ist eine Offlinezertifizierungsstelle 

für das Ausstellen von Zertifikaten an eine große Anzahl von Benutzern nicht sehr praktisch. 

Außerdem verhindert sie die automatische Registrierung bei bzw. Integration mit Active Directory. 

Die meisten Offlinezertifizierungsstellen sind Stammzertifizierungsstellen mit untergeordneten Zertifizierungsstellen 

für die Zertifikatregistrierung. Die untergeordneten Zertifizierungsstellen sind dann 

Unternehmenszertifizierungsstellen, die zum Vereinfachen der Zertifikatregistrierung Active Directory 

und Zertifikatvorlagen verwenden können. 

Hinweis Offlinezertifikatanforderungen können mit Certreq.exe erstellt werden. Windows Vista und Windows 

Server 2008 bieten über das MMC-Snap-In Zertifikate Unterstützung für die Erstellung von Offlinezertifikatanforderungen.


Szenarien für die Bereitstellung der Zertifikatdienste 

Die AD CS werden nur implementiert, wenn Sie eine oder mehrere interne Zertifizierungsstellen 

bereitstellen möchten. Wenn Sie Zertifikate einsetzen möchten, die von einer unternehmensexternen 

Zertifizierungsstelle ausgestellt werden, sind die AD CS nicht notwendig. Eine externe Zertifizierungsstelle 

wird zumeist genutzt, wenn Clients außerhalb des Unternehmens den Zertifikaten vertrauen 

müssen. Eine externe Zertifizierungsstelle kommt zumeist für folgende Zwecke zum Einsatz: 

• Absichern von E-Mail durch Verschlüsselung oder digitale Signaturen 

• Absichern von Websites mit SSL-Zertifikaten 

Eine interne Zertifizierungsstelle eignet sich gut für Clients, die es bereits im Unternehmen gibt 

und die problemlos so konfiguriert werden können, dass sie der internen Zertifizierungsstelle vertrauen. 

Für die folgenden Zwecke können die AD CS als interne Zertifizierungsstelle eingesetzt 

werden: 

Absichern von Dateien mit dem EFS Die AD CS können zum Ausstellen von Zertifikaten für 

alle EFS-Benutzer und zum Erstellen eines Wiederherstellungsschlüssels dienen. Die Schlüsselarchivierung 

und -wiederherstellung ist auch wichtig, wenn das EFS mithilfe der AD CS 

eingerichtet wird. 

Absichern interner Webanwendungen Mithilfe der AD CS können SSL-Zertifikate für interne 

Webserver ausgestellt werden. Die internen Clients vertrauen der internen Zertifizierungsstelle. 

Erhöhen der Sicherheit drahtloser Netzwerke Die AD CS können als Teil des Systems konfiguriert 

werden und die 802.1X-Authentifizierung für drahtlose Geräte durchführen. Bei Aktivierung 

der 802.1X-Authentifizierung werden drahtlose Clients authentifiziert, bevor ihnen der 

Zugriff auf das Netzwerk gestattet wird. Dies wird vom Registrierungsdienst für Netzwerkgeräte 

unterstützt, über den Geräte Zertifikate von den AD CS abrufen können. 

Erhöhen der Sicherheit von Benutzeranmeldungen durch Smartcards Die AD CS können Zertifikate 

ausstellen, die auf Smartcards gespeichert und zum Anmelden verwendet werden. Die 

Sicherheit ist höher, da die Authentifizierung nun auf zwei Faktoren basiert. Die Benutzer 

müssen die Smartcard und eine PIN (persönliche Identifizierungsnummer) vorlegen. Durch 

die Einführung eines eingeschränkten Registrierungs-Agent wurde die Unterstützung von 

Smartcards unter Windows Server 2008 optimiert. Ein autorisierter Benutzer kann nun Smartcards 

für bestimmte Personen oder Gruppen konfigurieren. Ein lokaler IT-Supportmitarbeiter 

kann beispielsweise Smartcards für alle Benutzer an einem Remotestandort konfigurieren. In 

früheren Windows-Versionen konnte ein Registrierungs-Agent nicht eingeschränkt werden. 

Hinweis Der eingeschränkte Registrierungs-Agent steht unter Windows Server 2008 Enterprise zur 

Verfügung. 

Implementieren der AD CS 

Die AD CS sind eine komplexe Komponente mit verschiedenen Optionen für die Implementierung. 

Die Implementierungsoptionen für Stamm- und untergeordnete Zertifizierungsstellen unterscheiden 

sich, weshalb Sie sich mit dem jeweiligen Prozess vertraut machen müssen. Die Webregistrierung 

wird üblicherweise in vielen Umgebungen verwendet und muss konfiguriert werden. Zudem müssen 

Sie auch die Zertifikatsperrung entweder mithilfe von Zertifikatsperrlisten oder OCSP verwalten. 

Schließlich müssen Sie wissen, wie die Schlüsselarchivierung und -wiederherstellung erfolgt.

Installieren von AD CS-Stammzertifizierungsstellen 

Implementieren der AD CS 659 

Die Installationsoptionen für eine Zertifizierungsstelle müssen dokumentiert werden, bevor Sie mit 

der Installation beginnen. Dies stellt sicher, dass während der Installation die ordnungsgemäßen 

Optionen ausgewählt werden, und unterstützt die Wiederherstellung nach einem Ausfall. Fügen Sie 

in Server-Manager die Rolle Active Directory-Zertifikatdienste hinzu. Sie müssen die folgenden 

Optionen festlegen: 

• Rollendienste Der einzige zum Konfigurieren einer Stammzertifizierungsstelle erforderliche Rollendienst 

heißt Zertifizierungsstelle und dient zum Konfigurieren des Servers für die Ausstellung 

von Zertifikaten. Ferner ist Zertifizierungsstellen-Webregistrierung erforderlich, um Zertifikatanforderungen 

anzunehmen und Zertifikate für eine eigenständige Stammzertifizierungsstelle auszustellen. 

Die Protokolle Online Certificate Status Protocol und Microsoft Simple Certificate 

Enrollment Protocol werden eher für untergeordnete Zertifizierungsstellen und nicht für die 

Stammzertifizierungsstelle installiert. 

• Installationstyp Der Installationstyp wird als Unternehmen oder Eigenständig angegeben. Wenn 

die Stammzertifizierungsstelle als Offline-Stammzertifizierungsstelle eingerichtet werden soll, 

wählen Sie Eigenständig. Ein Wechsel zwischen einer Unternehmens- und einer eigenständigen 

Zertifizierungsstelle ist möglich, wofür jedoch eine Neuinstallation und Wiederherstellung aus 

einer Sicherung erforderlich ist. 

• Zertifizierungsstellentyp Der Zertifizierungsstellentyp wird als Stammzertifizierungsstelle oder 

Untergeordnete Zertifizierungsstelle angegeben. Stammzertifizierungsstelle wird beim Installieren 

der ersten Zertifizierungsstelle in der Hierarchie ausgewählt. 

• Privater Schlüssel Sie können einen neuen privaten Schlüssel erstellen oder einen vorhandenen 

privaten Schlüssel verwenden. Erstellen Sie bei der Installation einer neuen Stammzertifizierungsstelle 

einen neuen privaten Schlüssel. Verwenden Sie beim Wiederherstellen einer ausgefallenen 

Zertifizierungsstelle einen vorhandenen privaten Schlüssel. 

• Kryptografie Sie müssen den Kryptografiedienstanbieter, Hashalgorithmus und die Schlüssellänge 

auswählen. Stellen Sie sicher, dass die gewählten Einstellungen mit anderen Systemen 

kompatibel sind, mit denen diese Zertifizierungsstelle kommunizieren muss. Einige Zertifizierungsstellen 

von Drittanbietern weisen beispielsweise eine maximale Schlüssellänge von 

2048 Bits auf. 

Hinweis Die integrierten Kryptografiedienstanbieter sind für die meisten Zwecke ausreichend, doch 

können Entwickler nach Wunsch eigene entwickeln, was häufig von Smartcardherstellern vorgenommen 

wird. Weitere Informationen zum Entwickeln von Kryptografiedienstanbietern finden Sie in „Writing 

a CSP“ unter http://msdn2.microsoft.com/en-us/library/aa388213(VS.85).aspx. 

• Zertifizierungsstellenname Sie sollten eine Standardbenennungsrichtlinie für sämtliche Zertifizierungsstellen 

festlegen. Der Zertifizierungsstellenname darf maximal 64 Zeichen haben. Standardmäßig 

enthält der Zertifizierungsstellenname den Computernamen, was aber nicht erforderlich ist. 

Der vollständig qualifizierte Domänenname der Zertifizierungsstelle darf nicht als Zertifizierungsstellenname 

gewählt werden, um zu verhindern, dass böswillige Benutzer die Stammzertifizierungsstelle 

eines Unternehmens einfach herausfinden. 

• Gültigkeitsdauer Der wichtigste Punkt bei der Gültigkeitsdauer ist, dass eine Zertifizierungsstelle 

keine Zertifikate ausstellen kann, die länger gültig sind als ihr eigenes Zertifikat.


Die Standardgültigkeitsdauer ist fünf Jahre, weshalb an untergeordnete Zertifizierungsstellen und 

Clients ausgestellte Zertifikate maximal fünf Jahre ab dem Datum der Installation der Stammzertifizierungsstelle 

gültig sind. Um für mehr Flexibilität zu sorgen, wird die Gültigkeitsdauer einer 

Stammzertifizierungsstelle häufig auf 10 oder gar 20 Jahre verlängert. Sie können das Zertifikat 

der Stammzertifizierungsstelle jederzeit über die Zertifikatdienst-Webseiten oder das MMC-Snap- 

In Zertifizierungsstelle erneuern. 

• Datenbank und Protokolldatei Eine Stammzertifizierungsstelle stellt zumeist nur wenige Zertifikate 

aus. Demzufolge wird die Systemleistung nicht beeinträchtigt, wenn der Standardspeicherort 

der Datenbank- und Protokolldateien auf dem Laufwerk %SystemRoot% übernommen wird. In 

der Datenbank werden von der Zertifizierungsstelle ausgestellte Zertifikate, von der Zertifizierungsstelle 

archivierte private Schlüssel und gesperrte Zertifikate und alle jemals von der Zertifizierungsstelle 

empfangenen Zertifikatanforderungen gespeichert. 

Hinweis Nach der Installation der AD CS kann der Name eines Servers nicht geändert werden. Um den 

Namen eines Servers zu ändern, müssen die AD CS deinstalliert, der Name geändert und die AD CS neu 

installiert werden. 

CAPolicy.inf 

Um eine standardisierte Installation von Zertifizierungsstellen zu gewährleisten, können Sie die Datei 

CAPolicy.inf verwenden. Diese Datei enthält Einstellungen, die während der Installation und Erneuerung 

einer Zertifizierungsstelle nach deren Ablage im Ordner %Windir% gelesen werden. Sie können 

die folgenden Einstellungen festlegen: 

• Zertifikatverwendungserklärung Diese Texterklärung beschreibt den Prozess der Ausstellung 

von Zertifikaten und wird im Zertifikat der Zertifizierungsstelle angezeigt, was jedoch nicht erforderlich 

ist. Um eine Zertifikatverwendungserklärung zu implementieren, müssen Sie die Datei 

CAPolicy.inf verwenden. Aus praktischen Gründen wird häufig eine URL hinzugefügt, die auf 

eine vollständige Zertifikatverwendungserklärung zeigt, sodass deren Text nicht hinzugefügt werden 

muss. 

• Veröffentlichungsintervall der Sperrliste Über diese Option können Sie festlegen, wie oft die Zertifikatsperrliste 

für diese Zertifizierungsstelle während der Installation aktualisiert wird. Sie können 

diese Einstellung auch im MMC-Snap-In Zertifizierungsstelle ändern. 

• Erneuerungseinstellungen für Zertifizierungsstellen Bei der Erneuerung eines Zertifikats mit dem 

MMC-Snap-In Zertifizierungsstelle wird die bestehende Konfiguration genutzt. Über das Festlegen 

von Erneuerungseinstellungen für Zertifizierungsstellen in CAPolicy.inf können Sie die 

Schlüssellänge und Gültigkeitsdauer ändern sowie bestimmen, ob ein neues Schlüsselpaar ausgestellt 

wird. 

• Pfade für den Verteilungspunkt von Zertifikatsperrlisten und Stelleninformationszugriff Da eine 

Stammzertifizierungsstelle in der Regel Clients nicht zur Verfügung steht, möchten Sie ggf. nicht 

dem Zertifikat der Zertifizierungsstelle die Pfade für den Verteilungspunkt von Zertifikatsperrlisten 

und den Stelleninformationszugriff hinzufügen. Sie können diese Erweiterungen in der Datei 

CAPolicy.inf deaktivieren. Der Stelleninformationszugriff gibt an, wo das Zertifikat der Zertifizierungsstelle 

abgerufen werden kann. 

Weitere Informationen Weitere Informationen zur Datei CAPolicy.inf finden Sie in „Syntax von 

"CAPolicy.inf"“ auf der Technet-Website unter http://www.microsoft.com/germany/technet/datenbank/ 

articles/600683.mspx#ED6DI.


Hardwaresicherheitsmodul (HSM) 

Um die Sicherheit privater Schlüssel für eine Zertifizierungsstelle zu erhöhen, können Sie ein Hardwaresicherheitsmodul 

(HSM) verwenden. Ein HSM dient zum Speichern privater Schlüssel auf Hardware, 

was sicherer als die Speicherung auf der Festplatte ist. Ein HSM kann Funktionalität bieten, die 

normalerweise von Software bereitgestellt wird, z.B. Schlüsselgenerierung, Schlüsselarchivierung 

und -wiederherstellung und Generierung von Zufallszahlen. Da die Server-CPU diese Aufgaben nicht 

mehr übernehmen muss, wird die Serverleistung optimiert. 

Installieren untergeordneter AD CS-Zertifizierungsstellen 

Die Installation einer untergeordneten Zertifizierungsstelle entspricht nahezu der Installation einer 

Stammzertifizierungsstelle, wobei jedoch eine untergeordnete Zertifizierungsstelle das Zertifizierungsstellenzertifikat 

von der Stammzertifizierungsstelle abrufen muss. Eine untergeordnete Zertifizierungsstelle 

ist zumeist eine Unternehmenszertifizierungsstelle, um die Integration mit Active 

Directory und den Einsatz von Zertifikatvorlagen zu ermöglichen. Wie bei der Installation einer 

Stammzertifizierungsstelle müssen die Installationsoptionen für eine untergeordnete Zertifizierungsstelle 

vor Beginn der Installation überlegt geplant werden. 

Wenn die untergeordnete Zertifizierungsstelle ein Zertifikat von der Stammzertifizierungsstelle 

anfordert, hängt dieser Vorgang davon ab, ob es sich um eine Offline-, Online-, Unternehmens- oder 

eigenständige Stammzertifizierungsstelle handelt. Ist die Stammzertifizierungsstelle eine Online- 

Unternehmenszertifizierungsstelle, kann das Zertifikat während der Installation der untergeordneten 

Zertifizierungsstelle automatisch abgerufen werden. Ist die Stammzertifizierungsstelle eine eigenständige 

Zertifizierungsstelle, muss die Anforderung des Zertifizierungsstellenzertifikats in einer 

Datei gespeichert und an die Stammzertifizierungsstelle übermittelt werden. Die Antwort der Stammzertifizierungsstelle 

muss anschließend in den Assistenten zum Installieren der Active Directory-Zertifikatdienste 

importiert werden. Ist eine eigenständige Stammzertifizierungsstelle online, kann die 

Zertifikatanforderung und -antwort über das Netzwerk erfolgen. Ist sie offline, muss die Zertifikatanforderung 

und -antwort auf einem Wechseldatenträger zum Transport zwischen der Stamm- und der 

untergeordneten Zertifizierungsstelle gespeichert werden. 

Konfigurieren der Webregistrierung 

Die Zertifizierungsstellen-Webregistrierung wird in den AD CS als Rollendienst implementiert, den 

Sie während der Erstinstallation oder nach der Installation installieren können. Wenn Sie die Zertifizierungsstellen-Webregistrierung 

installieren, sind verschiedene zusätzliche Rollendienste und Features 

erforderlich. Falls diese noch nicht installiert sind, werden Sie zu deren Installation aufgefordert. 

Die folgenden Features und Rollendienste sind erforderlich: 

• Webserver (IIS) Die Webserver- und Verwaltungsprogramme sind installiert. Dies gilt auch für die 

Unterstützung von ASP-Seiten und der .NET-Erweiterbarkeit, die für die Ausführung der zur Zertifizierungsstellen-Webregistrierung 

gehörenden dynamischen Webseiten erforderlich ist. 

• Aktivierungsdienst für Windows-Prozesse Hierzu gehört die .NET-Umgebung. 

Hinweis Um die Sicherheit zu erhöhen, kann die Website der Webregistrierung auf einem von der Zertifizierungsstelle 

getrennten Server konfiguriert werden.


Nach der Installation ist für die Zertifizierungsstellen-Webregistrierung keine weitere Konfiguration 

erforderlich. Wenn jedoch das virtuelle Verzeichnis für den Zugriff auf die Webregistrierungsseiten 

versehentlich entfernt oder geändert wird, kann es mithilfe von Certutil.exe verwaltet werden. Über 

den Befehl certutil -vroot können die virtuellen Verzeichnisse bei Bedarf neu erstellt werden. Über 

den Befehl certutil -vroot delete können die virtuellen Verzeichnisse bei Bedarf entfernt werden. Es ist 

ggf. sinnvoll, diese virtuellen Verzeichnisse zu entfernen und neu zu erstellen, sollte sich die Standardkonfiguration 

geändert haben. 

Konfigurieren der Zertifikatsperrung 

Wichtig ist, dass Public Key-fähige Anwendungen nur gültige Zertifikate annehmen. Dies gewährleistet, 

dass dem Zertifikat und infolgedessen dem Inhaber des Zertifikats vertraut werden kann. Zur 

Sicherstellung der Gültigkeit werden die folgenden Prüfungen auf ein Zertifikat angewendet: 

• Datumsprüfung Ein Zertifikat wird geprüft, um sicherzustellen, dass das aktuelle Datum zwischen 

einem gültigen Anfangs- und Enddatum liegt. 

• Zertifikatinhalt und -format Das Zertifikat muss ein gültiges X.509-Zertifikat sein, in dem alle 

Pflichtfelder ausgefüllt sind. 

• Signaturprüfung Die digitale Signatur der Stammzertifizierungsstelle dient zum Überprüfen, ob 

das Zertifikat geändert wurde. 

• Überprüfung der Stammzertifizierungsstelle Das Zertifikat muss von einer vertrauenswürdigen 

Stammzertifizierungsstelle ausgestellt worden sein. 

• Richtlinienüberprüfung und wichtige Erweiterungen Die Anwendung fordert ggf. an, dass eine 

bestimmte Richtlinie eingehalten wird. Oder eine Anwendung weist ggf. ein Zertifikat mit einer 

als wichtig markierten Erweiterung zurück, die die Anwendung nicht interpretieren kann. 

Zusätzlich zu diesen Gültigkeitsprüfungen kann eine Sperrprüfung erfolgen. Sie sperren ein Zertifikat, 

wenn sie es ungültig machen möchten, bevor das Ende seiner Gültigkeitsdauer erreicht ist. Es folgen 

verschiedene Gründe zum Sperren eines Zertifikats: 

• Gefährdete Sicherheit des privaten Schlüssels eines Zertifikats 

• Gefährdete Sicherheit des privaten Schlüssels der ausstellenden Zertifizierungsstelle 

• Veränderung der Geschäftsbeziehung zu einem anderen Unternehmen 

• Änderung des Beschäftigungsstatus eines Mitarbeiters 

• Betrügerischer Bezug eines Zertifikats 

Windows Server 2008 unterstützt sowohl Zertifikatsperrlisten als auch einen Online-Responder zum 

Überprüfen des Sperrstatus eines Zertifikats. Zertifikatsperrlisten sind die herkömmliche Methode 

zum Bereitstellen von Sperrungsdaten. Der Online-Responder ist eine neue Funktion unter Windows 

Server 2008. 

Konfiguration von Zertifikatsperrlisten 

Eine Zertifikatsperrliste enthält gesperrte Zertifikate, die eine Public Key-fähige Anwendung zum 

Überprüfen der Gültigkeit eines Zertifikats verwenden kann. Es gibt zwei Typen von Zertifikatsperrlisten: 

eine Basis- und eine Delta-Zertifikatsperrliste. Die Basis-Zertifikatsperrliste enthält alle ab 

einem bestimmten Zeitpunkt gesperrten Zertifikate. Die Delta-Zertifikatsperrliste enthält alle seit 

Erstellung der letzten Basis-Zertifikatsperrliste gesperrten Zertifikate.


Die Basis- und die Delta-Zertifikatsperrliste dienen gemeinsam zum Bereitstellen der vollständigen 

Liste gesperrter Zertifikate. Standardmäßig wird eine Basis-Zertifikatsperrliste einmal pro Woche und 

eine Delta-Zertifikatsperrliste einmal pro Tag veröffentlicht. Sie können im MMC-Snap-In Zertifizierungsstelle 

die Eigenschaften des Ordners Gesperrte Zertifikate an die besonderen Anforderung Ihres 

Unternehmens anpassen (siehe Abbildung 17.5). 


Festlegen der Veröffentlichung von Zertifikatsperrlisten 

Der Zweck einer Delta-Zertifikatsperrliste ist die Verringerung des Netzwerkdatenverkehrs beim 

Herunterladen von Zertifikatsperrlisten auf Clientcomputer. Wenn eine Zertifizierungsstelle für einen 

bestimmten Zeitraum in Betrieb ist, kann die Basis-Zertifikatsperrliste recht umfangreich werden. 

Heruntergeladene Zertifikatsperrlisten sind vergleichsweise wesentlich kleiner (vergleichbar mit einer 

differenziellen und einer vollständigen Datensicherung). 

Hinweis Windows 2000-Clients unterstützen keine Delta-Zertifikatsperrlisten und verwenden nur Basis- 

Zertifikatsperrlisten. Falls es im Netzwerk Windows 2000-Clients gibt, müssen Sie dafür sorgen, dass die 

Basis-Zertifikatsperrliste zur Unterstützung dieser Clients häufig genug aktualisiert wird. 

Zertifikatsperrlisten für eigenständige Zertifizierungsstellen stehen standardmäßig nur über die Seiten 

der Zertifizierungsstellen-Webregistrierung unter http://server/certsrv/ zur Verfügung. Sie können 

jedoch einen LDAP-Pfad für die Zertifikatsperrliste festlegen und diese mithilfe von CertUtil manuell 

in Active Directory veröffentlichen. Falls es sich um eine Offlinezertifizierungsstelle handelt, können 

Sie sie auch über HTTP an einer anderen Stelle bereitstellen. Die von Unternehmenszertifizierungsstellen 

veröffentlichten Zertifikatsperrlisten stehen über die Seiten der Zertifizierungsstellen- 

Webregistrierung und Active Directory zur Verfügung (siehe Abbildung 17.6).



Konfiguration von Zertifikatsperrlisten 

Direkt von der Quelle: So wird bestimmt, ob die Zertifikatsperrliste lokal auf einem 

System zwischengespeichert ist 

Mitunter werden wir gefragt, wie festgestellt werden kann, ob die neueste Zertifikatsperrliste auf 

die lokalen Systeme heruntergeladen wurde. Wichtig ist der Hinweis, dass es stets mindestens zwei 

verschiedene Zwischenspeicher für Zertifikatsperrlisten gibt, einen für SYSTEM und einen zweiten 

für den gegenwärtig angemeldeten Benutzer. Beim Versuch zu bestimmen, ob die Zertifikatsperrliste 

zwischengespeichert wurde, muss Ihnen dies klar sein. 

Wird die Anwendung im Kontext des Benutzers ausgeführt, kann sie den Zwischenspeicher für 

Zertifikatsperrlisten des Benutzers und den von SYSTEM (lokaler Computer) untersuchen. Wird 

die Anwendung dagegen im Kontext des Systems ausgeführt, kann nur der Zwischenspeicher für 

Zertifikatsperrlisten von SYSTEM untersucht werden. 

Es gibt zwei Methoden zum Bestimmen dieser Informationen: 

• Verwenden Sie den Befehl „CertUtil -URLCache CRL“. 

• Verwenden Sie das Snap-In Zertifikate. 

Führen Sie die folgenden Schritte aus, um mit dem Snap-In Zertifikate zu prüfen, ob die Zertifikatsperrliste 

heruntergeladen wurde: 

1. Fügen Sie dem MMC-Snap-In den ordnungsgemäßen Speicher hinzu, und fügen Sie diesen 

anschließend dem obersten Knoten hinzu, z.B. dem Knoten Zertifikate (Lokaler Computer).


2. Klicken Sie mit der rechten Maustaste auf den Knoten Zertifikate (Lokaler Computer), wählen 

Sie Ansicht und anschließend Optionen aus. 

3. Aktivieren Sie das Kontrollkästchen Physikalische Zertifikatspeicher. 

Wenn Sie die Zertifikatsperrliste der Stammzertifizierungsstelle suchen, untersuchen Sie folgenden 

Speicherort: Zertifikate (Lokaler Computer)\Vertrauenswürdige Stammzertifizierungsstellen\Registrierung\Zertifikatsperrliste. 

Dieser Speicherort wird nur angezeigt, da Sie Physikalische Zertifikatspeicher 

aktiviert haben. Dies ist ferner der Speicherort, an den Sie die Zertifikatsperrliste auf der 

grafischen Benutzeroberfläche importieren. 

Wenn Sie die Zertifikatsperrliste einer Zwischenzertifizierungsstelle (untergeordnete oder ausstellende 

Zertifizierungsstelle) suchen, untersuchen Sie folgenden Speicherort: Zertifikate (Lokaler 

Computer)\Zwischenzertifizierungsstellen\Registrierung\Zertifikatsperrliste. Dieser Speicherort 

wird nur angezeigt, da Sie Physikalische Zertifikatspeicher aktiviert haben. Dies ist ferner der Speicherort, 

an den Sie die Zertifikatsperrliste auf der grafischen Benutzeroberfläche importieren. 

Je nach Zweck der Zertifikatsperrliste müssen Sie verschiedene Speicher untersuchen. 

Rob Greene 


Commercial Technical Support – Platforms 

Direkt von der Quelle: Importieren einer Zertifikatsperrliste auf einen lokalen Computer 

Falls bestimmte Systeme keinen direkten Zugriff auf die Speicherorte der Zertifikatsperrlisten 

haben, können Sie diese manuell oder per Skript einem lokalen System hinzufügen. 

Führen Sie einen der folgenden Befehle aus, um die Zertifikatsperrliste dem Zertifikatspeicher des 

lokalen Computerkontos hinzuzufügen: 

• Zertifikatsperrliste der Stammzertifizierungsstelle Falls es sich um eine Zertifikatsperrliste für 

eine Stammzertifizierungsstelle handelt, geben Sie Folgendes ein: 

CertUtil -AddStore ROOT < Dateiname der Zertifikatsperrliste für die Stammzertifizierungsstelle> 

• Zertifikatsperrliste einer Zwischen-, untergeordneten und ausstellenden Zertifizierungsstelle Falls es 

sich um eine Zertifikatsperrliste für eine Zwischenzertifizierungsstelle handelt, geben Sie Folgendes 

ein: 

CertUtil -AddStore CA < Dateiname der Zertifikatsperrliste für die Zwischenzertifizierungsstelle> 

Diese beiden Befehle fügen die Zertifikatsperrliste dem Zwischenspeicher für Zertifikatsperrlisten 

des lokalen Computers und nicht dem des Benutzers hinzu. 

Eine weitere Methode zum Veröffentlichen einer Zertifikatsperrliste ist deren Veröffentlichung in 

Active Directory. Bei einer anschließenden Gruppenrichtlinienaktualisierung werden die neuen 

Zertifikatsperrlisten dem entsprechenden Speicher hinzugefügt. Geben Sie dazu folgenden Befehl 

ein: 

CertUtil -f -DSPublish


Rob Greene 


Commercial Technical Support – Platforms 

Online-Responder-Konfiguration 

Ein Online-Responder ist ein Server, der das OCSP-Protokoll zum Überprüfen des Sperrstatus von 

Zertifikaten unterstützt. OCSP ist eine Alternative zu Zertifikatsperrlisten und erfordert nicht das 

regelmäßige Herunterladen einer Zertifikatsperrliste. Stattdessen senden Clients eine Abfrage zum 

Überprüfen der Gültigkeit eines bestimmten Zertifikats. Dadurch kann der Netzwerkdatenverkehr aufgrund 

des herkömmlichen Herunterladens vollständiger Zertifikatsperrlisten wesentlich verringert 

werden. Ferner wird die Nutzung aktueller Statusinformationen durch die Clients möglich. Bei vielen 

sich wiederholenden Abfragen kann OCSP allerdings die Gesamtlast des Netzwerks im Vergleich zu 

Zertifikatsperrlisten erhöhen, die lokal zwischengespeichert werden. 

Hinweis Windows Server 2008 und Windows Vista sind die einzigen Windows-Betriebssysteme mit einem 

OCSP-Client, der den Zertifikatstatus durch Überprüfen eines Online-Responders bestimmen kann. 

Es folgt das Verfahren zum Überprüfen der Zertifikatgültigkeit mit einem Online-Responder: 

1. Der lokale Arbeitsspeicher und Festplattenzwischenspeicher werden auf eine noch gültige zuvor 

zwischengespeicherte OCSP-Antwort durchsucht. 

2. Wird keine OCSP-Antwort gefunden, sendet der Client eine HTTP GET-Anforderung. Unterstützt 

der Online-Responder nicht die GET-Methode, sendet der Client anschließend eine HTTP 

POST-Anforderung. 

3. Der Online-Responder durchsucht den lokalen Zwischenspeicher und die Zertifikatsperrliste, um 

den Status des zu prüfenden Zertifikats festzustellen, und sendet eine digital signierte Antwort. 

4. Sobald die Antwort empfangen wird, prüft der Client deren Signatur, um ihre Gültigkeit sicherzustellen. 

Installieren eines Online-Responders Um eine Windows Server 2008-Zertifizierungsstelle als Online- 

Responder zu konfigurieren, müssen Sie den RollendienstOnline Certificate Status-Protokoll für die 

Rolle Active Directory-Zertifikatdienste installieren. Falls noch nicht installiert, werden Sie zur Installation 

des Webservers (IIS) und des Aktivierungsdienstes für Windows-Prozesse aufgefordert, die 

auch für den Rollendienst Zertifizierungsstelle-Webregistrierung erforderlich sind. Bei der Installation 

des Rollendiensts Online Certificate Status-Protokoll gibt es keine Konfigurationsoptionen. 

Der Installationsprozess für den Rollendienst Online Certificate Status-Protokoll erstellt in Internetinformationsdienste 

(IIS) das virtuelle OSCP-Verzeichnis. Mit dem Befehl certutil -vocsproot können 

Sie dieses virtuelle Verzeichnis bei Bedarf neu erstellen. Mit dem Befehl certutil -vocsproot -delete 

können Sie dieses virtuelle Verzeichnis löschen. 

Konfigurieren von Zertifizierungsstellen Nach der Installation müssen Sie die Erweiterung Stelleninformationszugriff 

(Authority Information Access, AIA) der Zertifikate ausstellenden Zertifizierungsstellen 

so konfigurieren, dass die URL für den Online-Responder hinzugefügt wird. OSCP-Clients nutzen 

diese URL zum Überprüfen des Status von Zertifikaten. Dies erfolgt durch Verwenden des 

MMC-Snap-Ins Zertifizierungsstelle für den Zugriff auf die Registerkarte Erweiterungen in den 

Eigenschaften einer Zertifizierungsstelle.


Die hinzuzufügende URL lautet http://Servername/ocsp. Für diesen neuen Eintrag müssen Sie die 

Kontrollkästchen In AIA-Erweiterung des ausgestellten Zertifikats einbeziehen und In Online Certificate 

Status-Protokoll (OCSP)-Erweiterungen einbeziehen aktivieren. Mithilfe von OCSP können nur 

nach dieser Konfiguration ausgestellte Zertifikate überprüft werden. 

Konfigurieren eines OCSP-Antwortsignaturzertifikats Antworten eines Online-Responders können mit 

dem Zertifizierungsstellenzertifikat des Online-Responders oder mit einem delegierten Signierungsschlüssel 

signiert werden, wobei das Verwenden eines solchen Zertifikats keine weitere Konfiguration 

erfordert. Beim Verwenden eines delegierten Signierungsschlüssels müssen Sie ein OCSP-Antwortsignaturzertifikat 

registrieren. Ein delegierter Signierungsschlüssel hat die folgenden Merkmale: 

• Eine kürzere Gültigkeitsdauer als ein Zertifizierungsstellenzertifikat Empfohlen wird eine Gültigkeitsdauer 

von zwei Wochen, um die Gefährdung der Sicherheit eines Schlüssels zu minimieren. 

• Umfasst die Erweiterung id-pkix-ocsp-nocheck Diese Erweiterung hindert Clients am Überprüfen 

des Sperrstatus des Online-Responders, um die Systemleistung durch Reduzierung des Netzwerkdatenverkehrs 

zu verbessern. Wird diese Erweiterung angegeben, muss die Gültigkeitsdauer des 

Zertifikats kurz gehalten werden. 

• Bietet keinen Verteilungspunkt für Zertifikatsperrlisten und keine Erweiterung für den Stelleninformationszugriff 

Diese Erweiterungen sind nicht erforderlich, da der Sperrstatus nicht überprüft wird. 

• Bietet die Verwendung des optimierten Schlüssels id-kp-OCSPSigning. Gibt für OCSP-Clients an, 

dass die Antwort mit einem delegierten Signierschlüssel und nicht mit einem Zertifizierungsstellenschlüssel 

signiert wird. 

Unter Windows Server 008 gibt es für Unternehmenszertifizierungsstellen die Zertifikatvorlage 

OCSP-Antwortsignatur. Diese Vorlage kann der Zertifizierungsstelle so zugewiesen werden, dass 

außer der Erteilung der erforderlichen Sicherheitsberechtigungen für die Registrierung bzw. automatische 

Registrierung keine weiteren Konfigurationsschritte nötig sind. Eine eigenständige Zertifizierungsstelle 

kann die Zertifikatvorlage OCSP-Antwortsignatur nicht verwenden. Zum Erstellen eines 

OCSP-Antwortsignaturzertifikats müssen Sie Certreq.exe in Kombination mit einer angepassten INF- 

Datei einsetzen. 

Weitere Informationen Detaillierte Anweisungen zum Abrufen eines OCSP-Antwortsignaturzertifikats mithilfe 

einer eigenständigen Zertifizierungsstelle finden Sie im Abschnitt „Enrolling for an OCSP Response Signing 

Certificate Against a Stand-Alone CA“ unter Installing, Configuring, and Troubleshooting the Microsoft 

Online Responder unter http://technet2.microsoft.com/windowsserver2008/de/library/99d1f392-6bcd-4ccf- 

94ee-640fc100ba5f1031.mspx?mfr=true. 

Konfigurieren von Sperrinformationen Für einen Online-Responder müssen Sie Sperrinformationen 

konfigurieren, damit dieser auf OCSP-Anforderungen nach Zertifikaten antwortet, die von einer 

bestimmten Zertifizierungsstelle ausgestellt werden. Damit der Online-Responder mehrere Zertifizierungsstellen 

unterstützt, können mehrere Sperrkonfigurationen eingerichtet werden, wozu das MMC- 

Snap-In Online-Responderverwaltung verwendet wird. Beim Erstellen der Sperrkonfiguration bestimmen 

Sie die Zertifizierungsstelle, indem Sie das Zertifizierungsstellenzertifikat in Active Directory, 

im lokalen Zertifikatspeicher oder einer Datei auswählen. 

Als Nächstes wählen Sie das Signaturzertifikat für OCSP-Antworten aus (siehe Abbildung 17.7). Bei 

Wahl von Signaturzertifikat automatisch auswählen kann der Assistent ein geeignetes Zertifikat im 

lokalen Zertifikatspeicher auswählen oder zum Abrufen eines OCSP-Signaturzertifikats eine automatische 

Registrierung durchführen.


Bei Wahl von Signaturzertifikat manuell auswählen wird der Assistent am Zuweisen eines Zertifikats 

gehindert, sodass Sie nach Beendigung des Assistenten ein Zertifikat manuell zuweisen müssen. Wird 

Zertifizierungsstellenzertifikat für die Sperrkonfiguration verwenden ausgewählt, werden Anforderungen 

mit dem Zertifizierungsstellenzertifikat anstatt mit einem OCSP-Signaturzertifikat signiert. 

Diese Option kann nur ausgewählt werden, wenn der Online-Responder für die Zertifizierungsstelle 

ausgeführt wird. 

Hinweis Die automatische Registrierung für Computer muss aktiviert sein, damit der Online-Responder 

sich automatisch für das OCSP-Signaturzertifikat registriert. Diese Option ist nicht standardmäßig aktiviert. 

Im Abschnitt „Konfigurieren der automatischen Registrierung für Zertifikate“ finden Sie weitere Informationen. 


Auswählen des Signaturzertifikats 

Online-Responder-Arrays Wenn Online-Responder zum Bereitstellen des Sperrstatus von Zertifikaten 

verwendet werden, müssen diese stets zur Verfügung stehen, um aktuelle Statusinformationen zu liefern. 

Sind Online-Responder nicht erreichbar, kann der Sperrstatus nicht bestimmt werden, wodurch 

Public Key-fähige Anweisungen fehlschlagen können. Zertifikatsperrlisten werden lokal zwischengespeichert, 

weshalb die Verfügbarkeit gesichert ist. 

Um Fehlertoleranz für Online-Responder zu ermöglichen, können diese als Array konfiguriert werden, 

in dem die Konfigurationsinformationen unter den Mitgliedern synchronisiert werden. Dadurch 

wird die Konfiguration von Online-Respondern vereinfacht. Um fehlertolerant zu sein, müssen Zertifizierungsstellen 

mit der URL aller Online-Responder im Array konfiguriert werden. Anforderungen 

werden nicht automatisch an die Mitglieder des Arrays verteilt. 

Verwalten der Schlüsselarchivierung und -wiederherstellung 

Private Schlüssel können archiviert und wiederhergestellt werden. Windows speichert private Schlüssel 

im Benutzerprofil. Sollte dieses Profil aus einem beliebigen Grund verloren gehen, ist auch der 

private Schlüssel verloren.


Wurde der Schlüssel archiviert, kann er in einem Profil auf demselben oder einem anderen Computer 

ohne Funktionalitätsverlust wiederhergestellt werden. Wurde beispielsweise das Profil auf einer 

Arbeitsstation gelöscht, kann der Schlüssel in einem neuen Profil wiederhergestellt werden, woraufhin 

auf alle verschlüsselten Daten zugegriffen werden kann. 

Bei der Ausstellung von Zertifikaten können Sie den Export privater Schlüssel verhindern, sodass der 

private Schlüssel nicht an einen neuen Speicherort kopiert werden kann. Dies erfolgt in der Regel bei 

vertraulichen Zertifikaten, z.B. Zertifizierungsstellenzertifikaten, bei denen der Export des privaten 

Schlüssels an einen anderen Speicherort und dessen Verwendung sehr negative Auswirkungen haben 

können. Sie müssen jedoch das Risiko eines Schlüsselverlustes ohne Wiederherstellungsmethode mit 

dem jeweiligen Wiederherstellungsaufwand abwägen. Ohne einen archivierten Schlüssel können Sie 

ggf. nicht auf verschlüsselte Daten zugreifen. 

Manuelle Schlüsselarchivierung 

Falls das Zertifikat für die Unterstützung des Exports des privaten Schlüssels konfiguriert ist, können 

einzelne Benutzer ihre Zertifikate und privaten Schlüssel mithilfe des MMC-Snap-Ins Zertifikate 

exportieren. Während des Exports wird ein Schlüssel zum Verschlüsseln der Datei eingegeben, um 

unbefugte Benutzer am Import der Datei zu hindern. Die verschlüsselte Datei kann anschließend, bis 

sie benötigt wird, auf einem Wechseldatenträger abgelegt werden. Bei Bedarf kann der Schlüssel über 

das MMC-Snap-In Zertifikate importiert werden. Es folgen Empfehlungen für die manuelle Schlüsselarchivierung: 

• Wenn Sie einen Schlüssel manuell exportieren, müssen Sie zu seiner Absicherung die stärkstmögliche 

Verschlüsselung wählen. 

• Außerdem sollten Sie den Wechseldatenträger mit der verschlüsselten Datei physisch absichern, 

um über das Kennwort hinaus für noch mehr Sicherheit zu sorgen. 

• Wenn Sie einen Schlüssel für einen bestimmten Zweck vorübergehend importieren, müssen Sie 

diesen nach dessen Erfüllung entfernen. 

Die manuelle Schlüsselarchivierung kommt in Frage, wenn nur wenige Schlüssel archiviert werden 

müssen. Im Allgemeinen benötigen Großunternehmen eine automatisierte Lösung für die Schlüsselarchivierung, 

die zentral verwaltet werden kann. 

Automatische Schlüsselarchivierung 

Eine Zertifizierungsstelle unter Windows Server 2008 kann die Schlüsselarchivierung für die von ihr 

ausgestellten Zertifikate übernehmen. Dieser Vorgang wird auch als Schlüsselübertragung bezeichnet. 

Die Schlüsselarchivierung ist eine Funktion von Windows Server 2008 Enterprise und Datacenter 

Edition. 

Einrichten von Schlüsselwiederherstellungs-Agents Ein Schlüsselwiederherstellungs-Agent ist ein 

Benutzer, der für die Zertifizierungsstelle archivierte Schlüssel wiederherstellen kann. Der erste 

Schritt bei der Konfiguration der Schlüsselarchivierung ist die Einrichtung von Schlüsselwiederherstellungs-Agents. 

In jedem Unternehmen darf es nur eine begrenzte Anzahl von Schlüsselwiederherstellungs-Agents 

geben, die alle genehmigt werden müssen. 

Schlüsselwiederherstellungs-Agents werden durch Ausstellen eines Schlüsselwiederherstellungs- 

Agent-Zertifikats eingerichtet. Zu diesem Zweck enthält Windows Server 2008 die Zertifikatvorlage 

Schlüsselwiederherstellungs-Agent. Konfigurieren Sie diese Zertifikatvorlage mit den entsprechenden 

Berechtigungen für die Benutzer, die Sie für das Zertifikat registrieren möchten. Veröffentlichen 

Sie anschließend die Zertifikatvorlage Schlüsselwiederherstellungs-Agent.


Sobald die Zertifikatvorlage eingerichtet ist, können sich die vorgesehenen Benutzer über das MMC- 

Snap-In Zertifikate, die Registrierungswebseiten der Zertifizierungsstelle oder die automatische 

Registrierung für das Zertifikat Schlüsselwiederherstellungs-Agent registrieren. Die automatische 

Registrierung wird nicht empfohlen, da bei diesem überaus vertraulichen Vorgang verschiedene 

manuelle Eingaben bevorzugt werden sollten. Das Zertifikat Schlüsselwiederherstellungs-Agent kann 

nur über das MMC-Snap-In Zertifikate heruntergeladen werden, wenn die automatische Registrierung 

aktiviert ist. 

Hinweis Wenn die Anforderung des Zertifikats Schlüsselwiederherstellungs-Agent genehmigt wurde, wird 

das Zertifikat dem lokalen Zertifikatspeicher für die Zertifizierungsstelle und dem Active Directory-Objekt des 

Benutzers hinzugefügt, der das Zertifikat angefordert hat. 

Aktivieren der Schlüsselarchivierung für die Zertifizierungsstelle Um die Schlüsselarchivierung für die 

Zertifizierungsstelle zu aktivieren, müssen Sie der Zertifizierungsstelle einen Wiederherstellungs- 

Agent hinzufügen (siehe Abbildung 17.8). Nach Aktivierung der Schlüsselarchivierung müssen die 

Zertifikatdienste neu gestartet werden. Die Implementierung von Schlüsselwiederherstellungs-Agents 

hängt von der gewünschten Anzahl der Wiederherstellungs-Agents und konfigurierten Schlüsselwiederherstellungs-Agent-Zertifikate 

ab. 


Wiederherstellungs-Agents für die Schlüsselarchivierung 

Wenn die ausgewählte Anzahl von Wiederherstellungs-Agents der Anzahl der Schlüsselwiederherstellungs-Agent-Zertifikate 

entspricht, können alle Wiederherstellungs-Agents alle Schlüssel wiederherstellen. 

Ist die Anzahl geringer, wird eine Auswahlmethode nach dem Round-Robin-Prinzip verwendet, 

um zu bestimmen, welche Wiederherstellungs-Agents welche Schlüssel wiederherstellen können.


Um in diesem Fall einen Schlüssel aus der Datenbank wiederherzustellen, müssen Sie zuerst die 

Wiederherstellungs-Agent bestimmen, die dazu fähig sind. 

Konfigurieren von Zertifikatvorlagen Der Schlüsselwiederherstellungs-Agent eines privaten Schlüssels 

wird bei Ausstellung eines Zertifikats in der dazugehörigen Zertifikatvorlage konfiguriert (siehe 

Abbildung 17.9). Die Option Privaten Schlüssel für die Verschlüsselung archivieren gibt an, dass der 

private Schlüssel für mithilfe dieser Vorlage erstellte Zertifikate archiviert wird. Die Option Erweiterten 

symmetrischen Algorithmus zum Senden des Schlüssels an die Zertifizierungsstelle verwenden 

ist neu unter Windows Server 2008 und zwingt Client und Server zum Verwenden des AES-Verschlüsselungsalgorithmus 

für die Absicherung des privaten Schlüssels. 


Konfigurieren der Schlüsselarchivierung in einer Zertifikatvorlage 

Hinweis Die Option Exportieren von privatem Schlüssel zulassen muss aktiviert sein, damit die manuelle 

Schlüsselarchivierung erfolgen kann. 

Wiederherstellen eines archivierten Schlüssels Die Wiederherstellung eines archivierten Schlüssels ist 

ein manueller Prozess, der abhängig von der Sicherheitskonfiguration der AD CS in Ihrem Unternehmen 

ggf. die Zusammenarbeit mehrerer Personen erfordert. Ist die Trennung von Rollen vorgegeben, 

muss ein Zertifizierungsverwalter mit dem Schlüsselwiederherstellungs-Agent zusammenarbeiten, um 

den Schlüssel abzurufen. Sind Rollen nicht getrennt, kann ein Benutzer mit Verwaltungsberechtigung 

für die Zertifizierungsstelle zum Abruf des Schlüssels mit dem Schlüsselwiederherstellungs-Agent 

zusammenarbeiten.


Der erste Schritt bei der Wiederherstellung ist das Suchen für die Wiederherstellung in Frage kommender 

Zertifikate und das Extrahieren des Wiederherstellungs-BLOB (Binary Large Object). Über 

das MMC-Snap-In Zertifizierungsstelle oder das Dienstprogramm Certutil.exe können Sie das wiederherzustellende 

Zertifikat finden. Zu diesem Zweck benötigt die Zertifikatverwaltung den allgemeinen 

Namen (Common Name), Benutzerprinzipalnamen (UPN), Domänen- und Anmeldenamen, die 

Seriennummer des Zertifikats oder den Zertifikatfingerabdruck. Über den Befehl certutil -getkey 

können Sie eine Liste der für einen Benutzer ausgestellten Zertifikate 

abrufen. Der Suchtext kann entweder der allgemeine Name (CN) des Benutzers, der Benutzerprinzipalname 

(UPN) oder der Domänen-/Anmeldename sein. Wenn der Benutzer nur ein Zertifikat hat, 

wird das BLOB für die Schlüsselwiederherstellung in den angegebenen Dateinamen extrahiert. 

Wenn es mehrere Zertifikate für einen Benutzer gibt, wählen Sie im Befehl certutil als Suchtext die 

Seriennummer oder den Fingerabdruck des Zertifikats, die beide das Zertifikat eindeutig identifizieren, 

um das Wiederherstellungs-BLOB zu extrahieren. 

Das Wiederherstellungs-BLOB ist das Zertifikat im PKCS #7-Format, dessen Inhalt verschlüsselt ist 

und den öffentlichen Schlüssel enthält. Als Nächstes kann der Schlüsselwiederherstellungs-Agent den 

privaten Schlüssel aus dem Wiederherstellungs-BLOB extrahieren. Die Ausgabe des Befehls certutil 

-getkey gibt bei Bedarf die Schlüsselwiederherstellungs-Agents für ein Zertifikat an. 

Um den privaten Schlüssel aus dem Wiederherstellungs-BLOB wiederherzustellen, ruft der Schlüsselwiederherstellungs-Agent 

den Befehl certutil 

-recoverkey auf. Dateiname ist das zuvor generierte Wiederherstellungs-BLOB. 

Ausgabe.pfx ist ein allgemeiner Name einer Datei, die für die Ausgabe der Wiederherstellung 

des privaten Schlüssels verwendet werden kann. Die Ausgabedatei hat das PKCS #12-Format 

und muss die Erweiterung .pfx haben. Sie werden zur Eingabe eines Kennworts aufgefordert, um 

die Ausgabedatei während ihrer Erstellung abzusichern. Beachten Sie ferner, dass das Zertifikat des 

Schlüsselwiederherstellungs-Agents sich im lokalen Zertifikatspeicher befinden muss, in den die Wiederherstellung 

erfolgt, da diese andernfalls fehlschlägt. 

Hinweis Wenn das Zertifikat des Schlüsselwiederherstellungs-Agents mithilfe eines neuen CNG-Algorithmus 

(CryptoAPI Next Generation) generiert wurde, muss dieser Algorithmus während der Wiederherstellung 

über die Option -csp "für den kryptografischen Speicheranbieter" angegeben werden. 

Importieren des wiederhergestellten Schlüssels Nachdem der private Schlüssel in einer Datei wiederhergestellt 

wurde, kann der Benutzer ihn über das MMC-Snap-In Zertifikate oder das Dienstprogramm 

Certutil in das Benutzerprofil importieren. Bei Verwenden von Certutil lautet der Befehl: 

certutil -importPFX . Nach dem Import wird der private Schlüssel im Zertifikatspeicher 

des Benutzers wiederhergestellt, sodass der Benutzer das Zertifikat wieder nutzen kann. 

Verwalten von Zertifikaten in den AC CS 

Die AD CS bieten mehrere Funktionen zum Verwalten von Zertifikaten. Zertifikatvorlagen dienen 

zum Bestimmen von Zertifikateinstellungen, die während der Zertifikaterstellung von vielen Clients 

verwendet werden können. Über die automatische Zertifikatregistrierung kann der gesamte Zertifikatregistrierungsprozess 

automatisiert werden, sodass keine Endbenutzer- oder Administratoreingriffe 

erforderlich sind. Mithilfe von Gruppenrichtlinieneinstellungen kann festgelegt werden, wie Zertifikate 

von Clients akzeptiert werden. Und schließlich kann mit der Serverspeicherung von Anmeldeinformationen 

gearbeitet werden, um Zertifikate zu unterstützen, wenn Benutzer mehrere Arbeitsstationen 

nutzen.

Konfigurieren von Zertifikatvorlagen 

Verwalten von Zertifikaten in den AC CS 673 

Zertifikatvorlagen dienen zum Erstellen von Zertifikaten für Unternehmenszertifizierungsstellen. Die 

Einstellungen in einer Zertifikatvorlage werden in die von der Zertifizierungsstelle ausgestellten Zertifikate 

integriert. Darüber hinaus legen Sicherheitseinstellungen für eine Zertifikatvorlage fest, welche 

Benutzer oder Computer sich für den jeweiligen Zertifikattyp registrieren dürfen. 

Windows Server 2008 unterstützt drei Versionen von Zertifikatvorlagen. Version 1-Vorlagen sind die 

einzigen in Windows Server 2008 Standard Edition verfügbaren Vorlagen. Sie können die Sicherheitskonfiguration 

von Version 1-Vorlagen ändern, um die manuelle Zertifikatregistrierung zu steuern, 

können aber keine anderen Vorlageneinstellungen ändern. Auch die automatische Zertifikatregistrierung 

ist nicht möglich. In Windows Server 2008 Enterprise und Datacenter Edition stehen Version 2- 

und Version 3-Vorlagen zur Verfügung. 

Version 2-Zertifikatvorlagen ermöglichen die Anpassung der Vorlagen an Unternehmensanforderungen 

und die automatische Zertifikatregistrierung. Version 3-Vorlagen sind neu unter Windows 

Server 2008 und bieten die Möglichkeit, zusätzliche kryptografische Einstellungen anzugeben, die nur 

von einer Windows Server 2008-Zertifizierungsstelle unterstützt werden. Wenn Sie die Einstellungen 

einer Version 1-Zertifikatvorlage ändern möchten, können Sie durch Kopieren einer solchen Vorlage 

eine Version 2- oder Version 3-Zertifikatvorlage erstellen. Alternativ können Sie eine gänzlich neue 

Zertifikatvorlage generieren. 

Hinweis Windows Server 2008 bietet für verschiedene Zwecke zahlreiche Zertifikatvorlagen. Sie können 

im MMC-Snap-In Zertifikatvorlagen die dazugehörigen Beschreibungen lesen und Details anzeigen. 

Direkt von der Quelle: Version 3-Vorlagen 

Seit der Einführung der Public Key-Infrastruktur unter Windows Server 2000 bieten Zertifikatvorlagen 

eine praktische Lösung für die automatische Registrierung von Zertifikaten für Benutzer und 

Computer. Die mit Windows Server 2000 bereitgestellten Originalvorlagen wurden Version 1-Vorlagen 

genannt, die nicht entsprechend den besonderen Anforderungen einer Umgebung angepasst 

oder geändert werden konnten. Mit der Einführung von Windows Server 2003 wurden die Vorlagen 

auf Version 2-Vorlagen hochgestuft. Wenn eine Zertifizierungsstelle unter einer Enterprise Edition 

von Windows installiert wurde, konnten diese Vorlagen wie gewünscht angepasst werden. Mit 

Windows Server 2008 werden Version 3-Vorlagen eingeführt, die noch flexibler als vorherige Versionen 

sind. 

Die Version 3-Vorlagen unterstützen nun den Einsatz kryptografischer CNG Suite-B-Algorithmen 

(Cryptography API: Next Generation). Diese neue Technologie verbessert die kryptografischen 

Sicherheitsfunktionen und optimiert die gesamte Funktionalität, indem mithilfe eines Schlüsseldienstanbieters 

(Key Service Provider, KSP) der Einsatz neuer Algorithmen ermöglicht wird. 

Gegenwärtig unterstützen nur Windows Vista und Windows Server 2008 die folgenden neuen 

asymmetrischen Algorithmen: 

• ECDSA (Elliptic-Curve Digital Signature Algorithm) P256, P384, P521 

• Elliptic-Curve Diffie-Hellman (ECDH) P256, P384, P521 

• RSA 

• AES


Die enthaltenen Hashalgorithmen sind MD2, MD4, MD5, SHA1, SHA256, SHA384 und SHA512. 

Durch die Implementierung von Version 3-Vorlagen und der CNG-Technologien kann der KSP 

eine zuvor nicht mögliche, umfassende Überwachung bieten. Der KSP überwacht nun u.a. den Imund 

Export von Schlüsseln, fehlgeschlagene Überprüfungen geheimer Schlüssel, Verschlüsselungsfehler 

und fehlgeschlagene Generierungen von Schlüsselpaaren. Durch Ausführen des folgenden 

Befehls ist eine zusätzliche Überwachung möglich: 

Auditpol /set /subcategory:"other system events" /success:enable /failure:enable 

Weitere Informationen zu Version 3-Vorlagen, CNG-Funktionen und der Suite B-Kryptografie finden 

Sie auf den folgenden Websites: 

• http://msdn2.microsoft.com/en-us/library/ms683902(VS.85).aspx 

• http://msdn2.microsoft.com/en-us/library/bb204775(VS.85).aspx 

• http://www.nsa.gov/ia/industry/crypto_suite_b.cfm?MenuID=10.2.7 

Bob Drake 

Microsoft Directory Services Team 

Konfigurieren der Sicherheit von Zertifikatvorlagen 

Die für Zertifikatvorlagen festgelegten Berechtigungen (siehe Abbildung 17.10) bestimmen, welche 

Benutzer auf Zertifikatvorlagen basierende Zertifikate ändern, anzeigen und erstellen dürfen. 


Zertifikatvorlagenberechtigungen


Die folgenden Berechtigungen können zugewiesen werden: 

• Vollzugriff Der Benutzer bzw. die Gruppe kann alle Vorlagenattribute, einschließlich Berechtigungen, 

ändern. 

• Lesen Der Benutzer oder die Gruppe kann bei einem Versuch der Registrierung das Zertifikat 

suchen. 

• Schreiben Der Benutzer bzw. die Gruppe kann alle Vorlagenattribute, ausschließlich Berechtigungen, 

ändern. 

• Registrieren Der Benutzer oder die Gruppe kann sich für ein auf der Vorlage basierendes Zertifikat 

registrieren. Die Berechtigung Lesen muss ebenfalls zugewiesen sein. 

• Automatisch registrieren Der Benutzer oder die Gruppe kann über die automatische Registrierung 

ein auf der Vorlage basierendes Zertifikat automatisch empfangen. Die Berechtigungen 

Lesen und Registrieren müssen ebenfalls zugewiesen sein. 

Verwenden Sie zum Zuweisen von Berechtigungen in einer Umgebung mit mehreren Domänen 

globale und universelle Gruppen anstatt domänenlokale Gruppen. Wenn domänenlokalen Gruppen 

Berechtigungen zugewiesen werden, können Zertifizierungsstellen in anderen Domänen diese 

Berechtigungen nicht nutzen. 

Bereitstellen von Zertifikatvorlagen 

Zertifikatvorlagen werden in Active Directory gespeichert und auf alle Domänencontroller in der 

Active Directory-Gesamtstruktur repliziert. Die für die Replikation von Zertifikatvorlagen benötigte 

Zeit hängt von der jeweiligen Umgebung ab. Räumen Sie der Replikation neuer Zertifikatvorlagen 

genügend Zeit ein, bevor Sie Zertifizierungsstellen für das Verwenden der neuen Vorlage konfigurieren. 

Zertifikatvorlagen werden für eine Zertifizierungsstelle veröffentlicht, um sie für die Registrierung 

zur Verfügung zu stellen, was über den Knoten Zertifikatvorlagen im MMC-Snap-In Zertifizierungsstelle 

erfolgt. Im Allgemeinen sollten Sie eine Zertifikatvorlage für mindestens zwei Zertifizierungsstellen 

in der Gesamtstruktur veröffentlichen, um sicherzustellen, dass mindestens eine stets verfügbar 

ist. In Unternehmen mit mehreren physischen Standorten sollten Sie eine Zertifikatvorlage für 

eine Zertifizierungsstelle an jedem dieser Standorte veröffentlichen. 

Aktualisieren von Zertifikatvorlagen 

Es gibt keine Methode zum Bearbeiten vorhandener Zertifikate. Wenn Sie die Einstellungen eines 

Zertifikats für Benutzer ändern möchten, müssen Sie zuerst die Zertifikatvorlage aktualisieren, mit 

deren Hilfe die Zertifikate erstellt werden, und anschließend die Zertifikate erneut für die Benutzer 

ausstellen. Wenn Sie eine Zertifikatvorlage aktualisieren, können Sie eine vorhandene Zertifikatvorlage 

ändern oder eine neue Zertifikatvorlage erstellen, welche die vorhandene Zertifikatvorlage 

ablöst. Die Aktualisierung von Zertifikatvorlagen wirkt sich nicht auf bereits ausgestellte Zertifikate 

aus. 

Normalerweise ändern Sie eine vorhandene Zertifikatvorlage nur dann, wenn geringfügige Änderungen 

erforderlich sind. Dies ist allerdings nur bei Version 2- und Version 3-Zertifikatvorlagen möglich. 

Das Ändern der Sicherheitsberechtigungen erfordert kein erneutes Ausstellen von Zertifikaten, 

da der Inhalt der Zertifikate nicht betroffen ist. Wenn sich Änderungen auf den Inhalt der Zertifikate 

auswirken, müssen diese neu ausgestellt werden.


Durch Ablösen einer Zertifikatvorlage können Sie eine gänzlich neue Zertifikatvorlage erstellen, die 

eine oder mehrere vorhandene Zertifikatvorlagen ersetzt. Eine neue Zertifikatvorlage wird mit den 

Vorlagen konfiguriert, die sie ablöst (siehe Abbildung 17.11). Zertifikate müssen erneut ausgestellt 

werden, damit die neuen Änderungen wirksam werden. 

Das erneute Ausstellen von Zertifikaten erfolgt, wenn Zertifikate erneuert werden. Der Erneuerungszeitraum 

eines Zertifikats ist zumeist wesentlich kürzer als die Gültigkeitsdauer des Zertifikats, 

weshalb diese Änderungen nicht automatisch erfolgen. Sie können Zertifikatinhaber auch über das 

Snap-In Zertifikatvorlagen zwingen, eine erneute Registrierung vorzunehmen, bevor der Erneuerungszeitraum 

abgelaufen ist. Klicken Sie mit der rechten Maustaste auf das vorhandene Zertifikat, 

und wählen Sie Alle Zertifikatinhaber erneut registrieren. Vorhandene Zertifikatvorlage werden dann 

aktualisiert, wenn der Client das nächste Mal den Inhalt des Zertifikats mit der Vorlage abgleicht. Das 

Erzwingen der erneuten Registrierung ist nur bei Zertifikatvorlagen der Versionen 2 und 3 möglich. 


Registerkarte Abgelöste Vorlagen 

Gültigkeit von Zertifikaten bei eigenständigen Zertifizierungsstellen 

Bei Unternehmenszertifizierungsstellen wird die Gültigkeitsdauer eines Zertifikats in der Zertifikatvorlage 

bestimmt. Die standardmäßige Gültigkeitsdauer für von einer eigenständigen Zertifizierungsstelle 

ausgestellte Zertifikate ist ein Jahr. Um diese Gültigkeitsdauer zu verlängern, können 

Sie die Registrierung wie folgt bearbeiten: 

1. Öffnen Sie den Registrierungs-Editor. 

2. Suchen Sie folgenden Registrierungsschlüssel: 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\ 

Configuration\\


3. Bearbeiten Sie den Schlüssel ValidityPeriod, und geben Sie Werte für Tage, Wochen, Monate 

oder Jahre ein. 

4. Bearbeiten Sie den Schlüssel ValidityPeriodUnits, und geben Sie einen numerischen Wert entsprechend 

der Anzahl der Tage, Wochen, Monate oder Jahre ein, die die Zertifikate gültig sein 

sollen. 

5. Starten Sie die Active Directory-Zertifikatdienste neu. 

Hinweis Sie können auch mit dem Dienstprogramm Certutil.exe die Gültigkeitsdauer ändern (siehe 

„"Certutil"-Tasks zum Konfigurieren einer Zertifizierungsstelle”) unter http://technet2.microsoft.com/ 

WindowsServer/de/Library/a3d5dbb9-1bf6-42da-a13b-2b220b11b6fe1031.mspx?mfr=true. 

Konfigurieren der automatischen Zertifikatregistrierung 

Wenn in Ihrem Unternehmen sehr viele Zertifikate ausgestellt werden, kann der Verwaltungsprozess 

überaus aufwendig sein. Eine auf Windows basierende PKI-Lösung behebt dieses Problem mithilfe 

der automatischen Registrierung, die einer Windows-Zertifizierungsstelle die Ausstellung von Zertifikaten 

ohne Administrator- oder Benutzereingriffe ermöglicht. Dadurch wird die Ausstellung von Zertifikaten 

für das verschlüsselnde Dateisystem, Smartcards oder E-Mail erleichtert. Außerdem werden 

die Kosten reduziert. Die automatische Registrierung ist bei Zertifikatvorlagen der Versionen 2 und 3 

möglich. 

Version 1-Zertifikatvorlagen können über den automatischen Zertifikatanforderungsdienst (Automatic 

Certificate Request Service, ACRS) zum automatischen Generieren von Zertifikaten für Computer 

verwendet werden. Bei Verwenden dieses Dienstes werden Version 1-Zertifikatvorlagen in einem 

Gruppenrichtlinienobjekt konfiguriert. Die Einstellungen dieses Gruppenrichtlinienobjekts gelten nur 

für Computer- und nicht für Benutzerkonten. Sie müssen das Gruppenrichtlinienobjekt mit der Domäne, 

dem Standort, der Organisationseinheit mit den Computern verknüpfen, die das Zertifikat empfangen 

sollen. Die zu konfigurierende Gruppenrichtlinieneinstellung lautet Computerkonfiguration\ 

Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel\Einstellungen 

der automatischen Zertifikatanforderung. 

Im Gegensatz dazu wird die automatische Registrierung als Kombination aus Gruppenrichtlinienobjekt-Einstellungen 

und Einstellungen innerhalb der Zertifikatvorlage konfiguriert. Eine Gruppenrichtlinienobjekt-Einstellung 

dient zum Aktivieren der automatischen Registrierung. Die Sicherheitseinstellung 

für die Zertifikatvorlage bestimmt, welche Zertifikate abgerufen werden. Die 

Gruppenrichtlinienobjekt-Einstellungen für Zertifikatvorlagen der Versionen 2 und 3 können zur automatischen 

Registrierung von Zertifikaten für Benutzer- und Computerkonten verwendet werden. Sie 

müssen das Gruppenrichtlinienobjekt mit der Domäne, dem Standort, der Organisationseinheit mit 

Computern verknüpfen, die das Zertifikat empfangen sollen. Die zu konfigurierende Gruppenrichtlinieneinstellung 

lautet \Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien 

für öffentliche Schlüssel\Zertifikatdiensteclient - Einstellung 

für die automatische Registrierung (siehe Abbildung 17.12). 

Die Optionen für Konfigurationsmodell für das Gruppenrichtlinienobjekt lauten Aktiviert, Deaktiviert 

und Nicht konfiguriert. Falls auf Aktiviert eingestellt, wird die automatische Registrierung für die 

betreffenden Clients aktiviert. Die Option Abgelaufene Zertifikate erneuern, ausstehende Zertifikate 

aktualisieren und gesperrte Zertifikate entfernen ermöglicht die automatische Registrierung für zu 

erneuernde und ausstehende Zertifikate und entfernt außerdem gesperrte Zertifikate.


Die Option Zertifikate aktualisieren, die Zertifikatvorlagen verwenden erlaubt die automatische 

Registrierung zur Aktualisierung von Zertifikaten, wenn eine vorhandene Zertifikatvorlage abgelöst 

wird. Sie können auch die Ablaufbenachrichtigung konfigurieren, die die Benutzer über den anstehenden 

Ablauf ihrer Zertifikate informiert. 


Gruppenrichtlinieneinstellungen für die automatische Registrierung 

Bei Zertifikatvorlagen der Versionen 2 und 3 können Sie Einstellungen festlegen, die sich auf die 

automatische Registrierung auswirken. Auf der Registerkarte Anforderungsverarbeitung (siehe 

Abbildung 17.9) können Sie den Grad der Benutzereingaben bestimmen, der während der automatischen 

Registrierung erforderlich ist. Die Option Antragsteller ohne Benutzereingabe registrieren ist 

erforderlich, wenn Zertifikate für Computer und Dienstkonten ausgestellt werden. Sie wird auch 

zumeist für das Ausstellen von Zertifikaten für Benutzer empfohlen, da sie das automatische Erstellen 

des Zertifikats im Hintergrund ohne Benutzereingriffe ermöglicht. Die Option Benutzer zur 

Eingabe während der Registrierung auffordern zwingt Benutzer zur Interaktion mit dem Registrierungsprozess. 

Die Option Benutzer zur Eingabe während der Registrierung auffordern und Benutzereingabe 

beim Verwenden eines privaten Schlüssels anfordern zwingt den Benutzer, während der 

Registrierung ein Kennwort einzugeben. Dieses Kennwort muss jedes Mal eingegeben werden, wenn 

der Benutzer den zum Zertifikat gehörenden privaten Schlüssel verwendet. Diese zusätzliche Sicherheitseinstellung 

gewährleistet, dass der private Schlüssel nur vom Benutzer und nur zu vorgesehenen 

Zeitpunkten verwendet werden kann. 

Auf der Registerkarte Ausstellungsvoraussetzungen der Zertifikatvorlage (siehe Abbildung 17.13) 

wird festgelegt, ob Registrierungsanforderungen automatisch genehmigt werden oder ob Eingriffe 

erforderlich sind. Die Option Genehmigung von Zertifikatverwaltung der Zertifizierungsstelle fordert 

an, dass Registrierungsanforderungen für diese Vorlage vom Verwalter der Zertifizierungsstelle 

genehmigt werden, bevor das Zertifikat ausgestellt wird. Die Option Diese Anzahl an autorisierten 

Signaturen fordert an, dass Anforderer die Registrierungsanforderung mit einer digitalen Signatur 

signieren, welche dieselben Ausstellungs- und Anwendungsrichtlinien wie die aktuelle Zertifikatvorlage 

befolgt.


Sind mehrere Signaturen erforderlich, wird die automatische Registrierung für die Zertifikatvorlage 

deaktiviert. Das Anfordern von Gültiges vorhandenes Zertifikat anstelle von Gleiche Kriterien wie für 

Registrierung ermöglicht Benutzern das Erneuern ihres Zertifikats ohne Eingriff durch einen Zertifizierungsstellenverwalter 

oder Anforderung autorisierter Signaturen. 


Registerkarte Ausstellungsanforderungen einer Zertifikatvorlage 

Verwalten der Akzeptanz von Zertifikaten mithilfe von Gruppenrichtlinien 

Mithilfe von Gruppenrichtlinien können Sie vertrauenswürdige Stammzertifizierungsstellen automatisch 

an Clientcomputer verteilen. So kann am besten sichergestellt werden, dass Clients Zertifikaten 

einer Zertifizierungsstelle vertrauen, die nicht automatisch mit dem Windows-Client bereitgestellt 

wird. Die Gruppenrichtlinienobjekt-Einstellungen zur Verteilung vertrauenswürdiger Stammzertifizierungsstellen 

lautet Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien 

öffentlicher Schlüssel\Vertrauenswürdige Stammzertifizierungsstellen. Windows 

Server 2008 bietet verschiedene andere Gruppenrichtlinienobjekt-Einstellungen für die Verwaltung 

der Akzeptanz von Zertifikaten. So gibt es beispielsweise die neue Einstellung zum Verteilen vertrauenswürdiger 

Herausgeber zum Überprüfen von Software, die installiert und ausgeführt wird, unter 

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien 

öffentlicher Schlüssel\Vertrauenswürdige Herausgeber. 

Intern können Sie das Sperren von Zertifikaten steuern, denen nicht mehr vertraut wird. Eine Liste 

gesperrter Zertifikate kann über eine Zertifikatsperrliste oder OCSP verteilt werden. Windows 

Server 2008 bietet die Gruppenrichtlinienobjekt-Einstellung Nicht vertrauenswürdige Zertifikate. Hier 

handelt es sich um Zertifikate externer Zertifizierungsstellen, die Sie nicht sperren, jedoch als nicht 

vertrauenswürdig kennzeichnen möchten.


Die entsprechende Gruppenrichtlinienobjekt-Einstellung lautet Computerkonfiguration\Richtlinien\ 

Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel\Nicht vertrauenswürdige 

Zertifikate. 

Viele Optionen zur Verwaltung der Überprüfung wurden außerdem der Einstellung Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien 

öffentlicher Schlüssel\ 

Einstellungen für die Überprüfung des Zertifikatpfades hinzugefügt. Die Registerkarte Speicher kann 

dazu dienen, Benutzer am Hinzufügen vertrauenswürdiger Stammzertifizierungsstellen zu ihren Computern 

zu hindern. Die Registerkarte Vertrauenswürdige Herausgeber dient zum Steuern, ob Benutzer, 

Administratoren oder nur Unternehmensadministratoren die Liste vertrauenswürdiger Herausgeber 

von Software ändern dürfen. Auf der Registerkarte Netzwerkabruf können Zeitlimitwerte für 

OCSP-Anforderungen festgelegt werden. Die Registerkarte Sperrung dient zum Festlegen der Gültigkeitskeitsdauer 

von OSCP und Zertifikatsperrlisten. 

Konfigurieren der Serverspeicherung von Anmeldeinformationen 

In verschiedenen Unternehmen, z.B. Telemarketingfirmen, arbeiten Benutzer häufig an verschiedenen 

Computern. Da Zertifikate in den Profilen auf den Computern gespeichert werden, können 

Zertifikate in einer solchen Umgebung nicht ohne Weiteres eingesetzt werden. Eine Lösung sind servergespeicherte 

Benutzerprofile, bei denen Benutzerprofile bei jeder Abmeldung an einen Netzwerkspeicherort 

hochgeladen und bei der Anmeldung heruntergeladen werden. Servergespeicherte Profile 

enthalten jedoch neben dem Zertifikatspeicher sehr viele zusätzliche Daten, was zu langen Anmeldezeiten 

führen kann. 

Die Serverspeicherung von Anmeldeinformationen ermöglicht Benutzerzertifikaten und deren privaten 

Schlüsseln einen Wechsel auf einen anderen Computer, ohne dass servergespeicherte Benutzerprofile 

erforderlich sind. Wenn sich der Benutzer erstmals anmeldet, werden die Benutzerzertifikate 

im lokalen Zertifikatspeicher im entsprechende Benutzerkonto in Active Directory veröffentlicht. 

Gibt es in Active Directory veröffentlichte Zertifikate, die neuer als die lokalen Zertifikate sind, wird 

der lokale Zertifikatspeicher mit den Zertifikaten in Active Directory aktualisiert. Ab diesem Zeitpunkt 

werden neue für den Benutzer ausgestellte Zertifikate aus dem lokalen Speicher in Active 

Directory veröffentlicht. Wenn sich der Benutzer an einem anderen Computer anmeldet, werden die 

Zertifikate in Active Directory mit dem zu verwendenden lokalen Zertifikatspeicher synchronisiert. 

Die Serverspeicherung von Anmeldeinformationen wird immer dann ausgelöst, wenn sich ein Zertifikat 

im lokalen Zertifikatspeicher ändert, der Computer ge- bzw. entsperrt wird oder die Gruppenrichtlinien 

geändert werden. 

Hinweis Die Serverspeicherung von Anmeldeinformationen und servergespeicherte Benutzerprofile 

dürfen nicht parallel verwendet werden. 

Hinweis Zum Verwenden der Serverspeicherung von Anmeldeinformationen muss auf dem Client Windows 

XP SP2, Windows Server 2003 SP1, Windows Vista oder Windows Server 2008 ausgeführt werden. 

Die Gruppenrichtlinienobjekt-Einstellung zum Steuern der Serverspeicherung von Anmeldeinformationen 

lautet Benutzerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\ 

Richtlinien für öffentliche Schlüssel\Zertifikatdiensteclient - Einstellung für Serverspeicherung von 

Anmeldeinformationen (siehe Abbildung 17.14).

Entwerfen einer AD CS-Implementierung 681 

Die Option Maximale Alterungs-Gültigkeitsdauer von Anmeldeinformationen in Tagen bestimmt, wie 

lange ein Zertifikat in Active Directory verbleibt, nachdem es aus dem lokalen Zertifikatspeicher 

gelöscht wurde. Die Option Maximale Anzahl von servergespeicherten Anmeldeinformationen pro 

Benutzer begrenzt die Anzahl der Zertifikate, die auf dem Server gespeichert werden dürfen. Mit der 

Option Maximale Größe (in Byte) von servergespeicherten Anmeldeinformationen wird die maximale 

Größe eines Zertifikats und des privaten Schlüssels begrenzt, das/der auf dem Server gespeichert werden 

darf. Die Option Gespeicherte Benutzernamen und Kennwörter für Roaming verwenden ist neu 

unter Windows Server 2008 und ermöglicht die Serverspeicherung lokale gespeicherter Benutzernamen 

und Kennwörter für Ressourcen wie Websites, was allerdings nur von Computern mit Windows 

Vista unterstützt wird. 

Abbildung 17.14 Zertifikatdiensteclient - Gruppenrichtlinieneinstellung Serverspeicherung von 

Anmeldeinformationen 

Entwerfen einer AD CS-Implementierung 

Der AD CS-Entwurf muss vor der Implementierung sorgfältig geplant werden. Wenn Entwurfsänderungen 

nach der Implementierung erfolgen, kann dies zur Folge haben, dass viele Zertifikate neu ausgestellt 

werden müssen. Ein wichtiger Schritt im Entwurfsprozess ist das Bestimmen der zu verwendenden 

Zertifizierungsstellenhierarchie. Sie müssen außerdem die Zertifikatvorlagen bestimmen, die 

zur Unterstützung der Registrierung verwendet werden. Schließlich müssen Sie planen, wie die Zertifikatverteilung 

und -sperrung erfolgen soll. 

Entwerfen einer Zertifizierungsstellenhierarchie 

Die Zertifizierungsstellenhierarchie bildet die Organisation der Zertifizierungsstellen in Ihrem Unternehmen 

ab. Der Entwurf der Zertifizierungsstellenhierarchie bestimmt, wie Zertifikate von Ihrem 

Unternehmen ausgestellt und verwaltet werden. Vor dem Entwurf der Zertifizierungsstellenhierarchie 

müssen Sie exakt bestimmen, wie die Public Key-Infrastruktur verwendet werden soll.


Vorbereiten des Entwurfs einer Zertifizierungsstellenhierarchie 

Bevor Sie eine Zertifizierungsstellenhierarchie entwerfen können, müssen Sie den Projektumfang, die 

verwendeten Anwendungen sowie die technischen und geschäftlichen Anforderungen bestimmen. 

Beim Bestimmen des Umfangs kann der Entwurf für die gesamte Hierarchie oder nur einen Teil 

davon gelten. Der auszuwählende Umfang basiert auf der Verwaltung der PKI in Ihrem Unternehmen 

bzw. darauf, ob diese bereits implementiert wurde. Ein Unternehmen mit vorhandener PKI muss 

beispielsweise ggf. nur zusätzliche Infrastruktur entwerfen. Ein Unternehmen ohne PKI muss die 

gesamte Infrastruktur von Grund auf neu erstellen. 

Die Anwendungen, für die Sie die PKI verwenden, bestimmen die PKI-Implementierung. Es ist beispielsweise 

wahrscheinlich, dass Benutzerzertifikate zur Prozessoptimierung über die automatische 

Registrierung verteilt werden. An Webserver werden Zertifikate jedoch zumeist manuell ausgestellt. 

Sie können den Registrierungsdienst für Netzwerkgeräte einrichten, um die Implementierung von 

802.1X für die Authentifizierung von Netzwerkgeräten zu unterstützen. 

Die technischen Anforderungen umfassen die Anforderungen an Sicherheit und Verwaltung. Der Zertifizierungsstellenentwurf 

muss in Ihrem Unternehmen geltende Sicherheitsrichtlinien befolgen. Dazu 

können Hardwarespeichermodule zur Optimierung der Sicherheit gehören. Außerdem müssen Sie 

bestimmen, wer die Zertifizierungsstelleninfrastruktur verwalten soll. Bei Großunternehmen ist eine 

zentrale Verwaltung ggf. nicht realisierbar. In Großunternehmen werden meist einige Aufgaben zur 

Verwaltung von Zertifizierungsstellen lokalen Administratoren übertragen. 

Die geschäftlichen Anforderungen beziehen sich auf Verfügbarkeit und rechtliche Anforderungen und 

diktieren den Grad an Fehlertoleranz, der für Zertifizierungsstellen erforderlich ist. Wenn Ihre PKI 

beispielsweise Anwendungen unterstützt, die rund um die Uhr ausgeführt werden, ist Fehlertoleranz 

wichtig. Dadurch sind an manchen Standorten ggf. mehrere Zertifizierungsstellen nötig. Wenn Zertifikate 

in Ihrem Unternehmen jedoch nur gelegentlich ausgestellt werden, kann eine einzelne Zertifizierungsstelle 

ausreichend sein. Rechtliche Anforderungen hängen davon ab, ob externe Benutzer unterstützt 

werden müssen, und von den verwendeten Anwendungen ab. Jedes Unternehmen muss sein 

rechtlichen Obliegenheiten selbständig bestimmen. 

Hierarchietypen 

Wenn die Bereitstellung gänzlich intern erfolgt, benötigen Sie eine Stammzertifizierungsstellenhierarchie, 

bei der alle Zertifizierungsstellen einer gemeinsamen Stammzertifizierungsstelle vertrauen. 

Durch Einrichten einer Hierarchie können Sie verschiedenen Zertifizierungsstellen bestimmte Rollen 

zuordnen. Die ausstellenden Zertifizierungsstellen auf der untersten Stufe der Hierarchie können beispielsweise 

speziell für bestimmten Zertifikattypen oder geografische Standorte eingerichtet werden. 

Zertifizierungsstellen auf höheren Stufen können entsprechend den Sicherheitsanforderungen offline 

geschaltet werden. 

In einer Stammhierarchie implementieren große Unternehmen häufig drei Ebenen. Auf der ersten 

Ebene befindet sich die Stammzertifizierungsstelle. Auf der zweiten Ebene sind die Richtlinienzertifizierungsstellen. 

Eine Richtlinienzertifizierungsstelle legt Regeln fest, die untergeordnete Zertifizierungsstellen 

befolgen müssen, und kann zum Definieren von Richtlinien verwendet werden, die alle 

untergeordneten Zertifizierungsstellen für einen geografischen oder Unternehmensbereich betreffen. 

Auf der dritten Ebene befinden sich schließlich die Zertifizierungsstellen, die Zertifikate für Benutzer, 

Computer und Geräte ausstellen.


Stammzertifizierungsstelle 

Ausstellende 

Zertifizierungsstelle 

Ausstellende 


Ausstellende 



Stammzertifizierungsstellenhierarchie 

In vielen Fällen haben zwei Unternehmen bereits vorhandene Public Key-Infrastrukturen, die integriert 

werden müssen. In diesem Fall nutzen Sie eine Hierarchie zur gegenseitigen Zertifizierung (siehe 

Abbildung 17.16). Eine Zertifizierungsstelle im ersten Unternehmen stellt einer Zertifizierungsstelle 

im zweiten Unternehmen ein untergeordnetes Zertifizierungsstellenzertifikat aus. Eine Zertifizierungsstelle 

im zweiten Unternehmen stellt einer Zertifizierungsstelle im ersten Unternehmen ebenfalls 

ein untergeordnetes Zertifizierungsstellenzertifikat aus. Auf diese Weise wird von beiden Unternehmen 

ausgestellten Zertifikaten von beiden Unternehmen vertraut. Der Hauptnachteil dieser 

Konfiguration ist das vollständige Vertrauen in das andere Unternehmen, das erforderlich ist. 

Richtlinienzertifizierungsstelle 


Ausstellende 




Ausstellende 



Ausstellende 


Ausstellende 



Ausstellende 


Stammzertifizierungsstellenhierarchie mit gegenseitiger Zertifizierung 

Ausstellende 

Zertifizierungsstelle


Rollen in der Zertifizierungsstellenhierarchie 

Eine typische Zertifizierungsstellenhierarchie hat drei Ebenen. Diese Anzahl von Ebenen ist hinsichtlich 

der Flexibilität optimal. Bei mehr als drei Ebenen ergibt sich nur wenig mehr Flexibilität, jedoch 

mehr Komplexität. 

Auf der ersten Ebene befindet sich die Stammzertifizierungsstelle, die ihr eigenes Zertifikat ausstellt 

und die Richtlinienzertifizierungsstellen autorisiert. Ist die Sicherheit der Stammzertifizierungsstelle 

gefährdet, ist auch die Sicherheit aller von der gesamten Hierarchie ausgestellten Zertifikate 

gefährdet. 

Auf der zweiten Ebene befinden sich die Richtlinienzertifizierungsstellen. Eine Richtlinienzertifizierungsstelle 

setzt die Richtlinien und Verfahren für die Ausstellung von Zertifikaten durch. Aufgabe 

einer Richtlinienzertifizierungsstelle ist die Autorisierung der ausstellenden Zertifizierungsstellen. 

Mehrere Richtlinienzertifizierungsstellen sind nur dann erforderlich, wenn für die Ausstellung von 

Zertifikaten an verschiedene Benutzergruppen unterschiedliche Richtlinien befolgt werden. Zwei 

Abteilungen können beispielsweise unterschiedlichen Regeln unterliegen. 

Auf der dritten Ebene befinden sich die ausstellenden Zertifizierungsstellen, die für das Ausstellen 

von Zertifikaten an Clients zuständig sind. Eine ausstellende Zertifizierungsstelle muss stets online 

sein und ist zur Vereinfachung der Verwaltung zumeist eine Unternehmenszertifizierungsstelle. Ausstellende 

Zertifizierungsstellen können nach Zertifikatzweck, Standort, Abteilung oder Benutzertyp 

organisiert sein. Wenn eine Zertifizierungsstelle Zertifikate für das verschlüsselnde Dateisystem 

(EFS) ausstellt, basiert die Organisation auf dem Zertifikatzweck. Wenn eine Zertifizierungsstelle 

Zertifikate für externe Benutzer ausstellt, basiert die Organisation auf dem Benutzertyp. 

Die tatsächliche Anzahl von Ebenen in Ihrer Zertifizierungsstellenhierarchie hängt von den Anforderungen 

Ihres Unternehmens ab. In einer Umgebung mit sehr niedrigen Sicherheitsanforderungen mit 

nur einer minimalen Anzahl ausgestellter Zertifikate wird ggf. nur eine Stammzertifizierungsstelle 

zum Ausstellen von Zertifikaten eingesetzt. Sollten die Sicherheitsanforderungen und die Anzahl der 

ausgestellten Zertifikate ansteigen, kann eine zweite, dritte oder sogar vierte Ebene hinzugefügt werden. 

Beim mehreren Ebenen wird der Einsatz einer Offlinestamm- und Richtlinienzertifizierungsstellen 

empfohlen. 

Trennung von Rollen für die Verwaltung 

Die Verwaltungsrollen für die Windows-basierte Public Key-Infrastruktur (PKI) können voneinander 

getrennt werden. Wichtig ist es zu wissen, welche Rollen welchen Benutzern zugewiesen wurden, da 

diese bei zur Verwaltung der PKI zusammenarbeiten müssen. Wenn einem Benutzer mehrere Rollen 

zugewiesen wurden, kann er die dazugehörigen Aufgaben nicht ausführen. Die folgenden Verwaltungsrollen 

wurden festgelegt: 

• Zertifizierungsstellenadministrator Aufgabe dieser Rolle ist das Konfigurieren von Zertifikatdiensten, 

das Zuweisen von Zertifikatverwaltern und das Erneuern von Zertifikaten. 

• Zertifikatverwaltung Aufgabe dieser Rolle ist das Ausstellen und Sperren von Zertifikaten. 

• Auditor Aufgabe dieser Rolle ist das Überprüfen des Sicherheitsereignisprotokolls auf zertifikatdienstbezogene 

Ereignisse. 

• Sicherungs-Operatoren Dieser Rolle zugewiesene Benutzer können die Zertifizierungsstellenkonfiguration 

und -datenbank sowie das Zertifizierungsstellen-Schlüsselpaar sichern. 

Die Rollentrennung ist nicht standardmäßig aktiviert. Rufen Sie dazu den Befehl certutil -setreg ca\ 

RoleSeparationEnabled 1 auf. Die Zertifikatdienste müssen neu gestartet werden, damit diese Änderung 

wirksam wird.


Entwerfen von Zertifikatvorlagen 

Das Entwerfen von Zertifikatvorlagen umfasst das Auswählen von Optionen, die die Anforderungen 

Ihres Unternehmens am besten erfüllen. Wenngleich die von Ihnen gewählten Optionen spezifisch für 

Ihr Unternehmen sind, gelten für bestimmte Einstellungen dennoch allgemeine Empfehlungen. 

Gültigkeits- und Erneuerungszeitraum 

Ein Zertifikat kann bis zum Ende seiner Gültigkeitsdauer genutzt werden, es sei denn, es wird 

gesperrt. Wichtig ist es, die Gültigkeitsdauer mit dem Zweck des Zertifikats abzugleichen. Die Gültigkeitsdauer 

eines Zertifizierungsstellenzertifikats ist üblicherweise lang, da eine Zertifizierungsstelle 

nur Zertifikate mit einer Gültigkeitsdauer ausstellen kann, die mit oder vor Ablauf dem Ablauf des 

eigenen Zertifizierungsstellenzertifikats endet. Zertifikate für die Authentifizierung haben in der 

Regel eine kürzere Gültigkeitsdauer von maximal einem Jahr, um eine Sperrung nach Möglichkeit zu 

vermeiden. 

Der Erneuerungszeitraum eines Zertifikats bestimmt, wie lange vor Ablauf der Zertifikatgültigkeitsdauer 

der Client versucht, das Zertifikat zu erneuern. Die Erneuerung vor Ablauf der Gültigkeitsdauer 

stellt sicher, dass eine kurzzeitige Unterbrechung des Zertifizierungsstellendienstes die Erneuerung 

von Zertifikaten nicht beeinträchtigt. Wenn der Erneuerungszeitraum größer als 20 % der 

gesamten Zertifikatgültigkeitsdauer ist, wird das Zertifikat erst erneuert, nachdem 80 % der Gültigkeitsdauer 

abgelaufen sind. 

Zwecke von Zertifikaten 

Der Zertifikatzweck kann in einer Zertifikatvorlage exakt festgelegt werden. Grundlage ist hierbei, 

wie Sie Benutzeraktivitäten steuern möchten. 

Eine Methode ist das Ermitteln aller Zwecke, die ggf. bei Ihren Benutzern in Frage kommen, und das 

anschließende Ausstellen eines allgemeinen Benutzerzertifikats, das alle diese Zwecke erfüllt. In 

einem solchen Fall können jedoch alle Benutzer das Zertifikat für alle Zwecke nutzen, sodass Sie 

nicht einschränken können, welche Anwendungen Benutzergruppen verwenden dürfen. 

Die Alternative ist das Erstellen spezieller Zertifikatvorlage für bestimmte Zwecke und anschließende 

Erteilen von Berechtigungen für diese Zertifikatvorlage an ausschließlich Benutzergruppen, 

denen Sie die Nutzung bestimmter Anwendungen gestatten möchten. Diese Vorgehensweise bietet 

mehr Sicherheit und Steuerungsmöglichkeiten. Allerdings ist auch der Aufwand für die Verwaltung 

der verschiedenen Vorlagen größer. 

Der Zweck eines Zertifikats wird auf der Registerkarte Erweiterung einer Zertifikatvorlage bestimmt. 

Es gibt zwei Erweiterungen zum Bestimmen des Zertifikatzwecks: Anwendungsrichtlinien und Erweiterte 

Schlüsselverwendung. Anwendungsrichtlinien sind Microsoft-spezifisch, während die erweiterte 

Schlüsselverwendung von anderen Zertifizierungsstellenanbietern verwendet wird. Sind beide Erweiterungen 

Teil einer Zertifikatvorlage, müssen sie mit exakt denselben Einstellungen konfiguriert werden. 

Anforderungen an den Namen des Antragstellers 

Der Antragsteller ist der Benutzer oder Computer, der das Zertifikat anfordert. Sie können ermitteln, 

wie der Name eines Zertifikats abgeleitet wird (siehe Abbildung 17.17). In den meisten Fällen wird 

der Antragstellername anhand von Active Directory-Daten erstellt, was für die Unterstützung der 

automatischen Registrierung erforderlich ist. Das Format des Antragstellernamens kann entweder auf 

dem vollständig definierten oder dem allgemeinen Namen des Anforderers basieren.


Das Verwenden des vollständig definierten Namens gewährleistet, dass der Antragstellername 

eindeutig ist. 

Falls ein Computer- oder Benutzerkonto einige der benötigten Informationen nicht enthält, schlägt 

die Ausstellung des Zertifikats fehl. Wenn beispielsweise die E-Mail-Adresse Teil des Antragstellernamens 

ist, verhindert eine fehlende E-Mail-Adresse im Benutzerobjekt die Ausstellung des Zertifikats. 

Dieser Fehler wird im MMC-Snap-In Zertifizierungsstelle im Knoten Fehlgeschlagene Anforderungen 

angezeigt. 


Einstellungen für den Antragstellernamen in einer Zertifikatvorlage 

Wenn Sie die Option Informationen werden in der Anforderung angegeben auswählen, werden die 

Benutzer während der Registrierung zur Eingabe des Antragstellernamens aufgefordert. Diese Option 

setzt voraus, dass Benutzer mit dem Zertifikatregistrierungsprozess vertraut sind und einen entsprechenden 

Namen auswählen. In den meisten Fällen sollte diese Option nicht gewählt werden, da sie 

nicht zusammen mit der automatischen Registrierung verwendet werden kann. 

Ausstellungsrichtlinien 

Ausstellungsrichtlinien sind Bezeichner in einem Zertifikat, die beschreiben, bis zu welchem Grad Ihr 

Unternehmen dem Zertifikat vertraut. Die Umsetzung von Ausstellungsrichtlinien wird technisch 

nicht erzwungen. Ihr Unternehmen muss bei der Ausstellung des Zertifikats den gewünschten Sicherheitsgrad 

bestimmen. Windows Server 2008 bietet die folgenden Ausstellungsrichtlinien und ermöglicht 

das Erstellen benutzerdefinierter Ausstellungsrichtlinien: Alle ausgegebenen Richtlinien, Europäisches 

qualifiziertes Zertifikat, Hohe Zusicherung, Mittlere Zusicherung, Niedrige Zusicherung und 

SSCD-qualifiziertes Zertifikat.


Ausstellungssicherheit 

Sie können die Ausstellungssicherheit optimieren, indem Sie die Genehmigung des Zertifikatverwalters 

oder das Signieren von Anforderungen anfordern. Bei Anfordern der Genehmigung durch den 

Zertifikatverwalter muss dieser alle Anforderungen manuell überprüfen, bevor sie genehmigt werden. 

Dadurch kann der Zertifikatverwalter zusätzliche Identitätsprüfungen vornehmen. Durch Signieren 

von Anforderungen wird die Identität des Zertifikatanforderers überprüft. 

Entwerfen der Zertifikatverteilung und -sperrung 

Die Vorgehensweisen bei der Zertifikatverteilung und -sperrung basieren auf den spezifischen Anforderungen 

Ihres Unternehmens. Die Zertifikatverteilung muss den Benutzern erlauben, sich bei minimalem 

Aufwand für die benötigten Zertifikate zu registrieren. Bei der Zertifikatsperrung müssen 

aktuelle Informationen ohne Überlastung von Netzwerkressourcen bereitgestellt werden. 

Zertifikatverteilung 

Die Zertifikatverteilung bestimmt, wie Clients Zertifikate erhalten. Dies umfasst den Typ und die 

Schnittstelle für die Registrierung. Nach Möglichkeit sollte stets die automatische Registrierung für 

die Ausstellung sehr vieler Zertifikate genutzt werden, da dadurch der Verwaltungsaufwand verringert 

und die Benutzerzufriedenheit gesteigert wird. Dies ist jedoch nur möglich, wenn eine Unternehmenszertifizierungsstelle 

für zu Active Directory gehörende Clients verwendet wird. 

Das MMC-Snap-In Zertifikate eignet sich zum Abrufen von Zertifikaten von einer Unternehmenszertifizierungsstelle. 

Es liest die verfügbaren Zertifikatvorlagen aus Active Directory aus und zeigt nur 

Optionen an, die dem Benutzer, für den Zertifikate abgerufen werden, verfügbar sind. Auch diese 

Funktionalität gilt nur für Clients, die zu Active Directory gehören. 

Die Registrierungswebseiten der Zertifizierungsstelle sind erforderlich, wenn ein Anforderer nicht zu 

Active Directory gehört oder eine eigenständige Zertifizierungsstelle Zertifikate ausstellt. Diese Seiten 

sind außerdem für bestimmte Sonderfälle erforderlich, z.B. für die Registrierung und den Abruf 

von Zertifikaten für Schlüsselwiederherstellungs-Agents. 

Zertifikatsperrung 

Windows Server 2008 bietet für die Überprüfung des Sperrstatus von Zertifikaten Zertifikatsperrlisten 

und das OCSP-Protokoll. Die Verteilung von Zertifikatsperrlisten erfolgt für Active Directory- 

Clients automatisch. Clients, die nicht zu Active Directory gehören, können die Zertifikatsperrliste 

von den Webregistrierungsseiten der Zertifizierungsstelle herunterladen. Es ist jedoch unwahrscheinlich, 

dass ein Client solch einen manuellen Prozess ausführt. OCSP kann für Clients verwendet werden, 

die zu Active Directory gehören oder auch nicht. 

Im Allgemeinen bietet OCSP eine bessere Netzwerkleistung, sofern Zertifikatüberprüfungen nicht 

häufig erfolgen. Zertifikatsperrlisten führen bei zahlreichen Zertifikatprüfungen zu wenig Netzwerkdatenverkehr, 

da sie lokal zwischengespeichert werden. 


Die Active Directory-Zertifikatdienste (AD CS) sind die Microsoft-Implementierung einer Zertifizierungsstelle 

und umfassen Verwaltungsprogramme wie eine Unternehmens-PKI (Public Key-Infrastruktur) 

und das Snap-In Zertifizierungsstelle. Es gibt Unternehmenszertifizierungsstellen und eigenständige 

Zertifizierungsstellen.


Eine Unternehmenszertifizierungsstelle ist mit Active Directory integriert und kann für die automatische 

Registrierung Zertifikatvorlagen verwenden. Die erste installierte Zertifizierungsstelle ist eine 

Stammzertifizierungsstelle. Weitere Zertifizierungsstellen in derselben Hierarchie sind untergeordnete 

Zertifizierungsstellen. 

Sie können die Webregistrierung konfigurieren, damit Benutzer Zertifikate über eine Webseite abrufen 

können. Eine Zertifikatsperrliste wird von Clients zum Überprüfen der Gültigkeit eines Zertifikats 

verwendet. Sie können zum Bereitstellen von Zertifikatstatusinformationen auch einen Online- 

Responder konfigurieren. Die Schlüsselarchivierung kann implementiert werden, um von einer 

Windows Server 2008-Zertifizierungsstelle ausgestellte private Schlüssel für Zertifikate automatisch 

zu archivieren. 

Zertifikatvorlagen dienen zum Bestimmen, welche Zertifikattypen ein Benutzer oder Computer 

abrufen kann, und für die automatische Registrierung für Zertifikate. Ob Zertifikatvorlagen Benutzern 

zur Verfügung stehen, wird von Berechtigungen gesteuert, die den Zertifikatvorlagen zugewiesen 

wurden. Die Serverspeicherung von Anmeldeinformationen erlaubt Benutzern die Verwendung 

ihrer Zertifikate auf verschiedenen Computern und macht keine servergespeicherten Benutzerprofile 

erforderlich. 


• Vergewissern Sie sich, dass einer externen Zertifizierungsstelle von Clients automatisch vertraut 

wird, bevor Sie ein von dieser Zertifizierungsstelle ausgestelltes Zertifikat beziehen. 

• Arbeiten Sie mit einer internen Zertifizierungsstelle für interne Anwendungen, da Clients mühelos 

so konfiguriert werden können, dass sie der internen Zertifizierungsstelle vertrauen. 

• Verwenden Sie eine Offline-Stammzertifizierungsstelle zur Steigerung der Sicherheit. 

• Arbeiten Sie mit einer Unternehmenszertifizierungsstelle für die Ausstellung von Zertifikaten, um 

die automatische Registrierung zu ermöglichen. 

• Nutzen Sie die automatische Registrierung, wenn sehr viele Zertifikate für Benutzer oder Computer 

ausgestellt werden müssen. 

• Über die Schlüsselarchivierung und -wiederherstellung können Sie die Wiederherstellung verloren 

gegangener privater Schlüssel ermöglichen. 

• Ein Online-Responder dient zum sofortigen Überprüfen des Zertifikatstatus. 

• Arbeiten Sie mit der Verteilung von Zertifikatsperrlisten zur Unterstützung von Clients mit 

Windows 2000, Windows XP und Windows Server 2003. 

• Setzen Sie die Serverspeicherung von Anmeldeinformationen ein, wenn Benutzer regelmäßig an 

mehreren Computern arbeiten. 

• Wählen Sie eine Zertifizierungsstellenhierarchie mit mehreren Ebenen, um die Sicherheit zu 

optimieren. 



diesem Kapitel.



• Die Webseite zu den Active Directory-Zertifikatdiensten finden Sie unter http://technet2.microsoft.com/windowsserver2008/de/servermanager/activedirectorycertificateservices.mspx. 

• Weitere Informationen zu Wevtutil.exe finden Sie unter http://technet2.microsoft.com/ 

windowsserver2008/en/library/d4c791e0-7e59-45c5-aa55-0223b77a48221033.mspx?mfr=true. 

• Detaillierte Informationen zu X.509, Version 3, und zur PKI finden Sie in „RFC 3280: Internet 

X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile“ unter 

http://www.ietf.org/rfc/rfc3280.txt. 

• Weitere Informationen zum Entwickeln von Kryptografiedienstanbietern finden Sie in „Writing a 

CSP“ unter http://msdn2.microsoft.com/en-us/library/aa388213(VS.85).aspx. 

• Detaillierte Anweisungen zum Abrufen eines OCSP-Antwortsignaturzertifikats mithilfe einer 

eigenständigen Zertifizierungsstelle finden Sie im Abschnitt „Enrolling for an OCSP Response 

Signing Certificate Against a Stand-Alone CA“ unter Installing, Configuring, and Troubleshooting 

the Microsoft Online Responder at http://technet2.microsoft.com/windowsserver2008/en/ 

library/045d2a97-1bff-43bd-8dea-f2df7e270e1f1033.mspx. 


Windows Server 2008 bietet mehrere Tools, die bei der Verwaltung der AD CS eingesetzt werden 

können. In Tabelle 17-2 finden Sie einige dieser Tools und ihre Einsatzmöglichkeiten. 

Tabelle 17.2 

AD CS-Verwaltungstools 

Toolname 

Snap-In Zertifikatvorlagen 

Snap-In Zertifikate 

Snap-In Zertifizierungsstelle 

Certreq.exe 

Certutil.exe 

Snap-In Unternehmens-PKI 

Konsole Gruppenrichtlinienverwaltung 

Snap-In Online-Responder 

Wevtutil.exe 


Dient zum Verwalten von Zertifikatvorlagen 

Dient zum Verwalten von an Benutzer, Computer und Dienste ausgestellte 

Zertifikate 

Dient zum Verwalten von Windows-Zertifizierungsstellen 

Dient zum Erstellen und Verwalten von Zertifikatanforderungen über eine 

Befehlszeile 

Dient zum Verwalten von Zertifikaten und Zertifizierungsstellen über eine 

Befehlszeile 

Dient zum Anzeigen des Status aller Zertifizierungsstellen in einem Unternehmen 

Dient zum Ändern von Gruppenrichtlinienobjekten und Konfigurieren von 

Computern für die automatische Registrierung und die Serverspeicherung 

von Anmeldeinformationen 

Dient zum Verwalten der Online-Responder eines gesamten Unternehmens 

Dient dem Zugriff auf Ereignisprotokollinformationen über die Befehlszeile

691 

K A P I T E L 1 8 

Active Directory-Rechteverwaltungsdienste 


Überblick über die AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 

Implementieren der AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 

Verwalten der AD RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 



Die meisten IT-Experten sind sich einig, dass der Schutz von digitalen Informationen häufig eine 

schwierige und herausfordernde Aufgabe darstellt. Organisationen investieren immer größere Summen 

in die Implementierung von mehreren Sicherheitsstufen wie z.B. Umkreisfirewalls, um den 

Zugriff auf Netzwerk-, Verschlüsselungs- und Authentifizierungstechnologien zu sichern und dadurch 

die Sicherheit der Netzwerkkommunikation zu erhöhen. Dokumente werden typischerweise durch die 

Verwendung von sorgfältig erstellten Sicherheitsgruppen und Zugriffssteuerungslisten (Access Control 

Lists, ACLs) geschützt, über die festgelegt wird, welche Benutzer mit welchen Zugriffsberechtigungen 

auf Informationen zugreifen können. 

Doch selbst bei Implementierung all dieser Sicherheitsmethoden vergessen Organisationen häufig, 

dass die Empfänger die erhaltenen Informationen beliebig bearbeiten und behandeln können. Oftmals 

sind keine weiteren Einschränkungen im Hinblick darauf festgelegt, welche Aufgaben der Empfänger 

nach dem Zugriff für die Daten ausführen bzw. an wen er diese Informationen senden darf. Wenn sich 

eine Organisation darauf verlässt, dass einzelne Benutzer nach eigenem Ermessen entscheiden können, 

wie sie vertrauliche Informationen verwenden und weitergeben, stellt dies ein nicht akzeptables 

Risiko für das Sicherheitsmodell dieser Organisation dar. So kann ein Benutzer beispielsweise eine 

vertrauliche E-Mail-Nachricht an Empfänger weiterleiten, die diese nicht erhalten sollten, oder für ein 

vertrauliches Dokument Aufgaben durchführen, zu denen er nicht berechtigt ist (z.B. nicht zulässige 

Kopier-, Bearbeitungs- oder Druckvorgänge). 

Neben dem nicht ordnungsgemäßen Umgang mit Dokumenten müssen Organisationen auch die aktuellsten 

Gesetze im Hinblick auf Datenschutz und Offenlegung von Informationen berücksichtigen. In 

vielen Ländern wurden gesetzliche Bestimmungen zum Schutz von privaten Daten, wie personenbezogenen 

Gesundheitsdaten oder Finanzinformationen, eingeführt. Es ist äußerst wichtig, dass diese 

privaten Informationen sicher sind und selbst berechtigte Benutzer lediglich Aufgaben ausführen dürfen, 

mit denen die Einhaltung von Datenschutzbestimmungen erfüllt werden. 

In diesem Kapitel werden die Active Directory-Rechteverwaltungsdienste (Active Directory Rights 

Management Services, AD RMS) als Lösung vorgestellt, um die digitalen Informationen einer Organisation 

zu schützen. Neben der Funktionsweise der AD RMS wird die Implementierung und Verwaltung 

dieser Lösung beschrieben, um Informationen für interne, externe und organisationsübergreifende 

Benutzer zu schützen.

692 Kapitel 18: Active Directory-Rechteverwaltungsdienste 

Überblick über die AD RMS 

Die Sicherheitsstrategie einer Organisation muss Methoden umfassen, um die Sicherheit, den Schutz 

und die Gültigkeit von Unternehmensdaten und -informationen aufrecht zu erhalten. Dies umfasst 

nicht nur die Steuerung des Zugriffs auf die Daten, sondern ferner, wie die Daten verwendet und an 

interne und externe Benutzer verteilt werden. Die Strategie kann zudem Methoden umfassen, um 

sicherzustellen, dass die Daten manipulationssicher und die aktuellsten Informationen basierend auf 

dem Ablauf von überholten oder zeitkritischen Informationen gültig sind. 

Mit den AD RMS wird die vorhandene Sicherheitsstrategie einer Organisation erweitert, indem 

dauerhafte Nutzungsrichtlinien auf digitale Informationen angewendet werden. In einer Nutzungsrichtlinie 

werden vertrauenswürdige Entitäten wie Benutzer, Benutzergruppen, Computer oder 

Anwendungen festgelegt. Diese Entitäten können Informationen nur basierend auf den innerhalb der 

Richtlinie konfigurierten Rechten und Bedingungen verwenden. Rechte können Berechtigungen zum 

Durchführen von Aufgaben wie Lesen, Kopieren/Einfügen, Drucken, Speichern, Weiterleiten und 

Bearbeiten umfassen. Zudem können Rechte durch Bedingungen ergänzt werden, z.B., wenn für eine 

bestimmte Entität ein Ablaufzeitraum für die Nutzungsrichtlinie festgelegt wird. Nutzungsrichtlinien 

werden zu jedem Zeitpunkt für die geschützten Daten beibehalten, um Informationen zu schützen, die 

innerhalb des Intranets einer Organisation gespeichert, extern per E-Mail gesendet oder über ein 

mobiles Gerät übermittelt werden. 

Hinweis Die Rechteverwaltung darf nicht mit DRM (Digital Rights Management) verwechselt werden. 

DRM ist eine separate Technologie zum Schutz von Multimediainhalten wie Musikdaten, Videoaufnahmen 

und eBooks, die nicht mit den AD RMS verknüpft ist. 

AD RMS-Features 

Eine AD RMS-Lösung wird typischerweise innerhalb einer Organisation bereitgestellt, um die Verteilung 

von vertraulichen Informationen an nicht berechtigte Benutzer zu verhindern. Das Hinzufügen 

von AD RMS-fähigen Clientanwendungen wie dem Office 2007-System oder AD RMS-kompatiblen 

Serverrollen wie Exchange Server 2007 und Microsoft Office SharePoint Server 2007 bietet eine 

Gesamtlösung für die folgenden Verwendungzwecke: 

• Erzwingen von Dokumentrechten Jede Organisation verfügt über Dokumente, die als vertrauliche 

Informationen eingestuft werden können. Mithilfe der AD RMS lässt sich steuern, wer diese vertraulichen 

Dateien anzeigen kann. Ferner kann der Benutzerzugriff auf ausgewählte Anwendungsfunktionen 

wie Drucken, Speichern, Kopieren und Einfügen verhindert werden. Wenn eine 

Gruppe von Mitarbeitern gemeinsam an einem Dokument arbeitet und dieses häufig aktualisiert, 

kann eine Richtlinie konfiguriert und angewendet werden, die für jeden veröffentlichten Entwurf 

ein Ablaufdatum der Dokumentrechte enthält. So kann sichergestellt werden, dass alle beteiligten 

Benutzer ausschließlich die aktuellsten Informationen verwenden – die älteren Versionen lassen 

sich nicht mehr öffnen, nachdem das Ablaufdatum erreicht ist. 

• Schützen der E-Mail-Kommunikation Microsoft Office Outlook 2007 kann mit den AD RMS eingesetzt 

werden, um den versehentlichen oder vorsätzlichen nicht ordnungsgemäßen Umgang mit 

E-Mail-Nachrichten zu verhindern. Wenn ein Benutzer eine AD RMS-Vorlage für Benutzerrechterichtlinien 

auf eine E-Mail-Nachricht anwendet, können verschiedene Aufgaben deaktiviert werden 

(z.B. das Weiterleiten der Nachricht, Kopieren und Einfügen von Inhalten, Drucken und 

Exportieren der Nachricht).

Überblick über die AD RMS 693 

Direkt von der Quelle: Integrieren der AD RMS mit Office SharePoint Server 2007 

Die AD RMS lassen sich in Microsoft Office SharePoint Server 2007 integrieren, um Geschäftsdaten 

mithilfe von Zugriffsbeschränkungen auf Dokumentbibliotheksebene präzise steuern zu können. 

Wenn ein Benutzer zu einer durch Rechte geschützten Dokumentbibliothek wechselt und 

versucht, ein Dokument herunterzuladen, wendet Office SharePoint Server 2007 die für die Dokumentbibliothek 

konfigurierten Berechtigungen auf das Dokument an. Folglich ist eine direkte 

Zuordnung zwischen Office SharePoint Server 2007 und Dokumentberechtigungen vorhanden, 

über welche die Office SharePoint Server 2007-Rollen, die mit dem Dokument verknüpft sind, in 

AD RMS-Berechtigungen für das Dokument selbst übersetzt werden. 

Brian M. Lich 

Technical Writer 

Windows Server Security 

Hinweis Die AD RMS eignen sich gut, um digitale Daten gegen eine nicht ordnungsgemäße Verwendung 

zu schützen. Diese Lösung schützt jedoch nicht vor Angriffen wie Drittanbieterprogrammen zur Bildschirmerfassung 

oder vor dem Abfotografieren von vertraulichen Onlineinformationen mit einer Digitalkamera. Es 

ist wichtig, die AD RMS als zusätzliche Stufe der Sicherheitsstrategie zum Schutz digitaler Informationen zu 

verstehen. Andere Sicherheitsmaßnahmen wie das Konfigurieren geeigneter Zugriffssteuerungslisten und 

einer sicheren Desktopverwaltung sollten weiterhin implementiert werden. 

Abhängig von den Sicherheitsanforderungen einer Organisation wurden möglicherweise bereits eine 

Reihe von Technologien zum Schutz digitaler Inhalte implementiert. Technologien wie Zugriffssteuerungslisten 

(Access Control Lists, ACLs), Secure Multipurpose Internet Mail Extensions (S/MIME) 

oder das verschlüsselnde Dateisystem (Encrypted File System, EFS) können eingesetzt werden, um 

E-Mails und Unternehmensdokumente zu schützen. Die AD RMS bieten jedoch weitere Vorteile und 

Features, um die Vertraulichkeit und die Verwendung der in diesen Dokumenten gespeicherten Daten 

zu schützen. Tabelle 18.1 zeigt einen Vergleich dieser Features mit anderen gängigen Technologien, 

die typischerweise in einer Unternehmensumgebung implementiert sind. 

Tabelle 18.1 

AD RMS-Featurevergleich 

Feature RMS ACLs S/MIME- 

Signierung 

Überprüfen der Identität des 

Herausgebers 

Unterscheiden zwischen Berechtigungen 

basierend auf dem 

Benutzer 

Verhindern der Anzeige durch 

nicht berechtigte Benutzer 

Verschlüsseln von geschützten 

Inhalten 

Festlegen von Ablaufzeiträumen 

für Inhalte 

S/MIME-Verschlüsselung 

EFS 

Nein Nein Ja Nein Nein 

Ja Ja Nein Nein Nein 

Ja Ja Nein Ja Ja 

Ja Nein Nein Ja Ja 

Ja Nein Nein Nein Nein


Tabelle 18.1 

AD RMS-Featurevergleich (Fortsetzung) 

Feature RMS ACLs S/MIME- 

Signierung 

Steuern von Vorgängen wie 

Lesen, Weiterleiten, Speichern, 

Ändern oder Drucken von Inhalten 

durch den Benutzer 

Erweitern des Schutzes auf 

andere Speicherorte als das 

ursprüngliche Veröffentlichungsverzeichnis 

AD RMS-Komponenten 

Ja Festlegung von Änderungs-, 

Schreiboder 

nur Leseberechtigung 

möglich 

Nein Nein Nein 

Ja Nein Ja Ja Ja, für Ordner, die 

auf mit NTFS formatierten 

Volumes 

gespeichert 

und für die Verschlüsselung 

gekennzeichnet 

sind 

Die Implementierung einer AD RMS-Lösung umfasst verschiedene, teilweise optionale Komponenten. 

Die Komplexität einer spezifischen Konfiguration ist durch die Größe einer Organisation sowie 

die Anforderungen an Skalierbarkeit und gemeinsame Datenverwendung bestimmt. Abbildung 18.1 

zeigt die Hauptkomponenten einer AD RMS-Lösung. 

AD RMS-Stammcluster 

Webserver (IIS) 

Active Directory-Domänendienste 

Dienstverbindungspunkt 

Benutzer- und Gruppenkonfiguration 

S/MIME-Verschlüsselung 

EFS 

Reiner AD RMS-Lizenzierungscluster 

AD RMS- 

Client 

AD RMS- 

Client 

SQL-Server 

Konfigurationsdatenprotokollierung 

SQL-Server 

AD RMS- 

Client 

AD RMS- 

Client 


AD RMS-Komponenten


AD RMS-Stammcluster 

Der AD RMS-Stammcluster ist die primäre Komponente einer RMS-Bereitstellung und wird zur Verwaltung 

aller Zertifizierungs- und Lizenzierungsanforderungen für Clients verwendet. Eine Active 

Directory-Gesamtstruktur kann über maximal einen Stammcluster verfügen, der mindestens einen 

Windows Server 2008-Server zur Ausführung der AD RMS-Serverrolle umfasst. Für Redundanz und 

Lastenausgleich können weitere Server zum Cluster hinzugefügt werden. Bei der Erstinstallation führt 

der AD RMS-Stammcluster eine automatische Registrierung durch, bei der ein Server-Lizenzgeberzertifikat 

(Server Licensor Certificate, SLC) erstellt und signiert wird. Über das Server-Lizenzgeberzertifikat 

kann der AD RMS-Server Zertifikate und Lizenzen für AD RMS-Clients ausstellen. In 

vorherigen Versionen von RMS musste dieses Zertifikat über das Internet durch den Microsoft-Registrierungsdienst 

signiert werden. Daher war auf dem RMS-Server oder einem anderen Computer, der 

zur Offlineregistrierung des Servers verwendet wurde, Internetkonnektivität erforderlich. Für die 

Windows Server 2008 AD RMS muss keine Verbindung mit dem Microsoft-Registrierungsdienst hergestellt 

werden. Windows Server 2008 umfasst ein Server-Selbstregistrierungszertifikat, das zum 

lokalen Signieren des Server-Lizenzgeberzertifikats verwendet wird. Daher wird nun keine Internetverbindung 

mehr benötigt, um den RMS-Clusterregistrierungsvorgang abzuschließen. 

Hinweis Der AD RMS-Stammcluster darf nicht mit dem Failoverclusteringfeature von Windows Server 

2008 verwechselt werden. 

Webdienste 

Für jeden Server, der mit der AD RMS-Serverrolle installiert wird, sind ferner verschiedene webbezogene 

Serverrollen und Features erforderlich. Zur Bereitstellung der meisten AD RMS-Anwendungsdienste 

(z.B. Lizenzierung und Zertifizierung) wird die Serverrolle Webserver (IIS) benötigt. 

Diese IIS-basierten Dienste werden als Anwendungspipelines bezeichnet. Auch die Features Windows-Prozessaktivierungsdienst 

and Message Queuing sind für die AD RMS-Funktionalität erforderlich. 

Der Window-Prozessaktivierungsdienst wird für den Zugriff auf IIS-Features aus einer beliebigen 

Anwendung eingesetzt, die WCF-Dienste (Windows Communication Foundation) hostet. 

Message Queuing bietet eine garantierte Nachrichtenübermittlung zwischen dem AD RMS-Server 

und der SQL Server-Datenbank. Sämtliche Transaktionen werden zunächst in die Nachrichtenwarteschlange 

geschrieben und anschließend an die Datenbank übermittelt. Wenn die Konnektivität zur 

Datenbank unterbrochen ist, werden die Transaktionsinformationen in der Warteschlange gespeichert, 

bis die Konnektivität wiederhergestellt ist. Während der Installation der AD RMS-Serverrolle 

geben Sie die Website zur Einrichtung des virtuellen AD RMS-Verzeichnisses an. Ferner geben Sie 

die Adresse für die Kommunikation von Clients mit dem Cluster über das interne Netzwerk an. Sie 

können eine unverschlüsselte URL angeben oder ein SSL-Zertifikat verwenden, um SSL-verschlüsselte 

Verbindungen zum Cluster bereitzustellen. 

Reine Lizenzierungscluster 

Ein reiner Lizenzierungscluster ist optional und nicht Teil des Stammclusters; für Zertifizierung und 

andere Dienste hängt dieser Cluster jedoch vom Stammcluster ab (er kann keine eigenen Kontozertifizierungsdienste 

bereitstellen). Er wird zur Bereitstellung von Veröffentlichungslizenzen und Nutzungslizenzen 

für Benutzer eingesetzt. Ein reiner Lizenzierungscluster kann einen einzigen Server 

umfassen oder für Redundanz und Lastenausgleich um weitere Server ergänzt werden.


Diese Art von Cluster wird typischerweise bereitgestellt, um spezifische Lizenzierungsanforderungen 

zu erfüllen, wie z.B. die individuellen Rechteverwaltungsanforderungen einer Abteilung oder die 

Rechteverwaltung für externe Geschäftspartner als Teil eines Extranetszenarios. 

Hinweis In einem Standardszenario sollten Sie lediglich einen Stammcluster verwenden und diese Konfiguration 

um mehrere Server erweitern. Der Grund dafür ist, dass Stammserver und reine Lizenzierungscluster 

nicht innerhalb desselben Lastenausgleichspools verwendet werden können und die Kombination 

Probleme bei der Verwaltung bereiten könnte. 

Active Directory-Domänendienste (AD DS) 

Die AD RMS-Serverrolle wird auf einem Windows Server 2008-Server konfiguriert. Der Server muss 

Mitglied einer Active Directory-Domäne mit Domänencontrollern unter Windows Server 2000 SP3, 

Windows Server 2003 oder Windows Server 2008 sein. Die AD DS werden zudem zum Hosten des 

Dienstverbindungspunkts (Service Connection Point, SCP) eingesetzt. Der Dienstverbindungspunkt 

ist ein registriertes Objekt in der Konfigurationspartition innerhalb von Active Directory. Er wird verwendet, 

um Intranet-basierten Domänenclients die automatische Ermittlung der URL des AD RMS- 

Clusters zu ermöglichen. Der AD RMS-Dienstverbindungspunkt kann während der Installation der 

AD RMS-Serverrolle oder im Anschluss an die Installation über die AD RMS-Verwaltungskonsole 

registriert werden. Zum Durchführen der Registrierung müssen Sie Mitglied der Sicherheitsgruppe 

Organisations-Admins in Active Directory sein. Die Registrierung des Dienstverbindungspunkts 

sollte erfolgen, wenn die Benutzer mit der Verwendung der AD RMS beginnen können. 

Hinweis Für sämtliche Benutzer oder Gruppen, die unter Verwendung der AD RMS geschützte Inhalte 

verwenden oder veröffentlichen, muss eine E-Mail-Adresse in den Active Directory-Domänendiensten konfiguriert 

werden. 

Datenbankdienste 

Zum Speichern von Konfigurationsinformationen wie Konfigurationseinstellungen, Vorlagen oder 

Benutzer- und Serverschlüsseln benötigen die AD RMS eine Datenbank. Auch Protokollierungsinformationen 

werden in der Datenbank gespeichert. Ferner wird SQL Server verwendet, um einen Cache 

mit erweiterten Gruppenmitgliedschaften zu implementieren, die aus Active Directory abgerufen werden. 

Anhand dieser Informationen wird ermittelt, ob ein bestimmter Benutzer Mitglied einer Gruppe 

ist. In Produktionsumgebungen wird die Verwendung eines Datenbankservers wie SQL Server 2005 

oder höher empfohlen. Für Testumgebungen können Sie eine mit Windows Server 2008 bereitgestellte 

interne Datenbank einsetzen; die interne Datenbank unterstützt jedoch lediglich Stammcluster 

mit einem Server. 

AD RMS-Client 

Auf jedem Clientcomputer, der als Teil der AD RMS-Umgebung bereitgestellt werden soll, muss die 

AD RMS-Clientsoftware installiert werden. In den Betriebssystemen Windows Vista und Windows 

Server 2008 ist die AD RMS-Clientkomponente bereits integriert. Wenn auf einem Clientcomputer 

Windows XP, Windows 2000 oder Windows Server 2003 ausgeführt wird, kann eine kompatible Version 

des AD RMS-Clients vom Microsoft Download Center heruntergeladen werden.


Der AD RMS-Client umfasst eine als Lockbox bezeichnete Komponente. In der Lockbox werden alle 

benötigten Schlüssel und Anmeldeinformationen für die Verschlüsselung, Entschlüsselung, Signierung 

und Validierung gespeichert, die für die Veröffentlichung der rechtegeschützten Informationen 

erforderlich sind. Die Lockbox wird aktiviert, wenn ein Benutzer versucht, rechtegeschützte Daten zu 

veröffentlichen oder zu verwenden. 

Neben dem AD RMS-Client benötigen Endbenutzer Anwendungen mit Unterstützung für Rechteverwaltungsfeatures. 

Im Folgenden finden Sie Beispiele für Anwendungen, welche die Rechteverwaltung 

unterstützen: 

• Microsoft Office Professional Edition 2003 zum Erstellen von rechtegeschützten Informationen. 

Sämtliche Versionen ermöglichen die Nutzung von durch Rechte geschützten Inhalten. 

• Microsoft Office 2007 Enterprise, Ultimate und Professional Plus zum Erstellen von rechtegeschützten 

Informationen. Sämtliche Versionen ermöglichen die Nutzung von durch Rechte 

geschützten Inhalten. 

• Windows Mobile 6 

• Microsoft Office SharePoint Server 2007 

• Microsoft Exchange Server 2007 mit Service Pack 1 

Weitere Informationen Das Active Directory-Rechteverwaltungsdienste-SDK (Software Development Kit) 

umfasst Dokumentation und Beispielcode, mit der bzw. dem Entwickler die AD RMS-Umgebung anpassen und 

AD RMS-fähige Anwendungen erstellen können. Das AD RMS-SDK ist unter http://msdn2.microsoft.com/enus/library/bb968798(VS.85).aspx 

verfügbar. 

Funktionsweise der AD RMS 

Die Server- und Clientkomponenten einer AD RMS-Lösung verwenden verschiedene Typen von 

XrML-basierten (eXtensible rights Markup Language) Zertifikaten und Lizenzen, um vertrauenswürdige 

Verbindungen und geschützte Inhalte sicherzustellen. XrML ist ein Industriestandard zur 

Bereitstellung von Rechten, die mit der Verwendung und dem Schutz von digitalen Informationen 

verknüpft sind. Die Rechte werden in einer XrML-Lizenz ausgedrückt, die an die geschützten Informationen 

angefügt ist. Über die XrML-Lizenz legt der Besitzer der Informationen fest, wie die Informationen 

verwendet, geschützt und verteilt werden sollen. 

Weitere Informationen Weitere Informationen zu den XrML-Standards finden Sie auf der XrML-Website 

unter http://www.xrml.org/. 

Während der Server- und Clientregistrierung werden verschiedene XrML-basierte Zertifikate 

verwendet. Tabelle 18.2 zeigt eine Zusammenfassung dieser Zertifikate.


Tabelle 18.2 

Für die Server- und Clientregistrierung verwendete AD RMS-Zertifikate 

Zertifikat Beschreibung Sicherheitsinhalt 

Server-Lizenzgeberzertifikat 

(Server Licensor 

Certificate, SLC) 

Computerzertifikat 

Rechtekontozertifikat 

(Rights 

Account Certificate, 

RAC) 

Client-Lizenzgeberzertifikat 

(Client Licensor 

Certificate, CLC) 

Dieses Zertifikat wird bei der Installation und Konfiguration der 

AD RMS-Serverrolle auf dem ersten Server eines AD RMS- 

Stammclusters erstellt. Die Windows Server 2008 AD RMS führen 

eine Selbstregistrierung durch, bei der das Server-Selbstregistrierungszertifikat 

(in Windows Server 2008 enthalten) das SLC signiert. 

Dadurch wird sichergestellt, dass für Computer und Benutzer 

ausgestellte Lizenzen durch einen gültigen Stammcluster verifiziert 

und als vertrauenswürdig eingestuft werden. Wenn zusätzliche 

Server zum Stammcluster hinzugefügt werden, verwenden diese 

ebenfalls das SLC. Bei Bereitstellung von reinen Lizenzierungsclustern 

generieren diese ein eigenes eindeutiges SLC. 

Dieses Zertifikat wird auf dem Clientcomputer erstellt, wenn ein Benutzer 

erstmalig ein durch Rechte geschütztes Dokument verwendet 

oder erstmalig versucht, ein Dokument unter Verwendung einer 

AD RMS-fähigen Anwendung zu schützen. Bei diesem Vorgang 

wird der AD RMS-Client für den Stammcluster registriert, um 

dieses Zertifikat und ein öffentlich-privates Schlüsselpaar zu erstellen 

sowie die Client-Lockbox zu aktivieren. 

Das RAC wird zur Identifizierung der Benutzer verwendet, die innerhalb 

eines AD RMS-Systems als vertrauenswürdige Entitäten 

eingestuft werden. Beim Versuch eines Benutzers, eine AD RMSbasierte 

Aufgabe auszuführen, stellt der AD RMS-Stammcluster 

ein RAC aus, das den Benutzer mit dem verwendeten Computer 

oder Gerät verknüpft. Zum Abrufen eines RAC muss der Benutzer 

im E-Mail-Feld des Benutzerobjekts in Active Directory über eine E- 

Mail-Adresse verfügen. Ein Standard-RAC ist per Voreinstellung 

365 Tage gültig. Temporäre RACs sind für 15 Minuten gültig. 

Wenn bei Verwendung von Clientcomputern zur Veröffentlichung 

von durch Rechte geschützten Informationen die Computer nicht 

mit dem Unternehmensnetzwerk verbunden sind (Offlineveröffentlichung), 

ist eine lokale Registrierung erforderlich. Clientcomputer 

werden für den Stammcluster registriert und erhalten Rechteverwaltungs-CLCs, 

mit denen Benutzer durch Rechte geschützte Informationen 

über diese Computer veröffentlichen können, ohne mit 

dem Unternehmensnetzwerk verbunden zu sein. So kann der Benutzer 

Veröffentlichungs- und Nutzungslizenzen über die Lockbox 

signieren. 

Enthält den öffentlichen Schlüssel 

des Servers. 

Enthält den öffentlichen Schlüssel 

des aktivierten Computers. Der private 

Schlüssel wird in der Computer- 

Lockbox gespeichert. 

Enthält den öffentlichen und den privaten 

Schlüssel des Benutzers. 

Letzterer ist mit dem öffentlichen 

Schlüssel des aktivierten Computers 

verschlüsselt. 

Enthält den öffentlichen und den privaten 

Schlüssel des Clientlizenzgebers. 

Letzterer ist mit dem 

öffentlichen Schlüssel des Benutzers 

verschlüsselt, der das CLC 

anfordert. 

Enthält zudem den öffentlichen 

Schlüssel des Stammclusters oder 

reinen Lizenzierungsclusters, der 

das Zertifikat ausgestellt hat (dieses 

ist mit dem privaten Schlüssel des 

Clusters signiert, durch den das Zertifikat 

ausgestellt wurde). 

Hinweis Computerzertifikate, RACs und CLCs können in den folgenden Verzeichnissen auf der Arbeitsstation 

des Benutzers angezeigt werden: 

Windows XP/2003: %UserProfile%\Lokale Einstellungen\Anwendungsdaten\Microsoft\DRM 

Windows Vista/2008: %UserProfile%\AppData\Local\Microsoft\DRM


Nach der Computer- und Clientaktivierung können Benutzer Rechteverwaltungsrichtlinien auf Informationen 

anwenden oder durch Rechte geschützte Daten nutzen. Für beide Aufgaben sind spezifische 

Typen von Zertifikaten erforderlich, wie in Tabelle 18.3 beschrieben. 

Tabelle 18.3 

Zur Veröffentlichung und Nutzung von Daten verwendete AD RMS-Lizenzen 

Lizenz Beschreibung Sicherheitsinhalt 

Veröffentlichungslizenz 

(Publishing 

License, PL) 

Nutzungslizenz 

(Use License, UL) 

Diese Lizenz wird durch einen Server in einem AD RMS-Cluster 

oder durch ein CLC über die Lockbox ausgestellt. Die Veröffentlichungslizenz 

legt die Richtlinie (Prinzipale, Rechte und 

Bedingungen) für das Abrufen einer Nutzungslizenz (Use 

License, UL) für rechtegeschützte Informationen fest. 

Diese Lizenz wird ausschließlich durch einen Server in einem 

AD RMS-Cluster ausgestellt und ermöglicht einem autorisierten 

Benutzer mit gültigen RAC-Rechten die Nutzung von durch 

Rechte geschützten Informationen basierend auf der in der 

Veröffentlichungslizenz festgelegten Richtlinie. 

Enthält die symmetrischen Schlüssel 

für die Entschlüsselung der Inhalte, 

die mit dem öffentlichen Schlüssel 

des Servers verschlüsselt wurden, 

der die Lizenz ausgestellt hat. 

Die Veröffentlichungslizenz umfasst 

ferner die URL des AD RMS-Lizenzierungsdiensts. 

Enthält den symmetrischen Schlüssel 

zum Entschlüsseln der Inhalte, 

die mit dem öffentlichen Schlüssel 

des Benutzers verschlüsselt wurden. 

Die Computer- und Benutzerregistrierung sowie die Veröffentlichung und Nutzung von durch Rechte 

geschützten Informationen erfolgen weitgehend im Hintergrund und erfordern nur sehr wenig 

Benutzerinteraktion. Dennoch ist es wichtig, den Ablauf der verschiedenen Prozesse zu verstehen. 

Abbildung 18.2 zeigt die Funktionsweise der AD RMS, wenn Benutzer durch Rechte geschützte Informationen 

veröffentlichen oder nutzen. 

Datenbank 

AD RMS- 

Stammcluster 

AD RMS- 

Stammcluster 

7 

1 

6 8 

3 

4 

9 

2 

Informationsautor 

5 

Informationsbenutzer 


AD RMS-Workflow für Veröffentlichung und Nutzung von Informationen


1. Der Autor empfängt beim erstmaligen Versuch, Informationen durch Rechte zu schützen, ein 

RAC und ein CLC vom AD RMS-Stammcluster (oder reinen Lizenzierungscluster). Dieser Schritt 

wird einmalig ausgeführt, um die AD RMS-Anmeldeinformationen des Benutzers (das RAC) zu 

erstellen und die Offlineveröffentlichung von durch Rechte geschützten Informationen (unter 

Verwendung des CLC) in der Zukunft zu ermöglichen. 

2. Ein Autor erstellt unter Verwendung einer AD RMS-fähigen Anwendung eine Datei und gibt 

verschiedene Nutzungsrechte und -bedingungen für diese Datei an. Anschließend wird eine Veröffentlichungslizenz 

mit den Nutzungsrichtlinien generiert. 

3. Die Anwendung verschlüsselt die Datei mit einem symmetrischen Schlüssel, der dann mit dem 

öffentlichen Schlüssel des AD RMS-Clusters des Autors verschlüsselt wird. Der Schlüssel wird in 

die Veröffentlichungslizenz eingefügt, und die Veröffentlichungslizenz wird an die Datei gebunden. 

Nur der AD RMS-Cluster des Autors kann Nutzungslizenzen zum Entschlüsseln dieser Datei 

ausstellen. Wenn der Autor die Offlineveröffentlichung eingesetzt hat, wird eine weitere Kopie des 

symmetrischen Schlüssels mit dem öffentlichen Schlüssel des CLC des Autors verschlüsselt und 

in der Veröffentlichungslizenz eingefügt. Dieser zusätzliche Verschlüsselungsschritt führt zur 

Erstellung einer Besitzerlizenz, über die der Autor den Inhalt ohne Lizenzierung über einen 

AD RMS-Server nutzen kann. 

4. Anschließend verteilt der Autor die Datei. 

5. Eine durch Rechte geschützte Datei wird über einen normalen Verteilungskanal an die Empfänger 

übermittelt und unter Verwendung einer AD RMS-fähigen Anwendung oder eines AD RMSfähigen 

Browsers geöffnet. Wenn der Empfänger auf dem aktuellen Computer nicht über ein RAC 

verfügt, wird zu diesem Zeitpunkt ein solches Zertifikat ausgestellt. 

6. Die Anwendung sendet eine Anforderung für eine Nutzungslizenz an den AD RMS-Cluster, der 

die Veröffentlichungslizenz für die geschützten Informationen ausgestellt hat. Diese Anforderung 

umfasst das Kontozertifikat des Empfängers (welches den öffentlichen Schlüssel des Empfängers 

enthält) sowie die Veröffentlichungslizenz (welche den zur Verschlüsselung der Datei verwendeten 

symmetrischen Schlüssel enthält). 

7. Der AD RMS-Stammcluster (oder der reine Lizenzierungscluster) bestätigt, dass der Empfänger 

autorisiert ist, prüft, ob es sich um einen benannten Benutzer handelt, und erstellt eine Nutzungslizenz. 

Während dieses Vorgangs entschlüsselt der Server den symmetrischen Schlüssel unter Verwendung 

des privaten Schlüssels des Servers, verschlüsselt den symmetrischen Schlüssel erneut 

mithilfe des öffentlichen Schlüssels des Empfängers und fügt anschließend den verschlüsselten 

symmetrischen Schlüssel zur Nutzungslizenz hinzu. Über diesen Schritt wird sichergestellt, dass 

nur der gewünschte Empfänger den symmetrischen Schlüssel und somit die geschützte Datei entschlüsseln 

kann. Der Server fügt ferner alle gegebenenfalls relevanten Bedingungen zur Nutzungslizenz 

hinzu, wie z.B. das Ablaufdatum oder den Ausschluss bestimmter Anwendungen 

oder Betriebssysteme. 

8. Im Anschluss an diese Bestätigungsschritte gibt der AD RMS-Stammcluster oder reine Lizenzierungscluster 

die Nutzungslizenz an den Clientcomputer des Empfängers zurück. 

9. Nach dem Empfang der Nutzungslizenz untersucht die Anwendung die Lizenz und das Kontozertifikat 

des Empfängers, um zu ermitteln, ob ein Zertifikat in einer der Vertrauensketten eine 

Sperrliste erfordert. Wenn dies zutrifft, prüft die Anwendung, ob eine lokale Kopie der Sperrliste 

vorhanden ist, die nicht abgelaufen ist. Gegebenenfalls wird eine aktuelle Kopie der Sperrliste 

abgerufen. Anschließend wendet die Anwendung alle für den aktuellen Kontext relevanten Sperrbedingungen 

an. Wenn der Dateizugriff nicht durch eine Sperrbedingung blockiert wird, werden 

die Daten angezeigt, und der Benutzer kann die Aufgaben ausführen, für die er berechtigt ist.


AD RMS-Bereitstellungsszenarien 

Zum Erfüllen der spezifischen Anforderungen einer Organisation können die AD RMS in verschiedenen 

Szenarien bereitgestellt werden. Für jedes dieser Szenarien müssen individuelle Aspekte 

berücksichtigt werden, um eine sichere und effektive Rechteverwaltungslösung bereitzustellen. Im 

Folgenden sind einige mögliche Bereitstellungsszenarien aufgeführt: 

• Bereitstellen der AD RMS für das Unternehmensintranet 

• Bereitstellen der AD RMS für Benutzer über das Internet 

• Integrieren der AD RMS mit den Active Directory-Verbunddiensten 

Bereitstellen der AD RMS innerhalb des Unternehmensintranets 

Eine typische AD RMS-Installation wird in einer einzigen Active Directory-Gesamtstruktur durchgeführt. 

Es sind jedoch andere spezifische Situationen möglich, für die weitere Aspekte berücksichtigt 

werden müssen. Möglicherweise müssen Rechteverwaltungsdienste z.B. für die Benutzer innerhalb 

eines Großunternehmens mit mehreren Zweigstellen bereitgestellt werden. Aus Skalierbarkeits- und 

Leistungsgründen entscheidet sich ein Unternehmen möglicherweise, in diesen Zweigstellen reine 

Lizenzierungscluster einzusetzen. Oder eine AD RMS-Lösung muss gegebenenfalls für eine Organisation 

bereitgestellt werden, die über mehrere Active Directory-Gesamtstrukturen verfügt. Da jede 

Gesamtstruktur nur einen einzigen Stammcluster enthalten kann, müssen geeignete Vertrauensrichtlinien 

und AD RMS-Konfigurationen zwischen den beiden Gesamtstrukturen festgelegt werden. 

Dadurch haben Benutzer beider Gesamtstrukturen die Möglichkeit, Rechteverwaltungsinhalte zu 

veröffentlichen und zu nutzen. Die Konfiguration von Vertrauensrichtlinien für gesamtstruktur- und 

organisationsübergreifende Bereitstellungsszenarien ist weiter unten in diesem Kapitel im Abschnitt 

„Implementieren der AD RMS“ beschrieben. 

Bereitstellen der AD RMS für Benutzer über das Internet 

Die meisten Organisationen müssen mobile Mitarbeiter unterstützen, die sich von Remotestandorten 

aus über das Internet mit den Organisationsressourcen verbinden. Um sicherzustellen, dass mobile 

Benutzer Rechteverwaltungsaufgaben ausführen können, muss festgelegt werden, wie der externe 

Zugriff auf die AD RMS-Infrastruktur erfolgt. Eine Methode ist, einen reinen Lizenzierungsserver 

innerhalb des Umkreisnetzwerks der Organisation zu platzieren. So können externe Benutzer Nutzungs- 

und Veröffentlichungslizenzen zum Schützen oder Anzeigen von Informationen abrufen. Eine 

weitere gängige Lösung ist der Einsatz eines Reverseproxyservers wie Microsoft ISA Server 2006 

(Internet Security and Acceleration) zur Veröffentlichung der Extranet-URL des AD RMS-Clusters. 

ISA Server verarbeitet sämtliche Anforderungen aus dem Internet an den AD RMS-Cluster und übergibt 

die Anforderungen bei Bedarf. Da diese Methode sicherer und effektiver ist, sollte sie typischerweise 

der Platzierung von Lizenzierungsservern im Umkreisnetzwerk vorgezogen werden. 

Bereitstellen der AD RMS mit den Active Directory-Verbunddiensten 

Windows Server 2008 umfasst die AD FS-Serverrolle (Active Directory Federation Services, Active 

Directory-Verbunddienste) zur Bereitstellung von vertrauenswürdigen Zugriffs- und Zusammenarbeitsszenarien 

zwischen zwei Organisationen. Die AD RMS können die verbundene Vertrauensstellung 

als Grundlage für Benutzer beider Organisationen nutzen, um RACs sowie Nutzungs- und Veröffentlichungslizenzen 

abzurufen. Zur Installation der AD RMS-Unterstützung für die AD FS muss 

bereits eine AD FS-Lösung in der Umgebung vorhanden sein. Dieses Szenario wird empfohlen, wenn 

eine Organisation über die AD RMS verfügt, die andere jedoch nicht. Wenn die AD RMS in beiden 

Organisationen implementiert sind, werden typischerweise Vertrauensrichtlinien empfohlen.


Weitere Informationen zur Konfiguration der AD FS-Unterstützung finden Sie weiter unten in diesem 

Kapitel im Abschnitt „Unterstützung für Identitätsverbund“. 

Implementieren der AD RMS 

Unabhängig davon, welches Szenario für die Rechteverwaltungsdienste verwendet werden soll, ist der 

erste Schritt stets die Installation des AD RMS-Stammclusters. Nach der Installation des Stammclusters 

kann festgelegt werden, wie die spezifischen Anforderungen, wie z.B. die Bereitstellung von 

externem Zugriff auf die AD RMS-Umgebung, erfüllt werden sollen. In diesem Abschnitt wird die 

Bereitstellung und Konfiguration von AD RMS-Komponenten beschrieben, um eine effektive und 

sichere Rechteverwaltungslösung sicherzustellen. 

Vor der Installation der AD RMS zu berücksichtigende Aspekte 

Während der Installation der AD RMS-Serverrolle wird der Benutzer zur Angabe verschiedener Konfigurationswerte 

aufgefordert, die bereits im Vorfeld ermittelt werden sollten. Ferner müssen für eine 

erfolgreiche Implementierung eine Reihe von Anforderungen erfüllt werden. Berücksichtigen Sie vor 

der Installation der AD RMS die folgenden Aspekte: 

• Die AD RMS-Serverrolle sollte auf einem Mitgliedsserver in derselben Active Directory-Domäne 

wie die Benutzerkonten installiert werden, welche die Rechteverwaltungslösung nutzen. Die 

AD RMS können auf einem Domänencontroller installiert werden; das AD RMS-Dienstkonto 

muss jedoch zur Gruppe Domänen-Admins hinzugefügt werden, und dies kann ein Sicherheitsrisiko 

darstellen. 

• Es muss ein Domänenbenutzerkonto erstellt werden, das während der Installation als AD RMS- 

Dienstkonto angegeben wird. Für dieses Konto sind neben den Berechtigungen eines Standardbenutzerkontos 

keine zusätzlichen Berechtigungen erforderlich. 

• Das zur Installation der AD RMS-Serverrolle verwendete Benutzerkonto darf nicht mit dem als 

AD RMS-Dienstkonto angegebenen Konto übereinstimmen und muss Abfragen an die Active 

Directory-Domäne senden können. Wenn der AD RMS-Dienstverbindungspunkt während der 

Installation registriert werden soll, muss das zur Installation der AD RMS verwendete Konto ferner 

Mitglied der Active Directory-Gruppe Organisations-Admins oder einer vergleichbaren 

Gruppe sein. 

• Wenn eine externe Datenbank für den AD RMS-Cluster verwendet wird, muss der Benutzer, der 

die AD RMS-Installation durchführt, zur Erstellung neuer Datenbanken berechtigt sein. Wenn 

Microsoft SQL Server 2005 verwendet wird, muss das Benutzerkonto ferner Mitglied der Datenbankrolle 

für Systemadministratoren sein. 

• Während der Installation wird der Benutzer zur Angabe einer URL für den AD RMS-Cluster aufgefordert. 

Diese URL darf nicht mit dem Computernamen übereinstimmen und muss den gesamten 

AD RMS-Cluster darstellen. Darüber hinaus sollte ein DNS-Aliaseintrag (CNAME) für die 

AD RMS-Cluster-URL sowie ein separater CNAME-Eintrag für den Computer erstellt werden, 

auf dem die Konfigurationsdatenbank gehostet wird. CNAMEs bieten Flexibilität, für den Fall, 

dass ein Hardwarefehler auftritt oder ein Computername geändert wird. 

• Wenn die Kommunikation mit dem AD RMS-Cluster über SSL gesichert werden soll, muss das 

erforderliche SSL-Zertifikat von einer vertrauenswürdigen Stammzertifizierungsstelle abgerufen 

werden.

Implementieren der AD RMS 703 

Zwar kann ein selbstsigniertes Zertifikat verwendet werden, diese Option ist jedoch mit einer 

Reihe von Einschränkungen verbunden und wird für Produktionsumgebungen nicht empfohlen. 

Installieren von AD RMS-Clustern 

Die AD RMS-Serverrolle ist eine Option, die mit dem Betriebssystem Windows Server 2008 verfügbar 

ist. Der AD RMS-Stammcluster kann auf der Seite Aufgaben der Erstkonfiguration oder über den 

Server-Manager installiert und konfiguriert werden. Zum Durchführen der Installation muss der 

Benutzer Mitglied der lokalen Administratorengruppe oder einer vergleichbaren Gruppe sein. 

Im Folgenden sind die wesentlichen Installationsschritte für den AD RMS-Cluster beschrieben: 

1. Öffnen Sie den Server-Manager (oder die Seite Aufgaben der Erstkonfiguration), klicken Sie auf 

den Knoten Rollen und dann auf Rollen hinzufügen. Der Assistent zum Hinzufügen von Rollen 

wird gestartet. 

2. Wählen Sie auf der Seite Serverrollen auswählen die Option Active Directory-Rechteverwaltungsdienste. 

Sie werden zum Hinzufügen weiterer erforderlicher Rollendienste und -features 

aufgefordert. Diese umfassen den Rollendienst Webserver (IIS) sowie die Features Windows- 

Prozessaktivierungsdienst und Message Queuing. Abbildung 18.3 zeigt den Assistenten zum 

Hinzufügen von Rollen, in dem die erforderlichen Rollen ausgewählt sind. 


Auswählen der Rollen Active Directory-Rechteverwaltungsdienste und Webserver (IIS)


3. Auf der Seite Rollendienste auswählen können die Rollendienste ausgewählt werden, die für die 

Active Directory-Rechteverwaltungsdienste installiert werden sollen. Es gibt zwei Optionen: 

Active Directory-Rechteverwaltungsserver Dies ist der erforderliche Rollendienst zur Installation 

der AD RMS-Komponenten, die zum Veröffentlichen und Nutzen von durch Rechte 

geschützten Informationen benötigt werden. 

Unterstützung für Identitätsverbund Dieser optionale Rollendienst wird für die Integration von 

durch Rechte geschützten Informationen mit den Active Directory-Verbunddiensten verwendet. 

Bei Auswahl dieses Rollendiensts werden Sie auch zum Hinzufügen bestimmter Rollendienste 

für die Active Directory-Verbunddienste zum Server aufgefordert. 

4. Auf der Seite Erstellen eines AD RMS-Clusters oder Beitreten zu einem AD RMS-Cluster gibt es 

zwei Optionen: 

Neuen AD RMS-Cluster erstellen Bei der Implementierung einer neuen AD RMS-Bereitstellung 

wählen Sie diese Option aus, um einen AD RMS-Stammcluster zu Zertifizierungs- und Lizenzierungszwecken 

zu erstellen. Wenn in der Active Directory-Gesamtstruktur ein vorhandener 

AD RMS-Stammcluster ermittelt wird, wählen Sie diese Option zum Erstellen eines neuen 

reinen Lizenzierungsclusters. 

Vorhandenem AD RMS-Cluster beitreten Wenn bereits ein Stammcluster oder reiner Lizenzierungscluster 

bereitgestellt wurde, kann diese Option zum Hinzufügen eines weiteren Servers 

zum Cluster verwendet werden. Es muss der Name einer vorhandenen AD RMS-Konfigurationsdatenbank 

sowie der Name des Datenbankservers angegeben werden. 

5. Auf der Seite Auswählen der Konfigurationsdatenbank wird die Datenbank zum Speichern von 

Konfigurations- und Richtlinieninformationen konfiguriert. Auf dieser Seite gibt es zwei Optionen: 

Interne Windows-Datenbank auf diesem Server verwenden Bei der Implementierung der 

AD RMS auf einem einzigen Server für kleine oder Testumgebungen kann diese Option 

gewählt werden. Beachten Sie, dass bei Auswahl dieser Option keine weiteren Server zum 

AD RMS-Cluster hinzugefügt werden können. Falls in der Zukunft Skalierbarkeit erforderlich 

ist, wählen Sie eine andere Option. 

Anderen Datenbankserver verwenden Über diese Option können der Servername und die 

Datenbankinstanz für die Konfigurationsdatenbank angegeben werden. Es wird die Verwendung 

eines Datenbankservers wie Microsoft SQL Server 2005 oder höher empfohlen. 

6. Auf der Seite Angeben des Dienstkontos geben Sie das Konto für die Kommunikation des 

AD RMS-Clusters mit anderen Diensten auf dem Computer und innerhalb des Netzwerks an. Für 

dieses Konto sind lediglich standardmäßige Domänenbenutzerberechtigungen erforderlich. Dieses 

Konto wird automatisch zur AD RMS-Dienstgruppe hinzugefügt und mit den Standardberechtigungen 

für diese Gruppe versehen. 

7. Auf der Seite Konfigurieren des AD RMS-Clusterschlüsselspeichers geben Sie den Speicherort für 

den AD RMS-Clusterschlüssel an. Der AD RMS-Clusterschlüssel wird zum Signieren von Zertifikaten 

und Lizenzen verwendet, die durch den Cluster ausgestellt werden.


Darüber hinaus wird er in Notfallwiederherstellungsszenarien und von anderen AD RMS-Servern 

verwendet, wenn diese zum Cluster hinzugefügt werden. Zum Speichern des Clusterschlüssels 

gibt es zwei Optionen: 

Zentral verwalteten AD RMS-Schlüsselspeicher verwenden Nach dem Generieren des AD RMS- 

Clusterschlüssels wird im Assistenten eine Aufforderung zur Angabe eines Clusterschlüsselkennworts 

angezeigt, um den Schlüssel zu schützen (dieses Kennwort müssen Sie sich zu 

Notfallwiederherstellungszwecken merken). Der AD RMS-Clusterschlüssel wird in der Konfigurationsdatenbank 

gespeichert und automatisch durch die AD RMS-Server verwendet, die 

zum Cluster hinzugefügt werden. 

CSP-Schlüsselspeicher verwenden Für eine höhere Sicherheit kann der AD RMS-Clusterschlüssel 

in einem Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) gespeichert 

werden. Diese Vorgehensweise stellt die beste Sicherheitsoption dar, erfordert jedoch die 

manuelle Bereitstellung des Schlüssels, wenn neue Server zum Cluster hinzugefügt werden. 

Bei Auswahl dieser Option müssen Sie als nächsten Schritt im Assistenten den CSP auswählen 

und festlegen, ob mit dem CSP ein neuer Schlüssel erstellt oder ob ein vorhandener 

Schlüssel mit dem ausgewählten CSP verwendet werden soll (die zweite Option wird üblicherweise 

in Wiederherstellungsszenarien eingesetzt). 

8. Auf der Seite Auswählen der AD RMS-Clusterwebsite kann eine Website für das virtuelle 

AD RMS-Verzeichnis ausgewählt werden. Wenn auf einem Server ausschließlich die AD RMS- 

Serverrolle ausgeführt wird, legen Sie typischerweise die Option Standardwebsite fest. 

9. Auf der Seite Angeben der Clusteradresse wird festgelegt, wie AD RMS-Clients mit dem Cluster 

kommunizieren. Es kann eine SSL-verschlüsselte Verbindung gewählt oder eine unverschlüsselte 

Verbindung angegeben werden. Ferner muss die interne Adresse und der Port zur Verwendung für 

den Cluster eingegeben werden. Es wird die Verwendung einer SSL-verschlüsselten Verbindung 

empfohlen. Zu diesem Zweck bietet der Assistent im nächsten Schritt die Möglichkeit, ein vorhandenes 

Zertifikat auszuwählen, das bereits von einer Zertifizierungsstelle ausgestellt wurde, 

oder ein selbstsigniertes Zertifikat zu erstellen. Da das Zertifikat manuell auf allen Clients installiert 

werden muss, die mit dem Server kommunizieren, wird ein selbstsigniertes Zertifikat nur für 

kleine Bereitstellungen empfohlen. Abbildung 18.4 zeigt die Konfiguration einer SSL-verschlüsselten 

Verbindung. 

Hinweis Bei der internen Adresse muss es sich um einen vollqualifizierten Domänennamen (Fully 

Qualified Domain Name, FQDN) handeln, der in den AD RMS-Cluster aufgelöst wird. Es sollte kein Servername, 

sondern ein Alias angegeben werden, der den gesamten Cluster darstellt. So können zu einem 

späteren Zeitpunkt problemlos Netzwerklastenausgleichsoptionen oder zusätzliche Server zum Cluster 

hinzugefügt werden. Beachten Sie ferner, dass diese Adresse oder Portnummer im Anschluss an die 

Installation der AD RMS nicht mehr geändert werden kann. Daher muss dieser FQDN vor der Bereitstellung 

festgelegt werden. 

Hinweis Wenn die AD RMS mit den AD FS integriert werden sollen, muss die SSL-verschlüsselte 

Verbindung gewählt werden. Anderenfalls müssen die AD RMS neu installiert werden.



Konfigurieren einer SSL-verschlüsselten Clusteradresse 

10. Auf der Seite Benennen des Server-Lizenzgeberzertifikats geben Sie einen Namen zur Identifizierung 

des SLC ein. 

11. Auf der Seite Registrieren des AD RMS-Dienstverbindungspunkts sind zwei Optionen verfügbar: 

AD RMS-Dienstverbindungspunkt jetzt registrieren Wenn Sie Mitglied der Active Directory- 

Gruppe Organisations-Admins sind, können Sie den AD RMS-Dienstverbindungspunkt bei 

der AD RMS-Installation automatisch konfigurieren. Wie Sie wissen, ist dieses Active Directory-Objekt 

für AD RMS-fähige Clients zum Auflösen von Intranet-URLs für den AD RMS- 

Cluster erforderlich. 

AD RMS-Dienstverbindungspunkt später registrieren Wenn Sie kein Mitglied der Gruppe Organisations-Admins 

sind, oder wenn Sie nicht möchten, dass der AD RMS-Cluster bereits zu 

diesem Zeitpunkt automatisch von Clients erkannt wird, können Sie diese Option wählen. 

12. Wenn Sie die Installation der Unterstützung für Identitätsverbund gewählt haben, werden Sie zur 

Eingabe des Verbundservernamens aufgefordert, der mit dem AD RMS-Server kommuniziert. 

Anderenfalls ist diese Option nicht verfügbar. 

13. Der letzte Schritt ist die Konfiguration des Rollendiensts Webserver (IIS). Im Allgemeinen werden 

die empfohlenen Einstellungen auf der Seite Rollendienste auswählen übernommen; bei 

Bedarf können jedoch spezifische Rollendiensteinstellungen hinzugefügt oder entfernt werden. 

Nach Abschluss der Installation müssen Sie sich ab- und erneut anmelden, um Ihr Sicherheitstoken zu 

aktualisieren und den AD RMS-Server zu verwalten.


Nach der erneuten Anmeldung kann der Server über die Konsole der Active Directory-Rechteverwaltungsdienste 

verwaltet werden, wie in Abbildung 18.5 gezeigt. 


Anzeigen der Konsole der Active Directory-Rechteverwaltungsdienste 

Konfigurieren des AD RMS-Dienstverbindungspunkts 

Wie bereits erwähnt, ist der Dienstverbindungspunkt (Service Connection Point, SCP) erforderlich, 

damit Clients die AD RMS-Cluster-URL automatisch erkennen können. Pro Active Directory- 

Gesamtstruktur gibt es einen einzigen SCP. Wenn ein AD RMS-Client versucht, Rechteverwaltungsfeatures 

auf einem Computer zu verwenden, sendet die AD RMS-Clientanwendung eine 

Abfrage an den SCP, um die URL des AD RMS-Clusters zu ermitteln. Nach der Ermittlung des 

AD RMS-Clusters lädt der Client ein RAC herunter und kann anschließend an der Veröffentlichung 

und Nutzung von durch Rechte geschützten Informationen teilnehmen. 

Der SCP wird typischerweise während der Installation des AD RMS-Stammclusters registriert, wenn 

Sie (oder der Benutzer, der die Installation des AD RMS-Servers durchgeführt hat) jedoch kein Mitglied 

der Gruppe Organisations-Admins sind, muss diese Aufgabe möglicherweise als separater 

Schritt ausgeführt werden. 

Nach der Installation kann der SCP über die Konsole der Active Directory-Rechteverwaltungsdienste 

im Fenster mit den Clustereigenschaften registriert oder geändert werden. Zum Durchführen dieser 

Aufgabe müssen Sie Mitglied der Active Directory-Gruppen AD RMS-Organisationsadministratoren 

und Organisations-Admins sein. Abbildung 18.6 zeigt das Dialogfeld zum Ändern der SCP-Registrierung.



Ändern der SCP-Registrierung 

Arbeiten mit AD RMS-Clients 

Nach der Bereitstellung des AD RMS-Clusters und der Konfiguration des SCP muss im nächsten 

Schritt sichergestellt werden, dass auf allen Clients, welche die Rechteverwaltungslösung nutzen sollen, 

die geeignete AD RMS-Clientsoftware installiert ist. Wenn auf den Clients hauptsächlich Windows 

Vista oder Windows Server 2008 ausgeführt wird, ist dieser Schritt einfach, da der AD RMS- 

Client bereits mit dem Clientbetriebssystem installiert und bereitgestellt wird. 

Auf Clients unter Windows XP, Windows 2000 oder Windows Server 2003 muss eine kompatible 

Version des AD RMS-Clients vom Microsoft Download Center heruntergeladen und die geeignete 

Bereitstellungsmethode zur Installation dieser Anwendung auf den Computern bestimmt werden, die 

Teil der AD RMS sein werden. Viele Organisationen entscheiden sich bei der Bereitstellung des 

RMS-Clients für den Einsatz von Systems Management Server (SMS), System Center Configuration 

Manager (SCCM) oder Gruppenrichtlinien. Zur Bereitstellung des Clients über diese Methoden müssen 

die Windows Installer-Dateien unter Verwendung der folgenden Befehlssyntax aus dem ausführbaren 

Paket extrahiert werden (beachten Sie, dass für das Beispiel die SP2-Version des RMS-Clients 

verwendet wird): 

WindowsRightsManagementServicesSP2-KB917275-Client-ENU.exe /x 

Bei Verwendung der Option /x werden Sie zur Angabe eines Speicherorts zum Extrahieren der 

Dateien aufgefordert. Die folgenden zwei Dateien müssen für die Clients bereitgestellt werden: 

• MSDrmClient.msi Dies ist die Installationsdatei für den RMS-Client. Diese Datei sollte zuerst 

bereitgestellt werden, da sie zunächst alle vorherigen Versionen entfernt und anschließend die 

neue Clientversion installiert.


• RMSClientBackCompat.msi Über diese Datei wird der neue RMS-Client mit RMS-fähigen 

Anwendungen wie Microsoft Office verknüpft. Sie sollte nach der Bereitstellung der Datei 

MSDrmClient.msi ausgeführt werden. 

Die ausführbare Datei lässt sich ebenfalls über eine Skript- oder Batchdatei bereitstellen. Unter 

Verwendung des folgenden Befehls kann der RMS-Client über eine unbeaufsichtigte Installationsmethode 

bereitgestellt werden: 

WindowsRightsManagementServicesSP2-KB917275-Client-ENU.exe 

-override 1 /I MsDrmClient.msi REBOOT=ReallySuppress /q -override 2 /I 

RmClientBackCompat.msi REBOOT=ReallySuppress /q 

Hinweis Neben der Installation des Clients muss sichergestellt werden, dass für jedes Benutzerobjekt im 

Active Directory-Dialogfeld mit den Benutzereigenschaften auf der Registerkarte Allgemein das Attribut 

E-Mail konfiguriert ist. 

Konfigurieren der Clientdiensterkennung 

Beim Versuch eines Netzwerkclients, ein Rechteverwaltungsfeature einer kompatiblen Anwendung zu 

verwenden, sendet der AD RMS-Client eine Abfrage an den Dienstverbindungspunkt in Active Directory, 

um die URL-Pipeline des virtuellen Zertifizierungsverzeichnissen auf dem AD RMS-Stammcluster 

abzurufen. Die URL-Pipeline weist das folgende Format auf: http(s):///_wmcs/Certification. 

Hinweis Bei jedem Versuch, eine Verbindung mit dem AD RMS-Cluster herzustellen, wird eine Aufforderung 

zur Angabe von Anmeldeinformationen angezeigt. Um dies zu verhindern, kann die AD RMS-Cluster- 

URL für alle Benutzer, die in der AD RMS-Infrastruktur arbeiten, zur Sicherheitszone Lokales Intranet hinzugefügt 

werden. Um diese Einstellung für mehrere Clients festzulegen, kann sie bei Bedarf als Gruppenrichtlinieneinstellung 

definiert werden. 

Bei der Erstellung oder Nutzung von durch Rechte geschützten Inhalten sucht der AD RMS-Client 

nach der URL für das virtuelle Lizenzierungsverzeichnis auf dem AD RMS-Cluster und ruft diese 

URL ab. Die URL-Pipeline für Lizenzierungsanforderungen weist das folgende Format auf: http(s):// 

/_wmcs/Licensing. 

In einigen Situationen kann es erforderlich sein, den standardmäßigen Diensterkennungsprozess außer 

Kraft zu setzen und das Kontaktieren eines spezifischen AD RMS-Clusters durch einen Client zu 

erzwingen, der nicht mit dem im Dienstverbindungspunkt veröffentlichten Cluster übereinstimmt. 

Wenn aus Skalierbarkeitsgründen beispielsweise reine AD RMS-Lizenzierungscluster bereitgestellt 

werden, muss die Standardkonfiguration auf den Clients mit den bereitgestellten reinen Lizenzierungsclustern 

außer Kraft gesetzt werden, sodass der AD RMS-Stammcluster nicht mehr kontaktiert 

wird, um Nutzungs- oder Veröffentlichungslizenzen anzufordern. 

Zum Außerkraftsetzen des standardmäßigen Diensterkennungsprozesses kann auf den Clientarbeitsstationen, 

die Teil der AD RMS-Umgebung sind, der folgende Registrierungseintrag hinzugefügt 

werden: 

HKEY_LOCAL_MACHINE\Software\Microsoft\MSDRM\ServiceLocation 

Die in Tabelle 18.4 aufgeführten Schlüssel werden zum Außerkraftsetzen der Aktivierungs- oder 

Lizenzierungsdienste eingesetzt, um stattdessen den angegebenen AD RMS-Cluster zu verwenden.


Tabelle 18.4 

Schlüssel zum Außerkraftsetzen der Aktivierungs- oder Lizenzierungsdienste 

Schlüsselname Datentyp Syntax Beschreibung 

Activation REG_SZ http(s):///_wmcs/ 

certification (wobei die URL des 

Stammclusters ist, der für die Zertifizierung verwendet 

werden soll) 

EnterprisePublishing REG_SZ http(s):///_wmcs/licensing 

(wobei die URL des reinen 

Lizenzierungsclusters ist) 

Zum Außerkraftsetzen des standardmäßigen 

AD RMS-Zertifizierungsdiensts, 

der im SCP 

konfiguriert ist 

Zum Außerkraftsetzen des standardmäßigen 

AD RMS-Lizenzierungsdiensts 

Die meisten Anwendungen mit Rechteverwaltungsfeatures bieten eine Möglichkeit zur Angabe von 

bestimmten Lizenzierungsservern, die zur Veröffentlichung oder Nutzung von durch Rechte 

geschützten Informationen verwendet werden sollen. Dies verhindert, dass die globalen Einstellungen 

für die Diensterkennung geändert werden müssen, ermöglicht jedoch gleichzeitig das Festlegen 

von individuellen Einstellungen für eine bestimmte Anwendung. Um beispielsweise einen Lizenzierungsserver 

für Microsoft Office 2007 anzugeben, können Sie den folgenden Registrierungseintrag 

hinzufügen oder ändern: 

Struktur: HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\Common\DRM 

Wert: CorpLicenseServer 

Typ: REG_SZ 

Eintrag: http(s):///_WMCS/licensing 

Erstellen von rechtegeschützten Inhalten mit Microsoft Office 

Sowohl Microsoft Office 2003 Professional Edition als auch Microsoft Office 2007 (Enterprise, Ultimate 

und Professional Plus) können mit dem AD RMS-Client eingesetzt werden, um die Erstellung 

und Nutzung von rechtegeschützten Inhalten zu ermöglichen. Über die folgenden Methoden lassen 

sich Rechte auf ein Dokument anwenden: 

• Bei Microsoft Office Professional Edition 2003 zeigen Sie im Menü Datei auf Berechtigung. 

Anschließend kann eine geeignete Vorlage ausgewählt werden, in der die erforderlichen Rechte 

für das Dokument festgelegt sind. 

• Bei Microsoft Office 2007 klicken Sie auf die Office-Schaltfläche, und zeigen Sie auf Vorbereiten. 

Anschließend zeigen Sie auf die Option Berechtigung einschränken, um eine geeignete Vorlage 

für Benutzerrechterichtlinien zur Anwendung auf das Dokument auszuwählen. 

Abhängig von der verwendeten Vorlage für Benutzerrechterichtlinien wird für den Benutzer, der die 

Berechtigungen anwendet, das Dialogfeld Berechtigung geöffnet. In diesem Dialogfeld kann festgelegt 

werden, welche Benutzer über Lese- oder Änderungsberechtigungen für das Dokument verfügen. 

Wie in Abbildung 18.7 gezeigt, verfügt Don für das Dokument über Lese- und Terry über Änderungsberechtigungen.



Einschränken von Berechtigungen für ein Dokument 

Über die Schaltfläche Weitere Optionen werden zusätzliche Berechtigungen angezeigt, wie in 

Abbildung 18.8 dargestellt und in Tabelle 18.5 beschrieben. 


Zusätzliche Berechtigungen und Einstellungen für Benutzer


Tabelle 18.5 

Optionen für Berechtigungen und Einstellungen 

Berechtigung oder Einstellung 

Berechtigung für dieses Dokument 

einschränken 

Die folgenden Benutzer haben Zugriffsrechte 

für dieses Dokument 

Dieses Dokument läuft ab am 

Inhalt drucken 

Benutzern mit Lesezugriff das 

Kopieren des Inhalts erlauben 

Auf Inhalt programmatisch 

zugreifen 

Benutzer können zusätzliche 

Berechtigungen anfordern von 

Immer verbinden, um die Berechtigung 

eines Benutzers neu zu 

prüfen 

Standardwerte festlegen 

Beschreibung 

Ermöglicht das Aktivieren oder Deaktivieren der auf das Dokument angewendeten 

Berechtigungen. 

Über die Schaltflächen Hinzufügen oder Entfernen kann die Liste der Benutzer bearbeitet 

werden, die über die in diesem Dialogfeld konfigurierten Berechtigungen und Einstellungen 

verfügen. 

Ermöglicht das Festlegen eines Ablaufdatums für das Dokument. Nach diesem Ablaufdatum 

sind die Benutzer nicht mehr zum Öffnen des Dokuments berechtigt. 

Fügt die Berechtigung zum Drucken des Dokuments hinzu. 

Fügt die Berechtigung zum Kopieren von Inhalt und Einfügen dieses Inhalts an einer 

anderen Stelle oder in einem anderen Dokument hinzu. 

Fügt die Zugriffsberechtigung auf die Inhalte für Dienste oder Skripts hinzu. 

Über diese Option kann die E-Mail-Adresse der Person angegeben werden, von welcher 

Benutzer zusätzliche Berechtigungen zum Zugreifen auf Inhalte und Ändern von Inhalten 

anfordern können. 

Bei Aktivierung dieses Kontrollkästchens wird sichergestellt, dass ein Benutzer dieses 

Dokument nur öffnen kann, wenn der Benutzer durch den AD RMS-Cluster verifiziert 

werden kann. Da diese Verifizierung bei jedem Öffnen der Datei durchgeführt wird, 

sollten Sie diese Einstellung nicht für Offlinebenutzer aktivieren. 

Über die Schaltfläche Standardwerte festlegen können allgemeine Berechtigungseinstellungen 

zur zukünftigen Verwendung gespeichert werden. 

Beim Versuch eines Benutzers, rechtegeschützte Inhalte zu nutzen, wird ein Benachrichtigungsfenster 

angezeigt. Wie in Abbildung 18.9 gezeigt, enthält diese Benachrichtigung die URL der Lizenzierungspipeline 

zur Verifizierung der Anmeldeinformationen und zum Abrufen einer Nutzungslizenz. 


Anzeigen der Berechtigungsbenachrichtigung 

Die Berechtigungen des Benutzers sind anschließend auf die in der Nutzungsrichtlinie festgelegten 

Aktionen beschränkt. Diese Berechtigungen können über die Schaltfläche Berechtigung anzeigen 

angezeigt werden, wie in Abbildung 18.10 dargestellt. Beachten Sie, dass Don@Adatum.com über die 

Berechtigungen Anzeigen und Kopieren für das Dokument verfügt.

Verwalten der AD RMS 713 


Anzeigen von Berechtigungen, die für ein rechtegeschütztes Dokument zugewiesen sind 

Hinweis Für Benutzer, die nicht über Microsoft Office zum Anzeigen von rechtegeschützten Dokumenten 

verfügen, kann das Rechteverwaltungs-Add-On für Internet Explorer installiert werden. Über dieses Add-On 

können rechtegeschützte Informationen angezeigt, jedoch nicht geändert werden. Das Rechteverwaltungs- 

Add-On für Internet Explorer kann unter folgender Adresse heruntergeladen werden: http://www.microsoft.com/downloads/details.aspx?FamilyID=B48F920B-5AF0-46B4-994F-2F62582CC86F&displaylang=en. 

Verwalten der AD RMS 

Aufgrund der Komplexität und des Aufbaus einer AD RMS-Umgebung müssen nach der erstmaligen 

Bereitstellung des AD RMS-Stammclusters bestimmte Verwaltungsaufgaben ausgeführt werden. 

Wenn eine Organisation mehrere Active Directory-Gesamtstrukturen umfasst, müssen möglicherweise 

mehrere AD RMS-Bereitstellungen integriert werden. Ferner müssen gegebenenfalls externe 

Benutzer oder Partnerschaften mit anderen Organisationen berücksichtigt werden, um eine gemeinsame 

Nutzung von und Zusammenarbeit an rechtegeschützten Informationen zu ermöglichen. Zum 

Gewährleisten der Sicherheit einer AD RMS-Umgebung sind zudem weitere umfangreiche Verwaltungsaufgaben 

erforderlich. Dazu zählen beispielsweise die Anwendung von Ausschluss- und Sicherheitsrichtlinien 

sowie die Konfiguration und Bereitstellung von Vorlagen für Benutzerrechterichtlinien. 

In diesem Abschnitt werden diese Verwaltungsaufgaben beschrieben und Informationen bereitgestellt, 

um innerhalb einer Netzwerkumgebung eine effektive und sichere AD RMS-Bereitstellung zu 

vewalten. 

Verwalten von Vertrauensrichtlinien 

Eine Standardimplementierung der AD RMS bietet Rechteverwaltungsschutz für Dokumente, die 

innerhalb einer Organisation erstellt und genutzt werden. In vielen Szenarien ist jedoch die Konfiguration 

von Vertrauensrichtlinien erforderlich. Eine Vertrauensrichtlinie ermöglicht die Verarbeitung 

von Lizenzierungsanforderungen für Inhalte, die auf einem anderen AD RMS-Cluster in einer anderen 

Active Directory-Gesamtstruktur oder Organisation durch Rechte geschützt wurden.


Abhängig vom spezifischen Szenario können drei Haupttypen von Vertrauensrichtlinien konfiguriert 

werden: 

• Vertrauenswürdige Benutzerdomänen 

• Vertrauenswürdige Veröffentlichungsdomänen 

• Unterstützung für Identitätsverbund 

Vertrauenswürdige Benutzerdomänen 

In einer vertrauenswürdigen Benutzerdomänenkonfiguration können Empfänger eines AD RMS- 

Clusters in einer anderen Organisation oder Active Directory-Gesamtstruktur Nutzungslizenzen von 

Ihrem AD RMS-Cluster erhalten. Eine große Unternehmensorganisation kann z.B. mehrere Active 

Directory-Gesamtstrukturen mit einer Vielzahl von AD RMS-Installationen umfassen. Indem die verschiedenen 

AD RMS-Installationen untereinander als vertrauenswürdige Benutzerdomänen konfiguriert 

werden, wird eine Vertrauensbeziehung zwischen diesen Installationen hergestellt. Um eine 

gemeinsame Nutzung von und Zusammenarbeit an veröffentlichten rechtegeschützten Inhalten zu 

ermöglichen, kann eine vertrauenswürdige Benutzerdomäne auch zwischen zwei Organisationen konfiguriert 

werden. Typischerweise stellt eine der folgenden Entitäten eine vertrauenswürdige Benutzerdomäne 

dar: 

• Eine andere Active Directory-Gesamtstruktur innerhalb einer Organisation 

• Die AD RMS-Installation eines Partners 

• Der Windows Live ID-Dienst 

Per Voreinstellung verarbeitet der AD RMS-Cluster keine Anforderungen von Benutzern, deren RAC 

von einer anderen AD RMS-Installation ausgestellt wurde. Betrachten Sie z.B. das folgende Szenario: 

Kim@NWtraders.com sendet rechtegeschützte Inhalte an Don@Adatum.com. Beim Versuch, die 

Inhalte zu öffnen, wird Dons RAC (von der AD RMS-Installation seiner Organisation ausgestellt) und 

die Veröffentlichungslizenz an die in dieser aufgeführte URL gesendet. Der Lizenzierungcluster bei 

NWTraders.com empfängt Dons Nutzungslizenzanforderung, kann diese Anforderung jedoch nur verarbeiten, 

wenn Dons RAC verifiziert werden kann. Durch die Konfiguration eines anderen AD RMS- 

Clusters als vertrauenswürdige Benutzerdomäne kann verifiziert werden, dass der Benutzer, der die 

Nutzungslizenz anfordert, zu einer vertrauenswürdigen Benutzerdomäne gehört. 

Zum Konfigurieren einer vertrauenswürdigen Benutzerdomäne muss die Konsole der Active Directory-Rechteverwaltungsdienste 

geöffnet und die .bin-Datei einer vertrauenswürdigen Benutzerdomäne 

importiert werden. Die .bin-Datei enthält das SLC des AD RMS-Clusters, der als vertrauenswürdig eingestuft 

werden soll. Zum Erstellen der .bin-Datei wählen Sie im Knoten Vertrauenswürdige Benutzerdomänen 

das Domänenzertifikat Intern und klicken im Fenster Aktionen auf Vertrauenswürdige 

Benutzerdomäne exportieren. Die Datei kann anschließend gespeichert und an den Administrator 

übergeben werden, der die Integration der zwei AD RMS-Cluster konfiguriert. 

Nach dem Erhalt einer .bin-Datei von einer vertrauenswürdigen Domäne kann die Datei im 

Fenster Aktionen über die Option Vertrauenswürdige Benutzerdomäne importiert werden. Wie in 

Abbildung 18.11 gezeigt, wird die von der Adatum Corporation erhaltene .bin-Datei importiert. Zur 

eindeutigen Identifizierung der vertrauenswürdigen Benutzerdomäne wird ein Anzeigename angegeben.



Importieren der Datei einer vertrauenswürdigen Benutzerdomäne 

Durch den Import des Server-Lizenzgeberzertifikats eines anderen AD RMS-Clusters kann nun verifiziert 

werden, dass Benutzer, die eine Nutzungslizenz anfordern, Mitglied einer vertrauenswürdigen 

Benutzerdomäne sind. Abbildung 18.12 zeigt die Interaktion zwischen vertrauenswürdigen Benutzerdomänen. 

SLC (.bin-Datei) 

1 

2 

Adatum 

4 

5 

NWTraders 

Don 

3 

Kim 


Interaktion zwischen vertrauenswürdigen Benutzerdomänen


1. Adatum exportiert und sendet das Server-Lizenzgeberzertifikat (.bin-Datei) an NWTraders. 

2. NWTraders importiert die .bin-Datei und legt Adatum als vertrauenswürdige Benutzerdomäne 

fest. 

3. Kim (Mitarbeiter von NWTraders) sendet ein durch Rechte geschütztes Dokument an Don. 

4. Nach dem Erhalt der Inhalte werden Dons RAC und Veröffentlichungslizenz beim Versuch, das 

Dokument zu öffnen, an den Lizenzierungsserver von NWTraders gesendet. 

5. Der AD RMS-Cluster bei NWTraders erkennt die Adatum-Domäne als vertrauenswürdige Benutzerdomäne 

und verwendet das importierte SLC, um Dons RAC zu verifizieren und ihm eine Nutzungslizenz 

auszustellen. 

Hinweis In der ursprünglichen Konfiguration der Lizenzierungspipeline ist lediglich die Windows-Authentifizierung 

aktiviert. Um einem Benutzer einer anderen Domäne das Anfordern von Nutzungslizenzen zu 

ermöglichen, muss sich der Benutzer gegenüber dem Server authentifizieren können, auf dem IIS ausgeführt 

wird. Dies kann durch die Konfiguration einer Active Directory-Vertrauensstellung mit der anderen 

Gesamtstruktur erfolgen, um die anonyme Authentifizierung in der Lizenzierungspipeline in IIS zu ermöglichen, 

oder durch die Erstellung von Schattenkonten für die Authentifizierung. 

Vertrauenswürdige Veröffentlichungsdomänen 

Ein AD RMS-Cluster kann standardmäßig lediglich Nutzungslizenzen für rechtegeschützte Informationen 

mit einer Veröffentlichungslizenz ausstellen, die von demselben AD RMS-Cluster ausgestellt 

wurde. In einigen Szenarien kann es jedoch erforderlich sein, einen AD RMS-Cluster so zu konfigurieren, 

dass dieser Nutzungslizenzen für Veröffentlichungslizenen ausstellen kann, die von einem 

anderen AD RMS-Cluster ausgestellt wurden. Beispiel: Die Adatum Corporation übernimmt Northwind 

Traders, und es wurde entschieden, dass keine zwei AD RMS-Installationen benötigt werden. 

Northwind Traders kann das SLC und den privaten Schlüssel des Unternehmens exportieren, und der 

AD RMS-Cluster von Adatum kann das Zertifikat und den Schlüssel anschließend importieren. So 

wird Northwind Traders innerhalb des AD RMS-Clusters von Adatum als vertrauenswürdige Veröffentlichungsdomäne 

festgelegt. Anschließend kann der AD RMS-Cluster von Adatum für sämtliche 

rechtegeschützten Inhalte, die ursprünglich über die RMS-Installation bei Northwind Traders verwaltet 

wurden, Veröffentlichungslizenzen entschlüsseln und Nutzungslizenzen ausstellen. 

Zum Konfigurieren einer vertrauenswürdigen Veröffentlichungsdomäne muss die Konsole der Active 

Directory-Rechteverwaltungsdienste geöffnet und die Datei einer vertrauenswürdigen Veröffentlichungsdomäne 

importiert werden. Bei einer Domänendatei handelt es sich um eine XML-basierte 

Datei, die das Server-Lizenzgeberzertifikat, den Clusterschlüssel und gegebenenfalls die Vorlagen für 

Benutzerrechterichtlinien des AD RMS-Clusters enthält, der als vertrauenswürdig festgelegt werden 

soll. Zur Erstellung der XML-Datei wählen Sie das unterhalb des Knotens Vertrauenswürdige Veröffentlichungsdomänen 

aufgeführte SLC und klicken anschließend im Fenster Aktionen auf die Option 

Vertrauenswürdige Veröffentlichungsdomäne exportieren. Zudem muss für zusätzliche Sicherheit und 

zum Verschlüsseln der Datei der vertrauenswürdigen Veröffentlichungsdomäne ein Kennwort angegeben 

werden. Wenn die Datei in einen RMS-Cluster mit einer Vorgängerversion der RMS importiert 

wird, kann das Kontrollkästchen Wurde als V1-kompatible vertrauenswürdige Veröffentlichungsdomänendatei 

gespeichert aktiviert werden. Die Datei kann anschließend gespeichert und an den Administrator 

übermittelt werden, der die Datei der vertrauenswürdigen Veröffentlichungsdomäne in den 

AD RMS-Zielcluster importiert. Abbildung 18.13 zeigt das Dialogfeld für den Export der Datei der 

vertrauenswürdigen Veröffentlichungsdomäne.



Exportieren der Datei der vertrauenswürdigen Veröffentlichungsdomäne 

Nach dem Erhalt der Datei einer vertrauenswürdigen Veröffentlichungsdomäne kann die Datei importiert 

werden, indem Sie den Knoten Vertrauenswürdige Veröffentlichungsdomänen auswählen und im 

Fenster Aktionen auf Vertrauenswürdige Veröffentlichungsdomäne importieren klicken. 

Abbildung 18.14 zeigt die Interaktion zwischen vertrauenswürdigen Veröffentlichungsdomänen. 

1. Northwind Traders exportiert sein SLC, seinen privaten Schlüssel und seine Vorlagen für Benutzerrechterichtlinien 

im XML-Format in die Adatum-Umgebung. 

2. Adatum importiert die XML-Datei und legt Northwind Traders als vertrauenswürdige Veröffentlichungsdomäne 

fest. 

3. Kim (Mitarbeiter von Northwind Traders) sendet ein durch Rechte geschütztes Dokument an Don, 

das ursprünglich über eine Veröffentlichungslizenz verfügte, die durch den RMS-Cluster bei 

Northwind Traders zugewiesen wurde. 

4. Nach dem Erhalt der Inhalte werden Dons RAC und Veröffentlichungslizenz beim Versuch, das 

Dokument zu öffnen, an den lokalen AD RMS-Lizenzierungsserver von Adatum gesendet. 

5. Der AD RMS-Cluster von Adatum kann die vom RMS-Cluster bei Northwind Traders ausgestellte 

Veröffentlichungslizenz entschlüsseln und bestätigen, dass Don in der Veröffentlichungslizenz 

genannt ist. Anschließend stellt er eine Nutzungslizenz für Don aus. 

Hinweis Zur Weiterleitung der Veröffentlichungslizenz an den AD RMS-Cluster am Adatum-Standort müssen 

DNS-Einträge so geändert werden, dass die URL in der Veröffentlichungslizenz nicht in die IP-Adresse 

des Lizenzierungsclusters am Northwind Traders-Standort, sondern in die IP-Adresse des Lizenzierungsclusters 

bei Adatum aufgelöst wird.


SLC, privater Schlüssel 

und Vorlagen (.xml-Datei) 

Adatum 

2 

1 

Northwind 

Traders 

4 5 

Kim 

3 

Don 


Interaktion zwischen vertrauenswürdigen Veröffentlichungsdomänen 

Unterstützung für Identitätsverbund 

Windows Server 2008 AD RMS unterstützt die Möglichkeit, über die Active Directory-Verbunddienste 

(Active Directory Federation Services, AD FS) verbundene Vertrauensstellungen zwischen 

zwei Gesamtstrukturen oder zwei Organisationen zu verwenden. Dies ermöglicht die Verwendung 

einer einzigen AD RMS-Infrastruktur für alle Mitglieder der verbundenen Vertrauensstellung. Wenn 

ein Benutzer rechtegeschützte Informationen veröffentlichen oder nutzen möchte, kann er zum Abrufen 

eines RAC von einem AD RMS-Cluster die Kontoanmeldeinformationen verwenden, die über die 

verbundene Vertrauensstellung festgelegt sind. 

Weitere Informationen Weitere Informationen zu den Active Directory-Verbunddiensten finden Sie in 

Kapitel 19, „Active Directory-Verbunddienste“. 

Unterstützung für Identitätsverbund ist eine optionale Komponente, die mit dem AD RMS-Server 

installiert werden muss. Wenn Sie die Installation des Rollendiensts Unterstützung für Identitätsverbund 

wählen, werden Sie aufgefordert, auch den Ansprüche unterstützenden Active Directory-Verbunddienste-Agent 

als unterstützenden Rollendienst einzuschließen. Ferner muss während der Installation 

der Verbundserver für die Kommunikation mit dem AD RMS-Cluster angegeben werden. 

Hinweis Für die Kommunikation zwischen dem AD FS-Server und dem AD RMS-Cluster ist eine SSLverschlüsselte 

Verbindung erforderlich. Es wird die Verwendung eines von einer Zertifizierungsstelle ausgestellten 

Zertifikats empfohlen, die von allen Clients innerhalb der AD RMS-Lösung als vertrauenswürdig 

eingestuft wird. Für kleine Umgebungen oder Testszenarien kann ein selbstsigniertes Zertifikat verwendet 

werden; dieses Zertifikat muss jedoch manuell auf allen Clients installiert werden, die mit den Servern kommunizieren.


Nach der Installation des Rollendiensts Unterstützung für Identitätsverbund wird in der Konsole für 

die Active Directory-Rechteverwaltungsdienste ein neuer Knoten angezeigt. Sie können den Knoten 

Unterstützung für Identitätsverbund auswählen und den Active Directory-Verbunddienst aktivieren, 

wie in Abbildung 18.15 gezeigt. 


Anzeigen des Knotens Unterstützung für Identitätsverbund 

Sämtliche RACs, die für eine Verbundidentität ausgestellt werden, haben standardmäßig eine Gültigkeitsdauer 

von einem Tag. Dieser Wert kann im Dialogfeld Eigenschaften von Unterstützung für Identitätsverbund 

geändert werden. Ferner kann eine bestimmte URL eines AD RMS-Zertifizierungsservers 

angegeben werden, um RACs für externe Benutzer auszustellen. Das Dialogfeld Eigenschaften 

von Unterstützung für Identitätsverbund ist in Abbildung 18.16 gezeigt. 

Wichtig Stellen Sie sicher, dass Sie alle Auswirkungen der Aktivierung von Proxy-E-Mail-Adressen über 

eine verbundene Vertrauensstellung kennen. Wenn Sie diese Einstellung aktivieren, können böswillige Benutzer 

die Identität eines Benutzers ausspionieren und auf rechtegeschützte Inhalte zugreifen. Dieses Feature ist 

standardmäßig deaktiviert.



Konfigurieren von Active Directory-Verbunddienstrichtlinien 

Verwalten von Vorlagen für Benutzerrechterichtlinien 

Bei Verwendung einer AD RMS-fähigen Anwendung zum Veröffentlichen von geschützten Inhalten, 

wendet ein Benutzer eine bestimmte Vorlage für Benutzerrechterichtlinien an, die er aus einer Liste 

mit verfügbaren Vorlagen ausgewählt hat. Die für eine AD RMS-fähige Anwendung verfügbaren Vorlagen 

für Benutzerrechterichtlinien werden von AD RMS-Administratoren erstellt und verwaltet. Zum 

Erstellen und Verwalten von Vorlagen für Benutzerrechterichtlinien wählen Sie in der Konsole für die 

Active Directory-Rechteverwaltungsdienste den Knoten Vorlagen für Benutzerrechterichtlinien. Es 

können zwei Typen von Vorlagen für Benutzerrechterichtlinien konfiguriert werden: 

• Verteilte Vorlagen für Benutzerrechterichtlinien Wenn Sie eine verteilte Vorlage für Benutzerrechterichtlinien 

konfigurieren, wird die Vorlage für die Benutzer bereitgestellt, um Regeln und Bedingungen 

auf geschützte Inhalte anzuwenden. Wenn eine verteilte Vorlage nicht mehr verwendet 

werden soll, kann diese Vorlage ausgewählt und archiviert werden. 

• Archivierte Vorlagen für Benutzerrechterichtlinien Bei einer archivierten Vorlage für Benutzerrechterichtlinien 

handelt es sich um eine Vorlage, die nicht für die Benutzer verfügbar ist. Typischerweise 

wird eine archivierte Vorlage zum Entwerfen von Vorlagen oder Erstellen von Starter- 

Vorlagen verwendet, die anschließend kopiert, geändert und an AD RMS-Clients verteilt werden 

können. Ferner kann eine Vorlage für Benutzerrechterichtlinien archiviert werden, wenn sie nicht 

zum Veröffentlichen neuer Inhalte verwendet werden sollte, jedoch weiterhin benötigt wird, da 

ältere Inhalte noch immer verfügbar sind, für welche diese Vorlage gilt. 

Sämtliche Vorlagen für Benutzerrechterichtlinien werden standardmäßig in der von den AD RMS verwendeten 

Konfigurationsdatenbank gespeichert. Die Vorlagen können jedoch ebenfalls in einen freigegebenen 

Ordner kopiert und für Arbeitsstationen bereitgestellt werden, um lokalen Zugriff auf die 

Vorlagen für Benutzerrechterichtlinien und die Offlineerstellung von rechtegeschützten Inhalten zu 

ermöglichen.


Erstellen einer neuen verteilten Vorlage für Benutzerrechterichtlinien 

Führen Sie zum Erstellen einer neuen verteilten Vorlage für Benutzerrechterichtlinien die folgenden 

Schritte aus: 

1. Wählen Sie in der Konsole der Active Directory-Rechteverwaltungsdienste Vorlagen für Benutzerrechterichtlinien, 

und klicken Sie auf Verteilte Vorlage für Benutzerrechterichtlinien erstellen. 

2. Wählen Sie auf der Seite Vorlagenidentifikationsinformationen hinzufügen die auf den Clientcomputern 

unterstützte Sprache. Klicken Sie auf Hinzufügen, um die Sprache und anschließend einen 

Namen und eine Beschreibung für die Vorlage anzugeben. Abbildung 18.17 zeigt die Vorlagenidentifikationsinformationen 

für eine neue Vorlage mit dem Namen 

Adatum_nur_interne_Verwendung. 


Angeben der Vorlagenidentifikationsinformationen 

3. Auf der Seite Benutzerrechte hinzufügen können Rechte für Benutzer oder Gruppen innerhalb der 

Organisation festgelegt werden. Dabei kann entweder die E-Mail-Adresse für einen Benutzer oder 

eine Gruppe angegeben oder die Vorlage durch Auswahl von Alle Benutzer auf sämtliche Benutzer 

angewendet werden, die ein RAC abrufen können (einschließlich AD FS- und Windows Live 

ID-Benutzer). Ferner kann dem Autor des Dokuments permanenter Vollzugriff gewährt und eine 

URL zur Verwendung für Benutzeranforderungen für zusätzliche Rechte angegeben werden. Eine 

URL zur Anforderung von Rechten weist üblicherweise das Format mailto: URL auf, sodass 

Benutzer zusätzliche Rechte per E-Mail-Nachricht anfordern können. 

4. Auf der Seite Ablaufrichtlinie angeben können Bedingungen für den Inhalts- und Nutzungslizenzablauf 

festgelegt werden. 

5. Auf der Seite Erweiterte Richtlinie angeben können die folgenden Optionen konfiguriert werden: 

Benutzern das Anzeigen des geschützten Inhalts mit einem Browser-Add-On ermöglichen Diese 

Einstellung ermöglicht Benutzern das Anzeigen von geschützten Informationen über das 

Informationsrechteverwaltungs-Add-On für Internet Explorer. Wird diese Option nicht ausgewählt, 

können die Inhalte ausschließlich mit der Anwendung angezeigt werden, in der sie 

erstellt wurden. 

Bei jedem Zugriff auf den Inhalt eine neue Nutzungslizenz anfordern (Zwischenspeichern auf Clientseite 

deaktivieren) Wählen Sie diese Option, wenn die Benutzer bei jedem Öffnen von Inhalten, 

die auf dieser Vorlage basieren, eine Verbindung mit dem AD RMS-Cluster herstellen und 

eine neue Nutzungslizenz anfordern sollen. Wird diese Option nicht ausgewählt, kann eine auf 

dem Client zwischengespeicherte Version der Nutzungslizenz für den Zugriff auf die Inhalte 

verwendet werden.


Wenn Sie zusätzliche Informationen für die AD RMS-fähige Anwendung angeben möchten, können 

Sie die Informationen hier als Name/Wert-Paar angeben. Über diese Option können anwendungsspezifische 

Einstellungen zur Richtlinienvorlage hinzugefügt werden. 

6. Auf der Seite Sperrrichtlinie angeben kann festgelegt werden, ob geschützte Inhalte basierend auf 

einer Sperrliste gesperrt werden können oder nicht. Sie können das Feature aktivieren und einen 

Speicherort für die Sperrliste und die Datei mit dem öffentlichen Schlüssel angeben. 

7. Nach dem Erstellen einer Vorlage für Benutzerrechterichtlinien kann eine Rechtezusammenfassung 

angezeigt werden, indem Sie die neue Vorlage auswählen und auf Rechtezusammenfassung 

anzeigen klicken. Abbildung 18.18 zeigt eine solche Benutzerrechtezusammenfassung. 


Anzeigen der Benutzerrechtezusammenfassung 

Hinweis Die Schritte zum Erstellen einer neuen archivierten Vorlage für Benutzerrechterichtlinien stimmen 

mit den Schritten zum Erstellen einer verteilten Vorlage für Benutzerrechterichtlinien überein. 

Verteilen von Vorlagen für Benutzerrechterichtlinien 

Zum Erstellen von rechtegeschützten Informationen unter Verwendung einer Vorlage für Benutzerrechterichtlinien 

benötigen Benutzer Zugriff auf die Vorlage. Für Benutzer des internen Netzwerks 

können Vorlagen für Benutzerrechterichtlinien über einen freigegebenen Netzwerkordner bereitgestellt 

werden. Für mobile Benutzer, die nicht ständig mit dem Netzwerk verbunden sind, können die 

Vorlagen in ein Verzeichnis auf dem lokalen Computer kopiert werden. Der in Windows Server 2008 

und Windows Vista SP1 integrierte AD RMS-Client kann lokale Kopien von Vorlagen für Benutzerrechterichtlinien 

automatisch ermitteln und aktualisieren. 

So funktioniert es: Automatisches Verteilen von AD RMS-Vorlagen für 

Benutzerrechterichtlinien mit Windows Server 2008 und Windows Vista SP1 

Für eine vereinfachte Verwaltung von AD RMS-Vorlagen für Benutzerrechterichtlinien wird mit 

Windows Server 2008 und Windows Vista mit Service Pack 1 (SP1) eine neue Vorlagenverteilungspipeline 

auf allen Servern des AD RMS-Clusters eingeführt. Über diese neue Pipeline können 

die Vorlagen für Benutzerrechterichtlinien durch den AD RMS-Client vom Cluster angefordert 

und lokal auf dem AD RMS-Client gespeichert werden.


AD RMS-Vorlagen für Benutzerrechterichtlinien werden vom AD RMS-Client über eine geplante 

Aufgabe angefordert. Es gibt zwei Arten von geplanten Aufgaben: automatisiert oder manuell. 

Manuell geplante Aufgaben können zu einem beliebigen Zeitpunkt ausgeführt werden. Die automatisierte 

geplante Aufgabe ist so konfiguriert, dass sie eine Stunde nach der Anmeldung eines Benutzers 

am Computer sowie täglich um 3.00 Uhr morgens ausgeführt wird. Diese geplante Aufgabe ist 

standardmäßig deaktiviert. Sie kann über die Aufgabenplanung oder über ein Gruppenrichtlinienobjekt 

aktiviert werden. 

Bei AD RMS-Clients unter einem anderen Betriebssystem als Windows Vista mit SP1 oder Windows 

Server 2008 müssen die Vorlagen für Benutzerrechterichtlinien weiterhin manuell von einem 

zentralen Speicherort verteilt werden. Weitere Informationen zur Verteilung von AD RMS-Vorlagen 

für Benutzerrechterichtlinien finden Sie unter „Creating and Deploying Active Directory 

Rights Management Services Rights Policy Templates Step-by-Step Guide“ auf der folgenden 

Seite: http://technet2.microsoft.com/windowsserver2008/en/library/909a3fa6-a7c5-4c86-9468- 

2b77b72c54841033.mspx. 

Brian M. Lich 

Technical Writer 

Windows Server Security 

Gehen Sie folgendermaßen vor, um einen Speicherort für Vorlagen für Benutzerrechterichtlinien 

anzugeben und die Vorlagen in dieses Verzeichnis zu exportieren: 

1. Erstellen Sie einen Ordner auf dem Server als Bereitstellungspunkt zum Speichern der exportierten 

Vorlagen für Benutzerrechterichtlinien. Für die Freigabe sollte der Gruppe Jeder die 

Berechtigung Vollzugriff erteilt werden; für den Ordner selbst sollten die folgenden Berechtigungen 

festgelegt werden: 

AD RMS-Dienstgruppe – Ändern 

System – Ändern 

Benutzer – Lesen 

2. Wählen Sie in der Konsole der Active Directory-Rechteverwaltungsdienste Vorlagen für Benutzerrechterichtlinien, 

und klicken Sie auf Speicherort verteilter Vorlagen für Benutzerrechterichtlinien 

ändern. Aktivieren Sie das Kontrollkästchen Export aktivieren, und geben Sie den UNC- 

Pfad zum freigegebenen Ordner an, in dem die exportierten Vorlagen gespeichert werden sollen. 

Das Dialogfeld Vorlagen für Benutzerrechterichtlinien ist in Abbildung 18.19 gezeigt. Wenn Sie 

auf OK klicken, wird eine XML-Version der Vorlage aus der Konfigurationsdatenbank in den freigegebenen 

Ordner exportiert. 

Nach dem Export der Vorlagen für Benutzerrechterichtlinien in den freigegebenen Ordner müssen auf 

jedem Clientcomputer Registrierungseinstellungen so konfiguriert werden, dass sie auf den lokalen 

Vorlagenspeicher zeigen. Ferner müssen die Vorlagen für Benutzerrechterichtlinien aus dem freigegebenen 

Ordner auf dem Server in den lokalen Vorlagenspeicher auf den einzelnen Clients kopiert werden. 

Bei Windows Server 2008 und Windows Vista SP1 müssen die Dateien nicht manuell kopiert 

werden, da dieser Vorgang über eine geplante Aufgabe automatisch durchgeführt wird.



Angeben des Speicherorts für exportierte Vorlagen 

Die Konfiguration der Clientregistrierung kann vom Typ der Anwendung abhängen, die zum Schützen 

der Informationen verwendet wird. Im Allgemeinen werden die Registrierungseinstellungen über 

die folgenden Methoden konfiguriert: 

• Bereitstellen von Registrierungseinstellungen über Gruppenrichtlinien Sie können Gruppenrichtlinieneinstellungen 

oder spezifische anwendungsbasierte Gruppenrichtlinien-ADM- oder ADMX- 

Vorlagen verwenden, um den Vorlagenspeicher über die Registrierungseinstellungen anzugeben. 

• Manuelles Konfigurieren der Registrierungseinstellungen Sie können die Registrierung manuell 

ändern, um den Pfad zum lokalen Vorlagenspeicher auf einem Clientcomputer anzugeben. Zu diesem 

Zweck muss der folgende Schlüssel erstellt werden: 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\12.0\Common\DRM\ 

AdminiTemplatePath 

Typ: REG_EXPAND_SZ 

Empfohlener Wert: %allusersprofile%\Application Data\Microsoft\DRM\ 

 

Hinweis Der aufgeführte Schlüssel bezieht sich auf Office 2007. Bei der Konfiguration von Office 2003 

ersetzen Sie 12.0 durch 11.0. Zudem lautet der empfohlene Wert für Windows Vista %userprofile%\ 

AppData\Local\Microsoft\DRM. 

Nach der Konfiguration der Registrierungseinstellung AdminTemplatePath auf den einzelnen Clientcomputern 

können die Benutzer sämtliche Vorlagen im lokalen Vorlagenspeicher auf Dokumente 

anwenden, die durch Rechte geschützt werden sollen. Abbildung 18.20 zeigt ein Beispiel der Vorlage 

Adatum_nur_interne_Verwendung, die auf ein Office Word 2007-Dokument angewendet wird.



Anwenden einer benutzerdefinierten Vorlage für Benutzerrechterichtlinien 

Konfigurieren von Ausschlussrichtlinien 

Über eine Ausschlussrichtlinie kann das Abrufen von Zertifikaten und Anfordern von Lizenzen vom 

AD RMS-Cluster für bestimmte Entitäten ausgeschlossen werden. Im Gegensatz zum Sperren wird 

die Entität durch diesen Vorgang nicht ungültig. Gegebenenfalls vorhandene Lizenzen, die mit ausgeschlossenen 

Entitäten verknüpft sind, sind weiterhin gültig, neue Lizenzierungsanforderungen werden 

jedoch abgelehnt. Es können vier Typen von Ausschlussrichtlinien konfiguriert werden: 

• Benutzer Sie können eine Benutzerausschlussliste angeben, um zu definieren, welche Benutzerkonten 

vom AD RMS-Cluster als nicht vertrauenswürdig eingestuft werden. Bei Aktivierung des 

Benutzerausschlusses kann der Benutzername (in Form einer E-Mail-Adresse) oder der öffentliche 

Schlüssel des RAC eines Benutzers angegeben werden, der auf dem Server ausgeschlossen 

werden soll. 

• Anwendungen Sie können bestimmte Anwendungen ausschließen, die der AD RMS-Server 

anschließend als nicht vertrauenswürdig einstuft. Beispielsweise kann die Unterstützung der 

Rechteverwaltung auf diese Weise nur für bestimmte Microsoft Office-Versionen bereitgestellt 

werden. Um die Verwendung anderer Microsoft Office-Versionen in der AD RMS-Umgebung zu 

verhindern, können Sie den Anwendungsdateinamen sowie die Mindest- und die Maximalversion 

angeben.


• Lockbox Sie können eine Ausschlussrichtlinie konfigurieren, um sicherzustellen, dass nur eine 

bestimmte Mindestversion der AD RMS-Lockbox verwendet wird. Benutzer mit einer niedrigeren 

Version können keine RACs oder Nutzungslizenzen vom AD RMS-Cluster abrufen. 

• Windows-Versionen Aus Sicherheitsgründen sollten die meisten Organisationen Windows 98 

Second Edition und Windows Millennium Edition nicht länger unterstützen. Um sicherzustellen, 

dass diese beiden Betriebssysteme nicht in der AD RMS-Umgebung verwendet werden, kann eine 

Ausschlussrichtlinie konfiguriert werden, die verhindert, dass Benutzer dieser Betriebssysteme 

Nutzungslizenzen vom AD RMS-Cluster abrufen. 

Konfigurieren von Sicherheitsrichtlinien 

Der Knoten Sicherheitsrichtlinien in der Konsole Active Directory-Rechteverwaltungsdienste umfasst 

verschiedene sicherheitsbezogene Features wie z.B. das Konfigurieren von Administratoren, das 

Ändern des Clusterschlüsselkennworts sowie ein Feature, um allen Benutzern Vollzugriff auf 

geschützte Inhalte zu gewähren. Bevor Sie eine dieser Optionen ändern, müssen Sie die Auswirkungen 

auf Ihr Sicherheitsmodell sorgfältig prüfen, da diese Änderungen die Sicherheit des gesamten 

AS RMS-Clusters beeinflussen können. 

Verwalten von Administratoren 

Bei der Gruppe Administratoren handelt es sich um eine Gruppe, der in allen Nutzungslizenzen vollständigen 

Besitzerrechte gewährt werden, die vom AD RMS-Cluster ausgestellt werden. So erhalten 

Mitglieder der Gruppe Administratoren im Wesentlichen Vollzugriff auf alle rechtegeschützten 

Inhalte, die über den Cluster verwaltet werden. Diese Gruppe wird typischerweise als Datenwiederherstellungsmechanismus 

eingesetzt, um auf abgelaufene Inhalte oder Informationen zuzugreifen, die 

durch einen Benutzer geschützt wurden, der nicht mehr Mitarbeiter der Organisation ist. 

Die Gruppe Administratoren ist per Voreinstellung nicht aktiviert und sollte nur aktiviert werden, 

wenn eine Datenwiederherstellung erforderlich ist. 

Zum Einrichten einer Administratorengruppe können Sie die folgenden Aufgaben ausführen: 

1. Erstellen Sie unter Active Directory-Benutzer und -Computer eine Sicherheitsgruppe zur Verwendung 

für die Administratorengruppe. Für diese Gruppe muss auch eine E-Mail-Adresse angegeben 

werden. 

2. Erweitern Sie in der Konsole Active Directory-Rechteverwaltungsdienste den Knoten Sicherheitsrichtlinien, 

und klicken Sie auf Administratoren. 

3. Klicken Sie im Fenster Aktionen auf Administratoren aktivieren. 

4. Klicken Sie im Detailfenster auf Administratorengruppe ändern. 

5. Geben Sie im Dialogfeld Administratoren die E-Mail-Adresse für die Active Directory-Sicherheitsgruppe 

ein, die als Administratorengruppe verwendet werden soll. 

Abbildung 18.21 zeigt die Konfiguration einer Administratorengruppe. Beachten Sie, dass ADRMS- 

Administratoren@adatum.com konfiguriert wurde. Sämtliche Mitglieder dieser Gruppe verfügen über 

vollständige Besitzerrechte für Inhalte, die über diesen AD RMS-Cluster verwaltet werden.



Konfigurieren einer Administratorengruppe 

Die Aktivierung und Verwendung der Gruppe Administratoren kann überwacht werden, indem Sie in 

der Ereignisanzeige auf das Anwendungsprotokoll zugreifen und nach den in Tabelle 18.6 aufgeführten 

Ereignissen suchen. 

Tabelle 18.6 

Ereignisse im Zusammenhang mit der Administratorengruppe 

Ereignis-ID Quelle Beschreibung 

163 Active Directory-Rechteverwaltungsdienste 

49 Active Directory-Rechteverwaltungsdienste 

Die Gruppe Administratoren der Active Directory-Rechteverwaltungsdienste (AD 

RMS) wurde deaktiviert. 

Für einen Benutzer, der Mitglied der Gruppe Administratoren ist, wurde eine Nutzungslizenz 

ausgestellt. Die E-Mail-Adresse des Benutzers lautet: %1. 

E-Mail-Adresse: %1. 

Für den Zugriff auf rechtegeschützte Inhalte wird eine Nutzungslizenz verwendet.


Ändern des Clusterschlüsselkennworts 

Bei der ursprünglichen Bereitstellung eines neuen AD RMS-Clusters wird die Methode zum 

Schützen des AD RMS-Clusterschlüssels festgelegt (AD RMS-Clusterschlüsselschutz oder die Verwendung 

eines hardware- oder softwarebasierten Kryptografiedienstanbieters). Bei Auswahl des 

AD RMS-Clusterschlüsselschutzes muss ein sicheres Kennwort für die Verschlüsselung des Clusterschlüssels 

in der Konfigurationsdatenbank angegeben werden. 

In einigen Situationen muss das Clusterschlüsselkennwort möglicherweise geändert werden. Dieser 

Schritt kann in der Konsole der Active Directory-Rechteverwaltungsdienste im Knoten Clusterschlüsselkennwort 

durchgeführt werden. Für eine ordnungsgemäße Funktionsweise muss beim 

Zurücksetzen des Kennworts sichergestellt werden, dass das Clusterschlüsselkennwort auf sämtlichen 

AD RMS-Servern innerhalb des Clusters zurückgesetzt wird. 

Hinweis Das Kennwort kann nicht über eine Remotekonsole geändert werden, sondern muss über die 

lokal auf dem AD RMS-Server gestartete Konsole geändert werden. 

Außerbetriebsetzen der AD RMS 

Wenn der gesamte AD RMS-Cluster aus einer Organisation entfernt werden muss, muss der Cluster 

zunächst außer Betrieb gesetzt werden. Bei der Außerbetriebsetzung erhalten automatisch sämtliche 

Benutzer Vollzugriff auf Inhalte, die zuvor über den Cluster geschützt waren. Die Benutzer können 

die Inhalte anschließend ohne Rechteschutz speichern. 

Achtung Nach der Außerbetriebsetzung eines Clusters kann die vorherige Konfiguration nicht wiederhergestellt 

werden, und die Außerbetriebsetzung kann nicht rückgängig gemacht werden. Verwenden Sie diese 

Option daher mit Vorsicht! 

Führen Sie zum Außerbetriebsetzen der AD RMS die folgenden Schritte aus: 

1. Wechseln Sie auf dem AD RMS-Server zu %systemdrive%\inetpub\wwwroot\_wmcs\ 

decommission. Gewähren Sie der Gruppe Jeder für die Datei Decommissioning.asmx die Berechtigungen 

Lesen und Ausführen. 

2. Wechseln Sie innerhalb der Konsole der Active Directory-Rechteverwaltungsdienste zum Knoten 

Sicherheitsrichtlinien, und wählen Sie Außerbetriebsetzung. 

3. Klicken Sie im Fenster Aktionen auf Außerbetriebsetzung aktivieren. 

4. Klicken Sie im Detailfenster auf Außer Betrieb setzen. Wiederholen Sie diese Schritte für sämtliche 

Server innerhalb des Clusters. 

5. Exportieren Sie das Server-Lizenzgeberzertifikat, und deinstallieren Sie die AD RMS-Serverrolle 

vom Server. Hinweis: Dieser Vorgang sollte erst erfolgen, nachdem Sie sichergestellt haben, dass 

sämtliche rechtegeschützten Inhalte verschlüsselt wurden. 

Anzeigen von Berichten 

Die Windows Server 2008 AD RMS bieten Berichte zum Erfassen von Statistikdaten oder Behandeln 

von Problemen mit der Clientzertifizierung oder -lizenzierung. Es können unter anderem die folgenden 

Berichte angezeigt werden: 

• Statistikberichte Diese Berichte enthalten Informationen zu sämtlichen zertifizierten Benutzerkonten, 

zertifizierten Domänenbenutzerkonten und zertifizierten Verbundidentitäten.


• Systemstatus Dieser Bericht liefert Informationen zur Gesamtanzahl an Anforderungen sowie zu 

erfolgreichen und fehlgeschlagenen Anforderungen für Dienstidentifizierungen, Client-Lizenzgeberzertifikate 

oder Zertifizierungen innerhalb eines bestimmten Zeitraums. Abbildung 18.22 

zeigt ein Beispiel für den Bericht Systemstatus. 

• Problembehandlung Dieser Bericht liefert ähnliche Informationen wie der Bericht Systemstatus, 

ermöglicht jedoch zudem das Abrufen von Informationen zu einem bestimmten Benutzer und für 

einen bestimmten Zeitraum. 


Anzeigen des Berichts Systemstatus 

Hinweis Zum Anzeigen der Berichte Systemstatus und Problembehandlung muss Microsoft Report 

Viewer Redistributable 2005 heruntergeladen werden. In der Konsole der Active Directory-Rechteverwaltungsdienste 

finden Sie im Detailbereich einen Link zu diesem Download. 


In diesem Kapitel wurden die Active Directory-Rechteverwaltungsdienste (Active Directory Rights 

Management Services, AD RMS) als Lösung vorgestellt, um die digitalen Inhalte innerhalb einer 

Organisation zu schützen. Mithilfe von Zertifizierungen und Nutzungszertifikaten können Benutzer 

Rechteverwaltungsberechtigungen auf Informationen anwenden, um das Lesen, Kopieren, Drucken 

oder Weiterleiten dieser Inhalte durch nicht autorisierte Benutzer zu verhindern. Die AD RMS können 

eingesetzt werden, um Inhalte sowohl für Benutzer des Intranets als auch für Benutzer zu schützen, 

die über das Internet auf die Daten zugreifen. Ferner lassen sich diese Dienste mit den Active 

Directory-Verbunddiensten integrieren.


In diesem Kapitel wurde darüber hinaus die Implementierung und Verwaltung einer AD RMS-Umgebung 

beschrieben. Zu den Verwaltungsaufgaben zählen u.a. das Konfigurieren von Vertrauensrichtlinien, 

das Bereitstellen von Vorlagen für Benutzerrechterichtlinien, das Anwenden von Ausschlussrichtlinien 

sowie das Bearbeiten von Sicherheitsrichtlinien. Des Weiteren können Berichte mit 

Statistikdaten und Informationen zur Problembehandlung angezeigt werden, um die Benutzeranzahl 

und den Status der AD RMS-Umgebung zu ermitteln. 





• Weitere Informationen zur Verwendung der Active Directory-Verbunddienste finden Sie in 

Kapitel 19, „Active Directory-Verbunddienste“ 

• „Microsoft Windows Rights Management Services Client with Service Pack 2-x86“ unter 


• „Microsoft Windows Rights Management Services Client with Service Pack 2-x64“ unter 


• „Microsoft Windows Rights Management Services Client with Service Pack 2-IA64“ unter 


• „XrML“ unter http://www.xrml.org/ 

• „Active Directory Rights Management Services SDK“ unter http://msdn2.microsoft.com/en-us/ 

library/bb968798(VS.85).aspx 

• „Rights Management Add-on for Internet Explorer“ unter http://www.microsoft.com/downloads/ 

details.aspx?FamilyID=B48F920B-5AF0-46B4-994F-2F62582CC86F&displaylang=en 

• „Windows Rights Management Services“ unter http://go.microsoft.com/fwlink/?LinkId=14149 

• „Active Directory Rights Management Services Technical Library“ unter http://go.microsoft.com/ 

fwlink/?LinkId=51479 

• „Active Directory Rights Management Services Events and Errors Troubleshooting“ unter 

http://technet2.microsoft.com/windowsserver2008/en/library/8a2b240e-e426-4c37-8ca4- 

55a5aaad6fb91033.mspx 

• „Active Directory Rights Management Services Installed Help on the Web“ unter 

http://technet2.microsoft.com/windowsserver2008/en/library/c70ba42a-272d-4e99-940fbf7f30277ae41033.mspx 

• „Windows Rights Management Services Technical Library“ unter http://go.microsoft.com/fwlink/ 

?LinkId=68637 

• „Active Directory Rights Management Services Scripting API“ unter http://msdn2.microsoft.com/ 

en-us/library/bb968797(VS.85).aspx

731 

K A P I T E L 1 9 

Active Directory-Verbunddienste 


Überblick über die AD FS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 

Implementieren der AD FS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 




Die Active Directory-Domänendienste (Active Directory Domain Services, AD DS) bieten einen 

leistungsstarken Verzeichnisdienst für den Schutz und die Verwaltung unternehmensinterner Netzwerkressourcen. 

Darüber hinaus können Benutzer außerhalb des Unternehmens die AD DS zur 

Authentifizierung von Benutzeranforderungen für den Webzugriff, Remoteverbindungen zu Exchange 

Server-Systemen und Remotezugriffsverbindungen verwenden. Da sich bei den AD DS jedoch alle 

Benutzerkonten an einem zentralen Speicherort befinden, können die Active Directory-Domänendienste 

nur auf Benutzer mit vorhandenen Konten ausgeweitet werden. 

Viele Organisationen pflegen Partnerschaften und Arbeitsbeziehungen mit anderen Organisationen, 

bei denen Benutzer der einen Organisation auf Informationen oder Anwendungen einer anderen Organisation 

zugreifen müssen. Durch die Einrichtung von Gesamtstrukturvertrauensstellungen können 

die AD DS so erweitert werden, dass diese Zugriffsanforderungen erfüllt werden. Gesamtstrukturvertrauensstellungen 

setzen jedoch voraus, dass die Domänencontroller beider Organisationen miteinander 

kommunizieren können. Besteht zwischen den Organisationen lediglich eine öffentliche Internetverbindung, 

führt die Einrichtung von Gesamtstrukturvertrauensstellungen zu Sicherheitslücken. 

Die Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) wurden von 

Microsoft speziell für einige dieser Zugriffsszenarien zwischen Organisationen entwickelt. Die erstmalig 

mit Windows Server 2003 R2 veröffentlichten Active Directory-Verbunddienste bieten einen 

sicheren Zugriff auf webbasierte Anwendungen innerhalb einer Organisation und zwischen Organisationen, 

unabhängig von externen oder Gesamtstrukturvertrauensstellungen zwischen diesen Organisationen. 

Mit den AD FS erhalten IT-Abteilungen vollständige Verwaltungsautonomie und können 

gleichzeitig die Zusammenarbeit zwischen Organisationen ermöglichen. Beispielsweise kann jede 

Organisation in einem B2B-Szenario, das eine AD FS-Konfiguration mit Federated-Web-SSO 

umfasst, auf für andere Organisationen transparente Weise eigene Benutzer- und Gruppenkonten verwalten. 

Darüber hinaus kann jede Organisation den Zugriff auf selbst bereitgestellte webbasierte 

Anwendungen verwalten. Mithilfe der AD FS wird so der Zugriff über Benutzerkonten einer Organisation 

auf die Anwendung der anderen Organisation ermöglicht, während die IT-Abteilungen beider 

Organisationen weiterhin über die vollständige administrative Steuerung verfügen. 

Zudem ermöglichen die AD FS Benutzern eine webbasierte einmalige Anmeldung (Single Sign-On, 

SSO) beim Zugriff auf Extranetwebsites oder über Verbundpartnerschaften zugängliche Sites im 

Internet.

732 Kapitel 19: Active Directory-Verbunddienste 

So müssen sich Benutzer nur einmal gegenüber dem Verzeichnisdienst ihrer Organisation authentifizieren, 

um Zugriff auf verschiedene webbasierte Anwendungen zu erhalten, die im Umkreisnetzwerk 

der eigenen Organisation oder einer Partnerorganisation gehostet werden. 

Überblick über die AD FS 

Für den Zugriff auf webbasierte Anwendungen in unterschiedlichen Organisationen oder in verschiedenen 

Netzwerken einer Organisation stellen IT-Abteilungen Identitätsverbundlösungen bereit. Windows 

Server 2008 AD FS ist eine solche Identitätsverbundlösung. Identitätsverbundlösungen bieten 

eine auf Standards basierende Technologie für die Zusammenarbeit mit anderen Organisationen. 

Identitätsverbund 

Ein Identitätsverbund bietet Organisationen die Möglichkeit, den Benutzerzugriff auf Ressourcen für 

verschiedene Organisationen oder Serverplattformen freizugeben. Ein Ziel der Identitätsverbundlösung 

ist, dass Organisationen eigene Verzeichnisse verwalten können, während weiterhin ein sicherer 

Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen Organisationen stattfindet. 

Die einmalige Anmeldung an verschiedenen webbasierten Anwendungen ist ein weiteres 

wichtiges Ziel der Identitätsverbundlösungen. 

Bei der Einrichtung einer Identitätsverbundpartnerschaft stimmen beide Partner der Einrichtung einer 

Verbundvertrauensstellung zwischen den beiden Organisationen zu. Als Teil der Vertrauensstellung 

legen die Partner zudem fest, auf welche Ressourcen die jeweils andere Organisation zugreifen kann 

und wie dieser Zugriff auf die Ressourcen ermöglicht wird. Eine Organisation kann zum Beispiel eine 

Identitätsverbundlösung implementieren, die einem Vertriebsmitarbeiter den Zugriff auf Informationen 

in einer Lieferantendatenbank über eine Webanwendung ermöglicht, die im Netzwerk des Lieferanten 

gehostet wird. Der für die Vertriebsorganisation verantwortliche Administrator muss in diesem 

Fall sicherstellen, dass die entsprechenden Vertriebsmitarbeiter einer Gruppe angehören, die über 

Zugriffsrechte auf die Datenbank des Lieferanten verfügt. Der Administrator der Lieferantenorganisation 

wiederum muss gewährleisten, dass die Mitarbeiter der Partnerorganisation ausschließlich auf die 

für sie relevanten Daten zugreifen können. 

Bei einer Identitätsverbundlösung befinden sich Benutzeridentitäten und zugehörige Anmeldeinformationen 

im Besitz der Organisation des Benutzers und werden von dieser gespeichert und verwaltet. 

Als Teil der Identitätsverbund-Vertrauensstellung muss jede Organisation eine sichere Art der Freigabe 

von Benutzeridentitäten für den Zugriff auf Ressourcen definieren. Jeder Partner muss die 

Dienste definieren, die er vertrauenswürdigen Partnern und Kunden zur Verfügung stellt, sowie 

andere vertrauenswürdige Organisationen und Benutzer sowie akzeptierte Arten von Anmeldeinformationen 

und Anforderungen festlegen. Darüber hinaus muss angegeben werden, wie vertrauliche 

Informationen vor anderen vertrauenswürdigen Organisationen und Benutzern mithilfe von Datenschutzrichtlinien 

geschützt werden. 

Ein Identitätsverbund kann in den folgenden Szenarien implementiert werden: 

• Business-to-Business (B2B) Organisationen arbeiten mit vertrauenswürdigen Partnern, 

Lieferanten und Auftraggebern zusammen. Diese Partnerschaften können sowohl typische Lieferantenbeziehungen 

als auch Outsourcing-Beziehungen für interne Funktionen wie Arbeitgeberleistungen, 

Personalverwaltung oder Reisebuchungen beinhalten. Verbundvertrauensstellungen 

ermöglichen eine effizientere Zusammenarbeit von Organisationen ohne aufwendige Identitätenverwaltung 

in verschiedenen Organisationen.

Überblick über die AD FS 733 

In einer derartigen Beziehung entspricht der Verbund einem elektronischen Datenaustausch 

(Electronic Data Interchange, EDI), bei dem jedoch standardmäßige Internetprotokolle verwendet 

werden. Auf diese Weise lassen sich Vertrauensstellungen einfacher verwalten und kostengünstiger 

pflegen. Zusätzlich erhalten Benutzer durch den Identitätsverbund die Möglichkeit, sich mit 

unternehmenseigenen Anmeldeinformationen einmalig anzumelden, ohne die Anmeldeinformationen 

gegenüber den Geschäftspartnern offenzulegen. 

Bei den AD FS ist das hier erwähnte B2B-Szenario mit dem Federated-Web-SSO-Entwurf vergleichbar, 

der später in diesem Kapitel beschrieben wird. 

• Business-to-Employee (B2E) Eine Organisation muss den Mitarbeitern im Außendienst über das 

Internet Ressourcen zur Verfügung stellen, oder Benutzern in der Organisation soll der Zugriff auf 

Geschäftsanwendungen in einem Umkreisnetzwerk gewährt werden. Zum Beispiel könnten Organisationen 

durch die Integration verschiedener Back-End-Systeme Informationsportale erstellen, 

die Benutzern konsolidierte Informationen bieten. Die AD FS ermöglichen einen sicheren Zugriff 

auf Anwendungen, wobei lediglich eine einmalige Benutzeranmeldung erforderlich ist. 

Bei den AD FS ist das hier erwähnte B2E-Szenario mit dem Federated-Web-SSO-Entwurf mit 

Gesamtstrukturvertrauensstellung vergleichbar, der später in diesem Kapitel beschrieben wird. 

• Business-to-Consumer (B2C) Eine Organisation möchte einzelnen Benutzern über das Internet 

Zugriff auf Ressourcenes gewähren. Es handelt sich nicht um Mitarbeiter der Organisation, und 

die Benutzer verfügen möglicherweise nicht über ein Benutzerkonto in der Gesamtstruktur einer 

Partnerorganisation. Bei diesem Szenario besteht die Möglichkeit, in der Organisation Benutzerkonten 

für die Kunden in den AD DS oder AD LDS (Active Directory Lightweight Directory Services) 

zu erstellen. Anschließend kann diesen Benutzern eine einmalige Authentifizierung und der 

Zugriff auf mehrere Anwendungen gewährt werden. 

Bei den AD FS ist das hier erwähnte B2C-Szenario mit dem Web-SSO-Entwurf vergleichbar, der 

später in diesem Kapitel beschrieben wird. 

Webdienste 

Ein Identitätsverbund basiert auf den Industriestandards für Webdienste. Die Webdienststandards 

beinhalten eine Reihe von Spezifikationen für die Erstellung verbundener Anwendungen und Dienste, 

deren Funktionalität und Schnittstellen gegenüber potenziellen Benutzern in verschiedenen Organisationen 

mit unterschiedlichen Plattformen offengelegt werden. Webdienste basieren auf folgenden 

Standards: 

• Für die Datenübertragung über HTTP verwenden die meisten Webdienste XML (Extensible 

Markup Language). Mithilfe von XML können Entwickler eigene benutzerdefinierte Tags erstellen, 

die die Definition, Übertragung, Validierung und Interpretation von Daten zwischen Anwendungen 

und zwischen Organisationen ermöglichen. 

• Webdienste bieten Webbenutzern über ein Standardwebprotokoll hilfreiche Funktionen. Diese 

basieren in den meisten Fällen auf SOAP (Simple Object Access Protocol). SOAP ist das Kommunikationsprotokoll 

für XML-Webdienste und eine Spezifikation, die das XML-Format für 

Nachrichten festlegt. Im Wesentlichen enthält es eine Beschreibung des Layouts für ein gültiges 

XML-Dokument. 

• Webdienste stellen Informationen zu ihren Schnittstellen bereit, sodass Benutzer eine Clientanwendung 

erstellen können, die eine Kommunikation mit den Webdiensten ermöglicht. Diese 

Beschreibung ist in der Regel in einem XML-Dokument enthalten, das als WSDL-Dokument (Web 

Services Description Language) bezeichnet wird.


Anders ausgedrückt: Eine WSDL-Datei ist ein XML-Dokument, das Informationen zu einer Reihe 

von SOAP-Nachrichten und zum Austausch dieser Nachrichten enthält. 

• Webdienste werden registriert, sodass diese von potenzielle Benutzern problemlos gefunden werden 

können. Die Webdienstsuche erfolgt über einen UDDI-Dienst (Universal Description Discovery 

And Integration). Ein UDDI-Verzeichniseintrag ist eine XML-Datei, die Details zu einem 

Unternehmen und den von diesem bereitgestellten Diensten enthält. Ein Eintrag im UDDI-Verzeichnis 

besteht aus drei Teilen. Die „White Pages“ beinhalten Informationen zu den Dienstanbietern: 

Name, Adresse, Kontakte usw. In den „Yellow Pages“ werden Unternehmen mithilfe von 

Standardklassifizierungen einer bestimmten Branchenkategorie zugeordnet (z.B. nach NAICS 

(North American Industry Classification System) und SIC [Standard Industrial Classification]). 

Die „Green Pages“ beinhalten detaillierte Informationen zur Webdienstschnittstelle, sodass eine 

Anwendung zur Verwendung des Webdienstes geschrieben werden kann. 

Das Webdienstemodell beruht auf dem Konzept, dass Unternehmenssysteme in unterschiedlichen 

Sprachen und mit unterschiedlichen Programmiermodellen erstellt werden, die auf unterschiedlichen 

Gerätetypen ausgeführt werden und für unterschiedliche Gerätetypen zugänglich sind. Mithilfe von 

Webdiensten lassen sich verteilte Systeme erstellen, die – unabhängig von ihrer Programmiersprache 

und Plattform – einfach und effizient über das Internet eine Verbindung miteinander herstellen und 

interagieren können. Sofern Anwendungen für die Kommunkation SOAP und XML verwenden, 

ein WSDL-Dokument mit Schnittstelleninformationen für die Anwendung und UDDI-Verzeichnisinformationen 

für die Suche nach der Anwendung bereitstellen, ist eine Interoperabilität der Anwendungen 

über alle Plattformen hinweg gewährleistet. 

Die Webdienstspezifikationen umfassen Protokolle für Sicherheit, eine zuverlässige Nachrichtenübertragung 

und die Ausführung von Transaktionen in einer Webdienstumgebung. Die Spezifikationen 

bauen auf den Hauptkomponenten der zugrunde liegenden XML- und SOAP-Standards auf. Mit den 

Active Directory-Verbunddiensten werden die folgenden zwei WS-Sicherheitsstandards implementiert: 

• WS-Verbund Die WS-Verbundspezifikation definiert ein Modell für eine schnelle gegenseitige 

Authentifizierung von Einzelpersonen und Unternehmen in einer Vielzahl an heterogenen IT- 

Infrastrukturen. Die Spezifikation definiert Mechanismen, die einen Verbund verschiedener 

Sicherheitsbereiche ermöglichen, indem vertrauenswürdige Identitäten, Attribute und Authentifizierungen 

zwischen beteiligten Webdiensten zugelassen und verarbeitet werden. Die Implementierung 

der WS-Verbundspezifikation erfolgt mithilfe der AD FS, indem die Erstellung von 

Vertrauensrichtlinien zwischen Organisationen ermöglicht wird. In den Vertrauensrichtlinien ist 

definiert, wie eine Organisation Benutzern einer anderen Organisation den Zugriff auf Ressourcen 

gewährt. Darüber hinaus können Organisationen mit den AD FS Ansprüche erstellen, die 

Benutzerkonteneigenschaften festlegen. Diese enthalten Informationen für die Authentifizierung 

und Autorisierung zwischen Organisationen. 

• Webdienst-Verbund-PRP Das Webdienst-Verbund-PRP (Passive Requestor Profile) ist eine Implementierung 

der WS-Verbundspezifikation, die ein Standardprotokoll für die Übermittlung von 

Authentifizierungsinformationen zwischen vertrauenswürdigen Partnern durch passive Anfordernde 

(wie Webbrowser) und für den Zugriff auf Ressourcen von Partnerorganisationen vorschlägt. 

Innerhalb dieses Protokolls wird vorausgesetzt, dass Webdienstanfordernde die neuen 

Sicherheitsmechanismen verstehen und mit Webdienstanbietern interagieren können. AD FS 

implementiert PRP (Passive Requestor Profile). In einer AD FS-Bereitstellung wird vorausgesetzt, 

dass zwischen Webbrowsern und verschiedenen Komponenten der AD FS-Infrastruktur eine 

Verbindung über HTTPS hergestellt werden kann.


Nach dem Verbindungsaufbau erfolgt die Authentifizierung des Benutzers in seiner Organisation 

durch den Webbrowser, über den die für die Authentifizierung erforderlichen Anmeldeinformationen 

an Webdienstanwendungen in der Partnerorganisation weitergeleitet werden. 

Weitere Informationen Weitere Informationen zu Webdienstspezifikationen finden Sie im englischsprachigen 

Artikel zu diesem Thema unter http://msdn2.microsoft.com/en-us/webservices/aa740689.aspx. Ein 

Vorteil bei der Verwendung offener Standards, z.B. Webdiensten, ist die Interoperabilität der AD FS mit 

anderen, auf denselben Standards basierenden Anwendungen. Beispiele zur Implementierung der AD FS in 

andere Identitätsverbundlösungen finden Sie auf der Website zu den Active Directory-Verbunddiensten unter 

http://technet2.microsoft.com/windowsserver2008/de/servermanager/activedirectoryfederationservices.mspx. 

AD FS-Komponenten 

Für die Implementierung der AD FS ist zunächst das Bereitstellen mehrerer Komponenten auf Computern 

erforderlich, auf denen Windows Server 2008 oder Windows Server 2003 R2 ausgeführt wird. 

Abhängig vom Bereitstellungsszenario werden nur einige oder alle dieser Komponenten benötigt. In 

Abbildung 19.1 sind verschiedene der AD FS-Komponenten dargestellt. 

Adatum 

Kontopartner 

Woodgrove Bank 

Ressourcenpartner 

Client 

Verbundvertrauensstellung 

INTERNET 

Verbundserverproxy 

Verbundserver 

Firewall 


Firewall Firewall Firewall Verbundserver 

Client 

AD FS-Web-Agent 

Abbildung 19.1 Die AD FS umfassen verschiedene Komponenten, die auf mehrere Server in unterschiedlichen 

Organisationen verteilt sein können 

Verbundvertrauensstellungen 

Eine Verbundvertrauensstellung ist die AD FS-Lösung einer Vereinbarung auf Geschäftsebene oder 

einer Partnerschaft zwischen zwei Organisationen bzw. zwischen zwei Sicherheitsbereichen einer 

Organisation. Bei Verwendung der AD FS wird eine Verbundvertrauensstellung zwischen zwei Organisationen 

erstellt, sodass Benutzer einer Organisation auf Ressourcen einer anderen Organisation 

oder Benutzer auf Ressourcen aller anderen Organisation bzw. über technische Grenzen hinweg 

zugreifen können. Die Verbundvertrauensstellung ermöglicht eine erfolgreiche Verarbeitung von 

Authentifizierungsanforderungen an den Webserver in der Ressourcenpartnerorganisation durch die 

Verbundvertrauensstellung von Benutzern in der Kontopartnerorganisation. 

Hinweis Eine Verbundvertrauensstellung wird zwischen zwei Verbundservern eingerichtet, auf denen der 

Verbunddienst ausgeführt wird. Diese Vertrauensstellungen sind unabhängig von den Vertrauensstellungen 

zwischen Windows NT- oder AD DS-Domänen (Active Directory-Domänendienste).


Kontopartner 

Ein Kontopartner ist der Organisationspartner in der Vertrauensstellung, der die in der Beziehung verwendeten 

Benutzerkonten hostet und verwaltet. Konten werden in den AD DS, im Active Directory- 

Anwendungsmodus (Active Directory Application Mode, ADAM) oder den AD LDS gespeichert. 

Der Verbundserver des Kontopartners gibt Sicherheitstoken aus, die Assertionen für Benutzer vornehmen. 

Zum Beispiel kann ein Token anzeigen, dass der Benutzer ein Abteilungsleiter ist. Diese Token 

können dann in einer Verbundvertrauensstellung verwendet werden, um auf Ressourcen zuzugreifen, 

die sich innerhalb der Organisation des Ressourcenpartners befinden. 


Ein Ressourcenpartner ist der zweite Organisationspartner in einer Verbundvertrauensstellung. Beim 

Ressourcenpartner befinden sich die Webserver, auf denen mindestens eine webbasierte Anwendung 

ausgeführt wird. Der Ressourcenpartner vertraut dem Kontopartner bei der Benutzerauthentifizierung 

und der Ausstellung von Sicherheitstoken. Folglich basieren die Autorisierungsentscheidungen der 

Ressourcenpartnerserver auf den Sicherheitstoken, die durch den Kontopartner ausgestellt werden. 

Hinweis Abbildung 19.1 zeigt einen Federated-Web-SSO-Entwurf, in dem die Kontopartner- und Ressourcenpartnerrollen 

eindeutig festgelegt sind. Bei einem Federated-Web-SSO- bzw. Web-SSO-Entwurf kann 

eine Organisation sowohl Kontopartner als auch Ressourcenpartner sein. 

Verbunddienst 

Der Verbunddienst ist einer der Rollendienste, die bei der Installation der AD FS-Serverrolle auf 

einem Windows Server 2008-Computer verfügbar sind. Der Verbunddienst ist die AD FS-Komponente, 

die als Sicherheitstokendienst fungiert. Für AD FS-Implementierungen wird mindestens ein 

installierter Verbunddienst vorausgesetzt. Bei einem Federated-Web-SSO-Entwurf wird sowohl für 

die Kontopartner- als auch für die Ressourcenpartnerorganisation ein Verbundserver benötigt. 

Wenn der Verbunddienst als Kontopartner festgelegt ist, können Benutzer auf Ressourcen der Partnerorganisationen 

zugreifen. Der Verbunddienst bietet die folgenden Funktionen: 

1. Sammeln von Benutzeranmeldeinformationen und deren Überprüfung in den AD DS oder AD 

LDS. Die Authentifizierungsanforderungen eines Benutzers werden an den Verbundserver gesendet, 

um so die Authentifizierung des Benutzerkontos gegenüber dem Verzeichnisdienst sicherzustellen. 

2. Auffüllen eines Satzes an Organisationsansprüchen basierend auf den LDAP-Attributen des 

Kontos in einem Verzeichnisdienst. Ein AD FS-Anspruch ist ein Aussage über einen Benutzer, die 

von beiden Partnern in einem AD FS-Verbundszenario verstanden wird. Wenn die Verbundvertrauensstellung 

beispielsweise die Gruppenmitgliedschaft des Benutzers nutzt, um den Zugriff auf 

Anwendungen zu ermöglichen, fügt der Verbundserver das Gruppenmitgliedschaftsattribut zum 

Sicherheitstoken hinzu. 

3. Zuordnen von Organisationsansprüchen zu einem vereinbarten Satz an ausgehenden Verbundansprüchen 

für den Ressourcenpartner. Bei der Konfiguration der Verbundvertrauensstellung vereinbaren 

Organisationen, wie Attribute in der Kontoorganisation den Informationen zugeordnet 

werden, die zur Entscheidungsfindung bezüglich des Ressourcenzugriffs in der Ressourcenorganisation 

verwendet werden können. Beispielsweise können Mitgliedern einer Gruppe von Abteilungsleitern 

im Kontopartner mehr Zugriffsberechtigungen für Anwendungen zugeteilt werden als 

Mitgliedern anderer Gruppen. Diese Informationen werden dem Sicherheitstoken durch den Verbundserver 

hinzugefügt.


4. Zusammenfassen der Ansprüche in einem digital signierten Sicherheitstoken. Das Sicherheitstoken 

wird dem Webclient zur Verfügung gestellt, der den Zugriff auf die Anwendung in der 

Ressourcenorganisation anfordert. 

Wird ein Verbunddienst als Ressourcenpartner konfiguriert, ermöglicht dieser den Zugriff auf die 

Webanwendung. Der Verbunddienst des Ressourcenpartners führt die folgenden Aufgaben aus: 

1. Überprüfen von Sicherheitstoken. Wenn der Benutzer ein Sicherheitstoken vom Verbundserver 

des Kontopartners bereitstellt, wird durch eine Überprüfung der Anspruchsinformationen des 

Benutzers durch den Ressourcenverbunddienst sichergestellt, dass diese von einem vertrauenswürdigen 

Kontopartner stammen. 

2. Zuordnen eingehender Ansprüche in entsprechende Ansprüche der Ressourcenorganisation. Ein 

eingehender Anspruch kann zum Beispiel darauf hinweisen, dass der Benutzer zur Gruppe der leitenden 

Vertriebsangestellten gehört. In diesem Fall ordnet der Ressourcenverbunddienst diese 

Information einem Anspruch zu, der die Webanwendung veranlasst, den für leitende Vertriebsangestellte 

erforderlichen Zugriff zu gewähren. 

3. Zusammenfassen der Organisationsansprüche in einem neuen, digital signierten Sicherheitstoken, 

das an den Webclient zurückgegeben wird. Diese Token werden anschließend vom Webclient an die 

Webanwendung übertragen. 

Verbundansprüche 

Verbundansprüche werden durch den Verbunddienst erstellt. Hierbei handelt es sich um Assertionen 

für einen Benutzer, die auf Informationen aus einem LDAP-Verzeichnisspeicher basieren. Die Ansprüche 

werden in Attributen eines bestimmten Benutzers gespeichert und können Informationen zu Gruppen, 

in denen der Benutzer Mitglied ist, oder andere attributbezogene Informationen enthalten, z.B. 

den Benutzertitel. Diese Ansprüche werden vom Ressourcenverbunddienst zum Treffen von Autorisierungsentscheidungen 

verwendet. 

Verbunddienstproxy 

Ein Verbunddienstproxy ist ein weiterer Rollendienst, der separat auf einem Windows Server 2008- 

Computer installiert werden kann. Der Server, der den Verbunddienstproxy-Dienst hostet, wird auch 

als Verbundserverproxy bezeichnet. In der Regel wird der Verbundserverproxy in einem Umkreisnetzwerk 

bereitgestellt, um so einen Verbundserver des Kontopartners, des Ressourcenpartners oder beide 

zu schützen. Durch die Implementierung eines Verbundserverproxys kann die Offenlegung der Verbundserver 

im Internet vermieden werden. 

Die Kommunikation zwischen Verbundserverproxy und einem geschützten Verbunddienst erfolgt im 

Namen des Clients. Wenn ein Kontopartner durch den Verbundserverproxy geschützt wird, sammelt 

dieser zunächst Anmeldeinformationen von Benutzern des Browserclients und leitet dann die Anforderung 

an den Verbunddienst weiter. Wird ein Ressourcenpartner durch den Verbundserverproxy 

geschützt, leitet dieser Anforderungen von und für webbasierte Anwendungen an den Verbunddienst 

weiter. 

AD FS-Web-Agents 

AD FS-fähige Webserver verbrauchen Sicherheitstoken und lassen den Benutzerzugriff auf eine 

Webanwendung entweder zu oder verweigern diesen. Zu diesem Zweck benötigt der AD FS-fähige 

Webserver eine Beziehung mit einem Ressourcenverbunddienst, damit er den Benutzer bei Bedarf an 

den Verbunddienst weiterleiten kann. Der AD FS-Web-Agent ermöglicht dabei die Verbindung zwischen 

der Anwendung und dem Verbunddienst.


Der AD FS-Web-Agent wird als ISAPI-Erweiterung mit IIS 7.0 (Internet Information Services, Internetinformationsdienste) 

implementiert. Der AD FS-Web-Agent unterstützt zwei unterschiedliche 

Anwendungstypen: 

• Ansprüche unterstützende Anwendungen Anwendungen, die speziell für das Abfragen von 

Ansprüchen geschrieben oder geändert wurden, werden als Ansprüche unterstützende Anwendungen 

bezeichnet. Bei Ansprüchen unterstützenden Anwendungen kann der AD FS-Web-Agent 

Ansprüche einer Anwendung direkt zur Verfügung stellen, die für deren Verwendung programmiert 

ist (typischerweise Autorisierungsinformationen zu einem Benutzer, der einen bestimmten 

Anspruch stellt). 

• Windows-Token-basierte Anwendungen Ältere Anwendung, auch Legacyanwendungen genannt, 

sind nicht für die Verarbeitung von Ansprüchen programmiert. Autorisierungsentscheidungen dieser 

Anwendungen basieren auf Sicherheitskennungen (Security Identifiers, SIDs) des Sicherheitsprinzipals 

und Zugriffssteuerungslisten (Access Control List, ACL). In solchen Fällen kann die 

Anwendung so konfiguriert werden, dass ein Windows NT-Sicherheitstoken für den Benutzer 

erstellt wird, der eine Anforderung sendet, die mit einem Benutzer des Ressourcenpartner-Verzeichnisdiensts 

übereinstimmt. Um den Zugriff auf die Anwendung einzuschränken, müssen 

anschließend die Zugriffssteuerungslisten der Ressource konfiguriert werden, auf die zur Verwendung 

des Windows NT-Sicherheitstokens zugegriffen wird. 

Server, auf denen einer der AD FS-Web-Agents installiert ist, werden auch als AD FS-fähige Webserver 

bezeichnet. 

AD FS-Bereitstellungsentwürfe 

Active Directory-Verbunddienste lassen sich in vielen unterschiedlichen Situationen bereitstellen und 

können verwendet werden, um den Zugriff auf eine Vielzahl unterschiedlicher Anwendungen an verschiedenen 

Speicherorten und auf verschiedenen Serverplattformen zu ermöglichen. Die verschiedenen 

AD FS-Bereitstellungen können jedoch grundsätzlich in die folgenden Szenarien unterteilt 

werden: 

• Business-to-Business (B2B) 

• Business-to-Employee (B2E) 

• Business-to-Consumer (B2C) 

Diese Geschäftsszenarien werden bei der Installation oder Konfiguration der AD FS-Komponenten 

nicht als Konfigurationsoptionen angezeigt. Tatsächlich bieten die AD FS mehr als eine Option für 

die Implementierung der Geschäftsszenarien. Es gibt drei AD FS-Bereitstellungsentwürfe: 

• Web-SSO-Entwurf In einem Web-SSO-Szenario wird mindestens eine webbasierte Anwendung 

von einer Organisation bereitgestellt, auf die Benutzer innerhalb und außerhalb der Organisation 

zugreifen müssen. Die Implementierung der AD FS ermöglicht den Benutzerzugriff auf diese 

Anwendungen nach einmaliger Authentifizierung. Die Web-SSO-Bereitstellungsoption eignet 

sich sowohl für B2E- als auch für B2C-Szenarien. 

• Federated-Web-SSO-Entwurf Bei einer Federated-Web-SSO-Lösung gewähren zwei Organisationen 

oder zwei Sicherheitsbereiche innerhalb einer Organisation den Benutzern einer anderen 

Organisation Zugriff auf Anwendungen in der Organisation. Die Bereitstellungsoption Federated- 

Web-SSO eignet sich für B2B-Szenarien.


• Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung Bei einer Federated-Web-SSO- 

Lösung werden in einer Organisation zur Benutzerkontenverwaltung mehrere Gesamtstrukturen und 

zur Bereitstellung der SSO-Funktion die AD FS verwendet. Diese Bereitstellungsoption wird hauptsächlich 

für B2E-Szenarien verwendet. 

Beim Hinzufügen eines Konto- und Ressourcenpartners zu einem Verbunddienst können Sie wählen, 

ob die Bereitstellungsoption Federated-Web-SSO oder Federated-Web-SSO mit Gesamtstruktur-Vertrauensstellung 

implementiert werden soll. Die Web-SSO-Option ist in einer AD FS-Bereitstellung 

impliziert. 

Web-SSO-Entwurf 

Beim Web-SSO-Entwurf müssen sich Benutzer für den Zugriff auf mehrere AD FS-geschützte 

Anwendungen nur einmal authentifizieren. Zu den Benutzern können in diesem Entwurf externe Mitarbeiter 

bzw. Kunden oder interne Mitarbeiter gehören. Da es beim Web-SSO-Entwurf keine Partner 

gibt, besteht auch keine Verbundvertrauensstellung. Normalerweise wird dieser Entwurf verwendet, 

um einem Mitarbeiter oder Kunden den Zugriff auf AD FS-geschützte Anwendungen über das Internet 

zu gewähren. Zudem kann eine Organisation, die typischerweise eine AD FS-geschützte Anwendung 

in einem Umkreisnetzwerk ausführt, einen separaten Speicher für Kundenkonten im Umkreisnetzwerk 

einrichten, durch den die Isolierung von Kundenkonten und Mitarbeiterkonten vereinfacht 

wird. Zur Verwaltung der lokalen Kundenkonten im Umkreisnetzwerk können entweder die AD DS 

oder AD LDS als Kontospeicher verwendet werden. 

Beim Einrichten des Web-SSO-Entwurfs muss mindestens ein Verbundserver und ein Webserver zur 

Ausführung des AD FS-Web-Agents installiert werden. Da für die Rolle des Kontopartners kein zweiter 

Verbundserver vorhanden ist, wird in den AD FS auch kein Kontopartner hinzugefügt. Stattdessen 

wird dem einzigen Verbundserver ein lokaler Kontospeicher hinzugefügt, sodass dieser eine Anwendung 

nicht nur schützt, sondern zudem für den Zugriff auf diese Anwendung Benutzerauthentifizierungen 

anfordert und Sicherheitstoken ausstellt. 

Als Kontospeicher kann das interne oder das externe Verzeichnis ausgewählt werden. Bei einer B2E- 

Bereitstellung wird häufig ein interner Verzeichnisdienst (z.B. ein AD DS) verwendet. Wenn Sie 

einen Web-SSO-Entwurf implementieren, werden Sie in der Regel die AD LDS als Kontospeicher 

verwenden und den AD LDS-Server im Umkreisnetzwerk platzieren. Selbst die Bereitstellung beider 

Optionen auf einem Verbundserver ist möglich. Befinden sich Mitarbeiterkonten in den AD DS und 

externe Konten in den AD LDS, besteht bei der AD FS-Konfiguration die Möglichkeit, zwei Kontospeicher 

hinzuzufügen. Diese werden dann in der festgelegten Reihenfolge nach dem Benutzerkonto 

durchsucht. 

Abbildung 19.2 zeigt den Datenfluss in einem Web-SSO-Entwurf. In diesem Beispiel dienen die von 

der Organisation bereitgestellten AD LDS als Kontospeicher. Die Lösung verwendet eine Kombination 

aus einem Verbundserver und einem AD LDS-Server, die im Unternehmensnetzwerk gehostet 

werden, sowie einem Verbundserverproxy und einem Webserver im Umkreisnetzwerk. 

Der Ressourcenzugriff in dieser Bereitstellung kann anhand der folgenden Schritte beschrieben 

werden: 

1. Ein Kunde der Woodgrove Bank sendet über einen Webbrowser eine HTTPS-Anforderung für den 

Zugriff auf eine Anwendung, die auf dem Webserver im Umkreisnetzwerk der Woodgrove Bank 

ausgeführt wird.


2. Der AD FS-Web-Agent fängt die Anforderung ab und prüft, ob der Client über ein AD FS- 

Authentifizierungscookie verfügt, das den Zugriff auf die Anwendung ermöglicht. Da der Client 

nicht über dieses Cookie verfügt, wird die Clientanforderung abgelehnt und der Client wird an 

den Verbundserverproxy umgeleitet. 

3. Der Client sendet eine HTTPS-Anforderung an den Verbundserverproxy. Daraufhin wird der 

Client an die Authentifizierungsseite des Verbundserverproxys umgeleitet und zur Eingabe der 

Anmeldeinformationen aufgefordert. 

4. Der Verbundserverproxy akzeptiert die Anmeldeinformationen und die Anforderung wird an den 

Ressourcenverbunddienst übergeben. 

5. Der Verbundserver der Ressourcenorganisation wechselt direkt zu einem lokalen Kontospeicher 

(AD LDS), um die Authentifizierung des Benutzers anzufordern. 

6. Der Benutzer wird, wenn möglich, durch die AD LDS authentifiziert. Durch den Verbundserver 

der Ressourcenorganisation werden von den AD LDS Attribute über LDAP abgerufen sowie die 

Sicherheitstoken und die AD FS-Authentifizierungstoken für die AD FS-fähige Webserveranwendung 

ausgestellt. 

7. Die Authentifizierungsinformationen und andere Informationen werden in einem Anspruch 

zusammengefasst, der zusammen mit einer Umleitungsmeldung über den Proxy an den Client 

zurückgegeben wird. Diese Meldung weist den Client an, das Sicherheitstoken an die ursprüngliche 

URL zu übergeben. 

8. Der AD FS-Web-Agent empfängt die Anforderung, überprüft die signierten Token und stellt (bei 

erfolgreicher Prüfung) ein weiteres AD FS-Authentifizierungscookie aus. Anschließend leitet er 

die Anforderung zur Verarbeitung durch den Webdienst weiter, der basierend auf den Ansprüchen 

den Zugriff auf die Anwendung gewährt. 



7 

7 

6 

Client 

INTERNET 

3 

4 

Ressourcenverbundserver 

5 

2 

AD LDS-Server 

8 

1 


Webserver 

Kundenzugriff auf Webanwendungen über die Web-SSO-Entwurfsoption 

Federated-Web-SSO-Entwurf 

Durch die Verwendung des Federated-Web-SSO-Entwurfs in den Active Directory-Verbunddiensten 

(AD FS) wird eine sichere Kommunikation zwischen Organisationen ermöglicht. Dieser Entwurf wird


normalerweise für Verbundvertrauensstellungen zwischen zwei Organisationen gewählt, um Benutzern 

in der einen Organisation (der Kontopartnerorganisation) den Zugriff auf durch AD FS geschützte 

Webanwendungen in der anderen Organisation (der Ressourcenpartnerorganisation) zu gewähren. 

Bei einem typischen Federated-Web-SSO-Entwurf stellt eine Organisation eine Anwendung bereit, 

auf die Benutzer in der anderen Organisation zugreifen müssen. In einer Verbundvertrauensstellung 

wird diese Organisation als Ressourcenpartner bezeichnet. Der Ressourcenpartner ist für den Schutz 

der Anwendung verantwortlich. Hierzu muss die Organisation sicherstellen, dass nur autorisierte 

Benutzer auf die Anwendung zugreifen können. Zudem hat die Ressourcenorganisation die Möglichkeit, 

verschiedene Zugriffsebenen zu konfigurieren, sodass bestimmte Benutzer auf mehr Anwendungskomponenten 

und Aktionen Zugriff haben als andere Benutzer. Der Ressourcenpartner in 

Abbildung 19.3 ist die Woodgrove Bank. 

Die Benutzerkonten, für die der Zugriff auf die Anwendung in der Ressourcenpartnerorganisation 

erforderlich ist, werden beim Federated-Web-SSO-Entwurf von der anderen Organisation gehostet. 

Diese wird auch als Kontopartner bezeichnet. Der Kontopartner möchte die vollständige Steuerung 

der Benutzer- und Gruppenkonten in seiner Organisation behalten sowie die für andere Organisationen 

verfügbaren Informationen zu Benutzern einschränken. In Abbildung 19.3 ist die Organisation 

Adatum der Kontopartner. 

Bei der Implementierung eines Federated-Web-SSO-Entwurfs müssen beide Organisationen mindestens 

einen Verbundserver und die Ressourcenorganisation zusätzlich einen Webserver konfigurieren, 

auf dem die Anwendung und der AD FS-Web-Agent ausgeführt wird. Darüber hinaus können beide 

Organisationen einen Verbundserverproxy implementieren. 

Hinweis Abbildung 19.3 zeigt die im Federated-Web-SSO-Entwurf enthaltenen AD FS-Komponenten. Zur 

Vereinfachung der Grafik werden keine Verbunddienstproxys dargestellt. Stellt die Organisation keinen Verbundserverproxy 

bereit, wird für die Kommunikation zwischen Client und Verbundserver der Verbundserverproxy 

verwendet. 

Adatum 

Kontopartner 




7 

AD DS- 


4 

10 


6 

3 

9 

Kontoverbundserver 

INTERNET 

5 

2 

Webserver 


Entwurf 

8 

1 11 

Client 

Gegenseitiger Zugriff auf Webanwendungen von Organisationen durch den Federated-Web-SSO-


Der Datenfluss beim Federated-Web-SSO-Entwurf wird in den folgenden Schritten beschrieben: 

1. Ein Benutzer der Organisation Adatum sendet über einen Webbrowser eine HTTPS-Anforderung 

für den Zugriff auf eine Anwendung, die auf dem Webserver der Woodgrove Bank ausgeführt 

wird. 

2. Der auf dem Webserver installierte AD FS-Web-Agent fängt die Anforderung ab und prüft, ob der 

Client ein Cookie zur Legitimierung der Anforderung bereitgestellt hat. Erst wenn der Benutzer 

bereits authentifiziert wurde, verfügt der Client über dieses Cookie. In diesem Fall verwendet der 

AD FS-Web-Agent eine HTTP 302-Umleitungsmeldung, um den Client an den Ressourcenverbundserver 

bei der Woodgrove Bank umzuleiten. Da der AD FS-Web-Agent nicht über die 

Vertrauensstellung informiert ist, muss dieser die Clientanforderung an den Verbundserver weiterleiten. 

3. Der Client sendet eine HTTPS-Anforderung an den Ressourcenverbundserver. Der Ressourcenverbunddienst 

muss nun den Speicherort des Kontos ermitteln. Dieser Vorgang wird alsBasisbereichsermittlung 

bezeichnet. Basierend auf der Konfiguration der Verbundvertrauensstellung, 

die Informationen wie den UPN oder die E-Mail-Adresse umfasst, ermittelt der Ressourcenverbundserver 

Adatum als Basisbereich. 

4. Der Client wird erneut umgeleitet, diesmal jedoch zum Kontoverbundserver in der Organisation 

Adatum. 

5. Der Client sendet eine HTTPS-Anforderung an den Kontoverbunddienst. 

6. Die Benutzerauthentifizierung erfolgt über die integrierte Windows-Authentifizierung oder durch 

Angabe der Anmeldeinformationen bei Aufforderung durch den Verbundserver. 

7. Die AD DS authentifizieren den Benutzer und senden die Erfolgsmeldung zusammen mit den im 

Verzeichnis gespeicherten Benutzerinformationen (Attribute, Gruppenmitgliedschaften usw.), die 

zum Erstellen von Benutzeransprüchen verwendet werden, zurück an den Verbundserver. 

8. Die Anspruchsdaten werden in einem digital signierten Sicherheitstoken zusammengefasst, dem 

Client als Authentifizierungscookie übergeben und anschließend erneut zurück an den Ressourcenverbunddienst 

gesendet. 

9. Der Client sendet das Sicherheitstoken an den Ressourcenverbunddienst, der prüft, ob das Sicherheitstoken 

von einem vertrauenswürdigen Partner stammt. Ist dies der Fall, stellt der Verbundserver 

ein Basisbereichscookie aus, sodass künftige Anforderungen die Basisbereichsermittlung bis 

zum Ablauf der Gültigkeit des Cookies nicht erneut durchlaufen müssen. 

10. War der vorherige Schritt erfolgreich, erstellt und signiert der Verbundserver eine neues, eigenes 

Token. Dieses wird als Ressourcenpartnercookie zusammen mit einer abschließenden Umleitung 

zur ursprünglich angeforderten Quell-URL an den Client gesendet. 

11. Der Web-Agent empfängt die Anforderung, überprüft die signierten Token und stellt (bei erfolgreicher 

Überprüfung) ein weiteres Cookie aus. Anschließend leitet er die Anforderung zur Verarbeitung 

durch den Webdienst weiter. 

Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung 

Der Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung kombiniert zwei Active 

Directory-Gesamtstrukturen in einer Organisation. Dieser Entwurf wird in der Regel verwendet, um 

Mitarbeitern im Unternehmensnetzwerk und Remotemitarbeitern einen Verbundzugriff auf AD FSgeschützte 

Anwendungen im Umkreisnetzwerk zu gewähren. Hierzu werden für jeden Mitarbeiter die 

standardmäßigen Unternehmensdomänen-Anmeldeinformationen verwendet.


In einem Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung stellt die Organisation 

zwei AD DS-Gesamtstrukturen bereit – eine im internen Netzwerk und eine im Umkreisnetzwerk. 

Zwischen der Gesamtstruktur des Umkreisnetzwerks und der Unternehmensgesamtstruktur wird eine 

einseitige Gesamtstrukturvertrauensstellung konfiguriert. So können Mitarbeiterbenutzerkonten in der 

internen Gesamtstruktur für den Zugriff auf die Anwendung verwendet werden, die auf einem Server 

in der Gesamtstruktur des Umkreisnetzwerks installiert ist. Dieses Szenario wird in Zusammenhang 

mit Windows NT-Token-basierten Anwendungen am häufigsten eingesetzt. Eine Windows NT-Tokenbasierte 

Anwendung setzt voraus, dass ein Sicherheitsprinzipal vorhanden ist, dem das AD FS-Token 

zugeordnet werden kann. Das Konto des Sicherheitsprinzipals kann bei Bereitstellung von zwei 

Gesamtstrukturen in der internen Gesamtstruktur konfiguriert werden. 

Hinweis Wenn zwischen der internen Gesamstruktur und der Gesamtstruktur des Umkreisnetzwerks 

keine Vertrauensstellung besteht und es sich bei der Anwendung im Umkreisnetzwerk um eine Windows NT- 

Token-basierte Anwendung handelt, können in der Gesamtstruktur des Umkreisnetzwerks Schattenkonten 

oder -gruppen erstellt werden. Diese Konten können Benutzer anschließend für den Zugriff auf die Anwendung 

nutzen. 

Der Zugriff auf AD FS-geschützte Ressourcen wird durch den Federated-Web-SSO-Entwurf mit 

Gesamtstrukturvertrauensstellung sowohl für interne als auch externe Mitarbeiter ermöglicht. 

Abbildung 19.4 zeigt den Datenfluss in einem Szenario, bei dem sich Benutzer außerhalb des Unternehmens 

befinden. 


8 

8 

5 

4 10 

3 9 

5 

Konto- 



Client 

INTERNET 


Kontoverbundserver 

6 7 

1 

2 

Unidirektionale 


AD DS- 


AD DS- 


11 

Webserver 

Abbildung 19.4 Zugriff auf Webanwendungen in einer Gesamtstruktur des Umkreisnetzwerks durch den Federated- 

Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung


Die folgenden Schritte beschreiben die Vorgänge: 

1. Ein Mitarbeiter der Woodgrove Bank befindet sich außerhalb des Büros. Er sendet über einen 

Webbrowser eine HTTPS-Anforderung für den Zugriff auf eine Anwendung, die auf dem Webserver 

im Umkreisnetzwerk ausgeführt wird. 

2. Der AD FS-Web-Agent fängt die Anforderung ab. Da der Client nicht über das erforderliche Cookie 

verfügt, leitet der AD FS-Web-Agent den Client an den Ressourcenverbundserver um. 

3. Der Client sendet eine HTTPS-Anforderung an den Ressourcenverbundserver. 

4. Der Ressourcenverbundserver leitet den Client an den Konto-Verbundserverproxy um. 

5. Der Konto-Verbundserverproxy fordert die Benutzeranmeldeinformationen an und übergibt die 

Anforderung anschließend an den Kontoverbundserver. 

6. Der Kontoverbundserver leitet die Authentifizierungsanforderung an den AD DS-Domänencontroller 

weiter. 

7. Die AD DS authentifizieren den Benutzer und senden die Erfolgsmeldung zusammen mit weiteren 

im Verzeichnis gespeicherten Benutzerinformationen (Attribute, Gruppenmitgliedschaften 

usw.), die zum Erstellen von Benutzeransprüchen verwendet werden, zurück an den Kontoverbundserver. 

8. Bei einer erfolgreichen Authentifizierung werden die Authentifizierungsinformationen und weitere 

Informationen in einem Anspruch zusammengefasst, der zusammen mit einer Umleitungsmeldung 

über den Proxy an den Client zurückgegeben wird. Diese Meldung weist den Client an, das 

Sicherheitstoken an den Ressourcenverbunddienst zu übergeben. 

9. Der Webbrowser übergibt das Sicherheitstoken an den Ressourcenverbundserver. Dieser erstellt 

das Sicherheitstoken und AD FS-Authentifizierungstoken für die Webanwendung. 

10. Der Ressourcenverbundserver stellt dem Webbrowser die Token zur Verfügung und leitet den 

Client zur Verbindung mit der AD FS-Webanwendung um. 

11. Der Web-Agent erhält die Anforderung und das AD FS-Authentifizierungscookie. Da es sich bei 

der Anwendung um eine Windows NT-Token-basierte und nicht um eine Ansprüche unterstützende 

Anwendung handelt, muss die Anwendung ein Windows NT-Identitätstoken aus dem 

Sicherheitstoken erstellen. Dieses Windows NT-Token wird anschließend von der Anwendung 

verwendet, um die Identität des Benutzerkontos anzunehmen und den entsprechenden Zugriff zu 

ermöglichen. 

Die Vorgehensweise bei einem Benutzer innerhalb der Organisation ist dieselbe, abgesehen davon, 

dass der Konto-Verbundserverproxy nicht für die Benutzerauthentifizierung verwendet wird. Der 

Webbrowser kann direkt mit dem Konto-Verbundserver kommunizieren, da sich der Benutzer bereits 

im internen Netzwerk befindet. 

Implementieren der AD FS 

Nach Auswahl eines AD FS-Entwurfs werden die Active Directory-Verbunddienste durch die Installation 

und Konfiguration der AD FS-Komponenten auf Windows Server 2008-Computern implementiert. 

In diesem Abschnitt werden die Bereitstellung und die Konfiguration von Verbundservern, 

Verbundserverproxys und AD FS-fähigen Webservern beschrieben. Darüber hinaus werden die verschiedenen 

AD FS-Anwendungstypen (Ansprüche unterstützende und Windows NT-Token-basierte 

Anwendungen) sowie deren Implementierungen erläutert.

AD FS-Bereitstellungsanforderungen 

Implementieren der AD FS 745 

Hinweis Dieser Abschnitt beschreibt die Bereitstellung von AD FS im Federated-Web-SSO-Entwurf. Bei 

dieser Bereitstellungsoption handelt es sich um das komplizierteste Szenario, dass die Höchstzahl an AD 

FS-Komponenten umfasst. Der AD FS-Entwurf gibt vor, welche Komponenten tatsächlich erforderlich sind 

und wie diese konfiguriert werden. 

Damit die AD FS bereitgestellt werden können, muss zunächst sichergestellt werden, dass die AD FS- 

Anforderungen von der Netzwerkinfrastruktur des Unternehmens unterstützt werden. 

Netzwerkanforderungen 

Zur Bereitstellung von AD FS müssen die folgenden Netzwerkanforderungen erfüllt sein: 

• TCP/IP-Konnektivität Für die Verwendung der AD FS muss zwischen dem Client, den AD DSoder 

AD LDS-Servern und den Computern, die als Host für den Verbunddienst, den Verbunddienstproxy 

und die AD FS-Web-Agents fungieren, TCP/IP-Netzwerkkonnektivität gewährleistet 

sein. Da für alle Clientanforderungen HTTPS verwendet wird, muss zwischen dem Client und 

allen Servern, auf denen vom Client benötigte AD FS-Rollen ausgeführt werden, eine HTTPS- 

Verbindung bestehen. 

• DNS-Anforderungen Für die Verwendung der AD FS ist es erforderlich, dass die Clientcomputer 

die Namen aller Server auflösen können, auf denen AD FS-Komponenten ausgeführt werden. Die 

ordnungsgemäße Funktionsweise der Namensauflösung kann folgendermaßen überprüft werden: 

Die Auflösung der DNS-Namen für die Webserver, auf denen der AD FS-Web-Agent ausgeführt 

wird, muss von Clientcomputern über das Internet oder von Kontoorganisationen aus 

möglich sein. Dabei stellen die Clients eine Verbindung mit diesen Servern her, um mit der 

AD FS-Authentifizierung und Autorisierung zu beginnen und nach erfolgreicher Authentifizierung 

auf die Anwendung zuzugreifen. Zudem müssen Clientcomputer DNS-Namen für 

Verbundserverproxys bzw. Verbundserver auflösen können. 

Wenn der AD FS-Zugriff für interne Benutzer aktiviert wird und alle AD FS-Server im 

Umkreisnetzwerk bereitgestellt werden, muss der Clientcomputer im internen Netzwerk in der 

Lage sein, die IP-Adressen der AD FS-Server aufzulösen. 

Die Namen von Verbundservern müssen von Verbundserverproxys aufgelöst werden können, 

damit Clientanforderungen weitergeleitet werden. Diese Namensauflösung kann auf zwei 

Arten erfolgen: Entweder durch Verwendung der Hostdateien auf den Verbundserverproxys 

oder durch Implementierung von DNS im Umkreisnetzwerk mit geeigneten Zonen. 

Clientwebbrowser-Anforderungen 

Nahezu alle aktuellen JScript-fähigen Webbrowser können als AD FS-Client eingesetzt werden. Zu 

den von Microsoft getesteten Browsern gehören Internet Explorer 5 und neue Browser wie Internet 

Explorer 7, Mozilla Firefox und Safari (Apple Macintosh). JScript muss im Webbrowser aktiviert 

werden. 

Zur Bereitstellung der SSO-Funktionalität müssen die von den AD FS erstellten Authentifizierungscookies 

auf Clientcomputern gespeichert werden. Daher muss der Clientbrowser für die Zulassung 

von Cookies konfiguriert sein. Bei Authentifizierungscookies handelt es sich immer um HTTPS- 

Sitzungscookies (Secure Hypertext Transfer Protocol), die für den Quellserver geschrieben wurden. 

Wenn die Clientbrowserkonfiguration diese Cookies nicht zulässt, können die AD FS nicht ordnungsgemäß 

ausgeführt werden.


Die AD FS verwenden drei Cookietypen, die Authentifizierungs- und Autorisierungsaufgaben während 

einer Sitzung unterstützen: 

• Authentifizierungscookie Das Authentifizierungscookie ermöglicht die einmalige Anmeldung 

(Single Sign-On, SSO) an Ressourcen, die sich beim Ressourcenpartner befinden. Sowohl der 

Verbunddienst als auch der AD FS-Web-Agent können Authentifizierungscookies ausstellen. Werden 

diese durch den Kontoverbunddienst ausgestellt, enthält das Sicherheitstoken eines Cookies 

die Organisationsansprüche für den Client. Die Organisationsansprüche können ausgehenden 

Ansprüchen für eine bestimmte Ressource zugeordnet werden. 

Nachdem der Client einmal vom Ressourcenverbunddienst überprüft wurde, wird das Authentifizierungscookie 

auf den Client geschrieben. Dieses Cookie wird dann für weitere Authentifizierungen 

verwendet, sodass das erneute Sammeln von Clientanmeldeinformationen nicht mehr 

erforderlich ist. 

Vom Kontoverbundserver ausgestellte Cookies können vom AD FS-Web-Agent authentifiziert 

und verwendet werden. Sobald der Client mit dem Webserver verbunden wird, empfängt der Webserver 

ein Cookie. Anschließend kann der AD FS-Web-Agent dieses Cookie authentifizieren und 

die darin enthaltenen Ansprüche verwenden. Das Authentifizierungscookie ist immer ein 

signiertes, jedoch nicht verschlüsseltes Sitzungscookie. Daher ist die Verwendung von TLS 

(Transport Layer Security) und SSL (Secure Sockets Layer) in AD FS obligatorisch. 

• Kontopartnercookie Das Kontopartnercookie unterstützt SSO. Sobald der Ressourcenpartner die 

Gültigkeit des vom Kontopartner bereitgestellten Authentifizierungscookies bestätigt, wird das 

Kontopartnercookie auf den Client geschrieben. Die weitere Authentifizierung erfolgt nicht durch 

wiederholte Erfassung der Mitgliedschaftsinformationen des Kontopartners, sondern anhand des 

Cookies. Das Kontopartnercookie wird als Ergebnis der Kontopartnerermittlung gesetzt. Es handelt 

sich hierbei um ein langlebiges dauerhaftes Cookie, das weder signiert noch verschlüsselt ist. 

• Abmeldecookie Das Abmeldecookie ermöglicht die Abmeldung. Jedes Mal, wenn der Verbunddienst 

ein Token ausstellt, wird der Ressourcenpartner oder Zielserver des Tokens dem Abmeldecookie 

hinzugefügt. Bei Erhalt einer Abmeldeanforderung sendet der Verbundserver oder 

Verbundserverproxy Anforderungen an jeden der Zielserver des Tokens, um sie aufzufordern, 

Authentifizierungsartefakte wie z.B. vom Ressourcenpartner oder Webserver in den Client 

geschriebene zwischengespeicherte Cookies zu bereinigen. Im Fall eines Ressourcenpartners wird 

eine Bereinigungsanforderung an alle Anwendungswebserver gesendet, die der Client verwendet 

hat. Das Abmeldecookie ist immer ein Sitzungscookie, das weder signiert noch verschlüsselt ist. 

Kontospeicheranforderungen 

Für die Benutzerauthentifizierung und das Extrahieren von Sicherheitsansprüchen für diese Benutzer 

benötigen die AD FS mindestens einen Kontospeicher. AD FS unterstützen zwei Kontospeichertypen: 

AD DS- und AD LDS-Kontospeicher. 

AD DS AD DS-Kontospeicher können von Kontopartnerorganisationen verwendet werden, um lokal 

gespeicherten Identitäten den Zugriff auf Verbundanwendungen (sowohl Ansprüche unterstützende 

als auch Windows NT-Token-basierte Anwendungen) in einem Ressourcenpartner zu gewähren. Hingegen 

nutzen Ressourcenpartnerorganisationen die AD DS, um Verbundbenutzern die Zugriffsberechtigungen 

für Windows NT-Token-basierte Anwendungen zuzuweisen. In diesem Szenario muss jeder 

Verbundbenutzer einem Ressourcenkonto oder einer Ressourcengruppe in der lokalen AD DS-Domäne 

zugeordnet werden. Zu den Active Directory-Verbunddiensten kann nur ein AD DS-Kontospeicher 

hinzugefügt werden.


Damit die AD FS ordnungsgemäß funktionieren, müssen die Active Directory-Domänencontroller in 

der Kontopartner- oder der Ressourcenpartnerorganisation Windows 2000 Server SP4 (einschließlich 

wichtiger Updates), Windows Server 2003 SP1, Windows Server 2003 R2 oder Windows Server 2008 

ausführen. 

AD LDS AD LDS oder ADAM-Kontospeicher können ebenfalls verwendet werden, um lokal gespeicherten 

Identitäten den Zugriff auf Verbundanwendungen (sowohl Ansprüche unterstützende als auch 

Windows NT-Token-basierte Anwendungen) in einem Ressourcenpartner zu gewähren. Ressourcenpartnerorganisationen 

haben hingegen nicht die Möglichkeit, mithilfe der AD LDS Verbundbenutzer 

lokalen Ressourcenkonten oder Ressourcengruppen zuzuordnen. 

Zu den Active Directory-Verbunddiensten können mehrere AD LDS-Kontospeicher hinzugefügt werden. 

Zum Authentifizieren eines Benutzers verwendet ein Verbundserver den ersten Kontospeicher, 

der für die Anforderung der Benutzerauthentifizierung konfiguriert wurde. Falls das Benutzerkonto 

nicht im Speicher enthalten ist, fragt der Verbundserver die anderen Speicher in der Reihenfolge ab, in 

der diese konfiguriert wurden. 

Auf den Computern, die als Host für den ADAM-Kontospeicher dienen, muss Windows 2000 

Server mit Service Pack 4 (SP4) oder höher, Windows Server 2003 mit Service Pack 1 (SP1) oder 

Windows Server 2003 R2 ausgeführt werden. Die Installation der AD LDS ist nur auf einem Windows 

Server 2008-Computer möglich. 

Webserveranforderungen 

IIS ist eine verbindliche Anforderung für alle AD FS-Serverkomponenten. Ist die benötigte Serverrolle 

Webserver (IIS) nicht installiert, müssen zunächst die erforderlichen IIS-Komponenten hinzugefügt 

werden, damit die AD FS-Serverrollendienste installiert werden können. 

Hinweis Zur Verwendung der Active Directory-Verbunddienste müssen .NET Framework 2.0 und 

ASP.NET auf dem Computer installiert sein. .NET Framework 2.0 ist standardmäßig auf Windows Server 

2008-Computern installiert, ASP.NET wird zusammen mit der Serverrolle Webserver (IIS) installiert. 

Anforderungen an die Public Key-Infrastruktur (PKI) 

Für eine sichere Kommunikation zwischen den AD FS-Komponenten müssen zur Verwendung von 

AD FS für alle Websites, die Benutzerauthentifizierungs-Datenverkehr oder Sicherheitstoken zulassen, 

Zertifikate für die Serverauthentifizierung konfiguriert werden. Diese Zertifikate werden für die Kontopartner- 

und Ressourcenpartnerauthentifizierung und für die Authentifizierung zwischen Verbundservern 

und Verbundserverproxys verwendet. Das bedeutet, dass die erforderlichen digitalen Zertifikate 

von einer Zertifizierungsstelle (Certification Authority, CA) ausgestellt werden. Zur Ausstellung 

dieser Zertifikate kann eine vertrauenswürdige externe Zertifizierungsstelle oder eine interne Zertifizierungsstelle 

der Active Directory-Zertifikatdienste (Active Directory Certificate Services, AD CS) 


• Von Verbundservern verwendete Zertifikate Verbundserver führen sowohl server- als auch clientbasierte 

Funktionen aus, für die bestimmte Zertifikatstypen benötigt werden: 

• Tokensignaturzertifikat Jeder Verbundserver verwendet ein Tokensignaturzertifikat, um alle selbst 

erstellten Sicherheitstoken digital zu signieren. Da jedes Sicherheitstoken vom Kontopartner digital 

signiert wird, kann der Ressourcenpartner sicherstellen, dass das Sicherheitstoken tatsächlich 

vom Kontopartner ausgestellt und nicht geändert wurde. So werden Angreifer daran gehindert, 

Sicherheitstoken zu fälschen oder zu ändern, um unberechtigten Zugriff auf Ressourcen zu erlangen.


Digitale Signaturen werden für Sicherheitstoken auch innerhalb des Kontopartners verwendet, 

wenn mehr als ein Verbundserver verwendet wird. In diesem Fall werden anhand der digitalen 

Signaturen die Quelle und die Integrität der Sicherheitstoken überprüft, die von anderen Verbundservern 

des Kontopartners ausgestellt werden. Die Überprüfung der digitalen Signaturen erfolgt 

durch Verifizierungszertifikate. Jedes Tokensignaturzertifikat enthält einen privaten Schlüssel, der 

dem Zertifikat zugewiesen ist. 

Hinweis Ist mehr als ein Verbundserver in einer Serverfarm vorhanden, kann allen Verbundservern 

dasselbe Tokensignaturzertifikat oder jedem Verbundserver ein eindeutiges Zertifikat zugewiesen werden. 

Für eine einfachere und kostengünstigere Bereitstellung sollte auf allen Verbundservern dasselbe 

Tokensignaturzertifikat installiert werden. Weitere Informationen zur Planung der Bereitstellung einer 

Verbundserverfarm finden Sie im Entwurfshandbuch für Active Directory-Verbunddienste unter http:// 

technet2.microsoft.com/windowsserver/de/library/b0f029cb-65ab-44fb-bcfc- 

5aa02314e06e1031.mspx?mfr=true. 

• Verifizierungszertifikat Ein Verifizierungszertifikat wird verwendet, um sicherzustellen, dass ein 

Sicherheitstoken von einem zulässigen Verbundserver ausgestellt und nicht geändert wurde. 

Eigentlich ist ein Verifizierungszertifikat das Tokensignaturzertifikat eines anderen Verbundservers. 

Um verifizieren zu können, dass ein Sicherheitstoken von einem bestimmten Verbundserver 

ausgestellt und nicht geändert wurde, muss der Verbundserver über ein Verifizierungszertifikat für 

den Verbundserver verfügen, der das Sicherheitstoken ausgestellt hat. Wenn beispielsweise der 

Verbundserver von Adatum ein Sicherheitstoken ausstellt und an einen Verbundserver der Woodgrove 

Bank sendet, muss der Verbundserver der Woodgrove Bank über ein Verifizierungszertifikat 

(Tokensignaturzertifikat von Verbundserver von Adatum) verfügen. Im Gegensatz zu einem 

Tokensignaturzertifikat enthält ein Verifizierungszertifikat nicht den privaten Schlüssel, der dem 

Zertifikat zugewiesen ist. 

Die Ressourcenpartner und Web-Agents, die dem Verbundserver vertrauen, müssen dem Zertifikat 

der Stammzertifizierungsstelle für die Verifizierungszertifikate vertrauen. Zudem müssen Zertifikatssperrlisten 

(Certificate Revocation List, CRL) für Ressourcenpartner und Web-Agents 

zugänglich sein, die dem Verbundserver vertrauen. 

Hinweis Der Ressourcenverbundserver muss auf das Tokensignaturzertifikat für den Kontoverbundserver 

zugreifen können. Beim Erstellen eines Kontopartners auf dem Ressourcenverbundserver wird 

das Zertifikat importiert. 

• SSL-Serverauthentifizierungszertifikat Für einen sicheren Datenverkehr zwischen Webdiensten und 

Webclients bzw. dem Verbundserverproxy verwendet der Verbundserver ein SSL-Serverauthentifizierungszertifikat. 

Alle Verbundserverproxys und Web-Agents müssen der Stammzertifizierungsstelle für alle SSL- 

Serverauthentifizierungszertifikate vertrauen und die CRLs müssen für sämtliche Zertifikate in 

der Kette – vom Serverauthentifizierungszertifikat bis zum Zertifikat der Stammzertifizierungsstelle 

– verfügbar sein. Darüber hinaus muss der im Serverauthentifizierungszertifikat verwendete 

Antragstellername mit dem DNS-Namen (Domain Name System) der Verbunddienstendpunkt- 

URL (Uniform Resource Locator) in der Vertrauensrichtlinie übereinstimmen.


Direkt von der Quelle: Problembehandlung bei Zertifikatssperrungen 

Zertifikatsprobleme gehören zu den fünf Themen, mit denen das Microsoft-Supportteam bei der 

AD FS-Problembehebung am häufigsten konfrontiert wird. Ein Zertifikatsproblem in Zusammenhang 

mit AD FS betrifft einen gängigen Routinevorgang, bei dem die Gültigkeit eines Zertifikats 

überprüft wird, indem dieses mit einer von der Zertifizierungsstelle ausgegebenen Liste mit 

gesperrten Zertifikaten verglichen wird. Dieser Vorgang wird in der Public Key-Infrastruktur auch 

als CRL-Überprüfung bezeichnet. 

Die für einen Kontopartner auf einem Verbundserver konfigurierte Einstellung für die Sperrüberprüfung 

wird vom Verbundserver verwendet, um festzustellen, wie die Sperrüberprüfung für von 

diesem Kontopartner gesendete Token durchgeführt wird. Die Verbundservereinstellung für die 

Sperrüberprüfung wird über den Knoten Vertrauensrichtlinie des AD FS-Snap-Ins konfiguriert. 

Anhand dieser Einstellung stellt der Verbundserver und der an diesen gebundene AD FS-Web- 

Agent fest, wie die Sperrüberprüfung für das Tokensignaturzertifikat des Verbundservers durchgeführt 

wird. Bei der Überprüfung werden entweder die importierten CRLs auf dem lokalen Computer 

oder die über den Sperrlistenverteilungspunkt bereitgestellten CRLs verwendet. 

Bei der Behandlung von Zertifikatsproblemen sollten Sie die Möglichkeit haben, die Sperrüberprüfung 

schnell zu deaktivieren, damit die Problemquelle einfacher lokalisiert werden kann. Dies ist 

beispielsweise in Bereitstellungsszenarien sinnvoll, in denen für die Tokensignaturzertifikate keine 

CRLs verfügbar sind. 

Das AD FS-Produktteam bietet zur Lösung von Problemen mit der CRL-Überprüfung im AD FS- 

Snap-In in Windows Server 2008 eine Funktion, über die das Verhalten der Sperrüberprüfung im 

Rahmen des Verbunddienstes angepasst bzw. über die die Sperrprüfung deaktiviert werden kann. 

Die Sperrprüfung lässt sich zum Beispiel so konfigurieren, dass die Gültigkeit aller Zertifikate in 

einer Zertifikatskette oder nur das Endzertifikat in der Zertifikatskette überprüft wird. 

Nick Pierson 

Senior Technical Writer, Microsoft 

Von Verbundserverproxys verwendete Zertifikate Für eine sichere Kommunikation zwischen Verbundservern 

und Webclients verwendet der Verbundserverproxy die folgenden SSL-Zertifikate: 

• SSL-Clientauthentifizierungszertifikate Jeder Verbundserverproxy verwendet zur Authentifizierung 

des Verbunddienstes ein SSL-Clientauthentifizierungszertifikat. Eine Kopie des Clientauthentifizierungszertifikats 

vom Verbundserverproxy wird sowohl auf dem Verbundserverproxy als auch 

in der Vertrauensrichtlinie des Verbundservers gespeichert. Der private Schlüssel, der dem 

Clientauthentifizierungszertifikat des Verbundserverproxys zugewiesen ist, wird hingegen ausschließlich 

auf dem Verbundserverproxy gespeichert. 

• SSL-Serverauthentifizierungszertifikate Für einen sicheren Datenverkehr zwischen Webdiensten und 

Webclients verwendet der Verbundserverproxy SSL-Serverauthentifizierungszertifikate. 

Vom AD FS-Web-Agent verwendete Zertifikate Für eine sichere Kommunikation mit Webclients verwendet 

jeder Webserver, der als Host für den AD FS-Web-Agent fungiert, SSL-Serverauthentifizierungszertifikate. 

Diese Zertifikate werden über das Snap-In Internetinformationsdienste angefordert und 

installiert oder können über Gruppenrichtlinien oder eine automatische Registrierung installiert werden, 

wenn die AD CS bereitgestellt wurden.


Hinweis Clientzertifikate können ebenfalls für Clientcomputer verwendet werden, die mit Verbundservern, 

Verbundserverproxys oder Webservern verbunden sind. Die Clientauthentifizierung bietet zwar zusätzliche 

Sicherheit, setzt aber auch voraus, dass Zertifikate an alle Clientcomputer verteilt werden, die voraussichtlich 

mit der AD FS-Umgebung verbunden werden. Wenn die AD FS nur Mitarbeitern zur Verfügung gestellt 

werden, die ausschließlich zur internen AD DS-Gesamtstruktur gehörende Clientcomputer verwenden, kann 

die Zertifikatsverteilung automatisiert werden. Hierzu ist die Aktivierung der automatischen Registrierung in 

den AD CS erforderlich. Weitere Informationen zu diesem Thema finden Sie in Kapitel 17, „Active Directory- 

Zertifikatdienste“. 

Praxistipp: Auswahl einer Zertifizierungsstelle 

Um die Zertifikatsanforderungen für die AD FS zu erfüllen, besteht die Möglichkeit, Zertifikate 

von einer öffentlichen Zertifizierungsstelle zu erwerben, eine interne Zertifizierungsstelle einer AD 

CS-Implementierung einzusetzen oder selbstsignierte Zertifikate zu nutzen. In Tabelle 19.1 sind die 

Vor- und Nachteile der einzelnen Optionen aufgeführt. 

Tabelle 19.1 

Vorteile und Nachteile der Zertifizierungsstellenoptionen 

Zertifizierungsstellentyp 

Öffentliche 


Interne Zertifizierungsstelle 

Erläuterung 

Vorteile: 

• Clientcomputer vertrauen der Stammzertifizierungsstelle bereits, folglich können Zertifikate 

ohne zusätzliche Konfiguration mit dem Stamm verkettet werden. 

• Die öffentliche Zertifizierungsstelle bietet umfassende Verwaltungsdienste für Zertifikate 

und Zertifikatssperren. 

Nachteile: 

• Die von öffentlichen Zertifizierungsstellen ausgestellten Zertifikate verursachen 

höhere Kosten als selbstsignierte Zertifikate oder von internen Zertifizierungsstellen 

ausgestellte Zertifikate. 

• Das Sicherheitsrisiko wird erhöht, wenn öffentliche Zertifizierungsstellen unzureichende 

Sicherheitsrichtlinien verwenden. 

Vorteile: 

• Die Zertifikatsperrung wird intern verwaltet, daher können Zertifikate zentral gesperrt 

werden, wenn die Sicherheit eines privaten Schlüssels gefährdet ist. 

• Die Verwaltung der internen Zertifizierungsstelle ermöglicht eine höhere Flexibilität 

bei der Zertifikatsverteilung. 

• Die Verwaltung der internen Zertifizierungsstelle ermöglicht eine vollständige Kontrolle 

über die Sicherheit der Implementierung. 

Nachteile: 

• Die Implementierung einer internen Zertifizierungsstelle kann kompliziert sein. Bei 

falscher Handhabung kann die Komplexität zu Sicherheitsproblemen führen. 

• Die durch interne Zertifizierungsstellen ausgestellten Zertifikate sind zwar kostenlos, 

aber die Implementierungs- und Verwaltungskosten für eine solche Zertifizierungsstelle 

können die Kosten für den Erwerb von Zertifikaten einer öffentlichen Zertifizierungsstelle 

übersteigen. 

• Clientcomputer vertrauen der Stammzertifizierungsstelle nicht automatisch, folglich 

müssen diesen ggf. Zertifikate für die vertrauenswürdige Stammzertifizierungsstelle 

hinzugefügt werden.


Tabelle 19.1 

Vorteile und Nachteile der Zertifizierungsstellenoptionen (Fortsetzung) 

Selbstsignierte Zertifikate Vorteile: 

• Selbstsignierte Zertifikate können ohne Public Key-Infrastruktur bereitgestellt werden. 

• Zertifikate sind kostenlos. 

Nachteile: 

• Es sind keine zentralisierten Sperrlisten verfügbar. Wenn die Sicherheit des privaten 

Zertifikatsschlüssels gefährdet ist, muss jede vertrauende Partei manuell benachrichtigt 

werden, damit diese künftig anstatt des vorhandenen ein neues Zertifikat verwendet. 

• Clientcomputer vertrauen dem selbstsignierten Zertifikat nicht automatisch, folglich 

müssen diesen ggf. Zertifikate für die vertrauenswürdige Stammzertifizierungsstelle 


• Selbstsignierte Zertifikate sind nicht Teil einer Zertifikatsvertrauensliste, daher muss 

jedes selbstsignierte Zertifikat von einer vertrauenswürdigen Partei ausdrücklich als 

vertrauenswürdig eingestuft werden. 

Da eine größere Anzahl an Clients auf die SSL-Zertifikate zugreifen wird, die den Webservern und 

Verbundservern zugewiesen sind, wird empfohlen, für sämtliche SSL-Zertifikate eine öffentliche 

Zertifizierungsstelle zu nutzen. Die Tokensignaturzertifikate müssen nur von den Servern als vertrauenswürdig 

eingestuft werden, die AD FS-Rollendienste ausführen. In diesem Fall wird empfohlen, 

entweder eine interne Zertifizierungsstelle oder ein selbstsigniertes Zertifikat zu verwenden. 

Wenn es sich bei der Organisation um einen Kontopartner handelt, der voraussichtlich zahlreiche 

Ressourcenpartner haben wird und eine zentralisierte Sperren- und Vertrauensverwaltung benötigt, 

ist eine interne Zertifizierungsstelle in der Regel die beste Wahl. Wird die Organisation nur mit 

wenigen Ressourcenpartnern arbeiten, sind selbstsignierte Zertifikate häufig besser geeignet, da 

diese kostengünstiger und weniger komplex sind. 

Implementieren der AD FS in einem Federated-Web-SSO-Entwurf 

Nachdem sichergestellt ist, dass alle Anforderungen an die Umgebung erfüllt sind, kann nun die 

Installation der AD FS-Komponenten durchgeführt werden. In diesem Abschnitt werden die entsprechenden 

Vorgehensweisen beschrieben. 

Implementieren des Federated-Web-SSO-Entwurfs – Übersicht 

Zur Implementierung des Federated-Web-SSO-Entwurfs müssen die folgenden Schritte ausgeführt 

werden: 

Vorbereiten der Umgebung 

1. Installieren der Serverrolle Webserver (IIS) auf allen an der AD FS-Bereitstellung beteiligten 

Servern. Wenngleich diese Serverrolle auch im Rahmen der AD FS-Serverrollenbereitstellung 

installiert werden kann, sollte dieser Schritt vorher ausgeführt werden, wenn Sie die erforderlichen 

Serverzertifikate vor der AD FS-Installation konfigurieren möchten. 

Hinweis In den folgenden Abschnitten sind die Schritte zur Installation der Rolle Webserver (IIS) nicht 

enthalten. Weitere Informationen finden Sie in der Onlinehilfe zum Server-Manager und den Internetinformationsdiensten.


2. Abrufen der erforderlichen Authentifizierungszertifikate für jeden am AD FS-Szenario beteiligten 

Server und Konfigurieren der SSL-Authentifizierung für die anwendbaren Websites auf jedem 

Server. Diese Aufgabe schließt die Webserver und alle mit den AD FS verbundenen Server ein. Wenn 

das selbstsignierte Zertifikat verwendet werden soll, kann das Zertifikat zusammen mit den AD FS 

installiert werden. 

Für eine ordnungsgemäße Funktionsweise der AD FS müssen die folgenden Zertifikatsanforderungen 

erfüllt sein: 

Das vom Kontopartner verwendete Tokensignaturzertifikat muss auf den Ressourcenverbundserver 

importiert werden. Hierzu ist das Exportieren des Tokensignaturzertifikat auf dem Kontoverbundserver 

in eine Datei erforderlich. Der Speicherort der Datei sollte so gewählt sein, 

dass diese beim Erstellen eines neuen Kontopartners auf den Ressourcenverbundserver importiert 

werden kann. 

Ein AD FS-Webserver muss das Serverauthentifizierungszertifikat für den Ressourcenverbundserver 

als vertrauenswürdig einstufen. Bei Verwendung einer öffentlichen Zertifizierungsstelle 

für den Ressourcenverbundserver wird dem Zertifikat vertraut. Wenn eine interne 

Zertifizierungsstelle genutzt wird, muss das Zertifikat auf den Ressourcenverbundserver 

exportiert und anschließend auf dem AD FS-Webserver in den Ordner Vertrauenswürdige 

Stammzertifizierungsstellen importiert werden. 

Bei Verwendung eines Verbundserverproxys muss für diesen ein Clientzertifikat festgelegt 

werden, das von dem entsprechenden Verbundserver als vertrauenswürdig eingestuft wird. 

Hinweis In den folgenden Abschnitten wird die Vorgehensweise beim Import und Export der Serverzertifikate 

nicht beschrieben. Weitere Informationen finden Sie in der Onlinehilfe zu den Internetinformationsdiensten 

oder im Handbuch zur AD FS-Bereitstellung (beide in englischer Sprache) unter 

http://go.microsoft.com/fwlink/?LinkId=91899. 

3. Installieren des Rollendienstes Verbunddienst. Auf den gewünschten Kontopartner- und Ressourcenpartnerservern 

muss der AD FS-Rollendienst Verbunddienst installiert werden. Während 

dieses Vorgangs kann ein selbstsigniertes Tokensignaturzertifikat erstellt werden, das zur Sicherung 

von Token bei Authentifizierungen verwendet wird. 

4. Installieren des Rollendienstes Verbunddienstproxy. Auf den gewünschten Kontopartner- und Ressourcenpartnerservern 

muss der AD FS-Rollendienst Verbunddienstproxy installiert werden. 

5. Installieren des AD FS-Web-Agents. Die Installation und Konfiguration des AD FS-Web-Agents 

erfolgt auf dem Webserver, auf dem die Ansprüche unterstützende bzw. Windows NT-Tokenbasierte 

Anwendung ausgeführt wird. 

Konfigurieren des Kontoverbundpartners Die Konfiguration des Verbunddienstes für die Kontoumgebung 

umfasst zahlreiche Aufgaben: 

1. Konfigurieren der Vertrauensrichtlinie. Zur Konfiguration der Vertrauensrichtlinie gehört die Eingabe 

des entsprechenden Verbunddienst-URIs und der Verbunddienstendpunkt-URL für die Kontoverbundumgebung. 

2. Konfigurieren der Organisationsansprüche. Auf der Seite des Kontopartners handelt es sich bei 

den Organisationsansprüchen um einen standardmäßigen Satz an Ansprüchen, die entweder über 

die AD DS oder die AD LDS gefüllt werden. AD DS- oder AD LDS-Attribute werden mithilfe 

von Organisationsansprüchen AD FS-Objekten zugeordnet, die von Verbundservern verstanden 

werden.


3. Hinzufügen und Konfigurieren von Kontospeichern. Die vom Kontopartner verwendeten Benutzerkonten 

müssen entweder in den AD DS oder den AD LDS gespeichert werden. Durch Hinzufügen 

des Kontospeichers zu den AD FS wird der Zugriff des Kontoverbundservers auf die 

Benutzerkonten ermöglicht. 

4. Hinzufügen und Konfigurieren eines Ressourcenpartners. Das Hinzufügen eines Ressourcenpartners 

repräsentiert die Konfiguration der Beziehung zwischen den Konto- und Ressourcenpartnerorganisationen. 

Hinweis Die Vertrauensrichtlinieneinstellungen des Verbunds von sowohl dem Kontopartner als auch 

dem Ressourcenpartner können in eine XML-Datei exportiert werden, um diese für die Konfiguration 

zahlreicher Einstellungen auf dem Verbundserver der Partnerorganisation zu verwenden. 

5. Erstellen von Zuordnungen (Transformationen) ausgehender Ansprüche für den Ressourcenpartner. 

Nach dem Einrichten einer verbundenen Vertrauensstellung zwischen zwei Organisationen ist 

möglicherweise die Zuordnung (Transformation) der Organisationsansprüche des Kontopartners 

zu Ansprüchen erforderlich, die von der Ressourcenpartneranwendung verarbeitet werden. 

Konfigurieren des Ressourcenverbundpartners Die Konfiguration des Verbunddienstes für die Ressourcenumgebung 

umfasst zahlreiche Aufgaben: 

1. Konfigurieren der Vertrauensrichtlinie. Zur Konfiguration der Vertrauensrichtlinie gehört die Eingabe 

des entsprechenden Verbunddienst-URIs und der Verbunddienstendpunkt-URL für die Ressourcenverbundumgebung. 

2. Konfigurieren der Organisationsansprüche. Damit auf Ressourcenseite entsprechende Zugriffsentscheidungen 

getroffen werden können, müssen zum Ressourcenverbunddienst Organisationsansprüche 


3. Hinzufügen und Konfigurieren einer AD FS-Anwendung. Der AD FS-Ressourcenpartner stellt die 

freigegebene Ressource bereit. Die Anwendung muss dem Verbunddienst hinzugefügt werden, 

sodass der Verbundserver Clientanforderungen an den entsprechenden Webserver weiterleiten 

kann. 

4. Hinzufügen und Konfigurieren eines Kontopartners. Das Hinzufügen eines Kontopartners repräsentiert 

die Konfiguration der Beziehung zwischen den Konto- und Ressourcenpartnerorganisationen. 

Diese Beziehung basiert auf den konfigurierten Kontopartnereinstellungen und dem 

importierten Verifizierungszertifikat vom Kontopartner. 

5. Erstellen einer Zuordnung eingehender Ansprüche für die Anwendung. Durch diese Aufgabe werden 

die eingehenden Organisationsansprüche vom Kontopartner in die Organisationsansprüche für 

den Ressourcenpartner transformiert. 

Konfigurieren des Webservers und der webbasierten Anwendungen Die Konfiguration des Webservers 

und der webbasierten Anwendungen ist Teil der AD FS-Bereitstellung. Diese Aufgabe umfasst entweder 

die Einrichtung einer Ansprüche unterstützenden oder einer Windows NT-Token-basierten 

Anwendung. Abhängig vom konfigurierten Anwendungstyp werden bestimmte Einstellungen der 

Anwendung und Webserverkonfiguration vorausgesetzt. 

Auf der DVD Eine AD FS-Bereitstellung kann eine Vielzahl an Komponenten und unterschiedlichen Konfigurationen 

umfassen. Bei der Planung einer AD FS-Bereitstellung sollte daher jede Komponente in der auf der 

Begleit-CD enthaltenen Datei AD FS Documentation.xls erfasst werden.


Bereitstellen von Verbundservern 

Für eine erfolgreiche Installation des Verbunddienstes müssen Sie sicherstellen, dass alle erforderlichen 

Komponenten auf dem Server installiert und konfiguriert sind. Führen Sie anschließend die 

folgenden Schritte aus: 

1. Klicken Sie im Server-Manager auf Rollen und anschließend auf Rollen hinzufügen, um den 

Assistenten zum Hinzufügen von Rollen zu starten. 

2. Klicken Sie auf der Seite Vorbemerkungen auf Weiter. 

3. Wählen Sie auf der Seite Serverrollen auswählen die Option Active Directory-Verbunddienste. 

Klicken Sie zweimal auf Weiter. 

4. Aktivieren Sie auf der Seite Rollendienste auswählen (siehe Abbildung 19.5) das Kontrollkästchen 

Verbunddienst. Wenn Sie zur Installation der zusätzlichen Rollendienste Webserver (IIS) oder Windows-Prozessaktivierungsdienst 

aufgefordert werden, können Sie diese durch Klicken auf die 

Option Erforderliche Rollendienste hinzufügen installieren. Klicken Sie anschließend auf Weiter. 

5. Wählen Sie auf der Seite Serverauthentifizierungszertifikat für SSL-Verschlüsselung auswählen das 

Zertifikat für die SSL-Verschlüsselung aus, und klicken Sie anschließend auf Weiter. Wenn Sie 

bereits ein Zertifikat für die Standardwebsite konfiguriert haben, wird diese Seite nicht angezeigt. 

Wurde noch kein Zertifikat konfiguriert, können Sie auch ein selbstsigniertes Zertifikat verwenden. 

6. Wählen Sie auf der Seite Tokensignaturzertifikat auswählen (siehe Abbildung 19.6) das Zertifikat 

aus, dass zur Signatur der durch diesen Server ausgestellten Token verwendet werden soll, und 

klicken Sie auf Weiter. 


Installieren der AD FS-Serverrolle mit Auswahl der spezifischen zu installierenden Rollendienste



Tokensignaturzertifikate können installierte Zertifikate oder selbstsignierte Zertifikate sein 

Hinweis Denken Sie daran, dass das auf dem Kontopartner konfigurierte Tokensignaturzertifikat auf 

den Ressourcenverbundserver und den Verbundserverproxy importiert werden muss. Sie sollten das 

Tokensignaturzertifikat in eine Datei exportieren oder dieses später zusammen mit der Vertrauensrichtlinie 

exportieren. 

7. Geben Sie auf der Seite Vertrauensrichtlinie auswählen an, ob eine neue Vertrauensrichtlinie 

erstellt oder eine vorhandene Richtlinie importiert werden soll, und schließen Sie die Installation 

der Serverrolle Webserver (IIS) ab. 

Direkt von der Quelle: Einschränken der Verbunddienstbereitstellung mithilfe von 


In Windows Server 2003 R2 stellten die Active Directory-Verbunddienste keine Steuerungsmechanismen 

bereit, um Benutzer an der Installation und Konfiguration eines eigenen Verbunddienstes zu 

hindern. Windows Server 2008 bietet AD FS-Administratoren nun die Möglichkeit, Gruppenrichtlinieneinstellungen 

zu aktivieren, und so den Zugriff durch nicht autorisierte Verbundserver auf 

ihre Domäne zu unterbinden. IT-Abteilungen können mithilfe dieser neuen Einstellung die Einhaltung 

von behördlichen Auflagen und Kompatibilitätsanforderungen erzwingen.


Nach Aktivierung der Gruppenrichtlinieneinstellung wird im Registrierungsschlüssel jedes Verbundservers 

in dieser Domäne der Wert DisallowFederationService eingefügt. Bevor auf einem 

Windows Server 2008-Computer, der zu einer AD DS-Domäne gehört, die Serverrolle Verbunddienst 

installiert werden kann, stellt der Server zunächst sicher, dass die Gruppenrichtlinie Nur 

autorisierte Verbundserver in dieser Domäne zulassen aktiviert ist. Ist dies der Fall, kann der 

Verbunddienst nicht installiert werden. Wenn die Gruppenrichtlinie nicht aktiviert ist (Standardeinstellung), 

wird die Installation eines Verbunddienstes zugelassen und kann normal ausgeführt 

werden. 

Der Wert des Registrierungsschlüssels wird erst überprüft, wenn die Vertrauensrichtliniendatei 

geladen ist. Daher kann es zu einer Verzögerung zwischen dem Herunterladen der Richtlinie und 

dem Erkennen der Richtlinie vom Verbunddienst kommen. Die Richtlinie wird standardmäßig bei 

Erhalt einer Dateiänderungsbenachrichtigung und zusätzlich einmal pro Stunde gelesen. 

Beachten Sie, dass diese Funktion nur für Windows Server 2008-Verbundserver gilt und auf neue 

oder vorhandene Verbunddienstinstallationen in Windows Server 2003 R2 keine Auswirkungen 

hat. 

Lu Zhao 

Program Manager, Microsoft 

Bereitstellen von Verbunddienstproxy-Servern 

Mithilfe eines Verbundserverproxys kann eine Offenlegung der Verbundserver im Internet vermieden 

werden. In den meisten Fällen wird der Verbundserverproxy in einem Umkreisnetzwerk zusammen 

mit den Verbundservern im internen Netzwerk bereitgestellt. 

Bei der Implementierung von Verbundserverproxys sind zwei Konfigurationsoptionen zu beachten: 

• Ändern der Verbundproxy-URL Bei der Installation eines Konto- oder Ressourcenverbundservers 

kann in der Vertrauensrichtlinie ein URI (Uniform Resource Identifier) festgelegt werden, der die 

URL (Uniform Resource Locator) identifiziert, zu der die Benutzer bei einem Verbindungsversuch 

mit dem Verbundserver weitergeleitet werden. Diese URIs werden folgendermaßen verwendet: 

Für die AD FS-Web-Agents auf den IIS-Servern wird der URI des Ressourcenverbundservers 

festgelegt. 

Auf dem Ressourcenverbundserver wird der URI für den Kontoverbundserver festgelegt. 

Auf dem Kontoverbundserver wird der URI für den Ressourcenverbundserver festgelegt. 

Beim Hinzufügen eines Verbundserverproxys muss der Endpunkt der Verbundserver-URIs entsprechend 

geändert werden, sodass Clientcomputer anstatt einen direkten Verbindungsversuch mit 

dem Verbundserver zu starten, an den Verbundserverproxy umgeleitet werden. 

• Konfigurieren der Clientzertifikate des Verbundserverproxys Für die Clientauthentifizierung muss 

der Verbundserverproxy über ein Zertifikat verfügen, das mit einer Stammzertifizierungsstelle 

verkettet ist. Diese wiederum muss der durch das Zertifikat geschützte Verbundserver als vertrauenswürdig 

einstufen. Für dieses Zertifikat verfügt der Verbundserverproxy sowohl über einen 

öffentlichen als auch über einen privaten Schlüssel. Das Zertifikat muss (ohne den privaten 

Schlüssel) exportiert und anschließend in die Vertrauensrichtlinie des geschützten Verbundservers 

importiert werden.


Stellen Sie für eine erfolgreiche Installation des Verbunddienstproxys sicher, dass alle erforderlichen 

Komponenten auf dem Server installiert und konfiguriert sind, und führen Sie die folgenden Schritte 

aus: 






4. Aktivieren Sie auf der Seite Rollendienste auswählen (siehe Abbildung 19.5) das Kontrollkästchen 

Verbunddienstproxy. Wenn Sie zur Installation der zusätzlichen Rollendienste Webserver 

(IIS) oder Windows-Prozessaktivierungsdienst aufgefordert werden, können Sie diese durch Klicken 

auf die Option Erforderliche Rollendienste hinzufügen installieren. Klicken Sie anschließend 

auf Weiter. 

5. Geben Sie auf der Seite Verbundserver angeben den vollqualifizierten Namen des von diesem 

Proxy verwendeten Verbundservers ein, und klicken Sie anschließend auf Überprüfen, um sicherzustellen, 

dass die Kommunikation des Proxyservers mit dem Verbundserver einwandfrei funktioniert. 

Klicken Sie auf Weiter. 

6. Wählen Sie auf der Seite Clientauthentifizierungszertifikat auswählen das gewünschte Zertifikat 

für die Clientauthentifizierung aus, und klicken Sie anschließend auf Weiter. Wurde noch kein Zertifikat 

konfiguriert, können Sie auch ein selbstsigniertes Zertifikat verwenden. 

Hinweis Die vom Verbundserverproxy verwendeten Clientzertifikate müssen zur Verbundserverkonfiguration 

hinzugefügt werden. Daher ist es sinnvoll, die Clientzertifikate in eine Datei zu exportieren. 

7. Schließen Sie die Installation der Serverrolle Webserver (IIS) ab. 

Nach Abschluss der Installation sind in der Konfiguration der Verbunddienstproxy-Komponente die 

Standardeinstellungen für die Verbundserver-URL, die Clientabmeldung und -anmeldung sowie die 

Seite für die Ermittlung des Kontopartners festgelegt. Über das Snap-In Active Directory-Verbunddienste 

auf dem Verbundserverproxy lassen sich diese Einstellungen ändern oder erweiterte Anmeldeinstellungen 

für die Problembehandlung vornehmen. 

Bereitstellen des AD FS-Web-Agents 

Stellen Sie für eine erfolgreiche Bereitstellung des Rollendienstes AD FS-Web-Agent sicher, dass alle 

erforderlichen Komponenten auf dem Server installiert und konfiguriert sein, und führen Sie die folgenden 

Schritte aus: 






4. Aktivieren Sie auf der Seite Rollendienste auswählen (siehe Abbildung 19.5) entweder das Kontrollkästchen 

Ansprüche unterstützender Agent, das Kontrollkästchen Windows-Token-basierter 

Agent oder beide. Die zu treffende Auswahl hängt vom Anwendungstyp ab, den Sie auf dem Server 

installieren. Klicken Sie auf Weiter.


5. Setzen Sie die Installation der Serverrolle Webserver (IIS) fort. Aktivieren Sie bei Verwendung 

eines selbstsignierten Serverauthentifizierungszertifikats auf der Seite Rollendienste auswählen, 

zusätzlich zu den standardmäßig aktivierten Kontrollkästchen, das Kontrollkästchen Clientzertifikatzuordnung-Authentifizierung, 

und klicken Sie auf Weiter. Die Komponente Clientzertifikatzuordnung-Authentifizierung 

wird für IIS zum Erstellen selbstsignierter 

Serverauthentifizierungszertifikate benötigt. 

Konfigurieren des Kontopartner-Verbunddienstes 

Nach der Installation der AD FS-Rollendienste können die AD FS-Komponenten für die Konto- und 

Ressourcenpartner konfiguriert werden. 

Konfigurieren der Vertrauensrichtlinie 

In einer Vertrauensrichtlinie werden Parameter festgelegt, die für alle Verbundserver innerhalb eines 

AD FS-Sicherheitsbereichs gelten. Zum Konfigurieren der Vertrauensrichtlinie gehen Sie wie folgt 

vor: 

1. Starten Sie das Snap-In Active Directory-Verbunddienste. Erweitern Sie Verbunddienst, klicken 

Sie mit der rechten Maustaste auf Vertrauensrichtlinie, und klicken Sie anschließend auf Eigenschaften. 

2. Legen Sie im Fenster Vertrauensrichtlinie (siehe Abbildung 19.7) Folgendes fest: 

Verbunddienste-URI. Dieser Wert ermöglicht eine eindeutige Identifizierung der AD FS- 

Installation. Er wird dem Ressourcenpartner bereitgestellt. 

Wichtig Der Verbunddienst-URI berücksichtigt die Groß-/Kleinschreibung. Bei der Eingabe dieses Wertes 

auf dem Ressourcenverbundserver muss die Groß- und Kleinschreibung berücksichtigt werden. Um 

sicherzustellen, dass der Wert korrekt eingegeben wurde, sollte die Vertrauensrichtlinien nach der Erstellung 

in eine Datei exportiert werden, die dann an die Ressourcenpartner gesendet wird. 

 

 

 

 

 

 

Verbunddienstendpunkt-URL. An diese URL wird der Client vom Web-Agent auf dem Webserver 

umgeleitet. Bei Verwendung eines Verbundserverproxys muss diese URL auf den Verbundserverproxy 

verweisen. Wird kein Verbundserverproxy eingesetzt, verweist dieser Wert 

auf den Verbundserver. 

Verwendetes Tokensignatur-Verifizierungszertifikat. Tokensignatur-Verifizierungszertifikate 

(ohne den privaten Schlüssel), die von Kontopartnern zur Überprüfung der digitalen Signatur 

von Sicherheitstoken verwendet werden, können hinzugefügt oder entfernt werden. Wird das 

Zertifikat zur Vertrauensrichtlinie hinzugefügt, ist es in der Exportdatei der Vertrauensrichtlinie 

enthalten, die Sie zur Weitergabe an einen Ressourcenpartner erstellen. 

Verfügbare Clientauthentifizierungszertifikate des Verbundserverproxys. Die Clientauthentifizierungszertifikate 

(ohne privaten Schlüssel) können für Verbundserverproxy-Computer hinzugefügt 

werden. 

Verwendete Modul-DLL für die Anspruchstransformation. Wenn eine DLL-Datei erstellt 

wurde, wird diese Option zur Verwaltung der Anspruchstransformationen zwischen den Ressourcen- 

und Kontopartnern verwendet. 

Ereignisprotokollstufen. Anhand von Ereignisprotokollstufen kann festgelegt werden, ob Fehler, 

Warnungen und Überwachungsereignisse protokolliert werden oder nicht. 

Gültigkeitszeiträume für Token und Richtlinienaktualisierung.


Festlegen der für AD FS-Clients erforderlichen URI- und URL-Werte über die Vertrauensrichtlinien- 


einstellungen 

Verwalten von Vertrauensrichtliniendateien 

Durch Klicken mit der rechten Maustaste auf Verbunddienst und anschließendes Klicken auf Eigenschaften 

wird der Speicherort der Vertrauensrichtliniendatei angezeigt. Standardmäßig wird die 

Datei im Ordner C:\Windows\SystemData\ADFS gespeichert. Fungieren mehrere Computer als 

Host für den Verbunddienst in einer einzelnen Verbundpartnerorganisation, die in einer Serverfarm 

ausgeführt wird, nutzen diese dieselbe Vertrauensrichtliniendatei. Bei der Installation zusätzlicher 

Verbundserver in der Organisation sollte zur Serverkonfiguration diese Richtlinie verwendet werden. 

Weitere Informationen zur Konfiguration von Verbundserverfarmen finden Sie im Entwurfshandbuch 

für Active Directory-Verbunddienste unter http://technet2.microsoft.com/windowsserver/ 

de/library/b0f029cb-65ab-44fb-bcfc-5aa02314e06e1031.mspx?mfr=true. 

Nach dem Erstellen kann die Richtlinie zudem in eine XML-Datei exportiert werden, damit diese 

ebenfalls Ressourcenpartnern bereitgestellt werden kann. Klicken Sie hierzu mit der rechten Maustaste 

auf Vertrauensrichtlinie und anschließend auf Standardpartnerrichtlinie exportieren, und 

geben Sie einen Dateinamen und Speicherort für die Richtlinie ein. In der exportierten Richtlinie 

sind Anzeigename, URL und URI sowie das Verifizierungszertifikat enthalten. Wenn Sie den Ressourcenpartnern 

diese Datei zur Verfügung stellen, muss das Zertifikat nicht länger in einer separaten 

Datei bereitgestellt werden. So ist gewährleistet, dass alle Informationen ordnungsgemäß eingegeben 

sind. 

Konfigurieren von Organisationsansprüchen 

Ein AD FS-Anspruch ist ein Aussage über einen Benutzer, die von beiden Partnern in einem AD FS- 

Verbundszenario verstanden wird. In einem Verbundszenario wird zunächst der AD FS-Organisationsanspruch 

für den Kontopartner erstellt. Bei der Benutzerauthentifizierung auf dem Verbundserver 

werden die Informationen aus den AD DS oder den AD LDS vom Verbundserver extrahiert, um 

diese zum Erstellen des Anspruchs zu verwenden.


Wenn es sich bei dem Anspruch beispielsweise um einen Gruppenanspruch handelt (d.h. der Web- 

Agent des Ressourcenpartners trifft Autorisierungsentscheidungen anhand der Gruppe, zu der der 

Benutzer gehört), werden die Gruppeninformationen aus dem Verzeichnisdienst vom Verbundserver 

extrahiert und dem Client als Teil des Sicherheitstokens zur Verfügung gestellt. 

Über die für den Kontopartner erstellten Organisationsansprüche werden die verschiedenen Kriterien 

festgelegt, die im Anspruch enthalten sein werden. Der Verbunddienst unterstützt drei 

Anspruchstypen: 

• Identitätsansprüche Identitätsansprüche werden standardmäßig während der Verbunddienstinstallation 

konfiguriert. Mithilfe von Identitätsansprüchen wird sichergestellt, dass ein bestimmter 

Benutzer von einem vertrauenswürdigen Verzeichnisspeicher eines Verbundpartners authentifiziert 

wurde. Es gibt drei Identitätsanspruchstypen: 

UPN-Ansprüche stehen für einen Kerberos-Benutzerprinzipalnamen (User Principal Name, 

UPN), z.B.: benutzer@adatum.com. Nur ein Anspruch darf vom Typ UPN sein. Bei der Kontopartnerkonfiguration 

können mehrere UPN-Domänen und -Suffixe angegeben werden, die 

vom Kontopartner zugelassen werden. Bei Empfang einer UPN-Identität, deren Domänenteil 

nicht in der Liste aufgeführt ist, wird die Anforderung abgelehnt. 

E-Mail-Anforderungen stehen für RFC 2822-E-Mail-Namen der Form benutzer@adatum.com. 

Nur ein Anspruch darf den E-Mail-Anspruchstyp aufweisen. Bei der Kontopartnerkonfiguration 

können mehrere E-Mail-Domänen und -Suffixe angegeben werden, die vom Kontopartner 

zugelassen werden. Wie auch bei UPN-Ansprüchen wird bei Empfang einer E-Mail-Identität, 

deren Domänenteil nicht in der Liste aufgeführt ist, die Anforderung abgelehnt. 

Allgemeine Namensansprüche stehen für eine beliebige Zeichenfolge, die für die Personalisierung 

verwendet wird, z.B. John Smith oder Mitarbeiter von Adatum. Nur ein Anspruch darf 

vom Typ allgemeiner Name sein. Beachten Sie, dass es keinen Mechanismus gibt, durch den 

die Eindeutigkeit des allgemeinen Namensanspruchs sichergestellt werden kann. Daher sollte 

dieser Anspruchstyp bei Autorisierungsentscheidungen mit Vorsicht eingesetzt werden. Bei 

der Kontopartnerkonfiguration kann festgelegt werden, ob allgemeine Namensansprüche vom 

Kontopartner empfangen werden können oder nicht. 

Hinweis Die drei Identitätsansprüche sind möglicherweise nicht zugeordnet; sie werden jedoch übergeben, 

wenn sie aktiviert sind. Ist in einem Token mehr als einer der drei Identitätsanspruchstypen vorhanden 

ist, werden die Identitätsansprüche in der folgenden Reihenfolge nach Priorität geordnet: UPN, 

E-Mail und allgemeiner Name. 

• Gruppenansprüche Gruppenansprüche gehören zu dem Anspruchstyp, bei dem eine Gruppenmitgliedschaft 

in den AD DS oder AD LDS einer bestimmten Autorisierungsrolle zugeordnet wird. 

Zum Beispiel könnte die Gruppe FinanzManager einem Gruppenanspruch des Kontopartners 

zugeordnet werden. Anschließend trifft die Webanwendung auf der Seite des Ressourcenpartners 

basierend auf diesem Gruppenanspruch Autorisierungsentscheidungen. Bei der Ressourcenpartnerkonfiguration 

können mehrere eingehende Gruppenansprüche angegeben werden, die vom 

Kontopartner zugelassen werden. Darüber hinaus lassen sich Autorisierungs-Manager-Rollen mit 

Gruppenansprüchen verknüpfen, die zur Autorisierung der Webanwendung verwendet werden 

dürfen. 

• Benutzerdefinierte Ansprüche Benutzerdefinierte Ansprüche enthalten benutzerdefinierte Informationen 

zu einem Benutzer, z.B. die Personalnummer eines Mitarbeiters.


Diese Informationen werden aus den Benutzerkontoattributen über LDAP abgerufen und einem 

benutzerdefinierten Namen in dem Anspruch zugeordnet. Bei der Ressourcenpartnerkonfiguration 

können mehrere eingehende Namen benutzerdefinierter Ansprüche angegeben werden, die 

vom Kontopartner zugelassen werden. Eingehende benutzerdefinierte Ansprüche ohne Zuordnung 

werden verworfen. 

Sicherheitswarnung Beim Erstellen eines allgemeinen Namensanspruchs können beliebige Attribute aus 

dem Kontospeicher verwendet werden. Wenn in einem Unternehmen beispielsweise Personalnummern, 

Bankkontennummern oder Sozialversicherungsnummern im Verzeichnis gespeichert werden, lassen sich 

mithilfe dieser Informationen Ansprüche erstellen. Da jedoch einige dieser Informationen privat sind, müssen 

bei deren Weitergabe an andere Organisationen gesetzliche Bestimmungen eingehalten werden. 

Zum Erstellen neuer Organisationsansprüche klicken Sie mit der rechten Maustaste auf Organisationsansprüche, 

wählen Sie Neu, und klicken Sie anschließend auf Organisationsanspruch (siehe 

Abbildung 19.8). Durch das Erstellen des Organisationsanspruchs wird im Grunde genommen ein 

Platzhalter für den Anspruch erstellt, der erst nach Hinzufügen von mindestens einem Kontospeicher 

zum Verbunddienst und dem Konfigurieren der Anspruchszuordnungen verwendet werden kann. 

Abbildung 19.8 Zuordnen von Gruppen aus dem Kontospeicher zu AD FS-Objekten durch die Konfiguration eines 

Gruppenorganisationsanspruchs 

Hinzufügen eines Kontospeichers 

Ein Verbundserver, der für die Authentifizierung aller Verbundszenarien verwendet werden soll, muss 

über mindestens einen Kontospeicher verfügen. Klicken Sie zum Hinzufügen eines Kontospeichers 

mit der rechten Maustaste unter Eigene Organisation in der AD FS-Konsole auf Kontospeicher, und 

klicken Sie anschließend auf Kontospeicher. Per Voreinstellung wird durch den Assistenten zum Hinzufügen 

von Kontospeichern ein Kontospeicher für die AD DS-Domäne hinzugefügt, zu welcher der 

Verbundserver gehört. Es kann nur ein AD DS-Kontospeicher hinzugefügt werden. 

Sie können zusätzliche AD LDS-Kontospeicher erstellen. Beim Hinzufügen weiterer AD LDS-Kontospeicher 

müssen Sie die folgenden Informationen bereitstellen: 

• Anzeigename für den AD LDS-Kontospeicher. 

• Kontospeicher-URI im Format LDAP://Servername. 

• Servername, IP-Adresse und Portnummer (siehe Abbildung 19.9). Da auf einem Server mehrere AD 

LDS-Instanzen mit jeweils unterschiedlichen Portnummern ausgeführt werden können, muss für 

jede Instanz die entsprechende Portnummer angegeben werden.



Eingabe von Informationen zur AD LDS-Instanz beim Erstellen des Kontospeichers 

• Das LDAP-Benutzerobjektattribut enthält den Benutzernamen. Bei der Verwendung eines UPN- 

Identitätsanspruchs würde beispielweise Benutzerprinzipalname verwendet werden. 

• Basis-DN für LDAP-Suche. Diese Einstellung ist optional. Bei Angabe einer Unterstruktur beziehen 

sich ausgeführte Suchläufe auf die angegebene Unterstruktur. Anderenfalls wird die gesamte 

Verzeichnisstruktur durchsucht. 

• Identitätsansprüche. Bei der Speicherkonfiguration können Sie außerdem die Identitätsanspruchstypen 

konfigurieren, die vom AD LDS-Speicher unterstützt werden, und die in den erwarteten 

Informationen enthaltenen Benutzerattribute festlegen. 

• Clientzeitüberschreitung. Diese Einstellung ist optional. Sie bezieht sich auf die Zeit, die der Verbunddienst 

auf eine Antwort vom AD LDS-Server wartet, bevor die Verbindung aufgrund einer 

Zeitüberschreitung getrennt wird. Der Standardwert beträgt 5 Sekunden. 

Hinzufügen von Gruppenanspruchs- und benutzerdefinierten Anspruchsextrahierungen 

Nach der Konfiguration der Benutzerkonten und -gruppen enthaltenden Kontospeicher können 

Anspruchsextrahierungen festgelegt werden, um mithilfe der im LDAP-Verzeichnis gespeicherten Informationen 

einen Benutzeranspruch zu erfüllen. Beim Erstellen einer Anspruchsextrahierung wird ein mit 

einem Benutzerkonto im Kontospeicher verknüpftes Attribut einem AD FS-Anspruch zugeordnet, der 

vom AD FS-Prozess verarbeitet werden kann. 

Hinweis Das Erstellen von Anspruchsextrahierungen für Identitätsansprüche ist nicht möglich. Diese Attribute 

werden bestimmten Benutzerkonten zugewiesen. 

Es gibt zwei Anspruchsextrahierungstypen: 

• Gruppenanspruchsextrahierungen Bei Gruppenanspruchsextrahierungen wird die Mitgliedschaft 

einer Gruppe im Verzeichnisspeicher mit einem Organisationsanspruch verknüpft. Beispielsweise 

könnte die Gruppe FinanzManager aus den AD DS mit dem Organisationsanspruch FinanzMana-


ger zugeordnet werden (siehe Abbildung 19.10). Folglich verfügen die Sicherheitstoken aller 

Mitglieder der Gruppe FinanzManager über den Anspruch FinanzManager, wenn sie eine Verbindung 

mit der Webanwendung des Ressourcenpartners herstellen. 

Abbildung 19.10 Zuordnen von Gruppen aus dem Kontospeicher zu AD FS-Ansprüchen durch die 

Konfiguration einer Gruppenanspruchsextrahierung 

• Benutzerdefinierte Ansprüche Bei benutzerdefinierten Ansprüchen wird ein Attribut im Verzeichnis 

einem benutzerdefinierten Organisationsanspruch zugeordnet. Der Name des Anspruchs ist 

eine einfache Zeichenfolge, die zu der Organisation passt, die den Namen festgelegt hat. Zum Beispiel 

könnte ein Organisationsanspruch, der als Abteilung bezeichnet wird, mit dem Attribut 

Abteilung in den AD DS verknüpft werden. 

Hinzufügen eines Ressourcenpartners 

Bisher wurde der Ressourcenpartner bei der Konfiguration der AD FS für einen Kontopartner nicht 

berücksichtigt. Tatsächlich ist die Vorgehensweise bei der Konfiguration des Ressourcenpartners mit 

der des Kontopartners bis zu diesem Punkt identisch. Damit jedoch die Verknüpfung zwischen dem 

Kontopartner und dem Ressourcenpartner hergestellt werden kann, ist zunächst das Erstellen eines 

Ressourcenpartners auf dem Kontoverbundserver erforderlich. 

Zum Hinzufügen eines Ressourcenpartners gibt es zwei Methoden: 

• Manuelles Konfigurieren der Ressource über die AD FS-Konsole. 

• Importieren der Ressourcenpartnerinformationen aus einer XML-Konfigurationsdatei, die zuvor 

vom Ressourcenpartner exportiert und zur Verfügung gestellt wurde. (Die XML-Datei enthält 

lediglich die Informationen, die anderenfalls manuell eingegeben werden müssten.) 

Bei der manuellen Konfiguration eines Ressourcenpartners müssen die in der Vertrauensrichtlinie des 

Ressourcenpartners festgelegten Informationen angegeben werden. Um den Ressourcenpartner zu 

konfigurieren, erweitern Sie in der AD FS-Konsole den Knoten Partnerorganisationen, klicken mit 

der rechten Maustaste auf Ressourcenpartner, wählen Neu und klicken auf Ressourcenpartner. Im 

Assistenten zum Hinzufügen eines Ressourcenpartners müssen die folgenden Informationen angegeben 

werden (siehe Abbildung 19.11): 

• Anzeigename. 

• Verbunddienst-URI. 

• Verbunddienstendpunkt-URL. 

• Verbundszenario. Es stehen die Optionen Federated-Web-SSO und Federated-Web-SSO mit 

Gesamtstruktur-Vertrauensstellung zur Auswahl.


• Identitätsanspruch. Über diese Option wird festgelegt, ob UPN-Ansprüche, E-Mail-Ansprüche 

oder allgemeine Namensansprüche an den Ressourcenpartner gesendet werden. Es können alle 

drei, mindestens muss jedoch eine Option gewählt werden. 

• UPN-Suffixzuordnung. Bei der Verwendung von Benutzerprinzipalnamen-Suffixen besteht die 

Möglichkeit, alle Suffixe durch andere Suffixe zu ersetzen. Beispielsweise kann der Verbunddienst 

der Woodgrove Bank erfordern, dass alle Suffixe das Format WoodgroveBank.com aufweisen. 

Die Ressourcenpartnereinstellungen von Adatum können so konfiguriert werden, dass alle 

Adatum.com-UPNs durch WoodgroveBank.com ersetzt werden. 

Abbildung 19.11 Erstellen einer Seite der Vertrauensstellung zwischen den Konto- und Ressourcenpartnern durch 

die Konfiguration eines Ressourcenpartners 

Wichtig Die angegebenen Informationen müssen mit den für den Ressourcenpartner konfigurierten Informationen 

genau übereinstimmen, einschließlich der Groß- und Kleinschreibung des Verbunddienst-URIs. 

Direkt von der Quelle: Effizientere Erstellung von Verbundvertrauensstellungen mithilfe 

von Import- und Exportfunktionen 

Es lässt sich nicht leugnen: Die Einrichtung einer Verbundvertrauensstellung zwischen zwei Organisationen 

kann – aufgrund der Vielzahl an Schritten bei der manuellen Konfiguration beider Partner 

für eine erfolgreiche AD FS-Kommunikation – eine Herausforderung darstellen. In diesem Szenario 

sind beide Administratoren gleichermaßen für die Eingabe von Werten und Adressen (d.h. 

URIs, URLs und Ansprüchen) in die AD FS-Snap-Ins verantwortlich, die in der jeweiligen Verbundumgebung 

des Unternehmens eindeutig sind. 

Nach der ersten Installationsphase müssen sich die Administratoren der Organisationen diese Werte 

gegenseitig zur Verfügung stellen, damit eine Verbundvertrauensstellung ordnungsgemäß eingerichtet 

werden kann.


Selbst wenn diese Werte an den vorgesehenen Partneradministrator gesendet werden, besteht dennoch 

die Möglichkeit eines unbeabsichtigten Eingabefehlers durch den Administrator. Die Ermittlung 

der Fehlerquelle in der neuen Vertrauensstellung nach der Eingabe eines falsch oder unbeabsichtigt 

eingegebenen Wertes kann schnell mehrere Stunden dauern. 

Durch die verbesserten Funktionen in Windows Server 2008 kann jeder Partneradministrator die 

generische Vertrauensrichtlinie sowie die Partnervertrauensrichtlinie in eine kleine XML-Datei 

exportieren. Diese kann anschließend problemlos per E-Mail an den Administrator der Partnerorganisation 

übermittelt werden. Die generische Vertrauensrichtlinie enthält Werte wie Anzeigename 

des Verbundservers, URI, Verbundserverproxy-URL und alle Verifizierungszertifikatinformationen. 

Die Datei mit der Partnervertrauensrichtlinie umfasst ebenfalls Informationen zu den einzelnen 

Ansprüchen. Diese Informationen sind für die verbleibenden Schritte beim Einrichten der Verbundvertrauensstellung 

hilfreich, die durch das Importieren der Partnervertrauensrichtlinie und 

Zuordnen der Ansprüche schnell durchgeführt werden können. 

Das Exportieren der Informationen und das anschließende Versenden per E-Mail bietet dem Partneradministrator, 

der die XML-Datei empfängt, folgende Vorteile: 

• Schnellere Einrichtung einer Vertrauensstellung, da der Administrator die Inhalte der XML- 

Datei in den Assistenten zum Hinzufügen einer Partnerorganisation importieren kann. Die 

importierten Einstellungen muss der Administrator dann lediglich auf den einzelnen Seiten 

überprüfen und bestätigen. 

• Vermeidung des zusätzlichen Schritts, in dem das Kontoverifizierungszertifikat importiert werden 

muss, da dies beim Import automatisch geschieht. 

• Einfache Anspruchszuordnung 

• Verhinderung manueller Eingabefehler 

Sie können diese neue Funktion testen, indem Sie die Schrittweise Anleitung für die Active Directory-Verbunddienste 

in der Windows Server 2008-Version durcharbeiten. 

Nick Pierson 

Senior Technical Writer, Microsoft 

Hinzufügen ausgehender Anspruchszuordnungen 

Nach dem Erstellen des Ressourcenpartners können die ausgehenden Anspruchszuordnungen konfiguriert 

werden. Ausgehende Anspruchszuordnungen werden zur Umwandlung vom Kontopartner verwendeter 

interner Organisationsansprüche in Gruppenansprüche oder benutzerdefinierte Ansprüche 

genutzt, die für den Ressourcenpartner spezifisch sind. Die einzelnen Organisationen können unterschiedliche 

Namen für die Ansprüche verwenden. Beispielsweise kann Adatum über einen Organisationsanspruch 

FinanzManager und die Woodgrove Bank über einen zugehörigen Anspruch Adatum- 

FinanzManager verfügen. Durch das Erstellen der ausgehenden Anspruchszuordnung wird der 

Kontopartner-Organisationsanspruch in einen Anspruch umgewandelt, der die Anforderungen des 

Ressourcenpartners erfüllt. 

Hinweis Durch die Konfiguration ausgehender Anspruchszuordnungen kann derselbe Organisationsanspruch 

von mehreren Ressourcenpartnern genutzt werden. Der Organisationsanspruch FinanzManager 

kann beispielsweise sowohl dem Anspruch AdatumFinanzManager für die Woodgrove Bank als auch einem 

völlig anderen Anspruch für eine andere Ressourcenorganisation zugeordnet werden.


Zum Kontopartner müssen für jeden Ressourcenpartner ausgehende Ansprüche hinzugefügt werden, 

die anschließend bereits hinzugefügten Organisationsansprüchen zugeordnet werden. Um eine Zuordnung 

eines ausgehenden Gruppenanspruchs zu erstellen, klicken Sie mit der rechten Maustaste auf 

den Ressourcenpartnernamen, wählen Sie Neu und klicken Sie auf Zuordnung von ausgehenden 

Gruppenansprüchen (siehe Abbildung 19.12). Zuordnungen ausgehender benutzerdefinierter Ansprüche 

können ebenfalls erstellt werden. 

Abbildung 19.12 Zuordnen von Ansprüchen des Kontopartners zu Ansprüchen des Ressourcenpartners durch die 

Konfiguration einer ausgehenden Anspruchszuordnung 

Konfigurieren von AD FS-Komponenten des Ressourcenpartners 

Der Verbunddienst des Ressourcenpartners schützt den Zugriff auf mindestens eine Anwendungsressource. 

Der Kontoverbundserver sendet Ansprüche an den Ressourcenverbundserver, der diese extrahiert 

und prüft, ob sie zu den zulässigen eingehenden Ansprüchen gehören. Anschließend werden sie 

den eigenen Organisationsansprüchen zugeordnet und zu einem neuen Token hinzugefügt, der diese 

mit einem Tokensignaturzertifikat signiert. So können die Ansprüche an den Web-Agent gesendet 

werden, der auf dem als IIS-Server installiert ist, der als Host für die Anwendung fungiert. 

Eine Vielzahl der ersten Schritte bei der Konfiguration des Ressourcenpartners sind mit denen bei der 

Konfiguration des Kontopartners vergleichbar: 

1. Konfigurieren der Vertrauensrichtlinie. Die Konfiguration der Vertrauensrichtlinie eines Ressourcenpartners 

ist mit der Konfiguration der Vertrauensrichtlinie eines Kontopartners identisch. 

2. Konfigurieren von Organisationsansprüchen. Beim Ressourcenpartner werden die Organisationsansprüche 

verwendet, um den Zugriff auf Anwendungen zu definieren. Die Organisationsansprüche 

sind die eigentlichen Ansprüche, auf denen die Autorisierungsentscheidungen von Ansprüche 

unterstützenden Anwendungen basieren. Für die Konfiguration von Organisationsansprüchen sind 

dieselben Optionen wie bei der entsprechenden Konfiguration für den Kontopartner verfügbar. Es 

besteht die Möglichkeit, eine beliebige Anzahl an Organisationsansprüchen zu erstellen und 

anschließend einzelne oder alle für jede einzelne Anwendung zu aktivieren, die der Ressourcenverbundserver 

schützt. 

3. Konfigurieren von Kontospeichern (optional) und Anspruchsextrahierungen. In einem reinen 

B2B-Verbundszenario ist die Konfiguration eines Kontospeichers auf dem Ressourcenverbundserver 

nicht erforderlich. Wenn Mitarbeitern oder Kunden jedoch der Zugriff über den bereits installierten 

Verbundmechanismus auf dieselben Ressourcen ermöglicht werden soll, muss ein 

Kontospeicher konfiguriert und die Rolle eines Kontoanbieters angenommen werden.


Möglicherweise müssen nach der Kontospeicherkonfiguration auch die Gruppenanspruchs- und 

benutzerdefinierten Anspruchsextrahierungen konfiguriert werden, um die Verzeichnisinformationen 

an die von der Anwendung verwendeten Ansprüche anzupassen. 

Konfigurieren von Anwendungen 

Damit der Zugriff auf eine Anwendung durch einen Ressourcenverbundserver verhindert werden 

kann, muss die Anwendung für den Verbundserver definiert werden. Bei der Konfiguration einer 

Anwendung auf einem Verbundserver gibt es zwei Möglichkeiten: 

• Ansprüche unterstützende Anwendungen Beim Einrichten einer Ansprüche unterstützenden 

Anwendung sind alle Informationen zu einer bestimmten Identität in dem Token enthalten, das 

von der Anwendung bereitgestellt wird. Verfügt eine Anwendung über ein zulässiges Token, kann 

die Ansprüche unterstützende Anwendung Autorisierungsentscheidungen basierend auf den 

Ansprüchen des Tokens treffen. Daher wird für den Zugriff auf eine Ansprüche unterstützende 

Anwendung kein Benutzerkonto in den Ressourcen-AD DS benötigt. 

• Windows NT-Token-basierte Anwendung Beim Erstellen einer Windows NT-Token-basierten 

Anwendung können Sie Ansprüche in eingehenden AD FS-Token entweder Benutzerkonten oder 

-gruppen im lokalen AD DS-Benutzerspeicher des Ressourcenpartners zuordnen. Die Benutzerkonten 

oder -gruppen werden ebenfalls als Ressourcenkonten bzw. Ressourcengruppen bezeichnet. 

Anschließend werden die Ressourcenkonten oder -gruppen von der Anwendung für die 

Autorisierung verwendet. 

Weitere Informationen Weitere Informationen zur Konfiguration von Windows NT-Token-basierten Konten 

finden Sie später in diesem Kapitel im Abschnitt „Konfigurieren von AD FS für Windows NT-Token-basierte 

Anwendungen“. 

Klicken Sie zum Hinzufügen einer Anwendung mit der rechten Maustaste unter Eigene Organisation 

auf den Knoten Anwendungen, wählen Sie Neu, und klicken Sie auf Anwendung. Im anschließend 

geöffneten Assistenten zum Hinzufügen von Anwendungen müssen folgende Informationen eingegeben 

werden: 

• Anwendungstyp Zur Auswahl stehen die Ansprüche unterstützende Anwendung und die 

Windows NT-Token-basierte Anwendung. 

• Anzeigename und URL der Anwendung Die URL muss mit der tatsächlich für den Zugriff auf die 

Anwendung verwendeten URL übereinstimmen. 

• Unterstützte Identitätsansprüche Über diese Option wird festgelegt, ob die Anwendung UPN- 

Ansprüche, E-Mail-Ansprüche oder allgemeine Namensansprüche unterstützt. Es können alle 

drei, mindestens muss jedoch eine Option gewählt werden. 

Nach dem Erstellen der Anwendung kann auf die Anwendungseigenschaften zugegriffen werden. 

Diese werden für die Konfiguration des Schutzmechanismus für die Sicherheitstoken benötigt, die zur 

Anwendung gesendet werden. Standardmäßig ist die Option Public Key-Infrastruktur (PKI) aktiviert, 

d.h. der Verbunddienst schützt die Sicherheitstoken für diese Anwendung durch Tokensignaturzertifikate. 

Alternativ kann auch ein Domänendienstkonto verwendet werden. Bei Auswahl dieser Option 

verwendet der Verbunddienst zum Schutz der Sicherheitstoken für diese Anwendung eine Kerberos- 

Anforderung. Wenn diese Option gewählt wird, ist die Angabe eines Dienstprinzipalnames (Service 

Principal Name, SPN) für das Zieldienstkonto erforderlich. Bei Verwendung des AD FS-Web-Agents 

für Ansprüche unterstützende Anwendungen muss der SPN für die Identität des Anwendungspools 

der geschützten Anwendung registriert sein.


Des Weiteren kann festgelegt werden, welche Authentifizierungstypen von der Anwendung unterstützt 

werden sollen. Standardmäßig sind die Windows-integrierte Authentifizierung, die Authentifizierung 

durch Benutzername und Kennwort sowie die Zertifikats- oder TLS/SSL-Clientauthentifizierung 

aktiviert. 

Hinzufügen von Kontopartnern 

In der Regel verfügt ein Ressourcenpartner über mindestens einen konfigurierten Kontopartner. Ähnlich 

wie bei der Konfiguration eines Ressourcenpartners für den Kontopartner kann auch der Kontopartner 

manuell oder durch Importieren der vom Kontopartner exportierten Richtlinien konfiguriert 

werden. 

Kontopartner führen eine digitale Signierung des erstellten Sicherheitstokens durch. Die Token sind 

speziell für den Ressourcenverbunddienst konzipiert, um Anforderungen zu empfangen und bestimmten 

Partnern zu vertrauen. Aus diesem Grund wird für die Konfiguration des Kontopartners auf der 

Seite des Ressourcenpartners das Tokensignaturzertifikat benötigt. Bei der Konfiguration des Kontopartners 

ist die Angabe der folgenden Informationen erforderlich: 

• Anzeigename. 

• Verbunddienst-URI. 

• Verbunddienstendpunkt-URL. 

• Tokensignaturzertifikat des Kontopartners. Diese Werte werden beim Importieren der XML-Datei 

vom Kontopartner als erstes konfiguriert. Zudem kann zwischen der Verwendung des in der XML- 

Datei enthaltenen Tokensignaturzertifikats oder eines anderen Zertifikats gewählt werden. 

• Das Szenario, das gerade implementiert wird: ein Federated-Web-SSO-Entwurf oder ein Federated-Web-SSO-Entwurf 

mit Gesamtstrukturvertrauensstellung. 

• Vom Kontopartner bereitgestellte Identitätsanspruchstypen. 

• Vom Kontopartner zugelassene UPN- und E-Mail-Suffixe. 

Hinzufügen eingehender Anspruchszuordnungen 

Durch eingehende Gruppenanspruchszuordnungen werden Gruppen- oder benutzerdefinierte Ansprüche, 

die von einem Kontopartner gesendet wurden, in Ansprüche umgewandelt, die der Ressourcenpartner 

für Autorisierungsentscheidungen verwendet. Zum Beispiel kann der eingehende Anspruch 

von Adatum den Anspruch AdatumFinanzManager enthalten. Die Anwendung ist möglicherweise für 

die Verwendung des Anspruchs KundenManager konfiguriert, um die richtige Zugriffsebene für die 

Anwendung bereitzustellen. Die Konfiguration des eingehenden Anspruchs ermöglicht die Zuordnung 

des vom Kontopartner gesendeten Anspruchs zu einem Anspruch, der von der Anwendung verarbeitet 

werden kann. 

Um ausgehende benutzerdefinierte Ansprüche beim Kontopartner zu verarbeiten, können zudem 

Zuordnungen für eingehende benutzerdefinierte Ansprüche konfiguriert werden. Angenommen ein 

Kontopartner sendet ein Sicherheitstoken für einen Benutzer, das den benutzerdefinierten Anspruch 

MitarbeiterID enthält. Da der Ressourcenpartner keine auf diesem Anspruch basierende Autorisierungsentscheidungen 

treffen kann, besteht die Möglichkeit, eine Zuordnung für einen eingehenden 

benutzerdefinierten Anspruch zu konfigurieren, die den benutzerdefinierten Anspruch MitarbeiterID 

in einen als KundenID bezeichneten benutzerdefinierten Anspruch umwandelt.


Hinweis Für alle eingehenden Gruppenansprüche müssen entsprechende Zuordnungen erstellt werden, 

selbst wenn dadurch eine Transformation der Ansprüche in ihren ursprünglichen Wert stattfindet. Wenn es 

sich beim eingehenden Anspruch zum Beispiel um AdatumFinanzManager handelt und der Ressourcenpartner 

eine Benutzermitgliedschaft in der Gruppe AdatumFinanzManager verwenden kann, um Autorisierungsentscheidungen 

zu treffen, muss dennoch eine Zuordnung für den Gruppenanspruch erstellt werden. In 

diesem Fall wird die Zuordnung für den Gruppenanspruch zum Transformieren von AdatumFinanzManager 

in AdatumFinanzManager verwendet, wobei der Anspruch unverändert bleibt. 

So funktioniert es: Grundlegendes zu Ansprüchen 

Die verschiedenen Erläuterungen zu Ansprüchen können verwirren und das Verständis des Zusammenspiels 

der einzelnen Ansprüche erschweren. Abbildung 19.13 veranschaulicht die Interaktionen 

zwischen den Ansprüchen. 

Kontopartner 

Adatum 

Adatum.com 

FinanzManager 



Gruppenanspruchextrahierung 

Zuordnung ausgehender 

Ansprüche 

FinManager 

AdatumManager 

Organisationsansprüche 

Organisationsansprüche 

Zuordnung eingehender 

Ansprüche 

Finanzen 

AD-Web-Agent 

Abbildung 19.13 Weiterleitung der Ansprüche vom Kontopartner über mehrere Zuordnungen an den 


Diese Abbildung zeigt alle Vorgänge bei der Verwendung von Organisationsansprüchen. In diesem 

Beispiel haben die AD FS-Administratoren von Adatum den Organisationsanspruch Manager 

erstellt und anschließend die AD DS-Gruppe FinanzManager mithilfe einer Gruppenanspruchsextrahierung 

mit dem Organisationsanspruch Manager verknüpft.


Da die Woodgrove Bank jedoch die Finanz-Manager von unterschiedlichen Organisationen unterscheiden 

muss, ist es erforderlich, dass alle Ansprüche für die Finanz-Manager von Adatum als 

AdatumManager gekennzeichnet werden. Daher müssen die Administratoren von Adatum eine 

Zuordnung für den ausgehenden Gruppenanspruch erstellen, über die der Organisationsanspruch 

Manager dem Anspruch AdatumManager zugeordnet wird. 

Wenn bei einem Partner eine Anspruchszuordnung erstellt und benannt wird, ist es wichtig, dass 

für die Anspruchszuordnung beim anderen Partner genau derselbe Name vergeben wird. In diesem 

Szenario wird beispielsweise bei Adatum eine Zuordnung des ausgehenden Gruppenanspruch für 

AdatumManager erstellt. Bei der Woodgrove Bank muss eine Zuordnung für den eingehenden 

Gruppenanspruch konfiguriert werden, die ebenfalls den Namen AdatumManager verwendet. Der 

gemeinsam genutzte Name für den Anspruch stellt die Verbindung zwischen den beiden Verbundservern 

dar. 

Die Webanwendung der Woodgrove Bank wurde so konfiguriert, dass ein Anspruch mit dem 

Namen Finanzen für Autorisierungsentscheidungen eingesetzt wird. Daher müssen die AD FS- 

Administratoren der Woodgrove Bank einen eingehenden Gruppenanspruch konfigurieren, der den 

Anspruch AdatumManager zulässt und in einen Anspruch namens Finanzen für die Webanwendung 

transformiert. 

Schließlich erhalten die Mitgliedern der AD DS-Gruppe FinanzManager bei Adatum alle Zugriffsrechte, 

die dem Anspruch Finanzen auf dem Webserver der Woodgrove Bank zugewiesen wurden. 

Zuordnungen ausgehender und eingehender Gruppenansprüche bilden eine Abstraktionsebene zwischen 

den beiden Verbundpartnern. Es kann zum Beispiel sein, dass der Kontopartner die internen 

AD DS-Gruppennamen dem Verbundpartner nicht ohne weiteres mitteilen möchte. Zudem möchte 

der Verbundpartner die von eigenen Anwendungen verwendeten internen Anspruchsdetails möglicherweise 

nicht gemeinsam mit dem Kontopartner nutzen. Die interne AD DS-Gruppenstruktur 

wird bei der Konfiguration einer Zuordnung für einen ausgehenden Anspruch auf der Seite des 

Kontopartners ausgeblendet. Auch auf der Seite des Ressourcenpartners sind die Anwendungsansprüche 

nicht sichtbar, wenn eine Zuordnung für einen eingehenden Anspruch konfiguriert wird. 

Der Ressourcenpartner und Kontopartner müssen sich lediglich auf den Namen und die Autorisierungsanforderungen 

des Anspruchs einigen, der zwischen den Organisationen übermittelt wird. 

Konfigurieren von AD FS für Windows NT-Token-basierte Anwendungen 

Ein Großteil der bisherigen Beschreibungen zur Implementierung der Active Directory-Verbunddienste 

betraf deren Konfiguration für die Verwendung einer Ansprüche unterstützenden Anwendung. 

Eine Vielzahl an Organisationen verfügt jedoch bereits über Windows NT-Token-basierte 

Anwendungen, und es würde einige Zeit in Anspruch nehmen, um diese Anwendungen alle in 

Ansprüche unterstützende Anwendungen umzuprogrammieren. Dieser Abschnitt enthält Details zur 

Konfiguration von Active Directory-Verbunddiensten für die Verwendung von Windows NT-Tokenbasierten 

Anwendungen. 

Eine direkte Verarbeitung von AD FS-Ansprüchen durch Windows NT-Token-basierte oder Legacy- 

Anwendungen ist nicht möglich. Stattdessen werden alle Ressourcen auf dem Webserver durch 

Zugriffsteuerungslisten gesichert, die die SIDs für Sicherheitsprinzipale aus der AD DS-Gesamtstruktur 

der Ressource oder aus einer vertrauenswürdigen Gesamtstruktur enthalten. Das bedeutet, dass der 

Web-Agent, der eine Token-basierte Anwendung schützt, den Anspruch vom Ressourcenverbundserver 

zulassen muss.


Anschließend verwendet der Web-Agent die Informationen im Anspruch zur Suche nach einem zugehörigen 

AD DS-Benutzerkonto oder einer zugehörigen Benutzergruppe. Mithilfe des AD DS-Kontos 

erstellt der Web-Agent dann ein Zugriffstoken und gewährt basierend auf der Benutzer- oder Gruppenkonto-SID 

entsprechende Berechtigungen. 

Für den Zugriff auf Token-basierte Anwendungen ist die Konfiguration der Organisationsansprüche 

auf dem Ressourcenverbundserver erforderlich, auf dem der Organisationsanspruch einem Ressourcenbenutzer 

oder einer Ressourcengruppe zugeordnet wird. Bei der Woodgrove Bank kann zum 

Beispiel der Organisationsanspruch KundenManager der Gruppe KundenManager@Woodgrove- 

Bank.com zugeordnet werden (siehe Abbildung 19.14). 

Abbildung 19.14 Verwenden des Anspruchs durch Token-basierte Anwendungen über die Zuordnung einer 

Ressourcengruppe zu einem Organisationsanspruch 

Ressourcenbenutzer- bzw. Ressourcengruppenkonten können auf zwei Arten für den Zugriff auf 

Token-basierte Anwendungen implementiert werden: 

• Verwenden von Benutzer- und Gruppenkonten aus der Gesamtstruktur, in der der AD FS-Ressourcenverbundserver 

installiert ist, oder aus einer vertrauenswürdigen Domäne. Diese Option ist in 

einer B2E-Bereitstellung hilfreich, da die Mitarbeiter wahrscheinlich über Konten in der Gesamtstruktur 

verfügen, in der sich bereits die Active Directory-Verbunddienste befinden. Möglicherweise 

nutzen sie für die Authentifizierung gegenüber anderen webbasierten Ressourcen dieselben 

Anmeldeinformationen. Darüber hinaus kann diese Option gewählt werden, wenn ein Federated- 

Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung verwendet wird, da die Gesamtstruktur 

des Umkreisnetzwerks den Benutzerkonten aus der internen Gesamtstruktur vertraut. 

• Verwenden von Ressourcenbenutzer- und Ressourcengruppenkonten. Das Erstellen von Ressourcenkonten 

und -gruppen in der Ressourcengesamtstruktur dient dem Zweck, die Autorisierung 

gegenüber Token-basierten Anwendungen zu ermöglichen. Bei der Verwendung von Ressourcenbenutzer- 

und Ressourcengruppenkonten werden die Konten nicht für die Authentifizierung eingesetzt – 

eine Benutzerauthentifizierung gegenüber dem Kontoverbundserver ist weiterhin erforderlich und 

auch der normale Vorgang zum Erstellen von Ansprüchen findet nach wie vor Anwendung.


Eine Besonderheit bei der Verwendung von Ressourcenkonten ist, dass möglicherweise viele unterschiedliche 

Ressourcenkonten erstellt werden müssen, wenn die Organisation über mehrere Tokenbasierte 

Anwendungen verfügt und die Kontopartner über viele verschiedene Benutzerkonten auf die 

Anwendung zugreifen. Zur Vereinfachung dieses Prozesses bieten die Active Directory-Verbunddienste 

die folgenden Ressourcenkontomethoden: 

• Ressourcenkonten Bei dieser Methode wird ein in Active Directory erstellter Sicherheitsprinzipal 

(normalerweise ein Benutzerkonto) für die Zuordnung zu einem einzelnen Verbundbenutzer 

eingesetzt. Diese Option bietet zwar eine genaue Zugriffssteuerung auf Benutzerebene, erfordert 

aber auch die Erstellung eines eindeutigen Ressourcenkontos für jeden Benutzer, der auf die 

Anwendung zugreifen wird. 

• Ressourcengruppen Bei dieser Methode wird eine in AD DS erstellte Sicherheitsgruppe eingehenden 

Gruppenansprüchen zugeordnet. Der Implementierungsaufwand bei dieser Methode ist 

geringer, da nicht für jeden Verbundbenutzer separate Ressourcenkonten erstellt und verwaltet 

werden müssen. Eine Ressourcengruppe kann eine unbegrenzte Anzahl an Verbundbenutzern 

unterstützen, die dieser zugeordnet sind. Der entscheidende Nachteil dieser Methode ist, dass 

eine Zugriffssteuerung einzelner Benutzer durch die Ressourcenorganisation nicht möglich ist und 

darauf vertraut werden muss, dass die Kontoorganisation ausschließlich geeignete Benutzer zum 

Gruppenanspruch hinzufügt. 

• Gruppe-zu-UPN-Zuordnung Bei dieser Methode wird eine Gruppe von Verbundbenutzern dem in 

der Ressourcengesamtstruktur erstellten UPN eines Benutzerkontos zugeordnet. Es nicht mehr 

erforderlich, für jeden Verbundbenutzer separate Ressourcenkonten zu erstellen und zu verwalten. 

Die mangelnde Granularität bei der Überwachung ist der primäre Nachteil dieser Option. Da 

mehrere Benutzer über dieselbe Gruppe auf die Anwendung zugreifen werden, ist eine Überwachung 

einzelner Benutzerzugriffe nicht möglich. 

Hinweis Eine Möglichkeit, um den Verwaltungsaufwand für die Ressourcenkonten zu verringern, ist der 

Einsatz eines Identitätsbereitstellungstools wie Microsoft Identity Lifecycle Manager 2007 (ILM), mit dem die 

benötigten Konten automatisch erstellt werden können. Die Verwendung eines Transformationsmoduls für 

Ansprüche ist eine weitere Möglichkeit, um Konten automatisch zu erstellen und diese nach Beendigung der 

Sitzung wieder zu entfernen. 

Zur Implementierung von Ressourcengruppen ist möglicherweise das Hinzufügen von UPN-Suffixen 

zur Ressourcengesamtstruktur erforderlich. Wenn zum Beispiel Benutzer in der Gesamtstruktur 

WoodgroveBank.com den UPN Benutzer@WoodgroveBank.com verwenden, der keinem bereits zugelassenem 

UPN in der Ressourcengesamtstruktur zugeordnet ist, muss der UPN WoodgroveBank.com 

zur Ressourcengesamtstruktur hinzugefügt werden. 

Implementieren eines Web-SSO-Entwurfs 

Der Web-SSO-Entwurf ist im Vergleich zum Federated-Web-SSO-Entwurf weniger komplex, da er 

nur die folgenden Komponenten umfasst: 

• Ein Verbundserver (erforderlich). Der Verbundserver fungiert in diesem Entwurf als Kontopartner 

und auch als Ressourcenpartner. 

• Ein Verbundserverproxy (in dieser Bereitstellung optional). 

• Ein Webserver mit installiertem AD FS-Web-Agent und einer installierten Ansprüche unterstützenden 

oder Windows NT-Token-basierten Anwendung (erforderlich).


Die Installation des Web-SSO-Entwurfs erfordert die folgenden Schritte: 

1. Vorbereiten der Umgebung. Dieser Schritt umfasst die Installation der Serverrolle Webserver (IIS) 

auf jedem Computer und die Konfiguration der Webserverzertifikate sowie der Rollendienste Verbunddienst 

und Verbunddienstproxy. 

2. Konfigurieren des Verbundservers anhand der folgenden Schritte: 

a. Konfigurieren der Vertrauensrichtlinie. Die Schritte stimmen mit denen zur Konfiguration der 

Vertrauensrichtlinie im Federated-Web-SSO-Entwurf überein. 

b. Konfigurieren der Organisationsansprüche. Der Verbundserver fungiert im Web-SSO-Entwurf 

als Kontopartner und auch als Ressourcenpartner. Folglich werden die Organisationsansprüche 

entweder über die AD DS oder die AD LDS gefüllt. 

c. Hinzufügen und Konfigurieren von Kontospeichern. Die Benutzerkonten müssen entweder 

in den AD DS oder den AD LDS gespeichert werden. Daher muss mindestens ein Kontospeicher 

zum Verbundserver hinzugefügt werden. Sobald Benutzer auf die Anwendung zugreifen, 

werden diese gegenüber dem Kontospeicher authentifiziert, um die Erstellung des Sicherheitstokens 

zu starten. 

d. Erstellen von Anspruchszuordnungen für die Anwendung. Der Organisationsanspruch muss 

Ansprüchen zugeordnet werden, die von der Anwendung verarbeitet werden können. Ähnlich 

wie beim Federated-Web-SSO-Entwurf ist bei Verwendung von Windows NT-Token-basierten 

Anwendungen die Einrichtung von Ressourcengruppen erforderlich. Hierzu können AD 

DS-Konten in der Gesamtstruktur, in der der Verbundserver bereitgestellt ist, oder Ressourcenkonten 


e. Hinzufügen und Konfigurieren einer Anwendung. Wie der Ressourcenpartner ermöglicht die 

Anwendung den Zugriff auf die freigegebene Ressource. Die Anwendung muss dem Verbunddienst 

hinzugefügt werden, sodass der Verbundserver Clientanforderungen an den entsprechenden 

Webserver umleiten kann. 

Implementieren eines Federated-Web-SSO-Entwurfs mit 


Bei der AD FS-Bereitstellung besteht ebenfalls die Möglichkeit, den Federated-Web-SSO-Entwurf 

mit Gesamtstrukturvertrauensstellung zu implementieren. Der Federated-Web-SSO-Entwurf mit 

Gesamtstrukturvertrauensstellung wird weiterhin – wie dies auch bei der Web-SSO-Bereitstellung der 

Fall ist – hauptsächlich für B2E- bzw. B2C-Bereitstellungen verwendet, allerdings erfordert er zwei 

AD DS-Gesamtstrukturen und ist somit komplexer. Der Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung 

wird hauptsächlich verwendet, um den Einsatz von Windows NT-Tokenbasierten 

Anwendungen zu ermöglichen, die Autorisierungsentscheidungen anhand von Benutzeranmeldeinformationen 

aus der internen Gesamtstruktur treffen. Bei Verwendung einer Gesamtstrukturvertrauensstellung 

ist die Erstellung von Ressourcenbenutzer- oder Ressourcengruppenkonten im 

Umkreisnetzwerk der AD DS-Gesamtstruktur nicht mehr erforderlich. 

Ein Federated-Web-SSO-Entwurf mit Gesamtstrukturvertrauensstellung erfordert die folgenden 

Komponenten: 

• Zwei Verbundserver. In diesem Entwurf fungiert eine Verbundserver als Kontopartner und ein 

zweiter Verbundserver als Ressourcenpartner. Obwohl sich beide Verbundserver in derselben Organisation 

befinden, werden sie in separaten Gesamtstrukturen bereitgestellt. Verbundserverproxys 

sind in dieser Bereitstellung optional.


• Zwei AD DS-Gesamtstrukturen. Eine unidirektionale (oder bidirektionale) Gesamtstrukturvertrauensstellung, 

die so konfiguriert ist, dass die externe Gesamtstruktur der internen Gesamtstruktur 

vertraut. 

• Ein Webserver mit installiertem AD FS-Web-Agent und einer installierten Ansprüche unterstützenden 

oder Windows NT-Token-basierten Anwendung. 

Die Bereitstellung des Federated-Web-SSO-Entwurfs mit Gesamtstrukturvertrauensstellung erfordert 

die folgenden Schritte: 

1. Vorbereiten der Umgebung. Dieser Schritt umfasst die Installation der Serverrolle Webserver (IIS) 

auf jedem Computer und die Konfiguration der Webserverzertifikate sowie der Rollendienste 

Verbunddienst und Verbunddienstproxy. 

2. Konfigurieren einer Gesamtstrukturvertrauensstellung zwischen der Gesamtstruktur des 

Umkreisnetzwerks und der internen Gesamtstruktur. Mithilfe dieser Vertrauensstellung können 

Windows NT-Token-basierte Anwendungen Autorisierungsentscheidungen treffen, die auf internen 

AD DS-Konten basieren. 

3. Konfigurieren des Kontoverbundpartners. In diesem Szenario dient der Kontoverbundpartner als 

Verbundserver, der sich im internen Netzwerk befindet und auf einem Server ausgeführt wird, der 

ein Mitglied der internen AD DS-Gesamtstruktur ist. Die Konfiguration des Verbunddienstes 

erfordert die folgenden Schritte: 

a. Konfigurieren der Vertrauensrichtlinie. 

b. Konfigurieren der Organisationsansprüche. Die Informationen zum Füllen der Organisationsansprüche 

werden aus der internen AD DS-Gesamtstruktur abgerufen. 

c. Hinzufügen und Konfigurieren von Kontospeichern. Die Benutzerkonten werden in der internen 

AD DS-Gesamtstruktur gespeichert, daher muss der standardmäßige AD DS-Kontospeicher 

zum Verbundserver hinzugefügt werden. 

d. Konfigurieren der Organisationsgruppen- oder benutzerdefinierten Anspruchsextrahierungen. 

AD DS-Gruppen müssen den entsprechenden Organisationsgruppenansprüchen oder benutzerdefinierten 

Ansprüchen zugeordnet werden. 

e. Hinzufügen und Konfigurieren eines Ressourcenpartners. In diesem Fall handelt es sich beim 

Ressourcenpartner um den Verbundserver in der Gesamtstruktur des Umkreisnetzwerks. 

f. Erstellen von Zuordnungen ausgehender Ansprüche für den Ressourcenpartner. Organisationsansprüche 

werden Ansprüchen zugeordnet, die von der Ressourcenpartneranwendung verarbeitet 


4. Konfigurieren des Ressourcenverbundpartners. In diesem Szenario dient der Ressourcenverbundpartner 

als Verbundserver, der sich im Umkreisnetzwerk befindet und auf einem Server ausgeführt 

wird, der ein Mitglied der AD DS-Gesamtstruktur des Umkreisnetzwerks ist. Die 

Konfiguration des Verbunddienstes erfordert die folgenden Schritte: 

a. Konfigurieren der Vertrauensrichtlinie. 

b. Konfigurieren der Organisationsansprüche. 

c. Hinzufügen und Konfigurieren einer AD FS-Anwendung. Obwohl die Verwendung von 

Ansprüche unterstützenden Anwendungen in diesem Szenario möglich ist, handelt es sich bei 

den meisten Anwendungen wahrscheinlich um Windows NT-Token-basierte Anwendungen. 

d. Hinzufügen und Konfigurieren eines Kontopartners. 

e. Erstellen einer Zuordnung eingehender Ansprüche für die Anwendung.


f. Bereitstellen der Anwendung auf den Webservern. 

g. Zuweisen von Zugriffsteuerungsrechten zu Verbundbenutzerkonten. 


Die Active Directory-Verbunddienste bieten eine Möglichkeit, Netzwerkauthentifizierungs- und 

Autorisierungsdienste von AD DS ebenfalls Benutzern außerhalb der Organisation bereitzustellen. 

Mithilfe der AD FS lassen sich webbasierte Anwendungen bereitstellen, für die ein SSO-Zugriff eingerichtet 

werden kann. Daher ist es nicht erforderlich, dass alle Benutzer über ein Benutzerkonto in 

der internen AD DS-Gesamtstruktur verfügen. Dies ermöglicht Szenarien für die Zusammenarbeit mit 

anderen Organisationen, Kunden oder Remotemitarbeitern, die von außerhalb der Organisation auf 

Anwendungen zugreifen. 


• Stellen Sie Verbundserver bereit, die die interne AD DS-Gesamtstruktur als Kontospeicher im 

internen Netzwerk nutzen. Dies ist wichtig, da Verbundserver autorisiert sind, Sicherheitstoken zu 

erteilen. Aus diesem Grund sollten für Verbundserver dieselben Schutzmaßnahmen ergriffen werden 

wie für Domänencontroller. Des Weiteren sollten Sie zum Schutz des Verbundservers zusätzlich 

Verbundserverproxys im Umkreisnetzwerk bereitstellen. 

• Deaktivieren Sie als weitere Sicherheitsmaßnahme alle Ressourcenbenutzerkonten. Ist dies nicht 

möglich, sollten alle Ressourcenbenutzerkonten zu einer Sicherheitsgruppe hinzugefügt und die 

Berechtigung der Sicherheitsgruppe so festgelegt werden, dass eine lokale Anmeldung auf dem 

AD FS-Webserver nicht zulässig ist. 


• Kapitel 18, „Active Directory-Rechteverwaltungsdienste“, beschreibt die Integration der AD FS in 

die AD RMS. Dieses Feature ermöglicht die Verwendung der mit den AD FS verbundenen Identitäten 

in einer AD RMS-Bereitstellung, um Daten bei der Übermittlung zwischen Organisationen zu 

schützen. 

• Informationen zu Entwürfen und Bereitstellungen sowie eine Schrittanleitung für die AD FS- 

Implementierung in einer Testumgebung finden Sie auf der Website „Active Directory-Verbunddienste“ 

in der technischen Bibliothek zu Windows Server 2008 unter http://technet2.microsoft.com/windowsserver2008/de/servermanager/activedirectoryfederationservices.mspx. 

• Weitere Informationen zur Konfiguration von AD FS in Zusammenhang mit anderen 

Identitätsverbundprodukten wie IBM Tivoli Federated Identity Manager und CA SiteMinder 

Federation Security Services finden Sie auf der englischsprachigen Website „Active Directory 

Federation Services“ im Windows Server 2003-TechCenter. Diese Website finden Sie unter 

http://technet2.microsoft.com/windowsserver2008/de/servermanager/activedirectoryfederationservices.mspx. 

• Das Entwurfs- und Bereitstellungshandbuch für Active Directory-Verbunddienste steht unter 

http://www.microsoft.com/downloads/details.aspx?FamilyID=b92ea722-0c30-4ea6-bd45- 

7e5934b870cf&DisplayLang=en in englischer Sprache zum Download bereit. Es enthält detaillierte 

Informationen zu Entwurf und Bereitstellung einer AD FS-Implementierung, wie z.B. die 

Bereitstellung mehrerer Server in einer Verbundserverfarm-Konfiguration.


• Das englischsprachige Handbuch „Configure Web SSO authentication by using AD FS (Office 

SharePoint Server)“ finden Sie unter http://technet2.microsoft.com/Office/en-us/library/61799f9ada01-4c11-b930-52e5114324451033.mspx?mfr=true. 

Dieses Dokument enthält Erläuterungen zur 

Konfiguration von Microsoft Office SharePoint Server 2007 für die Verwendung mit den Active 

Directory-Verbunddiensten. 

• Detaillierte Informationen zur Problembehandlung finden Sie im Bereich „Active Directory Federation 

Services“ auf der englischsprachigen Website zur Problembehandlung für Windows Server 

2008 unter http://technet2.microsoft.com/windowsserver2008/en/library/acc299c9-3bff-4c2db4af-78d772012b101033.mspx?mfr=true. 


• Die Excel-Tabelle AD FS Documentation.xls dient als Vorlage für die Dokumentation der AD FS- 

Bereitstellung in Ihrer Organisation. 


• „AD FS-Problembehandlung“ in der Produkthilfe zu den Active Directory-Verbunddiensten 

• „AD FS-Terminologie“ in der Produkthilfe zu den Active Directory-Verbunddiensten

777 

Stichwortverzeichnis 

1:1-Zuordnung von Zertifikaten 292 

A 

Abgelehnte RODC-Kennwortreplikationsgruppe 208 

Abgesicherter Modus 588 

Abhängige Dienste, anhalten 8 

Ablaufzeit, Tombstone 103 

Abmeldecookies 746 

Abteilungsübergreifende Kommunikation 153 

Abwärtskompatibilität 276, 298 

Active Directory Application Mode (ADAM) 14, 735, 746 

Active Directory Lightweight Directory Services (AD 

LDS) 145, 611 

AD DS-Synchronisierung 643 

empfohlene Vorgehensweisen 646 

gespeicherte Konten 735 

implementieren 630 

Konfigurieren von Instanzen und Partitionen 630 

Replikationskonfiguration 638 

Sicherung und Wiederherstellung 640 

Verwaltungstools 633 

Instanzen in 615 

Kontopartner und 746 

Replikation 620 

Server in 614 

Sicherheit für 624 

Authentifizierung 628 

Berechtigungen 626 

Sicherheitsprinzipale 624 

Standardgruppen 625 

Tools für die 647 

Überblick 612 

Verzeichnispartitionen in 616 

Anwendungen 619 

Konfiguration 616 

Schema 617 

Active Directory Lightweight Directory Services, Setup-Assistent 

618, 630, 631, 632, 633, 638, 639, 647 

Active Directory Management Pack 136 

Active Directory Service Interface (ADSI) 35, 60, 383 

Active Directory-Anwendungsmodus-Setup-Assistent 617, 

623 

Active Directory-Benutzer und -Computer, Snap-In 

AD-Datenbankbereitstellungstool und 601 

angezeigte Attribute 37 

bei der Migration 256 

benutzerdefinierte Anpassung von MMC-Snap-In für Administratoren 

347 

Benutzerprofile und 458, 459 

Domänenkonfiguration und 60 

Domänenverzeichnispartition und 42 

für GPC-Objekt 400 

inetOrgPerson-Objekt, erstellt von 358 

Infrastrukturmaster und 252 

Objektanzeige über 323 

PDC-Emulator, Übernehmen der Rolle 604 

resultierende PSOs und 521 

RODC-Bereitstellung 235 

Überprüfen der Installation 230 

Überwachung aktiviert 306 

zum Ändern des Objektzugriffs 323 

zum Zuordnen von Zertifikaten 293 

zwischengespeicherte Anmeldeinformationen 26, 207 

Active Directory-Clienterweiterung 298, 299 

Active Directory-Diagnosetool 252, 253 

Active Directory-Dienste 11 

Active Directory Lightweigt Services, Rolle 14 

Rechteverwaltungsdienste, Rolle 15 

Verbunddienste, Rolle 13 

Zertifikatdienste, Rolle 11 

Active Directory-Domänen und -Vertrauensstellungen, Snap- 

In 29, 60, 255, 261, 357 

Active Directory-Domänendienste (AD DS) Siehe auch Verwaltung, 

delegieren; Domain Name System (DNS); Installieren 

der AD DS; Migrieren auf AD DS; 3 

AD LDS-Synchronisierung 643 

Datenbankbereitstellungstool in 9 

fein abgestimmte Kennwortrichtlinien in 7 

gespeicherte Konten 735 


neustartfähig 8 

Rechteverwaltungsdienste (RMS) und 696 

schreibgeschützter Domänencontroller (RODC) 3 

überwachen 6 

Verbesserungen der Benutzeroberfläche 9 

Active Directory-Domänendienste (AD DS), Komponenten 

19 

Betriebsmaster 28 

Domänenname 29 

Infrastruktur 31 

PDC-Emulator 30 

RID (Relative ID) 30 

Schema 28 

Übertragen von Rollen 31 

Datenspeicher 20 

Domänen 45 

Domänencontroller 22 

Gesamtstrukturen 49 

globale Katalogserver 22 

Organisationseinheiten 56 

Partitionen 41 

Schema 32 

ändern 34 

Deaktivieren von Objekten 39 

Komponenten 32 

neue Attribute 36 

schreibgeschützte Domänencontroller 25 

Standorte 54

778 Stichwortverzeichnis 

Active Directory-Domänendienste (AD DS), Komponenten 

(Fortsetzung) 

Tools 59 

Vertrauensstellungen 50 

Active Directory-Domänendienste (AD DS), Struktur 141 

Dienstanforderungen 142 

dokumentieren 148 

funktionelle Anforderungen 144 

geschäftliche Anforderungen 143 

Projekteinschränkungen 147 

rechtliche Anforderungen 145 

Sicherheit 146 

Vereinbarungen zum Servicelevel 144 

DNS-Infrastruktur 180 

Integration in 185 

interne und externe Namespaces 181 

Optionen für 182 

Domänenfunktionsebenen 178, 180 

Domänenstruktur 169 

Besitz 177 

Domänenanzahl 171 

Hierarchieänderungen nach der Bereitstellung 177 

Stammdomäne der Gesamtstruktur 173 

Strukturen und Vertrauensstellungen 175 


Entwurf der Standorttopologie 193 

Exchange Server 2007 und 199 

DNS-Serverstandort und 201 

Domänencontrollerstandort und 203 

Entwurf des schreibgeschützten Domänencontrollers 

(RODC) 205 

Standort des globalen Katalogservers 204 

Standorte der Betriebsmasterserver 208 


Gesamtstrukturentwurf 154 

Besitz 163 

einzelne oder mehrere 157 

Integration, mehrere 164 

Modelle 161 

Richtlinien zur Änderungskontrolle 164 



Gesamtstrukturfunktionsebenen 179 

Struktur von Organisationseinheiten 188 

Active Directory-Migrationsprogramm (ADMT) 245, 247, 

255 

Active Directory-Schema, MMC-Snap-In 23, 31, 35, 251 

Active Directory-Standorte und -Dienste, Snap-In 60 

AD LDS und 640, 647 

Konsistenzprüfung (KCC) und 110 

Objektanzeige über 323 

RCP-über-IP-Verbindungen und 127 

zur Problembehandlung bei der Replikation 133, 138 

Active Directory-Verbunddienste Siehe Verbunddienste 

Active Directory-Zertifikatdienste (AD CS) 128, 292, 747 

ActiveX Data Objects (ADO) 383 

Adamsync-Synchronisierung 644 

ADDS DesignDocument.xlsx 164, 180, 193, 199 

Administrative Autonomie 159, 160, 171, 248 

Administrative Isolation 160, 162, 209 

Administrative Vorlagen Siehe Vorlagen 

Administratoren 726 

Administratoren (Gruppe) 160 

Administratorgruppen, OU 160 

Administratorrechte 216 

Administratorrolle, Trennung der 5, 27 

ADML-Dateien 472 

ADMT-Assistent zum Migrieren von Gruppenkonten 256, 

257 

ADMX Migrator 476 

ADMX-Dateien Siehe auch Vorlagen, 398, 472, 473, 474 

Adprep.exe, Befehlszeilentool 8, 246, 251, 358 

AdRestore, Tool 598, 607 

ADSchemaAnalyzer 644 

ADSI Edit, Tool 73, 323 


für Active Directory-Objekte 353, 388, 390 

für GPC-Objekt 400 

für PSOs 519, 521 

in AD LDS 625, 633, 635 

Notfallwiederherstellung 607 

Sammlung veralteter Objekte 567 

Skripts und 565 

Standortverknüpfungen und 125, 126 

Advanced Encryption Services (AES) 179 

AES-Algorithmus 673 

Aktivierung 

Aktivierungsdienst für Windows-Prozesse 661 

Außerkraftsetzen des RMS-Clusters 709 

Dateierweiterung 480, 489 

Aktivierungsdienst für Windows-Prozesse 661, 666 

Aktualisierungen, dynamisch 87, 186 

Aktualisierungsarten, für Replikation 95 

Aktualitätsvektoren 97, 100 

Allgemeine Namensansprüche 758 

Alterung, Einträge 75, 77 

American National Standards Institute (ANSI) 38, 39 

Änderungsbasierte Überwachung 565 

Änderungsstempel, bei der Replikation 97, 101 

Anfang, Kerberos-Ticketflag 285 

Anfrage/Antwort-Authentifizierung 298 

Angriffsfläche verringern, Sicherheit 300 

Ankündigen von Anwendungen 480 

Anmeldeinformationen 

AD DS und 146, 216 

AD DS-Installations-Assistent und 10 

bei der Zugriffssteuerung 321 

für sicherheitsrelevante Konten 314 

in AD LDS 639 

in Verbundvertrauensstellungen 13 

RODC, administrative 206 

servergespeichert 680, 688 

zwischenspeichern 4, 25, 206, 207 

Anmeldeinformationsverwaltung 511 

Anmeldezeitstempel 178 

Anonyme Authentifizierung 628 

Anonyme SID-/Namensübersetzung 510 

Ansprüche 

Anwendungen, unterstützend 737 

ausgehende zuordnen 762

Stichwortverzeichnis 779 

Extrahierungen 760 

Identität 762 

unterstütztender Agent 14 

Verbund 737 

Antragstellername in Zertifikaten 685 

Anwendungen 

AD LDS-Verzeichnispartitionen für 619 

Ansprüche unterstützend 737 

Basisgruppen für 360, 361 

DNS-Partitionen für 75 

Domänencontrollersicherung und 581 

Ereignisanzeige und 560 

Gruppenrichtlinien für die Bereitstellung von 479 

in Federated-Web-SSO-Szenario 752 

interne Webanwendungen 658 

Kompatibilität 208 

Organisationseinheiten basierend auf 192 

Public Key-fähig 655 

spezifische Datenverwaltung für 320 

Standardpartition 73 

standortabhängig 482 

verzeichnisfähig 152 

Verzeichnispartitionen für 29, 43, 114, 235, 624 

Windows NT-Token-basiert 737, 742, 744 

ZAP-Datei (Zero Administration for Windows Down-Level 

Application Package) 483 

Anwendungsbezogene Rolle 3 

Anwendungsprogrammierschnittstellen (APIs) 651 

Anwendungsrichtlinien, Erweiterung 685 

Anzeigenamen 34, 355, 356 

Arbeitsstationen, Organisationseinheiten 192 

Archivierte Vorlagen für Benutzerrechterichtlinien 720 

ASP.NET-Anwendungen 14 

Assistent zum Installieren von Active Directory-Domänendiensten 

221 

Abschließen der Installation 229 

Bereitstellungskonfiguration und 222 

Betriebsmaster und 32 

Dateispeicherorte 228 

Deinstallieren der AD DS über 235 

Delegierungseintrag 80, 84 

DNS-Konfigurationsfehler 227 

Domänenaktualisierung 250 

Domänencontrolleroptionen 227 


Kennwortrichtlinienerzwingung 229 

Ntds.dit-Datei 22 

Optionsauswahl 230 

RODCs und 27 

Starten der AD DS-Installation 218, 220 


vollqualifizierter Domänename (FQDN) 223 

Windows Server 2008-Funktionsebenen 224 

Asymmetrische Verschlüsselung 649 

Asynchrone Verarbeitung von GPOs 407 

Attribute 

ändern, für Objekte 96 

Anspruchsextrahierungen 760 

classSchema-Objekt 33 

crossRef-Klasse 48 

displayName 34 

erstellen in Schema 36 

fSMORoleOwner 29 

globaler Katalog und 23 

in Benutzerobjekten 352 

indizieren 34 

isDeleted 102 

LdapDisplayName 39 

msDS-AuthenticatedToAccountList 26 

msDS-DnsRootAlias 29 

msDS-NeverRevealGroup 26 

msDS-RevealedList 26 

msDS-Reveal-OnDemandGroup 26 

msDS-UpdateScript 29 

Name 96 

RODC-Filter 4 

Schemadefinition 32 

SIDHistory 167 

userAccountControl 8 

USNChanged 98, 100 

verknüpft 96, 103 

von Kennworteinstellungsobjekten (PSOs) 7, 520 

von Kontosperreinstellungen 7 

Attribut-Editor 400 

Auditpol.exe, Befehlszeilentool 6, 305, 342, 344 

Aufbewahrungsmethode zum Archivieren von Protokollen 

307 

Aufgaben 

Delegieren administrativer Rechte 320, 338 

Warnungstask 551 

Zeitplanung 379 

Aufgaben der Erstkonfiguration, Assistent für 218 

Aufräumvorgänge, Einträge 75, 77 

Ausgehandelte Authentifizierung 289, 628, 629 

Ausgehende Ansprüche, zuordnen 762 

Ausgewählte Authentifizierung 162, 165, 179 

Ausschlussrichtlinien, RMS 725 

Ausstellungsrichtlinien für Zertifikate 686 

Authentifizierte Benutzer (Gruppe) 76, 166 

Authentifizierung Siehe auch Kerberos-Authentifizierung; 

Kerberos-Sicherheit 

AD DS-Infrastruktur und 141 

Anfrage/Antwort-Mechanismus 298 

ausgewählt 162, 165, 179 

Computerobjekte für 370 

Cookies 745 

delegiert 286 

digitale Zertifikate 649 


Domänencontroller für 22 

Extranetspeicher für 15, 613 

Firewalls für 166 

gesamtstrukturweit 263 

Grenzen für Sicherheitsrichtlinien 45 

grenzenübergreifend 285 

in AD LDS 623, 628 

in verkabelten Netzwerken, Sicherheit 530 

Kontopartner 747 

LAN-Manager-Authentifizierungsebene 516 

NTLM 298


Authentifizierung (Fortsetzung) 

Problembehandlung 132, 295 

schreibgeschützter Domänencontroller 206 

SSL-Clientzertifikate 748 

SSL-Serverzertifikate 747, 748 

standortspezifische SRV-Einträge und 55 


Umkreisnetzwerk und 146 

universelle Gruppen und 24, 364 

Verbunddienste und 13 

Vertrauensstellungen 50 

zweistufig 147, 658 

Authentifizierungsdienst (AS) 278, 280 

Authentifizierungsspeicher im Extranet 613 

Automatic, Steuerungsflag 273 

Automatische Registrierung von Zertifikaten 517, 668, 677, 

685, 688 

Automatische Standortabdeckung 205 

Automatischer Zertifikatanforderungsdienst (ACRS) 517, 

677 

Automatisieren der Objektverwaltung 379 

Befehlszeilentools für 379 

LDIFDE und CSVDE 380 

VBScript 382 

Autonomie, administrative 159, 160, 171, 248 

Autorisierende Wiederherstellung 583, 591, 643 

Autorisierender Benutzer 369 

Autorisierender Namenserver 79 

Autorisierung 

AD DS-Infrastruktur und 141 


Problembehandlung 132 

Ressourcenpartner für 735 


Autorisierungs-Manager 

Anwendungsgruppen für 361 

Gruppenansprüche 758 

LDAP-Abfragegruppen und 360 

Richtlinien für 179 

B 

Backlinks 594 

Backwardlink, Attribute 96, 103 

Bandbreite 

Analysetool für Netzwerkframes 241 

Dienst für Netzwerkadressinformationen (NlaSvc) 

und 398, 412 


Domänenerstellung und 175 


für Replikation 72, 194 

Gruppenrichtlinien zur Softwarebereitstellung und 482 

IFM-Feature und 580 

Multicasting und 495 

standortübergreifende Replikation 106, 108 

Standortverknüpfungen und 123 

Standortverknüpfungskosten und 197, 198 

Überwachung und 545 

Bandbreiteneinschränkung 104 

base schema-Objekte 39 

Basis-Zertifikatsperrlisten (CRLs) 662 

Batchdateien, zum Verwalten von Active Directory 379, 382, 

385 

Bedingte Weiterleitungen 81, 149 

Benachrichtigung über standortübergreifende Replikation 

125 

Benutzerdefinierte Ansprüche 758, 761 

Benutzerdefinierte Installation, Assistent 486 

Benutzerdesktops Siehe Gruppenrichtlinien für Benutzerdesktops 

Benutzergruppenrichtlinie 407 

Benutzerklasse 32, 34, 36 

Benutzerkonten 

Anwenden von Berechtigungen 337 

bei der Migration zwischen Gesamtstrukturen 257 

dringende Replikation und 108 

in AD LDS 624 

Zertifikatzuordnung 292 

Benutzeroberfläche, AD DS-Features in der 9 

Benutzerobjekte 352 

Benutzerprinzipalnamen (UPNs) 25 

Ansprüche 758 

in Umgebungen mit mehreren Domänen 388 

Objektverwaltung und 356, 357 

Sicherheit und 281, 293 

Suffixfilterung 168 

Suffixzuordnung 762 

Benutzerprofile 452 

in Windows-Versionen 454 

lokal 456 

Ordnerumleitung und 469 

servergespeichert 457, 460, 680 


verbindlich und superverbindlich 459 

Verknüpfungspunkte und 453 

Benutzerrechte, zuweisen 308, 510, 511 


administrative 27 

Anwendungsverzeichnispartitionen und 44 

Authentifizierung zulassen 167 

bei Ordnerumleitung 466 

Besitz 336 

delegieren 190 


Domänen-Admins (Gruppe) und 368 


effektiv 333, 349 

für Domänencontroller 28 

für eingeschränkte Daten 16 

in AD LDS 626 

in Gesamtstruktur-Stammdomäne 49 

in Zugriffssteuerungslisten 271 

Lokal anmelden 58 

Migration 247, 255 

Prinzip der geringsten Rechte 313, 316, 388 

Rechteverwaltungsdienste (RMS) und 710 

RODC, administrative 206 


speziell 325 

Standard 323


Steuerungsflags und 272 

Vererbung 330 

Zugriffstoken und 274 

zum AD DS-Installation 216 

zum Erstellen eines Delegierungseintrags 80 

Bereichsübergreifende Sitzungsschlüssel 285 

Bereichsvertrauensstellung 54, 294 

Berichte, RMS 728 

Besitz 


Domänenstruktur 177 

Gesamtstrukturentwurf 163 

Objektkontingente 315 

Sicherheitsbeschreibungen 272 

von Diensten und Daten 159 

von Gruppen 369 

Betriebsmaster 28 

Domänenname 29 

Einzelfehlerquelle 94 

FSMO 20, 28 

gemeinsam, in Gesamtstruktur 49 

Infrastruktur 31, 252, 594 

Notfallwiederherstellung und 602 

PDC-Emulator 30 

RID (Relative ID) 30 

RODCs und 27 

Rollenverwaltung 320 

Schema 28 

Serverstandorte für 208 

Übertragen von Rollen 31 

Überwachung 563 

wiederherstellen 585 

Betriebssystem, Leistungsindikatoren 559 

Bevorzugter DNS-Server, Einstellung 227 

Bezeichnerautorität, in SID 270, 271 

Bidirektionale Gesamtstrukturvertrauensstellungen 162 

Bidirektionale transitive Vertrauensstellungen 51, 155, 157 

Bidirektionale Vertrauensstellungen 176, 263 

Binary Large Object (BLOB) 672 

BIND-DNS-Infrastruktur 186, 187 

Bindungsumleitung, Authentifizierung 628, 629 

Bootmgr, Dateien 580 

Bridgeheadserver 4, 27 

bei der standortübergreifenden Replikation 107, 108, 118 

konfigurieren 128 

Replikationsintervall für 124 

SMTP-Replikation und 128 

Standortverknüpfungsbrücken und 126 

Standortverknüpfungskosten und 198 

Business-to-Business (B2B), Identitätsverbundszenario 732, 

735 

Business-to-Consumer (B2C), Identitätsverbundszenario 733 

Business-to-Employee (B2E), Identitätsverbundszenario 733 

C 

CAPolicy.inf, Datei 660 

Certreq.exe, Befehlszeilenprogramm 650, 652, 689 

CertUtil.exe, Befehlszeilenprogramm 663 

classSchema-Objekte 32, 33 

ClientAccess-Serverrolle 200 

Clientdiensterkennung 709 

Client-Lizenzgeberzertifikat (CLC) 698 

Clients 

Domänencontrollerverfügbarkeit und 68 

Rechteverwaltungsdienste (RMS) 696, 708 

SSL-Authentifizierungszertifikate 748 

Standort 68 

Verbundserverproxy 754 

Webbrowseranforderungen für die AD FS 745 

Clientseitige Erweiterungen (CSEs) 398 

Erkennung von langsamen Verbindungen, Standardverhalten 

413 

für Skripts 409 

im Vergleich zu Einstellungen 502, 524 

in Gruppenrichtlinien 403, 404 

anzeigen 404 

Dynamic Link Libraries (DLLs) 404 

Speicherung 404 

verknüpfte GUIDs 405 

Cluster, RMS 695, 703, 704 

Clusterdienstinformationen 580 

Clusterschlüsselkennwörter 705, 728 

Cmdlet-Syntax, in PowerShell 386, 387 

Comma Separated Value Directory Exchange (CSVDE), 

Tool 35 

Computer, MMC-Snap-In 9, 371 

Computergruppenrichtlinie 407 

Computerkonten 259 

Computermigrations-Assistent 259 

Computerobjekte 370 

Computerzertifikat 698 

Container 

Gruppenrichtlinien 451 

in AD LDS-Konfigurationsverzeichnispartition 616 

Password Settings 518 

übergeordnet 96 

Containerindizes 35 

Cookies 745 

CPU-Auslastung, KCC 563 

CryptoAPI 2.0-Diagnoseprotokollierung 651 

CryptoAPI Next Generation-Algorithmus (CNG) 672, 673 

Cryptography Next Generation (CNG) 11 

Cscript.exe, Laufzeit 383 

CSVDE, Befehlszeilenprogramm 352, 380, 387, 389 

CurrentNetworkEnvironment.xlsx 149, 150, 151, 180 

D 

Dateierweiterungsaktivierung 480, 489 

Dateireplikationsdienst (FRS) 104, 562, 602 

Dateiverbindungen 401 

DatenPrivilege Attribute Certificate (PAC) 297 


Speicherung 577 

Vertraulichkeit von 145, 146 

verwalten 320 

Datenbanken 21 

Bereitstellungstool für 9, 599, 606, 607 

Datenspeicher und 22 

Defragmentierung 567 

in AD LDS 615


Datenbanken (Fortsetzung) 

Integrität 570 

NTDS 214 

Rechteverwaltungsdienste (RMS) und 696, 704 

Schemaattribute und 37 

schreibgeschützt, AD DS 4 

semantische Analyse 571 

Sicherheitskontenverwaltung (SAM) 21, 229 

Speicherüberwachung 562 

SQL Server 17 

Standorte 571 

Verzeichnisverwaltung 320 

Zertifizierungsstelle 659 

Datenspeicher 

als AD DS-Komponente 20 

dynamische Anwendung 29 

für AD LDS 614 

indizieren 34 

Datenwiederherstellungs-Agent 517 

Dauer, Kontosperreinstellungen 7 

Dauerhaft geltende Nutzungsrichtlinie, objektbasiert 15 

Dcdiag.exe, Tool 

bei der Gesamtstrukturvorbereitung 252 

für Authentifizierungsstatus 295 

Überwachung 564, 565 

zum Überprüfen der AD DS-Installation 231 

zur Problembehandlung bei der Replikation 134, 138 

Dcgpofix.exe, Befehlszeilentool 516 

Dcpromo.exe, Tool 220, 231, 235, 239 

Dctlog.txt, Datei 260 

Deaktivieren der Vererbung von Berechtigungen 332 


Debugprotokollierung, Option 87 

Dedizierte Domänencontroller 315 

Dedizierte Stammdomäne 46, 173, 177 

Default Domain Controllers Policy Siehe Domänencontroller 

Definierte Namen (DNs) 41, 48, 566 

Defragmentierung 

offline 569 

online 567 

Delegierte untergeordnete Domänen 84 

Delegierung Siehe auch Verwaltung, delegieren 

administrativer Rechte 177 

Authentifizierung 276, 286 

dokumentieren 149, 151 

Einträge 79, 84 

Entwurf der Organisationseinheiten 189 

für neue Domänen 216 

Namespaceentwurf und 185 

Signaturschlüssel 667 

Verwaltung schreibgeschützter Domänencontroller 206 

Delete Nummer, Befehl 601 

Delta-Zertifikatsperrlisten (CRLs) 662 

Demilitarisierte Zone 14 

Designierte Dateitypen, Objekt 528 

Desktops Siehe Gruppenrichtlinien für Benutzerdesktops 

Dezentrale Verwaltung Siehe auch Verwaltung, delegieren, 

319 

DFSR-Dienst (Distributed File System Replication) 104, 179, 

562 

DFS-Replikation, Ereignisprotokoll 136 

DHCP-Clientdienst 86 

Diagnoseprotokollierung 651 

Dienst für die Ressourcenermittlung, DNS als 216 

Dienstadministratoren 314 

Dienstanforderungen in den AD DS 142 


funktionelle Anforderungen 144 

geschäftliche Anforderungen 143 


rechtliche Anforderungen 145 


Vereinbarungen zum Servicelevel 144 

Dienstidentifizierung, Ressourceneinträge Siehe SRV-Ressourceneinträge 

Dienstkonten 258, 359 

Dienstprinzipalnamen (SPNs) 21, 281, 283, 297, 317 

Dienstproxy, Verbund 737 

Diensttest 54 

Dienstverwaltung 320 

Differentiated Services Code Point (DSCP) 394 

Digest-Authentifizierung 276 

Digital signiertes Sicherheitstoken 736 

Digitale Signaturen 12, 291, 293, 747 

Digitale Zertifikate 291, 649, 653 

Dir-Befehl 456 

Display Specifier, Schema 617 

DisplayADLDSInstances.ps1, Skript 620 

DisplayMachineVersionLGPO.vbs, Skript 410 

DisplayUserVersionLGPO.vbs, Skript 410 

Distinguished Name Tag (DNT) 594 

Distributed File System (DFS) 

für SYSVOL-Ordner 602 

in AD DS-Struktur 194 

Replikation und 4, 402 

Sicherheit 55 

Veröffentlichen von freigegebenen Ordnern und 378 

Verwaltung der Netzwerkauslastung 482 

DNSCmd, Tool 73 

Dnscmd.exe, Befehlszeilentool 90 

DNSDomainname 600 IN AAAA IPv6Address, Eintrag 66 

DNSDomainname 600 IN IPv4Address, Eintrag 66 

DNS-Konsole, Tool 90 

Dnslint.exe, Tool 90, 138 

DNS-Locatordienst 66 

DNS-Manager 73 

DNS-Namen mit einer einzigen Bezeichnung 223 

dnsRoot-Attribut 48 

Dokumentation 

administrative Delegierung 348, 349 

aktuelle Umgebung 148 

Active Directory-Infrastruktur 150 

Exchange Server-Implementierung 152 

Infrastruktur zur Namensauflösung 149 

Infrastruktur zur Sicherung und Wiederherstellung 152 

Netzwerkinfrastruktur 148 

Verwaltungsmodelle und -prozesse 152 

verzeichnisfähige Anwendungen 152 

Dokumente, RMS und Siehe auch Drucker, 692


Domain Name System (DNS) 61 

AD DS-Installation und 216, 227 

AD DS-Integration in 62 

automatische Standortabdeckung für 69 

DNS-Locatordienst für 66 

SRV-Ressourceneinträge für 62 

AD DS-integrierte Zonen und 72 

Standardanwendungspartitionen für 73 

verwalten 75 

Vorteile 72 

aktualisieren 237 


Infrastruktur 180 

AD DS-Integration in 185 

interne und externe Namespaces 181 


Lookupfehler 136 

Namespaces 78 

Delegierung 79 


Stammhinweise 83 

Stubzonen 83 

Weiterleitungen 80 



schreibgeschützt 5 

Server für 201, 561 

Serverdienst 43 

Tools für 90 


Wiederherstellen von Domänencontrollern 587 

DomainDnsZones 5, 43, 73, 75, 76, 231 

Domänen Siehe auch Standarddomänenrichtlinie 

Active Directory-Domänen und -Vertrauensstellungen, 

Snap-In 60 

Aktualisierung beim Migrieren auf AD DS 245, 250 

Anzahl 171 

Funktionsebenen 150, 178, 180, 224, 226 

Gruppenrichtlinienimplementierung für 431 

Gruppenrichtlinienvorlagen basierend auf 474 

in AD DS 45 

in der Konsole zur Gruppenrichtlinienverwaltung 

(GPMC) 417, 418 

RMS, vertrauenswürde Veröffentlichungsdomäne 716 

RMS, vertrauenswürdige Benutzerdomäne 714 

standardmäßige Gruppenrichtlinienobjekte (GPOs) für 516 

Standardrichtlinie für 395 

Stilllegen der Quelldomäne 261 

Struktur 169 

Besitz 177 


Hierarchieänderungen nach der Bereitstellung 177 


Strukturen und Vertrauensstellungen 175 

umstrukturieren 246 

Verzeichnispartitionen für 42 

Wiederherstellen von Gruppen in Remotedomänen 596 

Domänen:umstrukturieren Siehe auch Migration zwischen 


Domänenadministrator, Konto 313 

Domänen-Admins (Gruppe) 134 

AD DS-Struktur und 159, 160, 163 

Anwendungsverzeichnispartitionen und 44 

Berechtigungen und 323, 368 

Datenbankbereitstellungstool und 601 

Deaktivieren von Berechtigungen 332 

Domänencontrollersicherheit und 312 

Entfernen von Domänencontrollern 237, 238 

in neuen Domänen 367 

Migration 252 

schreibgeschützte Domänencontroller und 235 

verschiedene Benutzertypen und 7 

Domänencontroller Siehe auch PDC-Emulator, Betriebsmasterrolle; 

Schreibgeschützte Domänencontroller (RODCs) 

Adprep-Befehlszeilentool und 8 


bei der Behandlung von Replikationsproblemen 133 


Computerobjekte für 371 

Datenbankverwaltung 320 

DNS und 61 


Domänennameninformationen, gespeichert auf 76 

dynamische Portzuordnung 127 

entfernen 237 

erzwungenes Entfernen 238 


für AD DS-Anmeldung 194 

heraufstufen 213 

Installieren der AD DS und 214, 227 

Löschdienst auf 375 

migrieren 265 

neu starten 364 


Partitionsintegration mit 160 

Quelle 10 

Redundanz 576 

registrierte SRV-Einträge 63 

Replikation und 54, 112, 114 

Sicherheit für 195, 300 

Angriffsfläche verringern 300 

Benutzerrechtezuweisung, Richtlinieneinstellungen 308 

Ereignisprotokolleinstellungen 307 

Sicherheitsoptionen, Richtlinieneinstellungen 309 

SMB-Signatur 310 

SYSKEY-Konfiguration 312 

Überwachungsrichtlinieneinstellungen für 304 

sichern 581 


Standardrichtlinie für 511 

Benutzerrechtezuweisung 511 

Sicherheitsoptionen für 515 

Überblick 395, 409 

Standorte 203 

Statuswerte 9 


Überwachungsrichtlinie für 342 

Verfügbarkeit 68 

Verwaltungsschnittstelle für 21 

Zurücksetzen des Kennworts 371


Domänencontrollerdiagnose, Tool 231 

Domänendienste Siehe Active Directory-Domänendienste 

(AD DS) 

Domänenkennung 270 

Domänennamenmaster 29, 31, 209, 605 

Domänenstrukturen 46 

Domänenübergreifende Verweise zwischen Gruppen und Benutzern 

31 

Domänenübergreifendes Kopieren, Assistent 435 

Drahtlosnetzwerke 12, 528, 531, 658 

Dringende Replikation 108 

Drittanbietertools für die Delegierung 346 

Drucker 

Gruppenrichtlinien für 395 

Objekte 373, 389 

Dsacls, Befehlszeilentool 626, 636 

Dsadd.exe, Dienstprogramm 372 

Dsadd.exe, Tool 380 

Dsamain.exe, Tool Siehe auch Datenbanken, Bereitstellungstool 

für, 599, 601 

Dsdbutil.exe, Befehlszeilenprogramm 60 

für AD LDS-Dienstkonto 616 

für AD LDS-Instanzensicherung 641, 642 

für AD LDS-Instanzenwiederherstellung 643 

für AD LDS-Verwaltung 635, 647 

DSGET, Befehlszeilentool 522 

Dsget.exe, Tool 380 

DsGetDcName-API 66 

Dsmgmt.exe, Befehlszeilenprogramm 27, 629 

Dsmod.exe, Tool 380 

Dsmove.exe, Tool 380 

Dsquery.exe, Tool 380 

Dsrm.exe, Tool 380 

Dynamic Host Configuration Protocol (DHCP) 8, 76 

Dynamic Link Libraries (DLLs) 404 

dynamicObject-Klasse 178 

Dynamische Aktualisierungen 87, 186 

Dynamische Anwendungsdaten 29 

Dynamische Portzuordnung 127 

Dynamisches DNS (DDNS) 76, 86 

E 

Edge-Transport, Serverfunktion 15, 644 

Effektive Berechtigungen 333, 349 

Eigenständige Zertifizierungsstellen 656, 663, 676 

Einbezogene Struktur 197 

Einfache LDAP-Bindung, Authentifizierung 628 

Eingeschränkte Gruppen 415, 524 

Eingeschränkte Gruppen, Richtlinie 313 

Eingeschränkter Registrierungs-Agent 12, 658 

Einmalige Anmeldung (SSO) 14, 141, 613 

Einschränkungen 147, 149 

Einstellungen, Gruppenrichtlinien und 395, 398 

im Vergleich zu Anmeldeskripts 478 

im Vergleich zu Einstellungen 496 

in Windows-Einstellungen 497 


Systemsteuerungseinstellungen 499 

zum Verstärken der Serversicherheit 524 

Einzelfehlerquelle 94 

Elektronischer Datenaustausch (EDI) 732 

Elliptic-Curve Diffie-Hellman-Algorithmus (ECDH) 673 

Elliptic-Curve Digital Signature Algorithm (ECDSA) 673 

E-Mail-Anspruch 758 


für AD DS-Struktur 209 


für den Entwurf universeller Gruppen 370 

für die Objektverwaltung 388 

für Dienstadministratoren 159 

für DNS 89 

für gesamtstrukturweite Authentifizierung 166 

für Gruppenrichtlinienvorlagen 475 

für Kerberos-Richtlinieneinstellungen 290 

für LM-Kennworthashwerte (LAN Manager) 299 

für Notfallwiederherstellung 606 

für Replikation 136 

für RODC-Bereitstellung 234 

für Zertifikatdienste (CS) 688 

Sicherheit 167, 315 

zum Migrieren auf AD DS 265 

Energieverwaltung 395, 524 

Ereignisablaufverfolgung, Daten 551, 552 

Ereignisanzeige 

AD DS-Installation und 231 

Delegieren der Verwaltung 342 

Gruppenrichtlinien und 444 

in AD LDS 616 




Ereignisprotokolle 

Einstellungen 346 

Richtlinieneinstellungen für 307 

von Administratoren 727 

zum Verstärken der Sicherheit 524 

zur Kerberos-Problembehandlung 296 

Erforderliche Attribute 352 

Ergebnisse, Gruppenrichtlinien 417, 437 

Erkennung von langsamen Verbindungen, Richtlinieneinstellung 

zur 413, 445, 460, 462 

Erweiterte Schlüsselverwendung, Erweiterung 685 

Erweiterungsaktivierung 480 

Erzwingen, Objekt 527 

ESENT-Protokolldateien (Extensible Storage Engine Transaction) 

214 

Eskalation im Notfall, Benachrichtigungsprozesse 154 

Eskalation, Notfall 154 

European Union Data Protection Directive (EUDPD) 145 

Exchange Server 2007 15, 199 

Adamsync-Synchronisierung und 644 

DNS und 61, 89, 201 

Dokumentieren der Implementierung 152 


Entwurf des schreibgeschützten Domänencontrollers 

(RODC) 205 

Gesamtstrukturgrenzen und 156 

LDF-Dateien und 644 

Schemaänderung und 34 

Standort des globalen Katalogservers 204


Standorte der Betriebsmasterserver 208 

Standorte und 55, 194 


Exchange-Verwaltungsshell 387, 389 

Extensible Storage Engine (ESE) 22, 615 

Externe Vertrauensstellungen 53, 162 

Externe Zertifizierungsstellen (CAs) 654 

F 

Federal Privacy Act (Australien) 145 

Fehler Siehe auch Problembehandlung, 132, 136, 138 

Fein abgestimmte Kennwortrichtlinien 7, 517 


Domänenfunktionsebene 179 



planen 518 

resultierende PSOs in 521 

Richtlinienergebnissatz für 8 

speichern 7 

Überblick 7 

Festplatten, klonen 494 

Festplattenspeicher, AD DS-Installation 214 

Filterattributsatz, RODC 4 

Filterung 54 

Replikation und 127 

Sicherheit 425, 444, 445 

von Sicherheitskennungen (SIDs) 167 

von UPN-Suffixen 168 

Windows-Verwaltungsinstrumentierung (WMI) und 421, 

427 

Financial Modernization Act (USA) 145 

Firewalls 



Kerberos-Authentifizierung, Ports 295 



Weiterleitungen und 184 

Flags 

DsGetDcName-Werte für 67 

für GPO-Status 400 

Kerberos-Ticket 284 

Steuerung 272 

ForestDnsZones 

DNS und 66, 73, 75, 76 

erstellen 43 

Überblick 5 


Forwardlink, Attribute 96, 103 

Forwardlinks 594 

Forward-Lookupzonen, Seite 231 

Freigegebene Ordnerobjekte 377 

Freigegebene Zugriffssteuerungsliste (DACL) Siehe auch 

Dsacls, Befehlszeilentool 

bei der Migration 247, 259 

beim Active Directory-Objektzugriff 321, 322 

in AD LDS 627, 637 

Sicherheit und 271, 272, 275 

Fremde Sicherheitsprinzipale, Container 230 

FSMOCheck-Test 54 

fSMORoleOwner, Attribut 29, 30, 31, 60 

FSMO-Rollen (Flexible Single-Master Operation) 20, 28, 

237, 239, 594, 604 

Funktionelle Anforderungen in den AD DS 144 

G 

gc, SRV-Eintrag 65 

gc. msdcs.DnsForestName, Eintrag 66 

Gegenseitige Authentifizierung 276, 282 

Gemeinsame Konfiguration von Vertrauensstellungen 49 

Gemeinsamer geheimer Schlüssel, Authentifizierungsmodell 

291, 293 

Gemischte Betriebssystemumgebung 476 

Geplante Tasks 379 

Geräteinstallation, sperren 395 

Gesamtstrukturen Siehe auch Migration zwischen Gesamtstrukturen, 

Siehe auch Migration innerhalb einer Gesamtstruktur 


Entwurf 154 

Besitz 163 

einzelne oder mehrere 157 

Integration, mehrere 164 

Modelle 161 

Richtlinien zur Änderungskontrolle 164 



Federated-Web-SSO mit Gesamtstrukturvertrauensstellung 

738, 742 

Funktionsebenen 4, 150, 179, 224, 227, 594 

Gruppenrichtlinienimplementierung für 431 

in AD DS 49 

Querverweisobjekte und 29 

standardmäßige Tombstone-Ablaufzeit für 582 


Verbundvertrauensstellungen zwischen 13 

Windows Server 2008-Upgrade 251 

Gesamtstrukturmodell mit eingeschränktem Zugriff 162 

Gesamtstruktur-Stammdomänen 

als AD DS-Komponente 46, 53 

DNS und 85 

erstellen 216 

Struktur 173 


Verteilung 204 

Gesamtstrukturübergreifende Vertrauensstellungen 164, 166, 

358 

Gesamtstruktur-Vertrauensstellungen 52 

Geschäftliche Anforderungen in den AD DS 143 

Geschäftseinheiten 153, 175 

Geschlossener Satz, bei der Migration zwischen Gesamtstrukturen 

262 

GINA-DLL (Graphic Identification and Authentication) 274 

Global eindeutige Kennungen (GUIDs) 

clientseitige Erweiterungen (CSEs) und 405 

DNS und 65 

für Gruppenrichtliniencontainer (GPCs) 399 

gelöschter Objekte 566 

PSOs und 521



Globale Adressliste 21, 156, 199, 356 

Globale Gruppen 363 

Globale Katalogserver 10, 20 

autorisierende Wiederherstellung 595 



erster Domänencontroller als 228 

erzwungenes Entfernen von Domänencontrollern 239 

Exchange Server 2007 und 199, 200 

in AD DS 22, 194, 214 

in einzelner Domäne 171 

Infrastrukturmaster und 209 

Standorte 204 

wiederherstellen 585, 605 

Globale Sicherheitsgruppe, Mitgliedschaft 8 

Globale Überwachungsrichtlinie 6 


gc, SRV-Eintrag 65 


in Gesamtstrukturentwurf 154 

Kontaktobjekte und 358 

Mitgliedschaft in universellen Gruppen, Liste 363 


Partition 43 



Globaler Katalog, LDAP 295 

GMPC 

GPOs erstellen und verknüpfen über 418 


GPLogView.msi, Skript 445 

GPMCSampleScripts.msi 440 

Gpresult.exe, Tool 438 

GPU, Befehlszeilentool 481 

Gpupdate, Befehlszeilentool 411 

Grafische Dienstprogramme 379 

Gramm-Leach-Bliley Act (USA) 145 

Grenzen 

Authentifizierung, übergreifend 285 

Domäne 45, 169 

Exchange Server 156 

Grenzen für den Ressourcenzugriff 45, 170 

Gruppen 

AD LDS, Standard 625 

eingeschränkt 415, 524 


für die Objektverwaltung 360 

Arten 360 

Bereich 361 


Spezialidentitäten 367 


primär 272, 321 


Tombstone-Wiederbelebung 597 

Verschachtelung 178, 362, 363 


Gruppenansprüche 758 

Gruppenanspruchsextrahierungen 760 

Gruppenrichtlinien Siehe auch Sicherheit, Gruppenrichtlinien 

für, 393 

Annahme von Authentifizierungsprotokollen 299 

Automatischer Zertifikatanforderungsdienst (ACRS) 

und 677 

Bereitstellen von Registrierungseinstellungen 724 

Computerobjekte und 372 


Domänenanzahl 171, 172 

Domänenebene 177 

Einstellungstypen 58 

für DNS-Locatoreinträge 206 

für DNS-Registrierung 70 

für Domänencontrollersicherheit 304 

für Drucker 374, 376 

für Zertifikatakzeptanz 679 


GMPC zum Erstellen und Verknüpfen von GPOs 418 

GMPC-Überblick 417 

GPO-Verarbeitungsbereich 420 

GPO-Verwaltung 429 

planen 443 

zwischen Domänen und Gesamtstrukturen 431 

Kerberos-Richtlinieneinstellungen 289 


Objekte 432 

Importieren von Einstellungen für 435 

kopieren 435 

Modellierung und Berichterstellung 435 

Sicherung und Wiederherstellung 432 

Standardobjekte in Domäne 516 

Organisationseinheiten und 58, 188, 190, 192 


SCW-Richtlinie und 303 

Skriptverwaltung von 440 

SYSVOL-Verzeichnis und 104 


Verarbeitung 403 

Aktualisierung von GPOs im Hintergrund 408 

anfängliche Verarbeitung von GPOs 406 

Client-GPO 404 

Intervall für Hintergrundaktualisierung 411 

verwalten 320 

zertifikatbezogene Einstellungen 12 

Gruppenrichtlinien für Benutzerdesktops 421, 425, 449 

administrative Vorlagen und 471 

domänenbasiert 474 



Benutzerprofile und 452 

in Windows-Versionen 454 

lokal 456 

servergespeichert 457, 460 


verbindlich und superverbindlich 459 

Verknüpfungspunkte und 453 

Einstellungen in 496 

im Vergleich zu Einstellungen 496 

in Windows-Einstellungen 497 

Optionen für 500



individuelle und zentrale Steuerung im Vergleich 450 


Gruppenrichtlinieneinstellungen für 469 


Offlinedateien für 468 

Skripts und 477 

Softwarebereitstellung und 478 


Einschränkungen 494 

entfernen 490 

Konfigurieren der Dateierweiterungsaktivierung 489 

Konfigurieren von Paketeigenschaften 484 

Netzwerkbandbreite und 482 

Nicht-Windows Installer 483 

planen 493 

Windows Installer-Technologie für 478, 491 


Gruppenrichtliniencontainer (GPCs) 399, 451 

Gruppenrichtlinienergebnis-Assistent 417 

Gruppenrichtlinienmodellierungs-Assistent 417, 431, 436 

Gruppenrichtlinienobjekt-Editor 376 

Gruppenrichtlinienverwaltung (GPMC), Konsole 397, 689 

Beschreibung 416 

globale Überwachungsrichtlinie, aktiviert durch 6 

GPOs erstellen und verknüpfen über 418 


Gruppenrichtlinienverwaltung, Konsole Siehe Gruppenrichtlinienverwaltung 

(GPMC), Konsole 

Gruppenrichtlinienverwaltungs-Editor 305 

Gruppenverschachtelung 178 

H 

Hardwaresicherheitsmodul (HSM) 661 

Hashwerte 4, 510, 525, 526 

Hauptbenutzer (Gruppe) 7 

Health Insurance Portability and Accountability Act von 1996 

(USA) 145 

Heraufstufen auf Domänencontroller (dcpromo) 213 

Hinzufügen von Druckern, Assistent 376 

Hinzufügen von Features, Assistent 397 

Hinzufügen von Ressourcenpartnern, Assistent 761 

Hinzufügen von Rollen, Assistent 9, 218 

HTTPS-Sitzungscookies (Secure Hypertext Transfer Protocol) 

745 

Hubtransport-Serverrolle 200 

HW Auth, Kerberos-Ticketflag 285 

I 

Identitätsansprüche 758, 762 

Identitätsverbund 732 

Identity Integration Feature Pack 169 

id-kp-OCSPSigning, optimierter Schlüssel 667 

id-pkix-ocsp-nocheck, Erweiterung 667 

IEEE 802.11-Standard 531 

IEEE 802.3-Standard 528, 529, 530 

Import-Csv, Cmdlet 387 

Indizierung 

Extensible Storage Engine (ESE) 22 

für Suche 34 

in AD LDS 615 

inetOrgPerson-Objekt 178, 357 

Infrastrukturmaster 31, 209 

im Vergleich zum globalen Katalogserver 32 

Migration 252 

Phantomobjekte und 594 

Tools für 31 

wiederherstellen 604, 605 

Installation, sperren 395 

Installieren der AD DS 213 

Assistent 221 

Abschließen der Installation 229 

Bereitstellungskonfiguration und 222 

Dateispeicherorte 228 

Domänencontrolleroptionen 227 


vollqualifizierter Domänename (FQDN) 223 

Windows Server 2008-Funktionsebenen 224 

Bereitstellung eines schreibgeschützten Domänencontrollers 

(RODC) 234 

Entfernen der AD DS und 235 


Tools für 241 

unbeaufsichtigt 231 

Voraussetzungen 213 

Administratorrechte 216 

Betriebssystemkompatibilität 216 


Festplattenspeicher 214 

Netzwerkkonnektivität 215 

Installieren von Medium (IFM-Feature) 

für AD DS 213, 220, 232 

Notfallwiederherstellung und 580, 584 

Instanzen 

Autorisierende Wiederherstellung der AD LDS 643 

in AD LDS 612, 615, 630 

Sichern der AD LDS 641 

Wiederherstellen der AD LDS 642 

Integrierte Authentifizierung 289, 628 

Integrierte Gruppen 365 

Integrierte Zonen, AD DS 72 

Standardanwendungspartitionen für 73 

verwalten 75 

Vorteile 72 

International Organization for Standardization (ISO) 38, 356, 

475 

International Telecommunications Union (ITU) 356 

Interne Zertifizierungsstellen (CAs) 654, 658, 749 

Internet Explorer 17, 394, 414 

Internet Protocol (IP) 107, 109, 215, 295 

Internet Protocol Security (IPsec) 12, 528, 532 

Internet, RMS-Bereitstellung im 701 

Internetinformationsdienste (IIS) 17, 276, 293, 301 

Internetnamensauflösung 184 

Inter-Site Topology Generator (ISTG) 117, 118, 123, 128, 

132, 201, 621 

Inter-Site Transport, Container 126 

Intervall, Replikation 124 

Intranet, RMS-Bereitstellung im 701 

Invalid, Kerberos-Ticketflag 285


IPconfig.exe, Tool 90 

IP-Subnetze (Internet Protocol) 54, 121, 149, 195 

IPv4-Adresse 66, 69 

Ipv6-Adresse 66, 69 

isDeleted-Attribut 102 

isMemberOfPartialAttributeSet, Attribut 23 

Isolation, administrative 160, 162, 209 

J 

Jeder, Gruppe 458 

JScript 383, 440 

K 

Katalog Siehe Globaler Katalog, Siehe Globaler Katalogserver 

Kccevent-Test 54 

Kennworteinstellungsobjekte (PSOs) 7 

Attribute 7 

resultierend 518, 521 

Richtlinienergebnissatz (RSoP) und 8 

Kennwörter 

benutzerdefinierte Filter für 507 

Berechtigung zum Zurücksetzen 339 

Clusterschlüssel 705, 728 

Deinstallieren der AD DS und 237 



fein abgestimmt 7 

Richtlinienergebnissatz für 8 

speichern 7 

Überblick 7 

für KRBTGT-Konto 278 

für SYSKEY 312 

für Verzeichnisdienst-Wiederherstellungsmodus (DS- 

RM) 229 

geteilt 314 


in AD LDS 629, 646 

Kerberos-Kennwortänderungsserver und 65 

Komplexität, Richtlinie für 316 

LM-Hashwerte für (LAN Manager) 299 


PDC-Emulator, Betriebsmasterrolle und 30, 109 

Richtlinie für 506 

schreibgeschützte Domänencontroller und 3 

speichern 4 

zurücksetzen 371 

zurücksetzen, Notfallwiederherstellung 588, 591 

Kennwortexportserver (PES) 258 

Kennwortreplikationsrichtlinien 5 

entwerfen 206, 208 

für RODCs 10, 26, 220, 234 

Kerberos Token Size, Tool 317 

Kerberos Tray, Tool 284, 317 

Kerberos-Authentifizierung 

Advanced Encryption Services (AES) für 179 

als empfohlene Vorgehensweise 315 


dynamische Aktualisierungen basierend auf 87 


in AD LDS 628, 629 

Security Support Provider (SSP) für 274 

SRV-Ressourcenbeispiel 64 

Zugriffstoken und 273 

Zurücksetzen des Kennworts 371 

Kerberos-Kennwortänderungsserver 65 



Authentifizierungsdelegierung 286 

Benutzerprinzipalnamen 758 

für AD LDS-Replikation 623, 624 

Interoperabilität 294 



Public Key-Infrastrukturintegration 290 


Smartcardintegration 293 


Kerberos-Ticketflags 284 

Klassen 

Benutzer 32, 34, 36 

crossRef 48 

dynamicObject 178 

Vererbung 34 

KList.exe, Tool 284, 317 

Klonen 244, 494 

Komma getrennte Wertdatei (CSV) 380 

Kompatibilität 216, 276, 298 

Kompatibilität, Anwendung 208 

Kompatible Clientcomputer 217 

Komprimierung, standortübergreifende Replikation und 125 

Konfigurationsspeicher für verteilte Anwendungen 15 

Konfigurationsverzeichnispartitionen 

Domänennamenmaster und 29 

in AD DS-Struktur 42 

in AD LDS-Struktur 616 

in Gesamtstrukturentwurf 49, 155 


Konfliktlösung bei der Replikation 101, 621 

Konnektivität 

bei der Problembehandlung für Gruppenrichtlinien 445 

erzwungenes Entfernen von Domänencontrollern 238 

für Remoteprozeduraufrufe (RPCs) 109 



Konsistenzprüfung (KCC) 

AD LDS und 621 

bei der Behandlung von Replikationsproblemen 133 


CPU-Auslastung 563 

Domänenfunktionsebene 178 

Kccevent-Test für 54 

Standortverknüpfungskosten und 125, 197 

Topologietest für 54 

Verbindungsobjekte, erstellt durch 104, 111, 118 

Zweigstellenstandorte und 201 

Kontaktobjekte 358 

Konten, Organisationseinheiten 192 

Konten-Operatoren (Gruppe) 313


Kontensperrung 108 

Attribute 7 


fein abgestimmte Kennwortrichtlinien und 518 


in AD LDS 629 


Steuerung über Standarddomänenrichtlinie 7 

Kontensperrungsschwelle, Kontosperreinstellungen 7 

Kontenverwaltung 320 

Kontodomänen 175 

Kontoeigenschaften für Benutzerobjekt 354 

Kontopartner in den AD FS 


ausgehende Ansprüche zuordnen 762 

Cookies 745 

Definition 735 

in Federated-Web-SSO-Szenario 740, 742, 751, 752 

Kontospeicher 758 

Ressourcenpartner 761 

Verbunddienst konfiguriert als 736 

Kontorichtlinien 506 

Kontospeicher 

hinzufügen 758 

Verbunddienstanforderungen 746 

Konvergenz, Replikation 94 

Kopieren, bei der Migration 246 

Kosten 

der Überwachung 545 

interner Zertifizierungsstellen (CAs) 654 


Bandbreite verknüpfen mit 197 

Formel für 197 

KCC-Routingtopologie und 125 

RCP-über-IP und 128 

Redundanz 123 

kpassword, SRV-Eintrag 65 

KRBTGT-Konten 4, 26, 206, 278 

Kryptografiedienstanbieter (CSP) 659, 705 

Kryptografische Kennung 525 

Ksetup.exe, Tool 294, 317 

Ktpass.exe, Tool 317 

L 

Laden von Zonen im Hintergrund 77 

LAN Manager (LM), Authentifizierung 299 

LanMan 301 

Lastenausgleich 63, 132, 200, 641 

Latenz 105, 107, 125, 149 

Laufwerkzuordnung 378 

LDAP Directory Interchange Format (LDIF) 380 

LDAP-Abfragegruppen 360, 361 

LdapDisplayName-Attribut 39 

LDF-Dateien 617, 644 

LDIF-Dateien 595, 632 

LDIFDE, Befehlszeilenprogramm 

für PSOs 519 


zum Verwalten von Objekten 352, 380, 389 

Ldp.exe, Tool 42, 73, 99 

ACE-Anzeige über 323, 328 


in AD LDS 626, 634, 637, 647 

Notfallwiederherstellung 598, 608 

zum Verwalten von Objekten 388, 390 

Lebenszyklusverwaltung, Software 478 

Leere Stammdomäne 46 

Legacyanwendungen, migrieren 15 

Leistung Siehe auch Überwachung 

Leistungsindikatoren und Schwellenwerte 551, 554, 555 

SLAs (Service-Level Agreements) 144 

Letzte interaktive Anmeldung, Informationen zur 179, 355 

Letzter Schreibzugriff 101, 102 

Lightweight Directory Access Protocol (LDAP) Siehe auch 

Active Directory Lightweight Directory Services (AD LDS) 

Active Directory-Domänendienste und 41 

beim Installieren der AD DS 213 

Data Interchange Format Directory Exchange (LDIFDE), 

Tool 35, 38 

Datenbankbereitstellungstool und 9, 599 

Domäne, Angriffsfläche verringern 301 

inetOrgPerson-Objekt und 357 

Ports für 295 

Schnittstelle 21 

Sicherheitsoptionen für Domänencontroller und 516 

SRV-Ressourcenbeispiel 63, 64 

Verbunddienste und 14 

Weiterleitungsantwort 4 

Links 

von Kennworteinstellungsobjekten (PSOs) 7 

Linux 243 

ListADDSDomains.ps1, Skript 50 

ListADDSSites.ps1, Skript 54, 122 

ListADDSSites.xlsx, Aufgabeninformation 122 

ListAppPartitions.ps1, Skript 75 

ListDomainControllers.ps1, Skript 28 

ListFSMOs.ps1, Skript 31 

Lizenzen, RMS 699 

LMHosts-Dateien 61 

Lokal anmelden, Berechtigungen 58 

Lokale Benutzerprofile 456, 461, 464 

Lokale Richtlinien 509 

Lokale Sicherheitsautorität (LSA) 108, 274, 285, 287, 317 

Lokales Gruppenrichtlinienobjekt (LGPO) 396, 398 

Lokales Netzwerk (LAN) 54 

Lookupfehler, DNS 138 

Loopbackverarbeitung 415, 445 

Loopbackverarbeitungsmodus für Benutzergruppenrichtlinie 

415 

Löschdienst, auf Domänencontrollern 375 

Lose Konsistenz, Replikation 94 

LSA-Konto (Local System Authority) 258 

M 

Massachusetts Institute of Technology (MIT) 276 

Massenvorgänge 381, 389 

Mathematischer Hash, in digitalen Signaturen 291 

May postdate, Kerberos-Ticketflag 285 

mayContain-Attribute 33


Messaging API (MAPI) 21, 200 

Messaging, standortübergreifend 109 

Metaverzeichnis 613 

Microsoft Download Center 397 

Microsoft Identity Integration Server 2003 (MIIS) 169, 358, 

613 

Microsoft Identity Lifecycle Manager 2007 (ILM) 169, 358, 

613 

Microsoft Management Console (MMC) 14, 235, 347, 385 

Microsoft Office, RMS und 710 

Microsoft Simple Certificate Enrollment Protocol 659 

Microsoft System Center Operations Manager 345 

Microsoft Systems Management Server (SMS) 494 

Microsoft-Stammzertifikatsprogramm 654 

Migration innerhalb einer Gesamtstruktur 253, 255, 261 

Migration zwischen Gesamtstrukturen 253 

Active Directory-Migrationsprogramm für 255 

Benutzerkonten 257 


Dienstkonten 258 

Erstellen einer neuen Gesamtstruktur 254 

Erstellen von Vertrauensstellungen 255 

globale und domänenlokale Gruppenkonten 256 

Konfigurieren von Vertrauensstellungen 262 

Kontenerstellung 254 

Stilllegen von Quelldomänen 261 


Migrationspfade 172 

Migrieren auf AD DS 243 

Domänenaktualisierung 245, 250 

Domänenumstrukturierung 246 


Legacyanwendungen 15 

Pfadermittlung 248 



zwischen Gesamtstrukturen 253, 261 

Active Directory-Migrationsprogramm für 255 

Benutzerkonten 257 


Dienstkonten 258 

Erstellen einer neuen Gesamtstruktur 254 

Erstellen von Vertrauensstellungen 255 

globale und domänenlokale Gruppenkonten 256 

Konfigurieren von Vertrauensstellungen 262 

Kontenerstellung 254 

Stilllegen von Quelldomänen 261 


Migrieren von Benutzerkonten, Assistent 260, 266 

Migrieren von Dienstkonten, Assistent 258, 259 

Mit Windows NT 4.0 kompatible Kryptografiealgorithmen zulassen, 

Option 217 

Mobile Benutzer, als Sicherheitsrisiko Siehe auch Servergespeicherte 

Benutzerprofile, 146 

Modellierung, Gruppenrichtlinien 417, 436 

msDS-AuthenticatedToAccountList, Attribut 26 

msDS-DnsRootAlias, Attribut 29 

msDS-NeverRevealGroup, Attribut 26 

msDS-RevealedList, Attribut 26 

msDS-Reveal-OnDemandGroup, Attribut 26 

msDS-UpdateScript, Attribut 29 

Msgina.dll 274 

MSI-Installationspaket 549 

Multimaster-DNS-Serverkonfiguration 72 

Multimasterreplikation 22, 28, 94, 95, 104, 621 

mustContain-Attribute 33 

N 

Nachrichtenroutingtopologie 55 

Namen 

allgemeine Namensansprüche 758 

Anonyme SID-/Namensübersetzung für 510 

Antragstellername in Zertifikaten 685 

Anzeigename 355 

Attribute 96 

Benutzerprinzipalname (UPN) 168, 281, 293, 357, 388, 

758, 762 

definiert 41, 48, 566 

Dienstprinzipalname (SPN) 281, 283, 297, 317 

Distinguished Name Tag (DNT) für 594 

Dokumentieren der Infrastruktur zur Namensauflösung 149 

Domäne 29 

Domänenumbenennung 177, 178 

NetBIOS 61, 62, 288 

RFC 2822-E-Mail-Namen 758 

Server für 5 

Standardanzeigename 356, 358 

Standortname-des-ersten-Standorts 55 

Universal Naming Convention (UNC) für 373, 377 

vollqualifizierter Domänenname 223, 288 

von AD LDS-Verzeichnispartitionen 619 

von Benutzerobjekten 355 

von Zertifizierungsstellen 659 

WINS-Server (Windows Internet Name Service) und 216 

X.500 OID-Struktur für 38 

Zwischenspeicher 295 

Namespaces, Domain Name System (DNS) 78 

Delegierung 79 

Distributed File System (DFS) und 378 


intern und extern 181, 183 


Stammhinweise 83 

Stubzonen 83 

Weiterleitungen 80 

NC-Kopf 564 

ncName-Attribut 48 

NetBIOS-Namen 61, 62, 288 

NetDom, Befehlszeilentool 371, 389, 591 

NETLOGON 

Benutzerprofile in 457, 458, 459 

Dienst 109 

freigegebener Ordner 104 


Network Access Protection (NAP) 528, 531 

Netzwerkadressinformationen, Dienst für (NlaSvc) 398, 412 

Netzwerkdienst, Konto 632, 646 

Netzwerkkonnektivität 

bei der Problembehandlung für Gruppenrichtlinien 445 

Problembehandlung 131



Netzwerklisten-Manager-Richtlinien 528 

Netzwerkmonitor 86, 90, 241, 297 

Netzwerksicherheit, Gruppenrichtlinien für 528 

drahtloses Netzwerk 531 

Einstellungen 510, 528 

für Windows-Firewall und IPsec 532 

verkabeltes Netzwerk 529 

Netzwerkzonen 526 

Neue Gesamtstruktur 253, 254 

Neue Vertrauensstellung, Assistent 168, 263, 294 

Neustart 569, 570 

Neustartfähige AD DS 8 

Nicht autorisierende Wiederherstellung von Active Directory 

583, 587 

Nicht dedizierte Stammdomäne 46 

Nicht technische Einschränkungen 149 

Nicht transitive externe Vertrauensstellungen 53 

Nicht-Objekt-ACEs 273 

Nltest.exe, Tool 91 

Non-Domain Naming Context (NDNC) 43 

North American Industry Classification System (NAICS) 733 


AD DS-Datendateien und 20 

Betriebsmasterstandorte und 209 

Datenspeicherung und 577 



planen 576 

Rollback 246 

Sicherung für die 579 

Häufigkeit 583 

Notwendigkeit 581 

Tombstone-Ablaufzeit und 581 


SLAs (Service-Level Agreements) 145 


Wiederherstellung von Active Directory 583 

autorisierend 591 

Betriebsmaster und globaler Katalog 602 

Datenbankbereitstellungstool für 599 

Erstellen von Domänencontrollern 583 

Gruppenmitgliedschaften 594 

nicht autorisierend 587 

SYSVOL-Informationen 602 

Tombstone-Objektwiederbelebung 597 

Novell Directory Services 243 

Nslookup.exe, Tool 86, 91, 138, 295 

Ntbackup.exe, Tool 579 

NTDS Settings, Objekt 110, 133, 237 

Ntds.dit, Datei 214, 577 

Ntdsai.dll 21 

NTDS-Datenbank 214 

Ntdsdbutil.exe, Tool 641 

Ntdsutil.exe, Tool 

AD DS-Komponenten und 29, 60 

bei der AD DS-Installation 233 

für AD-Snapshots 600 

IFM-Feature und 580, 584 

Notfallwiederherstellung 585, 592, 593, 608 

Replikation verknüpfter Werte und 595 

Überblick 9 

Wartung 569, 570 

NTLM v1, Authentifizierung 299 

NTLM v2, Authentifizierung 299 

NTLM-Authentifizierung (NT LAN Manager) 

in AD LDS 628, 629 


Sicherheit 274, 276, 298 

O 

Obere Grenzwerte 97, 100, 101 

Objekt-ACEs 273 

Objektbasierte dauerhaft geltende Nutzungsrichtlinie 15 

Objekte 

ActiveX Data (ADO) 383 

Adsiedit.msc, Tool für 388 

anfängliche Verarbeitung von GPOs 406 

attributeSchema 32 


Besitz 336 

effektiv 333 

speziell 325 

Standard 323 

Vererbung 330 

Binary Large Object (BLOB) 672 

classSchema 32, 33 

Clientgruppenrichtlinie 404 

Computer 259 

deaktivieren im Schema 39 

Designierte Dateitypen 528 

dynamicObject-Klasse 178 

Ermittlung in anderen Domänen 48 

Erzwingen 527 

Gruppenrichtlinien 59, 151 

Verarbeitungsbereich 420 

verwalten 432 

inetOrgPerson 178 

Kennworteinstellungen 518 

Konfigurieren der Überwachung 344 

Kontingente für den Objektbesitz 315 

Ldp.exe, Tool für 388 

lokales Gruppenrichtlinienobjekt (LGPO) 396, 398 

löschen 102, 581 

NTDS Settings, Objekt 237 

Organisationseinheiten für Verwaltung 58 

Paketreplikation 106 

Phantom 594 

PowerShell-Skripts und 385 

Querverweis 29, 237 

resultierende Kennworteinstellungsobjekte (PSOs) 521 

rootDSE 620, 634 

Sicherheitsbeschreibungen 321 

Sicherheitsprinzipal 270 

standardmäßige GPOs in Domäne 516 

Standortverknüpfung 122 

Tombstone 581, 597, 606 

Überwachen von Änderungen 343 

ursprüngliche Aktualisierungen 95 

VBScript und 383


Objekte (Fortsetzung) 

Verbindung 110 

Vertrauenswürdige Herausgeber 528 

Verwaltungszugriff 321 

X.500-Objekt-IDs für 38 

Objektidentifikationsmodell, LDAP als 41 

Objektverwaltung 351 

automatisieren 379 

Befehlszeilentools für die 379 

LDIFDE und CSVDE 380 

VBScript 382 

Benutzer 352 

Computer 370 

Dienstkonten und 359 

Drucker 373 


Gruppen 360 

Arten 360 

Bereich 361 




inetOrgPerson 357 

Kontakte 358 


veröffentlichte freigegebene Ordner 377 

Öffentliche Schlüssel, Zertifikate für Siehe auch PKI (Public 

Key-Infrastruktur), 11 

Öffentliche Zertifizierungsstellen 749 

Office SharePoint Server 2007 14, 693 

Offlinedateien, für Ordnerumleitung 453, 468 

Offline-Stammzertifizierungsstellen 688 

Offlinezertifizierungsstellen 657 

OK As Delegate, Kerberos-Ticketflag 285 

Online Certification Status Protocol (OCSP) 12, 659, 666, 

667, 687 

Online-Responder-Dienst 12, 666, 688, 689 

Optimierung für schnelles Anmelden, Feature 407 

Ordnerumleitung 462 

Computerstart und 409 

Gruppenrichtlinieneinstellungen für 59, 394, 469 

Gruppenrichtlinienimplementierung und 432 


Offlinedateien für 453, 468 

Reihenfolge der Gruppenrichtlinienverarbeitung und 421 

synchrone GPO-Verarbeitung und 407, 408 

Organisations-Admins (Gruppe) 49 

AD DS-Struktur und 156, 159, 160, 163 



Domänenerstellung und 216 

Entfernen von Domänencontrollern 237, 238 

Erstellen von Gesamtstrukturvertrauensstellungen 263 


Migration 252 

Organisationseinheiten (OUs) Siehe auch Verwaltung, delegieren, 

188 

administrative Autonomie 248 

autorisierende Wiederherstellung 591 

Bereitstellen von Sicherheitsvorlagen 536 


entwerfen 189 

Gruppenrichtlinien und 429 

in AD DS 56 

Kennwortrichtlinien und 7 

oberste OU-Struktur für Domäne 177 

Sperrung und 415 

Struktur, Überblick 188 

Organisationsvertrauen, Einstellungen 517 

Organisatorisches Gesamtstrukturmodell 161, 162 

Outlook-Clients 199 

P 

PAC-Daten (Privilege Attribute Certificate) 279, 282, 297 

Partitionen 

Anwendungsverzeichnis 29, 114, 235 

DNS-Anwendung 75 

Domänencontrollerintegration mit 160 

in AD DS 41 

in AD LDS 616, 630 

Konfigurationsverzeichnis 29, 49, 155 

mehrere logische, in AD DS 94 

Querverweisobjekte und 48 

redundante Ringe basierend auf 112 

Replikation der Konfiguration 133 

Standardanwendung 73 

Passport-Authentifizierung 276 

Password Settings Containers (PSCs) 7, 518 

Patriot Act von 2001 (USA) 145 

PDC-Emulator, Betriebsmasterrolle 


domänenbasierte Vorlagendatei, Speicherung auf 475 

Kennwörter und 109 

Konsole „Gruppenrichtlinienverwaltung“ und 417 


Standorte 208 

Tools für 31 


Peerdomänen 46 

Personal Information Protection Act (Japan) 145 

Personal Information Protection and Electronic Documents 

Act (Kanada) 145 

Persönliche Identifizierungsnummer (PIN) 658 

Pfadregeln, Richtlinien zur Softwareeinschränkung und 526 

Phantomobjekte 594 

PIN (Personal Identification Number) 293 

Ping, Dienstprogramm 215 

PKI (Public Key-Infrastruktur) 12 

Gegenseitige Zertifizierung, Hierarchie für 683 

Richtlinieneinstellungen für 528 


Verbunddienstanforderungen 747 

Zertifikatdienste (CS) 649, 650 

PKIView 12 

Planen der Replikation 104, 124 

Planungsmodus, für RSoP 435 

PolicyDefinitions, Ordner 475 

Portale 613 

Portquery, Tool 295 

Ports 127, 295


POSIX-Subsystem (Portable Operating System Interface for 

UNIX) 272, 321 

Postfachserver 200 

PowerShell-Skripts 

DisplayADLDSInstances.ps1 620 


Exchange-Verwaltungsshell 387 

ListADDSDomains.ps1 50 

ListADDSSites.ps1 54, 122 

ListAppPartitions.ps1 75 

ListDomainControllers.ps1 28 

ListFSMOs.ps1 31 

Objektverwaltung über 385 

Primäre Gruppen 272, 321 

Primärer DC-Emulator Siehe PDC-Emulator, Betriebsmasterrolle 

Prinzip der geringsten Rechte 313 

Problembehandlung 

Anmeldeskripts 496 

Dokumentieren der Prozesse 153 


Erkennung von langsamen Verbindungen 413 

Gruppenrichtlinien 401, 437, 444 




Dcdiag.exe, Tool für 134 

Fehler 131 

Repadmin, Tool für 133 

Zertifizierungsstellen (CAs) 12 

Problembehandlung bei der Active Directory-Replikation, 

Website 133 

Projekte, Organisationseinheiten basierend auf 192 


Propagierungsdämpfung 100 

Protected, Steuerungsflag 273 

Protokollierung 

CryptoAPI 2.0-Diagnose 651 

Debugging 87 

Gruppenrichtlinien 398 

Richtlinienergebnissatz (RSoP), Modus für 435 

Transaktionen 570, 571, 578 

Verzeichnisdienstüberwachung und 6 

zirkulär 576, 579 

Proxy, Kerberos-Ticketflag 285, 286 

Prüfpunktdatei 578 

Pubprn.vbs, Skript 373 

Q 

Quality of Service (QoS), richtlinienbasiert 394 

Quelldomänencontroller 10 

Querverweisobjekte 29, 48, 237 

R 

Rangfolge von Kennworteinstellungsobjekten (PSOs) 7, 8 

Rechte 313, 337, 388 

Delegieren administrativer Rechte 57, 177 

zuweisen 510, 511 

Rechtekontozertifikat (RAC) 698 

Rechteverwaltungsdienste (RMS) 691 

Bereitstellung 701 

Betrieb 699 

Features 692 


Clients 708 

Clusterinstallation 703 

Konfigurieren von Verbindungspunkten 707 

Überlegungen vor der Installation 702 


Lizenzen 699 

Überblick 15 

verwalten 713 

Ausschlussrichtlinien 725 

Berichte 728 

Sicherheitsrichtlinien 726 

Vertrauensrichtlinien 713 

Vorlagen für Benutzerrechterichtlinien 720 

Zertifikate 697 

Rechtliche Anforderungen in den AD DS 145 

Redircmp.exe, Dienstprogramm 372 

Redundanter Ring, für Domänencontroller 112, 114 

Redundanz 

beim Planen der Notfallwiederherstellung 576 

für Replikation 101 

für Stammdomäne 209 

Standortverknüpfungen 124 

Regelmäßige Gruppenrichtlinienaktualisierungen 407 

Registrierungsbasierte Parameter 58 

Registrierungsdienst für Netzwerkgeräte 12, 682 

Regsvr32 Schmmgmt.dll, Befehl 35 

Reine Lizenzierungscluster, RMS 695 

Relativer definierter Name (RDN) 42 

Remoteaktivierung über LAN 494 

Remotedesktop 314 

Remotedifferenzialkomprimierung (RDC) 104 

Remotedomänen, Wiederherstellen von Gruppen in 596 

Remoteprozeduraufrufe (RPCs) 

bei der standortinternen Replikation 105 

DNS und 66, 78 

für Kennwortaktualisierung 109 

in AD LDS 614 

Konnektivität für 109 

Replikationsschnittstelle und 21 

RID-Master (Relative Identifier) und 209 

über IP-Verbindung 127 

Remoteserver-Verwaltungstools 475 

Remoteverwaltungs, Ausnahme 438 

Rendom.exe 29 

Repadmin.exe, Tool 

/bridgeheads, Befehl 128 


Replikation 99, 114, 133 


zur Problembehandlung bei der Replikation 138 


AD LDS-Sicherheit 646 

Aktualisierungsarten 95 

Bandbreite 194 

Distributed File System (DFS) 179


Replikation (Fortsetzung) 

dringend 108 


Entwurf 197 

erzwungen 591 

GPOs und 402, 445 

Grenzen für 45, 49, 169 

im Vergleich zur Zonenübertragung 72 

in mehreren Domänen 171 

in Windows Server 2008 96 

Kennwort 10 

Kennwortreplikationsrichtlinie für 26 

Kennwortreplikationsrichtlinie für die 5 

Kerberos-Problembehandlung 296 

Komprimierung 194 

Latenz 107 

Leistungsindikatoren 557 

Migration 252 

Modell 94 

Multimaster 22, 28 

Netzwerkdatenverkehr 10 




Fehler 131 

Repadmin.exe, Tool für 133 

Schnittstelle 21 

Standorte und 54 

standortintern 104 

standortübergreifend 106, 120 

Bridgeheadserver 128 



Transportprotokolle für 127 

zusätzliche Standorte und 121 

Synchronisierung 42 


Topologieerstellung 109 

globaler Katalog 116 


Konsistenzprüfung (KCC) für 110 

RODCs und 118 

standortintern 112 

standortübergreifend 117 

Verbindungsobjekte für 110 


unidirektional 4 

verknüpfte Werte 178, 363, 594 

verwalten 320 

Verzeichnis 612, 613 

Verzögerung, bei der Installation 230 

von AD LDS 620, 638 

von Änderungen 97 

Aktualitätsvektoren und Propagierungsdämpfung 100 

Änderungsstempel und Konfliktlösung 101 

in USNs 98 

obere Grenzwerte 100 

Objektlöschung 102 

von RODC-Filterattributen 4 

von SYSVOL-Ordner 104, 602 

zwischengespeicherte Anmeldeinformationen 208 

Replikation verknüpfter Werte 363, 594 

Replizierte Aktualisierungen 95 

Replizierte Namenskontexte, Einstellung 114 

Ressourcen, Organisationseinheiten 192 

Ressourcendomänen 175 

Ressourcengesamtstrukturmodell 162, 165 

Ressourcenmonitor 546 

Ressourcenverwaltung 320 

Resultierende Kennworteinstellungsobjekte (PSOs) 521 

Revisionsstufe, in SID 270 

RFC 2798-Kompatibilität 357 

RFC 2822-E-Mail-Namen 758 

Richtlinien zur Änderungskontrolle 153, 156, 164 

Richtlinienbasierte Dienstqualität (QoS) 394 

Richtlinienergebnissatz (RSoP) 8, 430, 435, 438 

Richtlinien-Ersteller-Besitzer, Gruppe 429 

Richtung von Gesamtstrukturvertrauensstellungen 165 

RID-Master (Relative Identifier) 



RODC-Beschränkungen und 27 


Tools für 31 


Zweck 30 

Ringe, Replikation 112, 114 

Ringtopologie 621 

RMS-Administratoren 726 

Rollback, bei der Notfallwiederherstellung 246 

rootDSE-Objekt 620, 634 

Router, mit Portzuordnung 127 

Routingfähige IP-Infrastruktur 109 

RSA-Algorithmus 673 

S 

SAM-Datenbank (Sicherheitskontenverwaltung) 21, 229, 237 

Sammlung veralteter Objekte, Wartung 103, 566 

Sammlungssätze und Berichte 551, 555 

Sarbanes-Oxley Act von 2002 (USA) 145 

SASL-Bindungen, Authentifizierung 628, 629 

Schattengruppen 7 

Schattenkonten 742 

Schema 

AD LDS-Verzeichnispartitionen für 617 

Betriebsmaster 27, 28, 31, 209, 604 

Display Specifier 617 

erweiterbar 612 


Gesamtstrukturdomänen 156, 157 

globaler Katalog und 23 

in AD DS 32 

ändern 34 



neue Attribute 36 


verwalten 320 

Verzeichnispartition für 43


Schema-Admins (globale Gruppe) 35 

Schema-Admins (Gruppe) 49 

AD DS-Struktur und 156, 159, 163 



Schlüssel, Archivierung und Wiederherstellung 668 

Schlüsselverteilungscenter (KDC) 

bei der Autorisierung 275 


Kerberos, SRV-Einträge 64 

PAC-Daten vom 297 

Verschlüsselung und 279 

Verwalten gemeinsamer geheimer Schlüssel 277 

Zurücksetzen des Kennworts 371 

Schlüsselwiederherstellungs-Agents 669, 672 




für Schemaänderung 35 

neue Features in 9 

resultierende PSOs und 521 

Security Support Provider (SSP) 274 

Sicherheitskonfigurations-Assistent, Benutzer 301 

Schreibgeschützte Domänenamenserver 5 

Schreibgeschützte Domänencontroller (RODCs) 


DNS und 78 

eindeutige Rollen 20 

Entwurf 205 

im Vergleich zu SYSKEY-Einstellungen 312 

Installieren der AD DS und 234 

Kennwortreplikationsrichtlinie für 10, 26, 220 

Konto erstellen für 221 


SRV-Einträge und 66 

Überblick 3 

Windows Server 2008 178 

Script Center Script Repository-Website 28, 122 

Scriptomatic.exe 427 

Scwcmd, Befehlszeilenprogramm 302, 303 

Secedit.exe, Tool 537 

Secure Sockets Layer (SSL) 616, 631, 649, 658, 745 

Secure Sockets Layer-Transport Layer Security (SSL- 

TLS) 12, 276 

Secure-Multipurpose Internet Mail Extensions (S-MIME) 12 

Security Support Provider (SSP) 274 

Selbstsignierte Zertifikate 749 

Semantische Datenbankanalyse 571 

Server 


für Verbunddienste 753 

für Verbunddienstproxy 754 

in AD LDS 614 

Verstärken der Sicherheit 522 


Richtlinien zur Softwareeinschränkung 525 

Web 746, 752 

Server Core-Installation 214, 221, 234 

Server Message Block-Signatur Siehe SMB-Signatur (Server 

Message Block) 

Servergespeicherte Benutzerprofile 453, 457, 460, 680 

Server-Lizenzgeberzertifikat (SLC) 698 

Server-Manager 11, 15, 219 

Server-Operatoren (Gruppe) 160 

Serverseitige Erweiterungen (SSEs) 403 

Serverspeicherung, Anmeldeinformationen 680, 688 

Set-ExecutionPolicyRemoteSigned, Befehl 28, 75 

Setspn.exe, Tool 317 

Shortcutvertrauensstellungen 51, 176, 285 

Sichere Drahtlosnetzwerke 12 

Sicherer Kanal, Signatur von Netzwerkdatenverkehr über 216 

Sicherheit Siehe auch Rechteverwaltungsdienste (RMS), 269 

administrative Delegierung 335 

administrative Vorgehensweisen 312 

als Dienstanforderung in den AD DS 146 

Ausstellungsrichtlinien 687 


Autorisierung 275 

beim Bereitstellen der Zertifikatdienste 658 

DDNS und 76 

Delegierungseinträge und 80 

digital signierte Token 736 

empfohlene Vorgehensweisen 167, 315 

Ereignisanzeige und 560 

Fremde Sicherheitsprinzipale, Container 230 




Replikation 623, 646 



für Domänencontroller 195, 216, 300 

Angriffsfläche verringern 300 

Benutzerrechtezuweisung, Richtlinieneinstellungen 308 

Ereignisprotokolleinstellungen 307 

Sicherheitsoptionen, Richtlinieneinstellungen 309 

SMB-Signatur 310 


Überwachungsrichtlinieneinstellungen für 304 

für Rechteverwaltungsdienste (RMS) 726 

für RODCs 3, 25, 207 

Gesamtstrukturentwurf und 158 

Grenzen für 49 

Grenzen für Richtlinien 45, 170 

Gruppen 360 

Gruppenrichtlinien für 58, 394 

Gruppenverwaltung 320 

Hardwaresicherheitsmodul (HSM) 661 

in Gesamtstruktur-Stammdomäne 49 

integrierte Zonen 72 

interner DNS-Server 181, 182 

Kennworteinstellungsobjekte (PSOs) und 8 

Kerberos 276 


Authentifizierungsdelegierung 286 

Interoperabilität 294 



Public Key-Infrastrukturintegration 290 

Smartcardintegration 293


Sicherheit, Kerberos (Fortsetzung) 


Leistungsindikatoren 558 

NTLM-Authentifizierung 298 

objektbasierte dauerhaft geltende Nutzungsrichtlinie 15 

Objektverwaltung und 367 

physisch 161 

Richtlinien auf Domänenebene 177 

Richtlinienverwaltung 320 


Testen von Änderungen 349 

Version 3-Vorlagen 673 

Weiterleitungen für 184 

Zugriffssteuerungslisten für 271 

Zugriffstoken 273 

Sicherheit, Gruppenrichtlinien für 505 

fein abgestimmte Kennwortrichtlinien in 517 


planen 518 

resultierende PSOs in 521 

Netzwerk 528 

drahtloses Netzwerk 531 


für Windows-Firewall und IPsec 532 

verkabeltes Netzwerk 529 

Standarddomänenrichtlinie und 506 

Kontorichtlinien in 506 

lokale Richtlinien in 509 

standardmäßige GPOs 516 

Standardrichtlinie für Domänencontroller und 511 

Benutzerrechtezuweisung 511 

Sicherheitsoptionen für 515 

Verstärken der Serversicherheit 522 


Richtlinien zur Softwareeinschränkung 525 

Vorlagen 534 

Sicherheitsaufruf (SAS) 274 

Sicherheitsbeschreibung 272, 321 

Sicherheitsfilterung 425, 444, 445 

Sicherheitskennungen (SIDs) 160, 321 

bei der Migration 246 


externe Vertrauensstellungen und 54 

filtern 167 

Historie 178 

RID-Betriebsmaster und 30 


Sicherheitskonfiguration und -analyse, Snap-In 536 

Sicherheitskonfigurations-Assistent 301, 302, 311, 537 

Sicherheitskonfigurationsdatenbank 302 

Sicherheitskonvertierungs-Assistent 259, 260 


AD DS-Migration 246 

ausgewählte Authentifizierung und 166 


Domänenressourcenzugriff 50 

Gesamtstrukturvertrauensstellungen und 52 

im Vergleich zu Organisationseinheiten 59 

RID-Master, erstellen 30 


Sicherheitsprotokoll 342 

Sicherung und Wiederherstellung Siehe auch Notfallwiederherstellung 

Active Directory Lightweight Directory Services (AD 

LDS) 640 




Gruppenrichtlinienobjekte 432 

Häufigkeit 583 

Medien 10 

Medien für 315 

Notwendigkeit 581 

standardmäßige GPOs in Domänen 516 

Tombstone-Ablaufzeit und 581 


verwalten 320 

Sicherungs-Operatoren (Gruppe) 160 

SIDHistory-Attribut 167 

Simple Mail Transfer Protocol (SMTP) 21 

Benutzerprinzipalname und 357 


Replikation und 107, 109, 127 

Skripts Siehe auch JScript, Siehe auch PowerShell-Skripts, 

Siehe auch VBScript 

ADSI-basiert 565 

Benutzerverwaltung über 477 

clientseitige Erweiterung für 409 

für Gruppenrichtlinien für Benutzerdesktops 477 

für Gruppenrichtlinienverwaltung 440 

für Versionsnummern 410 

Gruppenrichtlinien für 394 


im Vergleich zu Einstellungen 478, 496 

synchrone Anmeldung 408 

SLAs (Service-Level Agreements) 144, 544 

Smartcards 

Anmeldung 12 

Sicherheit und 293, 314 

Zertifikate und 12, 658 

SMB-Signatur (Server Message Block) 


für Domänencontrollersicherheit 310, 516 

Migration 265 


Snapshotvolume 9 

Softwarebereitstellung 58, 408, 409, 478 


Einschränkungen 494 

entfernen 490 

Konfigurieren der Dateierweiterungsaktivierung 489 

Konfigurieren von Paketeigenschaften 484 

Netzwerkbandbreite und 482 

Nicht-Windows Installer 483 

planen 493 

Richtlinien zur Einschränkung 524, 525 

Windows Installer-Technologie für 478, 491 

Zuverlässigkeitsüberwachung 549 

Speichern fein abgestimmter Kennwörter 7 

Speichern und Weiterleiten, Replikationsprozess 94, 95


Speicherzuweisungsfehler 297 

Sperren der Geräteinstallation 395 

Sperren von Zertifikaten 

entwerfen 687 


Statuswerte 12 

Zertifikatsperrlisten (CRLs) 655, 660, 688, 748 

Spezialidentitäten, für Gruppen 230 

Spezielle Berechtigungen 325 

SQL Server-Datenbank, RMS und 17 

SRV-Ressourceneinträge 

Authentifizierung und 55 

DNS und 62, 216 

DNS und AD DS-Integration 186 

entfernen 237 


standortspezifisch 205 

SSL-Clientauthentifizierungszertifikate 748 

SSL-Serverauthentifizierungszertifikate 747, 748 

SSO-Bereitstellung Siehe Verbunddienste 

Stammcluster, RMS 695 

Stammdomäne 204, 209 


Stammhinweise 83, 184, 227 

Stammzertifizierungsstellen 659, 747 

Standard Industrial Classification (SIC) 733 

Standardanzeigename 356, 358 

Standardberechtigungen 323 

Standarddomänenrichtlinie Siehe auch Domänen, 289, 506 

Kennworteinstellungsobjekte und 7, 8 

Kontorichtlinien in 506 

Kontosperreinstellungen und 7 

lokale Richtlinien in 509 

Standardkonfiguration von Vertrauensstellungen 175 

Standortabhängige Anwendungen 482 

Standortabhängige Netzwerkdienste 55 

Standorte Siehe auch Standortübergreifende Replikation, Siehe 

auch Standortinterne Replikation 


AD DS 54 

AD LDS 640 

automatische Abdeckung 69, 205 


Entwurf 107 

in der Konsole zur Gruppenrichtlinienverwaltung 

(GPMC) 417 

Replikation basierend auf 621 

SRV-Ressourceneinträge und 65 

Topologieentwurf 193 

Verknüpfungen für 122, 197 

Verknüpfungsbrücken für 126, 199 

zugehörige Clients 68 

Standortinterne Replikation 104, 112, 621 

Standortname, Parameter 67 

Standortname-des-ersten-Standorts 55, 121 

Standortspezifische SRV-Einträge 55 

Standortübergreifende Replikation 120 

Benachrichtigung 125 


in AD LDS 621 

Komprimierung und 125 


standortübergreifender Messagingdienst 109 



Topologieerstellung 117 

Transportprotokolle für 127 


zusätzliche Standorte und 121 

Standortverknüpfungsbrücke 126, 199 

Startkonfigurations-Datenspeicher (BCD) 580 

Statisches Berechtigungsvererbungsmodell 330 

Statusbasiertes Replikationsmodell 95 

Stelleninformationszugriff (AIA) 660 

Steuerungsflags 272 

Strikte Replikationskonsistenz 106 

Strukturen, Domäne 


einbezogen 197 

in Stammdomäne 85, 216 

Struktur 175 

Strukturstamm-Vertrauensstellungen 51, 176 

Stubzonen 83, 149 

Suchen 34, 376 

Suchen, Befehl 10 

Suffixrouting, Name 168 

Superverbindliche Benutzerprofile 459 

Svchost, Dienst 404 

Synchrone Anmeldeskripts 408 

Synchrone Verarbeitung von GPOs 407, 408 

Synchrone Verbindungen 127 

Synchronisierung 

AD DS und AD LDS 643 

bei der Migration von Legacyanwendungen 15 


von Startskripts 478 

von Verzeichnisdienstdaten 515 

von Verzeichnissen 169 

von Zertifikaten 680 


System Center Configurations Manager (SCCM) 494 

System Center Operations Manager 136, 546 

Systemcontainer 7 

systemmayContain-Attribute 33 

Systemmonitor 55, 543, 547, 548 

systemmustContain-Attribute 33 

Systemstabilitätsbericht 549, 550 


System-Zugriffssteuerungslisten (SACLs) 6, 272, 306, 322 

SYSVOL-Ordner 

ADMX-Dateien im 398 

Deinstallieren der AD DS und 237 

DFS-Replikation für 179 

Gruppenrichtliniencontainer im 399, 401 

Installation 215 


sichern 580 

Speicherort für 228 


Wiederherstellung von Active Directory 602


T 

TCP-IP-Netzwerk (Transmission Control Protocol-Internet 

Protocol) 62, 295 

TCP-Ports (Transmission Control Protocol) 42 

Technische Anforderungen in den AD DS 143 

Technische Referenz, Tools 486 

Teilattributsatz (PAS) 23, 24 

Teilautorität, in SID 270, 271 

Temporäre Benutzerprofile 461 

Terminaldienste 512, 513 

Testgesamtstruktur, für Schemaänderungen 36 

Testumgebung 349 

Thawte, Zertifizierungsstelle 292 

Ticket-Granting Service (TGS) Siehe auch Kerberos-Sicherheit, 

Siehe auch Kerberos-Ticketflags 

Exchange-Protokoll 282 

Kerberos-Richtlinieneinstellungen für 290 


Sitzungsschlüssel 279, 285 

Verantwortung 278 

Tokensignaturzertifikate 747, 753 

Tokensz.exe, Tool 297, 317 

Tombstone-Objekte 

Ablaufzeit 581 



Wartung und 566 

Wiederbelebung 597 

Topologietest 54 

Transaktionsprotokolle 570, 571, 578 

Transformationsdateien 486 

Transitive bidirektionale Vertrauensstellungen 51, 155, 157 

Transitive Standortverknüpfungen 124, 126 

Transitive Vertrauensstellungen 48, 155, 157, 165 

Transport Layer Security (TLS) 745 

Transportprotokolle, Replikation 124, 127 

Trennung der Administratorrolle 5 

Tupelindex 35 

U 

Über- und untergeordnete Domänen, Konfiguration 46 

Übergeordnete Container 96 

Übergeordnete/untergeordnete Elemente, Vertrauensstellung 

zwischen 176 

Übernetzwerke 195 

Überprüfen der AD DS-Installation 230 

Übertragbar, Kerberos-Ticketflag 284, 286 


administrative Delegierung 341 

administrative Maßnahmen 161 

Administratorenkonten 314 

bei der Migration zwischen Gesamtstrukturen 256 

Benutzerrechtezuweisung und 514 


Archivieren von Protokollen 307 



Unterkategorien 304 

Verzeichnisdienständerungen, Unterkategorie 305 

Domänendienste 6 


einzuschließende Elemente 562 

Gründe 544 


Server 546 

Ressourcenmonitor 546 

Sammlungssätze und Berichte 551 

Systemmonitor 547 

Zuverlässigkeitsüberwachung 549 


Überwachungsrichtlinie für 301, 509 

Version 3-Vorlagen 674 

Vorgehen 554 

Baselines und Schwellenwerte 555 

Ereignisanzeige 560 

Leistungsindikatoren und Schwellenwerte 556 


Umbenennen von Domänen 29, 177, 178 

Umkehrbare Verschlüsselung 7, 8 

Umkreisnetzwerk 14 

Umkreisnetzwerke 

AD LDS 644 

als Sicherheitsrisiko 146 

Business-to-Employee (B2E), Identitätsverbundszenario 

733 

Gesamtstrukturbereitstellung 157 

Windows NT-Token-basierte Anwendung 742 

Unbeaufsichtigte Installation der AD DS 221, 231 

Unbeaufsichtigtes Entfernen der AD DS 238 

Unbelastete Umgebungen 243 

Unidirektionale Gesamtstrukturvertrauensstellungen 162 

Unidirektionale Replikation 4 

Unidirektionale Vertrauensstellungen 165, 263 

Uniting and Strengthening America by Providing Appropriate 

Tools Required to Intercept and Obstruct Terrorism Act von 

2001 (USA) 145 

Universal Description Discovery and Integration (UDDI) 733 

Universal Naming Convention (UNC) 373, 377, 464, 483 

Universelle Gruppen 24, 96, 204 

Authentifizierung und 364 


globaler Katalog, Speicherung in 363 

Verfügbarkeit 362 

zwischenspeichern 364 

UNIX 185, 187, 243, 272, 321 

Unmount Nummer, Befehl 601 

Unteilbare Operationen, ursprüngliche Aktualisierungen 96 

Unterdomänen, delegiert 84 

Untergeordnete Domänen 46, 48, 216 

Untergeordnete Zertifizierungsstellen 661 

Unternehmens-PKI, MMC-Snap-In 12, 652, 689 

Unternehmensverzeichnisspeicher 15, 613 

Unternehmenszertifizierungsstellen (CAs) 128, 292, 656, 

661, 688 

Unterstrukturindizes 35 

Update Sequence Numbers (USNs) 97, 591 

Upgrade 


beim Migrieren auf AD DS 245, 250


Installieren der AD DS als 214 

Software 488 

Ursprüngliche Aktualisierungen 95, 100 

Ursprungsserver 101 

USA Patriot Act von 2001 145 

User Datagram Protocol (UDP) 62, 297 

userAccountControl-Attribut 8 

Users, Container 366 

uSNChanged-Attribut 98, 100 

V 

VBScript 


für AD DS-Informationen 28 

für Gruppenrichtlinienverwaltung 440 

Hinzufügen von Druckern über 373 


zum Automatisieren der Objektverwaltung 382 

Verbindliche Benutzerprofile 453, 459 

Verbindungslokale Ipv6-Adresse 66, 69 

Verbindungsobjekte 110 

Verbindungspunkte, RMS 706, 707 

Verbunddienste 165, 613, 731 

Bereitstellungsszenarien 

Federated-Web-SSO 738, 740 

Federated-Web-SSO mit Gesamtstrukturvertrauensstellung 

738, 742 

Web-SSO 738 

Identitätsverbund und 732 

Implementierung als Federated-Web-SSO-Entwurf 

Installieren von Verbundservern 753 

Installieren von Verbundserverproxy 754 

Implementierungsanforderungen 

Clientwebbrowser 745 


PKI (Public Key-Infrastruktur) 747 

Webserver 746 

Kontopartnerkonfiguration 


ausgehende Ansprüche zuordnen 762 


Ressourcenpartner 761 

Rechteverwaltung, Integration in 16 

RMS und 704, 718 

Überblick 13 

Verbunddienstproxy 14 

Vererbung 34, 330 

Verfolgung 

Druckerstandorte 376, 389 

zum Steuern der Delegierung 339 

Verfügbarkeit, erforderliche 143, 144 

Verifizierungszertifikate 565, 747 

Verisign, Zertifizierungsstelle 292 

Verkabelte Netzwerke, Sicherheit 528, 529 

Verknüpfte Attribute 96, 103 

Verknüpfungen 

als Brücken für Standorte 126 

Geschwindigkeit 149 

GPO-Reihenfolge 421 

Gruppenmitgliedschaften und 594 

Konsole „Gruppenrichtlinienverwaltung“ 418 

mit GPOs 418 

mit IP-Subnetzen (Internet Protocol) 195 

Standort 122 

Verknüpfungspunkte, Benutzerprofile und 453 

Verlängerbar, Kerberos-Ticketflag 285 

Veröffentlichen 

Anwendungen 480, 481 

freigegebene Ordnerobjekte 377 

RMS, vertrauenswürdige Domänen 716 

Verschachtelte Gruppen 178, 362, 363 

Verschieben, bei der Migration 246 

Verschlüsselndes Dateisystem (EFS) 12, 517, 649, 653, 658 

Verschlüsselung 7, 8, 11, 649 

Versionsnummern 101, 102 

für Gruppenrichtliniencontainer (GPCs) 400 

für Gruppenrichtlinienkomponenten 402 

für Gruppenrichtlinienobjekte (GPOs) 409 

Windows-Benutzerprofile und 454 

Verstärken der Sicherheit Siehe Sicherheit, Gruppenrichtlinien 

für 

Verteiler-Agent, Protokolldatei 260 

Verteilergruppen 360 

Verteilte Anwendungen 15 

Verteilte Vorlagen für Benutzerrechterichtlinien 720, 721 

Verteilung von Zertifikaten 655, 687 

Vertrauensstellungen 

Active Directory-Domänen und -Vertrauensstellungen, 

Snap-In 60 

AD DS 50 

Assistent für neue Vertrauensstellungen 168, 294 

ausgewählte Authentifizierung 162 

bei der Migration zwischen Gesamtstrukturen 255, 262 

Bereich 294 

bidirektional 176, 263 



gemeinsam, in Gesamtstrukturen 49 

Gesamtstruktur 164, 179 

gesamtstrukturübergreifend 358 

Grenzen für 46 

Kerberos-Authentifizierung und 276 


Rechteverwaltungsdienste (RMS), Richtlinien für 713 


Shortcut 176, 285 

Struktur 175 

Strukturstamm 176 

transitiv 48, 165 

transitiv, bidirektional 51, 155, 157 

verwalten 320 

Zertifizierungsstellen (CAs) und 654 

zwischen übergeordneten und untergeordneten Elementen 

176 

Vertrauensstellungen:Gesamtstruktur Siehe auch Verbunddienste 

Vertrauenswürdige Administratoren 156, 160 

Vertrauenswürdige Herausgeber, Objekt 528 

Vertrauenswürdige Stammzertifizierungsstellen 517 

Vertraulichkeit 145, 146


Verwaiste Objekte 332 

Verwaltung, delegieren 57, 177, 319 

Aufgaben 320 

Entwurf der Organisationseinheiten 189 

für schreibgeschützte Domänencontroller 206 

Objektberechtigungen 323 

Besitz 336 

effektiv 333 

speziell 325 

Standard 323 

Vererbung 330 

Objektzugriff 321 

planen 348 



Verwaltungsmodell des Unternehmens 153 

Verwaltungsmodell mit Benutzerkonten 153 

Verwaltungstools für die AD DS 10 

Verweigern-ACEs 273, 322 

Verweigernde Berechtigungen 334 

Verzeichnisdienst, Ereignisprotokoll 136, 564 

Verzeichnisdienst-Agent (DSA) 21, 278, 614 

Verzeichnisdienständerungen, Unterkategorie 305, 343 

Verzeichnisdienstüberwachung 6 

Verzeichnisdienst-Wiederherstellungsmodus (DSRM) 

bei der AD DS-Installation 229, 238 

Notfallwiederherstellung 587, 592, 593 

Überblick 8, 9 


Verzeichnisfähige Anwendungen 152 

Verzeichnispartitionen 


in AD LDS 612, 616 



Schema 617 

Namen 619 

Virtuelle Private Netzwerke (VPNs) 12, 147, 265, 494, 495 

Visual Basic 440 

Vollqualifizierter Domänename (FQDN) 86, 223, 288 

Volumeschattenkopie-Dienst (VSS) 9, 579 

Vorlagen 

administrative 58, 471 

domänenbasiert 474 


in Gruppenrichtlinien 394, 398, 401 


Benutzerrechterichtlinien 720 

OCSP-Antwortsignatur, Zertifikat 667 


Version 3 673 

Zertifikat 669 

aktualisieren 675 

Bereitstellung 675 


entwerfen 685 



MMC-Snap-In für 689 

Sicherheitskonfiguration 674 

W 

W32tm.exe, Tool 317 

Warnungstasks 551 

Wartezeit, bei der Replikation 105 

Wartung 566 

Ntdsutil.exe 570 

Offlinedefragmentierung 569 

Onlinedefragmentierung 567 

Sammlung veralteter Objekte 566 

von Gruppenmitgliedschaften 594 

Wbadmin, Befehlszeilentool 232, 579, 587, 593, 608 

Web Services Description Language (WSDL) 733 

Web-Agents, AD FS 737, 739, 741, 745, 748, 751, 756 

Webbasierte Unternehmensverwaltung, Initiative 

(WBEM) 383 

Webdienst-Verbund-RPR (WS-F RPR) 14, 734 

Webregistrierung von Zertifizierungsstellen 12, 659, 661, 

663, 666 

Webserver 661, 746, 752 

Web-SSO, AD FS-Implementierung 738 

Weitbereichsnetzwerke (WANs) 27, 54, 93, 94 

Weitergeleitet, Kerberos-Ticketflag 284, 286 

Weitergeleitete Ereignisse 560 

Weiterleitbar, Kerberos-Ticketflag 284 

Weiterleitungen 80, 149, 184, 227 

Wevutil.exe, Befehlszeilentool 651, 689 

Where-Object, Cmdlet 387 

Wichtige Leistungsindikatoren (KPIs) 554 

Wiederherstellen Siehe Sicherung und Wiederherstellung, 

Siehe Notfallwiederherstellung 

Wiederherstellen von Gruppenrichtlinienobjekten, Assistent 

434 

Wi-Fi Protected Access 531 

Windows Explorer 215, 456 

Windows Installer-Technologie 461, 478, 491 

Windows NT 4.0-Aktualisierung 245 

Windows Script Host (WSH) 383, 477 

Windows Server 2008 96 

Windows Server 2008 Server Core-Installation 3, 25 

Windows Server-Sicherungsprogramm 232, 579, 608 

Windows Vista, RMS und 17 

Windows-Bereitstellungsdienste 494 

Windows-Firewall 528, 532 

Windows-Ressourcenschutz 580 

Windows-Token-basierte Anwendungen 737, 742, 744 

Windows-Token-basierter Agent 14 

Windows-Verwaltungsinstrumentierung (WMI) 383, 417, 

421, 427, 438 

Windows-Wiederherstellungsumgebung (Windows RE) 590, 

606, 608 

WINS (Windows Internet Name Service) 61, 62, 216 

Wscript.exe, Laufzeit 383 

WS-Verbundspezifikation 734 

X 

X.500-Objekt-IDs 15, 38 

X.500-Verzeichnisse 357


Z 

ZAP-Datei (Zero Administration for Windows Down-Level 

Application Package) 483 

Zeichenfolgenattribute 35 

Zentrale Verwaltung, in Gesamtstrukturentwurf 156 

Zertifikatdienste (CS) 649 

Akzeptanz von Zertifikaten mithilfe von Gruppenrichtlinien 

679 

automatische Zertifikatregistrierung 677 

Bereitstellungsszenarien 658 


Hierarchie 681 


Schlüsselarchivierung und -wiederherstellung 668 

Stammzertifizierungsstellen 659 

untergeordnete Zertifizierungsstellen 661 

Webregistrierung 661 

Zertifikatsperrung 662 

PKI-Komponenten (Public Key-Infrastruktur) 650 

Serverspeicherung von Anmeldeinformationen 680 


Überblick 11 

Vorgehensweise zur Sperrung 687 

Vorgehensweise zur Verteilung 687 

Zertifikatvorlagen für 673, 685 

Zertifizierungsstellen und 656 

Zertifikate 

Authentifizierungsmodell, basierend auf 291 

Benutzerkontenzuordnung 292 

Client-Lizenzgeberzertifikat 698 

digital 291 

Einstellungen für automatische Anforderung 517 

für Kontopartnerauthentifizierung 747 


PAC (Privilege Attribute Certificate) 279, 282, 297 

Rechteverwaltungsdienste (RMS) 697 

Richtlinien zur Softwareeinschränkung und 525 

selbstsigniert 749 

SSL-Serverauthentifizierung 747 

Stammzertifizierungsstelle 747 

Tokensignatur 747, 753 

Verbundserver 747 

Verbundserverproxy, Client 754 

Verifizierung 747 

Zertifikatsperrlisten (CRLs) Siehe auch Sperrung 

für SSL-Serverauthentifizierungszertifikate 748 

importieren 665 


Pfade für Verteilungspunkt 655, 660 

Überblick 12 

Veröffentlichungsintervall 660 

Verteilung 688 

zwischenspeichern 664 

Zertifikatverwendungserklärung 660 

Zertifizierungsstellen (CAs) 291 

auswählen 749 

bei der SMTP-Replikation 128 


eigenständig 12, 676 



MMC-Snap-In für 689 

Offline-Stammzertifizierungsstelle 688 


Stamm 659, 747 

untergeordnet 661 

Unternehmen 12, 688 

vertrauenswürdiger Stamm 517 

Verwaltungstools 650 

Webregistrierung 659 

Zertifikatdienste (CS) und 656 

Zirkuläre Protokollierung 576, 579 

Zonen laden, im Hintergrund 77 

Zoneneigenschaften 75 

Zugriffssteuerungseinträge (ACEs) 

beim Active Directory-Objektzugriff 321 

Beschreibung 271, 273 

in AD LDS 637 

Ldp.exe, zur Anzeige 328 

Zugriffssteuerungslisten (ACLs) 

ausgewählte Authentifizierung und 166 

DDNS und 76 

für GPO-Einstellungen 400, 401 

für Organisationseinheiten 58 

Gruppen und 360 

in AD LDS 636 

integrierte Zonen und 72 

Schemaobjekte und 617 

Sicherheitsfilterung und 426 


Zugriffstoken 


in AD LDS 627 

Migration 247 


Zugriffsverweigerung, Fehler aufgrund von 132 

Zulassen-ACEs 273, 322 

Zulassende Berechtigungen 334 

Zulässige RODC-Kennwortreplikationsgruppe 208 

Zuordnen 

ausgehende Ansprüche 762 

Laufwerke zu freigegebenen Ordnern 378 

n:1-Zuordnung von Zertifikaten 292 

Ports 127 

Zertifikate 292 

Zurücksetzen 

Kennwörter 339, 371, 588, 591 

Kontosperreinstellungen 7 

Zuverlässigkeit, erforderliche 143 

Zuverlässigkeitsüberwachung 55, 543, 549 

Zuweisen der Objektverwaltung, Assistent 330, 339, 429 

Zuweisen von Anwendungen 481 

Zweigstellen Siehe auch Schreibgeschützte Domänencontroller 

(RODCs), 3, 5, 201, 234 

Zweiphasenmigration 244 

Zweistufige Authentifizierung 147, 658 

Zwischenspeicherung 

Anmeldeinformationen 25, 206, 207 

Domänencontrollerinformationen 69


Mitgliedschaft in universellen Gruppen 25, 204, 364, 370 

Namen 295 

Schema 37 

Zertifikatsperrlisten (CRLs) 664

Über die Autoren 

803 

Stan Reimer ist President von S. R. Technical Services Inc., wo er als 

Unternehmensberater, Schulungsleiter und Autor tätig ist. Als Berater 

hat Stan Exchange Server und Active Directory für einige der 

größten Unternehmen Kanadas entworfen und implementiert. Als 

Schulungsleiter hat er sich auf das Entwickeln und die Durchführung 

von Schulungen zur Anpassung von Exchange Server, Active Directory 

und zum Thema Sicherheit spezialisiert. Stan ist außerdem der 

Hauptautor von Active Directory for Microsoft Windows Server 2003 

Technical Reference (Microsoft Press, 2003) und anderen Büchern zu 

Exchange Server und ISA Server sowie Autor vieler Microsoft Learning-Schulungen. 

Stan lebt und arbeitet in Winnipeg, mit dem Herzen 

(und oft auch in Gedanken) weilt er jedoch in einem Cottage 

am Big Whiteshell Lake. Stan ist unter der E-Mail-Adresse 

Stanr@srtech.ca erreichbar. 

Conan Kezema machte 1994 seinen Bachelor of Education und 

erkannte sofort die Bedeutung der Computertechnik und den Bedarf 

an erfahrenen, technisch hoch spezialisierten Pädagogen. Er zertifizierte 

sich als Microsoft Certified Systems Engineer und Microsoft 

Certified Trainer. In den letzten 12 Jahren war Conan im IT-Bereich 

als Lehrer, Systemberater, Architekt für Netzwerksysteme und technischer 

Autor tätig. In den letzten vier Jahren trat Conan für die S. R. 

Technical Services Inc. in zahlreichen Microsoft-bezogenen Projekten 

als Sachbereichsexperte, Instructional Designer und technischer 

Autor auf. Wenn Sie mit Conan bezüglich einer Schulung, 

einer Beratung oder dem Verfassen technischer Dokumente in Kontakt 

treten möchten, können Sie ihm unter ckezema@sasktel.net eine 

E-Mail schreiben. 

Mike Mulcare arbeitet für die Microsoft Corporation als Senior Product 

Manager für Onlineschulungsprodukte. Während seiner acht 

Jahre bei Microsoft hat Mike zahlreiche Schulungen zu Verzeichnisdiensten 

und Windows-Servernetzwerken sowohl als Instructional 

Designer als auch als Sachbereichsexperte entwickelt. Zusammen mit 

Stan Reimer ist er Autor von Active Directory for Microsoft Windows 

Server 2003 Technical Reference (Microsoft Press, 2003). 

Ursprünglich stammt Mike aus dem Staat New York und wohnt jetzt 

mit seiner Frau und seinen drei Söhnen in Seattle, Washington. In der 

Softwareberatungs- und Schulungsbranche ist er seit 1990 tätig.

804 Über die Autoren 

Byron Wright ist Mitinhaber von Conexion Networks, wo er sich in 

den Bereichen Netzwerkberatung, Implementierung von Computersystemen 

und technische Schulungen betätigt. Byron ist außerdem 

Sessional Instructor für die Asper School of Business an der Universität 

von Manitoba, an der er in den Bereichen Verwaltungsinformationssysteme 

und Netzwerktechnik lehrt. Byron hat eine Reihe von 

Büchern über Windows-Server, Windows Vista und Exchange Server 

verfasst. Derzeit wohnt er mit seiner Frau und seinen zwei Töchtern 

in Winnipeg, Manitoba, ist jedoch in Saskatoon, Saskatchewan, 

geboren und aufgewachsen. Byron ist unter der E-Mail-Adresse 

byron@conexion.ca erreichbar.

805 

Systemanforderungen 

Zur Verwendung der Begleit-CD zu diesem Buch benötigen Sie einen Computer, der die folgenden 

Mindestkonfiguration erfüllt: 

• Microsoft Windows Server 2008, Windows Vista, Windows Server 2003 oder Windows XP 

• 1 GHz 32-Bit- (x86) oder 64-Bit-Prozessor (x64), (in Abhängigkeit von den Mindestanforderungen 

für das Betriebssystem) 

• 1 GB Systemarbeitsspeicher (in Abhängigkeit von den Mindestanforderungen für das Betriebssystem) 

• Eine Festplattenpartition mit mindestens 1 GB freiem Speicherplatz 

• Geeignetes Videoausgabegerät 

• Tastatur 

• Maus oder anderes Zeigegerät 

• Optisches Laufwerk zum Lesen von CD-ROMs 

• Microsoft Office 2003 oder Microsoft Office 2007 

Zusätzlich enthält die Begleit-CD Skripts, die in VBScript (Dateierweiterung .vbs) und Windows 

PowerShell (Dateierweiterung .ps1) geschrieben wurden. Die Windows PowerShell-Skripts erfordern, 

dass Windows PowerShell auf Ihrem Computer installiert wurde und Sie Windows PowerShell 

zur Ausführung nicht signierter Skripts konfiguriert haben. Zur Ausführung dieser Skripts muss Ihr 

System die folgenden zusätzlichen Anforderungen erfüllen: 

• Installieren Sie auf Windows Server 2008 das Windows PowerShell-Feature. 

• Windows XP SP2, Windows Server 2003 SP1 oder Windows Vista: Zur Installation von Windows 

PowerShell auf diesen Betriebssystemen müssen Sie PowerShell von der Website 

http://www.microsoft.com/downloads/ herunterladen und installieren. 

• Zur Aktivierung nicht signierter Skripts in Windows PowerShell starten Sie Windows PowerShell 

und geben anschließend Set-ExecutionPolicy RemoteSigned ein. Wenn Sie ein Windows 

PowerShell-Skript ausführen, benötigen Sie den vollständigen Pfad zum Skript. 

• Zur Verwendung der VBScript-Skripts doppelklicken Sie auf die Datei oder führen das Skript 

direkt von einer Befehlszeile aus.

Active Directory.pdf - Gattner

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?