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 2164852 - man page entry should make clear that a nested group needs a name
Summary: man page entry should make clear that a nested group needs a name
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: sssd
Version: 9.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: jstephen
QA Contact: Anuj Borah
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-26 16:49 UTC by Ondrej
Modified: 2023-11-07 11:32 UTC (History)
7 users (show)

Fixed In Version: sssd-2.9.0-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2164805
Environment:
Last Closed: 2023-11-07 08:54:17 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 6544 0 None open AD: Nested group processing can fail or return invalid members (security issue) 2023-01-27 18:35:32 UTC
Red Hat Issue Tracker RHELPLAN-146592 0 None None None 2023-01-26 16:53:02 UTC
Red Hat Issue Tracker SSSD-5552 0 None None None 2023-01-27 11:45:08 UTC
Red Hat Product Errata RHBA-2023:6644 0 None None None 2023-11-07 08:54:35 UTC

Description Ondrej 2023-01-26 16:49:09 UTC 
+++ This bug was initially created as a clone of Bug #2164805 +++

Description of problem:
[root@slsrvmongr-01v ~]# getent group acacia
[root@slsrvmongr-01v ~]# id -a ovalouse
uid=62133(ovalouse) gid=27263 groups=27263,11030(acacia),1000(admins),12167(adesto2dialog)

- first command suggests group acacia is empty
- second suggests user 'ovalouse' is member

The problem does not occur for direct group members, only for indirect (i.e. "acacia" group has a member different group where "ovalouse" is member of).


Version-Release number of selected component (if applicable):
2.7.3

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:
getent <group> is missing nested members

Expected results:
id -a <username> and getent group <group> provide coherent output

Additional info:
Getting something wrong in the logs:
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_group_single_step_process] (0x0040): [RID#20] Unknown entry type [CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]!
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_group_single_step_done] (0x0020): [RID#20] Error processing direct membership [22]: Invalid argument
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_done] (0x0020): [RID#20] Nested group processing failed: [22][Invalid argument]


My config:
[sssd]
services = autofs, nss, pam, ifp
config_file_version = 2
debug_level = 7

domains = diasemi
[nss]

[domain/diasemi]
debug_level = 9
ldap_id_mapping = False
ad_domain = DIASEMI.COM
ad_enabled_domains = diasemi.com
id_provider = ad
auth_provider = ad
chpass_provider = ad
autofs_provider = ad
ad_enable_gc = False
cache_credentials = True
krb5_realm = DIASEMI.COM
krb5_canonicalize = False
ldap_user_name = uid
ldap_group_name = displayName
krb5_renew_interval = 3600
# request renewable Kerberos tickets
krb5_renewable_lifetime = 30d
ldap_sasl_mech = GSSAPI
ldap_referrals = False
ldap_autofs_search_base = OU=sl,OU=SSSD,OU=Unix,OU=Global,DC=diasemi,DC=com
fallback_homedir = /users/%u
default_shell = /bin/bash
# auto_private_groups = true
# ldap_use_tokengroups = false

[ifp]
user_attributes = +mail
Comment 1 Sumit Bose 2023-01-26 17:06:25 UTC 
Hi,

can you check if setting `ldap_ignore_unreadable_references = True` in the [domain/..] section helps?

bye,
Sumit
Comment 2 Ondrej 2023-01-26 17:17:56 UTC 
It did help - now it behaves just like the RHEL-8 (bug #2164805)
Note user 'ovalouse' is member of the PROJ_acacia_read group SSSD is complaining about.
Comment 3 Sumit Bose 2023-01-26 18:43:39 UTC 
Hi,

can you send a bit more log context especially the part coming before the snippet you have already send, ideally everything with the '[RID#20]' tag and the lines in between. It looks like the credentials used by SSSD to connect to AD have no permissions to read the the LDAP object of group PROJ_acacia_read.

bye,
Sumit
Comment 4 Ondrej 2023-01-27 07:43:47 UTC 
Hi,

It's very unlikely the permissions would not be sufficient, as they are obviously sufficient for the top group (PROJ_acacia).
Anyway, here is the full log:

(2023-01-26 16:37:46): [be[diasemi]] [dp_get_account_info_send] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=acacia@diasemi]
(2023-01-26 16:37:46): [be[diasemi]] [dp_attach_req] (0x0400): [RID#20] DP Request [Account #20]: REQ_TRACE: New request. [sssd.nss CID #23] Flags [0x0001].
(2023-01-26 16:37:46): [be[diasemi]] [dp_attach_req] (0x0400): [RID#20] Number of active DP request: 1
(2023-01-26 16:37:46): [be[diasemi]] [sss_domain_get_state] (0x1000): [RID#20] Domain diasemi is Active
(2023-01-26 16:37:46): [be[diasemi]] [sss_domain_get_state] (0x1000): [RID#20] Domain diasemi is Active
(2023-01-26 16:37:46): [be[diasemi]] [sdap_id_op_connect_step] (0x4000): [RID#20] reusing cached connection
(2023-01-26 16:37:46): [be[diasemi]] [get_ldap_conn_from_sdom_pvt] (0x4000): [RID#20] Returning LDAP connection for user lookup.
(2023-01-26 16:37:46): [be[diasemi]] [sdap_id_op_connect_step] (0x4000): [RID#20] reusing cached connection
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_groups_next_base] (0x0400): [RID#20] Searching for groups with base [DC=diasemi,DC=com]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_print_server] (0x2000): [RID#20] Searching 10.54.16.33:389
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x0400): [RID#20] calling ldap_search_ext with [(&(displayName=acacia)(objectClass=group)(displayName=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=diasemi,DC=com].
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectClass]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [displayName]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [gidNumber]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [member]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectGUID]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectSID]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [whenChanged]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [uSNChanged]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [groupType]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x2000): [RID#20] ldap_search_ext called, msgid = 8
(2023-01-26 16:37:46): [be[diasemi]] [sdap_op_add] (0x2000): [RID#20] New operation 8 timeout 6
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c0605232c0], ldap[0x55c060510030]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_message] (0x4000): [RID#20] Message type: [LDAP_RES_SEARCH_ENTRY]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_call_op_callback] (0x20000): [RID#20] Handling LDAP operation [8][server: [10.54.16.33:389] filter: [(&(displayName=acacia)(objectClass=group)(displayName=*)(&(gidNumber=*)(!(gidNumber=0))))] base: [DC=diasemi,DC=com]] took [135.356] milliseconds.
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_entry] (0x1000): [RID#20] OriginalDN: [CN=PROJ_acacia,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com].
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [objectClass]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [member]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [whenChanged]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [displayName]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [uSNChanged]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [objectGUID]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [objectSid]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [groupType]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_parse_range] (0x2000): [RID#20] No sub-attributes for [gidNumber]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c0605232c0], ldap[0x55c060510030]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_message] (0x4000): [RID#20] Message type: [LDAP_RES_SEARCH_REFERENCE]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_add_references] (0x1000): [RID#20] Additional References: ldap://diasemi.com/CN=Configuration,DC=diasemi,DC=com
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c0605232c0], ldap[0x55c060510030]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_message] (0x4000): [RID#20] Message type: [LDAP_RES_SEARCH_RESULT]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_op_finished] (0x0400): [RID#20] Search result: Success(0), no errmsg set
(2023-01-26 16:37:46): [be[diasemi]] [sdap_op_destructor] (0x2000): [RID#20] Operation 8 finished
(2023-01-26 16:37:46): [be[diasemi]] [generic_ext_search_handler] (0x4000): [RID#20] Request included referrals which were ignored.
(2023-01-26 16:37:46): [be[diasemi]] [generic_ext_search_handler] (0x4000): [RID#20]     Ref: ldap://diasemi.com/CN=Configuration,DC=diasemi,DC=com
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_groups_process] (0x0400): [RID#20] Search for groups, returned 1 results.
(2023-01-26 16:37:46): [be[diasemi]] [sdap_has_deref_support_ex] (0x0400): [RID#20] The server supports deref method ASQ
(2023-01-26 16:37:46): [be[diasemi]] [sdap_check_ad_group_type] (0x4000): [RID#20] AD group [] has type flags 0x80000002.
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_hash_insert] (0x4000): [RID#20] Inserting [CN=PROJ_acacia,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com] into hash table [groups]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_process_send] (0x2000): [RID#20] About to process group [CN=PROJ_acacia,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_users] (0x2000): [RID#20] Search users with filter: (&(objectCategory=user)(originalDN=CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com))
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_users] (0x2000): [RID#20] No such entry
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_groups] (0x2000): [RID#20] Search groups with filter: (&(objectCategory=group)(originalDN=CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com))
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_groups] (0x2000): [RID#20] No such entry
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_split_members] (0x4000): [RID#20] [CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com] is unknown object
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_users] (0x2000): [RID#20] Search users with filter: (&(objectCategory=user)(originalDN=CN=PROJ_acacia_write,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com))
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_users] (0x2000): [RID#20] No such entry
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_groups] (0x2000): [RID#20] Search groups with filter: (&(objectCategory=group)(originalDN=CN=PROJ_acacia_write,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com))
(2023-01-26 16:37:46): [be[diasemi]] [sysdb_cache_search_groups] (0x2000): [RID#20] No such entry
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_split_members] (0x4000): [RID#20] [CN=PROJ_acacia_write,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com] is unknown object
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_process_send] (0x2000): [RID#20] Looking up 2/2 members of group [CN=PROJ_acacia,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_nested_group_process_send] (0x2000): [RID#20] Members of group [CN=PROJ_acacia,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com] will be processed individually
(2023-01-26 16:37:46): [be[diasemi]] [sdap_print_server] (0x2000): [RID#20] Searching 10.54.16.33:389
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x0400): [RID#20] calling ldap_search_ext with [(objectclass=user)][CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com].
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectClass]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [uid]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_get_generic_ext_step] (0x2000): [RID#20] ldap_search_ext called, msgid = 9
(2023-01-26 16:37:46): [be[diasemi]] [sdap_op_add] (0x2000): [RID#20] New operation 9 timeout 6
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c06052d220], ldap[0x55c060510030]
(2023-01-26 16:37:46): [be[diasemi]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c06052d220], ldap[0x55c060510030]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_message] (0x4000): [RID#20] Message type: [LDAP_RES_SEARCH_RESULT]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_call_op_callback] (0x20000): [RID#20] Handling LDAP operation [9][server: [10.54.16.33:389] filter: [(objectclass=user)] base: [CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]] took [138.487] milliseconds.
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_op_finished] (0x0400): [RID#20] Search result: Success(0), no errmsg set
(2023-01-26 16:37:47): [be[diasemi]] [sdap_op_destructor] (0x2000): [RID#20] Operation 9 finished
(2023-01-26 16:37:47): [be[diasemi]] [sdap_print_server] (0x2000): [RID#20] Searching 10.54.16.33:389
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x0400): [RID#20] calling ldap_search_ext with [(&(objectClass=group)(displayName=*))][CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com].
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectClass]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [displayName]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [gidNumber]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [member]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectGUID]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [objectSID]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [whenChanged]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [uSNChanged]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x1000): [RID#20] Requesting attrs: [groupType]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_ext_step] (0x2000): [RID#20] ldap_search_ext called, msgid = 10
(2023-01-26 16:37:47): [be[diasemi]] [sdap_op_add] (0x2000): [RID#20] New operation 10 timeout 6
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c060456000], ldap[0x55c060510030]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_result] (0x2000): Trace: sh[0x55c0605f90b0], connected[1], ops[0x55c060456000], ldap[0x55c060510030]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_process_message] (0x4000): [RID#20] Message type: [LDAP_RES_SEARCH_RESULT]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_call_op_callback] (0x20000): [RID#20] Handling LDAP operation [10][server: [10.54.16.33:389] filter: [(&(objectClass=group)(displayName=*))] base: [CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]] took [134.896] milliseconds.
(2023-01-26 16:37:47): [be[diasemi]] [sdap_get_generic_op_finished] (0x0400): [RID#20] Search result: Success(0), no errmsg set
(2023-01-26 16:37:47): [be[diasemi]] [sdap_op_destructor] (0x2000): [RID#20] Operation 10 finished
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_group_single_step_process] (0x0040): [RID#20] Unknown entry type [CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com]!
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_group_single_step_done] (0x0020): [RID#20] Error processing direct membership [22]: Invalid argument
(2023-01-26 16:37:47): [be[diasemi]] [sdap_nested_done] (0x0020): [RID#20] Nested group processing failed: [22][Invalid argument]
(2023-01-26 16:37:47): [be[diasemi]] [sdap_id_op_destroy] (0x4000): [RID#20] releasing operation connection
(2023-01-26 16:37:47): [be[diasemi]] [sdap_id_op_done] (0x4000): [RID#20] releasing operation connection
(2023-01-26 16:37:47): [be[diasemi]] [ad_account_info_done] (0x0040): [RID#20] ad_handle_acct_info_recv failed [22]: Invalid argument
(2023-01-26 16:37:47): [be[diasemi]] [dp_req_done] (0x0400): [RID#20] DP Request [Account #20]: Request handler finished [0]: Success
(2023-01-26 16:37:47): [be[diasemi]] [dp_req_done] (0x20000): [RID#20] DP Request [Account #20]: Handling request took [409.917] milliseconds.
(2023-01-26 16:37:47): [be[diasemi]] [_dp_req_recv] (0x0400): [RID#20] DP Request [Account #20]: Receiving request data.
(2023-01-26 16:37:47): [be[diasemi]] [dp_req_destructor] (0x0400): [RID#20] DP Request [Account #20]: Request removed.
(2023-01-26 16:37:47): [be[diasemi]] [dp_req_destructor] (0x0400): [RID#20] Number of active DP request: 0
(2023-01-26 16:37:47): [be[diasemi]] [dp_req_reply_std] (0x1000): [RID#20] DP Request [Account #20]: Returning [Internal Error]: 3,0,Group lookup failed
(2023-01-26 16:37:47): [be[diasemi]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
Comment 5 Sumit Bose 2023-01-27 09:33:35 UTC 
Hi,

does the LDAP object of the PROJ_acacia_read group `CN=PROJ_acacia_read,OU=ProjectGroups,OU=Groups,OU=Global,DC=diasemi,DC=com` have the `displayName` attribute set?

bye,
Sumit
Comment 6 Ondrej 2023-01-27 09:48:44 UTC 
No, they do not - and that should not be required for the nested group processing, correct?
Comment 7 Sumit Bose 2023-01-27 10:01:04 UTC 
Hi,

you have set 'ldap_group_name = displayName' in sssd.conf which currently makes it a required attribute at least for SSSD.

bye,
Sumit
Comment 8 Ondrej 2023-01-27 10:57:54 UTC 
Hi,

Ok, that's an interesting side effect I was not aware of. Perhaps it would be good to mention it somewhere in the manual.
The reason for 'ldap_group_name = displayName' is that we can't use the default 'samaccountName' as Windows group names are not identical to Unix ones in our environment - and hence I picked (currently unused) displayName attribute to keep the Unix name.

So I have to fill in displayName with something to keep SSSD happy.

Long term, I would say the behavior is bit misleading at least - because it's just sufficient to populate displayName keeping gidNumber empty.
So I would vote for either fixing this or at least explain it somewhere in the manual.

Anyway, I can confirm this workaround works for me for both RHEL-8 and RHEL-9 - Thanks for the quick help!
Comment 9 Sumit Bose 2023-01-27 11:42:46 UTC 
Hi,

glad to hear it is working for you. The reason why the name is needed is that SSSD somewhat mimics the original nested group hierarchy in its cache so that the group-memberships can be updated if a group in the middle of the hierarchy is removed. And the group name is used as the name of the cache object as well. But the group which connects the user with the POSIX group must not be a POSIX group and so the gidNumber is not required. I agree that it would be good to have this information in the man page.


bye,
Sumit
Comment 10 Ondrej 2023-01-27 16:30:55 UTC 
Further update/question:
Setting the attribute 'displayName' (in my case) for all nested groups to something like 'sssd' or 'delete-me' is obviously not sufficient as the name has to be unique across the whole Directory (pretty much like sAMAccountName is).

If it is not unique (and 'displayName' does NOT have to be unique), then SSSD nested group enumeration can (and probably will) fail miserably even possibly offering wrong group members which can even be a security issue.

Can you confirm?
Comment 11 Sumit Bose 2023-01-27 16:48:31 UTC 
(In reply to Ondrej from comment #10)
> Further update/question:
> Setting the attribute 'displayName' (in my case) for all nested groups to
> something like 'sssd' or 'delete-me' is obviously not sufficient as the name
> has to be unique across the whole Directory (pretty much like sAMAccountName
> is).
> 
> If it is not unique (and 'displayName' does NOT have to be unique), then
> SSSD nested group enumeration can (and probably will) fail miserably even
> possibly offering wrong group members which can even be a security issue.
> 
> Can you confirm?

Hi,

yes, SSSD expects that group names of different groups are unique.

bye,
Sumit
Comment 12 Ondrej 2023-01-27 17:18:32 UTC 
Upstream report:
https://github.com/SSSD/sssd/issues/6544
Comment 13 Alexey Tikhonov 2023-02-03 17:16:17 UTC 
Upstream PR: https://github.com/SSSD/sssd/pull/6562
Comment 14 Alexey Tikhonov 2023-02-09 13:28:40 UTC 
Pushed PR: https://github.com/SSSD/sssd/pull/6562

* `master`
    * 4138b0a732d30ef1eec7380e73e817e3d86e704d - MAN: ldap_group_name enhancement with nested groups
Comment 20 errata-xmlrpc 2023-11-07 08:54:17 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 (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2023:6644
Note You need to log in before you can comment on or make changes to this bug.