Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Guide de reference - Format des fichiers de configuration PAM

16.3. Format des fichiers de configuration PAM

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.

16.3.1. Interface du module

Il existe quatre types d'interfaces pour les modules PAM, chacune correspondant � un aspect diff�rent du processus d'autorisation�:

  • auth — Cette interface de module sert � authentifier l'utilisateur. Elle demande par exemple la saisie d'un mot de passe pour lequel elle v�rifie la validit�. Les modules avec cette interface peuvent �galement �tablir des certificats d'identit�, tels que l'appartenance � un groupe ou des tickets Kerberos.

  • account — Cette interface de module sert � v�rifier que l'acc�s est bien autoris�. Par exemple, elle peut v�rifier si un compte utilisateur a expir� ou non, ou bien si l'utilisateur est autoris� � se connecter � un moment donn� de la journ�e.

  • password — Cette interface de module sert � d�finir et v�rifier les mots de passe.

  • session — Cette interface de module ser � 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.

NoteRemarque
 

Un module individuel peut fournir une interface de module quelconque ou toutes les interfaces de modules. Par exemple, pam_unix.so fournit les quatre interfaces de module.

Dans un fichier de configuration PAM, le champ relatif � l'interface de module est le premier � �tre d�fini. Par exemple, une ligne typique d'un fichier de configuration pourrait ressembler � l'extrait suivant�:

auth      required  pam_unix.so

Cette ligne donne l'instruction � PAM d'utiliser l'interface auth du module pam_unix.so.

16.3.1.1. Empilage d'interfaces de module

Les directives relatives aux interfaces de modules peuvent �tre empil�es ou plac�es les unes sur les autres, afin que de multiples modules soient 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 qu'un utilisateur puisse utiliser 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. Ensuite, si une authentification rhosts est �tablie avec succ�s, la connexion est autoris�e. En revanche, si l'authentification rhosts n'aboutit pas, une authentification de mot de passe standard est ex�cut�e.

16.3.2. Indicateurs de contr�le

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 � PAM la mani�re de 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 puisse se poursuivre. Si la v�rification d'un module de type 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 de type requisite �choue, l'utilisateur en est averti imm�diatement par le biais d'un message lui indiquant l'�chec du premier module de types required ou requisite.

  • sufficient — En cas d'�chec, les v�rifications de modules sont ignor�es. Toutefois, si la v�rification d'un module de type sufficient est r�ussie et qu'aucun module pr�c�dent de type 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 de type optional ne devient n�cessaire que pour la r�ussite d'une authentification lorsqu'aucun autre module ne r�f�rence l'interface.

ImportantImportant
 

L'ordre dans lequel les modules de type required sont appel�s n'est pas primordial. Les indicateurs de contr�les sufficient et requisite en revanche, donnent � l'ordre une importance vitale.

Pour PAM, il existe d�sormais une nouvelle syntaxe d'indicateurs de contr�le qui offre un contr�le encore plus pr�cis. Veuillez lire la documentation relative � PAM disponible dans le r�pertoire /usr/share/doc/pam-<version-number>/ (o� <version-number> correspond au num�ro de version de PAM) pour obtenir des informations sur cette nouvelle syntaxe.

16.3.3. Nom de module

Le nom de module donne � PAM le nom du module enfichable contenant l'interface module sp�cifi�e. Sous les versions plus anciennes de Red Hat Enterprise Linux, le chemin entier du module �tait fourni dans le fichier de configuration PAM, tel que /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 car les applications sont li�es � la version appropri�e de libpam, qui peut trouver la version correcte du module.

16.3.4. Arguments des modules

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 la base de donn�es pr�cise devant �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 <path-to-file> 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 des erreurs dans le fichier /var/log/messages.

 
 
  Published under the terms of the GNU General Public License Design by Interspire