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

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

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 :no_mouth:

Gruß,
Mathias

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

VG, Thomas

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

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

Die stehen da normalerweise auch nicht drin. Das haben wir nur testweise reingeschrieben.

VG, Thomas

Klar, das Attribut msDS-KeyVersionNumber ist readonly. Daher bricht die Durchführung an der Stelle ab…
Aber, nachdem alle Änderungen wieder rückgängig gemacht wurden. Läuft das System wie es soll?!?
Gruß,
Mathias

… und noch eine Beobachtung:
bei einem frischen System mit Windows und Linux, bei dem die beschriebenen Probleme bestehen, funktioniert das Löschen der Zeilen

replace: supplementalCredentials
supplementalCredentials:: sigh lubkhgjdglkhdfgkdf...

nicht. Obwohl ich vermutet hätte, dass ab

replace: msDS-KeyVersionNumber
msDS-KeyVersionNumber:: 47

die Aufsührung des rsync-post-download - Skripts abbricht.

Also für mich leider nicht nachvollziehbar…

Gruß,
Mathias

Lieber Matthias,

ich verfolge seit einiger Zeit diesen thread, weil die Thematik / das Problem hier misteriös und bedeutend ist (finde ich). Leider bin ich, was Samba4 und AD angeht, wenig beschlagen.
Aber das Problem mit den „supplemental credentials“ scheint vielleicht in die Richtung einer Lösung zu gehen, dazu dieser (alte) EIntrag hier:

https://lists.samba.org/archive/samba/2017-April/207671.html

Vielleicht müssen die Entwickler nochmal die Routinen abklopfen, die die Passwortänderungen über ldbmodify betreffen, evtl. liegt hier das Problem.

Gruß
Christoph

Hallo,

ich denke, das hat sich erledigt. War wohl ein spezielles Problem von Mathias’ Setup.
Wenn man es macht, wie es hier dokumentiert ist, funktioniert es.

VG, Thomas

Hallo zusammen,
leider hat es sich noch nicht ganz erledigt. Ich habe das Problem ebenfalls und komme erst im Moment dazu, weiter daran zu arbeiten. In den letzten 6 Wochen war die Schule ferienbedingt zu.

Nun gibt es ja im Thread viele Lösungsansätze aber für mich ist im Moment nicht ersichtlich, was nun tatsächlich den „Durchbruch“ gebracht hat.

Ich habe hier 16 Rechner mit Windows 10 und Bionic. Die Bionic-Anmeldung funktioniert nicht mehr, da ich mich an den Win10 Clients angemeldet habe.

Mein Setup ist ansonsten nicht speziell sondern eher „standard“. Ich habe die fertigen Proxmox-Images von Netzint genommen, das Win10-Cloop von Holger und das Bionic-Cloop aus den servertools.

Was muss ich konkret tun, um die Anmeldung unter Linux wieder zu ermöglichen?

Hier mal ein paar Daten:

[linuxadmin@PC09 ~]$ sudo klist -K -k /etc/krb5.keytab 
[sudo] Passwort für linuxadmin: 
(pam_mount.c:365): pam_mount 2.16: entering auth stage
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  22 host/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 host/PC09@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 host/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 host/PC09@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 host/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x69777436ff56ae828b4f2556ee5ca3eb)
  22 host/PC09@LINUXMUSTER.LAN (0x69777436ff56ae828b4f2556ee5ca3eb)
  22 host/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x47e01565ce2ad5be3064f18ba9cc8e231bf36c2b7fbacfc5354da77f482b7ac2)
  22 host/PC09@LINUXMUSTER.LAN (0x47e01565ce2ad5be3064f18ba9cc8e231bf36c2b7fbacfc5354da77f482b7ac2)
  22 host/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x293c22a9a42177616a3cfa5ad6bb69e2)
  22 host/PC09@LINUXMUSTER.LAN (0x293c22a9a42177616a3cfa5ad6bb69e2)
  22 restrictedkrbhost/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 restrictedkrbhost/PC09@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 restrictedkrbhost/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 restrictedkrbhost/PC09@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 restrictedkrbhost/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x69777436ff56ae828b4f2556ee5ca3eb)
  22 restrictedkrbhost/PC09@LINUXMUSTER.LAN (0x69777436ff56ae828b4f2556ee5ca3eb)
  22 restrictedkrbhost/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x47e01565ce2ad5be3064f18ba9cc8e231bf36c2b7fbacfc5354da77f482b7ac2)
  22 restrictedkrbhost/PC09@LINUXMUSTER.LAN (0x47e01565ce2ad5be3064f18ba9cc8e231bf36c2b7fbacfc5354da77f482b7ac2)
  22 restrictedkrbhost/pc09.linuxmuster.lan@LINUXMUSTER.LAN (0x293c22a9a42177616a3cfa5ad6bb69e2)
  22 restrictedkrbhost/PC09@LINUXMUSTER.LAN (0x293c22a9a42177616a3cfa5ad6bb69e2)
  22 PC09$@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 PC09$@LINUXMUSTER.LAN (0x61c16b3776bf29a4)
  22 PC09$@LINUXMUSTER.LAN (0x69777436ff56ae828b4f2556ee5ca3eb)
  22 PC09$@LINUXMUSTER.LAN (0x47e01565ce2ad5be3064f18ba9cc8e231bf36c2b7fbacfc5354da77f482b7ac2)
  22 PC09$@LINUXMUSTER.LAN (0x293c22a9a42177616a3cfa5ad6bb69e2)
(pam_mount.c:133): clean system authtok=0x562e79c85b00 (1073741824)

[linuxadmin@PC09 ~]$ hostname -f
PC09.linuxmuster.lan

@rettich
Was hat bei dir die Lösung gebracht? Kannst du das noch nachvollziehen?

Vielen Dank vorab und Grüße
Ralf

Hallo Ralf,
ich bin zur Zeit noch im Urlaub. Insofern kann ich nicht konkret werden.
Beim Starten eines Clients wird der Passworthash des AD und von Kerberos zurückkopiert. So gesehen sollte die Anmeldung funktionieren. Hat sie leider nicht.
Ich habe dann wild experimentiert und festgestellt, dass wenn ich in der linux-macct Datei den Kerberis-Hash lösche, dass dann die Anmeldung klappt.
Leider klappt sie in der Zwischenzeit nicht mehr.
Da nur ich und noch jemand aus der Liste dieses Problem zu haben schien, dachte ich, dass es vielleicht daran liegt, dass ich mein Testsystem mit Virtual-Box auf meinem Laptop simuliert habe und der Server nicht genug Speicherplatz bekommen hat.
Nächste Woche möchte ich dann anfangen, die lmn7 in der Schule zu installieren. Und da wird der Server dann genug RAM haben.
Wenn sich jetzt Meldungen häufen, dass es mit Dualboot Probleme gibt, macht mir das Sorgen.
Ich geh’ mal davon aus, dass dein Server genug RAM hat.
Ich bin gespannt, wie’s mit diesem Problem weiter geht…
Gruß,
Mathias

Hallo Ralf,
ich weiß, es ist schon ein bisschen Arbeit, aber könntest du folgendes tun:

  • Nimm einen Linux-client nochmal in die Domäne auf (Linuxmuster_client_adsso oder so ähnlich)

  • Starte den Client neu, erzeuge ein neues Cloop und lade es gleich hoch.

  • Verteile das Image auf die Rechner im Raum.

Wenn du jetzt Linux startest, sollte alles funktionieren.

Was passiert, wenn du auf einem Client Windows startest?
Bei mir (unter Virtualbox mit dem wenigen Speicher) hat bei den Clients, auf denen ich mich bereits angemeldet habe das SSO nicht mehr funktioniert.
Unter Linux konnte ich mich auf keinem Client mehr anmelden.
Ist das bei dir genauso?

Ich weiß, das ist viel Arbeit, aber es könnte den Entwicklern helfen.

Gruß,
Mathias

Hallo Mathias,
vielen Dank für deine Hilfe!
Mein Server ist ein guter (neuer) Dell-Server mit 64Gb-Ram.
Dort läuft Proxmox als Hypervisor und die LMN7-VM hat 4Gb Ram. Davon sind 2.61Gb dauerhaft genutzt. 4Gb scheinen also für den virtuellen Linuxmuster-Server locker auszureichen.

Ich habe deine Anleitung umgesetzt.

Nach der (erneuten) Aufnahme in die Domäne und Image-Erstellung funktioniert der Login unter Linux erwartungsgemäß wieder. Sowohl auf dem „Image-Master“ (der das neue Cloop hochläd), als auch auf den Clients, die das neue Cloop gesynct haben!

Nun habe ich mich an einem anderen Rechner im Computerraum unter Windows angemeldet.
Dann auf zwei Rechnern Linux beendet, Neustart und erneut angemeldet. FUNKTIONIERT!

Im Laufe der Unterrichtsstunde, in der ich das mit den Schülern getestet habe, sind aber dann doch WIEDER ALLE LINUXRECHNER AUSGEFALLEN.
Keine Domänenanmeldung mehr möglich, sowohl auf dem „Image-Master“, als auch auf den gesyncten Linux-Clients.

Schei*e :frowning:

Da es zunächst ja zu funktionieren schien, habe ich nicht genau mitbekommen, wann das System wieder „kippte“. Es könnte nach dem Herunterfahren des Windows-Clients aufgetreten sein. Also nicht direkt nach dem Windows-Login!

Jedenfalls ist die Linux-Domänenanmeldung nun wieder unmöglich - auf allen Clients. Sogar auf jenen, die frisch gesynct und erstmalig verwendet werden.

Was nun???

Hallo Ralf,
so, wie ich das sehe, scheint das ein Problem zu sein, das sich die Entwickler anschauen sollten.
Ich befürchte, wir können da nichts machen.
@thomas @Tobias @baumhof @jeffbeck
Könntet ihr euch bitte dieses Problem nochmals anschauen.
Ich habe in der Zwischenzeit das System mehrfach neu aufgesetzt und das Dualboot hat nie funktioniert.
Falls es hilft, kann ich auch mein Installationsprotokoll schicken, das meine Installation from Scratch dokumentiert. Das Phänomen ist reproduzierbar.
Eine Installation aus den OVAs hat bei mir auch nichts geholfen.
Falls es bei euch doch funktioniert. Mit welcher Windows-Version / build arbeitet ihr?

Schon jetzt vielen Dank für eure Unterstützung.

Gruß,
Mathias

Dem kann ich nur zustimmen.
Ich habe Linux nun schon zig-Mal installiert. Ich dachte Anfangs immer, dass ich einen blöden Fehler mache und habe mich nicht direkt an das Forum gewendet. Ich habe sicherlich ein halbes Dutzend Versuche zunächst mit Holgers Vorab-Bionic hinter mir + 2-3 Versuche mit dem Bionic aus den Servertools.
Das Verhalten ist (zumindest bei mir) reproduzierbar!
Zuerst funktioniert es, ich verteile das (scheinbar funktionieren) Cloop und nach kurzer Zeit ist kein Login mehr möglich. Ich bin mir ziemlich sicher, dass zwischen Funtionieren und Nicht-Funktionieren lediglich ein Windows-Login im Netzwerk liegt…

P.S. Was mir noch aufgefallen ist: Wenn ich ein neues Cloop hochlade, dann fehlt die Postsync-Datei für das neue Cloop. Ich habe es jetzt mehrfach sowohl ohne postsync-script, als auch mit von mir selbst bereitgestellten Versionen probiert. Egal wie, nach kurzer Funktionsfähigkeit ist kein Linux-Domänenlogin mehr möglich…

Hallo Ralf,

wenn du ein „Basic-cloop“ mit postsync-Datei hast und dieses Cloop veränderst, ohne den Namen des Cloops zu ändern, bleibt die postsync-Datei für das neue Cloop erhalten und das vorherige erhält eine Bezeichnung mit Datumsstempel. Solltes du allerdings einen neuen Namen für das Cloop auswählen, dann musst du für dieses Cloop die Postsync-Datei durch Kopieren bereitstellen.

Viele Grüße

Wilfried

Ach ja, noch was:
Ich hab das Windows prof 10 installiert, wie in der Anleitung reg-Datei eingespielt und in die Domäne aufgenommen. Und dann noch ein Image erzeugt, auf den Server hochgeladen und verteilt.
Ich habe mich noch nicht um SSO oder Proxy gekümmert…
Gruß,
Mathias

Hallo Wilfried,
genau so habe ich es gemacht nachdem mir aufgefallen ist, dass das Postsync-Skript fehlte.
Grüße
Ralf