Das sieht Ok aus. Daǹn müssen wir weiter suchen. Setze mal in /etc/sssd/sssd.conf im Domainabschnitt debug_level = 3
Danach systemctl restart sssd.
Versuch mal einzuloggen und schau dann in /var/log/sssd/sssd_<DOMAIN>.log
Hallo Thomas,
die Ausgabe von tail -f /var/log/sssd/sssd_LINUXMUSTER.LAN.log liefert:
(Thu Jul 9 23:24:05 2020) [sssd[be[LINUXMUSTER.LAN]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
und
root@lc-r01:/etc/sssd# cat /var/log/sssd/krb5_child.log
(Thu Jul 9 23:24:05 2020) [[sssd[krb5_child[1852]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
(Thu Jul 9 23:24:05 2020) [[sssd[krb5_child[1852]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN].
(Thu Jul 9 23:24:05 2020) [[sssd[krb5_child[1852]]]] [get_and_save_tgt] (0x0020): 1732: [-1765328340][Cannot find key for host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN kvno 16 in keytab]
(Thu Jul 9 23:24:05 2020) [[sssd[krb5_child[1852]]]] [map_krb5_error] (0x0020): 1808: [-1765328340][Cannot find key for host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN kvno 16 in keytab]
In der Zwischenzeit habe ich die ova-Dateien für OpnSense und den Server heruntergeladen und ein System neu aufgesetzt. Windows installiert und in die Domäne eingebunden. Linux installiert und in die Domäne eingebunden.
Sobald ein Client Windows startet kann man sich auf dem anderen Client unter Linux nicht mehr anmelden. Das eigenartige Verhalten scheint reproduzierbar zu sein…
Für mich sieht das so aus, als ob beim Start von Windows die Art der Kommunikation umgestellt würde. Und dadurch alle Linux-Clients nicht mehr mit dem AD kommunizieren könnten…
In der Zwischenzeit habe ich die ova-Dateien für OpnSense und den Server
heruntergeladen und ein System neu aufgesetzt. Windows installiert und
in die Domäne eingebunden. Linux installiert und in die Domäne eingebunden.
Sobald ein Client Windows startet kann man sich auf dem anderen Client
unter Linux nicht mehr anmelden. Das eigenartige Verhalten scheint
reproduzierbar zu sein…
Hast du das gleiche Linuximage verwendet wie bei den anderen tests oder
ein frisches default cloop?
Jetzt habe ich mal eine Spur:
In krb5_child.log steht: Cannot find key for host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN kvno 16 in keytab
In der keytab gibt es aber keinen Eintrag mit kvno 16. Alle Einträge haben kvno 14.
Hallo Holger,
Bei meinem Test mit dem neuen Server und der neuen OpnSense habe ich auch ein ganz frisches ubuntu 18.04 genommen.
Ich habe alles ziemlich genau dokumentiert. Leider als odt-Datei über mehrere Seiten. Und hier im Forum kann man ja nur Bilder uploaden.
Das hier kommt aber von dem Image, das wir hier schon die ganze Zeit besprechen (lmn-bionic-200507).
Ich komm nicht dahinter wie das mit dem Windowsboot zusammenhängt, dass die Ubuntuhosts danach quasi aus der Domäne raus sind.
Mit einem Workaround kann ich aber dienen. Nach einem erneuten Domänenbeitritt funktioniert die Anmeldung wieder. Wenn man also dafür sorgt, dass der Host beim Booten der Domäne beitritt, ist alles gut. Das geht so:
Man legt eine Datei /etc/linuxmuster-client/onboot.d/99_domainjoin.sh
mit folgendem Inhalt an:
# joins the ad domain, adjust the global-admin password
net ads join -k --no-dns-updates -U global-admin%'Muster!'
und sichert sichert sie mit chmod 600 ab.
Dann ändert man noch in /etc/systemd/system/linuxmuster-client-adsso.service die Zeile WantedBy=multi-user.target
in WantedBy=multi-user.target sssd.service
Damit ist die macct-Datei für das Ubuntuimage zwar obsolet, schadet aber auch nicht. Den Workaround benötigt man nur für Dualboot-Systeme.
Unschön ist klarerweise, dass das global-admin-Passwort hier im Klartext drinsteht.
Besser wäre es, wir hätte einen Nutzer domadmin, der nur das Recht hätte der Domäne beizutreten. Wie man den anlegt, wissen evtl. @jeffbeck@Maurice@Till
Ein Befehl sophomorix-admin --create-domadmin wäre auch nicht schlecht.
den gibt es derzeit noch nicht. Du kannst nur Schuladmins (keine Domain Admins) sowie global-admins (Domain Admins) via Sophomorix anlegen. Wir hatten neulich aber auch einen Fall bei dem ein Benutzer gut Gewesen wäre der nur PCs aufnehmen kann aber sonst nichts.
Ich schau mal wie sich das am besten umsetzen lässt.
Hallo Thomas,
der Workaround hat bei mir leider nicht funktioniert…
Nach ein paar Versuchen habe ich den Rechner synchronisiert gestartet, um die Änderungen wieder rückgängig zu machen.
Dann habe ich folgenden Befehl als root abgesetzt:
root@lc-r01:~# net ads join -k --no-dns-updates -U global-admin%'GeheimesKennwort'
Using short domain name -- LINUXMUSTER
Joined 'LC-R01' to dns domain 'linuxmuster.lan'
root@lc-r01:~# Connection to lc-r01 closed by remote host.
Connection to lc-r01 closed.
Linux unsynchronisiert gestartet und versucht, mich anzumelden. Das hat komischerweise auch nicht geklappt?!
Meine Beobachtung war ja, dass wenn ein Windows-Client gestartet wurde, eine Anmeldung auf allen Linux-Clients nicht mehr möglich war. Das würde bedeuten, dass alle Clients einen Neustart machen müssten…
Gruß,
Mathias
Diese Meldung habe ich nicht. Da verweigert der Server offensichtlich die Verbindung.
Und das kann ich überhaupt nicht nachvollziehen. Das macht keinen Sinn. Hier müsste ja der Windowsclient auf dem Server einen Prozess triggern, der die Domänenanmeldung für die anderen Clients deaktiviert. Ich habe keine Idee, was das sein könnte. Internetrecherche dazu gibt nichts her. Bisher hat auch niemand sonst diesen Fehler gemeldet. Es muss einen anderen Zusammenhang geben.
Das scheint sehr zeitkritisch zu sein. Es klappt offensichtlich nicht immer, dass der systemd-Prozess von linuxmuster-client-adsso vor dem Start von sssd beendet ist. Mit dieser Anpassung in 99_domainjoin.sh hat es bei mir immer funktioniert:
# joins the ad domain, adjust the global-admin password
net ads join -k --no-dns-updates -U global-admin%'Muster!'
sleep 2
service sssd restart
Hallo Thomas,
in der Zwischenzeit kapiere ich gar nichts mehr?!? Jetzt tuts?!?
Was habe ich gemacht?
Ich habe laut
Von Hand den Fix#100 eingepflegt.
Dein Workaround probiert und wie ich schon geschrieben habe hat’s nicht funktioniert.
Dann habe ich den lc-r02 neu in die Domäne aufgenommen und ein Image gemacht. Anmeldung hat geklappt.
Jetzt wollte ich sehen, was ein Start von Windows auf dem lc-r01 bewirkt. Dazu habe ich vor dem Windows-Start mir das ausgeben lassen:
Dann habe ich auf lc-r01 über Linbo Windows gestartet und noch vor dem eigentlichen Start von Windows lc-r01 „ausgeschaltet“ und die Ausgabe von klist -K -k /etc/krb5.keytab mit der von vorher verglichen. Kein Unterschied (wer hätts gedacht).
Dann habe ich Windows auf dem lc-r01 komplett gestartet. Wieder die Ausgabe von klist -K -k /etc/krb5.keytab auf lc-r02 verglichen. Kein Unterschied.
Jetzt habe ich mich auf lc-r02 als rettich angemeldet. Es hat funktioniert ?!? (das erste mal nach einem Start von Windows).
Dann habe ich mich auf lc-r01 unter Windows angemeldet. Hat wie immer funktioniert.
Dann habe ich auf lc-r01 Linux synchronisiert gestartet. Anmeldung hat funktioniert!!!
Die Ausgabe von klist -K -k /etc/krb5.keytab hat das gleiche Ergebnis wie auf lc-r02 gebracht. Aus LC-R02 wurde nicht LC-R01. Aber es hat funktioniert.
Windows start auf lc-r02 und anschließender unsynchronisierter Start von Linux. Keine Anmeldung möglich.
Synchronisierter Start von Linux auf lc-r02. Anmeldung funktioniert.
Doch, ich. Ich bin ja der TE
Allerdings kann ich gerade nichts zur Problemlösung beitragen wegen Sommerferien (RLP) und Urlaub.
Bei mir war es ebenfalls so, dass der Linux-Login nicht mehr funktioniere sobald der Windows-Login erfolgt war. Ich kann allerdings nicht bestätigen, dass eine einzige Win-Domänenanmeldung gleich alle Linux-Clients gekillt hat. Ich habe es immer nur auf einem Rechner getestet…
Sobald ich wieder in der Schule bin werde ich weiter testen (auch deinen Workaround).
Bis dahin!
Liebe Grüße
Ralf
Hallo zusammen,
In der Zwischenzeit habe ich Fix#100 in das frisch installierte System eingepflegt.
Auf diesem Testsystem habe ich getestet, ob auch hier die Anmeldung in Linux läuft. Leider nicht
Dann habe ich die Clients wieder in mein altes Testsystem übernommen. Ich habe die Client-Festplatten partitioniert -> neustart -> formatiert -> Windows zurückgespielt -> Linux zurückgespielt
Anmelden war nicht mehr möglich.
Nochmal Linux synchronisiert gestartet. Auf lc-r01 war die Anmeldung möglich auf lc-r02 nicht.
Nach einem weiteren synchronisierten Start von Linux war die Anmeldung auf beiden Clients nicht mehr möglich.
Kann es sein, dass das ganze ein Timing-Problem ist?
Das ganze läuft auf meinem Laptop unter Virtual-Box. Damit sind die Rechner entsprechend langsam.
Hallo Matthias.
… als ich das las, klingelte es bei mir: Ich hatte anfangs auch zum Testen nur einen sehr kleinen Server mit wenig Power. Da hatte ich immer das Problem, dass die Ubuntu-Clients zwar hochfuhren, doch der Daemon sssd lief nicht sauber hoch! Daher war dort auch nie eine Anmeldung möglich. Check das doch mal, in dem du auf so einem Client journalctl -xe aufrufst und verfolgst, ob da irgendwelche Dienste nicht wollen.
Seitdem ich die v7-Umgebung auf einem richtigen Server betreibe, sind bei mir diese Probleme verschwunden.
Neben dem sssd waren manchmal übrigens auch andere Dienste betroffen. Ich habe das am Ende auch auf zu wenig Gesamtspeicher geschoben. Beim Hochfahren der einzelnen VMs hatte ich daher auch sehr auf die Reihenfolge und auf den gesamten zur Verfügung stehenden Speicher geachtet …
Das wäre ja 'n Ding, wenn es das auch bei dir ist!
Schöne Grüße,
Michael
Hallo Michael,
vielen Dank für den Tipp. Ich war kurz davor, vom Glauben abzufallen. Bei mir läuft’s nicht und bei fast allen anderen läo, wie ich Ralf verstanden habe, hat er es auch mit virtuellen Maschinen getestet…
ja, schau mal, ob der sssd überhaupt läuft, wenn du dich nicht anmelden kannst.
Wir brauchen hier noch ein valides Testverfahren, sonst können wir in Zukunft bei solchen Loginproblemen immer im Dunkeln tappen.
Solange du vom Server aus per ssh auf den Client kommst, kannst du ja so etwas testen.
Also diese Fehler habe ich auch - auf einem Client der läuft.
Du kannst ohne Anmeldung mal als root mit dem Befehl id <username> checken, ob du eine Rückmeldung bekommst.
Das scheint doch schon das Problem zu beschreiben: der sssd versucht die Schlüssel mit KVNO 44 aus der krb5.keytab zu holen, dort ist man aber erst bei der kvno 42 angekommen.
Dass er nach KVNO 44 fragt, ist halt seltsam und kommt wohl von kerberos. vllt. liegt hier der Hund: Windows zieht ein neues Ticket, damit erhöht sich die Nummer und was in /etc/krb5.keytab steht ist dann nicht mehr gültig.
Ich habe das mal auf meinem Client versucht nachzustellen, dort habe ich KVNO 4 und 5 drinstehen für den host, der das image erzeugt hat. Wenn ich mich als user anmelde (bzw. über die Console ein su - username mache und dann ein „kinit“), dann erhalte ich bei kvno hostname@DOMÄNE die Zahl 2 zurück… häh?
suggeriert, dass Windows die kvno ignoriert und wohl keinen Einfluss auf die kvno hat, wenn die Artikel darin von Microsoft von 2014 noch aktuell sind. Aber vllt. ist das ja dennoch dein Problem, dass aus irgendeinem Grund die kvno hochgezählt wird, in den Lösungen hab ich bei mir:
net ads search -P '(&(objectCategory=computer)(cn=client-wlan))' msDS-KeyVersionNumber
erfolgreich getestet und „client-wlan“ kann ich jetzt durch alle möglichen Hostnamen in meinem Netz ersetzen.
Der Befehl funktioniert auf jedem der Domäne erfolgreich beigetretenen host, also - einen funktionierenden Client im Netz bereithalten für den Befehl. Auf dem Server funktioniert der Befehl bei mir nicht (server ist wohl auch sinnvollerweise nicht der domäne beigetreten).
Der könnte auch unter Windows funktionieren, so dass du „zwischendurch“ auch unter Windows schauen kannst, wie die Zahl ist.
Last but not least: Die Zahl ist wohl mit dem zu vergleichen, was kvno auf dem client ausspuckt. Ich vermute fast, dass der Befehl evtl. bei dir auf dem Client (wenn man sich nicht mehr anmelden kann), gar nichts ausspuckt. Schick das mal.
