SSSD can use an LDAP filter to decide which directory users are allowed to log in to a Linux host. This is useful when accounts should remain visible in the directory, but only members of designated groups should have access to a particular server.
The filter is evaluated by the LDAP access provider. It matches attributes on the user entry; a matching user is allowed by this access check, while a user who does not match is denied. This controls SSSD’s account/access decision, not whether the user exists in LDAP or can authenticate by some other path.
Prerequisites
- SSSD is installed and configured to look up users in the intended LDAP domain.
- The host can reach the LDAP server, and the configured bind account (if required) can read the user and group attributes used by the filter.
- You know the full distinguished name (DN) of the group that grants access.
- PAM and the relevant login service (such as SSH) are configured to use the system’s SSSD-backed account checks.
On older RHEL or CentOS releases, install SSSD with:
sudo yum install sssd
On newer releases, the package manager may be dnf instead:
sudo dnf install sssd
Allow members of one group
Edit the domain section in /etc/sssd/sssd.conf. The section name must match the domain listed under [sssd]; for example, domains = example.com uses [domain/example.com].
[domain/example.com]
id_provider = ldap
access_provider = ldap
ldap_access_filter = (memberOf=cn=linux-login,ou=Groups,dc=example,dc=com)
The group DN in the filter must match the directory’s actual DN. LDAP filter syntax requires parentheses around each filter expression. When access_provider = ldap is enabled, configure an access filter; without one, SSSD’s LDAP access provider denies users by default.
Allow members of either of multiple groups
Use LDAP’s OR operator, |, to allow a user who matches any listed group:
access_provider = ldap
ldap_access_filter = (|(memberOf=cn=linux-admins,ou=Groups,dc=example,dc=com)(memberOf=cn=database-users,ou=Groups,dc=example,dc=com))
Use the AND operator, &, when a user must satisfy every condition. For example, the following requires both a user object and membership in the named group:
ldap_access_filter = (&(objectClass=person)(memberOf=cn=linux-login,ou=Groups,dc=example,dc=com))
LDAP filter operators can be combined to express more specific policies. Keep the expression on one line in sssd.conf, and verify the parentheses are balanced.
Active Directory nested group membership
In Active Directory, a user’s memberOf attribute normally lists direct memberships. If access should also be granted through nested groups, use Microsoft’s matching-rule-in-chain OID (1.2.840.113556.1.4.1941) in the filter. This is an AD-specific LDAP feature; it is not portable to every LDAP server.
[domain/example.com]
id_provider = ldap
access_provider = ldap
ldap_schema = ad
ldap_access_filter = (memberOf:1.2.840.113556.1.4.1941:=cn=linux-server-access,ou=Groups,dc=example,dc=com)
To allow membership through either of two groups, wrap both matching rules in an OR expression:
ldap_access_filter = (|(memberOf:1.2.840.113556.1.4.1941:=cn=linux-server-access,ou=Groups,dc=example,dc=com)(memberOf:1.2.840.113556.1.4.1941:=cn=linux-admins,ou=Groups,dc=example,dc=com))
Check that the configured LDAP server supports this matching rule and that the filter’s group DNs are correct. If nested membership is not needed, a plain memberOf filter is simpler.
Example domain configuration
The following is a minimal illustration of the relevant settings. Integrate them into the existing SSSD configuration rather than replacing unrelated identity, authentication, or Kerberos settings:
[sssd]
config_file_version = 2
services = nss, pam
domains = example.com
[domain/example.com]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_schema = ad
ldap_uri = ldaps://ldap.example.com
ldap_tls_cacert = /etc/openldap/cacerts/ca-certificates.crt
ldap_default_bind_dn = cn=sssd-reader,ou=Service Accounts,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = REPLACE_WITH_A_SECRET
ldap_access_filter = (memberOf:1.2.840.113556.1.4.1941:=cn=linux-server-access,ou=Groups,dc=example,dc=com)
Use the certificate authority file and LDAP URI appropriate for your environment. The bind password above is only a placeholder: do not publish real credentials in a configuration example, source repository, or blog post. On the host, protect sssd.conf so only root can read it:
sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 600 /etc/sssd/sssd.conf
If authentication is provided by Kerberos or another mechanism, retain the appropriate existing auth_provider and authentication settings; the access filter setting is independent of that choice.
Apply and verify the change
After saving the file, check its permissions and configuration, then restart SSSD. sssctl config-check is available on many current SSSD releases; consult the installed version’s documentation if that command is unavailable.
sudo sssctl config-check
sudo systemctl restart sssd
On older systems that do not use systemd, the service command may be used instead:
sudo service sssd restart
Test with one account that should be allowed and one that should be denied. Where supported, sssctl user-checks can help inspect the access decision:
sudo sssctl user-checks allowed-user
sudo sssctl user-checks other-user
If results appear stale, SSSD may be using cached identity or access data. Review the cache settings and, if appropriate for your environment, invalidate cached entries with sss_cache; account for the effect on users and services before clearing the cache. When a user is unexpectedly denied, check SSSD’s domain logs, LDAP connectivity, the user’s group membership as seen by the LDAP server, and the exact group DN and filter syntax.