In der Datei readvars.sh aus dem linuxmuster-client-adsso ist ein Schreibfehler:
Oder gab es den Fehler mal genau umgekehrt und bei der Erstinstallation war es mal „verkehrt“?
Hallo,
So wie ich die CommitHistory verstehe ist es kein Schreibfehler : das ist so absichtlich.
Aber die Datei adsso.conf vom Ordner templates sollte im Ordner etc/linuxmuster-client verschoben sein. Es fehlt vielleicht eine Zeile im postinst-Skript. @Tobias kann besser antworten.
Viele Grüße
Arnaud
Das template wurde erweitert, d.h. ihr müsst
linuxmuster-client-adsso-setup
ausführen und damit der Domäne neu beitreten. Ist das eigentlich schlimm? Ein neues Image muss man ja sowieso machen.
Dann könnt ihr /etc/linuxmuster-client-adsso.conf (die alte Konfigurationsdatei) löschen.
In der Tat hätte ich das in ein postinst packen sollen, werde ich bei der nächsten Version machen, bzw. linuxmuster-client-adsso-setup eben auch beim upgrade aufrufen.
VG, Tobias
Hallo Tobias,
Das template wurde erweitert, d.h. ihr müsst
linuxmuster-client-adsso-setup |
ausführen und damit der Domäne neu beitreten.
… und vorher die /etc/kbr5.keytab (oder so ähnlich) Datei löschen… oder?
Ist das eigentlich
schlimm? Ein neues Image muss man ja sowieso machen.
… ich denke, es ist nicht soooo einfach, denn es muss gegebenenfalls
beachtet werden:
In der Tat hätte ich das in ein postinst packen sollen, werde ich bei
der nächsten Version machen, bzw. linuxmuster-client-adsso-setup eben
auch beim upgrade aufrufen.
die macct Datei auf dem Server löschen bekommst du aber nicht in einen
postinst, oder? 
LG
Holger
Hi Holger,
also die /etc/krb5.keytab wird bereits mit dem linuxmuster-client-adsso-setup skript gemacht.
Das musst du also nicht mehr verbreiten.
die macct Datei - ist das so wichtig, dass die gelöscht wird? Das ist mir nicht klar.
VG,Tobias
Hallo Tobias,
die macct Datei - ist das so wichtig, dass die gelöscht wird? Das ist
mir nicht klar.
ich weiß es nicht sicher, aber so habe ich es verstanden:
wird ein Rechner (win oder lin) in die Domäne aufgenommen, so wird mit
dem AD ein workstationpasswort ausgehandelt: das ist so, da kann man
nicht dran drehen.
Wird ein Image erstellt (win oder lin) und es ist keine .macct Datei
vorhanden, dann wird auf dem Server das workstation Passwort ausgelesen
und in die .macct Datei geschrieben (win und Lin).
Wenn du der Domäne frisch beitrittst, dann wird also ein neues
workstationspasswort ausgehandelt. Ist die .macct Datei auf dem server
vorhanden wird es nicht neu ausgelesen und damit geht es verloren,
sobald der Rechner mit dem image gesynct wird: dann wird nämlich das
alte Passwort aus der .macct Datei in den AD geschrieben (für diese
Workstation) und das „richtige“ wird überschrieben: dann ist es essig
mit der Domänenanmeldung.
Also: die .macct muss weg.
LG
Holger
Hi Holger,
das klingt für mich logisch:
was für mich nicht logisch klingt, ist, dass die macct weg muss, denn
Also mein Fazit wäre: Trittst du in einem Client der Domäne neu bei, dann musst du mit dem client ein neues Image erstellen. (aber nicht, "dann musst du die macct-Datei löschen).
Für mich stellt sich also nur die frage: schreibt der server bei einem create_cloop (oder von mir aus, beim upload_cloop) auch die macct-Datei neu - und wenn nicht - warum nicht? Das ist dann doch ein bug oder mindestens ein feature request.
LG, Tobias
Hallo Tobias,
Also mein Fazit wäre: Trittst du in einem Client der Domäne neu bei,
dann musst du mit dem client ein neues Image erstellen. (aber nicht,
"dann /musst/ du die macct-Datei löschen).Für mich stellt sich also nur die frage: schreibt der server bei einem
create_cloop (oder von mir aus, beim upload_cloop) auch die macct-Datei
neu - und wenn nicht - warum nicht? Das ist dann doch ein bug oder
mindestens ein feature request.
ich kann nur sagen, wie ich es erlebt hatte: ich hatte Probleme mit dem
Neubeitreten, daraufhin hat thomas gesagt: lösch die macct Datei und
erstell ein Image: danach klappte es.
Vielelicht veranlaßt linbo das ja auch inzwicschen… ich weiß es nicht.
Solange ich es nicht weiß, sag ich den Leuten: „löscht die .macct Datei
auf dem Server“
LG
Holger
Hallo,
ich habe das jetzt mal versucht umzusetzen. Ist ja auch blöd, wenn wir das alte Template verwenden.
Wir haben ja auch nach wie vor das Problem, dass nach der ersten Anmeldung nach einer Weile Home_auf_Server fehlt. Wenn man sich erneut anmeldet, bleibt Home_auf_Server gemountet. Deshalb habe ich mir davon einiges versprochen…
Was soll ich sagen: Das ging deutlich in die Wicken:
krb5.keytab gelöscht
linuxmuster-client-adsso-setup
macct vom server gelöscht
image geschrieben (neue macct auf dem Server wurde erstellt)
–> keine Anmeldung mehr möglich. Habt ihr Tipps?
Grüße
Daniel
Hallo Daniel,
Was soll ich sagen: Das ging deutlich in die Wicken:
krb5.keytab gelöscht
linuxmuster-client-adsso-setup
macct vom server gelöscht
image geschrieben (neue macct auf dem Server wurde erstellt)–> keine Anmeldung mehr möglich. Habt ihr Tipps?
voller Erfolg … sozusagen
Spass beiseite: so hab ich das noch nie erlebt.
Sag mal bitte deine volle Domäne vom Server:
server.meine.schule.lan
Ist das Clientpaket aktuell?
Ist der Server aktuell?
LG
Holger
Hallo Holger,
Server ist aktuell (gestern aktualisiert)
Domäne: server.linuxmuster.lan
Gruß
Daniel
Hallo Daniel,
Server ist aktuell (gestern aktualisiert)
Domäne: server.linuxmuster.lan
du hast das nur an einem Rechner getestet?
Kannst du es noch an einem anderen Rechner testen?
du hast es nur mit einem Domänennutzer getestet? (Welcher?)
Kannst ud es auch noch mit einem anderen Domänennutzer testen?
Manchmal ist noch ein Profil im cache des Clients: das kann
Nebenwirkungen haben.
LG
Holger
Hi,
check mal von einem anderen Rechner aus (über ssh auf dem Client) was das syslog oder auth.log des Clients beim scheiternden Anmeldeversuch ausgibt.
VG
Wolfgang
Hallo Holger,
du hast das nur an einem Rechner getestet?
mehrere Rechner getestet.Überall gleiches Verhalten.
du hast es nur mit einem Domänennutzer getestet? (Welcher?)
Ich habe verschiedene User getestet. Was interessant ist: Bei meinem eigenen (fischd) Account klappt die Anmeldung. Ich habe auch Reste von meinem Account in /var/lib/lightdm-data und /var/lib/Accountservice gefunden. Das müssen aber Leichen aus früheren Images sein.
Ansonsten finde ich nichts, was darauf hinweißt, dass gerade mein eigener User sich anmelden kann, alle anderen aber nicht.
/home/cache ist leer, wenn ich mich als linuxadmin direkt nach dem Sync anmelde.
Was ich noch gemacht habe, bevor ich das Image erstellt habe: bleachbit durchlaufen lassen…kann es daran liegen?
Soll ich das linuxmuster-client-adsso-setup einfach nochmal ausführen?
Grüße
Daniel
auth.log von abgelehntem User:
Jun 16 16:16:03 rwg-t-22 lightdm: pam_unix(lightdm:auth): check pass; user unknown
Jun 16 16:16:03 rwg-t-22 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Jun 16 16:16:03 rwg-t-22 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=testlehrer
Jun 16 16:16:03 rwg-t-22 lightdm: pam_sss(lightdm:auth): received for user testlehrer: 10 (User not known to the underlying authentication module)
Jun 16 16:16:05 rwg-t-22 lightdm: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
Jun 16 16:16:05 rwg-t-22 lightdm: PAM adding faulty module: pam_kwallet.so
Jun 16 16:16:05 rwg-t-22 lightdm: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory
Jun 16 16:16:05 rwg-t-22 lightdm: PAM adding faulty module: pam_kwallet5.so
auth.log von meinem akzeptierten User:
Jun 16 16:17:02 rwg-t-22 lightdm: pam_succeed_if(lightdm:auth): requirement „user ingroup nopasswdlogin“ not met by user „fischd“
Jun 16 16:17:23 rwg-t-22 lightdm: (mount.c:558): 355 26 0:48 / /run/user/0 rw,nosuid,nodev,relatime shared:231 - tmpfs tmpfs rw,size=371356k,mode=700
Jun 16 16:17:23 rwg-t-22 lightdm: (mount.c:558): 356 27 0:49 / /srv/samba/schools/default-school rw,nosuid,nodev,relatime shared:232 - cifs //server.linuxmuster.lan/default-school rw,vers=1.0,sec=ntlmssp,cache=strict,username=fischd,uid=380402728,forceuid,gid=380400513,forcegid,addr=10.0.0.1,soft,unix,posixpaths,serverino,mapposix,nobrl,acl,mfsymlinks,rsize=61440,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1
Jun 16 16:17:23 rwg-t-22 lightdm: (mount.c:558): 374 27 0:50 / /var/lib/samba/sysvol rw,nosuid,nodev,relatime shared:246 - cifs //server.linuxmuster.lan/sysvol rw,vers=1.0,sec=ntlmssp,cache=strict,username=fischd,uid=380402728,forceuid,gid=380400513,forcegid,addr=10.0.0.1,soft,unix,posixpaths,serverino,mapposix,nobrl,acl,mfsymlinks,rsize=61440,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1
Jun 16 16:17:23 rwg-t-22 lightdm: command: ‚pmvarrun‘ ‚-u‘ ‚fischd‘ ‚-o‘ ‚1‘
Jun 16 16:17:23 rwg-t-22 lightdm: (pam_mount.c:441): pmvarrun says login count is 1
Jun 16 16:17:23 rwg-t-22 lightdm: (pam_mount.c:660): done opening session (ret=0)
Jun 16 16:17:23 rwg-t-22 systemd-logind[1166]: New session c2 of user fischd.
Hallo Daniel,
Was ich noch gemacht habe, bevor ich das Image erstellt habe: bleachbit
durchlaufen lassen…kann es daran liegen?
glaub ich nicht: das mach ich auch imemr: einmal al root einmal als
linuxadmin.
Soll ich das linuxmuster-client-adsso-setup einfach nochmal ausführen?
ja: keytab löschen, macct Datei löschen
… ach so: vorher kontrollieren, ob der Inhalt der /etc/hosts auf dem
Client stimmt: daran könnte es ja auch liegen.
LG
Holger
Jetzt hat er es gefressen.
Woran es lag? Keine Ahnung.
Spekulation: Postsync? Profilreste im Image? Speicherplatz auf dem Server war evtl zu knapp, aber dann wäre wohl gar nichts gelaufen…?
Oder Layer8 Problem…
Danke für die Hilfe