Univention Bugzilla – Bug 49498
S4-Connector rejects for CN=Machine/CN=User due to CN=MachineStaging/CN=UserStaging
Last modified: 2021-05-14 16:38:08 CEST
In a support case we found S4-Connector rejects, where we had CN=MachineStaging and CN=UserStaging objects in OpenLDAP (and the lowercase versions in Samba/AD) in addition to the CN=Machine and CN=User containers of some GP containers. AFAIK these are temporary objects created by some MS tool (GPMC?) and I guess that it does these steps: 1. create CN=MachineStaging, 2. delete CN=Machine and 3. rename CN=MachineStaging to CN=Machine. I could be wrong, but if that is the case then the S4-Connector may have a timing problem with this. I guess we should put the CN=MachineStaging and CN=UserStaging of the ignore list. The traceback doesn't exactly give a direct clear idea of this situation: =========================================================================== 16.05.2019 16:39:32,358 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=Machine,CN={C61AEC73-370D-4296-8DB0-745075D87BFD},CN=Policies,CN=System,DC=domain,DC=net 16.05.2019 16:39:32,361 LDAP (PROCESS): sync to ucs: [ container] [ modify] cn=machine,cn={c61aec73-370d-4296-8db0-745075d87bfd},cn=policies,cn=system,dc=domain,dc=net 16.05.2019 16:39:32,369 LDAP (ERROR ): Unknown Exception during sync_to_ucs 16.05.2019 16:39:32,369 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1626, in sync_to_ucs result = self.modify_in_ucs(property_type, object, module, position) File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1377, in modify_in_ucs res = ucs_object.modify(serverctrls=serverctrls, response=response) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 583, in modify dn = self._modify(modify_childs, ignore_license=ignore_license, response=response) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 1207, in _modify self._ldap_pre_modify() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/container/cn.py", line 272, in _ldap_pre_modify self.move(newdn) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 735, in move res = n(self._move(newdn, ignore_license=ignore_license)) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 1354, in _move self.lo.rename(self.dn, newdn) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 862, in rename raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg) ldapError: Already exists ===========================================================================
tl;dr: Try putting CN=MachineStaging and CN=UserStaging on the ignorelist. Details: Using the LDAP search with notification control ( https://help.univention.com/t/q-a-how-to-use-samba-ad-controls-to-work-with-notifications/10115 ) I was able to trace the origin of these temporary containers. The Group Policy Management Console (GPMC) creates them when you restore a GPO from backup. This is the order of LDAP changes as they happen, pretty straight forward: =========================================== # record 1 dn: CN=UserStaging,CN={GPOGUID},... changetype: add # record 2 dn: CN=MachineStaging,CN={GPOGUID},... changetype: add # record 3 dn: CN=User,CN={GPOGUID},... changetype: modrdn newrdn: CN=UserOld deleteoldrdn: 1 # record 4 dn: CN=Machine,CN={GPOGUID},... changetype: modrdn newrdn: CN=MachineOld deleteoldrdn: 1 # record 5 dn: CN=UserStaging,CN={GPOGUID},... changetype: modrdn newrdn: CN=User deleteoldrdn: 1 # record 6 dn: CN=MachineStaging,CN={GPOGUID},... changetype: modrdn newrdn: CN=Machine deleteoldrdn: 1 # record 7 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 6 # record 8 dn: CN=UserOld,CN={GPOGUID},... changetype: modrdn newrdn: CN=UserOld\0ADEL:... deleteoldrdn: 1 # record 9 dn: CN=MachineOld,CN={GPOGUID},... changetype: modrdn newrdn: CN=MachineOld\0ADEL:... deleteoldrdn: 1 # record 10 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 196614 # record 10 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 196617 =========================================== From that I think we could safely try putting CN=MachineStaging on the ignorelist, but we should probably not put CN=MachineOld on it too, because the S4-Connector would probably treat the modrdn operations in record 3&4 as a deletes which could be dangerous if the S4-Connector echos that delete back to Samba/AD. We may have a recipie against that by using the LDAP Post Read control (Bug #43628 / Bug #48988), but that would probably require an invasive code change in the S4-Connector.
This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.