Bug 626775 - sssd: no group support
sssd: no group support
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-08-24 07:49 EDT by Jan Engelhardt
Modified: 2010-08-26 13:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-26 13:43:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Jan Engelhardt 2010-08-24 07:49:53 EDT
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 07:55:35 EDT
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 07:57:59 EDT
Or the schema used is not the right one (rfc2307bis vs rfc2307) ...
Comment 3 Jan Engelhardt 2010-08-24 08:01:12 EDT
>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 08:02:04 EDT
ou=groups of course, no change.
Comment 5 Stephen Gallagher 2010-08-24 08:08:07 EDT
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 08:42:59 EDT
LDAP server is a openldap2-2.4.21-9.1.x86_64(openSUSE 11.3).
Comment 7 Jan Engelhardt 2010-08-24 08:44:09 EDT
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 09:13:12 EDT
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 10:01:11 EDT
(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 10:09:16 EDT
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 13:43:57 EDT
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.