Bug 48362 - Synchronization fails after move in UCS if ldap/base and samba4/ldap/base are different
Synchronization fails after move in UCS if ldap/base and samba4/ldap/base are...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.3
Other Linux
: P5 normal (vote)
: UCS 4.3-3-errata
Assigned To: Felix Botner
Arvid Requate
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-12-17 15:18 CET by Nico Stöckigt
Modified: 2019-03-30 07:54 CET (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.143
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2018120421000817
Bug group (optional):
Max CVSS v3 score:


Attachments
here_be_dragons.diff (992 bytes, patch)
2018-12-17 21:44 CET, Arvid Requate
Details | Diff
proposal.diff (2.24 KB, patch)
2018-12-17 23:35 CET, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Stöckigt univentionstaff 2018-12-17 15:18:02 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
Comment 2 Arvid Requate univentionstaff 2018-12-17 21:43:32 CET
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.
Comment 3 Arvid Requate univentionstaff 2018-12-17 21:44:10 CET
Created attachment 9780 [details]
here_be_dragons.diff
Comment 4 Arvid Requate univentionstaff 2018-12-17 23:35:14 CET
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.
Comment 7 Felix Botner univentionstaff 2019-01-08 16:31:51 CET
This error was triggerd by a move in UCS, not a password change.
Comment 8 Felix Botner univentionstaff 2019-01-09 11:52:07 CET
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
Comment 10 Arvid Requate univentionstaff 2019-01-16 12:54:01 CET
Ok, looks good.
Comment 11 Arvid Requate univentionstaff 2019-01-16 13:25:23 CET
<http://errata.software-univention.de/ucs/4.3/405.html>