Bug 600446 - LDAP + sssd: group trouble (DOC)
LDAP + sssd: group trouble (DOC)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Deployment_Guide (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: David O'Brien
ecs-bugs
: Documentation
: 599713 (view as bug list)
Depends On: 599713
Blocks: 579775
  Show dependency treegraph
 
Reported: 2010-06-04 14:01 EDT by Dmitri Pal
Modified: 2016-06-17 17:12 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 599713
Environment:
Last Closed: 2010-11-11 10:28:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri Pal 2010-06-04 14:01:42 EDT
+++ This bug was initially created as a clone of Bug #599713 +++

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

--- Additional comment from sgallagh@redhat.com on 2010-06-03 15:36:31 EDT ---

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

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

--- Additional comment from terjeros@phys.ntnu.no on 2010-06-03 15:48:22 EDT ---

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?

--- Additional comment from sgallagh@redhat.com on 2010-06-03 15:56:11 EDT ---

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)

--- Additional comment from terjeros@phys.ntnu.no on 2010-06-03 16:21:46 EDT ---

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?

--- Additional comment from sgallagh@redhat.com on 2010-06-04 06:23:16 EDT ---

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 2 Dmitri Pal 2010-06-04 14:02:59 EDT
This is cloned as a doc bug.
Comment 3 RHEL Product and Program Management 2010-06-04 14:13:25 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 4 David O'Brien 2010-06-15 22:43:16 EDT
(In reply to comment #0)
> +++ This bug was initially created as a clone of Bug #599713 +++
> 
> 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
> 
> --- Additional comment from sgallagh@redhat.com on 2010-06-03 15:36:31 EDT ---
> 
> Please include your (possibly sanitized) /etc/sssd/sssd.conf
> 
> Also make sure that you have:
> ldap_schema = rfc2307
> in your [domain/<domainname>] section.
> 
> --- Additional comment from terjeros@phys.ntnu.no on 2010-06-03 15:48:22 EDT
> ---
> 
> 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?
> 
> --- Additional comment from sgallagh@redhat.com on 2010-06-03 15:56:11 EDT ---
> 
> 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)
> 
> --- Additional comment from terjeros@phys.ntnu.no on 2010-06-03 16:21:46 EDT
> ---
> 
> 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?
> 
> --- Additional comment from sgallagh@redhat.com on 2010-06-04 06:23:16 EDT ---
> 
> 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.    

Are you looking at man sssd.conf? It contains:
min_id,max_id (integer)
           UID and GID limits for the domain.

Has somebody else updated this page before me, or am I looking in the wrong paddock? I'll make sure the formal doc is up to date as well.
Comment 5 David O'Brien 2010-06-16 02:14:55 EDT
The "Domain Configuration Options" section in the SSSD chapter in the new Deployment Guide underlines the fact that min_id and max_id apply to both UID and GID.

It is, however, a little confusing. The man page reads "Default: 1 for min_id, 0 (no limit) for max_id" but the user doc states "If min_id is unspecified, it defaults to 1000 for any back end." Can I get a definitive say-so from somebody?
Comment 6 Sumit Bose 2010-06-16 02:56:00 EDT
The default for min_id was recently changed to 1 due to many bug reports like https://bugzilla.redhat.com/show_bug.cgi?id=590513 .
Comment 7 Stephen Gallagher 2010-06-16 07:50:37 EDT
(In reply to comment #5)
> It is, however, a little confusing. The man page reads "Default: 1 for min_id,
> 0 (no limit) for max_id" but the user doc states "If min_id is unspecified, it
> defaults to 1000 for any back end." Can I get a definitive say-so from
> somebody?    

I'm not sure which "user doc" that is listing, but as Sumit said, the correct value should be 1 now.
Comment 8 David O'Brien 2010-06-16 21:02:31 EDT
(In reply to comment #7)
> (In reply to comment #5)
> > It is, however, a little confusing. The man page reads "Default: 1 for min_id,
> > 0 (no limit) for max_id" but the user doc states "If min_id is unspecified, it
> > defaults to 1000 for any back end." Can I get a definitive say-so from
> > somebody?    
> 
> I'm not sure which "user doc" that is listing, but as Sumit said, the correct
> value should be 1 now.    

The draft RHEL 6.0 Deployment Guide which hasn't made it into the public eye yet. This is where all the SSSD doc lives.

Ok, now I know the history of these default values and why they are what they are. Unfortunately the user doc missed out on this last update. Should get patched today.
Comment 9 David O'Brien 2010-06-16 23:54:26 EDT
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=590513 for details of update.
Comment 10 David O'Brien 2010-06-16 23:59:47 EDT
*** Bug 599713 has been marked as a duplicate of this bug. ***
Comment 11 Gowrishankar Rajaiyan 2010-08-18 03:22:00 EDT
Reviewed: 15.2.5.1.1. General Domain Configuration Options.

Could not find the defaults for max_id in this section. Suggest to include this as well.
Comment 12 Stephen Gallagher 2010-08-18 07:52:13 EDT
For the record, the default for max_id is 0 (which means unbounded)
Comment 13 David O'Brien 2010-08-31 19:27:31 EDT
Fixed in RHEL 60 Deployment Guide:

9ebc768..69d00a1  master -> master

Applying BZ 600446: SSSD 'General Domain Configuration Options' updated with min_id,max_id values
Comment 14 Michael Doyle 2010-08-31 22:19:27 EDT
David, what build was the fix included in?

I can't see the default for max_id as requested in #c11 in 15.2.5.1.1. General Domain Configuration Options of Red_Hat_Enterprise_Linux-Deployment_Guide-6-en-US-0.5-44.
Comment 15 David O'Brien 2010-09-01 00:12:06 EDT
Michael,

This update has only just made it into the repo, and probably won't make it into a build until tomorrow, or at least late today.

Silas (dhensley, CC'd on this bug) looks after building the Deployment Guide, and he's based in Brno.
Comment 17 Douglas Silas 2010-09-01 18:47:21 EDT
Andrew,

Hopefully within an hour. David's update should be in Red_Hat_Enterprise_Linux-Deployment_Guide-6-web-en-US-0.5-47.el5 (or later).
Comment 18 Andrew Ross 2010-09-01 19:49:49 EDT
Verified: Red_Hat_Enterprise_Linux-Deployment_Guide-6-web-en-US-0.5-47.el5

Thanks Silas :)

" Specifies the UID and GID limits for the domain. If a domain contains entries that are outside these limits, they are ignored.
The default value for min_id is 1; the default value for max_id is 0 (unbounded). "
Comment 19 releng-rhel@redhat.com 2010-11-11 10:28:26 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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