Bug 599713

Summary:	LDAP + sssd: group trouble
Product:	[Fedora] Fedora	Reporter:	Terje Røsten <terje.rosten>
Component:	sssd	Assignee:	David O'Brien <nobody+davido>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	daobrien, jhrozek, sbose, sgallagh, ssorce
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	600446 (view as bug list)		Environment:
Last Closed:	2010-06-17 03:59:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	600446

Description Terje Røsten 2010-06-03 19:28:11 UTC

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

Comment 1 Stephen Gallagher 2010-06-03 19:36:31 UTC

Please include your (possibly sanitized) /etc/sssd/sssd.conf

Also make sure that you have:
ldap_schema = rfc2307
in your [domain/<domainname>] section.

Comment 2 Terje Røsten 2010-06-03 19:48:22 UTC

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?

Comment 3 Stephen Gallagher 2010-06-03 19:56:11 UTC

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)

Comment 4 Terje Røsten 2010-06-03 20:21:46 UTC

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?

Comment 5 Stephen Gallagher 2010-06-04 10:23:16 UTC

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.

Comment 6 David O'Brien 2010-06-17 03:59:46 UTC


*** This bug has been marked as a duplicate of bug 600446 ***