12:55 p.m.
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 john(a)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