Wieder Vertrauensstellung / AD

Clientpflege Windowsclient
1

Hallo zusammen,

ich habe in den Ferien mit LM7.1 zwei neue PC-Räume installiert (Einmal mit Fujitsu-PCs, einmal mit Lenovo-Notebooks, beidesmal mit Win10Pro). Dabei habe ich mit zwei Hardwareklassen das gleiche Win10-EFI-Image genutzt. Vorgehen laut der aktuellen LM71-Doku inkl. Win10Reg-Patch und Image-Patch.
Nachdem die Räume nun gut laufen, möchte ich zusätzlich die bestehenden Klassenzimmer-Laptops (anderes Lenovo-Modell) ebenfalls mit dem LM7-Win10-Image nutzen. Dazu habe ich eine dritte Hardwareklasse erstellt, welches das gleiche Image nutzt.
Das Verteilen hat auf zwei Test-Geräte ohne Probleme funktioniert:
Erst habe ich die zusätzlichen Geräte im LM7 unter Geräte aufgenommen mit Name und LAN-IP-Adresse, dann über PXE/Linbo partitioniert, neu gestartet, über Linbo/torrent das Systemimage auf gespielt (rot Starten).
Allerdings zeigen beide Testgeräte beim Domainlogin
„Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“.
Was ich geprüft habe:
Das Datum/Uhrzeit passt.
PCs nochmal aus der Geräteliste gelöscht und neu eingetragen
Images mehrfach neu über „rot Starten“ sauber neu „entpackt“.
Problem bleibt bestehen.

Was funktioniert:
Einen der beiden neuen Clients im Windows manuell aus der Domäne nehmen, neu starten und wieder manuell in die Domäne aufnehmen. Nach anschließendem Neustart klappt der Domänen-Login.

Ich könnte nun diesen manuell erneut aufgenommenen Client abziehen und als neues Image nutzen.
Ich habe nur die Befürchtung, dass dann die PCs in den beiden schon funktionierenden PC-Räume mit diesem Image vielleicht Probleme beim Domänen-Login bekommen können. Auch weil mir unklar ist, was das Problem ausgelöst hat und ob damit das Problem dauerhaft behoben ist.

Hier im Forum-Archiven wird bei dem Problem u.a. geraten das Geräte-Passwort am Client mit mtaman und am Server neu zu setzen. Allerdings hat sich in den letzten 5 Jahren viel geändert und ich nehme an, dass diese Vorgehensweise bei LM7.1 nicht mehr stimmt.

Kann man am Client und Server prüfen woran der Domänen-Login scheitert bzw. was zwischen AD-Server und Client nicht stimmt?

Viele Grüße,
Tom

2

Hallo Tom,

schau Dir mal die einzelnen Rechner an. Haben die alle den gleichen Rechnernamen? Wenn ja, dann kommt die image.reg nicht bei den Rechnern an.

Gruß

Alois

3

Hallo Tom,

bitte schick mal die zwei Zeilen aus der
/etc/linuxmuster/sophomorix/default-school/devices.csv

Was auch sein kann: das Windows kennt die Netzwerkkarte der Lenovos noch
nicht und installiert die im Hintergrund: ist aber noch nciht fertig,
wenn du dich anmelden willst.

Ich gehe bei solch einer Imagevereinheitlichung immer so vor, dass ich
das vorhandene Image von HWK A auf einen Client von HWK B aufspiele und
mcih dann als lokaler Admin anmelde und nachschaue, ob alle Treiber
installiert sind.
Sind sie das (gegebenenfalls nach dem Nachhelfen), erstelle ich ein
neues Image und spiele es auf die alte HWK (einen Client) zurück um zu
schauen, ob das noch funktioniert.
Funktioniert das, dann ist die Vereinheitlichung abgeschlossen.
Anmelden sollte klappen (wenn die IPs und die Rechenernamen der neuen
Clients ordentlich sind).

LG

Holger

4

Hallo Holger,

hier die beiden Zeilen aus der Devices:

E11;PCE11-Lehrer;Win10EFILenovoV330;48:2a:e3:25:23:16;10.0.11.100;;;;classroom-teachercomputer;;1;;;;;
E10;PCE10-Lehrer;Win10EFILenovoV330;48:2a:e3:25:11:92;10.0.10.100;;;;classroom-teachercomputer;;1;;;;;

Ich habe einen GPO, dass die Anmeldung erst bei bestehender LAN-Verbindung erfolgen soll. Nach dem Booten wartet der Laptop auch etwas bevor der Login kommt und zeigt dann auch das Netzwerksymbol im Login.

Hallo Alois,
die Rechnernamen sind eindeutig. Die Laptops haben allerdings ein LAN und ein WLAN-Interface. Ich habe die LAN-MAC/IP im LM7 aufgenommen. Eventuell werden ich später noch mit separaten Namen die WLAN-IP eintragen, damit ich die IPs besser zuordenen kann bei Logfiles etc.

5

Ich habe zum verifizieren, dass mit dem Image alles ok ist, das Image nochmal per Linbo auf einen PC aus dem funktionierenden PC-Raum frisch aufgespielt. Hier geht der Domain-Login nach wie vor sofort nach dem klonen.

Ich habe nun für einen der problematischen Klassenzimmer-Lenovos als lokaler Admin alle Lenovo-Treiber installiert. Danach funktionierte der Domänen-Login (wie zu erwarten) immer noch nicht.
Ich erstelle jetzt damit ein neues Images um einerseits zu testen, ob dieses Image dann auf den PC-Raum Rechner auch Ärger macht und andererseits ob dieses Image mit allen Treiber dann vielleicht nach dem klonen den Domänen-Login erlaubt.

Kann man das, was Linbo nach dem Klonen mit der Domänen-Einbindung automatisch durchführt irgendwie händisch anstoßen?

Viele Grüße,
Tom

6

Hallo Tom,

E11;PCE11-Lehrer;Win10EFILenovoV330;48:2a:e3:25:23:16;10.0.11.100;;;;classroom-teachercomputer;;1;;;;;
E10;PCE10-Lehrer;Win10EFILenovoV330;48:2a:e3:25:11:92;10.0.10.100;;;;classroom-teachercomputer;;1;;;;;

ich rate von der Verwendung von Großbuchstaben in Computernamen und
Hardwareklasse ab.

Linux ist Case Sensitiv: Windows manchmal nicht: das gibt ein
kudelmuddel der dir ab und zu auf die Füße fallen kann.
Wie ist den der Rechnernamen in den Laptops nach dem Syncen?
Mit Großbuchstaben und KLeinbuchstaben wie bei dir?
Oder nur klein oder nur Groß?

Ich würde das in der devices.csv ändern, und zwar so:

  1. beide Zeilen auskommentieren und
    linuxmuster-import-devices
    machen.

  2. Dann Kommentarzeichen wieder entfernen und alle Großbuchstaben klein
    machen.
    Dann wieder:
    linuxmuster-import-devices

  3. Cleint mit „neu+start“ syncen lassen

Wenn die Anmeldung nicht klappt unter linbo nachschauen ob neben dem
Image.qcow2 auch die .macct Datei vorliegt.

Ist deine funktionierende Gruppe den in der selben Hardwareklasse
(Win10EFILenovoV330) oder benutzen die nur das selbe Image?

LG

Holger

7

Hallo Holger,

danke für den Hinweis wg. Case-sensitiv.
Ich probiere deinen Vorgehen bei nächster Gelegenheit.

Eine macct-Datei hat das Image (es existieren inzwischen ca. 7 Generationen im Backup-Unterordner, alle mit identischer macct-Datei). Das gleiche Image wird auch für die beiden anderen HW-Klassen verwendet.
Die beiden funktionierenden HW-Klassen heißen „Win10EFIFujitsu“ (Anfangs Win10EFI-Fujitsu-EDVRaum, dann hattest Du mir bei einem andern Problem den Tipp gegeben auf Bindestriche zu verzichten) und „Win10EFI-Lenovo-Klasse“.

Ich habe auch schon das syncen der Problem-Laptops über die Klasse „Win10EFI-Lenovo-Klasse“ probiert (nur das Partitionieren klappt mit der Klasse nicht, da die NVMes kleiner sind). Das Ergebnis war das gleiche. Anmeldung an der Domäne nicht möglich wg. Vertrauensstellung.

Nach dem Syncen stimmen die Rechnernamen (habe aber nicht auf groß/klein geachtet). Ich prüfe das bei nächster Gelegenheit.

Viele Grüße
Tom

8

Hallo Holger,

ich habe die Rechnernamen und Hardwareklasse nun mit Kleinbuchstaben neu erstellt:
Die beiden problematischen Test-Notebooks aus den Klassenzimmern heißen jetzt
und pce10-lehrer und pce11-lehrer
die HW-Klasse dazu win10efilenov330

Ich habe (nach Deiner Empfehlung) die beiden Rechner aus der devices.csv genommen, importiert, mit neuem Namen wieder eingetragen, wieder importiert.
Außerdem habe ich vorher in der Hardware-Klasse die Cache-Partition von unendlich/Rest auf 85 GB geändert, da Windows mit „Rest-Größe“ ja oft Probleme hat und dies der einzige Unterschied zur originalen HW-Klasse war.
Nach dem Partitionieren und „rot starten“ ist der Rechnername im Windows korrekt klein geschrieben, die Domäne ist groß geschrieben (letzteres identisch zu den funktionierenden PCs).
Ein Domänen-Login ist leider wieder trotz allem mangels Vertrauensstellung nicht möglich.
Was mir bei diesen Notebooks auffällt, ist, dass das Wiederherstellen der Windows-Partition aus dem Cache ab 90% extrem langsam geht. Die LAN-Übertragung der ca. 20 GB in den Cache ist meist in 3 Minuten erledigt, das Formatieren und Wiederherstellen läuft auch anfangs recht flott, aber insgesamt braucht der Vorgang dann doch eine gute halbe Stunde. Auf den Fujitsu-PCs im EDV-Raum braucht das nur ein paar Minuten obwohl beide Geräte NVMes haben. Ich weiß nicht ob dies etwas bedeuten kann oder nur daran liegt, dass die Laptops einfach älter sind.

Ein Image, welches ich von diesem Problem-Notebook erstellt habe (inkl. der LenovoV330-Treiber), funktioniert übrigens problemlos mit Domänen-Login auf einen der Fujiitsu-PCs im EDV-Raum.

Ich bin ein wenig ratlos woran das Problem bei den V330-Notebooks noch liegen kann.

Bin für jeden Tipp dankbar.

Viele Grüße,
Tom

9

Hallo Tom,

Systemzeit auf den Problemgeräten stimmt? Wie genau?
Ist die .macct Datei auch im Cache dieser Geräte?

Vergleich auch mal die image.log Dateien von einem Problemgerät und
einem funktionierenden.

Hast du das „mit Lenovotreiebern“ Image für die Tests genommen?

Ist dein Netz gesubnettet?
Welche Netzwerkmaske hast du den am Server?

Versuch mal einen Client in den IP Range der funktionierenden zu nehmen
und dann mit neu+start zu syncen.

LG

Holger

10

Hallo Holger,

danke für deine Unterstützung.

Die Systemzeit im Linbo stimmt auf die Sekunde mit dem Server überein.

Die .macct-Datei befindet sich weder auf der Cache-Partition der Problem-Geräte noch auf den funktionierenden Geräten. Sollte sie dort sein?
Am Server:

ls -al /srv/linbo/images/win10/
total 23816764
drwxr-xr-x 3 root root        4096 Sep 20 17:25 .
drwxr-xr-x 4 root root        4096 Aug 25 12:01 ..
drwxr-xr-x 8 root root        4096 Sep 19 14:48 backups
-rw-rw-r-- 1 root root 24386469888 Sep 19 14:42 win10.qcow2
-rw-rw-r-- 1 root root         573 Sep 19 13:51 win10.qcow2.desc
-rw-rw-r-- 1 root root         148 Sep 19 14:42 win10.qcow2.info
-rw------- 1 root root        3070 Sep  6 15:51 win10.qcow2.macct
-rw-rw-r-- 1 root root     1860742 Sep 19 14:44 win10.qcow2.torrent
-rw-rw-r-- 1 root root         505 Sep 20 17:25 win10.reg

Am problematischen LenovoV330 im Cache:

pce10-lehrer: ~ # ls -al /cache/
drwxr-xr-x    6 root     root          4096 Sep 21  2022 .
drwxr-xr-x   18 root     root           560 Sep 21  2022 ..
drwxrwxr-x    4 root     root          4096 Sep 19 07:54 boot
-rw-rw-r--    1 root     root            24 Sep 21  2022 hostname
drwxrwxr-x    2 root     root          4096 Sep 21  2022 icons
-rw-r--r--    1 root     root        984928 Sep  9 07:21 ipxe.efi
-rw-rw-r--    1 root     root          3125 Sep 21  2022 linbo.log
-rw-r--r--    1 root     root       4180160 Sep  8 17:04 linbo64
-rw-r--r--    1 root     root            33 Sep  8 17:04 linbo64.md5
-rw-r--r--    1 root     root      16864712 Apr 12 16:36 linbo_gui64_7.tar.lz
-rw-r--r--    1 root     root            33 Apr 12 16:36 linbo_gui64_7.tar.lz.md5
-rw-r--r--    1 root     root            33 Apr 12 16:36 linbo_gui64_7.tar.lz.md5.bak
-rw-rw-rw-    1 root     root      24468257 Sep  9 07:21 linbofs64.lz
-rw-r--r--    1 root     root            33 Sep  9 07:21 linbofs64.lz.md5
drwxr-xr-x    2 root     root          4096 Sep 21  2022 linuxmuster-win
drwx------    2 root     root         16384 Sep 19 07:54 lost+found
-rwxr-xr-x    1 root     root           990 Sep 21  2022 start.conf
-rw-r--r--    1 root     root          1597 Sep 21  2022 update.log
-rw-r--r--    1 root     root     24386469888 Sep 19 14:42 win10.qcow2
-rw-rw-r--    1 root     root             0 Sep 19 14:42 win10.qcow2.complete
-rw-rw-r--    1 root     root           573 Sep 19 13:51 win10.qcow2.desc
-rw-rw-r--    1 root     root           148 Sep 19 14:42 win10.qcow2.info
-rw-rw-r--    1 root     root       1860742 Sep 19 14:44 win10.qcow2.torrent
-rw-rw-r--    1 root     root           505 Sep 20 14:30 win10.reg

Auf den funktionierenden Fujitsu-PCs (der Arbeitsplatz mit dem letzten Image-Test ist leider gerade in Nutzung, daher ist hier der Cache von einem identischen PC mit dem vorherigen Image und daher unterscheidet sich die Größe der qcow2-Datei):

PCE01-13: ~ # ls -al /cache/
drwxr-xr-x    6 root     root          4096 Sep 21  2022 .
drwxr-xr-x   18 root     root           560 Sep 21  2022 ..
drwxrwxr-x    4 root     root          4096 Sep  6 17:13 boot
-rw-rw-r--    1 root     root            20 Sep 21  2022 hostname
drwxrwxr-x    2 root     root          4096 Sep 21  2022 icons
-rw-r--r--    1 root     root        984928 Sep  9 07:21 ipxe.efi
-rw-rw-r--    1 root     root          4305 Sep 21  2022 linbo.log
-rw-r--r--    1 root     root       4180160 Sep  8 17:04 linbo64
-rw-r--r--    1 root     root            33 Sep  8 17:04 linbo64.md5
-rw-r--r--    1 root     root      16864712 Apr 12 16:36 linbo_gui64_7.tar.lz
-rw-r--r--    1 root     root            33 Apr 12 16:36 linbo_gui64_7.tar.lz.md5
-rw-r--r--    1 root     root            33 Apr 12 16:36 linbo_gui64_7.tar.lz.md5.bak
-rw-rw-rw-    1 root     root      24468257 Sep  9 07:21 linbofs64.lz
-rw-r--r--    1 root     root            33 Sep  9 07:21 linbofs64.lz.md5
drwxr-xr-x    2 root     root          4096 Sep 21  2022 linuxmuster-win
drwx------    2 root     root         16384 Sep  6 17:13 lost+found
-rwxr-xr-x    1 root     root          1003 Sep 21  2022 start.conf
-rw-r--r--    1 root     root          1314 Sep 21  2022 update.log
-rw-r--r--    1 root     root     20463484928 Sep  6 17:17 win10.qcow2
-rw-rw-r--    1 root     root             0 Sep  6 17:17 win10.qcow2.complete
-rw-rw-r--    1 root     root           510 Sep  6 15:23 win10.qcow2.desc
-rw-rw-r--    1 root     root           148 Sep  6 15:47 win10.qcow2.info
-rw-rw-r--    1 root     root       1561442 Sep  6 15:48 win10.qcow2.torrent
-rw-rw-r--    1 root     root           505 Sep  6 17:14 win10.reg

Die Image.logs unterscheiden sich anscheinend nur darin, dass der problematische Lenovo noch die UUIDs wieder herstellen musste, da er neu partitioniert war und der funktionierende Fujitsu schon die passenden UUIDs hatte.

Ich habe für den letzten Test das erweiterte „Lenovo-Treiber-Image“ von einem der beiden problematischen Lenovo-Test-Laptops genommen. Am Fujitsu klappte auch damit der Domänen-Login, am anderen Lenovo klappte es weiterhin nicht.

Das Netz ist ein 10.0.0.0/16 ohne Subnetze. Die Aufteilung ist nicht in Subnetzen, sondern nur logisch, indem ich das dritte Byte für die Raumnummern nehme, als Zimmer E01 = 10.0.1.x, Zimmer E08 = 10.0.8.x. Netzmaske ist immer /16, also kein Routing innerhalb des LANs.

LG,
Tom

11

Hallo Tom,

Die Systemzeit im Linbo stimmt auf die Sekunde mit dem Server überein.

das ist leider die falsche Stelle: es geht um die Systemzeit unter Windows.

Gibt es den eine .macct Datei auf dem Server?

LG

Holger

12

Hallo Holger,

der Server und Linbo laufen auf UTC, im Windows ist es +2, also ebenfalls auf die Sekunde genau und entspricht auch der realen Zeit.
Ein net time \server zeigt auf allen PCs die lokal time (+2) z.B. 12:53:56 und am Server die GMT z.B. 10:53:56. Die Zeiten sind also bei Fujitsu als auch LenovoV330 synchron.

Die .macct-Datei befindet sich auf dem Server:

-rw------- 1 root root        3070 Sep  6 15:51 win10.qcow2.macct
13

Ich nehme einen der problematische Laptops jetzt mal manuell aus der Domäne und dann wieder in die Domäne auf und ziehe ein neues Image. Dann teste ich, ob sich dieses Image auf den Problem-Laptops verteilen lässt. Wenn das klappt, habe ich halt zwei Images zu pflegen.
Ich geb Bescheid was heraus kommt.

LG
Tom

14

So, das neue erstellte Image, welches auf Lenovo#1 einen Domain-Login erlaubt (nach dem ich das Gerät auf dem alten Image manuell aus der Domäne entfernt und wieder aufgenommen habe) habe ich auf den Server hochgeladen. Die entspr. .macct-Datei unterscheidet sich wie erwartet von der bisherigen.
Dieses Image, bringt leider nach dem Partitionieren+Sync auf Lenovo#2 wieder eine fehlende Vertrauensstellung.

15

Hallo Tom,

die Idee aus der Dom raus, reboot, wieder rein, reboot+Image erstellen
war gut: das hätte ich auch als nächstes vorgeschlagen.
Dass das nicht hilft ist sehr seltsam.

Was meinst du den mit „+2“ bei der Zeit? 2 Minuten?

Kannst du mal einen problemclient syncen (immer neu+start nehmen) und
dann 5 Minuten warten bevor du dich das erste mal versuchst an zu melden?

und dann nochmal ganz genau schauen, wie der Rechnernamen ist und wie
die Domain heißt…

LG

Holger

16

Hallo Holger,

mit +2 meinte ich UTC/GMT+2, also die lokale Zeitzone welche zwei Stunden weiter ist als die UTC.
Windows arbeitet per default ja mit lokal Zeit.

LG
Tom

17

Hallo Tom,

mit +2 meinte ich UTC/GMT+2, also die lokale Zeitzone welche zwei
Stunden weiter ist als die UTC.
Windows arbeitet per default ja mit lokal Zeit.

das ist ja schön.
Auch deine andere Aussage war schön:
„der Server und Linbo laufen auf UTC, im Windows ist es +2, also
ebenfalls auf die Sekunde genau und entspricht auch der realen Zeit.“

… ich bin mir aber trotzdem nicht sicher, ob die beiden nun die selbe
Zeit anzeigen, oder nicht… kann natürlich an mir liegen: dann tut es
mir Leid.

Haben Server und Client den die selbe Zeit?

LG

Holger

18

Hallo Holger,

Ich interpretiere die Angaben so, dass die Zeit identisch ist. Der Ubuntu-Server gibt die Zeit lediglich mit der Zeitzone UTC an und damit ist der Zahlenwert zwei Stunden zurück, der Windows Client gibt sie in unserer Zeitzone an CEST.

Mir ist gerade aufgefallen: Die Linbo-Zeit war eh unsinnig zu prüfen, da diese immer identisch mit dem Server ist und nicht der BIOS/HW-Clock entspricht.
Um ganz sicher zu sein, werde ich bei nächster Gelegenheit noch die BIOS-Zeit eines funktionierenden Win-Client und eines der Problem-Clients vergleichen.

LG
Tom

19

Hallo Holger,

die BIOS-Uhren der funktionierenden und nicht funktionierenden Rechner weichen um ca. 30 Sekunden ab. Server, funktionierende und nicht funktionierende Clients haben also auf eine halbe Minute genau die gleiche Zeit.

LG
Tom

20

Ich bin etwas perplex:
Ich habe heute als erstes den Server aktualisiert (Linbo4.0.35 auf Linbo4.0.38). Ich hatte dies etwas hinausgezögert, da beim letzten Linbo-Updates alle Stand-PC-Clients beim Linbo-booten einmal hingen und vor Ort ausgeschaltet werden mussten.
Seit jetzt können sich die „Problem-Laptops“ nun auch mit dem normalen Image an der AD anmelden.
Ich finde im Changelog von Linbo keinen Punkt der die Behebung des Problems erklären könnte.
Ich denke ich nehme das jetzt mal als geschenkte Lösung.

Danke an alle für die Hilfe bei der Ursachen-Forschung.

Lg
Tom