Bug 692404

Summary: rfc2307bis groups are being enumerated even when the gidNumber is out of the range of min_id,max_id.
Product: Red Hat Enterprise Linux 6 Reporter: Kaushik Banerjee <kbanerje>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: benl, dpal, grajaiya, jgalipea, jhrozek, prc
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of:
: 692455 (view as bug list) Environment:
Last Closed: 2011-12-06 16:38:05 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: 692455    

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