Erweiterungswunsch: LDAP und Gruppenrechte

[mirko]

@ im Nutzernamen ist eigentlich nicht erlaubt, gefällt mir nicht aber kann ich auch anpassen. Kannst selbst die Datei usersedit.php ändern Zeile 79 und 85 steht

Ich hab beide RegEx angepasst, trotzdem lässt sich ein @ im Usernamen nicht speichern. Gibt es noch eine weitere Codestelle?

Sind nur die 2 Stellen und lässt sich speichern. Kannst auch das Update von gestern einspielen, ist es auch enthalten.

Die werden alle automatisch umgewidmet. Sobald man auf LDAP umstellt, wird nur noch der Nutzer superadmin lokal in der DB gesucht, alle anderen Admins und Nutzer gehen alle per LDAP.

Planst Du das nochmal zu überarbeiten? Eine "nur LDAP" Beschränkung halte ich nicht für sinnvoll. Über LDAP deckt man meist alle "internen" User ab. Wenn ein "externer" User Zugriff bekommen soll, legt man für den nicht extra ein LDAP-Konto an (Aufwand / Sicherheit). Somit wäre es echt sinnvoll, beide Authentifizierungsverfahren parallel zu ermöglichen. Entweder durch das festlegen einer Reihenfolge (suche erst intern, wenn kein Match dann LDAP) oder über eine Auswahlbox, siehe angehängter Screenshot von LimeSurvey.
[/quote]

Das bleibt jetzt erst mal bei der Variante, so wie das hier beim Forum auch ist, man muss sich für eine Authentifizierungsvariante entscheiden, entweder Authentifizierung über DB, LDAP oder OAuth.

[adelphi]

@ im Nutzernamen ist eigentlich nicht erlaubt, gefällt mir nicht aber kann ich auch anpassen. Kannst selbst die Datei usersedit.php ändern Zeile 79 und 85 steht

Ich hab beide RegEx angepasst, trotzdem lässt sich ein @ im Usernamen nicht speichern. Gibt es noch eine weitere Codestelle?

Die werden alle automatisch umgewidmet. Sobald man auf LDAP umstellt, wird nur noch der Nutzer superadmin lokal in der DB gesucht, alle anderen Admins und Nutzer gehen alle per LDAP.

Planst Du das nochmal zu überarbeiten? Eine "nur LDAP" Beschränkung halte ich nicht für sinnvoll. Über LDAP deckt man meist alle "internen" User ab. Wenn ein "externer" User Zugriff bekommen soll, legt man für den nicht extra ein LDAP-Konto an (Aufwand / Sicherheit). Somit wäre es echt sinnvoll, beide Authentifizierungsverfahren parallel zu ermöglichen. Entweder durch das festlegen einer Reihenfolge (suche erst intern, wenn kein Match dann LDAP) oder über eine Auswahlbox, siehe angehängter Screenshot von LimeSurvey.

[mirko]

Natürlich muss der Nutzername übereinstimmen aber die darf man ab der Version über die Oberfläche umbenennen, so dass es passen sollte.

Da habe ich nun aber wirklich ein Problem:
Bei per LDAP erzeugten Usern wird als SWM-Nutzername die E-Mail-Adresse erzeugt (lässt sich nicht steuern, oder?). Leider lässt der SWM es nicht zu, den Nutzernamen eines lokalen Users in eine E-Mail-Adresse zu ändern (@ nicht erlaubt).
Übersehe ich etwas?

@ im Nutzernamen ist eigentlich nicht erlaubt, gefällt mir nicht aber kann ich auch anpassen. Kannst selbst die Datei usersedit.php ändern Zeile 79 und 85 steht

Code: Alles auswählen

preg_match("/^[a-zA-Z0-9_]{3,}$/", $_POST["Username"])

das ändern in

Code: Alles auswählen

preg_match("/^[a-zA-Z0-9_@]{3,}$/", $_POST["Username"])

Noch eine Frage zum Zugriff auf Empfängerlisten:
Hilfe sagt: "dass der Nutzer Zugriff auf alle Empfängerliste oder keine Empfängerlisten erhalten soll."
Ist das eine einmalige Rechtezuweisung auf existierende Empfängerlisten oder sieht er auch automatisch alle nachträglich im admin hinzugefügten Empfängerlisten?

Das ist einmalig. Sobald sich derjenige das ERSTE Mal anmeldet und damit in der lokalen Datenbank angelegt wird, bekommt er Zugriff auf alle Empfängerlisten, die zu diesem Zeitpunkt existieren. Erstellt der Admin später neue Empfängerlisten muss man, wie jetzt auch, manuell das Häkchen beim jeweiligen Nutzer setzen.

[adelphi]

Natürlich muss der Nutzername übereinstimmen aber die darf man ab der Version über die Oberfläche umbenennen, so dass es passen sollte.

Da habe ich nun aber wirklich ein Problem:
Bei per LDAP erzeugten Usern wird als SWM-Nutzername die E-Mail-Adresse erzeugt (lässt sich nicht steuern, oder?). Leider lässt der SWM es nicht zu, den Nutzernamen eines lokalen Users in eine E-Mail-Adresse zu ändern (@ nicht erlaubt).
Übersehe ich etwas?

Noch eine Frage zum Zugriff auf Empfängerlisten:
Hilfe sagt: "dass der Nutzer Zugriff auf alle Empfängerliste oder keine Empfängerlisten erhalten soll."
Ist das eine einmalige Rechtezuweisung auf existierende Empfängerlisten oder sieht er auch automatisch alle nachträglich im admin hinzugefügten Empfängerlisten?

[adelphi]

Sorry, hat sich erledigt. Da war ein Buchstabendreher im Hostnamen

[adelphi]

Ich habe mir schon gedacht, dass diese Funktion Probleme machen wird, weil keiner so richtig weiß, was überhaupt einzugeben ist.

Ähm, sorry, aber wir haben sehr wohl Ahnung, was einzugeben ist. Ich binde seit über 10 Jahren zahlreiche Tools via LDAP an. Sowas ist in Unternehmen eher die Regel als die Ausnahme...

LDAP-Basis DN richtig eingeben, Screenshot anbei aus Userbooster light, gibt es auch andere grafische Tools, DN ist hier dc=maxcrc,dc=com. Für einem Server vom Bund ist es z.B. ou=BfA,o=Bund,c=DE.

Ist natürlich korrekt eingegeben:
uo=users,ou=accounts,dc=intern,dc=domain,dc=de

Im selben Prinzip auf der Benutzer als DN:
cn=username,ou=service accounts,ou=accounts,dc=intern,dc=domain,dc=de

Als Nutzernamen verwenden wir "userPrincipalName", da Multidomain-Umgebung.

Und wie schon gesagt: Zahlreiche andere Tools auf dem Server haben keine Probleme mit der LDAP Anbindung bei selber Konfiguration...
Aber selbst wenn die Basis DN falsch wäre, müsste ja trotzdem ein LDAP Request auf Port 389 des Servers ankommen. Tut er aber nicht...

[mirko]

Ich habe das soeben getestet und hatte leider keinen Erfolg.

Fehlermeldung: Die Authentifizierung ist fehlgeschlagen. Searching failed, No such object 2 ldap_search(): Search: No such object /srv/www/test/ldap_auth.php 133

Interessanterweise kommt überhaupt keine LDAP-Abfrage beim LDAP-Server an (tcpdump)!? Wir nutzen die selben Einstellungen wie alle anderen LDAP-Applikationen auf dem selben Webserver, somit Tippe ich eher auf einen Fehler im SWM...

Ich habe mir schon gedacht, dass diese Funktion Probleme machen wird, weil keiner so richtig weiß, was überhaupt einzugeben ist.

LDAP-Basis DN richtig eingeben, Screenshot anbei aus Userbooster light, gibt es auch andere grafische Tools, DN ist hier dc=maxcrc,dc=com. Für einem Server vom Bund ist es z.B. ou=BfA,o=Bund,c=DE.

Beispiel:

Aufbau der Verbindung: http://php.net/manual/de/function.ldap-bind.php
Suche mit base DN: http://php.net/manual/de/function.ldap-search.php

Aus der Praxis kann ich zudem noch ein paar Tipps beitragen:
- Das "entweder lokale Konten oder LDAP Konten" ist keine gute Idee. Normal wäre eher ein Dropdown über der Loginmaske, ggf nur eingeblendet wenn LDAP konfiguriert ist, um die anderen Nutzer nicht zu verwirren. Im System bestehen nämlich schon etliche lokale User die bei Aktivierung von LDAP sonst ausgesperrt wären. Oder gibt es im SWM eine Funktion einen lokalen User zum LDAP-User umzuwidmen?

Die werden alle automatisch umgewidmet. Sobald man auf LDAP umstellt, wird nur noch der Nutzer superadmin lokal in der DB gesucht, alle anderen Admins und Nutzer gehen alle per LDAP. Natürlich muss der Nutzername übereinstimmen aber die darf man ab der Version über die Oberfläche umbenennen, so dass es passen sollte.

- Ein "LDAP Test" Button wäre auf der Konfigurationseite wünschenswert. Entweder mit einfacher OK / Nicht OK Meldung oder besser mit Ausgabe der gefundenen Konten.

Das fiel mir auch schon auf....

Der findet aber auch keine Konten, er sucht immer nach Username uid=eingegebener Username, wäre also wieder zusätzlich eine Funktion nach allen suchen zu lassen.

- Wie erfolgt die Rechtezuweisung? ich hatte gehofft, dass es bei der LDAP-Konfiguration eien Auswahl gibt, welche Rechte einem neu ezeugten user zugewiesen werden. Z.B. durch Auswahl eines Referenzusers, dessen Rechte dann kopiert werden.

ja das ist so. Gibt den Reiter neuer Nutzer, das natürlich nur in der Enterprise-Variante, siehe Screenshot anbei

[adelphi]

Ich habe das soeben getestet und hatte leider keinen Erfolg.

Fehlermeldung: Die Authentifizierung ist fehlgeschlagen. Searching failed, No such object 2 ldap_search(): Search: No such object /srv/www/test/ldap_auth.php 133

Interessanterweise kommt überhaupt keine LDAP-Abfrage beim LDAP-Server an (tcpdump)!? Wir nutzen die selben Einstellungen wie alle anderen LDAP-Applikationen auf dem selben Webserver, somit Tippe ich eher auf einen Fehler im SWM...

Aus der Praxis kann ich zudem noch ein paar Tipps beitragen:
- Das "entweder lokale Konten oder LDAP Konten" ist keine gute Idee. Normal wäre eher ein Dropdown über der Loginmaske, ggf nur eingeblendet wenn LDAP konfiguriert ist, um die anderen Nutzer nicht zu verwirren. Im System bestehen nämlich schon etliche lokale User die bei Aktivierung von LDAP sonst ausgesperrt wären. Oder gibt es im SWM eine Funktion einen lokalen User zum LDAP-User umzuwidmen?

- Ein "LDAP Test" Button wäre auf der Konfigurationseite wünschenswert. Entweder mit einfacher OK / Nicht OK Meldung oder besser mit Ausgabe der gefundenen Konten.

- Wie erfolgt die Rechtezuweisung? ich hatte gehofft, dass es bei der LDAP-Konfiguration eien Auswahl gibt, welche Rechte einem neu ezeugten user zugewiesen werden. Z.B. durch Auswahl eines Referenzusers, dessen Rechte dann kopiert werden.

[mirko]

Beta-Tester nutzt bei Scripten wenig, ich hoffe das es funktioniert, zumindest mit OpenLDAP funktioniert das.

Die Rechte sind die gleichen wie bei einem normalen Nutzer den man von Hand einrichtet, das gibt man vor und dann bekommt jeder Nutzer die gleiche Rechte, falls dieser nicht existiert. Admin-Nutzer werden nicht automatisch angelegt, nur eingeschränkte Nutzer.

[adelphi]

Aber ob das jemand nutzt, da habe ich so meine Zweifel. Der LDAP-Server muss vom Webspace auch noch erreichbar sein, das wird auch sehr selten der Fall sein.

Wow, super, ich bin beeindruckt! Falls Du einen Beta-Tester brauchst, erkläre ich mich gerne bereit!

Aber ob das jemand nutzt, da habe ich so meine Zweifel.

Wir auf jeden Fall und dadurch ersparen wir uns eine Menge Arbeit bei der Nutzerverwaltung.
Wie erfolgt das mit der Rechtevergabe? Kann man festlegen, welche Rechte ein per LDAP erzeugter SWM-User standardmäßig bekommt? Man könnte dazu ja die Funktion der Rechtevorlage gebrauchen...

Der LDAP-Server muss vom Webspace auch noch erreichbar sein, das wird auch sehr selten der Fall sein.

In Enterpriseumgebungen gibt es gesicherte VPN Tunnel zwischen Webserver und internem LDAP. Sonst würde ja wohl kaum fast jedes Webtool eine LDAP Schnittstelle haben, wenn das niemand gebrauchen könnte.

Ich bin sehr gespannt!

[mirko]

So 3 Tage Arbeit, nun ist die LDAP-Anbindung fertig und wird es in der nächsten Version geben. Aber ob das jemand nutzt, da habe ich so meine Zweifel. Der LDAP-Server muss vom Webspace auch noch erreichbar sein, das wird auch sehr selten der Fall sein.

[adelphi]

Ich erlaube mir mal, mich hier mit einzuklinken, da diesbezüglich in den letzten 3 Jahren nichts passiert ist und auch für uns diese Funktion wichtig ist.

Auch wir setzen SWM in einem größeren Umfeld (250 User) ein, wo Automatisierung im Rahmen der Nutzerverwaltung unverzichtbar ist. Nahezu alle von uns eingesetzten php basierten Weblösungen (Nextcloud, Pydio, Drupal, Wordpress, Joomla, Redmine, LimeSurvey, Moodle, TeamPasswordManager, um nur einige zu nennen) setzten seit Jahren auf LDAP oder SAML für die Nutzerauthentifizierung.
Selbst die von Dir eingesetzte Forensoftware kann LDAP: https://www.phpbb.com/support/docs/en/3 ... al_client/

Bei SuperWebMailer müssen die Nutzer in die Datenbank, hinten dran hängen viele Tabellen.

Alle genannten Lösungen legen dazu in der lokalen Datenbank bei der Erstanmeldung lokale Nutzer mit etlichen Tabellen an und reichen anschließend nur noch die Authentifizierungsanfrage an den LDAP-Server weiter. Das ist also kein Argument gegen LDAP sondern ein ganz normales Verhalten.

Wird bei der Synchronisierung festgestellt, dass ein Nutzer nicht mehr vorhanden ist, dann kann er auch nicht einfach die Daten aus den Tabellen und die Tabellen selbst löschen.

Auch das berücksichtigen alle Lösungen indem man einstellen kann, was beim Löschen eines Users im LDAP passiert: Daten liegen lassen oder Daten löschen. Eine Sperre des Konto erfolgt aber natürlich in jedem Fall, da die weitergereichte Authentifizierung ja fehlschlägt....

Insofern würde ich es sehr begrüßen, wenn Du Dir nochmal Gedanken darüber machst, LDAP vielleicht doch einzubinden. Wir einfach das geht, siehst Du in diesem Beispielcode: https://www.foxplex.com/sites/php-ldap- ... anbindung/

[roland.doe]

Ich kenne das von anderen PHP-basierten Systemen, die gehen wie folgt vor:

Bei der ersten Anmeldung des Benutzers wird der Account automatisch in der lokalen (also SWM) Datenbank angelegt (Berechtigungen: keine/wenige). Die Daten dafür stammen aus LDAP (z.B. UID, SN, CN, mail,...). Nach der erstmaligen Anmeldung kann ein Admin dann die Rechte dem neuen Benutzer zuteilen. Die weiteren Anmeldungen laufen "lokal" nur die Kennwortabfrage wird an LDAP zur Bestätigung weitergeleitet und das Ergebnis verarbeitet. Dafür braucht man nur den LDAP-Client unter Linux installiert zu haben. Dadurch ist auch eine Neukompilierung von PHP nicht nötig (da stimme ich zu, dass das nur wenige schaffen würden).

Die OpenSource-Produkte Alfresco ("www.alfresco.com/community"), OTRS (otrs.github.io) und ich glaube auch GIT (about.gitlab.com/) verwenden diesen Weg um mit LDAP zu arbeiten. Auch andere Produkte verfahren ähnlich, manche haben zusätzlich einen Synchronizer, der die Daten aus dem LDAP immer wieder abgleicht. Dafür muss ein eindeutiges Merkmal (z.B. die UUID, Mailadresse usw.) festgelegt werden (siehe dazu "lsc" - http://lsc-project.org/wiki/).

Roland

[mirko]

Das geht aber nicht. Bei SuperWebMailer müssen die Nutzer in die Datenbank, hinten dran hängen viele Tabellen. Wird bei der Synchronisierung festgestellt, dass ein Nutzer nicht mehr vorhanden ist, dann kann er auch nicht einfach die Daten aus den Tabellen und die Tabellen selbst löschen.

Nachtrag: PHP unterstützt nicht mal LDAP, muss man PHP erst neu compilieren, das bekommt kaum jemand hin.

[roland.doe]

Hallo,

ich habe SWM neu installiert und muss nun Benutzer und Benutzerberechtigungen erstellen. Es wäre toll, wenn Benutzer via LDAP synchronisiert/angemeldet werden könnten.

Da ich mehrere Benutzer mit identischen Berechtigungen anlegen muss wäre eine Verwaltung mit Gruppenrechten auch wünschenswert. Das würde den administrativen Aufwand bei uns enorm vereinfachen.

Roland