Mixing passwd accounts with LDAP groups issue
by Jan Engelhardt
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 :)
11 years, 9 months
My solution to keep an update cache of all LDAP entries. Is there a better way?
by Mark London
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
11 years, 9 months
No negative cache with sssd_nss
by Jan Engelhardt
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;
}
11 years, 9 months
[PATCH] fix ipa provider (already pushed)
by Simo Sorce
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
11 years, 9 months
