Authentification LDAP sur les machines

Le but est de pouvoir utiliser les comptes LDAP pour :

• Se connecter aux machines via une clé SSH
• Attribuer des groupes (docker, sudo) en fonction des groupes LDAP

L’idée est qu’au lieu d’avoir à configurer les utilisateurs sur chaque machine, on centralise les informations sur le LDAP (clés publiques, machines autorisées, mots de passe…), et on ne les stocke qu’une seule fois.

Sans LDAP, on devrait modifier son mot de passe sur chaque machine, etc.

Pour commencer, il vaut mieux éteindre nscd (Name Service Caching Daemon), qui permet de mettre en cache certaines informations à propos des utilisateurs. Ce démon risque de masquer des problèmes de configuration :

snippet.bash

systemctl stop nscd

Traditionnellement, les utilisateurs d’une machine Linux sont configurés via le fichier /etc/passwd.

NSS (pour Name Service Switch) permet de remplacer ces fichiers de configuration par l’interrogation d’une base de données centralisée, comme LDAP. On commence donc par configurer NSS pour récupérer les données du serveur LDAP.

Pour ce faire, il faut installer le paquet libnss-ldapd, qui est la version moderne de libnss-ldap.

snippet.bash

apt install libnss-ldapd

Ce paquet installe automatiquement :

• libpam-ldapd, qui permet à PAM de déléguer l’authentification aux outils installés via les autres paquets (en utilisant le serveur LDAP, donc)
• nslcd, qui est un démon qui réalise les requêtes LDAP à proprement parler

Lors de l’installation, des modales s’ouvrent et demandent plusieurs informations.

D’abord, l’URI de notre serveur LDAP. Nous utilisons LDAPS pour sécuriser les connexions, ce sera donc ldaps://ldap.picasoft.net:636.

Ensuite, le DN qui sert de base aux recherches. Toutes les entrées du LDAP se situe sous dc=picasoft,dc=net.

Comme on utilise une connexion sécurisée, le serveur doit pouvoir fournir un certificat valide. On choisit demand pour imposer la récupération et la vérification de ce certificat.

Enfin, on nous demande quelles “bases de données” récupérer depuis le serveur LDAP. De notre côté, on aura besoin de :

• passwd, pour les utilisateurs
• group, pour les groupes POSIX
• shadow, pour les mots de passes des utiisateurs

# The DN to bind with for normal lookups.
binddn cn=nss,dc=picasoft,dc=net
bindpw XXX

Ensuite, on démarre les services nécessaires :

snippet.bash

systemctl start nscd
systemctl start nslcd

On vérifie que NSS est fonctionnel :

snippet.bash

getent passwd
getent group

Les utilisateurs et les groupes du LDAP devraient être affichés.

À ce stade, on peut se connecter en tant que n’importe quel utilisateur du LDAP, pourvu que l’on ait son mot de passe, par exemple :

snippet.bash

su mattermost

Chaque utilisateur LDAP a un ou plusieurs attributs host qui définissent la ou les machines sur lesquelles ils ont le droit de se connecter.

Dans notre configuration, cet hôte correspond à l’hostname de la machine (pica01-test, pica02…).

On ajoutera donc à la fin de /etc/nslcd.conf la ligne suivante :

pam_authz_search (&(objectClass=posixAccount)(uid=$username)(|(host=$hostname)(host=\\2A)))

Ce qui signifie : chercher une entrée LDAP qui a pour classe posixAccount, pour uid le login de l’utilisateur, et qui a pour attribut host soit le hostname de la machine, soit *.

L’objectif de cette partie est d’indiquer aux machines clientes quels groupes attribuer aux utilisateurs en fonction des groupes LDAP dans lesquels ils sont. En particulier, on souhaite que :

• Le groupe tech attribue le groupe docker
• Le group admin attribue les groupes sudo et docker

Voir la documentation complète.

Pour cela, on commence par ajouter au fichier /etc/pam.d/common-auth la ligne :

auth    required                        pam_group.so use_first_pass

Dans le fichier /etc/security/group.conf, on ajoute :

*;*;%tech;Al0000-2400;docker
*;*;%admin;Al0000-2400;sudo,docker

Les champs sont séparés par des espaces. Dans l’ordre, par exemple :

• * : concerne tous les services PAM (su, sudo, sshd, login…)
• * : concerne tous les TTY (donc tous les terminaux)
• %admin : le % indique un groupe. Ainsi, tous les utilisateurs du groupe admin…
• Al0000-2400 n’importe quand (All days, entre 00h00 et 24h00)…
• sudo : se verront attribuer les groupe sudo et docker.

Lors de sa première connexion, un utilisateur n’a pas de home. Il faut donc lui créer. Pour cela, on ajoute au fichier /etc/pam.d/common-session la ligne :

session optional        pam_mkhomedir.so

Maintenant, un nouvel utilisateur sur une machine aura un home créé automatiquement, à partir de l’attribut homeDirectory.

Pour utiliser les clés SSH entrées dans le LDAP pour l’authentification, il faut indiquer à sshd de requêter le LDAP lors des tentatives de connexion. Pour cela, on crée le script /etc/ssh/ldapssh.sh :

#!/bin/bash
/usr/bin/ldapsearch -x -H ldaps://ldap.picasoft.net -b dc=picasoft,dc=net -D cn=nss,dc=picasoft,dc=net -w <password> '(&(objectClass=posixAccount)(uid='"$1"'))' 'sshPublicKey' | /bin/sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp'

Où <password> est le mot de passe de l’utilisateur nss.

snippet.bash

$ chmod +x /etc/ssh/ldapssh.sh

Ce script récupère tous les attributs sshPublicKey de l’utilisateur, c’est à dire toutes ses clés publiques, et les concatène ($1 désigne le login de l’utilisateur).

Ensuite, on modifie dans /etc/ssh/sshd_config :

PubkeyAuthentication yes
AuthorizedKeysCommand /etc/ssh/ldapssh.sh
AuthorizedKeysCommandUser nobody
PermitRootLogin no

TLS_CACERT	/etc/ssl/certs/ca-certificates.crt

Ces paramètres indiquent qu’à chaque tentative de connexion d’un utilisateur, il faut utiliser le script /etc/ssh/ldapssh.sh, lancé en tant que nobody, pour récupérer les clés publiques autorisées.

On redémarre les services dont on a modifié la configuration :

snippet.bash

systemctl restart nscd
systemctl restart nslcd
systemctl restart sshd

On supprime le cache nscd pour ne pas avoir de valeurs qui n’existent plus :

snippet.bash

nscd --invalidate=group
nscd --invalidate=passwd

Si nscd n’est pas trouvé, il pourrait être dans /usr/bin/nscd.

Tout devrait être fonctionnel.