Description of problem: Testing with IPA source tip from 11/2/2008, soon to be freeipa v1.2. I don't have a recent fix related to DNA so adding a user on the AD side will fail to add to IPA because uidNumber isn't set. My solution to this was to add the user on both sides. On the IPA side I have to add ntUser to the objectclass list and set ntuserdomainid to the uid. The bottom line seems to be that if you have an attribute set only on the IPA side then changes to it will not be synced to the AD side. Version-Release number of selected component (if applicable): fedora-ds-base-1.1.3-2.fc9.i386 How reproducible: every time Steps to Reproduce: 1. Disable DNA 2. Add user to AD 3. Add same user to IPA 4. Set IPA user telephoneNumber to something 5. Add ntUser and ntuserdomainid to IPA user 6. Change telephoneNumber on IPA side 7. Sync of the telephoneNumber will fail To get them back into sync: 1. Set the telephoneNumber on AD side 2. This will change it on the IPA side 3. Future changes to either side will be replicated Additional info: Here is a log showing the IPA-side password change not replicating. [11/Nov/2008:11:11:54 -0500] NSMMReplicationPlugin - dump mods for replay update:[11/Nov/2008:11:11:54 -0500] - smod 0 - delete: telephoneNumber [11/Nov/2008:11:11:54 -0500] - smod 0 - value: telephoneNumber: 410-555-1216 [11/Nov/2008:11:11:54 -0500] - smod 1 - add: telephoneNumber [11/Nov/2008:11:11:54 -0500] - smod 1 - value: telephoneNumber: 410-555-1217 [11/Nov/2008:11:11:54 -0500] NSMMReplicationPlugin - agmt="cn=meTowin2003.example.local636" (win2003:636): Received result code 16 (00002085: AtrErr: DSID-03151ADF, #1: 0: 00002085: DSID-03151ADF, problem 1001 (NO_ATTRIBUTE_OR_VAL), data 0, Att 14 (telephoneNumber):len 24 ) for modify operation [11/Nov/2008:11:11:54 -0500] NSMMReplicationPlugin - agmt="cn=meTowin2003.example.local636" (win2003:636): Consumer failed to replay change (uniqueid 00c42963-1dd211b2-9971fe7a-09010000, CSN 4919aec9000000030000): No such attribute. Skipping.
In step 3 - when you added the user to IPA, did you add it with a telephoneNumber value? In step 4 - did you use the IPA GUI or XML-RPC script to change the telephoneNumber? The reason I ask is that the sequence of operations in the log is odd: smod 0 - delete: telephoneNumber smod 0 - value: telephoneNumber: 410-555-1216 smod 1 - add: telephoneNumber smod 1 - value: telephoneNumber: 410-555-1217 AFAICT, these are the operations received by the IPA DS. Assuming these succeeded, the entry must have had a telephoneNumber, and it must have had a value of 410-555-1216
At step 7 - how do you get the telephoneNumber to sync? Do you perform an ipa-replica-manage init at that point?
per comment #1 this is the sync log of when I'm trying to change the telephoneNumber on the IPA side. There is no phone number on the AD side. If I'm reading this right the update is failing because the original value doesn't exist in AD. I sync by changing the value. 410-555-1216 was the original telephoneNumber attribute set on the IPA side before linking it to the AD account by setting ntuserdomainid I tried to force the phone number to send to AD by changing it and saw that it failed.
I was able to reproduce. I used the same steps above. I used regular DS Winsync - no IPA. I setup winsync and did the init before step 2. A couple of notes: Step 3 is usually not needed - adding a user to AD will automatically add the user to DS - but if you do steps 3-7 immediately after adding the AD entry, you will usually beat the 5 minute sync interval. That is, if after step 2, you wait over 5 minutes, the entry will be created, and step 3 will give an error. Sync will continue - after the error, sync will just skip this mod, and move on to the next one. The problem is only when the DS is replaying updates during an incremental update (synch). The problem does not happen with a total update (init). In the total update case, the function windows_generate_update_mods() is called to generate the updates to send to the remote entry. This function does take into consideration missing attributes. I'm not sure why the incremental code doesn't do this. So I think it is safe to release IPA with this bug. But we do need to fix it for DS.
I'm testing a patch for this, should be available very soon.
Created attachment 328589 [details] diffs
The changes look good. Please open a doc bug to get the Plugin Guide updated with the new public function that is added by your patch.
Created attachment 328593 [details] cvs commit log Reviewed by: nkinder (Thanks!) Fix Description: Before sending updates to AD, first check to see if the updates still apply. For modify/add operations, check to make sure the value to add doesn't exist. If it does, remove it from the list of values in the mod. If all values are removed, then just skip the modify/add op altogether. For modify/del ops, check to see if the attribute exists. If not, just skip the op. If it does exist, check to see if the values exist, and remove the values from the mod/del op that do not exist anymore. If all values have been removed, just skip the mod/del op. I added a new slapi function - slapi_mod_init_valueset_byval - which will init a Slapi_Mod and init the list of values using a valueset. Fortunately there was already a function for converting a Slapi_Value** to a berval**. I also fixed a few compiler warnings. Platforms tested: RHEL5 Flag Day: no Doc impact: yes - add new function to slapi docs
Following the steps in the Description, telephoneNumber successfully synched to active directory. fix verified DS 8.1 RHEL 5 - passsync v 1.1.0
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. http://rhn.redhat.com/errata/RHEA-2009-0455.html