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.
ERR: (Invalid attribute syntax) "objectclass_attrs: attribute 'msDS-KeyVersionNumber' on entry 'CN=R100-PC02,CN=Computers,DC=linuxmuster,DC=lan' contains at least one invalid value!" on DN CN=R100-PC02,CN=Computers,DC=linuxmuster,DC=lan at block before line 9
Modify failed after processing 0 records
Hallo Thomas,
noch bin ich in der Schule. Aber ich glaube, einen Fehler gefunden zu haben:
bei objectclass_attrs: attribute 'msDS-KeyVersionNumber' fehlt ein : es sollte objectclass_attrs:: attribute 'msDS-KeyVersionNumber' heißen.
Da es bei mir funktioniert hat, habe ich mir die log-Dateien nicht angeschaut. Sorry.
ich hab die Änderung mal gemacht und dann keine kvno bekommen.
Vergiss meine Mail von vorher…
Jetzt bin ich grade dabei, nochmal ein Image zu ziehen…
Bei mir lief alles ohne Fehler durch.
Jetzt prüfe ich noch, ob ich mich in Lunux und Windows anmelden kann.
Ich melde mich dann,
Hallo Thomas,
ich bekomme den gleiche Fehler in der log-Datei.
Komischerweise kann ich mich aber auf beiden Clients sowohl an Windows als auch an Linux anmelden.
Was ich noch checken möchte ist, ob die KVNO am AD geändert wurde. Das werde ich später machen… Ich muss leider weiter…
Gruß, Mathias
Die kvno wird nicht geändert.
Eigentlich muss das ein einfacher Doppelpunkt sein, denn hinter Doppelten wird ein base64 kodierter Wert erwartet. Aber mit einem Einfachen geht es auch nicht. Das Attribut msDS-KeyVersionNumber ist scheints readonly.
Es sieht so aus, als hätte ich bei den Tests nur Glück gehabt.
Windows scheint die kvno zu ignorieren, Linux leider nicht. Vielleicht kann man auf dem Client Kerberos überreden, wie Windows die kvno zu ignorieren.
Was ich an der ganzen Sache nicht verstehe, ist dass wenn man zuerst Windows in die Domäne aufnimmt, sollte bei der Domänenaufname von Linux die kvno auf dem Linuxclient mit der kvno auf dem Server übereinstimmen. Beim Zurückspielen der Attribute unicodePwd und supplementalCredentials sollte die kvno nicht verändert werden- Damit sollte eigentlich eine Anmeldung in Windows und Linux möglich sein?!?
Gruß,
Mathias
