Learn more about these different git repos.
Other Git URLs
It should be possible to choose whether or not to expand child groups (a group that's a member of a group where the parent group is within the search base) where the child group is outside of the group search base.
I'm not entirely sure whether this should be a boolean to allow it (but how far, as far as the overall search_base or simply "unlimited"), or if it needs a separate nested_group_search_base to provide a second limit...
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.7.0
Moving this back to NEEDS_TRIAGE. This ticket will need a lot of discussion. It's a very complicated problem and I strongly advise against trying to do this in 1.7.0. Ticket #960 belongs in 1.7.0 so we at least get expected results.
milestone: SSSD 1.7.0 => NEEDS_TRIAGE
As it was explained to me the current functionality is to lookup users outside of the base so the ticket is just to make it configurable to execute current code path or the one that will be implemented in #960. I do not see how it is complex but may be I am missing something or you see the scope of the ticket differently.
The current code does not look up users outside of the base in a sane way. The short version is that a group can list some users that you can't individually look up.
The longer version is that when a group is looked up, if it has member DNs that are not currently cached, we will create a temporary fake user in the cache. The idea is that later on when that user is directly requested, the cache entry will be updated with the complete set of user data. However, because this user is outside the search base, this entry will NEVER be updated (and is essentially wasted space in the database).
So in order to solve this ticket properly, we need to ensure that we only store users in the sysdb that can be looked up in LDAP. There are a few potential approaches to this, but all of them require significant changes to our cache lookup to allow it to update a cache entry that is outside of the specified search bases. We can't just do a standard LDAP search for the username or UID, because it will be looking in the wrong place. Instead we'd need to first search the cache to see if a fake user exists with that username, then use the originalDN attribute to look up the user.
Of course, there are issues with this too, if the username happens to be in use in different parts of the LDAP tree (i.e. you have a fake user that's outside the search base with the same name as a user that DOES exist inside the search base, but the fake user's group was looked up first).
It's a highly nontrivial problem and it requires a lot of thought and careful planning. Ticket #960 is the safe and least difficult solution at this time.
milestone: NEEDS_TRIAGE => SSSD Deferred
rhbz: => 0
Metadata Update from @prefect: - Issue set to the milestone: SSSD Patches welcome
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/2003
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.