none
AD mit multiplen Sites greift nicht auf gewünschte DCs zu, was sollte angepasst werden? RRS feed

  • Frage

  • Hallo,

    ich versuche mich kurz zu fassen, wäre schön wenn jemand helfen könnte.

    Thx
    Adam


    Wir betreiben ein AD mit 3 Domains, FOO.LAN, DE.FOO.LAN (head office) und BX.FOO.LAN (branch office), wobei sich FOO und FOODE in der Site IL und FOOBX in der Site EIN befinden. Das head office soll nun um zwei Sites erweitert werden, eine private DMZ, in der an das AD angebundene public Services gehostet werden sollen, und eine weitere private DMZ, in die die Mitarbeiter per VPN gelangen. Der VPN-Zugriff soll aus dem Kernnetzwerk dorthin verlagert werden. Um nicht ein großes Loch für den Domänencontrollerzugriff in die Firewall bohren zu müssen und nicht jeder DMZ einen vollen Satz RODCs zur Verfügung stellen zu müssen war der Gedanke der, einen Satz RODCs in einer weiteren privaten DMZ zur Verfügung zu stellen, der dann von allen Domänenmitgliedern bzw. angeschlossenen Services außerhalb des Kernnetzwerkes (alles noch private IP-Netze) genutzt wird. Dabei soll es so sein, daß die Site IL-PrivateDmzWebsvcs netzwerktechnisch Zugriff auf die Site IL-PrivateDmzDomsvcs hat, aber keinen Zugriff auf die Site IL. Gleiches gilt für die Site IL-PrivateDmzVpnsvcs. Websvcs und Vpnsvcs dürfen ebenfalls nicht miteinander kommunizieren. Die RODCs der Site IL-PrivateDmzDomsvcs dürfen mit den Domänencontrollern der Sites IL und EIN kommunizieren. Es gibt entsprechende SiteLinks, BASL ist abgeschaltet.

    Das Problem hier ist, daß aus den Sites IL-PrivateDmzWebsvcs und IL-PrivateDmzVpnsvcs versucht wird, auf die schreibbaren Domänencontroller zuzugreifen, und nicht auf die dafür vorgesehenen RODCs. Da die Firewall zu ist funktioniert das natürlich nicht. Kann man ohne in die beiden DMZ RODCs zu stellen dafür sorgen, daß nur RODCs verwendet werden, oder ist sowas nicht vorgesehen?

    Ich habe das zur besseren Übersicht mal grafisch aufbereitet und angehängt.

    https://paste.pics/67a936cf5f884c1b15cc11f4ce0404b6

    Die derzeit vorhandenen DNS-Records habe ich hier mal aufgelistet.

    DNS-Server Domain FOO:

    Zone _msdcs.foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites.dc DCFOO1 DCFOO2
    _tcp.IL._sites.dc DCFOO1 DCFOO2
    _tcp.IL-PrivateDmzDomsvcs._sites.dc RODCFOO1 RODCFOO2
    _tcp.IL-PrivateDmzWebsvcs._sites.dc DCFOO1
    _tcp.IL-PrivateDmzVpnsvcs._sites.dc DCFOO1

    Zone foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites DCFOO1 DCFOO2
    _tcp.IL._sites DCFOO1 DCFOO2
    _tcp.IL-PrivateDmzDomsvcs._sites RODCFOO1 RODCFOO2
    _tcp.IL-PrivateDmzWebsvcs._sites kein Record, nur _gc
    _tcp.IL-PrivateDmzVpnsvcs._sites kein Record, nur _gc

    Zone DomainDnsZones.foobar.lan, SRV Records _ldap:

    _tcp.EIN._sites DCFOO1 DCFOO2
    _tcp.IL._sites DCFOO1 DCFOO2
    _tcp.IL-PrivateDmzDomsvcs._sites DCFOO1 DCFOO2 RODCFOO1 RODCFOO2


    Zone ForestDnsZones.foobar.lan, SRV Records _ldap:

    _tcp.EIN._sites DCFOOBX1 DCFOOBX2
    _tcp.IL._sites DCFOO1 DCFOO2 DCFOOBX3 DCFOODE1 DCFOODE2
    _tcp.IL-PrivateDmzDomsvcs._sites DCFOO1 DCFOO2 DCFOOBX3 DCFOODE1 DCFOODE2 RODCFOO1 RODCFOO2 RODCFOODE1 RODCFOODE2 RODCFOOBX1 RODCFOOBX2
    _tcp.IL-PrivateDmzWebsvcs._sites DCFOO1
    _tcp.IL-PrivateDmzVpnsvcs._sites DCFOO1



    DNS-Server Domain FOODE

    Zone _msdcs.de.foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites.dc DCFOODE1 DCFOODE2
    _tcp.IL._sites.dc DCFOODE1 DCFOODE2
    _tcp.IL-PrivateDmzDomsvcs._sites.dc RODCFOODE1 RODCFOODE2
    _tcp.IL-PrivateDmzWebsvcs._sites.dc DCFOO1
    _tcp.IL-PrivateDmzVpnsvcs._sites.dc DCFOO1

    Zone de.foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites DCFOODE1 DCFOODE2
    _tcp.IL._sites DCFOODE1 DCFOODE2
    _tcp.IL-PrivateDmzDomsvcs._sites RODCFOODE1 RODCFOODE2
    _tcp.IL-PrivateDmzWebsvcs._sites DCFOODE1 DCFOODE2
    _tcp.IL-PrivateDmzVpnsvcs._sites DCFOODE1 DCFOODE2

    Zone DomainDnsZones.de.foobar.lan, SRV Records _ldap:

    _tcp.EIN._sites DCFOODE1 DCFOODE2
    _tcp.IL._sites DCFOODE1 DCFOODE2
    _tcp.IL-PrivateDmzDomsvcs._sites DCFOODE1 DCFOODE2 RODCFOODE1 RODCFOODE2
    _tcp.IL-PrivateDmzWebsvcs._sites DCFOODE1
    _tcp.IL-PrivateDmzVpnsvcs._sites DCFOODE1



    DNS-Server Domain FOOBX:

    Zone _msdcs.bx.foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites.dc DCFOOBX1 DCFOOBX2
    _tcp.IL._sites.dc DCFOOBX3
    _tcp.IL-PrivateDmzDomsvcs._sites.dc RODCFOOBX1 RODCFOOBX2


    Zone bx.foobar.lan, SRV Records _ldap und _kerberos:

    _tcp.EIN._sites DCFOOBX1 DCFOOBX2
    _tcp.IL._sites DCFOOBX3
    _tcp.IL-PrivateDmzDomsvcs._sites RODCFOOBX1 RODCFOOBX2 RODCFOOBX3


    Zone DomainDnsZones.bx.foobar.lan, SRV Records _ldap:

    _tcp.EIN._sites DCFOOBX1 DCFOOBX2
    _tcp.IL._sites DCFOOBX3
    _tcp.IL-PrivateDmzDomsvcs._sites DCFOOBX3 RODCFOOBX1 RODCFOOBX2

    Mittwoch, 3. Juli 2019 13:35

Antworten

  • Moin,

    um Deine Frage in den richtigen Kontext zu setzen: Topologie-Design dieser Komplexität wären in der verarbeitenden Industrie 2-3 Tage Beraterleistung, im Bankenumfeld zwei Wochen, in Behörden 20 Tage und im militärischen Bereich vermutlich zwei Monate. Bitte habe also Verständnis dafür, dass die Tragweite der hier, in einem freien Forum, erzeugten Ergebnisse vielleicht nicht 100% Deine Hoffnungen erfüllen wird.

    Nun aber zum Thema:

    1. unpopular opinion: Ein Netzwerksegment, in dem sich AD-Domain-Member oder-Controller befinden, ist keine DMZ, auch wenn es auf der Firewall 1000 Mal als DMZ gelabelt ist. Die reine Lehre der Netzwerksicherheit besagt, dass Anfragen stets aus Segmenten höherer Schutzstufe in solche niedrigerer Schutzstufe zu erfolgen haben und nicht umgekehrt. Das wird im AD-Geschäft niemals möglich sein.
    2. RODC, wenn er ge-ownt wird, ist genau so gefährlich wie ein RWDC. Das Konzept des RODC wurde nicht für Standorte mit eingeschränktem Netzwerkverkehr entwickelt, sondern für Standorte mit fehlender physischer Sicherheit (jemand klaut einen DC, es soll verhindert werden, dass er alle Passwörter aller User mitnimmt).
    3. Aus 2. folgend: Es gibt im AD-Geschäft *immer* Vorgänge, die den Zugriff auf einen RWDC benötigen. Der RODC agiert in dem Moment nicht etwa als Proxy für solche Anfragen, sondern er beantwortet nur Anfragen, für die sein lokal gespeicherter Datenbestand ausreicht.
    4. Den Traffic zwischen Sites regelst Du durch Kostenzuweisung der Site Links PLUS Sicherstellung, dass keine Site Link Bridge vorhanden ist, die Verbindungen dort überbrückt, wo keine Route existiert. Es sieht zwar an manchen Stellen so aus, als ob es nur für die Replikation gedacht wäre, aber die Site Coverage errechnet sich auch daraus.
    5. aus 3. und 4. folgend: jeder Standort, in dem AD Member stehen, muss eine Route UND eine Site Link-Kette zu einem Standort haben, wo ein RWDC steht.
    6. einschränkend zu allem Vorherigen: Es gibt Applikationen, die auf das ganze Site Coverage-Gedöns und überhaupt auf die Site-Topologie pfeifen und durch die Liste aus dem DNS so lange nach einem DC suchen, bis sie einen finden oder aufgeben.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Adam Minski Freitag, 5. Juli 2019 12:19
    Mittwoch, 3. Juli 2019 14:40

Alle Antworten

  • Moin,

    um Deine Frage in den richtigen Kontext zu setzen: Topologie-Design dieser Komplexität wären in der verarbeitenden Industrie 2-3 Tage Beraterleistung, im Bankenumfeld zwei Wochen, in Behörden 20 Tage und im militärischen Bereich vermutlich zwei Monate. Bitte habe also Verständnis dafür, dass die Tragweite der hier, in einem freien Forum, erzeugten Ergebnisse vielleicht nicht 100% Deine Hoffnungen erfüllen wird.

    Nun aber zum Thema:

    1. unpopular opinion: Ein Netzwerksegment, in dem sich AD-Domain-Member oder-Controller befinden, ist keine DMZ, auch wenn es auf der Firewall 1000 Mal als DMZ gelabelt ist. Die reine Lehre der Netzwerksicherheit besagt, dass Anfragen stets aus Segmenten höherer Schutzstufe in solche niedrigerer Schutzstufe zu erfolgen haben und nicht umgekehrt. Das wird im AD-Geschäft niemals möglich sein.
    2. RODC, wenn er ge-ownt wird, ist genau so gefährlich wie ein RWDC. Das Konzept des RODC wurde nicht für Standorte mit eingeschränktem Netzwerkverkehr entwickelt, sondern für Standorte mit fehlender physischer Sicherheit (jemand klaut einen DC, es soll verhindert werden, dass er alle Passwörter aller User mitnimmt).
    3. Aus 2. folgend: Es gibt im AD-Geschäft *immer* Vorgänge, die den Zugriff auf einen RWDC benötigen. Der RODC agiert in dem Moment nicht etwa als Proxy für solche Anfragen, sondern er beantwortet nur Anfragen, für die sein lokal gespeicherter Datenbestand ausreicht.
    4. Den Traffic zwischen Sites regelst Du durch Kostenzuweisung der Site Links PLUS Sicherstellung, dass keine Site Link Bridge vorhanden ist, die Verbindungen dort überbrückt, wo keine Route existiert. Es sieht zwar an manchen Stellen so aus, als ob es nur für die Replikation gedacht wäre, aber die Site Coverage errechnet sich auch daraus.
    5. aus 3. und 4. folgend: jeder Standort, in dem AD Member stehen, muss eine Route UND eine Site Link-Kette zu einem Standort haben, wo ein RWDC steht.
    6. einschränkend zu allem Vorherigen: Es gibt Applikationen, die auf das ganze Site Coverage-Gedöns und überhaupt auf die Site-Topologie pfeifen und durch die Liste aus dem DNS so lange nach einem DC suchen, bis sie einen finden oder aufgeben.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Adam Minski Freitag, 5. Juli 2019 12:19
    Mittwoch, 3. Juli 2019 14:40
  • 7. Parent/Child Forests sind nicht mehr State of the art. Security Boundary ist der Forest, nicht die Domain. Und ESAE sieht überhaupt nur noch Single Domain/Forest vor.

    8. FOO und BAR mag in der englischen Welt als Dummy geläufig sein. Für uns wäre es einfacher, Du würdest reale Namen (Orte) als Beispiel für Sites und geläufige Dummies (Contoso, Tailspintoys, Northwindtraders) als Firmennamen nehmen.

    Und Evgenjis Punkte unterschreibe ich.


    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Mittwoch, 3. Juli 2019 16:27
  • Moin Evgenij,

    hab Dank für deinen Kommentar, und die Einordnung in den Kontext. Im Grunde is das Wesentliche gesagt, daher werde ich ihn als Antwort markieren. Erlaube mir noch einige kurze Fragen bzw. Kommentare zu den von dir genannten Punkten:


    Zu 1:
    Soll man, da das AD-Geschäft niemals der Lehre der Netzwerksicherheit folgen wird, keinerlei Schutzmaßnahmen für interne Netze treffen und alles in eine Site einüten? Meiner Ansicht nach ist es doch besser, Segmente mit unterschiedlicher Schutzstufe zu schaffen, auch wenn nicht alles Gold ist was glänzt.

    Zu 3:
    Bisher hatte ich angenommen, daß ein RODC, solange man die Passwortreplikation unterbindet, sehrwohl als Proxy arbeitet. Ist das nicht so? Wenn das grundsätzlich nicht so ist bin ich doch mit Samba-RODCs allemal besser dran, auch wenn deren aktuelle Einschränkung (aktuelles Build mit Heimdal KDC und internem DNS backend) die ist, daß sie ohne Passwortreplikation für LDAP auth nicht funktionieren. Es geht mir dabei um die mit MS-Servern einhergehende Verschwendung von Ressourcen.

    Zu 5:
    Das heisst daß man zwei Möglichkeiten hat, 1. ein großes Loch in die Firewall zu bohren (konträr zur Lehre der Netzwerksicherkeit), oder 2. in jede Site minimum einen DC zu stellen und mit kleinen Löchern zu arbeiten. Ich glaube nicht, daß man meine Konfiguration durch 4. lauffähig bekommt.
    Freitag, 5. Juli 2019 12:19
  • Moin,

    zu 1. Nein, die Implikation aus meiner Sicht ist eine andere. Segmente unterschiedlicher Schutzstufe sollten nur Systeme beinhalten, die in unterschiedlichen sich nicht oder nur einseitig vertrauenden AD-Forests Mitglied sind.

    zu 3. das war vielleicht etwas ungenau. RODC leitet Authentifizierungsanfragen weiter für User, die noch kein Kennwort gecacht wurde oder vielleicht auch nicht gecacht werden soll. Aktionen jedoch, die Änderungen bewirken wie z.B. Kennwortänderung (auch für Computer-Accounts!) werden direkt mit einem RWDC durchgeführt. Auch Lese-Abfragen nach Attributen, die im FAS enthalten sind, müssen direkt gegen einen RWDC gehen.

    zu 5. doch, das bekommt man hin, aber wenn ich "Route" schreibe, meine ich vermutlich genau das, was Du mit "großes Loch" bezeichnest - halt den gesamten Satz an Ports und Protokollen, die man zwischen einem Member und einem DC braucht.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 5. Juli 2019 13:41
  • Moin Evgenij,

    Zu 1:

    Das ist eine konzeptionell interessante Variante, nicht nur aus sicherheitstechnischer Sicht, dürfte einige Probleme vom Tisch schaffen. Hab Dank, das werde ich mir anschauen.

    Zu 3:

    Ich sollte mir wohl mal meine saloppe Ausdrucksweise abgewöhnen. Mit "großem Loch" meine ich Port- und Protokollfreigaben für alle Member und DC zu den DCs im anderen Segment/Site, mit "kleinem Loch" gleiches aber ausschließlich für DCs. Das Netzwerkrouting meine ich ansich nicht, das setze ich funktionierend voraus. Du meinst mit Route die eigentliche Netzwerkroute und die entsprechenden Port- und Protokollfreigaben. Letztendlich kommt es aber auf's gleiche.

    Freitag, 5. Juli 2019 21:41