Security and Hardening Guide
- About This Guide
- 1 Security and Confidentiality
- 2 Common Criteria
- I Authentication
- II Local Security
- 10 Physical Security
- 11 Automatic Security Checks with seccheck
- 12 Software Management
- 13 File Management
- 14 Encrypting Partitions and Files
- 15 Storage Encryption for Hosted Applications with cryptctl
- 16 User Management
- 17 Spectre/Meltdown Checker
- 18 Configuring Security Settings with YaST
- 19 Authorization with PolKit
- 20 Access Control Lists in Linux
- 21 Certificate Store
- 22 Intrusion Detection with AIDE
- III Network Security
- IV Confining Privileges with AppArmor
- 27 Introducing AppArmor
- 28 Getting Started
- 29 Immunizing Programs
- 30 Profile Components and Syntax
- 31 AppArmor Profile Repositories
- 32 Building and Managing Profiles with YaST
- 33 Building Profiles from the Command Line
- 34 Profiling Your Web Applications Using ChangeHat
- 35 Confining Users with
pam_apparmor - 36 Managing Profiled Applications
- 37 Support
- 38 AppArmor Glossary
- V SELinux
- VI The Linux Audit Framework
- A GNU Licenses
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—A Directory Service, 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:
. Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains.
This module is described in Section 8.3.2, “Joining Active Directory Using ”.
. Join an Active Directory (which entails use of Kerberos and LDAP). This option is based on
winbindand is best suited for joining an Active Directory domain if support for NTLM or cross-forest trusts is necessary.This module is described in Section 8.3.3, “Joining Active Directory Using ”.
. Allows setting up LDAP identities and Kerberos authentication independently from each other and provides fewer options. While this module also uses SSSD, it is not as well suited for connecting to Active Directory as the previous two options.
This module is described in:
5.2 SSSD #Edit source
Two of the YaST modules are based on SSSD: and .
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 sssdsssd.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 >sudosystemctl stop sssdtux >sudorm -f /var/lib/sss/db/*tux >sudosystemctl start sssd