On Sun, 2010-02-14 at 16:31 +0100, Andrey Ivanov wrote: > Hi, > > > At long last I think I see it. FDS has create groups with object class > > groupofuniquenames to which we have added an objectclass of posixgroup > > but it is only populated with uniquemember and not memberuid. It looks > > like I have two options: > > > > 1) Define nss_map_objectclass posixgroup groupofuniquenames: > > This works for getent group but seems to make id hang. I think this > > also creates a problem in that the user groups, i.e., the posixgroup > > created for each uid, will not be mapped. > > > > 2) Define all the memberuids in each group: > > This means an extra administrative step (is there anyway to automate > > this from the uniquemembers attribute?) and exposure to human error. > > > > My guess is that option 2 is the correct way to go. Is that true? > > Thanks - John > > It depends on how you proceed. There is a parameter nss_schema > <rfc2307bis|rfc2307> (man nss_ldap) that lets you to chose whether you > prefer memberuid or member dn in the groups. > Another important point is that the user used by nss_ldap to bind to > your ldap server should have the right to read memberUid & > uniqueMember attributes on group entries... I could certainly use some enlightenment on those parameters. Not coming from an NIS world, I'm not that familiar with RFC2307. I gather RFC2308 is expired and 2307bis was never adopted but both are still used in practice. I did try setting nss_schema to rfc2307bis but it did not help. I assumed that meant it would use DNs for the group membership but it did not return them. If it did, would that still work with determining posixgroup membership, e.g., CUPS authentication which is where this all started? Thanks - John
