Bug 31083 - rename operation failed during sync from ucs: [windowscomputer]
rename operation failed during sync from ucs: [windowscomputer]
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 3.1
Other Linux
: P5 normal (vote)
: UCS 3.2-6-errata
Assigned To: Felix Botner
Stefan Gohmann
Depends on:
Blocks: 37709
  Show dependency treegraph
Reported: 2013-04-17 17:21 CEST by Arvid Requate
Modified: 2016-03-22 19:29 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

traceback at loglevel 4 (6.55 KB, text/plain)
2013-04-17 17:22 CEST, Arvid Requate
respect dn_attr and dn_attr_val in samaccountname_dn_mapping when looking for S4 object (1.28 KB, patch)
2015-05-18 17:35 CEST, Felix Botner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2013-04-17 17:21:27 CEST
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"
Comment 1 Arvid Requate univentionstaff 2013-04-17 17:22:14 CEST
Created attachment 5176 [details]
traceback at loglevel 4
Comment 2 Moritz Muehlenhoff univentionstaff 2013-05-31 10:45:42 CEST
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.
Comment 3 Arvid Requate univentionstaff 2013-11-27 13:23:19 CET
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.
Comment 4 Janis Meybohm univentionstaff 2014-08-20 09:05:47 CEST
Reported again 2014081921000608
UCS 3.2-2 e153; UCS@school 3.2 R2v1
Comment 5 Janis Meybohm univentionstaff 2014-08-20 09:31:24 CEST
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):

We should disable renaming of windows computers in Samba 4 domains.
Comment 6 Janis Meybohm univentionstaff 2014-08-20 10:15:19 CEST
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).
Comment 7 Fabian Zimmermann 2014-11-24 09:53:30 CET
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
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.
Comment 8 Felix Botner univentionstaff 2014-12-12 14:40:01 CET
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:

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

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).
Comment 9 Felix Botner univentionstaff 2014-12-18 11:11:21 CET
We will disable the modification of the computer name in UMC/UDM.
Comment 10 Felix Botner univentionstaff 2015-02-06 12:01:14 CET
(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

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).

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).
Comment 11 Felix Botner univentionstaff 2015-05-18 17:33:51 CEST
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 
    -> 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.

 * look for samaccountname=ucsattrib in samaccountname_dn_mapping AND
 * 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
Comment 12 Felix Botner univentionstaff 2015-05-18 17:35:39 CEST
Created attachment 6909 [details]
respect dn_attr and dn_attr_val in samaccountname_dn_mapping when looking for S4 object
Comment 13 Felix Botner univentionstaff 2015-06-01 12:10:20 CEST
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
Comment 14 Stefan Gohmann univentionstaff 2015-07-18 23:16:26 CEST
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.
Comment 15 Janek Walkenhorst univentionstaff 2015-07-28 15:02:13 CEST