Hide Forgot
Description of problem: Unable to enumerate rfc2307bis group with non-default attribute names. Version-Release number of selected component (if applicable): sssd-1.5.1-47.el6 How reproducible: Always Steps to Reproduce: 1. Setup a ldap schema with non-default attribute names and add a user using those attribute names: Add a user-group with the following attributes: dn: uid=kau12,dc=example,dc=com objectClass: account objectClass: posixAccount1 cn1: kaushik12 uid1: kau12 uidNumber1: 121212 gidNumber1: 121212 homeDirectory1: /home/kau12 loginShell1: /bin/tcsh gecos1: GECOS TEST userPassword: XXXXX dn: cn=kau12_grp1,dc=example,dc=com gidNumber1: 121212 objectClass: extensibleObject objectClass: groupOfNames1 member1: uid=kau12,dc=example,dc=com cn1: kau12_grp1 2. Setup sssd with the following in domain section: [domain/LDAP] debug_level=9 id_provider = ldap ldap_tls_cacert=/etc/openldap/cacerts/server.pem ldap_uri = ldap://<ldap-server> ldap_search_base = dc=example,dc=com ldap_user_object_class = posixAccount1 ldap_user_name = uid1 ldap_user_uid_number = uidNumber1 ldap_user_gid_number = gidNumber1 ldap_user_gecos = gecos1 ldap_user_home_directory = homeDirectory1 ldap_user_shell = loginShell1 ldap_group_gid_number = gidNumber1 ldap_user_fullname = cn1 ldap_group_name = cn1 ldap_schema = rfc2307bis ldap_group_object_class = groupOfNames1 ldap_group_member = member1 3. Enumerate the user: # id kau12 uid=121212(kau12) gid=121212 groups=121212 4. Enumerate the group # getent -s sss group kau12_grp1 # Actual results: Unable to enumerate group /var/log/sssd/sssd_LDAP.log shows: <snip> (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(cn1=kau12_grp1)(objectclass=groupOfNames1)(cn1=*)(&(gidNumber1=*)(!(gidNumber1=0))))][dc=example,dc=com]. (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [objectClass] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [cn1] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [userPassword] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [gidNumber1] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [member1] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [nsUniqueId] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [modifyTimestamp] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_step] (8): ldap_search_ext called, msgid = 3 (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_id_op_connect_done] (9): caching successful connection after 1 notifies (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [cn=kau12_grp1,dc=example,dc=com]. (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x81432a8], connected[1], ops[0x814cb58], ldap[0x81433b0] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_generic_done] (7): Total count [0] (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_get_groups_process] (6): Search for groups, returned 1 results. (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_nested_group_process_send] (9): The group's gid was missing (Tue Aug 23 06:03:44 2011) [sssd[be[LDAP]]] [sdap_nested_group_process_send] (8): Marking group as non-posix and setting GID=0! </snip> Expected results: Enumeration of the group should work. Additional info:
Upstream ticket: https://fedorahosted.org/sssd/ticket/983
Kaushik, is this the issue that was solved by the scratch build I gave you? If so, then it is already fixed upstream (#975).
(In reply to comment #3) > Kaushik, is this the issue that was solved by the scratch build I gave you? If > so, then it is already fixed upstream (#975). Yes. The issue was solved with the scratch build. The bug was logged to track the issue on rhel6.2 build.
Verified in version: # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 51.el6 Build Date: Mon 12 Sep 2011 06:55:14 PM IST Install Date: Tue 13 Sep 2011 08:02:21 PM IST Build Host: x86-001.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-51.el6.src.rpm Size : 3670464 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon
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: SSSD uses internal cache to store all entities retrieved from server. Attributes of these entities can have different name in the cache and remote server. In couple cases, SSSD used attribute names for the remote server instead of names for local cache. Consequence: When non-default attribute names were used either for group GID or name, all groups were processed and stored to the cache incorrectly, thus not returned to NSS client. Fix: Cache attribute names are now correctly used when processing groups retrieved from server. Result: Groups retrieved from servers with non-standard attribute names are stored and returned correctly.
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