Bug 182515 - Dual winsync paths results in LDAP ADD collision on AD
Dual winsync paths results in LDAP ADD collision on AD
Status: CLOSED DEFERRED
Product: 389
Classification: Community
Component: Replication - General (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Ben Levenson
:
Depends On:
Blocks: 512820 690316
  Show dependency treegraph
 
Reported: 2006-02-22 17:48 EST by Ulf Weltman
Modified: 2015-11-19 18:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 18:08:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulf Weltman 2006-02-22 17:48:40 EST
Description of problem:
In a configuration with two DS in MMR (M1 and M2) and two AD in the same domain
(AD1 and AD2), if we configure M1 to sync with AD1 and M2 to sync with AD2, we
have a ring configuration with good availability.  Changes will be available
everywhere even if a server crashes.

However, replication between AD1 and AD2 seems to always lag behind slightly. 
If user uid=fbar,o=abc is added to M1, then uid=fbar,o=abc will be added right
away to M2.  Then M1 and M2 will both sync the user (with DN morphed into CN=foo
bar,o=abc) to their respective AD sync partners.

Here comes the problem.  Sometimes, not always, the sync from M1 to AD1 and the
sync from M2 to AD2 both succeed because of the lag between AD1 and AD2.  This
results in an update collision.  In both AD1 and AD2 we end up with CN=foo
bar,o=abc, and another entry called CN=foo
bar\0ACNF:8ba01336-6466-4495-85c4-54d4bd24549f,o=abc.  And then, because adding
users is a 3 step process (add user, mod password, mod activation flag) the
former is left inactive, while the latter is activated.  I'm not sure which of
them gets the password!

And it doesn't stop there.  Then next time DS calls dirsync on ADS, another cn
will added to uid=fbar,o=abc on M1 and M2 containing
CNF:8ba01336-6466-4495-85c4-54d4bd24549f.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.Configure MMR between replicas M1 and M2
2.Configure two AD domain controllers in a single domain, AD1 and AD2
3.Configure sync between M1 and AD1 and M2 and AD2
4.Add some NT users to M1.  Some, but not all, will collide on AD1 and AD2.
  
Actual results:


Expected results:


Additional info:
Comment 1 Rich Megginson 2009-01-14 12:53:20 EST
latering to 8.2
Comment 2 Martin Kosek 2012-01-04 08:49:53 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/148
Comment 4 Noriko Hosoi 2015-11-19 18:08:41 EST
Closing this bug since we moved to the ticket system:
https://fedorahosted.org/389/ticket/148

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