On Sat, 2012-06-02 at 14:28 -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
> 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
> 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
>> # 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
> *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
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?
Yes, that's the case, especially with AD, as Users and groups can be
stored in the same OU, and there is nothing in the DN that can tell you
what is what.
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.
We can do it for IPA, as long as we force a scheme where we have
something in the DN that makes the distinction clear (right now we have
both the RDN and part of the DN to hint us, we just need to implement
the code to read the smarts instead of blindly searching the LDAp
Unfortunately nothing in AD allows you to do that. However, we should
probably smarten up SSSD and make it check the *local* database first.
We keep the originalDN attribute so we can search locally to find out if
we already know what is the object.
We should also always use the MS-PAC for initgroups when using AD (if
Kerberos auth is used), and not search the LDAP directory until some app
really asks a for a getgrgid() op, IMO.
Simo Sorce * Red Hat, Inc * New York