Sans une explication des scénarios spécifiques que vous recherchez, il est difficile de vous donner un "pas à pas".
L'application de la politique de groupe des utilisateurs est influencée par :
- Le nom distinctif (DN) de l'objet utilisateur dans Active Directory et les objets GPlink dans les objets de l'unité d'organisation dans le chemin parent de l'objet utilisateur DN.
- Objets GPlink du site AD contenant l'adresse IP de l'ordinateur où l'utilisateur se connecte.
- L'attribut "Block Inheritance" des OU dans le chemin parent du DN de l'objet utilisateur ou de l'objet site AD.
- L'attribut "Enforced" / "No Override" des objets GPlink qui sont liés aux OU dans le chemin parent de l'objet utilisateur ou dans l'objet site AD.
- L'appartenance des comptes d'utilisateurs à des groupes de sécurité et l'autorisation qui leur est conférée en ce qui concerne l'application des GPO ou l'application de paramètres de politique ou de préférence spécifiques au sein de la GPO qui peuvent avoir des listes de contrôle d'accès (la politique d'installation de logiciels et les paramètres de préférence de politique de groupe ont des listes de contrôle d'accès au sein de la GPO, par exemple).
- Activation du traitement des stratégies de groupe en boucle sur les ordinateurs (en mode Fusion ou Remplacement)
Ce sont tous les mécanismes permettant de contrôler l'application de la politique de groupe des utilisateurs. Entre toutes ces fonctions, vous pouvez créer des scénarios de déploiement raisonnablement complexes.
Votre hiérarchie OU doit siempre être conçu en premier lieu sur la base de la délégation de contrôle prévue. Vous n'avez qu'une seule hiérarchie d'OU et il n'existe pas de bons mécanismes pour découpler la délégation de contrôle de la hiérarchie d'OU. Concevez d'abord la délégation de contrôle, puis l'application de la stratégie de groupe.
Je me concentre sur l'utilisation de l'appartenance à un groupe de sécurité pour filtrer l'application de la politique de groupe des utilisateurs. N'oubliez jamais que certains paramètres au sein des GPO ont des ACL distinctes de la GPO elle-même. Les fonctions "Block Inheritance" et "Enforced" / "No Override" doivent être utilisées avec parcimonie et sont généralement le signe d'une conception défectueuse. Le traitement des stratégies de groupe en boucle peut être un outil très puissant et utile, mais il est un peu complexe à comprendre.
Vous vous concentrez sur les utilisateurs mais je vais prendre un moment pour mentionner les ordinateurs aussi. L'application de stratégie de groupe pour ordinateurs possède toutes les mêmes fonctionnalités de filtrage que la stratégie de groupe pour utilisateurs, mais elle comprend également le filtrage WMI. Le filtrage WMI peut vous permettre de cibler les GPO sur des attributs spécifiques du matériel ou du système d'exploitation des ordinateurs. Je constate souvent que le filtrage des groupes de sécurité est négligé lors du filtrage de la stratégie de groupe des ordinateurs.
Il y a certaines choses que vous pouvez accomplir avec le filtrage WMI et le filtrage des groupes de sécurité pour la stratégie de groupe de l'ordinateur. Le filtrage WMI a la particularité d'être calculé dynamiquement sur chaque application de stratégie de groupe (contrairement aux appartenances aux groupes de sécurité, qui doivent être modifiées manuellement pour affecter le filtrage). Le filtrage des groupes de sécurité peut toujours être utile si vous avez des ordinateurs situés dans des OU disparates sans attribut filtrable WMI qui doivent avoir des objets de stratégie de groupe communs appliqués. J'utilise fréquemment le filtrage des groupes de sécurité avec les ordinateurs pour contrôler la politique d'installation des logiciels (j'ai une GPO à laquelle sont attribués plusieurs logiciels, chacun ayant une ACL unique qui inclut un groupe pour contrôler l'installation du logiciel).
La chose la plus importante que vous puissiez faire, en mettant de côté tout ce que j'ai dit ci-dessus, est de vous assurer que vous comprenez parfaitement comment le client de stratégie de groupe calcule l'ensemble de stratégies résultant et, avec cette connaissance, de réfléchir et de tester les conceptions possibles avant de les mettre en production. Je crois fermement que les tests doivent commencer avec un stylo et du papier (tableau blanc, etc.) plutôt qu'avec un logiciel. Vous devez avoir une connaissance suffisante de l'organisation pour être en mesure de concevoir des scénarios réalistes et de les tester. Faites participer d'autres groupes au sein de votre organisation informatique (et en dehors de l'organisation informatique si nécessaire). Votre équipe de helpdesk, par exemple, aura des besoins de délégation de contrôle qui détermineront la hiérarchie des OU physiques. Votre équipe d'assistance informatique peut avoir des besoins d'installation de logiciels qui déterminent le filtrage de la stratégie de groupe d'ordinateurs. Il existe un grand nombre de scénarios possibles qui doivent être discutés, élaborés sur papier et finalement testés en laboratoire avant d'être mis en production.
1 votes
Le filtrage WMI des GPO et des groupes de sécurité et les scripts qui vérifient ces appartenances me viennent immédiatement à l'esprit. Cependant, je suis curieux de savoir si un administrateur AD plus expérimenté a quelque chose de mieux, moi-même.
3 votes
@HopelessN00b : Plutôt que d'écrire des scripts qui vérifient l'appartenance à un groupe (ce qui peut être difficile - avez-vous déjà mis en œuvre un algorithme récursif pour vérifier les appartenances à des groupes imbriqués ?), il est souvent plus facile de diviser votre scripts en plus petites parties, chacune se rapportant à un problème de sécurité individuel, et de spécifier des ACL NTFS qui contrôlent qui peut exécuter le scripts. Ensuite, vous déchargez toute la vérification de l'appartenance à un groupe au système d'exploitation, qui s'en chargera toujours mieux que vous (gestion de domaines multiples, relations de confiance, etc.)