I triaged this with stein today on IRC. It looks to be reproducible by adding a member object that exists but does not have the user or group objectclass and attributes. I'm not certain where the breakage originates, but the final experience is that sdap_save_grpmem() returns an error, most likely chained from sdap_find_entry_by_origDN().

cc: => sgallagh

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: => 0

Fields changed

owner: somebody => preichl

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.12.1

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

We need to do a release as requested by downstream. Moving tickets that are not fixed already or very close to acking to 1.12.3

milestone: SSSD 1.12.2 => SSSD 1.12.3

I was not able to replicate this bug and in meantime ticket https://fedorahosted.org/sssd/ticket/2343 was solved which should fix problem described in this ticket.

Shall we close the ticket?

mark: => 0

Yes, please close it as a duplicate.

Fields changed

resolution: => duplicate
status: new => closed

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/3172

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.