Univention Bugzilla – Bug 48362
Synchronization fails after move in UCS if ldap/base and samba4/ldap/base are different
Last modified: 2019-03-30 07:54:21 CET
============================================================ 04.12.2018 14:23:52,722 LDAP (PROCESS): sync from ucs: [ user] [ modify] CN=test.user,cn=users,dc=my-domain,dc=tlDC=cw,DC=my-domain,DC=tld 04.12.2018 14:23:52,746 LDAP (ERROR ): sync_from_ucs: traceback during add object: CN=test.user,cn=users,dc=my-domain,dc=tlDC=cw,DC=my-domain,DC=tld 04.12.2018 14:23:52,746 LDAP (ERROR ): sync_from_ucs: traceback due to addlist: [('objectClass', ['top', 'user', 'person', 'organizationalPerson']), ('sAMAccountName', [u'test.user']), (u'displayName', [u'Test Jan']), (u'sn', [u'Jan']), (u'givenName', [u'Test'])] 04.12.2018 14:23:52,755 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1543929830.378022 04.12.2018 14:23:52,755 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 909, 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/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2555, in sync_from_ucs self.lo_s4.lo.add_ext_s(compatible_modstring(object['dn']), compatible_addlist(addlist), serverctrls=ctrls) # FIXME encoding File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 195, in add_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) INVALID_DN_SYNTAX: {'info': "00002032: ldb_add: invalid dn '(null)'", 'desc': 'Invalid DN syntax'} 04.12.2018 14:23:52,759 LDAP (PROCESS): sync from ucs: [ user] [ modify] CN=test.user,CN=Users,DC=cw,DC=my-domain,DC=tld ============================================================ Besonderheit: OpenLDAP Base-DN und S4 Base-DN sind unterschiedlich konfiguriert: S4: DC=cw,DC=my-domain,DC=tld LDAP: dc=my-domain,dc=tld
Looking at the join script univention-samba4/96univention-samba4.inst I see a function set_samba4_ldap_base which derives the samba4/ldap/base from kerberos/realm. The setup-s4.sh script which calls samba-tool domain provision also passes kerberos/realm, so I guess that's how you can change the default. Anyway, the connector-s4.log shows the point where the DN get's messed up: ========================================================================== 13.12.2018 13:23:35,140 LDAP (INFO ): samaccount_dn_mapping: check newdn for key dn: uid=test.user,cn=users,dc=my-domain,dc=com 13.12.2018 13:23:35,140 LDAP (INFO ): samaccount_dn_mapping: not premapped (in first instance) 13.12.2018 13:23:35,140 LDAP (INFO ): samaccount_dn_mapping: got an UCS-Object 13.12.2018 13:23:35,140 LDAP (INFO ): samaccount_dn_mapping: search in s4 for (&(objectclass=user)(samaccountname=test.user)) 13.12.2018 13:23:35,141 LDAP (INFO ): samaccount_dn_mapping: newdn: CN=test.user,cn=users,dc=my-domain,dc=codc=my-domain,dc=com 13.12.2018 13:23:35,141 LDAP (INFO ): samaccount_dn_mapping: newdn for key dn: 13.12.2018 13:23:35,141 LDAP (INFO ): samaccount_dn_mapping: olddn: uid=test.user,cn=users,dc=my-domain,dc=com 13.12.2018 13:23:35,141 LDAP (INFO ): samaccount_dn_mapping: newdn: CN=test.user,cn=users,dc=my-domain,dc=codc=my-domain,dc=com 13.12.2018 13:23:35,141 LDAP (INFO ): samaccount_dn_mapping: check newdn for key olddn: cn=test.user,cn=users,DC=cw,DC=my-domain,DC=com ========================================================================== Looks like the rfind call in samaccount_dn_mapping returns a -1 in this case. Before the adjustment for Bug #46741 the rfind was a string replace, and that probably never did anything (wrong). Tracing back the history of that code line left me in the dark (2007 import from CVS). I always treated that line as "better don't touch" whenever I worked on that function, because it always felt like it did something useless -- but it didn't break anything. I'll attach a patch that may restore the "doesn't break anything" behavior. We should carefully consider removing those few lines of code. I'll have to chat with Felix to hear if he can see a point why we should keep them.
Created attachment 9780 [details] here_be_dragons.diff
Created attachment 9781 [details] proposal.diff After reading the code, I guess this would be the right way to do it? Please don't hand this patch over into a productive environment unless it is properly understood and tested.
This error was triggerd by a move in UCS, not a password change.
We can not simply return the S4 DN in samaccountname_dn_mapping for moves, sync_from_ucs depends on that UCS DN, see Bug #48438 for more info. So return the S4 DN with the UCS ldap base for "move" in the "if ucsobject:" section. aff1e7e0ecd2632e57a45db8e345a331f1af57b7 - yaml 5d83ea733885ce469d6d69bbe70e100cb382a2e5 - univention-s4-connector be313fe6bd001ce41f2765203c876f115c511c53 - merge to 4.4-0
tests look good http://jenkins.knut.univention.de:8080/job/UCS-4.3/job/UCS-4.3-3/job/AutotestJoin/SambaVersion=s4connector,Systemrolle=master/ws/test/
Ok, looks good.
<http://errata.software-univention.de/ucs/4.3/405.html>