sssd.service fails to start after hardening with `ism_o`, `stig` and `anssi` profiles

[matusmarhefka]

Description of problem:

After system is hardened with any variant of ism_o or anssi profiles or with stig profile and rebooted, the sssd.service fails to start.

SCAP Security Guide Version:

master

Operating System Version:

RHEL 9, RHEL 10

Steps to Reproduce:

1. Run /scanning/boot-errors test for any of the affected profiles.

Actual Results:

× sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2026-03-11 16:15:35 CET; 3s ago
    Process: 892 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
   Main PID: 892 (code=exited, status=4)
        CPU: 21ms

Mar 11 16:15:35 localhost systemd[1]: Starting System Security Services Daemon...
Mar 11 16:15:35 localhost sssd[892]: SSSD couldn't load the configuration database [1432158246]: No domain is enabled
Mar 11 16:15:35 localhost systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Mar 11 16:15:35 localhost systemd[1]: sssd.service: Failed with result 'exit-code'.
Mar 11 16:15:35 localhost systemd[1]: Failed to start System Security Services Daemon.

Expected Results:

No failure after hardening.

[matusmarhefka]

Note that we already have a waiver for sssd service rule at https://github.com/RHSecurityCompliance/contest/blob/2425473d946f8cc6c9d8c94736233a10a13b6420/conf/waivers/permanent#L14-L18 so we might just group it with the scanning/boot-errors waiver there. Still it might be worth double-checking if there is no issue caused by our remediation.