Bug 207893 - rhds71 importing users with crypted passwords results in a AD-RHDirServ sync loop
Summary: rhds71 importing users with crypted passwords results in a AD-RHDirServ sync ...
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Sync Service
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: DS8.0
: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
Depends On:
Blocks: 152373 240316
TreeView+ depends on / blocked
Reported: 2006-09-25 07:41 UTC by Jose Plans
Modified: 2018-10-19 20:30 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2016-05-06 14:51:08 UTC

Attachments (Terms of Use)
CVS Diffs (7.88 KB, patch)
2007-08-24 22:15 UTC, Nathan Kinder
no flags Details | Diff
test data (410 bytes, text/plain)
2007-10-19 21:40 UTC, Yi Zhang
no flags Details

Description Jose Plans 2006-09-25 07:41:39 UTC
The winsync code is not designed to deal with crypted passwords, only with plain

Here is how to reproduce:
1. set up winsync agreement with AD (including password sync)
2. import a user with NT attributes using an ldif file.  This user should have
NT attributes to create/delete the user on the AD side.  He should also have a
crypted userpassword to be imported.

What happens:
1. RHDS realizes that what is imported is a crypt password.  It stores the crypt
and sends the entire crypt string to AD.  That is - it sends "{crypt}XXXX". 
This is likely wrong behaviour.
2. AD does not know how to handle crypt strings.  It thinks the password is a
new password -with the plaintext "{crypt}XXXX"
3.  This triggers password sync -- who tries to bind to the DS with the password
"{crypt}XXXX" to confirm that the password has changed.  Thsi of course fails,
so it sends a notification of the "new" password to RHDS
4.  RHDS sees the new password, realizes its a crypted password - strips the
crypt - and sends the entire crypted string to AD.
5. Loop!

This of course does not occur if all the users have been imported prior to the
initial sync as the initial sync does not pass passwords over.  And there is ,
of course, no problem if users are added with cleartext passwords.

ADS used is Windows 2003.

Comment 3 To Ngan 2006-11-29 20:04:24 UTC
This bug is currently targeted to be addressed in DS 7.2.  However, the product
team reserves the right to later it in case schedule/resource becomes an issue.

Comment 4 Chandrasekar Kannan 2007-07-25 19:18:28 UTC
DS7.2 is not a valid milestone anymore. Anything thats set to DS7.2 should be
set to DS8.0. Will make further changes per bug council on 07/24/2007, after this.

Comment 5 Nathan Kinder 2007-08-24 22:15:58 UTC
Created attachment 172462 [details]
CVS Diffs

This fix first checks if there is a password storage scheme at the beginning of
the userpassword attribute value before syncing it.  If there is a storage
scheme present, a message is logged at the replication logging level that this
hashed password is being skipped instead of just trying to sync it.

If someone adds a password with the clear prefix on it to RHDS (such as
"{clear}secret"), we will detect that and strip off the "{clear}" prefix before
sending it to AD.  All other passwords that start with the "{" character and
contain the "}" character somewhere else in the password will be considered to
be already hashed.

Comment 6 Rich Megginson 2007-08-24 23:01:11 UTC
You should probably log the DN of the entry that has the pre-hashed password so
the administrator can find it and figure out what happened.  Otherwise, looks good.

Comment 7 Nathan Kinder 2007-08-27 16:32:28 UTC
The DN of the affected entry is logged in the previous log message, so I don't
think there is a need to list the DN in the new message as well.  Here is an
example of what an administrator would see in the errors log:

[24/Aug/2007:14:26:07 -0700] NSMMReplicationPlugin - agmt="cn=Ad Sync"
(172:636): windows_replay_update: Processing modify operation local
dn="uid=nkinder,ou=people,dc=sfbay,dc=redhat,dc=com" remote
[24/Aug/2007:14:26:07 -0700] NSMMReplicationPlugin - agmt="cn=Ad Sync"
(172:636): windows_create_remote_entry: Password is already hashed.  Not syncing.

Comment 8 Nathan Kinder 2007-08-27 17:17:27 UTC
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in windows_protocol_util.c;
 <--  windows_protocol_util.c
new revision: 1.29; previous revision: 1.28
Checking in windowsrepl.h;
/cvs/dirsec/ldapserver/ldap/servers/plugins/replication/windowsrepl.h,v  <-- 
new revision: 1.11; previous revision: 1.10

Comment 9 Yi Zhang 2007-10-19 21:40:08 UTC
Created attachment 233131 [details]
test data

Comment 10 Yi Zhang 2007-10-19 21:43:00 UTC
Bug verification test done. Fix is valid. please check the attached test data
for details. The following lines from ldap error log file (to prove the above
date sync'd without error)
[19/Oct/2007:14:51:52 -0700] NSMMReplicationPlugin -
agmt="cn=to_mirror_newWinOU" (mirror:636): windows_replay_update: Processing add
operation local dn="uid=encryptuser02,ou=People,dc=dsdev, dc=sjc, dc=redhat,
dc=com" remote dn="cn=encryptuser 02,ou=newWinOU,dc=dsdev,dc=sjc,dc=redhat,dc=com"
[19/Oct/2007:14:51:52 -0700] NSMMReplicationPlugin -
agmt="cn=to_mirror_newWinOU" (mirror:636): process_replay_add:
dn="cn=encryptuser 02,ou=newWinOU,dc=dsdev,dc=sjc,dc=redhat,dc=com" (not
present,add allowed)
[19/Oct/2007:14:51:52 -0700] NSMMReplicationPlugin -
agmt="cn=to_mirror_newWinOU" (mirror:636): windows_create_remote_entry: Password
is already hashed.  Not syncing.
[19/Oct/2007:14:51:52 -0700] - Windows sync entry: Created new remote entry:
 dn: cn=encryptuser 02,ou=newWinOU,dc=dsdev,dc=sjc,dc=redhat,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: user
userprincipalname: abcd1232@dsdev.sjc.redhat.com
givenName: encryptuser02
sn: encryptuser02
cn: encryptuser 02
sAMAccountName: abcd1232

[19/Oct/2007:14:51:52 -0700] - Attempting to add entry cn=encryptuser
02,ou=newWinOU,dc=dsdev,dc=sjc,dc=redhat,dc=com to AD for local entry
uid=encryptuser02,ou=People,dc=dsdev, dc=sjc, dc=redhat, dc=com
[19/Oct/2007:14:51:52 -0700] NSMMReplicationPlugin -
agmt="cn=to_mirror_newWinOU" (mirror:636): Received result code 0 () for add
[19/Oct/2007:14:51:52 -0700] agmt="cn=to_mirror_newWinOU" (mirror:636) -
clcache_load_buffer: rc=-30990
[19/Oct/2007:14:51:52 -0700] NSMMReplicationPlugin -
agmt="cn=to_mirror_newWinOU" (mirror:636): No more updates to send
[19/Oct/2007:14:51:52 -0700] agmt="cn=to_mirror_newWinOU" (mirror:636) - session
end: state=5 load=1 sent=1 skipped=0

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