AGDLP – Bien gérer les permissions de son serveur de fichiers
I. Présentation
Dans ce chapitre, nous allons apprendre à mettre en pratique la méthode AGDLP pour gérer les droits sur un serveur de fichiers Windows Server, puisqu'il s'agit d'une méthode recommandée par Microsoft.
Si vous êtes prêt à répondre à la question "Comment bien gérer les droits sur un serveur de fichiers ?", en environnement Active Directory, alors vous pouvez continuer la lecture.
II. La méthode AGDLP, en théorie
L'acronyme "AGDLP" signifie "Account Global Domain Local Permissions". Mais concrètement, ça fonctionne comment ?
En résumé, cette méthode consiste à jouer avec l'imbrication des groupes de sécurité et des étendues liées aux groupes de sécurité. Pour rappel, lorsque l'on crée un groupe de sécurité dans l'Active Directory, nous avons accès à trois étendues différentes : Domaine local, Globale et Universelle.
La méthode AGDLP consiste à appliquer le principe suivant :
- Un compte utilisateur doit être membre d'un groupe de sécurité global (GG_),
- Ce groupe de sécurité global doit ensuite être ajouté en tant que membre d'un groupe de sécurité domaine local (GDL_) - Ayant une portée uniquement sur le domaine d'appartenance,
- Ce groupe de sécurité domaine local est utilisé pour ajuster les permissions NTFS sur le répertoire partagé
Ce principe de gestion des droits d'accès est avantageux, car il va permettre de bien structurer les droits d'accès et d'en faciliter la gestion sur la durée. À l'usage, ce sera un gain de temps pour les administrateurs et ce n'est pas un luxe, car certains serveurs de fichiers sont un véritable calvaire à gérer lorsqu'il y a une mauvaise gestion des permissions.
Vous vous demandez sûrement pourquoi on utilise deux types de groupes différents, avec des étendues différentes : c'est pour des raisons de sécurité. En cas de compromission ou d'infection d'un serveur, nous limitons ainsi les risques de propagation, car nous attribuons des droits uniquement aux groupes de sécurité avec l'étendue "Domaine local", dont la portée se limite au domaine local. De ce fait, la méthode AGDLP est encore plus pertinente sur les environnements avec plusieurs domaines.
Avant de continuer, je vous recommande de lire ce chapitre :
Note : dans un environnement multi-domaines, nous pouvons appliquer la méthode AGUDLP qui reprend le même principe qu'AGDLP à la différence que nous ajoutons un groupe de sécurité supplémentaire, avec l'étendue "Universelle", entre les groupes globaux et de domaine local.
III. AGDLP dans la pratique
Pour bien comprendre le principe de la méthode AGDLP, prenons un exemple concret dans la continuité de mon précédent article sur les permissions NTFS et de partage. Imaginons, un partage nommé "Partage" hébergé sur un serveur de fichiers et sur lequel nous avons besoin de définir les droits. Sur ce répertoire, nous avons besoin d'attribuer des autorisations en lecture/écriture pour certains utilisateurs, notamment "Guy Mauve", ainsi que des permissions en lecture seule pour "Lou Ange". Créez les utilisateurs si besoin, afin de reproduire cet exemple.
Si nous traduisons ce besoin en groupes de sécurité en respectant la méthode AGDLP, nous obtenons la représentation suivante :
Autrement dit, je ne veux pas voir de permissions associées directement à un objet utilisateur sur le dossier "Partage", et il est important de respecter l'imbrication des groupes.
Ce qui implique de créer 4 groupes dans l'annuaire Active Directory :
Ainsi, les membres du groupe "GG_Comptables" auront des autorisations en lecture/écriture sur "Partage". De cette façon, tous les comptables de l'entreprise seront membres de ce groupe et auront un niveau de permissions identiques. Cette autorisation sera attribuée grâce à l'appartenance au groupe "GDL_Partage_RW".
C'est important d'adopter une convention de nommage pour vos groupes. Par exemple :
- GG_ pour tous les groupes de sécurité avec l'étendue "Globale"
- GDL_ ou GL_ pour tous les groupes de sécurité avec l'étendue "Domaine local"
- _RW pour tous les groupes permettant de bénéficier de droits en lecture et écriture
- _RO pour tous les groupes permettant de bénéficier d'un accès en lecture seule
Ainsi, rien qu'en regardant la liste des groupes dans l'Active Directory, vous pouvez savoir à quoi correspond ce groupe. Si besoin, vous pouvez préciser le chemin UNC vers le partage dans la description du groupe de domaine local pour être encore plus précis.
Prenons l'exemple du groupe "GDL_Partage_RO" qui est bien configuré avec l'étendue "Domaine local".
Parmi les membres de ce groupe, il n'y a pas d'utilisateurs ! C'est bien le groupe "GG_Externes" qui est membre de ce groupe, et dans le groupe "GG_Externes", il y a l'utilisateur "Lou Ange".
Ensuite, une fois que les groupes sont prêts, il ne reste plus qu'à configurer les permissions de partage et les permissions NTFS. Pour cela, nous utilisons bien les groupes "GDL_", comme ceci :
Puis, dans le même esprit avec les autorisations NTFS en restant cohérent entre le nom du groupe et les droits (_RO = Lecture seule).
Il ne restera plus qu'à tester sur un poste client, avec le compte "Guy Mauve" puis avec le compte "Lou Ange" pour vérifier que les permissions s'appliquent correctement !
Bien sûr, les groupes globaux peuvent être ajoutés à d'autres groupes avec l'étendue de domaine local. Par exemple, le groupe "GG_Comptables" peut être membre du groupe "GDL_Compta_RW" pour accéder au partage "Comptabilité".
IV. Conclusion
En appliquant cette méthode, les droits sur les répertoires partagés sont plus faciles à gérer et à maintenir dans le temps ! Au-delà d'appliquer la méthode AGDLP, la clé, c'est de bien nommer les groupes de sécurité pour que ce soit facile à interpréter d'un coup d'œil ! Sans oublier que l'arborescence de votre serveur de fichiers doit être bien pensée également sinon elle peut devenir problématique. Je vous encourage à appliquer cette bonne pratique en entreprise pour gérer les droits sur votre serveur de fichiers !
Au sein d'un environnement avec plusieurs domaines et des relations d'approbations, il y a un véritable intérêt à utiliser la méthode AGDLP d'un point de vue de la sécurité. C'est moins vrai sur un environnement mono-domaine puisque la notion d'étendue importe peu, mais il vaut mieux appliquer cette méthode dès le départ. Aujourd'hui, votre Active Directory n'a peut-être pas de relation d'approbation avec un autre domaine, mais qu'en sera-t-il demain ?
Cela simplifie la gestion mais quand on a de multiples groupe cela reste complexe.
Il faut s’outiller soit script ou produit commerciaux pour réaliser dès audit de revue de permission.
Et quid de cette demande classique de l’accès au sous dossier pour une autre population.
Le parcours sans autorisation est intégré à comprendre.
Tout comme le fait de n’a pas donner le droit de modifier les permission ntfs a un groupe sur un dossier.
Pas si simple ces files server tout compte fait. Ça paraît pourtant basique au départ mais ça devient vite un sac de noeud.
Bonjour
Articles intéressants, mais, comme l’indiquait Boisrobe, quelle est la bonne pratique pour donner des privilèges (ou droits) à un groupe sur un sous-répertoire alors que ce groupe n’en a pas sur la racine.
De plus, quelle différence entre les privilèges « Modification » & « Écriture » ?
D’avance, merci pour vos réponses.
Cordialement.
Avec Modification tu peux supprimer.
tu fais un groupe de plus sur les quels tu as les droits de lister les sous_rep et sur les sous_rep tu appliques AGDLP
et surtout tu ne casse jamais l’héritage
A chaque fois que j’ai mis en place des serveurs de fichiers, j’ai traité tous les cas généraux comme ceux donnés en exemple (compta, archives, RH, etc.) en appliquant strictement AGDLP. Et ça marche bien, c’est clair mais assez souple (cas des utilisateurs faisant partie de plusieurs services). Après seulement j’ai traité les cas particuliers. Par exemple un dossier partagé pour un projet (donc temporaire et avec des accès inter service) ou un espace partagé pour une mission entre plusieurs services (pas temporaires mais au cas par cas niveau droits, toujours avec un périmètre pas évident) j’ai appliqué AGP. C’est pareil sauf qu’on mets directement des utilisateurs dans un groupe local correspondant au dossier partagé (sans passer par le groupe global) et ça permet de faire facilement des exceptions.
Pour les dossiers racines avec des droits différents, il y a souvent des contournement comme par exemple créer un dossier racine partagé avec absolument tout le monde et y créer toute une arborescence en AGDLP avec énumération basée sur les accès.
Par exemple un dossier « Paie » qui doit être partagé entre RH et Compta mais qui se trouve initialement dans un dossier Compta qui, lui ne devrait être partagé qu’avec la compta, en fait on peut soit le placer dans le dossier racine à côté de Compta, soit placer Paie dans un autre endroit correspondant aux dossiers aux droits « spéciaux » que j’évoquais tout à l’heure (en AGP). L’avantage c’est que les droits des dossiers restent toujours « propres » et lisibles et qu’on ne fait pas d’exceptions à AGP ou AGDLP…
Bonjour,
Il y a 20 ans lorsque j’ai créé mon arborescence (sous NT4 !) je suis tombé dans le piège de l’octroi des droits à Tout le Monde sur la racine du partage… Et durant ces 20 ans ça s’est considérablement complexifié.
Je suis en train de mener une réorganisation des droits d’accès des dizaines de milliers de dossiers, avec une arborescence complexe, en respectant cette préconisation AGDLP, non sans quelques arrachages de cheveux lorsqu’il s’agit de gérer des exceptions (genre un membre d’un groupe qui doit avoir des droits sur des sous-répertoires d’un autre groupe !). Bref c’est pas toujours simple.
Mais j’ai aussi un autre problème. Lorsque je m’attaque aux droits d’un répertoire sur lequel c’était géré « à l’ancienne » et que je dois passer à l’AGDLP, je crée les GDL et les GG qui vont bien, j’attribue les GDL au répertoire et je mets les comptes utilisateurs concernés dans le GG. Tout est OK, j’ai plus qu’à supprimer les anciens droits et là… patatras ! Les utilisateurs connectés se voient coupés du dossier, ils sont obligés de fermer leur session et de la réouvrir pour retrouver l’accès grâce aux nouveaux droit affectés par l’AGDLP !
Tout se passe comme si les droits étaient réoctroyés lors de l’ouverture de session…
Savez-vous s’il y a un moyen d’éviter ce problème ?
Bonjour,
Je réponds un peu tard mais la solution est relativement simple.
Ta démarche est la bonne, c’est juste que tu vas un peu trop vite.
Lorsque tu ajoutes les utilisateurs dans le GG, cette modification ne sera prise en compte qu’après leur réouverture de session. Il te suffit donc d’attendre avant de supprimer les anciens droits.
Dans mon établissement, après ajout des droits, j’attends 24h avant la suppression des anciens droits mais bien sûr, un délai plus long te permettrait de t’assurer que le user appartient bien au nouveau groupe et voit donc ses droits bien appliqués.
Bonjour,
J’utilise cette méthode depuis plusieurs années et je me heurte néanmoins à un problème lors de remplacements temporaires de personnels.
par exemple :
– User A est membre du GG Comptables et le GG est membre des DL Finances_RO et Compta_RW
– User B est membre du GG Finances et le GG est membre des DL Finances_RW
Le user B démissionne, user A assurera ses missions le temps d’un remplacement (sans lui retirer ses tâches actuelles évidemment).
Je me retrouve avec un user A membre des deux groupes GG et donc avec un « conflit » de droits sur Finances.
Le seul moyen que j’ai trouvé est de créer un groupe GG pour traiter ce cas et appliquer les bons droits ce qui est vite laborieux au vu du nombre de cas qui se présentent.
Si quelqu’un a une solution plus sexy, je suis preneur 🙂
Dans l’entreprise pour laquelle je travaille on pousse un max ce modèle de droits, mais je me demandais si c’est une bonne chose si on essaie aussi de l’appliquer à autre chose que des droits fichiers. Par contre exemple le combiner avec des droits applicatif et systèmes?