Bug 1598478 - If a replica is created with a bindDNGroup, this group is taken into account only after bindDNGroupCheckInterval seconds
Summary: If a replica is created with a bindDNGroup, this group is taken into account ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: thierry bordaz
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
: 1598159 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-05 15:25 UTC by mreynolds
Modified: 2018-10-30 10:15 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.3.8.4-4.el7
Doc Type: Bug Fix
Doc Text:
Directory Server now retrieves members of the replica bind DN group when the first session is started Directory Server replicas define entries that are authorized to replicate updates to the replica itself. If the entries are members of the group set in the "nsds5replicabinddngroup" attribute, the group is retrieved periodically based on the interval set in the "nsDS5ReplicaBindDnGroupCheckInterval" attribute. If the entry is not a member at the time the server retrieves the group, any session that is authenticated using this entry is not authorized to replicate updates. This behavior remains until the entry becomes a member of the group and the server retrieves the group again. As a consequence, replication fails for the first interval set in "nsDS5ReplicaBindDnGroupCheckInterval". With this update, the server retrieves the group when the first session is started rather than when the replica is created. As a result, the group is taken into account at the first attempt it is checked.
Clone Of:
Environment:
Last Closed: 2018-10-30 10:14:34 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3127 None None None 2018-10-30 10:15:20 UTC

Description mreynolds 2018-07-05 15:25:03 UTC
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/49818

#### Issue Description
When a replica is created, the time of the last_group_check is set at the current time.
So if the a replica contains a nsds5replicabinddngroup, this group will only be uploaded after a delay of nsDS5ReplicaBindDnGroupCheckInterval.

So in the period [replica_creation, replica_creation+nsDS5ReplicaBindDnGroupCheckInterval] any incoming replication connections, within will fail with NSDS50_REPL_PERMISSION_DENIED , even if the group actually contains the bound DN.

On the supplier side we can see message like 

    [29/Jun/2018:17:21:58.943439172 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meTo<server_fqdn>" (<server>:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.



#### Package Version and Platform
Any version


#### Steps to reproduce

1. IPA server-replica install
2. or create a replica with a group/check interval and verify that for the first check_interval period all replication session fail
3.

#### Actual results
It fails


#### Expected results
should not

Comment 2 Viktor Ashirov 2018-07-09 09:37:33 UTC
*** Bug 1598159 has been marked as a duplicate of this bug. ***

Comment 4 Simon Pichugin 2018-07-30 09:54:01 UTC
The test case was automated in 
dirsrvtests/tests/suites/replication/regression_test.py::test_fetch_bindDnGroup

================== test session starts ==================
platform linux -- Python 3.6.3, pytest-3.6.4, py-1.5.4, pluggy-0.7.1 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-924.el7.x86_64-x86_64-with-redhat-7.6-Maipo', 'Packages': {'pytest': '3.6.4', 'py': '1.5.4', 'pluggy': '0.7.1'}, 'Plugins': {'metadata': '1.7.0', 'html': '1.19.0'}}
389-ds-base: 1.3.8.4-9.el7
nss: 3.36.0-5.el7_5
nspr: 4.19.0-1.el7_5
openldap: 2.4.44-18.el7
svrcore: 4.1.3-2.el7
FIPS: 0

rootdir: /mnt/tests/rhds/tests/upstream/ds, inifile:
plugins: metadata-1.7.0, html-1.19.0
collected 6 items

dirsrvtests/tests/suites/replication/regression_test.py::test_double_delete PASSED      [ 16%]
dirsrvtests/tests/suites/replication/regression_test.py::test_repl_modrdn PASSED        [ 33%]
dirsrvtests/tests/suites/replication/regression_test.py::test_password_repl_error PASSED [ 50%]
dirsrvtests/tests/suites/replication/regression_test.py::test_invalid_agmt PASSED       [ 66%]
dirsrvtests/tests/suites/replication/regression_test.py::test_fetch_bindDnGroup PASSED  [ 83%]
dirsrvtests/tests/suites/replication/regression_test.py::test_cleanallruv_repl PASSED   [100%]

================== 6 passed in 252.94 seconds ==================

Marking as verified.

Comment 9 errata-xmlrpc 2018-10-30 10:14:34 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.

https://access.redhat.com/errata/RHSA-2018:3127


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