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. 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 [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
