Univention Bugzilla – Bug 33882
Unable to delete computer object in AD due to child objects
Last modified: 2017-09-04 14:06:27 CEST
On a Samba 4 dc there have been s4 connector rejects while deleteing windows computers due to unknown child objects that are located below the windows computer object (in AD). It turns out that the child objects are objects of local printer shares. They are added in AD if a local printer share is created on that host and the checkbox "im Verzeichnis anzeigen" (← Win XP) is switched on. The local printer share objects are used for locating printers within the AD domain by windows clients. The checkbox may be turned off permanently by GPO. The objects are removed if the checkbox is turned off later. Workaround: occuring rejects may be solved by removing the local printer share objects manually via ldbdel 09.01.2014 11:24:40,346 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1384341924.289883 09.01.2014 11:24:40,350 LDAP (PROCESS): sync from ucs: [windowscomputer] [ delete] cn=winhost1,cn=computers,ou=someou,dc=some,dc=example,dc=com 09.01.2014 11:24:41,528 LDAP (WARNING): delete subobject: CN=winhost1-HP Officejet 6700 (Netzwe0023004711,CN=winhost1,CN=computers,OU=someou,DC=some,DC=example,DC=com 09.01.2014 11:24:41,612 LDAP (WARNING): sync failed, saved as rejected 09.01.2014 11:24:41,612 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 753, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2338, in sync_from_ucs self.delete_in_s4( object, property_type ) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2377, in delete_in_s4 if not self.sync_from_ucs(key, subobject, object_mapping['dn']): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2127, in sync_from_ucs if self.property[property_type].sync_mode in ['read', 'none']: KeyError: None
Also seen at [Ticket#2015070921000814]: If one install a Windows terminalserver there will be also an object CN=TermServLicensing as subobject of the terminalserver created. Once one want to delete the terminalserver itself via UMC there will be a reject created since the subobject cannot be deleted (AFAIK the LDAP doesn't know anything about this subobject). 09.07.2015 14:24:50,11 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1435824301.685845 09.07.2015 14:24:50,26 LDAP (PROCESS): sync from ucs: [windowscomputer] [ delete] CN=w2k8termp,OU=223,OU=windowsserver,DC=local,DC=de 09.07.2015 14:24:50,746 LDAP (WARNING): delete subobject: CN=TermServLicensing,CN=w2k8termp,OU=223,OU=windowsserver,DC=local,DC=de 09.07.2015 14:24:50,764 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1435824301.685845 09.07.2015 14:24:50,765 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 801, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))): File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2536, in sync_from_ucs self.delete_in_s4( object, property_type ) File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2590, in delete_in_s4 if not self.sync_from_ucs(key, subobject, object_mapping['dn']): File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2243, in sync_from_ucs if self.property[property_type].sync_mode in ['read', 'none']: KeyError: None
Happened again at 2015071421000439 - bumped version to 4.0, adjusted TM You have to remove all Subobjects (also happend sfor hyper-v metaobjects for example), then the connector removes the machine object.
Happened again at 2015120721000451. UCS-Version 4.1
Happened again at Ticket#2016011321000155 after update to 4.1
*** Bug 31090 has been marked as a duplicate of this bug. ***
(In reply to Stefan Gohmann from comment #5) > *** Bug 31090 has been marked as a duplicate of this bug. *** See Bug #31090 for a similar case.
I've adjusted the delete_in_s4 method to support removal of unmapped sub-objects. Before this the DNs of those objects needed to be whitelisted (Bug #26210) in a "con_subtree_delete_objects" mapping attribute. I've removed that now, too. Advisroy: univention-s4-connecor.
(In reply to Arvid Requate from comment #7) > I've adjusted the delete_in_s4 method to support removal of unmapped > sub-objects. > Before this the DNs of those objects needed to be whitelisted (Bug #26210) > in a "con_subtree_delete_objects" mapping attribute. I've removed that now, > too. Wouldn't it be better to use the con_subtree_delete_objects and allow to add values via UCR? This could be logged and the Administrator can expand the UCR variable and we should add some of the objects which are part of the tickets. Otherwise it could result in a deletion of a complete AD tree for example if a rename fails or the Listener gives wrong values due to a cache problem.
Ok, googling for these kind of UCS tracebacks I find these RDNs: ======================================================== CN=winhost1-HP Officejet 6700 (Netzwe0023004711 CN=TermServLicensing CN=Windows Virtual Machine CN=RouterIdentity CN={3cefcc1a-6c7a-4f56-b7c3-951849cdb5f8} ======================================================== * The first probably is of objectClass=printQueue, added by clicking on "List in the Directory", see https://blogs.technet.microsoft.com/askperf/2009/05/05/printing-and-active-directory/ * The next three are of objectClass=serviceConnectionPoint (SCP), see https://msdn.microsoft.com/en-us/library/windows/desktop/ms677638(v=vs.85).aspx . There are other SCPs, like "CN=IASIdentity" and there are also objects of class "serviceAdministrationPoint", so maybe we should allow removal of the parent class "connectionPoint" to catch all of those types. * Another frequent sub-object object could be "CN=NTFRS Subscriptions", which has objectclass=nTFRSMember.
Ok, I've reverted my changes and implemented the filter based approach. Advisroy: univention-s4-connecor.yaml
con_subtree_delete_objects is set for 'dc' objects, we probably want this for 'windowscomputer' to
OK - connector deletes unknown subobjects of objectclass 'objectClass=rIDSet', 'objectClass=connectionPoint' or 'objectclass=nTFRSMember' for dc and windowscomputer objects OK - connector does not delete other unknown subobjects OK - univention-s4-connector.yaml
<http://errata.software-univention.de/ucs/4.2/44.html>