enumerate=false still enumerates a lot of users/groups
by GOLLSCHEWSKY, Tim
Hi SSSD Users.
I'm trying to increase the performance of my user's logins, we have a medium sized Active Direcctory.
According to the man page, the enumerate directive:
enumerate (bool)
Determines if a domain can be enumerated. This parameter can have one of the following values:
TRUE = Users and groups are enumerated
FALSE = No enumerations for this domain
However when I start sssd with no cache and simulate an initgroups, it still seems to enumerate many
many groups and user accounts.
I'm running sssd v1.8.4:
# pkill sssd
# pgrep sssd
# pwd
/apps/sssd-1.8.4
# rm -f var/lib/sss/db/*
# grep enumerate /etc/sssd/sssd.conf
enumerate = FALSE
# grep ldap_access /etc/sssd/sssd.conf
ldap_access_filter = memberOf=cn=xxxgroup,ou=yyyOU,ou=zzzOU,ou=Groups,dc=aaa,dc=bbb,dc=ccc
# sbin/sssd -c /etc/sssd/sssd.conf
# su - myuser -c "groups | wc"
1 193 1181
# strings var/lib/sss/db/cache_AAA.BBB.CCC.ldb | grep OU=Groups,DC=aaa,DC=bbb,DC=ccc | sort -u | wc -l
522
# strings var/lib/sss/db/cache_AAA.BBB.CCC.ldb | grep OU=Accounts,DC=aaa,DC=bbb,DC=ccc | sort -u | wc -l
1938
Sorry for my use of strings and sort -u, I don't know a better way to interrogate the cache.
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?
Regards,
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.
11 years, 6 months
Announcing SSSD 1.8.4
by Stephen Gallagher
The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.8.4.
As usual, the source can be downloaded from
https://fedorahosted.org/sssd/
== Highlights ==
Fix a bug causing AD servers not to fail over properly when the KDC
on the primary server is down
Fix an endianness bug on big-endian systems when looking up services
Fix a segfault dealing with nested groups
Make the nowait cache updates work for netgroups
Fix a regression that broke domains with
use_fully_qualified_names = True
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/1206
RHEL5 detection in sssd.spec.in does not work
https://fedorahosted.org/sssd/ticket/1321
Warning in debug log about nscd
https://fedorahosted.org/sssd/ticket/1322
Special-case LDAP_SIZELIMIT_EXCEEDED when handling ldap return codes
https://fedorahosted.org/sssd/ticket/1324
LDAP provider needs to use all available servers for GSSAPI if the
child times out
https://fedorahosted.org/sssd/ticket/1325
heimdal: configure: Kerberos locator plugin cannot be build
https://fedorahosted.org/sssd/ticket/1329
Group enumeration fails in proxy provider
https://fedorahosted.org/sssd/ticket/1333
Potential NULL dereference in proxy provider
https://fedorahosted.org/sssd/ticket/1335
sss_groupadd no longer detects duplicate GID numbers
https://fedorahosted.org/sssd/ticket/1338
sssd does not provide maps for automounter when custom schema is
being used
https://fedorahosted.org/sssd/ticket/1340
SSSD netgroups do not honor entry_cache_nowait_percentage
https://fedorahosted.org/sssd/ticket/1343
sssd_be crashed with SIGSEGV in _tevent_schedule_immediate()
https://fedorahosted.org/sssd/ticket/1344
Loading of selinux user maps broken
https://fedorahosted.org/sssd/ticket/1348
Service lookups by port number doesn't work on s390x/ppc64 arches
== Detailed Changelog ==
Ariel Barria (2):
Potential NULL dereference in proxy provider
Warn to syslog when dereference requests fail
Jakub Hrozek (11):
Special-case LDAP_SIZELIMIT_EXCEEDED
Kerberos locator: Include the correct krb5.h header file
krb5 locator: Do not leak addrinfo
Try all KDCs when getting TGT for LDAP
Send the correct enumeration request
SYSDB: Handle user and group renames better
Use the sysdb attribute name, not LDAP attribute name
LDAP nested groups: Do not process callback with _post deep in the
nested structure
Use sized_string correctly in FQDN domains
Send 16bit protocol numbers from the sss_client
Revert the client packet length, too, after reverting the packet
protocol
Jan Engelhardt (1):
build: resolve link failure
Jan Zeleny (1):
Fixed issue in SELinux user maps
Stef Walter (3):
Limit krb5_get_init_creds_keytab() to etypes in keytab
If canon'ing principals, write ccache with updated default principal
Remove erroneous failure message in find_principal_in_keytab
Stephen Gallagher (7):
Bump version to 1.8.4
murmurhash: Relax inline requirement
RPM: Allow running 'make rpms' on RHEL 5 machines
NSS: Expire in-memory netgroup cache before the nowait timeout
KRB5: Avoid NULL-dereference with empty keytab
NSS: Restore original protocol for getservbyport
Updating translations for 1.8.4 release
11 years, 6 months
Using sudo via SSSD in Fedora 17
by Erinn Looney-Triggs
I have been working on configuring SSSD to handle sudo natively in
Fedora 17.
Here are the versions of things:
sssd-1.8.3-11.fc17.x86_64
sudo-1.8.3p1-7.fc17.x86_64
This is running against a RHEL 6.2 IPA server:
ipa-server-2.1.3-9.el6.x86_64
I have been using these two sources of information:
https://fedoraproject.org/wiki/Features/SSSDSudoIntegration
http://jhrozek.livejournal.com/2065.html (Thanks for the write up)
The bit that seems to hang for me is when it comes to the
ldap_sudo_search_base, the blog doesn't state explicitly that it should
go in the domain section of sssd.conf, but the feature page does, so I
drop it in there, after a restart even simple lookups via getent passwd
won't work any more, remove it, restart sssd, things work fine. I
suppose I should mention that my test system has been working fine as an
IPA client up until I start messing with the sudo bit.
The line I am trying to put into the domains section is the following:
ldap_sudo_search_base = "ou=SUDOers,dc=foo,dc=com"
Any thoughts?
-Erinn
11 years, 6 months
Stress testing sssd - group enumeration
by Ondrej Valousek
Hi all,
I have been testing sssd - i.e. enumerating groups as per RFC2307bis (AD schema) in our (fairly large) organization and here are the results:
sssd 1.5.1 - 5:08 minutes
sssd 1.8.3 - 1:24 minutes
Centrify (commercial product) - 34 seconds
The performance gain between sssd 1.5.1 and 1.8.3 is obvious, but it is still far behind a commercial product Centrify.
Note that when computing the groups membership, Centrify also considers the AD-specific 'PrimaryGroupID' attribute - this is something sssd
can not do yet.
Ondrej
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications(a)s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
11 years, 6 months
hello and corrupted db
by Angel Bosch
first of all: HI!
nice to see a users list for this project :)
and now the real dirt:
I'm having problems of corruption with one of several fresh installed machines.
seems that cache_*.db is corrupted periodically. after some time of working, user cant work and console says that he doesn't exist. if I execute `id' I can see extrange big numbers instead of real GIDs.
the only thing that seems to work is stopping service, removing cache, and starting service again:
service sssd stop
rm /var/lib/sss/db/cache*
service sssd start
this is only happening on one machine of about 10, but all are fresh installations of ubuntu 12.04 with official packages.
anyone detected similar problem?
abosch
11 years, 6 months
