Hi Jakub,
Since SSSD 1.7, the SSSD allows specifying filter as part of the
search base. For example, to only download users that are members of a particular
group:
ldap_user_search_base =
OU=Accounts,DC=aaa,DC=bbb,DC=ccc?subtree?(memberOf=cn=xxxgroup,ou=yyyO
U,ou=zzzOU,ou=Groups,dc=aaa,dc=bbb,dc=ccc)
I've been having a play around with this. Strangely it doesn't seem to limit
much... and I can't work out why. :/
If I have the ldap_user_search_base set at the OU level, it gets this many user records:
# grep ^ldap_user_search_base /etc/sssd/sssd.conf
ldap_user_search_base = ou=Accounts,dc=aaa,dc=bbb,dc=ccc
# ldbsearch -H var/lib/sss/db/cache_AAA.BBB.CCC.ldb 'objectclass=user' | grep
^gecos | wc -l
asq: Unable to register control with rootdse!
1939
But if I put in the memberOf=cn= in there, it gets:
# grep ^ldap_user_search_base /etc/sssd/sssd.conf
ldap_user_search_base =
ou=Accounts,dc=aaa,dc=bbb,dc=ccc?subtree?(memberOf=cn=mygroup,ou=UnixGroups,ou=Groups,ou=aaa,ou=bbb,ou=ccc)
# ldbsearch -H var/lib/sss/db/cache_AAA.BBB.CCC.ldb 'objectclass=user' | grep
^gecos | wc -l
asq: Unable to register control with rootdse!
1938
So not a lot of difference. Just 1 record less.
> 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.
*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 ?
If I'm interpreting this correctly (that we can determine if an object is a
"user" record based on the DN and not have to do a lookup), and if we can also
do this for AD as well as IPA, I think this enhancement would provide a truly remarkable
performance improvement for AD-based sites like mine using RFC2307bis with a medium(to
large) sized directory.
> 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?
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?
Sure.
There is probably a better way to do this. :) But this is how I'm doing it: turning
on debug, and grepping for ldap_search:
sbin/sssd -c /etc/sssd/sssd.conf -i -d8 2>&1 | fgrep calling\ ldap_search_ext
> /tmp/searches.txt
Note in this example I'm using a cleared cache with nesting = 0 and enumerate = false
and the following user search base.
The login took 31 seconds.
ldap_user_search_base =
ou=Accounts,dc=aaa,dc=bbb,dc=ccc?subtree?(memberOf=CN=mygroup,OU=UnixGroups,OU=Groups,DC=aaa,DC=bbb,DC=ccc)
# wc -l /tmp/searches.txt
2980 /tmp/searches.txt
# grep objectclass=user /tmp/searches.txt | wc -l
2397
"mygroup" contains 581 users.
This is what some of the searches look like:
# grep objectclass=user /tmp/searches.txt | head
(Mon Jun 4 16:25:11 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(&(&(msSFU30Name=myuser)(objectclass=user))(memberOf=CN=mygroup,OU=UnixGroups,OU=Groups,DC=aaa,DC=bbb,DC=ccc))][ou=Accounts,dc=aaa,dc=corp,dc=ccc].
(Mon Jun 4 16:25:11 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(&(&(msSFU30Name=myuser)(objectclass=user))(memberOf=CN=mygroup,OU=UnixGroups,OU=Groups,DC=aaa,DC=bbb,DC=ccc))][ou=Accounts,dc=aaa,dc=corp,dc=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser1,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser2,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser3,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser4,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser5,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [(objectclass=user)][CN=someuser6,OU=Admin
Accounts,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(objectclass=user)][CN=someuser7,OU=Users,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
(Mon Jun 4 16:25:12 2012) [sssd[be[AAA.BBB.CCC]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(objectclass=user)][CN=someuser8,OU=Users,OU=Accounts,DC=aaa,DC=bbb,DC=ccc].
If more sanitised debug output would be useful, please let me know.
Cheers,
Tim.
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related
entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at
suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not
necessarily reflect the view of Suncorp. The content, including attachments, is a
confidential communication between Suncorp and the intended recipient. If you are not the
intended recipient, any use, interference with, disclosure or copying of this e-mail,
including attachments, is unauthorised and expressly prohibited. If you have received this
e-mail in error please contact the sender immediately and delete the e-mail and any
attachments from your system.