6
Replikation des internen Win-AD (LDAP) auf externen Debian möglich?
Hallo,
vielleicht kann mir jemand mit einem Hinweis auf die generelle Vorgehensweise helfen:
Ein im Unternehmens-Intranet laufender Dienst (auf einem Debian-Host) soll auf einen externen (und somit von überall erreichbaren) Server verlagert werden. Dieser Dienst benutzt zur Nutzer-Authentifikation das AD unserer Windows-Server. Dies soll auch nach der Auslagerung noch möglich sein. Idealerweise pusht der Windows-Server die AD-Daten nach außen, so dass nicht von außen nach innen gepullt werden musss. Der Dienst authentifiziert dann gegen die lokal vorhanden, replizierten AD-Daten.
Die Anforderung: Damit der externe Dienst möglichst entkoppelt und autark arbeitet, sollen die Daten des AD nur 1-2 mal pro Woche nach außen repliziert werden (kann auch täglich sein). Hierbei ist problemlos vertretbar, dass dann die Authentifikation nur entsprechend verzögert aktuell ist. Der Dienst greift nur "read only" auf das AD zu, ein Rückkanal ist also nicht erforderlich.
KEINE Option ist hierbei, einen Kanal/VPN/etc. in das Intranet zu etablieren, auch wenn dies natürlich einfacher und naheliegend ist. Genau dies soll aber mit einer Entkopplung vermieden werden.
Vermutlich muss auf dem Debian ein Samba installiert werden. Es geht also darum, wie unser Windows-AD seine Verzeichnisdaten regelmäßig an diesen externen Samba repliziert bekommt und was hierbei zu beachten ist. Könnte mir jemand skizziere, wie eine solche Push-Replikation funktionieren könnte? Für Hinweise bin ich enorm dankbar. (ach ja - und wenn einer ganz genau weiß wie es laufen muss und beim Aufsetzen sogar mithelfen möchte, dann bezahlen wir auch gerne dafür)
Tom
vielleicht kann mir jemand mit einem Hinweis auf die generelle Vorgehensweise helfen:
Ein im Unternehmens-Intranet laufender Dienst (auf einem Debian-Host) soll auf einen externen (und somit von überall erreichbaren) Server verlagert werden. Dieser Dienst benutzt zur Nutzer-Authentifikation das AD unserer Windows-Server. Dies soll auch nach der Auslagerung noch möglich sein. Idealerweise pusht der Windows-Server die AD-Daten nach außen, so dass nicht von außen nach innen gepullt werden musss. Der Dienst authentifiziert dann gegen die lokal vorhanden, replizierten AD-Daten.
Die Anforderung: Damit der externe Dienst möglichst entkoppelt und autark arbeitet, sollen die Daten des AD nur 1-2 mal pro Woche nach außen repliziert werden (kann auch täglich sein). Hierbei ist problemlos vertretbar, dass dann die Authentifikation nur entsprechend verzögert aktuell ist. Der Dienst greift nur "read only" auf das AD zu, ein Rückkanal ist also nicht erforderlich.
KEINE Option ist hierbei, einen Kanal/VPN/etc. in das Intranet zu etablieren, auch wenn dies natürlich einfacher und naheliegend ist. Genau dies soll aber mit einer Entkopplung vermieden werden.
Vermutlich muss auf dem Debian ein Samba installiert werden. Es geht also darum, wie unser Windows-AD seine Verzeichnisdaten regelmäßig an diesen externen Samba repliziert bekommt und was hierbei zu beachten ist. Könnte mir jemand skizziere, wie eine solche Push-Replikation funktionieren könnte? Für Hinweise bin ich enorm dankbar. (ach ja - und wenn einer ganz genau weiß wie es laufen muss und beim Aufsetzen sogar mithelfen möchte, dann bezahlen wir auch gerne dafür)
Tom
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: 1284365093
Url: https://administrator.de/contentid/1284365093
Printed on: April 19, 2024 at 15:04 o'clock
6 Comments
Latest comment
Moin,
Gruß,
Dani
Dieser Dienst benutzt zur Nutzer-Authentifikation das AD unserer Windows-Server. Dies soll auch nach der Auslagerung noch möglich sein. Idealerweise pusht der Windows-Server die AD-Daten nach außen, so dass nicht von außen nach innen gepullt werden musss.
- Wie sind deine Planungen hinsichtlich der Absicherung des Servers mit den Daten aus dem Active Directory? Denn es hilft nichts, wenn Daten nur One-Way repliziert werden. Wenn die Daten dann von potenziellen Angreifer abgegriffen werden können. Meistens resultieren daraus erst recht gezielte Angriffe.
- Was machst du mit den Fällen, bei denen bei der Authentifizierung das Passwort ändern muss, weil es abgelaufen ist?
Idealerweise pusht der Windows-Server die AD-Daten nach außen, so dass nicht von außen nach innen gepullt werden musss. Der Dienst authentifiziert dann gegen die lokal vorhanden, replizierten AD-Daten.
- Du keine Details und genaue Anforderungen genannst hast, werfe ich einmal RODC (Read Only Domain Controller) ins Rennen. Die Vor- und Nachteile sind dir sicherlich bekannt. Macht grundsätzlich genau das, was du möchtest. Allerdings wird dir jeder IT Security Engineer/Architect davon abraten.
- Evtl. könnte auch ein AD LDS der richtige Ansatz sein. Details dazu kannst du inital hier nachlesen. Allerdings sollte man bei dieser Idee genau wissen was man tut.
- Last but least, nutzt man für solche Szenarieren heute Authentifizierungsverfahren via oAuth oder SAML2. Somit werden keiner Doppelstrukturen aufgebaut. Die (sensiblen) daten bleiben sicher auf dem Domain Controller gespeichert und mögliche Brut-Force Attaken wird ein Riegel vorgeschrieben ohne dass es für das gesicherte Netzwerk eine Beeinträchtigung gibt.
Gruß,
Dani
Moin,
Was ist denn die Basis des Intranets? Typo3 z. B. bietet dafür ein Modul an, mit dem man ein Teilreplikat des LDAPs direkt in die Anwendung einlesen kann. Frage mich bitte nicht nach genaueren Informationen. An der Stelle bediene ich das nur. Man kann ja nicht alles können.
Liebe Grüße
Erik
Zitat von @Tom3578:
Ein im Unternehmens-Intranet laufender Dienst (auf einem Debian-Host) soll auf einen externen (und somit von überall erreichbaren) Server verlagert werden.
Ein im Unternehmens-Intranet laufender Dienst (auf einem Debian-Host) soll auf einen externen (und somit von überall erreichbaren) Server verlagert werden.
Was ist denn die Basis des Intranets? Typo3 z. B. bietet dafür ein Modul an, mit dem man ein Teilreplikat des LDAPs direkt in die Anwendung einlesen kann. Frage mich bitte nicht nach genaueren Informationen. An der Stelle bediene ich das nur. Man kann ja nicht alles können.
Liebe Grüße
Erik
Erstmal vielen Dank für eure Hinweise 
@Dani: ja, RODC geht in die richtige Richtung, das werde ich hier mal in die Runde einbringen. (von AD LDS haben wir keinen Plan, also dann eher nicht). Unser Problem mit oAuth oder SAML2 ist, dass die Dinger halt auch immer verfügbar sein müssen. Wir hatten das früher mal mit nem extern gehosteten Exchange, der sich am internen AD authentifizieren musste. Theoretisch lief es, in der Praxis gab es fast jeden Monat irgend einen Ausfall wegen Router oder sonstwas und meistens natürlich genau dann, wenn der Postfachzugriff dringend war. Aus dieser Erfahrung heraus halte ich "persistente" Kanäle von außen nach innen für bedenklich.
@erikro: Intranet ist halt einfach nur unser Windows AD mit gemeinsamen Verzeichnissen/Laufwerken und Druckern etc. Und natürlich ein Haufen interer Entwicklungs-Server, die auf unserem ESXi liegen. Ein Intronet-Portal oder sowas ist nicht im EInsatz.
@Dani: ja, RODC geht in die richtige Richtung, das werde ich hier mal in die Runde einbringen. (von AD LDS haben wir keinen Plan, also dann eher nicht). Unser Problem mit oAuth oder SAML2 ist, dass die Dinger halt auch immer verfügbar sein müssen. Wir hatten das früher mal mit nem extern gehosteten Exchange, der sich am internen AD authentifizieren musste. Theoretisch lief es, in der Praxis gab es fast jeden Monat irgend einen Ausfall wegen Router oder sonstwas und meistens natürlich genau dann, wenn der Postfachzugriff dringend war. Aus dieser Erfahrung heraus halte ich "persistente" Kanäle von außen nach innen für bedenklich.
@erikro: Intranet ist halt einfach nur unser Windows AD mit gemeinsamen Verzeichnissen/Laufwerken und Druckern etc. Und natürlich ein Haufen interer Entwicklungs-Server, die auf unserem ESXi liegen. Ein Intronet-Portal oder sowas ist nicht im EInsatz.
Moin,
Aha. Ich dachte halt an irgendwas webbasiertes. Was ist das denn für ein "Dienst", der da zur Verfügung gestellt werden soll? So spontan fällt mir da RDP via RDP-Gateway ein. RDP gibt es ja auch für Linux-Server (xRDP). Ob das allerdings so wie unter Windows auch via Gateway und https geht, entzieht sich meiner Kenntnis.
Ein weiterer Ansatz wäre ssh.
Beide hätten den Vorteil, dass Du den Debian-Host in eine DMZ packen kannst, so dass er weiterhin den DC direkt fragen kann, ob Username und Passwort stimmen. Wie die Kollegen schon sagten: Diese Informationen ins Netz zu kopieren, ist keine gute Idee.
Liebe Grüße
Erik
Zitat von @Tom3578:
@erikro: Intranet ist halt einfach nur unser Windows AD mit gemeinsamen Verzeichnissen/Laufwerken und Druckern etc. Und natürlich ein Haufen interer Entwicklungs-Server, die auf unserem ESXi liegen. Ein Intronet-Portal oder sowas ist nicht im EInsatz.
Aha. Ich dachte halt an irgendwas webbasiertes. Was ist das denn für ein "Dienst", der da zur Verfügung gestellt werden soll? So spontan fällt mir da RDP via RDP-Gateway ein. RDP gibt es ja auch für Linux-Server (xRDP). Ob das allerdings so wie unter Windows auch via Gateway und https geht, entzieht sich meiner Kenntnis.
Ein weiterer Ansatz wäre ssh.
Beide hätten den Vorteil, dass Du den Debian-Host in eine DMZ packen kannst, so dass er weiterhin den DC direkt fragen kann, ob Username und Passwort stimmen. Wie die Kollegen schon sagten: Diese Informationen ins Netz zu kopieren, ist keine gute Idee.
Liebe Grüße
Erik
@Tom3578
DNS und AD am RODC in DMZ
https://adsecurity.org/?p=3592
https://social.technet.microsoft.com/Forums/ie/en-US/199ecd2c-7f5d-438e- ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/co ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Kurz um: Das Loch, dass du da bohrst hat nicht nur ein Durchmesser von 3-4mm, sondern 5-10cm. Das ist aus Sicht der IT-Sicherheit nicht unerheblich und diese Konstellation zu warten und zu sichern, ist nicht ganz einfach. Da müssen die verantwortlichen ITler genau wissen, was Sie tun. Sonst könnte das nächste Projekt ein neue Systemlandschaft sein.
Gruß,
Dani
RODC geht in die richtige Richtung, das werde ich hier mal in die Runde einbringen.
(von AD LDS haben wir keinen Plan, also dann eher nicht)
Dazu ein bisschen Lesestoff, was Mann/Frau zu dem Thema berücksichtigen soll/muss:(von AD LDS haben wir keinen Plan, also dann eher nicht)
DNS und AD am RODC in DMZ
https://adsecurity.org/?p=3592
https://social.technet.microsoft.com/Forums/ie/en-US/199ecd2c-7f5d-438e- ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/co ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Kurz um: Das Loch, dass du da bohrst hat nicht nur ein Durchmesser von 3-4mm, sondern 5-10cm. Das ist aus Sicht der IT-Sicherheit nicht unerheblich und diese Konstellation zu warten und zu sichern, ist nicht ganz einfach. Da müssen die verantwortlichen ITler genau wissen, was Sie tun. Sonst könnte das nächste Projekt ein neue Systemlandschaft sein.
Aus dieser Erfahrung heraus halte ich "persistente" Kanäle von außen nach innen für bedenklich.
Worin liegt der Unterschied zu dem Szenario RODC zu SAML2/oAuth? Ist der RODC offline stehst du vor dem gleichen Problem, eine Anmeldung ist nicht möglich.Gruß,
Dani
Moin,
Das würde ich nicht machen. Ich würde das Ganze in etwa so aufbauen:
Auf einen RODC werden alle Daten des AD repliziert. Wie schon erwähnt, ist das aber keine gute Idee, solche Daten über das Internet zugänglich zu machen. Der Debian braucht ja auch nur ein Teilreplikat, nämlich die Daten zur Authentifizierung. Eigentlich reichen sAMAcountName und Passwort. Sensibel genug, das nochmal extra zu schützen, bevor der Zugriff durch den Debian erfolgt. Der steht ja schließlich zwar auch hinter einer Firewall aber dennoch im Internet.
hth
Erik
Zitat von @Dani:
@Tom3578
@Tom3578
RODC geht in die richtige Richtung, das werde ich hier mal in die Runde einbringen.
Das würde ich nicht machen. Ich würde das Ganze in etwa so aufbauen:
Firmennetz --- DC --- FW --- LDAP-Server(Teilreplikat) --- FW --- Debian --- FW --- InternetAuf einen RODC werden alle Daten des AD repliziert. Wie schon erwähnt, ist das aber keine gute Idee, solche Daten über das Internet zugänglich zu machen. Der Debian braucht ja auch nur ein Teilreplikat, nämlich die Daten zur Authentifizierung. Eigentlich reichen sAMAcountName und Passwort. Sensibel genug, das nochmal extra zu schützen, bevor der Zugriff durch den Debian erfolgt. Der steht ja schließlich zwar auch hinter einer Firewall aber dennoch im Internet.
hth
Erik
