Bug 626775 - sssd: no group support
Summary: sssd: no group support
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-24 11:49 UTC by Jan Engelhardt
Modified: 2010-08-26 17:43 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2010-08-26 17:43:57 UTC

Attachments (Terms of Use)
requested log (34.03 KB, text/x-log)
2010-08-24 12:44 UTC, Jan Engelhardt
no flags Details

Description Jan Engelhardt 2010-08-24 11:49:53 UTC
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.)

Comment 1 Stephen Gallagher 2010-08-24 11:55:35 UTC
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.

Comment 2 Simo Sorce 2010-08-24 11:57:59 UTC
Or the schema used is not the right one (rfc2307bis vs rfc2307) ...

Comment 3 Jan Engelhardt 2010-08-24 12:01:12 UTC
>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.

config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = LDAP
filter_groups = root
filter_users = root
reconnection_retries = 3
reconnection_retries = 3
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

Comment 4 Jan Engelhardt 2010-08-24 12:02:04 UTC
ou=groups of course, no change.

Comment 5 Stephen Gallagher 2010-08-24 12:08:07 UTC
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?

Comment 6 Jan Engelhardt 2010-08-24 12:42:59 UTC
LDAP server is a openldap2-2.4.21-9.1.x86_64(openSUSE 11.3).

Comment 7 Jan Engelhardt 2010-08-24 12:44:09 UTC
Created attachment 440643 [details]
requested log

Started sssd. Then echo ----- >>sssd_LDAP.log. Afterwards, ran `getent group -s sss`.

Comment 8 Stephen Gallagher 2010-08-24 13:13:12 UTC
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)

Comment 9 Jan Engelhardt 2010-08-24 14:01:11 UTC
(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.

Comment 10 Stephen Gallagher 2010-08-24 14:09:16 UTC
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.

Comment 11 Jan Engelhardt 2010-08-26 17:43:57 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.