Re: Issue with resolving groups with nss_ldap

Hi Erik,

Your problem may be the following. The id command (and any command
that uses system calls like getgrent?) wants to find all groups, and
so will always look in all possible group info sources. Username, on
the other hand, is presumed to be unique, and so the first hit is enough.

I think the idea is that groups convey authorization info, and so
something like login or id needs to know all authorizations of a
user.

In order to avoid this problem we had to give up using LDAP for group
info altogether, and stick to /etc/groups.

Craig

.....................................................................
$Id: candcsysadmin,v 1.0 Fri Sep  1 08:30:59 2006 Craig Squires Exp $

On Fri, 1 Sep 2006, Erik Logtenberg wrote:

> Hi Tonni,
> 
> I don't understand your reply exactly. The problem doesn't seem to be
> with pam_ldap, since the issue isn't related to 'authentication' but to
> 'resolving'.
> In other words, simply asking nss_ldap "id <user>" will not even cause
> pam_ldap to do anything, right? So I don't see how my
> /etc/pam.d/system-auth file can have anything to do with it, or for that
> matter any pam-related configuration file.
> 
> For the record, my /etc/pam.d/system-auth is in fact configured in the
> way that you suggest:
> 
> auth            required        pam_env.so
> auth            sufficient      pam_unix.so likeauth nullok
> auth            sufficient      pam_ldap.so use_first_pass
> auth            required        pam_deny.so
> 
> account         required        pam_unix.so
> account         sufficient      pam_localuser.so
> account         required        pam_ldap.so
> 
> password        required        pam_cracklib.so difok=2 minlen=8
> dcredit=2 ocredit=2 retry=3
> password        sufficient      pam_unix.so nullok md5 shadow use_authtok
> password        sufficient      pam_ldap.so use_authtok use_first_pass
> password        required        pam_deny.so
> 
> session         required        pam_limits.so
> session         required        pam_unix.so
> session         optional        pam_ldap.so
> 
> However, as said: I don't think this is related.
> 
> The problem is that nss_ldap tries to contact ldap for group
> information, even though the correct group information is in fact
> available in /etc/group. This is no real problem as long as the OpenLDAP
> server is running, but I have /etc/passwd, /etc/group and /etc/shadow
> setup as fallback for when OpenLDAP is not running.
> So a special case of a user and group that are in /etc/passwd|group is
> ofcourse the user that OpenLDAP should run as, because it's obvious that
> you can't ask a daemon for information that is needed to start that
> daemon in the first place, right? :)
> 
> Now I thought that configuring nss_ldap using a setting like this in
> /etc/nsswitch.conf would cause nss to first read the local files and
> only try to contact ldap when the local files don't contain the required
> information:
> 
> passwd:         files ldap
> shadow:         files ldap
> group:          files ldap
> 
> For passwd and shadow this seems to work, but somehow for group it
> always contacts ldap, even if the asked group is available in /etc/group.
> 
> By the way, the OS is Gentoo Linux (Base System version: 1.12.4, Linux:
> 2.6.16.18). I use nss_ldap 249 and pam_ldap 180. My LDAP server is
> OpenLDAP 2.3.24.
> 
> Kind regards,
> 
> Erik Logtenberg.
> 
> 
> > 
> > This is a chestnut.
> > 
> > You don't say what OS, but on RHAS we add "account
> > sufficient    /lib/security/$ISA/pam_localuser.so" to /etc/pam.d/system-
> > auth (an across-the-board Red Hat pam configuration file), which tells
> > pam/nss that using /etc/passwd is ok. You might have to add it to your
> > own /etc/pam.conf or /etc/pam.d/{login,su,whatever} if you're not
> > running Red Hat/Fedora.
> > 
> > --Tonni
> > 
>