On Mon, Jul 25, 2016 at 01:45:13PM +0200, Jakub Hrozek wrote: > On Thu, Jul 21, 2016 at 02:13:40PM +0200, Sumit Bose wrote: > > Hi, > > > > this is my suggestion to solve https://fedorahosted.org/sssd/ticket/2948 > > "Handle overriden name of members in the memberUid attribute". > > So far I read them to get a grasp of what they do, but didn't do a full > review. See some comments below. > > > > > The first two patches are for the IPA provider and make sure that all > > ghost members in a group get resolved because otherwise we cannot > > determine if the name is overridden or not. This adds an overhead to > > group lookups, especially for larger groups but I think it is an > > requirement which cannot be skipped. > > Right. But I wonder if we could skip it on-demand. Could we maybe check > if any views exist in the IPA domain at all and not resolve the members > if there are no idview data? I would guess that since this is SSSD on > the IPA server, then an additiona LDAP lookup might be cheaper than > resolving a full large group.
Yes, that would be possible. But since this is about AD users I would prefer a different change. Since AD used RFC2307bis (member attribute with the DN of the member) we already read the user object from the AD GC when resolving the group but only ask for objectclass and samAccountName to be able to fill the ghost entry. If we would switch to the LDAP port, read the whole entry and save it to the chance there wouldn't be any ghost entries in the first place. But I wanted to avoid regressions in the common SDAP code at this time so I resolved the ghosts in a second step. But I guess it is worth to open a ticket to add either or both kinds of optimization. > > > > > The third patch adds a sysdb call to recursively resolve all > > user-members of a group. Since the groups in SSSD's cache are > > hierarchically organized the member attribute only contains direct > > user and group members. To get all users the group members must be > > resolved recursively. > > Would dereferencing memberof:top-level-group yield different results? It worked in my testing but I have to admit that I'm not sure if it can be used reliable all the time, i.e. is independent of all the different lookup sequences you can have with nested groups. If you are sure it is reliable, the call can be simplified. bye, Sumit > > > > > Finally the forth patch applies the code-path which is already used for > > non-default views to the default case as well and adds a new list of > > members, with correctly overridden names (hopefully :-) which is then > > used in fill_grmem(). This adds some overhead to the overall group > > processing in the NSS responder (as can be seen in the test changes > > because the members are returned in different order in some cases). But > > I think because the of memory cache this is acceptable and might even > > help to remove the memberuid attribute in future and make the memberof > > plugin simpler. > > > > I worked on an alternative approach as well which tried to make the > > memberof plugin aware of the defaultOverrideName attribute. My wip tree > > is at > > https://fedorapeople.org/cgit/sbose/public_git/sssd.git/log/?h=memberof_default_view > > but so far it does not work properly. Additionally I would prefer to not > > touch the memberof plugin. > > > > bye, > > Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
