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

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

Identity lookups without SSSD

N etw or k B ou n d ar y Identity Server Authentication Server Client Client Client

Identity lookups with SSSD

N etw or k B ou n d ar y Identity Server Authentication Server Client Client Client SSSD NSS Responder PAM Responder Domain Provider Auth Provider Identity Provider Cache

SSSD Data Providers

N etw or k B ou n d ar y Identity Server Auth Server Client Client Client SSSD NSS Responder PAM Responder Auth Provider Cache Domain Provider 2 Identity Provider Domain Provider 1 Auth Provider Identity Provider Domain Provider N Auth Provider Identity Provider Domain Provider ... Auth Provider Identity Provider Identity Server Auth Server Identity Server Auth Server Identity Server Auth Server

Traditional Authentication

Client Request Directory 2 Directory 1 ... Directory N PAM Auth N ... Auth 2 Auth 1 NSS

SSSD Authentication

Client Request Directory 2 Directory 1 ... Directory N PAM Auth N ... Auth 2 Auth 1 NSS

Improvements over nscd and

pam_ccreds

●

nscd

– 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

backend-specific 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,

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

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

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)

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 Providers

●

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

nameservice library

–

E.g. nss_nis.so.2

Authentication Providers

●

LDAP

– Password authentication through LDAP simple bind

●

KRB5

– 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

●

IPA

– Password authentication to FreeIPA through the Kerberos protocol or

LDAP simple bind (during password migration only)

– Can handle password migrations from LDAP -> FreeIPA migrations

●

Proxy

– Invokes a custom PAM stack to perform authentication against a

Access Providers

● 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

– Grants access to users whose user entry matches a particular LDAP search

query

Chpass Providers

●

LDAP

–

Change password using the password change

extended operation of the LDAP protocol

●

KRB5

–

Change password through the Kerberos protocol

to a kadmin server