Bug 204966 - WinSync ignores entry if NT attributes are added later.
WinSync ignores entry if NT attributes are added later.
Product: Red Hat Directory Server
Classification: Red Hat
Component: Sync Service (Show other bugs)
All Linux
medium Severity medium
: DS8.1
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
Depends On:
Blocks: 434915 FDS1.2.0
  Show dependency treegraph
Reported: 2006-09-01 15:18 EDT by To Ngan
Modified: 2015-01-04 18:20 EST (History)
6 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-29 18:59:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diffs (8.10 KB, patch)
2009-01-12 17:28 EST, Rich Megginson
no flags Details | Diff
better diffs (9.67 KB, patch)
2009-01-12 22:38 EST, Rich Megginson
no flags Details | Diff
cvs commit log (563 bytes, text/plain)
2009-01-13 13:29 EST, Rich Megginson
no flags Details

  None (edit)
Description To Ngan 2006-09-01 15:18:38 EDT
Description of problem:
This is from Ade Lee:
"If we add a brand new user on RHDS, making sure to set his NT attributes and to
set the attributes to create a new user on the AD side, then everything works
correctly.  The AD user is created correctly and is not created in a disabled
state, when an incremental update is made.

If we take an existing RHDS user and simply add the NT attributes (ntDomainName)
and the attributes to create a new user in AD, then the user is not created on
the AD side on an incremental update.  Also, on a full update, the user is
created but is created in a disabled state."

Version-Release number of selected component (if applicable):
All current DS 7.1x with WinSync

How reproducible:

Steps to Reproduce:
1. Set up WinSync with AD
2. Test to see a brand new user with proper NT attributes gets sync'd to AD and
is enabled.
3. Create a user in RHDS without NT attributes.  The entry won't sync to AD.
4. Then add NT attributes to that user entry.
Actual results:
User doesn't sync to AD.  If a full sync is issued, the entry will be sync'd to
AD, but will be disabled.

Expected results:
When NT attributes are added, and entry should sync to AD, or at least a full
sync should not result in a disabled user entry in AD.
Comment 3 Rich Megginson 2009-01-12 17:28:37 EST
Created attachment 328796 [details]
Comment 4 Rich Megginson 2009-01-12 22:38:32 EST
Created attachment 328818 [details]
better diffs
Comment 5 Rich Megginson 2009-01-13 13:29:05 EST
Created attachment 328899 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Fix Description: If we are replaying a modify operation, we need to check if the ntUser objectclass is being added along with the other attributes that tell the sync service to sync this entry.  If the objectclass is being added or replaced, we check the existing entry to see if it is still a sync-able entry.  If it is, we call process_replay_add to add the entry.  I changed this function to accept a Slapi_Entry to add rather than the operation structure.  Finally, I had to change the way we send the Account Control flags to take into account an entry that may have been added as a result of a modify operation.
I fixed a memory leak when setting the Slapi_Attr attribute type, and cleaned up a compiler warning.
NOTE: There will be no clear text password to send (unless the userPassword was modified in the same modify operation).  This means the account will be added to Windows, and will be enabled, but will be essentially unusable - the user cannot login - until either the user modifies the password on the directory server side, or the administrator resets the password.
Platforms tested: RHEL5
Flag Day: no
Doc impact: yes - we will have to document the new winsync behavior
Comment 6 Jenny Galipeau 2009-03-12 10:49:38 EDT
fix verified DS 8.1 RHEL 5 - Windows Synchronization 1.1.0

User added without nt attributes.
User then modified and nt attributes added.
Send and received updates.
User correctly added to ADS and enabled.

I do not see the new behavior documented in

Will open documentation bug and reference this bug.
Comment 7 Jenny Galipeau 2009-03-12 11:01:14 EDT
sorry - didn't mean to change component
Comment 8 Chandrasekar Kannan 2009-04-29 18:59:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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