WebUntis LDAP Anbindung

Apps & App Center
,
#1

Das How-To https://www.univention.de/blog-de/2018/06/how-to-fuer-anbindung-von-webuntis-an-ucsschool-fuer-single-sign-on-anmeldungen/
beschreibt ja die Anbindung an LDAP und SAML.

Wir wollen im ersten Schritt nur die Benutzerauthentifizierung gegen LDAP realisieren.

Leider spielt WebUntis beim Punkt 1.c nicht mit und erklärt (per Mail), dass sie keine selbst-signierte Zertifikate oder eigene Wurzelzertifikate einspielen und nur offiziell signierte LDAP-Zertifikate unterstützen.

UCS beschriebt ja eine Alternative: kommerzielle Zertifikate
Dazu zwei Fragen:

  1. Gilt letsEncrypt hier schon als kommerzielles Zertifikat (obwohl kostenlos)?
  2. Hat die Sperrung von Port 636 Auswirkungen auf andere Dienste? (verwendet Moodle nicht genau den Port für die Authentifizierung)?

Mit freundlichem Gruß
Holger Jessen-Thiesen

#2

Hallo,

Let’s Encrypt Zertifikate werden mittlerweile von aktuellen Browsern unterstützt, weil es eine anerkannte Certificate Authority ist. Ich nehme deshalb an, dass Let’s Encrypt ausreichend sein sollte.

Gruß, Nico.

#3

Hallo, danke für die Antwort. Ich werde es gerne ausprobieren und hier posten ob es klappt.

Jedoch habe ich immer noch Sorge wegen Frage 2) ob ich bei meinem Produktivsystem nur Moodle oder noch irgendwas anderes nicht erreichbar mache, wenn ich den Port 636 sperre.

Ich habe trotzdem mit Verfahren nach dem How-To angefangen. Dabei ergeben sich erhebliche Differenzen.
1.Setzen Sie den ldaps-Port ausschließlich auf 7636. Achten Sie bitte außerdem darauf, dass Samba nicht auf dem Server installiert ist.
-> 7636 ist standardmäßig der laps-Port, daher nichts umzustellen
-> Unter ucs@school ist standardmäßig der Aktive Directory Domain Controller installiert und wird als Samba in der Übersicht tituliert. Muss dieser deinstalliert werden.
2. entfällt da nichts neu konfiguriert
3. root@ucs:~# ldapsearch -H “ldaps://localhost:636” -D uid=<LDAP-Suchbenutzer>,cn=users,$(ucr get ldap/base) -v -W -LLL uid=Administrator liefert
-> ldap_initialize( ldaps://localhost:636/??base )

Enter LDAP Password:

ldap_bind: Invalid credentials (49)

additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

Das eingegebene Passwort ist natürlich nicht falsch. Ohne die Hostangabe -H “ladps…” funktioniert es, aber mit einem anderen ldap_initialize
ldap_initialize( <DEFAULT> )

Enter LDAP Password:

filter: uid=Administrator

requesting: All userApplication attributes

dn: uid=Administrator,cn=users,dc=info,dc=tm

uid: Administrator
4. stunnel4 ist standardmäßig installiert
5. unter etc/stunnen gibt es bereits eine univention_saml.conf Soll diese ergänzt werden oder ist ist es egal in welche Datei die Zeilen geschrieben werden? In der readme steht das nur .conf ausgelesen werden. Ich habe zum Test dann eine webuntis.conf erstellt.
6. klappt nicht siehe 3.
7. openssl s_client -connect ldap.server:636

140194279809088:error:20087002:BIO routines:BIO_lookup:system lib:…/crypto/bio/b_addr.c:694:Name or service not known

connect:errno=0

Können Sie mir dort bitte weiterhelfen. Danke
Mit freundlichem Gruß
Holger Jessen-Thiesen

#4

Hallo Holger,

zu deiner Frage 2. Der Port 636 soll gar nicht gesperrt werden sondern für WebUntis “frei” gemacht werden. Das liegt daran, dass WebUntis hier meiner Erfahrung nach recht unflexibel bei den Ports war.
Das ist vielleicht in dem Blogartikel etwas missverständlich ausgedrückt. Das werden wir ändern. Wenn derzeit die Authentifizierung von Moodle über den Port läuft müsste das unbedingt beachtet werden. Die Authentifizierung kann natürlich nebeneinander betrieben werden aber man müsste es unbedingt einmal testen.

Wenn Let’s encrypt eingesetzt wird sollten die Pfade in der webuntis.conf angepasst werden:
cert = /etc/univention/letsencrypt/signed_chain.crt
key = /etc/univention/letsencrypt/domain.key
CAfile = /etc/univention/letsencrypt/intermediate.pem

Die grundsätzliche Funktionsweise kann mit folgendem Befehl wieder getestet werden:

root@ucs:~# ldapsearch -H "ldaps://localhost:636" -D uid=<LDAP-Suchbenutzer>,cn=users,$(ucr get ldap/base) -v -W -LLL uid=Administrator

Zu beachten ist jedoch, dass die Variable TLS_CACERT in /etc/ldap/ldap.conf auf /etc/ssl/certs/ca-certificates.crt steht.

Hoffe das hilft etwas weiter
Michel

#5

Danke,

mit den Änderungen klappt es.

Gruß Holger

1 Like
#6

Super! Das freut mich.

Mastodon