Bug 537956

Summary: Password replication from 389DS to AD2008(64bit) fails, all other replication continues
Product: [Retired] 389 Reporter: Anne Cross <across>
Component: Sync ServiceAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2.1CC: james_roman, jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:32:24 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:
Bug Depends On:    
Bug Blocks: 434914, 533025    
Attachments:
Description Flags
Log of the 389DS server with replication logging turned on during a password change.
none
patch nhosoi: review+

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:

Servers: 
* 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]
patch

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>
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

version:
redhat-ds-base-8.2.0-2010052704.el4dsrv
RedHat-PassSync-1.1.4-i386.msi

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