Alle verwenden einen LDAP-Server, wir auch, allerdings über die PaedML. Da ich das rumgefummel in den Configs umständlich finde, wollte ich eine LDAPS-Lösung ohne das selbstsignierte Zertifikat der PaedML zu entfernen. Also einen Proxy, der Anfragen an LDAPS an das selbstsignierte LDAPS weiterreicht. Das kann man per nginx machen. Wusste ich bis gestern auch nicht, aber es ist relativ einfach, zumal man auch Let’s Encrypt Zertifikate dafür nutzen kann. Ich habe mir eine CNAME-Domain auf meinen nginx gerichtet, dort eine Server-Config angelegt und mit dem certbot ein Zertifikat inklusive regelmäßiger Erneuerung eingerichtet. Dann die Server-Config gelöscht (wahrscheinlich geht das auch einfacher…) und in die nginx.conf folgenden Eintrag gemacht:
stream {
server {
# Endpunkt für Port 663 mit SSL
listen 636 ssl;
# Hole Daten vom Backend
proxy_pass 1.2.3.4:7636;
# Das Backend spricht auch SSL
proxy_ssl on;
# Verwende das mit LE erstellte Zertifikat
ssl_certificate /etc/letsencrypt/live/ldap.frontend.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ldap.frontend.de/privkey.pem;
}
}
Was hier nicht zu sehen ist, ich habe das selbstsignierte CA-Root Zertifikat auf dem Server installiert, ansonsten müsste man in dem Block noch den Check daktivieren, aber das ist nicht so gut.
jaaaa, danke, genau das habe ich gebraucht, um den Untis-Login mit dem ldaps zu verbinden! Mit unserer internen .lan-Domäne habe ich natürlich kein externes Zertifikat bekommen, aber ich habe sowieso noch einen Webserver mit nginx laufen, auf dem habe ich deine Einstellungen in der conf-Datei vorgenommen, einfach mit den sowieso schon bestehenden Zertifikaten des Webservers und Webuntis hat die ldap-Verbindung hergestellt!
Super, vielen Dank!
ich will das auch haben Blicke aber noch nciht durch.
Ich habe also einen Webserver auf dem nginx läuft.
Und der hat auch ein LE Cert.
Und jetzt geb ich dem nginx eine weitere Site, die aber nur Anfragen auf Port 636 annimmt und im Hintergrund weiterleitet an den LDAP der lmn7.
Ich blick die Config aber noch nicht.
Ist hier die IP meines lmn7 Servers ein zu tragen?
Warum Port 7636? da lauscht doch mein LDAP gar nicht. Und die OPNsense läßt das nicht durch …
Und zum CA auf der lmn installieren: welche Datei nehme ich da? Wie „installiere“ ich das auf der lmn7?
Einfach die richtige Datei ins richtige Verzeichnis legen (mit den richtigen Rechten)?
bezieht sich tatsächlich auf die IP des LDAP-Servers, der wahrschenlich eine andere IP als diese hat. 7636 ist der Port, der bei mir eingestellt ist. Die PaedML verwendet aus welchen Gründen auch immer diesen Port für sichere Verbindungen. Du kannst, wenn Du die Default-Ports verwendest `proxy_pass 1.2.3.4:636; einsetzen.
CA auf der lmn könnte ein selbstsigniertes Zertifikat sein. Hast Du das vielleicht schon installiert? Oder läuft ldap grundsätzlich unverschlüsselt auf lmn? Wenn ja, könntest Du auch, wenn nginx und lmn im gleichen Netz liegen auf den unverschlüsselten Port weiterleiten. Dann wäre zumindest die Kommunikation nach draußen verschlüsselt. Quer durchs Netz würde ich aber nur von verschlüsselt zu verschlüsselt die Daten leiten. Das selbstsignierte Zertifikat des LDAP-Servers musste ich nicht einrichten, das ist schon so im ausgelieferten Zustand dabeigewesen. Da gibt es aber wahrscheinlich Dokus im Netz zu.
Die lmn7 läuft schon länger.
Ich war vorhin falsch gewickelt.
Der LDAP ist schon verschlüsselt: eben mit einem selbstsignierten Cert (passiert beim setup der lmn7).
Ich muss also andersrum: ich muss die CA der lmn7 auf dem Server, auf dem der nginx läuft, importieren.
Wie mache ich das?
der LDAP der lmn7 nimmt natürlich nur verschlüsselte Verbindungen an.
brauchst Du nicht importieren. Der nginx hat das gute Zertifikat von LE, damit werden die Verbindungen externer Clients hergestellt. Der Client sieht das Zertifikat von LE und denkt, alles ok. Der Nginx-Server reicht die Anfrage an lmn7 weiter und ignoriert das selbsterstellte Zertifikat, weil es das ja kennt. Soweit so gut. Alternativ kannst Du natürlich das Zertifikat auf dem nginx-Server importieren: How to install CA certificates in Ubuntu server - TechRepublic
Vielen Dank, @hmt für dieses Juwel.
Du hast mir grade (gefühlt) ein Haufen Arbeit erspart!
Um es für andere noch einfacher zu machen: Die obige Konfiguration trägt man bei einer ubuntu/debian basierten nginx-Installation in /etc/nginx/nginx.conf… ein, dann hat man einen rProxy out-of-the-box.
Alternative Empfehlung (nicht in /etc/nginx/nginx.conf eintragen, sondern…)
wenn ich jetzt, wie Tobias, das als modul einfüge, dann brauche ich noch das cert für meindomain.dynalias.org
richtig?
Dann muss ich ja nur das dehydrated bitten, auch noch ein LE Cert für meindomain.dynalias.org
zu besorgen und das trage ich dann in die conf für das Modul ldaps-proxy ein.
Sehe ich das richtig?
ich verstehe nicht so ganz das drumherum, aber wenn der nginx auf dem Host läuft, dann ist ja relativ egal, wie die Zertifikate generiert werden, hauptsache Du trägst den richtigen Pfad beim Proxy ein. Am besten einfach mal ausprobieren. Wenn dann Fehler auftreten, können wir an einem konkreten Problem weiterarbeiten.
an sich ist das, wie hmt schon gesagt hat, ganz egal. Du kannst natürlich nochmal ein neues Zertifikat ordern, oder bereits ein bestehendes nehmen. In der Auth-Konfiguration der externen Server (Moodle, Webuntis) trägst du in der URI z.B. ldaps://wiki.meindomain.dynalias.org ein und hinterlegts in der stream-Sektion der nginx-Konfiguration, sei es in der nginx.conf oder im Modul, eben auch das Zertifikat von wiki.meindomain.dynalias.org. Die NAT Regel für eingehend WAN Port 636 TCP auf deiner FW muss ja auch auf den reverseProxy zeigen und der antwortet dann auf die LDAPS-Anfragen mit dem wiki.meindomain.dynalias.org Zertifikat. Wichtig ist hier nur das URI und Zertifikat zusammen passen.
ich habs auf der pfsense laufen. sollte keinen großen unterschied machen:
ein signiertes zertikat sollte auf der firewall bereits vorhanden sein.
Bei system-> certificates sollte dann das Zertifikat da sein (ggf. auch passende RootCA Zertifikat hochladen, bzw. da müsst ja dann ein LE Zertifikat sein, wenn man das nutzt)
backend:
ldap_back
serveradresse + Port eingeben (389 oder 636, encrypt ssl falls port 636 intern genutzt wird)
HealthCheck method LDAP
(im screenshot hat mein backend 2 server weil ich ssl und ohne ssl als Verbindungen drin habe. eine Verbindung reicht hier aus)
Frontend:
0.0.0.0:636
ssl offloading
bei ssl offloading das signierte zertitifikat auswählen
type: tcp
default backend: name des backends auswählen (ldap_back)
Hallo sucher,
danke erstmal für den Tipp, dass es genau so geht, wie für webseiten auch…
Auch, wenn ichs noch nicht hinbekommen habe.
Health-Check method kann ich nicht wählen, ist wahrscheinlich aber nicht funktionsrelevant, oder?
Warum ist die frontend-Adresse 0.0.0.0, wie findet er da den LMN-Server?
ssl offloading finde ich nirgends… ich kann aber eine regel setzen, dass bei dem und dem FQDN dieses und jenes Zertifikat gesendet wird.
Ich erstelle einen Pool-Frontend „ldap-server“ mit dem LMN-Server 10.16.1.1, (nicht 0.0.0.0, geht aber auch nicht) drinnen.
Im Backend „ldap-proxy“ habe ich den lmn-server ausgewählt, Port 636 gesetzt und als Modus „HTTP Layer 7 [standard]“ ausgewählt gelassen.
Ich erstelle eine Bedingung: FQDN entspricht „server…“
Ich mache eine Regel: wenn obiges zutrifft, nutze das backend ldap-proxy.
Das ist bei allen anderen Web-Anwendungen so und klappt da super, ist aber halt https und nicht ldaps.
Wenn ich innerhalb des Schulnetztes ldapsearch -H „ldaps//server.lmn.eichendorff-gymnasium.de“ mit Credentials des Bind-User angebe, klappt es, nur von außerhalb nicht. Komisch.
Hallo!
Nachtrag: Brauche ich noch Firewallregeln?
Ich habe sowas für meinen apt-cacher eingerichtet, mit allem wie oben. Das funktioniert. ABER: Tatsächlich habe ich auch eine Portweiterleitung von meinem Apt-Cacher-Port auf der Firewall zum apt-cacher in meinem Netz. Deaktiviere ich die, gehts nimmer, also der HA_Proxy scheint auch da nicht zu funktionieren. DH, immer, wenn der Port nicht 443 ist, macht der HA nicht was er soll…
LG
Max
also frontend sind die Adressen auf der der proxy lauscht.
wenn du ldaps von allen ipadressen erreichbar machen willst muss da dann 0.0.0.0:636 rein. dann nimmt der proxy von überall Verbindungen an. also statt 0.0.0.0 kann da auch „any“ rein oder ähnliches. wenn du die ip des externen moodle kennst, könnte man die auch hier eintragen. aber was von aussen erlaubt ist oder nicht, würde ich eher über firewall regeln regeln.
nur im backend trägst du den lmn server ein. wenn du über port 636 auf den laps des lmn server gehst muss da natürlich eingestellt sein, dass das Zertifikat nicht verifiziert sein muss
im backend darfst du nicht den http layer7 auswählen; das ist zuviel des guten. richtig ist Mode tcp (layer4). Damit funktioniert dann ldaps und das ist der Hauptunterschied zur Verwendungen mit https Verbindungen. Der Mode http layer 7 ist nur Webapplikationen vorbehalten die per https port 443 erreichbar sind.
natürlich muss in der firewall dann noch der port 636 freigeschalten werden mit ziel „this firewall“
von aussen greifst du mit ldaps nicht direkt auf lmn zu, sondern auf die firewall, die die anfrage dann an den lmn weiterleitet.
auch muss eine firewall Regel den zugriff vom lmn server auf die firewall via port 636 bzw 389 erlauben.
sprich eine firewall Regel auf der Netzwerkkarte nach aussen
von * auf this firewall mit port 636 zugriff erlauben
und eine firewall regeln auf der Netzwerkkarte mit Verbindung zum lmn server
von * auf this firewall mit port 636 zugriff erlauben
mit dem Befehl
openssl s_client -connect meinefirewalldomain.de:636 -showcerts
kannst du dann überprüfen ob nun das korrekte Zertifikat hinterlegt ist
Nachtrag zum Datenschutz: wenn man ldaps nach aussen auf macht, sollte man noch sicherstellen dass ein Anonymous bind nicht schon an alle Nutzerdaten kommt. dann sollte man die Erreichbarkeit von aussen auf die Server von ausserhalb einschränken, die auch genutzt werden
Hallo Sucher,
danke danke danke für den Input. Heute schafft mein Kopf das nicht mehr, aber morgen setz ich mich da dran. Immerhin wird klar, dass trotz HA-Proxy auch Firewallregeln da sein müssen.
Lieben Gruß
Max
Hallo Max,
hat das eigentlich jetzt geklappt. Ich hab mir jetzt auch mal ne opnsense geholt und musste feststellen dass die GUI doch da einiges anders ist, auch wenn natürlich dieselben Einstellungen man da konfigurieren muss…
Hallo Sucher,
nein, ich habs nicht hinbekommen bzw. dann war LDAPS unsigniert möglich und ich habe, weil Moodle so viel Zeit braucht, nicht weiter probiert.
Sorry.
LG
Max
Der nächste Schritt ist SAML, das wäre sogar noch besser.
Blicke aber noch nciht durch.
