Authentifizierung geht nicht bei mehreren Domains

[StefS]

Hallo,

anscheinend ist bei der aktuellen EGrouoware Version die Authentifizierung defekt, wenn man mehrere Domains konfiguriert hat.

Es geht mit zwei Domains, die beide komplett gegen SQL arbeiten (Nutzerspeicher + Auth).
Es geht aber nicht, sobald eine Domain gegen SQL Authentifiziert und die andere gegen LDAP - bei einer der beiden kann sich anschliessend niemand mehr anmelden.

Konfiguration:

• Domain 1-SQL
  Benutzerkonten speichern: SQL
  Authentifizierung (alle Arten): SQL
  SQL-Verschlüsselungstyp für das Passwort: sha512_crypt
  Password Migration: JA

• Domain 2-LDAP:
  Benutzerkonten speichern: SQL (nach initialem LDAP-Import via Setup)
  Authentifizierung (alle Arten): LDAP
  SQL-Verschlüsselungstyp für das Passwort: sha512_crypt
  Password Migration: JA

In diesem Setup können sich immer nur Nutzer einer der beiden Domains erfolgreich anmelden. Welche der beiden Domains das ist, hängt davon ab, bei welcher der beiden sich zuerst ein Nutzer versucht anzumelden, also:

1. Restart Docker-Container “egroupware”

2. Web-Login von user-a@1-SQL -> erfolgreich

3. Web-Login oder CardDAV-Login von user-b@1-SQL -> erfolgreich

4. Web-Login von user-x@2-LDAP -> Fehler
   => es kann sich kein einziger Nutzer von 2-LDAP anmelden, es gehen alle Nutzer von 1-SQL

5. Restart Docker-Container “egroupware”

6. Web-Login von user-x@2-LDAP -> erfolgreich

7. Web-Login oder CardDAV-Login von user-y@2-LDAP -> erfolgreich

8. Web-Login von user-a@1-SQL -> Fehler
   => es kann sich kein einziger Nutzer von 1-SQL anmelden, es gehen alle Nutzer von 2-LDAP

9. Restart Docker-Container "egroupware"
   11ff obere Abläufe beliebig wiederholbar…

Da die erfolgreiche resp. fehlerhafte Authentifizierung beider Domains allein vom ersten Login abhängig ist, gehe ich mal davon aus, das die Konfigurationen der beiden Domains an sich korrekt sind (d.h. SQL-Passwörter und LDAP-Daten sind richtig). Der Fehler muss allein bei Egroupware liegen, da es anscheinend nicht richtig prüft, gegen welches Backend es die Nutzer zu authentifizieren hat.

In den (Docker-)Logs von Egroupware habe ich aber keine Fehler dazu gefunden oder überhaupt Hinweise wogegen es jeweils versucht zu authentifizieren.
Ich sehe aber in jedem Fall in der zugehörigen Datenbank der Domain in der Access-Log Tabelle die Einträge für die fehlgeschlagenen Authentifizierungen mit entsprechenden Block des Nutzers bei zu vielen Fehlerhaften Anmeldungen. Nur halt wie gesagt keinen Hinweis wo/wie Egroupware zu authentifizieren versucht.

System:
Debian/10 mit dep-Paket egroupware-docker 21.1.20220916
MariaDB-Server und LDAP-Server auf Extern (nicht lokale docker-images)

Viele Grüße,
Stefan Seide

p.s. Vielen Dank an Stefan Unverricht für den Hnweis auf Dockly in einem der anderen Threads - wirklich nettes Tool und hilfreich hier

[RalfBecker]

Hallo StefS,

ich empfehle Dir ein etwas anderes Setup, bei dem die Instanz wie bei einem vHost durch deren Hostnamen ausgewählt wird, das funktioniert und wird von uns unterstützt.

Als Beispiel:

• egw.example.org --> 1. Instanz mit Benutzernamen OHNE “@”
• egw.example.de --> 2. Instanz ------------- " -------------------
• …

In der header.inc.php wird “egw.example.org” bzw “egw.example.de” als Key für das Domain-Array verwendet, statt z.B. “default”, das wir standardmäßig für die erste Instanz verwenden, oder was auch immer Du da im Moment als Key eingetragen hast.

Alles andere funktioniert nicht in jedem Fall, z.B. nicht mit Basic Authentication für *DAV.
Ich bin mir aber nicht bewußt das sich daran etwas in letzter Zeit geändert hätte, evtl. versuchst Du jetzt nur einen anderen Spezialfall.

Wir können da im kostenpflichtigen Support sicher mit Dir zusammen das Problem debuggen, aber ohne Garantie es wirklich lösen zu können! Deswegen schlage ich in diesen Fällen immer vor die Instanzen entsprechend umzubauen. Mit LetsEncrypt kosten (Multidomain-)Zertifikate ja heute auch nichts mehr.

Ralf

[StefS]

gerade erst gesehen, das der Entwurf noch gar nicht abgeschickt worden war…

===

Hallo Ralf,

vielen Dank für die schnelle Antwort. Und teilweise hatte ich das ja sogar schon (zufällig) so gemacht für die zweite Domain. Habe es aber nochmal für beide Domains glatt gezogen und bei der Login-Seite die Drop-down Box für die Domains deaktiviert. In den beiden “egw_accesslog” Tabellen der Domains sehe ich, das nun auch die Loginnamen ohne Domain richtig zugeordnet werden und je nach Domain da ankommen wo sie sollen.

Trotzdem bleibt aber das Problem bestehen, das immer nur die Domain, welche nach Docker-Container Neustart als erste einen Login hatte, sich erfolgreich authentifizieren kann. Die zweite wirft immer Fehler bis zum Docker-Image Neustart… Also es geht entweder die Domain mit SQL-Auth oder die Domain mit LDAP-Auth.

Wir können da im kostenpflichtigen Support sicher mit Dir zusammen das Problem debuggen, aber ohne Garantie es wirklich lösen zu können! Deswegen schlage ich in diesen Fällen immer vor die Instanzen entsprechend umzubauen. Mit LetsEncrypt kosten (Multidomain-)Zertifikate ja heute auch nichts mehr.

Da das einmal Familie und einem Freundeskreis für gemeinsames Projekt ist, ist leider niemand von denen bereit etliche Pro-Support-Stunden zu bezahlen. Insofern werde ich die VM dann wohl doppeln um jeweils eine Authentifizierungsart per VM zu haben. Da dann aus jeder der Kopien nur je eine der Domains zu löschen ist, geht das auch schnell. Oder, da ja eh nur ein Bruchteil der Funktionen genutzt wird, stelle ich das eine von beiden auf einen reinen CalDAV/CardDAV Server (Radicale o.ä.) um…

Nichtsdestotrotz ganz vielen Dank für die Hilfe und EGW als solches.

Stefan Seide

[RalfBecker]

Ich bin gestern beim Versuch mich auf meinem Entwicklungssystem per Domain-Selectbox auf einer anderen Instanz einzuloggen in das gleiche bzw. ein ähnliches Problem gestoßen und habe es behoben:

fix not working login with domain selectbox

Du kannst Dir den Fix ja mal bei Dir im Container einspielen, evtl. war es das ja schon.

Zum Einspielen von Patches/Commits gibt es eine Anleitung hier im Forum.

Ralf

[StefS]

Hallo,

ich habe (wegen FPM) den “egroupware” Docker-Container neu gestartet und dann mich in dem Container eingeloggt und die Datei “usr/share/egroupware/api/src/Auth.php” editiert. Die eine Zeile 144 entsprechend dem Patch angepasst und zusätzlich noch in Zeile 26 bei “error_log(…)” den Kommentar entfernt.

Funktioniert aber leider immer noch nicht.

1. Login nach Docker-Restart und Editieren mit Domain+LDAP -> Login erfolgreich und in den Logs (via /etc/egroupware-docker/egroupware-logs.sh) steht

2023/02/06 09:33:08 [error] 20#20: *29186 FastCGI sent in stderr: “
PHP message: using auth_type=ldap, currentapp=login” while reading response header from upstream, …

2. Login mit Domain-SQL -> Bad username/password. In den Logs steht aber weiterhin auth_type “ldap” und nicht “sql”?

2023/02/06 09:34:52 [error] 20#20: *29165 FastCGI sent in stderr: “
PHP message: using auth_type=ldap, currentapp=login” while reading response header from upstream, …

Wenn ich mir die “Auth.php” anschaue wird bei Backends ja anscheinen nur auf Globale Env “$GLOBALS[‘egw_info’][‘server’][‘auth_type’]” verwiesen. Wird diese Variable bei jedem Request entsprechend des Eintrages aus der DB (egw_config Tabelle) für die aktuelle Domain re-initialisiert?

Vieel Grüße,
Stefan

[RalfBecker]

ich habe (wegen FPM) den “egroupware” Docker-Container neu gestartet und dann mich in dem Container eingeloggt und die Datei “usr/share/egroupware/api/src/Auth.php” editiert. Die eine Zeile 144 entsprechend dem Patch angepasst und zusätzlich noch in Zeile 26 bei “error_log(…)” den Kommentar entfernt.

Schau Dir mal die Anleitung an, so hast Du nichts im Container geändert

Kurzanleitung für Lesefaule:

curl https://github.com/EGroupware/egroupware/commit/4f0e65c1a57ade25f0e294c74717bb0b62f2162a.patch | docker exec -i  egroupware patch -p1 -d /usr/share/egroupware
docker exec -it egroupware kill -s USR2 1

Auf meinem Entwicklungssystem kann ich seit dem (wieder) problemlos zwischen den Instanzen per Selectbox wechseln.

Ralf

[StefanU]

Einen Patch aus GitHub installieren

[StefS]

Vielen Dank für den Link - hatte zwar im Forum gesucht, aber mich da wohl etwas zu dumm angestellt und den nicht gefunden.
Aber meine “Art” hat auch was im Container geändert - auch wenn nicht dauerhaft, sondern nur temporär bis zum nächsten Container-Restart. Der wird halt so selten genutzt, das ich da genug Zeit habe zwischen Restart und erstem Client-Aufruf bevor FPM die Dateien lädt…

Zumindest kam erst nach meinem händischen “Update” die Logmeldung mit “using auth_type=ldap, currentapp=login”. Sobald ich den Container wieder neu starte ist die Log-Meldung und die händische Änderung des Patches weg gewesen - insofern gehe ich mal davon aus, da das aktiv war.

Nichtsdestotrotz natürlich das “curl -> patch” ausgeführt und Effekt ist der selbe wie vorher beim temporären Update. Die zuerst aufgerufene Domain nach Image-Restart (oder nur FPM-Restart als ProcessID 1) kann sich authentifizieren, alle Nutzer der zweiten Domain die einen anderen “auth_type” für Web-Login in selber laufenden Docker-Instanz verwendet geht nicht.

Bei den Nutzern der als zweites angesprochenen Instanz wird in “ihrer” Datenbank immer nur die “bad login” Meldung in der “egw_accesslog” Tabelle geloggt.

[RalfBecker]

Ist echt komisch: der Auth-Type der Instanz wird in der Sitzung gespeichert, und Du sagst ein Restart des Containers, der den Instanz-Cache, nicht aber die Sitzung löscht, hilft um auf die andere Domain zu wechseln.

Irgendwie hast Du ein Deiner Umgebung etwas anders als auf meinem Entwicklungssystem, da kann ich Dir jetzt in kostenfreien Support einfach nicht mehr weiter helfen.

Den einfachen Workaround mit zwei (Sub-)Domains willst Du ja auch nicht machen
Der funktioniert immer zuverlässig, und Zertifikate kosten heute ja nichts mehr …

Ralf

[StefS]

Hallo,

Ist echt komisch: der Auth-Type der Instanz wird in der Sitzung gespeichert, und Du sagst ein Restart des Containers, der den Instanz-Cache, nicht aber die Sitzung löscht, hilft um auf die andere Domain zu wechseln.

Ja - ich habe einen Browser (Firefox oder Chromium - egal) offen und rufe die erste Domain auf. Direkt davor wurde der Docker-Container neu gestartet (oder nur FPM via “docker exec” wie jetzt gelernt). Alle Nutzer dieser Domain können sich dann einloggen + ausloggen. Egal mit welchem Browser/Computer.
Nachdem ich mich im Browser ausgeloggt habe, ändere ich händisch in der Adresszeile des Browsers die Url (DNS-Name) auf die zweite Domain, die im selben Docker-Container als zweite Instanz mit einer anderen Datenbank läuft. Login geht nicht. Login geht ebenso nicht, wenn ich auf einem zweiten PC einen Browser öffne und mich versuche mit einem Nutzer der zweiten Domain anzumelden. Diese Anmelde-Problem ist unabhängig vom verwendeten Browser des Nutzers.

Und wie gesagt - je nachdem mit welchem Nutzer ich mich versuche anzumelden - die Log-Meldungen (PHP Session-ID oder “bad login”) landen immer in der richtigen Datenbank dieser Domain in der “egw_accesslog” Tabelle. Zumindest hier klappt die Zuordnung richtig.

Und wie gesagt - mit welcher der beiden Domains ich mich erfolgreich anmelden kann und welche immer für alle Nutzer abgewiesen wird hängt allein davon ab, mit welcher Domain ich nach dem Restart des FPM ich mich zuerst angemeldet habe. Der Docker-Container scheint intern nur einmal nach dem Start den “auth_type” resp. die Auth-Backend Instanz zu bestimmen und dann für alle nachfolgenden Requests, egal auf welche Domain, dieses einen “auth_type”/Backend zu cachen. Es geht entweder die Domain mit “auth_type=sql” oder die Domain mit “auth_type=ldap”.

Den einfachen Workaround mit zwei (Sub-)Domains willst Du ja auch nicht machen

Das hier denke ich ein Missverständnis (oder ich habe es noch nicht verstanden) - ich habe ja schon zwei eigenständige Domains / eigene TLS-Zertifikate wie in der ersten Antwort vorgeschlagen Das ist alles wie dort von dir vorgeschlagen angepasst. Es sind zwar keine unterschiedlichen Subdomains sondern sie unterscheiden sich schon auf TLD Ebene, aber sind zwei (aus DNS-Sicht) komplett unabhängige Domains, welche mit ihrem vollen Namen in Egroupware konfiguriert sind und via unterschiedlicher VHosts je nach verwendeter URL im Browser auch automatisch korrekt selektiert werden.

Ich werde mich dann einfach mit den anderen Nutzern besprechen was eigentlich an Funktionen benötigt wird und dann entweder im Egroupware Header Setup die eine Domain löschen und mit Stand-Alone CalDAV/CardDAV Server ersetzen oder zwei komplett eigenständige Docker-Setups mit Egroupware und nur jeweils einer Domain aufsetzen (auch ein Gelegenheit den “Zoo” etwas auszumisten) …

Und zumindest scheint es ja einen anderen Bug unterwegs erwischt zu haben wenn ich den Patch oben richtig verstehe .
Ganz vielen Dank für die Hilfe bis hier hin.

Stefan Seide

[RalfBecker]

Hast Du die Domain-Selectbox noch angeschaltet, die sollte in dem Fall aus sein UND die Namen der Domains sollten genau so im header verwendet werden z.B. statt der standard-mäßigen Domain “default”, sollte da die FWDN stehen.

Ralf

[StefS]

Die Domain-Select-Box ist ausgeschaltet und die DNS-Domain Namen im Browser sind exakt die Namen, die ich in der “header.inc.php” unterhalb des $GLOBALS['egw_domain'] Array als Keys für die Domains verwendet habe.
Die “Default” Domain gibt es da nicht mehr.

[RalfBecker]

Das haben wir so auf hunderten von Instanzen im Einsatz, echt komisch was Du da hast

Enthalten die Benutzernamen eine Domain wie EMail Adressen, oder kein @ und nur einen Namen?
Das könnte noch eine Fehlerquelle sein.

Ralf