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).
Firewallregel musste erstellt werden
Kann ich jetzt nicht nachschauen.
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:
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
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.
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
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).
Firewallregel musste erstellt werden
Kann ich jetzt nicht nachschauen.
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:
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.
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.
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
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?!?
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.
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.
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.
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.