Le 5 nov. 09 à 15:09, Christian Pélissier a écrit :
Plus un système est documenté et simple à mettre en oeuvre, logique à
configurer et plus il est adopté. Personnelement je pense que s'il
faut
jouer aux devinettes et faire des dizaines d'essais avant d'aboutir
cela
Avec pam, tu n'as pas le choix de toute façon. Dès que tu sors des
clous, ça devient totalement inévitable tellement la syntaxe est
complexe.
Pour une auth classique en
LDAP, il y a un exemple fonctionnel dans ma présentation GUSES.
Celui joint fonctionne avec OpenLDAP et les services Sun.
Y a ça qui traine dedans :
rlogin auth sufficient pam_rhosts_auth.so.1
Même si rlogin est pas démarré, c'est une fonction qu'il est vraiment
souhaitable de désactiver.
Mon mien tout réduit et sans ldap, mais kerberisé à la place :
# Default definitions for Authentication management
other auth requisite pam_authtok_get.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_unix_auth.so.1 server_policy
other auth sufficient pam_krb5.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
# Default definition for Account management
#
other account requisite pam_roles.so.1
other account sufficient pam_unix_account.so.1 server_policy
other account requisite pam_krb5.so.1
other account required pam_deny.so
#
# Default definition for Session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
#
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1 server_policy
--
_______________________________________________
Liste (Open)Solaris francophone
ug-fosug@xxxxxxxxxxxxxxx
http://www.opensolaris.org/jive/forum.jspa?forumID=109
|