Configure SSSD LDAP Backend Client to Demand a Valid Certificate from the Server
Sets SSSD's LDAP backend to ldap_tls_reqcert = demand (or hard), so it refuses to connect unless the LDAP server presents a valid, verified TLS certificate.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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
SSSD authenticates users against an LDAP directory. If certificate validation is disabled or set to allow/never, SSSD will trust any server presenting itself as the directory, enabling a man-in-the-middle to impersonate the LDAP server, harvest credentials and forge authentication decisions. Requiring demand/hard forces SSSD to reject connections whose certificate is missing, untrusted or invalid, preserving the integrity and confidentiality of the authentication channel.
What Pavois checks
Pavois greps the SSSD configuration tree under /etc/sssd/ (including conf.d/ drop-ins) for an ldap_tls_reqcert set to demand or hard. SSSD has no simple runtime dump for this value, so the on-disk directive, across all included fragments, is the authoritative source of the policy the daemon loads at start.
only_if { command('test -f /etc/sssd/sssd.conf').exit_status.zero? }
describe command('grep -qriE \'^[[:space:]]*ldap_tls_reqcert[[:space:]]*=[[:space:]]*(demand|hard)\' /etc/sssd/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run grep -riE 'ldap_tls_reqcert\s*=\s*(demand|hard)' /etc/sssd/. The expected output is a matching line such as ldap_tls_reqcert = demand. After any change, restart with systemctl restart sssd and confirm authentication still works.
Inspect & investigate
SSSD logs its LDAP/TLS handshake outcome via journalctl -u sssd and, with debugging raised, in /var/log/sssd/sssd_*.log. A rejected certificate appears there as a TLS verification failure; authentication events also surface in /var/log/secure (RHEL) or /var/log/auth.log (Debian/Ubuntu).
Remediation
No automated harden plan is defined, so this must be applied manually: in the [domain/...] section of /etc/sssd/sssd.conf, set ldap_tls_reqcert = demand and ensure ldap_tls_cacert (or ldap_tls_cacertdir) points to the CA that signs the LDAP server certificate, then systemctl restart sssd.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # If SSSD with LDAP is configured, require certificate validation in /etc/sssd/sssd.conf: # ldap_tls_reqcert = demand # then: systemctl restart sssd |
|---|---|
| reason | only applies if SSSD/LDAP is in use, set tls_reqcert in sssd.conf deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If the LDAP server's certificate is self-signed, expired, or signed by a CA not present in the system trust store / ldap_tls_cacert, switching to demand/hard will block all LDAP authentication, potentially locking out every directory user. Before applying, verify the server certificate chain validates (e.g. openssl s_client -connect ldap.example.com:636) and that the CA is configured. Keep a local admin account available, and restart SSSD during a maintenance window with a tested fallback login.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R67 | direct | 2.0 | high |
| NIST | CM-6(a), SC-12(3) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.