Les ACL dans OpenLDAP

Principes généraux

Les ACL dans OpenLDAP peuvent se trouver à 2 niveaux, database ou backEnd, sachant qu'il est assez courant d'avoir un backend par database (ou vice-versa).

Les ACL sont donc généralement positionnées dans la configuration de la database.

Syntaxe

La syntaxe globale est :

olcAccess: to [ressource]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]

Un exemple de base, qui limite l'accès à l'attribut userPassword :

olcAccess: to attrs=userPassword 
 by self write 
 by group.exact="cn=ADMIN,ou=groups,dc=example,dc=com" write 
 by anonymous auth 
 by * none

Dans l'exemple, on autorise l'utilisateur à écrire (modifier) son propre mot de passe, ainsi qu'au groupe ADMIN.
Pour les utilisateurs anonymes, seule l'authentification est possible.
Pour les autres, l'accès est refusé.

On peut également gérer les accès sur un objet de l'arborescence :

olcAccess: to dn.subtree="ou=applications,dc=example,dc=com" 
 by group.exact="cn=APPADMIN,ou=groups,dc=example,dc=com" write 
 by users read
 by * none

Ici, on donne accès en écriture au groupe APPADMIN sur toute l'arborescence de la branche "ou=applications" (via le dn.subtree).
Les utilisateurs authentifiés peuvent lire l'arborescence. Les accès non authentifiés ne sont pas autorisés. Il faut noter que par défaut, la règle "by * none" est ajoutée, interdisant les accès anonymes.

 

Par défaut, s'il n'y a pas de correspondance (directive d'accès ou [who]), l'accès est refusé.

Ressource protégées

Une ACL peut protéger / cibler une ressource, en se basant sur le DN, un filtre LDAP, un attribut ou une combinaison. Les types de ressources protégées sont :

  • * : toutes les entrées
  • dn:[scope] : un objet ou un périmètre (exact, subtree, children)
  • filter: filtre LDAP
  • attrs: attribut(s)

Pour les DN, on peut cibler un élément particulier (dn.exact, dn.base, dn.one, dn.children, dn.subtree) :

  • dn.exact ou dn.base : accès restreint au DN de l'objet ciblé lui-même
  • dn.one : accès restreint aux entrées présentes exactement sous le DN (mais pas l'objet lui-même, ni les niveaux inférieurs)
  • dn.subtree : accès à toute l'arborescence sous le DN, y compris le DN
  • dn.children : accès à toute l'arborescence sous le DN, excepté le DN

Pour les attributs, on peut avoir un seul ou plusieurs attributs, dans ce cas ils sont séparés par des virgules. Par exemple :

access to attrs=homePhone,fax,mobile,telephoneNumber,mail
  by users read
  by * none

Si on veut permettre la recherche et la lecture de certains attributs, il faut ajouter entry dans la liste des attributs. Par exemple :

olcAccess: to dn.subtree="ou=people,dc=example,dc=com" 
  attrs=entry,cn,uid,userstatus,employeenumber,ou 
  by dn.exact="cn=AppRead,ou=access,dc=example,dc=com" read 
  by * none

Dans le cas des attributs, il est également possible de restreindre l'accès à une valeur.

Une règle rarement mise en oeuvre utilise un filtre LDAP. On peut par exemple restreindre des accès en fonction d'un filtre sur un attribut. Prenons l'exemple d'entrées avec un attribut portant le code Pays :

access to filter="(co=fr)"
  by group.exact="cn=ADMIN-FR,ou=groups,dc=example,dc=com" write
  by users read
  by * none

 

A qui donner accès

On trouve plusieurs sélecteurs :

  • * : tout le monde
  • anonymous : les utilisateurs non connectés
  • users : les utilisateurs conenctés (via un BIND)
  • self : porte sur l'utilisateur lui-même
  • dn.[specifier] : un DN (peut être un DN exact, subtree ou children)
  • group.[specifier] : un groupe LDAP

Type d'accès à donner

Les ACL permettent de gérer plusieurs niveaux de droits, du plus faible au plus élevé :

  • (0) none : pas d'accès
  • (d) disclose : permet de savoir si l'entrée ou l'attribut existe
  • (x) auth : requis pour l'authentification
  • (c) compare : comparaison de valeur d'attribut
  • (s) search : recherche sur un attribut
  • (r) read : lecture / affichage d'un attribut
  • (w) write : modification / écriture d'un attribut

Chaque niveau de droit implique tous les droits inférieurs.
Par exemple, le droit "read" donne également les droits search, compare, auth et disclose.

Il est possible d'utiliser le verbe (plus parlant) ou une combinaison des codes de droits. Par exemple :

access to dn.subtree=ou=people,dc=example,dc=com
  by group.exact="cn=ADMIN-FR,ou=groups,dc=example,dc=com" write
  by users=cd
  by * none

Dans l'exemple, les utilisateurs authentifiés auront les droits compare et disclose.

 

Ordre d'évaluation

Le placement des ACI dans la configuration est importante, car l'évaluation des directives de droits d'accès se fait dans l'ordre d'apparition.

Si une directive est plus spécifique d'une autre, en terme d'entrées sélectionnées, elle doit apparaître en premier dans la configuration.

De la même manière, si un sélecteur "who" est plus spécifique il doit également être positionné en premier. Par exemple, si on met :

 by users read
 by group.exact="cn=ADMIN,ou=groups,dc=example,dc=com" write 

la première règle sera toujours appliquée pour les utilisateurs, même s'ils font partie du groupe ADMIN. Du coup, seuls les accès en lecture seront autorisés.

Break et Continue

Comme vu précédemment, le mode de fonctionnement des ACL est particulier : par défaut, dès qu'une ACL correspond à l'objet et au compte, la validation s'arrête. Dans certains cas simples, ceci est satisfaisant, mais parfois il faut pouvoir traiter plusieurs cas à l'intérieur d'une même ACL, ou traiter différentes ACL.
C'est notamment le cas si on doit restreindre les droits sur des attributs, dans une même branche.

Dans ce cas, on peut utiliser des directives telles que break et continue :

  • break : permet d'outrepasser la règle en cours d'analyse, et de continuer l'analyse des autres règle
  • continue : permet de continuer au sein d'une même ACL
  • stop : arrête l'analyse des règles (c'est le comportement par défaut)

Voyons quelques exemples plus parlants.

olcAccess: to attr=employeeNumber,employeeType,departmentNumber
 by users=cd
 by dn="uid=matt,ou=Users,dc=example,dc=com" +r

olcAccess: to attr=employeeNumber
 by users +w

If I bind as uid=matt,ou=Users,dc=example,dc=com and try to modify my employeeNumber , will I be allowed to? No, I will not. The reason I will not be able to modify the record is because I will only have the permissions granted by the first by phrase: by users =cd (remember, by users =cd is the same as by users=cd stop ). As soon as SLAPD sees that I match the first by phrase of the first ACL, it will stop testing ACLs

olcAccess: to attr=employeeNumber, employeeType, departmentNumber
 by users=cd continue
 by dn="uid=matt,ou=Users,dc=example,dc=com" +r break

olcAccess: to attr=employeeNumber
 by users +w stop

Now what will happen when the user with UID matt attempts accesses an employeeNumber ? First, the by phrase of the first ACL will be evaluated, and matt will be granted =cd . Because of the continue control, SLAPD will then examine the second by clause, which will also match for the user matt . Thus, matt will have =rcd when the processing of the first ACL completes. Due to the break control the second ACL will also be evaluated, and matt will be granted +w as well, bringing his final permissions up to =wrcd .

 

Vérification des ACL

Afin de vérifier le bon fonctionnement des ACL, on peut utiliser les outils LDAP tels que ldapsearch ou ldapmodify. Dans ce cas, je préconise de modifier le niveau de logs en acl trace

dn: cn=config
changetype:modify
add: olcLogLevel  # ou replace si on a déjà positionné un olcLogLevel 
olcLogLevel: acl trace

Conversion des ACI Sun DSEE vers OpenLDAP

Il y a plusieurs différences par rapport aux ACI dans l'annuaire Sun.
Au niveau du placement, les ACI sont positionnées dans l'annuaire Sun DSEE au niveau où elles s'appliquent. Dans un export LDIF on peut donc avoir des ACI dans tout le fichier. Si dans l'ACI, il n'y a pas de (target) définie explicitement, alors l'ACI s'applique sur l'objet et son arborescence.

Sun DSEE gère également des types d'accès supplémentaires : import, export, all. Il n'y a pas par contre de droit "auth".

Dans les ACI Sun DSEE, il est possible de mettre des commentaires pour nommer l'ACI. Ceci n'est pas possible avec les ACL OpenLDAP.

Les ACI étant placées dans l'arborescence, il est recommandé de les protéger avec une ACI. Ceci n'est pas nécessaire avec OpenLDAP, puisque les ACI sont au niveau de la configuration, séparée des données.

Par défaut, l'annuaire de Sun autorise la lecture (read / compare / search) en anonyme sur toute l'arborescence.

Catégorie: 

Tag: 

Add new comment

(If you're a human, don't change the following field)
Your first name.
(If you're a human, don't change the following field)
Your first name.
(If you're a human, don't change the following field)
Your first name.

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <pre>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.