Bug 52946 - AD-Connector looses otherTelephone value
AD-Connector looses otherTelephone value
Status: NEW
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-03-17 20:00 CET by Arvid Requate
Modified: 2021-03-17 20:44 CET (History)
1 user (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 7: Crash: Bug causes crash or data loss
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.160
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
connector.log (1.29 MB, text/x-log)
2021-03-17 20:00 CET, Arvid Requate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2021-03-17 20:00:10 CET
Created attachment 10650 [details]
connector.log

The test case 52_s4connector/120sync_create_and_modify_ucs_user shows a bug in the AD-Connector (if it is installed together with S4-Connector):

=========================================================================
info 2021-03-17 18:47:22         CN=lswkcpfn,CN=users,DC=AR41I1,DC=QA: "telephoneNumber" == "14265871" ??
info 2021-03-17 18:47:22         Yes
info 2021-03-17 18:47:22         CN=lswkcpfn,CN=users,DC=AR41I1,DC=QA: "831365874" in "otherTelephone" ??
info 2021-03-17 18:47:23         Value of "otherTelephone" is "65877", does not contain line "831365874"
error 2021-03-17 18:47:23        See #18501
error 2021-03-17 18:47:23        **************** Test failed above this line (121) ****************
=========================================================================



The "con_other" attributes are not synchronized properly any longer. E.g.

telephoneNumber: 14265871
telephoneNumber: 831365874
telephoneNumber: 65877

from OpenLDAP is handled like this:

(INFO   ): sync_from_ucs: The following attribute has been changed: otherTelephone
(INFO   ): sync_from_ucs: Found a corresponding mapping defintion: telephoneNumber
(INFO   ): sync_from_ucs: otherTelephone old_values: set([])
(INFO   ): sync_from_ucs: otherTelephone new_values: set([u'831365874', u'65877'])
(INFO   ): sync_from_ucs: The current AD values: set([])
(INFO   ): sync_from_ucs: The current AD other values: set([])
[...]
(INFO   ): sync_from_ucs: The following attribute has been changed: telephoneNumber
(INFO   ): sync_from_ucs: Found a corresponding mapping defintion: telephoneNumber
(INFO   ): sync_from_ucs: telephoneNumber old_values: set([])
(INFO   ): sync_from_ucs: telephoneNumber new_values: set([u'14265871'])
(INFO   ): sync_from_ucs: The current AD values: set([])
(INFO   ): sync_from_ucs: The current AD other values: set([])

and then otherTelephone is split again into telephoneNumber + otherTelephone and then telephoneNumber is put twice into the modlist:

(ALL    ): sync_from_ucs: modlist: [(2, 'sn', set([u'ohybdtkl'])), (2, 'givenName', set([u'fwfxdtki'])), (2, 'telephoneNumber', [u'831365874']), (2, 'otherTelephone', set([u'65877'])), (2, 'userWorkstations', set([u'fpkjdtlf'])), (2, 'pager', [u'0665889']), (2, 'otherPager', set([u'65892'])), (2, 'profilePath', set([u'yhxpdtkz'])), (2, 'pager', [u'65886']), (2, 'streetAddress', set([u'sqwzdtkr'])), (2, 'scriptPath', set([u'ifojdtlc'])), (2, 'displayName', set([u'fwfxdtki ohybdtkl'])), (2, 'postalCode', set([u'tioldtkw'])), (2, 'homePhone', [u'ndtlw']), (2, 'l', set([u'irevdtku'])), (2, 'telephoneNumber', [u'14265871']), (2, 'mobile', [u'fjymhdaftxadiysdwloladtly']), (0, 'description', set([u'tttkdtko']))]
Comment 1 Arvid Requate univentionstaff 2021-03-17 20:05:01 CET
I guess this has to do with the commits leading up to 3375da581f, but I'm unsure. The con_other_attribute handling collides with the handling of proxyAddresses. The S4-Connector doesn't handle the latter, so it doesn't suffer from this.

https://jenkins.knut.univention.de:8181/job/UCS-4.4/job/UCS-4.4-7/job/ADConnectorMultiEnv/Version=s4connector-w2k8r2-german/lastCompletedBuild/testReport/52_s4connector/120sync_create_and_modify_ucs_user/master237/