Nach Update auf 4.2 Probleme mit SSO

Ich habe mein UCS von 4.1 auf 4.2 geupdatet. Bisher habe ich SSO nicht genutzt.
Nun habe ich Probleme mit dem einloggen per UCS.

Wenn ich nach dem einloggen per SSH auf der Console:
service univention-management-console-server status
eingebe, bekomme ich folgende Fehlermeldung:
ucs python2.7[5716]: saml_msg is too small: minlength = 128

Weiß jemand was das bedeutet, oder in welchen Log-Files ich noch suchen kann?
(in /var/log/univention/management-console-server.log finde ich keinen Fehler)

Tante Google findet bei der Suche nach der Python-Meldung nur einen Eintrag hier im Forum und im Bugzilla, beide aber ohne Hinweis darauf, dass es sich um ein Problem handelt. Es gibt noch einen weiteren Bug, aber auch der sieht nicht nach Ursache des Fehlers aus.

Was ich noch nicht ganz verstanden habe ist der Weg, den Sie auf die Kommandozeile nehmen. Melden Sie sich dann mit einem unter UCS erstellten Konto an, sind also nicht “root”? Reden wir hier wirklich von SSO (single-sign-on) oder doch von SSH (secure shell)?

Auf die Console logge ich mich mit SSH an.
Habe meinen Tippfehler im ersten Beitrag berichtigt.

Der Beschreibung kann ich leider immer noch nicht entnehmen, was konkret nicht funktioniert. Oben steht [quote=“bre, post:1, topic:5820”]
Nun habe ich Probleme mit dem einloggen per UCS.
[/quote]

“UCS” steht für das Produkt Univention Corporate Server. Der bietet einige Möglichkeiten zum Anmelden.

Die weiter zitierte Fehlermeldung kann natürlich mit Ihrem eigentlichen Problem zusammenhängen, aber im Moment sehe ich das noch nicht.

Ich meine das Anmelden an der UCS Web-Oberfläche und dort das einloggen per single-sign-on.

Das Anmeldung per Web-Oberfläche ohne single-sign-on funktioniert.

In der Support Datenbank gibt es zunächst einige Artikel zum Thema, noch für 4.1 geschrieben, aber grundsätzlich m.E. auch auch 4.2 anwendbar.
Single Sign On link on UMC login page is crossed out
Single Sign On setup failed (join-script fails with various errors)

Hinweise könnten auch in management-console-web-server.log sein. Ansonsten hilft es auch generell, den Fehler zu reproduzieren und dann im Logverzeichnis ein “ls- ltr” abzusetzen und sich die unten stehenden (also zuletzt aktualisierten) Dateien anzusehen.

Mastodon