On Sat, Jun 02, 2012 at 02:28:57PM -0400, Dmitri Pal wrote:
On 06/01/2012 03:11 AM, Jakub Hrozek wrote:
> On Fri, Jun 01, 2012 at 12:53:36AM +0000, GOLLSCHEWSKY, Tim wrote:
>> Hi Jakub and Stephen,
>>
>> Thanks for your responses.
>>
>> Stephen wrote:
>>>> Why does it still enumerate so many users and groups (that are not
>>>> me, and not in my ldap_access_filter) when I log in? Even when I have
disabled domain enumeration?
>>>
>>> As Jakub suggested, your investigation is slightly flawed. I'm guessing
your version of "simulating an initgroups" is by running 'id username'.
>>> This is actually different from initgroups. What this does is an
>>> initgroups() call followed by a loop to look up every group that the user is
a member of.
>> OK, thanks. I see now I've been using the wrong method to test this.
>>
>> You guys have suggested "id -G" or actually logging in. "id
-G" doesnt seem to have the same effect on SSSD that actually logging in has.
"id -G" returns quite quickly, whereas a normal ssh login takes a very long time
as SSSD goes nuts performing user lookups on our AD (for hundreds of users that aren't
even logging into the server at the time).
>>
>> I'll ensure all my testing from now on is an actual ssh login and not the
"groups" command.
> I suspect the reason is that SSSD tries to be smart here and
> differentiates between initgroups operation performed via the NSS
> interface (id -G) and initgroups performed during auth via the PAM
> stack.
>
> The initgroups that comes from the NSS can be returned from the cache
> for speed's sake. On the other hand, the PAM responder only keeps a very
> short-lived in-memory cache - see the pam_id_timeout option in sssd.conf,
> defaults to 5 seconds. Its purpose is mainly to only contact the server
> once even if the login program performs multiple initgroups calls during
> login - SSH is one example, it performs several initgroups operations during
> various stages of the PAM conversation and even from different processes.
>
>>> The net effect of this is that by doing this, we're also doing a lookup
of all the users in those groups (we don't have a choice in this, because RFC2307bis
servers can have other groups as a member and we cannot know which we're dealing with
until we request it).
>> Yes this is what I'm seeing. But is this also the case when I have disabled
nesting?
>>
>> # grep nesting /etc/sssd/sssd.conf
>> ldap_group_nesting_level = 0
>>
>> All our LDAP groups in the Unix OU have been flattened specifically to negate
the need for nested searching and (hopefully) increase performance.
> Still, the SSSD needs to check the DNs to see if the DN points to a user
> entry or not. In theory, the group members can be other objects than
> users.
>
> *Maybe* we could do more heuristics if the group and user base DNs are
> specified and don't overlap, something similar to what's proposed in
>
https://fedorahosted.org/sssd/ticket/1319 ?
>
Are you saying that no when we get a set of the DNs in the memberOf we
do not know whether the entry is a user or a group so we have to fetch
entries to see if the entry is a user or a group?
IMO with there should be a way to regex it in SSSD and fetch only in
cases when it is not possible to determine if the member is a user or a
group. Use of the regex will help with other 2307 bis servers not just
IPA. We need to think about AD too.
That's only 100% doable with tightly-controlled environments such as IPA
where you know for certain that a particular DN points to user or group
containers.
In the generic case, the DN might simply look like
"cn=name,ou=accounts,dc=example,dc=com" and then only a lookup can tell
if it's a user or a group.
What I was telling Tim earlier was that we might want to do the
LDAP-search based heuristics also in cases when the group and user
containers are distinct, such as "ou=Users,dc=example,dc=com" and
"ou=Groups,dc=example,dc=com".