Univention Bugzilla – Bug 45416
hardcoded wrong object type "user" for computers during password sync to UCS
Last modified: 2019-08-08 12:19:09 CEST
During the sync of a computer object to UCS (when joining a windows client) the log contains a misleading error message: 18.09.2017 23:01:13,155 LDAP (ERROR ): get_ucs_object: could not identify UDM object type: cn=WIN7PRO,CN=Computers,dc=four,dc=two 18.09.2017 23:01:13,155 LDAP (PROCESS): get_ucs_object: using default: users/user 18.09.2017 22:32:29,822 MAIN (------ ): DEBUG_INIT 18.09.2017 22:32:29,855 LDAP (PROCESS): Building internal group membership cache 18.09.2017 22:32:29,861 LDAP (PROCESS): Internal group membership cache was created 18.09.2017 23:01:12,110 LDAP (PROCESS): sync to ucs: [windowscomputer] [ add] cn=WIN7PRO,CN=Computers,dc=four,dc=two 18.09.2017 23:01:13,155 LDAP (ERROR ): get_ucs_object: could not identify UDM object type: cn=WIN7PRO,CN=Computers,dc=four,dc=two 18.09.2017 23:01:13,155 LDAP (PROCESS): get_ucs_object: using default: users/user 18.09.2017 23:01:14,669 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,dc=four,dc=two 18.09.2017 23:01:20,804 LDAP (PROCESS): sync from ucs: [windowscomputer] [ add] cn=win7pro,cn=computers,DC=four,DC=two 18.09.2017 23:01:20,858 LDAP (PROCESS): sync from ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,DC=four,DC=two 18.09.2017 23:01:20,889 LDAP (PROCESS): sync from ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,DC=four,DC=two 18.09.2017 23:01:21,926 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,dc=four,dc=two 18.09.2017 23:02:03,275 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,dc=four,dc=two After debugging this one sees the stacktrace of the error message: /usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py(296)<module>() -> main() /usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py(279)main() -> connect() /usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py(225)connect() -> change_counter = s4.poll() /usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py(2329)poll() -> sync_successfull = self.sync_to_ucs(property_key, mapped_object, object['dn'], object) /usr/lib/pymodules/python2.7/univention/s4connector/__init__.py(1581)sync_to_ucs() -> f(self, property_type, object) /usr/lib/pymodules/python2.7/univention/s4connector/s4/password.py(831)password_sync_s4_to_ucs_no_userpassword() -> password_sync_s4_to_ucs(s4connector, key, ucs_object, modifyUserPassword=False) /usr/lib/pymodules/python2.7/univention/s4connector/s4/password.py(783)password_sync_s4_to_ucs() -> userobject = s4connector.get_ucs_object('user', ucs_object['dn']) > /usr/lib/pymodules/python2.7/univention/s4connector/__init__.py(963)get_ucs_object() -> ud.debug(ud.LDAP, ud.ERROR, "get_ucs_object: could not identify UDM object type: %s" % searchdn) In univention/s4connector/s4/password.py there is a function call with hardcoded "user" while the object is a computer: s4connector.get_ucs_object('user', ucs_object['dn']). mapping.py contains in 'windowscomputer' the post_ucs_modify_functions "univention.s4connector.s4.password.password_sync_s4_to_ucs_no_userpassword". Patch is the following: diff --git a/services/univention-s4-connector/modules/univention/s4connector/s4/password.py b/services/univention-s4-connector/modules/univention/s4connector/s4/password.py index 8a98031..9891dc3 100644 --- a/services/univention-s4-connector/modules/univention/s4connector/s4/password.py +++ b/services/univention-s4-connector/modules/univention/s4connector/s4/password.py @@ -783 +783 @@ def password_sync_s4_to_ucs(s4connector, key, ucs_object, modifyUserPassword=Tru -» » » » userobject = s4connector.get_ucs_object('user', ucs_object['dn']) +» » » » userobject = s4connector.get_ucs_object(key, ucs_object['dn'])
I commited the patch in the branch fbest/45416-wrong-object-type-password-sync.
18.09.2017 23:49:59,308 LDAP (ERROR ): password_sync_s4_to_ucs: couldn't get user-object from UCS
*** This bug has been marked as a duplicate of bug 49649 ***