Bug 599713 - LDAP + sssd: group trouble
Summary: LDAP + sssd: group trouble
Status: CLOSED DUPLICATE of bug 600446
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David O'Brien
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 600446
TreeView+ depends on / blocked
Reported: 2010-06-03 19:28 UTC by Terje Røsten
Modified: 2010-06-17 03:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 600446 (view as bug list)
Last Closed: 2010-06-17 03:59:46 UTC
Type: ---

Attachments (Terms of Use)

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:

# 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

# 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):


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 ***

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