Univention Bugzilla – Bug 49860
After the windows AD is replaced, providing all changes and objects causes some similar rejects
Last modified: 2019-07-19 06:58:26 CEST
It seems, that if a user or an computer account was renamed long time ago, the resync of all Objects to UCS, manually pushed by setting lastUSN to 1, triggered now a reject. The Reject itself: 16.07.2019 16:05:11.206 LDAP (ERROR ): Unknown Exception during sync_to_ucs 16.07.2019 16:05:11.207 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1311, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.7/univention/connector/ad/password.py", line 321, in password_sync_kinit ucs_result = connector.lo.search(base=ucs_object['dn'], attr=attr.keys()) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 752, in search raise univention.admin.uexceptions.noObject(_err2str(msg)) noObject: No such object ------------------------------------------ With more debug (4) 16.07.2019 16:05:11.207 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=LAPTOP-chris,OU=Computer,OU=Service,DC=schein,DC=de 16.07.2019 16:05:11.207 LDAP (INFO ): Search AD with filter: (|(uSNChanged=19702184)(uSNCreated=19702184)) 16.07.2019 16:05:11.209 LDAP (INFO ): encode_ad_object: attrib objectGUID ignored during encoding 16.07.2019 16:05:11.210 LDAP (INFO ): object_from_element: olddn: CN=LENOVO-RESERVE2,CN=Computers,DC=schein,DC=de 16.07.2019 16:05:11.210 LDAP (INFO ): _object_mapping: map with key windowscomputer and type con 16.07.2019 16:05:11.210 LDAP (INFO ): _dn_type con 16.07.2019 16:05:11.211 LDAP (INFO ): _dn_type con 16.07.2019 16:05:11.211 LDAP (INFO ): samaccount_dn_mapping: check newdn for key dn: 16.07.2019 16:05:11.211 LDAP (INFO ): samaccount_dn_mapping: premapped UCS object not found 16.07.2019 16:05:11.211 LDAP (INFO ): samaccount_dn_mapping: got an AD-Object 16.07.2019 16:05:11.212 LDAP (INFO ): samaccount_dn_mapping: samaccountname is:LAPTOP-chris$ 16.07.2019 16:05:11.212 LDAP (INFO ): samaccount_dn_mapping: newdn for key dn: 16.07.2019 16:05:11.212 LDAP (INFO ): samaccount_dn_mapping: olddn: cn=laptop-cbi2019,ou=computer,ou=service,dc=schein,dc=de 16.07.2019 16:05:11.212 LDAP (INFO ): samaccount_dn_mapping: newdn: cn=LAPTOP-chris,ou=computer,ou=service,dc=schein,dc=de 16.07.2019 16:05:11.212 LDAP (INFO ): samaccount_dn_mapping: check newdn for key olddn: 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: premapped UCS object not found 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: got an AD-Object 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: samaccountname is:LAPTOP-chris$ 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: newdn is ucsdn 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: newdn for key olddn: 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: olddn: cn=lenovo-reserve2,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.213 LDAP (INFO ): samaccount_dn_mapping: newdn: cn=LAPTOP-chris,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.214 LDAP (INFO ): _ignore_object: Do not ignore cn=LAPTOP-chris,ou=computer,ou=service,dc=schein,dc=de (key: windowscomputer) 16.07.2019 16:05:11.214 LDAP (INFO ): _ignore_object: Do not ignore CN=LAPTOP-chris,OU=Computer,OU=Service,DC=schein,DC=de (key: windowscomputer) 16.07.2019 16:05:11.215 LDAP (INFO ): _ignore_object: Do not ignore cn=LAPTOP-chris,cn=computers,dc=schein,dc=de (key: windowscomputer) 16.07.2019 16:05:11.216 LDAP (INFO ): get_ucs_object: object found: cn=LAPTOP-chris,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.216 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=LAPTOP-chris,ou=computer,ou=service,dc=schein,dc=de 16.07.2019 16:05:11.216 LDAP (INFO ): sync_to_ucs: set position to ou=computer,ou=service,dc=schein,dc=de 16.07.2019 16:05:11.216 LDAP (INFO ): sync_to_ucs: using existing target object type: computers/windows 16.07.2019 16:05:11.217 LDAP (INFO ): __set_values: set attribute, ucs_key: operatingSystem - value: [u'Windows 10 Pro'] 16.07.2019 16:05:11.217 LDAP (INFO ): __set_values: set attribute, ucs_key: operatingSystemVersion - value: [u'10.0 (17763)'] 16.07.2019 16:05:11.217 LDAP (INFO ): __set_values: no ldap_attribute defined in <univention.connector.attribute instance at 0x7f7224009dd0>, we unset the key description in the ucs-object 16.07.2019 16:05:11.218 LDAP (INFO ): __set_values: set attribute, ucs_key: name - value: [u'LAPTOP-chris'] 16.07.2019 16:05:11.218 LDAP (INFO ): Call post_ucs_modify_functions: <function set_univentionObjectFlag_to_synced at 0x7f72240a0488> 16.07.2019 16:05:11.218 LDAP (INFO ): _object_mapping: map with key windowscomputer and type ucs 16.07.2019 16:05:11.218 LDAP (INFO ): _dn_type ucs 16.07.2019 16:05:11.219 LDAP (INFO ): _dn_type ucs 16.07.2019 16:05:11.219 LDAP (INFO ): samaccount_dn_mapping: check newdn for key dn: 16.07.2019 16:05:11.220 LDAP (INFO ): get_object: got object: cn=laptop-cbi2019,ou=computer,ou=service,DC=schein,DC=de 16.07.2019 16:05:11.221 LDAP (INFO ): encode_ad_object: attrib objectGUID ignored during encoding 16.07.2019 16:05:11.221 LDAP (INFO ): samaccount_dn_mapping: premapped AD object found 16.07.2019 16:05:11.221 LDAP (INFO ): samaccount_dn_mapping: check newdn for key olddn: 16.07.2019 16:05:11.221 LDAP (INFO ): samaccount_dn_mapping: not premapped (in first instance) 16.07.2019 16:05:11.221 LDAP (INFO ): samaccount_dn_mapping: got an UCS-Object 16.07.2019 16:05:11.221 LDAP (INFO ): samaccount_dn_mapping: search in ad samaccountname=LAPTOP-chris 16.07.2019 16:05:11.222 LDAP (INFO ): samaccount_dn_mapping: newdn: cn=LAPTOP-chris,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.222 LDAP (INFO ): samaccount_dn_mapping: newdn for key olddn: 16.07.2019 16:05:11.222 LDAP (INFO ): samaccount_dn_mapping: olddn: cn=LAPTOP-chris,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.222 LDAP (INFO ): samaccount_dn_mapping: newdn: cn=LAPTOP-chris,cn=computers,dc=schein,dc=de 16.07.2019 16:05:11.223 LDAP (ERROR ): Unknown Exception during sync_to_ucs 16.07.2019 16:05:11.223 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1311, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 167, in set_univentionObjectFlag_to_synced ucs_result = connector.lo.search(base=ucs_object['dn'], attr=['univentionObjectFlag']) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 752, in search raise univention.admin.uexceptions.noObject(_err2str(msg)) noObject: No such object ------------------------------------------------------ In sqlite you still find the old object mapped to the GUID sqlite3 /etc/univention/connector/internal.sqlite "select * from 'AD GUID' where value = 'CN=LENOVO-RESERVE2,CN=Computers,DC=schein,DC=de';" tmQofs0JxEOYv5TGWr+iig== |CN=LENOVO-RESERVE2,CN=Computers,DC=schein,DC=de ----------------------------------------------------- Deleting this entry, the connector is able to resync/match the new object and the reject is solved.
Is it reproducible with UCS 4.3 or 4.4? When was the object renamed? My guess is that the missing update of the table was a bug in an earlier UCS version. Why is the problem blocking the customer? Question: "How will those affected feel about the bug?"
(In reply to Stefan Gohmann from comment #1) > Is it reproducible with UCS 4.3 or 4.4? > Both customers have UCS 4.4 in use > When was the object renamed? > I don't know. It seems in one of my conversation with the customer, that he cannot recall the renaming. > My guess is that the missing update of the table was a bug in an earlier UCS > version. > This might be the case, but we should address this issue now, if possible, so the customer do not get the rejects. > Why is the problem blocking the customer? Question: "How will those affected > feel about the bug?" > Both customers did not see, if the resync was already successful/finished, because for the customer the process seems to stuck, looking in the logfile and getting all these rejects. Also the highestCommitedUSN and the lastUSN where not equal, so the customer did not know, if everything was synced. Finally, one customer have the nagios checks activated and they get repeatedly a message that they have rejects
(In reply to Christina Scheinig from comment #2) > (In reply to Stefan Gohmann from comment #1) > > Is it reproducible with UCS 4.3 or 4.4? > > > > Both customers have UCS 4.4 in use > > > When was the object renamed? > > > I don't know. It seems in one of my conversation with the customer, that he > cannot recall the renaming. > > > My guess is that the missing update of the table was a bug in an earlier UCS > > version. > > > This might be the case, but we should address this issue now, if possible, > so the customer do not get the rejects. The reject is correct and shows a problem with the internal data. That is nothing the connector should try to fix automatically. For me it is important to know if the problem still occurs with UCS 4.3 or UCS 4.4. In this case it is critical. Otherwise an article how to solve this issue is sufficient since we have already fixed the root cause. @Arvid, can Fathan check this? > > Why is the problem blocking the customer? Question: "How will those affected > > feel about the bug?" > > > Both customers did not see, if the resync was already successful/finished, > because for the customer the process seems to stuck, looking in the logfile > and getting all these rejects. > Also the highestCommitedUSN and the lastUSN where not equal, so the customer > did not know, if everything was synced. > > Finally, one customer have the nagios checks activated and they get > repeatedly a message that they have rejects "Blocking further progress on the daily work" means that the customer / user is unable to work. As far as I understand that is not the case here. So, I'll reduce it.