Re: Issue with resolving groups with nss_ldap

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
>>>