> Tech > Au-delà  de la délégation à  l’A.D. du wizard de contrôle

Au-delà  de la délégation à  l’A.D. du wizard de contrôle

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Siegfried Jagott
Comment déléguer les autorisations dans l'AD (Active Directory) de Windows 2000 ? D'après Microsoft, on peut utiliser le modèle de délégation et de sécurité de l'AD pour déléguer tous les droits dont on a besoin dans Win2K. La réponse générale de Microsoft à  la question est la suivante : « Utilisez simplement l'Active Directory Delegation of Control Wizard. Cependant, l'expérience de ma société montre que même si le wizard joue son rôle pour des procédures de base comme la création d'utilisateurs et la gestion de groupes, il est impuissant si l'on ambitionne de déléguer les autorisations d'AD de manière plus granulaire.

  Dans son article de septembre 2000, « The Active Directory Delegation of Control Wizard », Paula Sharick introduit la fonctionnalité du wizard. Cet article est amplement suffisant si vous commencez seulement à  déléguer le contrôle dans l'environnement Win2K. Mais imaginons que vous ayez l'intention de mettre en oeuvre un domaine à  l'échelle mondiale dans une très grande forêt d'AD (par exemple, une division contenant plus de 10.000 utilisateurs). Comment commencer?

  Chez Siemens Power Generation (PG), nous avons dû relever exactement ce défi. Chez nous, chaque division fonctionne comme une société autonome et a une équipe informatique dont les employés sont dispersés dans différents sites fonctionnant de manière indépendante. Nous voulions créer un domaine pour la division - au lieu de plus de 88 domaines avec plus de 400 trusts sur la planète (comme c'était le cas de la division dans son environnement Windows NT 4.0). Nous avions l'intention d'exploiter le domaine indépendamment de l'Active Directory Forest Root Service Provider (FRSP) de Siemens - le principal service informatique interne de la société qui gère toutes les configurations pour l'ensemble des forêts, comme les extensions de schéma. Mais nous avons vu d'emblée qu'il nous faudrait établir un département informatique similaire, responsable de la gestion générale des domaines, et agissant comme point de contact unique pour le domaine de nos divisions. Nous avons baptisé ce département Domain Central Service Provider (DCSP). Nous voulions aussi accorder aux administrateurs locaux de la division les autorisations leur permettant d'accomplir leur travail comme ils le faisaient sous NT 4.0

  En route, nous avons rencontré des problèmes et les avons résolus. A la fin, nous nous sommes trouvés face à  une nouvelle perspective quant au jeu d'autorisations de l'AD - une perspective bien plus profonde que celle qu'aucun article ou livre pourrait fournir. Donc, si vous décidez d'adapter les techniques de cet article à  votre implémentation d'AD, soyez extrêmement prudent. Certains des conseils fournis ici pourraient fort bien donner des résultats imprévisibles faute de tests approfondis préalables. Pour notre mise en oeuvre, nous avons utilisé la version d'AD qui accompagnait la release initiale de Win2K.

Au-delà  de la délégation à  l’A.D. du wizard de contrôle

  Quand on fait partie d’une vaste forêt, il faut le plus

souvent renoncer à  certains aspects de ses droits administratifs en faveur

d’un fournisseur de services central chargé de toute la société,
qui supervise et soutient l’infrastructure. Chez Siemens PG, nous avons

décidé de ne donner au FRSP de la société le droit d’accès à  aucune des
ressources de notre division (file shares, par exemple). Nous ne voulions
pas courir le risque de voir le FRSP modifier par inadvertance des
objets dans notre domaine. Pour nous séparer ainsi du FRSP, nous avons

simplement ôté certaines autorisations de groupe Enterprise Admins de

notre domaine.

   Dans Win2K, vous pouvez révoquer les droits Enterprise

Admins ou Domain Admins des ACL, mais ces groupes conservent les droits

Take Ownership. Autrement dit, bien que vous déniiez des droits

administratifs à  ces groupes, les administrateurs de l’entreprise peuvent

néanmoins accéder à  votre domaine et s’octroyer des autorisations sur un

objet. Vous ne pouvez pas modifier cet aspect de Win2K, mais vous pouvez

établir des politiques d’audit strictes et suivre de très près l’activité

dans votre domaine AD pour empêcher les administrateurs d’entreprise

d’apporter des modifications accidentelles ou volontaires. (Chez Siemens,

nous n’accordons aux administrateurs que les autorisations nécessaires pour

accomplir leur travail.) Pour plus d’informations sur le retrait des droits

Enterprise Admins de votre domaine, voir le white paper Lucent « Windows

2000 Active Directory Design: Restricting the Enterprise Administrators

Group » (http://www.lucent.com/livelink/161922_Whitepaper.pdf).

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro.fr - Publié le 24 juin 2010