Informations et configuration de PAM (Pluggable Authentification Modules)
But de ce document
Ce document me sert de mémo pour la compréhension et la configuration de PAM (Pluggable Authentification Modules » sous Debian. Je le diffuse en espérant qu’il serve à d’autres personnes.
PAM c’est quoi ?
Le système PAM est un ensemble de modules permettant de gérer l’authentification sur un système Linux.
Cela permet de rendre les différents programmes nécessitant une authentification (login, su, ssh, kdm,..) indépendants de la base de données gérant les comptes utilisateurs (passwd, LDAP, MySQL, Domaine Windows avec Winbind,...).
De plus avec PAM, l’authentification ne se limite pas à la gestion d’un login/password, mais va beaucoup plus loin comme nous le verrons dans ce document.
ATTENTION
Une erreur dans la modification des fichiers de configuration de PAM peut entraîner l’impossibilité de se connecter même sous root. Avant de modifier la configuration, il est fortement recommandé de se connecter sous une autre console en root pour pouvoir corriger le problème.
Les 4 groupes de modules
Dans un fichier de configuration de PAM, nous allons retrouver les différents modules répartis en 4 groupes. Un module (ex : pam_unix.so) pouvant être utilisé dans plusieurs groupes.
Groupe | Fonction |
---|---|
auth | Authentification : Établit en général la correspondance entre l’utilisateur et le mot de passe, mais toutes les authentifications ne sont pas de ce type, il existe par exemple des schémas d’authentification basés sur le matériel. |
account | Vérification du compte utilisateur : Est-ce que le mot de passe est encore valide ? ; Cet utilisateur a t-il le droit d’accéder au service demandé ? L’utilisateur a t-il le droit de se connecter à cette date et à cette heure ? |
password | Habituellement, les services sont fortement couplés avec un des groupes auth. Ce groupe permet par exemple d’autoriser le changement de mot de passe. |
session | Ce groupe est utilisé après l’authentification pour ouvrir la session, monter les répertoires personnels, activer sa boite mail,... |
Présentation des différents fichiers de configurations de PAM
Les fichiers de configurations de PAM, sont disponibles dans « /etc/pam.d/ ».
Dans ce dossier, nous retrouverons un fichier de configuration pour chaque service (programme) ayant besoin d’une authentification (su, login, ssh, ftp,..). Nous trouverons également des fichiers communs (common-*) permettant de simplifier la configuration. Ces fichiers communs seront inclus dans les fichiers des services à l’aide de la directive « @include common-* ».
Présentation de quelques fichiers disponibles dans « /etc/pam.d/ :
Fichier | Commentaire |
---|---|
common-account | Fichier commun pour les modules du groupe « account » |
common-auth | Fichier commun pour les modules du groupe « auth » |
common-password | Fichier commun pour les modules du groupe « password » |
common-session | Fichier commun pour les modules du groupe « session » |
kdm | Utilisé pour l’authentification de KDM |
kscreensaver | Utilisé pour l’authentification pour la sortie de l’écran de veille avec un mot de passe ou pour le déverrouillage de la session. |
login | Utilisé pour l’authentification sur une console (ex : ALT+F1) |
ssh | Utilisé pour l’authentification de ssh |
su | Utilisé pour l’authentification de su (changement d’utilisateur) |
sudo | Utilisé par sudo |
Les indicateurs de contrôle de PAM
Lors d’une vérification, chaque module retourne un résultat et en fonction de celui-ci et de l’indicateur de contrôle indiqué avant, PAM sait ce qu’il doit faire.
Il existe plusieurs indicateurs de contrôle :
Indicateur | Description |
---|---|
required | Si le résultat du test échoue, les autres modules sont quand même analysés avant de prendre une décision finale. |
sufficient | Si le résultat est positif, le résultat global sera positif même si les modules précédents de type « required » étaient en échec. |
requisite | Si le résultat du test échoue, l’analyse est interrompue et l’utilisateur est immédiatement averti de l’échec. |
optional | Que le résultat soit positif ou négatif, cela n’aura aucune importance dans l’authentification globale sauf si ce module est le seul testé. |
Les arguments passés en options
Chaque module peut utiliser des arguments. Ceux-ci sont écrits à la fin du nom du module. Par exemple, voici les arguments que le l’on peut trouver pour le module « pam_unix » :
Arguments | Description |
---|---|
debug | Augmente les logs dans syslog |
use_first_pass | Reprend le mot de passe fourni par le module précédent pour éviter à l’utilisateur de le saisir plusieurs fois |
nullok | Autorise les mots de passe vides |
Exemple de fichier de configuration
Dans un fichier nous retrouverons, un ou plusieurs modules avec un indicateur de contrôle (required, sufficient,..) avant le nom du module et éventuellement des options de configuration après (debug, nullok, use_first_pass ,..)
Attention : L’ordre des modules dans un fichier de configuration de PAM est important.
Un fichier de configuration PAM ressemble à ceci :
#%PAM-1.0
auth required pam_securetty.so
auth required pam_unix.so shadow nullok
auth required pam_nologin.so
account required pam_unix.so
password required pam_cracklib.so
password required pam_unix.so shadow nullok use_authtok
session required pam_unix.so
La première ligne est un commentaire car elle commence par un #
auth required pam_securetty.so
Cette ligne sert à s’assurer que, si l’utilisateur essaie de se connecter en tant qu’utilisateur root, le terminal sur lequel il se connecte fait partie de la liste se trouvant dans le fichier /etc/securetty, si ce fichier existe.
auth required pam_unix.so shadow nullok
Cette ligne fait en sorte que le mot de passe de l’utilisateur soit demandé et vérifié.
auth required pam_nologin.so
Cette ligne vérifie si le fichier /etc/nologin existe. Si c’est le cas et que l’utilisateur n’est pas un utilisateur root, l’authentification échoue.
account required pam_unix.so
Cette ligne active la vérification des comptes si nécessaire. Par exemple, si des mots de passe masqués ont été activés, le module pam_unix.so vérifie si le compte est périmé ou si l’utilisateur a changé son mot de passe pendant le délai de grâce alloué.
password required pam_cracklib.so
Cette ligne teste les mots de passe récemment modifiés afin de déterminer s’ils peuvent être détectés facilement par un programme de détermination de mots de passe utilisant un dictionnaire.
password required pam_unix.so shadow nullok use_authtok
Cette ligne spécifie que le module pam_unix.so doit être utilisé si le programme login change le mot de passe de l’utilisateur. (Cela ne se produit que lorsqu’un module auth détermine que le mot de passe doit être changé - quand un mot de passe masqué est périmé, par exemple.)
session required pam_unix.so
Cette ligne indique que le module pam_unix.so doit être utilisé pour gérer la session. En ce moment, ce module ne fait rien du tout ; il pourrait être remplacé par tout autre module nécessaire ou complété par la superposition de modules.
Autres sources de documentation :
Page de man en français : http://www.delafond.org/traducmanfr/man/man8/pam.8.html
La bible sur PAM en anglais : http://www.kernel.org/pub/linux/libs/pam/
Référence des modules : http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html
Historique des modifications
Version | Date | Commentaire |
---|---|---|
0.1 | 13/07/06 | Création par Tony GALMICHE |
0.2 | 15/08/06 | Mise en ligne |
Commentaires
Informations et configuration de PAM (Pluggable Authentification
La traduction du comportement de "sufficient" est erronée. Comme on peut le lire sur la page http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html, (citée en référence), "sufficient" est suffisant au sens mathématique du terme.
Si un module marqué "sufficient" réussi, les autres modules ne sont pas testés. S’ilrate, cela n’a aucune influence sur les autres, précédents ou suivants.
Dans le cas d’une combinaison
required toto.sosufficient tata.sorequired titi.so
Si tata reussi, le resultat est celui de toto et titi n’est même pas essayé.
si tata rate, le résultat dépend de toto et titi.
Voilà le texte de la page de référence :
sufficient
success of such a module is enough to satisfy the authentication requirements of the stack of modules (if a prior required module has failed the success of this one is ignored). A failure of this module is not deemed as fatal to satisfying the application that this type has succeeded. If the module succeeds the PAM framework returns success to the application immediately without trying any other modules.