Bug 207893
| Summary: | rhds71 importing users with crypted passwords results in a AD-RHDirServ sync loop | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Directory Server | Reporter: | Jose Plans <jplans> | ||||||
| Component: | Sync Service | Assignee: | Nathan Kinder <nkinder> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 7.1 | CC: | tao | ||||||
| Target Milestone: | DS8.0 | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-05-06 14:51:08 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: | 152373, 240316 | ||||||||
| Attachments: |
|
||||||||
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. 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. 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.
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. 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 dn="<GUID=251ba66b4614934480a3a7a3ae2b8c4c>" [24/Aug/2007:14:26:07 -0700] NSMMReplicationPlugin - agmt="cn=Ad Sync" (172:636): windows_create_remote_entry: Password is already hashed. Not syncing. Checked into ldapserver (HEAD). Thanks to Rich for his review! Checking in windows_protocol_util.c; /cvs/dirsec/ldapserver/ldap/servers/plugins/replication/windows_protocol_util.c,v <-- windows_protocol_util.c new revision: 1.29; previous revision: 1.28 done Checking in windowsrepl.h; /cvs/dirsec/ldapserver/ldap/servers/plugins/replication/windowsrepl.h,v <-- windowsrepl.h new revision: 1.11; previous revision: 1.10 done Created attachment 233131 [details]
test data
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.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 operation [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 (cl5GetNextOperationToReplay) [19/Oct/2007:14:51:52 -0700] agmt="cn=to_mirror_newWinOU" (mirror:636) - session end: state=5 load=1 sent=1 skipped=0 |
The winsync code is not designed to deal with crypted passwords, only with plain text. 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.