das hört sich gut an
Hi!
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.
VG, Thomas
Hi Thomas,
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
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
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.
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?
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
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