Re: Group lookups (groupOfNames)

[Tim <weirdit [at] gmail.com>]

It appears that my groups have started working.
A quick test confirms that using the package from ubuntu it fails.
Using the package I built myself with the bugfix I submitted to the
list earlier today, groups work!
So it came down to the fact that we are using uidNumber=111 format in
the dn's instead of uid=username format.

I will have to think about our database layout a bit more now, as it
appears that a lookup using out format will probably do more LDAP
queries than the uid=username format.
1 for the group, then 1 for each dn in the group to get the uid attr.
Not sure if currently nslcd will be able to skip that 2nd lookup using
the uid=username format given that it has the dn and can just read the
uid from the dn?

I guess when it's all running well, nscd will cache so should I worry
about the extra lookup?

Tim

On 19 May 2011 21:38, Tim <weirdit@gmail.com> wrote:
> I'm not sure the best way to "present" the current schema, as it
> appears ldif gets formatted horribly for long lines.
> Here are the files as they come out of the
> /etc/ldap/slapd.d/cn=config/cn=schema/ directory.
> http://dl.dropbox.com/u/1496809/cn%3D%7B0%7Dcore.ldif
> http://dl.dropbox.com/u/1496809/cn%3D%7B1%7Dcosine.ldif
> http://dl.dropbox.com/u/1496809/cn%3D%7B2%7Drfc2307bis.ldif
> http://dl.dropbox.com/u/1496809/cn%3D%7B3%7Dinetorgperson.ldif
> http://dl.dropbox.com/u/1496809/cn%3D%7B4%7Dopenldap.ldif
>
> The rfc2307bis.schema file that I am using came from the gosa package.
> (Had forgotten that earlier, so hope that's not the cause of my
> problems!) I've uploaded it to
> http://dl.dropbox.com/u/1496809/rfc2307bis.schema so it's probably
> easier that going through the ldif file.
>
> I believe the relevant sections are.
>
> objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY
>  DESC 'Abstraction of a group of accounts'
>  MUST gidNumber
>  MAY ( userPassword $ memberUid $
>        description ) )
>
> I've just noticed the following section.
> ## namedObject is needed for groups without members
> objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top
>       STRUCTURAL MAY cn )
>
> Which makes me wonder if I'm constructing my groups wrongly.
>
> My groupOfNames comes from the core.schema that is shipped with the
> openldap package.
>
> objectclass ( 2.5.6.9 NAME 'groupOfNames'
>        DESC 'RFC2256: a group of names (DNs)'
>        SUP top STRUCTURAL
>        MUST ( member $ cn )
>        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
>
>
> Does that help anyone to see what I need to change?
>
> Thanks
>
> Tim
>
> On 18 May 2011 23:21, Ryan Steele <ryans@aweber.com> wrote:
>> Tim wrote:
>>> Hi All, I've been trying for a few days to get this working without luck.
>>>
>>> Running Ubuntu Natty as a test server with openldap 2.4.23, and
>>> libnss-ldapd/nslcd/libpam-ldapd 0.7.13
>>>
>>> I'm using rfc2307bis.ldif to attempt to have groups as "groupOfNames"
>>> with posixGroup as an Ancillary object class.
>>> So far, it appears to work partially. It retrieves the groups, just
>>> not the members. I was originally trying libnss-ldap but not having
>>> any luck with groups (even though there is a switch for rfc2307bis),
>>> not even able to get the groups to show.
>>
>>
>> There are a few things that I have observed to cause this.  The first is 
>> forgetting uniqueMember -> member mapping,
>> which you appear to have taken care of.  The second is mismatched schema on 
>> the LDAP server and the client systems.  The
>> other is also schema related, and revolves around extending rfc2307bis such 
>> that 'member' is in the MAY clause of the
>> groupOfMembers objectclass.  Assuming the schema on the LDAP server and the 
>> clients match, and given what you've
>> mentioned, I would expect it is the latter.
>>
>> I think you may have a more recent version of rfc2307bis than I do, however, 
>> so you may or may not be able to use my
>> suggestion.  The one I've got doesn't have groupOfNames, but instead has an 
>> extended groupOfMembers objectclass, as
>> described above.  I guess we'd have to see the relevant objectclass from 
>> your schema to be able to answer more concretely.
>>
>>
>>>
>>> The contents of /etc/nslcd.conf are (with comments removed)
>>>
>>> uid nslcd
>>> gid nslcd
>>> uri ldap://127.0.0.1/
>>> base dc=plug,dc=org,dc=au
>>> filter group (objectClass=posixGroup)
>>> map group uniqueMember member
>>>
>>> $ getent group|grep committee
>>> committee:*:1006:
>>>
>>>
>>> The relevant ldif for committee group
>>> # committee, Groups, plug.org.au
>>> objectClass: groupOfNames
>>> objectClass: posixGroup
>>> dn: cn=committee,ou=Groups,dc=plug,dc=org,dc=au
>>> cn: committee
>>> member: uidNumber=10030,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10163,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10048,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10246,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10062,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10318,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10189,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10252,ou=Users,dc=plug,dc=org,dc=au
>>> member: uidNumber=10254,ou=Users,dc=plug,dc=org,dc=au
>>> gidNumber: 1006
>>>
>>> I've not setup anything on the pam side yet, as I'm trying to just get
>>> NSS working first. (So attempting to login as a LDAP user will
>>> currently fail).
>>>
>>> Any ideas what I'm missing? I watched the slapd debug logs and
>>> realised it wasn't returning the member attr, which is how I
>>> eventually worked out "map group uniqueMember member" should be
>>> correct as it now returns the member attr. I'm guessing the problem is
>>> now ether what I'm mapping it to, or the resolution of the dn to a
>>> user (although in the logs I see no more ldap queries after it gets
>>> the groups, so I'm assuming it's the mapping that's the problem).
>>>
>>> If I'm using the wrong package (i.e. ldapd version doesn't support
>>> this), I apologise in advance as I've found very little documentation
>>> regarding this.
>>>
>>> Tim
>>>
>>
>
>
>
> --
> Timothy White - Somewhere in Australia
>



-- 
Timothy White - Somewhere in Australia
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users