[Mise à jour le 14 février 2024 ; initialement publiée le 29 novembre 2021] Le nombre et l'étendue des paramètres de sécurité déroutants et risqués dans Active Directory sont de mieux en mieux connus à chaque nouvelle cyberattaque. Bon nombre de ces vulnérabilités peuvent être attribuées à des configurations risquées qui se sont accumulées au fil du temps dans les environnements existants. Cependant, les équipes informatiques doivent toujours être attentives aux paramètres problématiques qui sortent de la boîte de Windows Server 2022. Malheureusement, il en va de même pour le prochain Windows Server 2025. L'un des paramètres d'Active Directory que toutes les équipes informatiques devraient immédiatement prendre en compte est le groupe Pre-Windows 2000 Compatible Access pré-rempli avec le principe de sécurité Authenticated Users (Utilisateurs authentifiés ). Ce paramètre peut laisser une porte ouverte aux intrus, comme je vais le démontrer.
Pour comprendre pourquoi le paramètre Accès compatible pré-Windows 2000 est si problématique, examinons l'histoire de la délégation d'autorisations et de l'attribution de stratégies dans Active Directory. Vous pourrez ainsi décider en toute connaissance de cause de la manière de gérer ce paramètre dans votre organisation.
Lecture connexe : Qu'est-ce que la sécurité Active Directory ?
Être ou ne pas être ... compatible avec Windows NT ?
Il y a une bonne raison pour laquelle nous ne parlons pas beaucoup de Windows NT ces jours-ci. C'est de l'histoire ancienne. C'est une technologie du siècle dernier.
Windows NT a été un grand pas en avant pour Microsoft et a marqué l'entrée de la société sur le marché des entreprises en 1993. Mais le système d'exploitation a été remplacé par des versions plus récentes et plus sûres depuis la sortie de Windows 2000 au début de ce siècle. Du côté des serveurs, Microsoft a conservé la norme de dénomination consistant à ajouter l'année la plus proche de la date de sortie.
Au moment où j'écris cette mise à jour, Windows Server 2022 est le dernier système d'exploitation de Microsoft. Mais en janvier 2024, le nom de la prochaine version "vNext" a été (sans surprise) confirmé comme étant Windows Server 2025. Nous nous attendons à ce que la nouvelle version du système d'exploitation soit publiée avant la fin de l'année 2024.
Qu'est-ce qui a changé dans Windows 2000 ?
L'un des principaux changements apportés par Windows 2000 a été le remplacement du concept de domaine de Windows NT - qui était un répertoire plat permettant d'authentifier les utilisateurs et les machines au sein du réseau d'une entreprise - par l'Active Directory, beaucoup plus évolutif et sécurisé. Outre le concept de domaine, Active Directory a introduit les arbres de domaine et les forêts. Le service a également permis la création d'une structure hiérarchique d'unités d'organisation (OU) pour les objets au sein d'un domaine. Cette structure était utile pour déléguer des permissions et assigner des politiques spécifiques.
Une autre différence essentielle était tout aussi importante. Active Directory a introduit la possibilité de définir des autorisations non seulement au niveau des objets (par exemple, utilisateurs, groupes, ordinateurs), mais aussi au niveau des attributs (par exemple, département, numéro de téléphone, appartenance à un groupe) de chaque objet. Les administrateurs peuvent désormais faire la distinction entre la possibilité de "lire" ou d'"écrire" tous les attributs d'un objet Active Directory donné ou seulement les attributs pertinents pour une tâche donnée.
La clé du principe du moindre privilège
Cette capacité était essentielle pour permettre aux entreprises de suivre le mantra du moindre privilège de tout bon plan de sécurité : N'accordez à vos utilisateurs que les autorisations dont ils ont besoin pour faire leur travail. N'accordez pas aux utilisateurs davantage d'autorisations d'accès aux données dont ils n'ont pas besoin. Dans le cas contraire, un utilisateur - en particulier un utilisateur compromis - pourrait abuser de ces autorisations et nuire à l'entreprise.
Dans un serveur de fichiers ou une structure SharePoint qui partage des documents pour les utilisateurs de toute l'entreprise, l'approche la plus naturelle consisterait à suivre la règle du moindre privilège. Par exemple, les utilisateurs doivent être membres d'un groupe de sécurité approprié pour être autorisés à consulter des documents contenant des données financières ou d'autres données sensibles de l'entreprise, ou même pour faire état de l'existence d'un fichier.
Vous pouvez toujours choisir de mettre des données spécifiques et non sensibles à la disposition de tous vos utilisateurs par le biais d'un partage de documents publics auquel tous les utilisateurs ont accès, sans qu'il soit nécessaire de les ajouter à un groupe spécial. Cet accès serait généralement accordé à votre groupe d'utilisateurs du domaine ou même aux principes de sécurité Utilisateurs authentifiés ou Tout le monde .
Malheureusement, la plupart des entreprises ne traitent pas Active Directory de cette manière. Cela s'explique en partie par les autorisations par défaut avec lesquelles Microsoft a déployé - et déploie encore - les nouveaux domaines Active Directory.
Qu'est-ce que le groupe "Pre-Windows 2000 Compatible Access" ?
Prenons l'exemple du groupe Pre-Windows 2000 Compatible Access. Microsoft a décidé d'introduire ce groupe - qu'il serait plus approprié d'appeler le groupe "Less Secure Windows NT Permissions" - lors de la sortie de Windows 2000. Le problème : même dans un nouveau déploiement d'une toute nouvelle forêt Active Directory sur des serveurs Windows Server 2022 - et oui, des serveurs Windows Server 2025 - Microsoft pré-remplit le groupe Pre-Windows 2000 Compatible Access avec le principal de sécurité Authenticated Users (utilisateurs authentifiés ).
En quoi cela est-il important et pourquoi devriez-vous vous en préoccuper ?
Comme son nom l'indique, le groupe Pre-Windows 2000 Compatible Access a été créé pour être compatible avec Windows NT. En d'autres termes, le groupe vous permet d'accorder des autorisations au niveau de l'objet sur les objets Active Directory qui sont compatibles avec Windows NT, moins sûr, au lieu d'utiliser des autorisations plus granulaires au niveau de l'attribut. Microsoft ne cache pas les implications potentiellement risquées dans la description du groupe : "Un groupe de compatibilité ascendante qui autorise l'accès en lecture à tous les utilisateurs et groupes du domaine".
Et parce que Microsoft veut vous "aider" autant que possible avec cette compatibilité ascendante, il accorde des permissions READ complètes pour les objets respectifs (utilisateurs et groupes) au sommet de chaque domaine de votre forêt, permettant d'hériter de toute la hiérarchie OU.
Ces autorisations par défaut sont définies, bien que Microsoft ne vous demande plus si vous souhaitez déployer votre nouvelle forêt AD d'une manière compatible avec les versions de Windows antérieures à Windows 2000 (c'est-à-dire Windows NT). Cette option était disponible dans l'ancien système d'exploitation lors de la promotion d'une nouvelle forêt AD. Si vous aviez effectivement choisi cette option il y a quelques années, vous auriez même ajouté les Utilisateurs anonymes et Tout le monde au groupe Accès compatible pré-Windows 2000, accordant ainsi à ces principes de sécurité un accès en lecture puissant à votre Active Directory. Les utilisateurs n'auraient même pas besoin de s'authentifier pour lire votre AD ! J'espère sincèrement que vous avez déjà nettoyé ces autorisations héritées du passé, au sujet desquelles tous les contrôles de sécurité vous auraient déjà mis en garde.
Pouvez-vous laisser les utilisateurs authentifiés dans le groupe Accès compatible pré-Windows 2000 ?
Oui, vous devez supprimer les utilisateurs authentifiés des groupes d'accès compatibles pré-Windows 2000 dans chaque domaine de votre forêt AD, même si Microsoft continue de les ajouter par défaut aux nouveaux déploiements AD. Le fait de laisser les utilisateurs authentifiés dans le groupe leur accorde des autorisations de LECTURE complètes, ce qui permet à tout utilisateur et à tout ordinateur connecté à un domaine de lire les données correspondantes sur n'importe quel objet de ce type.
Notez que chaque ordinateur relié à un domaine est également un utilisateur authentifié dans votre forêt Active Directory. Même si aucun utilisateur n'est connecté à ces ordinateurs, un processus - peut-être un cheval de Troie - exécuté dans le contexte système d'un ordinateur relié à un domaine a le même accès à Active Directory que vos utilisateurs.
Pour mieux comprendre l'impact, nous devons creuser un peu plus et vérifier quelles sont les permissions accordées par défaut à Authenticated Users sur tous les objets utilisateurs et groupes de votre domaine. Après tout, chaque fois que vous créez un objet, Active Directory ajoute le descripteur de sécurité par défaut pour l'objet donné au nouvel objet. Ces autorisations sont explicitement accordées à l'objet (c'est-à-dire qu'elles ne sont pas héritées). En tant que telles, elles ont la priorité la plus élevée lorsque les autorisations globales de l'objet sont déterminées. Notez que cette configuration accorde également à ces autorisations par défaut une priorité plus élevée qu'une autorisation de refus héritée, ce qui est souvent source de confusion pour les administrateurs.
Permissions sur les objets du groupe
Pour les objets de groupe, les autorisations d'accès compatibles pré-Windows 2000 ne font pas de différence. Les utilisateurs authentifiés bénéficient d'une LECTURE complète sur chaque objet de groupe.
Même si vous supprimez l'autorisation Utilisateurs authentifiés du groupe Accès compatible pré-Windows 2000, tous vos utilisateurs peuvent toujours lire les membres de tous les groupes de votre forêt Active Directory. Si vous ne supprimez pas cette autorisation pour les groupes sélectionnés, n'importe quel utilisateur de votre forêt - y compris un intrus potentiel - peut facilement déterminer qui est membre de n'importe quel groupe de votre domaine. Pour les groupes AD les plus sensibles, tels que les administrateurs de domaine ou les administrateurs d'entreprise, vous devrez prendre quelques mesures supplémentaires pour supprimer cette autorisation READ. (Ces groupes sont contrôlés par des autorisations sur un objet spécial appelé AdminSDholder. Pour en savoir plus sur AdminSDholder et la sécurité d'Active Directory, consultez ce livre blanc).
Permissions sur les objets des utilisateurs
Toutefois, la situation est tout à fait différente pour les objets utilisateurs. Les autorisations par défaut accordées aux utilisateurs authentifiés sur les objets utilisateurs sont également très étendues, y compris la lecture de tous les attributs d'informations générales et personnelles. Toutefois, les autorisations sont moins étendues que la lecture de tous les attributs des utilisateurs.
Cela signifie que les utilisateurs authentifiés ne peuvent PAS accéder à divers attributs sensibles de l'utilisateur par le biais de ces autorisations d'objet par défaut. Il s'agit notamment des attributs userAccountControl, memberOf et de tous les attributs liés à la connexion, tels que la dernière connexion ou la date du dernier changement de mot de passe. Attention, lorsque vous obtenez un accès en lecture à l'attribut userAccountControl , vous êtes autorisé à déterminer quels utilisateurs ont l'indicateur PasswordNotRequired activé et d'autres informations qui pourraient permettre la découverte d'objets non sécurisés dans votre forêt AD. Les utilisateurs configurés avec l'indicateur PasswordNotRequired peuvent avoir été créés il y a longtemps pour une application quelconque et peuvent réellement ne pas avoir de mot de passe si l'administrateur d'Active Directory a choisi de le configurer de cette manière. En tant que tels, ils constituent un appât facile pour un intrus.
Ainsi, si vous choisissez de conserver les utilisateurs authentifiés dans votre groupe Accès compatible pré-Windows 2000, chaque utilisateur et ordinateur du domaine se voit automatiquement attribuer les autorisations de ce groupe au moment de l'ouverture de session. Avec cette attribution, tout processus - y compris un code malveillant qu'un intrus pourrait exécuter sur un client connecté à un domaine sans utilisateur connecté - est autorisé à énumérer tous les attributs d'utilisateur dans votre domaine.
Alors que les intrus utilisent souvent des outils et des scripts spécifiques pour analyser Active Directory et trouver des vulnérabilités, ne pensez pas que vos utilisateurs normaux auront du mal à faire de même. Même sans droits d'administrateur sur leur client, ils peuvent simplement télécharger la dernière version de Sysinternals AD explorer de Microsoft(https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer) et fouiller joyeusement dans votre forêt Active Directory. Les images suivantes montrent à quel point c'est facile.
Suppression des utilisateurs authentifiés du groupe Pre-Windows 2000 Compatible Access groupe
Cette étape n'est qu'une parmi d'autres pour renforcer la sécurité de votre Active Directory. De nos jours, il n'est plus nécessaire de maintenir la compatibilité avec le modèle de sécurité de Windows NT.
Vos utilisateurs n'ont pas besoin des autorisations accordées par le groupe Pre-Windows 2000 Compatible Access. Ils peuvent toujours se connecter. Les ordinateurs et serveurs reliés à un domaine n'ont pas non plus besoin de ces autorisations ; ils continueront à fonctionner dans votre domaine sans problème. Le traitement de la stratégie de groupe n'est pas non plus affecté par ce changement. Les administrateurs de l'Active Directory n'ont pas non plus besoin de ces autorisations, puisqu'ils bénéficient par ailleurs des mêmes autorisations, voire de davantage d'autorisations.
Néanmoins, la suppression des utilisateurs authentifiés du groupe Pre-Windows 2000 Compatible Access n'est pas une modification que vous pouvez effectuer rapidement dans votre Active Directory un lundi matin. Tout d'abord, testez l'impact potentiel de ce changement dans votre propre environnement. Il se peut que vous utilisiez des outils ou des solutions qui s'attendent à ce que ces autorisations pré-Windows 2000 soient configurées dans votre Active Directory et que vous les utilisiez pour des raisons légitimes.
Exemples de solutions ou de tâches qui utilisent par défaut les autorisations accordées via Utilisateurs authentifiés dans le groupe Accès compatible pré-Windows 2000 :
- Certains outils d'analyse de la sécurité qui ne sont pas exécutés avec un compte privilégié ou qui s'exécutent dans le contexte de sécurité d'une machine peuvent avoir du mal à lire les attributs utilisateur sensibles à la sécurité dont il est question dans cet article. Par conséquent, ces outils peuvent ne pas vous avertir si un utilisateur est configuré avec l'indicateur PasswordNotRequired . Vous pouvez choisir d'ajouter le compte de service utilisé par l'outil ou son compte d'ordinateur au groupe Accès compatible pré-Windows 2000, ou vous pouvez accorder les autorisations nécessaires séparément.
- Méfiez-vous des applications qui se lient à Active Directory via LDAP pour énumérer les membres des groupes pour la sécurité au sein de l'application.
- Si vous utilisez AD Federation Services (ADFS), en fonction de votre configuration, vous pourriez avoir un impact sur l'authentification de WebForms, ce qui pourrait nécessiter des autorisations de lecture dédiées pour vos serveurs ADFS ou l'utilisation du groupe d'accès aux autorisations Windows (WAAG).
- Lorsque vous utilisez l'onglet Accès effectif dans les paramètres de sécurité avancés de vos serveurs de fichiers pour vérifier les droits qu'un utilisateur donné peut avoir sur un dossier, le serveur utilise son compte d'ordinateur pour lire les appartenances de groupe de l'utilisateur. Ce processus échouera après que les Utilisateurs authentifiés auront été supprimés du groupe Accès compatible pré-Windows 2000. La valeur réelle de l'onglet Accès effectif est généralement discutable, car il ne prend pas correctement en compte les groupes imbriqués. Toutefois, si vous souhaitez toujours l'utiliser, vous pouvez à nouveau ajouter vos comptes d'ordinateur de serveur de fichiers au groupe Accès compatible pré-Windows 2000 ou accorder les autorisations de lecture respectives sur les objets utilisateur.
- Le client Ivanti File Director a des problèmes de lecture de homeDirectory et userAccountAttribute. Les utilisateurs ne pourront pas se connecter à ce logiciel à moins que vous n'ajoutiez le compte de service qu'il utilise au groupe Pre-Windows 2000 Compatible Access ou que vous n'accordiez les autorisations appropriées directement sur vos objets utilisateur.
Un avantage supplémentaire de vider votre groupe d'accès compatible pré-Windows 2000 : Vous auriez ainsi été protégé contre la vulnérabilité PrintNightmare avant de patcher vos contrôleurs de domaine avec le correctif critique CVE-2021-1675 de l'été 2021. De même, le fait de vider le groupe vous protégera contre d'autres vulnérabilités "Zero Day" qui utilisent ces autorisations par défaut dans Active Directory.
En tout état de cause, pour un fonctionnement normal et plus sûr de votre Active Directory, il n'est pas nécessaire que les utilisateurs authentifiés soient membres du groupe Pre-Windows 2000 Compatible Access. Il en va de même pour Tout le monde ou pour les Utilisateurs anonymes. Le fait de laisser le groupe vide - ou du moins de ne le peupler que des quelques utilisateurs et ordinateurs qui pourraient en avoir besoin - contribuera certainement à réduire la surface d'attaque de votre Active Directory. Grâce à cette configuration, il est beaucoup plus difficile pour les intrus d'énumérer les comptes faibles et d'extraire d'autres données sensibles de votre AD.
Comment résoudre ce problème dans un environnement étendu ?
Il est facile d'écrire sur la nécessité d'améliorer votre sécurité. Mais modifier l 'appartenance à un groupe par défaut que Microsoft a décidé de laisser en place, même dans la dernière version de son système d'exploitation, peut représenter un véritable défi, en particulier dans les grands environnements.
Comme nous l'avons déjà mentionné, commencez par protéger vos groupes les plus critiques (par exemple, Domain Admin, Enterprise Admin) afin qu'ils ne soient pas lus par tout le monde. En effet, si vous ne le faites pas, il est extrêmement facile pour les intrus de planifier des attaques contre les objets utilisateurs les plus sensibles de votre forêt Active Directory. La meilleure façon de s'acquitter de cette tâche est de mettre à jour le modèle AdminSDholder, qui est utilisé pour mettre à jour les autorisations sur tous ces objets sensibles.
Dans les environnements plus restreints, il est possible de "nettoyer" le groupe d'accès compatible pré-Windows 2000 en l'espace d'un week-end - avec quelques tests initiaux des systèmes de gestion de base pour confirmer que tout fonctionne toujours comme prévu. Mais cette approche peut s'avérer quelque peu décourageante dans les grandes entreprises. Après tout, vous ne voulez pas causer un impact commercial plus important simplement parce que vous avez renforcé la sécurité de votre Active Directory.
Comme pour toute tâche importante, je recommande de diviser le travail. Même si le choix est finalement binaire - les utilisateurs authentifiés font partie ou non du groupe Pre-Windows 2000 Compatible Access - les autorisations de ce groupe sont héritées à différents objets de votre forêt Active Directory à partir de la racine de chaque domaine de cette forêt. Vous avez donc la possibilité de verrouiller des OU individuels en.. :
- Désactivation de l'héritage sur les OU
- Copie de toutes les autorisations existantes
- Supprimer uniquement le groupe Pre-Windows 2000 Compatible Access de l'ensemble des autorisations explicites qui en résulte.
Pour les objets de l'OU concernée, l'effet est le même que si vous aviez supprimé les utilisateurs authentifiés du groupe à la racine du domaine. En d'autres termes, le groupe Pre-Windows 2000 Compatible Access n'a plus d'autorisations sur les objets de l'OU concernée.
Naturellement, vous voudrez tester l'impact de ces changements de permissions avant de les effectuer. Je vous suggère d'enregistrer les permissions actuelles sur toutes les OU que vous souhaitez modifier. Il est utile de disposer d'une solution qui enregistre tous les changements dans votre Active Directory, y compris l'attribut nTsecurityDescriptor, qui stocke essentiellement la permission de l'objet concerné. Il serait encore mieux de disposer d'une solution capable d'annuler ces modifications ! Semperis Directory Service Protector (DSP ) est un outil de ce type, mais vous pouvez également utiliser des scripts accessibles au public et vos propres captures d'écran pour documenter votre travail.
Dans l'idéal, vous disposez de plans de test et de parties prenantes prêtes à valider les applications, les outils et les processus de gestion des utilisateurs et des clients les plus critiques. Vous devrez recueillir des commentaires après avoir modifié les autorisations. L'exécution de vos tests sur les objets de la première OU verrouillée vous donnera des indications sur les problèmes potentiels que vous devez résoudre avant de verrouiller une autre OU, et ainsi de suite.
Finalement, vous serez prêt à supprimer complètement le groupe Utilisateurs authentifiés du groupe Accès compatible pré-Windows 2000. À ce moment-là, veillez à réactiver l'héritage des permissions sur les OU que vous avez utilisées pour les tests. Revenez aux autorisations explicites précédentes qui étaient accordées à ce niveau. L'utilisation d'outils appropriés pour détecter tous les changements dans votre forêt Active Directory réduira également vos efforts au cours de cette étape.
Points clés pour les paramètres d'accès compatibles pré-Windows 2000 dans Windows Server 2025 et antérieurs
Active Directory est plein de champs de mines en matière de sécurité que les cyber-attaquants peuvent exploiter. (Pour identifier les failles de sécurité potentielles dans votre environnement, téléchargez Purple Knightun outil gratuit d'évaluation de la sécurité d'Active Directory qui identifie plus de 100 indicateurs d'exposition ou de compromission et fournit des conseils sur la manière de les traiter). Mais l'adoption de Windows Server 2025 ou Windows Server 2022 ne signifie pas nécessairement que vous abandonniez tous ces paramètres hérités du passé.
Au moins, envisagez de modifier les paramètres de configuration relatifs à la compatibilité avec les systèmes antérieurs à Windows 2000 :
- N'hésitez pas à supprimer Anonymous et Everyone du groupe d'accès compatible pré-Windows 2000 dans chaque domaine de votre forêt AD.
- Faites de même pour les utilisateurs authentifiés, mais soyez conscient de l'impact potentiel et soyez prêt à repeupler le groupe avec des systèmes ou des utilisateurs qui pourraient dépendre des autorisations qui leur sont accordées.
- Supprimez les permissions de lecture par défaut pour les utilisateurs authentifiés des groupes sensibles afin de restreindre les personnes qui peuvent énumérer leurs membres. Consultez mon blog sur la façon de procéder pour les groupes d'administrateurs AD intégrés.
Vous devez décider vous-même si vous souhaitez supprimer le groupe des utilisateurs authentifiés afin d'améliorer la sécurité de votre Active Directory. Vous pouvez choisir d'accepter le risque et de continuer à vivre avec ces anciennes permissions de type Windows NT dans votre Active Directory. Mais ne suivez cette voie qu'après avoir bien compris le danger potentiel.
