{{indexmenu_n>25}}

# 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`)