#2239 AD backend sometimes fails to store groups
Closed: Duplicate None Opened 10 years ago by jhrozek.

We've encoutered a scenario where the AD provider would fail to save some of the groups but other groups would be saved fine. As first step, we decided to decorate the group processing code with more DEBUG messages so that we are able to pinpoint which member of which group is causing trouble.


Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
owner: somebody => preichl
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.5

Requested by downstream, bumping priority

priority: major => critical

After Pavel's investigation, we suspect the issue the customer was seeing was solved by another patch in the 1.9 timeframe. I'll leave the ticket open now, but it shouldn't block the 1.11.5 release.

milestone: SSSD 1.11.5 => SSSD 1.11.6

The investigation is still ongoing, but we've added some extended debug messages as part of investigating in the meantime:
- master: 9123c2a

The same debugging patch went to sssd-1-11: 2ba0b0b

I think that this problem was addressed by #1755.
After creating scratch build with this patch back ported issue seems to cease exist.

Fields changed

resolution: => duplicate
status: new => closed

Metadata Update from @jhrozek:
- Issue assigned to preichl
- Issue set to the milestone: SSSD 1.11.6

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3281

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata