[Kolab-devel] Kolab-Webadmin group memberships

[Daniel Hoffend]

The problem with group membership is that LDAP knows 2 different sorts 
of group memberships that are handled differently.

1) groupOfNames or groupOfUniqueNames

The group contains the dn of each group member. Afaik this group 
supports nested group memberships aswell.

2) posixGroup

This type of group is mostly used for unix or windows/samba/ad group 
memberships. It only contains the uid of the user, not the DN of the 
user.

The method "find_user_groups" only returns groupOf membership and 
doesn't support posixGroups.

>From my openldap experience I can say that the overlay "memberOf" 
populates a user object with memberOf attributes as soon as the group 
entry gets modified. But this only applies to groupOfNames, etc and not 
to posix groups afaik. Not sure how 389 handles it tbh.

When somebody plans to enhance the webadmin with a list of group 
memberships maybe take this into account that ldap has 2 differnt types 
of groups (3 of you count this roles thing into it aswell).


--
Regards
Daniel Hoffend



------ Originalnachricht ------
Von: "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>
An: "Kolab development coordination" <devel at lists.kolab.org>
Cc: "Henning" <henne.gwath at gmx.de>
Gesendet: 11.02.2014 15:45:54
Betreff: Re: [Kolab-devel] Kolab-Webadmin group memberships

>On 2014-02-11 14:20, Henning wrote:
>>Hi,
>>
>>kolab-webadmin is quite flexible concerning the design of your special
>>environment. However for users I'm missing a "user.groups" section to
>>easily identify the groups a user is member of. The section could be
>>read-only, but it would make things easier to handle.
>>For this I think one could have a look at the code somewhere in the
>>roundcubemail addressbook.
>>
>>I tried to figure out what to do, but I'm bad at php, so maybe one of
>>you could spend some time on this.
>>
>
>You're right, this would be a nice enhancement.
>
>Just like we have "Role(s)" already there, we should also have 
>"Group(s)".
>
>It's a little tricky for roles are actually attached to the user object 
>entry itself, and therefore almost "free" to pull in performance-wise.
>
>Groups however work the other way around, and what is even worse is 
>that dynamic groups would be omitted unless each of its searches is 
>executed in an attempt to find whether or not the user is a member of 
>such dynamic group (see groupofurls).
>
>That said, this could be amended by enabling the memberOf plugin, 
>though I'm not sure that would work for dynamic groups equally well as 
>it does for static groups.
>
>We expose an API call to find groups a certain user is a member of 
>here:
>
>   http://git.kolab.org/pear/Net_LDAP3/tree/lib/Net/LDAP3.php#n906
>
>but note it does only direct membership of static groups, and not a 
>scenario like the following (for a user uid=doe):
>
>   dn: cn=mail-users,ou=Groups,dc=example,dc=org
>   objectclass: groupofuniquenames
>   uniquemember: cn=kolab-users,ou=Groups,dc=example,dc=org
>
>   dn: cn=kolab-users,ou=Groups,dc=example,dc=org
>   objectclass: groupofuniquenames
>   uniquemember: uid=doe,ou=People,dc=example,dc=org
>
>only the kolab-users group would be returned. One could probably loop, 
>but watch out for infinite nesting.
>
>Kind regards,
>
>Jeroen van Meeuwen
>
>-- Systems Architect, Kolab Systems AG
>
>e: vanmeeuwen at kolabsys.com
>m: +44 74 2516 3817
>w: http://www.kolabsys.com
>
>pgp: 9342 BF08
>_______________________________________________
>devel mailing list
>devel at lists.kolab.org
>https://lists.kolab.org/mailman/listinfo/devel