Re: [gentoo-user] nss_updatedb && pam_ccreds

[Daniel Troeder]

On 07/29/2010 06:50 PM, Giampiero Gabbiani wrote:
> Hi all,
> I configured nss & pam in order to make LDAP authentication. In order to
> have a proper authentication and attributes retrieving I added also ccreds
> and nss_updatedb modifying /etc/pam.d/system-auth for the first and
> /etc/nsswithch for both:
>
> /etc/pam.d/system-auth:
>
> auth            [success=done default=ignore]                   pam_unix.so
> nullok_secure try_first_pass debug
> auth            [authinfo_unavail=ignore success=1 default=2]   pam_ldap.so
> use_first_pass
> auth            [default=done]
> pam_ccreds.so action=validate use_first_pass
> auth            [default=done]
> pam_ccreds.so action=store
> auth            [default=bad]
> pam_ccreds.so action=update
>
> account         [user_unknown=ignore authinfo_unavail=ignore default=done]
> pam_unix.so debug
> account         [user_unknown=ignore authinfo_unavail=ignore default=done]
> pam_ldap.so debug
> account         required
> pam_permit.so
>
> password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2
> ocredit=2 try_first_pass retry=3
> password        sufficient      pam_unix.so try_first_pass use_authtok
> nullok md5 shadow
> password        sufficient      pam_ldap.so use_authtok use_first_pass
> password        required        pam_deny.so
>
> session         optional        pam_mkhomedir.so skel=/etc/skel/ umask=0022
> session         required        pam_limits.so
> session         required        pam_env.so
> session         required        pam_unix.so
> session         optional        pam_permit.so
> session         optional        pam_ldap.so
>
> # /etc/nsswitch.conf:
> # $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v
> 1.1 2006/09/29 23:52:23 vapier Exp $
>
> passwd:         files ldap [NOTFOUND=return] db
> shadow:         files ldap
> group:          files ldap [NOTFOUND=return] db
>
> #passwd:      files ldap
> #shadow:      files ldap
> #group:       files ldap
>
> # passwd:    db files nis
> # shadow:    db files nis
> # group:     db files nis
>
> hosts:       files dns
> networks:    files dns
>
> services:    db files
> protocols:   db files
> rpc:         db files
> ethers:      db files
> netmasks:    files
> netgroup:    files ldap
> bootparams:  files
>
> automount:   files ldap
> aliases:     files
>
> sudoers:        ldap files
>
> the problem is that, when the connection to the ldap server is down, I can't
> login:
>
> Jul 18 19:22:59 athena login[10600]: pam_unix(login:auth): check pass; user
> unknown
> Jul 18 19:22:59 athena login[10600]: pam_unix(login:auth): authentication
> failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost=
> Jul 18 19:22:59 athena login[10600]: pam_ldap: ldap_simple_bind Can't
> contact LDAP server
> Jul 18 19:23:02 athena login[10600]: nss_ldap: failed to bind to LDAP server
> ldap://vesta.homenet.telecomitalia.it: Can't contact LDAP server
> Jul 18 19:23:02 athena login[10600]: nss_ldap: could not search LDAP server
> - Server is unavailable
> Jul 18 19:23:02 athena login[10600]: FAILED LOGIN (1) on 'tty2' FOR
> `UNKNOWN', User not known to the underlying authentication module
>
> from the last line above it seems like the credentials were not cached or the
> nss switch doesn't use the db service for the passwd and shadow database.
>
> Is there someone that has a working configuration in order to have the
> cached credentials systems working properly ?
>
> Regards
> Giampiero
>
I haven't done this on Gentoo, only on a Ubuntu 10.04 system of a
client, but there it works like a charm. So I don't know if the
following applies, but here are my ideas:

Did you run "sudo nss_updatedb ldap"? In Ubuntu it fetches the
(non-password) data for "getent passwd" and "getent group" and stores it
in /var/lib/misc/passwd.db and /var/lib/misc/group.db.
Check those files. You should be able to list LDAP-users and LDAP-groups
now without connection to the LDAP (by running "getent passwd" and
"getent group").

The PAM configuration is very different of course.

Then to be able to login the user must have logged in once with the LDAP
connected, so that the password can be stored locally. If that was
successful, can be checked by running "sudo cc_dump". It prints:

$ sudo cc_dump

Credential Type  User   Service Cached Credentials
------------------------------------------------------------------------
Salted SHA1      daniel any     788e8f863a089211911dbbf1774ce141516936f4


Hope it helps...
Daniel


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887