I'm experiencing problems on my RHEL 9 instance when looking up members of group using getent group <GROUP NAME>. I can only get users which has direct access to a group, and no the "user groups" part of the group.
My sssd.conf: [domain/<DOMAIN>] id_provider = ldap auth_provider = ldap chpass_provider = ldap sudo_provider = ldap
ldap_uri = ldaps:/ipa.example.com ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com
[sssd] services = nss, pam, sudo domains = default
[nss] homedir_substring = /home
[pam]
[sudo]
Finn,
with LDAP, recursively searching for all nested subgroups, sub-sub-groups, etc. -- that can be an expensive operation.
the default ldap_group_nesting_level is 2. You might try to set that to some larger number (like 5 or 6) to see if it makes any difference.
If you're connecting to AD, there's an optimization that's not expensive (to clients doing LDAP searches) called 'tokengroups'.
Spike White
On Thu, Jan 18, 2024 at 5:28 PM Finn Fysj finnfysj133@gmail.com wrote:
I'm experiencing problems on my RHEL 9 instance when looking up members of group using getent group <GROUP NAME>. I can only get users which has direct access to a group, and no the "user groups" part of the group.
My sssd.conf: [domain/<DOMAIN>] id_provider = ldap auth_provider = ldap chpass_provider = ldap sudo_provider = ldap
ldap_uri = ldaps:/ipa.example.com ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com
[sssd] services = nss, pam, sudo domains = default
[nss] homedir_substring = /home
[pam]
[sudo]
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
with LDAP, recursively searching for all nested subgroups, sub-sub-groups, etc. -- that can be an expensive operation.
the default ldap_group_nesting_level is 2. You might try to set that to some larger number (like 5 or 6) to see if it makes any difference.
So... We divide users into different teams (groups): e.g sysadmins, testers, etc. and then give these groups membership to other groups rather than the user directly. So, according to my understanding a nesting level of 2 should be enough?
However, when I run getent group testers, I don't get any results unless I give a specific user membership to that group.
What I want: IPA: group: sysadmins member: user1 member: user2 member: user3 group: prod member: sysadmins
getent group prod prod:<GID>: user1,user2,user3
If you're connecting to AD, there's an optimization that's not expensive (to clients doing LDAP searches) called 'tokengroups'.
IPA is being used as out LDAP server.
It's working for my old clients using nlscd and nscd, but not for newer using SSSD...
Hi,
On Fri, Jan 19, 2024 at 10:03 AM Finn Fysj finnfysj133@gmail.com wrote:
with LDAP, recursively searching for all nested subgroups, sub-sub-groups, etc. -- that can be an expensive operation.
the default ldap_group_nesting_level is 2. You might try to set that to some larger number (like 5 or 6) to see if it makes any difference.
So... We divide users into different teams (groups): e.g sysadmins, testers, etc. and then give these groups membership to other groups rather than the user directly. So, according to my understanding a nesting level of 2 should be enough?
However, when I run getent group testers, I don't get any results unless I give a specific user membership to that group.
What I want: IPA: group: sysadmins member: user1 member: user2 member: user3 group: prod member: sysadmins
getent group prod prod:<GID>: user1,user2,user3
If you're connecting to AD, there's an optimization that's not expensive (to clients doing LDAP searches) called 'tokengroups'.
IPA is being used as out LDAP server.
IPA doesn't show member attribute for non-authenticated binds
Typically users are interested in the correct group list the user is a member of. On the other side, 'ignore_group_members = true' is used often for performance reasons. Why do you care about 'getent group' and why don't you use "id_provider=ipa"?
IPA doesn't show member attribute for non-authenticated binds
As mentioned this works for older hosts not using SSSD...
Typically users are interested in the correct group list the user is a member of. On the other side, 'ignore_group_members = true' is used often for performance reasons.
How will this help?
Why do you care about 'getent group' and why don't you use "id_provider=ipa"?
getent group, will let me know which user is member of the group, which again let the user access a specific instance... We're using it as LDAP server.
On Fri, Jan 19, 2024 at 11:56 AM Finn Fysj finnfysj133@gmail.com wrote:
IPA doesn't show member attribute for non-authenticated binds
As mentioned this works for older hosts not using SSSD...
Typically users are interested in the correct group list the user is a member of. On the other side, 'ignore_group_members = true' is used often for performance reasons.
How will this help?
I meant to say users typically didn't care about 'getent group' (`getgrnam()`/`getgruid()`) output.
Why do you care about 'getent group' and why don't you use "id_provider=ipa"?
getent group, will let me know which user is member of the group, which again let the user access a specific instance...
When it gets to DAC, `getgrouplist()` (initgroups list) is what matters.
Does this work properly, i.e. does `id user1` returns all expected groups?
On Fri, Jan 19, 2024 at 11:56 AM Finn Fysj <finnfysj133(a)gmail.com> wrote:
I meant to say users typically didn't care about 'getent group' (`getgrnam()`/`getgruid()`) output.
When it gets to DAC, `getgrouplist()` (initgroups list) is what matters.
Does this work properly, i.e. does `id user1` returns all expected groups?
For old systems not using SSSD (nslcd & nscd), this works. I can run id <UID> and get returned expected groups. This is not the case for systems using SSSD.
On Fri, Jan 19, 2024 at 11:56 AM Finn Fysj <finnfysj133(a)gmail.com> wrote:
I meant to say users typically didn't care about 'getent group' (`getgrnam()`/`getgruid()`) output.
When it gets to DAC, `getgrouplist()` (initgroups list) is what matters.
Does this work properly, i.e. does `id user1` returns all expected groups?
For old systems not using SSSD (nslcd & nscd), this works. I can run id <UID> and get returned expected groups. This is not the case for systems (rhel9) using SSSD.
On Fri, Jan 19, 2024 at 12:39 PM Finn Fysj finnfysj133@gmail.com wrote:
When it gets to DAC, `getgrouplist()` (initgroups list) is what matters.
Does this work properly, i.e. does `id user1` returns all expected groups?
For old systems not using SSSD (nslcd & nscd), this works. I can run id <UID> and get returned expected groups. This is not the case for systems (rhel9) using SSSD.
Well, to debug this one needs: - stop sssd - remove old sssd logs (/var/log/sssd/) - set 'debug_level = 9' in [nss] and domain sections of sssd.conf - start sssd - date; id UID - capture logs
Then `sssctl analyze --logdir . request list` - it will list 'id' - it will list something like "... [uid 0] CID #1: id" And `sssctl analyze --logdir . request show --merge 1` (where 1 is from CID #1) will show all log messages related to this lookup.
Not an easy read, though...
Well, to debug this one needs:
- stop sssd
- remove old sssd logs (/var/log/sssd/)
- set 'debug_level = 9' in [nss] and domain sections of sssd.conf
- start sssd
- date; id UID
- capture logs
I can't pinpoint the problem, example from sssd_nss.log: (2024-01-21 16:32:33): [nss] [sss_ncache_check_str] (0x2000): [CID#32926] Checking negative cache for [NCE/GROUP/default/prod-users@default] (2024-01-21 16:32:33): [nss] [cache_req_search_done] (0x0400): [CID#32926] CR #294846: Returning updated object [GID:650612@default] (2024-01-21 16:32:33): [nss] [cache_req_create_and_add_result] (0x0400): [CID#32926] CR #294846: Found 1 entries in domain default (2024-01-21 16:32:33): [nss] [cache_req_done] (0x0400): [CID#32926] CR #294846: Finished: Success (2024-01-21 16:32:33): [nss] [sss_ncache_check_str] (0x2000): [CID#32926] Checking negative cache for [NCE/USER/default/user1@default] (2024-01-21 16:32:33): [nss] [sss_domain_get_state] (0x1000): [CID#32926] Domain default is Active (2024-01-21 16:32:33): [nss] [sss_ncache_check_str] (0x2000): [CID#32926] Checking negative cache for [NCE/USER/default/user2@default]
The reason I get these two users is because they are direct members of the group: prod-users. I'm missing a user3, which is member of a group "devs", which is again member of prod-user:
IPA groups: prod-users: users: member: user1 member: user2 groups: member: devs
devs: users: member: user3
Then `sssctl analyze --logdir . request list` - it will list 'id' - it will list something like "... [uid 0] CID #1: id" And `sssctl analyze --logdir . request show --merge 1` (where 1 is from CID #1) will show all log messages related to this lookup.
sssctl analyze didn't give anything that seemed interesting.
I just don't understand what I'm missing and why sssd is not able to fetch it like nss-pam-ldapd.
On Fri, Jan 19, 2024 at 12:39 PM Finn Fysj <finnfysj133(a)gmail.com> wrote:
Well, to debug this one needs:
- stop sssd
- remove old sssd logs (/var/log/sssd/)
- set 'debug_level = 9' in [nss] and domain sections of sssd.conf
- start sssd
- date; id UID
- capture logs
Then `sssctl analyze --logdir . request list` - it will list 'id' - it will list something like "... [uid 0] CID #1: id" And `sssctl analyze --logdir . request show --merge 1` (where 1 is from CID #1) will show all log messages related to this lookup.
Not an easy read, though...
Looking furher into sssd_default.log: (2024-01-21 16:34:40): [be[default]] [sysdb_store_group] (0x0400): [RID#31] Group "prod-users@default" has been stored (2024-01-21 16:34:40): [be[default]] [sdap_save_groups] (0x4000): [RID#31] Group 0 processed! (2024-01-21 16:34:40): [be[default]] [sdap_attrs_get_sid_str] (0x1000): [RID#31] No [objectSID] attribute. [0][Success] (2024-01-21 16:34:40): [be[default]] [sdap_save_grpmem] (0x0400): [RID#31] Failed to get group sid (2024-01-21 16:34:40): [be[default]] [sdap_get_primary_name] (0x0400): [RID#31] Processing object prod-users (2024-01-21 16:34:40): [be[default]] [sdap_save_grpmem] (0x0400): [RID#31] Processing group prod-users@default (2024-01-21 16:34:40): [be[default]] [sdap_save_grpmem] (0x0400): [RID#31] Adding member users to group [prod-users@default] (2024-01-21 16:34:40): [be[default]] [sdap_find_entry_by_origDN] (0x4000): [RID#31] Searching cache for [uid=user1,cn=users,cn=accounts,dc=example,dc=com]. (2024-01-21 16:34:40): [be[default]] [sdap_fill_memberships] (0x1000): [RID#31] member #0 (uid=user1,cn=users,cn=accounts,dc=example,dc=com): [name=user1@default,cn=users,cn=default,cn=sysdb] (2024-01-21 16:34:40): [be[default]] [sdap_find_entry_by_origDN] (0x4000): [RID#31] Searching cache for [cn=prod-users,cn=groups,cn=accounts,dc=example,dc=com]. (2024-01-21 16:34:40): [be[default]] [sdap_fill_memberships] (0x0080): [RID#31] Member [cn=devs,cn=groups,cn=accounts,dc=example,dc=com] was not found in cache. Is it out of scope? (2024-01-21 16:34:40): [be[default]] [sdap_find_entry_by_origDN] (0x4000): [RID#31] Searching cache for [uid=user2,cn=users,cn=accounts,dc=example,dc=com]. (2024-01-22 16:34:40): [be[default]] [sdap_fill_memberships] (0x1000): [RID#31] member #2 (uid=user2,cn=users,cn=accounts,dc=example,dc=com): [name=user2@default,cn=users,cn=default,cn=sysdb]
It's important to note that the groups "devs" is a NON-Posix group in FreeIPA. However, as preivously stated, this works with nss-pam-ldapd.
sssd-users@lists.fedorahosted.org