Réduire la Surface d'attaque Active Directory
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Cette section se concentre sur les contrôles techniques à implémenter pour réduire la surface d’attaque de l’installation d’Active Directory. Cette section contient les informations suivantes :
Implémentation de modèles d’administration de moindre privilège : se concentre sur l’identification du risque que représente l’utilisation de comptes hautement privilégiés pour l’administration quotidienne, en plus de fournir des recommandations à implémenter afin de réduire le risque présenté par les comptes privilégiés.
Implémentation d’hôtes d’administration sécurisés : décrit les principes de déploiement de systèmes d’administration dédiés et sécurisés, en plus de certains exemples d’approches pour un déploiement d’hôte d’administration sécurisé.
Sécurisation des contrôleurs de domaine contre les attaques : traite des stratégies et des paramètres qui, bien que similaires aux recommandations pour l’implémentation d’hôtes d’administration sécurisés, contiennent des recommandations propres au contrôleur de domaine pour que les contrôleurs de domaine et les systèmes utilisés pour les gérer soient bien sécurisés.
Groupes et comptes privilégiés dans Active Directory
Cette section fournit des informations générales sur les comptes et groupes privilégiés dans Active Directory, destinées à expliquer les points communs et les différences entre les groupes et comptes privilégiés dans Active Directory. En comprenant ces distinctions, que vous implémentiez les recommandations décrites dans Implémentation de modèles d’administration selon le principe des privilèges minimum telles quelles ou que vous choisissiez de les personnaliser pour votre organisation, vous disposez des outils dont vous avez besoin pour sécuriser chaque groupe et chaque compte de manière appropriée.
Comptes et groupes privilégiés intégrés
Active Directory facilite la délégation de l’administration et soutient le principe des privilèges minimum dans l’attribution de droits et d’autorisations. Les utilisateurs « courants » qui ont des comptes dans un domaine sont, par défaut, en mesure de lire une grande partie de ce qui est stocké dans le répertoire, mais ne peuvent modifier qu’un ensemble très limité de données dans le répertoire. Les utilisateurs qui ont besoin de privilèges supplémentaires peuvent se voir accorder l’appartenance à différents groupes privilégiés intégrés au répertoire, afin de pouvoir effectuer des tâches spécifiques liées à leurs rôles, mais ils ne peuvent pas effectuer des tâches qui ne sont pas pertinentes à leurs fonctions. Les organisations peuvent également créer des groupes adaptés à des responsabilités de travail spécifiques et se voir accorder des droits et des autorisations précis qui permettent au personnel informatique d’effectuer des fonctions administratives quotidiennes sans accorder des droits et autorisations qui dépassent ce qui est requis pour ces fonctions.
Dans Active Directory, trois groupes intégrés sont les groupes aux privilèges les plus élevés dans l’annuaire : Administrateurs d’entreprise, Administrateurs de domaine et Administrateurs. La configuration et les fonctionnalités par défaut de chacun de ces groupes sont décrites dans les sections suivantes :
Groupes aux privilèges les plus élevés dans Active Directory
Administrateurs de l’entreprise
Administrateurs d’entreprise (EA) est un groupe qui existe uniquement dans le domaine racine de la forêt et, par défaut, il est membre du groupe Administrateurs dans tous les domaines de la forêt. Le compte Administrateur intégré dans le domaine racine de la forêt est le seul membre par défaut du groupe EA. Les EA bénéficient de droits et d’autorisations qui leur permettent d’implémenter des modifications à l’échelle de la forêt (c’est-à-dire des modifications qui affectent tous les domaines de la forêt), comme l’ajout ou la suppression de domaines, l’établissement d’approbations de forêt ou l’élévation des niveaux fonctionnels de la forêt. Dans un modèle de délégation correctement conçu et implémenté, l’appartenance à l’EA n’est requise que lors de la construction initiale de la forêt ou lors de certaines modifications à l’échelle de la forêt, telles que l’établissement d’une approbation de forêt sortante. La plupart des droits et autorisations accordés au groupe EA peuvent être délégués à des utilisateurs et à des groupes à privilèges moindres.
Administrateurs du domaine
Chaque domaine d’une forêt possède son propre groupe Administrateurs de domaine (DA), qui est membre du groupe Administrateurs de ce domaine et du groupe Administrateurs local sur chaque ordinateur joint au domaine. Le seul membre par défaut du groupe DA pour un domaine est le compte Administrateur intégré pour ce domaine. Les DA sont toutes puissantes au sein de leurs domaines, tandis que les BA ont des privilèges à l’échelle de la forêt. Dans un modèle de délégation correctement conçu et implémenté, l’appartenance aux administrateurs de domaine ne doit être requise que dans les scénarios d’urgence (par exemple, dans les situations où un compte avec des niveaux de privilèges élevés sur chaque ordinateur du domaine est nécessaire). Bien que les mécanismes de délégation Active Directory natifs autorisent la délégation dans la mesure où il est possible d’utiliser des comptes DA uniquement dans les scénarios d’urgence, la construction d’un modèle de délégation efficace peut prendre du temps et de nombreuses organisations utilisent des outils tiers, afin d’accélérer le processus.
Administrateurs
Le troisième groupe est le groupe Administrateurs locaux de domaine intégré (BA) dans lequel les DA et EA sont imbriqués. Ce groupe bénéficie de nombreux droits et autorisations directs dans l’annuaire et sur les contrôleurs de domaine. Toutefois, le groupe Administrateurs d’un domaine ne dispose pas de privilèges sur les serveurs membres ou sur les stations de travail. C’est via l’appartenance au groupe Administrateurs local des ordinateurs que le privilège local est accordé.
Notes
Bien qu’il s’agisse des configurations par défaut de ces groupes privilégiés, un membre de l’un des trois groupes peut manipuler le répertoire pour devenir membre de l’un des autres groupes. Dans certains cas, il est trivial d’obtenir l’appartenance aux autres groupes, tandis que dans d’autres cas c’est plus difficile, mais du point de vue des privilèges potentiels, les trois groupes devraient être considérés comme effectivement équivalents.
Administrateurs du schéma
Un quatrième groupe privilégié, Administrateurs de schéma (SA), existe uniquement dans le domaine racine de la forêt, et a uniquement le compte Administrateur intégré de ce domaine comme membre par défaut, comme le groupe Administrateurs d’entreprise. Le groupe Administrateurs de schéma est destiné à être rempli uniquement temporairement et occasionnellement (lorsque la modification du schéma AD DS est requise).
Bien que le groupe SA soit le seul groupe qui peut modifier le schéma Active Directory (autrement dit, les structures de données sous-jacentes de l’annuaire, comme les objets et les attributs), l’étendue des droits et autorisations du groupe d’accès partagé est plus limitée que pour les groupes décrits précédemment. Il est également courant de constater que les organisations ont développé des pratiques appropriées pour la gestion de l’appartenance au groupe SA, car l’appartenance au groupe est généralement rarement nécessaire, et seulement pendant de courtes périodes. Cela est techniquement vrai pour les groupes EA, DA et BA dans Active Directory, mais il est beaucoup moins courant de constater que les organisations implémentent des pratiques similaires pour ces groupes que pour le groupe SA.
Groupes et comptes protégés dans Active Directory
Dans Active Directory, un ensemble par défaut de comptes et de groupes privilégiés appelés comptes et groupes « protégés » sont sécurisés différemment des autres objets de l’annuaire. Tout compte qui a une appartenance directe ou transitive à un groupe protégé (que l’appartenance soit dérivée de groupes de sécurité ou de distribution) hérite de cette sécurité restreinte.
Par exemple, si un utilisateur est membre d’un groupe de distribution qui est, à son tour, membre d’un groupe protégé dans Active Directory, cet objet utilisateur est marqué en tant que compte protégé. Lorsqu’un compte est marqué en tant que compte protégé, la valeur de l’attribut adminCount sur l’objet est définie sur 1.
Notes
Bien que l’appartenance transitive dans un groupe protégé inclut une distribution imbriquée et des groupes de sécurité imbriqués, les comptes membres de groupes de distribution imbriqués ne recevront pas le SID du groupe protégé dans leurs jetons d’accès. Toutefois, les groupes de distribution peuvent être convertis en groupes de sécurité dans Active Directory, ce qui explique pourquoi les groupes de distribution sont inclus dans l’énumération des membres de groupe protégés. Si un groupe de distribution imbriqué protégé est converti en groupe de sécurité, les comptes membres de l’ancien groupe de distribution recevront par la suite le SID du groupe protégé parent dans leurs jetons d’accès à la prochaine ouverture de session.
Le tableau suivant répertorie les comptes et groupes protégés par défaut dans Active Directory par version du système d’exploitation et niveau de Service Pack.
Comptes et groupes protégés par défaut dans Active Directory par système d’exploitation et version de Service Pack (SP)
| Windows 2000 <SP4 | Windows 2000 SP4 - Windows Server 2003 | Windows Server 2003 SP1 | Windows Server 2008 -Windows Server 2012 |
|---|---|---|---|
| Administrateurs | Opérateurs de compte | Opérateurs de compte | Opérateurs de compte |
| Administrateur | Administrateur | Administrateur | |
| Administrateurs | Administrateurs | Administrateurs | |
| Administrateurs du domaine | Opérateurs de sauvegarde | Opérateurs de sauvegarde | Opérateurs de sauvegarde |
| Éditeurs de certificats | |||
| Administrateurs du domaine | Administrateurs du domaine | Administrateurs du domaine | |
| Administrateurs de l’entreprise | Contrôleurs de domaine | Contrôleurs de domaine | Contrôleurs de domaine |
| Administrateurs de l’entreprise | Administrateurs de l’entreprise | Administrateurs de l’entreprise | |
| Krbtgt | Krbtgt | Krbtgt | |
| Opérateurs d'impression | Opérateurs d'impression | Opérateurs d'impression | |
| Contrôleurs de domaine en lecture seule | |||
| Duplicateur | Duplicateur | Duplicateur | |
| Administrateurs du schéma | Administrateurs du schéma | Administrateurs du schéma |
AdminSDHolder et SDProp
Dans le conteneur système de chaque domaine Active Directory, un objet appelé AdminSDHolder est automatiquement créé. L’objectif de l’objet AdminSDHolder est de s’assurer que les autorisations sur les comptes et groupes protégés sont appliquées de manière cohérente, quel que soit l’emplacement des groupes et comptes protégés dans le domaine.
Toutes les 60 minutes (par défaut), un processus appelé SDProp (Security Descriptor Propagator) s’exécute sur le contrôleur de domaine qui détient le rôle Émulateur PDC du domaine. SDProp compare les autorisations sur l’objet AdminSDHolder du domaine avec les autorisations sur les comptes et groupes protégés dans le domaine. Si les autorisations sur l’un des comptes et groupes protégés ne correspondent pas aux autorisations de l’objet AdminSDHolder, les autorisations sur les comptes et groupes protégés sont réinitialisées pour correspondre à celles de l’objet AdminSDHolder du domaine.
L’héritage des autorisations est désactivé sur les groupes et comptes protégés, ce qui signifie que même si les comptes ou les groupes sont déplacés vers des emplacements différents dans le répertoire, ils n’héritent pas des autorisations de leurs nouveaux objets parents. L’héritage est également désactivé sur l’objet AdminSDHolder afin que les modifications d’autorisations apportées aux objets parents ne modifient pas les autorisations d’AdminSDHolder.
Notes
Lorsqu’un compte est supprimé d’un groupe protégé, il n’est plus considéré comme un compte protégé, mais son attribut adminCount reste défini sur 1 s’il n’est pas modifié manuellement. Le résultat de cette configuration est que les listes de contrôle d’accès de l’objet ne sont plus mises à jour par SDProp, mais que l’objet n’hérite toujours pas des autorisations de son objet parent. Par conséquent, l’objet peut résider dans une unité d’organisation à laquelle des autorisations ont été déléguées, mais l’objet précédemment protégé n’héritera pas de ces autorisations déléguées. Vous trouverez un script pour localiser et réinitialiser des objets précédemment protégés dans le domaine dans l’article du Support Microsoft 817433.
Propriété AdminSDHolder
La plupart des objets dans Active Directory appartiennent au groupe BA du domaine. Toutefois, l’objet AdminSDHolder appartient par défaut au groupe DA du domaine. (Il s’agit d’une circonstance dans laquelle les autorités de domaine ne dérivent pas leurs droits et autorisations via l’appartenance au groupe Administrateurs pour le domaine.)
Dans les versions de Windows antérieures à Windows Server 2008, les propriétaires d’un objet peuvent modifier les autorisations de l’objet, y compris s’octroyer des autorisations qu’ils n’avaient pas à l’origine. Par conséquent, les autorisations par défaut sur l’objet AdminSDHolder d’un domaine empêchent les utilisateurs membres des groupes BA ou EA de modifier les autorisations de l’objet AdminSDHolder d’un domaine. Toutefois, les membres du groupe Administrateurs du domaine peuvent s’approprier l’objet et s’accorder des autorisations supplémentaires, ce qui signifie que cette protection est rudimentaire et protège uniquement l’objet contre toute modification accidentelle par des utilisateurs qui ne sont pas membres du groupe DA dans le domaine. En outre, les groupes BA et EA (le cas échéant) sont autorisés à modifier les attributs de l’objet AdminSDHolder dans le domaine local (domaine racine pour EA).
Notes
Un attribut de l’objet AdminSDHolder, dSHeuristics, permet une personnalisation limitée (suppression) des groupes considérés comme des groupes protégés et qui sont affectés par AdminSDHolder et SDProp. Cette personnalisation doit être soigneusement envisagée si elle est implémentée, bien qu’il existe des circonstances valides dans lesquelles la modification de dSHeuristics sur AdminSDHolder est utile. Pour plus d’informations sur la modification de l’attribut dSHeuristics sur un objet AdminSDHolder, consultez les articles du Support Microsoft 817433 et Annexe C : Comptes protégés et groupes dans Active Directory.
Bien que les groupes les plus privilégiés d’Active Directory soient décrits ici, un certain nombre d’autres groupes ont reçu des niveaux élevés de privilèges. Pour plus d’informations sur tous les groupes par défaut et intégrés dans Active Directory, ainsi que sur les droits utilisateur attribués à chacun d’eux, consultez Annexe B : Comptes privilégiés et groupes dans Active Directory.