PC12 (Master-Image) Linux gesynct und neu in die Domäne aufgenommen - Login funktioniert!
PC09 & PC10 gesynct und Linux-Domänenanmeldung überprüft - Login funktioniert!
PC09 - smb.conf gemäß Tipp von @Blair angepasst - reboot - Login funktioniert!
PC10 - mittels „linuxmuster-cloop-turnkey“ die /etc/krb5.keytab angepasst - Login funktioniert!
PC12 - Windwos10 gestartet und angemeldet
PC12 & PC09 Linux Login NICHT mehr möglich (@Blair - die neue Option in der smb.conf ändert nichts. Schade!)
PC10 (der mit der neuen keytab) - Login funktioniert!!! (mehrfach getestst mit Win10 Logins zwischendurch)
So weit so gut. Damit haben wir den eindeutigen Zusammenhang zwischen einer Windows-Domänenanmeldung auf PC12 und dem Ausfall der Domänenanmeldung auf allen Rechneren, die PC12 in der /etc/krb5.keytab stehen haben!!!
Nun der kritische Test: Kann ich mich auf PC10, wo die Domänenanmeldung noch immer funktioniert (und wo nun korrekterweise auch PC10 in der keytab steht), auch dann noch unter Linux anmelden wenn ich DORT einen Domänenlogin unter Windows mache?
Die Antwort lautet JA.
Ich will es vorsichtig so ausdrücken: Eine Problemlösung (besser ein Workaround) scheint zu sein auf allen Linux-Clients direkt nach dem Sync einen neuen Domänenbeitritt mittels linuxmuster-cloop-turnkey durchzuführen.
Dieser neue Beitritt sorgt dafür, dass die keytab mit dem korrekten Rechnernamen neu erzeugt wird. In dieser Konfiguration scheint es dann resilient gegenüber Windows-Domänenanmeldungen zu sein.
Ich formuliere das mit Vorsicht, da es erst an einem Rechner getestet ist. Ich muss das am Mittwoch noch mit allen Rechnern im Computerraum testen, bin aber guter Hoffnung.
@rettich
Es bleibt allerdings noch die Frage warum bei dir Mathias auf LMN6.2 die keytabs alle identisch sind und es dennoch funktioniert! Ist der Fehler vielleicht schon alt, wirkt sich aber erst in der neuen LMN7 oder auf aktuellen Win10-Clients negativ aus?
Ich sitze hier in der Schule an der lmn7 früher in der lmn6.2 haben sich die Windows-Clients an der Domäne angemeldet und die Linux-Clients habe über LDAP die Anmeldung geprüft. Da ist keiner dem Anderen in die Quere gekommen.
Heute sind beide in der Domäne. Selbst wenn’s funktioniert hat das Nachteile.
Bei einem Laptop, der hauptsächlich im WLAN ist. Wird der Passwort-Hash beim Starten nicht aktualisiert. Die Folge wäre, dass die Anmeldung immer nur auf einem System klappt. Jedenfalls so lange, bis der Client beim Start mit einem Netzwerkkabel am Schulnetz hängt
Ich will es vorsichtig so ausdrücken: Eine Problemlösung scheint zu sein
auf allen Linux-Clients direkt nach dem Sync einen neuen Domänenbeitritt
mittels linuxmuster-cloop-turnkey durchzuführen.
… ich habe noch eine andere Lösung: man führt den Domänenbeitritt mit
einem virtuellen Linuxclient durch, an dem sich nie jemand an Windows
anmeldet … könnte auch klappen, oder hab ich da was falsch verstanden.
Ach ja, eines ist mir gerade noch aufgefallen.
Beim Absetzen von „linuxmuster-cloop-turnkey“ auf PC10 (der noch immer brav unter Linux und unter Win10 funktioniert) ist es zu einer Fehlermeldung gekommen:
Joined 'PC10' to dns domain 'linuxmuster.lan'
Installing server certificate ... mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
cp: Aufruf von stat für '/var/lib/samba/sysvol/linuxmuster.lan/tls/cacert.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden
umount: /var/lib/samba/sysvol: nicht eingehängt.
Success!
Also ein Cloop auf einem Rechner erzeugen, wo kein Dual-Boot Win10 drauf ist und das dann im Netz verteilen??
Das werde ich am Mittwoch testen! Das hätte den Vorteil, dass man die Rechner dennoch automatisch syncen kann und nicht nach jedem Sync wieder Domänenbeitritte machen muss.
So, heute habe ich auf einem Reserve-PC (PC22) Windows entfernt, unter Bionic auf dem selben PC ein neues Image erzeugt und dieses auf alle 16 Rechner im Computerraum hochgeladen.
Ich kann mich jetzt an allen Rechnern unter Linux anmelden.
Ich habe mich dann auf PC12 unter Windows angemeldet und abgemeldet. Bislang hat das die Linux-Anmeldung außer Kraft gesetzt!
Dann nochmal an den Linuxrechnern die Domänenanmeldung getestet und - siehe da - et funzt
@baumhofDein Workaround scheint zu klappen - JUCHUUUU
So weit war ich noch nie!!!
Morgen werden ich es noch intensiver mit allen Rechnern testet und dann melde ich mich noch einmal.
Ich habe es gerade mit einer Klasse an allen Rechner getestet.
Die SuS haben sich alternierend unter Linux/Win10/Linux angemeldet.
Es hat auf 15 von 16 Rechnern funktioniert.
Ein einziger Linux-Rechner verweigerte die Domänenanmeldung unter Linux allerdings beim zweiten Versuch aber das ist dann wohl ein anderes Problem… wobei es mich wundert… gleiche Hardware, gleiches Image… hmmm
Ein einziger Linux-Rechner verweigerte die Domänenanmeldung unter Linux
allerdings beim zweiten Versuch aber das ist dann wohl ein anderes
Problem… wobei es mich wundert… gleiche Hardware, gleiches Image… hmmm
vielleicht stimmte bei dem die Systemzeit im BIOS noch nicht und der
linuxclient braucht ein paar Minuten um das zu korrigieren.
Hat er das korrigiert, dann hält das auch eine Weile.
Hast du Windows umgestellt, dass es UTC im BIOS erwartet und nicht
localtime?
Sonst setzt Windows die BIOS Zeit immer auf localtime während alle
anderen (linbo/linux) UTC erwarten und das wiederrum auf UTC setzen…
Hallo Mathias,
hast du ebenfalls das Win10-cloop und das Bionic-Cloop auf demselben Rechner erstellt oder zumindest mit identischen Hostnamen unter Linux/Windows?
Ich vermute, dass so wenig User den Fehler gemeldet haben da diese die Cloops in VMs oder mit unterschiedlichen Namen erstellt haben…
LG
Ralf
schön, dass ihr Lösungen gefunden habt. Ich hab noch ein paar Fragen:
Dass in der krb5.keytab immer Daten des MAsterclients stehen, war mir schon bekannt. Ich habe nur Linuxclients und dort ist das (bisher) kein Hindernis gewesen: scheinbar war bei mir eine Domänenanmeldung immer möglich.
Du führst jetzt „turnkey“ aus und dann hast du auf dem client jeweils scheinbar eine „korrektere“ keytab?
du stellst noch „machine password timeout = 0“ in smb.conf
Ist das deiner Beschreibung nach jetzt hinreichend für die Lösung deines Problems?
Ich würde gerne das systematisch analysieren. Bisher ist das alles symptomatisch, wir doktorn so lange rum, bis es funktioniert. Wenn jemand hier oder in einem anderen Thread schon mehr Erkenntnis über das „Warum funktioniert es so?“ hat, wäre ich für Tipps dankbar.
Ich muss jetzt auch doktorn, weil bei mir bei reinen Linuxclients sporadisch die Domänenanmeldung nicht mehr funktioniert, daher wäre ich über jede tiefere Erkenntnis dankbar.
VG, Tobias
Ich muss jetzt auch doktorn, weil bei mir bei reinen Linuxclients
sporadisch die Domänenanmeldung nicht mehr funktioniert, daher wäre ich
über jede tiefere Erkenntnis dankbar.
da würde ich erstmal nach der systemzeit schauen: das war bei mir das
Problem von sporadisch aus der Domäne gefallenen Linuxclients.
Stell sicher, dass die mit dem server reden können (der timedatectl oder
wie das Ding heißt) und dass sie das auch tun.
Erst wenn es das nicht ist würde ich nach komplexeren Dingen schauen wie
der key Datei.
Hallo Tobias, sorry wegen der späten Antwort aber ich habe eine Weile nicht im Forum gelesen.
Zu deinen Punkten…
zu 1) Das habe ich versucht, es hat nicht zu einer dauerhaften Lösung geführt.
zu 2) das „machine password timeout“ hat gar nichts gebracht.
zu 3) Nein, beide Punkte haben das Problem nicht gelöst
Die Problemlösung bestand darin NICHT auf dem gleichen Rechner das Win10 und das Linux-cloop mit gleichem Rechnernamen zu erstellen und hochzuladen.
Ich hatte das für beide Systeme auf PC12 gemacht. Die Linux-Domänenanmeldung fiel dann reproduzierbar aus, sobald sich ein Windows-Client im Netz anmeldete.
Nun habe ich einen isolierten Rechner für das Linux-Cloop (PC22), auf dem auch kein Windows läuft. Das Windows-cloop wird nach wie vor auf PC12 gepflegt.
So funktioniert es mit beiden Systemen. Die keytab auf den Linuxsystemen ist nach wie vor bei allen Clients identisch (PC22).
Hilft dir diese Beschreibung um den Fehler zu finden?
Klasse. DAs ist doch super ausführlich.
Zu wissen, was nicht funktioniert ist genauso wichtig, wie anders rum, sonst rät man anderen ja auch falsche Sachen auszuprobieren.
Hallo zusammen,
ich habe letztens im Unterricht auch noch einen Grund für ein fehlschlagendes Anmelden gefunden:
viele meine Clients im selben Raum (alle im subnet 10.16.16.x) haben den „server“ mit 172.17.0.1 aufgelöst. Mir ist völlig unklar woher das kommt. Ich habe schnell mal „dhclient devicename“ laufen lassen, ob das von einem DHCP kam und die nachfolgende Auflösung von „server“ war korrekt.
ich habe einen rogue DHCP-server im Netz im Verdacht, kann aber jetzt, abends, keinen finden.
Bei den betroffenen PCs konnte ich sssd durch neustarten nicht dazubringen, dass die SuS sich anmelden konnten, weil der Server scheinbar weiterhin offline war. Vermutlich muss der cache gelöscht werden. Da half dann ein reboot.
Mein zweiter Verdacht ist, dass ubuntu evtl. bei schlechtem Kontakt zum Server beim Booten irgendeine Vermutung über die korrekte Auflösung von „server“ anstellt, die dann mehr oder weniger persistent bleibt.
Die Historie hier war: Ich habe im selben Raum einen Laptop mit rsync gesynct (viel traffic) und außerdem auf dem VM-host des Servers durch weiteres Kopieren vermutlich eine hohe IO-Bandbreite benutzt, ob die Last auf dem Server auch betroffen war, kann ich leider nicht rekonstruieren. Zeit für ein Monitoringsystem…
Hi Holger,
ja, weiterhin unerklärlich: auf dem server läuft docker, auf dem client klar nicht. außerdem habe ich noch einen (bzw. mehrere) docker im DMZ stehen und keinen dezidierten docker irgendwo in grün (außer dem server). docker network ls und docker network inspect bridge bringt tatsächlich das 172.17.0.0 netzwerk auf der bridge und ip -br addr list zeigt auch den server als gateway mit der ip 172.17.0.1, allerdings ist das interface „down“…
in den Herbstferien mach ich mal einen RAM-check auf dem server(host) und bestelle bei der Stadt einen neuen Server, mir reicht es jetzt mit Stochern im Heuhaufen.
