RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 600446 - LDAP + sssd: group trouble (DOC)
Summary: LDAP + sssd: group trouble (DOC)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Deployment_Guide
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: David O'Brien
QA Contact: ecs-bugs
URL:
Whiteboard:
: 599713 (view as bug list)
Depends On: 599713
Blocks: 579775
TreeView+ depends on / blocked
 
Reported: 2010-06-04 18:01 UTC by Dmitri Pal
Modified: 2016-06-17 21:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 599713
Environment:
Last Closed: 2010-11-11 15:28:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dmitri Pal 2010-06-04 18:01:42 UTC
+++ 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 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.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 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.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 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 18:02:59 UTC
This is cloned as a doc bug.

Comment 3 RHEL Program Management 2010-06-04 18:13:25 UTC
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-16 02:43:16 UTC
(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 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.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 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.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 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 06:14:55 UTC
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 06:56:00 UTC
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 11:50:37 UTC
(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-17 01:02:31 UTC
(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-17 03:54:26 UTC
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=590513 for details of update.

Comment 10 David O'Brien 2010-06-17 03:59:47 UTC
*** Bug 599713 has been marked as a duplicate of this bug. ***

Comment 11 Gowrishankar Rajaiyan 2010-08-18 07:22:00 UTC
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 11:52:13 UTC
For the record, the default for max_id is 0 (which means unbounded)

Comment 13 David O'Brien 2010-08-31 23:27:31 UTC
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-09-01 02:19:27 UTC
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 04:12:06 UTC
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 22:47:21 UTC
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 23:49:49 UTC
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 15:28:26 UTC
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.