On 10/31/2014 05:31 PM, Petr Vobornik wrote:
On 31.10.2014 16:54, Martin Basti wrote:
Hello list,

I ran upgrade (related steps listed in order):

ipa-ldap-updater --upgrade
- applying update files (including 55-pbacmemberof.update)
- updating ACI (new permissions created, added to existing privilege)
- setting up new service (which uses privilege with new permission)

At the end I was expecting, the privilege will missing the new
permission (memberOf attribute), but I tested it in lab, and membership
was OK.

How the memberof plugin works?

I know of http://directory.fedoraproject.org/docs/389ds/design/memberof-plugin.html If there is other source, I would like to see it as well.
I don't know of another doc, but the mechanism of memberof is quit simple:

In the plugin config you define one or more groupattr and a memberofattr, eg

|memberofgroupattr: member
memberofgroupattr: uniqueMember
memberofattr: memberOf

then for any occurrence of the groupattr a value for the memberofattr in the 
referenced entry will be created, eg:

||dn: cn=group,dc=example
member: cn=user,dc=example

will trigger the addition of the memberofattr to the referenced entry cn=users

dn: cn=user,dc=example
objectclass: inetUser
memberOf: cn=group,dc=example|

This happens for any add/delete of a |memberofgroupattr or when the memberof fixup task is run.

You have to make sure that the entry which you expect the memberof has an objectclass allowing the memberof attribute,


We had similar issue with new DNS installation, where meberOf attributes
was missing, if DNS was installed later. But I cant reproduce this
behavior during upgrade. (Fix was use 55-pbacmemberof.update as last
step of bind service installation)

Was fixed by a fixup task call in:


PS: we had a case where user had broken DNS privileges and
55-pbacmemberof.update helps. But he had multiple errors and it could be
cascade effect.

Freeipa-devel mailing list

Reply via email to