Am Tue, Dec 20, 2022 at 06:55:58PM -0000 schrieb Jeffrey Chung: > Hello all. We’re noticing an issue where at times the id command does not > return a complete list of the user’s secondary groups. In our Linux > environment we use both Universal and Global groups and it’s always only the > Global groups that are missing. From troubleshooting we’re certain this > issue comes up when a Global Catalog that is not in the same domain of the > missing Global groups is used to query for group membership. From my > understanding, in Active Directory only Universal group memberships are > replicated to every Global Catalog. > > We have a single forest with multiple domains. The forest root domain is > empty and only use for administration. We have a child domain for resource > like users, groups and computers.
Hi, is there a reason you are using 'ldap_use_tokengroups = false'? Have you tried if 'ldap_use_tokengroups = true' is working more reliable? bye, Sumit > > contoso.com – empty forest root > corp.contoso.com – child domain of root, users, groups and computer objects > live here. SSSD Linux are joined to this domain. > > Every Domain Controller in the forest are Global Catalogs, so we have GCs in > both contoso.com and corp.contoso.com. > > Here’s an example of when secondary groups are missing. > We have a user j...@corp.contoso.com and is a direct member of the following > corp.contoso.com groups. > group1 (Universal scope) > group2 (Global scope) > > On the SSSD host we run the following command. > % id john > > Only john’s primary group and group1 are returned. From the SSSD debug logs, > we only see this happen when the query is hitting a Global Catalog (port > 3268) in the root domain contoso.com. If the query hits a GC in > corp.contoso.com the correct groups are returned. > > The LDAP filter we see from the logs is this. > (&(member=CN=john,CN=Users,DC=corp,DC=contoso,DC=com)(objectClass=posixgroup)(cn=*)) > > Which will not return Global groups because the Global Catalog Domain > Controllers in contoso.com only have membership data for Universal groups. > > We noticed this issue on sssd-1.16.1, we have hosts running an older version > sssd-1.11.5.1 that don’t have this issue because the group membership query > is using the LDAP port 389 not GC port 3268. On both versions we have > “ad_enable_gc” set to true. > > Is this a bug we’re hitting, or we have SSSD configured incorrectly? Should > SSSD be group scope aware and handle this situation correctly? > > We can think of a couple work-arounds, but rather not implement it if > possible. > 1. Set “ad_enable_gc” to false – this will probably cause some inefficiencies > for SSSD > 2. Convert the Global groups to Universal – we have a lot of groups and this > will take some time to vette out to avoid any negative impact to our > environment > > Here is an example of our sssd.conf. > > [sssd] > config_file_version = 2 > debug_level = 9 > services = nss,pam > domains = corp.contoso.com > > [nss] > debug_level = 9 > filter_users = root > filter_groups = root > filter_users_in_groups = false > timeout = 60 > > [pam] > debug_level = 9 > reconnection_retries = 3 > timeout = 60 > > [domain/corp.contoso.com] > ad_gpo_access_control = disabled > debug_level = 9 > ldap_user_object_class = posixaccount > ldap_user_home_directory = unixhomedirectory > ldap_group_object_class = posixgroup > ldap_group_name = cn > ldap_group_member = member > ldap_group_nesting_level = 0 > ldap_use_tokengroups = false > cache_credentials = true > id_provider = ad > auth_provider = ad > chpass_provider = ad > access_provider = ad > dns_discovery_domain = corp.contoso.com > dyndns_update = false > ldap_id_mapping = false > ad_enable_gc = true > ldap_search_base = dc=corp,dc=contoso,dc=com?subtree? > ad_maximum_machine_account_password_age = 0 > use_fully_qualified_names = false > krb5_ccachedir = /tmp > krb5_ccname_template = FILE:%d/krb5cc_%U > krb5_renew_interval = 60m > timeout = 60 > > Thanks in advance > > -Jeff > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
