0

Mit dem Read-Only Domänencontroller hat Microsoft ein weiteres Highlight in Windows Server 2008 eingeführt,
nämlich eine neue Art von Domänencontroller (DC). Einige werden sicherlich denken, dass Microsoft ganz nach dem Motto
„Back to the Roots“ sich nicht von dem zu NT-Zeiten existierenden, des BDCs (Backup Domain Controller) lösen konnte.
Das ist ein Irrtum, denn ein RODC stellt weitaus mehr zur Verfügung und ist keineswegs mit dem NT-BDC zu vergleichen.


Der primäre Gedanke bei Microsoft war an dieser Stelle, dass Domänencontroller in Außenstellen besser „geschützt“ werden müssen.
Die Gegebenheiten einer Außenstelle sind meistens gleich: Es existiert nur eine geringe bis keine physikalische Sicherheit, weiterhin existiert ein
geringes EDV-Wissen vor Ort, i.d.R. eine begrenzte Anzahl von Benutzern sowie eine geringe WAN-Anbindung. Oftmals ist es so, dass der
Domänencontroller der in einer Außenstelle steht, physikalisch nicht die gleiche sichere Umgebung genießt, wie ein Domänencontroller der in der Zentrale steht.
In den Außenstellen steht der DC meistens unter einem Tisch mitten im Raum (samt Backup), an den physikalisch jeder heran kann
(z.B. die Putzfrau) und somit diesen DC Schaden bzw. kompromittieren könnte. Was auch noch denkbar wäre, dass der DC Freitag Abends wenn
keiner im Büro ist von jemandem gestohlen wird, die Benutzer- und vor allem administrativen Konten verändert und den DC danach Sonntag Abends
erneut an seinen Platz stellt. Somit würden unbemerkt die kompromittierten Konten repliziert werden und geben dadurch dem Angreifer ganz
andere Möglichkeiten.


Daher war die Idee, wenn zumindest der Domänencontroller nicht physikalisch gesichert werden kann, dass zumindest die Domäne und somit die
Active Directory-Domänendienste (AD-DS) mehr Sicherheit bekommen. Früher (bis Windows Server 2003) würde man im Idealfall dazu übergehen,
vor Ort keinen Domänencontroller aufzustellen (ja, die Realität sieht anders aus). Der Nachteil wäre, dass erstens, die Benutzerauthentifizierung über
das WAN erfolgen müsste und zweitens, wenn die WAN-Verbindung gestört wäre, dass sich die Benutzer nicht mehr in der Domäne anmelden können
und der Benutzer sich mit seinen zwischengespeicherten Benutzerinformationen (cached credentials) nur lokal anmelden kann
(es würde keine Verbindung zu Domänen-Ressourcen bestehen).

Genau für diese Szenarien wurde der Read-Only Domänencontroller entwickelt. Denn mit einem RODC haben nun Unternehmen die Möglichkeit,
auch in Außenstellen die keine physikalische Sicherheit gewährleisten können, einen Domänencontroller aufzustellen.


 


Die Besonderheiten eines RODC




  • Der RODC besitzt ein vollständiges Replikat der Active Directory-Datenbank (samt allen Objekten und Attributen),
    die sich auf einem normalen Domänencontroller befinden. Der einzige Unterschied, die Active Directory-Datenbank (NTDS.DIT) die sich auf
    einem RODC befindet, erlaubt keine Änderungen und es besteht nur ein lesender Zugriff darauf. Änderungen müssen auf einem „beschreibbaren“
    Domänencontroller vollzogen und auf den RODC repliziert werden.


  • Es ist möglich das DNS auf einem RODC zu installieren, dieser hat aber ebenfalls nur einen lesenden Zugriff auf das DNS
    (Read-Only Domain Name System). Der RODC kann alle Anwendungsverzeichnispartitionen die vom DNS genutzt werden,
    wie es die DomainDNSZones sowie ForestDNSZones Partitionen darstellen, enthalten. Wenn das DNS auf einem RODC installiert ist,
    können Clients diesen für eine Namensauflösung anfragen und die Benutzer an den Standorten können sich ganz normal anmelden.
    Dieser kann aber nicht die Namens-Aktualisierungen der Clients oder Name-Server (NS)-Einträge im DNS vornehmen.


  • Standardmäßig speichert ein RODC weder Computer- noch Benutzerinformationen, außer sein eigenes Computerkonto sowie ein
    spezielles krbtgt Konto für den RODC. Der RODC trägt sich als Key Distribution Center (KDC) im Active Directory für den Standort ein.
    Das krbtgt Konto das der RODC für zum Erstellen von verschlüsselten Ticket-Granting Tickets (TGT) verwendet, ist ein anderes,
    als das auf einem beschreibbaren Windows Server 2008-Domänencontroller.

    Auf einem RODC kann je nachdem explizit angegeben werden, welche Benutzer-, Computer- bzw. Dienstkonten für die
    Zwischenspeicherung zugelassen oder verweigert werden sollen (credential caching). Diverse administrative Konten
    (wie z.B. der Domänen-Administrator) werden standardmäßig nicht auf einem RODC zwischengespeichert. Es existieren zwei Domänenlokale
    Sicherheitsgruppen: Abgelehnte RODC-Kennwortreplikationsgruppe und Zulässige RODC-Kennwortreplikationsgruppe die sich für die
    Verwaltung der zu zwischenspeichernden Konten anbieten. Es lassen sich auch selbst definierte Gruppen verwenden.
    Wenn ein Benutzerkonto in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist, so hat die abgelehnte Gruppe Vorrang!
    Sind die Konten einmal zwischengespeichert, können sich die Benutzer ohne eine bestehende WAN-Anbindung an dem RODC authentifizieren.

    Wird nun ein RODC gestohlen, befinden sich „lediglich“ die zwischengespeicherten Konten auf der Maschine.
    Wenn danach im Domain Controllers Container (im ADBuC) das Computerobjekt des RODCs entfernt werden würde,
    bekommt man die Gelegenheit die Benutzer- sowie Computerkonten die auf dem RODC gespeichert waren, zurückzusetzen.
    Weiterhin besteht die Möglichkeit, eine Liste der zwischengespeicherten Konten zu exportieren.


  • Es findet ausschließlich eine einseitige (unidirektionale) Replikation statt. Da keine Änderungen an einem RODC vollzogen werden können,
    ist es somit auch nicht nötig, dass sich der Replikationspartner (ein beschreibbarer Domänencontroller) Änderungen von dem RODC zieht.
    Es findet eine eingehende (Inbound) und keine ausgehende (Outbound) Replikation auf einem RODC statt.
    Somit werden auch weniger Bridgeheadserver benötigt.


  • Dadurch, dass der RODC das gesamte Schema repliziert bekommt, ist dieses Verhalten evtl. in einigen Situationen nicht wünschenswert.
    Wenn z.B. Applikationen eingesetzt werden, die sensible Informationen in den Active Directory-Domänendiensten speichern,
    möchte man vielleicht diese Informationen nicht auf einem RODC haben. Daher bietet der RODC die Option
    Read-Only Partial Attribute Set (ROPAS), auch bekannt als RODC Filtered Attribute Set (ROFAS).
    Mit dieser Funktion lässt sich definieren, dass diverse Attribute nicht auf einen RODC repliziert  werden.
    Ist es angedacht das solche Applikationen zum Einsatz kommen, so sollte darauf geachtet werden,
    dass sich aus Sicherheitsgründen die Gesamtstrukturfunktionsebene im Modus „Windows Server 2008“ befindet.


  • Einem Domänen-Benutzer bzw. einer Gruppe können administrative Rechte auf einem RODC delegiert werden.
    Somit wird der Benutzer bzw. die Gruppe zum lokalen Administrator auf dem RODC, ohne das der Benutzer/die Gruppe weitere
    Rechte auf die Domäne bzw. andere DCs erhält. Dadurch können die Personen die diese Rechte delegiert bekommen haben,
    z.B. die Wartung des RODCs vornehmen sowie Treiber oder Updates von Applikationen einspielen.


  • Ein RODC kann an einem Standort mit folgenden Server-Versionen aufgestellt werden:

    - Windows Server 2003 DCs aus der gleichen und/oder anderen Domäne 
    - Windows Server 2008 DCs aus der gleichen und/oder anderen Domäne
    - Windows Server 2008 R2 DCs aus der gleichen und/oder anderen Domäne
    - Windows Server 2008 RODCs aus der gleichen und/oder anderen Domäne
    - Windows Server 2008 R2 RODCs aus der gleichen und/oder anderen Domäne


  • Damit RODCs eingesetzt werden können, wurden dem Schema des Windows Server 2008 die folgenden Attribute hinzugefügt:

    - ms-DS-Reveal-OnDemand-Group
    - ms-DS-Never-Reveal-Group
    - ms-DS-Revealed-List
    - ms-DS-AuthenticatedTo-Accountlist


  • Die Installation eines RODCs kann in zwei Schritten vollzogen werden. Zuerst wird im Snap-In Active Directory-Benutzer und –Computer
    mit einem Rechtsklick auf den Container Domain Controllers das Computer-Objekt erstellt.
    Dazu werden Domänen-Administrator Rechte benötigt. Beim erstellen des Computer-Objekts wird z.B. der Computername und der
    Standort festgelegt. Im zweiten Schritt ruft man den Active Directory-Assistenten DCPROMO auf und konfiguriert den Server zum RODC.
    Das ausführen von DCPROMO kann von einem Benutzer in einer Außenstelle vollzogen werden,
    der die entsprechenden Rechte delegiert bekommen hat.

    Es reicht natürlich weiterhin aus, nur das DCPROMO direkt auszuführen.


 



Welche Voraussetzungen müssen erfüllt sein, um einen RODC einzusetzen?





  • Die Domänenpartition kann sich der RODC ausschließlich von einem beschreibbaren Windows Server 2008 bzw.
    Windows Server 2008 R2 Domänencontroller replizieren. Demzufolge muss sich bereits ein
    beschreibbarer Windows Server 2008/2008 R2/Core/Core R2 Domänencontroller in der Domäne befinden.




  • Der Gesamtstrukturfunktionsmodus muss sich mindestens in dem Modus Windows Server 2003
    oder höher befinden, damit die Linked Value Replikation (LVR) zur Verfügung steht. 




  • Das Active Directory Preparation Tool (ADPREP) muss mit dem Schalter /RODCPREP ausgeführt worden sein.
    Dabei werden die Berechtigungen (Security Descriptor, SD) von allen DNS-Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) in der Gesamtstruktur aktualisiert. Der Befehl muss mit Organisations-Administrator Rechten durchgeführt werden und
    kann auf irgendeinem DC ausgeführt werden. Dieser DC muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen von ADPREP /Rodcprep werden die einzelnen Infrastrukturmaster der Domänen kontaktiert, um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.



Welche Einschränkungen hat ein RODC?





  • Dadurch dass der RODC nur einen lesenden Zugriff auf die AD-Datenbank hat, kann er deshalb auch nicht der Träger der fünf
    Flexible Single Master Operations (FSMO)-Rollen sein. Denn diese Rollen benötigen einen Schreibzugriff auf die AD-Datenbank,
    damit z.B. der Schema-Master eine Schema-Änderung vollziehen kann usw.




  • Des Weiteren kann ein RODC auch kein Bridgehead-Server sein. Ein Bridgehead-Server ist für die Standort-zu-Standort Replikation zuständig.
    Dieser sammelt die getätigten Änderungen im Active Directory an seinem Standort und repliziert diese zu einem anderen Bridgeheadserver an
    einem entfernten Standort. Da der RODC nur eine einseitige In-Bound Replikation wahrnehmen kann, entfällt somit die Rolle des Bridgehead-Servers.




  • Da der RODC von einem beschreibbaren Domänencontroller abhängig ist, kann demzufolge der erste DC weder
    in einer neuen Gesamtstruktur, noch in einer neuen Domäne ein RODC sein. Beim installieren eines RODCs muss
    sich bereits ein beschreibbarer Windows Server 2008 DC in der Domäne befinden. Anderfalls ist das Heraufstufen zum RODC nicht möglich.




  • Eine weitere Einschränkung des RODCs wäre, dass sich die Domänenpartition in der sich z.B. die Benutzer- und Computerkonten befinden,
    nicht von einem Windows Server 2003 DC replizieren lässt, sondern ausschließlich von einem beschreibbaren Windows Server 2008 bzw. Windows Server 2008 R2.




  • Es findet keine Replikation zwischen RODCs statt.




  • Ein Exchange Server wird auf einem RODC nicht unterstützt.




  • Wenn der einzige beschreibbare Domänencontroller einer Domäne crasht und an einem entfernten Standort „lediglich“ ein RODC existiert,
    muss die Domäne neu erstellt werden. Denn im Gegensatz zum NT-BDC (dieser kann zum PDC gestuft werden) ist es nicht möglich,
    einen RODC zu einem vollwertigen Domänencontroller zu stufen.

    Das bedeutet, die allgemeine Empfehlung in jeder Domäne zwei Domänencontroller zu besitzen (neben dem RODC), gilt weiterhin.



 


Die Installation eines RODC




Mehr zum RODC gibt es hier:
Step-by-Step Guide for Read-Only Domain Controller in Windows Server 2008
Read-Only DCs and the Active Directory Schema


Comments are closed, but trackbacks and pingbacks are open.