In setups with idmap_ad this may result in request flood to LDAP server. In a member server setup using idmap_ad, under the following conditions we may end up sending all xid2sid request to the LDAP server sidestepping the cache due to cache churn: - expired or non-existing cache entry for xid2sid mapping, it's likely required to be a frequently queried id like the gid of "Domain Users" - steady stream of xid2sid requests for this id, eg 20 per second The sequence of requests and processing: START: xid2sid request 1 comes in XID2SID: check cache -> not existing (or expired) XID2SID: generates two internal xid2sid requests, the first for the internal domain, the second for the primary domain XID2SID_I: does not know about id, returns null sid, this gets stored in the cache Now xid2sid request 2 comes in: XID2SID: check cache -> not existing (negative cache entry from request 1) XID2SID: generates two internal xid2sid requests, the first for the internal domain, the second for the primary domain XID2SID_P: returns a SID for the id, this gets stored in the cache XID2SID_I: does not know about id, returns null sid, this overwrite the result from request 1 Now xid2sid request 3 comes in, asf. As a result, the correct xid2SID cache entry keeps being overwritten and all requests are sent to the LDAP server. Now the way to fix this: instead of updating the cache when the per-domain map request finished, update the cache after all domains had their say.
Created attachment 14868 [details] Patch for 4.8, 4.9 and 4.10 cherry-picked from master
Reassigning to Karolin for inclusion in 4.8, 4.9 and 4.10.
(In reply to Ralph Böhme from comment #2: Pushed to autobuild-v4-{10,9,8}-test.
(In reply to Karolin Seeger from comment #3) Pushed to all branches. Closing out bug report. Thanks!