Hallo zusammen,
im Hinblick auf den Wegfall der Belwue-Services bin ich gerade dabei, den externen Dockerhost in die DMZ hinter der Firewall umzuziehen. Dadurch komme ich mit nur einer IP aus…
Der Umzug an sich läuft ganz gut. Die Oberflächen sind alle erreichbar.
Die Nextcloud läuft super. Die Benutzerkönnen sich anmelden und auf ihre Daten zugreifen.
Der ldaps-Zugriff funktioniert also.
Aber jetzt kommts: mrbs und das OpenSchulPortfolio können sich nicht anmelden. Von außen gehts da ist das ldap über ldaps://meineURL:636 erreichbar.
Von innne, also aus der DMZ sollte es doch über ldaps://10.16.1.1:636 erreichbar sein. Ist es auch nur leider heißt es immer „Unbekannter Benutzer“
Gibt es jemanden, der mrbs in der DMZ betreibt oder der mir einen Tip geben kann?
Schonmal vielen Dank für’s Mitdenken.
Gruß,
Mathias
Hallo Christoph,
vielen Dank für deine schnelle Antwort.
Da hast du natürlich recht. Daher habe ich zu Testzwecken aus der DMZ alles erlaubt.
Das scheint auch zu funktionieren. Die Nextcloud, die auf dem gleichen Dockerhost läuft kann ja ohne Probleme die Benutzer abfragen.
Das MRBS leider nicht. Witzigerweise kommt sofort die Antwort, dass der Benutzer, der sich anmelden möchte ein unbekannter Benutzer ist. Wenn ich dann eine falsche Server IP eingebe, muss man auf eine Antwort wesentlich länger warten?!?
Hier ist ein Ausschnitt meiner /srv/docker/linuxmuster-mrbs/config/raumbuchung.inc.php
// LDAP auth für linuxmuster62 mit einem Workaround, so
// dass man den Zugang auf Gruppen einschränken kann
$auth["type"] = "linuxmuster7";
// LDAP Server
// $ldap_host = "ldaps://servername:636";
// $ldap_host = "ldaps://ip-Addr:636";
$ldap_host = "ldaps://10.16.1.1:636";
// Gruppen, die Zugang zum MRBS haben sollen
// $ldap_lmn_accessgroups = array("teachers","p_mrbs");
// Wenn alle Benutzer zugang haben sollen, auskommentieren
$ldap_lmn_accessgroups = array("teachers","p_mrbs");
$ldap_base_dn = "DC=linuxmuster,DC=lan";
$ldap_dn_search_dn = "CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan";
$ldap_dn_search_password = "12geheim90";
$ldap_dn_search_attrib = "sAMAccountName";
Leider protokollieren weder das MRBS noch das OSP etwas.
… nur so eine Idee: kann es evtl daran liegen, dass du über ldaps (verschlüsselt) gehst? Erwartet das ein gültiges Zertifikat, das es bei Nutzung der IP anstelle des Namens nicht gibt?
das dachte ich auch am Anfang. Allerdings klappt’s bei der Nextcloud?!? Die fragt auch über ldaps://10.16.1.1:636 ab?
Das MRBS auf dem externen Dokerhost ist über mrbs.staufer-gymnasium.de erreichbar und das MRBS auf dem Dockerhost in der DMZ ist unter wwwmc.staufer-gymnasium.de erreichbar. Ich habe den CNAME-Eintrag noch nicht auf unseren Server gesetzt. Daher arbeite ich unter wwwmc.staufer-gymnasium.de.
Ob’s irgendwie daran liegt?
Gruß,
Mathias
naja, eher ein Workaround - denn so laufen die Anfragen halt
unverschlüsselt. Das kann man je nach Netzwerktopologie aber auch so lassen.
Wenn die Anfragen so funktionieren, dann liegt es entweder an einem
gesperrten Port oder am Zertifikat. Eine gute Lösung wäre:
„Von außen“ hattest Du einen FQDN für den LMN-Server (genauer: die
Firewall, von der aus die Anfragen per Portweiterleitung zum Server
gelangen) für die Ldap-Abfrage verwendet. Du sorgst dafür, dass in der
DMZ dieser FQDN auf die 10.16.1.1 aufgelöst wird. Dann richtest Du auf
der Firewall eine Regel ein: „Zugriffe aus der DMZ nach 10.16.1.1 auf
Port 636 sind erlaubt“.
Und dann musst Du noch klären, dass Dein Zertifikat (also das, dass der
LDAP verwendet) auf dem neuen Host akzeptiert wird. Entweder, Du nimmst
ein richtiges Zertifikat, oder Du schaltest beim LDAP-Client auf dem
neuen Host die Zertifikatsprüfung ab.
So sollte es wieder mir der alten Konfiguration gehen.
das deaktiviert tatsächlich die Verwendung von TLS.
Die Überprüfung von Zertifikaten bei kann man normalerweise verhindern,
wenn man in der Datei /etc/ldap/ldap.conf die folgende Option
einträgt:
TSL_REQCERT never
Allerdings würde ich bevorzugen, auf dem Server ein gültiges Zertifikat
zu verwenden, z. B. von Let’s Encrypt - das ist schnell eingerichtet. So
musst Du auf jedem Client erneut Hand anlegen, auch ist die Fehlersuche
oft mühsam, weil die Fehlermeldungen oft nicht wirklich weiterhelfen.
Zum Testen empfehle ich auch immer Ldapsearch. Wenn es damit Probleme
gibt, dann liegt es an Ports oder Zertifikaten. Wenn es damit geht und
im eigentlichen Tool wie MRBS nicht, dann liegt es an den Einstellungen
innerhalb des Tools - so kann man das getrennt analysieren.
Ich war mal im Container und hab mir die /etc/ldap/ldap.conf angeschaut. Da war TSL_REQCERT never schon gesetzt.
Am Zertifikat ligts also nicht.
Naja, unsere Firewall ist von Außen unter server.staufer-gymnasium.de erreichbar. Intern haben wir die Domäne linuxmuster.lan. staufer-gymnasium.de war als Domäne wohl für Samba zu lang.