Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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

Summary:	man page entry should make clear that a nested group needs a name
Product:	Red Hat Enterprise Linux 9	Reporter:	Ondrej <ondrej.valousek.xm>
Component:	sssd	Assignee:	jstephen
Status:	CLOSED ERRATA	QA Contact:	Anuj Borah <aborah>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.1	CC:	aborah, atikhono, pasik, pbrezina, sbose, sgadekar, sssd-qe
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sync-to-jira
Fixed In Version:	sssd-2.9.0-1.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2164805	Environment:
Last Closed:	2023-11-07 08:54:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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