Nachträgliches "linuxmuster-setup" ausgeführt -> bionic-image kein Domänenlogin möglich

Hallo zusammen,
ich habe unter LMN7 ein nachträgliches

linuxmuster-setup

ausführen müssen um die Firewall nachträglich zu konfigurieren. Das hat auch gut funktioniert. Das Win10-Image benötigte danach allerdings einen neuen Domänen-Join, was ebenfalls funktioniert hat.

Das bionic-Image weigert sich jedoch bislang hartnäckig, einen Domänen-Login zuzulassen. Vor dem nachträglichen linuxmuster-setup funktionierte es tadellos.

Ich habe folgendes nach dem „linuxmuster-setup“ gemacht:

  • linuxmuster-import-devices
  • torrent-Datei für das bionic-image neu erstellt
  • .macct für das bionic-image gelöscht (verschoben)
  • Client Rechner gestartet, partitioniert, formatiert, gesynct
  • Bionic auf dem Client gestartet und linuxmuster-client-adsso-setup ausgeführt (keine Fehlermeldungen!)
  • rebootet, ein Image erstellt und hochgeladen (.macct-Datei wurde neu erzeugt)
  • Domän-Login getestet - leider ohne Erfolg. Es kommt auch keine Fehlermeldung… der Bildschirm wird schwarz und der Display-Manager startet erneut.

Ich bin ratlos :roll_eyes:

Hallo Ralf,

dein Vorgehen ist gut, es fehlt aber ein SChritt auf dem Client: die
alten keys löschen, damit die neuen genommen werden:

Ich habe folgendes nach dem „linuxmuster-setup“ gemacht:

  • linuxmuster-import-devices
  • torrent-Datei für das bionic-image neu erstellt
  • .macct für das bionic-image gelöscht (verschoben)
  • Client Rechner gestartet, partitioniert, formatiert, gesynct

nach dem booten zuerst die /etc/krb5.keytab löschen
rm /etc/krb5.keytab

  • Bionic auf dem Client gestartet und linuxmuster-client-adsso-setup
    ausgeführt (keine Fehlermeldungen!)
  • rebootet, ein Image erstellt und hochgeladen (.macct-Datei wurde neu
    erzeugt)
  • Domän-Login getestet - leider ohne Erfolg. Es kommt auch keine
    Fehlermeldung… der Bildschirm wird schwarz und der Display-Manager
    startet erneut.

LG

Holger

Alles klar. Habe ich gemacht! Folgendes Ergebnis:

  • ich selber kann mich nach wie vor nicht einloggen (Domänenuser: jardon). Gleiches Phänomen
  • andere Domänenuser funktionieren hingegen.

Was kann ich tun? Benutzer „jardon“ löschen und neu anlegen?

Hallo,

nach dem booten zuerst die /etc/krb5.keytab löschen
rm /etc/krb5.keytab

Alles klar. Habe ich gemacht! Folgendes Ergebnis:

  • ich selber kann mich nach wie vor nicht einloggen (Domänenuser:
    jardon). Gleiches Phänomen
  • andere Domänenuser funktionieren hingegen.

Was kann ich tun? Benutzer „jardon“ löschen und neu anlegen?

dann hast du mal ein Image erstellt, nachdem der Nutzer sich angemeldet
hatte: das sollte möglichst nicht passieren.

Du mußt den Client syncen und das lokal gecachte Profil von jardon löschen.
Danach wieder ein Image erstellen: dann sollte es wieder klappen.
Ich vermute es ist hier:
Wo der lokale cache liegt steht in einer config unter
/etc/linuxmuster-client (meine ich )
Sorry: ich weiß es nicht auswendig.

LG

Holger

Das Problem ist doch komplexer als ich dachte.

Nach dem Löschen der krb5.keytab habe ich die folgenden wie oben beschrieben Schritte ausgeführt (inuxmuster-client-adsso-setup, reboot, Image erzeugt und hochgeladen).

Nun habe ich das neue Image auf einen (neuen) Testrechner gesynct. Ergebnis: KEIN Domainlogin möglich. Weder als „jardon“, noch als irgendein anderer Domainuser.

Auf dem Quellrechner (von wo das Image stammt) kann ich mich nach wie vor nicht als „jardon“ an der Domäne anmelden (klar, habe den Cache auch noch nicht gefunden bzw. gelöscht). Ich hatte am Montag auch noch den User „hahn“ getestet, der sich problemlos anmelden kann. Daraus habe ich geschlossen, dass sich die anderen Domainuser ebenfalls anmelden können und das Problem auf den Account „jardon“ beschränkt ist.
TATSÄCHLICH funktioniert aber NUR „hahn“

Also nochmal zur Übersicht:

Quellrechner (von wo das Image stammt): Domänenlogin nur als Lehrer „hahn“ möglich.
Zielrechner (neuer Rechner in der Gruppe): KEIN Domänenlogin möglich.

Die Fehlermeldung lautet übrigens immer „Passwort ungültig. Bitte wiederholen.
Das Erstpasswort ist jedoch für alle Lehrer identisch („Geheim2020!“).
SuS können sich ebenfalls nicht anmelden.

Wie gesagt, unter Windows 10 funzt alles nach dem erneuten Setup und dem Domain-join. Nur unter Linux habe ich dieses seltsame Phänomen.

Könnte es vielleich mit der Uhrzeit zusammenhängen? Unter LMN-Server und damit auch unter Linbo bzw. Windows habe ich die korrekte Zeit (UTC). Unter Linux habe ich jedoch +2h (CEST). Aber warum funzt dann „hahn“???

Sehr seltsam :crazy_face:

Hmm… ich habe jetzt auf dem LMN-Server die Zeitzone korrekt auf Europe/Berlin gesetzt und habe nun unter Linbo und auf dem Server die korrekte Zeit. Der Windows-Client macht dann jedoch wieder eine falsche Zeit daraus (er addiert 2h dazu) :upside_down_face:
Auch wenn ich die Zeit von Hand setze, so dass sie mit der Serverzeit übereinstimmt bleibt das Login-Problem…

Hallo,

setze mal das um

damit du beim Login die richtige Zeit hast, vielleicht hilfst.

Viele Grüße

Wilfried

Das Thema diskutieren wir gerade hier:

https://ask.linuxmuster.net/t/probleme-mit-der-systemzeit-im-zusammenhang-mit-linbo-und-dem-lmn-bionic-cloop/5504/16

Hallo Holger,
leider finde ich den Pfad des Caches nicht in /etc/linuxmuster-client.
Es gibt ein cache-Verzeichnis in /home/, dort sind die User zu finden, welche sich schon einmal eingeloggt haben (u.a. jardon). Wenn ich das Verzeichnis lösche wird es beim Login (der nach wie vor nicht klappt) neu angelegt.

Es scheint aber tatsächlich mit dem Cache zusammenzuhängen. Das bionic „reagiert“ z.B. auch nur auf das alte Passwort von „jardon“ und nicht auf das aktuelle, auf dem Server eingetragene Passwort.

Man sieht das, wenn ich ein „su jardon“ absetzte:

su jardon
Passwort: ALTES PASSWORT
(pam_mount.c:365): pam_mount 2.16: entering auth stage
(pam_mount.c:568): pam_mount 2.16: entering session stage
(mount.c:267): Mount info: globalconf, user=jardon <volume fstype="cifs" server="server.linuxmuster.lan" path="default-school" mountpoint="/srv/samba/schools/default-school" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="sec=ntlmssp,nodev,nosuid,mfsymlinks,nobrl,vers=1.0" /> fstab=0 ssh=0
(mount.c:664): Password will be sent to helper as-is.
command: 'mount' '-t' 'cifs' '//server.linuxmuster.lan/default-school' '/srv/samba/schools/default-school' '-o' 'username=jardon,uid=884201260,gid=884200513,sec=ntlmssp,nodev,nosuid,mfsymlinks,nobrl,vers=1.0' 
(mount.c:72): Messages from underlying mount program:
(mount.c:76): mount error(13): Permission denied
(mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[...]
(pam_mount.c:522): mount of default-school failed
(mount.c:267): Mount info: globalconf, user=jardon <volume fstype="cifs" server="server.linuxmuster.lan" path="sysvol" mountpoint="/var/lib/samba/sysvol" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="sec=ntlmssp,nodev,nosuid,mfsymlinks,nobrl,vers=1.0" /> fstab=0 ssh=0
(mount.c:664): Password will be sent to helper as-is.
command: 'mount' '-t' 'cifs' '//server.linuxmuster.lan/sysvol' '/var/lib/samba/sysvol' '-o' 'username=jardon,uid=884201260,gid=884200513,sec=ntlmssp,nodev,nosuid,mfsymlinks,nobrl,vers=1.0' 
(mount.c:72): Messages from underlying mount program:
(mount.c:76): mount error(13): Permission denied
(mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[...]
(pam_mount.c:522): mount of sysvol failed
command: 'pmvarrun' '-u' 'jardon' '-o' '1' 
(pmvarrun.c:258): parsed count value 0
(pam_mount.c:441): pmvarrun says login count is 1
(pam_mount.c:660): done opening session (ret=0)

Jetzt ein Loginversuch mit aktuellem Passwort:

su jardon
Passwort: AKTUELLES PASSWORT
su: Legitimierungsfehler

Jetzt als User, der sich noch nie angemeldet hat:

su bey
Kein Passworteintrag für Benutzer »bey«

Wie gesagt, das Problem trat erst auf nachdem ich das nachträgliche „linuxmuster-setup“ auf dem Server durchgeführt hatte. Zuvor klappten alle Logins!!

Hallo Ralf,

Wie gesagt, das Problem trat erst auf nachdem ich das nachträgliche
„linuxmuster-setup“ auf dem Server durchgeführt hatte. Zuvor klappten
alle Logins!!

das ist eine, wie ich meine, nicht ausreichend genaue Beschreibung der
Situation.
Besser wäre, würde ich sagen: „das Problem ist mir erst aufgefallen,
nachdem ich linuxmuster-setup“ ausgeführt hatte und damit eine
neuanmeldung an die Domäne nötig wurde"

Dein Problme ist nämlich, dass ein Nutzer im Image steckt (deiner).

Löschst du den Cache, so sind die NUtzerdaten noch anderswo vorhanden
(z.B. Passwort).

Na dann suchen wir mal:

mach mal folgendes:

  1. Client gesynct starten
  2. also lokaler admin anmelden
  3. Supertaste drücken und "b e n u t "
    eintippen: „Benutzer“ anklicken
  4. taucht der Nutzer dort auf? → löschen
    falls nicht … schade, dann so weiter
  5. /home/cache Benutzerverzeichnis löschen
  6. in die /etc/shadow rein schauen, ob dort der nutzer ist

falls das nicht hilft, überlegen was mehr arbeit macht:

  1. internetrecherche, wie man einen Domänennutzer, der schon mal
    angemeldet war, aus einem ubuntu 18.04 sauber wieder raus bekommt oder:
    nochmal default.cloop her nehmen und frisch anfangen :slight_smile:

LG

Holger