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.
Der nächste Schritt ist SAML, das wäre sogar noch besser.
Blicke aber noch nciht durch.