Univention Bugzilla – Bug 53530
AD rejects User with "Error in attribute conversion operation" in traceback, if User have TelexNumber as Attribute
Last modified: 2021-06-30 11:13:09 CEST
The AD-connector throws rejects and shows "Error in attribute conversion operation" in traceback, while trying to sync users with the telexNumber Attribute: 16.05.2021 06:26:11.449 MAIN (------ ): DEBUG_INIT 16.05.2021 06:26:11.479 LDAP (PROCESS): Building internal group membership cache 16.05.2021 06:26:12.040 LDAP (PROCESS): Internal group membership cache was created 16.05.2021 06:26:12.041 LDAP (PROCESS): Using ADMCE as AD Netbios domain name 16.05.2021 06:26:12.202 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/ad/1618386814.821459 16.05.2021 06:26:12.210 LDAP (PROCESS): sync from ucs: [ user] [ add] cn=sieh,ou=people,ou=eim,DC=ad,DC=ank,DC=eu 16.05.2021 06:26:12.217 LDAP (ERROR ): sync_from_ucs: traceback during modify object: cn=seh,ou=people,ou=eim,DC=ad,DC=ank,DC=eu 16.05.2021 06:26:12.218 LDAP (ERROR ): sync_from_ucs: traceback due to modlist: [(2, 'title', set([u'XXX'])), (2, 'streetAddress', set([u'Schefersten 5'])), (2, 'postalCode', set([u'66639'])), (2, 'mail', set([u'tian.hoelz@sys.xx'])), (2, 'display 16.05.2021 06:26:12.276 LDAP (WARNING): sync failed, saved as rejected 16.05.2021 06:26:12.283 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/univention/connector/__init__.py", line 820, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, object_old))): File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 2826, in sync_from_ucs self.lo_ad.lo.modify_s(compatible_modstring(object['dn']), compatible_modlist(modlist)) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 402, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 503, in result resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 507, in result2 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 514, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 521, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) CONSTRAINT_VIOLATION: {'info': '00000057: LdapErr: DSID-0C090FEC, comment: Error in attribute conversion operation, data 0, v4563', 'desc': 'Constraint violation'} Adding the user with ldapmodify: "eval $(ucr shell" "ldapmodify -x -D $connector_ad_ldap_binddn -w $(cat $connector_ad_ldap_bindpw) -h $connector_ad_ldap_host -f "telexNumber.ldif " works. Examing the tcpdump connection from the AD-connector to AD shows a 0 Value in the AD LDAP modifyrequest. (Screenshot available but not diclosed for privacy reasons) - modification telexNumber type: telexNumber vals: 0 items As the AD consider the Attribute telexNumber as binary and the AD don´t seems to accept it, we removed it with a patch on the customer system and the sync went back to work. root@ad-connector:~/univention-support-2021-06-28# diff -Nur /usr/lib/python2.7/dist-packages /univention/connector/ad/__init__.py.orig /usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py --- /usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py.orig 2021-06-28 15:30:03.378660713 +0200 +++ /usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py 2021-06-28 15:30:10.082120011 +0200 @@ -139,7 +139,7 @@ 'serviceClassID', 'serviceClassInfo', 'serviceInstanceVersion', 'sIDHistory', 'siteGUID', 'supplementalCredentials', 'supportedApplicationContext', 'syncWithSID', 'teletexTerminalIdentifier', - 'telexNumber', 'terminalServer', 'thumbnailLogo', + 'terminalServer', 'thumbnailLogo', 'thumbnailPhoto', 'tokenGroups', 'tokenGroupsGlobalAndUniversal', 'tokenGroupsNoGCAcceptable', 'trustAuthIncoming', 'trustAuthOutgoing', 'unicodePwd', 'unixUserPassword', 'upgradeProductCode', According to the customer, it worked before, there are actually users from LDAP in AD that were synchronized including a telex number. We can't find any clue to understand when and why this process stopped working.