IGDLA, où comment gérer l'imbrication de groupes sous Windows

Et hop, mon premier article...

Je devais expliquer à mes élèves comment gérer des groupes, les étendues, et comment donner des permissions à des utilisateurs sur des ressources.

Il existe pléthore de sites traitant de ce sujet, mais hélas je n'ai trouvé aucun article qui était à la fois simple, explicite, compréhensible facilement, et "à jour".

Voilà pourquoi je dégaine ma cyberplume.

Comment gérer les accès à des ressources dans un système d'exploitation?

Il y a plusieurs manières de faire, celles pratiquées par la plupart des entreprises, et la bonne!

Ici je ne vais pas expliquer comment fonctionne un groupe, ni quelles étendues utiliser, juste comment bien les nommer et gérer ceux-ci.

Je vous renvoie à un article (en anglais) beaucoup plus exhaustif si vous voulez tout connaitre des groupes:

http://blogs.msmvps.com/acefekay/2012/01/06/using-group-nesting-strategy-ad-best-practices-for-group-strategy/

Ce que je vois (trop) souvent, ce sont des droits donnés à des utilisateurs directement...C'est franchement une solution d'amateur, car c'est impossible à gérer! En plus bonjour la compétence de la personne qui a mis ça en place...

Ce que je vois également, ce sont des groupes domaine local...mais qui n'ont ni un nom explicite, ni de différenciation entre la lecture et l'écriture. Il existe toujours dans ce cas là des utilisateurs avec des droits nominatifs sur une ressource, car ils sont "seuls" à occuper une fonction dans l'entreprise par exemple...

Évidemment il est nécessaire de créer un groupe même si l'utilisateur est unique...il est probable qu'il parte en congés, qu'un collaborateur rejoigne l'entreprise, etc.

Dans ce cas l'ajout d'une personne au groupe existant est beaucoup plus simple.

Les Best Practices:

Heureusement il existe des best practices, qui rendent la vie l'administration de votre système beaucoup plus facile.

Premier point, le nommage des groupes de sécurité:

Il est nécessaire d'avoir des noms qui permettent en un clin d’œil de savoir les éléments suivants:

• Quelle est la portée du groupe.
• A qui s'adresse le groupe.
• A quoi il va donner accès.
• Quels droits effectifs il va donner sur cette ressource.

 Exemple:

DL_Comptables_Exercices comptables_RW

Je sais donc identifier que ce groupe est un groupe domaine Local, qui est composé des comptables, qui va donner des droits en Lecture Écriture (ReadWrite) sur mon dossier Exercices comptables.

IGDLA? I Go Direction Los Angeles?

Maintenant que nous avons des noms de groupes explicites et qui répondent à une règle de nommage, voici la logique d'imbrication des groupes à respecter, j'ai nommé IGDLA! (ou IGUDLA dans une organisation multidomaines).

Identité
Global (étendue du groupe)
Domaine Local (étendue du groupe)

Accès

 

Graphique issu du cours officiel Microsoft 22-410 , modifié par mes soins.

Pour reprendre le graphique, une identité (user par exemple) est membre d'un groupe global "ventes", qui est lui même membre d'un groupe "ACL_Sales_Read", qui a un accès en lecture sur un dossier du système de fichier.

En combinant cette règle avec la règle de nommage précédente, nous aurions un utilisateur, disons Pierre, membre du groupe global "G_Commerciaux" (dans ce cas pas de précision de la cible de l'ACL car il n'y en aura aucune sur ce groupe, c'est le groupe domaine local qui la possèdera), qui est lui même membre du groupe "DL_Commerciaux_Sales_R".

Dans le cas d'une forêt multidomaine, nous intercalerions un groupe Universel entre le groupe global et le groupe domaine local.

Attention toutefois, à utiliser avec parcimonie, un groupe universel est dupliqué dans le catalogue global et est répliqué dans tous les domaines, ce qui peut entrainer des volumes importants sur le long terme. 

Prenons l'exemple d'une holding qui possède plusieurs sociétés (donc plusieurs domaines), avec des comptables dans les deux sociétés.

Les comptables ont besoin d'accéder à un dossier commun une fois le bilan finalisé.

Nous aurions donc un groupe "U_Comptables" qui contiendrait des groupes globaux "G_Comptables" de chaque domaine, et qui serait contenu dans un groupe "DL_comptables_bilans annuels_RW".

Ainsi, les comptables de tous les domaines auraient un accès effectif au dossier "bilans annuels", sans trop surcharger le catalogue global, le tout de manière transparente pour l'administrateur système, qui saurait en un clin d’œil qui a des droits effectifs sur cette ressource.

Pour résumer donc:

• Pas d'accès à des ressources par des utilisateurs, uniquement à des groupes de sécurité.
• Un nom explicite pour les groupes de sécurité, qui permette de quasiment tout savoir en un instant, même si nous ne sommes pas la personne qui a mis en place la sécurité.
• Une imbrication des groupes pour faciliter la gestion.
• Une utilisation des groupes universels qu'en cas de nécessité.
• Une utilisation des groupes globaux pour regrouper les fonctions ou lieux géographiques par exemple.
• Une utilisation des groupes Domaine Locaux pour assigner des droits d'accès effectifs sur des ressources. 

J'espère que ces conseils vous seront utiles, et j'en profite pour remercier Nicolas, qui m'a fait gagner des heures lors de la reprise d'une arborescence, grâce à des groupes bien nommés et identifiés! :)

A Bientôt!