SSSD / sssd

A daemon to manage identity, authentication and authorization for centrally-managed systems.
https://sssd.io
GNU General Public License v3.0
604 stars 247 forks source link

Cannot find name for group id error #6169

Closed jagga13 closed 11 months ago

jagga13 commented 2 years ago

Hello,

I have implemented sssd to integrate with our AD/LDAP instance to authorize users/groups on a linux system. It seems to have worked for the most part but when running the groups or id command, I see a rouge group id that is not resolvable via AD:

# groups user
user : user app_cloudhpc_admins groups: cannot find name for group ID 2100513
2100513
# id user
uid=2193058(user) gid=2193058(user) groups=2193058(user),2191525(app_cloudhpc_admins),2100513

The 2100513 group is not coming from AD and not sure where locally it might be coming from. I have rm'd /var/lib/ss/db/* and did a sss_cache -E and restarted sssd but this issue still exists. Any help would be greatly appreciated. Here is my sssd.conf:

[domain/xxx.COM]
debug_level = 10
ldap_tls_reqcert = never
ldap_schema = ad
cache_credentials = True
ldap_search_base = dc=xxx,dc=com
ad_domain = xxx.com
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
ldap_access_order = filter,expire
ldap_account_expire_policy = ad
ldap_tls_cacertdir = /etc/openldap/certs
ldap_tls_cacert = /etc/openldap/certs/xxx_ad_cert.crt
ldap_access_filter = memberOf=CN=xxx,OU=T2-Groups,OU=Tier2,OU=xxx,OU=xxx,DC=xxx,DC=com
ldap_user_name = sAMAccountName
ldap_user_object_class = user
ldap_group_object_class = group
ldap_group_member = member
ldap_group_search_base = OU=Groups,OU=T2-Groups,OU=Tier2,OU=xxx,OU=xxx,DC=xxx,DC=com?subtree?(&(objectclass=group)(cn=*CloudHPC*))
ldap_uri = ldap://server.xxx.com
ldap_default_authtok_type = password
ldap_default_bind_dn = CN=xxx,OU=Service Accounts,DC=xxx,DC=com
ldap_default_authtok = xxx
auto_private_groups=true
ad_server = server1.xxx.com,server2.xxx.com,server3.xxx.com
enumerate = False
ldap_referrals = False
ldap_id_mapping = True
ldap_idmap_autorid_compat = True
ldap_idmap_range_min = 2100000
ldap_idmap_range_max = 3000000
ldap_groups_use_matching_rule_in_chain = False
ldap_deref_threshold = 0
fallback_homedir = /data/home/%u
case_sensitive = False
ldap_id_use_start_tls = True
default_shell = /bin/bash
override_shell = /bin/bash
[sssd]
debug_level = 6
services = nss, pam
config_file_version = 2
domains = xxx.com
[nss]
debug_level = 6

[pam]
 pam_verbosity = 3
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
[sudo]
[autofs]
[ssh]

Thanks

jagga13 commented 2 years ago

I feel this is being caused due to the 'domain users' group coming from AD. Is there a way for me to ignore this group explicitly from my sssd.conf. Maybe in the ldap_group_search_base? Is there a way to update the following and add a not group domain users filter:

ldap_group_search_base = OU=Groups,OU=T2-Groups,OU=Tier2,OU=xxx,OU=xxx,DC=xxx,DC=com?subtree?(&(objectclass=group)(cn=*CloudHPC*))

Thanks!

aranc23 commented 2 years ago

I have seen identical errors after upgrading to 2.7.0 from 2.5.2. The issue exists in 2.6.3 as well. What version of sssd are you using? I haven't filed a bug report yet.

pbrezina commented 1 year ago

Can you try using the ad provider instead of ldap, ie *_provider=ad? It would simplify the configuration a lot and most probably resolve your issue.

andreboscatto commented 11 months ago

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards, André Boscatto