Tobias Crefeld [13.11.2015 19:22]:

Am Fri, 13 Nov 2015 16:52:21 +0100 schrieb Werner Flamme :

...

Hallo miteinander,

ich versuche gerade, eine Konfiguration hinzubekommen, wie ich mich gegen LDAP authentifizieren kann. Das soll ja mit sssd möglich sein, und "man sssd-ldap" ist auch recht lang.

Bei mir geht das einfach nicht. Wenn ich als root angemeldet bin und "ssh wflamme@localhost" versuche, erhalte ich nach korrekter Eingabe des Passworts nur:

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=wflamme

im Log. Obwohl ich bei allen Aufrufen von pam_unix schon den Parameter debug mitgebe, erhalte ich hier keine weitere Info.

Ein "getent passwd wflamme" funktioniert, die Daten werden korrekt aus dem LDAP gezogen.

In dem [domain/intranet] Abschnitt habe ich folgende Einträge:

id_provider = ldap auth_provider = ldap chpass_provider = ldap access_provider = ldap ldap_access_filter = (uid=wflamme) ldap_schema = rfc2307 ldap_uri = ldaps://192.168.22.91 ldap_search_base = dc=fasel,dc=bla ldap_user_search_base = ou=People,dc=fasel,dc=bla ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/ssl/certs ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid cache_credentials = true enumerate = False

Habe ich da offensichtliche Fehler drin? Der GUI im YaST ist ja keine wirkliche Hilfe. Oder wo kann ich suchen, wenn mir pam_unix schon keine Infos gibt?

In /var/log/sssd gibt es eine Datei ldap_child.log mit 0 Bytes, im sssd.log steht nur Sülz, in sssd_pam.log finde ich keinen Hinweis auf einen Login-Versuch, sssd_nss.log ist auch leer. In sssd_intranet.log finde ich immerhin Hinweise, dass der LDAP-Server als "working" markiert wird. Und eine Anfrage wird gestartet, die mit "Success(0), no errmsg set" endet.

Bei mir war's ein Fehler beim SSL-Zertifikat, aber das muss nichts heißen.

Inwiefern ldap_schema rfc2307 reicht, ist auch so eine Frage. Die korrekte Unterstützung von Unix-Clients auf einem LDAP, dass auch Windows-Clients unterstützt, benötigt wohl zwangsläufig rfc2307bis, aber lassen wir das.

Der LDAP-Server ist ein Oracle-Exemplar, ehemals Sun Java Directory Server, der hatte aber auch andere Namen. Der ist nicht für Windows-Clients da, für die gibt es Windows-Domaincontroller.

Wichtig ist natürlich erstmal, dass in /etc/nsswitch.conf sss verwendet wird, also irgendwas wie "passwd files sss" eingetragen ist.

Das ist es offenbar so, denn bei "getent passwd wflamme" bekomme ich ja die Zeile zurück, obwohl wflamme ein LDAP-User ist. passwd: compat sss group: compat sss [...] passwd_compat: files group_compat: files

Im Kern scheint mir jedoch für Deine weitere Fehleranalyse eine Erhöhung des debug-Levels pro Sektion angeraten (siehe man sssd.conf).

Bei debug_level habe ich 0x0770 eingetragen. Bedeutet also Fatal, Critical und Serious Failures (keine Minor errors), Configuration settings, Function data und Trace messages for operation functions. Da sollte doch alles auftauchen, oder? Zumindest sollten hier Fehler der Art "User nicht gefunden" kommen. Und der Eintrag ist in allen Sections vorhanden. Gruß Werner --

Kai Grunau [16.11.2015 11:55]:

Hallo Werner ,

On 11/13/2015 04:52 PM, Werner Flamme wrote:

...

Hallo miteinander,

ich versuche gerade, eine Konfiguration hinzubekommen, wie ich mich gegen LDAP authentifizieren kann. Das soll ja mit sssd möglich sein, und "man sssd-ldap" ist auch recht lang.

Bei mir geht das einfach nicht. Wenn ich als root angemeldet bin und "ssh wflamme@localhost" versuche, erhalte ich nach korrekter Eingabe des Passworts nur:

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=wflamme

im Log. Obwohl ich bei allen Aufrufen von pam_unix schon den Parameter debug mitgebe, erhalte ich hier keine weitere Info.

Ein "getent passwd wflamme" funktioniert, die Daten werden korrekt aus dem LDAP gezogen.

In dem [domain/intranet] Abschnitt habe ich folgende Einträge:

id_provider = ldap auth_provider = ldap chpass_provider = ldap access_provider = ldap ldap_access_filter = (uid=wflamme) ldap_schema = rfc2307 ldap_uri = ldaps://192.168.22.91 ldap_search_base = dc=fasel,dc=bla ldap_user_search_base = ou=People,dc=fasel,dc=bla ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/ssl/certs ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid cache_credentials = true enumerate = False

Habe ich da offensichtliche Fehler drin? Der GUI im YaST ist ja keine wirkliche Hilfe. Oder wo kann ich suchen, wenn mir pam_unix schon keine Infos gibt?

In /var/log/sssd gibt es eine Datei ldap_child.log mit 0 Bytes, im sssd.log steht nur Sülz, in sssd_pam.log finde ich keinen Hinweis auf einen Login-Versuch, sssd_nss.log ist auch leer. In sssd_intranet.log finde ich immerhin Hinweise, dass der LDAP-Server als "working" markiert wird. Und eine Anfrage wird gestartet, die mit "Success(0), no errmsg set" endet.

Ich vermute, dass für sssd der Account OK ist. Aber warum nicht für pam_unix?

Das erinnert mich an tagelanges Frickeln mit pam_mount, bis eine funktionierende Konfiguration gefunden war - die zwar nicht der Doku entsprach, aber klappte...

ich habe mich heute daran gemacht einen Rechner mit openSUSE leap 42.1 an unser Ldap zu binden und es funktioniert.

Die Settings, die Du in Deiner sssd.conf eingetragen hast, entsprechen mit ein wenig Modifikationen den unsrigen.

Die Initialisierung der Ldap Einstellung habe ich über Yast angestossen. Es wurden die notwendigen zusätzlichen Softwarepakete automatisch installiert :

sssd-krb5-common-1.11.5.1-5.1.x86_64 sssd-1.11.5.1-5.1.x86_64 sssd-ldap-1.11.5.1-5.1.x86_64 libini_config3-1.0.0.1-21.1.x86_64 sssd-32bit-1.11.5.1-5.1.x86_64 libsss_idmap0-1.11.5.1-5.1.x86_64 libref_array1-0.1.3-21.1.x86_64 libpath_utils1-0.2.1-21.1.x86_64 libnl1-1.1.4-3.6.x86_64 libdhash1-0.4.3-21.1.x86_64 libcollection2-0.6.2-21.1.x86_64 libcares2-1.9.1-3.2.x86_64 libbasicobjects0-0.1.0-21.1.x86_64

Ausserdem wurden Aenderungen in den 4 Dateien

common-account-pc (account sufficient pam_localuser.so account required pam_sss.so use_first_pass ) common-session-pc (session optional pam_sss.so) common-password-pc (password required pam_sss.so use_authtok) common-auth-pc (auth required pam_sss.so use_first_pass)

und in /etc/nsswitch.conf vorgenommen.

Hth, Kai

Naja, so richtig hilfreich ist es wieder nicht, obwohl die Richtung stimmen dürfte :) Erstens handelt es sich um einen SLES 12, nicht um Leap. Aber Leap beruht ja auf SLE-12, kommt also halbwegs hin. Zweitens: in meiner /etc/pam.d/common-account-pc steht überhaupt nur account required pam_unix.so try_first_pass debug in /etc/pam.d/common-session-pc: session required pam_limits.so session required pam_unix.so try_first_pass debug session required pam_mkhomedir.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so in /etc/pam.d/common-password-pc: password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password required pam_unix.so use_authtok nullok shadow try_first_pass debug und in /etc/pam.d/common-auth-pc: auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so try_first_pass debug debug also nirgendwo etwas vom sssd, obwohl eine /lib64/security/pam_sss.so existiert. An welcher Stelle wurden Deine Zeilen eingefügt? Vorne, hinten, irgendwo mitten drin? Die Reihenfolge ist ja wichtig. Gruß Werner --

Moin, On 11/17/2015 09:45 AM, Werner Flamme wrote:

Kai Grunau [16.11.2015 11:55]:

...

Hallo Werner ,

On 11/13/2015 04:52 PM, Werner Flamme wrote:

...

Hallo miteinander,

ich versuche gerade, eine Konfiguration hinzubekommen, wie ich mich gegen LDAP authentifizieren kann. Das soll ja mit sssd möglich sein, und "man sssd-ldap" ist auch recht lang.

Bei mir geht das einfach nicht. Wenn ich als root angemeldet bin und "ssh wflamme@localhost" versuche, erhalte ich nach korrekter Eingabe des Passworts nur:

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=wflamme

im Log. Obwohl ich bei allen Aufrufen von pam_unix schon den Parameter debug mitgebe, erhalte ich hier keine weitere Info.

Ein "getent passwd wflamme" funktioniert, die Daten werden korrekt aus dem LDAP gezogen.

In dem [domain/intranet] Abschnitt habe ich folgende Einträge:

id_provider = ldap auth_provider = ldap chpass_provider = ldap access_provider = ldap ldap_access_filter = (uid=wflamme) ldap_schema = rfc2307 ldap_uri = ldaps://192.168.22.91 ldap_search_base = dc=fasel,dc=bla ldap_user_search_base = ou=People,dc=fasel,dc=bla ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/ssl/certs ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid cache_credentials = true enumerate = False

Habe ich da offensichtliche Fehler drin? Der GUI im YaST ist ja keine wirkliche Hilfe. Oder wo kann ich suchen, wenn mir pam_unix schon keine Infos gibt?

In /var/log/sssd gibt es eine Datei ldap_child.log mit 0 Bytes, im sssd.log steht nur Sülz, in sssd_pam.log finde ich keinen Hinweis auf einen Login-Versuch, sssd_nss.log ist auch leer. In sssd_intranet.log finde ich immerhin Hinweise, dass der LDAP-Server als "working" markiert wird. Und eine Anfrage wird gestartet, die mit "Success(0), no errmsg set" endet.

Ich vermute, dass für sssd der Account OK ist. Aber warum nicht für pam_unix?

Das erinnert mich an tagelanges Frickeln mit pam_mount, bis eine funktionierende Konfiguration gefunden war - die zwar nicht der Doku entsprach, aber klappte...

ich habe mich heute daran gemacht einen Rechner mit openSUSE leap 42.1 an unser Ldap zu binden und es funktioniert.

Die Settings, die Du in Deiner sssd.conf eingetragen hast, entsprechen mit ein wenig Modifikationen den unsrigen.

Die Initialisierung der Ldap Einstellung habe ich über Yast angestossen. Es wurden die notwendigen zusätzlichen Softwarepakete automatisch installiert :

sssd-krb5-common-1.11.5.1-5.1.x86_64 sssd-1.11.5.1-5.1.x86_64 sssd-ldap-1.11.5.1-5.1.x86_64 libini_config3-1.0.0.1-21.1.x86_64 sssd-32bit-1.11.5.1-5.1.x86_64 libsss_idmap0-1.11.5.1-5.1.x86_64 libref_array1-0.1.3-21.1.x86_64 libpath_utils1-0.2.1-21.1.x86_64 libnl1-1.1.4-3.6.x86_64 libdhash1-0.4.3-21.1.x86_64 libcollection2-0.6.2-21.1.x86_64 libcares2-1.9.1-3.2.x86_64 libbasicobjects0-0.1.0-21.1.x86_64

Ausserdem wurden Aenderungen in den 4 Dateien

common-account-pc (account sufficient pam_localuser.so account required pam_sss.so use_first_pass ) common-session-pc (session optional pam_sss.so) common-password-pc (password required pam_sss.so use_authtok) common-auth-pc (auth required pam_sss.so use_first_pass)

und in /etc/nsswitch.conf vorgenommen.

Hth, Kai Naja, so richtig hilfreich ist es wieder nicht, obwohl die Richtung stimmen dürfte :)

Erstens handelt es sich um einen SLES 12, nicht um Leap. Aber Leap beruht ja auf SLE-12, kommt also halbwegs hin. das es ein SLES 12 ist kann man nicht wissen, wenn ....

Zweitens: in meiner /etc/pam.d/common-account-pc steht überhaupt nur account required pam_unix.so try_first_pass debug es folgen die Inhalte der 4 modifizierten Dateien :

/etc/pam.d/common-account-pc account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass

in /etc/pam.d/common-session-pc: session required pam_limits.so session required pam_unix.so try_first_pass debug session required pam_mkhomedir.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so

/etc/pam.d/common-session-pc session optional pam_mkhomedir.so session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so

in /etc/pam.d/common-password-pc: password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password required pam_unix.so use_authtok nullok shadow try_first_pass debug

/etc/pam.d/common-password-pc password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password sufficient pam_unix.so use_authtok nullok shadow try_first_pass password required pam_sss.so use_authtok

und in /etc/pam.d/common-auth-pc: auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so try_first_pass debug debug

/etc/pam.d/common-auth-pc auth required pam_env.so auth optional pam_gnome_keyring.so auth sufficient pam_unix.so try_first_pass auth required pam_sss.so use_first_pass Gruss, Kai