Description of problem: `getent group` does not return any LDAP groups. Version-Release number of selected component (if applicable): sssd-1.1.0-1.10 (openSUSE 11.3) and sssd-1.2.2-19.fc13.x86_64 (F-13) How reproducible: Configure sssd as usual. Run `id someuser` that is a member of an LDAP-delivered group. Actual results: [root@localhost sssd]# id jengelh uid=25121(jengelh) gid=15000 groups=15000 Expected results: [root@localhost sssd]# id jengelh uid=25121(jengelh) gid=15000(users) groups=15000(users) Additional info: [root@localhost sssd]# getent group -s sss [root@localhost sssd]# (Looks like sssd does not replace nss_ldap just yet.)
Please include your (sanitized) sssd.conf. I would hazard a guess that you accidentally used 'ldap_user_search_base' instead of 'ldap_search_base', and SSSD doesn't know where in your LDAP tree to find users.
Or the schema used is not the right one (rfc2307bis vs rfc2307) ...
>accidentally used 'ldap_user_search_base' Well the HOWTOs diverged on that. For safety I used all. >Or the schema used is not the right one (rfc2307bis vs rfc2307) ... No change when going to 2307bis. --- [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = LDAP [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/LDAP] id_provider = ldap auth_provider = ldap ldap_schema = rfc2307bis ldap_uri = ldap://borg.medozas.de ldap_search_base = o=borg ldap_user_search_base = ou=users,o=borg ldap_group_search_base = ou=group,o=borg ldap_tls_reqcert = demand cache_credentials = true enumerate = False
ou=groups of course, no change.
Jan, could you add `debug_level = 9` to the [domain/LDAP] section, restart SSSD, run `id someuser` again and then attach /var/log/sssd/sssd_LDAP.log to the ticket? This is definitely a new issue. Also, what LDAP server are you using?
LDAP server is a openldap2-2.4.21-9.1.x86_64(openSUSE 11.3).
Created attachment 440643 [details] requested log Started sssd. Then echo ----- >>sssd_LDAP.log. Afterwards, ran `getent group -s sss`.
Judging by this log, SSSD never received a group lookup request. Can you check that there is a line like this in /etc/nsswitch.conf: group: files sss If 'sss' isn't there, (or is misspelled) glibc won't ask SSSD for user information. If it is there, please also attach /var/log/sssd/sssd_nss.log (which will hopefully tell us why it's not asking LDAP for this information)
(Tue Aug 24 09:56:39 2010) [sssd[nss]] [nss_cmd_getgrent] (4): Requesting info for all groups (Tue Aug 24 09:56:39 2010) [sssd[nss]] [nss_cmd_setgrent_ext] (4): Requesting info for all groups (Tue Aug 24 09:56:39 2010) [sssd[nss]] [nss_cmd_setgrent_ext] (2): Enumeration disabled on all domains! (Tue Aug 24 09:56:39 2010) [sssd[nss]] [nss_cmd_endgrent] (4): Terminating request info for all groups Enabled enumeration and now it works. Strange defaults sssd has there.
Enumeration is disabled by default since in large environments it can be very expensive to perform a lookup on the entire database. However, that doesn't explain why 'id someuser' wasn't returning the group properly. This is still a bug and I need to know why it's happening. Please do the following: 1) Stop SSSD 2) Purge the cache (rm -f /var/lib/sss/db/cache_*.ldb) 3) Disable enumeration and turn on debug_level = 9 for [nss] and [domain/LDAP] 4) Start SSSD 5) Run 'id <someuser>' 6) Attach /var/log/sssd_nss.log and /var/log/sssd_LDAP.log to this bug.
I think it wasn't returning anything for 15000 because that was only locally defined on the other host. Right now I am unable to produce any problems.