Windows Server 2008 R2-Domänencontroller: Sorgfältige Planung von RODCs
Paul Yu
Wenn es an physischer Sicherheit mangelt, wird es umso wichtiger, sich auf die Datensicherheit zu konzentrieren. Windows Server 2008 und R2 bieten einige neue Möglichkeiten, die speziell auf Umgebungen wie externe Zweigstellen zugeschnitten zu sein scheinen, in denen die physische Sicherheit nicht so gewährleistet ist. Read-Only-Domänencontroller (RODC, schreibgeschützte Domänencontroller) sind ein neues Feature der Active Directory-Domänendienste (AD DS) in Windows Server-Systemen. Mit ihnen ändert sich die Art und Weise grundlegend, wie Domänencontroller (DC) in der Regel verwendet werden.
Da viele neue Fähigkeiten der RODCs wichtige Aspekte des Entwurfs- und Bereitstellungsprozesses beeinflussen, müssen Sie wissen, wie Sie sie im Unternehmen nutzen können. Es gibt auch wesentliche Entwurfs- und Planungsüberlegungen, die zu berücksichtigen sind, bevor RODCs in eine Umgebung eingeführt werden. RODCs sind DCs, die komplette schreibgeschützte Kopien der Active Directory-Datenbankpartitionen, eine schreibgeschützte SYSVOL-Kopie und einen Attributsatz mit RODC-Filter enthalten, durch den die eingehende Replikation bestimmter Anwendungsdaten von beschreibbaren DCs beschränkt wird.
Standardmäßig werden auf RODCs keine Anmeldeinformationen ausgewählter Benutzer- und Computerkonten gespeichert, Sie können dies jedoch konfigurieren. Dies allein schon rechtfertigt den Einsatz von RODCs in externen Zweigstellen oder Perimeternetzwerken, die nicht die physische Sicherheit aufweisen, die üblicherweise in Intranets von Rechenzentren gegeben ist. RODCs bieten auch weniger bekannte Sicherheitsfeatures, beispielsweise ein spezielles Kerberos-Ticket-Granting-Konto, mit dem auf Tickets basierende Angriffe unterbunden werden, durch die der RODC selbst gefährdet werden könnte.
Obwohl die Bereitstellung von RODCs meist aus Sicherheitsgründen erfolgt, bieten Sie auch einige andere Vorteile, wie Verwaltbarkeit und Skalierbarkeit in Unternehmen. Im Allgemeinen sind RODCs für Umgebungen vorgesehen, die eine lokale Authentifizierung und Autorisierung erfordern, aber nicht über die entsprechende physische Sicherheit verfügen, die für einen sicheren Einsatz beschreibbarer DCs erforderlich ist. Daher finden sich RODCs am häufigsten in Perimeternetzwerken von Rechenzentren oder in Zweigstellen.
Ein Beispiel für eine vorteilhafte Verwendung von RODCs ist ein Rechenzentrum, das AD DS erfordert, wegen Sicherheitseinschränkungen die AD DS-Gesamtstruktur des Unternehmens aber nicht im Perimeternetzwerk nutzen kann. In diesem Fall entsprechen RODCs möglicherweise allen einschlägigen Sicherheitsanforderungen, sodass sich der Infrastrukturbereich der AD DS-Implementierung im Unternehmen dadurch ändert. Diese Art von Szenario wird wahrscheinlich häufiger werden. Es spiegelt auch die aktuellen bewährten AD DS-Modelle für Perimeternetzwerke wider, beispielsweise das erweiterte Unternehmensgesamtstrukturmodell.
Zweigstellen mit RODCs
Die gängigsten Umgebungen für RODCs mit AD DS sind noch immer Zweigstellen. Diese Art von Umgebung stellt in der Regel Endpunkte in einer Hub-and-Spoke-Netzwerktopologie dar. Zweigstellen sind geografisch weit verteilt, in großer Anzahl vorhanden und jeweils mit einer kleinen Benutzerpopulation ausgestattet, die über langsame, unzuverlässige Netzwerkverbindungen mit dem Hubstandort verbunden sind. Zudem sind oft keine erfahrenen Administratoren vor Ort.
Bei Zweigstellen, die bereits beschreibbare DCs beherbergen, ist die Bereitstellung von RODCs wahrscheinlich nicht notwendig. In diesem Szenario entsprechen die RODCs nicht nur den vorhandenen Anforderungen bezüglich AD DS, sondern sie gehen durch höhere Sicherheit, verbesserte Verwaltung, vereinfachte Architektur und niedrigere Gesamtbetriebskosten sogar noch darüber hinaus. Bei Standorten, bei denen die Anforderungen an Sicherheit und Verwaltbarkeit den Einsatz von DCs verbieten, können mithilfe von RODCs Domänencontroller in die Umgebung eingeführt und eine Reihe nützlicher, lokaler Dienste bereitgestellt werden.
Obwohl sich diese neuen Features und Vorteile auf die Bewertung von RODCs sehr günstig auswirken, müssen andere Faktoren berücksichtigt werden, wie Fragen der Anwendungskompatibilität und Dienstauswirkungen. Diese Faktoren können dazu führen, dass die Bereitstellung von RODCs für bestimmte Umgebungen nicht akzeptabel ist.
Weil viele verzeichnisfähige Anwendungen und Dienste beispielsweise Daten aus AD DS lesen, sollten sie auch mit einem RODC funktionieren und arbeiten können. Wenn bestimmte Anwendungen jedoch zu jeder Zeit Schreibzugriff erfordern, dann ist ein RODC möglicherweise nicht akzeptabel. RODCs erfordern für Schreibvorgänge zudem Netzwerkverbindungen mit einem beschreibbaren DC. Obwohl fehlgeschlagene Schreibvorgänge die Ursache der meisten bekannten anwendungsbezogenen Probleme sein dürften, müssen andere Dinge berücksichtigt werden, wie ineffiziente oder fehlgeschlagene Lesevorgänge, fehlgeschlagene Schreib- und Einlesevorgänge und allgemeine Anwendungsfehler auf dem RODC.
Abgesehen von Anwendungsproblemen kann sich eine Unterbrechung der Verbindung mit einem beschreibbaren DC auf grundlegende Benutzer- und Computervorgänge auswirken. Beispielsweise können grundlegende Authentifizierungsdienste möglicherweise nicht ausgeführt werden, wenn die Kennwörter für Benutzerkonten nicht zwischenspeicherbar sind und nicht lokal auf dem RODC zwischengespeichert werden. Diese Probleme lassen sich einfach entschärfen, indem die Konten über die Kennwortreplikationsrichtlinie (Password Replication Policy, PRP) des RODC als zwischenspeicherbar markiert und die Kennwörter dann vorab ausgefüllt und zwischengespeichert werden. Zur Durchführung dieser Schritte ist auch eine Verbindung mit einem beschreibbaren DC erforderlich.
Wenn keine Verbindung mit einem beschreibbaren DC verfügbar ist, wirkt sich dies deutlich auf die Erneuerung von Kennwörtern und Kontosperrungen aus, von anderen Authentifizierungsproblemen abgesehen. Aufforderungen zum Ändern des Kennworts und jeder Versuch, die Sperre eines Kontos manuell aufzuheben, schlagen solange fehl, bis die Verbindung mit einem beschreibbaren DC wiederhergestellt wurde. Sie müssen diese Abhängigkeiten und die daraus resultierenden Änderungen des Betriebsverhaltens kennen, um die Erfüllung von Anforderungen und Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) gewährleisten zu können.
Es gibt einige allgemeine Szenarien, in denen RODCs bereitgestellt werden können. RODCs sind an Standorten ohne vorhandene DCs hilfreich oder an Standorten mit DCs, die entweder ersetzt oder auf eine neuere Version von Windows aktualisiert werden. Obwohl zu jedem Szenario umfassende Planungsüberlegungen gehören, konzentrieren wir uns hier auf allgemeine Ansätze. Diese sind jedoch RODCs eigen und nicht auf traditionelle beschreibbare DCs anwendbar.
Vorausplanung
Bevor Sie mit einer formalen RODC-Planung beginnen, sollten Sie eine angemessene Überprüfung und eine grundlegende AD DS-Vorausplanung durchführen. Hierzu gehören wichtige Aufgaben wie die Überprüfung der vorhandenen logischen AD DS-Struktur und die Sicherstellung, dass das Verwaltungsmodell und die physische AD DS die vorhandenen geschäftlichen und technischen Anforderungen erfüllen können. Überdies müssen Hardwareanforderungen, Softwareupgradestrategien und alle bekannten einschlägigen Betriebssystemprobleme berücksichtigt und die Voraussetzungen von RODC-AD DS beurteilt werden. Diese Informationen sind für die Planung und Bereitstellung maßgeblich. In einer detaillierten Bereitstellungsprüfliste sind sie gut dokumentiert.
Installation und Verwaltung
RODCs verfügen über ein bedeutendes Verwaltungsfeature namens Aufteilung der Administratorrolle. Damit wird die Fähigkeit, RODC-Server zu installieren und zu verwalten, an Administratoren, die keine Dienstadministratoren sind, delegiert, ohne diesen Active Directory-Rechte zu gewähren. Das ist eine wesentliche Änderung gegenüber den traditionellen Überlegungen in Bezug auf den DC-Serverentwurf, die Delegation von Verwaltungsaufgaben und Bereitstellungsverfahren. Diese Aufteilung der Rollen gewinnt bei kritischen Anwendungen, die direkt auf einem DC installiert werden müssen, oder bei Standardorten mit einzelnen Mehrzweckservern zunehmend an Bedeutung.
Weitere Serverrollen
Allgemein gilt die Regel, dass Sie alle Rollen vom Server entfernen sollten, die für die Arbeit des RODC nicht unbedingt erforderlich sind. Daher sollten Sie RODCs nur die DNS-Serverrolle und die globale Katalogserverrolle hinzufügen. Sie sollten die DNS-Serverrolle auf jedem RODC installieren, so dass lokale DNS-Clients die DNS-Auflösung durchführen können, wenn keine Netzwerkverbindungen mit einem beschreibbaren DC verfügbar sind. Wenn die DNS-Serverrole nicht über Dcpromo.exe installiert wird, müssen Sie sie allerdings im Nachhinein installieren. Der RODC muss mit Dnscmd.exe in die DNS-Anwendungsverzeichnispartitionen, die integrierte Active Directory-Zonen enthalten, eingetragen werden. Die RODCs sollte auch als globale Katalogserver konfiguriert werden, damit sie Authentifizierungsanforderungen und globale Katalogabfragen ausführen können. Was die Authentifizierung betrifft, kann die universelle Gruppe zwischengespeichert werden, falls die globale Katalogrolle nicht in Frage kommt. Eine erfolgreiche Authentifizierung bei einem RODC kann schließlich von der PRP-Konfiguration des RODCs abhängig sein.
RODC-Platzierung
Die DC-Platzierung hat sich seit der Einführung der RODC PRP beträchtlich verändert. RODCs müssen die Domänenpartition von einem beschreibbaren DC mit Windows Server 2008 oder Windows Server 2008 R2 in der gleichen Domäne replizieren können, weil nur diese DCs die PRPs für die RODCs erzwingen können. Um eine ordnungsgemäße Replikation sicherzustellen, sollte der beschreibbare DC an dem AD DS-Standort platziert werden, der über die kostengünstigste Verbindung mit dem Standort verfügt, an dem sich der RODC befindet.
Wenn Sie diese Konfiguration nicht einrichten können, dann muss sich die RODC-Replikation auf die Option "Brücke zwischen allen Standortverknüpfungen herstellen" (d. h. Standardortverknüpfungstransitivität) oder auf Standortverbindungsbrücken zwischen den Standortverbindungen zwischen dem RODC-Standort und dem Standort des beschreibbaren DC stützen. Wenn die Standardorttransitivität oder Standortverbindungsbrücken nicht zur Disposition stehen, dann können Sie neue Standortverbindungen erstellen, um RODC-Standort direkt mit dem Standort des beschreibbaren DC zu verbinden.
Als allgemeine bewährte Methode gilt, dass Sie keine weiteren DCs an dem AD DS-Standort einrichten sollten, an dem sich der RODC befindet, weil Clientvorgänge dann möglicherweise nicht konsistent ausgeführt werden und das Clientverhalten infolgedessen unberechenbar werden kann. Grundlegende Vorgänge, wie die Authentifizierung, LDAP-Lese- und –Schreibvorgänge und Kennwortänderungen, können abhängig von verschiedenartigen RODC-Konfigurationen, der Windows-Version eines beschreibbaren DC oder der Verfügbarkeit von Netzwerkverbindungen mit den anderen beschreibbaren DCs ein unterschiedliches Verhalten zeigen. RODCs speichern keine Vertrauensstellungskennwörter und erfordern eine domänenübergreifende Authentifizierung, um Authentifizierungsanforderungen an die verschiedenen beschreibbaren DCs in jeder Domäne weiterleiten zu können. Wenn sich an getrennten Standorten beschreibbare DCs befinden, dann wären alle domänenübergreifenden Authentifizierungsanforderungen von Netzwerkverbindungen abhängig und könnten nicht beantwortet werden, wenn Fehler in den Netzwerkverbindungen auftreten.
Skalierbarkeit und Replikation
RODCs bieten auch Vorteile in Bezug auf die Skalierbarkeit, die in größeren oder komplexeren AD-DS-Implementierungen hilfreich sein können. Beispielsweise ermöglichen RODCs die unidirektionale Replikation. Daher wird durch die Bereitstellung von RODCs an Zweigstellen die Arbeitslast der Bridgeheadserver an Hubstandorten verringert, die normalerweise die eingehende Replikation für Zweigstellen-DCs verarbeiten. Von den Gesamtkosten her gesehen, wird dadurch die Anzahl der zu erstellenden und zu verwaltenden Verbindungsobjekte verringert. Auch die erforderliche Anzahl von Hubstandort-DCs lässt sich dadurch reduzieren.
RODCs bieten auch Verbesserungen hinsichtlich des Lastenausgleichs, die zu einer gleichmäßigen automatischen Verteilung ausgehender Verbindungsobjekte unter den Bridgeheadservern am Hubstandort beitragen. Bei früheren Versionen von Windows war hierzu ein manuelles Eingreifen erforderlich. Wenn die Konsistenzprüfung jetzt auf einem RODC erkennt, dass ein Bridgeheadserver an einem Hubstandort hinzugefügt oder entfernt wird, dann wird ermittelt, ob die Replikationspartner an einen neuen Bridgehead weitergeleitet werden sollen. Hierzu werden ein Algorithmus und ein probabilistischer Lastenausgleich ausgeführt. Wenn RODCs an Zweigstellenstandorten hinzugefügt werden, führt die Konsistenzprüfung auch unter den vorhandenen Bridgeheadservern am Hubstandort einen Lastenausgleich für eingehende Verbindungen durch.
Zwischenspeicherung von Anmeldeinformationen
Die PRP eines RODC legt fest, ob Konten auf dem betreffenden RODC zwischenspeicherbar sind. Standardmäßig wird über die Liste "Zulassen" in der PRP angegeben, dass keine Kontokennwörter zwischengespeichert werden können. Außerdem wird mit dieser Liste auch die Zwischenspeicherung bestimmter Konten explizit unterbunden. Dies hat Vorrang gegenüber manuell konfigurierten "Zulassen"-Konfigurationen. Wie bereits oben erwähnt, müssen Sie die PRP unter Umständen auf jedem RODC so konfigurieren, dass die Kennwörter für Konten zwischengespeichert werden können.
Lassen Sie bei diesem Schritt Vorsicht walten, da sich PRP-Änderungen sowohl auf die Sicherheit als auch die Dienstverfügbarkeit auswirken können. Beispielsweise resultiert das Standardszenario, in dem keine Konten zwischenspeicherbar sind, in hoher Sicherheit, aber keinem Offlinezugriff, falls die Netzwerkverbindung mit einem beschreibbaren DC getrennt wird. Wenn umgekehrt ein großer Prozentanteil der Konten (z. B. die Gruppe der Domänenbenutzer) zwischenspeicherbar ist, dann ist die Sicherheit viel weniger gewährleistet, wenn der RODC gefährdet ist, die Dienstverfügbarkeit ist bei den zwischenspeicherbaren Konten aber viel höher. Wegen der speziellen geschäftlichen und technischen Anforderungen verschiedener Infrastrukturumgebungen, unterscheidet sich der PRP-Entwurf von Organisation zu Organisation.
Sobald Sie ein PRP-Modell eingeführt haben, müssen Sie die PRP auf jedem RODC konfigurieren, damit die entsprechenden Konten zwischengespeichert werden. Es gilt als gewährte Methode, die PRPs mit expliziten Einträgen in der Zulassen-Liste zu konfigurieren und die Verweigern-Liste nicht zu ändern. Die Verweigern-Liste ist wichtig, weil sie verhindert, dass die Anmeldeinformationen wichtiger Konten (z. B. die Konten der AD DS-Administratoren) auf RODCs zwischengespeichert werden.
Ein weiterer wichtiger Aspekt des PRP-Entwurfs besteht in der Festlegung, ob die Kennwörter für zwischenspeicherbare Konten vorab ausgefüllt werden. Standardmäßig werden die Anmeldeinformationen zwischenspeicherbarer Konten erst nach der ersten Anmeldung bei einem RODC zwischengespeichert, wenn die Authentifizierungsanforderung an einen beschreibbaren DC mit Windows Server 2008 oder Windows Server 2008 R2 weitergeleitet wird und die Anmeldeinformationen auf dem RODC repliziert werden. Wenn die Netzwerkverbindung mit einem beschreibbaren DC getrennt wird, bevor die zwischenspeicherbaren Konten für einen RODC authentifiziert werden, kann deshalb selbst dann keine erfolgreiche Anmeldung ausgeführt werden, wenn die Konten als zwischenspeicherbar konfiguriert wurden.
Um auf dieses Problem einzugehen, können Sie den Kennwortcache vorab ausfüllen, sobald die PRP konfiguriert und die Konten als zwischenspeicherbar markiert wurden. Dieser Vorgang erfordert ebenfalls eine Netzwerkverbindung zwischen einem beschreibbaren DC mit Windows Server 2008 oder Windows Server 2008 R2 und dem RODC. Sie können dies frühzeitig während der Bereitstellung erledigen, lange bevor sich zwischenspeicherbare Benutzer zum ersten Mal anmelden.
Sie können diese grundlegende architektonische Anleitung als Grundlage ihrer RODC-Planung nutzen. Durch die Behandlung wichtiger Entwurfüberlegungen stellt dieser Artikel einen effektiven Ausgangspunkt für den Entwurf einer detaillierten und umfassenden RODC-Lösung dar. Dies ist kein einfacher Prozess, sondern es ist einige Zeit erforderlich, um neue Features und Entwurfsaspekte mit der speziellen Umgebung und den Anforderungen Ihrer Organisation in Einklang zu bringen.
Paul Yu* (Paul.Yu@microsoft.com) ist seit 10 Jahren als Senior Consultant für Microsoft Consulting Services tätig und stellt Wirtschaftsunternehmen und Unternehmen der öffentlichen Hand Unternehmensinfrastrukturlösungen von Microsoft bereit.*