{{indexmenu_n>7}}

# Comprendre les permissions

Cette page vise à donner un aperçu de qui a le droit de faire quoi sur le serveur LDAP lors de son premier lancement. Les ACL sont configurables en [[technique:adminsys:ldap:utilisation#pour_modifier_la_configuration|modifiant la configuration]]. On pourra en ajouter, mais on gardera cette configuration.

Pour comprendre ce qui suit, on pourra lire [la documentation sur les ACL](https://www.openldap.org/devel/admin/access-control.html) ainsi que la documentation sur [la configuration générale](https://www.openldap.org/doc/admin24/slapdconf2.html).

Lorsque l'on lance le serveur LDAP pour la première fois, on trouve trois bases de données :

* `frontend`, une base de données spéciale qui contient les caractéristiques qui seront appliquées à toutes les autres base de données
* `config`, une base de données spéciale qui contient entre autres les permissions liées à la configuration
* `mdb`, qui contient la configuration des entrées que l'on utilise. En effet, son attribut `olcDbDirectory` vaut `/var/lib/ldap`, qui est le chemin de notre base de données, et son attribut `olcSuffix` est à `dc=picasoft,dc=net`, ce qui indique que toute requête concernant un DN qui termine par `dc=picasoft,dc=net` sera traitée par cette base de données.

Les entrées correspondante se voient dans la configuration :

{{ technique:adminsys:ldap:2020-09-08_18-05-38.png?nolink&200 |}}

### frontend

Les ACL définies ici sont appliquées par défaut à toutes les autres bases de données, et susceptibles d'être écrasées.

On trouve les ACL suivantes :

```
to * 
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage 
  by * break
  
to dn.exact="" 
  by * read
  
to dn.base="cn=Subschema" 
  by * read
```

Qui indiquent respectivement que :

* L'utilisateur `root` (ici dans le conteneur LDAP) a le droit de modifier l'ensemble des entrées du serveur
* N'importe qui a le droit de lire le `Base DN`, qui contient des informations sur les extensions utilisables avec le serveur LDAP, par exemple
* N'importe qui a le droit de lire l'entrée `cn=Subschema`, qui contient des informations sur les schémas chargés sur le serveur LDAP.

À titre d'exemple, voici ce qu'a le droit de voir un utilisateur quelconque voire non-authentifié.
{{ technique:adminsys:ldap:2020-09-08_15-58-21.png?nolink&500 |}}

### config

Même chose que pour `frontend`, et on retrouve en plus les attributs suivants :

* `olcRootDN` : `cn=admin,cn=config`
* `olcRootPW` : `XXX`

Ces attributs spécifient que le DN `cn=admin,cn=config` n'est sujet à aucun contrôle d'accès pour la base de données `config`. En d'autres termes, en se connectant avec `cn=admin,cn=config`, on peut tout faire avec `cn=config` (i.e. modifier la configuration).

Cette configuration est réalisée par l'exécution de [ce LDIF](https://github.com/osixia/docker-openldap/blob/stable/image/service/slapd/assets/config/bootstrap/ldif/01-config-password.ldif) présent dans l'image sur laquelle nous nous basons.

### mdb

La configuration initiale est réalisée par l'exécution de [ce LDIF](https://github.com/osixia/docker-openldap/blob/stable/image/service/slapd/assets/config/bootstrap/ldif/readonly-user/readonly-user-acl.ldif) de l'image Docker sur laquelle nous nous basons.

On retrouve deux ACL intéressantes :

```
to attrs=userPassword,shadowLastChange 
  by self write 
  by dn="cn=admin,dc=picasoft,dc=net" write 
  by anonymous auth 
  by * none
```

Ici, on indique que les attributs `userPassword` et `shadowLastChange` (utilisés notamment pour s'authentifier sur les machines et les services, car il faut bien pouvoir vérifier le mot de passe) :

* Peuvent être lus modifiés par soi-même (je peux changer mon mot de passe) et par l'administrateur (`cn=admin`)
* Peuvent être utilisés pour les mécanismes d'authentification
* Ne peuvent être lus par personne d'autre

En gros, je ne peux pas lire le mot de passe d'un autre utilisateur : je peux seulement essayer de m'authentifier, sans jamais avoir les droits de lecture sur le mot de passe.

Les ACL sont traitées dans l'ordre et le traitement s'arrête au premier match. Ainsi, tout ce qui concerne `userPassword` est traité ci-dessus, et ce qui suit s'applique à tout ce qui ne concerne **pas** `userPassword` :

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

Ici, on indique que :

* Je peux lire tous les attributs de mon entrée (par exemple, si je me connecte en tant que `qduchemi`, mon entrée est un `posixAccount`, et je peux lire mes attributs `sshPublicKey`, `sn`, etc).
* L'administrateur (`cn=admin`) peut lire et écrire toutes les entrées
* L'utilisateur en lecture seule (`cn=nss`) peut uniquement lire toutes les entrées
* Les autres ne peuvent rien faire

On peut vérifier empiriquement ces ACL en faisant des requêtes sur le LDAP, avec la syntaxe suivante :

```bash
ldapsearch -x -b "<base de la recherche>" -D "<DN pour l'authentification>" -H ldaps://ldap.picasoft.net:636 -W
```

Par exemple, j'essaye de lire les attributs de mon utilisateur :

```bash
ldapsearch -x -b "cn=qduchemi,ou=People,dc=picasoft,dc=net" -D "cn=qduchemi,ou=People,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W

dn: cn=qduchemi,ou=People,dc=picasoft,dc=net
objectClass: authorizedServiceObject
[...]
objectClass: top
cn: qduchemi
gidNumber: 501
homeDirectory: /home/users/qduchemi
[...]
userPassword:: <REDACTED>
```

On constate que j'ai bien accès à toutes les données de mon utilisateur, y compris mon mot de passe.

J'essaye de lire les données d'un autre utilisateur :

```bash
ldapsearch -x -b "cn=kyane,ou=People,dc=picasoft,dc=net" -D "cn=qduchemi,ou=People,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W

# search result
search: 2
result: 32 No such object
```

Je n'ai pas le droit : ok.

J'essaye de lire les données d'un compte quelconque avec l'utilisateur `nss` :

```
ldapsearch -x -b "cn=qduchemi,ou=People,dc=picasoft,dc=net" -D "cn=nss,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W

dn: cn=qduchemi,ou=People,dc=picasoft,dc=net
objectClass: authorizedServiceObject
[...]
cn: qduchemi
gidNumber: 501
homeDirectory: /home/users/qduchemi
[...]
```

On constate que l'utilisateur `nss` peut lire les entrées, mais qu'elles ne contiennent **pas** l'attribut `userPassword`, grâce à la première ACL.