Uubu.org

Systèmes d'information: une approche OpenSource

OpenLDAP - Design d'annuaire

Mise en œuvre d'un annuaire LDAP

Le 09 septembre 2014 , Aucun commentaire pour cet article


Le design proposé ici servira de base pour les prochains articles. Une base de données LDAP a la particularité d'être organisée en une structure d'objets hiérarchiques. Ce modèle permet d'organiser ses données de manière à correspondre au plus proche de l'organisation. Il y a cependant un certains nombre de points important à respecter:


- Déport des délégations: Les délégations doivent être placées dans une branche extérieure à l'organisation, de manière à éviter q'un utilisateur puisse s'octroyer des privilèges.
- Délégation hors scope: Toute personne ayant des délégations sur une partie de l'organisation ne doit pas être en mesure de d'octroyer des droits en dehors du scope qui lui a été attribué.
- Mécanismes d'approbation: Si une délégation est sensible, ce qui est le cas au niveau de la gestion du haut du DSE, des mécanismes d'approbation ou techniques similaires doivent pouvoir être mis en œuvre.
- Hiérarchisation des rôles: les rôles doivent être hiérarchisés et séparés (par exemple les rôles techniques, et fonctionnels).
- Design basé sur les délégations et les stratégies: La structure du DIT doit avant tout correspondre à la gestion de la base (délégations) et non se focaliser exclusivement sur l'organisation fonctionnelle de l'entreprise.
- Scope limité: Les équipes en charge de la gestion des annuaires ne devraient pas être en mesure de gérer plus de 4 niveaux hiérarchiques. Cela permet d'une part de limiter les comptes à fort privilèges, de séparer les pouvoirs, et de simplifier la gestion.
- Sécurité: La sécurité d'un annuaire est cruciale, surtout si les accréditifs des utilisateurs s'y trouvent. l'authentification des comptes à privilèges doit être forte, et idéalement via des comptes dédiés.

 

Nous allons repartir sur l'exemple de l'article précédent, une fabrique de jouets. elle possède 3 sites de production et 1 site où se situe le siège. Nous appellerons cette entreprise jouets-fr. Rajoutons un peu de contenus, cette entreprise a racheté une autre entreprise de vente de jouets qui s'appelle openjouets, il n'y a pour le moment qu'un seul magasin, mais cela pourrait évoluer dans le future.

 

Le DN root, tout comme le desing du DIT, est libre. Cependant, il est intéressant d'harmoniser les contextes de nommage, et l'utilisation du composant de domaine (dc) est une bonne idée pour traduire le contexte DNS en LDAP. Prenons notre annuaire dont le DN root sera dc=uubu,dc=fr:

 

dc=uubu,dc=fr
\_ cn=Delegations
\_ o=Enterprises
   \_o=jouets-fr
     \_l=Grenoble
     \_l=Paris
     \_l=Toulouse
     \_l=Londre
   \_o=openjouets
     \_l=Paris

 

On commence simplement par déporter les délégations. Ensuite, un nœud Enterprises contient les entreprises. Chaque entreprise possède un nœud organisation portant son nom. Sous chaque entreprise, nous créons un nœud par site et sous chacun d'eux, nous créons des nœuds correspondant aux divers types d'objets de l'entreprise:

l=<site>
\_ou=Peoples
\_ou=groups
\_ou=Computers
\_ou=Printers
\_ou=Servers

Nous resterons sur ce modèle basique pour le moment. Il ne dépasse pas 4 nœuds par entreprise, et va nous permettre de définir un niveau de délégation assez simple.

 

Décortiquons un peu plus le nœud Délégations. Celui-ci va contenir les rôles de gestion de notre annuaire:

cn=Délégations
\_Administration
  \_Admin-Approvers
  \_Admin-Managers
  \_Admin-Groups
    \_ADM-<app1>
\_Applications
  \_<app1>
    \_<roleX>

La branche Administration concerne tous les groupes à fort privilèges, chapotés par les 2 groupes "top-level": Admin-Approvers et Admin-Managers. Ils permettent de se gérer mutuellement afin que personne ne soit en situation de pleins privilèges et/ou la possibilité de s'octroyer ou d'octroyer à une autre personne les pleins pouvoirs.

Sous Admin-groups, nous retrouverons tous les responsables applicatifs (c.a.d: les personnes habilitées à gérer les droits des autres personnes. Sous Applications, nous allons trouver tous les rôles de chaque application communes à toutes les entreprises, principalement le serveur LDAP lui-même. Les applications de base seront discutées dans l'article consacré aux contrôle d'accès.

Vie et évolution de l'annuaire

Un design d'annuaire doit prendre en compte l'exploitation au quotidien, et l'évolution dans le temps. La complexité de l'organisation de l'annuaire peut dépendre également de la solution utilisée pour gérer cet annuaire. Si l'annuaire est géré à l'ancienne, par exemple via phpldapadmin, la simplicité sera de mise. Par contre, si l'annuaire est gérée par une solution de gestion des identités, le design peut être plus élaboré, puisque l'annuaire devient donc une base applicative.

Prenons le cas d'une entreprise qui embauche fortement. À l'origine, les comptes utilisateurs étaient tous sous le nœud ou=Peoples. Avec le temps, on souhaite séparer la production de l'administration, gérées par 2 équipes différentes, ou par besoin de définir des stratégies différentes. Nous avons 2 cas possibles:

- On renomme ou=Peoples en ou=Production, et on créé sous le même parent ou=Administration.
- Sous ou=Peoples, on créé ou=Production et ou=Administration.

Dans le premier cas, celà nous implique de modifier fortement les acl, mais nous conservons le même niveau dans la hiérarchie. Dans l'autre cas, la modification des acl ne s'opèrent qu'au niveau du nœud ou=Peoples, et l'ajout ultérieurs d'autres nœuds ne necéssitera pas de définir de nouvelles acl ou d'en modifier d'autres. En revanche, nous ajoutons un niveau hiérarchique.

Autre cas, une entreprise en rachète une autre, et nous devons l'intégrer dans l'infrascture existante. Ici, le fait d'avoir un nœud Enterprise, nous permet de rajouter d'autres entreprises, ou possiblement d'autre sites sous un entreprise. Il suffira de se conformer et de calquer le modèle d'acl en place et de l'adapter à la nouvelle branche.

Dernier point important: il existe 3 façons de gérer l'appartenance d'un objet: Sa place dans la hiérarchie (est unique), le "membership" (n'est pas unique), et le DN (unique ou non en fonction du design). Cet aspect est à prendre en compte avant de se lancer dans un design d'arborescence afin d'éviter de se couper l'herbe sous les pieds!

Aucun commentaire pour cet article

Note: Les commentaires sont temporaiment désactivés, merci de contacter l'auteur par mail