Read-Only Domänencontroller reduzieren Risiken

Liegen weniger kritische Informationen in der Datenbank für das Active Directory, reduziert sich bei einem Verlust des Domänencontrollers der Umgang der potenziell kompromittierten Informationen. Deswegen gibt es ab Windows Server 2008 die Möglichkeit, einen RODC – Read-Only Domain Controller – zu konfigurieren, der sich speziell für den Einsatz in Zweigstellen anbietet. Zudem lassen sich bei diesem Konzept Verwaltungsaufgaben am RODC an lokale Administratoren delegieren. Damit bekommen die Domänen-Administratoren mehr Freiräume.

In den frühen Tagen der Windows-Vernetzung auf der Basis von Windows NT gab es noch keine Multimaster-Replikation der Datenbank, die das Active Directory (AD) beherbergte. Die aktuelle Version dieser Datenbank lag auf dem Primary Domain Controller (PDC), doch der erwies sich als ein Single-Point-of-Failure und bei hoher Belastung auch als Flaschenhals. Deswegen erwies sich der Einsatz von Backup Domain Controllern (BDC) als eine Möglichkeit, eine Kopie der AD-Datenbank vorzuhalten. Dabei handelte es sich aber nur um eine Read-Only-Version.

Fiel der PDC aus, konnte man den BDC verwenden, allerdings musste dann eine Heraufstufung erfolgen. Zudem gab es die Möglichkeit, mit dem BDC eine Lastverteilung vorzunehmen. Insgesamt gesehen, war die Funktionalität des BDC-Ansatz doch sehr eingeschränkt. Das Konkurrenzprodukt zur damaligen Zeit, Netware, galt als technologisch weiter.

Mit der Vorstellung von Windows Server 2000 und der Nachfolge-Generation Windows Server 2003 aber hat Microsoft das Multimaster-Replikationsmodell für seine DC eingeführt beziehungsweise optimiert. Damit war aber auch das Ende der BDC vorgezeichnet, denn nun waren alle Domänencontroller (DC) prinzipiell gesehen gleichberechtigt. Eine relative aktuelle Kopie der AD-Datenbank lag auf allen DCs in einem Netzwerkverbund vor. Relativ deswegen, weil die Verbindung der DC untereinander hier eine Rolle spielt. Wenn Standorte über langsame Netzwerkverbindungen – wie sie oftmals bei Weitverkehrstrecken gegeben sind – kommunizieren, kann es zu Verzögerungen in der Replikation kommen.

Diese Art der Replikation erwies sich vor allem bei großen und verteilten Unternehmen als eine Problemquelle, da jeder DC ankommende Authentifizierungsanfragen selbst erledigen soll und die entsprechenden Änderungen auch in seiner lokalen Instanz der AD-Datenbank eintragen darf. Erst dann wird diese Modifikation an seine Kollegen im Verbund repliziert.

Aber auch aus dem Blickwinkel der Sicherheit gibt es Einwände: Angenommen ein Unternehmen betreibt am Stammsitz zwei DCs, beide gut im Rechnerraum geschützt, und hält in einer Außenstelle einen weiteren DC vor, der allerdings nur in einer Abstellkammer steht. Wird nun ein derart leicht zugängiger DC entwendet oder auch nur eine Kopie der AD-Datenbank gezogen, dann sind alle Informationen zum unternehmensweiten AD kompromittiert. In vielen Situationen ist das Problem sogar noch größer, da viele Unternehmen auch andere Informationen über die Mitarbeiter im AD ablegen. Damit besteht für das gesamte Unternehmen eine massive Sicherheitsproblematik.

Neuauflage des BDC-Konzepts

Mit der Vorstellung von Windows Server 2008 kam es daher zu einer Art Neuauflage des BDC-Konzepts: der Windows Server 2008 RODC (Read Only Domain Controller). Auch sie enthalten eine Read-Only-Kopie der AD-Datenbank, doch hier gibt es einen wesentlichen Unterschied: der Domänenadministrator kann vorgeben, welche Konten aus der AD-Datenbank an den RODC repliziert werden.

Damit ergibt sich für das zuvor skizzierte Szenario eine elegante Lösung: Bei der Konfiguration des RODC  für die Zweigstelle durch einen Domänen-Administrator werden nur die vor Ort eingesetzten Benutzerkonten auf dem RODC vorgehalten. Geht dieser RODC dann irgendwann einmal verloren, ergibt sich ein geringeres Risiko: Nur die in der Zweigstelle aktiven AD-Informationen können kompromittiert werden.

Ein weiteres Problem mit den üblichen DCs liegt im Verwaltungsaufwand. Dazu sind in der Regel Domänen-Administratoren zuständig. Anders als bei anderen Windows-basierten Servern muss ein Administrator auf einem traditionellen DC immer ein Domänen-Administrator sein.  Diese Vorgabe soll sicherstellen, dass die AD-Datenbank vor fehlerhafter Bedienung durch nicht entsprechend ausgebildete IT-Mitarbeiter beschädigt wird.

Dieser an sich gute Ansatz erleidet in der täglichen Praxis aber oftmals Rückschläge: Die Domänen-Administratoren haben kaum Zeit, sich um „niedriger Arbeiten“, wie zum Beispiel das Zurücksetzen von vergessenen Benutzer-Kennwörtern oder das Einspielen von bereits freigegebenen Patches  zu kümmern. Derartige Aufgaben könnten auch weniger gut ausgebildete IT-Mitarbeiter oder gar normale Benutzer übernehmen.

Vor allem bei verteilten Unternehmen mit DCs in den jeweiligen Zweigstellen empfiehlt sich eine entsprechende Aufgabenteilung mit dem Personal vor Ort. Doch bei dem üblichen DC-Ansatz hat das zur Folge, dass man eine womöglich weniger gut ausgebildete Person dann doch zu einem Domänen-Administrator herauf stufen muss.

Das sieht beim RODC-Konzept ganz anders aus. Hier haben die Entwickler bei Microsoft vorgesehen, dass eine neue Gruppe hinzukommt, die für derartigen Aufgaben herangezogen wird: Auf jeden eingesetzten RODC besteht die Möglichkeit, lokale Administratorrechte an einen Benutzer oder eine Gruppe zuzuweisen, ohne dass dieser lokale Benutzer (oder diese lokale Gruppe) die Privilegien eines Domänen-Administrators haben muss. Im Rahmen des DCPROMO-Prozesses, bei dem ein System zu einem RODC gemacht wird, besteht die Option, in einem entsprechenden Dialog diese Gruppe oder diesen Benutzer anzugeben.

Eine besondere Komplexität ergibt sich bei den RODCs aber, wenn bestimmte Anwendungen – wie zum Beispiel der Exchange-Server – Informationen im laufenden Betrieb in das AD schreiben: Sie benötigen unbedingt eine komplett zugängige Instanz eines DC: Hier hilft ein RODC nicht weiter. Diese Problematik sollte man auch im Hinterkopf haben, wenn das Domain Name System (DNS) so konfiguriert ist, dass es die DNS-Zonen im AD ablegt (wie das beim Dynamic DNS der Fall ist).

Rainer Huttenloher