Red Hat Bugzilla – Bug 599713
LDAP + sssd: group trouble
Last modified: 2010-06-16 23:59:46 EDT
Description of problem:
using LDAP auth (against RHEL 5 OpenLDAP server) and sssd.
Everything is smooth expect group info.
$ getent group
don't return any groups in LDAP and id <user> only return primary group.
LDAP server has:
# joe, Users, foo.bar.com
cn: Joe User
gecos: Joe User
# Groups, foo.bar.com
description: System Groups
# web, Groups, foo.bar.com
I have set:
ldap_group_member = memberUid
ldap_group_search_base = ou=Groups,dc=foo,dc=bar,dc=com
ldap_search_base = dc=foo,dc=bar,dc=com
default is memberuid (no uppercase U).
This config work perfect on Fedora 1 to 12 (with nss_ldap and friends) .
This is a blocker for moving to Fedora 13 and sssd.
Version-Release number of selected component (if applicable):
Please include your (possibly sanitized) /etc/sssd/sssd.conf
Also make sure that you have:
ldap_schema = rfc2307
in your [domain/<domainname>] section.
Now it suddenly seems to work after adding correct ldap_group_search_base and ldap_group_member options.
Was I tricked by some caching? How can I flush the cache?
I'm not sure what happened, given that you were describing sanitized values above.
For the record, ldap_group_search_base and ldap_user_search_base are completely optional if ldap_search_base is configured appropriately above both paths. (Those two options are only useful if your users or groups are in very distant branches of the tree, for performance)
There's no reason to set ldap_group_member for case, it's a case-insensitive option.
As for caching, it should only cache values that LDAP actually responded with, so I don't think that's the issue. However if you want to forcibly empty the SSSD cache, just shut down the sssd and 'rm -f /var/lib/sss/db/cache_*.ldb'
It's also possible that if you specified 'enumerate=true' in the sssd.conf that you were trying to read the results before the first enumeration run had completed (which will result in inaccurate data until it finishes, sometimes several minutes after startup for large LDAP databases)
Sorry, forget my comment #2, it's min_id which is the culpit.
Default was 1000, while all LDAP groups have 500-999.
Can I ask for min_gid or at least a documentation update to add that
min_id give restricts to gids too?
David, could you ensure that our manpages and formal documentation properly reflects that min_id and max_id represents both UID and GID?
On quick inspection, I see that the manpage falsely gives the impression that it is UID only.
*** This bug has been marked as a duplicate of bug 600446 ***