Problem:
The s4-connector generates this rejects when modifiying objects
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/univention/s4connector/__init__.py", line 837, in __sync_file_from_ucs
if not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new, restored=restored):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/univention/s4connector/s4/__init__.py", line 2046, in sync_from_ucs
if self.restore_in_s4(object, property_type):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/univention/s4connector/s4/__init__.py", line 2467, in restore_in_s4
self.lo_s4.lo.modify_ext_s(
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 400, in modify_ext_s
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 543, in result3
resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4(
^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 553, in result4
ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 128, in _ldap_call
result = func(*args,**kwargs)
^^^^^^^^^^^^^^^^^^^^
ldap.UNWILLING_TO_PERFORM: {'msgtype': 103, 'msgid': 416, 'result': 53, 'desc': 'Server is unwilling to perform', 'ctrls': [], 'info': '00002035: Trying to restore not deleted object\n at ../../source4/dsdb/samdb/ldb_modules/tombstone_reanimate.c:376'} | x_filename=/var/lib/univention-connector/s4/1773052849.989480
Investigation:
The S4 Connector maintains several database tables; two of them are relevant here: the “UCS deleted” table and the newer “uoid2guid” table.
The uoid2guid table contains a mapping between the univentionObjectIdentifier (key) in LDAP and the objectGUID (value) in Samba4.
The “UCS deleted” table contains a mapping from the LDAP entryUUID / UOI to the objectGUID of deleted objects.
Entries may look like the following examples:
8a1126c0-aedf-103a-9bca-ff269e4955f9|224443b3-cb29-4028-a664-7518c949614f
ceb76276-6e01-1040-9283-776241f997ad|objectGUID
If there is a discrepancy between the entries in uoid2guid and UCS deleted, this may indicate potential issues.
Checking the object:
univention-ldapsearch -LLL uid=lilly$ univentionObjectIdentifier
dn: cn=LILLY,cn=computers,dc=schein,dc=com
8a1126c0-aedf-103a-9bca-ff269e4955f9
univention-s4search samaccountName=lilly$ 1.1
# record 1
dn: CN=LILLY,CN=Computers,DC=schein,DC=com
checking the database for univentionObjectIdentifier to objectGUID mapping:
sqlite3 /etc/univention/connector/s4internal.sqlite
sqlite> select value from 'uoid2guid' where key like '8a1126c0-aedf-103a-9bca-ff269e4955f9';
b5dc4721-de33-454a-8dee-bad24bec6c17
This entry matched to:
univention-s4search --cross-ncs --show-deleted objectGUID=b5dc4721-de33-454a-8dee-bad24bec6c17 1.1
# record 1
dn: CN=LILLY,CN=Computers,DC=schein,DC=com
Now check the UCS deleted table for deleted mapping
sqlite> select * from 'UCS deleted' where key like '8a1126c0-aedf-103a-9bca-ff269e4955f9';
8a1126c0-aedf-103a-9bca-ff269e4955f9|224443b3-cb29-4028-a664-7518c949614f
There is an entry in the UCS deleted table, which is not present in samba4 anymore:
univention-s4search --cross-ncs --show-deleted objectGUID=224443b3-cb29-4028-a664-7518c949614f
Nothing found.
Solution:
What happened her is, that the s4-connector looks in the UCS deleted table for deleted objects to restore, and found an entry, which is no longer present, and ignores completely that there is a propper mapping and object in samba4.
So we have to remove the database entry to get the reject resolve. The connector does not find a suitable entry anymore and synchronizes the object.
Delete the outdated entry:
sqlite> delete from 'UCS deleted' where key='8a1126c0-aedf-103a-9bca-ff269e4955f9'
see also Bug 59113
The script attached to the Bug might come handy to analyse the state of the UCS deleted database table of the s4-connector