On Fri, Jun 01, 2012 at 12:53:36AM +0000, GOLLSCHEWSKY, Tim wrote:
Hi Jakub and Stephen,
Thanks for your responses.
>> 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
>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
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
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
>Most of what you're seeing in the 'strings' are actually what we call
"fake" users though. They're users we've saved a minimal set of data
about in the cache so that we can maintain our member/memberOf linkages so that group
lookups work properly.
OK thanks, that makes sense. So when you get the results from a group search, you create
"fake" entries for those users.
Can I ask why SSSD still performs an LDAP lookup for each of these "fake"
users? Since none of these users are actually logging in at the time, it seems
to penalise the user who is logging in because sshd(& pam) blocks waiting for a
response from SSSD.
I'm just installed ldb-tools (this is going to make interrogating the cache much
easier!) and I can see fullname and gecos information for almost 2000 users after I clear
the cache log in with my login user.
# pkill sssd
# rm -f var/lib/sss/db/*
# sbin/sssd -c /etc/sssd/sssd.conf
# ssh myuser@0 date
Fri Jun 1 10:48:56 EST 2012
# ldbsearch -H var/lib/sss/db/cache_AAA.BBB.CCC.ldb 'objectclass=user' | grep
^gecos | wc -l
asq: Unable to register control with rootdse!
I can confirm SSSD is doing ldap user lookups for all the "fake" users by
turning on debug.
This goes back to my original question. When I have enumerate disabled, why does SSSD
still look up all this fake user information in LDAP? And is there any way to disable it
from doing so?
Thanks for your help.
Hm, this is interesting. I'm not seeing this in my test setup -- I
tested with the 1.8 branch, with ldap_group_nesting_level=0 against a
RFC2307bis server. Would you mind sharing a snippet from your logs?