Enable the SSSD Service
Ensures the SSSD service (sssd.service) is enabled and running so centralized authentication and credential caching are operational.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
The System Security Services Daemon (SSSD) brokers access to centralized identity sources (LDAP, Active Directory, Kerberos, IPA) and caches credentials so users can authenticate even when the directory is unreachable. If sssd is not running, centralized authentication, host-based access control, and credential caching stop working: logins may fall back to weaker mechanisms or fail entirely, and offline access is lost. A consistent, centrally-managed identity backbone is a prerequisite for enforcing strong, auditable authentication policy across a fleet.
What Pavois checks
Pavois queries the effective unit state with service('sssd.service'), which resolves to systemctl is-enabled sssd and systemctl is-active sssd. This reflects what systemd will actually do at boot and what is running now, including drop-in overrides under /etc/systemd/system/sssd.service.d/ and unit masking. Reading a file such as /etc/sssd/sssd.conf would only tell you a config exists; it would not reveal that the unit is masked, failed, or never started.
only_if { file('/etc/sssd/sssd.conf').exist? }
describe service('sssd.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Run systemctl is-enabled sssd && systemctl is-active sssd. Both must print enabled and active respectively. A full status check is systemctl status sssd.service, expected to show Active: active (running) with Loaded: ... enabled.
Inspect & investigate
Inspect the unit journal with journalctl -u sssd.service. Authentication events brokered by SSSD appear in /var/log/sssd/ (per-domain logs) and in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Increase verbosity temporarily with sssctl logs-fetch or debug_level in sssd.conf when troubleshooting.
Remediation
Pavois's harden plan acts on the service resource named sssd: it runs the enable action (so the unit starts at every boot) and the start action (so it is running immediately). It is applied with pavois harden apply. SSSD must already be installed and a valid /etc/sssd/sssd.conf with at least one domain must exist, otherwise the service will start but stay idle or fail.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # SSSD only makes sense once the host is joined to a domain (IdM / AD / LDAP). # realm join ... (or write /etc/sssd/sssd.conf), then: systemctl enable --now sssd |
|---|---|
| reason | sssd refuses to start without a domain configuration: enabling it would just fail |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If SSSD is disabled or stopped, centralized logins fail and cached offline authentication is unavailable, on a domain-joined host this can lock out every directory user, including remote admins. Precautions: before enabling, confirm /etc/sssd/sssd.conf is present, has mode 0600, and defines a working domain; verify connectivity to the directory; and keep a local emergency account (or console access) so you are not locked out if SSSD misconfiguration prevents authentication. Test with sssctl config-check before applying broadly.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R67 | direct | 2.0 | high |
| NIST | CM-6(a), IA-5(10) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-254015, UBTU-24-100660 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.