Bug 1023085

Summary: nsds5ReplicaStripAttrs are not set on agreements
Product: Red Hat Enterprise Linux 7 Reporter: Martin Kosek <mkosek>
Component: ipaAssignee: Martin Kosek <mkosek>
Status: CLOSED CURRENTRELEASE QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: dpal, rcritten, sgoveas, spoore
Target Milestone: rcKeywords: Regression, TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-3.3.3-4.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 09:47:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
slapd error logs for winsync agreement failure none

Description Martin Kosek 2013-10-24 15:08:02 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/3989

In ipaserver/install/replication.py::setup_agreement() the value for nsds5ReplicaStripAttrs is added after the agreement is created.

This is masked when installing a new replica because the update fixup plugin is executed and the agreement is repaired.

If you do a connect between two masters then this attribute won't be added to the agreement.

A workaround is to run ipa-ldap-updater after doing a connect.

This was noticed in DS ticket https://fedorahosted.org/389/ticket/47386

Comment 1 Martin Kosek 2013-10-25 13:01:19 UTC
Fixed upstream:
master: https://fedorahosted.org/freeipa/changeset/9a368b6358e77607214a33bedd3f906641bea4e4
ipa-3-3: https://fedorahosted.org/freeipa/changeset/e2a4deb1800a0c3e7aa5612434c0d8aa08f150ab

REPRODUCTION SCENARIO:
1) Install IPA server and two replicas
2) Connect the two replicas
3) See replication agreement and see if nsds5ReplicaStripAttrs is set:
# ldapsearch -h `hostname` -D "cn=Directory Manager" -x -w Secret123 -b "cn=config" "(objectclass=nsds5replicationagreement)" nsDS5ReplicaHost nsds5ReplicaStripAttrs

With the patched version, nsds5ReplicaStripAttrs will be there.

Comment 3 Steeve Goveas 2013-11-12 12:54:14 UTC
Adding winsync agreement fails.

[root@hp-z600-01 ~]# rpm -q 389-ds-base ipa-server
389-ds-base-1.3.1.6-8.el7.x86_64
ipa-server-3.3.3-3.el7.x86_64

[root@hp-z600-01 ipa-winsync]# ipa-replica-manage connect --winsync --passsync=password --cacert=/tmp/tmp.HoMxuBdA3E/ADcert.cer squab.adrelm.com --binddn "CN=Administrator,CN=Users,DC=adrelm,DC=com" --bindpw Secret123 -v -p Secret123 | tee -a /tmp/tmp.HoMxuBdA3E/tmpout.ipa_winsync_0003.out
ipa: INFO: AD Suffix is: DC=adrelm,DC=com
Added CA certificate /tmp/tmp.HoMxuBdA3E/ADcert.cer to certificate database for hp-z600-01.testrelm.com
The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=testrelm,dc=com
Windows PassSync entry exists, not resetting password
unexpected error: attribute "nsds5ReplicaStripAttrs" not allowed

Comment 4 Steeve Goveas 2013-11-12 12:55:33 UTC
Created attachment 822953 [details]
slapd error logs for winsync agreement failure

slapd error logs for winsync agreement failure

Comment 8 Steeve Goveas 2013-11-13 12:58:11 UTC
[root@hp-z600-01 ~]# yum update ipa-server

[root@hp-z600-01 ~]# rpm -q ipa-server
ipa-server-3.3.3-4.el7.x86_64

[root@hp-z600-01 ~]# ipa-replica-manage connect --winsync --passsync=password --cacert=/tmp/tmp.HoMxuBdA3E/ADcert.cer squab.adrelm.com --binddn "CN=Administrator,CN=Users,DC=adrelm,DC=com" --bindpw Secret123 -v -p Secret123 | tee -a /tmp/tmp.HoMxuBdA3E/tmpout.ipa_winsync_0003.out 
ipa: INFO: AD Suffix is: DC=adrelm,DC=com
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: 0 No replication sessions started since server startup: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Added CA certificate /tmp/tmp.HoMxuBdA3E/ADcert.cer to certificate database for hp-z600-01.testrelm.com
The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=testrelm,dc=com
Windows PassSync entry exists, not resetting password
Starting replication, please wait until this has completed.
Update in progress, 69 seconds elapsed
Update succeeded

Connected 'hp-z600-01.testrelm.com' to 'squab.adrelm.com'

New test1 user in AD got synced successfully with its password.

[root@hp-z600-01 ~]# ipa user-find test1
--------------
1 user matched
--------------
  User login: test1
  First name: test1
  Last name: user
  Home directory: /home/test1
  Login shell: /bin/sh
  UID: 933400007
  GID: 933400007
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 1
----------------------------

Comment 9 Namita Soman 2013-11-15 20:50:30 UTC
Also verified using steps from Comment 1.
Verified using ipa-server-3.3.3-4.el7.x86_64

Steps taken:
1. Installed master and 2 replicas
2. Ran the cmd below on the three machines:
# ldapsearch -h `hostname` -D "cn=Directory Manager" -x -w Secret123 -b "cn=config" "(objectclass=nsds5replicationagreement)" nsDS5ReplicaHost nsds5ReplicaStripAttrs

on master - there were entries for meToibm-x3650m4-01-vm-05.testrelm.com (replica1), and meToibm-x3650m4-01-vm-16.testrelm.com (replica2)
on replica1 - there was entry for meTointel-canoepass-09.testrelm.com (master)
on replica2 - there was entry for  meTointel-canoepass-09.testrelm.com (master)

3. Ran command to connct the two replicas: 
# ipa-replica-manage connect <replica1> <replica2>

4> ran cmd again:
# ldapsearch -h `hostname` -D "cn=Directory Manager" -x -w Secret123 -b "cn=config" "(objectclass=nsds5replicationagreement)" nsDS5ReplicaHost nsds5ReplicaStripAttrs
This time:
on replica1 - there were entries for meTointel-canoepass-09.testrelm.com (master) and meToibm-x3650m4-01-vm-05.testrelm.com (replica2)
on replica2 - there were entries for meTointel-canoepass-09.testrelm.com (master) and meToibm-x3650m4-01-vm-16.testrelm.com (replica2)

Comment 10 Ludek Smid 2014-06-13 09:47:36 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.