Debian - Offline-Anmeldung von AD-Benutzer scheitert
Hallo Gemeinde,
eine Debian-11-VM (reine iso-Standardinstallation) ist mit Samba/Winbind in das lokale Active Directory eingebunden. Ist diese VM mit dem lokalen Netzwerk verbunden, ist die Anmeldung und Nutzung durch die AD-Benutzer problemfrei.
Die Offline-Anmeldung wurde gemäß dem Samba-Wiki: PAM_Offline_Authentication eingerichtet. Ebenso wurde die Datei /etc/security/pam_winbind.conf angelegt. Hingegen wurden die Dateien im Verzeichnis /etc/pam.d nicht geändert, so dass diese den System-/Programm-Vorgaben entsprechen. Der im vorgenannten Wiki-Artikel angegebene Test mit smbcontrol winbind offline und wbinfo -K funktioniert ordnungsgemäß. Ebenso können im Offline-Modus unter einem lokalen Benutzer (oder mit root) die AD-Benutzer (/ -Gruppen) mit wbinfo -u (/ -g) abgerufen werden. Hingegen gibt getent passwd (/ group) im Offline-Modus lediglich die lokalen Benutzer (/ Gruppen) zurück - im Online-Modus enthält die Ausgabe von getent auch die AD-Daten.
Das gesamte Verhalten ist sowohl bei der grafischen sddm-/lightdm-Anmeldung als auch mit einer Konsolen-Anmeldung identisch.
Als Desktopumgebung wird LXQt verwendet. Sowohl beim Display-Manager sddm als auch beim test-/kontrollweise hinzugefügten lightdm zeigt sich dieselbe Disfunktionalität im Offline-Modus. In beiden Fällen findet sich beim Scheitern der Offline-Anmeldung in der /var/log/auth.log wiederkehrend als zugehöriger Eintrag:
Bei sddm steht lediglich sddm anstelle von lightdm. Es spielt überdies keine Rolle, ob beim Anmelden die Domain mit angegeben wird oder nicht.
Aufgefallen ist mir, dass im Online-Modus sowohl eine reguläre Anmeldung als auch der vorgenannte smbcontrol-Test mit wbinfo -K zu einer entsprechenden Datei /tmp/krb5cc_%u führen. Sie kann im Anschluss mit klist abgerufen werden. Indes fehlt diese Datei beim Offline-Modus.
Was ist hier fehlerhaft? Muss die PAM-Konfiguration noch angepasst werden? Falls ja, welche konkreten Dateien?
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
eine Debian-11-VM (reine iso-Standardinstallation) ist mit Samba/Winbind in das lokale Active Directory eingebunden. Ist diese VM mit dem lokalen Netzwerk verbunden, ist die Anmeldung und Nutzung durch die AD-Benutzer problemfrei.
Die Offline-Anmeldung wurde gemäß dem Samba-Wiki: PAM_Offline_Authentication eingerichtet. Ebenso wurde die Datei /etc/security/pam_winbind.conf angelegt. Hingegen wurden die Dateien im Verzeichnis /etc/pam.d nicht geändert, so dass diese den System-/Programm-Vorgaben entsprechen. Der im vorgenannten Wiki-Artikel angegebene Test mit smbcontrol winbind offline und wbinfo -K funktioniert ordnungsgemäß. Ebenso können im Offline-Modus unter einem lokalen Benutzer (oder mit root) die AD-Benutzer (/ -Gruppen) mit wbinfo -u (/ -g) abgerufen werden. Hingegen gibt getent passwd (/ group) im Offline-Modus lediglich die lokalen Benutzer (/ Gruppen) zurück - im Online-Modus enthält die Ausgabe von getent auch die AD-Daten.
Das gesamte Verhalten ist sowohl bei der grafischen sddm-/lightdm-Anmeldung als auch mit einer Konsolen-Anmeldung identisch.
Als Desktopumgebung wird LXQt verwendet. Sowohl beim Display-Manager sddm als auch beim test-/kontrollweise hinzugefügten lightdm zeigt sich dieselbe Disfunktionalität im Offline-Modus. In beiden Fällen findet sich beim Scheitern der Offline-Anmeldung in der /var/log/auth.log wiederkehrend als zugehöriger Eintrag:
May 30 16:43:47 AP213 lightdm: pam_krb5(lightdm:auth): authentication failure; logname=BENUTZER uid=0 euid=0 tty=:0 ruser= rhost=
May 30 16:43:47 AP213 lightdm: pam_unix(lightdm:auth): check pass; user unknown
May 30 16:43:47 AP213 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): [pamh: 0x564e79dfc190] ENTER: pam_sm_authenticate (flags: 0x0000)
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): getting password (0x00000389)
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): pam_get_item returned a password
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): Verify user 'BENUTZER'
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): PAM config: krb5_ccache_type 'FILE'
May 30 16:43:47 AP213 lightdm: pam_winbind(lightdm:auth): [pamh: 0x564e79dfc190] LEAVE: pam_sm_authenticate returning 10 (PAM_USER_UNKNOWN)
Bei sddm steht lediglich sddm anstelle von lightdm. Es spielt überdies keine Rolle, ob beim Anmelden die Domain mit angegeben wird oder nicht.
Aufgefallen ist mir, dass im Online-Modus sowohl eine reguläre Anmeldung als auch der vorgenannte smbcontrol-Test mit wbinfo -K zu einer entsprechenden Datei /tmp/krb5cc_%u führen. Sie kann im Anschluss mit klist abgerufen werden. Indes fehlt diese Datei beim Offline-Modus.
Was ist hier fehlerhaft? Muss die PAM-Konfiguration noch angepasst werden? Falls ja, welche konkreten Dateien?
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2939092765
Url: https://administrator.de/forum/debian-offline-anmeldung-von-ad-benutzer-scheitert-2939092765.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
9 Kommentare
Neuester Kommentar
Servus HansDampf06.
Poste doch bitte mal den Inhalt der folgende Konfigurations-Dateien des Clients
Grüße Uwe
Poste doch bitte mal den Inhalt der folgende Konfigurations-Dateien des Clients
* /etc/security/pam_winbind.conf* /etc/samba/smb.conf* /etc/krb5.conf* /etc/nsswitch.conf* /etc/pam.d/common-auth
Muss die PAM-Konfiguration noch angepasst werden?
Im Normallfall nicht (pam-auth-update
lässt sich aber auch nachträglich ausführen), fehlerhafte Konfiguration sehe ich aber wenn du den Inhalt des "common-auth" Moduls postest.Grüße Uwe
Du bist hier einem Irrtum aufgesessen. Das Kerberos-Ticket wird nur teilweise zum Login genutzt bzw. erst nach dem Login. Die gecachten SAM-Credentials liegen woanders (
Bezüglich Kerberos-Ticket, die werden eh nach logoff/reboot wieder durch den Dienst gelöscht. Das Ticket selbst ist also nicht der offline Logon-Cache.
Schaut mir das auf Debian11 nächste Woche nochmal genauer an woran es noch liegen könnte das es bei dir nicht läuft falls dir in den Logs bis dahin nichts auffällt.
Grüße Uwe
net cache samlogon list
). Diese werden immer wieder aktualisiert wenn sich der User Online einloggt. Ist der User offline werden diese für den Login des Users genutzt. Und diese sind persistent, überleben also einen Reboot.Bezüglich Kerberos-Ticket, die werden eh nach logoff/reboot wieder durch den Dienst gelöscht. Das Ticket selbst ist also nicht der offline Logon-Cache.
Hierdurch mag die Offline-Funktionalität von Winbind in laufender Sitzung hilfreich sein. Für ein so genanntes Roadwarrior-Szenario bringt es nach meinem derzeitigen Erkenntnisstand hingegen keinen praktischen Nutzen: Winbind erwartet im Kern eine bestehende Verbindung zum KDC, um einen AD-Benutzer authentifizieren zu können.
Nein, braucht es definitiv nicht! Schalte das Debugging von winbind ein und schau warum die SAM-Credentials nicht gecached werden. Hier ein Login nach einem Reboot mit gezogenem LAN.Schaut mir das auf Debian11 nächste Woche nochmal genauer an woran es noch liegen könnte das es bei dir nicht läuft falls dir in den Logs bis dahin nichts auffällt.
Frohe Pfingsten
DitoGrüße Uwe
Zitat von @HansDampf06:
. Die Variante FILE führt uno sono mit die Ablage der Session-krb5-Tickets, die nach dem Logoff gelöscht werden, zu derselben Dateibezeichnung /tmp/krb5cc_%u. Die Folge dessen kann so interpretiert werden, dass Winbind den Cache nicht halten kann, weil beim Logoff diese identische Datei gelöscht wird.
Ja, da das Ticket nicht zwingend nötig für einen Login ist. Überdies wird es i.d.R. auch nach dem regulären Logoff wieder gelöscht.. Die Variante FILE führt uno sono mit die Ablage der Session-krb5-Tickets, die nach dem Logoff gelöscht werden, zu derselben Dateibezeichnung /tmp/krb5cc_%u. Die Folge dessen kann so interpretiert werden, dass Winbind den Cache nicht halten kann, weil beim Logoff diese identische Datei gelöscht wird.
Ich hatte überdies keinen Erfolg, bei FILE einen anderen Ablageort vorzuschreiben (weder in pam_winbind noch in common-auth) - Winbind ist stoisch bei der Standardeinstellung /tmp/krb5cc_%u geblieben.
Dann hast du für den Pfad die Berechtigungen nicht richtig gesetzt. Der Ablageort muss für jeden beschreibbar sein (1777).Den Ort zu ändern wird dir aber nicht viel bringen da wie gesagt die Tickets im Normalfall immer wieder nach Logoff , reboot etc. gelöscht werden.
Mit dem von Dir genannten net cache samlogon list lässt sich aber wunderbar sehen, dass die (letzte) erfolgreiche Anmeldung (im Online-Modus) vorhanden ist. Das wiederum könnte zu der Vermutung verleiten, dass selbst das Fallback dysfunktional sei.
Ja evt. eine korrupte *.tdb, evt. führt hier schon das Löschen der *.tdb s zum Erfolg.Zudem müsste doch eigentlich getent passwd im Offline-Modus auch die AD-Benutzer auswerfen, wenn die Authentifizierung klappen würde? Oder ist das eine irrtümliche Annahme?
Kann ich gerade nicht sagen, bin gerade offline. Könnte wine der Fehlerteufel sein?
Eher nicht.Ein anderer Gedanke: Sowohl bei sddm als auch bei lightdm ist das Verhalten identisch laut auth.log. Lightdm liefert aber am Anmeldefenster wenigstens Informationen, die mitteilen, was los ist. Sddm löscht hingegen kommentarlos das Passwort-Feld. Die FensterManager würde ich als Fehlerquelle ausschließen.
Vorhin hatte ich noch einmal die Debian-VM rebootet. Die Link-Option der virtuellen Netzwerkschnittstelle ist vorher auf inaktiv gesetzt worden, was einem gezogenen LAN-Kabel entspricht (NO-CARRIER). Die Winbind-Log-Dateien mit den zugehörigen Einträgen während des Neustarts und der erfolglosen Anmeldung:
Poste auch mal die Parameter womit winbind in seinem systemd unit aufgerufen wird.
Zitat von @HansDampf06:
Nein, leider nicht. Denn ad steht für die direkte Verbindung zum Active Directory als originäre Quelle.
Das brauchst du mir nicht erklären, weiß ich selbst 😉.Nein, leider nicht. Denn ad steht für die direkte Verbindung zum Active Directory als originäre Quelle.
Also das ad ist an dieser Stelle zwingend,
Nein. Lass den ganzen DOMAIN Block mal weg und nutze testweise nur das tdb Backend.Genau das hat hier im Test nämlich dazu geführt das das die offline Auth fehl schlägt.
Mittags war ich noch Deinem Hinweis mit dem Log-Level nachgegangen. Gibt es wegen der Zeilenbegrenzung für einen Kommentar die Möglichkeit, die längeren Logs als TXT-Datei hochzuladen?
Lade sie auf einen Hoster deiner Wahl und Gib sie frei.Auf das Offline-Caching kann und darf es keinen Einfluss haben, weil es ja "nur" bestimmt, wie das Mapping erfolgt. Welche konkrete ID der Benutzer(/ die Gruppe) erhält, ist aber für das Caching wohl eher irrelevant.
Doch das hat es, da das Backend wohl eine bestehende Verbindung beim Login benötigt um die IDs abzugeichen, das zeigt mir mein Debug-Trace von heute Mittag auf dem Debian-System.