sssd-devel July 2012

sssd-devel@lists.fedorahosted.org

19 participants
76 discussions

Mixing passwd accounts with LDAP groups issue
by Jan Engelhardt 05 Jul '12

05 Jul '12

Hi, I have my user account listed in both /etc/passwd, /etc/shadow and the LDAP tree. However, only the LDAP tree has the supplementary group list info. In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop) In sssd-1.8.93, this is no longer the case, and instead I get: uid=25121(jengelh) gid=100(users) groups=100(users),33(video) `getent group 31327` has to say: rdesktop:*:31327:fz,mm,mk `ldapsearch -x cn=rdesktop`: dn: cn=rdesktop,ou=groups,o=borg objectClass: posixGroup objectClass: top objectClass: groupOfNames objectClass: sambaGroupMapping objectClass: zarafa-group cn: rdesktop description: Remote Desktop Users member: uid=jengelh,ou=users,o=company member: uid=fz,ou=users,o=company member: uid=mm,ou=users,o=company member: uid=mk,ou=users,o=company sambaGroupType: 2 displayName: Remote Desktop gidNumber: 31327 zarafaHidden: 1 sambaSID: S-1-5-21-2434340325-2384729352-2357823451-12387 If I comment about my entry in /etc/passwd, I do receive the groups from LDAP again, but naturally I am missing out on the local groups: uid=25121(jengelh) gid=27072(netitwork) groups=27072(netitwork),33(video),56485(friends), 31327(rdesktop),399(abuild) It seems like if the user entry is satisfiable from /etc/passwd, group lookup is also only limited to passwd. This breaks with behavior of all previously seen implementations (pam_ldap,..) which strictly separated user and group lookups like NSS's design set forth a handful of decades ago. Side-note supplement: And then there is the cache coming into play, which provided for a handful of surprises on its own. Removing the comment hash mark # from my entry in /etc/passwd again after the previous lookup, I then get *all* memberships from both local and LDAP: uid=25121(jengelh) gid=100(users) groups=100(users),33(video),56485(friends),31327(rdesktop), 27072(netitwork),399(abuild) so the look-in-passwd-only "misfeature" is not even consistent :)

2 5

My solution to keep an update cache of all LDAP entries. Is there a better way?
by Mark London 03 Jul '12

03 Jul '12

Here is my solution to have a persistant uptodate local cache of all ldap entries, so as to avoid very long delays when a user issues a command that causes a large number of LDAP lookups, i.e. by doing a "ls -l /home": enumerate = true enum_cache_timeout = 86400 ldap_purge_cache_timeout = 0 ldap_enumeration_refresh_timeout = 300 I set the cache timeout to be 24 hours, and do an enumerate every 5 minutes. What I would like to know, is why such long delays (i.e. minutes) occurs when doing an "ls -l /home". Is it because it has to write out each entry into the local database? Just curious. :) Thanks. Mark London

3 2

No negative cache with sssd_nss
by Jan Engelhardt 02 Jul '12

02 Jul '12

Hi, it seems that sssd does not cache negative responses from the shadow/NSS backend. This is particularly observable when repeatedly querying for groups that do not exist in /etc/group, but do exist in LDAP. sssd is configured to search local db, plus another server's LDAP tree. If the group "clients" is in LDAP, the following testcase below runs in about ~8.5 sec on the reference machine. However, if I add the "clients" group to the end of /etc/group, it completes in like 1.3 sec. When only in LDAP, tcpdump shows no activity on port 389, so at least the positive caching does work. However, the negative response from NSS increases the execution time significantly, which leads me to believe that part is not cached. ---8<--- #include <stdio.h> #include <stdlib.h> #include <pwd.h> #include <grp.h> int main(void) { unsigned int i; struct group *g; for (i = 0; i < 50000; ++i) { g = getgrnam("clients"); } return EXIT_SUCCESS; }

3 12

[PATCH] IPA: Don't hang onto memory longer than necessary
by Stephen Gallagher 02 Jul '12

02 Jul '12

This request and attached memory would be freed at the end of access-check processing, but it's a waste to keep it around.

2 2

[PATCH] LDAP: Print extended failure message for SASL bind
by Stephen Gallagher 02 Jul '12

02 Jul '12

Adds a useful DEBUG message if SASL binds fail. This was helpful in tracking down issues while working on the Active Directory ID provider.

3 4

[PATCH] fix ipa provider (already pushed)
by Simo Sorce 02 Jul '12

02 Jul '12

After recent changes the ipa provider was broken. The problem is in the code the looks at the rootdse, it assumed the sudorule_map to be always available and unconditionally referenced that. That map is configured only if sudo_provider = ldap is configure in the ldap case, however it is never configured in the ipa case as a sudo_provider = ipa has not been made available. This may not be the ultimate way to fix the issue however because there is no sudo provider for ipa there is no other workaround to avoid sssd_be crashing so I pushed this patch under the onliner and unbreak the ipa provider rule (yes I made that last one up :-D but I use it daily so it is important to never completely break it for me). Simo. -- Simo Sorce * Red Hat, Inc * New York

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel July 2012