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 692404 - rfc2307bis groups are being enumerated even when the gidNumber is out of the range of min_id,max_id.
Summary: rfc2307bis groups are being enumerated even when the gidNumber is out of the ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.1
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 692455
TreeView+ depends on / blocked
 
Reported: 2011-03-31 09:14 UTC by Kaushik Banerjee
Modified: 2020-05-02 16:19 UTC (History)
6 users (show)

Fixed In Version: sssd-1.5.1-35.el6
Doc Type: Bug Fix
Doc Text:
Cause: When saving group memberships, SSSD uses a two-pass approach - save all the groups first and then save their members. When a group GID is outside a specifed range, the group should be skipped completely. SSSD correctly skipped the groups out of range during the save groups step, but then created the group anyway as a side-effect of the save members step. Consequence: SSSD did not filter groups whose GID was outside a specified range Fix: The group save operation was changed so that only members of groups that were processed successfully are saved. Result: SSSD correctly filters groups based on the min_id/max_id limits.
Clone Of:
: 692455 (view as bug list)
Environment:
Last Closed: 2011-12-06 16:38:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 1876 0 None closed RFC2307bis groups are not filtered out when their UID is out of range 2020-05-02 16:19:28 UTC
Red Hat Product Errata RHBA-2011:1529 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2011-12-06 00:50:20 UTC

Description Kaushik Banerjee 2011-03-31 09:14:27 UTC 
Description of problem:
Able to enumerate groups even when the gid is out of the range of min_id,max_id.

Version-Release number of selected component (if applicable):
sssd-1.5.1-21.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Configure sssd to enumerate against AD. See additional info for relevant sssd.conf

2. Add a user02 and group02 in Active Directory. The ldapsearch returns:

#  ldapsearch -H ldaps://pluto.lab.eng.pnq.redhat.com -D cn=Administrator,cn=Users,dc=sssdad,dc=com -b "CN=group02,CN=Users,DC=sssdad,DC=com" -W 
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <CN=group02,CN=Users,DC=sssdad,DC=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# group02, Users, sssdad.com
dn: CN=group02,CN=Users,DC=sssdad,DC=com
objectClass: top
objectClass: group
cn: group02
member: CN=user02,CN=Users,DC=sssdad,DC=com
distinguishedName: CN=group02,CN=Users,DC=sssdad,DC=com
instanceType: 4
whenCreated: 20110330235022.0Z
whenChanged: 20110330235022.0Z
uSNCreated: 17860
uSNChanged: 17872
name: group02
objectGUID:: l1UdlT+WBUGBeog7fmrAlQ==
objectSid:: AQUAAAAAAAUVAAAAG7QhYKWWbzz2dDlknwQAAA==
sAMAccountName: group02
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=sssdad,DC=com
dSCorePropagationData: 16010101000000.0Z
msSFU30Name: group02
msSFU30NisDomain: sssdad
gidNumber: 20002

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

============================================================================
#  ldapsearch -H ldaps://pluto.lab.eng.pnq.redhat.com -D cn=Administrator,cn=Users,dc=sssdad,dc=com -b "CN=user02,CN=Users,DC=sssdad,DC=com" -W 
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <CN=user02,CN=Users,DC=sssdad,DC=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# user02, Users, sssdad.com
dn: CN=user02,CN=Users,DC=sssdad,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: user02
sn: user02
givenName: user02
distinguishedName: CN=user02,CN=Users,DC=sssdad,DC=com
instanceType: 4
whenCreated: 20110330235022.0Z
whenChanged: 20110330235022.0Z
displayName: user02
uSNCreated: 17863
memberOf: CN=group02,CN=Users,DC=sssdad,DC=com
uSNChanged: 17870
name: user02
objectGUID:: OGG3GT8MX0aVCW3hcddiJA==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 129460026226093750
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAG7QhYKWWbzz2dDlkoAQAAA==
accountExpires: 0
logonCount: 0
sAMAccountName: user02
sAMAccountType: 805306368
userPrincipalName: user02
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=sssdad,DC=com
dSCorePropagationData: 16010101000000.0Z
msSFU30Name: user02
msSFU30NisDomain: sssdad
uidNumber: 20002
gidNumber: 20002
unixHomeDirectory: /home/user02
loginShell: /bin/bash

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


3. Enumerate user02 "getent -s sss passwd user02"(Returns nothing and appropriate message is seen in the logs).
4. Enumerate group02 "getent -s sss group group02".
  
Actual results:
Able to enumerate groups even when the gid is out of the range of min_id=90000.

# getent -s sss group group02
group02:*:90001:

/var/log/sssd/sssd.log
<snip>
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_user] (2): User [user02] filtered out! (id out of range)
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_user] (2): Failed to save user [user02]
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_users] (2): Failed to store user 0. Ignoring.
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [ldb] (9): commit ldb transaction (nesting: 0)
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [ldb] (9): start ldb transaction (nesting: 0)
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_group] (2): Group [group02] filtered out! (id out of range)
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_group] (2): Failed to save group [group02]
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_groups] (2): Failed to store group 0. Ignoring.
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_save_grpmem] (7): Adding member users to group [group02]
(Thu Mar 31 12:27:46 2011) [sssd[be[AD]]] [sdap_fill_memberships] (9): [IPA or AD Schema]

</snip>

Expected results:
"getent -s sss group group02" should return nothing since it's gid 20002 is less than the min_id set.

Additional info:

1. This works well against 389ds (rfc2307 schema).

2. # cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = AD

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 9

[pam]
reconnection_retries = 3

[domain/AD]
description = LDAP domain with AD server
debug_level = 9
enumerate = false
cache_credentials = False
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://pluto.sssdad.com
ldap_schema = rfc2307bis
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=sssdad,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = redhat_123
ldap_search_base = dc=sssdad,dc=com
ldap_user_object_class = person
ldap_user_name = cn
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = cn
ldap_force_upper_case_realm = True
min_id = 90000
Comment 2 Jakub Hrozek 2011-03-31 09:24:22 UTC 
Upstream ticket - https://fedorahosted.org/sssd/ticket/834
Comment 6 Kaushik Banerjee 2011-09-28 13:50:29 UTC 
Verified in version:

# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 52.el6                        Build Date: Tue 20 Sep 2011 09:11:03 PM IST
Install Date: Mon 26 Sep 2011 05:56:30 PM IST      Build Host: x86-010.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-52.el6.src.rpm
Size        : 3550647                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon
Comment 7 Jakub Hrozek 2011-10-26 16:15:09 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: When saving group memberships, SSSD uses a two-pass approach - save all the groups first and then save their members. When a group GID is outside a specifed range, the group should be skipped completely. SSSD correctly skipped the groups out of range during the save groups step, but then created the group anyway as a side-effect of the save  members step.
Consequence: SSSD did not filter groups whose GID was outside a specified range
Fix: The group save operation was changed so that only members of groups that were processed successfully are saved.
Result: SSSD correctly filters groups based on the min_id/max_id limits.
Comment 8 errata-xmlrpc 2011-12-06 16:38:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1529.html
Note You need to log in before you can comment on or make changes to this bug.