Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Security and Hardening Guide
Applies to SUSE Linux Enterprise Desktop 15 SP3

5 Setting up authentication clients using YaST Edit source

Whereas Kerberos is used for authentication, LDAP is used for authorization and identification. Both can work together. For more information about LDAP, see Chapter 6, LDAP with 389 Directory Server, and about Kerberos, see Chapter 7, Network authentication with Kerberos.

5.1 Configuring an authentication client with YaST Edit source

YaST allows setting up authentication to clients using different modules:

5.2 SSSD Edit source

Two of the YaST modules are based on SSSD: User Logon Management and LDAP and Kerberos Authentication.

SSSD stands for System Security Services Daemon. SSSD talks to remote directory services that provide user data and provides various authentication methods, such as LDAP, Kerberos, or Active Directory (AD). It also provides an NSS (Name Service Switch) and PAM (Pluggable Authentication Module) interface.

SSSD can locally cache user data and then allow users to use the data, even if the real directory service is (temporarily) unreachable.

5.2.1 Checking the status Edit source

After running one of the YaST authentication modules, you can check whether SSSD is running with:

root # systemctl status sssd
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Thu 2015-10-23 11:03:43 CEST; 5s ago

5.2.2 Caching Edit source

To allow logging in when the authentication back-end is unavailable, SSSD will use its cache even if it was invalidated. This happens until the back-end is available again.

To invalidate the cache, run sss_cache -E (the command sss_cache is part of the package sssd-tools).

To completely remove the SSSD cache, run:

tux > sudo systemctl stop sssd
tux > sudo rm -f /var/lib/sss/db/*
tux > sudo systemctl start sssd
Print this page