Created attachment 403519 [details] errorlog with replication debug turned on Description of problem: The Active Directory sync is blocked after changing the uid or ntUserDomainId, error logs are attached Version-Release number of selected component (if applicable): 1.2.5 How reproducible: Steps to Reproduce: 1. Create User in AD and let it snyc to 389 DS 2. Change uid/ntUserDomainId in 389 DS 3. Actual results: ntUserDomainId is synched correctly, but no more users are synced from AD to 389 with this sync agreement. After a "Full resynch" this error is gone Expected results: New users that are created should still be synched Additional info:
Note that entry naming is different in DS than in AD: uid=rmeggins,ou=people,... DS CN=Rich Megginson,CN=Users,... AD So if in the DS you rename uid=rmeggins to uid=rmeggins2 - what do you expect to happen on the AD side?
we actually changed the "ntUserDomainId" and the "uid" in one turn, changing the "ntUserDomainId" like ntUserDomainId=rmeggins to rmeggins2 should result in a change of the sAMAccountName to "rmeggins2" on the AD side as well. I am not 100% sure, but as far as i understood, the uid is only constructed once when synchronizing the user from AD to DS, we put it only in there, because we change both attributes at once, i can rechack though if it happens when only changing one attribute
Ok. Then I think what should happen is that the ntUserDomainId should sync over to the samAccountName, but the rename operation should not sync.
Created attachment 404763 [details] 0001-Bug-578229-Blocked-sync-afer-UID-or-ntUserDomainId.patch
Now I get this error, and winsync keeps going: [06/Apr/2010:11:31:26 -0600] NSMMReplicationPlugin - agmt="cn=meTow2k3i386389" (w2k3i386:389): replay_update: rename [uid=testuser1,ou=people,dc=example,dc=com] to [uid=testuser2] returned error [10] but since windows naming is different, this error will be ignored
With current git master:HEAD (1.2.6.a3) I get the following: [06/Apr/2010:13:35:21 -0600] NSMMReplicationPlugin - process_replay_rename: newparent is empty [06/Apr/2010:13:35:21 -0600] NSMMReplicationPlugin - agmt="cn=meTow2k3i386389" (w2k3i386:389): Consumer failed to replay change (uniqueid 65f65c90-41b311df-b256d03a-48d5a624, CSN 4bbb8cf8000000010000): Success. Skipping. Since subtree rename was added, the code attempts to handle rename/move operations correctly, and skips the rename. The following was checked in to the 8.2 branch commit 700ba895387aaf63523353f622e57fab9726b0f2 Author: Rich Megginson <rmeggins> Date: Tue Apr 6 12:03:38 2010 -0600 Reviewed by: nhosoi (Thanks!) Branch: Directory_Server_8_2_Branch Fix Description: Since Windows DIT naming can be very different than DS DIT naming, most modrdn operations do not apply. The fix is to allow the modrdn operation to go through, but check the error returned. If the error returned indicates some sort of naming difference, the error is ignored. Platforms tested: RHEL5 x86_64, Win 2003 Flag Day: no Doc impact: no
verified - RHEL 4 version: redhat-ds-base-8.2.0-2010052704.el4dsrv 1. created user in AD with uid /ntUserDomainId of "changeme" and allowed synchronization 2. in DS console changed the uid and ntUserDomainId to "changeme2" and allowed synchronization Successful: dn: CN=change me,CN=Users,DC=bos,DC=redhat,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: change me sn: me givenName: change distinguishedName: CN=change me,CN=Users,DC=bos,DC=redhat,DC=com instanceType: 4 whenCreated: 20100527172935.0Z whenChanged: 20100527173020.0Z displayName: change me uSNCreated: 82031 uSNChanged: 82038 name: change me objectGUID:: h5aWAREYX0OVP/xa+wm+5Q== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 129194549756555000 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAJdbgAbVFuQmrmcJDbgQAAA== accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: changeme2 <============================================== sAMAccountType: 805306368 userPrincipalName: changeme.com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=bos,DC=redhat,DC=com 3. Add a new user to DS and to ADS and allowed synchronization Both users synced successfully.