↓ Skip to main content
Le Site de François
  1. Index/

SSSD (System Security Services Daemon)

Identity Authentication Linux Ldap Kerberos Ad Pam Rhel

SSSD (System Security Services Daemon) is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — NSS (Name Service Switch) for identity lookups (user names, UIDs, GIDs, group membership) and PAM (Pluggable Authentication Modules) for authentication and session management — without creating local user accounts. It was originally developed as a component of the FreeIPA project at Red Hat, introduced in Fedora 11 (2009), and quickly became the standard identity integration layer across RHEL, Fedora, Ubuntu, Debian, and most enterprise Linux distributions. Before SSSD, integrating a Linux host with LDAP or AD required configuring nss_ldap, pam_ldap, pam_krb5, and pam_winbind independently — each with its own caching (or lack thereof), its own reconnection logic, and its own configuration syntax. SSSD replaced this collection with a single, unified daemon providing caching, offline authentication, multi-domain support, and access control in one place.

SSSD’s architecture is built around providers — loadable modules that implement the connection to a specific backend type — and responders — protocol-specific daemons that answer NSS and PAM queries from the system. The providers supported include: ad (native Active Directory integration using LDAP for identity data and Kerberos 5 for authentication, with SID-to-UID mapping, PAC validation from Kerberos tickets, and automatic detection of AD sites and domain controllers via DNS SRV records — the recommended provider for AD-joined hosts); ldap (generic LDAP integration for OpenLDAP, 389 Directory Server, and other RFC 2307-compliant directories, with Kerberos or simple bind authentication); ipa (FreeIPA/Red Hat Identity Management integration, using the IPA-extended LDAP schema for HBAC rules, sudo rules, SSH key distribution, and certificate-based authentication); krb5 (standalone Kerberos authentication without LDAP identity lookup, for environments where identity comes from a separate source); and idp (OIDC/OAuth 2.0 integration for cloud identity providers supporting the device authorisation grant, available since SSSD 2.7). The sss NSS module (registered in /etc/nsswitch.conf as passwd: sss files, group: sss files) intercepts getpwnam(), getgrnam(), and related libc calls and forwards them to the SSSD responder, which either serves them from its local lmdb cache (sub-millisecond) or fetches them from the backend provider. The cache stores complete user entries, group memberships, and — when cache_credentials = true — Kerberos or password credentials, enabling offline authentication: a user who has logged in at least once can continue to authenticate while the network or identity provider is unavailable, using the cached credential hash.

SSSD’s access control and security features make it the correct integration point for several security patterns in this glossary. HBAC (Host-Based Access Control) rules — defined centrally in FreeIPA or emulated via LDAP group membership in the simple_allow_groups SSSD option — restrict which users and groups may log in to which hosts, enforced in the PAM stack before the session is opened. sudo rule distribution (via sudo_provider = sssd) fetches sudo rules from the LDAP/IPA directory, enabling centralised privilege management without distributing /etc/sudoers files across a fleet — changes to sudo rules in the directory propagate to all hosts at the next SSSD cache refresh. SSH public key distribution (ssh_authorised_keys_command /usr/bin/sss_ssh_authorizedkeys) retrieves public keys from the sshPublicKey LDAP attribute or IPA user record, allowing central SSH key management without authorized_keys files on individual hosts. Certificate-based authentication (pam_cert_auth = true with certificate_verification) allows users to authenticate with a smartcard or FIDO2 token presenting an X.509 certificate whose subject matches their LDAP entry, verified against the CA configured in SSSD — tying PKI, FIDO2, and LDAP-based identity into a single authentication flow. SSSD integrates with realmd (realm join, realm permit) for automated AD and IPA domain joining, and with SELinux via the selinux_provider which fetches per-user SELinux context mappings from the IPA server, enabling domain users to receive different SELinux user mappings than local accounts. Diagnostics are via sssctl (sssctl user-checks, sssctl cache-expire, sssctl domain-status) and journalctl -u sssd with debug_level = 7 in sssd.conf for verbose provider tracing.

Related

AD (Active Directory)

Identity Authentication Microsoft Kerberos Ldap Pki Enterprise
Active Directory (AD) is Microsoft’s enterprise directory and identity platform, first released with Windows 2000 and now the dominant identity provider in enterprise environments worldwide. It combines four technologies into a single integrated system: LDAP as the directory access protocol for querying and modifying identity data; Kerberos 5 as the authentication protocol for issuing tickets that prove identity without transmitting passwords; DNS as the service location mechanism that clients use to discover domain controllers, Kerberos KDCs, and LDAP servers; and Group Policy as the configuration management system that pushes security settings, software installation, and policy enforcement to every joined machine. These four components are inseparable in practice: a Linux host joining an AD domain receives a Kerberos principal in AD’s KDC, a machine account object in the AD LDAP directory, a DNS record for its hostname, and (optionally) Group Policy Objects applied to it. The AD forest is the trust boundary: multiple domains can exist within a forest and all share a common schema, configuration, and Global Catalog, with transitive Kerberos trust between them.

AIDE (Advanced Intrusion Detection Environment)

Security Linux Integrity Monitoring Rhel Compliance
AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.

LDAP (Lightweight Directory Access Protocol)

Identity Networking Directory Authentication Standards Pki
LDAP (Lightweight Directory Access Protocol) is a client-server protocol for accessing and modifying a directory service: a specialised database optimised for read-heavy, hierarchically-organised identity data. It was derived from the X.500 directory standard in the early 1990s, stripping out OSI transport dependencies to run over TCP/IP, and standardised in its current form in RFC 4511 (LDAPv3, 2006). A directory in the LDAP sense is not a general-purpose database — it is a tree of entries (also called objects), each identified by a Distinguished Name (DN) that encodes its position in the hierarchy: cn=alice,ou=users,dc=example,dc=com. Each entry is an instance of one or more object classes (defined in a schema), and each object class defines a set of mandatory and optional attributes — typed, multi-valued fields such as uid, cn (common name), mail, userPassword, memberOf, sshPublicKey, objectClass, and userCertificate. The schema is extensible: LDAP servers ship with standard schema files (RFC 2307 for POSIX users and groups, RFC 4519 for person entries) and organisations add custom schema for application-specific attributes. The tree structure makes hierarchical policy delegation natural — all objects under ou=engineering,dc=example,dc=com can be administered by a different set of ACL rules than objects under ou=ops.