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
> 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?
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.
>> 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?
sssd-users mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?