Configure SSSD LDAP Backend to Use TLS For All Transactions
Sets ldap_id_use_start_tls = true in SSSD so every LDAP lookup (identity and authentication) is wrapped in StartTLS, never sent in clear text.
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
When SSSD queries LDAP over a plain connection, usernames, group memberships and, depending on the bind method, credentials traverse the network unencrypted, readable and modifiable by anyone on the path. Enabling StartTLS on the identity lookups encrypts the channel and provides integrity protection, preventing eavesdropping, credential theft and tampering with the directory data that drives authentication and authorization decisions.
What Pavois checks
The control only runs when /etc/sssd/sssd.conf exists, then greps the SSSD tree under /etc/sssd/ for ldap_id_use_start_tls = true. Since SSSD offers no straightforward runtime dump of this setting, the on-disk directive across all config fragments is the authoritative reflection of what the daemon loads, and Pavois reads the whole tree, not a single file, so drop-ins are not missed.
only_if { file('/etc/sssd/sssd.conf').exist? }
describe command('grep -qriE \'^[[:space:]]*ldap_id_use_start_tls[[:space:]]*=[[:space:]]*true\' /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_id_use_start_tls\s*=\s*true' /etc/sssd/. The expected output is a matching line ldap_id_use_start_tls = true. Note: this directive applies to ldap:// URIs; if ldap_uri already uses ldaps://, TLS is implicit and StartTLS is not needed.
Inspect & investigate
SSSD records its TLS negotiation via journalctl -u sssd and, with debug enabled, in /var/log/sssd/sssd_*.log. A failed StartTLS handshake (missing CA, server without TLS) appears there; user authentication events also land 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_id_use_start_tls = true, ensure ldap_tls_cacert/ldap_tls_cacertdir is configured and ldap_tls_reqcert is demand, 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, enable StartTLS in /etc/sssd/sssd.conf: # ldap_id_use_start_tls = true # then: systemctl restart sssd |
|---|---|
| reason | only applies if SSSD/LDAP is in use, enable StartTLS 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
Enabling StartTLS requires the LDAP server to support TLS on its ldap:// port and the client to trust the server's CA; if either is missing, SSSD will fail to bind and authentication will break for all directory users. Before applying, confirm the server offers StartTLS and the CA is installed, keep a local admin account for recovery, and restart SSSD in a maintenance window while watching journalctl -u sssd. This control only evaluates when SSSD is actually in use.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R67 | direct | 2.0 | high |
| NIST | CM-6(a), CM-7(a), CM-7(b) | 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.