Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07030.jsonl.gz/865

Considérations relatives à la conception d'une délégation d'administration dans Active Directory
Considérations relatives à la conception d'une délégation d'administration dans Active Directory
Mise en œuvre de l'autonomie et de l'isolement à l'aide de forêts, de domaines et d'unités organisationnelles
Résumé
La délégation d'administration est une fonctionnalité clé du service d'annuaire Active Directory™ inclus dans Microsoft® Windows® 2000. La délégation d'administration vous permet de concevoir une infrastructure d'annuaire qui couvre plusieurs organisations et vous permet ainsi de prendre en charge vos besoins spécifiques d'indépendance structurelle et opérationnelle.
Dans Active Directory, les administrateurs peuvent déléguer la gestion de service et la gestion de données. Il est possible de déléguer la gestion de manière à mettre en œuvre une autonomie ou un isolement entre des organisations. Ce livre blanc traite des questions de conception et des implications de sécurité liées à Active Directory lors de l'utilisation de forêts, de domaines ou d'unités organisationnelles pour la délégation d'administration.
Sommaire
Introduction
La délégation d'administration est une fonctionnalité clé du service d'annuaire Active Directory™ dans Microsoft® Windows® 2000. Elle vous permet de concevoir une infrastructure d'annuaire couvrant plusieurs organisations qui ont des besoins de gestion uniques. En particulier, la délégation d'administration dans Active Directory aide les organisations à prendre en charge leurs besoins spécifiques en matière d'indépendance structurelle et opérationnelle.
Dans Active Directory, les administrateurs peuvent déléguer la gestion de service et la gestion de données. Il est possible de déléguer la gestion de manière à mettre en œuvre une autonomie ou un isolement entre les organisations. Ce document traite des questions de conception et des implications en matière de sécurité liées à Active Directory, lors de l'utilisation de forêts, de domaines ou d'unités organisationnelles pour la délégation d'administration.
Cette discussion s'appuie sur l'hypothèse que le lecteur connaît les concepts et procédures associés à la planification et au déploiement de Microsoft Active Directory. Pour plus d'informations sur la planification et le déploiement de Active Directory, consultez : le dossier Active Directory.
Concepts de délégation
Pour comprendre les procédures liées à la délégation d'administration dans Active Directory, il est nécessaire de comprendre les raisons d'une telle délégation et de connaître les différents types de responsabilités administratives susceptibles d'être déléguées.
Raisons de la délégation d'administration
En général, les organisations délèguent l'administration pour trois raisons :
- Structure organisationnelle — Plusieurs entités d'une même organisation peuvent se regrouper dans une infrastructure partagée afin de réduire leurs coûts, mais doivent pouvoir fonctionner indépendamment du reste de l'organisation.
- Besoins opérationnels — Une partie d'une organisation ou une application qui utilise Active Directory peut posséder des contraintes uniques sur la configuration, la disponibilité ou la sécurité du service d'annuaire. Des exemples sont notables dans :
- les organisations militaires ;
- les scénarios d'hébergement ;
- les scénarios d'extranet ou d'annuaire tourné vers l'extérieur
- Exigences juridiques — Certaines organisations sont soumises à des exigences juridiques qui leur imposent des conditions de fonctionnement spécifiques, telles que la limitation de l'accès à certaines informations. Ces exigences s'appliquent généralement aux organisations des types suivants :
- les institutions financières ;
- les sociétés de défense ;
- les organisations gouvernementales.
Pour ces diverses raisons, une organisation peut être amenée à déléguer son contrôle de la gestion de service, de la gestion de données ou des deux. En fonction des besoins particuliers de l'organisation, l'objet d'une telle délégation peut être de mettre en œuvre un isolement, une autonomie ou les deux. La première étape de la conception Active Directory est très importante et consiste à définir avec précision les besoins d'une organisation en s'appuyant sur les concepts de gestion de service, de gestion de données, d'autonomie et d'isolement. Ces concepts sont définis ci-dessous.
Gestion de service et gestion de données
Les responsabilités administratives déléguées dans Active Directory peuvent être divisées en deux catégories : la responsabilité de la livraison du service d'annuaire (gestion de service) et la responsabilité du contenu stocké ou protégé par le service d'annuaire (gestion de données). Ces responsabilités incombent aux administrateurs de service et aux administrateurs de données.
- Administrateurs de service — Les administrateurs de service Active Directory sont responsables de la configuration et de la livraison du service d'annuaire. Par exemple, les administrateurs de service se chargent de la maintenance des serveurs contrôleurs de domaine, contrôlent les paramètres de configuration d'annuaire et sont responsables de la disponibilité du service.
- Administrateurs de données — Les administrateurs de données Active Directory sont responsables de la gestion des données stockées dans Active Directory ou sur des ordinateurs joints à Active Directory, et n'ont aucun contrôle sur la configuration ou la livraison du service d'annuaire. Les administrateurs de données incluent :
- Les administrateurs qui contrôlent un sous-ensemble d'objets dans l'annuaire. Par l'intermédiaire d'un contrôle d'accès au niveau attribut pouvant être hérité, les administrateurs de données peuvent obtenir le contrôle de sections très spécifiques de l'annuaire, mais n'ont aucun contrôle sur la configuration du service lui-même.
- Les administrateurs qui gèrent les ordinateurs membres joints à l'annuaire et les données stockées sur ces ordinateurs.
- Dans de nombreux cas, la configuration du service d'annuaire est déterminée par les valeurs des attributs des objets stockés dans l'annuaire. En conséquence, dans Active Directory, les administrateurs de service sont également des administrateurs de données.
Autonomie et isolement
Les objectifs de la délégation dans une organisation se divisent généralement en deux catégories : l'autonomie et l'isolement.
- Autonomie — L'autonomie représente l'aptitude des administrateurs d'une organisation à gérer indépendamment :
- l'ensemble ou une partie de la gestion du service (autonomie du service) ;
- l'ensemble ou une partie des données stockées dans l'annuaire ou sur les ordinateurs membres joints à l'annuaire (autonomie des données).
- Isolement — L'isolement représente l'aptitude des administrateurs d'une organisation à empêcher d'autres administrateurs de :
- contrôler ou perturber la gestion du service (isolement du service) ;
- contrôler ou afficher un sous-ensemble de données dans l'annuaire ou sur les ordinateurs membres joints à l'annuaire (isolement des données).
L'autonomie présente moins de contraintes que l'isolement. Les administrateurs qui requièrent seulement l'autonomie acceptent que d'autres administrateurs disposant de privilèges égaux ou supérieurs dans le système disposent d'un contrôle équivalent ou prédominant. Les administrateurs qui requièrent l'isolement tentent en particulier d'empêcher d'autres administrateurs d'afficher et de contrôler leur part de la gestion du service et des données. Comme l'autonomie est soumise à moins de contraintes que l'isolement, il est généralement moins coûteux et plus efficace de déléguer l'autonomie dans Active Directory.
L'ensemble des exigences en matière de gestion de service, de gestion de données, d'autonomie et d'isolement déterminent la structure Active Directory qu'il convient d'utiliser pour déléguer le contrôle à une organisation.
Remarque Dans de nombreuses petites et moyennes entreprises, il est courant que l'ensemble de la gestion de service et de données Active Directory soit sous le contrôle d'un groupe unique d'informaticiens. Les organisations qui ne présentent aucun besoin particulier en matière d'autonomie ou d'isolement peuvent utiliser des conceptions Active Directory d'une seule forêt ou d'un seul domaine, et utiliser les procédures données dans ce document en tant que références seulement.
Délégation d'administration à l'aide de forêts, de domaines et d'unités organisationnelles
Trois structures différentes peuvent être utilisées pour déléguer l'administration dans Active Directory : les forêts, les domaines et les unités organisationnelles. La section suivante décrit brièvement les caractéristiques de chaque structure et les structures appropriées à certaines exigences de délégation spécifiques.
Pour plus d'informations sur la conception Active Directory, consultez : le dossier Active Directory.
Forêts, domaines et unités organisationnelles
Pour pouvoir comprendre la discussion suivante sur la délégation, il est utile de revoir brièvement la définition et les caractéristiques de gestion des forêts, des domaines et des unités organisationnelles Active Directory.
Une forêt est une collection de domaines, dotée d'une configuration et d'un schéma partagés, représentée par un catalogue global logique unique et connectée par une arborescence fractionnée d'approbations transitives. Une forêt est représentée par son domaine racine. Le propriétaire administratif par défaut d'une forêt est le groupe Administrateurs de domaine du domaine racine de la forêt. Le groupe Administrateurs de domaine de la racine de la forêt contrôle l'appartenance aux groupes Administrateurs d'entreprise et Administrateurs de schéma, qui par défaut contrôlent les paramètres de configuration de la forêt entière. Comme le propriétaire de la forêt contrôle les contrôleurs de domaine, le propriétaire de la forêt est un administrateur de service.
Un domaine est une partition dans une forêt Active Directory. Le propriétaire administratif par défaut d'un domaine est le groupe Administrateurs de domaine de ce domaine. Comme le propriétaire de domaine contrôle les contrôleurs de domaine, le propriétaire de domaine est un administrateur de service. Tous les propriétaires de domaines non-racine d'une forêt sont homologues, quelle que soit la position de leur domaine dans la hiérarchie de noms. Le propriétaire d'un domaine parent non-racine ne dispose d'aucun contrôle administratif par défaut sur les domaines enfants.
Une unité organisationnelle (OU) est un conteneur au sein d'un domaine. Le contrôle d'une OU et des objets d'une OU est entièrement déterminé par les listes de contrôle d'accès (listes ACL) relatives à l'OU et aux objets inclus dans l'OU. Les utilisateurs et les groupes qui ont un contrôle sur les objets stockés dans les OU sont des administrateurs de données.
Plus nombreuses sont les organisations qui composent une forêt, plus importants sont les avantages possibles en matière de collaboration et de réduction des coûts. C'est pourquoi il est recommandé de réduire au maximum le nombre de forêts dans un déploiement de Active Directory. Toutefois, certaines situations présentent des exigences de délégation qui justifient complètement le déploiement de plusieurs forêts.
Par exemple, dans le cas d'organisations où le contrôle administratif est hautement distribué, il peut s'avérer irréaliste d'envisager de regrouper toutes les organisations dans la même infrastructure. Dans ce type de situation, le coût de la gestion d'une forêt supplémentaire est compensé par le fait de satisfaire à cette exigence pratique.
Informations sur les structures d'annuaire et leurs propriétaires
Les informations suivantes sur les structures Active Directory et leurs administrateurs sont utiles lors du choix d'une structure d'annuaire pour une délégation. Pour appliquer ces informations dans une procédure de sélection de structure simple, voir "Choix d'une structure en fonction des exigences de délégation", plus loin dans ce document.
- Les propriétaires de domaine ne peuvent pas empêcher les propriétaires de forêt de contrôler leurs services, ni d'accéder à leurs données. Bien qu'il soit possible de supprimer l'accès à un domaine pour les administrateurs d'entreprise, il n'est généralement pas possible d'empêcher le propriétaire de la forêt d'accéder aux objets stockés dans des domaines non-racine. Par exemple, les membres du groupe Administrateurs de schéma (contrôlé par le groupe Administrateurs de domaine du domaine racine de la forêt) peuvent modifier le descripteur de sécurité par défaut d'une classe d'objet pour accorder au groupe Administrateurs d'entreprise le contrôle total sur les objets nouvellement créés dans cette classe. En conséquence, les organisations qui font partie d'une forêt doivent approuver le propriétaire de la forêt.
- Les propriétaires de domaine conservent toujours le droit d'accéder aux données stockées dans un domaine ou hébergées sur des ordinateurs joints à un domaine. Les administrateurs de service d'un domaine peuvent toujours afficher ou manipuler les données stockées dans un domaine ou sur des ordinateurs joints à un domaine. Ceci est une conséquence des caractéristiques de Active Directory suivantes :
- Le groupe Builtin\Administrateurs défini sur un contrôleur de domaine peut devenir propriétaire de tout objet du domaine, ce qui lui permet ensuite de le lire, le modifier ou le supprimer, quelle que soit la liste de contrôle d'accès précédemment définie sur l'objet. Cette fonctionnalité permet aux administrateurs de service de corriger des erreurs dans les listes de contrôle d'accès définies pour les objets. En conséquence, les organisations qui stockent des données dans les unités organisationnelles d'un domaine doivent approuver le propriétaire du domaine.
- Un administrateur de service malveillant peut modifier le logiciel système d'un contrôleur de domaine pour éviter les contrôles de sécurité normaux. Un administrateur de service peut utiliser cette procédure pour afficher ou manipuler tout objet dans le domaine, quelle que soit la liste ACL de l'objet. En conséquence, les organisations qui stockent des données dans les unités organisationnelles d'un domaine doivent approuver le propriétaire du domaine.
- Un administrateur de service peut utiliser la stratégie de sécurité Groupes restreints pour accorder à tout utilisateur ou groupe l'accès administratif à tout ordinateur joint au domaine. Cette fonctionnalité garantit qu'un administrateur pourra toujours obtenir le contrôle d'un ordinateur joint au domaine, quelles que soient les intentions du propriétaire de l'ordinateur. En conséquence, les organisations qui joignent des ordinateurs à un domaine doivent approuver le propriétaire du domaine.
- Si un utilisateur ou un groupe dans un domaine obtient l'accès aux données stockées sur un ordinateur joint à la forêt, le propriétaire du domaine de l'utilisateur ou du groupe peut réinitialiser le mot de passe de l'utilisateur ou manipuler l'appartenance au groupe, et par là même obtenir l'accès aux données. En conséquence, les organisations qui joignent des ordinateurs à une forêt doivent approuver chaque propriétaire de domaine de la forêt.
- Les propriétaires de domaine ne peuvent pas empêcher des propriétaires de domaine malveillants de contrôler leurs services, ni d'accéder à leurs données. En raison de la nature étroitement couplée d'une forêt Active Directory, un propriétaire de domaine malveillant peut utiliser des méthodes lui permettant d'accéder à d'autres domaines dans la forêt. Par exemple, un propriétaire de domaine malintentionné peut modifier le logiciel système sur un contrôleur de domaine. Par là même, il peut perturber le fonctionnement de tout domaine dans la forêt, afficher ou manipuler les données de configuration de la forêt, les données stockées dans chaque domaine et les données stockées sur chaque ordinateur joint à la forêt. C'est pourquoi le propriétaire d'une forêt doit approuver tous les propriétaires de domaine dans la forêt et tous les propriétaires de domaine de la forêt doivent s'approuver entre-eux.
- Les contrôleurs de domaine d'une même forêt ne peuvent pas être isolés les uns des autres. En raison de la nature distribuée de Active Directory, la violation de sécurité d'un seul contrôleur de domaine peut avoir des conséquences sur la forêt entière. Par exemple, un attaquant pouvant accéder physiquement à un contrôleur de domaine peut modifier hors connexion la base de données de l'annuaire, et ce faisant, perturber le fonctionnement de n'importe quel domaine dans la forêt. Il peut également afficher et manipuler les données stockées dans tout emplacement de la forêt, ainsi que les données stockées sur tout ordinateur joint à la forêt. En conséquence, l'accès physique aux contrôleurs de domaine doit être restreint au personnel autorisé.
Approbation des administrateurs de service
Pour résumer les conséquences des faits concernant les structures d'annuaire et leurs propriétaires, pour qu'une organisation participe à une infrastructure de type forêt ou domaine, elle doit décider d'approuver tous les administrateurs de service dans la forêt et dans tous les domaines. Dans un tel contexte, approuver les administrateurs de service implique les points suivants :
- Vous pensez objectivement que les administrateurs de service ont pour priorité les intérêts de l'organisation. Une organisation ne doit pas joindre une forêt ou un domaine si les propriétaires de la forêt ou du domaine peuvent avoir des raisons légitimes de lui nuire.
- Vous pensez objectivement que les administrateurs de service mettent en œuvre les méthodes conseillées pour les administrateurs de service et la restriction de l'accès physique aux contrôleurs de domaine. Pour plus d'informations sur ces méthodes, consultez la section "Méthodes conseillées pour les administrateurs de service et la restriction de l'accès physique aux contrôleurs de domaine", plus loin dans ce document.
- Vous comprenez et acceptez les risques encourus par l'organisation, liés aux administrateurs non conformes et aux administrateurs contraints.
- Administrateurs non conformes — Il est toujours possible que des administrateurs approuvés deviennent des administrateurs non conformes et mettent à profit leur pouvoir dans le système.
- Administrateurs contraints — Des administrateurs approuvés peuvent être contraints ou forcés à effectuer des opérations destinées à violer la sécurité du système.
Certaines organisations peuvent accepter le risque lié à une violation de sécurité par des administrateurs de service non conformes ou contraints, basés dans d'autres parties de l'organisation. De telles organisations peuvent déterminer que l'intérêt à participer à une infrastructure partagée, en termes de travail collaboratif et de réduction des coûts, prévaut sur les risques associés. Cependant, d'autres organisations ne pourront pas accepter un tel risque, car les conséquences potentielles d'une violation de sécurité sont trop importantes.
Remarque La documentation déjà publiée sur Active Directory mentionne qu'un domaine représente une limite de sécurité, mais ne fournit pas de détails particuliers sur le niveau d'autonomie et d'isolement possible entre les domaines d'une forêt. Bien qu'un domaine soit en fait une limite de sécurité du point de vue de la gestion de Active Directory, il ne garantit pas un isolement complet face aux attaques éventuelles d'administrateurs de service malveillants, qui modifieraient le comportement du système. Pour plus d'informations, voir l'annexe de ce document.
Choix d'une structure en fonction des besoins de délégation
La figure 1 illustre le processus décisionnel permettant de déterminer si les besoins spécifiques de délégation d'une organisation justifient la délégation du contrôle d'une forêt, d'un domaine ou d'une OU distinct à cette organisation. Pour employer ce processus, effectuez l'exercice conceptuel suivant :
- Commencez par placer toutes les organisations dans une forêt à un seul domaine.
- Pour chaque organisation présentant des exigences administratives uniques, employez le processus décisionnel pour déterminer les actions appropriées à mettre en œuvre.
- Lorsque vous enregistrez la justification de chaque décision, notez les points suivants :
- La nécessité de déléguer est-elle commandée par une ou plusieurs exigences organisationnelles, opérationnelles, juridiques ou autres ?
- La nécessité de déléguer concerne-t-elle la gestion de service, la gestion de données ou les deux ?
- Est-il nécessaire de mettre en œuvre une autonomie, un isolement ou les deux ?
Le processus décisionnel pour la délégation de l'administration est illustré à la figure 1 et présenté en détail dans la série de scénarios qui suit.
Figure 1 Processus de détermination des besoins de délégation de votre organisation
Scénario 1 : Création de forêts pour l'isolement de service
Une organisation qui requiert un isolement de service exige qu'aucun administrateur externe à l'organisation ne puisse perturber le fonctionnement de l'annuaire. L'isolement de service est généralement commandé par des exigences opérationnelles ou juridiques. Pour garantir l'isolement de service, créez une nouvelle forêt pour l'organisation.
Exemples d'exigences opérationnelles qui commandent l'isolement de service :
- Une entreprise de fabrication peut disposer d'une application essentielle utilisant Active Directory qui contrôle les machines de l'usine. Si cette entreprise considère que le fonctionnement de ces machines est prioritaire, elle peut décider de créer une forêt unique pour toute l'entreprise pour les fonctions administratives normales et une forêt distincte pour chaque usine. Cela permet à chaque usine de continuer à fonctionner indépendamment de l'état de la forêt globale et des autres usines.
- Dans la marine, la capture d'un seul navire ne doit pas pouvoir compromettre la livraison de services pour la flotte ou la marine toute entière. Pour contenir l'impact de la capture d'un seul navire à ce navire même, la marine peut créer une forêt distincte pour chaque navire.
- Une société d'hébergement voudra peut-être placer des contrôleurs de domaine dans les locaux d'un client. Comme la violation de sécurité d'un seul contrôleur de domaine peut affecter la livraison de service dans le reste de la forêt, la société pourra créer une forêt distincte pour chaque client qui requiert des contrôleurs de domaine sur site. Dans le cas contraire, un client malveillant pouvant accéder physiquement à un contrôleur de domaine dans ses locaux sera en mesure de perturber le fonctionnement de l'annuaire pour nuire à d'autres clients de la même forêt.
Points spéciaux à prendre en compte pour les forêts à isolement de service :
Scénario 2 : Création de forêts pour une autonomie de service au niveau de la forêt
Une forêt se compose d'un ensemble de domaines accompagnés d'un conteneur de schéma et d'un conteneur de configuration partagés. Ces conteneurs sont contrôlés par le propriétaire de la forêt.
- Schéma : Le schéma d'une forêt détermine les classes d'objet qui peuvent être créées dans l'annuaire et les attributs associés à ces objets. Les applications qui utilisent Active Directory peuvent développer le schéma afin d'inclure des données qui leur sont spécifiques.
- Configuration : Les données stockées dans le conteneur de configuration incluent les éléments suivants :
- Les données qui définissent la topologie de site et la topologie de réplication de la forêt.
- Les paramètres de différentes stratégies appliquées dans la forêt entière, telles que la stratégie basée sur les sites et la stratégie LDAP définie sur toute la forêt (pour les contrôleurs de domaine).
- Des informations qui identifient l'ensemble des domaines inclus dans la forêt et la hiérarchie d'approbation. Chaque domaine de la forêt approuve tous les autres domaines de la forêt. En contrôlant ces données de configuration, le propriétaire de la forêt contrôle la création de nouveaux domaines dans la forêt.
- Les applications utilisant Active Directory peuvent stocker des données de configuration de la forêt toute entière dans le conteneur de configuration. Un exemple d'une telle application est Microsoft® Exchange 2000.Server.
Si une organisation doit être en mesure de manipuler indépendamment le conteneur de schéma ou de configuration, elle requiert sa propre forêt. Cette exigence est généralement induite par la structure de l'organisation ou des exigences opérationnelles.
Exemple d'exigence liée à la structure d'une organisation qui impose l'autonomie de service au niveau de la forêt :
- Une division d'une société veut installer des applications orientées annuaire qui développent le schéma, sans consulter les autres divisions de la société. La création d'une forêt distincte génère des coûts supplémentaires de gestion, qui sont compensés par l'autonomie au niveau de la forêt.
Exemple d'exigence opérationnelle, qui impose l'autonomie de service au niveau de la forêt :
- Une société d'hébergement veut que ses clients soient en mesure d'installer des applications orientées annuaire personnalisées, qui développent le schéma mais n'appartiennent pas au programme logo Windows qui certifie que le logiciel est conforme aux méthodes conseillées de schéma. Comme il est improbable que les autres clients acceptent des applications non certifiées, le client requiert un contrôle autonome sur le schéma. Pour cela, la société d'hébergement doit lui attribuer une forêt distincte.
Point spécial à prendre en compte lors de la création de forêts pour mettre en œuvre une autonomie de service au niveau de chaque forêt :
- Les organisations qui justifient la création d'une forêt distincte par les exigences liées à la structure organisationnelle doivent être conscientes que les déploiements à forêts multiples impliquent un certain équilibrage des coûts et des bénéfices. Bien qu'une organisation puisse préférer un fonctionnement avec des services autonomes, il peut s'avérer plus efficace en matière de coûts de concéder la responsabilité de la livraison de service à un groupe informatique approuvé, central. De cette manière, le groupe informatique de l'organisation peut participer à la gestion des données dans la forêt et éliminer le coût de l'expertise spécialisée de la gestion du service d'annuaire. Pour plus d'informations sur l'équilibrage des coûts et des bénéfices dans ce scénario, consultez : L'Active Directory.
Scénario 3 : Délégation de domaines pour une autonomie de service au niveau des domaines
Une organisation peut décider de laisser le propriétaire de la forêt déterminer la configuration de la forêt entière, tout en conservant une autonomie de service au niveau des domaines. Les éléments suivants du service sont contrôlés indépendamment au niveau des domaines :
- Disponibilité du service — Le propriétaire de domaine est en mesure de créer, supprimer, sauvegarder et restaurer les contrôleurs de domaine afin de maintenir le niveau souhaité de disponibilité de service.
- Approbation externe — Le propriétaire de domaine peut déterminer les domaines approuvés dans les autres forêts.
- Stratégie de compte d'utilisateur de domaine — Certaines stratégies gouvernant les comptes d'utilisateur de domaine peuvent être contrôlées uniquement au niveau des domaines. Stratégies de ce type :
- stratégie de mot de passe ;
- stratégie de verrouillage de compte ;
- stratégie de durée de vie du ticket Kerberos.
Pour déléguer la capacité de contrôler de manière autonome ces aspects du service, un propriétaire de forêt peut déléguer un domaine à l'organisation. Les points particuliers à prendre en compte lors de la délégation d'un domaine incluent les éléments suivants :
- Conformément aux informations sur Active Directory présentées plus haut dans ce document (voir "Informations sur les structures d'annuaire et leurs propriétaires"), un propriétaire de forêt doit déléguer un domaine à une organisation seulement si le propriétaire de la forêt et tous les propriétaires de domaine approuvent le propriétaire de domaine dans l'organisation déléguée. Conformément à cette condition, la méthode recommandée consiste à centraliser la propriété des services de la forêt et des domaines en une seule organisation responsable de la forêt, et à utiliser des domaines uniquement pour un partitionnement géographique de la réplication. Comme tous les administrateurs de service sont approuvés, la délégation peut être réalisée en toute sécurité, entièrement au niveau des unités organisationnelles.
- Les domaines garantissent l'autonomie de service au niveau des domaines, mais ne garantissent pas l'isolement des données par rapport au propriétaire de la forêt ou aux autres propriétaires de domaine. Créez des forêts distinctes si une organisation requiert l'isolement des données par rapport aux propriétaires de service. Pour plus d'informations, consultez la section "Scénario 4 : Création de forêts pour l'isolement des données par rapport aux propriétaires de service", plus loin dans ce document.
- Dans une organisation de grande taille, il est possible que l'organisation informatique propriétaire de la forêt soit différente de l'organisation informatique qui gère toutes les autres opérations d'annuaire. Dans ce cas, il est recommandé de créer un domaine racine dédié de la forêt. Le propriétaire du domaine racine de la forêt contrôle le domaine racine dédié de la forêt et l'organisation informatique opérationnelle obtient la propriété d'un ou de plusieurs domaines enfants. Cela permet à l'organisation informatique opérationnelle de gérer de manière autonome la disponibilité du service, mais pas de contrôler l'appartenance aux groupes Administrateurs d'entreprise et Administrateurs de schéma dans le domaine racine de la forêt. Notez qu'un domaine racine dédié fournit seulement une protection contre le détournement accidentel ou involontaire de privilèges ; les propriétaires de domaine non-racine peuvent toujours utiliser des méthodes malveillantes pour tenter de manipuler les groupes dans le domaine racine.
Pour plus d'informations sur les méthodes conseillées pour le partitionnement géographique des domaines et la conception d'un domaine racine dédié, consultez : L'Active Directory.
Scénario 4 : Création de forêts pour l'isolement des données par rapport aux propriétaires de service
Comme les données stockées dans Active Directory et sur les ordinateurs joints à Active Directory ne peuvent pas être isolées par rapport aux administrateurs de service de l'annuaire, la seule méthode dont dispose une organisation pour réaliser l'isolement complet des données consiste à créer une forêt distincte. Cette situation peut se produire dans une organisation où les administrateurs de service sont approuvés normalement, mais où une attaque par un administrateur non conforme ou contraint peut avoir des conséquences graves pour l'organisation. Ce besoin spécifique d'isoler les données est généralement induit par des exigences d'ordre juridique.
Exemples d'exigences juridiques qui rendent nécessaire l'isolement des données par rapport aux propriétaires de service :
- Une institution financière peut être tenue légalement de limiter l'accès aux données appartenant à des clients dans une juridiction particulière aux utilisateurs, ordinateurs et administrateurs situés dans cette juridiction. Bien que l'institution puisse normalement approuver les administrateurs de service qui travaillent en dehors de la juridiction protégée, une violation de la restriction d'accès peut faire perdre à l'institution son aptitude à opérer dans cette juridiction.
- Une société de défense peut être tenue légalement de limiter l'accès aux données des projets de défense à un ensemble précis d'utilisateurs. Bien que la société puisse normalement approuver les administrateurs de service qui contrôlent les systèmes informatiques liés à d'autres projets, une violation de sécurité par ces administrateurs de service peut faire perdre à la société son aptitude à traiter avec le gouvernement.
Points particuliers à prendre en compte lors de la création de forêts pour l'isolement des données par rapport aux propriétaires de service :
Scénario 5 : Délégation d'unités organisationnelles pour l'autonomie et l'isolement des données par rapport aux utilisateurs non-propriétaires de service
Une organisation peut autoriser le contrôle de la propriété des services au niveau de la forêt et des domaines par une organisation approuvée distincte, tout en conservant un contrôle autonome sur ses données en les plaçant dans une unité d'organisation (OU). Des autorisations peuvent être définies sur les données de manière à ce que seuls certains utilisateurs spécifiques puissent les consulter. Cela permet à une organisation d'isoler ses données par rapport à d'autres organisations non-propriétaires de service qui contrôlent des OU dans le même domaine ou la même forêt.
Exigence liée à la structure de l'organisation, justifiant l'utilisation d'unités organisationnelles pour la délégation :
- Dans une société, une unité professionnelle peut avoir besoin de créer, modifier et supprimer de manière indépendante des comptes d'utilisateur pour ses employés. Si l'unité professionnelle n'a pas de raison d'isoler ces comptes d'utilisateur par rapport aux propriétaires de service, elle peut accepter en toute sécurité une OU déléguée.
Exigence opérationnelle qui justifie l'utilisation d'unités organisationnelles pour la délégation :
- Une société d'hébergement qui s'occupe de la maintenance de toutes les propriétés de service dans une forêt et qui limite l'accès physique à son personnel peut déléguer des unités organisationnelles à des clients. Ces derniers peuvent gérer les données de leur annuaire de manière autonome et peuvent aussi choisir de cacher leurs données aux autres clients qui partagent la même infrastructure.
Point particulier à prendre en compte pour la délégation d'unités organisationnelles :
- Une unité d'organisation déléguée est appropriée seulement lorsque l'organisation considère que tous les propriétaires de service de la forêt sont fiables et que tous les contrôleurs de domaine de la forêt sont physiquement sécurisés.
Méthodes conseillées pour les administrateurs de service et la restriction de l'accès physique aux contrôleurs de domaine
Comme les administrateurs de service doivent être hautement approuvés, il est important de comprendre quels groupes administratifs dans Active Directory sont des administrateurs de service et quelles méthodes conseillées ces groupes doivent suivre.
Les administrateurs de service dans Active Directory incluent :
- tout groupe qui peut modifier en toute légitimité les paramètres de configuration d'annuaire ;
- tout groupe qui peut installer des contrôleurs de domaine ;
- tout groupe qui peut installer ou modifier des logiciels sur les contrôleurs de domaine ;
- tout groupe qui peut modifier l'appartenance à un autre groupe d'administrateurs de service.
Dans la version Windows 2000 de Microsoft Active Directory, ces groupes incluent :
- les groupes contrôlés par un propriétaire de forêt :
- Administrateurs de domaine (domaine racine de la forêt),
- Administrateurs d’entreprise,
- Administrateurs de schéma ;
- les groupes contrôlés par un propriétaire de domaine :
- Administrateurs de domaine,
- Builtin\Administrateurs,
- Builtin\Opérateurs de serveur,
- Builtin\Opérateurs de sauvegarde.
Pour réduire les risques d'attaque par des administrateurs de service ou par le biais de l'accès physique aux contrôleurs de domaine, nous vous conseillons d'utiliser les méthodes conseillées suivantes :
- Réduisez au maximum le nombre de membres des groupes d'administrateurs de service.
- Autorisez uniquement les groupes d'administrateurs de service à modifier l'appartenance aux autres groupes d'administrateurs de service.
- N'incluez pas d'utilisateurs ni de groupes issus de forêts approuvées externes dans les groupes d'administrateurs de service de votre forêt, à moins que les administrateurs de service provenant de la forêt externe soient approuvés au même degré que les administrateurs de service de votre forêt.
- Effectuez l'audit des modifications apportées aux appartenances aux groupes d'administrateurs de service
- Ouvrez une session à l'aide des informations d'identification d'un administrateur de service uniquement en cas d'absolue nécessité. Utilisez des comptes d'utilisateur auxiliaires pour les administrateurs, pour les tâches quotidiennes.
- Autorisez uniquement les groupes d'administrateurs de service à gérer les stations de travail utilisées par des administrateurs de service.
- Limitez aux administrateurs de service l'accès physique aux contrôleurs de domaine. Ne placez pas les contrôleurs de domaine dans des emplacements qui ne peuvent pas être sécurisés.
- Limitez aux administrateurs de service l'accès physique aux sauvegardes de l'état du système des contrôleurs de domaine. N'enregistrez pas les sauvegardes de l'état du système dans des emplacements qui ne peuvent pas être sécurisés.
- Réduisez au maximum la taille du logiciel qui s'exécute sur les contrôleurs de domaine.
- Préparez et mettez en pratique un plan de récupération d'entreprise sur l'ensemble de la forêt.
- Formez les administrateurs de service sur le fait qu'il est essentiel de suivre les méthodes conseillées.
Conclusion
Active Directory fournit une infrastructure qui permet la collaboration entre les personnes et les organisations. Lors de la conception d'une délégation d'administration, les planificateurs doivent définir précisément leurs besoins en délégation, comprendre les implications de la délégation en terme de sécurité et être conscients du compromis à faire entre collaboration, autonomie et isolement dans une infrastructure d'annuaire.
Pour permettre une collaboration maximale à un coût de gestion minimal, une organisation peut déployer une infrastructure à une seule forêt, dans laquelle une seule organisation informatique est propriétaire de toute la gestion de service de la forêt et des domaines, et délègue l'autonomie ou l'isolement des données à d'autres organisations à l'aide d'unités organisationnelles. Chaque organisation voulant participer à la forêt doit auparavant approuver le propriétaire de service.
Les besoins spécifiques en autonomie ou en isolement de certaines organisations font que l'approbation d'un propriétaire de service central est peu pratique ou déconseillée. Ces organisations peuvent déployer plusieurs forêts et permettre une collaboration inter-forêt par le biais de systèmes de gestion supplémentaires, tels que Microsoft Metadirectory Services (MMS).
Pour plus d'informations sur MMS, consultez Microsoft Metadirectory Services.
Annexe - Informations générales sur la nécessité d'approuver les administrateurs de service et d'accéder physiquement aux contrôleurs de domaine
Les procédures de conception fournies dans ce document partent de l'hypothèse que toute organisation qui participe à une forêt approuve tous les administrateurs de service dans cette forêt (le propriétaire de la forêt et les propriétaires des domaines) et est satisfaite de la sécurité physique des contrôleurs de domaine. La section suivante explique pourquoi ces conditions doivent être respectées.
Implications en matière de sécurité de l'accès des administrateurs de service et de l'accès physique
Active Directory inclut des fonctionnalités de sécurité définies par les deux composants centraux du système suivants :
- Le logiciel système qui correspond à un contrôleur de domaine Active Directory — Ce logiciel prend en charge les processus d'authentification, crée et transmet les structures de données qui définissent l'identité d'un utilisateur (également nommées données d'autorisation), applique les stratégies et limite l'accès aux objets dans l'annuaire sur la base d'autorisations définies par objet et par attribut.
- La base de données d'annuaire stockée sur les contrôleurs de domaine — La base de données Active Directory stocke des informations telles que les mots de passe des utilisateurs, les appartenances aux groupes et les listes de contrôle d'accès, qui régissent l'accès aux objets.
Si un attaquant modifie le logiciel système ou la base de données d'annuaire d'un contrôleur de domaine, il peut désactiver les fonctionnalités de sécurité dans Active Directory ou les modifier à son avantage. Les personnes suivantes ont la capacité de lancer une telle attaque :
Remarque La fonctionnalité SYSKEY de Active Directory fournit une protection supplémentaire pour les mots de passe enregistrés dans la base de données Active Directory en les cryptant à l'aide d'une clé système conservée sur disquette. Pour décoder les mots de passe dans la base de données, l'attaquant doit pouvoir accéder physiquement à la base de données Active Directory et à la disquette contenant la clé système.
Il est important de noter que SYSKEY ne crypte pas la base de données entière. Un attaquant capable d'obtenir une copie physique de la base de données peut encore lire et modifier les données non cryptées dans la base de données, sans que les listes ACL soient vérifiées. Pour plus d'informations sur la fonctionnalité SYSKEY, consultez : Windows 2000 Server Resource Kits .
Les attaques visant à modifier le logiciel système ne se limitent pas à changer le comportement des fonctionnalités de sécurité. Par exemple, le système applique normalement une condition qui veut que les mises à jour du schéma soient enregistrées sur le contrôleur de domaine détenant le rôle de contrôleur de schéma. Un attaquant peut modifier le logiciel système de manière à annuler la vérification du rôle de contrôleur de schéma et mettre à jour le schéma sur le contrôleur de domaine modifié.
Bien que les attaques contre le logiciel système et les modifications physiques de la base de données d'annuaire paraissent difficiles, un seul attaquant hautement qualifié peut créer les outils nécessaires à une telle attaque. Une fois que ces outils ont été créés, ils peuvent être fournis à tout administrateur.
Vulnérabilités liées à la modification du système
Dans un système distribué, la violation de sécurité d'un seul ordinateur peut avoir des conséquences sur de nombreux ordinateurs, voire sur le système entier. Une forêt Active Directory est un système distribué étroitement couplé. Un attaquant en mesure de modifier le logiciel système sur un contrôleur de domaine ou d'accéder physiquement à un contrôleur de domaine peut exploiter le couplage étroit du système pour étendre l'attaque à d'autres ordinateurs dans la forêt. En particulier, l'attaque peut tirer parti des caractéristiques suivantes de Active Directory :
- Tous les centres de distribution de clés Kerberos (centres KDC) sont approuvés au même degré.
Lorsqu'un utilisateur ouvre une session, le logiciel KDC sur un contrôleur de domaine crée les données d'autorisation qui décrivent l'identité de l'utilisateur. Ces données d'autorisation contiennent les identificateurs de sécurité (SID) de l'utilisateur et des groupes dont l'utilisateur est membre. Lorsqu'un utilisateur tente d'accéder à une ressource dans un autre domaine, le centre KDC de l'utilisateur envoie les données d'autorisation au centre KDC dans l'autre domaine en tant que représentation de l'identité de l'utilisateur.
Pour que des fonctions telles que l'historique des SID et les groupes universels soient utilisables, les centres KDC de chaque domaine doivent accepter la validité des données d'autorisation d'utilisateur qui incluent des SID provenant de l'extérieur du domaine de base de l'utilisateur.
Un attaquant peut exploiter une telle fonction en modifiant le logiciel KDC ou la base de données d'annuaire afin d'insérer des SID dans les données d'autorisation d'un utilisateur. De cette manière, l'attaquant peut s'authentifier auprès d'un contrôleur de domaine modifié et utiliser les SID insérés pour se faire passer pour un utilisateur quelconque ou devenir membre d'un groupe dans la forêt (y compris les groupes administratifs). Une attaque de ce type est nommée attaque d'usurpation des données d'autorisation ou d'usurpation de SID.
- Les données stockées dans les partitions partagées de schéma et de configuration sur tous les contrôleurs de domaine et les données stockées dans les partitions de domaine partielles sur tous les serveurs de catalogue global sont approuvées au même degré.
Lorsque des contrôleurs de domaine répliquent des modifications dans les partitions partagées de schéma et de configuration, ils considèrent toutes les copies de la partition sur tous les contrôleurs de domaine comme également fiables. Un contrôleur de domaine accepte la réplication de mises à jour sur ces partitions à partir de tous les contrôleurs de domaine de la forêt. En outre, le logiciel utilisant Active Directory sur les ordinateurs clients approuve au même degré les partitions de schéma et de configuration sur tous les contrôleurs de domaine et accepte les réponses de tous les contrôleurs de domaine de la forêt à ses requêtes sur ces informations.
Lorsque des contrôleurs de domaine configurés en tant que serveurs de catalogue global répliquent des modifications dans des partitions de domaine partielles, ils peuvent sélectionner comme partenaire de réplication un contrôleur de domaine disposant d'une copie complète de la partition ou un autre serveur de catalogue global issu d'un domaine quelconque de la forêt. Là encore, le logiciel client utilisant Active Directory approuve au même degré tous les serveurs de catalogue global d'une forêt et accepte les réponses de tous ces serveurs à ses requêtes.
Ces conditions permettent aux contrôleurs de domaine d'optimiser le flux de réplication entre les contrôleurs de domaine, en fonction de la topologie de site de la forêt. Cela permet d'empêcher de répliquer les mêmes données plusieurs fois sur une liaison réseau lente. Ces conditions permettent également aux clients d'interroger un serveur de catalogue global ou les conteneurs de configuration ou de schéma d'un contrôleur de domaine dans le même site que le client, quel que soit le domaine auquel appartient le serveur. Cela empêche de restreindre les clients aux serveurs de catalogue global et contrôleurs de domaine issus du même domaine que le client, qui peuvent ne pas être situés dans le même site que le client.
Une vulnérabilité est introduite car un attaquant peut, soit en modifiant le logiciel système, soit en accédant physiquement à la base de données d'annuaire, modifier les données sensibles de sécurité stockées dans la partition de schéma, la partition de configuration ou toute partition de domaine partielle sur un contrôleur de domaine dont la sécurité a été violée. Ceci peut avoir les conséquences suivantes :
- les contrôleurs de domaine en aval acceptent ces modifications en tant que mises à jour de réplication légales ;
- le logiciel client orienté annuaire accepte ces données en tant que données légales.
Le logiciel de sécurité enregistré dans ces partitions inclut les éléments suivants :
- Schéma — Le descripteur de sécurité par défaut d'une classe d'objet. Un attaquant peut modifier le descripteur de sécurité par défaut d'une classe d'objet pour autoriser l'accès à des utilisateurs ou des groupes sous son contrôle. Cela autorise l'attaquant à accéder aux objets nouvellement créés de cette classe.
- Configuration — Stratégie définie sur des sites. Un attaquant peut modifier la stratégie définie sur les sites, afin que les utilisateurs dans les domaines distants exécutent les scripts d'ouverture de session qu'il a lui-même définis.
- Partitions de domaine partielles — Appartenances à des groupes universels. Un attaquant peut modifier l'appartenance à un groupe universel administratif disposant de privilèges très élevés, tel que le groupe des administrateurs d'entreprise, pour inclure des utilisateurs qu'il spécifiera.
En utilisant ces fonctionnalités comme il est décrit, un attaquant peut étendre l'impact d'une attaque portant sur un seul contrôleur de domaine aux éléments suivants :
- la configuration de la forêt ;
- la configuration de tout domaine dans la forêt ;
- toute application qui s'appuie sur des données stockées dans un domaine de la forêt ou dans le conteneur de configuration de la forêt ;
- tout ordinateur joint à la forêt, y compris les données stockées sur ces ordinateurs et les services qui y sont exécutés ;
- toute ressource située dans un domaine quelconque externe à la forêt attaquée, qui approuve un domaine inclus dans la forêt attaquée et auquel les utilisateurs de la forêt attaquée ont accès.
Pour les raisons présentées ici, les organisations qui participent à une forêt ne peuvent pas être isolées par rapport aux administrateurs de service de la forêt et doivent approuver toutes les personnes disposant d'un accès physique aux contrôleurs de domaine. En conséquence, ces organisations doivent entreprendre d'atténuer ou de limiter les vulnérabilités qui résultent de la nécessité d'approuver les administrateurs de service et de la possibilité d'accéder sans autorisation aux contrôleurs de domaine.
Remarque Les deux caractéristiques précédentes de Active Directory ne peuvent pas être utilisées pour lancer des attaques entre des domaines situés dans des forêts différentes, si les précautions requises suivantes sont observées :
- Pour vous protéger contre les attaques de type usurpation des données d'autorisation, utilisez la fonctionnalité de filtrage des identificateurs de sécurité sur les liens d'approbation externes entre des domaines situés dans des forêts différentes. Pour plus d'informations sur le filtrage des identificateurs de sécurité, consultez l'article Q309172 de la Base de connaissances Microsoft, sur le site Support en Ligne.
- Aucune partition de données n'est partagée ni répliquée entre contrôleurs de domaine situés dans des forêts différentes. Les utilisateurs et administrateurs issus de domaines approuvés en externe dans des forêts distantes peuvent mettre à jour des données sensibles sur le plan de la sécurité dans une autre forêt, seulement si l'autorisation d'accès en écriture à ces données leur a été spécifiquement accordée. N'autorisez pas l'accès à des données sensibles sur le plan de la sécurité à des utilisateurs issus de domaines approuvés en externe, à moins que ces utilisateurs et les administrateurs de service du domaine distant soient approuvés au même degré que les administrateurs de service de votre forêt.
Article N° 37, du 29.08.2002, par Alain Gremaud
URL de cet article : http://winad.epfl.ch/?article=37