System Security Services Daemon
System Security Services Daemon Manages communication with centralized identity and authentication stores Provides robust, predictable caching for network accounts Can cache authentication credentials locally to allow local updates Can handle multiple domains of user data and authentication
SSSD Use Cases Corporate Laptop Traditional problem: users maintain a separate local account on the laptop to log into when out of the office With SSSD providing cached credentials, the user can keep the same account (UID and all) when logging in remotely Datacenter Datacenters that require highly-available authentication can take advantage of SSSDs caching to ride out temporary internal service outages (such as an LDAP or Kerberos server outage)
Network Boundary Identity lookups without SSSD Identity Authentication
Network Boundary Identity lookups with SSSD NSS Responder Identity Identity Cache SSSD Domain PAM Responder Auth Authentication
SSSD Data s Network Boundary Identity Auth SSSD NSS Responder PAM Responder Auth Cache Domain 2 Identity Domain 1 Auth Identity Domain N Auth Identity Domain... Auth Identity Identity Auth Identity Auth Identity Auth
Traditional Authentication NSS PAM Directory 1 Auth 1 Request Directory 2... Auth 2... Directory N Auth N
Copyright Dbarefoot, used under Attribution-NonCommercial License
SSSD Authentication NSS PAM Directory 1 Auth 1 Request Directory 2... Auth 2... Directory N Auth N
nscd Improvements over nscd and pam_ccreds SSSD user and group cache expiration is more predictable When cached in the SSSD, user identity entries will not expire while offline SSSD operates closer to the backends, so it can be aware of backendspecific temporary failures that nscd would report as missing entries pam_ccreds SSSD can be configured to perform offline expiration of cached credentials (requiring clients to 'check in' with the central server regularly) SSSD will inform the user when authenticating with cached credentials, and will warn of approaching offline expiration
Differences from traditional authentication SSSD requires the use of transport layer encryption when performing simple bind authentication against LDAP LDAPS, TLS or GSSAPI SSSD enforces a one-to-one relationship between user identities and authentication services Offline authentication against a Kerberos server can be configured to automatically perform a kinit when the server becomes available
To Infinity and Beyond Developer environment Build custom identity and authentication backends Better ActiveDirectory Support Integrate with ActiveDirectory using winbind InfoPipe Advanced authentication interface over D-BUS system bus Provide access to extended directory information such as keyboard and language preferences
Configuration Basic configuration can be most easily managed with authconfig Version 6.1.4 or later of authconfig Properly configures the following standard configuration files for use with SSSD: /etc/nsswitch.conf /etc/pam.d/system-auth /etc/pam.d/password-auth /etc/sssd/sssd.conf /etc/krb5/krb5.conf (when using Kerberos for auth) SSSD 1.2.x supports LDAP for identities and either LDAP or Kerberos for authentication
Advanced Configuration Many more complicated configuration settings are available Advanced options be set manually in /etc/sssd/sssd.conf For a complete listing of these options, see: sssd.conf(5) sssd-ldap(5) sssd-krb5(5) Options that may be of interest: enumerate Whether to allow a complete listing of all users in a domain. Default: False ldap_tls_reqcert How strict SSSD should be when validating the certificate for an LDAP server krb5_store_password_if_offline Whether to store a user's password (securely) until the SSSD becomes online. When this occurs, the SSSD will perform a kinit on behalf of the user with this password to acquire a TGT
Identity s LDAP Supports LDAP servers using RFC2307 or RFC2307bis schema SSSD 1.2 supports users and groups Upcoming versions will also support netgroups IPA Support for the upcoming FreeIPA v2 identity store Uses (and requires) GSSAPI/KRB5 encrypted communication with the FreeIPA LDAP server Proxy Can support identity data from an existing
Authentication s LDAP Password authentication through LDAP simple bind KRB5 IPA Proxy Password authentication through the Kerberos protocol Authentication through this backend will perform a kinit and acquire a Kerberos ticket-granting ticket for network single-sign-on Password authentication to FreeIPA through the Kerberos protocol or LDAP simple bind (during password migration only) Can handle password migrations from LDAP -> FreeIPA migrations Invokes a custom PAM stack to perform authentication against a tradition PAM module (or series of modules)
Access s Permit Always allows access to any user that succeeded at authentication Default if no access_provider is specified Deny Always denies access, regardless of authentication success Simple Grants access to users in a list LDAP IPA Grants access to users whose user entry matches a particular LDAP search query Grants access based on complex host-based access control (HBAC) rules configured on a FreeIPA server
Chpass s LDAP KRB5 Proxy Change password using the password change extended operation of the LDAP protocol Change password through the Kerberos protocol to a kadmin server