Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

Schreibgeschützte Domänencontroller 253
Sie spezielle Anforderungen haben, weil zum Beispiel eine Anwendung auf einem DC installiert
sein muss. Oder wenn der einzige lokale Server im Standort der DC ist und Sie darauf
auch Anwendungen hosten müssen. Der Besitzer einer Anwendung muss sich oft interaktiv
an einem DC anmelden oder die Terminaldienste verwenden, um die Anwendung
zu konfigurieren und zu verwalten. Das verursacht ein inakzeptables Sicherheitsrisiko auf
einem beschreibbaren DC. Ein weiteres Beispiel ist ein Szenario, in dem die lokale Speicherung
aller Domänenbenutzerkennwörter eine Bedrohung verursacht, zum Beispiel in einem
Extranet oder wenn eine Anwendung zur Verfügung gestellt wird. Meiner Ansicht nach ist
das wichtigste Einsatzgebiet für den RODC die Bereitstellung in Remote- oder Zweigstellenumgebungen.
Schreibgeschützte AD DS-Datenbank
Der RODC speichert alle Active Directory-Objekte und -Attribute, die auch ein beschreibbarer
DC verwaltet, aber Sie können keine Änderungen an seiner Datenbank vornehmen. Sie
müssen Änderungen auf einem beschreibbaren DC durchführen und sie dann zurück auf den
RODC replizieren. Eine lokale Anwendung, die Lesezugriff auf das Verzeichnis anfordert,
erhält diesen Zugriff. Eine Anwendung, die Schreibzugriff anfordert, bekommt als Antwort
eine LDAP-Umleitung. Das bedeutet, dass die Anwendung von der Antwort auf einen beschreibbaren
DC verwiesen wird, wo sie den gewünschten Zugriff erhalten kann.
RODC-gefilterte Attributsätze
Keine Attribute, die im RODC-gefilterten Attributsatz definiert sind, dürfen auf irgendwelche
RODCs in der Gesamtstruktur repliziert werden. Falls Sie also Anwendungen haben, die
mit AD DS Authentifizierungsdaten wie zum Beispiel Kennwörter, Anmeldeinformationen
oder Verschlüsselungsschlüssel speichern, und Sie nicht wollen, dass diese Daten auf einem
RODC gespeichert werden (weil er kompromittiert werden könnte), können Sie diesen Satz
von Attributen dynamisch als Teil des gefilterten Attributsatzes im Schema für Domänenobjekte
definieren. Der Attributsatz wird dann niemals auf irgendwelche RODC repliziert.
Falls ein böswillige Benutzer einen RODC kompromittiert und versucht, ihn so zu konfigurieren,
dass er Attribute repliziert, die im RODC-gefilterten Attributsatz liegen, wird die
Replikationsanforderung verweigert, sobald der RODC das nächste Mal versucht, diese
Attribute von einem Windows Server 2008-DC zu replizieren. Aber falls der RODC versucht,
diese Attribute von einem Windows Server 2003-DC zu replizieren, wird die Replikationsanforderung
zugelassen. Falls Sie den RODC-gefilterten Attributsatz verwenden wollen,
sollten Sie sicherstellen, dass Ihre Gesamtstrukturfunktionsebene Windows Server 2008
lautet. Falls die Gesamtstrukturfunktionsebene Windows Server 2008 ist, sind keine Windows
Server 2003-DCs in der Gesamtstruktur erlaubt. Ein kompromittierter RODC lässt
sich also nicht auf diese Weise missbrauchen.
Um sicherzustellen, dass die AD DS-Funktionalität nicht von Hand fehlkonfiguriert wird,
dürfen Sie keine systemkritischen Attribute zum RODC-gefilterten Attributsatz hinzufügen.
Ein Attribut ist systemkritisch, falls es gebraucht wird, damit AD DS richtig funktioniert.
Beispiele sind LSA (Local Security Authority), Sicherheitskontenverwaltung (Security Accounts
Manager, SAM) und Microsoft-spezifische SSPIs (Security Service Provider Interface)
wie etwa Kerberos. Bei einem systemkritischen Attribut ist der Attributwert schema-
FlagsEx gleich 1 (schemaFlagsEx-Attributwert & 0x1 = TRUE).