Hallo Holger,
Ja, auch nach synchronisiertem Start nicht.
Gruß,
Mathias
Hallo Thomas,
vielen Dank schon mal für den Tipp.
Ich bin noch an der Schule und komme heute nicht mehr dazu, etwas auszuprobieren. Ich melde mich wieder, wenn ich mehr weiß…
Gruß,
Mathias
Hallo Thomas,
Vielen Dank für den Tipp. Der Befehl liefert mir die Attribute des Rechner-Accounts.
Eigenartig ist, dass die Rechner mal unter CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan und mal unter CN=LC-R01,OU=info,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan zu finden sind.
Eine Frage, die für mich immer noch offen bleibt, ist:
Wo wird der MAccT auf dem AD gespeichert (Attribute unicodePwd und supplementalCredentials )? Diese Attribute kann ich nirgends finden.
Da frage ich auch mal nach.
Nochmals vielen Dank für deine Tipps.
Gruß,
Mathias
Das passiert wenn du der Domäne mit einem Rechner beitritts welcher nicht schon existiert. Linuxmuster legt die Computeraccounts unter der Schule im Zweig Verzeichnisse an.
Neue Geräte welche einfach der Domäne beitreten landen aber (ADStandard) direkt im Root unter Computers.
Das unicode Passwort wird in den Maschinenaccount$ der Arbeitsstation geschrieben, so wie thomas das auch schon weiter oben beschrieben hat.
ldbsearch --url /var/lib/samba/private/sam.ldb "(&(sAMAccountName=lcr01$)) | grep unicode"
Das muss nach dem Starten aus Linbo dem entsprechen was in deiner macct Datei steht.
Hallo Till,
so ein Problem hatte ich auch schon mal. Leider konnte ich die Ursache nicht reproduzieren. Gefühlt lag es daran, dass der PC einem anderen Raum zugewiesen wurde, aber das Computerkonto nicht verschoben bzw. gelöscht wurde.
Das war aber schon ein paar Versionen her.
Nachdem ich alle Computerkonten im AD gelöscht habe, Import-Devices gestartet habe, ging es wieder.
Viele Grüße
Mcteefax
Hallo Andreas,
jetzt wird doch einiges klarer 
Vielen Dank!
Sobald ich wieder zuhause bin probiere ich das mal aus.
Gruß,
Mathias
Das ist auch nach wie vor ein Bug, hierzu ist auch seit längerem ein Issue offen, ich denke Rüdiger wir das bei Gelegenheit auch mal Fixen.
Das Problem ist hier dass die Computeraccounts nicht ordentlich in den OUs verschoben werden. Der Workaround ist den Eintrag aus der Devices.csv zu entfernen, einzulesen und wieder hinzuzufügen.
Damit fehlt aber auch erstmal das Maschinenpasswort welches per Linbo neu gesetzt werden muss.
Das ist für unsere Schule leider kein gangbarer Weg. Wir haben einige Rechner in den Naturwissenschaftenm, auf denen Windows laufen sollte. Und die würde ich gerne mit Linux und mit Windows versorgen. Und unter Windows wirklich nur die Software (z.B. Cassy und Robo Pro) installieren, die unter Linux nicht läuft.
Es wäre super, wenn das noch gefixt werden würde.
Für die Anzeige unicodepwd muss der Attributname explizit gesetzt werden:
ldbsearch --url=/var/lib/samba/private/sam.ldb 'sAMAccountName=lcr01$' unicodePwd
VG, Thomas
Hi!
Ich muss auf die oben schon mal erwähnte Problemlösung zurückkommen. MMn spuckt uns hier das Attribut supplementalCredentials in die Suppe. Ich habe das damals auf Anforderung von @jeffbeck implementiert. Aus welchem Grund weiß ich nicht mehr.
@rettich
Versuch mal Folgendes:
- Entferne aus der Datei /usr/share/linuxmuster/linbo/templates/machineacct die beiden Zeilen
replace: supplementalCredentials supplementalCredentials:: @@suppcredentials@@ - Ubuntu booten.
- Mit
linuxmuster-client-adsso-setupneu der Domäne beitreten. - Neustart in Linbo und Image erstellen.
- Windows booten.
- Domänenbeitritt durchführen.
- Neustart in Linbo und Image erstellen.
Danach sind hier die Anmeldeprobleme mit Ubuntu nach Windowsstart weg.
Falls das bei dir auch klappt, mach ich ein neues Paket.
VG, Thomas
Hallo Thomas,
probier ich gleich aus
Gruß,
Mathias
Hallo Thomas,
leider klappt die Anmeldung unter Linux immer noch nicht.
Ich habe vorher überprüft, ob die Attribute unicodePwd und supplementalCredentials korrekt an den AD übertragen wurden. Sie wurden unter Windows und unter Linux korrekt an den AD übertragen.
Für mich sieht das so aus, als ob noch etwas an den AD übertragen werden sollte.
VG,
Mathias
Das verstehe ich jetzt nicht. Wenn du die Anpassung wie beschrieben gemacht hast, steht supplementalCredentials nicht mehr in der macct-Datei drin und kann auch nicht mehr an den AD übertragen werden.
VG, Thomas
Hier ging es um den Workaround wenn ich eine Maschine in eine andere OU verschieben will. Das ist nichts was täglich passiert und hat ja auch weder etwas mit Windows noch Linux zu tun.
Hallo Thomas,
gestern abend war es schon spät. supplementalCredentials habe ich natürlich nicht überprüft (zu viel cut and past).
Der Inhalt der macct-Dateien ist:
root@server:~# cat /srv/linbo/win10.cloop.macct
dn: @@dn@@
changetype: modify
replace: unicodePwd
unicodePwd:: mwquc/BjDb5KHbZPdw9nIA==
-
und
root@server:~# cat /srv/linbo/lmn-bionic-200507.cloop.macct
dn: @@dn@@
changetype: modify
replace: unicodePwd
unicodePwd:: PjPpF1Kvc+qphpcUbwbozQ==
-
also so, wie du erwartet hast.
Ich bin die ganze Sache nochmal durchgegangen (und zwar im ausgeschlafenen Zustand )
Hier die Resultate:
- Die Anmeldung unter Linux hat funktioniert.
- Dann habe ich auf lc-r01 windows gestartet (ohne mich anzumelden)
Eine Anmeldung am anderen Client (also lc-r02) ging nicht mehr?!? - Neustart von lc-r01 in Linux: Anmeldung ging nicht mehr.
- Synchronisierter Start von Linux auf lc-r01 ging nicht mehr.
- Nochmaliger unsychronisierter Start von Windows aul lc-r01. Anmeldung ging nicht mehr.
Das Attribut von supplementalCredentials ist wohl notwendig, damit die Anmeldung in Windows funktioniert.
Was ich überhaupt nicht verstehe ist, dass ein Windows-Start auf lc-r01 die Linux-Anmeldung auf beiden Rechnern (lc-r01 und lc-r02) verhindert.
Gruß,
Mathias
Hallo Mathias,
nach meiner Erfahrung benötigt man die supplementalCredentials nicht. Bei mir hat das schon immer ohne funktioniert. Ich habe die nur reingenommen, weil @jeffbeck das vorschlug. Lt. meinen Netzrecherchen reicht das unicodePwd um den Passworthash eines Benutzers zu sichern und wiederherzustellen.
Ich habe hier ein Testsystem mit zwei UEFI-Client-VMs jeweils mit Windows 10 auf Partition 3 und Ubuntu 18.04 auf Partition 5. Das läuft problemlos ohne supplementalCredentials. Ich kann auf beiden VMs abwechelnd beide Betriebssysteme hin und her starten und immer Domänennutzer anmelden. Die von dir beschriebenen Phänomene kann ich leider nicht nachvollziehen. Evtl. sollte sich das @jeffbeck mal anschauen. Ich habe leider keinen Schimmer, was da schief läuft.
VG, Thomas
Hallo Matthias und Thomas,
meine bisherigen Erfahrungen sind so:
Bei der Migration reicht es das unicodepwd zu füllen. Dann tut die Anmeldung.
(Allerdings nicht jede. An der Schulkonsole tat es damals, am Linuxclient nicht) Nach dem Ändern des Passworts in der Schulkonsole (auch z.B. auf demselben Wert) tat es dann auch am Linux-client und die supplementalCredentials waren im AD da.
Beim Erstellen eines Klassenarbeitsaccounts wird ja das gehashte unicodePwd kopiert. damit die Anmeldung aber dauerhaft, zuverlässig tut, auch die supplementialCredentials. Meines Erachtens braucht man die supplementialCredential in einigen Fällen, aber nicht allen. Welche kann ich leider auch nicht sagen.
Um unicodePwd und supplementalCredentials von einem account zum anderen zu übertragen gibt es den Befehl:
sophomorix-passwd --clone-from-user <user1> --clone-to-user <user2>
LG, Rüdiger
Hallo Rüdiger,
aber für den $-Account reicht das mit dem unicodePwd aus. Auf meinem Testsystem gab es Probleme mit gemischten Windows- & Linux-Clients (s.o.). Also spricht nichts dageben, dass ich supplementialCredentials bei Clonen des $-Account-Passworthashes wieder rausnehme.
Allerdings hat Mathias seltsame Effekte, wo ich vermute, dass die AD-Accounts fehlerhaft sind.
VG, Thomas
Hallo Thomas, hallo Rüdiger,
ich weiß nicht, ob’s was bringt, aber ich hab hier noch log-Datei-Auszüge:
syslog:
Jul 8 22:36:38 lc-r01 [sssd[krb5_child[1663]]]: Cannot find key for host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN kvno 16 in keytab
Jul 8 22:36:38 lc-r01 [sssd[krb5_child[1663]]]: Cannot find key for host/lc-r01.linuxmuster.lan@LINUXMUSTER.LAN kvno 16 in keytab
Jul 8 22:36:40 lc-r01 linuxmuster-client: logout.sh executed
und auth.log
Jul 8 22:40:46 lc-r01 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=rettich
Jul 8 22:40:46 lc-r01 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=rettich
Jul 8 22:40:46 lc-r01 lightdm: pam_sss(lightdm:auth): received for user rettich: 4 (System error)
Gruß,
Mathias
Moin Mathias,
was geben
klist -K -k /etc/krb5.keytab
und
hostname -f
aus?
VG Thomas