9
LDAPS und DNS Namen des DC
Hallo Zusammen,
ich habe eine Frage zu einem Gedanken den ich habe.
folgendes steht im Raum:
- Wir möchten ein neues Ticketsystem extern über LDAPS verbinden an unser AD.
- Unsere DC sind soweit konfiguriert für LDAPS.
- User für LDAPS im AD angelegt sowie die Gruppe wo die User reinkommen die nachher die Möglichkeit bekommen dich im Ticketsystem einzuloggen.
nun will der Ticketsystem Hersteller eine IP Address or public DNS for LDAPS gesendet bekommen allerdings haben ich sehr Bauchschmerzen damit den DNS Namen von unseren DC mitzuteilen nach außen.
1. gibt es eine Möglichkeit den DNS Namen zu verschleiern mit z.b einem ALIAS oder so ?
2. oder bin ich da generell zu sensibel eingestellte ?
Ziel: eine DNS Namen der DC´s mitzuteilen der nicht den Namen des Servers preis gibt !
Mit freundlichen Grüßen
Philipp Peter
ich habe eine Frage zu einem Gedanken den ich habe.
folgendes steht im Raum:
- Wir möchten ein neues Ticketsystem extern über LDAPS verbinden an unser AD.
- Unsere DC sind soweit konfiguriert für LDAPS.
- User für LDAPS im AD angelegt sowie die Gruppe wo die User reinkommen die nachher die Möglichkeit bekommen dich im Ticketsystem einzuloggen.
nun will der Ticketsystem Hersteller eine IP Address or public DNS for LDAPS gesendet bekommen allerdings haben ich sehr Bauchschmerzen damit den DNS Namen von unseren DC mitzuteilen nach außen.
1. gibt es eine Möglichkeit den DNS Namen zu verschleiern mit z.b einem ALIAS oder so ?
2. oder bin ich da generell zu sensibel eingestellte ?
Ziel: eine DNS Namen der DC´s mitzuteilen der nicht den Namen des Servers preis gibt !
Mit freundlichen Grüßen
Philipp Peter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72465850298
Url: https://administrator.de/contentid/72465850298
Ausgedruckt am: 14.11.2024 um 01:11 Uhr
9 Kommentare
Neuester Kommentar
Hmm, mein Beitrag wird nicht hilfreich sein.
Ja, man kann alternative Namen in Windows setzen via Powershell
Wie folgt:
(Quelle: https://www.tech-faq.net/alias-erstellen-in-windows-server-2019/)
Aber der Hersteller verlangt von dir (wenn ich das richtig verstehe), dass du LDAPs über ein Portforwarding freigibst??
Also da würde ich ganz klar verneinen und mir was anderes suchen. Auch wenn man das per VPN machen könnte, aber wenn ein Hersteller sowas schon fordert, wie ist es dann andersweitig mit der Sicherheit bestellt?
Aber dann musst du natürlich auch ein passendes Zertifikat mit dem alternativen Hostnamen haben (interne CA? oder Zertifikatsanforderung via OpenSSL)
Gruß
Max
Ja, man kann alternative Namen in Windows setzen via Powershell
Wie folgt:
netdom computername AKTUELLERHOSTNAME /add: ALIASHOSTNAMEAber der Hersteller verlangt von dir (wenn ich das richtig verstehe), dass du LDAPs über ein Portforwarding freigibst??
Also da würde ich ganz klar verneinen und mir was anderes suchen. Auch wenn man das per VPN machen könnte, aber wenn ein Hersteller sowas schon fordert, wie ist es dann andersweitig mit der Sicherheit bestellt?
Aber dann musst du natürlich auch ein passendes Zertifikat mit dem alternativen Hostnamen haben (interne CA? oder Zertifikatsanforderung via OpenSSL)
Gruß
Max
Danke PrieserMax für deine Antwort.
meines Wissens muss der Hersteller nur einen gültigen Public DNS oder IP bekommen und die Ansteuerung über den Port 636 LDAPs mit angeben.
mein Problem oder was ist mich frage ich es ein Sicherheitslücken wenn ich den DNS namen eines DNS Pubic setzte, in meine gefühl schon.
und da war halt meine Idee eine Alias im DNS auszu bauen wie LDAPs.meinedomain.com der dann auch die DC zeigt.
was ich mich da aber wieder frage kann dan von außen diesen Alisa auflösen und dann noch die Namen der DC sehen ?
meines Wissens muss der Hersteller nur einen gültigen Public DNS oder IP bekommen und die Ansteuerung über den Port 636 LDAPs mit angeben.
mein Problem oder was ist mich frage ich es ein Sicherheitslücken wenn ich den DNS namen eines DNS Pubic setzte, in meine gefühl schon.
und da war halt meine Idee eine Alias im DNS auszu bauen wie LDAPs.meinedomain.com der dann auch die DC zeigt.
was ich mich da aber wieder frage kann dan von außen diesen Alisa auflösen und dann noch die Namen der DC sehen ?
Moin,
Ich würde da maximal (wobei mir das auch schon zu Grenzwertig wäre, so ohne VPN) nen RODC bereitstellen, in einer DMZ. Besser aber via ReverseProxy.
Ausprobiert habe ich das nicht, daher nur mal laut gedacht:
Öffentlichen DNS-Record auf LDAPS.company.tld auf eure feste IP
Per portforwarding auf den ReverseProxy.
Müsstest dann mal schauen, ob du dem ReverseProxy ein Öffentliches Zertifikat mitgeben kannst.
Intern dann natürlich das internes der DCs
https://jackiechen.blog/2019/01/24/nginx-sample-config-of-http-and-ldaps ...
Edit: und den ReverseProxy darf auch nur die IP des Ticketservers ansprechen…
Ich würde da maximal (wobei mir das auch schon zu Grenzwertig wäre, so ohne VPN) nen RODC bereitstellen, in einer DMZ. Besser aber via ReverseProxy.
Ausprobiert habe ich das nicht, daher nur mal laut gedacht:
Öffentlichen DNS-Record auf LDAPS.company.tld auf eure feste IP
Per portforwarding auf den ReverseProxy.
Müsstest dann mal schauen, ob du dem ReverseProxy ein Öffentliches Zertifikat mitgeben kannst.
Intern dann natürlich das internes der DCs
https://jackiechen.blog/2019/01/24/nginx-sample-config-of-http-and-ldaps ...
Edit: und den ReverseProxy darf auch nur die IP des Ticketservers ansprechen…
Moin,
Daher sollte sowas immer mit Protokollen wie SAML oder oAuth realisiert werden. Dafür wurden diese ins Leben gerufen. Damit schlafen alle Beteiligten in der Nacht ruhig und wie ein kleines Baby.
Gruß,
Dani
allerdings haben ich sehr Bauchschmerzen damit den DNS Namen von unseren DC mitzuteilen nach außen.
Soll das eine Security Maßnahme sein? Damit hältst du dir maximal die Skript Kiddies vom Hals. Das war es aber es aber auch schon.oder bin ich da generell zu sensibel eingestellte ?
Nein, du bist von dem was du beschrieben hast, sehr naiv.Wir möchten ein neues Ticketsystem extern über LDAPS verbinden an unser AD.
Den Port würde ich nicht mal aufmachen, wenn das AD vollumfänglich gehärtet ist. Ein ungehärtetes AD ist beim ersten Klick schon ein DSGVO Verstoß.nen RODC bereitstellen, in einer DMZ.
Ein RODC löst keine Probleme. Es schafft noch weitere Probleme, weil die Firewall zwischen DMZ und LAN danach wie ein Schweizer Käse aussieht. Abhilfe würde eine Kommunikation zwischen RODC und WRDC schaffen mit Hilfe eines IPSec Tunnel auf Basis von Windows Server. Wie viele ITler kennst du, die sowas eingerichtet und entstören können?Besser aber via ReverseProxy.
Wenn du mit Reverse Proxy einen LDAP Proxy meinst, bin ich bei dir. Wobei das mein Plan C wäre. Weil auch der LDAP Proxy muss entsprechend konfiguriert werden. Im Idealfall werden nur Daten repliziert, welche unbedingt erforderlich sind. Alternativ alle Daten replizieren und mit Hilfe von ACLs auf dem LDAP Proxy reglementieren, was ausgelesen werden darf. Ist aber auch kein Selbstläufer...Auch wenn man das per VPN machen könnte
VPN, dein Ernst? Du möchtest ein Server oder Subnetz an dein lokales Netzwerk anbinden, wo du keinerlei Ahnung hast da vor sich geht. Im Worst Case kommen anderen Kunden auf den Servern des Anbieters per VPN an dein AD/DC. Das kannst du hinterher keinem Erklären.Daher sollte sowas immer mit Protokollen wie SAML oder oAuth realisiert werden. Dafür wurden diese ins Leben gerufen. Damit schlafen alle Beteiligten in der Nacht ruhig und wie ein kleines Baby.
Gruß,
Dani
1Zitat von @Dani:
Das stimmt wohl.nen RODC bereitstellen, in einer DMZ.
Ein RODC löst keine Probleme. Es schafft noch weitere Probleme, weil die Firewall zwischen DMZ und LAN danach wie ein Schweizer Käse aussieht.Besser aber via ReverseProxy.
Wenn du mit Reverse Proxy einen LDAP Proxy meinst, bin ich bei dir.Wobei das mein Plan C wäre. Weil auch der LDAP Proxy muss entsprechend konfiguriert werden. Im Idealfall werden nur Daten repliziert, welche unbedingt erforderlich sind. Alternativ alle Daten replizieren und mit Hilfe von ACLs auf dem LDAP Proxy reglementieren, was ausgelesen werden darf. Ist aber auch kein Selbstläufer...
Das stimmt wohl. Aber das ist es ja fast eh immer.Daher sollte sowas immer mit Protokollen wie SAML oder oAuth realisiert werden. Dafür wurden diese ins Leben gerufen.
Stimmt, die gibt es ja auch noch 
Damit schlafen alle Beteiligten in der Nacht ruhig und wie ein kleines Baby.
Oder haben Zeit für Freitagsfragen 
Moin,
Gruß,
Dani
Jau, den meine ich. Läuft ja mit nginx.
Nein, tun wir nicht. LDAP Proxy ungleich Reverse Proxy. Wo liegt der Sicherheitsgewinn bei einem Reverse Proxy, der erst einmal keine Sicherheitsfunktionen mitbringt und 1:1 die Verbindung durchreicht?Gruß,
Dani
Zitat von @Dani:
Auch wenn man das per VPN machen könnte
VPN, dein Ernst? Du möchtest ein Server oder Subnetz an dein lokales Netzwerk anbinden, wo du keinerlei Ahnung hast da vor sich geht. Im Worst Case kommen anderen Kunden auf den Servern des Anbieters per VPN an dein AD/DC. Das kannst du hinterher keinem Erklären.Ich würde es auch nicht so machen. Es ist aber eine Möglichkeit.
Daher sollte sowas immer mit Protokollen wie SAML oder oAuth realisiert werden. Dafür wurden diese ins Leben gerufen. Damit schlafen alle Beteiligten in der Nacht ruhig und wie ein kleines Baby.
Wir haben bei uns Azure AD Connect, dann würde ich das auch so machen.
Wobei ich dachte, dass man ja auch die User nur nach Azure syncen kann und Gruppen etc. ohne Lizenzen. Dann könnte man es natürlich trotzdem so machen.
Hatte das mal im Einsatz, aber jetzt nicht mehr. Kann auch sein, dass MS das geändert hat.
Tenant nur mit TXT ohne MX anlegen, vorher aber die recommended Reg-Keys wegen Outlook prüfen, falls ein On Prem Exchange im Einsatz ist. Geht ansonsten auch per GPO, hier bei Franky genaueres: https://www.frankysweb.de/outlook-autodiscover-fuer-office-365-deaktivie ...
Alternativ, mMn was man am ehesten mit den Gegebenheiten machen kann (ohne Azure / 365).
LDAP Proxy und diesen in einer DMZ via VPN bereitstellen -> Aber immer noch nicht perfekt.
Ich würde mir da andersweitig eine Software besorgen oder schauen, ob man deren Software On-Prem hosten kann.
Gruß
Max
Hallo Zusammen,
es hab hier nun mehrere Infos geschrieben danke dafür erstmal.
Wie versuchen halt gerade OTRS Ticketsystem einzuführen.
Das Problem ist bei OTRS das die da das Silber packet haben und nicht das Gold packet.
und nur im Gold packet ist SAML mit drin.
nun suche ich halt nach einer Sicheren Möglichkeit des zu gewährleiten das nur die User die in der Gruppe "OTRS_Users" drin sind sich an der Externen Applikation OTRS anmelden können.
mit ein wenig verzweifelt.
hab nun ein tag mich mit dem RODC auseinander gesetzt und nun hab ich das Gefühl das es nicht die Optimalste Sicherste Lösung ist.
Grüße
Philipp
es hab hier nun mehrere Infos geschrieben danke dafür erstmal.
Wie versuchen halt gerade OTRS Ticketsystem einzuführen.
Das Problem ist bei OTRS das die da das Silber packet haben und nicht das Gold packet.
und nur im Gold packet ist SAML mit drin.
nun suche ich halt nach einer Sicheren Möglichkeit des zu gewährleiten das nur die User die in der Gruppe "OTRS_Users" drin sind sich an der Externen Applikation OTRS anmelden können.
mit ein wenig verzweifelt.
hab nun ein tag mich mit dem RODC auseinander gesetzt und nun hab ich das Gefühl das es nicht die Optimalste Sicherste Lösung ist.
Grüße
Philipp
Moin,
hab nun ein tag mich mit dem RODC auseinander gesetzt und nun hab ich das Gefühl das es nicht die Optimalste Sicherste Lösung ist.
gut, dann sind wir wieder bei meinem ersten Kommentar. 
