# Linuxclients Anmeldungs-/Domänenproblem **URL:** \ **Category:** v7-Betatest\ **Created:** [5. August 2019 um 13:17 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925 "2019-08-05T13:17:22Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [1. September 2019 um 14:37 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/21 "2019-09-01T14:37:37Z")
Hallo zusammen, in den Logfiles steht nichts komisches, außer dass immer UNKNOWN.lender.schule dasteht. Das ist vermutlich nicht normal, oder? Eine macct datei kommt nicht vor.😒 Log auf von Linbo Upload of bionic64.cloop was successful. HOSTNAME: UNKNOWN.lender.schule FILE: /srv/linbo/bionic64.cloop.info PIDFILE: /tmp/rsync.26858 BACKUP: /srv/linbo/bionic64.cloop.info.BAK FTYPE: .info Upload of bionic64.cloop.info was successful. HOSTNAME: UNKNOWN.lender.schule FILE: /srv/linbo/bionic64.cloop.torrent PIDFILE: /tmp/rsync.26936 BACKUP: /srv/linbo/bionic64.cloop.torrent.BAK FTYPE: .torrent Upload of bionic64.cloop.torrent was successful. HOSTNAME: UNKNOWN.lender.schule FILE: /srv/linbo/bionic64.cloop.desc PIDFILE: /tmp/rsync.26901 BACKUP: /srv/linbo/bionic64.cloop.desc.BAK FTYPE: .desc Upload of bionic64.cloop.desc was successful. umbenannt ‚/srv/linbo/bionic64.cloop.BAK‘ -\> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop‘ Archive file bionic64-2019-09-01-1117.cloop created. Image file bionic64.cloop detected. Restarting multicast service if enabled. umbenannt ‚/srv/linbo/bionic64.cloop.torrent.BAK‘ -\> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop.torrent‘ Archive file bionic64-2019-09-01-1117.cloop.torrent created. Torrent file bionic64.cloop.torrent detected. Restarting bittorrent service. umbenannt ‚/srv/linbo/bionic64.cloop.info.BAK‘ -\> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop.info‘ Archive file bionic64-2019-09-01-1117.cloop.info created. RC: 0 ### rsync post upload end: So 1. Sep 11:17:36 CEST 2019 umbenannt ‚/srv/linbo/bionic64.cloop.desc.BAK‘ -\> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop.desc‘ Archive file bionic64-2019-09-01-1117.cloop.desc created. RC: 0 ### rsync post upload end: So 1. Sep 11:17:36 CEST 2019 Stopping BitTorrent service for bionic64.cloop … done! Stopping BitTorrent service for mate14.cloop … done! RC: 0 ### rsync post upload end: So 1. Sep 11:17:37 CEST 2019 Stopping bittorrent (via systemctl): bittorrent.service. Starting bittorrent (via systemctl): bittorrent.servicebttrack.bittorrent: Kein Prozess gefunden . Starting BitTorrent service for bionic64.cloop … done! ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [1. September 2019 um 14:51 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/22 "2019-09-01T14:51:22Z")
Hallo, > erstelle mal ein Image und schau dann in die logs von linbo…vielleicht > liefert das irgendwas brauchbares. Die Datei muss auch in der lmn7 > erzeugt werden. Wo genau der Fehler liegt kann ich nicht > sagen…vielleicht kennen andere hier das Problem!? vielleciht wird sie schon erzeugt, aber nicht hochgeladen. Mal mit ls -al auf die Cachpartition schauen … Was auch helfen könnte: alle .cloop.\* Dateien und das cloop selbst im Clientcache löschen und dann noch mal ein Image erstellen. Ist die macct Datei dann da? LG Holger ---
**Author:** ![foer](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/f/ac8455/32.png) [@foer](https://ask.linuxmuster.net/u/foer)\ **Post date:** [1. September 2019 um 14:55 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/23 "2019-09-01T14:55:28Z")
Hi, > [@tha](#): > > außer dass immer UNKNOWN.lender.schule dasteht. > Das ist vermutlich nicht normal, oder? nein statt UNKNOWN müsste da der Hostname des Rechners stehen. Was steht bei dem Rechner denn in der /etc/hosts? Eigentlich patcht Linbo da den richtigen Namen nach dem Sync rein…auch ohne spezielles postsync Skript! Irgendwas ist bei euch Faul…entweder beim Client oder im Linbo. Setze doch mal schnell ein völlig neues Ubuntu-Mate auf, installiere die linuxmuster Pakete mache ein Image und schau ob da dann alles klappt…wenn ja weißt du das bei eurem Client was verbastelt ist und kannst nach Unzetschieden suchen…das würde ich jetzt tun… VG Dominik ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [1. September 2019 um 20:08 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/24 "2019-09-01T20:08:05Z")
Hallo Dominik, das Problem tritt ja auch nun mit dem heruntergeladenem Image auf. Auch dort ist nach dem ersten Image schreiben (linuxmuster-client-adsso-setup gemacht) keine macct Datei vorhanden. Ich habe ja die ganzen alten Images noch, das ist nie eine macct dabei. Das kann dann nicht am Clienten liegen. Übrigens steht, wenn linbo läuft in hostname das richtige drin. In den linbo-logs habe ich auch mal in die ältesten logs (nach Aufsetzen des LMN7) gesehen: `Removing dummy logfile /srv/linbo/tmp/inf3-h14_linbo.log. ### rsync post download begin: Do 8. Aug 16:53:02 CEST 2019 ### HOSTNAME: UNKNOWN.lender.schule` Das ist bei jedem Gerät so, in der ersten Zeile steht der richtige Name , dann UNKNOWN… Ich habe auch mal die Dateien im cache gelöscht und ein neues Image erzeugt -\> auch keine macct Datei. Auf dem Server ergibt `journalctl|grep linbo|grep macct` ``` Sep 01 10:59:15 hlserver.lender.schule rsyncd[22816]: rsync on linbo/bionic64.cloop.macct from UNKNOWN (10.0.15.3) Sep 01 10:59:15 hlserver.lender.schule rsyncd[22816]: rsync: link_stat "bionic64.cloop.macct" (in linbo) failed: No such file or directory (2) ``` Holen will sie wohl der Client. Seltsam Viele Grüße Johannes ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [1. September 2019 um 21:51 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/25 "2019-09-01T21:51:54Z")
Hallo zusammen, ich habe mal eine macct aus unseren Test noch in lmn6 auf den Server gelegt. Dann kommt in pre download > ``` > rsync pre download begin: So 1. Sep 23:33:24 CEST 2019 ### > HOSTNAME: UNKNOWN.lender.schule > RSYNC_REQUEST: linbo/bionic64.cloop.macct > FILE: /srv/linbo/bionic64.cloop.macct > PIDFILE: /tmp/rsync.69637 > EXT: .macct > Machine account ldif file: /srv/linbo/bionic64.cloop.macct > Host: unknown > Cannot determine DN of unknown! Aborting! > RC: > rsync pre download end: So 1. Sep 23:33:24 CEST 2019 ###` > > ``` und > ``` > Upload request for kvm-pc_linbo.log. > ssh: connect to host unknown.lender.schule port 2222: Network is unreachable > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2] > RC: > > ``` Es ist wohl doch ein Fehler mit dem Namen. Hat da jemand eine Idee? ---
**Author:** ![foer](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/f/ac8455/32.png) [@foer](https://ask.linuxmuster.net/u/foer)\ **Post date:** [2. September 2019 um 04:57 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/26 "2019-09-02T04:57:46Z")
Stimmt der Hostname des Masterclients denn mit dem in der devices.csv überein? Ändere mal den Rechnernamen in der devices. csv lass kinuxmuster-import-devices laufen, starte dann den Rechner synchronisiert und schau ob der neue Name in die /etc/hostname geschrieben wird. Durchsuche evtl. mal die Linbologs am Ende der Synchronisation, ob der Hostname überhaupt gepatcht wird…wenn nicht würde ich als nächstes Mal ein Postsync einrichten bei dem der Hostname gesetzt wird…siehe dazu die Doku zum universellen Postsyncscript… Eine andere Idee habe ich gerade nicht… VG Dominik ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [2. September 2019 um 09:15 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/27 "2019-09-02T09:15:09Z")
Hallo zusammen, ein Sache haben wir gestern noch gefunden. Wenn ich ein Ping auf dem Server 10.0.0.1 mit dem Namen eines PCs machte, dann wurde dieser falsch aufgelöst. Das wurde korrigiert im DNS, das Problem bleibt aber trotzdem bestehen. Wenn der PC in Linbo läuft, steht in hostname das Richtige (aus devices.csv) drin, auch wenn er im Mate- Betriebssystem läuft. Journalctl gibt: ` > Sep 02 11:04:43 hlserver.lender.schule rsyncd[20222]: rsync on linbo/tmp/r308\_linbo.log from UNKNOWN (10.0.103.8) ` Unter rsyncd.conf habe ich /usr/share/linuxmuster/linbo/rsync-pre-download.sh gefunden, dort wird die Variable $RSYNC\_HOST\_NAME benutzt, die ja dann wohl falsch ist. Zum Verständnis, wo läuft das Skript , auf dem PC in der Linbo-Phase (es wird vom Server geholt?) oder auf dem Server? Wie wird die Variable befüllt? Was ich auch nicht verstehe, warum die log-Datei sogar richtig nach dem PC-Namen heißt. Viele Grüße Johannes ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [2. September 2019 um 19:32 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/28 "2019-09-02T19:32:02Z")
Hallo zusammen, ich habe mal per ssh nachgesehen, während linbo läuft, sind alle Namen, IPs usw richtig gesetzt. Der Fehler entsteht dann wohl auf dem Server. Grüße Johannes ---
**Author:** ![roesslerrr](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/r/f6c823/32.png) [@roesslerrr](https://ask.linuxmuster.net/u/roesslerrr)\ **Post date:** [3. September 2019 um 02:02 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/29 "2019-09-03T02:02:35Z")
Hallo! Leider funktioniert meine Anmeldung auf den Ubuntu 18.04-Clients auch nicht mehr. Am 16.08.19 hat die Anmeldung noch auf allen Testrechnern funktioniert. Jetzt nach dem Urlaub, ohne irgend welche Änderungen, funktioniert die Anmeldung nicht mehr. Ich habe auf einem Client eine Anmeldung kurzfristig wieder ermöglichen können durch linuxmuster-client-adsso-setup . Dieser Erfolg war allerdings nur von kurzer Dauer. Keine Ahnung warum. Jedenfalls habe ich folgende Erkenntnisse gewonnen: - Die macct-Datei zu einem cloop exisitiert bei meinen Rechnern ausschließlich auf dem Server. Die Datei kann daher erst nach dem Upload des Images auf dem Server erzeugt werden. Mit dieser Datei wird dann vermutlich der AD manipuliert, damit von einem Rechner mit diesem Image eine Anmeldung an der Domäne erfolgen kann. - Wenn ich ein neues Image erzeuge, wird die macct-Datei identisch erzeugt. Eine zwischenzeitliches Ausführen von linuxmuster-client-adsso-setup ändert daran nichts. Das Ergebnis in der macct-Datei ist immer das Gleiche (auslesen mit: „# klist -kte /etc/krb5.keytab“ ). Für den Moment bin ich ratlos, vermute aber einen Zusammenhang mit kerberos, da auf dem client klist folgendes Ergebnis liefert: „klist: No credentials cache found (filename: /tmp/krb5cc\_0)“ Nach dem Durchführen von linuxmuster-client-adsso-setup erhält man dagegen den Ticketzwischenspeicher: FILE:/tmp/krb5cc\_0 dessen Tickets ein Tag gültig sind und nach einer Woche erneuert werden müssen. „Valid starting Expires Service principal 03.09.2019 01:19:18 03.09.2019 11:19:18 krbtgt/DOMÄNE@DOMÄNE erneuern bis 10.09.2019 01:19:10 …“ Da kerberos zeitkritsch ist, habe ich auch auf die Synchronität der Uhrzeit auf den Rechnern geachtet. Dann habe ich noch die kerberos-key-Tabelle /etc/krb5.keytab auf dem Client gelöscht und mit linuxmuster-client-adsso-setup neu erzeugen lassen. Leider bisher alles ohne Erfolg. Aktuell erhalte ich auf dem client mit „#systemctl status sssd.service“ die Fehler: „Sep 03 03:23:04 HOSTNAME sssd[1232]: response to SOA query was unsuccessful Sep 03 03:23:04 HOSTNAME sssd[1232]: ; TSIG error with server: tsig verify failure“ Gruß - Rainer ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [3. September 2019 um 07:39 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/30 "2019-09-03T07:39:40Z")
Hallo zusammen, ich hab jetzt den ganzen Thread nochmal durchgelesen: auf der Suche nach Inspiration. Ich fasse mal zusammen: Dominik hat das Problem entdeckt und mit löschen und durch linbo neu erstellter macct Datei bei sich behoben. Bei Johannes wird die macct Datei grundsätzlich nicht erstellt Bei Rainer wird sie erstellt, aber wohl nicht erneuert: deswegen fliegen seine Clients nach sieben Tagen wieder aus der Domäne. Bei Johannes haben wir einen Fehler gefunden: einer der Rechnernamensauflösungsmechanismen (geiles Wort 🙂 ) scheint bei ihm nicht zu funktionieren. Ein Prozess auf dem Server scheint aber genau diesen zu verwenden, um die macct Datei zu erstellen. Linbo scheint das anders zu lösen und der linuxclient selbst auch, weil beide den richtigen Namen kennen. Es stellen sich also folgende Fragen: An Rainer: wie sieht es den mit den Namen bei dir aus (siehe frühere Posts mit UNKNOWN)? An Johannes: das Namensauflösungsgedöns hab ich noch nie ganz durchdrungen, deswegen schlage ich nun vielleicht Mist vor: aber vielleicht willst du es ja mal versuchen. Bei Namensauflösung fällt mir der unbound auf der opnsense ein: hast du SSO auf der opnsense eingerichtet, so wie hier beschrieben? > **[linuxmuster/linuxmuster-base7](https://github.com/linuxmuster/linuxmuster-base7/wiki/Setup-und-Inbetriebnahme-des-Systems#single-sign-on-aktivieren)** > > Mangement scripts for linuxmuster.net V7. Contribute to linuxmuster/linuxmuster-base7 development by creating an account on GitHub. Besonderes Augenmerk sei auf das erste Bild gerichtet, wo unter „Überbrückung“ der DNS aktualisiert wird. Und wo wir schon bei unbound sind: es fällt auf, dass es nur bei Dominik funktioniert und er aber auch, soweit ich weiß, der einzige ist, der unbound den Zwang zu DNSSEC abgewöhnt hat … klingt doch auch mal nach was, oder? LG Holger ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [3. September 2019 um 08:52 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/31 "2019-09-03T08:52:45Z")
Hallo zusammen, mittlerweile wird die macct Datei erstellt, nach ein paar mal deviceimport ging es plötzlich. Alle logs in Linbo sind jetzt mit den richtigen Namen. (DNS hatte nicht richtig die eigenen Rechner umgesetzt) Interessanterweise geht auch plötzlich linuxmuster-import-devices viel schneller. Das hat bei uns immer minutenlang gedauert, plötzlich läuft es ganz schnell durch. Gestern konnte ich dann mich anmelden, heute nicht mehr. Was mir aufgefallen ist, dass bei der macct-Datei die Rechte vielleicht falsch sind. > ` Sep 03 02:13:49 hlserver.lender.schule rsyncd[122780]: rsync: send_files failed to open "bionic64.cloop.macct" (in linbo): Permission denied (13)` > Statt 644 muss da wohl 664 stehen, so wie für die anderen Dateien auch. > Dann wird es gemacht (macct zum Clienten) Schaut mal bei systemctl status sssd.service , da gibt es Fehler mit dem Ticketgedöns. > ``` > Sep 03 12:39:53 test-pc [sssd[ldap_child[1289]: Failed to initialize credentials > Sep 03 12:39:53 test-pc sssd[1287]: Starting up > Sep 03 12:39:53 test-pc sssd[1288]: Starting up > Sep 03 12:39:53 test-pc systemd[1]: Started System Security Services Daemon. > Sep 03 12:41:18 test-pc [sssd[ldap_child[1463]: Failed to initialize credentials > Sep 03 12:41:18 test-pc [sssd[ldap_child[1464]: Failed to initialize credentials > > ``` Wenn ich in sssd.conf krb5\_validate=false setze, dann kommt noch > ``` > Sep 03 12:44:58 test-pc [sssd[ldap_child[1623]: Failed to initialize > credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed > Sep 03 12:44:58 test-pc sssd[1621]: Starting up > > ``` Neulich hatte es nach dieser Änderung bei mir funktioniert. Es ist tatsächlich wie ein hässlicher Wackelkontakt das ganze, gestern konnte ich mich nun anmelden, jetzt nicht mehr. Könnte man als Drumherum die Lebenszeit der Tickets erhöhen, es gibt sowohl auf dem Server als auch auf dem Clienten configs dazu? Viele Grüße Johannes ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [3. September 2019 um 09:15 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/32 "2019-09-03T09:15:50Z")
Hallo zusammen, ich krieg die Krise, auf dem PC war jetzt die Zeit 2h voraus, Zeit gesetz-\>kann mich anmelden. Ich denke dieser chrony.service erledigt das? Aber er hats falsch gesetzt. Viele Grüße Johannes ---
**Author:** ![jochen](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/jochen/32/121_2.png) [@jochen](https://ask.linuxmuster.net/u/jochen)\ **Post date:** [3. September 2019 um 10:55 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/33 "2019-09-03T10:55:32Z")
> [@tha](#): > > auf dem PC war jetzt die Zeit 2h voraus, Zeit gesetz-\>kann mich anmelden. Dann vielleicht doch ein Zusammenhang mit der Zeitkritik von Kerberos!? So a al Systemzeit auf Server und Client deutlich abweichend, weil kein NTP und/oder wegen UTC vs. MESZ!? Nur als Schuss ins Blaue… Viele Grüße aus Italien, Jochen ---
**Author:** ![foer](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/f/ac8455/32.png) [@foer](https://ask.linuxmuster.net/u/foer)\ **Post date:** [3. September 2019 um 11:36 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/34 "2019-09-03T11:36:03Z")
OK falls es ein Zeitsyncproblem ist muss man per postsync dafür sorgen, dass die Rechnerzeit (Software- und Hardwareuhr) immer beim Booten gesetzt wird. In Ubuntu passiert das über einen Systemd-Startup-Hook in _/etc/systemd/timesyncd.conf_. Standardmäßig steht da ein Ubuntu Zeitserver drin, der aber durch die Firewall in der Regel geblockt wird, weswegen die Clients irgendwann davon driften. Bei uns im Netzwerk ist ja die OpnSense der Zeitserver für alle (auch für die AD), daher trägt man in die o.g. Konfigurationsdatei bei NTP die IP der OpnSense ein. Die Datei sieht dann bei Ubuntu 18.04 so aus: ``` # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See timesyncd.conf(5) for details. [Time] NTP=10.16.1.254 #FallbackNTP=ntp.ubuntu.com #RootDistanceMaxSec=5 #PollIntervalMinSec=32 #PollIntervalMaxSec=2048 ``` In meine Fall hat die OpnSense also die IP 10.16.1.254. Ich glaube aber nicht, dass das wirklich das alleinige Problem ist, da ich die hier beschriebenen Probleme auch hatte und bei mir die Systemzeit von Anfang an i.O. war. VG Dominik ---
**Author:** ![zefanja](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/zefanja/32/75_2.png) [@zefanja](https://ask.linuxmuster.net/u/zefanja)\ **Post date:** [3. September 2019 um 11:43 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/35 "2019-09-03T11:43:13Z")
Fakt ist, dass Kerberos recht empfindlich bei zu großen Zeitunterschieden reagiert (default ist glaube ich bei ca. 5 min). ---
**Author:** ![roesslerrr](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/r/f6c823/32.png) [@roesslerrr](https://ask.linuxmuster.net/u/roesslerrr)\ **Post date:** [3. September 2019 um 15:42 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/36 "2019-09-03T15:42:17Z")
Bei mir stimmen die Zeiten überein, trotzdem kein Erfolg. Doch ich fühle mit Johannes (Wackelkontakt), denn gestern hatte ich auch kurz EINE erfolgreiche Anmeldung nach einem Durchgang von linuxmuster-client-adsso.setup. Ich denke momentan in Richtung der macct-Datei. Bei mir ist dort immer der gleiche Inhalt. Ich hätte erwartet nach neuem Domänenbeitritt (mit linuxmuster-client-adsso.setup) ein anderes Passwort darin zu finden. Das ist bei mir immer gleich. Wie sieht das bei anderen aus? @foer ? Gruß - Rainer ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [3. September 2019 um 15:55 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/37 "2019-09-03T15:55:49Z")
Hallo zusammen, chrony wird doch in linuxmuster-client-adsso-setup aktiviert. Das soll das doch übernehmen und darf nicht gleichzeitg mit ntpd laufen. Viele Grüße Johannes ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [3. September 2019 um 16:21 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/38 "2019-09-03T16:21:29Z")
Hallo, > Ich denke momentan in Richtung der macct-Datei. Bei mir ist dort immer > der gleiche Inhalt. Ich hätte erwartet nach neuem Domänenbeitritt (mit > linuxmuster-client-adsso.setup) ein anderes Passwort darin zu finden. > Das ist bei mir immer gleich. > Wie sieht das bei anderen aus? @foer [https://ask.linuxmuster.net/u/foer](https://ask.linuxmuster.net/u/foer) ? er sagte mir Heute Mittag, dass die bei ihm auch immer gleich ist. In deinem Fall würde ich mal die macct Datei auf dem client im Cache und auf dem server löschen (wegschieben) und dann nochmal linuxmuster-client-adsso machen und dann gleich ein Image erzeugen. Ist die macct dann wieder da? Auf Cleint? Auf Server? LG Holger ---
**Author:** ![tha](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/t/a9a28c/32.png) [@tha](https://ask.linuxmuster.net/u/tha)\ **Post date:** [3. September 2019 um 19:15 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/39 "2019-09-03T19:15:22Z")
Hallo zusammen, jetzt habe ich es mal auf die harte Tour probiert und das ganze krb5-Zeug rausgeworfen, auch wenn’s jetzt nicht mehr so sicher ist (Ist , glaube ich, für die PCs in den Klassen- und Computerräumen auch nicht so wichtig) dyndns hat auch immer Fehler gemeldet in sssd.service, wozu braucht man das? 3 Zeilen in sssd.conf dazu: > [domain/LENDER.SCHULE] > id\_provider = ad > access\_provider = ad > krb5\_store\_password\_if\_offline = False > krb5\_validate = False > dyndns\_update = false In /etc/pam.d/lightdm habe ich die krb5-Sachen auskommentiert > ``` > #%PAM-1.0 > auth requisite pam_nologin.so > auth sufficient pam_succeed_if.so user ingroup nopasswdlogin > @include common-auth > #auth optional pam_gnome_keyring.so > #auth optional pam_kwallet.so > #auth optional pam_kwallet5.so > @include common-account > session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close > #session required pam_loginuid.so > session required pam_limits.so > @include common-session > session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open > #session optional pam_gnome_keyring.so auto_start > #session optional pam_kwallet.so auto_start > #session optional pam_kwallet5.so auto_start > session required pam_env.so readenv=1 > session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale > @include common-password > > ``` und in /etc/pam.d/lightdm-greeter genauso > ``` > #%PAM-1.0 > auth required pam_permit.so > #auth optional pam_gnome_keyring.so > #auth optional pam_kwallet.so > #auth optional pam_kwallet5.so > @include common-account > session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close > session required pam_limits.so > @include common-session > session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open > #session optional pam_gnome_keyring.so auto_start > #session optional pam_kwallet.so auto_start > #session optional pam_kwallet5.so auto_start > session required pam_env.so readenv=1 > session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale > > ``` So geht es, mal sehen wie es morgen ist (man weiss ja nie) Falls ihr euch fragt, wie ich darauf komme - unser Ubuntu-Client hing auch am logodidact-adserver und es war genauso ein Wackelkontakt beim Anmelden. Das fiel mir jetzt wieder ein (ist 3 1/2 Jahre her), vor allem wo es steht. Wie ich damals drauf kam, weiß ich nicht mehr. Vielleicht bekommen wir das noch ordentlich hin, aber ich brauche jetzt eine Anmeldung, sonst werde ich nächste Woche gesteinigt. Ein linuxmuster-client-adsso-setup darf ich jetzt nicht mehr laufen lassen, sonst ist alles wieder weg. Viele Grüße Johannes ---
**Author:** ![Tobias](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/tobias/32/85_2.png) [@Tobias](https://ask.linuxmuster.net/u/Tobias)\ **Post date:** [3. September 2019 um 19:36 UTC](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925/40 "2019-09-03T19:36:28Z")
Hi Johannes, so wie ich das verstehe, hast du die Wallets rausgeschmissen, d.h. dass man sich zwar anmelden kann, aber dass man nicht mehr automatisch geöffnete Wallets hat. Das ganze Kerberos erscheint mir deshalb so komplex, weil es schon auf der consolenebene nicht so durchsichtig ist, wie was wann funktioniert. Da ist der login-vorgang sicher das komplizierteste. viel Erfolg,Tobias [Vorherige Seite](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925.md?page=1) [Nächste Seite](https://ask.linuxmuster.net/t/linuxclients-anmeldungs-domaenenproblem/3925.md?page=3)