Outils pour utilisateurs

Outils du site


ateliers:serveurmail:pam

Introduction

PAM

Pluggable Authentication Modules

PAM est le système permettant à Unix d'identifier les utilisateurs et de vérifier de quels droit dispose un compte de vérifier si le mot de passe est correct, de lancer des scripts au démarrage, etc…

Il est basé sur une architecture modulaire et des configuratiosn disponible dans ``/etc/pam.d/`` et ``/etc/security/``.

NSSwitch

NSSwitch permet aux outils Unix d'identification (``login``, ``shadow``, etc) de savoir où trouver les informations pour qu'ils puissent fonctionner (dans des fichiers, des serveurs DNS, des process, ou, par exemple, un annuaire ldap).

Il fonctionne avec nslcd qui permet de conserver en cache les informations des utilisateurs afin de pouvoir répondre aux requètes sans réinterroger à chaque fois les bases de données (et de permettre de pallier à de légères coupures de services).

Installation

Comme l'on va modifier les systèmes d'authentification et que donc l'on peut se retrouver coincé hors de la machine, il est recommandé de se prendre un shell en tant que root, permettant de remettre les choses en place éventuellement.

Avec tmux, cela se fait en faisant <Ctrl>+<B> pour ouvror une nouvelle fenêtre, puis

$ sudo -s

Nous nous baserons sur le Wiki Debian pour les procédures, le tout est détaillé en détail ci-dessous.

On commence par installer les paquets nécessaires.

$ sudo apt install libnss-ldapd nslcd libpam-ldapd

Attention à bien demander les variantes -ldapd et non -ldap des paquets, ils utilisent des systèmes plus récents.

Configuration

NSlcd

On configure nslcd en utilisant cette commande.

  $ sudo dpkg-reconfigure nslcd

On renseigne les valeurs fournies par le ldap comme suit :

  • LDAP server URI: ldapi:\/\/\/
  • LDAP server search base: dc=anarcha,dc=pink* * LDAP authentication to use: none * Use StartTLS: No**

Comme on se connecte via les sockets Unix, pas besoin de starttls. Le reste devrait être relativement logique. Si on veut connecter des machines distantes à ce server, il ne faudra pas oublier d'activer TLS.

Le fichier de configuration doit maintenant ressembler à ça:

/etc/nscld.conf
# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.
 
# The user and group nslcd should run as.
uid nslcd
gid nslcd
 
# The location at which the LDAP server(s) should be reachable.
uri ldapi:///
 
# The search base that will be used for all queries.
base dc=anarcha,dc=pink
 
# The LDAP protocol version to use.
#ldap_version 3
 
# The DN to bind with for normal lookups.
#binddn cn=admin,dc=anarcha,dc=pink
#bindpw jaaS9bie
 
# The DN used for password modifications by root.
#rootpwmoddn cn=admin,dc=anarcha,dc=pink
 
# SSL options
ssl off
#tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
 
# The search scope.
#scope sub

NSSwicth

Configuration de libnss-ldapd via ``dpkg-reconfigure``

$ sudo dpkg-reconfigure libpam-ldapd

On veut que NSSwitch utilise LDAP uniqueent pour ``passwd``, ``group`` et ``shadow``, qui permettent de récupérer les informations nécessaires à l'identification d'un utilisateur.

Le fichier de configuration de NSSwitch doit maintenant ressembler à ça :

/etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
 
passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files
 
hosts:          files dns
networks:       files
 
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
 
netgroup:       nis

On peut maintenant redémarrer nslcd et vérifier que tout fonctionne

$ sudo systemctl restart nslcd
$ sudo systemctl status nslcd
● nslcd.service - LSB: LDAP connection daemon
   Loaded: loaded (/etc/init.d/nslcd; generated; vendor preset: enabled)
   Active: active (running) since Wed 2018-06-27 19:57:02 CEST; 21s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 22257 ExecStop=/etc/init.d/nslcd stop (code=exited, status=0/SUCCESS)
  Process: 22268 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS)
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/nslcd.service
           └─22279 /usr/sbin/nslcd
 
juin 27 19:57:01 server02 systemd[1]: Starting LSB: LDAP connection daemon...
juin 27 19:57:01 server02 nslcd[22279]: version 0.9.7 starting
juin 27 19:57:02 server02 nslcd[22279]: accepting connections
juin 27 19:57:02 server02 nslcd[22268]: Starting LDAP connection daemon: nslcd.
juin 27 19:57:02 server02 systemd[1]: Started LSB: LDAP connection daemon.

libpam-ldapd

Comme nous utilisons libnss-ldapd, aucune configuration n'est nécessaire pour ce module. Mais au cas oú il fudrait changer les choses, pour désactiver un système par exemple, il faut configurer libpam-ldapd avec l'outil PAM adapté:

$ sudo pam-auth-update

Voici les fichiers communs de PAM et comment libpam-ldap les modifie.

/etc/pam.d/common-auth
[...]
# here are the per-package modules (the "Primary" block)
auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so minimum_uid=1000 use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Nous utilisons le module ldap avec le mot de passe saisi par l'utilisateur lors de la connexion (``use_first_pass``) afin d'éviter les saisies de commandes multiples. Nous réservons égalememnt l'utilisation de LDAP aux comptes ayant un uid >=1000 (Les comptes utilisateurs donc par opérations aux comptes systèmes).

# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore authinfo_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config

On utilise l'authentification ldap pour associer le compte utilisateur à la session. On garde un ``minimum_uid=1000`` pour ne pas utiliser d'utilusateur système avec ldap et, en fonction du retour de la commande LDAP, on valide ou non si l'utilisateur est autoriséà se connecter.

Si le compte d'utilisateur n'est pas trouvé dans la base (ou que la base est indisponible), alors PAM ignore ce module et continue.

bash /etc/pam.d/common-password
# here are the per-package modules (the "Primary" block)
password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_ldap.so minimum_uid=1000 try_first_pass
# here's the fallback if no module succeeds
password        requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password        required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Pour préparer les mots de passe, on commence par vérifier si il en existe un dans la base unix (en le hashant avec l'algo SHA512). Si il ne trouve pas, alors il continue avec ldap. Si il trouve, alors il saute les deux instructiosn suivantes, afin d'autoriser la connexion

LDAP utilise le premier mot de passe entré par l'utilisateur.

Cela signifie qu'une utilisatrice disposant d'un compte de type unix et d'un autre sur LDAP, alors elle peut avoir un mot de passe différent pour chaque système. Soit elle utilise le mot de passe unix, et PAM saute à pam_permit, soit elle utilise son mot de passe ldap, et le résultat de ``pass_unix.so`` sera ignoré et le mot de passe saisis sera envoyé à LDAP pour validation.

/etc/pam.d/common-session
# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session [success=ok default=ignore]     pam_ldap.so minimum_uid=1000
session optional        pam_systemd.so
# end of pam-auth-update config

Classiquement, on vérifie que l'utilisateur LDAP a bien un uid >= 1000 et si le compte n'existe pas, alors on ignore et on passe à la suite, afin de permettre aux utilisateurs purement système de continuer de fonctionner.

Le fichier common-session-noninteractive contiens la même chose que le common-session, à l'exception de la ligne relative à systemd 9vu que c'est ce qui est utilisé pour les utilisateurs n'ouvrant pas de terminal).

Il est maintenant possible de restreindre les accès à certains groupes ou à certains services enmodifiant les fichoers contenus dans ``/etc/security.conf``

ateliers/serveurmail/pam.txt · Dernière modification: 2018/06/27 20:54 par okhin