Ajout d'un service avec authentification par LDAP

Cette page suppose que vous êtes connecté au serveur LDAP avec le compte d'administration.

Elle décrit les étapes générales à effectuer pour connecter un service quelconque au serveur LDAP. En pratique, cela veut dire que les utilisateurs disposant d’un compte sur le LDAP pourront se connecter au service en l’utilisant.

C’est donc essentiellement pertinent pour les services “internes” ou “limités”, comme le Wiki, le Cloud, Grafana, etc.

Cette étape est optionnelle. En effet, il existe déjà un utilisateur en lecture seule sur le LDAP, nss. Si malgré tout vous voulez créer un utilisateur dédié qui aura le droit de lire sur le LDAP, suivez ces étapes. Sinon, passez à la section suivante.

C’est parce que pour s’authentifier, il faut utiliser le DN complet du compte (exemple : cn=qduchemi,ou=People,dc=picasoft,dc=net). Or, quand je m’authentifie sur le Wiki, j’utilise seulement mon login (qduchemi). Cela signifie donc qu’à un moment ou un autre, le Wiki doit chercher dans le LDAP si une entrée avec cn=qduchemi existe, par exemple (ça dépend du filtre qu’on choisit). Et pour effectuer cette recherche, il faut des droits de lecture.

On créera un compte sous ou=Services, avec pour cn le nom du service (exemple : wiki, nextcloud).

On lui attribuera ensuite les classes organizationalRole et simpleSecurityObject, et on choisira un mot de passe pour userPassword que l’on ajoutera dans le vaultwarden. Le chemin utilisé dans le pass est par convention Tech/LDAP/<Nom Service>/cn=<cn>,dc=picasoft,dc=net.

Maintenant que notre utilisateur est créé, on doit lui donner les accès en lecture seule au LDAP.

Le plus simple est de modifier la configuration avec ApacheDirectoryStudio.

Dans l’entrée olcDatabase={1}mdb,cn=config, on va modifier les ACL pour permettre au compte nouvellement créé de lire le LDAP.

On cherche l’attribut olcAccess dont le début ressemble à :

to * by self read by dn="cn=admin,dc=picasoft,dc=net" write by dn="cn=nss,dc=picasoft,dc=net" read by * none

On modifie cet attribue pour lui ajouter, avant by * none, la chaîne suivante :

by cn=<cn>,ou=Services,dc=picasoft,dc=net read

où <cn> est le CN choisi pour votre utilisateur.

La valeur de l’attribut ressemblera alors à :

to * by self read by dn="cn=admin,dc=picasoft,dc=net" [...] by cn=<cn>,ou=Services,dc=picasoft,dc=net read by * none

On peut tester le compte a bien les droits en lecture avec la requête suivante :

snippet.bash

ldapsearch -x -D "cn=<cn>,ou=Services,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W

Après avoir entré le mot de passe, si le résultat contient les entrées du LDAP, c’est que le compte est fonctionnel.

Chaque service a sa propre configuration, mais en général on trouvera les paramètres suivants :

• User bind DN : c’est le DN de notre utilisateur en lecture seule. On utilisera cn=<cn>,ou=Services,dc=picasoft,dc=net, où <cn> vaut nss si vous n’avez pas créé de compte spécifique.
• User bind password : le mot de passe de l’utilisateur en lecture seule, accessible dans le vaultwarden
• URL : ldaps://ldap.picasoft.net
• Port : 636

On demande généralement le DN racine à partir duquel chercher les utilisateurs. On choisira ou=People,dc=picasoft,dc=net, car tous les comptes utilisés pour se connecter sur un service ou une machine sont sous cette OU.

Ensuite, il y a généralement un filtre pour pouvoir chercher l’utilisateur. Il aura en général la forme suivante :

(&(objectClass=posixAccount)(uid=%s))

Dans cet exemple, on cherche une entrée qui a :

• La classe posixAccount
• Et l’UID correspondant au login que l’utilisateur essaye

Encore une fois, tout ceci est modulable : vous pouvez faire des filtres n’autorisant que les personnes d’un certain groupe à accéder à tel service, ou carrément mapper des groupes sur des autorisations spécifiques du service.

Si le service que vous déployé doit être réservé aux personnes ayant un attribut authorizedService à <service>, le filtre ressemblera à ceci :

(&(objectClass=posixAccount)(uid=%s)(|(authorizedService=<service>)(authorizedService=\2a))

Ce qui signifie qu’il ne faut autoriser que les utilisateurs :

• Qui ont une classe posixAccount et un uid correspondant au login
• Et dont l’attribut authorizedService est à <service> ou à * (représenté par \2a)