Table des matières

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 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 ainsi que la documentation sur la configuration générale.

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

Les entrées correspondante se voient dans la configuration :

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 :

À titre d’exemple, voici ce qu’a le droit de voir un utilisateur quelconque voire non-authentifié.

config

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

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 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 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) :

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 :

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

snippet.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 :

snippet.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 :

snippet.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.