Redhat – Some AD Users are missing supplemental groups on RHEL Linux

active-directoryredhatsssd

My organization is trying to join our RHEL/CentOS 7 servers to our Microsoft AD domain. The domain controllers consist of 2x Windows 2008R2 servers and 1x Windows 2016 server.

On the Linux side, I'm using realm to join to the domain, which I've managed to do successfully:

# realm list
mydomain.net
  type: kerberos
  realm-name: MYDOMAIN.NET
  domain-name: mydomain.net
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@mydomain.net
  login-policy: allow-realm-logins

I would like to permit only members of a certain group access to SSH:

# realm permit -g mygroup@mydomain.net

That's when I encounter problems. When tested on two users, userA & userB, userA is allowed in, but userB is denied. The /var/log/sssd/sssd_mydomain.net.log file reveals that userB has no supplemental groups:

(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_access_check_send] (0x0200): Simple access check for userB@mydomain.net
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): User userB@mydomain.net is a member of 0 supplemental groups
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): All groups had name attribute

Or rather, it does, but none that SSSD can see. The following commands confirm that:

# id userA@mydomain.net
uid=1918001261(userA@mydomain.net) gid=1918000513(domain users@mydomain.net) groups=1918000513(domain users@mydomain.net),1918001757(devops_aws@mydomain.net),1918003900(sccm administrators@mydomain.net),1918004006(ts remote desktop users@mydomain.net),1918004329(macbook_users@mydomain.net)
# id userB@mydomain.net
uid=1918003883(userB@mydomain.net) gid=1918000513(domain users@mydomain.net) groups=1918000513(domain users@mydomain.net)

Eventually, we found out that userA has the adminCount attribute set to 1 in its AD/LDAP object. I'm not entirely sure what implications this attribute has, but it seems to be the reason why SSSD can find all of its supplemental groups and consequently it has found none for userB.

Any help would be greatly appreciated! I have been banging my head on this problem for a long, long time.

/etc/sssd/sssd.conf

[sssd]
domains = mydomain.net
config_file_version = 2
services = nss, pam

[domain/mydomain.net]
ad_domain = mydomain.net
krb5_realm = MYDOMAIN.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = mygroup@mydomain.net
debug = 6

Best Answer

I figured out the issue when I read the SSSD Troubleshooting guide. In the guide, it briefly mentions:

If you use a non-standard LDAP search bases, please disable the TokenGroups performance enhancement by setting ldap_use_tokengroups=False. Otherwise, the AD provider would receive the group membership via a special call that is not restricted by the custom search base which causes unpredictable results

And in the blog post Restrict the set of groups the user is a member of with SSSD, a bit more is explained about TokenGroups:

The first step is to make the client look up the groups the user is a member of using plain LDAP lookups instead of looking up the AD-specific tokenGroups attribute. Normally, if all groups are to be returned, using the tokenGroups attribute provides a significant performance benefit, because the list of all groups is a member of can be returned with a single BASE-scoped search of the user entry. However, the tokenGroups attribute is a multi-valued list of SIDs the user is a member of and as said earlier, all the SIDs would have to be resolved into group names anyway.

It seems TokenGroups are an optimization technique, which is enabled by default, in resolving a user's groups. However, as these articles have alluded, it may prove problematic, as it did in my case.

The issue was fixed by simply setting the parameter to false:

[domain/mydomain.net]
ldap_use_tokengroups = false

in my sssd.conf file.

Related Topic