4.9 KiB
SSSD, premier contact.
SSSD sait faire de l'authentification LDAP et Kerberos et plein d'autres. On peut se limiter à Kerberos, on n'est pas obligé d'utiliser toutes les fonctionnalités.
Le fichier sssd.conf contient un paramétrage Kerberos (realm, etc). Les
possibilités de configuration ne sont pas aussi évoluées que celles qu'on
trouve dans '/etc/krb5.conf'. Il est possible d'en mettre un minimum dans
sssd.conf, et laisser le principal dans krb5.conf, ça tombe bien.
Depuis que j'ai installé et configuré SSSD, l'authentification de sudo sait non seulement utiliser mon mot de passe local, mais aussi mon mot de passe AD ! Et cerise sur le gateau : ça renouvelle automatiquement mon ticket Kerberos !
Debug SSSD
D'après sssd.conf(5), on active le debug avec la propriété debug_level à
valeur de 0 à 10, à placer dans toutes les sections de la configuration,
pas seulement dans [sssd]. On pourra utiliser un fichier de configuration
drop-in pour faciliter la mise en place.
Pour observer les logs:
# journalctl -f -g pam
# journalctl -f -u sssd.service -u sssd-pam.socket -u sssd-pam.service
# tail -f /var/log/auth.log
La commande sssctl du paquet sssd-tools donne plein d'infos utiles sur
l'état du service sssd, en particulier pour vérifier la configuration:
$ sudo sssctl config-check
Voir sssctl --help pour toutes les options (le man est quasi vide).
Service PAM pour SSSD
La documentation en ligne indique qu'il faut configurer les "services" de SSSD comme ceci:
$ head -2 /etc/sssd/sssd.conf
[sssd]
services = nss,pam
Mais à l'usage, on s'aperçoit que SSSD n'est pas utilisé dans le processus de login, et dans les logs on voit ceci:
$ journactl -u sssd-pam.socket
systemd[1]: Starting SSSD PAM Service responder socket.
sssd_check_socket_activated_responders[17888]:
Misconfiguration found for the pam responder.
The pam responder has been configured to be socket-activated but it's
still mentioned in the services' line in /etc/sssd/sssd.conf.
Please, consider either adjusting your services' line in
/etc/sssd/sssd.conf or disabling the pam's socket by calling:
"systemctl disable sssd-pam.socket"
systemd[1]: Dependency failed for SSSD PAM Service responder socket.
Donc on a deux choix possibles:
-
soit on laisse le fichier
sssd.confen l'état, et on désactive la socketsssd-pam.socket. -
soit on active la socket
sssd-pam.socketet on supprimepamde la liste des services danssssd.conf.
Sachant que par défaut la socket est activée à l'installation du paquet
sssd, le choix le plus facile c'est le n°2, on modifie la configuration
dans le fichier sssd.conf.
Activer SSSD dans GDM (password)
Quatre opérations à faire:
- basculer l'alternative
gdm-smartcardsurgdm-smartcard-smartcard-or-password - desactiver l'authentification par smartcard dans
dconfpour GDM - démarrer le service
sssd - redémarrer le service
gdm3
soit:
# update-alternatives --set gdm-smartcard /etc/pam.d/gdm-smartcard-sssd-or-password
# sed -Ei 's/(enable-smartcard-authentication)=.*/\1=false/' /etc/dconf/db/gdm.d/03-smartcard
# dconf update
# systemctl enable sssd.service sssd-pam.socket
# systemctl start sssd.service
# systemctl restart gdm3
Pour l'instant, on désactive gdm-smardcard dans la configuration GDM via dconf
parce que la gestion du PKCS#11 dans SSSD n'est pas encore configurée, et ce n'est
pas aussi facile qu'avec pam_pkcs11 ...
SSSD et PKCS#11
Pas certain que SSSD puisse fonctionner avec SmartCard + utilisateur local, la documentation mentionne explicitement LDAP comme sources d'identité, donc il faudrait joindre le domaine AD, fonctionnerait seulement online (sauf si cache).
TODO
Les choses à voir:
sss-certmapsss_cachep11-child
Et la configuration PKCS#11 dans SSSD ...