sssd-users May 2012

sssd-users@lists.fedorahosted.org

6 participants
5 discussions

enumerate=false still enumerates a lot of users/groups
by GOLLSCHEWSKY, Tim 05 Jun '12

05 Jun '12

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.

6 13

Announcing SSSD 1.8.4
by Stephen Gallagher 30 May '12

30 May '12

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

1 0

Using sudo via SSSD in Fedora 17
by Erinn Looney-Triggs 29 May '12

29 May '12

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

3 5

Stress testing sssd - group enumeration
by Ondrej Valousek 29 May '12

29 May '12

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

2 1

hello and corrupted db
by Angel Bosch 24 May '12

24 May '12

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

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2012