Share via

RODC in DMZ

  • Article

Hallo, hier gleich nochmal Andy aus dem Domain Team. Das Thema RODC in der DMZ führt immer wieder mal zu Missverständnissen. RODC sind ja grundsätzlich ein Segen, wenn in einer DMZ AD Integrierte Server betrieben werden müssen.

Bis zu Windows 2003 musste entweder ein DC in der DMZ vorhanden sein, oder die Firewall sieht in das interne Netzwerk aus wie ein Schweizer Käse. Mit Windows 2008 kann in die DMZ ohne großes Sicherheitsrisiko ein DC installiert werden, ohne dass die sicherheitsrelevanten Informationen der AD Datenbank in die DMZ repliziert wird. Leider verbergen sich ein paar Fallstricke wenn ein RODC in einer DMZ betrieben wird.
Es sollten folgende Punkte beachtet werden:

- IPSec Tunnel 
- Installation
- DNS
- Site Configuration
- Password Replication Policy
- Administrator Rolle
- Client Installation
- Anmerkungen/Verständnis

IPSec Tunnel
Fangen wir mal mit der Grundlegenden Frage an. Wenn einen RODC verwendet wird, benötigt dieser einen schreibbaren Windows 2008 (oder höher) Domain Controller zur Replikation. Dies bedeutet erst mal, dass einige viele Ports zwischen der DMZ und dem internen Netz offen sein müssen. Neben den Standard Protokollen wie DNS, LDAP, Kerberos und SMB kommt noch RPC Kommunikation hinzu. Als ob das nicht schlimm genug ist, ist der Verbindungsaufbau der IP Verbindung in beide Richtungen. Um jetzt nicht mit einer Schrotflinte auf die Firewall zu schießen bietet sich IPsec an.
Bei IPsec klingen natürlich bei den Firewall Administratoren die Alarmglocke. Die Firewall wird insgesamt sicherer weil einfacher (Immer nach dem Motto KeepItSimpleandStupid) andererseits ist IP ein Tunnel und was in dem Tunnel passiert sieht die Firewall nicht. Hier beginnt der philosophische Ansatz der Diskussion. Beide Lösungen sind valide und gut. Welche Entscheidung hier die richtige ist lässt sich nicht pauschal beantworten.

Installation
Dann kommen wir zum Thema Installation. Im ersten Schritt sollte man sich darüber klar werden, das in in der DMZ installierte DC immer ein höheres Angriffsziel darstellen kann als ein Intranet DC. Um die Angriffsfläche zu reduzieren, sollte (meiner Meinung nach) ein RODC in einer DMZ als Server Core installiert werden.

DNS (Domain Name System)
Das Thema DNS wird auch oftmals unterschätzt. Als Windows Administrator muss man sich klar darüber werden, dass RODC's nur als Secondary DNS Server fungieren und somit keine beschreibbar Partition des DNS NC besitzt. Im Gegensatz zur Anmeldung bei der ein Kerberos Passthrough erfolgt (darauf komme ich später nochmal zu sprechen) werden DNS Registrierungen nicht an einen writeable DC weitergeleitet. Ist ein Server für Dynamisches DNS konfiguriert wird er versuchen einen DC mit einem gültigen SOA Eintrag zu kontaktieren. Was natürlich nicht Ziel einer DMZ sein kann. Um diese Problem zu lösen gibt es wieder verschiedene Ansätze:

- kein DNS: Der Client / Server muss nicht im DNS registriert sein. In diesem Fall ist der Server nur über die IP Adresse erreichbar. Was mit IPv4 vielleicht noch machbar ist, aber mit IPv6 Adressen ???
- statischer DNS Eintrag: Das ist heute ein immer noch weit verbreiteter Ansatz IP Adressen und Hostnamen offline zu verwalten. Bedeutet aber manueller mehr Aufwand, der sich jedoch für eine DMZ in Grenzen halten sollte.
- DHCP: Das ist der Königsweg. Warum die IP Adresse nicht per DHCP an Server in der DMZ verteilen? Über den DHCP Server kann dann die Registrierung im DNS erfolgen. Dies ist gerade in IPv6 Umgebungen ein sehr eleganter Weg (oder wer will IPv6 Adressen manuell verwalten, eintragen etc.)

Site Configuration
Natürlich muss die DMZ mit Ihren Subnetzen im AD abgebildet werden. Hierzu ist eine entsprechende Site zu erstellen und die Netzwerke der DMZ dieser Site zuzuweisen. Der DCLocator des Clients benötigt diese Zuordnung, um über die entsprechenden LDAP Server Records den RODC als Anmeldeserver seiner zugewiesenen Site zu identifizieren.

Password ReplicationPolicy
Als nächster Schritt ist die Password Replication Policy zu definieren und mit den Benutzer und Computerkonten zu konfigurieren.

- Im AD eine Gruppe für die DMZ Benutzer und Computer anlegen.
- Die Computer und Benutzerkonten dieser Gruppe hinzufügen.
- Jetzt muss noch die Password Replication Policy angepasst werden. Die Password Policy kann über das “Active Directory Users and Computers” Snap-in (DSA.MSC) verwaltet werden. Einfach den/die RODC Domain Controller auswählen und im “Password Replication Policy” Tab über “Add…”, “Allow passwords for the account to replicate to this RODC.” die Gruppen auswählen, deren Password auf den RODC repliziert werden soll.

 

Administrator Rolle In einer DMZ sollte natürlich ein Domain Administrativer Account verwendet werden. Um jedoch Administrative Aufgaben auch auf einem RODC auszuführen sollte eine DMZ Administrator Rolle eingerichtet werden. Referenz hierzu ist “Administrator Role Separation Configuration”, https://technet.microsoft.com/en-us/library/cc732301(WS.10).aspx
Das Einrichten erfolgt über: dsmgmt.exe => local roles => add <domain>\<user> administrators

So die DMZ ist für den Betrieb mit einem RODC bereit. Auch hierzu eine gute Referenz “Designing RODCs in the Perimeter Network”, https://technet.microsoft.com/en-us/library/dd728028(WS.10).aspx

Client Installation Kommen wir zur Installation der Clients. Auch hier haben wir zwei Vorgehensweisen. Standardmäßig versucht ein Windows Client der in eine Domain aufgenommen wird einen beschreibbaren DC zu erreichen. Dies wird in unserer DMZ jedoch nicht funktionieren. Also ein Weg ist, dass Computerkonto im AD zu erstellen und das Konto der Password Replication Group hinzuzufügen. Mein Kollege Ingolfur Arnar Stangeland hat dazu ebenfalls einen Blog veröffentlicht, https://blogs.technet.com/b/instan/archive/2008/08/13/troubleshooting-rodc-s-troubleshooting-domain-joins-against-rodc-s.aspx 
Mit dem Befehl „netdom join <machine> /Domain:<domain> /UserD:<domain user> /PasswordD:* /ReadOnly“ kann dann eine Maschine der AD hinzugefügt werden, sofern das Konto bereits existiert.

Anmerkungen/Verständnis So jetzt zum Schluss noch ein paar Anmerkungen über Themen, die oft zu Verwirrungen führen:

Windows RODC erlauben eine Kerberos Pass Through Authentication: Ja das ist richtig, ist ein Konto nicht in der Password Policy bzw. stimmt das eingegebene Passwort nicht mit dem vorhandenen Konto überein, wird die Authentifizierung an den nächsten schreibbaren/writeable DC (präferiert PDC) weitergeleitet. In diesem Fall arbeitet der RODC als Proxy.

Ein Kennwort kann auch über einen RODC geändert werden: Es stimmt, ein Benutzer / Computer (der in der Password Replication Policy mit "Allow" eingetragen ist) kann sein Kennwort ändern. Der RODC arbeitet in diesem Fall ebenfalls als Proxy und leitet diese Änderung an einen writeable DC weiter, von dem er wiederum das Passwort in seine Datenbank repliziert. Referenz Abschnitt “Password changes on an RODC” in https://msdn.microsoft.com/de-de/library/cc754218(v=ws.10).aspx

Was jedoch nicht funktioniert ist, dass ein Konto das nicht in der Password Policy vorhanden ist sein Passwort ändern kann wenn kein writeable DC vorhanden ist.
Interessant wird dieses Verhalten, wenn ein Computer Konto sein Passwort ändert.

---- Ein kleiner Abstecher wie ändert ein Computer sein Konto Passwort ----
Ist der Zeitpunkt erreicht, dass das Computer Konto seine maximales Alter erreicht hat, wird die Änderung aktiv vom Client ausgelöst. Hierzu prüft der Netlogon Service ob er einen Secure Channel zu einem DC besitzt oder zumindest einen DC erreicht. Dann wird ein neues Kennwort generiert und lokal in HKLM\SECURITY\Secrets\$machine.ACC in CurrVal gespeichert. Das bisherige Passwort wird von dem Wert CurrVal in OldVal verschoben. Erst jetzt wird das neue Passwort an das AD weitergeleitet – unabhängig davon, ob der DC das Passwort verarbeiten kann oder nicht.
Das alte Passwort wird dazu verwendet, wenn eine Maschine (aus welchen Gründen auch immer) einen neuen Secure Channel zu einem DC aufbaut, dieser jedoch die Änderung des Passwortes noch nicht repliziert bekommen hat, in diesem Fall verwendet Windows das im OldVal gespeicherte Passwort. Somit ist der Secure Channel auch beim Passwortwechsel grundsätzlich gewährleistet.
Auch hierzu eine Blog Referenz, von Manish Singh aus dem US DS Team https://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
”When a client determines that the machine account password needs to be changed, it would try to contact a domain controller for the domain of which it is a member of to change the password on the domain controller. If this operation succeeds then it would update machine account password locally.
We first change the password locally and then update it in Active Directory. It will not rollback the changes to the current password if it is unable to update it in Active Directory.”
---- und wieder zurück zu unserem RODC Problem ----

Ein Computer der nicht Mitglied in der Password Replication Policy ist, jedoch in der Site (in unserem Fall die DMZ) platziert ist, in der nur ein oder mehrere RODC’s vorhanden sind, kann keinen gültigen Secure Channel zu einem RODC aufbauen. Referenz hierzu “Appendix A: RODC Technical Reference Topics”, https://technet.microsoft.com/en-us/library/cc754218(WS.10).aspx 
“For the client computer to be able to establish a secure channel with the RODC, its current credentials must be cached on the RODC. If the client computer does not have a secure channel with the RODC, it attempts the password change on a writable domain controller. (This always happens if the client computer account is not cached on the RODC.) ”
Ändert der Client sein Passwort (z.B. nach 30 Tagen) ist der RODC der einzig erreichbare DC, fungiert jetzt aber nicht als Proxy, dennoch meldet er dem Client gleichzeitig ein erfolgreichen Password Change. Das gemeine ist, das Passwort wird so nicht im AD geändert. Das neue Passwort CurrVal ist damit ungültig und der Client greift auf OldVal zurück. Der RODC kann ihn über die Weiterleitung zum PDC zunächst weiter authentifizieren.
Nach weiteren 30 Tagen wiederholt sich das Spiel. Der der Client speichert das aktuelle Passwort im OldVal Wert. Der bisherige OldVal Wert wird überschrieben. Wird der Client neu gestartet wird eine neue Authentifizierung notwendig. Da aber in diesem Fall weder das "neue" noch "alte" Password gütig ist, kann der Client über den RODC nicht mehr authentifiziert werden und ist somit ausgesperrt.
Durch die Verzögerung von 2 x Passwortwechsel ist dieser Fehler nicht ganz so einfach zu verstehen bzw. zu erkennen.
Zugegebenermaßen könnte sich hier der Client etwas schlauer verhalten, das ist in der besonderen DMZ Konstellation ein ungünstiges Design. Der RODC wurde eben primär für WAN ausgelegt, was temporäre nicht-Verfügbarkeit eines writeable DCs für Clients bedeutet. Bei der DMZ Konfiguration ist es jedoch so, daß ein writeable DC nie von den Clients erreicht werden kann – was speziell berücksichtigt werden muß.

Fazit
Clients in der DMZ die sich nicht direkt mit einem writeable DC verbinden können, müssen in der “Password Replication Policy” konfiguriert sein! Das gilt auch für Clients die potentiell mehr als 30 Tage in einer DMZ betrieben werden.
Ansonsten sind RODC’s die richtige Wahl wenn ein AD integrierter Server in einer DMZ platziert werden muss.

Ich wünsche euch weiterhin viel Erfolg mit euren RODC’s in der DMZ
Andy

Comments

  • Anonymous
    January 01, 2003
    Hallo Daniel, das IPSec Setup ist recht komplex. Die Spezialisten dazu sind zudem unsere Netzwerkkollegen. Das Whitepaper "Deploying RODCs in the Perimeter Network",technet.microsoft.com/.../dd728035(WS.10).aspx, verweist an der Stelle auf: Step-by-Step Guide to Internet Protocol Security (IPsec) (go.microsoft.com/fwlink) and Checklist: Implementing a Standalone Server Isolation Policy Design (go.microsoft.com/fwlink). Auf den ersten Blick sieht das für mich ganz brauchbar aus, auch wenn es nicht in Deutsch ist... Hoffe das hilft etwas! Grüße, Rol

  • Anonymous
    May 23, 2011
    Hallo, ein wirlich toller Beitrag zu dem Thema. Infos zur implementierung von IPSEC zwischen einem RODC und einem writabel DC währen noch hilfreich. Grüße

  • Anonymous
    June 03, 2011
    Hallo, danke für die Antwort und die Infos. Ich werde mein Glück einmal versuchen. Grüße

  • Anonymous
    June 16, 2011
    nach einigen Versuchen hat es doch schließlich mit der IPSEC Verbindung geklappt. Hierei hat mir das folgende MS Dokument weitergeholfen ergänzend zu den Links, die du bereitgestellt hast. IPSec support for client-to-domain controller traffic and domain controller-to-domain controller traffic (support.microsoft.com/.../en-us) und IPSec-Standardausnahmen werden in Windows Server 2003 entfernt. (support.microsoft.com/.../810207) Grüße Daniel