Activer le service SSSD
Garantit que le service SSSD (sssd.service) est activé et en cours d'exécution afin que l'authentification centralisée et la mise en cache des identifiants soient opérationnelles.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Le System Security Services Daemon (SSSD) sert d'intermédiaire vers les sources d'identité centralisées (LDAP, Active Directory, Kerberos, IPA) et met en cache les identifiants pour permettre l'authentification même lorsque l'annuaire est injoignable. Si sssd n'est pas actif, l'authentification centralisée, le contrôle d'accès basé sur l'hôte et la mise en cache des identifiants cessent de fonctionner : les connexions peuvent retomber sur des mécanismes plus faibles ou échouer totalement, et l'accès hors-ligne est perdu. Une identité centralisée et cohérente est un prérequis pour appliquer une politique d'authentification forte et auditable sur tout un parc.
Ce que vérifie Pavois
Pavois interroge l'état effectif de l'unité via service('sssd.service'), ce qui revient à systemctl is-enabled sssd et systemctl is-active sssd. Cela reflète ce que systemd fera réellement au démarrage et ce qui tourne maintenant, y compris les surcharges drop-in sous /etc/systemd/system/sssd.service.d/ et le masquage d'unité. Lire un fichier comme /etc/sssd/sssd.conf indiquerait seulement qu'une configuration existe, sans révéler que l'unité est masquée, en échec ou jamais démarrée.
only_if { file('/etc/sssd/sssd.conf').exist? }
describe service('sssd.service') do
it { should be_enabled }
it { should be_running }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled sssd && systemctl is-active sssd. Les deux doivent afficher respectivement enabled et active. Pour un contrôle complet, systemctl status sssd.service doit montrer Active: active (running) avec Loaded: ... enabled.
Inspecter et investiguer
Examinez le journal de l'unité avec journalctl -u sssd.service. Les événements d'authentification relayés par SSSD apparaissent dans /var/log/sssd/ (journaux par domaine) et dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Augmentez temporairement la verbosité avec sssctl logs-fetch ou debug_level dans sssd.conf lors d'un diagnostic.
Remédiation
Le plan de durcissement de Pavois agit sur la ressource service nommée sssd : il exécute l'action enable (pour que l'unité démarre à chaque boot) et l'action start (pour qu'elle tourne immédiatement). Il s'applique avec pavois harden apply. SSSD doit déjà être installé et un fichier /etc/sssd/sssd.conf valide avec au moins un domaine doit exister, sinon le service démarrera mais restera inactif ou échouera.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| 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 localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si SSSD est désactivé ou arrêté, les connexions centralisées échouent et l'authentification hors-ligne en cache devient indisponible, sur un hôte joint à un domaine, cela peut bloquer tous les utilisateurs de l'annuaire, y compris les administrateurs distants. Précautions : avant d'activer, vérifiez que /etc/sssd/sssd.conf existe, est en mode 0600 et définit un domaine fonctionnel ; contrôlez la connectivité à l'annuaire ; et conservez un compte local de secours (ou un accès console) pour ne pas être verrouillé si une mauvaise configuration de SSSD empêche l'authentification. Testez avec sssctl config-check avant un déploiement large.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R67 | direct | 2.0 | haute |
| NIST | CM-6(a), IA-5(10) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| DISA STIG | UBTU-22-254015, UBTU-24-100660 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.