glady2000
Goto Top

AD in DMZ, Security

Hallo Admin's,

wir möchten von lokalen Administrator bzw. Root Benutzern wegkommen. Für die Anmeldung am OS der verschiedenen DMZ-Systeme wie z.B. Proxy, Webserver, SMTP, Reverseproxy, usw.
ADFS geht nicht, weil es für Webanmeldungen gedacht ist und nicht die Anmeldung am OS.

Microsoft empfahl früher einmal RODC für die DMZ. Wurde aber zwischenzeitlich revidiert aus u.a. folgenden Gründen:
"Wenn sich jemand auf den Webserver einnisten kann, dann kommt er auch auf den RODC und könnte dort die Benutzerdaten anderer User evtl. erforschen. Komplettes AD mit Ausnahme der Passwörter wird repliziert. Evtl. muss man nicht das ganze AD dort spiegeln sondern kann einzelne Gruppen oder Benutzer."

Von Microsoft habe ich folgende Empfehlung gefunden, die zwar auch älter ist -aber ich habe keine aktuellere Empfehlung finden können.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...

Das Forest-Trust-Model könnte man mit einem One-Way Trust anlegen.

Welche Vorteile hätte man tatsächlich gegenüber einer Lösung mit RODC? Und welche Risiken würden bei dieser Lösung bestehen?

Vielen Dank schon einmal!

Grüße, Glady

Content-Key: 480353

Url: https://administrator.de/contentid/480353

Ausgedruckt am: 29.03.2024 um 02:03 Uhr

Mitglied: sabines
sabines 01.08.2019 aktualisiert um 09:41:08 Uhr
Goto Top
Moin,

wie wäre es mit einer Begrüßung und ggfs. mal den Text vor dem Absenden durchlesen und die Satzstellung anpassen.

Wenn ich Dich richtig verstehe, willst Du die lokalen User entfernen und durch AD User ersetzen, richtig?
Das macht man für den Zweck der Administration nicht (mehr), eine Trennung ist sicherer.
Hat jemand erst einmal Zugriff auf DMZ Devices kann er damit gleich weiter ins AD.

Wohlgemerkt, das gilt nur für Administration, die normalen User für Spam Queue o.ä. werden mit LDAP angebunden.
Du könntest allenfalls bestimmte User im AD zusätzlich abbilden nur für den Zweck der DMZ Administration, aber auch hier gilt, hat jemand Zugriff auf das AD erlangt, kommt er damit auch in die DMZ.

Gruss
Mitglied: it-fraggle
it-fraggle 01.08.2019 um 10:45:01 Uhr
Goto Top
Wir sind aktuell beim gleichen Thema. Würden gerne ein AD einrichten, aber unsere Netzwerksicherheitsrichtlinien geben das nicht her. Es ist ausschließlich Netzwerkverkehr von einem "sicheren" zu einem unsicheren Netzwerk erlaubt. Arbeiten gerade mit Univention an einer Lösung, die rein per Push vom Master aus funktioniert. Vielleicht wäre das auch was für euch?
Mitglied: Dani
Dani 01.08.2019 aktualisiert um 12:30:00 Uhr
Goto Top
Moin,
ADFS geht nicht, weil es für Webanmeldungen gedacht ist und nicht die Anmeldung am OS.
So ist es.

wir möchten von lokalen Administrator bzw. Root Benutzern wegkommen. Für die Anmeldung am OS der verschiedenen DMZ-Systeme wie z.B. Proxy, Webserver, SMTP, Reverseproxy, usw.
Einen wird es immer geben. Die Zugangskennung pro System ist einem Umschlag im Tresor, wo einer alleine nicht rankommt. Denn der Account kann bei Recovery oder Problemem it der zentralen Authentifizierung lebensnotwendig werden.

"Wenn sich jemand auf den Webserver einnisten kann, dann kommt er auch auf den RODC und könnte dort die Benutzerdaten anderer User evtl. erforschen. Komplettes AD mit Ausnahme der Passwörter wird repliziert.
Nicht nur das... muss/soll ein Benutzer sein Passwort ändern, erfolgt dies nicht über RODC. Dafür wird die Anfrage an einem WRDC weitergeleitet. D.h. eine Kommunikation dorthin muss auf jeden Fall gewährleistet sein. Unabhängig davon, was gewinnst du?
Zudem sollte die Verbindungen zwischen RODC und WRDC immer mit IPSec Tunnel verschlüsselt werden. Anderenfalls bohrst du riesige Löcher in die Firewall. Stichwort ist WinRPC und dessn dym. Portrange. Der Aufbau mit Zertifikaten und dazugehörigen Windows-Firewallregeln ist nicht ohne und da muss man genau wissen, was man konfiguriert. Im Worst Case ist nämlich der WRDC im LAN auch nicht mehr erreichbar.

Evtl. muss man nicht das ganze AD dort spiegeln sondern kann einzelne Gruppen oder Benutzer."
Wie soll das Spiegel von Benutzern und Gruppen erfolgen? Bis kann ein Domain Controller "nur" die vollständige Datenbank replizieren. Eine Synchronisation zwischen AD und LDS ist möglich, aber die Passwörter bleiben außen vor.

Für die Anmeldung am OS der verschiedenen DMZ-Systeme wie z.B. Proxy, Webserver, SMTP, Reverseproxy, usw
Wie groß ist denn eure DMZ? Ich frage deshalb, weil ich vermute dass der Aufwand in keinem Verhältnis zum Ergebnis steht.
Unabhängig davon warum nicht ein LDAP (z.B. OpenLDAP) in der DMZ aufbauen und dort die Benutzer und Gruppen entsprechend verhalten? Somit hat du weiterhin eine saubere Trennung der Zonen und grundsätzlich eine volle Unabhängigkeit. Wenn du noch das i-Tüpfelchen haben möchtest, setzt du auf sogenannte PAWs welche mit 2FA abgesichert sind. face-smile


Gruß,
Dani
Mitglied: glady2000
glady2000 01.08.2019 aktualisiert um 13:25:15 Uhr
Goto Top
@sabines
Ich hoffe, es ist jetzt besser face-smile

@it-fraggle
Danke schon mal für die Info.Was genau soll gepusht werden?
Beim Forest-Trust-Model würde man "nur" die Ports für das einseitige Trust zwischen den DC's in der DMZ (in einem separaten Firewall VLAN) und den DC's im sicheren Bereich (die auch in einem separaten Firewall VLAN separiert sind) freigeben.
Was beinhaltet die Lösung von Univention? Ist das das Forest-Trust-Model wo nur der Master Richtung DMZ Sessions initiiert (also Portfreigabe nur in Richtung DMZ)? Soll das über SSH Port Forwarding geschehen?
Oder liege ich gerade völlig daneben?

@Dani
Danke für deine ausführlichen Erläuterungen!
"Unabhängig davon warum nicht ein LDAP (z.B. OpenLDAP) in der DMZ aufbauen und dort die Benutzer und Gruppen entsprechend verhalten? Somit hat du weiterhin eine saubere Trennung der Zonen und grundsätzlich eine volle Unabhängigkeit."

Wie würde das funktionieren, dass man nicht die Benutzer doppelt pflegen muss? Ich bin kein AD Experte -sorry wenn ich blöde Fragen stellen sollte.
Wir haben so grob geschätzt 200 Systeme in der DMZ. DMZ ist zusätzlich durch VLANs und Firewalls separiert.
Mitglied: Dani
Dani 01.08.2019 um 13:39:20 Uhr
Goto Top
Moin,
Wie würde das funktionieren, dass man nicht die Benutzer doppelt pflegen muss? Ich bin kein AD Experte -sorry wenn ich blöde Fragen stellen sollte.
gar nicht. Es ist eine doppelte Pflege - keine Frage. Aber bei 200 Systemen lohnt es sich auch. Setzt euch mal hin und überlegt euch Vor-/Nachteile und die möglichen Risiken bzw. Angriffsvektoren der verschiedenen Architkturen. In der Größe habt ihr doch sicher für Netzwerk/Sicherheit/Active Directory entsprechende Spezialisten/Teams. Wenn da jeder eine Argumente hervorbringt, wird es bei einer zusätzlichen Benutzerverwaltung bleiben - so war's bei uns. face-smile

Wir haben so grob geschätzt 200 Systeme in der DMZ. DMZ ist zusätzlich durch VLANs und Firewalls separiert.
Hübsch, wahrscheinlich eine Microsegmentierung. Umso größer werden die Löcher in der Firewall zwischen den beiden Sicherheitszonen DMZ und LAN.

Das Forest-Trust-Model könnte man mit einem One-Way Trust anlegen.
Den Artikel kennst du: Not A Security Boundary: Breaking Forest Trusts


Gruß,
Dani
Mitglied: it-fraggle
it-fraggle 01.08.2019 aktualisiert um 14:04:39 Uhr
Goto Top
Sorry, bin davon ausgegangen, dass dir UCS etwas sagt. Das bietet die Möglichkeit Samba4 als Domänencontroller einzusetzen. Es können ein Master, Backup-AD und Slaves aufgesetzt werden. Die Slaves sind vergleichbar mit dem RODC. Alles läuft über LDAP. Hier sind wir aktuell mit Univention im Gespräch, dass der Master alles Notwendige NUR "pusht". Quasi Master für das "sichere" Netzwerk, "Sub"-Master für die DMZ beispielsweise und Slave in den Filialen. Stecken noch in den Anfängen. Nächste Woche gibt es dazu einen Workshop mit denen, um herauszufinden wie man das am besten hier umsetzt. Ich könnte mir denken, dass das für dich auch nicht ganz uninteressant ist.
Mitglied: glady2000
glady2000 01.08.2019 um 14:13:10 Uhr
Goto Top
Danke für die Infos mit UCS! Werde ich an die Kollegen weitergeben.

Dani, den Link hatte ich überflogen und so verstanden, dass das nur einen beidseitigen Trust gilt. ist das nicht so?
Mitglied: Dani
Dani 01.08.2019 um 20:30:35 Uhr
Goto Top
Moin,
Dani, den Link hatte ich überflogen und so verstanden, dass das nur einen beidseitigen Trust gilt. ist das nicht so?
einfach den Beitrag lesen, verstehen und vermutlich ist deine Frage dann beanwortet. face-wink

Danke für die Infos mit UCS! Werde ich an die Kollegen weitergeben.
Denk daran, dass mit dem Ansatz von it-fraggle ebenfalls doppelte Strukuren aufgebaut werden. Denn auch UCS kann das Standardverhalten eines Microsoft AD DS nicht ändern.


Gruß,
Dani