Hallo zusammen,
habt ihr auf dem Server nach dem Erstellen der Keytab mal den Samba Service neu gestartet (systemctl restart samba-ad-dc)? Ich meine mich zu erinnern, dass ich mal ein ähnliches Problem hatte und das die Lösung war.
Viele Grüße
Christoph
Hallo Christoph,
danke für Deinen Einwurf. Ich wäre sehr glücklich, wenn es das nur wäre und habe das sofort ausprobiert. Leider ohne Erfolg.
Danke,
Jens
Hallo,
ich habe auch das Problem. Gestern ging es noch. Habe keine Updates installiert. Neustart hat nichts gebracht.
Auf die Schnelle hab ich Opnsense auf 22.7.11 zurück gesetzt und Schlüssel neu erzeugt. Nun funktioniert es erst mal wieder.
Viele Grüße
Steffen
Hallo,
ich habe jetzt mal nach einem kurzen Austausch mit Klaus die OPNsense-„Installationsparty“ durchgezogen:
Das alles zunächst gegen einen Test-LMN 7.1-Server. Und hier das Ergebnis:
Dann habe ich auf die neueste Version 23.7.2 (vorgestern am 23.8. released) aktualisiert. Und Überraschung! Funktioniert auch.
Dann habe ich auf meinem Testsystem wieder zu LMN7.2 zurück gewechselt > devices.csv angepasst, usw. Und, zweite Überraschung: funktioniert nicht. Weder auf meinem Testsystem noch auf meinem Produktivsystem. Zur Sicherheit hab ich den 7.2-Server nochmal runtergefahren und 7.1 gebootet > linuxmuster-opnsense-reset: geht wieder.
@steff66: Mit welcher LMN-Version arbeitest Du grad, bei der ja OPNsense 22.7.11 funktioniert?
Sollte da nicht LMN7.2 raus kommen, gibt es m.E. ein neues Problem mit der 7.2, das für den einen oder anderen sicher relevant sein könnte.
Hinweis am Rande: sowohl bei LMN7.1 als auch 7.2 (hat sich vermutlich einfach nicht geändert) funktioniert das automatische Erstellen der keytab-Datei durch linuxmuster-opnsense-reset nicht mehr. Fehlermeldung: Failed to create new kerberos key table. See opnsense-reset.log for details.. Die Datei habe ich dann immer über die UI manuell erstellt. Meist mit Erfolg (s.o.).
Gute Nacht!
Jens
Hallo Jens,
wir arbeiten in der Schule mit LMN7.2 seit 4 Wochen. Aber auch bei 7.1 ist uns das schon passiert. Opensense von 22.7 auf 23.1 Upgrade mit LMN7.1: funktioniert ca 2 Monate problemlos, dann plötzlich SSO nicht mehr möglich.
Opnsense zurück gesetzt auf 22.7 (Backup) wieder Upgrade auf 23.1 funktionierte wieder
Nun Upgrade von 7.1 auf 7.2 und Opnsense 23.1 funktionierte (ca. 4 Wochen)
Und gestern funktionierte SSO plötzlich nicht mehr.
Viele Grüße
Steffen
Hallo zusammen,
nun habe ich durch Vergleich von Logfiles und Ausgaben der OpnSense zumindest mal den Unterschied zwischen dem LMN7.1 und 7.2-Server herausgefunden:
Der LDAP-Eintrag CN=FIREWALL-K,CN=Computers,DC=lmn,DC=linuxmuster,DC=lan hat beim LMN7.2-Server nur einen servicePrincipalName-Attribut, beim LMN7.1-Server zwei:
(der erste Eintrag fehlt beim LMN7.2-Server).
Das führt dazu, dass es das oben von Klaus bereits identifizierte Delta der keytab-Dateien gibt, die generiert werden. V.a. fehlen die Principals HTTP/firewall@LINUXMUSTER.LAN. Und genau diese werden - wie Klaus oben schon geschrieben hat - von der OPNsense genutzt.
Ein Workaround ist damit mit dem LDAP Browser beim LMN7.2-Server einen weiteren servicePrincipalName hinzuzufügen. Damit funktioniert zumindest der Kerberos-Test der OPNsense (sowohl auf meinem Test- wie Produktivsystem). Ob damit dann auch das SSO funktioniert, probiere ich morgen aus.
Die Fragen sind nun für mich:
Gute Nacht!
Jens
Hallo zusammen,
hier noch die fehlende Rückmeldung: mit dem zusätzlichen servicePrincipalName für die Firewall im LDAP (und anschließendem neuen Erstellen der keytab) funktioniert das SSO der Clients wieder. Da hab ich nun wirklich lang dran rumgetüftelt. Danke an alle, die mitgelesen haben und v.a. Klaus und Steffen für ihre Inputs.
Ich habe mir mal erlaubt, damit das im Rahmen der 7.2-Entwicklung nicht abhanden kommt (ich bin ja offenbar nicht der einzige mit dem Problem und 7.1 hatte das Thema noch nicht) dafür ein Issue auf GitHub zu erstellen. Ich hoffe, das ist passt so.
Schönen Tag!
Jens
Danke Jens,
endlich hat diese Grausamkeit ein Ende, dank der Seite samba-tool konnte ich dann auch die Lösung auf dem LinuxMusterServer anwenden:
if ! samba-tool spn list 'FIREWALL-K$' | grep -q '^\s*HTTP\/firewall$'; then
samba-tool spn add HTTP/firewall 'FIREWALL-K$'
fi
Ich häng’ mich hier mal dran.
Ich habe den Befehl mal ausprobiert und kriege eine Fehlermeldung:
root@server:~# if ! samba-tool spn list 'FIREWALL-K$' | grep -q '^\s*HTTP\/firewall$'; then
samba-tool spn add HTTP/firewall 'FIREWALL-K$'
fi
check_spn_alias_collision: trying to add SPN 'HTTP/firewall' on 'CN=FIREWALL-K,CN=Computers,DC=linuxmuster,DC=lan' when 'host/firewall' is on 'CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan'
System ist auch aus einem Upgrade von lmn71 auf lmn72 hervor gegangen.
Kerberos-Anmeldung testen in der onSense-GUI funktioniert - im Browser (Firefox auf Linux) wird aber weiterhin vehement nach Anmeldedaten für den Proxy gefragt…(systemweite Proxy-Einstellungen stimmen - das Anmeldeskript wird also offensichtlich ausgeführt)…
Ideen, was da los ist?
sambatool gibt übrigens aus:
root@server:~# samba-tool spn list 'FIREWALL-K$'
firewall-k$
User CN=FIREWALL-K,CN=Computers,DC=linuxmuster,DC=lan has the following servicePrincipalName:
HTTP/firewall.linuxmuster.lan
HTTP/firewall
Danke,
Guntram
Wie sieht denn der Befehl samba-tool spn list 'FIREWALL$' aus?
Hier stünde bei mir (frische 7.2 Installation):
firewall$
User CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan has the following servicePrincipalName:
RestrictedKrbHost/FIREWALL
RestrictedKrbHost/FIREWALL.linuxmuster.lan
host/firewall.linuxmuster.lan
host/firewall
Möglicherweise ist dort bereits der Eintrag „HTTP/firewall“ falsch hinterlegt worden?
Ich bin mir zwar nicht ganz sicher, aber der Eintrag sollte dann wie folgt gelöscht werden können:
samba-tool spn delete HTTP/firewall 'FIREWALL$'
Der Kerberos Login Name in der OPNsense Firewall unter SSO sollte dann auch wie folgt „FIREWALL-K“ heißen.
Möglicherweise gibt es mit den doppelten Einträgen irgendwelche Identifikationsprobleme.
ACHTUNG:
Bitte nicht host/firewall mit HTTP/firewall verwechseln.
EDIT:
Ich revidiere, die „Fehlermeldung“ erscheint bei mir auch. Der SPN Name wird aber dennoch zu „Firewall-K$“ hinzugefügt.
Aber wie von mir zuvor beschrieben, sehe ich gerade selbst, dass dort host/firewall für „FIREWALL$“ steht. Was das genau bewirkt weiß ich nicht.
Möglicherweise betrifft das aber auch den Fehler bei der Generation der Schlüsseltabelle?:
Error: another computer account (CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan) has the principal host/firewall
Aber der nächste Schritt „Schlüsseltabelle“(de)/„Keytab“(en) wurde ebenfalls durchgeführt?
Was sagt denn Schritt 3? Wird dort von der Firewall das Konto mit einem „OK token“ bestätigt?
PS:
Der global-admin kann in der OPNsense geprüft werden, sollte aber nicht im Betriebssystem genutzt werden.
Hallo!
root@server:~# samba-tool spn list 'FIREWALL$'
firewall$
ERROR: User FIREWALL$ not found
Das klingt nicht gut - oder?
Wie erzeuge ich den User auf richtigem Wege?
Danke,
Guntram
Hallo Guntram,
steht in den ersten Zeilen der /etc/linuxmuster/sophomorix/default-school/devices.csv
den die Firewall mit dem Namen Firewall drin?
Stimmt die MAC Adresse?
Was ist bei dir passiert? Du hast eien neue Firewall hingesetzt?
Ich meine hier im Tread wird beschrieben, was man machen msus.
LG
Holger
Hallo Holger,
ich meine alle hier im Thread beschriebenen Maßnahmen getätigt/geprüft zu haben.
Aber ich kam aus der Kiste irgendwie nicht mehr raus - deswegen jetzt doch komplette Neuinstallation :-(.
Ich weiß aber leider immer noch nicht so recht, was bei mir falsch gelaufen ist. Sehe ich das richtig, dass es ein Problem ist, wenn ich Proxmox-Snapshots von Server und Firewall unabhängig voneinander wieder einspiele? Weil die sich gegenseitig verändern?
Sprich: Snapshots gehen eigentlich nur gleichzeitig von beiden VMs, damit ich sauber bleibe?