Kai Grunau [17.11.2015 10:00]:
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
Danke, das war's! Mit diesen Einträgen klappt die Anmeldung! Werde die Authentifizierung auf einer anderen VM nochmal versuchen mit YaST einzurichten. Wenn dann wieder keine Einträge in den pam-Dateien kommen, gibt es einen Bugreport. Gruß Werner --