Red Hat Linux 9: Guide de référence de Red Hat Linux | ||
---|---|---|
Prev | Chapter 14. Modules d'authentification enfichables (PAM) | Next |
Chaque fichier de configuration PAM comprend un ensemble de directives établies selon format suivant:
<interface-module> <indicateur-contrôle> <chemin-module> <arguments-module> |
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 — Ces modules sont utilisés pour authentifier l'utilisateur, par exemple en lui demandant son mot de passe et en le vérifiant. Les modules avec cette peuvent également établir des certificats d'identité, tels qu'une inscription à un groupe ou des tickets Kerberos.
account — Ces modules sont utilisés pour vérifier que l'accès est bien autorisé. Par exemple, ils peuvent vérifier si le compte a expiré ou non, ou bien si l'utilisateur est autorisé à se connecter à un moment donné de la journée.
password — Ces modules sont utilisés pour définir les mots de passe.
session — Ces modules sont utilisés pour configurer et gérer des sessions d'utilisateurs. These modules configure and manage user sessions. 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 a être défini. Par exemple, une ligne typique d'une configuration pourrait ressembler à l'extrait suivant:
auth required /lib/security/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 une 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 /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/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 non-cryptée 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 — en cas d'échec, les vérifications de modules sont ignorées. En revanche, si la vérification des modules est réussie, le résultat ne joue aucun rôle dans la réussite ou l'échec global de l'interface de ce module. 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. Dans ce cas précis, un module optional détermine l'authentification des PAM générale pour 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).
Les chemins d'accès aux modules indiquent à PAM où trouver les modules enfichables à utiliser avec l'interface de module spécifiée. Normalement, le chemin d'accès complet du module est indiqué, comme par exemple, /lib/security/pam_stack.so. Cependant, si ce n'est pas le cas, les système suppose que le module spécifié se trouve dans le répertoire /lib/security/, l'emplacement par défaut des modules PAM.
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 /lib/security/pam_userdb.so db=<chemin-au-fichier> |
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.