sssd unable to get group info from LDAP with: Error in initgroups: [22][Invalid argument]

[srcc-chekh]

working client system is Ubuntu 20.04 LTS with standard sssd packages version 2.2.3-3ubuntu0.12

non-working client test system is stock Ubuntu 22.04.2 LTS with the regular Ubuntu sssd packages version 2.6.3-1ubuntu3.2

Our setup has AD and then slapd proxies, so the Linux clients are just doing plain LDAP lookups from the proxies, no direct AD connections.

The problem seems very similar to this: https://buildingtents.com/2021/09/12/sssd-with-active-directory-only-showing-primary-group/ or to this: https://bugzilla.redhat.com/show_bug.cgi?id=1127265 or to this: https://bugzilla.redhat.com/show_bug.cgi?id=1105561#c15

But not an exact match.

The main error message seems to be:

(2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_get_generic_op_finished] (0x0400): [RID#7] Search result: Success(0), no errmsg set (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_get_generic_op_finished] (0x2000): [RID#7] Total count [0] (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_op_destructor] (0x2000): [RID#7] Operation 8 finished (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_initgr_rfc2307bis_process] (0x1000): [RID#7] Found 12 parent groups for user [alex@calicolabs.local] (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [rfc2307bis_nested_groups_send] (0x2000): [RID#7] About to process 12 groups in nesting level 0 (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sysdb_attrs_primary_name] (0x0020): [RID#7] Could not determine primary name: [22][Invalid argument] (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_get_primary_name] (0x0020): [RID#7] The object has no name attribute (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_done] (0x4000): [RID#7] Initgroups done (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_done] (0x4000): [RID#7] Error in initgroups: [22][Invalid argument] (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_id_op_destroy] (0x4000): [RID#7] releasing operation connection (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [sdap_id_op_done] (0x4000): [RID#7] releasing operation connection (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [dp_req_done] (0x0400): [RID#7] DP Request [Initgroups #7]: Request handler finished [0]: Success (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [_dp_req_recv] (0x0400): [RID#7] DP Request [Initgroups #7]: Receiving request data. (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [dp_req_destructor] (0x0400): [RID#7] DP Request [Initgroups #7]: Request removed. (2023-07-21 20:56:28): [be[CALICOLABS.LOCAL]] [dp_req_destructor] (0x0400): [RID#7] Number of active DP request: 0

I read through this page https://docs.pagure.org/sssd.sssd/users/troubleshooting.html I tried changing various attributes but none seem to have any effect in our basic configuration. ldap_schema = ad or default ldap_group_search_base = ou=Groups,dc=calicolabs,dc=local or just dc=calicolabs,dc=local enumeration = true or false

On the working systems, the sssd client lists the user groups from AD as expected, e.g. root@gpu8:~# id alex uid=12894(alex) gid=10513(Domain Users) groups=10513(Domain Users),<8 other AD groups>

On the non-working test system, the sssd client cannot get the group info root@cb2-alex-test-sssd:/var/log/sssd# id alex uid=12894(alex) gid=10513 groups=10513

Here is the entire sssd.conf, pretty much nothing site-specific except the domain name:

[sssd] services = nss, pam config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 domains = CALICOLABS.LOCAL

[nss] reconnection_retries = 3 homedir_substring = /home fallback_homedir = /home/%u default_shell = /bin/bash filter_groups = root filter_users = root,bin,adm,lp,nobody,avahi-autoipd,dbus,polkitd,sssd,nagios debug_level = 4

[domain/CALICOLABS.LOCAL] debug_level = 9 enumerate = True min_id = 1000 entry_cache_timeout = 600 ldap_network_timeout = 1

ldap_referrals = False

id_provider = ldap access_provider = ldap auth_provider = ldap selinux_provider = none

ldap_access_filter = (&(objectClass=user)(objectClass=group)(!(objectClass=computer)))

krb5_realm = CALICOLABS.LOCAL dns_discovery_domain = CALICOLABS.LOCAL

ldap_schema = ad ldap_id_mapping = True ldap_idmap_autorid_compat = True ldap_idmap_range_min = 10000

ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = True ldap_search_base = dc=calicolabs,dc=local

ldap_uri = ldaps://cb-proxy, ldaps://cb-login, ldaps://cb-admin ldap_tls_reqcert = allow ldap_id_use_start_tls = false

ldap_user_object_class = user ldap_user_search_base = cn=users,dc=calicolabs,dc=local ldap_user_name = uid ldap_user_home_directory = unixhomeDirectory ldap_user_principal = userPrincipalName

ldap_group_object_class = group ldap_group_search_base = dc=calicolabs,dc=local

ldap_default_authtok_type = password

How do I drill further down into these errors? I have also seen (2023-07-21 21:46:57): [be[CALICOLABS.LOCAL]] [dp_req_reply_std] (0x1000): [RID#4] DP Request [Initgroups #4]: Returning [Internal Error]: 3,22,Init group lookup failed

[srcc-chekh]

I took another stab at it. I found this description here https://sssd.io/troubleshooting/ad_provider.html "Cases like this are best debugged from an empty cache. Check if the group GID appears in the output of id -G first. In case the group is not present in the id -G output at all, there is something up with the initgroups part. Check the schema and look for anything strange during the initgr operation in SSSD back end logs. If the group is present in id -G output but not in id output (or a subsequent id output) then there’s something wrong with resolving the group GIDs with getgrgid()."

Here are the relevant logs

(2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_send] (0x4000): [RID#5] Retrieving info for initgroups call (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_next_base] (0x0400): [RID#5] Searching for users with base [cn=users,dc=calicolabs,dc=local] (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_user] (0x4000): [RID#5] Receiving info for the user (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_user] (0x4000): [RID#5] Storing the user (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_user] (0x4000): [RID#5] Commit change (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_user] (0x4000): [RID#5] Process user's groups (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_initgr_rfc2307bis_next_base] (0x0400): [RID#5] Searching for parent groups for user [cn=Alex Chekholko,cn=Users,dc=calicolabs,dc=local] with base [dc=calicolabs,dc=local] (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_initgr_rfc2307bis_process] (0x1000): [RID#5] Found 12 parent groups for user [alex@calicolabs.local] (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_done] (0x4000): [RID#5] Initgroups done (2023-07-25 21:54:47): [be[CALICOLABS.LOCAL]] [sdap_get_initgr_done] (0x4000): [RID#5] Error in initgroups: [22][Invalid argument]

[sumit-bose]

Hi,

could you send the full debug logs with debug_level = 9 in the [domain/...] section of sssd.conf covering a getent group GID_OF_BROKEN_GROUP? Additionally it would be good to see the full LDAP entry of the group object from the proxy, e.g. the output of ldapsearch.

bye, Sumit

[srcc-chekh]

Thanks for your response. The main and only error line seems to be "(2023-08-25 16:31:33): [be[CALICOLABS.LOCAL]] [sysdb_attrs_primary_name] (0x0020): [RID#5] Could not determine primary name: [22][Invalid argument]"

I picked one group (none work) and attach the ldapsearch result and the sssd.conf and the domain log

sssd.conf.txt sssd_CALICOLABS.LOCAL.log ldapsearch.txt

[sumit-bose]

Hi,

in the AD scheme the sAMAccountName attribute is used as group name and this attribute is missing for the group as can be seen in the ldapsearch output. Is this attribute missing only for this group or for all groups? In the former case please check why it is missing. In the latter it might be worth to change ldap_group_name to cn. But there is also the attribute uid which is afaik not an attribute typically used in AD groups. If this, by chance is generated from the original sAMAccountName attribute by some mapping rules I would recommend to use this attribute (uid) as group name. The main reason is that sAMAccountName in AD has a unique contraint while cn has not and you do not want two different groups to have the same name.

HTH

bye, Sumit

[srcc-chekh]

I added ldap_group_name = cn to sssd.conf and now it works!

Our environment is small so we will not have conflicting group names in AD. I inherited this setup from 5+ years ago and AFAIK there were not special configurations on AD side. And it worked just fine with previous version of sssd.

I looked in the LDAP proxy config and I do see in there: rwm-map attribute uid sAMAccountname

So I tried changing in sssd client config ldap_group_name = uid and that also works fine.

So it sounds like in previous versions it would fall back to using uid or cn automatically if sAMAccountname was missing?

[sumit-bose]

Hi,

I'm glad to hear it is working now.

So it sounds like in previous versions it would fall back to using uid or cn automatically if sAMAccountname was missing?

No, if the previous version of SSSD is also more than 5 years old SSSD might still have used cn and group name even with AD. But due to the reason mentioned above and to be compatible with Samba and AD's understanding of group names we changed this to sAMAccountName.

bye, Sumit