Red Hat Bugzilla – Bug 798368
Automembership plugin fails to create member attributes, if groups are located other than the replication suffix
Last modified: 2012-05-14 16:29:28 EDT
Description of problem: Configuring automembership plugin in a replicated environment fails to create member attributes for the groups, if they are placed in other than the replication suffix. AutomemberScope: cn=Employees,dc=replAutoMembers,dc=com autoMemberDefaultGroup: cn=Defaultgrp,dc=noreplication,dc=com autoMemberTargetGroup: cn=Managers,dc=noreplication,dc=com Version-Release number of selected component (if applicable): 389-ds-base-1.2.10.2-1 How reproducible: Consistently. Steps to Reproduce: 1. Install latest 389-ds-base(1.2.10) bits and configure four way MMR. - Replicated Suffix - "dc=replAutoMembers,dc=com". 2. Configure Automembership plugin with "nsslapd-pluginConfigArea" on all the masters. nsslapd-pluginConfigArea: dc=autoMembersPlugin,dc=replAutomembers,dc=com 3. Add plugin configuration entries to "dc=autoMembersPlugin,dc=replAutoMembers,dc=com" with regex rules. Automembers plugin's regex rule: dn: cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com objectclass: autoMemberDefinition autoMemberScope: cn=Employees,dc=replAutoMembers,dc=com autoMemberFilter: objectclass=posixAccount autoMemberDefaultGroup: cn=SubDef1,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberDefaultGroup: cn=SubDef2,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberDefaultGroup: cn=SubDef3,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberDefaultGroup: cn=SubDef4,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberDefaultGroup: cn=SubDef5,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberGroupingAttr: member: dn dn: cn=Managers,cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com objectclass: autoMemberRegexRule description: Group placement for Managers cn: Managers autoMemberTargetGroup: cn=Managers,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberInclusiveRegex: uidNumber=^5..5$ autoMemberInclusiveRegex: gidNumber=^[1-4]..3$ autoMemberInclusiveRegex: nsAdminGroupName=^Manager$|^Supervisor$ autoMemberExclusiveRegex: uidNumber=^999$ autoMemberExclusiveRegex: gidNumber=^[6-8].0$ autoMemberExclusiveRegex: nsAdminGroupName=^Junior$ dn: cn=Contractors,cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com objectclass: autoMemberRegexRule description: Group placement for Contractors cn: Contractors autoMemberTargetGroup: cn=Contractors,dc=SubSuffix,dc=replAutoMembers,dc=com autoMemberInclusiveRegex: uidNumber=^8..5$ autoMemberInclusiveRegex: gidNumber=^[5-9]..3$ autoMemberInclusiveRegex: nsAdminGroupName=^Contract|^Temporary$ autoMemberExclusiveRegex: uidNumber=^[1,3,8]99$ autoMemberExclusiveRegex: gidNumber=^[2-4]00$ autoMemberExclusiveRegex: nsAdminGroupName=^Employee$ 4. Create all the associated groups and containers before creating user entries. For eg: Groups - Contractors, Managers, SubDef1, SubDef2, SubDef3, SubDef4 and SubDef5. Containers: cn=autoMembersPlugin and cn=Employees 5. Add few user entries(with posixAccount objectClass) to M1 and observe whether the entry is added as a member to the groups. Actual results: Users successfully added to all the masters, but the member attribute created only for the instance on which the user is created(in this case its M1). Expected results: Member attribute should be created on all the masters irrespective whether the groups are within the replication suffix or not. Additional info: Similar kind of setup works well on a stand alone instance. For eg: when you configure the standalone instance with the regex rules with the following attributes. AutomemberScope: cn=Employees,dc=AutoMembers,dc=com autoMemberDefaultGroup: cn=Defaultgrp,dc=newsuffix,dc=com autoMemberTargetGroup: cn=Managers,dc=newsuffix,dc=com
The Automembership plug-in ignores replicated operations. This means that the member attribute is simply replicated from the originating master to the replicas. The Automembership plug-in on the replica does not get triggered to create the member attribute for the replicated new user entry. With the scenario that you are testing, you are replicating the user portion of the tree (which is in one backend database), but the groups are in another non-replicated tree (another backend database). This means that the member attribute that is added to the group is outside of the scope of replication, hence it will never be replicated. As mentioned in the previous paragraph, the replicated user that is being added will not trigger the Automembership plug-in on the replicas by design. I would not consider this issue to be a bug. Having the groups in a non-replicated backend while the users are in a replicated backend is not a sensible use-case. If your groups and users are all within the replicated backend, things should work just fine since the member attributes in the group entries will be replicated. Have you tested this case?