9:47 a.m.
Hi,
I'm playing with memberof overlay. For my tests, I use the default
database (numbered 1) from slapd installation with suffix dc=nodomain.
The tests are running on debian jessie 8.2 and slapd version
2.4.40+dfsg-1
Activating the module in cn=module entry and activating the overlay for
the database, I have something that works like (I think) it should. I
mean adding a user (attribute member) in a group creates an attribute
memberOf for the user and deleting a user from the group deletes the
user's memberOf attribute. That's great.
There is nothing special configured.
# Entrée 1: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectclass: olcConfig
objectclass: olcOverlayConfig
objectclass: olcMemberOf
objectclass: top
olcoverlay: {0}memberof
Reading the man page, I saw memberof-refint option. From what I
understand, when set to true, you can alter the user's "is member of"
attribute and that would be reflected in the group's "member" attribute.
Right ?
But, the member attribute is an operational attribute and can't be
modified. So I started to search for an alternative and found the
eduMember schema from here
https://spaces.internet2.edu/display/macedir/OpenLDAP+eduMember. Once
added to the installation I could use it for objects. It adds isMemberOf
and hasMember attributes that can be setable for users and groups. But
can't make it work with memberof overlay. When trying to add isMemberOf
as memberof-memberof-ad it was rejected with
member attribute=”isMemberOf” must either have DN
(1.3.6.1.4.1.1466.115.121.1.12) or nameUID
(1.3.6.1.4.1.1466.115.121.1.34) syntax
And the same error was reported with hasMember as memberof-member-ad.
To make it work together I modified the attribute's definitions and
reimported them to openldap. So I can now set isMemberOf as
memberof-memberof-ad and the same for hasMember as memberof-member-ad.
The configuration then was like this
# Entrée 1: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectclass: olcConfig
objectclass: olcOverlayConfig
objectclass: olcMemberOf
objectclass: top
olcmemberofmemberofad: isMemberOf
olcoverlay: {0}memberof
Now that works like (I think) it should. I mean adding a user (attribute
member) in a group creates an attribute isMemberOf for the user and
deleting a user from the group deletes the user's isMemberOf attribute.
That's great.
isMemberOf is a modifiable attribute so it's time to test the
memberof-refint and set it to TRUE
# Entrée 1: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectclass: olcConfig
objectclass: olcOverlayConfig
objectclass: olcMemberOf
objectclass: top
olcmemberofmemberofad: isMemberOf
olcmemberofrefint: TRUE
olcoverlay: {0}memberof
And this is where things do not work. I mean what was working before is
still working. If I add a member in a group an atttribute isMemberOf is
created for the user. But if I add a second attribute isMemberOf with a
second group, no new member is created on the second group. And if I
delete the attribute isMemberOf from the user's entry, it is still
visible on the group.
Does anybody have any idea why the modifications made on the user (with
the deletion of isMemberOf) are not applied to the group ? Is there
something I'm doing wrong ?
Thanks.
--
------------
M. P.
11:19 p.m.
M. P. wrote:
Reading the man page, I saw memberof-refint option. From what I
understand,
when set to true, you can alter the user's "is member of" attribute and
that
would be reflected in the group's "member" attribute. Right ?
I read the man page differently: "memberof-refint true" preserves referential
integrity for the 'member' attribute if the member entry is renamed. Normally
one would use slapo-refint for that.
=> IMO the text seems a bit ambigous.
But, the member attribute is an operational attribute and can't
be modified.
So I started to search for an alternative and found the eduMember schema from
here https://spaces.internet2.edu/display/macedir/OpenLDAP+eduMember. Once
added to the installation I could use it for objects. It adds isMemberOf and
hasMember attributes that can be setable for users and groups. But can't make
it work with memberof overlay. When trying to add isMemberOf as
memberof-memberof-ad it was rejected with
Wrong route...
Why do you want to change group membership by tweaking 'memberOf' anyway? Note
that this would somewhat circumvent access control delegation on group
entries. Hence you should always modify the group entries directly.
Ciao, Michael.
5:59 a.m.
Le 2015-11-20 08:19, Michael Ströder a écrit :
M. P. wrote:
> Reading the man page, I saw memberof-refint option. From what I
> understand,
> when set to true, you can alter the user's "is member of" attribute
> and that
> would be reflected in the group's "member" attribute. Right ?
I read the man page differently: "memberof-refint true" preserves
referential
integrity for the 'member' attribute if the member entry is renamed.
Normally
one would use slapo-refint for that.
=> IMO the text seems a bit ambigous.
Maybe it is because english is not my native language, but reading again
the man page, it was(is still ?) a little bit confusing for me.
But, based on your point of view, I changed my test actions and I have
to admit that it tends to your direction. Yes when I rename the user,
the dn of the user is changed in the group and when the user is deleted,
it is removed from the group. I agree with you, it seems very similar to
slapo-refint which I tested too.
I wonder now, if we have the choice between both of these overlays to do
the same think, is there one that should be prefered to the other ?
> But, the member attribute is an operational attribute and can't be
> modified.
For correctness, I was talking about the memberOf atribute and not the
member attribute.
> So I started to search for an alternative and found the eduMember
> schema from
> here https://spaces.internet2.edu/display/macedir/OpenLDAP+eduMember.
> Once
> added to the installation I could use it for objects. It adds
> isMemberOf and
> hasMember attributes that can be setable for users and groups. But
> can't make
> it work with memberof overlay. When trying to add isMemberOf as
> memberof-memberof-ad it was rejected with
Wrong route...
Why do you want to change group membership by tweaking 'memberOf'
anyway?
I want to permit a "two way" group membership management, something more
flexible. First by adding members to groups objects and the other way by
adding groups to users objects. I dont know if it is clear enough and if
it is doable like this. But I try.
Note
that this would somewhat circumvent access control delegation on group
entries.
Sorry, I don't understand this part.
Hence you should always modify the group entries directly.
Yes I can do this, but for flexibility I'm looking for a way to alter
user entries and that would be reflected on group entries. For sure it
is scriptable, I know, but maybe there is a solution more integrated and
modifications written instantaneously.
Ciao, Michael.
--
------------
M. P.
8:32 a.m.
M. P. wrote:
> Why do you want to change group membership by tweaking
'memberOf' anyway?
I want to permit a "two way" group membership management, something more
flexible. First by adding members to groups objects and the other way by
adding groups to users objects. I dont know if it is clear enough and if it is
doable like this. But I try.
Yes, but why do you really need that?
> Note that this would somewhat circumvent access control
delegation on
> group entries.
Sorry, I don't understand this part.
Your user and group entries could be subject to different access control.
> Hence you should always modify the group entries directly.
Yes I can do this, but for flexibility I'm looking for a way to alter user
entries and that would be reflected on group entries. For sure it is
scriptable, I know, but maybe there is a solution more integrated and
modifications written instantaneously.
Just mentioning flexibility is not a valid requirement and more flexibility
always leads to additional complexity.
Ciao, Michael.
3:42 p.m.
Le 2015-11-21 17:32, Michael Ströder a écrit :
M. P. wrote:
>> Why do you want to change group membership by tweaking 'memberOf'
>> anyway?
>
> I want to permit a "two way" group membership management, something
> more
> flexible. First by adding members to groups objects and the other way
> by
> adding groups to users objects. I dont know if it is clear enough and
> if it is
> doable like this. But I try.
Yes, but why do you really need that?
I'm trying but I don't know how to explain you that differently :/
It's just for the support guys. If they alter group entries that should
be reflected on the user (that is the case with slapo-memberof). If they
alter user entries that should be reflected on the group (the opposite
of slapo-memberof).
>> Note that this would somewhat circumvent access control delegation on
>> group entries.
>
> Sorry, I don't understand this part.
Your user and group entries could be subject to different access
control.
Ok. I'm aware of this point but thanks for the reminder. ;)
>> Hence you should always modify the group entries directly.
>
> Yes I can do this, but for flexibility I'm looking for a way to alter
> user
> entries and that would be reflected on group entries. For sure it is
> scriptable, I know, but maybe there is a solution more integrated and
> modifications written instantaneously.
Just mentioning flexibility is not a valid requirement and more
flexibility
always leads to additional complexity.
Ciao, Michael.
--
------------
M. P.
10:59 a.m.
--On Friday, November 20, 2015 2:59 PM +0100 "M. P."
<kisscoolandthegangbang(a)hotmail.fr> wrote:
I want to permit a "two way" group membership management,
something more
flexible. First by adding members to groups objects and the other way by
adding groups to users objects. I dont know if it is clear enough and if
it is doable like this. But I try.
Why not use dynamic groups?
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
3:20 p.m.
Le 2015-11-21 19:59, Quanah Gibson-Mount a écrit :
--On Friday, November 20, 2015 2:59 PM +0100 "M. P."
<kisscoolandthegangbang(a)hotmail.fr> wrote:
> I want to permit a "two way" group membership management, something
> more
> flexible. First by adding members to groups objects and the other way
> by
> adding groups to users objects. I dont know if it is clear enough and
> if
> it is doable like this. But I try.
Why not use dynamic groups?
I'm not sure how dynamic groups could help me here.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
------------
M. P.
8:51 p.m.
--On Sunday, November 22, 2015 12:20 AM +0100 "M. P."
<kisscoolandthegangbang(a)hotmail.fr> wrote:
Le 2015-11-21 19:59, Quanah Gibson-Mount a écrit :
> --On Friday, November 20, 2015 2:59 PM +0100 "M. P."
> <kisscoolandthegangbang(a)hotmail.fr> wrote:
>
>> I want to permit a "two way" group membership management, something
>> more
>> flexible. First by adding members to groups objects and the other way
>> by
>> adding groups to users objects. I dont know if it is clear enough and
>> if
>> it is doable like this. But I try.
>
> Why not use dynamic groups?
I'm not sure how dynamic groups could help me here.
You just define groups based off an attribute in the user entry. Thus it
is a single write op to update the membership for a given user, and the
change in user membership is instant. If you do it sanely, you can
trivially determine what groups a user belongs to by looking at the entry,
and as long as the ldap client is using ldapcompare etc properly for group
membership checks, it appears just like any "static" ldap group to the
client.
You can even use the memberOf attribute for creating the dynamic groups.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
2:29 p.m.
Le Sun, 22 Nov 2015 14:29:00 +0100,
Michael Ströder <michael(a)stroeder.com> a écrit :
Quanah Gibson-Mount wrote:
> You can even use the memberOf attribute for creating the dynamic groups.
Because 'memberOf' has "USAGE dSAOperation" you would have to switch
of
slapo-memberof and re-declare the attribute type description without it.
What are the implications/consequences of that modification ?
Ciao, Michael.
2:24 p.m.
Le Sat, 21 Nov 2015 20:51:30 -0800,
Quanah Gibson-Mount <quanah(a)zimbra.com> a écrit :
--On Sunday, November 22, 2015 12:20 AM +0100 "M. P."
<kisscoolandthegangbang(a)hotmail.fr> wrote:
> Le 2015-11-21 19:59, Quanah Gibson-Mount a écrit :
>> --On Friday, November 20, 2015 2:59 PM +0100 "M. P."
>> <kisscoolandthegangbang(a)hotmail.fr> wrote:
>>
>>> I want to permit a "two way" group membership management,
something
>>> more
>>> flexible. First by adding members to groups objects and the other way
>>> by
>>> adding groups to users objects. I dont know if it is clear enough and
>>> if
>>> it is doable like this. But I try.
>>
>> Why not use dynamic groups?
>
> I'm not sure how dynamic groups could help me here.
You just define groups based off an attribute in the user entry. Thus it
is a single write op to update the membership for a given user, and the
change in user membership is instant. If you do it sanely, you can
trivially determine what groups a user belongs to by looking at the entry,
and as long as the ldap client is using ldapcompare etc properly for group
membership checks, it appears just like any "static" ldap group to the
client.
It is not exactly what I'm looking for but I'll certainly use dynamic groups
later for something else.
To make it clearer, I have 2 users, userA and userB, and a group, groupA. If I
add a user by his dn uid=userA,ou... to cn=groupA, slapo-memberof will add to
userA an attribute isMemberOf=cn=groupA,ou... (isMemberOf is a modifiable
replacement for memberOf in my case).
What I want to make work is when I add an attribute isMemberOf=cn=groupA to
userB, then in cn=groupA I want to see an attibute member=uid=userB,ou... . Then
if for any reason I want to delete the group membership by removing
member=uid=userB,ou... from cn=groupA, it should remove the attribute
isMemberOf=cn=GroupA,ou... from uid=userB,ou...
You can even use the memberOf attribute for creating the dynamic groups.
The memberof attribute is a readonly attribute. How could it be modified ?
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
3:48 p.m.
--On Sunday, November 22, 2015 11:24 PM +0100 k c
<kisscoolandthegangbang(a)hotmail.fr> wrote:
>
> You can even use the memberOf attribute for creating the dynamic groups.
The memberof attribute is a readonly attribute. How could it be modified
Yeah, I was wrong, you can't use that one specifically. ;)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
2749
days inactive
2752
days old
openldap-technical@openldap.org
11 comments
4 participants
participants (4)
-
k c -
M. P.
-
Michael Ströder -
Quanah Gibson-Mount