RODCs in Perimeter-Netzwerken

RODC („Rotz“ gesprochen) sind wohl das meistberüchtigste neue Feature von Windows Server 2008! Endlich haben wir den guten alten Backup Domain Controller (BDC) zurück – obwohl man diesen natürlich keineswegs mit einem solchen verwechseln sollte, da das Verhalten trotz aller Ähnlichkeit, absolut anders ist. Jedoch ist es sehr reizvoll, einen RODC nicht einfach nur bei den üblichen Branch-Office Konstellationen einzusetzen, sondern auch in etwas abenteuerlichen Bereichen – wie z.B. in einer DMZ oder abgesicherten Zone, in welchem die Benutzer möglichst wenig beschreibbare Dienste vorfinden sollten. In diesem Szenario gibt es einen Grundsatz: Die Clients und Member-Server können ausschliesslich auf einen RODC zugreifen und nur diese sind dann wiederum in der Lage, mit einem beschreibbaren Domänencontroller zu kommunizieren (gemäss der Regeln auf einer Netzwerk-Firewall).

Dies klingt eigentlich alles sehr gut – aber es gibt dabei so einiges an „Kleinigkeiten“ zu beachten:

  • Ein regulärer Domain Join ist so nur noch mittels Umwegen zu erreichen (Offline Domain Join oder Scripting), da auf einem RODC halt eben keine neuen Objekte erstellt werden können und ein RWDC nicht durch den neuen Client erreichbar ist
  • Ein regulärer Client in dieser Zone kann sich nur dann an der Domäne anmelden, wenn der RODC dessen Benutzer- (und falls benötigt auch dessen Computer-) Kennwort zwischengespeichert hat oder ein RWDC für die Authentifzierung über den RODC als Proxy zur Verfügung steht.
  • Ein regulärer Client in dieser Zone kann in DNS keinen dynamischen Update seiner A- und PTR-Records vornehmen, da auch die DNS-Zone auf dem RODC nicht beschreibbar ist und der vom RODC angegebene beschreibbare DC (Redirecting) nicht durch den Client erreicht werden kann.
  • Ein Client in dieser Zone kann nicht bestimmen, in welchem Standort er sich befindet, da für dies einige SRV-Records für den/die RODC(s) in DNS fehlen.
  • Passwortänderungen sind nur dann möglich, wenn auch eine Verbindung vom RODC zu einem RWDC besteht.
  • LDAP-Abfragen von dieser sicheren Zone aus, können zu Problemen führen, da Microsoft dabei vergessen hat, dass ADSI-Abfragen im LDAP teilweise auch von Gruppenrichtlinien mit Zielgruppenfilterung vorgenommen werden.

Wie können nun jedoch die obig genannten Probleme behoben werden? Nachfolgend eine Ubersicht mit ein paar Tipps & Tricks dazu:

  • Wie schon erwähnt, ist ein Domain Join nur noch über die Offline-Variante (djoin.exe), welche erst mit Windows 7 erhältlich ist, möglich. Alternativ gibt es zwar noch die Alternative, das Computerkonto zuvor im AD zu erstellen, das Passwort dessen auf den RODC über die Passwort-Replikationsrichtlinie zu übertragen, mittels eines Scripts noch einige weitere Attribute auf diesen RODC zu synchronisieren und dann mittels eines weiteren Scripts den Domain Join vorzunehmen. Entscheide also selbst, welches der praktikablere Weg dafür ist…
  • Das mit den Passwörtern lässt sich natürlich über eine Passwort-Replikationsrichtlinie lösen – aber diese macht nur dann Spass, wenn nur ein einzelner RODC in der sicheren Zone vorhanden ist – zumindest bei Benutzerpasswörtern. Für Computerkennwörter lohnt es sich stets, eine entsprechende PRP zu erstellen, welche jedoch bei mehreren RODCs auf allen dieselbe sein sollte.
  • Für dieses Problem gibt es laut Microsoft, 3 Lösungsvarianten: 1. Man verzichtet auf die Erstellung der Records in DNS, 2. Man erstellt die Records manuell und 3. Man überträgt die Aufgabe der Erstellung der Records an den DHCP-Server, der somit jedoch einen DNS auf einem beschreibbaren DC erreichen können muss. Nummer 3 ist da wohl die praktikabelste Lösung – aber bei Servern in der sicheren Zone, welche über eine statische Konfiguration verfügen, ist da wohl dennoch Handarbeit angesagt, falls diese auch über DNS auflösbar sein sollen…
  • Auch für dies gibt es einen Trick: Auf den RODCs der sicheren Zone lässt ein ein kleines Registry-Hack ausführen, welcher dem RODC sagt, dass er auch alle nicht Standort-spezifischen Records in DNS registrieren solle. Dieser Eintrag befindet sich unter dem Pfad: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\RegisterSiteSpecificDnsRecordsOnly  – und muss auf den Wert „0“ gesetzt werden, wenn nicht nur die Standort-spezifischen Einträge dynamisch erstellt werden sollen. Mit dem ist es jedoch noch nicht getan. Auf diese Weise versucht ein RODC zwar, die Einträge zu erstellen, wird jedoch immer wieder kläglich dabei scheitern, da er nicht über die notwendigen Rechte auf den in den IP-Settings angegebenen DNS-Servern hat. Schon einmal vorweg: Auf dem RODC sind die DNS-Server auf einem beschreibbaren DC anzugeben. Damit diese auch noch über die notwendigen Rechte verfügen, sollten die Computerkonten der RODCs in einer Gruppe zusammengefasst werden und dieser Gruppe im Anschluss die Lese- und Schreibberechtigung über die Domänenzone und die „_msdcs“-Zone zugewiesen werden. Wichtig: Unbedingt im Anschluss dafür sorgen, dass in den erweiterten Sicherheitseinstellungen der Zonen die Rechte für „Diesen Container und alle untergeordneten Objekte“ zugeordnet wird.
  • Dieser Punkt ist nicht direkt zu lösen: „This behavior is by design“…
  • Dieses Problem tritt im Einsatz mit Windows Server 2008 + R2 ohne SP auf und kann durch einen Patch auf allen Clients behoben werden, der jedoch nicht offiziell zur Verfügung steht und auch nicht per WSUS verteilt werden kann. Mehr dazu im folgenden KB-Artikel von Microsoft: http://support.microsoft.com/kb/983531

Das also mal als Kurzzusammenfassung aller Spezialitäten eines RODCs in einer DMZ ;-D – viel Spass beim Implementieren.

Weiterführende Artikel:

VN:R_U [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)
RODCs in Perimeter-Netzwerken, 10.0 out of 10 based on 1 rating

Schreib einen Kommentar