Summary of dynamic groups

2010-05-25 Thread Ian Collins

Hello again,

My earlier thread appears to have been hijacked, so I'm starting a new 
one for the summary of my investigations.


My current understanding is as follows:

There are three overlays that can use yes to manage groups dynamically: 
dynlist, autogroup and memberof.


 - dynlist works well for including members specified in a URL to the 
result of a search on a group.  The dynamic members can not be included 
in a search filter.


- autogroup works well for including members specified in a URL to the 
result of a search on a group. The dynamic members can be included in a 
search filter, but the only supported list attribute is 'member', which 
limits its use.


- memberof works well for reverse group management, including group dn 
in the entries for group members.  It only works with DN-values 
attributes, so it can't be used with clients that expect POSIX group 
members to be listed by 'memberUid' rather than 'member'.


From the above, I don't see a way to use OpenLDAP in an existing 
environment where dynamic groups are searched for by members and don't 
list their members with the 'member' attribute.


Please tell me I'm wrong (and how)!

Thanks,

--
Ian.



Re: Summary of dynamic groups

2010-05-25 Thread Howard Chu

Ian Collins wrote:

Hello again,

My earlier thread appears to have been hijacked, so I'm starting a new
one for the summary of my investigations.

My current understanding is as follows:

There are three overlays that can use yes to manage groups dynamically:
dynlist, autogroup and memberof.

   - dynlist works well for including members specified in a URL to the
result of a search on a group.  The dynamic members can not be included
in a search filter.

- autogroup works well for including members specified in a URL to the
result of a search on a group. The dynamic members can be included in a
search filter, but the only supported list attribute is 'member', which
limits its use.


That's false, you can configure it to use any attribute type.

However, uniqueMember is a broken attribute type and should not be used by any 
LDAP software.



- memberof works well for reverse group management, including group dn
in the entries for group members.  It only works with DN-values
attributes, so it can't be used with clients that expect POSIX group
members to be listed by 'memberUid' rather than 'member'.


POSIX group / memberUid is deprecated, no new LDAP clients should be using it 
anyway.


uniqueMember and memberUid have been discussed at length on these mailing 
lists before, so I won't elaborate again here. Search the archives for context.



  From the above, I don't see a way to use OpenLDAP in an existing
environment where dynamic groups are searched for by members and don't
list their members with the 'member' attribute.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


Re: Summary of dynamic groups

2010-05-25 Thread Ian Collins

On 05/26/10 02:40 PM, Howard Chu wrote:

Ian Collins wrote:

Hello again,

My earlier thread appears to have been hijacked, so I'm starting a new
one for the summary of my investigations.

My current understanding is as follows:

There are three overlays that can use yes to manage groups dynamically:
dynlist, autogroup and memberof.

   - dynlist works well for including members specified in a URL to the
result of a search on a group.  The dynamic members can not be included
in a search filter.

- autogroup works well for including members specified in a URL to the
result of a search on a group. The dynamic members can be included in a
search filter, but the only supported list attribute is 'member', which
limits its use.


That's false, you can configure it to use any attribute type.


No according to the read me:

  The value member-ad is the name of the attributeDescription that
specifies the member attribute. User modification of this 
attribute

is disabled for consistency.

I could only et it to work with 'member'.  Even if I specified 
'uniqueMember', 'member' was inserted.


However, uniqueMember is a broken attribute type and should not be 
used by any LDAP software.


But it is and I'm stuck with supporting third party applications that 
use it.



- memberof works well for reverse group management, including group dn
in the entries for group members.  It only works with DN-values
attributes, so it can't be used with clients that expect POSIX group
members to be listed by 'memberUid' rather than 'member'.


POSIX group / memberUid is deprecated, no new LDAP clients should be 
using it anyway.



But it is and I'm stuck with supporting old applications that use it.

uniqueMember and memberUid have been discussed at length on these 
mailing lists before, so I won't elaborate again here. Search the 
archives for context.




While I agree with the theory, it doesn't help when adding OpenLDAP into 
an existing network.


--

Ian.



Re: Summary of dynamic groups

2010-05-25 Thread Howard Chu

Ian Collins wrote:

On 05/26/10 02:40 PM, Howard Chu wrote:

Ian Collins wrote:

Hello again,

My earlier thread appears to have been hijacked, so I'm starting a new
one for the summary of my investigations.

My current understanding is as follows:

There are three overlays that can use yes to manage groups dynamically:
dynlist, autogroup and memberof.

- dynlist works well for including members specified in a URL to the
result of a search on a group.  The dynamic members can not be included
in a search filter.

- autogroup works well for including members specified in a URL to the
result of a search on a group. The dynamic members can be included in a
search filter, but the only supported list attribute is 'member', which
limits its use.


That's false, you can configure it to use any attribute type.


No according to the read me:

The valuemember-ad  is the name of the attributeDescription that
  specifies the member attribute. User modification of this
attribute
  is disabled for consistency.

I could only et it to work with 'member'.  Even if I specified
'uniqueMember', 'member' was inserted.


Then there's something else interfering in your config. There is nothing in 
the autogroup code that gives preference to the member attribute. It uses 
the attribute type you configure, and nothing else. Of course, the objectclass 
you use must also allow the attribute type you chose.


The text you quote above merely states that whatever attribute you choose will 
no longer be user-modifiable; the member list will always contain only the 
dynamically-generated values.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/