hansdampf06
Goto Top

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:

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

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

colinardo
colinardo 31.05.2022 aktualisiert um 16:11:27 Uhr
Goto Top
Servus HansDampf06.

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
HansDampf06
HansDampf06 04.06.2022 um 14:18:37 Uhr
Goto Top
@colinardo:

Die common-*-Dateien hatte ich vorsorglich mit pam-auth-update "glattgezogen".

Im Übrigen sollten meine conf-Dateien den Best-Praxis-Vorgaben der Originalquellen bei samba.org entsprechen. Jedenfalls läuft die Linux-Einbindung ins Active Directory im stationären Betrieb seit mehreren Jahren unauffällig (Ubuntu 16.04/18.04/20.04). Daher käme es eigentlich nur auf das Offline-Caching an ...

Bei meinen Konfigurationstests war mir neben der schon beschriebenen Besonderheit bei getent aufgefallen, dass wbinfo -K im Offline-Modus über smbcontrol keine krb5cc_%u-Datei unter /tmp ablegt, die üblicherweise mit klist ausgelesen werden kann. Das ist auch im "echten" Offline-Modus der Fall, was wohl auch so sein muss: Schließlich ist keiner der KDC verfügbar, wenn der Computer mit dem lokalen Netzwerk nicht verbunden ist - dann kann der KDC auch kein krb5-Ticket verteilen.
Nach einem Neustart muss außerdem eine solche krb5cc_%u-Datei verloren gehen, weil /tmp regelmäßig "flüchtiger" Speicher ist.

Das adressiert das eigentliche Problem: die Erstellung und Vorhaltung des bereits erteilten krb5-Tickets. Ohne KDC kann ein solches nicht erstellt werden - selbstredend. Also bedarf es der Vorhaltung zumindest des letzten erteilten Tickets für den betreffenden Benutzer. Und genau das macht Winbind nicht beziehungsweise versteht unter "offline" nur einen ganz eingeschränkten Anwendungsbereich: Zunächst ist Winbind in der aktuellen Sitzung mit dem KDC verbunden und erhält auf Anfrage entsprechende Tickets vom KDC, sobald der betreffende Benutzer einen Authentifizierungsvorgang auslöst. Geht danach in dieser laufenden Sitzung die Verbindung zum KDC verloren, so kann Winbind auf seinen Cache zugreifen. Aber wehe, der Computer wird neu gestartet oder in den Ruhezustand geschickt. Dann geht der Cache verloren. Dieser Verlust scheint gleichfalls einzutreten, wenn Winbind in laufender Sitzung lediglich restartet (oder stop + start) wird. Dieses Verhalten von Winbind ändert sich auch dann nicht, wenn das letzte Ticket weiterhin vorgehalten wird. Winbind greift nicht darauf zu.

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. Aber vielleicht fehlt ja vorliegend noch etwas ...

Nun die Konfigurationsdateien:

  • /etc/security/pam_winbind.conf
[global]
debug=yes
#debug_state = yes
krb5_auth=yes
krb5_ccache_type=FILE
cached_login=yes

  • /etc/samba/smb.conf
[global]
security = ads
realm = ADDOMAIN.TLD
workgroup = ADDOMAIN
netbios name = AP201N

log file = /var/log/samba/log.%m
max log size = 1000
server role = member server
server min protocol = SMB2_10
server max protocol = SMB3_11
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

idmap config * : backend = tdb
idmap config * : range = 3000-7999

idmap config ADDOMAIN : backend = ad
idmap config ADDOMAIN : schema_mode = rfc2307
idmap config ADDOMAIN : range = 10000-999999
idmap config ADDOMAIN : unix_nss_info = yes
idmap config ADDOMAIN : unix_primary_group = yes

winbind enum users = yes
winbind enum groups = yes
winbind cache time = 10
winbind use default domain = yes
winbind refresh tickets = yes

winbind offline logon = yes
lock directory = /var/cache/samba
#winbind nested groups = yes

template homedir = /home/%D/%U
template shell = /bin/bash
client signing = yes
#client use spnego = yes
#client ntlmv2 auth = yes
#encrypt passwords = yes
restrict anonymous = 2
domain master = no
local master = no
preferred master = no
os level = 0
kerberos method = secrets and keytab

vfs objects = acl_xattr
map acl inherit = yes

  • /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
clock_skew = 300
default_realm = ADDOMAIN.TLD
dns_lookup_realm = false
dns_lookup_kdc = true

[realms]
    ADDOMAIN.TLD = {
	kdc = dc1.addomain.tld:88
	kdc = dc2.addomain.tld:88
	admin_server = dc1.addomain.tld:464
	default_domain = ADDOMAIN.TLD
	auth_to_local = RULE:[1:$1@$0]
    }

[domain_realm]
    .addomain.tld = ADDOMAIN.TLD
    addomain.tld = ADDOMAIN.TLD

  • /etc/nsswitch.conf
passwd:         files winbind
group:          files winbind
shadow:         files sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
sudoers:        files

  • /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)  
auth	[success=4 default=ignore]	pam_krb5.so minimum_uid=1000
auth	[success=3 default=ignore]	pam_unix.so nullok try_first_pass
auth	[success=2 default=ignore]	pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth	[success=1 default=ignore]	pam_sss.so use_first_pass
# here's the fallback if no module succeeds  
auth	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;  
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)  
# end of pam-auth-update config

Frohe Pfingsten
HansDampf06
colinardo
colinardo 04.06.2022 aktualisiert um 21:45:14 Uhr
Goto Top
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 (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.

screenshot

screenshot

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
Dito

Grüße Uwe
HansDampf06
HansDampf06 05.06.2022 um 12:29:53 Uhr
Goto Top
Zitat von @colinardo:

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 (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.

Dieses Missverständnis ist von der Originalquelle für die pam_winbind-Parameter provoziert worden. Dort ist nach meinem Verständnis beschrieben, dass samlogon das Fallback für die aktivierte Kerberos-Authentifizierung ist. Diese Authentifizierung hat vier einstellbare Varianten, wovon FILE die Default-Variante ist, wenn gar nichts weiter konfiguriert wurde außer cached_login=yes. 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.

Ausprobiert hatte ich daneben die Variante KEYRING. Aber auch dort dasselbe Verhalten: Im Online-Modus funktionieren alle Authentifizierungen wie erwartet und prompt. Hingegen im Offline-Modus wird das Passwort als fehlerhaft bezeichnet. Für das Scheitern der Anmeldung findet sich dann übereinstimmend in auth.log:

lightdm: pam_winbind(ligthdm:auth): PAM config: krb5_cache_type 'KEYRING'  
lightdm: pam_winbind(ligthdm:auth): [pamh: 0x...] LEAVE: pam_sm_authenticate returning 10 (PAM_USER_UNKNOW)

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.
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? Wenn es nicht irrtümlich ist, müsste irgendwo dort die Ursache für das Scheitern der Authentifizierung zu finden sein. Ein Rechteproblem? Wenn ja, an welcher Stelle? ...

Insgesamt ist das einigermaßen irritierend, wenn dann das Logon im Offline-Modus nicht funktioniert, obschon die Konfiguration selbst wohl keinen Fehler meinerseits scheint erkennen zu lassen ...

Die Debian-VM ist nahezu jungfräulich: Installation vom ISO, Update auf aktuellen Stand, Einbindung ins Active Directory. Hinzugekommen ist dann "lediglich" winehq-stable, um mit der VM die Nutzbarkeit relevanter Windowsprogramme, die keine(n) Linux-Variante/-Ersatz haben, unter Linux testen zu können. Auch insoweit erfolgte die Installation nach Standard aus den öffentlichen Repositorien. Könnte wine der Fehlerteufel sein? Jedoch wäre das für mich gar nicht naheliegend, weil wine eigentlich nichts mit der Authentifizierung zu schaffen hat.

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:

  • log.wb-AP201N
[2022/06/05 10:50:09.374131,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=0)
[2022/06/05 10:51:35.732087,  0] ../../source3/winbindd/winbindd_cm.c:1873(wb_open_internal_pipe)
  open_internal_pipe: Could not connect to dssetup pipe: NT_STATUS_RPC_INTERFACE_NOT_FOUND
[2022/06/05 10:51:35.736282,  0] ../../source3/rpc_server/rpc_ncacn_np.c:454(rpcint_dispatch)
  rpcint_dispatch: DCE/RPC fault in call lsarpc:2E - DCERPC_NCA_S_OP_RNG_ERROR

  • log.winbindd
[2022/06/05 10:50:09.361021,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=1)
[2022/06/05 10:51:35.696066,  0] ../../source3/winbindd/winbindd.c:1773(main)
  winbindd version 4.13.13-Debian started.
  Copyright Andrew Tridgell and the Samba Team 1992-2020
[2022/06/05 10:51:35.725952,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
  daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections  

  • log.wb-ADDOMÄNE
[2022/06/05 10:50:09.372280,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=0)

  • log.winbindd-idmap
[2022/06/05 10:50:09.375867,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=0)

  • log.smbd
[2022/06/05 10:51:35.824928,  0] ../../source3/smbd/server.c:1784(main)
  smbd version 4.13.13-Debian started.
  Copyright Andrew Tridgell and the Samba Team 1992-2020
[2022/06/05 10:51:35.884461,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
  daemon_ready: daemon 'smbd' finished starting up and ready to serve connections  
[2022/06/05 10:51:35.888463,  0] ../../source3/printing/nt_printing.c:252(nt_printing_init)
  nt_printing_init: error checking published printers: WERR_ACCESS_DENIED

  • log.nmbd
[2022/06/05 10:51:15.534224,  0] ../../source3/nmbd/nmbd.c:960(main)
  nmbd version 4.13.13-Debian started.
  Copyright Andrew Tridgell and the Samba Team 1992-2020
[2022/06/05 10:51:15.539560,  0] ../../lib/util/become_daemon.c:147(daemon_status)
  daemon_status: daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...  
[2022/06/05 10:51:15.539628,  0] ../../source3/nmbd/nmbd_subnetdb.c:253(create_subnets)
  NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).

Viele Grüße
HansDampf06
colinardo
colinardo 05.06.2022 aktualisiert um 15:17:57 Uhr
Goto Top
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.

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.
Würde ich nicht unbedingt. Auf jeden Fall diese mal deaktivieren/deinstallieren. Ich arbeite hier ausschließlich ohne GUI auf Servern.


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:

Deine Logs sind leider nicht im Debug Level. Stelle die Loglevel auf 10 in der smb.conf, bevor du dich erneut versuchst anzumelden nachdem du offline gegangen bist.

Poste auch mal die Parameter womit winbind in seinem systemd unit aufgerufen wird.
colinardo
Lösung colinardo 05.06.2022 aktualisiert um 17:40:15 Uhr
Goto Top
idmap config ADDOMAIN : backend = ad
Nach einem kurzen Test liegt hier wohl der Hase im Pfeffer. Nimm mal testweise tdb als Backend.
HansDampf06
HansDampf06 05.06.2022 aktualisiert um 21:48:19 Uhr
Goto Top
Zitat von @colinardo:

idmap config ADDOMAIN : backend = ad
Nach einem kurzen Test liegt hier wohl der Hase im Pfeffer. Nimm mal testweise tdb als Backend.

Nein, leider nicht. Denn ad steht für die direkte Verbindung zum Active Directory als originäre Quelle. Ändere ich es auf tdb, kann ich mich weder im Online-Modus anmelden noch per id Benutzer die UID-/GID-Daten abfragen. Also das ad ist an dieser Stelle zwingend, was auch im Online-Modus problemfrei funktioniert.

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? In den FAQ sind nur Bilddateien benannt und auch der obigen Editierbutton ist nur auf Fotos fokussiert.

Noch einen schönen Pfingstabend
HansDampf06

PS:
Hier noch die Erläuterung zu dem Erfordernis ad gemäß Samba-Wiki: Bei dem hiesigen Active Directory sind die uidNumber und gidNumber durch direkte Vergabe im Active Directory in der gesamten Domäne hinsichtlich des id-Mappings zentralisiert und vereinheitlicht. Das stellt sorgenfrei sicher, dass ein konkreter AD-Benutzer(/-Gruppe) auf allen Domänenmitgliedern dieselbe ID verwendet. Ursprünglich war das nicht so und erschwerte die Rechteverwaltung durch die Beliebigkeit des Mappings. Selbst ein Löschen der Winbind-Datenbank konnte auf ein und demselben Domänenmitglied zu erheblichen Abweichungen führen. Es ist also eine bewusste Konfigurationsentscheidung.

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.
colinardo
Lösung colinardo 05.06.2022 aktualisiert um 22:32:43 Uhr
Goto Top
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 😉.
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.
HansDampf06
Lösung HansDampf06 06.06.2022 um 15:51:02 Uhr
Goto Top
Zitat von @colinardo:

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.

Das, was ich als Hinweis auf das Scheitern der Anmeldung gefunden habe, ist folgendes:

  • log.winbindd:
[2022/06/05 13:37:07.001054,  5, pid=5467, effective(0, 0), real(0, 0), class=winbind] ../../source3/winbindd/winbindd_getpwnam.c:141(winbindd_getpwnam_recv)
  Could not convert sid S-1-...-1127: NT_STATUS_NO_SUCH_USER


  • auth.log:
Jun  5 13:37:06 AP213 lightdm: pam_krb5(lightdm:auth): authentication failure; logname=ADDOMÄNE\Benutzer uid=0 euid=0 tty=:0 ruser= rhost=
Jun  5 13:37:07 AP213 lightdm: pam_unix(lightdm:auth): check pass; user unknown
Jun  5 13:37:07 AP213 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= 
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): [pamh: 0x563b49b60190] ENTER: pam_sm_authenticate (flags: 0x0000)
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): getting password (0x00000389)
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): pam_get_item returned a password
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): Verify user 'ADDOMÄNE\Benutzer'  
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): PAM config: krb5_ccache_type 'KEYRING'  
Jun  5 13:37:07 AP213 lightdm: pam_winbind(lightdm:auth): [pamh: 0x563b49b60190] LEAVE: pam_sm_authenticate returning 10 (PAM_USER_UNKNOWN)
=> Die hiesige letzte Zeile korrespondiert mit dem obigen Eintrag, dass die SID nicht convertiert werden könne. Diesen Eintrag hat er viermal geworfen. Im Übrigen konnte er mit den Cache-Daten wohl ordnungsgemäß umgehen.

  • Ausgabe von net cache samlogon list betreffend den Benutzer des Anmeldeversuchs:
S-1-...-1127	ADDOMÄNE\Benutzer	So Jun 5 10:44:17 2022 CEST
=> Das entspricht dem obigen Eintrag.

Stimmt der Convertierungsfehler mit Deinem Debug-Trace für das Scheitern überein? Das würde mich auf jeden Fall interessieren.

Ungeachtet dessen:

Der Wechsel des Backends auf tdb kommt hier eher nicht in Betracht. Dort war die hiesige AD-weite Konfiguration einmal und wurde bewusst verlassen, so dass dorthin auch nicht zurückgekehrt werden wird. Dennoch steht die Frage des Backend-"Wechsels" in gewisser Weise im Ausgangspunkt im Raum, um eine betriebssichere Offline-Anmeldung zu etablieren.

Denn ist es scheinbar generell so, dass Winbind im Falle des Backends ad trotz des Cachings seine Probleme hat, wenn die Verbindung zu den DC's ausfällt oder sich irgendwie ändert (WBC_ERR_WINBIND_NOT_AVAILABLE und WBC_ERR_DOMAIN_NOT_FOUND). Die bei einem Betroffenen hilfreiche Lösung, unix_nss_info auf no zu setzen, war hier wirkungslos. Die Problemlage ist jedenfalls bereits seit längerem bekannt (vgl. diese weitere Bug-Meldung), ohne dass bisher eine greifbare Lösung ersichtlich ist.

Indes muss für den "Wechsel" an der smb.conf und konkret am Backend gar nichts geändert werden, was schon einmal ein riesiger Vorteil ist. Denn bekanntlich lautet (1) die Alternative zu Winbind sssd, (2) die dabei zu wählende Konfiguration der smb.conf ist identisch und (3) ist hier sssd bereits bekannt, sprich: eine funktionierende und erprobte Konfiguration existiert im hiesigen Active Directory bereits. Als nämlich vor längerer Zeit der Weg von Windows in Richtung Linux eingeschlagen wurde, ging es zunächst um eine Protierung des SQL Servers und nach den damaligen Vorgaben war für die windowsintegrierte Anmeldung - das ist fast wie ein Deja-vu - die Verwendung von sssd erforderlich, weil das Winbind nicht beherrscht. Winbind und sssd können wunderbar koexistieren, was durch die identische Konfiguration der smb.conf unterstrichen wird.

Somit reduziert sich der Lösungsaufwand auf die Installation von sssd, den Eintrag von sss vor winbind in der nsswitch.conf und das Vorziehen der Zeile von sssd vor winbind in der common-auth. Das ist insgesamt sehr überschau- und leicht nachvollziehbar, insbesondere zugleich betriebssicher. Der administrative Aufwand ist zudem als gering zu bezeichnen.

Conclusio: Besten Dank an Dich @colinardo für Deinen hilfreichen Einsatz. Immerhin hast Du mit Deinem Vorschlag, das Backend zu wechseln, den Impuls gegeben, nun doch auch für die Fälle der möglichen Offline-Anmeldung den Weg über sssd zu gehen.

Noch einen schönen Pfingstmontag
HansDampf06