Bei Windows 2000 und beim Windows Server 2003 waren die Einführung bzw. die Änderungen am Active Directory die wichtigsten Neuerungen. Beim Windows Server Longhorn bietet sich nun ein anderes Bild. Wenn man sich die Liste der neuen Funktionen betrachtet, die ohnehin nicht so lang ist wie bei früheren Releases, dann spielt das Active Directory doch eine erstaunlich geringe Rolle dabei. Das zeigt sich schon daran, dass es keine völlig neuen funktionalen Levels des Active Directory gibt und man sich auch keine Gedanken darüber machen muss, wie nun das Zusammenspiel mit älteren Versionen des Active Directory funktioniert.
Doch – wie gesagt – eine Neuerung erkennen wir bereits beim Blick in den Container Users von Active Directory-Benutzer und -Computer. Sie heißt RODCs (Read Only Domain Controllers) und stellt einen neuen Typ von Domänencontroller, dar, der für viele Einsatzbereiche des Active Directory von großer Bedeutung ist. Von diesen Domänencontrollern können Daten nur gelesen werden. Es können aber keine Daten auf die Systeme geschrieben werden.
Warum RODC?
Das Argument, das Microsoft für den Einssatz von RODCs nennt, ist die Sicherheit. Ein Domänencontroller muss in einer Umgebung mit einem ausreichend hohen Maß an Sicherheit betrieben werden. Das ergibt sich schon daraus, dass ein Angreifer, der physischen Zugang zu einem solchen Server hat, beispielsweise einen Domänencontroller mit einem anderen Betriebssystem booten und auf Daten im Active Directory zugreifen oder diese manipulieren könnte.
Natürlich gibt es grundsätzlich auch das Risiko eines Angriffs über das Netzwerk, wobei dieses Risiko unabhängig vom Standort des Domänencontrollers besteht.
Damit stellt sich aber die Frage, welchen Nutzen ein RODC wirklich bringen soll. Beim lesenden Zugriff ist die Gefährdung dieselbe wie bei jedem anderen Domänencontroller. Der einzige Unterschied ist, dass bei einem Angriff mit physischem Zugang zum Server keine direkten Änderungen vorgenommen werden können. Das ist aber ohnehin die unwahrscheinlichste Angriffsvariante, selbst wenn sich ein Domänencontroller an einem weniger sicheren Standort befindet. Abgesehen davon wird es Angreifern auch in diesem Fall eher darum gehen, Daten zu lesen, wozu auch gehashte Kennwortinformationen für eine Dictionary-based Attack gehören können. Das Schreiben von Änderungen durch physischen Zugang zum System gehört nicht unbedingt zu den typischen Szenarien.
Zwei Gruppen von Benutzern
Das von Microsoft genannte Sicherheitsargument greift also so nicht ganz. Ein Blick auf die im Container Users definierten Sicherheitsgruppen macht dann aber klar, warum das Modell doch Sinn macht.
Es gibt zwei Gruppen von Benutzern, über die gesteuert wird, von wem Kennwörter auf RODCs repliziert werden. Richtig konfiguriert, gibt es auf einem RODC also nur einen Teil der Kennwortinformationen. Ein Angreifer kann damit auch nur die Hashs von Kennwörtern eines Teils der Benutzer auslesen.
Die Umsetzung
Ein RODC ist relativ einfach aufzusetzen. Die Einrichtung eines solchen Domänencontrollers kann in einer bestehenden Domäne erfolgen, wobei es zuvor mindestens zwei „richtige“ Domänencontroller geben könnte. Der RODC kann im Assistent für die Erstellung von Domänencontrollern (dcpromo.exe) als Option ausgewählt werden.
Der Zugriff auf diesen Typ Domänencontroller wird über spezielle Gruppen gesteuert, die im Container Users angelegt werden. Zwei davon steuern die Kennwortsynchronisation, die andere wird für die interne Kommunikation mit diesen Domänencontrollern benötigt.
Braucht man RODCs?
Ob man – trotz der eingeschränkten Kennwortsynchronisation – RODCs braucht, ist eine Frage, die nicht so einfach zu beantworten ist. Der Vorteil in Bezug auf die Sicherheit ist nicht sehr hoch, weil eben immer noch sicherheitskritische Informationen auf diesen Systemen liegen. Neben dem Active Directory gibt es ja meist auch andere sensible Daten, die auf den Servern gespeichert werden. Zudem werden eben auch Kennwörter dort gehalten. Das sind zwar nicht alle, und sie sind auch nicht veränderbar – aber es sind Kennwörter. Und wenn es einem Angreifer gelingt, an eines der Kennwörter zu gelangen, kann er regulär im Kontext des entsprechenden Benutzers zugreifen.
Insofern sollte man auch RODCs unter dem Aspekt der Sicherheit sehr kritisch betrachten. Die Verwendung beispielsweise von Terminal Services an einem Standort, der nicht ausreichend Sicherheit für den Betrieb eines Domänencontrollers bietet, ist eine Option, die ihren Charme hat. Zudem wird dadurch, dass höhere Bandbreiten zu immer günstigeren Preisen verfügbar werden, auch die Anbindung externer Standorte direkt an die zentralen Netzwerke mit ihren gesicherten Servern in Rechenzentren immer attraktiver.
Man kann sich also die Frage stellen, ob es nicht viel besser gewesen wäre, einen solchen RODC gleich mit gefilterten Repliken zu realisieren, sodass man auch nur einen Teil der Informationen dort bereitstellt. Das wäre auch als Ergänzung zu ADAM sinnvoll, das eine solche Aufgabe in Teilen übernehmen kann. So bleibt das Gefühl, dass die RODC zwar die einzige nennenswerte Neuerung beim Active Directory ist, aber nicht wirklich große Bedeutung hat.