6 votes

Stratégie AD pour les utilisateurs de plusieurs départements

Je travaille pour un collège qui compte près de mille utilisateurs (professeurs et personnel). De nombreux membres du personnel enseignent également à temps partiel, et de nombreux membres du corps enseignant enseignent dans différents départements.

Sachant qu'un utilisateur et/ou un ordinateur ne peut exister que dans une seule OU, quel type de stratégie permettrait d'avoir une belle structure hiérarchique, tout en étant suffisamment flexible pour permettre à des stratégies de groupe de différents départements de s'appliquer au même utilisateur.

Ce scénario ne doit pas être trop rare, mais je ne vois pas encore la disposition la plus simple ou la plus propre.

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.)

10voto

Evan Anderson Points 140581

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.

0 votes

Je ne sais pas comment tu as pu trouver la réponse si vite, bon sang ! Un +1 bien mérité. En tant que district K12, nous travaillons toujours à nettoyer, réorganiser et rationaliser notre configuration héritée.

2 votes

@jscott : Il a été établi depuis longtemps que je ne suis pas vraiment humain. Mon environnement AD préféré dans ma base de clients est mon district K12. J'aime vraiment la variété des scénarios et la possibilité d'exercer une grande partie des fonctionnalités du produit. Malheureusement, comme il s'agit d'un environnement AD de près de 9 ans, il a accumulé une certaine quantité de "trucs" que je ne cesse de répéter "je vais y arriver" en ce qui concerne le nettoyage de certaines choses. Vous pouvez vraiment vous faire une idée de mon évolution personnelle en ce qui concerne l'utilisation de certaines fonctionnalités d'AD simplement en regardant leur répertoire trié par date de création des objets.

0 votes

@EvanAnderson Merci pour la profondeur des informations et la réflexion que vous avez mises dans ce post. Cela va nous aider énormément.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X