Bug 537956 - Password replication from 389DS to AD2008(64bit) fails, all other replication continues
Summary: Password replication from 389DS to AD2008(64bit) fails, all other replication...
Alias: None
Product: 389
Classification: Retired
Component: Sync Service
Version: 1.2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
: 549384 (view as bug list)
Depends On:
Blocks: 434914 389_1.2.5
TreeView+ depends on / blocked
Reported: 2009-11-16 22:15 UTC by Anne Cross
Modified: 2015-12-07 16:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:32:24 UTC

Attachments (Terms of Use)
Log of the 389DS server with replication logging turned on during a password change. (18.09 KB, text/plain)
2009-11-16 22:15 UTC, Anne Cross
no flags Details
patch (1.58 KB, patch)
2010-01-04 17:55 UTC, Rich Megginson
nhosoi: review+
Details | Diff

Description Anne Cross 2009-11-16 22:15:28 UTC
Created attachment 369802 [details]
Log of the 389DS server with replication logging turned on during a password change.

> Description of problem:

* AD 2008 64 bit, running on Windows Server 2007 SP2
* 389DS 1.2.4 running on CentOS 5.3

passsync 1.1.4 will successfully capture and replicate passwords from the 2008 AD server to the 389DS server.  However, winsync on the 389DS server is unable to replicate passwords to the AD server.

It appears that winsync binds to as the replication manager to the AD server, attempts to bind as the user to verify that the password needs to be changed, fails, and then stops.  Five minutes later, it attempts to change the password again and the log reports the following:

[16/Nov/2009:16:53:36 -0500] NSMMReplicationPlugin - agmt="cn=ita4windc2-user" (ita4windc2:636): AD already has the current password for CN=<CN> Not sending password modify to AD.

Replication is binding to AD over port 636/LDAPS, and all other changes continue to flow normally.  Winsync password changes appear to be the only issue.

The following functions correctly against the AD server when the password is set on the AD side, but not when the password is set on the 389DS side and replicated back:

/usr/lib64/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-<host>/cert8.db -h <AD SERVER> -p 636 -D "CN=<CN>" -w '<password>' -s base -b 'dc=corp,dc=itasoftware,dc=com' "objectclass=*"

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

389DS 1.2.4

> How reproducible:

We only have one environment.

> Additional info:

With regards to http://support.microsoft.com/kb/906305/en-us, the AD server has had the OldPasswordAllowedPeriod set to 0.  This did not affect the behaviour of the servers in the slightest.

Comment 1 Anne Cross 2009-11-16 22:17:30 UTC
Replication is between one AD server in the pair (the one responsible for handling password changes) and a single LDAP master. We will eventually set up MMR, but it makes digging through the logs simpler to have a single master for the moment.

Comment 2 Rich Megginson 2010-01-04 17:51:57 UTC
*** Bug 549384 has been marked as a duplicate of this bug. ***

Comment 3 Rich Megginson 2010-01-04 17:55:37 UTC
Created attachment 381602 [details]

Comment 4 Rich Megginson 2010-01-04 18:14:11 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   4383fca..fc6040d  master -> master

commit fc6040d2a1b57d45f43f55648cff3ccf753b21ad
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Mon Jan 4 10:54:47 2010 -0700

    Password replication from 389DS to AD fails

Comment 5 Jenny Severance 2010-05-27 19:09:55 UTC
verified ( not specific to windows 2008 - see duplicate bug ) - Windows 2003


1. Changed ADS synced user's password and mail attribute from DS console.
2. Logged into ADS domain successfully with DS changed password
3. Mail attribute change synced successfully
4. Again changed the ADS synced user's password and telephoneNumber attribute
5. Logged into ADS domain successfully with DS changed password.
6. telephoneNumber attribute change synced successfully

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