nss_ldap and openldap on the same server.

[Jonathan McKeown]

On Tuesday 13 March 2007 10:26, Gerhard Schmidt wrote:

> > It's a well-known problem rather than a bug, and it arises when looking
> > up group information for a user. The system needs a list of all the
> > groups the user is a member of. Since it's a list, not a single answer,
> > you can't short-circuit the process with ``success'' after finding a
> > single result: initgroups(3) must work through all possible sources of
> > group information to build the list.
>
> I think its still a bug. You are right that all groups should be found so
> the default for groups should be success=continue to have this done. But
> when I explicily specify that on success the process should abort, it
> should be done exacly this way.

You've now had responses from me and Joerg Pulz, and given us essentially the 
same reply. I'm not sure success means what you think it means: group 
information is a complete list, not ``first item found'' like a user account.

You have told the system to check for group information in files and ldap. You 
have, therefore, not succeeded in listing all groups until you have both 
searched the files *and* received a response from nss_ldap, either group 
information or NSS_STATUS_NOTFOUND.

It looks as though you can instruct nss_ldap to unconditionally return 
NSS_STATUS_NOTFOUND for a user, by adding

nss_initgroups_ignoreusers user

in nss_ldap.conf. I'd be interested to hear whether it works, having not 
tested it myself, but at the moment you're banging your head against the wall 
and shouting about how much it hurts. It will hurt less if you stop.

Jonathan