Encrypt SSSD LDAP connections and verify the server certificate

Description

When SSSD uses an LDAP directory (id_provider, auth_provider or chpass_provider set to ldap in /etc/sssd/sssd.conf or /etc/sssd/conf.d/*.conf), its connections must be protected by TLS:

• either every ldap_uri uses ldaps://, or ldap_id_use_start_tls = true;
• ldap_tls_reqcert must not be never, allow or try. The SSSD default, hard (same as demand), rejects a server whose certificate cannot be verified.

The check reads every SSSD configuration file as a whole, not domain by domain: with several domains, one weak setting fails the control. Without ldap_uri, SSSD finds servers through DNS SRV records and uses plain ldap://, so StartTLS is then required. The control does not apply when sssd-ldap is not installed, or when no domain uses the LDAP provider.

Rationale

With the LDAP provider, SSSD checks passwords by binding to the directory with them. Without TLS the passwords and the account data cross the network in clear text; without certificate verification an attacker on the path can impersonate the directory and accept any password.

Impact

The directory server must present a certificate signed by a CA the client trusts (ldap_tls_cacert or the system store). Logins fail if TLS cannot be established.

Applies when

Detected: when: SSSD LDAP provider is installed A scanner reports the control not applicable when one is false.

Audit

In /etc/sssd/sssd.conf and /etc/sssd/conf.d/*.conf, for each domain with an ldap provider:

1. every ldap_uri starts with ldaps://, or ldap_id_use_start_tls = true;
2. ldap_tls_reqcert is absent, demand or hard.

Automated: every check must pass. Scanners report each check by its id.

ldap-tls

LDAP domains use TLS and require a valid server certificate.

script: |
  cfg=$(cat /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf 2>/dev/null | sed 's/[#;].*//')
  [ -n "$cfg" ] || { echo "no SSSD configuration"; exit 2; }
  p() {
    printf '%s\n' "$cfg" | grep -Ei "^[[:space:]]*$1[[:space:]]*=" |
      sed 's/^[^=]*=[[:space:]]*//; s/[[:space:]]*$//'
  }
  p '(id|auth|chpass)_provider' | grep -qix ldap || { echo "no domain uses the LDAP provider"; exit 2; }
  rc=0
  r=$(p ldap_tls_reqcert | tail -n 1 | tr 'A-Z' 'a-z')
  case $r in never | allow | try) echo "ldap_tls_reqcert = $r"; rc=1 ;; esac
  tls=$(p ldap_id_use_start_tls | tail -n 1 | tr 'A-Z' 'a-z')
  uris=$(p ldap_uri | paste -sd, -)
  if [ "$tls" != true ] && { [ -z "$uris" ] || printf '%s' "$uris" | grep -qi 'ldap://'; }; then
    echo "LDAP without TLS: ldap_uri = ${uris:-DNS SRV}, ldap_id_use_start_tls = ${tls:-false}"
    rc=1
  fi
  [ "$rc" = 0 ] && echo "TLS in use, ldap_tls_reqcert = ${r:-hard (default)}"
  exit "$rc"

Remediation

In each LDAP domain section of the SSSD configuration:

ldap_uri = ldaps://ldap.example.org
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

or keep ldap:// URIs and add ldap_id_use_start_tls = true. Then run systemctl restart sssd and check a login on a test session before closing yours.

Rollback

Restore the previous SSSD configuration and run systemctl restart sssd.

References

• sssd-ldap(5), Debian manual pages Debian, vendor-doc, accessed 2026-10-18
• ANSSI-BP-028 v2.0 - Recommandations de configuration d'un système GNU/Linux (R67) ANSSI, guide, accessed 2026-10-18

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

People and lifecycle