sssd(System Security Services Daemon) SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources as well as D-Bus interface. It is also the basis to provide client auditing and policy services for projects like FreeIPA. It provides a more robust database to store local users as well as extended user data. – from manual

1. 工作机制 #

The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client) to an external back-end system (a provider). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm. – from redhat

For this purpose, SSSD:

  • Connects the client to an identity store to retrieve authentication information.
  • Uses the obtained authentication information to create a local cache of users and credentials on the client.

Users on the local system are then able to authenticate using the user accounts stored in the external back-end system.

SSSD does not create user accounts on the local system. Instead, it uses the identities from the external data store and lets the users access the local system.

图 1.1.

SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or Pluggable Authentication Modules (PAM).

2. 使用sssd的好处 #

2.1. Reduced load on identity and authentication servers #

When requesting information, SSSD clients contact SSSD, which checks its cache. SSSD contacts the servers only if the information is not available in the cache.

2.2. Offline authentication #

SSSD optionally keeps a cache of user identities and credentials retrieved from remote services. In this setup, users can successfully authenticate to resources even if the remote server or the SSSD client are offline.

2.3. A single user account: improved consistency of the authentication process #

With SSSD, it is not necessary to maintain both a central account and a local user account for offline authentication.

Remote users often have multiple user accounts. For example, to connect to a virtual private network (VPN), remote users have one account for the local system and another account for the VPN system.

Thanks to caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine. SSSD then maintains their network credentials.

3. 关于provider #

Identity and authentication providers are configured as domains in the SSSD configuration file. A single domain can be used as:

  • An identity provider (for user information)
  • An authentication provider (for authentication requests)
  • An access control provider (for authorization requests)
  • A combination of these providers (if all the corresponding operations are performed within a single server)

You can configure multiple domains for SSSD. At least one domain must be configured, otherwise SSSD will not start.

The access_provider option in the /etc/sssd/sssd.conf file sets the access control provider used for the domain. By default, the option is set to permit, which always allows all access.

3.1. Proxy Providers #

A proxy provider works as an intermediary relay between SSSD and resources that SSSD would otherwise not be able to use. When using a proxy provider, SSSD connects to the proxy service, and the proxy loads the specified libraries.

Using a proxy provider, you can configure SSSD to use:

  • Alternative authentication methods, such as a fingerprint scanner
  • Legacy systems, such as NIS
  • A local system account defined in /etc/passwd and remote authentication
Identity Provider Authentication Provider
Identity Management Identity Management
Active Directory Active Directory
LDAP Kerberos
proxy proxy
proxy LDAP
proxy Kerberos

4. 安装和配置 #


yum install sssd

SSSD reads the configuration files in this order: The primary /etc/sssd/sssd.conf file Other *.conf files in /etc/sssd/conf.d/, in alphabetical order


domains =
sbus_timeout = 30
services = nss, pam, ssh

filter_groups = root
filter_users = root

offline_credentials_expiration = 3

id_provider = ldap
auth_provider = ldap

cache_credentials = true

ldap_uri = ldap://
ldap_backup_uri = ldap://
ldap_search_base = dc=troy,dc=wang

ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

ldap_user_search_base = ou=staff,dc=troy,dc=wang
ldap_user_ssh_public_key = sshPublicKey

ldap_group_search_base = ou=group,dc=troy,dc=wang
ldap_group_member = memberuid

SSSD always uses an encrypted channel for authentication, which ensures that passwords are never sent over the network unencrypted. With ldap_id_use_start_tls = true, identity lookups (such as commands based on the id or getent utilities) are also encrypted.


5.为系统服务配置sssd #

5.1. Configure NSS Services to Use SSSD #

1.Use the authconfig utility to enable SSSD:

authconfig --enablesssd --update

This updates the /etc/nsswitch.conf file to enable the following NSS maps to use SSSD:

passwd:     files sss
shadow:     files sss
group:      files sss

netgroup:   files sss

2.Open /etc/nsswitch.conf and add sss to the services map line:

services: files sss

5.2. Configure SSSD to Work with NSS #

1.Open the /etc/sssd/sssd.conf file.

2.In the [sssd] section, make sure that NSS is listed as one of the services that works with SSSD.

[... file truncated ...]
services = nss, pam

3.In the [nss] section, configure how SSSD interacts with NSS. For example:

filter_groups = root
filter_users = root
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

For a complete list of available options, see NSS configuration options in the sssd.conf(5) man page. Restart SSSD.

systemctl restart sssd.service


id user
getent passwd user

5.4. Configure PAM to Use SSSD #

authconfig --enablesssdauth --update

This updates the PAM configuration to reference the SSSD modules, usually in the /etc/pam.d/system-auth and /etc/pam.d/password-auth files. For example:

[... file truncated ...]
auth		required
auth		sufficient nullok try_first_pass
auth		requisite uid >= 500 quiet
auth        	sufficient use_first_pass
auth		required
[... file truncated ...]

5.5. Configure SSSD to Work with PAM #

1.Open the /etc/sssd/sssd.conf file.

2.In the [sssd] section, make sure that NSS is listed as one of the services that works with SSSD.

[... file truncated ...]
services = nss, pam
In the [pam] section, configure how SSSD interacts with PAM. For example:
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

3.For a complete list of available options, see PAM configuration options in the sssd.conf(5) man page. Restart SSSD.

systemctl restart sssd.service


sssctl user-checks user_name auth

6. 其他 #


# WARNING: Running nscd with a secondary caching service like sssd may lead to
#          unexpected behaviour, especially with how long entries are cached.


所以,要么关闭nscd,本身services和hosts的缓存没啥太大作用;要么就将passwd, group, netgroup的缓存关闭。