La méthode AGDLP (Account, Global, Domain Local, Permission) est une bonne pratique pour définir et gérer les accès aux ressources partagées sur les technologies Microsoft, principalement les fichiers et les imprimantes dans un domaine Active Directory. Bien que ce système ne soit ni parfait ni universel, il facilite les tâches d’administration et réduit les possibilités d’erreur.
Le principal inconvénient est qu’il n’existe pas d’outils disponibles d’origine pour forcer l’utilisation de cette méthode. On trouve beaucoup de domaines Active Directory respectant plus ou moins la méthode à un moment donné, et de lourdes dérives par la suite. Souvent la méthode est mise en place par une personne « qui s’y connaît » et qui a un esprit un peu fort (capable d’imposer cela au reste de l’équipe), et une fois que cette personne ne fait plus partie du service l’anarchie reprend sa place et les permissions deviennent petit à petit ingérables. La situation la plus classique est d’avoir tout un tas de ressources ouvertes à tous vents parce que les administrateurs systèmes n’ont pas la capacité à s’auto-astreindre à l’utilisation des bonnes méthodes qui leur font pourtant gagner beaucoup de temps et de sérénité.
Le principe est que chaque utilisateur soit relié à un ou des groupes globaux qui symbolisent les fonctions de chaque utilisateur.
Chaque groupe global est ensuite relié à un ou plusieurs groupes locaux qui symbolisent le type d’accès aux ressources.
Et enfin chaque ressource (dossier, fichier, imprimante) se voit assigner des permissions vers les groupes locaux.
Dans l’exemple ci-dessus, si une nouvelle personne s’occupe de la comptabilité, il suffit de l’ajouter au groupe global Compta. Par exemple si Gérald va désormais également gérer la comptabilité, on l’ajoute au groupe Compta. Si c’est un nouvel employé, on crée l’utilisateur correspondant et on l’ajouter au groupe Compta. Et si c’est un stagiaire qui ne doit pas avoir accès en écriture, on crée le nouvel utilisateur, on crée un nouveau groupe global (puisque c’est une nouvelle fonction : stagiaire en compta, ou collaborateur compta en lecture seule) nommé par exemple Compta assitant. Et ce nouveau groupe sera relié au groupe local Documents compta (lecture seule).
Le jour où on décide que le département des vente doit avoir accès en lecture seule à un sous dossier de la direction, il faut créer un groupe local nommé Direction-vente (lecture seule) auquel la permission en lecture est accordée depuis le dossier voulu. Et on relie le groupe global Vente à ce nouveau groupe local.
Si une semaine plus tard on décide que finalement cet accès doit être en lecture/écriture, il suffit de modifier la permission sur le dossier et de renommer le groupe local en Direction-vente tout court (il n’est pas obligatoire de renommer, mais il est plus sein d’avoir des noms qui correspondent à l’utilisation réelle).
L’utilisation de ce système nécessite parfois de réagencer qui fait partie de quel groupe, ainsi que les liaisons entre groupes. Ce petit inconvénient n’est que le reflet des changements qui ont lieu au sein de l’organisation, donc non évitable quelle que soit la méthode. Dans tous les cas il est impératif que les administrateurs système s’astreignent à correctement définir les groupes, à correctement définir les permissions, et mettre les utilisateurs dans les bonnes cases. Sans cette ligne de conduite il devient vite quasi-impossible de gérer convenablement les accès aux ressources, même avec un nombre réduit d’utilisateurs.
Une variante est la méthode AGUDLP qui intercale des groupes universels entre les groupes globaux et locaux. C’est plutôt utilisé sur des forêts multi-domaines, donc dans de grandes organisations ou des organisations multi-sites. Dans beaucoup de cas les groupes universels ne sont qu’une redite des groupes globaux et il est tentant de ne pas les créer dans certains cas, ce qui amène généralement une sur-complexification.