Bug 1136708

Hi,

I do not mind supporting one, both or any, I just need a reference.
So far I did not find one[1]...

In the new provider there is no problem to customize by:
---
redhat.properties
---
include = <rhds.properties>
sequence-init.init.999-redhat-init-vars = redhat-init-vars
sequence.redhat-init-vars.010.type = var-set
sequence.redhat-init-vars.010.var-set.variable = simple_filterGroupObject
sequence.redhat-init-vars.010.var-set.value = (objectClass=posixGroup)
---

So it is not that of a problem.

Not sure why this is z-stream as it is not a new issue.

Regards,
Alon

[1] http://onemoretech.wordpress.com/2011/11/23/389rhds-memberof-plugin/

posixGroup is defined in:
http://tools.ietf.org/html/rfc2307#section-4

... and widely used in existing deployments with unix machines.

AFAIK there is RFC 2307bis which contains alternative definition of member/memberUid attribute.

I'm sure that SSSD guys can add more details on this matter.

(In reply to Petr Spacek from comment #2)
> posixGroup is defined in:
> http://tools.ietf.org/html/rfc2307#section-4
> 
> ... and widely used in existing deployments with unix machines.
> 
> AFAIK there is RFC 2307bis which contains alternative definition of
> member/memberUid attribute.
> 
> I'm sure that SSSD guys can add more details on this matter.

RFC2307bis (and its derivatives like the schema Active Directory uses) use a full DN for a group member. Unlike plain RFC2307 which uses a username in the memberUid attribute. The net effect is that the bis schema also allows you to nest groups as the member can also be another group.

I hope this helps.

btw notably ActiveDirectory doesn't use the posixGroup OC by default at all, so I guess some schema configuration is the best approach..

(In reply to Jakub Hrozek from comment #4)
> btw notably ActiveDirectory doesn't use the posixGroup OC by default at all,
> so I guess some schema configuration is the best approach..

At version 3.4 we distinguish between different LDAP vendors using hard coded data structure, with version 3.5 , and the generic-ldap extension we are suppporting this by configuration files.

However, to support memberUid which contains user name instead of DN - it requires work - a new driver in the new provider.

Maybe easier to just activate the plugin/feature that provides memberOf.

another note: this model differ from standard ldap, the group refer to users instead of user refer to group.

(In reply to Alon Bar-Lev from comment #7)
> another note: this model differ from standard ldap, the group refer to users
> instead of user refer to group.

User referring to group is not really as standardized. MS AD does that with memberof attribute, which is non-transitive, so this setup:

user -- group1 -- group2
     -- group3

would only list group1 and group3 in the memberof attribute. On the other hand, IPA 'unrolls' the nested group membership, so the above setup would list all three groups in memberof. Traditional RFC2307bis setups often have no memberof attribute at all.

Bottom line, retrieving group memberships might sound easy at first but the devil is in the details :-) Might I suggest something like SSSD and the modules Jan Pazdziora is working on to solve the problem for you?

The posix extensions are later addition to the ldap scheme, all implementations do support the memberOf to be able to derive  user permissions (recursively) from user as root entity.

Otherwise the entire directory should be searched, especially in multi-domain setup.

Having directory that does not populate the information into memberOf was not considered, I will work something out that is specific to single namespace interaction.

(In reply to Alon Bar-Lev from comment #6)
> However, to support memberUid which contains user name instead of DN - it
> requires work - a new driver in the new provider.
> 
> Maybe easier to just activate the plugin/feature that provides memberOf.

The openLDAP "memberOf" overlay only works with groupOfNames group types. It is NOT compatible with PosixGroups group types. So enabling that overlay in OpenLDAP won't help.

Group search requires a second ldap query after user's memberUid was first retrieved.

As an example, this is how we retrieve groups on our openldap server :

ldapsearch -x  -b 'ou=Groups,dc=info-ufr,dc=univ-montp2,dc=fr' '(&(objectClass=posixGroup)(memberUid=tkauffmann))' cn

oVirt 3.5 has been released and should include the fix for this issue.