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: User: ------ # joe, Users, foo.bar.com dn: uid=joe,ou=Users,dc=foo,dc=bar,dc=com objectClass: account objectClass: posixAccount objectClass: top uidNumber: 1708 gidNumber: 13740 homeDirectory: /home/joe loginShell: /bin/zsh uid: joe cn: Joe User gecos: Joe User Group: -------- # Groups, foo.bar.com dn: ou=Groups,dc=foo,dc=bar,dc=com objectClass: top objectClass: organizationalUnit ou: Groups description: System Groups # web, Groups, foo.bar.com dn: cn=web,ou=Groups,dc=foo,dc=bar,dc=com objectClass: posixGroup objectClass: top cn: web gidNumber: 699 memberUid: joe memberUid: henry 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) . Any ideas? This is a blocker for moving to Fedora 13 and sssd. Version-Release number of selected component (if applicable): sssd-1.2.0-12.fc13.x86_64
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 ***