Ldap und webuntis

hallo zusammen,

wir versuchen gerade unser ldap auch von webuntis lesbar zu machen …

  1. ueber ldaps: da braucht man wohl ein externes zertifikat, das wollen
    wir dann im 2. schritt machen

  2. ueber ldap: braucht man laut webuntis support einen ldap user mit
    leserechten auf den gesamten ldap baum

kann mir jemand einen tipp zum anlegen eines solchen users geben …

gerne auch tipps zu 1) und empfehlungen zu ldap browsern (die nicht die
ganze festplatte zumuellen)

vg

artur (amg ettlingen)

Hallo Artur,

vielleicht hilft das weiter:

http://www.linuxmuster.net/wiki/anwenderwiki:erweiterungen:webuntis_anbinden

Wir setzen hier kein WebUnties ein, deswegen kann ich nicht bestätigen, ob das so klappt, aber ich bin da sehr zuversichtlich :slight_smile:

Vielleicht hilft dir auch dieser Thread weiter:

vG

Hallo Artur,

zuerst musst Du sicherstellen, dass die LDAP-Anfrage vom WebUntis auf Deinen Server funktioniert. Ich habe dies damals erstens vom WebUntis aus probiert mit der Testfunktion der LDAP-Seite und zweitens in den Logs vom IPfire nachgesehen (wie das genau geht, kann ich aus dem Gedächtnis nicht schreiben).

  1. Firewallregel musste erstellt werden
    Kann ich jetzt nicht nachschauen.

  2. LDAP-Anfrage am Server zulassen (LDAPS ist wohl ohne Anpassungen erlaubt)

in der /etc/ldap/slapd.conf
muss der anfragende Rechner unter #Limits Access eingetragen werden.

#Limits Access:

by anonymous peername.ip=abc.def.ghi.jkl.mno auth

Gruß
Alois

Wobei abc.def.ghi.jkl.mno für die IP des WebUntis-Servers stehen muss.


Zu den LDAP-Untersuchungsprogrammen:
Auf dem Server hat mir das schon einmal geholfen:
# smbldap-usershow username

Ich habe in meinem Aufzeichnungen auch noch dies gefunden:

LDAP Admin Tool
unter Ubuntu installiert als linuxadmin in /tmp
Search - Build Filter kann bei Syntax helfen

Habe ich damals als hilfreich empfunden. Installation muss damals wohl auf dem Client gewesen sein und dann verbindet man sich wohl zum Server.


Nun zu dem LDAP-Einstellungen im WebUntis:

Das kann man so machen (war bei uns so mit der PaedML Windows eingerichtet). Mit LMN haben wir das aber ohne diesen Benutzer. Hier einmal ein Screenshot unserer Einstellungen im WebUntis mit Erläuterungen:

  • Die unkenntlich gemachte LDAP-Server-URL wäre dann die öffentliche IP Deiner IPfire-Firewall ldap://abc.def.ghi.jkl.mno:389
  • Der Userfilter greift nur, wenn Du „BaseDn für Benutzersuche“ verwendest. Der Filter musste nach meinen Tests für unsere Umgebung dann so lauten:
    (&(objectClass=posixAccount)((uid={0})(!(gidNumber=10056))))
    (uid={0}) findet alle User, (!(gidNumber=10056) schließt User der gidGruppe 10056 aus. Vermutlich haben viele Admins einen Filter gesetzt, der gar nicht greift, weil sie MusterDN verwenden. Es fällt aber nicht auf, weil ja alle Benutzer über die MusterDN gefunden werden.
  • Die gidGruppe 10056 enthält die Personen, die ein LMN-Login haben, aber nicht auf WebUntis zugreifen dürfen.
  • Außerdem haben wir Personen, die auf WebUntis Zugriff haben, aber keine Lehrer oder Schüler sind z.B. Hausmeister, Sekretariat. Die sind in LMN in einer Extraklasse 0webuntis mit der homeDirectory …/home/students/0…, während Schüler alle in Extraklassen sind mit der homeDirectory …/home/students/k… z.B. kl9a.

Und hier die Zusammenfassung meiner Bemühungen aus der früheren Mailingliste:

aus den ganzen Anregungen konnte nun auch bei uns eine
zufrriedenstellende Lösung gebastelt werden. Die Test waren
erfolgreich.

Die grobe Aufgabenverteilung in den versch. Netzen ist:

VerwNetz: Benutzernamenerzeugung (und Erstkennworterstellung)

PädNetz: Benutzergruppenverwaltung (und damit auch
LDAP-Authentifizierung)

nach ewigem hin und her hat unsere Schulleitung nun für alle Klassen lokal in Webuntis
einen Nutzer angelegt und vergibt jedes SJ neue PW’s…da gibt es im
Webuntis Handbuch auch einen Eintrag dazu… das klappt super.

Dominik

Ich habe zum Glück einen sehr netten und kompetenten Kollegen, der im
Verwaltungsnetz die Schüler anlegt und WebUntis betreut. Wir haben uns
darauf verständigt, dass im Verwaltungsnetz die Benutzernamen von
Lehrern und Schülern verwaltet werden. Ich bekomme jetzt eine
Textdatei für alle SuS mit Loginname und Passwort, so dass ich die SuS
damit direkt als extraschueler anlegen kann (weil man bei denen das
Wunschlogin vergeben kann).

Übrigens ist die Doku für extraschueler.txt unvollständig. Es fehlt
das letzte (6.) Feld: „Kennwort“.
Klasse;Nachname;Vorname;Geburtsdatum;Wunschlogin;Kennwort

Das hat den Vorteil, dass der Benutzername in WebUntis und im
LMN-System immer gleich ist. So ist die Personenidentifizierung beim
WebUntis problemlos.

Außerdem bekommen die neu an der Schule angemeldeten Schüler (bei uns
zukünftige 5-Klässler) schon vor den Sommerferien eine Mappe mit allen
möglichen Infos und da ist dann auch schon der Zugang zu WebUntis
drin, so dass der Stundenplan auch schon in der letzten Ferienwoche
eingesehen werden kann.

aus der Liste hier hatte ich mal den Tipp erhalten die Unterscheidung

zwischen LuL und SuS per unterschiedlichen Pfad des Home zu machen.

Rainer

Das habe ich jetzt auch so verwendet und sogar noch etwas erweitert.
Das war unbedingt nötig, da sonst die Unterscheidung von Schülern und
Schulnahen Personen, die ja auch in Extraklassen sind nicht möglich
gewesen wäre.

Die SuS sind alle in Klassen, die mit kl anfangen und die
Kursschülerklassen haben ku (z.B. kuJ1a). Die schulnahen Personen sind
in Klassen, die mit 0 anfangen.

So kann ich die Gruppen im WebUntis schön den Rollen zuteilen:

Teil des Attributs „homeDirectory“: /home/teachers → Lehrer

Teil des Attributs „homeDirectory“: /home/students/k → Schüler

Teil des Attributs „homeDirectory“: /home/students/0 → Sekretariat

Durch den Userfilter im WebUntis werden Gruppen ausgeschlossen, die
keinen Zugang haben sollen - bei uns schulnahe Personen die nur einem
LMN-Account haben sollen, aber sonst nix.


Hoffe das hilft bei dem komplexen Thema!
Gruß
Stefan

1 „Gefällt mir“

Hallo Artur,

hier noch die fehlenden Infos:

  1. Firewallregel musste erstellt werden:
    Auf das Webinterface der Firewall zugreifen, wie in der Doku beschrieben mit https://10.16.1.254:444
    Dort unter Firewall - Firewallregeln - Neue Regel …

Für LDAPS braucht es genau die selbe Regel noch einmal mit Zielport 636 statt 389.

Unter Firewall - Firewallregeln kann man auch das Logging für die einzelnen Regeln verwalten und unter dem Reiter Logs sich diese ansehen.


  1. Hier die Kopie der entscheidenden Stelle aus meiner /etc/ldap/slapd.conf
    #Limits Access:
    access to attrs=sambaLMPassword,sambaNTPassword,sambaPwdLastSet,sambaPwdMustChange,sambaAcctFlags,userPassword
    by anonymous peername.ip=10.16.1.254 auth
    by anonymous peername.ip=10.16.1.1 auth
    by anonymous peername.ip=127.0.0.1 auth
    by anonymous peername.ip=213.208.138.146 auth

Danach musste der Dienst neu gestartet werden:
# /etc/init.d/slapd restart

Viel Erfolg!
Stefan

hallo stefan,

danke fuer deine sehr ausfuehrliche darlegeung eurer loesung

ich habe letztendlich in /etc/ldap/slapd.conf

den eintrag

by anonymous peername.ip=213.208.138.154 auth

(nslookup neilo.webuntis.com -> 213.208.138.154)

eingetragen und nun klappt es!

artur

Hallo Artur,

das freut mich für Dich! Bitte setzte doch den Haken für “gelöst”.

Gruß
Stefan

Hallo Stefan,

ich habe heute auch einen ersten Versuch unternommen, Webuntis per LDAPS
an den LDAP der LMN anzubinden.

Ich habe mich bei den Einträgen in Webuntis an diese Anleitung gehalten:
http://www.linuxmuster.net/wiki/anwenderwiki:erweiterungen:webuntis_anbinden

zuerst musst Du sicherstellen, dass die LDAP-Anfrage vom WebUntis auf
Deinen Server funktioniert. Ich habe dies damals erstens vom WebUntis
aus probiert mit der Testfunktion der LDAP-Seite

Leider kommt beim Verbindungstest, den man auf der
LDAP-Einstellungsseite in Webuntis machen kann nach langer Wartezeit ein
Timeout.

Versucht man sich als Lehrer auf der Loginseite zu authentifizieren,
heißt es, die Benutzerdaten seien falsch.

Ich weiß diesbezüglich inzwischen auch warum:
Der Stundenplaner hat alle Lehrer in Webuntis als Export aus SVP
angelegt und alle haben derzeit ein Standardpasswort, mit dem klappt die
Anmeldung.

Webuntis berücksichtigt bislang also den LDAP gar nicht.

und zweitens in den
Logs vom IPfire nachgesehen (wie das genau geht, kann ich aus dem
Gedächtnis nicht schreiben).

  1. Firewallregel musste erstellt werden
    Kann ich jetzt nicht nachschauen.

  2. LDAP-Anfrage am Server zulassen (LDAPS ist wohl ohne Anpassungen erlaubt)

    in der /etc/ldap/slapd.conf
    muss der anfragende Rechner unter #Limits Access eingetragen werden.

    |#Limits Access|:

    by anonymous peername.ip=abc.def.ghi.jkl.mno auth

    Gruß
    Alois

Wobei abc.def.ghi.jkl.mno für die IP des WebUntis-Servers stehen muss.

Selbstverständlich ist der LDAP über Port 636 aber erreichbar, das
Belwü-Moodle authentifiziert z.B. auch gegen den LDAP.

Ich habe auch die Webuntis IP in der /etc/ldap/slapd.conf eingetragen
wie du es oben vorschlägst, sowie unser signiertes Zertifikat.

In der Apache-Config ist das Zertifikat so eingetragen:

SSLCertificateFile /etc/ssl/private/server_afs-engen_de.crt
SSLCertificateKeyFile /etc/ssl/private/server_afs-engen_de.key
SSLCertificateChainFile /etc/ssl/private/server_afs-engen_de.cabundle

In der /etc/ldap/slapd.conf habe ich

#TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/ssl/private/server.pem
TLSCertificateFile /etc/ssl/private/server.pem
TLSCertificateKeyFile /etc/ssl/private/server.pem

auskommentiert und

TLSCACertificateFile /etc/ssl/private/server_afs-engen_de.crt
TLSCertificateFile /etc/ssl/private/server_afs-engen_de.crt
TLSCertificateKeyFile /etc/ssl/private/server_afs-engen_de.key

eingetragen.
Hier bin ich allerdings nicht sicher, wie ich das Chainfile eintragen
muss - und vielleicht ist das ja auch schon der alleinige Grund des
Nichtfunktionierens der Abfrage aus Webuntis, dass das Chainfile fehlt.

  • Der Userfilter greift nur, wenn Du „BaseDn für Benutzersuche“
    verwendest. Der Filter musste nach meinen Tests für unsere Umgebung
    dann so lauten:
    |(&(objectClass=posixAccount)((uid={0})(!(gidNumber=10056))))|

Hier sagt das Wiki

(&(objectClass=posixAccount)(!(cn=ExamAccount)))

So habe ich es aktuell eingetragen. Wie hast du diese Tests denn genau
gemacht?

  • Die gidGruppe 10056 enthält die Personen, die ein LMN-Login haben,
    aber nicht auf WebUntis zugreifen dürfen.

Und welche Personen sind das?
Wie kommen die in LMN in diese Gruppe? Extraklasse?

Übrigens ist die Doku für extraschueler.txt unvollständig. Es fehlt
das letzte (6.) Feld: „Kennwort“.
Klasse;Nachname;Vorname;Geburtsdatum;Wunschlogin;Kennwort

Das hat den Vorteil, dass der Benutzername in WebUntis und im
LMN-System immer gleich ist. So ist die Personenidentifizierung beim
WebUntis problemlos.

Heißt das, Webuntis übernimmt nicht einfach die Benutzernamen aus dem
LDAP, sondern kreiert eigene? Nach welchem Muster?

Wir wollen natürlich schon, dass sich alle Benutzer mit genau den Daten
an Webuntis anmelden können, die sie im Schulnetzwerk haben.

Die SuS sind alle in Klassen, die mit kl anfangen und die
Kursschülerklassen haben ku (z.B. kuJ1a). Die schulnahen Personen sind
in Klassen, die mit 0 anfangen.

So kann ich die Gruppen im WebUntis schön den Rollen zuteilen:

Teil des Attributs „homeDirectory“: /home/teachers → Lehrer

Teil des Attributs „homeDirectory“: /home/students/k → Schüler

Teil des Attributs „homeDirectory“: /home/students/0 → Sekretariat

Hm, unsere Klassen beginnen etweder mit r wie Realschule oder mit w wie
Werkrealschule. So bekomme ich die Daten auch aus SVP für das Schulnetz.

Ist das ungünstig?

Viele Grüße
Steffen

Hallo Steffen,

1. Verbindungstest

Probiere es erst einmal über LDAP ohne S - Port 389 bis es klappt, um die Probleme mit den Zertifikaten auszuschließen. Wenn es klappt, kommt kein Timeout-Fehler mehr, sondern wahrscheinlich ein Fehler bzgl. Benutzername oder Kennwort.

Gut - das brauchst Du aber nur für LDAP ohne S. Bei dem Zertifikaten kann ich Dir leider nicht helfen.

2. Userfilter

Den Filter kannst Du genau zum Testen erst einmal genau so verwenden.
(uid={0}) sorgt dafür, dass alle Konten im LDAP, die eine uid besitzen, sich anmelden dürfen.
(!(gidNumber=10056)) würde dafür sorgen, dass die Konten mit dieser gidNumber sich nicht anmelden dürften.

Das sind schulnahe Personen: Hausmeister, Sozialarbeiter, Sekretäre…
Die habe ich tatsächlich in Extraklassen angelegt.
Übrigens habe ich auch alle Schüler in Extraklassen angelegt, da mein Kollege aus SVP die Schülerlisten samt Benutzernamen und Erstpasswörtern erzeugt und ich meine dass man die Benutzernamen nur bei den Extraklassen selbst eintragen kann (und nicht in schueler.txt). Das sorgt dafür, dass die Benutzernamen im Päd.Netz übereinstimmen mit denen in WebUntis, welches die Benutzerdaten auch aus einem SVP-Export erhält.

Nein - WebUntis versucht aus mittels der LDAP-Daten den angemeldeten User einer Person in seiner Datenbank zuzuordnen. Siehe dazu die Grafik weiter oben zur LDAP-Konfiguration im WebUntis.
Das geschieht bei uns dann über
LDAP ID Attribute: uid (=Benutzername im Päd.Netz)
wird verglichen mit
Elementardaten ID Feld: name (=dort ist im WebUntis der Benutzername eingetragen von meinem Kollegen, der SVP und Untis und WebUntis betreut).
Und das stimmt dann eben exakt überein, da beides bei uns ursprünglich aus SVP stammt.

3. Rollenidentifizierung

Kommt darauf an für was Du es genau brauchst. Dafür solltest Du Dir überlegen, welche Gruppen aus dem Päd.Netz welche Rolle in WebUntis zugerdnet bekommen sollen: Lehrer, Schüler oder Andere.
Dann musst Du ein LDAP-Attribut finden, durch welche Du die Gruppen aus dem Päd.Netz unterscheiden kannst für die Zuordnung der Rollen in WebUntis.
Wenn Du nur Lehrer und Schüler hast → kein Problem.
Wenn Du aber - wie ich - noch schulnahe Personen hast, die als Schüler angelegt werden, dann musst Du Dir was einfallen lassen. Aber die LMN7.0 hat ja auch wahrscheinlich mehr Gruppen, da es ja wohl auch die Möglichkeit für mehrere Schularten geben soll - und da könnte man ja einfach die Schulart „Andere“ noch anlegen.

Gruß
Stefan

Hallo Stefan,

hm, dann müsste ich erst mal vom Router über den IPFire überall Port 389 freischalten… mal sehen, ob es nicht auch so klappt, denn es muss imho aus Sicherheitsgründen (Passwörter) ja eh über 636 gehen - oder gar nicht.

ja, das habe ich prinzipiell verstanden, Ich nehme den Filter erst mal wieder raus.

Das hatte ich schon gelsenen, dass du das so machst. Das ist natürlich schlau, sofern man jemanden hat, der das so pflegt :wink:

Eigentlich hätte ich angenommen, das Webuntis, wenn man es an den LDAP anbindet, so wie ja auch Moodle etc. genau die Anmeldedaten (also Benutzername und PW) vom LDAP übernimmt. Das scheint ja wohl nicht der Fall zu sein?!?

Viele Grüße
Steffen

Sorry, hatte den letzten Beitrag schon zu früh unvollendet abgeschickt - bitte nochmal den Rest lesen!

Gruß
Stefan

P.S:

Der Benutzer wird beim WebUntis eben meist nicht bei der Anmeldung angelegt, wie bei Moodle, sondern existiert meist schon, da er ja schon einen Stundenplan hat - hoffentlich!
Daher muss bzw. sollte der gerade angemeldete Benutzer einem schon existierenden zugeordnet werden.

Das wäre ungut, da es kein Ausfiltern ist. Ohne Filter wird nämlich gar kein User gefunden, wenn man nicht ‚MusterDN für Benutzersuche‘ verwendet

Also nimm:
(&(objectClass=posixAccount)((uid={0})))
Das findet alle.
Und lasse ‚MusterDN für Benutzersuche‘ leer, da dies den Userfilter abschaltet.

Gruß
Stefan

Hallo Stefan,

Ich habe nun mal alle Einstellungen gemacht wie von dir weiter oben (hier:
https://ask.linuxmuster.net/uploads/default/original/1X/4abf8b0485afb580357d9993b0c76af1e749dfc0.jpg) gepostet und auch das was du gerade schriebst so eingetragen.

Auerdem habe ich nun doch mal LDAP im Router und IPFire weitergeleitet um ohne LDAPS zu testen (und damit Zertifikatprobleme auszuschließen).
Im IPFire habe ich eine Regel angelegt wie hier
https://ask.linuxmuster.net/uploads/default/original/1X/5106ca5cd2061d24008091c9465a8b5077121d7c.png

Als IP für die Quelle habe ich die IP des Webuntis-Servers (213.208.138.154) eingetragen.
Die Änderungen habe ich übernommen.

In /etc/ldap/slapd.conf steht bereits „by anonymous peername.ip=213.208.138.154 auth“ und der LDAP ist neu gestartet.

Beim Test auf der LDAP-Einstellungsseite von Webuntis bekomme ich aber immer noch „Connection timed out“.

Ich habe dann noch unsere Moodle-IP in /etc/ldap/slapd.conf eingetragen, eine Firewallregel analog der zu Webuntis für die IP des Belwü-Moodles angelegt (und übernommen) und die LDAP-Anbindung von Moodle mal auf ldap statt ldaps gestellt. Dann kann man sich am Moodle als LDAP-User auch nicht mehr anmelden.

Einen Fehler finde ich in der Konfigurationskette für externen Zugriff auf den LDAP (Port 389) nicht.

Langsam gehen mir die Ideen aus…

Viele Grüße
Steffen

Hallo,

ich hatte bei nochmaliger Kontrolle der LDAP-Einstellungen in Webuntis bei Personenrolle noch - wie im Wiki beschrieben - einfach teachers und students. Ich habe das auf die vorgeschlagene Pfadangabe geändert und erhalte nun (bei LDAP über Port 389) eine sofortige Rückmeldung

Als Anmeldedaten habe ich meinen Lehrerbenutzernamen und Passwort des Schulnetzwerks eingegeben.

Über LDAPS kommt nach wie vor lange Zeit keine Rückmeldung, wahrscheinlich wenn man lange genug wartet ein Timeout. Das liegt vermutlich noch am Zertifikat.

Viele Grüße
Steffen

Hallo,

das hier hat mich einen Schritt weiter gebracht:
http://www.linuxmuster.net/forum/post/6540

Ich hatte einen nslookup auf die tipo.webuntis.com, die uns als Zugangs-URL genannt wurde, gemacht und diese IP für die LDAP(s)-Anfragen erlaubt.

Der Blick in die Logs des IPFire offenbarte aber, dass die LDAP-Anfragen von Webuntis von einer anderen IP stammen. Nachdem ich diese eingetragen habe, kommt beim LDAP-Test

Wenn ich es allerdings mit LDAPs versuche, kommt

Daher muss ich mich wohl nochmal ans richtige Einbinden des Zertifikats in die LDAP-Config machen.
Zur Erinnerung:

Allerdings sieht man, dass das Zetifikat auch ein Chainfile besitzt. Ich habe keine Ahnung, wie ich das im LDAP eintragen muss, damit die Zertifikatskette vollständig ist und das Zertifikat akzeptiert wird.

Viele Grüße
Steffen

Hallo Steffen,

probier doch mal, für alles dieselbe Datei zu nehmen, dann sucht sich
der Ldap schon das richtige Zertifikat heraus. Also:

cat /etc/ssl/private/server_afs-engen_de.key > /etc/ssl/private/ldap.pem

cat /etc/ssl/private/server_afs-engen_de.crt >> /etc/ssl/private/ldap.pem

cat /etc/ssl/private/server_afs-engen_de.cabundle >>
/etc/ssl/private/ldap.pem

und dann dieses ldap.pem überall als Zertifikat in der slapd.conf eintragen.

Viele Grüße

Jörg

Hallo Jörg,

probier doch mal, für alles dieselbe Datei zu nehmen, dann sucht sich
der Ldap schon das richtige Zertifikat heraus.

wie immer spitzenmäßig, das funktioniert 1a. Vielen Dank!!

Viele Grüße
Steffen