[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
nss-ldap not working for non-root users
Hi,
This isn't really an OpenLDAP question, since it relates more to a
problem with the underlying LDAP transport of
getpwnam(). Nevertheless, I am trying to communicate with an OpenLDAP
directory server, so this seemed as good a place as any to post my
question.
I have a number of Linux systems that use nss_ldap with great
success. nss_ldap is an extension library to the Linux C library that
allows the configuration of LDAP as a name service in
/etc/nsswitch.conf.
All of my systems work admirably, with the exception of one new system
that is giving me a major headache. After extensive tests, I have
narrowed the problem down to the fact that getpwnam() look-ups are not
happening over LDAP when a non-root user is initiating the query.
The relevant part of my /etc/nsswitch.conf looks like this:
passwd: files ldap
shadow: files ldap
group: files ldap
The following command, when run as root, produces no output:
perl -e '($name,$passwd,$uid,$gid) = getpwnam($ARGV[0]); print $uid' kgerber
However, when run as root, it prints 783, which is kgerber's
uid. kgerber is not in /etc/passwd, so I know that the look-up is
occurring correctly over LDAP. Both tcpdump and full trace debugging
on the LDAP server (which is OpenLDAP 2.0.7, running on the same box)
attest to this also.
Running tcpdump and checking the LDAP server's log, it's clear that
the LDAP look-up does not take place when the command is run as a
non-root user. getpwnam() will return the UID of anyone in
/etc/passwd, but will not go to LDAP for the UID of anyone who isn't.
nscd has been disabled on this box, so there are no caching issues at
play here. However, if I *start* nscd and then immediately run the
above one-liner as a non-root user, the UID *is* printed.
So, getpwnam() works over LDAP in combination with nscd, but not
without, which is logical in the context of my problem, since nscd
runs as root and thus successfully performs the look-up on behalf of
the Perl command.
Another sign that something is anomalous on this box is when I print
the $passwd field using the above Perl one-liner. As root, it prints
the crypted password rather than just 'x' as it does on other
boxes. The same thing happens when I run 'getent passwd' as root.
This is very strange in itself, since I have an ACL in OpenLDAP that
prevents reading the userPassword attribute by anyone, except when
binding to the server as the root user. I have /etc/ldap.conf
configured to bind to the server anonymously, so the password should
never be retrieved.
/etc/ldap.conf contains the following:
# Your LDAP server. Must be resolvable without using LDAP.
host 127.0.0.1
# The distinguished name of the search base.
base dc=linuxcare,dc=com
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
# Filter to AND with uid=%s
pam_filter objectclass=account
# No SSL
ssl no
I'm running Linux 2.2.18 with glibc 2.1.3 and nss_ldap 149 on all of
my boxes, and this is the only one that gives me this problem. I have
run md5sum on all the config files of both OpenLDAP and nss_ldap, plus
/etc/nsswitch.conf, and they are identical everywhere,
If anyone could shed some light on this very mysterious issue, I would
be very grateful.
Thanks,
Ian
--
Ian Macdonald | Hmmm ... A hash-singer and a cross-eyed guy
Senior System Administrator | were SLEEPING on a deserted island, when
Linuxcare, Inc. | ...
Support for the Revolution |
|