Bug 1052754 - [RFE] Allow nsDS5ReplicaBindDN to be a group DN
Summary: [RFE] Allow nsDS5ReplicaBindDN to be a group DN
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Ludwig
QA Contact: Viktor Ashirov
Depends On:
Blocks: 1029640 1185066
TreeView+ depends on / blocked
Reported: 2014-01-14 01:18 UTC by Noriko Hosoi
Modified: 2020-09-13 20:54 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Enhancement
Doc Text:
Using a group DN in binding to replicas is now possible This update adds the nsDS5ReplicaBindDNGroup and nsDS5ReplicaBindDNGroupCheckInterval attributes to the ndsdReplica object. The nsDS5ReplicaBindDNGroup attribute specifies a group DN; this group is then expanded and its members, including the members of its subgroups, are added to the replicaBindDNs attribute at startup or when the replica object is modified. This enhancement extends the current functionality provided by the existing nsDS5ReplicaBindDN attribute, as it allows nsDS5ReplicaBindDN to be a group DN. To set the attribute, use the following syntax: nsDS5ReplicaBindDNGroup: <dn> Directory Server (DS) checks for any changes in the specified groups and automatically rebuilds the list for replicaBindDNs accordingly. These operations have a negative effect on performance and are therefore performed only at a specified interval. You can configure this interval using the nsDS5ReplicaBindDNGroupCheckInterval attribute. This attribute accepts the following values: "n" where "n" is the minimum number of seconds that are required to pass since the last rebuild before DS rebuilds the list again "-1" specifies that no dynamic verification at runtime is performed, and the administrator is required to manage the groups manually "0" specifies that DS rebuilds the list immediately after the groups are changed
Clone Of:
Last Closed: 2015-03-05 09:33:26 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1004 0 None closed Allow nsDS5ReplicaBindDN to be a group DN 2020-12-23 19:17:40 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Noriko Hosoi 2014-01-14 01:18:40 UTC
This bug is created as a clone of upstream ticket:

We should allow nsDS5ReplicaBindDN to handle group DNs.  This would allow one to have a group of replication users in the replicated tree, which simplifies certain use-cases.

FreeIPA uses GSSAPI for replication, so the replication users exist in the replicated tree.  Each replica uses a separate replication user. The DNA plug-in is also used by IPA, which utilizes the replication bind DNs for authorization when receiving a range transfer request extended operation.  Being able to use a group DN simplifies the configuration changes that need to be made when a new replica is added.  Consider the following 3 master replication topology:

   A <-> B <-> C

If a new master D is added that is only connected to master C, we would need to update nsDS5ReplicaBindDN on A, B, and C to allow DNA range transfers between D and all other masters with the current behavior.  If a group of replication users from the replicated tree is used instead, we could simply add the new replication bind DN to the group and it would be replicated out to the rest of the topology.

Comment 2 Sankar Ramalingam 2014-10-16 12:16:15 UTC
This looks like an RFE to me. I hope we need to have good test coverage for this. Please correct me if I am wrong.

Comment 4 Amita Sharma 2014-10-28 09:24:07 UTC

May I have a design doc link for this RFE please.


Comment 5 Noriko Hosoi 2014-11-06 02:13:24 UTC
(In reply to Amita Sharma from comment #4)
> Hi,
> May I have a design doc link for this RFE please.
> Thanks,
> Ami

[Design memo by Ludwig]
The fix adds a new attribute to the ndsdReplica object:
    nsDS5ReplicaBindDNGroup: <dn>
When this attr is set at startup or when the replica object is modified
the group is expanded and its members and all mambers of its
subgroups are added to a hash of replcabinddns. this is in
parallel to the normal hash od replicabind dn specified using
the existing attr nsDS5ReplicaBindDN.

Since groups can change, the list of bingdns based on groups has to be
rebuilt when the spcified groups change. This check and the
rebuilding of the group has a performance cost and will be done only
in a specified interval, the interval can be configured by
This attr takes the following values:
  -1 no dynamic check at runtime, admin must take care that groups 
     are stable or restart to get changes accounted for
   0 everytime a binddn is verified the groupdns are rebuilt
   n only if n seconds have passed since last rebuild it is done again

Comment 6 Milan Kubík 2014-11-10 17:00:55 UTC

could you provide me with more information as to how this works internally (does it try to bind with every member of the group) and probably another use case? I'm not sure I understand the feature enough.

Proper design document would help too.


Comment 7 Ludwig 2014-11-10 17:09:36 UTC
The server binding does not know or does not need to know about the group feature, it is only on the receiving side.

Before this feature was implemented, in a replication agreement a dn to bind was defined and in a replica allowed dns to bind were defined, there could have been more than one.
So a server maintained a list of binddns for a replica allowed to bind. What is new now is that not only single dns can be specified, but also groups. Internally all the individual bind dns are collected into a list of allowed binddns and thios list is extended with all the members of the allowed binddngroups - then processing is as before.

Comment 10 Amita Sharma 2015-01-29 13:25:06 UTC
Thanks for reply Ludwig, you are correct, case 4 is working fine ::
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
cn: replica
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsds5replicabinddngroup: cn=QA Managers,ou=Groups,dc=example,dc=com
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20150129114708Z
modifyTimestamp: 20150129132259Z
nsDS5ReplicaName: 870dcf04-a7ac11e4-bb039697-342b433a
nsds5replicabinddngroupcheckinterval: 0
numSubordinates: 2

[root@dhcp201-126 export]# ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=ami1,dc=example,dc=com
> cn: ams1
> sn: ams1
> givenname: ams1
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: ami1
> mail: ams1@example.com
> userpassword: Secret123
adding new entry "uid=ami1,dc=example,dc=com"

[root@dhcp201-126 export]# ldapsearch -x -h localhost -p 30102 -D "cn=Directory Manager" -w Secret123 -b "uid=ami1,dc=example,dc=com"
# extended LDIF
# LDAPv3
# base <uid=ami1,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL

# ami1, example.com
dn: uid=ami1,dc=example,dc=com
cn: ams1
sn: ams1
givenName: ams1
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: ami1
mail: ams1@example.com
userPassword:: e1NTSEF9SXcwakk2SWYxNC9sdDBIbkJkc0RYem81TE9SbmI2RzhzREJRanc9PQ=

No error message. So basic functionality is tested and VERIFIED.
I will log bug for other Issues. Thanks, Ami

Comment 12 errata-xmlrpc 2015-03-05 09:33:26 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.