bei uns war ein Umzug der Opnsense-Firewall von KVM auf ESX nicht über ein Veam-Backup möglich. Deshalb hat die IT des Schulträgers die Opnsense neu installiert und wir haben ein Konfigurationsbackup eingespielt. Seitdem funktioniert das SSO nicht mehr.
Ich habe das SSO schon neu eingerichtet und eine neue KeyTable erstellt - ohne Erfolg.
Ein Test scheint zu funktionieren:
Password for [...]@[.....]:
OK token=[...]
BH quit command
Im Browser wird allerdings durchgehend der Authentifizierungsdialog angezeigt.
Was mich etwas wundert - wenn ich unter System → Zugang den Benutzer teste, wird folgender Fehler angezeigt:
in der Musterlösung wurde kein Passwort geändert. Die Passwörter in der OPNsense wurden aus dem Konfigurationsbackup wiederhergestellt. Ich glaube nicht, dass es etwas mit Passwörtern zu tun hat.
grundsätzlich, damit SSO geht, muss die Systemzeit von allen drei
beteiligten Rechnern stimmen: server, OPNsense und Client.
Da denkt man oft erst viel zu spät dran.
linuxmuster-linuxclient7 ist das aktuelle paket.
linuxmuster-client-adsso
ist „outdatet“, sollte aber trotdem funktioneiren.
Wenn ihr das aber gerade neu macht, dann würde ich gleich das neue Paket
nehmen.
an die Systemzeit hatte ich auch schon gedacht, weil wir genau das Problem immer mal wieder bei Notebooks hatten, aber die Geräte laufen alle synchon.
Wenn wir ein neues Image erstellen (nach dem Umstieg auf 7.1 und qcow), wollen wir den Linuxclient sowieso komplett neu bauen; dann werden wir auch das neue Paket nehmen.
habt Ihr die Datei, in der das Konfigurationsbackup war, evtl. auf einem Windows-System „geparkt“ und dadurch eventuell die für UNIX-Systeme ab und zu unverträglichen Zeichenschluss-Sonderzeichen (CR/LF) drin ? (Reparieren geht unter Linux mit dem kate-Editor).
Nur so eine Idee.
Die Fehlermeldung deutet auf Zertifikate (RSA). Padding ist das Vorgehen zu kurze Zeichenketten auf für die Verschlüsselung benötigte Blockgröße aufzufüllen.
Kennt die OPNsense das Zertifikat der CA vom LDAP-Server? Ist es auch genau das selbe Zertifikat oder nur ein gleichnamiges?
Hallo Buster,
in diese Richtung hatte ich auch schon gedacht und werde es beizeiten überprüfen. Wir haben den Proxy zunächst einmal deaktiviert und auf den Linux-Maschinen ausgetragen. Ein großer Teil der Geräte hier sind iPads, die den Proxy sowieso nie genutzt haben…
Ergänzung: Irgendwas ist beim Import des Zertifikates schief gegangen - es liegt sicherlich daran.