Univention Bugzilla – Bug 53102
Creating users that are named like containers should be prevented
Last modified: 2022-05-12 11:05:44 CEST
root@srv-ucsm01:~# univention-app info UCS: 4.4-7 errata873 Installed: letsencrypt=1.2.2-8 pkgdb=11.0 prometheus-node-exporter=1.1 samba4=4.10 ucsschool=4.4 v8 Upgradable: letsencrypt ucsschool Scenario: A member of "Domain Admins" created a user named "lehrer" in the container "cn=users,ou=schule11,dc=schule-musterstadt,dc=de". Observed behaviour: UCS created the user object just fine in OpenLDAP: uid=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de However, there is also a container at the same level of the LDAP tree called: cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de Things start to get messy, when Samba AD and the S4-Connector are involved. In AD, user object DNs don't start with "uid=" but with "cn=". So, the user object in AD would be: CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de And now we have the same DN for the user object and the container object. At first, this will create a S4-Connector-Reject, because the S4-Connector can't add user attributes like objectSid to a container object. However, when we delete the user "lehrer", the S4-Connector will delete "CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de", which is the container, with all its subordinate objects(!), e.g. all teacher accounts of that school. To prevent this, I think it should not be possible to create users with the same name as existing containers (at least on the same level of the LDAP tree).
This is the S4-Connector trying to add the object, but failing because of object class violation: 24.03.2021 11:32:35.355 LDAP (PROCESS): sync from ucs: [ user] [ add] cn=lehrer,cn=users,ou=schule11,DC=schule-musterstadt,DC=de 24.03.2021 11:32:35.356 LDAP (PROCESS): Calling value mapping function for attribute sid 24.03.2021 11:32:35.358 LDAP (ERROR ): sync_from_ucs: traceback during modify object: cn=lehrer,cn=users,ou=schule11,DC=schule-musterstadt,DC=de 24.03.2021 11:32:35.358 LDAP (ERROR ): sync_from_ucs: traceback due to modlist: [(2, 'displayName', [u'lehrer lehrer']), (2, 'objectSid', ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00\xe7\x15\xc4r\xad\xb6\xcf-\xf2T\x02\x12\xec\x15\x00\x00']), (2, 'sn', [u'lehrer']), (2, 'givenName', [u'lehrer']), (2, 'sAMAccountName', [u'lehrer']), (2, 'uidNumber', [u'2306']), (2, 'personalTitle', [u'herr']), (2, 'loginShell', [u'/bin/bash']), (2, 'gidNumber', [u'5001']), (2, 'unixHomeDirectory', [u'/home/lehrer'])] 24.03.2021 11:32:35.369 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1616581951.530065 24.03.2021 11:32:35.369 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 891, in __sync_file_from_ucs if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new))): File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2622, in sync_from_ucs self.lo_s4.lo.modify_ext_s(compatible_modstring(object['dn']), compatible_modlist(modlist), serverctrls=self.serverctrls_for_add_and_modify) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 374, in modify_ext_s resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.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) OBJECT_CLASS_VIOLATION: {'info': "00002014: objectclass_attrs: attribute 'objectSid' on entry 'CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de' does not exist in the specified objectclasses!", 'desc': 'Object class violation'}
This is the S4-Connector deleting the "user", but really deleting the whole container with all subordinate objects in it: 25.03.2021 10:10:56.237 LDAP (PROCESS): sync from ucs: [ user] [ delete] cn=lehrer,cn=users,ou=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.273 LDAP (WARNING): delete subobject: u'uid=rli,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.274 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=rli,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.303 LDAP (WARNING): delete subobject: u'uid=nbo,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.303 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=nbo,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.320 LDAP (WARNING): delete subobject: u'uid=nho,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.320 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=nho,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.337 LDAP (WARNING): delete subobject: u'uid=ede,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.337 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=ede,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.353 LDAP (WARNING): delete subobject: u'uid=hst,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.353 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=hst,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.368 LDAP (WARNING): delete subobject: u'uid=mwi,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.369 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=mwi,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.388 LDAP (WARNING): delete subobject: u'uid=doe,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.389 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=doe,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.408 LDAP (WARNING): delete subobject: u'uid=igo,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' 25.03.2021 10:10:56.409 LDAP (PROCESS): sync from ucs: [ user] [ delete] CN=igo,CN=lehrer,CN=users,OU=schule11,DC=schule-musterstadt,DC=de 25.03.2021 10:10:56.428 LDAP (WARNING): delete subobject: u'uid=tst,cn=lehrer,cn=users,ou=schule11,dc=schule-musterstadt,dc=de' [...]
Happend again in a big school environment. Fortunately it was just a small school. UCS: 4.4-7 errata966 Installed: nagios=4.3 pkgdb=11.0 samba4=4.10 self-service=4.0 self-service-backend=4.0 ucsschool=4.4 v9 zuludesk=1.0-1 The stuff member did exactly the same, as already described by Michael. I could reproduce this, if I use the normal users module. We had to manually restore the deleted users from ldap backup
@Dirk: I created a patch which makes your test case (61_udm-users/55_users_unique_name_in_container.py) pass. git:fbest/53102-uid-cn-position-conflict (https://git.knut.univention.de/univention/ucs/-/commit/f080ebd483397a9d416fc5588a4cd4608ad03b9d)
The uniqueness for objects with uid/cn/ou in the same subtree position is now checked. Especially for renaming objects this was tricky: users/user, users/ldap, container/cn and container/ou are doing a manual self.move() if they detect that the DN-identifying property changed. All other objects like groups/group, etc. rely on the logic in univention.uldap.access.modify() which does a self.rename() in case it detects a renamed. Therefore a new interface _ldap_pre_rename(new_dn), _ldap_post_rename(old_dn) has been added to UDM. The test case was extended. Important is also to check the uniqueness only applies for the attribute in the DN. A users/user object e.g. has both: uid and cn. But a user uid=foo with cn=bar should not prevent creating a group/container/whatever with cn=bar. The test case also has been adapted for this behavior. univention-python.yaml 98266a82ac94 | YAML Bug #53102 univention-python (13.0.2-4) b8db883e08bd | Bug #53102: introduce _ldap_pre_rename(newdn) and _ldap_post_rename(olddn) univention-directory-manager-modules.yaml 98266a82ac94 | YAML Bug #53102 univention-directory-manager-modules (15.0.11-3) 616644f28864 | Bug #53102: make sure uniqueness applies only for DN part 467e5cc9e39c | Bug #53102: simplify renaming by using new _ldap_pre_rename() method 31086ad1e098 | Bug #53102: users/user: cleanup move() logic 1a9a979f9db4 | Bug #53102: ensure uniqueness of object names in the same subtree position univention-directory-manager-modules (15.0.11-2) b8db883e08bd | Bug #53102: introduce _ldap_pre_rename(newdn) and _ldap_post_rename(olddn) 201a3e884976 | Bug #53102: always call super() methods ucs-test (10.0.6-1) 616644f28864 | Bug #53102: make sure uniqueness applies only for DN part 1a9a979f9db4 | Bug #53102: ensure uniqueness of object names in the same subtree position
Code review: Looks good Manual Tests: OK Auto Tests: OK YAML: OK
<https://errata.software-univention.de/#/?erratum=5.0x61> <https://errata.software-univention.de/#/?erratum=5.0x64>