[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

PAM config and LDAP [WAS: Re: LDAP breaks kcheckpass when not setuid root (#298148)]

On Fri, May 04, 2007 at 12:17:03PM -0700, Steve Langasek wrote:
> If you use libnss-ldap+pam_unix for authentication, authentication involves
> the system querying the password hash from LDAP across the network, and
> using pam_unix to attempt to authenticate against it.  If normal users do
> not have access to query the password hash from LDAP (a correct
> configuration), pam_unix should fall back to using /sbin/unix_chkpwd, a
> setuid binary that's only allowed to query the password for the current
> user.  You can test whether /sbin/unix_chkpwd works on your system with:
> $ cat | /sbin/unix_chkpwd `id -u -n` nullok ; echo $?
> <your password here>^D^M
> as a non-root user and checking whether the exit value is 0.  If it doesn't
> work, you still have a PAM misconfiguration.  (If it does work, something's
> really broken, but maybe not the configuration...)
This may be starting to drift OT, but here goes.  In my case, I am using
libnss-ldap and libpam-ldap.  I have both pam_unix.so and pam_ldap.so
listed in common-{account,auth,password}.  My LDAP configuration is such
that regular users cannot see passwords, except for their own passwords
once they have authenticated:

access to attrs=userPassword
        by dn="cn=admin,dc=foo,dc=bar" write
        by anonymous auth
        by self write
        by * none

Now, if the incantation above gives a zero, then is that good or bad?  I
am guessing that it is OK, since I also have pam_ldap.so in my
configuration, but I am not sure.

> Er, LDAP is a network service.  If you mean that the LDAP server runs
> locally, that's fine, but otherwise you should take care to protect the
> integrity of your network traffic.  (Even if you use libpam-ldap and aren't
> sending password hashes across the network, you probably don't need a MITM
> attack granting attackers access to your systems.)
Being paranoid, I only allow connections to the LDAP server using the
UNIX domain socket (for local processes on the server) and via SSL.
However, this causes other really annoying problems:




Roberto C. Sánchez

Attachment: signature.asc
Description: Digital signature

Reply to: