4
RODC in DMZ
Hallo Liebe Gemeinde,
ich habe eine Herausforderung im Bereich RODC in DMZ.
Ich weiss, es gibt tausende Artikel im Internet - doch irgendwie werde ich nicht schlau hieraus.
Vielleicht könnt Ihr mir einen Tipp geben.
Anforderung:
Diverse Clients verbunden via VPN - (VPN endet in DMZ, da der Zugriff etwas risiko-behaftet ist) -> Authentifizierung soll gegen RODC erfolgen
und
weitere Server im Bereich der DMZ sollen sich im AD authentifizieren können via RODC
Geplanter / teildurchgeführter Aufbau:
2 RW-DCs in der Domäne, 1 RODC im Bereich der DMZ - logischerweise getrennt durch eine Firewall
Clients / Server und RODC befinden sich in DMZ (auch AD-Site DMZ)
RWDCs im Innern (AD Site Intern)
Clients / Server haben als DNS den RODC eingetragen.
Zugriff nur zwischen RODC und RWDCs auf Firewall freigegeben
RODC ist auch RO-DNS und GC
Es sollen keine Passwörter etc. auf dem RODC gespeichert werden - alle Anfragen sollen an die RWDCs weitergegeben werden (somit gibt es keine Mitglieder in der Gruppe "Zugelassene Kennwortreplikation") - er soll quasi als Proxy agieren, damit Clients / DMZ-Server nicht mit den RWDCs sprechen müssen
Alles funktioniert:
Die Server/Clients authentifizieren sich gegen den RODC, beziehen GPOs hierüber und sind in der richtigen Site.
Trotzdem stelle ich fest, dass die Systeme immer wieder versuchen die RWDCs anzusprechen (z.B. auf Port 389, 53 etc.) - dies wird durch die Firewall geblockt
Meine Frage:
Warum passiert das? Ich würde gerne diesen "sinnlosen" Traffic loswerden.
und
Kann es zu Problemen kommen, wenn die Systeme nicht auf die RWDCs zugreifen können?
Noch eine Anmerkung:
Es handelt sich nicht um eine "klassische" DMZ - es befinden sich hier keine Webserver mit Internetzugriff.
Ich würde gerne die Diskussion über die Sinnhaftigkeit von RODCs in der DMZ möglichst klein halten.
Ich danke Euch sehr herzlich!
ich habe eine Herausforderung im Bereich RODC in DMZ.
Ich weiss, es gibt tausende Artikel im Internet - doch irgendwie werde ich nicht schlau hieraus.
Vielleicht könnt Ihr mir einen Tipp geben.
Anforderung:
Diverse Clients verbunden via VPN - (VPN endet in DMZ, da der Zugriff etwas risiko-behaftet ist) -> Authentifizierung soll gegen RODC erfolgen
und
weitere Server im Bereich der DMZ sollen sich im AD authentifizieren können via RODC
Geplanter / teildurchgeführter Aufbau:
2 RW-DCs in der Domäne, 1 RODC im Bereich der DMZ - logischerweise getrennt durch eine Firewall
Clients / Server und RODC befinden sich in DMZ (auch AD-Site DMZ)
RWDCs im Innern (AD Site Intern)
Clients / Server haben als DNS den RODC eingetragen.
Zugriff nur zwischen RODC und RWDCs auf Firewall freigegeben
RODC ist auch RO-DNS und GC
Es sollen keine Passwörter etc. auf dem RODC gespeichert werden - alle Anfragen sollen an die RWDCs weitergegeben werden (somit gibt es keine Mitglieder in der Gruppe "Zugelassene Kennwortreplikation") - er soll quasi als Proxy agieren, damit Clients / DMZ-Server nicht mit den RWDCs sprechen müssen
Alles funktioniert:
Die Server/Clients authentifizieren sich gegen den RODC, beziehen GPOs hierüber und sind in der richtigen Site.
Trotzdem stelle ich fest, dass die Systeme immer wieder versuchen die RWDCs anzusprechen (z.B. auf Port 389, 53 etc.) - dies wird durch die Firewall geblockt
Meine Frage:
Warum passiert das? Ich würde gerne diesen "sinnlosen" Traffic loswerden.
und
Kann es zu Problemen kommen, wenn die Systeme nicht auf die RWDCs zugreifen können?
Noch eine Anmerkung:
Es handelt sich nicht um eine "klassische" DMZ - es befinden sich hier keine Webserver mit Internetzugriff.
Ich würde gerne die Diskussion über die Sinnhaftigkeit von RODCs in der DMZ möglichst klein halten.
Ich danke Euch sehr herzlich!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 379907
Url: https://administrator.de/contentid/379907
Printed on: April 19, 2024 at 00:04 o'clock
4 Comments
Latest comment
Hallo,
Selbst auf normale DCs (RWDCs) sind keine Passwörter im AD gespeichert. Dort sind höchstens die Hasches zu finden. Selbst ein NT4 DC kennt die eigentlichen Passwörter nicht.
Gruß,
Peter
Selbst auf normale DCs (RWDCs) sind keine Passwörter im AD gespeichert. Dort sind höchstens die Hasches zu finden. Selbst ein NT4 DC kennt die eigentlichen Passwörter nicht.
Trotzdem stelle ich fest, dass die Systeme immer wieder versuchen die RWDCs anzusprechen (z.B. auf Port 389, 53 etc.) - dies wird durch die Firewall geblockt
Schon mal geschaut wer oder was von PORT 389 genutzt wird? Und bedenke, wenn dein RODC in der Domäne keinerlei Benutzerpasswörter kenn würde, wie sollen die dann am RWDC abgefragt werden? Und dein Port 53 ist eigentlich DNS. Warum will dein RODC den DNS in der Domäne anfragen? Klingelingeling - hier kommt der ... Warum passiert das? Ich würde gerne diesen "sinnlosen" Traffic loswerden.
Was für dich evtl Sinnlos ist kann aber Lebenswichtig sein. Ein Wireshark hilft dir Erkentnisse zu bekommen.Kann es zu Problemen kommen, wenn die Systeme nicht auf die RWDCs zugreifen können?
Warum soll dein RODC denn von seinen Kollegen abgeschnitten werden und wo soll der dann Anfragen wenn er etwas nicht kennt? RODC bedeutet ja nur das er Schreibgeschützt ist, nicht das er allwissend ist Gruß,
Peter
Hallo Peter,
vielen Dank für deine Antwort.
Leider scheinst Du meinen Beitrag nicht ganz verstanden oder nicht richtig gelesen zu haben...
Die leicht überhebliche Art finde ich etwas unangemessen - aber ich denke Du meinst dies nicht so negativ wie es klingt...
-Mir ist bewusst, dass DCs keine Passwörter speichern - hier ist gemeint, dass auf dem RODC keine Anmeldedaten/Hashes vorgehalten werden sollen (für welchen Zweck ein RODC ja eigentlich gedacht ist - z.B. bei Verbindungsverlust die Anmeldung in der Außenstelle trotzdem zu ermöglichen)
-Das Port 389 LDAP ist und Port 53 DNS ist mir klar - die Frage ist aber, wieso die Server und Clients in der DMZ diese Anfrage an die RWDCs stellen und nicht an den in Ihrer Site vorhandenen RODC / RO-DNS
Das der RODC DNS-Anfragen an die RW-DCs sendet ist in diesem Aufbau normal, korrekt und wird durch die Firewall zugelassen.
-Ich sehe den (geblockten) Traffic auf der Firewall - ein Wireshark-Dump hilft mir eher nicht weiter
-Da die Authentifizierung und Co funktionieren, zielte meine Frage darauf ab, ob es zu Fehlern kommen kann, wenn die Clients/Server in der DMZ die RWDCs auf Dauer nicht erreichen können.
Ich danke Dir für deine Bemühungen und hoffe etwas Licht ins Dunkel gebracht zu haben.
Gruß
Mario
vielen Dank für deine Antwort.
Leider scheinst Du meinen Beitrag nicht ganz verstanden oder nicht richtig gelesen zu haben...
Die leicht überhebliche Art finde ich etwas unangemessen - aber ich denke Du meinst dies nicht so negativ wie es klingt...
-Mir ist bewusst, dass DCs keine Passwörter speichern - hier ist gemeint, dass auf dem RODC keine Anmeldedaten/Hashes vorgehalten werden sollen (für welchen Zweck ein RODC ja eigentlich gedacht ist - z.B. bei Verbindungsverlust die Anmeldung in der Außenstelle trotzdem zu ermöglichen)
-Das Port 389 LDAP ist und Port 53 DNS ist mir klar - die Frage ist aber, wieso die Server und Clients in der DMZ diese Anfrage an die RWDCs stellen und nicht an den in Ihrer Site vorhandenen RODC / RO-DNS
Das der RODC DNS-Anfragen an die RW-DCs sendet ist in diesem Aufbau normal, korrekt und wird durch die Firewall zugelassen.
-Ich sehe den (geblockten) Traffic auf der Firewall - ein Wireshark-Dump hilft mir eher nicht weiter
-Da die Authentifizierung und Co funktionieren, zielte meine Frage darauf ab, ob es zu Fehlern kommen kann, wenn die Clients/Server in der DMZ die RWDCs auf Dauer nicht erreichen können.
Ich danke Dir für deine Bemühungen und hoffe etwas Licht ins Dunkel gebracht zu haben.
Gruß
Mario
Hallo,
Das wird es sein
Gruß,
Peter
Das wird es sein
aber ich denke Du meinst dies nicht so negativ wie es klingt...
Si-Das Port 389 LDAP ist und Port 53 DNS ist mir klar - die Frage ist aber, wieso die Server und Clients in der DMZ diese Anfrage an die RWDCs stellen und nicht an den in Ihrer Site vorhandenen RODC / RO-DNS
Nun den Server (dein RODC) lassen wir mal ausen vor. Gibt es dort noch andere Server? Was deine dortigen Clients betrifft, ich dachte das sind dein VPN Clients weil du in dieser DNZ eher keine Clients hast, oder? Aber egal, wenn ein Client per Port 53 einen DNS sucht, hat ihm das ja jemand oder ein DHCP so mitgeteilt - aöso Konfiguration. Ansonsten hilft Wireshark und / oder ein TCPView (Sysinternals). Das deine Clients sich diese IP als DNS ausdenken, das glaube ich eher nicht ob es zu Fehlern kommen kann, wenn die Clients/Server in der DMZ die RWDCs auf Dauer nicht erreichen können.
Sollen deine Clients doch gar nicht, dafür hast du doch dir deinen RODC hingestellt - und der kennt hoffentlich die gesuchten Antworten.Gruß,
Peter
Hi,
ich vermute, Du hast vergessen, die DMZ und die einzelnen VPN-Subnetze als Standort- und Subnetz-Objekte im AD anzulegen?
Falls ja, dann gehe wie folgt vor:
In der MMC "Standorte und Dienste" ...
Jetzt sollten die Clients nach und nach mitbekommen, dass sie zu einem anderen AD-Standort gehören und dass nach der AD-Topologie der RODC der näheste DC ist. Solange dieser reagiert, werden sie nach keinem anderen DC fragen.
E.
Edit: Reihenfolge geändert. RODC muss früher in seinen Standort verschoben werden, sonst kann zu Problemen am Client kommen.
ich vermute, Du hast vergessen, die DMZ und die einzelnen VPN-Subnetze als Standort- und Subnetz-Objekte im AD anzulegen?
Falls ja, dann gehe wie folgt vor:
In der MMC "Standorte und Dienste" ...
- Erstelle ein Subnet-Objekt für die DMZ.
- Erstelle ein Site-Objekt für die DMZ und ordne das Subnet-Objekt zu
- Erstelle ein Site-Link zwischen erstem Standort und DMZ-Standort --> ändere das Replikationsintervall auf Minimum "15 min"
- Verschiebe das Serverobjekt des RODC in den DMZ-Standort
- Erstelle je ein Subnet-Objekte für alle VPN-Netze (dort, wo die Clients drin sind).
- Erstelle EIN Site-Objekt für alle VPN-Standorte zusammen und bennen es z.B. "ohne DC" oder "VPN Standorte" und ordne diesem alle Subnet-Objekte der VPN-Standorte zu
- Erstelle ein Site-Link zwischen DMZ-Standort und VPN-Standort (nicht zum ersten Standort mit den Write-DC!)
- Warte die Replikation ab!
Jetzt sollten die Clients nach und nach mitbekommen, dass sie zu einem anderen AD-Standort gehören und dass nach der AD-Topologie der RODC der näheste DC ist. Solange dieser reagiert, werden sie nach keinem anderen DC fragen.
E.
Edit: Reihenfolge geändert. RODC muss früher in seinen Standort verschoben werden, sonst kann zu Problemen am Client kommen.
