Vers une meilleure gestion des groupes locaux

Cette gestion est en effet primordiale afin de garantir une bonne sécurité des accès et des données d’un poste de travail ou d’un serveur.

Les besoins généralement exprimés au sein d’une direction informatique sont souvent les mêmes. Adresser une configuration standardisée  de l’ensemble de son parc informatique et être capable de gérer les cas particuliers sans trop d’effort tout en gardant une bonne visibilité de la configuration en place.

La gestion du groupe Administrateur local est un besoin souvent exprimé car il s’agit de maîtriser une configuration locale à chaque ordinateur. L’article d’aujourd’hui portera donc sur cet exemple en particulier.

Il existe plusieurs façons de gérer les membres d’un groupe local Windows.
•    Le scripting via la commande net group par exemple.
•    Les stratégies de groupe de préférences (ou GPP).
•    Les groupes restreints via une stratégie de groupe

Le scripting est une solution acceptable mais demande un effort de mise en œuvre et de suivi plus important. Il n’est généralement pas utilisé dans les entreprises à cause de cela.

Les stratégies de groupes de préférences sont très efficaces pour figer les membres d’un groupe local mais ce paramétrage manque malheureusement de flexibilité. Il ne sera en effet pas possible d’ajouter un utilisateur spécifique sur un poste spécifique. Il sera cependant idéal si vous souhaitez ajouter un compte (local ou de domaine) dans un groupe local présent sur chacun de vos ordinateurs.

Les groupes restreints répondent quant à eux à ces différents besoins et permettent de forcer les membres d’un groupe tout en laissant suffisamment de flexibilité. Un groupe restreint est donc un paramètre de stratégie qui s’applique à un ordinateur et fige les utilisateurs ou groupes définis au niveau de « Membres » et/ou « Membre De » de ce groupe restreint. Ce paramètre est rafraichi à chaque redémarrage de l’ordinateur ou toutes les 90 minutes environ. Un utilisateur s’étant ajouté sans autorisation dans le groupe Administrateurs verra alors son compte automatiquement retiré du groupe lors de la ré-application de la GPO.

Les groupes restreints se configurent au niveau de la stratégie Configuration Ordinateur – Stratégies – Paramètres Windows – Paramètres de sécurité – Groupes restreints.

Avant de se lancer dans la configuration d’un groupe restreint, il convient de bien comprendre la différence entre le paramètre « Membres de ce groupe » et Ce groupe est membre de ».

Prenons l’exemple du groupe local Administrateurs de chaque ordinateur (spécifié comme BUILTIN\Administrateurs dans Windows). Vous pouvez définir celui-ci en tant que Groupe Restreint depuis la stratégie de groupe et lui indiquer un groupe de domaine (par ex. MaSociete\AdminLocal) au niveau de Membres de ce groupe. Ainsi, tous les utilisateurs du groupe MaSociete\AdminLocal seront membre du groupe BUILTIN\Administrateurs des ordinateurs se trouvant dans le conteneur lié à la stratégie de groupe définie.

Parfait ! Me direz-vous ? Et bien pas tant que cela…

Imaginez que ce groupe restreint soit défini au niveau des ordinateurs de votre Active Directory et qu’un utilisateur ait besoin d’être membre du groupe Administrateurs de son ordinateur (il n’est pas rare que les utilisateurs d’ordinateurs portables aient ce genre de besoin). En le rajoutant au groupe MaSociete\AdminLocal, l’utilisateur sera en effet membre du groupe BUILTIN\Administrateurs de son ordinateur mais également administrateur de tous les autres ordinateurs puisqu’il fera parti du groupe BUILTIN\Administrateurs de chacun d’eux !

De même, si vous tentez de rajouter ce même utilisateur localement au groupe BUILTIN\Administrateurs de son ordinateur de bureau, l’application de la stratégie de groupe aura pour effet de nettoyer les membres des groupes locaux. Logique puisque la GPO indique que seul le groupe Masociete\AdminLocal peut en faire parti… et par conséquent l’utilisateur se verra retirer les droits administrateurs.

Vous l’aurez compris, ce type de configuration n’est que peu adaptée à la définition des membres des groupes au niveau des postes de travail car la population des utilisateurs est très diversifiée. Cette configuration peut cependant être très intéressante pour contrôler les membres des groupes des serveurs et contrôleurs de domaine afin de figer et ainsi contrôler au mieux leurs groupes locaux.

Pour en revenir à notre utilisateur souhaitant être administrateur de son ordinateur en utilisant les groupes restreints et sans que cela n’impacte la sécurité des autres ordinateurs, il convient de définir les groupes restreints de façon un peu différente.

Il faut en effet définir un groupe restreint à partir du groupe de domaine choisi (dans notre exemple le groupe MaSociete\AdminLocal) et définir le paramètre Ce groupe est membre de : afin d’y rajouter le groupe BUILTIN\Administrateurs (ou BUILTIN\Administrators selon que cette stratégie de groupe soit définie depuis un ordinateur français ou anglais).

Ainsi, le groupe MaSociete\AdminLocal a son attribut IsMemberOf  figé et les utilisateurs faisant partie de ce groupe sont effectivement membres du groupe Administrateurs de tous les ordinateurs. Par contre, à la différence de la situation précédente,  cette configuration n’empêchera pas un utilisateur lambda d’être administrateur de son ordinateur.

En production, vous devrez idéalement utiliser les deux configurations.

Le plus simple étant de créer une unité d’organisation (OU) par population (groupe Admin figé ou pas) et d’appliquer la GPO qui convient pour chacune d’elle.
La gestion via OU a pour avantage de simplifier ce suivi.

Pour aller plus loin ….

« Sur le terrain », il n’est pas rare de trouver des utilisateurs cherchant à contourner les règles en place.

Le contournement le plus commun est la réinitialisation du mot de passe du compte Administrateur local.  Action possible la plupart du temps en amorçant l’ordinateur via une clé USB dédiée à cet effet (d’où l’intérêt de bien configurer et protéger son BIOS contre la modification).

Une fois le mot de passe modifié, l’utilisateur redémarre Windows et ajoute son compte utilisateur de domaine dans le groupe Administrateur local de son poste en utilisant le compte administrateur local, puis il ouvre immédiatement après une session. Même si une stratégie de groupe restreint est en place sur le domaine, elle n’aura pas le temps de s’appliquer et l’utilisateur sera administrateur de l’ordinateur.

Au bout de 90 minutes… la GPO se réapplique, le compte de l’utilisateur est supprimé du groupe Administrateur local et les admins sont soulagés, sauf qu’en réalité …. l’utilisateur sera toujours Administrateur tant qu’il n’aura pas fermé sa session ! En effet, les droits admin sont fournis dans le token délivré lors de l’ouverture de session de l’utilisateur (l’outil tokensz dispo sur le site de Microsoft sera là pour vous en convaincre). Les droits de l’utilisateur sont définis à ce moment.

Pour contrer « ces petits malins » (aaah les joies de s’occuper de la Sécurité en entreprise), j’avais mis en place un script exécuté régulièrement sous le contexte de l’utilisateur logué. Le script tentait, sur chaque ordinateur, de créer un fichier texte dans un dossier normalement inscriptible que par les membres du groupe Administrateur. Si la création fonctionnait, cela signifiait que l’utilisateur était logué avec des privilèges Administrateur sur son ordinateur. Et cela était identifiable même si son compte ne faisait pas parti du groupe Admin au moment de l’audit. Le nom de l’utilisateur et de l’ordinateur étaient centralisés dans un fichier de logs audité une fois par jour  🙂

En résumé, les groupes restreints répondent en grande partie au besoin de gestion des groupes locaux des ordinateurs membres de l’Active Directory.

La sécurité de son système d’information interne passant par la maîttrise de son parc informatique, cette solution, bien que pouvant présenter quelques lacunes, s’avèrera être extrêmement utile pour la gestion et le suivi de vos ordinateur sur le domaine.