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

thomas · 13. Juli 2020 um 10:21

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

thomas · 13. Juli 2020 um 10:29

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

rettich · 13. Juli 2020 um 12:27

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

rettich · 13. Juli 2020 um 16:48

Hallo zusammen,
ich glaube, ich hab die Lösung
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

thomas · 13. Juli 2020 um 17:36

Hallo Mathias,

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

VG, Thomas

rettich · 13. Juli 2020 um 17:48

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

rettich · 13. Juli 2020 um 19:04

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

thomas · 13. Juli 2020 um 20:39

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

rettich · 14. Juli 2020 um 05:13

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

thomas · 14. Juli 2020 um 07:20

Hallo Mathias,

In rsync-pre-download.log seh ich:

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

Die macct-Datei enthält:

replace: msDS-KeyVersionNumber
msDS-KeyVersionNumber:: 53

Hast du die Fehlermeldung nicht?

VG, Thomas

rettich · 14. Juli 2020 um 09:13

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.

Gruß,
Mathias

thomas · 14. Juli 2020 um 10:07

Versteh ich nicht. Wo sollte es so heißen?
In der macct-Datei steht der Attributname gefolgt von :: drin (s.o.).

VG, Thomas

rettich · 14. Juli 2020 um 11:33

Hallo Thomas,

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,

Mathias

rettich · 14. Juli 2020 um 12:11

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

thomas · 14. Juli 2020 um 13:33

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.

VG, Thomas

rettich · 14. Juli 2020 um 19:39

Hallo Thomas,

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

rettich · 15. Juli 2020 um 12:00

Hallo Thomas,
ich habe in der Zwischenzeit ein bisschen weiter experimentiert:

Ich habe zwei neue Clients lc-r03 und lc-r04 aufgenommen und die Images aufgespielt.

Nach der Rechneraufnahme war kvno = 1

Nach dem Start von Linux war kvno = 2 aber klist -k zeigt KVNO=60 an?!
War aber nicht schlimm, die Anmeldung funktionierte.

Nach dem Start von Windows war kvno = 3.
Die Anmeldung funktioniert.

Nach erneutem Start von Linux war kvno = 4.
Die Anmeldung funktioniert.

Nach erneutem Start von Windows war kvno = 5.
Die Anmeldung fuktioniert.

Die kvno wird also bei jeden Betriebssystemwechsel um ein hochgezählt.

Was für mich völlig erstaunlich ist, dass die kvno von AD und Client doch nicht übereinstimmen muss.

Auf dem Testsystem scheint jetzt alles zu klappen. Leider habe ich keine Ahnung, warum

Gruß,
Mathias

thomas · 15. Juli 2020 um 12:30

Bei mir funktionierts ja auch schon immer.
War bei dem Windows der win10.global.reg-Patch eingespielt?

VG, Thomas

rettich · 15. Juli 2020 um 17:05

Klar, wie es in der Anleitung steht.

Offensichtlich scheint jetzt das Kerberos auf dem Client die kvno zu ignorieren. Ich versuche mich da etwas einzulesen…

Beim aus den ova-Dateien erzeugten Testsystem, funktionierts immer noch nicht. Wenn ich etwas herausfinde melde ich mich wieder.

Vielen Dank nochmal für eure Unterstützung und für eure Tips!!!

Gruß,
Mathias

rettich · 18. Juli 2020 um 14:36

Hallo zusammen,
ich habe in der Zwischenzeit noch ein bisschen herumgespielt. Hier meine Beobachtungen:
Bei einem, aus den ova-Dateien, frisch installiertem System können sich unter Linux keine Benutzer mehr anmelden, sobald ein Windows 10 gestartet wurde. Wenn auf lc-r01 windows 10 gestartet wurde kann man sich auf lc-r02 unter Linux nicht mehr anmelden. Auch ein synchronisierter Start von Linux ändert daran nichts.
Was löst auf dem Server dieses Verhalten aus?

Arbeite ich diese Anleitung durch. Gewht es plötzlich wieder. Allerdings muss man in der win.cloop.macct die Zeilen

replace: msDS-KeyVersionNumber
msDS-KeyVersionNumber:: 47

löschen. Sonst kann man sich unter Windows nicht mehr anmelden.
Und das obwohl man das Attribut msDS-KeyVersionNumber eigentlich nicht überschreiben kann. Es dürfte eigentlich nicht funktionieren? Macht man dann die Änderungen wieder rückgängig, funktioniert trotzdem noch alles. Selbst dann, wenn man neue Images erzeugt?!?

Vielleicht kann sich jemand einen Reim darauf machen und mir einen Tipp geben, was da eigentlich passiert ist.

Liebe Grüße,
Mathias