Bug 51995 - 2 way sync is failing on changed objects
2 way sync is failing on changed objects
Status: NEW
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 4.4
i386 Linux
: P5 critical (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-09-11 05:20 CEST by Telirand
Modified: 2020-09-11 10:39 CEST (History)
1 user (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:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
mixed up UCS (23.61 KB, image/jpeg)
2020-09-11 10:32 CEST, Telirand
Details
mixed up ad (32.16 KB, image/jpeg)
2020-09-11 10:34 CEST, Telirand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telirand 2020-09-11 05:20:10 CEST
We initially appear to get two way sync
but some users are removed from the "domain users" group after the sync

It is as if, the UCS is removing them on the return trip back to the AD server

But there are no sync errors.


when changing   "CN" names in the ad server. some changes are being propagated to
the UCS. but FAIL when going the other way

so far about 217 errors ALL related to the same containers.


try to sync 271 changes from UCS
done: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 
Changes from UCS: 0 (271 saved rejected)



the error message is all the same, but different users.


 cat connector.log
11.09.2020 06:25:17.140 MAIN        (------ ): DEBUG_INIT
11.09.2020 06:25:17.234 LDAP        (PROCESS): Building internal group membership cache
11.09.2020 06:25:17.425 LDAP        (PROCESS): Internal group membership cache was created
11.09.2020 06:25:17.501 LDAP        (PROCESS): Using GP01 as AD Netbios domain name
11.09.2020 06:25:18.121 LDAP        (PROCESS): sync from ucs:   Resync rejected file: /var/lib/univention-connector/ad/1599730906.256689
11.09.2020 06:25:18.167 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=ben.qiu,ou=pd manager (d),ou=merchandising,ou=gpc office,DC=gp01,DC=org,DC=grown-up,DC=com
11.09.2020 06:25:18.214 LDAP        (WARNING): sync failed, saved as rejected
11.09.2020 06:25:18.216 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/connector/__init__.py", line 803, in __sync_file_from_ucs
    or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, object_old))):
  File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 2617, in sync_from_ucs
    self.lo_ad.lo.add_s(compatible_modstring(object['dn']), compatible_addlist(addlist))  # FIXME encoding
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 210, in add_s
    return self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 503, in result
    resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 507, in result2
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,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)
NO_SUCH_OBJECT: {'info': "0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0, best match of:\n\t'DC=gp01,DC=org,DC=grown-up,DC=com'\n", 'matched': 'DC=gp01,DC=org,DC=grown-up,DC=com', 'desc': 'No such object'}
Comment 1 Telirand 2020-09-11 10:32:47 CEST
Created attachment 10485 [details]
mixed up UCS

mixed-up objects
Comment 2 Telirand 2020-09-11 10:34:40 CEST
Created attachment 10486 [details]
mixed up ad
Comment 3 Telirand 2020-09-11 10:39:52 CEST
this seems to have resulted from "renaming"

"supply chain" to "supply-chain" , with a lot of internal objects (271 ?)

on the AD it went thru correctly

on the UCS it failed with the errors but generated TWO copies
the old entry & the new entry & the internal groups

but the users & nested groups remained in the old. UCS "supply chain"

then it looks like that was duplicated over to the AD server, 
but since the objects had already moved on the AD server, they could not be deleted from "supply  chain" since it had been renamed

and since the objects were tried to move BEFORE "supply-chain" was generated on the USC, the task could not be completed, throwing the errors.