polux     Julien Thomas - TELECOM Bretagne frenchenglish

Déploiement de PAM LDAP

Objectifs

La maquette (voir la pages Objectifs) requiert que certains comptes, tel que l'utilisateur ayant accès aux mailbox des utilisateurs, soient partagés entre les serveurs. D'une manière plus général, il peut être intéressant de permettre à certains comptes d'avoir accès aux différents serveurs, pour des raisons de maintenance ou autres. Afin de satisfaire ses besoins, l'annuaire LDAP peut être utilisé.

Sous Linux, le partage de compte peut être configuré via LDAP, en utilisant les modules NSS et PAM :

  • NSS (ou Name Service Switch) permet la configuration de fichiers d'administration sous Unix/LINUX avec par exemple /etc/passwd (qui contient la list des passwords) ou /etc/group (la liste des groupes d'utilisateurs) via une ou plusieurs bases centralisées.
  • PAM (ou Pluggable Authentication Modules, modules d'authentification enfichables) est une solution permettant d'intégrer différents schémas d'authentification de bas niveau dans une API de haut niveau. Couplée avec NSS, elle permet par exemple de décentraliser la gestion des comptes d'une machine en la renvoyant en totalité vers un serveur d'authentification ou en partie seulement.

L'installation de ce deux modules se fait un simple emerge emerge -av nss_ldap pam_ldap. Les versions installées sur la maquette sont 0.78-r5 pour PAM et la 253 pour NSS_LDAP

Principe de fonctionnement

L'authentification PAM avec LDAP se fait en deux temps. Au niveau du client, la vérification du login se fait premièrement au niveau local. Ensuite, le module nsswitch (NameService Switch) détecte le lien avec LDAP et effectue une requête au serveur LDAP pour tester les identifiants de connexion.

Configuration du serveur LDAP

Au niveau du LDAP, les identifiants sont stockées de la manière suivante. Le DN base est ou=server,ou=accounts,ROOT_DN. Ensuite, les différents comptes sont classés suivants leur fonctionnalité. Les comptes utilisables sur tous les serveurs sont stockés dans la branche ou=all et chaque objet doit hériter des classes LDAP posixAccount et shadowAccount. Il est également possible de définir des groupes d'utilisateur (à la manière du fichier /etc/group). Dans l'annuaire LDAP, ils sont définis sur la branche ou=groups,ou=services,ROOT_DN. Chaque objet de cette branche doit hériter de l'objet LDAP posixGroup.

Configuration des clients

Plusieurs modifications sont à apporter au client afin qu'il puisse utiliser l'authentification via l'annuaire LDAP.

Lien avec LDAP

La première modification consiste à definir comment faire les liens avec l'annuaire.

  • /etc/ldap.conf : dans ce fichier, les informations à donner sont :
    • Quel est l'adresse du serveur LDAP? A ce niveau, plusieurs solutions existes : la variable host peut être définie. Mais celle-ci est plutôt obsolète et l'utilisation des URIs est conseillé. Nous avons donc uri ldaps://URL_LDAP:636
    • Quel est l'utilisateur nécessaire pour se connecter ? binddn cn=Manager,ROOT_DN
    • Quels sont les liens vers les différentes variables NS Switch ? Les comptes sont situés sur la branche ou=servers, ou=accounts,ROOT_DN?sub et les groupes sur ou=groups, ou=accounts,ROOT_DN?sub.
# host 10.133.14.1
# The distinguished name of the search base.
base ROOT_DN
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
uri ldaps ://URL_LDAP :636
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
...
# The distinguished name to bind to the server with.
binddn cn=Manager,ROOT_DN
# The credentials to bind with.
bindpw Managerpassword
...
# The port.
port 636
scope one
...
# Filter to AND with uid=
pam_filter objectclass=posixAccount
...
# The user ID attribute (defaults to uid)
pam_login_attribute uid
...
# RFC2307bis naming contexts
# Syntax :
# nss_base_XXX base ?scope ?filter
nss_base_passwd ou=servers, ou=accounts,ROOT_DN ?sub
nss_base_shadow ou=servers, ou=accounts,ROOT_DN ?sub
nss_base_group ou=groups,ou=services,ROOT_DN ?one
  • /etc/openldap/ldap.conf : le deuxième fichier à éditer pour les configurations avec LDAP est le fichier /etc/openldap/ldap.conf. Il permet de définir (de manière récurrente) les liens vers LDAP. Cette redéfinition est probablement due au fait que les outils n'utilisent pas tous /etc/ldap.conf, vue qu'ils ont été développés pour openLDAP. Comme pour /etc/ldap.conf, les informations à donner sont l'URI de connexion et la base du serveur, ROOT_DN. La ligne TLS_REQCERT allow indique que le chiffrement TLS sera mis en place.
URI ldap ://auth.polux.org
BASE ROOT_DN
TLS_REQCERT allow

Prise en compte des comptes distants

Après avoir configuré les liens avec l'annuaire LDAP, il faut indiquer au système d'exploitation que l'identification doit également passer par LDAP. Pour ce faire, des modifications sont à apporter au fichier /etc/nsswitch.conf. En plus de l'identification classique (compat), on indique avec ldap qu'il faut passer par un annuaire LDAP. Il est à noter que le fait de mettre compat puis ldap fait que la première vérification se fait en local puis ensuite si nécessaire sur le serveur ldap.

Gestion des droits des comptes distants

La dernière modification concerne les droits des comptes distants. Il faut interfacer correctement les droits locaux avec ceux définis par le serveur LDAP. Les fichiers à modifier, et décrits plus bas, sont /etc/pam.d/system-auth, /etc/pam.d/common-auth et /etc/pam.d/common-account. L'ensemble des modifications consiste à rajouter les librairies (.so) du projet pam_ldap, en plus des librairies pam_unix.so (ou autres) déjà présentes. Comme on peut également le voir, ces ajouts se font soit en mode sufficient, soit en mode optionnal, ce qui permet de rajouter les librairies ldap sans provoquer des erreurs au niveau des systèmes d'authentification existant (si le fichier /etc/nsswitch verifie bien compat avant ldap). Le fichier common-auth définit permet d'effecuter un mapping des autorisations
# host 10.133.14.1
# The distinguished name of the search base.
base ROOT_DN
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
uri ldaps ://URL_LDAP:636
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
...
# The distinguished name to bind to the server with.
binddn cn=Manager,ROOT_DN
# The credentials to bind with.
bindpw Managerpassword
...
# The port.
port 636
scope one
...
# Filter to AND with uid=
pam_filter objectclass=posixAccount
...
# The user ID attribute (defaults to uid)
pam_login_attribute uid
...
# RFC2307bis naming contexts
# Syntax :
# nss_base_XXX base ?scope ?filter
nss_base_passwd ou=servers, ou=accounts,ROOT_DN ?sub
nss_base_shadow ou=servers, ou=accounts,ROOT_DN ?sub
nss_base_group ou=groups,ou=services,ROOT_DN ?one

/etc/ldap.conf - Configuration de PAM-LDAP

URI ldap ://auth.polux.org
BASE ROOT_DN
TLS_REQCERT allow

/etc/openldap/ldap.conf - Configuration de PAM-LDAP

Le fichier common-account définit permet d'effecuter un mapping des comptes utilisateurs :

passwd : compat ldap
shadow : compat ldap
group : compat ldap

configuration de NSSwitch

auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok shadow
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so
account sufficient /lib/security/pam_unix.so
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_deny.so
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok shadow md5
password sufficient /lib/security/pam_ldap.so use_authtok
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
session optional /lib/security/pam_ldap.so

/etc/pam.d/system-auth

auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so

/etc/pam.d/common-auth

account sufficient pam_ldap.so
account sufficient pam_unix.so use_first_pass

/etc/pam.d/common-account



«Design-by-assumption works as long as assumptions hold. Assumptions are shortcuts to useful efficiencies, provided they are not violated. »
David S. Isenberg

«If the kernel is not evaluated to an MLS-capable protection profile, MLS features cannot be trusted regardless of how impressive the demonstration looks.»
J. Davidson