Univention Bugzilla – Bug 31083
rename operation failed during sync from ucs: [windowscomputer]
Last modified: 2016-03-22 19:29:51 CET
The following S4-Connector reject was found in a customer environment: ================================================================ 1: UCS DN: cn=machine1,cn=computers,ou=school1,$ldap_base S4 DN: cn=machine2,cn=computers,ou=school1,$ldap_base Filename: /var/lib/univention-connector/s4/1365249382.121660 ================================================================ The traceback indicates that the rename failed: "Modify of RDN 'cn' on cn=machine2,cn=computers,ou=school1,$ldap_base not permitted, must use 'rename' operation instead"
Created attachment 5176 [details] traceback at loglevel 4
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2. As such, this bug is moved to the new target milestone.
This NOT_ALLOWED_ON_RDN connector traceback was found again on Ticket#: 2013111421008025 in var_log_univention_connector-s4.log_1, contained in the USI archive.
Reported again 2014081921000608 UCS 3.2-2 e153; UCS@school 3.2 R2v1
MS KB suggests that it is not possible to rename a client "server side" in AD. One has to use the netdom renamecomputer command (which actually connects to the client and triggers the name change there): http://support.microsoft.com/kb/298593/en-us http://support.microsoft.com/kb/325354/en-us We should disable renaming of windows computers in Samba 4 domains.
Customer reported that it is possible to rename Clients (joined clients at least) in Windows 2012 AD Domains. I tested with Windows 2008 R2 AD where it was not possible to rename a client via MMC (even if it is joined).
We are just using Unix/Mac-systems and as soon as we rename a system in umc our sync.log is flooded with: -- 24.11.2014 09:45:51,365 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1415887491.361366 24.11.2014 09:45:51,389 LDAP (PROCESS): sync from ucs: [windowscomputer] [ modify] cn=virt16,cn=computers,dc=ad,dc=in,dc=x,dc=de 24.11.2014 09:45:51,391 LDAP (ERROR ): sync_from_ucs: traceback during modify object: cn=virt16,cn=computers,dc=ad,dc=in,dc=x,dc=de 24.11.2014 09:45:51,392 LDAP (ERROR ): sync_from_ucs: traceback due to modlist: [(2, u'cn', [u'virt16', u'virt2'])] 24.11.2014 09:45:51,393 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1415887491.361366 24.11.2014 09:45:51,393 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 752, in __sync_file_from_ucs if ((old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, unicode(old_dn,'utf8'), old)) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2435, 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.6/dist-packages/ldap/ldapobject.py", line 808, in modify_ext_s return self._apply_method_s(SimpleLDAPObject.modify_ext_s,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 766, in _apply_method_s return func(self,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 295, in modify_ext_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) NOT_ALLOWED_ON_RDN: {'info': "00002016: Modify of RDN 'cn' on cn=virt16,cn=computers,dc=ad,dc=in,dc=x,dc=de not permitted, must use 'rename' operation instead", 'desc': 'Operation not allowed on RDN'} -- So, please disable the rename-operation in umc until this is working as expected.
I found no way to rename the client via the ad tools/server side (w2k8r2, w2k12), only on the client renaming was possible. So to disallow renaming windows/mac computer objects in UDM may be a good idea. Difference between renaming in AD and Samba: During rename of a computer in AD, all attributes of the computer object are modified (dn, cn, name, displaName, sAMAccountname, ...). But in Samba dn, cn, and name are not modified! Problems S4 Connector: (1) The Connector does not sync sAMAccountname. UDM implicitly sets the OpenLDAP equivalent "uid" if the name (cn in Samba) attribute is changed. But Samba does not change the cn attribute during the rename, name and therefore uid is not updated by the connector. -> uid, displayName differ between OpenLDAP and Samba after renaming a computer (2) If we set name.may_change=0 in the computer UDM handler we may get problems if samba decides to update the cn during the rename of a computer object (as AD does).
We will disable the modification of the computer name in UMC/UDM.
(In reply to Felix Botner from comment #9) > We will disable the modification of the computer name in UMC/UDM. Hmm, this breaks the ad connector if we disbale changing the name (cn) renaming windows clients in a AD connector setup fails (AD rejected) (ERROR ): Value may not change: key=name old=WIN7EN new=WIN7EN7 (cn=WIN7EN7,cn=computers,dc=w2k8r2en,dc=test) => AD changes cn during rename of the windows client -> connectors wants to set name, which is disabled -> reject => S4 does not change cn during rename We can not simply disable renaming windows (mac) clients in UDM, the connectors (at least AD) needs to modify this attribute (1) Maybe we introduce a new property attribute "may_change_umc" (default 1). If this is set to 0, changing this attribute via UMC is disabled (UDM, Connector still works). (2) Or we have to fix the original connector problem, caused by the rename of the windows client in UDM (the connector does not register the rename of the windows object, but then wants to change the rdn attribute rdn attribute cn => NOT_ALLOWED_ON_RDN). But if we do that, what happens with joined windows clients, which are renamed via UDM. How they know their new name? And also, this operation (renaming clients server side) is apparently not allowed in AD, so it is maybe a good idea not to allow this in UDM as well. So i prefer (1).
Problem is that the rename comes in two steps (rename [dn, cn], and modify[uid]). So after renaming a computer (from win10 to 10win) the listener pickel file looks like: dn = "cn=10win,dc=fb,dc=intranet" new = { 'cn': ['10win'], 'uid': ['win10$'], ... old_dn = "cn=win10,dc=fb,dc=intranet" old = {} Notice that uid is not yet changed. The connector then maps the objects in s4 and ucs _object_mapping -> windowscomputer_dn_mapping -> samaccountname_dn_mapping But samaccountname_dn_mapping always looks for samaccountname=ucsattrib in S4, but ucsattrib is "uid", and "uid" is still the old value -> samaccountname_dn_mapping finds an object (win10$) and the connector does not execute a rename. Proposal: * look for samaccountname=ucsattrib in samaccountname_dn_mapping AND dn_attr=dn_attr_val * dn_attr for windowscomputer_dn_mapping is "cn" (which is changed when renaming the object in UCS) * dn_attr_val is the actual cn in UCS * this new filter (only used if dn_attr is set, which is the case only for windowscomputer_dn_mapping, not group_dn_mapping ...) does not find the object in S4 after rename in UCS and the connector triggers the ldap.rename
Created attachment 6909 [details] respect dn_attr and dn_attr_val in samaccountname_dn_mapping when looking for S4 object
univention-s4-connector (8.0.33-90) - also look for dn_attr=dn_attr_val in samaccountname_dn_mapping() to detect modrdn my tests: * ucs-test (s4) * renaming windows host via UMC * reaming joined windows host via windows host Added test 402rename_computer_object to 52_s4connector. YAML - 2015-06-01-univention-s4-connector.yaml
Code review: OK (r60949) YAML: OK (I've limited the upgrade to 3.2-6errata) ucs-test: OK Tests: OK (I was able to reproduce it with the old version but not with the fixed version) Felix, feel free to merge it to 4.0-2errata: Bug #37709.
<http://errata.univention.de/ucs/3.2/346.html>