technique:adminsys:ldap:acl

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
technique:adminsys:ldap:acl [2021/11/22 22:29] – ↷ Page déplacée de technique:internal_serv:ldap:acl à technique:adminsys:ldap:acl qduchemitechnique: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>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.