HILFE! Plötzlich keine Domänenanmeldung unter Win und Linux möglich

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

VG, Thomas

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:

root@lc-r02:~# klist -K -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  17 host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 host/LC-R02@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 host/LC-R02@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0x84bac5813fbebec9b1b7956cf5d80476)
  17 host/LC-R02@LINUXMUSTER.LAN (0x84bac5813fbebec9b1b7956cf5d80476)
  17 host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xcd07f39938e15cfdfa409a6a01caf5aad082a5ec35e5cf4ad81ca4ee046f67f3)
  17 host/LC-R02@LINUXMUSTER.LAN (0xcd07f39938e15cfdfa409a6a01caf5aad082a5ec35e5cf4ad81ca4ee046f67f3)
  17 host/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0x83b44673ac47a417fddff3f6af9013d8)
  17 host/LC-R02@LINUXMUSTER.LAN (0x83b44673ac47a417fddff3f6af9013d8)
  17 restrictedkrbhost/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 restrictedkrbhost/LC-R02@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 restrictedkrbhost/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 restrictedkrbhost/LC-R02@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 restrictedkrbhost/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0x84bac5813fbebec9b1b7956cf5d80476)
  17 restrictedkrbhost/LC-R02@LINUXMUSTER.LAN (0x84bac5813fbebec9b1b7956cf5d80476)
  17 restrictedkrbhost/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0xcd07f39938e15cfdfa409a6a01caf5aad082a5ec35e5cf4ad81ca4ee046f67f3)
  17 restrictedkrbhost/LC-R02@LINUXMUSTER.LAN (0xcd07f39938e15cfdfa409a6a01caf5aad082a5ec35e5cf4ad81ca4ee046f67f3)
  17 restrictedkrbhost/lc-r02.linuxmuster.lan@LINUXMUSTER.LAN (0x83b44673ac47a417fddff3f6af9013d8)
  17 restrictedkrbhost/LC-R02@LINUXMUSTER.LAN (0x83b44673ac47a417fddff3f6af9013d8)
  17 LC-R02$@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 LC-R02$@LINUXMUSTER.LAN (0xd0a2b031926d79bc)
  17 LC-R02$@LINUXMUSTER.LAN (0x84bac5813fbebec9b1b7956cf5d80476)
  17 LC-R02$@LINUXMUSTER.LAN (0xcd07f39938e15cfdfa409a6a01caf5aad082a5ec35e5cf4ad81ca4ee046f67f3)
  17 LC-R02$@LINUXMUSTER.LAN (0x83b44673ac47a417fddff3f6af9013d8)

die KVNO ist immer 17!

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.

Irgendwie hat sich die Situation verändert.

Gruß,
Mathias

Doch, ich. Ich bin ja der TE :wink:
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 :frowning:
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. :frowning:

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.

Gruß,
Mathias

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

Gerade wiedergefunden - vielleicht hilft es dir:

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…

Vielen Dank,

Mathias

Hallo Mathias,

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.

VG, Tobias

Hallo Tobias,

Ja, der läuft:

root@lc-r01:~# service sssd status
● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/sssd.service.d
           └─override.conf
   Active: active (running) since Sun 2020-07-12 20:14:57 CEST; 1min 28s ago
 Main PID: 1850 (sssd)
    Tasks: 4 (limit: 2328)
   CGroup: /system.slice/sssd.service
           ├─1850 /usr/sbin/sssd -i --logger=files
           ├─1851 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain LINUXMUSTER.LAN --uid 0 --gid 0 --logger=files
           ├─1852 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─1853 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jul 12 20:14:57 lc-r01 systemd[1]: Started System Security Services Daemon.
Jul 12 20:14:57 lc-r01 sssd[1850]: response to SOA query was unsuccessful
Jul 12 20:14:57 lc-r01 sssd[1850]: response to SOA query was unsuccessful
Jul 12 20:14:57 lc-r01 sssd[1850]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Jul 12 20:14:57 lc-r01 sssd[1850]: ; TSIG error with server: tsig verify failure
Jul 12 20:14:57 lc-r01 sssd[1850]: update failed: SERVFAIL
Jul 12 20:14:57 lc-r01 sssd[1850]: ; TSIG error with server: tsig verify failure
Jul 12 20:14:57 lc-r01 sssd[1850]: update failed: SERVFAIL
Jul 12 20:15:22 lc-r01 [sssd[krb5_child[1886]: Cannot find key for host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN kvno 44 in keytab
Jul 12 20:15:22 lc-r01 [sssd[krb5_child[1886]: Cannot find key for host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN kvno 44 in keytab

Offensichtlich fehlen da ein paar keys?!

root@lc-r01:~# klist -K -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  42 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 host/LC-R01@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 host/LC-R01@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x97721f850c2585f8eb465ac2297dac95)
  42 host/LC-R01@LINUXMUSTER.LAN (0x97721f850c2585f8eb465ac2297dac95)
  42 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x6314d38a0869b4308100128605679b1aa026493b860344ee85649b16ce78c7d5)
  42 host/LC-R01@LINUXMUSTER.LAN (0x6314d38a0869b4308100128605679b1aa026493b860344ee85649b16ce78c7d5)
  42 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x23e30b8bb18ecbd1dc85550d6b194d2f)
  42 host/LC-R01@LINUXMUSTER.LAN (0x23e30b8bb18ecbd1dc85550d6b194d2f)
  42 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x97721f850c2585f8eb465ac2297dac95)
  42 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN (0x97721f850c2585f8eb465ac2297dac95)
  42 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x6314d38a0869b4308100128605679b1aa026493b860344ee85649b16ce78c7d5)
  42 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN (0x6314d38a0869b4308100128605679b1aa026493b860344ee85649b16ce78c7d5)
  42 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN (0x23e30b8bb18ecbd1dc85550d6b194d2f)
  42 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN (0x23e30b8bb18ecbd1dc85550d6b194d2f)
  42 LC-R01$@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 LC-R01$@LINUXMUSTER.LAN (0x2cb36415571ce620)
  42 LC-R01$@LINUXMUSTER.LAN (0x97721f850c2585f8eb465ac2297dac95)
  42 LC-R01$@LINUXMUSTER.LAN (0x6314d38a0869b4308100128605679b1aa026493b860344ee85649b16ce78c7d5)
  42 LC-R01$@LINUXMUSTER.LAN (0x23e30b8bb18ecbd1dc85550d6b194d2f)

aber vor Windows gings?!?

Gruß,
Mathias

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?

z.B. hier: Problems With Key Version Numbers - Managing Kerberos and Other Authentication Services in Oracle® Solaris 11.2

vielleicht findest du ja einen Weg die keytab zu „refreshen“ ohne dabei der Domäne neu beitreten zu müssen.
VG, Tobias

Hi,

tl;dr

net ads search  -P  '(&(objectCategory=computer)(cn=lc-r01))'  msDS-KeyVersionNumber
kvno LC-R01@LINUXMUSTER.LAN
klist -K -k /etc/krb5.keytab

miteinander vergleichen.

noch ein bisschen ge-entet:


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.

VG, Tobias

Hi,

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.

VG, Thomas

Ergänzende Info zum dom-admin:
Im AD-Account wird dabei folgendes Attribut hinzugefügt
msDS-AllowedToDelegateTo: CN=Computers,DC=LINUXMUSTER,DC=LAN

Hallo Tobias,

klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  49 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 host/LC-R01@LINUXMUSTER.LAN
  49 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 host/LC-R01@LINUXMUSTER.LAN
  49 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 host/LC-R01@LINUXMUSTER.LAN
  49 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 host/LC-R01@LINUXMUSTER.LAN
  49 host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 host/LC-R01@LINUXMUSTER.LAN
  49 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN
  49 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN
  49 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN
  49 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN
  49 restrictedkrbhost/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN
  49 restrictedkrbhost/LC-R01@LINUXMUSTER.LAN
  49 LC-R01$@LINUXMUSTER.LAN
  49 LC-R01$@LINUXMUSTER.LAN
  49 LC-R01$@LINUXMUSTER.LAN
  49 LC-R01$@LINUXMUSTER.LAN
  49 LC-R01$@LINUXMUSTER.LAN

und

net ads search  -P  '(&(objectCategory=computer)(cn=lc-r01))'  msDS-KeyVersionNumber
Got 1 replies

msDS-KeyVersionNumber: 51

Ganz offensichtlich stimmt die KVNo nicht.

kvno LC-R01$@LINUXMUSTER.LAN
kvno: No credentials cache found (filename: /tmp/krb5cc_0) beim Holen des Client-Principal-Namens

lief bei mir nicht…

Gruß,
Mathias

Hallo zusammen,
ich glaube, ich hab die Lösung :slight_smile:
Wir speichern einfach die kvno in der macct-Datei und schreiben beim Start die kvno wieder auf den AD.

Dazu habe ich die Datei /usr/share/linuxmuster/linbo/rsync-post-upload.sh ab Zeile 86 wie folgt verändert:

# save samba passwords of host we made the new image
  LDBSEARCH="$(which ldbsearch)"
  if [ -n "$RSYNC_HOST_NAME" -a -n "$LDBSEARCH" -a -n "$basedn" ]; then
   #  fetch samba nt password hash from ldap machine account
   url="--url=/var/lib/samba/private/sam.ldb"
   unicodepwd="$("$LDBSEARCH" "$url" "(&(sAMAccountName=$compname$))" unicodePwd | grep ^unicodePwd:: | awk '{ print $2 }')"
# Ab hier!!!
   kvno="$("$LDBSEARCH" "$url" "(&(sAMAccountName=$compname$))" msDS-KeyVersionNumber | grep ^msDS-KeyVersionNumber: | awk '{ print $2 }')"
# bis hier...
   suppcredentials="$(ldbsearch "$url" "(&(sAMAccountName=$compname$))" supplementalCredentials | sed -n '/^'supplementalCredentials':/,/^$/ { /^'supplementalCredentials':/ { s/^'supplementalCredentials': *// ; h ; $ !d}; /^ / { H; $ !d}; /^ /! { x; s/\n //g; p; q}; $ { x; s/\n //g; p; q} }' | awk '{ print $2 }')"

   if [ -n "$unicodepwd" ]; then
    echo "Writing samba password hash file for image $image."
    template="$LINBOTPLDIR/machineacct"
    imagemacct="$LINBODIR/$image.macct"
    # sed -e "s|@@unicodepwd@@|$unicodepwd|" -e "s|@@suppcredentials@@|$suppcredentials|" "$template" > "$imagemacct"
# ... und ab hier...
    sed -e "s|@@unicodepwd@@|$unicodepwd|" -e "s|@@suppcredentials@@|$suppcredentials|" -e "s|@@kvno@@|$kvno|" "$template" > "$imagemacct"
# bis hier.
    chmod 600 "$imagemacct"
   else
    rm -f "$imagemacct"
   fi
  fi

Die Datei /usr/share/linuxmuster/linbo/templates/machineacct wurde wie folgt erweitert:

dn: @@dn@@
changetype: modify
replace: unicodePwd
unicodePwd:: @@unicodepwd@@
replace: msDS-KeyVersionNumber
msDS-KeyVersionNumber:: @@kvno@@
replace: supplementalCredentials
supplementalCredentials:: @@suppcredentials@@

Thomas, kannst du dir das anschauen und eventuell mit ins linbo-Paket übernehmen?

Vielen Dank an alle für*s Mitdenken und für die vielen Tipps.

Gruß,

Mathias

Hallo Mathias,

klingt interessant. Hast du das getestet (Domänenbeitritt, Image erstellt, auf zweiten Client ausgerollt, Anmeldung synchronisiert, unsynchronisiert)?

VG, Thomas

Hallo Thomas,

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

Hallo Thomas,
auch mit einem neuen Windows-Image funktioniert alles.
Gruß,
Mathias

Hallo 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.

VG, Thomas

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.

Was man noch testen könnte:
Lösche

replace: msDS-KeyVersionNumber
msDS-KeyVersionNumber:: @@kvno@@

aus der macct-Datei.
Funktionierts dann?

Gruß,
Mathias