Différences

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

--- technique:adminsys:ldap:acl [2020/09/08 16:58] – créée qduchemi
+++ technique:adminsys:ldap:acl [2021/11/22 22:29] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. qduchemi
@@ Ligne 1: / Ligne 1: @@
-{{indexmenu_n>3}}
+{{indexmenu_n>7}}
-# Configurer les permissions
+# Comprendre les permissions
-Cette page vise à donner un aperçu de qui a le droit de faire quoi sur le serveur LDAP. Les ACL sont configurables en [[technique:adminsys:ldap:utilisation#pour_modifier_la_configuration|suivant ce tutoriel]].
+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.
-## root
+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).
-Depuis le conteneur LDAP, l'utilisateur `root` a tous les droits sur le serveur LDAP (lecture, modification...). Ceci fonctionnera avec les commandes de type `ldapsearch`, `ldapmodify`, etc. En pratique, on utilise ApacheDirectoryStudio.
+Lorsque l'on lance le serveur LDAP pour la première fois, on trouve trois bases de données :
-## N'importe qui
+* `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.
-Tout le monde (y compris les utilisateurs anonymes) a le droit de lire l'objet racine du LDAP (qui donne des informations sur les extensions supportées par le serveur, par exemple).
+Les entrées correspondante se voient dans la configuration :
-Ici, on interroge le serveur LDAP sans authentification :
+{{ technique:adminsys:ldap:2020-09-08_18-05-38.png?nolink&200 |}}
-{{ :technique:adminsys:ldap:2020-09-08_16-31-31.png?nolink&500 |}}
+### frontend
-En revanche, aucune entrée du LDAP n'est lisible sans autorisation spécifique.
+Les ACL définies ici sont appliquées par défaut à toutes les autres bases de données, et susceptibles d'être écrasées.
-## cn=admin,cn=config
+On trouve les ACL suivantes :
-Le DN `cn=admin,cn=config` a le droit de modifier la configuration de LDAP. Son mot de passe est défini dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
+```
+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
+```
-La configuration est faite dans `olcDatabase={0}config,cn=config`.
+Qui indiquent respectivement que :
-Ici, `olcAccess` indique que seul `root` peut changer la configuration, mais l'attribut `olcRootDN` (qui vaut `cn=config,cn=admin`) indique que le DN `cn=config,cn=admin` n'est pas concerné par les restrictions et a dont accès à toute la configuration.
-## cn=admin,dc=picasoft,dc=net
+* 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.
-Le DN `cn=admin,dc=picasoft,dc=net` peut lire et modifier n'importe quelle entrée du serveur LDAP (mais pas la configuration).
+À 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 |}}
-## cn=nss,dc=picasoft,dc=net
+### config
-Le DN `cn=nss,dc=picasoft,dc=net` peut lire
+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.