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.
die kvno wird wohl bei jedem domainjoin hochgezählt, wobei immer die letzten zwei in krb5.keytab gespeichert bleiben.
Für den Workaround habe ich jetzt herausgefunden wie man einen User anlegt, der das Recht hat Computer in die Domäne zu bringen:
samba-tool user create dom-admin 'Joinit!' --given-name=Domainjoin --surname=Admin --description='Unprivileged user for domain join'
legt einen User dom-admin mit Passwort Joinit! an
samba-tool delegation add-service dom-admin CN=Computers,DC=LINUXMUSTER,DC=LAN
verschafft ihm das Recht zum Domänenbeitritt.
ich hab ein Linux-Image erstellt und ausgerollt. Dann Windows gestartet und dann wieder Linux.
Hat bisher alles geklappt.
Ich teste aber noch weiter… Windows-Image erzeugen …
Gruß,
Mathias
bei mir leider nicht. Anmeldung mit Linux funktioniert auf beiden Clients. Mit dem geklonten Windows 10 funktioniert die Anmeldung wg. Vertrauensstellung nicht. Auf dem Client, von dem ich das Windowsimage gemacht habe, klappt die Anmeldung. Sieht so aus, dass der Maschinenaccount des geklonten Windows durch das Patchen der msDS-KeyVersionNumber kaputt geht.
Hallo Thomas,
in meinem Test habe ich Windows zunächst aus der Domäne genommen, im dem ich Windows in die Workgroup WG genommen habe. Nach einem Neustart habe ich Windows wieder in die Domäne aufgenommen, ein Image erstellt und hochgeladen. Das hat funktioniert.
Mein Windows ist ein Windows 10 Pro Version 2004 und nicht nicht aktivieret.