lists.arthurdejong.org
RSS feed

Re: Help the newbie please

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

Re: Help the newbie please



On Tue, 2010-03-16 at 20:55 -0500, Kean Johnston wrote:
> I think the problem I am having is with the PAM portion of
> nss-pam-ldapd but if it isn't, and you either happen to know the
> answer or can point me in the direction of docs or lists that may
> provide it, I would be much obliged.

Documentation for the nssov overlay is mostly present in the OpenLDAP
nssov overlay itself [0]. Any nssov-specific questions are probably best
asked on the openldap-software mailing list.

I don't have much first-hand experience with nssov yet so I can't
comment on those parts too much.

> First let me describe the environment. Running CentOS 5.3 with a
> custom compiled version of OpenLDAP 2.4.21 with nssov. Using
> nss-pam-ldapd (which I will call N-P-L for short from now on) 0.7.3
> but obviously not using the daemon part of it due to using nssov.

You should be able to combine nssov with current versions of
nss-pam-ldapd. The protocol between the NSS and PAM modules on one end
and the nssov overlay or nslcd on the other is tried to be kept as
constant as possible.

There could be incompatibilities though (especially the PAM module is
still changing somewhat) so you could try an older version of
nss-pam-ldapd (OpenLDAP includes 0.6.2).

> The relevant bits of the various configuration files are posted here
> so I don't clutter the mailing list: http://unix42.com/ldap

In /etc/nsswitch.conf I would put the files lookups before ldap. The
reason for this is there can always be cases where lookups through LDAP
can cause delays (network problems, sldap overloaded, etc). In these
circumstances it is important to be able to log in as root to diagnose
the problem. If this is delayed by LDAP lookups it will slow things
down. Another reason is performance. Your slapd will be hit quite often
by applications doing name lookups that can simply be found in flat
files.

Another thing that could confuse something is the host lookups through
LDAP. I'm not 100% sure about nssov but nslcd does some tricks to
prevent it from doing hostname lookups through LDAP itself. It should
work but when debugging try without it.

About /etc/pam.d/system-auth: again I would put pam_unix before pam_ldap
for the same reasons as outlined above. Also, the first line probably
shouldn't have the try_first_pass option. For reference Debian's PAM
authentication file looks like this (when libpam-ldap(d) is installed):

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

I always have trouble reading PAM configuration files.

> I can do all the various LDAP things I want like ldapsearch and such
> but I absolutely cannot figure out how to log in. ssh fails (ssh -vvv
> yields absolutely no useful information at all), there are no errors
> in /var/log/messages and pam_ldap doesn't have any form of debugging
> (BTW would you accept a patch to add some?) so I can't see where its
> failing.

Error messages from sshd and PAM are in /var/log/auth.log in Debian, I
don't know if CentOS uses something equivalent.

Patches for logging debugging information from the PAM module are very
welcome (see [1]).

> The only GOOD news is that NSS seems to be working ok. It may in fact
> be the root of my problems:
> getent passwd jkj
>    jkj:{SSHA}REMOVED:1009:1010:Kean Johnston:/home/jkj:/bin/bash
> getend shadow ldapadm
>    ldapadm:{SSHA}REMOVED:::::::0

If the NSS layer returns a password entry pam_unix may try to do
authentication which could mess things up but since you have pam_ldap
first I don't think this makes a difference. Anyway, there is no need to
expose password hashes through NSS.

The best way to debug this would be to try with a simpler authentication
than SSH (e.g. modify /etc/pam.d/su or something else you can easily
test) and see if you can get that working. SSH also does not always use
PAM for authentication (see the UsePAM option).

Also, you could try with an older version of nss-pam-ldapd or even try
nslcd (this can produce quite reasonable debugging information) so see
if the problem is in the PAM stack or in the LDAP part. slapd should
also log some things (you have to find the magic loglevel to use
though).

> The one other thing I noticed was trying to set a users password using the 
> passwd command as root. It asked for the LDAP administrator pasword. What 
> password is that? Any this flies in the face of traditional use of the 
> passwd tool where a root user (a sysadmin) should have power to change a 
> user's password but may very well NOT be the LDAP administrator becuase a 
> sysadmin doesn't need and shouldn't have access to the full directory 
> (thing: sensitive HR info in the LDAP directory). Would the following 
> change to pam.c fix this? (line 695):
> 
> if ((pwent!=NULL)&&(pwent->pw_uid!=getuid() && getuid() != 0))

The difference between flat files and LDAP here is that you need to be
authentication to do password modification. Access to /etc/shadow is
implemented by suid executables but this is only partially possible with
LDAP. Since the protocol to handle NSS and PAM requests runs over a
socket it is much more difficult to determine if the root user is trying
to update a password. Implementing this check in the PAM module is not
an option because any user can communicate over the socket. This is
further complicated because most PAM functionality is run as effective
userid 0 (even when not started by the root user).

With release 0.7.3 nss-pam-ldapd introduces a rootpwmoddn configuration
file option which directs nslcd to not authenticate as the current user
when run as root (try to look up the root user in LDAP) but to
authenticate as the user configured in rootpwmoddn. In any case a
password needs to be provided to check the authenticity of the user.

The rootpwmoddn LDAP user must be able to update the userPassword
attribute and you could even limit that with access controls to entries
which may be modified by that user.

I don't think password modification by root is implemented in nssov (but
I may be mistaken) so the above is more about nslcd than nssov.

[0] http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/nssov/
[1] 
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-see-programming-syslog.html

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users