Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:adminsys:ldap:add_service [2020/09/08 19:01] – qduchemi
+++ technique:adminsys:ldap:add_service [2022/09/23 10:20] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
 {{indexmenu_n>25}}
-# Ajout d'un service connecté au LDAP
+# Ajout d'un service avec authentification par LDAP
+Cette page suppose que vous êtes [[technique:adminsys:ldap:utilisation|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.
+## Ajout d'un utilisateur en lecture seule
+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.
+<bootnote question>Pourquoi a-t-on besoin d'un utilisateur en lecture seule pour faire de l'authentification ?</bootnote>
+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 [[asso:tuto:vaultwarden|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.
+<bootnote>On peut se référer à [[technique:adminsys:ldap:acl|la page concernant les permissions]] pour mieux comprendre.</bootnote>
+Le plus simple est de [[technique:adminsys:ldap:utilisation#pour_modifier_la_configuration|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 :
+```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.
+## Configuration du service
+### Configuration de l'utilisateur en lecture seule
+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 [[asso:tuto:vaultwarden|vaultwarden]]
+* `URL` : `ldaps://ldap.picasoft.net`
+* `Port` : `636`
+### Filtre
+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
+<bootnote web>Les filtres ne sont pas traités précisément ici, voir [une documentation](https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html) pour des exemples.</bootnote>
+<bootnote warning>Le `%s` est spécifique à la syntaxe du service et se réfère l'UID testé, voir la configuration LDAP du service pour savoir comment écrire ses requêtes.</bootnote>
+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.
+### Utilisation de authorizedService
+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`)