Re: Issue with resolving groups with nss_ldap

I have been using that same method along with a few other lines that 
ensure local accounts are always available.  Along with the point made 
by an other individual though, if any listed users under the 
nss_initgroups_ignoreusers are part of an ldap group, this will prevent 
that membership from being known.  I find the trade-off for always 
available local access to be worth it.

# Search timelimit
timelimit 15
# Bind timelimit
bind_timelimit 15
# Return if initial bind attempt fails
bind_policy soft
# return NSS_STATUS_NOTFOUND if called with a listed
# user as an argument
nss_initgroups_ignoreusers root,ldap


- Josh, RHCE

Erik Logtenberg wrote:
> I may have found a solution to my problem. A friend of mine suggested I
> might want to use "bind_policy soft" in my /etc/ldap.conf file.
> When I tried, it indeed seems to solve the issue, so now when my LDAP
> server is down, just /etc/group is used. I'm able to start openldap as
> 'ldap' user now.
>
> I'm not sure if there could be any side-effects, but for now this will do.
> Thanks for your time and help.
>
> Kind regards,
>
> Erik Logtenberg.
>
>
> Craig Squires wrote:
> > 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