Read-only Domain Controller (RODC): Features und Voraussetzungen

    AD-Topologie mit RODCSchreib­geschützte DCs sind pri­mär für den Ein­satz in Zweig­stellen gedacht, die über ein WAN ange­bunden sind. Sie beschleu­nigen das Logon der lokalen Benutzer und kön­nen Rep­liken der DNS-Daten­bank sowie des Global Catalog vor­halten. RODC unter­liegen aber auch einigen Eins­chrän­kungen.

    Microsoft führte Read-only Domain Controller erstmals in Windows Server 2008 ein. Seitdem hat sich daran praktisch nichts verändert, auch in Server 2016 funktionieren RODC noch genauso wie zuvor. Einzig bei den Management-Tools sind seit Server 2012 PowerShell-Cmdlets hinzuge­kommen, mit denen sich RODC-Konten vorab im AD eintragen (Staging) und Domänen-Controller installieren lassen.

    Kaum kritische Daten auf einem RODC

    Der wesentliche Unterschied zu einem vollwertigen DC besteht darin, dass ein RODC nur die eingehende Replikation unterstützt und keine Daten an andere Domänen-Controller überträgt. Darüber hinaus dürfen Anwendungen die Datenbank eines RODC nicht verändern, dieser kann aber Schreib­anfragen an einen normalen DC weiterleiten.

    Der wesentliche Vorteil einer solchen DC-Installation besteht darin, dass sich damit Domänen-Controller auch in Büros betreiben lassen, wo der physische Zugang zu einem Server nicht abgesichert werden kann. Beim Diebstahl eines Rechners finden sich darauf je nach Konfiguration keine oder nur wenige Zugangsdaten.

    Caching von Passwörtern

    Standardmäßig speichert ein RODC keine Passwörter. Diese Einstellung hat jedoch den Nachteil, dass sich Benutzer in der Außenstelle nicht anmelden können, wenn die Netz­verbindung zum Rechen­zentrum unterbrochen ist. Der schreib­geschützte DC benötigt in dieser Konfiguration nämlich den Kontakt zu einem regulären DC, weil er so Benutzer nicht selbst authen­tifizieren kann.

    Um die Zweig­niederlassung autarker zu machen, kann ein Read-only Domain-Controller die Anmelde­daten ausgewählter Konten zwischen­speichern. Für diesen Zweck existiert die vorgegebene Gruppe mit den Namen Zulässige RODC-Kennwort­replikations­gruppe, für deren Mitglieder die Passwörter auf dem RODC verbleiben.

    Zwei vordefinierte Gruppen helfen bei der Auswahl von Benutzern, deren Passwort zwischengespeichert werden soll.

    Es lassen sich aber beliebige andere Gruppen oder User dafür verwenden. Eine weitere Gruppe namens Abgelehnte RODC-Kennwort­replikations­gruppe dient dem Anliegen, Accounts explizit davon auszuschließen.

    Auch Passwörter der Computer-Konten erforderlich

    Um auf Nummer sicher zu gehen, dass sich Benutzer bei Ausfall des WANs weiterhin einloggen können, lassen sich Passwörter bereits vorab replizieren ("Prepopulate cached Passwords"). Andernfalls liegt das Kennwort eines Benutzers auf dem RODC erst dann vor, wenn er sich zumindest einmal angemeldet hat. Diese Funktion lässt sich in Active Directory-Benutzer und -Computer (ADUC) in den Eigenschaften des RODC abrufen.

    Die Kennwörter ausgewählter User lassen sich schon vor dem ersten Logon auf dem RODC zwischenspeichern.

    Beim Caching der Passwörter ist zu beachten, dass es nicht reicht, bloß die Anmeldedaten der Benutzerkonten zu replizieren. Benötigt werden auch die Kennwörter der Computer im entfernten Office, damit sich User erfolgreich anmelden können, wenn keine Verbindung zu einem beschreibbaren DC besteht.

    Falls ein RODC, der Passwörter zwischen­speichert, entwendet wird, sollte der Administrator die Kennwörter der betroffenen Konten so schnell wie möglich zurücksetzen. Dafür muss er die betroffenen Accounts nicht extra ausfindig machen. Vielmehr bietet Active Directory-Benutzer und -Computer (ADUC) beim Löschen des RODC-Kontos die Möglichkeit zum Password-Reset gleich an.

    Delegierung und Wahl der Attribute

    Neben den Passwörtern verzichtet ein RODC standardmäßig auch auf die Replikation anderer sensibler Informationen. Dazu gehört eine Reihe von Attributen, die im Filtered Attribute Set (FAS) definiert sind. Dieses lässt sich bei Bedarf nachträglich anpassen.

    Ein weiteres Features, das einen RODC für den Einsatz in Außenstellen prädestiniert, ist die Delegierung der Administration an einen Mitarbeiter vor Ort. Das gilt sogar für die Heraufstufung zu einem Domänen-Contoller, wenn zuvor die Domänen-Dienste und ein Computer-Konto für den RODC eingerichtet wurden.

    Anpassen des AD-Schemas

    Bevor man einen RODC installieren kann, muss man möglicherweise das AD-Schema aktualisieren. Als Funktionsebene setzt er indes nur Server 2003 voraus, so dass diese Bedingung fast überall gegeben sein dürfte.

    Generell gilt bei der Installation eines DCs, dass man das Schema aktualisieren muss, wenn dieser auf einer neueren Version des Betriebssystems läuft als die vorhandenen Domänen-Controller.

    Erfolgt das Staging von einem Rechner, dessen Betriebssystem neuer ist als auf den DCs, dann erhält man diese Meldung.

    In diesem Fall muss man unter Umständen explizit

    adprep /forestprep

    ausführen (installiert man den RODC ohne Staging des Computer­kontos über den Wizard im Server Manager, dann entfällt dieser Schritt). Darüber hinaus kann es erforderlich sein, dass man

    adprep /rodcprep

    ausführen muss, wenn die regulären DCs von Windows Server 2003 auf 2008 (R2) aktualisiert wurden. Ob dies zutrifft, zeigt sich etwa beim Staging des RODC-Kontos im Active Directory-Verwaltungscenter. Dieses gibt eine entsprechende Fehlermeldung aus.

    Kompatibilität

    Schließlich empfiehlt sich noch, vor dem produktiven Einsatz eines RODC in einer Testumgebung zu prüfen, ob die benötigten Anwendungen mit ihm kompatibel sind. Sie sollten etwa damit zurecht­kommen, dass während eines Schreibvorgangs in das AD die Verbindung zu einem regulären DC abbricht.

    Microsoft selbst führt eine Liste mit eigenen Programmen und Diensten, die mit einem RDOC zurechtkommen. Diese wurde allerding seit geraumer Zeit nicht mehr aktualisiert.

    Keine Kommentare