Red Hat Enterprise Linux 3: Guide de référence | ||
---|---|---|
Précédent | Chapitre 15. Modules d'authentification enfichables (PAM) | Suivant |
Chaque fichier de configuration PAM comprend un ensemble de directives établies selon format suivant :
<module interface> <control flag> <module name> <module arguments> |
Les sections suivantes décrivent ces éléments un par un.
Il existe quatre types d'interface pour les modules PAM, chacune correspondant à un aspect différent du processus d'autorisation :
auth — Ce module d'interface est utilisé pour authentifier l'utilisateur, par exemple en lui demandant son mot de passe et en le vérifiant. Les modules avec cette interface peuvent également établir des certificats d'identité, tels qu'une inscription à un groupe ou des tickets Kerberos.
account — Ce module est utilisé pour vérifier que l'accès est bien autorisé. Par exemple, il peut vérifier si un compte d'utilisateur a expiré ou non, ou bien si l'utilisateur est autorisé à se connecter à un moment donné de la journée.
password — Ce module est utilisé pour définir et vérifier les mots de passe.
session — Ce module est utilisé pour configurer et gérer des sessions d'utilisateurs. Les modules ayant cette interface peuvent également effectuer des tâches supplémentaires requises pour autoriser l'accès, comme par exemple pour monter le répertoire personnel d'un utilisateur ou activer sa boîte aux lettres.
![]() | Remarque |
---|---|
Un module individuel peut fournir une interface de module particulière ou toutes les interfaces de modules. Par exemple, pam_unix.so fournit les quatre interfaces. |
Dans un fichier de configuration PAM, l'interface de module est le premier aspect à être défini. Par exemple, une ligne typique d'une configuration pourrait ressembler à l'extrait suivant :
auth required pam_unix.so |
Cette ligne donne l'instruction aux PAM d'utiliser l'interface auth du module pam_unix.so.
Les directives des interfaces de modules peuvent être empilées ou placées les unes sur les autres, afin que de multiples modules puissent être utilisés ensemble dans un but particulier. Dans de telles circonstances, l'ordre dans lequel les modules sont répertoriés est très important au niveau du processus d'authentification.
Grâce à l'empilage, un administrateur peut facilement exiger la présence de différentes conditions avant d'autoriser un utilisateur à s'authentifier. Par exemple, rlogin utilise normalement cinq modules auth empilés, comme le montre son fichier de configuration PAM :
auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth |
Avant d'accorder l'autorisation d'utilisation de rlogin, PAM s'assure que le fichier /etc/nologin n'existe pas, que l'utilisateur n'essaie pas de se connecter à distance en tant que super-utilisateur (ou root) au moyen d'une connexion réseau et que toutes les variables d'environnement peuvent être chargées. Si une authentification rhosts peut être établie avec succès, la connexion est alors autorisée. En revanche, si l'authentification rhosts échoue, une authentification standard de mot de passe est exécutée.
Lorsqu'ils sont appelés, tous les modules PAM donnent un résultat indiquant soit la réussite, soit l'échec. Les indicateurs de contrôle indiquent aux PAM comment traiter ce résultat. Étant donné que les modules peuvent être empilés dans un ordre bien précis, les indicateurs de contrôle décident de l'importance de la réussite ou de l'échec d'un module spécifique par rapport au but général d'authentification d'un utilisateur pour un service donné.
Il existe quatre types d'indicateurs de contrôle prédéfinis, à savoir :
required — Le module doit être vérifié avec succès pour que l'authentification puise se poursuivre. Si la vérification d'un module portant l'indication required échoue, l'utilisateur n'en est pas averti tant que tous les modules associés à cette interface n'ont pas été vérifiés.
requisite — Le module doit être vérifié avec succès pour que l'authentification puisse se poursuivre. Cependant, si la vérification d'un module requisite échoue, l'utilisateur en est averti immédiatement par le biais d'un message lui indiquant l'échec du premier module required ou requisite.
sufficient — En cas d'échec, les vérifications de modules sont ignorées. Toutefois, si la vérification d'un module portant l'indication sufficient est réussie et qu'aucun module précédent portant l'indicateur required n'a échoué, aucun autre module de ce type n'est nécessaire et l'utilisateur sera authentifié auprès du service.
optional — Les vérifications de modules sont ignorées. Un module portant l'indication optional devient nécessaire pour la réussite d'une authentification lorsqu'aucun autre module ne fait référence à cette interface.
![]() | Important |
---|---|
L'ordre dans lequel les modules required sont appelés n'est pas primordial. Les modules portant l'indication sufficient et requisite en revanche, donnent à l'ordre une importance vitale. |
Il existe désormais pour PAM une nouvelle syntaxe d'indicateurs de contrôle offrant un contrôle encore plus précis. Veuillez lire les documents PAM figurant dans le répertoire /usr/share/doc/pam-<numéro-de-version>/ pour obtenir des informations sur cette nouvelle syntaxe (où <numéro-de-version> correspond au numéro de version de PAM).
Le nom de module donne à PAM le nom du module enfichable contenant l'interface de module spécifiée. Dans les versions plus anciennes de Red Hat Enterprise Linux, le chemin entier du module était fourni dans le fichier de configuration PAM, comme /lib/security/pam_stack.so. Toutefois, depuis l'arrivée de systèmes multilib qui stockent des modules PAM de 64-octets dans le répertoire /lib64/security/, le nom du répertoire est omis vu que les applications sont liées à la version appropriée de libpam, qui peut trouver la correcte version du module.
PAM utilise des arguments pour transmettre des informations à un module enfichable lors du processus d'authentification de certains modules.
Par exemple, le module pam_userdb.so utilise des indications secrètes stockées dans un fichier de la base de données Berkeley pour authentifier les utilisateurs. La base de données Berkeley est une base de données Open Source intégrée dans de nombreuses applications. Le module nécessite un argument db pour spécifier à la base de données Berkeley quelle base de données précise doit être utilisée pour le service demandé.
Une ligne pam_userdb.so typique d'un fichier de configuration PAM ressemble à l'extrait suivant :
auth required pam_userdb.so db=<path-to-file> |
Dans l'exemple précédent, remplacez <chemin-au-fichier> par le chemin d'accès complet au fichier de la base de données Berkeley DB.
Les arguments non-valides ne sont pas pris en compte et n'ont aucune incidence sur la réussite ou l'échec du module PAM. Toutefois, la plupart des modules rapporteront une erreur dans le fichier /var/log/messages.
Précédent | Sommaire | Suivant |
Fichiers de configuration PAM | Niveau supérieur | Exemples de fichiers de configuration PAM |