LimeSurvey mit LDAP

Michael · 8. März 2019 um 13:07

Hi.
Ich habe für eine anstehende Umfrage unter unseren Schülern LimeSurvey installiert, was zunächst einen ganz guten Eindruck macht.

Hat das zufällig einer von Euch auch laufen – zudem mit einer funktionierenden LDAPv3 Abfrage? Diese LDAP-Syntax ist echt nicht meins …
Es klappt bereits, dass man sich als LDAP-User anmelden kann. Was aber einfach nicht hinhauen will, ist der Import von Umfrageteilnehmern aus den LDAP-Abfragen, die man zuvor unter …/application/config/ldap.php definiert hat. Die Einträge sind an beiden Stellen identisch – trotzdem wird immer wieder gemeldet:
Fehler : Mit dem LDAP Verzeichnis konnte nicht verbunden werden

Ich würde die User-Accounts dort natürlich nur ungern manuell erzeugen. Die LDAP-Funktion ist eigentlich genau das, was ich gesucht habe …

Schöne Grüße,
Michael

baumhof · 8. März 2019 um 21:57

Hallo Michael,

ich hab mal LimeSurvey für meinen Bereichsleiter im Seminar installiert:
ist aber schon 3 Jahre her…
Der hat aber nie nach LDAP gefragt: warum auch. Für Umfragen ist eine
Personenbezogene Anmeldung keien gute Idee: je mehr die Personen sich
nachverfolgbar wähnen, desto weniger aussagekräftig die Umfrage.
Also gibt er den Link an ausgewählte Leute weiter.
Ob er da auch “loginkärtchen” für macht: damit die Nutzer nur einmal
abstimmen können, weiß ich nicht.

Ich wäre befangen bei einer Umfrage, bei der ich mich mit Namen anmelden
müßte.

LG

Holger

Michael · 8. März 2019 um 22:28

Hallo Holger,
ja, wenn’s eine normale Umfrage wäre, hast du Recht. Wir wollen das aber als “Abfrage” nutzen – das ist eh nicht annoym, da der Name erforderlich ist. Daher könnte man LDAP sehr gut nutzen, um es direkt auf Jahrgang 11 zuzuschneiden und entsprechend zu filtern.

Vorher habe ich sowas immer mit grafStat gemacht. Da kann man den Fragebogen gegen Mehrfachausfüllen mit TANs sichern. Das geht ja hier auch alles, doch wenn’s direkt mit LDAP ginge, wäre es noch schicker.

Ich habe auch den Menupunkt “Dummy-Teilnehmer” gefunden, um anonyme Teilnehmer mit Zufallspasswort generieren zu können - doch hier ist es so vorgesehen, dass man die Passwörter per eMail verteilt. Das funktioniert natürlich nicht, wenn’s Zufalls-Logins sind. Die einzige Möglichkeit ist hier der Export als CSV-Datei aller Umfrageteilnehmer, oder?

Schöne Grüße,
Michael

Cgsman · 9. März 2019 um 00:14

Lieber Michael,
vor einiger Zeit haben wir für Projektwahlen für alle Schüler unserer Schule dazu Moodle benutzt - zusammen mit dem questionnaire-Modul; vielleicht würde das bei Dir auch funktionieren,
liebe Grüße Christoph G.

jrichter · 9. März 2019 um 02:48

Hallo Michael,

bei Problemen mit dem Ldap ist es oft hilfreich, auf dem Server das Loglevel hochzusetzen, das Log wird dann sehr ausführlich.

Ansonsten poste doch mal die beiden Konfigurationsdateien.

Beste Grüße

Jörg

Michael · 9. März 2019 um 06:22

Hallo.
Notfalls kann ich auf moodle ausweichen – aber jetzt ist LimeSurvey schon mal drauf.
Ich habe auch eine Vermutung, woran es liegt. Wenn man in die Datei
/application/config/ldap.php
schaut, kann man dort Profile für jede einzelne LDAP-Abrfagen erstellen. Eigentlich ist das genial, da man auf diese Art immer sofort die passende Anzahl an “Tickets” erstellen kann.

Dort steht:

// Define the ldap protocol to use
// 'ldapv2' and 'ldapv3' are supported
$ldap_server[$serverId]['protoversion'] = "ldapv3";

// Define the encryption method to use
// 'ldaps' is supported for 'ldapv2' servers
// 'start-tls' is supproted for 'ldapv3' servers
// 'none' is supproted for no encryption at all
// Don't forget to setup your CA's certificate in
// the openldap ldap.conf file
$ldap_server[$serverId]['encrypt'] = "start-tls";

// Define the referral option
// 'false' is recommended for ActiveDirectory servers

$ldap_server[$serverId]['referrals'] = true;

Es ist also so, dass bei v3 offenbar nur die beiden Optionen “start-tls” oder “none” aber leider nicht “ldaps” möglich sind (nur v2). Das Loglevel kann man tatsächlich hochdrehen, und zwar unter /application/config/config.php -> Zeile 61/62. Dort habe ich auch den Eintrag
‘enableLdap’=>1 ergänzt.

Ich habe mir das ganze so zusammengereimt, dass die LDAP-Abfrage mit “none” auf dem lml-Server gar nicht klappt und mit “start-tls” nur dann, wenn der lml-Server ein gültiges Let’s Encrypt Zertifikat hat und man die Einstellung /etc/ldap/ldap.conf --> “TLS_REQCERT never” so ändert, dass dort das gültige Zertifikat eingetragen wird!?? Mit dert Option “Ldapv3” und “ldaps” geht es nicht weiter. (Auf das pasten der ganzen debug-Ausgabe verzichte ich daher vorerst …)

Zudem bin ich nicht sicher, ob bei der “referral” nun false oder true gesetzt sein muss – das ändert aber bisher nichts.

Vielleicht bekommt das ja jemand mit gültigem LE-Zertifikat auf 10.16.1.1 hin und kann berichten, wie toll das läuft?

(Damit wäre ich wieder bei einer Frage zur v7: Es wäre offensichtlich sehr vernünftig, den lml-v7 Server sofort bei der Installation mit einem FQDN zu versehen, um dann auch direkt ein gültiges LE-Zertifkat erstellen zu können. Wird das der empfohlene Weg sein??)

Schöne Grüße,
Michael

Michael · 10. März 2019 um 19:40

Ich habe eine Lösung des Problems gefunden (ist nicht auf meinem Mist gewachsen). Wenn man den Eintrag


/*********************************************/
/* LDAP servers                              */
/*********************************************/
putenv("LDAPTLS_REQCERT=never");

vor die Definition der Verbindung packt, kommt auch eine Verbindung für ein selbstsigniertes Zertifikat zustande!

Was jetzt nur noch fehlt ist ein Filter, der z.B. nur eine Klasse filtert. Die LDAP-Abfrage dazu lautet:

$ldap_queries[$query_id]['userfilter'] = '(objectclass=*)';

Damit hat man dann aber alle User importiert und nicht nur eine Jahrgangsstufe.
Wenn man zusätzlich

(|(gidNumber=10000))

nutzt, kann man nun weiter einschränken; in diesem Fall auf alle Lehreraccounts.

Jetzt wäre es noch schön, wenn man eine Übersicht erzeugen könnte, welche gid welchem Jahrgang entspricht. Dann hätte man alles zusammen…

Schöne Grüße,
Michael

baumhof · 10. März 2019 um 20:30

Hallo Michael,

$ldap_queries[$query_id][‚userfilter‘] = ‚(objectclass=*)‘;|

Damit hat man dann aber alle User importiert und nicht nur eine
Jahrgangsstufe.
Wenn man zusätzlich

(|(gidNumber=10000))|

nutzt, kann man nun weiter einschränken; in diesem Fall auf alle
Lehreraccounts.

Jetzt wäre es noch schön, wenn man eine Übersicht erzeugen könnte,
welche gid welchem Jahrgang entspricht. Dann hätte man alles zusammen…

warum machst du es über gid und nicht über den Gruppennamen?
Bei mir ind er nextcloud sieht der Gruppenfilter so aus:

(&(|(objectclass=posixGroup))(|(cn=teachers)(cn=p_fs_englisch)(cn=p_info1)(cn=p_info2)(cn=p_mathematikfs)))

Vielleicht hilft es dir.

LG

Holger

Michael · 11. März 2019 um 06:54

Hi Holger.
Ja, die Idee ist gut – nur: Wie muss dann die Syntax bzw die Einschränkung auf students UND jg-11(oder andere Klassen) lauten? Diese LDAP-Syntax …

Ich habe es bisher so gemacht, dass ich auf dem Server ldapsearch verwendet habe und dort die gidNumber zum entsprechenden Jahrgang direkt sehen konnte. Das war eindeutig …

Noch ein Wort zur Anonymisierung: Ich habe mittlerweile gesehen, dass man das alles unter LimeSurvey einstellen kann. Man kann auch (trotz persönlichem Zugangsschlüssel) alle Antworten komplett anonym halten, wenn man das für eine „richtige“ Umfrage benötigt. In diesem Fall geht es aber wie gesagt um eine Abfrage zum Wahlverhalten innerhalb eines Jahrgangs. Da brauchen wir eh die Namen. Das klappt mit LDAP jetzt wunderbar …

Schönen Gruß,
Michael

baumhof · 11. März 2019 um 08:31

Hallo Michael,

Ja, die Idee ist gut – nur: Wie muss dann die Syntax bzw die
Einschränkung auf students UND jg-11(oder andere Klassen) lauten? Diese
LDAP-Syntax …

… ich verstehe dich nicht.
„students“ ist gar keine Gruppe in der lmn62, du willst doch einfach nur
auf deine jg-11 einschränken (ich nehme an, dass die Klasse so heißt,
wobei ich ein „-“ im Klassenbezeichner schon für mutig halte).
Also schränkt diese Zeile den Zugriff auf „nur Klasse jg-11“ ein:

(&(|(objectclass=posixGroup))(|(cn=jg-11)))

Noch ein Wort zur Anonymisierung: Ich habe mittlerweile gesehen, dass
man das alles unter LimeSurvey einstellen kann. Man kann auch (trotz
persönlichem Zugangsschlüssel) alle Antworten komplett anonym halten,
wenn man das für eine “richtige” Umfrage benötigt.

da hab ich mich nicht genau genug ausgedrückt: es geht nicht um die
Annonymität auf deiner Seite, sondern um die annonymität auf der Seite
derer, die befragt werden.
Wenn ich mich mit meinem Schullogin einlogge und dann die Abfrage mache,
dann muss ich dir glauben, dass du die limesurveyumfrage so eingerichtet
hast, der der Nutzernamen nicht im Datensatz auftaucht: ich muss sogar
erst mal wissen, dass das limesurvey kann und auch ordentlich macht.
Wahrscheinlich ist es aber leicht mit Hilfe von logdateien dann nach zu
vollziehen, wer welchen Datensatz erschaffen hat: ganz an limesurvey
vorbei…

Also: das wichtige ist das „Gefühl“ desjenigen, der an der Umfrage teil
nimmt: und das sollte immer sein: du bist komplett annonym (außer bei
deinem Fall, wo es um eine persöhnliche Wahl geht).

LG

Holger

Michael · 11. März 2019 um 14:29

Hallo Holger,

Ja, das ist der Plan – hast natürlich Recht … in Klasse 11 gibt es das Problem gar nicht. Aber wie würde man das in Jahrgangsstufe 8 machen? Alle Klassen einzeln filtern?
Oder gibt es eine Wildcard a la 8* ?

Das hat noch nie Stress gemacht.

Also da sind wir genau einer Meinung. Ich ziehe bei richtigen Umfragen auch den vollständig anonymen Weg vor und würde da auch keine LDAP-Abfrage einsetzen sondern Zugangsschlüssel (ohne Login) verwenden. Aber selbst dann kann man natürlich den Schlüsseln noch ihre Antworten zuordnen. Daher muss auch die Vergabe der Passwörter absolut zufällig geschehen. Erst dann hat man sowas wie einen „vollständig anonymen“ Fragebogen. Wenn man’s ganz öffnet und gar keine Zugangskontrolle davor schaltet, gibt es halt immer wieder das Problem, dass der absichtlich oder versehentlich mehrfach ausgefüllt wird und so die ganze Statistik unbrauchbar wird … aber alles in allem kann LimeSurvey jetzt genau das, was ich gesucht hatte.

Schöne Grüße,
Michael

Tobias · 13. März 2019 um 00:08

Das gibt es tatsächlich. Aber kompliziertere „Regexp“ gibt es bei LDAP nicht, nur so eine Wildcard mit * hat bei mir funktioniert. Siehe hier: anwenderwiki:nextcloud:nextcloud-ldap [CommunityWiki] als beispiel

Michael · 13. März 2019 um 06:35

Hallo Tobias.
Ich habe es ausprobiert – aber LimeSurvey meldet mit dieser Syntax nur:

Fehler
0
Ergebnisse aus LDAP Abfrage.
0 Datensätze erfüllten die Mindestanforderungen
0 Datensätze importiert.
0 Doppelte Datensätze entfernt

Die LDAP-Abfrage dazu:

/********** Jahrgang 5  ********************/
$query_id++;
$ldap_queries[$query_id]['ldapServerId'] = 0;
$ldap_queries[$query_id]['name'] = 'Jahrgang 5 (Import vom linuxmuster-Server)';
$ldap_queries[$query_id]['userbase'] = 'ou=accounts,dc=linuxmuster,dc=local';
$ldap_queries[$query_id]['userfilter'] = '(&(objectclass=posixGroup)(cn=5*))';
$ldap_queries[$query_id]['userscope'] = 'sub';
$ldap_queries[$query_id]['firstname_attr'] = 'givenname';
$ldap_queries[$query_id]['lastname_attr'] = 'sn';
$ldap_queries[$query_id]['email_attr'] = 'mail';

Hab’s auch schon mit dem | Operator versucht (auch wenn der bei einer einzigen Gruppe nicht viel Sinn ergibt). Ich nehme an, dass Nextcloud den Gruppenfilter zusätzlich verwendet, oder? Hier ist das ja die einzige Abfrage … ldapsearch liefert bei einem Schüler der Unter-/Mittelstufe kein Feld mit der Klasse. Und wenn ich nach “memberof” filtere, habe ich die eingetragenen Lehrer mit drin, oder?

Vielleicht hast du ja noch einen Tipp …
Schöne Grüße,
Michael

Tobias · 13. März 2019 um 20:41

Ok, jetzt verstehe ich: du willst die User anhand ihrer Gruppenzugehörigkeit zulassen bzw. sperren.
Da bist du zunächst auf verlorenem Posten: dein Userfilter würde nur gruppen zurückliefern, keine user. Du musst ein Merkmal finden, das alle 5-klässler gemein haben, und zwar in ihrem LDAP eintrag, z.B. ldapsearch -x uid=schueler mal auf dem Server betrachten.
Ich vermute: Du findest keines. Einzig die gidNumber ist für alle Schüler einer einzelnen Klasse identisch, z.b: „11000“, d.h. du könntest eine Suchmaske:

'(|(gidNumber=11000)(gidNumber=11001)(...)...)'

bis du alle klassen mit ihrer gidNumber drin hast. Das könnte gehen.
Das sieht aufwändig aus, könntest du aber skripten. Kann mir vorstellen, dass sophomorix-class die gidNumber ausspuckt.

P.S. vermutlich wird mit der v7 wird alles besser, dort muss man dann nur „students“ eingeben, oder so, mal sehen.

VG, Tobias

Michael · 13. März 2019 um 21:32

Hallo Tobias,

Ja, ganz genau!
Ich hatte zwischendurch auch schon das hier ausprobiert:

ou=groups,dc=linux,dc=lokal und 
(&(objectclass=*)(cn=5*))

Das lieferte mir 6 Treffer (und zwar natürlich genau die 5a bis 5f) aber hat keine User hinzgefügt, da so NUR die Gruppen gefunden wurden. Ich habe auch schon an „uid“ oder „memberOf“ gedacht … aber wie gesagt: mit dieser LDAP-Syntax kann ich mich nicht wirklich gut anfreunden. Was hier etwas geholfen hat, ist phpLDAPAdmin … da kann man suchen und sieht dann die cn, dn … Einträge.
Für die Gruppe „teachers“ käme man auf diesem Weg wahrscheinlich zum Ziel … es wäre natürlich auch denkbar, ein Projekt anzulegen und da alle 5er, 6er … reinzupacken. Dann könnte man auch danach filtern. Aber sooo wichtig ist das im Moment auch nicht. Für die Oberstufe läuft der Filter ja, da es dort keine Klassen gibt …

OT: Ich habe schon ein paar Befürchtungen, wo man überall nachjustieren muss, wenn die v7 kommt. Ich muss vorher eine Aufstellung machen, wo wir überall LDAP-Abfragen nutzen. Das sind schon ein paar Stellen, an die man dann denken muss …

Schöne Grüße,
Michael

jrichter · 14. März 2019 um 04:52

Hallo Michael,

kannst Du nicht nach dem Homeverzeichnis filtern, z. B. (homeDirectory=/home/students/5*) für die 5er?

Beste Grüße

Jörg

Michael · 14. März 2019 um 11:10

Hallo Jörg.

Hab’s ausprobiert …
Was klappt:

(homeDirectory=*)   
(findet alles)

Was nicht klappt ist die Einschränkung auf

(homeDirectory=/home/students/5*) ... auch nicht *5*, auch nicht mit kleinem "d"

0 Treffer.
Syntax richtig?

Schöne Grüße,
Michael

Michael · 15. März 2019 um 19:09

Also ich habe vermutlich mit Kanonen auf Spatzen geschossen – aber so erhält man immerhin die Zugehörigkeit aller Schüler eines Jahrgangs zur gesuchten gidNumber:

ldapsearch -x -D 'uid=meinlogin,ou=accounts,dc=linuxmuster,dc=local' -W -H ldaps://10.16.1.1:636 -b ou=accounts,dc=linuxmuster,dc=local uid=* |  grep -E '^(gidNumber|homeDirectory):' | cut -d':' -f2 | sed 's#\s##' | sed -r '$!N;s/(.*)\n(.*)/\2|\1/' |grep 5[a-f] |cut -c1-23 |sort -n |uniq

Geht sicher noch schöner … aber „w4m“

[… später …]
Gerade habe ich das mit dem gidNumber-Filter getestet … es funktioniert!
Also kann ich jetzt gezielt z.B. Jahrgang 5 herausfiltern, allen SuS einen Zugangsschlüssel zu bestimmten Um-/Abfragen erstellen und alle anderen draußen lassen. Super Sache!

Für Jahrgang 5 sieht der Filter bei mir nun so aus:

$ldap_queries[$query_id]['userfilter'] = '(|(gidNumber=10043)(gidNumber=10044)(gidNumber=10061)(gidNumber=10065)(gidNumber=10077)(gidNumber=10116))';

Ich habe auch gleich einen Filter für gidNumber=10000 (nur Lehrer) angelegt. Könnte sich auch nochmal als sinnvoll erweisen…

Fazit 1:
LimeSurvey sieht auf jeden Fall sehr gut aus! Da man es in der Konfiguration bei den Plugins auch so einstellen kann, dass sich Schüler per LDAP direkt am Backend anmelden können, hat man damit ein sehr gutes Werkzeug an der Hand, wenn SuS selbst Umfragen erstellen wollen…

Fazit 2:
Man muss ja auch noch überlegen, auf welche Art und Weise die Schüler ihren Zugangsschlüssel erhalten sollen. Wenn man direkt die schulinterne eMail nutzt, gibt es damit keine Probleme. Wenn man die Schlüssel allerdings exportiert, druckt und z.B. beim Zugang zum Computerraum einzeln verteilt, kann man sich den persönlichen Zugangscode auch gleich sparen und eine passende Anzahl dummy-User mit Zugangsschlüssel anlegen lassen… aber weiter oben wurde ja schon diskutiert, dass es durchaus sinnvoll sein kann, dass man bei nicht-anonymen Abfragen gleich die Namen hat.

Schöne Grüße,
Michael

Tobias · 15. April 2019 um 05:05

Hi Michael,

ich kriege das mit LDAP-auth nur gerade folgendermaßen hin:

LDAPplugin-aktivieren
LDAP mode „search+bind“ und man muss „mail“ angeben und dort muss eine e-mail-adresse im LDAP sein, sonst sagte er sowas wie „credentials ok, but could not create user“

server                  | "ldaps:\/\/server.humboldt-gymnasium.ka.schule-bw.de"        |
|  2 |         4 | NULL  |     NULL | ldapport                | "636"                                                        |
|  3 |         4 | NULL  |     NULL | ldapversion             | "3"                                                          |
|  4 |         4 | NULL  |     NULL | ldapoptreferrals        | "0"                                                          |
|  5 |         4 | NULL  |     NULL | ldaptls                 | "1"                                                          |
|  6 |         4 | NULL  |     NULL | ldapmode                | "searchandbind"                                              |
|  7 |         4 | NULL  |     NULL | userprefix              | null                                                         |
|  8 |         4 | NULL  |     NULL | domainsuffix            | null                                                         |
|  9 |         4 | NULL  |     NULL | searchuserattribute     | "uid"                                                        |
| 10 |         4 | NULL  |     NULL | usersearchbase          | "ou=accounts,dc=humboldt-gymnasium,dc=ka,dc=schule-bw,dc=de" |
| 11 |         4 | NULL  |     NULL | extrauserfilter         | ""                                                           |
| 12 |         4 | NULL  |     NULL | binddn                  | ""                                                           |
| 13 |         4 | NULL  |     NULL | bindpwd                 | ""                                                           |
| 14 |         4 | NULL  |     NULL | mailattribute           | "mail"                                                       |
| 15 |         4 | NULL  |     NULL | fullnameattribute       | "displayName"                                                |
| 16 |         4 | NULL  |     NULL | is_default              | ""                                                           |
| 17 |         4 | NULL  |     NULL | autocreate              | "1"                                                          |
| 18 |         4 | NULL  |     NULL | automaticsurveycreation | "1"                                                          |
| 19 |         4 | NULL  |     NULL | groupsearchbase         | ""                                                           |
| 20 |         4 | NULL  |     NULL | groupsearchfilter       | ""                                                           |
| 21 |         4 | NULL  |     NULL | allowInitialUser        | "1"

ich habe in der Tat ein valides Zertifikat für den LDAP-server.

Meine Fragen:

Wie sieht die Konfiguration bei dir aus?
hast du sie nur in der ldap.php stehen oder per webfrontend gemacht. denn obige optionen habe ich nicht in der ldap.php gefunden sondern nur über das webfrontend machen können.

ich finde es generell seltsam, dass man die Konfigurationen über die Dateien machen kann - und diese auch nicht ignoriert werden, wie mir scheint, aber dass man dann über das webfrontend weitere Konfigurationen macht, die aber nicht in den config-dateien sondern in der db gespeichert werden…

VG, Tobias

Tobias · 15. April 2019 um 10:48

Hi @Michael,

jetzt noch mal ausführlicher, was momentan in limesurvey geht und was nicht, aus meiner Sicht:

Mich beschleicht das Gefühl, dass die ldap.php nur dafür da ist, Benutzer/Token aus LDAP zu generieren und nicht, um eine Authentifizierung von Umfrageadministratoren zuzulassen. Dafür scheint wiederum alleinig das LDAP-Plugin zuständig zu sein. Beides ist auf einer Seite im Manual dokumentiert, nur meine Vermutung nicht.
Benutzer hinzufügen als Umfrageadministratoren:
- das geht nur über die LDAP-Plugin-Konfiguration übers webfrontend, allerdings geht das auch ziemlich simple direkt in datenbank reinzuhauen (siehe auszug letzter post). Sobald ich nur „simplebind“ einstelle, kann ich als administrator auch keine benutzer manuell hinzufügen.
- und ich kann mich auch nicht als neuer LDAP-benutzer anlegen durch anmelden, wenn „simplebind“ eingestellt ist.
- stellt man „searchandbind“ ein, egal ob übers webfrontend oder direkt in die datenbank reingehauen, dann kann man sich als neuer LDAP-Nutzer anmelden oder der Administrator kann einen hinzufügen.
- sind dann die Benutzer erstmal in der Datenbank, dann kann ich auch mit „simplebind“ den Benutzer authentifizieren - das ist sehr merkwürdig. Im Zweifel lieber auf „searchandbind“ lassen.
Benutzer in der Token-Datenbank verwenden: da bin ich noch nicht so weit wie du, wie man das am besten voreinstellt, aber so viel dazu:
- dafür ist die ldap.php da
- du hast das per skript für die gidNumber pro Klasse geregelt.
- diese Anleitung hier: LDAP settings - LimeSurvey Manual suggeriert allerdings, dass das was du willst, ohne irgendwelche skripte (und das wäre ziemlich einmalig, denn weder moodle noch nextcloud oder andere machen so was) geht:
  
  these queries use a first LDAP search that looks for LDAP groups entries and get their members. These members values are then used in a user search filter to search for corresponding entries. Thus another parameter must be configured to define the user attribute in the user’s entry that should match the member UID found in the groups.
  
  auf deutsch: du wählst einen filter für die gruppe, z.B. „cn=5a“, sagst noch was „member“ bedeutet, z.B. $ldap_queries[$query_id]['groupmemberattr'] = "memberuid" dann noch sagen, wie dieselbe ID in einem Benutzereintrag gefunden werden kann: $ldap_queries[$query_id]['useridattr' ]= "uid"
für lmn7 und Anbindung an AD könnte das einfacher werden, aber im Zweifel geht es auch so wie oben, denke ich.

Fazit: Wenn ich mit meinen Tests recht habe, dann kann man die Token-LDAP-Geschichte relativ automatisiert in einem docker-container anlegen, so dass eine linuxmuster.net Schule z.B. für jede Klasse und jedes Projekt aus der lmn 6.2 einen Auswahlfilter für Umfragen hat.
Die Lehrer (oder auch und Schüler) als Umfrageadministratoren so anzulegen, dass sie sich gleich mit Schulkonto einloggen können geht nur über „searchandbind“ mit den nötigen Firewallregeln für Port 636 und der Info, ob selbst-zertifizierte oder global-zertifizierte LDAP-Server im Einsatz sind.

Puh, mal sehn, ob ich das in den Osterferien hinbekomme…

VG, Tobias