Comment durcir Active Directory

Introduction

L'Active Directory (AD) représente la colonne vertébrale des réseaux informatiques pour de nombreuses entreprises. C'est un élément clé de l'infrastructure informatique qui gère les identités, les autorisations et les services liés à la sécurité. Cependant, il est fréquent de constater que l'AD est mal configuré, mal utilisé, ce qui facilite la tâche des personnes malveillantes. Les conséquences d'une attaque peuvent être extrêmement coûteuses et perturbatrices pour une organisation.

Une mauvaise configuration de l'AD peut ouvrir la porte à diverses sources ou origines de compromissions. Parmi celles-ci, on retrouve une mauvaise configuration des paramètres de sécurité, le manque de mises à jour régulières, l'existence de comptes sensibles dotés de privilèges élevés, et bien d'autres facteurs. Il est crucial de prendre en compte ces éléments pour renforcer la sécurité de votre infrastructure.

Il est essentiel de garder à l'esprit que le risque zéro n'existe pas dans le domaine de la sécurité informatique. Toutefois, la mise en place de mesures adéquates et une bonne configuration de l'Active Directory permettront de ralentir les attaquants et de renforcer la résilience de votre système. En suivant les recommandations de ce guide, vous serez en mesure de prendre des mesures préventives efficaces et de protéger votre Active Directory contre les menaces potentielles.

info

Ce document s'adresse à toute personne chargée de la gestion et de la configuration de l'Active Directory au sein d'une entreprise. Que vous soyez administrateur système, responsable de la sécurité ou responsable informatique, ce guide vous accompagnera dans toutes les étapes de configuration de manière simple et compréhensible. Les explications sont appuyées par des captures d'écran pour faciliter la mise en œuvre des recommandations. Dans ce guide, nous utiliserons les zones DNS cyber.local et cyberlab.local pour illustrer les étapes et méthodes de traitement. Vous devrez faire correspondre ces informations avec votre propre contexte d'exécution.

Recommandations générales

Maintenir une bonne hygiène Active Directory

La suppression régulière des sites et des objets d'ordinateur inutilisés est une pratique essentielle pour maintenir une bonne hygiène de l'Active Directory et renforcer la sécurité globale de l'environnement. Les sites inutilisés peuvent être le résultat de restructurations organisationnelles, de fermetures de succursales ou de changements d'infrastructures. En les supprimant, vous réduisez la complexité et le nombre de points d'accès potentiellement vulnérables dans votre réseau.

Déployer un environnement de test

La mise en œuvre temporaire d'un environnement de test et l'acquisition temporaire de compétences spécialisées peuvent faciliter l'adoption de ce guide. Avant toute opération de changement de configuration, de restriction de permissions, ou d'implémentation de nouvelle fonctionnalité, il est vital de s'assurer de disposer d'une sauvegarde saine et dont la restauration est maitrisée.

Les Quick Win

• Sauvegarder le Contrôleur de Domaine;
• Désactiver les services non nécessaires sur sur Contrôleur de Domaine;
• Durcir les réglages du Contrôleur de Domaine;
• Améliorer la politique de mot de passe par défaut;
• Changer le mot de passe du compte KRGTBT;
• Changer le mot de passe du compte DSRM;
• Supprimer les comptes sans pré-authentification;
• Améliorer les règles d'audit.

Sauvegarder les composants d'Active Directory

Contrôleur de Domaine (DC)

Les "Contrôleurs de Domaines" ou "Domain Controller" (DC) gèrent l'authentification dans un réseau. Un DC garde les identifiants dans un fichier DIT et applique une politique de sécurité pour un Domain Windows. Le DC est la clé du royaume, il est donc crucial de réaliser des sauvegardes et de les stocker de manière sécurisée. Il existe plusieurs façons et fournisseurs pour le faire, Windows Server Backup (Sauvegarde Windows Server) est la solution fournie avec Windows.

Étapes :

• Se connecter au DC et lancer le PowerShell avec les droits administrateurs;

• Importer depuis le PowerShell le module ServerManager;

• Installer la fonctionnalité Windows-ServerBackup;

  Import-Module ServerManager 
  Install-WindowsFeature Windows-Server-Backup

  

• Vérifier que Windows Server Backup est installé.

  Get-WindowsFeature | where {$_.Name -eq "Windows-Server-Backup"}

  

Utiliser Windows Server Backup pour créer des sauvegardes. Il existe deux sortes de sauvegardes : « Backup Schedule » et « Backup Once ».

Ici nous allons faire une sauvegarde programmée « Backup Schedule ».

• Ouvrir Sauvegarde Windows Server (Windows Server Backup);

• Cliquer sur Planification de sauvegarde puis sur Suivant;

  

• Cliquer sur Personnalisé;

  

• Cliquer sur Suivant puis cliquer sur "Ajouter des éléments";

  

• Sélectionner "État du système" puis sur Suivant;

• Choisir la fréquence d’exécution des sauvegardes. Ici la fréquence par défaut est gardée;

  

• Cliquer sur Suivant puis sélectionner l'emplacement de stockage des sauvegardes;

• Cliquer sur Suivant puis sélectionner le disque où stocker les sauvegardes (ajouter le volume s'il n'apparaît pas dans la liste);

  

• Cliquer sur Suivant, puis Terminer.

Une tâche programmée va être créée sous le nom "Microsoft-Windows-Backup".

Une fois la sauvegarde terminée, un message s’affiche dans l’interface graphique :

Tous les évènements concernant les sauvegardes se trouvent dans le dossier Microsoft\Windows\Backup\Operational, et l’évènement sous l’ID 14 indique qu’une sauvegarde est terminée.

Cliquer ici pour auditer la sauvegarde de Contrôleur de Domaine

DHCP (Dynamic Host Configuration Protocol)

Pour comprendre les fonctionnalités de base : Déployer et gérer le protocole DHCP - Training | Microsoft Learn

Un serveur DHCP est un serveur (réseau) qui fournit et attribue automatiquement des adresses IP aux périphériques clients, mais pas seulement des adresses IP. Il attribue également les passerelles par défaut et d'autres paramètres réseau. DHCP est une partie cruciale, car il permet aux appareils de participer à un réseau en allouant des adresses IP aux clients. Il vérifie auprès de l'Active Directory (AD) pour vérifier s'il est autorisé à attribuer des adresses IP en location.

Étapes :

• Se connecter au serveur DHCP et lancer le PowerShell avec des droits élevés;
• Faire une sauvegarde de la configuration DHCP sur une destination externalisée au DHCP. Le fichier DhcpCfg est le fichier de configuration du DHCP.

Backup-DhcpServer -ComputerName "Cyberlab-dc01" -Path "C:\Temp"

Cliquer ici pour auditer la sauvegarde du serveur DHCP

Service DNS (Domain Name System)

Le service DNS est une méthode de résolution permettant de traduire les noms d'hôtes en adresses IP. Le fonctionnement d'Active Directory dépend du service DNS. Il maintient une base de données de la résolution de nom des actifs en cours d'exécution sur un réseau. La liste des services en cours d'exécution est gérée sous forme d'enregistrements (A, CNAME, etc...). Les enregistrements de service permettent à un client dans un environnement Active Directory de localiser un service, comme par exemple le serveur de fichiers. Le service DNS est une partie cruciale à prendre en compte dans le plan de sauvegarde également.

Étapes :

• Se connecter Contrôleur de Domaine et lancer le PowerShell avec des droits élevés;

• Ouvrir le Gestionnaire DNS pour trouver les zones de recherches directes;

  

• Exporter les zones DNS présentes sur le serveur. Ici "_msdcs.cyberlab.local" et "cyber.local" sont les nom de la zone DNS;

  Dnscmd /zoneexport _msdcs.cyberlab.local _msdcs.cyberlabl.local.txt
  Dnscmd /zoneexport cyberlab.local cyberlab.local.txt

  

  Toute la configuration du DNS est maintenant stockée dans C:\Windows\system32\dns. Il est important de s'assurer que le fichier soitbien stocké à cet endroit pour le bon déroulement de la restauration de cette sauvegarde.

• Faire des sauvegardes hors ligne du DNS.

  Il suffit, après avoir effectué la sauvegarde du DNS, d'enregistrer sur une sauvegarde hors ligne les ficher .txt entourés en rouge, cela se fait donc rapidement.

  

Cliquer ici pour auditer la sauvegarde du DNS

Infrastructure de Clés Publiques sur Active Directory Certificate Services

Cliquer ici pour voir sur le site de Microsoft comment configurer une Infrastructure de Clés Publiques

L'Infrastructure de Clés Publiques (ou PKI pour Public Key Infrastructure en anglais) dans Active Directory est une infrastructure de sécurité essentielle qui gère les certificats numériques. Ces certificats contiennent une paire de clés : une clé publique et une clé privée. Lorsqu'un utilisateur ou un ordinateur souhaite accéder à des ressources sur le réseau, il utilise son certificat pour prouver son identité. De plus, la PKI facilite le chiffrement des données, permettant ainsi de sécuriser les communications entre les différentes entités du réseau. En utilisant les certificats et les clés, Active Directory assure l'authentification des utilisateurs et le chiffrement des données, contribuant ainsi à renforcer la sécurité globale du réseau et à protéger les informations sensibles des accès non autorisés.

Les autorités de certifications sont importantes, mais dépendent de la fonction des PKI. La plupart du temps il s'agit de protéger la donnée du client.

Étapes :

• Se connecter au serveur et ouvrir l'Autorité de Certification (Certificate Authority)

• Faire une sauvegarde de l'Autorité de Certification en sélectionnant bien ces deux cases.

  

• Choisir un endroit de stockage pour la sauvegarde.

• Choisir un mot de passe fort et cliquer sur Suivant

• La configuration du CA doit être enregistrée également, on la trouve sous HKLM\System\CurrentControlSet\Services\CertSVc\Configuration\

• Stocker le tout dans le dossier C:\Temp

La configuration de l'Autorité de Certification est maintenant sauvegardée.

Cliquer ici pour auditer la sauvegarde de la PKI

Auditer les sauvegardes des composants d'Active Directory

Le Contrôleur de Domaine (DC)

Avant d'effectuer cette étape, s'assurer d'avoir au préalable fait une sauvegarde du Contrôleur de Domaine

La procédure décrite ci-dessous est destinée à faire un test de restauration uniquement. Il faut réaliser cette procédure sur un environnement virtuel pour ne pas engendrer de dégâts sur le réseau de l'entreprise.

• Auditer la dernière sauvegarde du DC

  Windows Server Backup fournit des informations sur les sauvegardes, par exemple, si une sauvegarde a réussi ou échoué. Êtes-vous informé lorsque la sauvegarde échoue ?

  

  S'assurer d'avoir également une sauvegarde qui est stockée hors ligne et de surveiller les évènements concernant les sauvegardes. Tous les évènements se trouvent sous Microsoft-Windows-Backup\Operational

  Event ID	Description
  4	L'opération de sauvegarde s'est terminée avec succès.
  5	L'opération de sauvegarde qui a débuté à ... a échoué

• Restaurer des sauvegardes du DC

  • S'assurer d'avoir un plan de restauration en place pour restaurer Active Directory en cas de besoin (à mettre en place selon la taille de l'entreprise)
  • Utiliser le mode de restauration des services d'annuaire (DSRM) comme compte de secours pour les contrôleurs de domaine.
  • Stocker les informations d'identification de DSRM de manière sécurisée et n'accéder à celles-ci qu'avec les personnes autorisées.
  • Maintenir des sauvegardes hors ligne d'AD / DC opérationnelles en tout temps pour pouvoir les restaurer rapidement.
  • Pratiquer régulièrement le plan de restauration dans un environnement de test, tel qu'Azure, afin que vous et votre équipe se familiarise avec le processus et éviter les difficultés lors d'une véritable restauration.

Le DHCP (Dynamic Host Configuration Protocol)

Avant d'effectuer cette étape, s'assurer d'avoir au préalable fait une sauvegardé du serveur DHCP sur une destination externalisée au serveur DHCP.

La procédure décrite ci-dessous est destinée à faire un test de restauration uniquement. Il faut réaliser cette procédure sur un environnement virtuel pour ne pas engendrer de dégâts sur le réseau de l'entreprise.

• Restaurer la configuration à l'aide de la commande suivante
• Il est nécessaire de redémarrer le serveur DHCP

Restore-DhcpServer -ComputerName "Cyberlab-dc01" -Path "C:\Temp"
Restart-service dhcpserver

La sauvegarde est maintenant restaurée.

DNS (Domain Name System)

Avant d'effectuer cette étape, s'assurer d'avoir au préalable sauvegardé le DNS.

La procédure décrite ci-dessous est destinée à faire un test de restauration uniquement. Il faut réaliser cette procédure sur un environnement virtuel pour ne pas engendrer de dégâts sur le réseau de l'entreprise.

• Supprimer le fichier cyberlab.local

• Créer une nouvelle Zone de Recherche Directe et décocher la case suivante

• Taper "cyberlab.local" pour le nom de zone

• Sélectionner "utiliser un fichier existant et taper : "cyberlab.local". Cela permet d'utiliser le fichier que nous avons sauvegardé plus tôt. (utiliser les mises à jour dynamique ?) + insérer un lien

  

• Cliquer sur suivant et terminer

Tout a été restauré

PKI (Public Key Infrastructure)

Avant d'effectuer cette étape, s'assurer d'avoir fait au préalable une sauvegarde de l'Infrastructure de Clés Publiques.

La procédure décrite ci-dessous est destinée à faire un test de restauration uniquement. Il faut réaliser cette procédure sur un environnement virtuel pour ne pas engendrer de dégâts sur le réseau de l'entreprise.

• Ici nous restaurons ce qui a été sauvegardé plus haut (Certificats d'Autorité). Il se peut que les éléments ne se trouvent pas dans le dossier "C:\Temp" de votre côté.

  

• Taper le mot de passe choisi plus tôt pour les sauvegardes. Cliquer sur Suivant et Terminer.

La PKI est désormais bien restaurée.

Gestion des Liste de Contrôle d'Accès (ACL)

Exécution périodique des analyses ACL

Un ancien PFE (Premier Field Engineer) de Microsoft a développé un outil puissant pour analyser les ACL dans un environnement. Les ACL sont souvent configurées par les administrateurs pour des tâches temporaires, mais elles restent souvent en place pendant des années, ce qui crée des risques d'escalade pour les attaquants. Il existe plusieurs outils en ligne utilisés par les attaquants pour mapper un environnement et découvrir des chemins d'escalade via les ACL. Cet outil peut être utilisé par des utilisateurs non administrateurs.

Pour commencer, utiliser AD ACL Scanner pour obtenir un aperçu des ACL dans l'environnement. Télécharger AD ACL Scanner

Étapes :

• Lancer des scans ACL sur des objets dans AD. Sur cette capture, un scan ACL est en cours sur l'Objet de Domaine (Domain Naming Context)

  Une fois le scan terminé, un rapport affiche toutes les ACL effectuées sur le Domain Object

  

• Lancer un scan notamment sur une OU (Organizational Unit), par exemple sur l'OU "Utilisateurs".

  

  Les résultats peuvent être exportés au format CSV. Il est recommandé de lancer des scans régulièrement pour trouver de potentielles mauvaises configurations.

• Connaître les permissions et comment elles peuvent être instrumentalisées par un attaquant (voir tableau page 37 du doc --> à revoir)

Gérer les ACL définies sur les OU du Contrôleur de Domaine.

Les ACL qui ont été définies sur l'unité d'organisation (OU) des contrôleurs de domaine (DC) représentent un risque, car si un attaquant parvient à lier une Group Policy Object (GPO) arbitraire ou à la désactiver, cela peut affaiblir la sécurité des contrôleurs de domaine.

Voici un exemple : John Doe dispose des permissions "Écrire toutes les propriétés" sur l'OU des contrôleurs de domaine. Paul West peut désactiver les GPO liées à l'OU des contrôleurs de domaine afin de diminuer la sécurité des DC.

Il est conseillé de pas déléguer de permissions sur l'OU des contrôleurs de domaine et de vérifier si des permissions ont été déléguées sur l'OU des contrôleurs de domaine et les supprimer dès que possible.

Pour accéder à cette vue des accès effectifs, réaliser les étapes suivantes :

• A partir du Gestionnaire de serveur, ouvrir le Gestionnaire de Stratégie de groupe

• Ouvrir les paramètres avancés de la politique par défaut du Contrôleur de Domaine

  

• Ouvrir les autorisations spéciales et paramètres avancés. Cliquer sur accès effectifs et sélectionner un utilisateur.

  

Gérer les ACL définies sur les Computer Objects

Les utilisateurs disposant de droits "GenericAll" ou équivalents sur les Computer Objects peuvent effectuer une attaque de délégation de contraintes pour exécuter du code sur le contrôleur de domaine. Si un utilisateur dispose des droits pour écrire la propriété "ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity" sur le Computer Object du contrôleur de domaine, il peut agir au nom de ce service, qui est le contrôleur de domaine dans cet exemple. Cela donne à un attaquant la possibilité de se déplacer latéralement vers le contrôleur de domaine et d'exécuter du code.

Voici un exemple où un utilisateur dispose des permissions "Contrôle total" sur l'objet informatique du contrôleur de domaine. Les attaquants peuvent maintenant exécuter du code sur le contrôleur de domaine dans ce cas-là.

• Vérifier toutes les ACL qui ont été définies sur tous les objets informatiques des contrôleurs de domaine et supprimer les permissions non nécessaires comme sur la capture d'écran. Il n'est pas nécessaire de déléguer des permissions sur les Computer Objects.

  

Gérer les ACL des membres du "Domain Admins" ou équivalent

Des permissions mal déléguées sur des utilisateurs faisant partie des administrateurs de domaine représentent un risque considérable, car cela signifie que certains utilisateurs ou groupes pourraient être en mesure de prendre le contrôle d'un compte et de devenir administrateur de domaine.

• Pour savoir qui fait partie de ce groupe, il suffit de taper dans PowerShell :

Get-ADGroupMember -Identity "Domain Admins"

Dans cet exemple, trois utilisateurs font partie du Domain Admins.

Mais si l'on regarde les ACL pour Sam Hawk, on remarque que le groupe "Ingénieurs" a le contrôle total sur son compte. Un membre de ce groupe pourrait s'emparer de son compte en réinitialisant son mot de passe.

• Supprimer les permissions déléguées définies sur les utilisateurs du groupe "Administrateurs", "Domain Admins" "Enterprise Admins" etc.

Gérer les ACL qui ont été définies Domain Admins ou équivalent

AD ACL Scanner peut bien sûr automatiser cela, mais pour une vérification rapide, il suffit de regarder quel type d'ACL a été défini sur des groupes tels que Administrateurs, Domain Admins et Enterprise Admins. Si une ACL a été déléguée à l'un de ces groupes, cela crée des chemins d'escalade pour les attaquants afin d'obtenir des privilèges élevés, par exemple en devenant administrateur de domaine.

Voici un exemple où les utilisateurs du domaine ont les permissions "Ecrire (toutes les propriétés)" sur le groupe Domain Admins, ce qui permet à n'importe qui de se donner le statut d'administrateur de domaine. Supprimer les utilisateurs ou groupes délégués des groupes Administrateurs, Domain Admins, Enterprise Admins et équivalents. Ce sont différents chemins d'escalade vers l'administrateur de domaine.

Gérer les ACL qui ont été définies sur le DNS Object

Par défaut, les contrôleurs de domaine sont des serveurs DNS. Des chercheurs en sécurité ont découvert un moyen d'exécuter une DLL en tant que SYSTEM sur le contrôleur de domaine pour escalader les privilèges vers un administrateur de domaine. Étant donné que DnsAdmins a par défaut les permissions "Full Control" sur l'objet DNS, tout membre du groupe DnsAdmins peut devenir administrateur de domaine.

Voici un exemple où le groupe "Human Ressources" dispose des permissions "Ecrire (toutes les propriétés)" sur l'objet DNS, ce qui permet à tous les membres du groupe des ressources humaines d'exécuter une DLL en tant que SYSTEM sur le contrôleur de domaine et d'escalader leurs privilèges vers un administrateur de domaine.

Les utilisateurs ou groupes avec les permissions "Contrôle total" ou "Écrire toutes les propriétés" sont inutiles, car personne n'a besoin d'autant de droits. Les permissions de lecture sur l'objet DNS sont suffisantes pour créer des enregistrements DNS, car les utilisateurs authentifiés disposent de la permission "Créer tous les objets enfants" sur la zone de recherche directe.

• Supprimer les utilisateurs ou groupes auxquels des permissions "Contrôle total" ou "Ecrire toutes les propriétés" ont été déléguées sur l'objet DNS.

Gérer les ACL des GPO (Group Policy Object) liées aux DC

Les GPO qui sont liées au contrôleur de domaine contiennent différents paramètres. Toutes les GPO liées au contrôleur de domaine doivent être gérées depuis un niveau de sécurité Tier 0. Ne déléguez pas de permissions sur ces GPO, car toute personne pouvant les modifier peut devenir administrateur de domaine.

Voici un exemple où une GPO appelée ''Group Policy 3'' est liée à l'OU des contrôleurs de domaine, mais des permissions ont été déléguées. Le groupe "Domain Admins" dispose de tous les droits et John Doe peut modifier la GPO, ce qui signifie que tous les membres de du groupe et Paul peuvent devenir administrateurs de domaine.

• Révoquer les permissions déléguées sur les GPO liées au contrôleur de domaine. Toutes ces GPO doivent être gérées depuis un niveau de sécurité Tier 0.

Voir comment déployer un modèle de sécurité par Tier.

Gérer les ACL qui ont été définies sur le Domain Object

Déléguer des droits sur l'objet de domaine n'est pas quelque chose que vous devriez envisager, car cela crée différents chemins d'escalade vers l'administrateur de domaine. Les utilisateurs disposant de droits "GenericAll" ou équivalents peuvent répliquer des informations sensibles à partir du contrôleur de domaine et obtenir les identifiants de chaque utilisateur dans AD, y compris le compte Administrateur.

Voici un exemple que de nombreuses organisations ont dans leur environnement : les groupes Exchange par défaut avec des permissions étendues dans AD. Ce groupe, également connu sous le nom de "Exchange Trusted Subsystem", dispose du droit de "Modification" sur l'objet de domaine et est membre du groupe "Exchange Windows Permissions".

Étapes :

• "Exchange Trusted Subsystem" et "Exchange Windows Permissions" n'ont pas besoin d'avoir des permissions de modification sur l'objet de domaine.
• Si la permission de modification du groupe Exchange Trusted Subsystem est supprimée, une petite fonctionnalité se brisera dans la console de gestion Exchange, qui consiste à attribuer des permissions de "Send as" aux utilisateurs. Cela peut être délégué pour résoudre le problème.
• Vérifier si d'autres utilisateurs et groupes ont été délégués sur l'objet de domaine et essayer de voir s'il est possible de les supprimer et de trouver d'autres solutions

Tips : Exécuter BloodHound pour trouver des chemins d'escalade

L'outil BloodHound trouve tous les chemins d'ACL/ACE plus rapidement qu'en les recherchant manuellement, et il est probable qu'il découvre encore plus de chemins d'escalade. C'est un excellent outil pour découvrir les permissions mal déléguées dans Active Directory.

BloodHound est disponible ici : GitHub - BloodHoundAD/BloodHound: Six Degrees of Domain Admin

Politiques de mot de passe

Comptes de service

Les comptes de services sont généralement utilisés pour fournir des identifiants et des permissions à un service installé sur une machine. Les comptes de service ont souvent des mots de passe faibles, ce qui augmente les chances que les attaquants ciblent ces comptes. Les comptes de service sont rarement modifiés, mais il est important de veiller à ce que ces comptes disposent d'un mot de passe fort.

Voici un exemple de quelques comptes de service SQL. Tous ces comptes de service font partie du groupe des comptes de service SQL. Il est recommandé d'exiger des mots de passe forts pour les comptes de service.

Étapes :

• Mettre en place des comptes de service qui ont un mot de passe de 20 caractères minimum

  • Ouvrir le centre d'administration Active Directory depuis le tableau de bord.

  • Cliquer sur "cyberlab (local)"

  • Cliquer sur "System"

  • Cliquer sur "Password settings Container"

  • Cliquer sur "New"

  • Configurer les paramètres de mot de passe en remplaçant l'exemple de John Doe par le groupe des comptes de service SQL ("SQL Service accounts")

    

    Remplacer ici John Doe par le groupe "Comptes SQL"

    Désormais lorsqu'un compte de service membre du groupe "SQL Accounts" change son mot de passe, il sera refusé s'il est trop faible. Les paramètres de mot de passe s'appliquent sur tous les comptes membres de ce groupe.

    

Administrateurs IT

Les utilisateurs ayant des privilèges élevés dans un réseau Windows, généralement les administrateurs informatiques, doivent également avoir un mot de passe fort. Il est judicieux de créer une politique de mots de passe pour ces comptes, avec une longueur minimale de 16 caractères.

Dans cet exemple, deux membres du "groupe ingénieurs"" ont accès à de nombreux systèmes du réseau, il s'agit de s'assurer qu'ils disposent d'un mot de passe solide.

Étapes :

• Mettre en place une politique de mot de passe rigoureuse pour les administrateurs IT

  

Améliorer la politique de mot de passe par défaut

La politique de mot de passe par défaut dans AD impose une chaîne de minimale de 8 caractères, ce qui rend la tâche plus facile pour des attaquants. Il vous revient de mettre en place une politique de mot de passe plus forte (12 caractères minimum).

• Exécuter cette commande pour voir la politique de mot de passe actuelle

net accounts /domain

Changer le mot de passe du compte KRBTGT

• Exécuter cette commande pour constater la dernière modification du mot de passe du compte krbtgt

  get-aduser krbtgt -properties passwordlastset

Changer le mot de passe du compte DSRM

DSRM (Directory Services Restore Mode) est un compte "brise glace" pour les contrôleurs de domaine. DSRM est similaire à un compte "Administrateur local" sur un contrôleur de domaine. Le mot de passe du compte DSRM est rarement modifié, mais il est recommandé de le faire régulièrement pour des raisons de sécurité.

Étapes :

• Se connecter au Contrôleur de Domaine.

• Lancer l'invite de commande avec des droits élevés.

• Exécuter la commande ntdsutil puis rentrer les paramètres suivants.

  ntdsutil

  set DSRM password
  reset password on server DC # DC est le nom du contrôleur de domaine
  <New password>
  <Re type the New Password>
  Quit
  Quit

  

• Mettre en place une procédure pour le remplacement du mot de passe du compte DSRM. Il est recommandé de le changer tous les 6 mois, et tous les ans au minimum. Il s'agit également de stocker ce mot de passe de manière sécurisée et de limiter le nombre de personnes y ayant accès : un gestionnaire de mots de passe serait bienvenu. Enfin, l'évènement 4794 est notifié lorsque quelqu'un change le mot de passe du compte DSRM.

  

Configurations faibles ou mal sécurisées

Comptes sous SPN (Service Principal Name)

Les comptes sous SPN et qui sont membres du groupe Domain Admins ou équivalent sont facteurs de risques. Tout attaquant est capable de récupérer un ticket d'authentification de ce compte et de le craquer hors ligne. Ces comptes de service sont partout, il est difficile de détailler quels groupes surveiller en particulier, cela dépend en partie de la configuration propre à l'entreprise.

Étapes :

• Commencer par chercher les comptes sous SPN dans des groupes tels que "Administrateurs", "Domain Admins", "Enterprise Admins", "Account Operators" etc.

  

  Les comptes de service sont rarement changés, ce n'est pas une surprise si un attaquant est capable de cracker le mot de passe facilement.

• Les comptes avec un SPN ne doivent jamais faire partie du groupe des administrateurs de domaine. Les fournisseurs le demandent souvent, mais ce n'est pas toujours nécessaire. Il n'y a aucune raison d'accorder à quelqu'un des droits d'administrateur de domaine. Contacter le fournisseur pour comprendre les droits dont il a besoin. Ne pas accepter d'accepter les demandes des fournisseurs qui nécessitent des droits d'administrateurs de domaine.

  Les administrateurs de domaine sont uniquement nécessaires pour les tâches suivantes :

  • Augmenter le niveau fonctionnel du domaine
  • Promouvoir un contrôleur de domaine

  Tous les autres droits peuvent être délégués.

Comptes sans pré-authentification

Lorsque la pré-authentification est désactivée, toute personne sur le réseau peut demander des données d'authentification, ce qui amène le KDC (Key Distribution Center) à renvoyer un TGT (Ticket-Granting Ticket) chiffré, qui peut être cracké hors ligne. Généralement, cette fonctionnalité est activée pour les comptes de service par souci de compatibilité.

Voici un exemple où l'on peut voir qu'un compte a la pré-authentification désactivée :

Étapes :

• La première étape consiste à obtenir (grâce à cette commande) un aperçu de tous les comptes ayant la pré-authentification désactivée.

  Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties UserAccountControl

  

• La deuxième partie consiste à vérifier si ces comptes sont toujours utilisés. Si des comptes inutilisés sont découverts :

  • Désactiver les comptes inutilisés
  • Laisser un délai d'observation de 30 jours
  • Supprimer les comptes

Cette configuration est généralement définie sur des comptes de service, mais si la pré-authentification est désactivée sur un compte utilisateur régulier, il s'agit d'une vulnérabilité à identifier et réparer.

Serveurs avec délégation non contrainte

La délégation non contrainte permet à un service d'usurper l'identité d'un utilisateur vis-à-vis de tous les autres services Kerberos du réseau.

Le risque associé à la délégation non contrainte est que lorsqu'un utilisateur se connecte à un serveur avec une délégation non contrainte, un TGT (Ticket-Granting Ticket) de l'utilisateur est attaché au TGS (Ticket-Granting Service) pour représenter cet utilisateur ultérieurement auprès du service. Ainsi, lorsque l'utilisateur accède au serveur, le TGT est extrait en mémoire et le service est capable d'usurper l'identité de l'utilisateur vis-à-vis de tous les services Kerberos.

Il s'agit d'un risque sérieux et Microsoft recommande de ne jamais utiliser ce type de configuration.

• Pour trouver les serveurs avec une délégation non contrainte, utiliser la commande suivante :

Get-ADObject -filter { (UserAccountControl -BAND 0x0080000) -OR (UserAccountControl -BAND 0x1000000) -OR (msDS-AllowedToDelegateTo -like '*') } -Properties Name,ObjectClass,PrimaryGroupID,UserAccountControl,ServicePrincipalName,msDS-AllowedToDelegateTo

Étapes :

• Les administrateurs de niveau Tier 0 doivent faire partie du groupe "Protected Users" dans l'AD et la case à cocher "Le compte est sensible et ne peut pas être délégué" doit être activée . Cliquer ici pour en savoir plus sur la sécurisation des administrateurs Tier 0.
• Limiter et surveiller le groupe local des administrateurs sur les serveurs avec délégation non contrainte.
• Dans la mesure du possible, limiter autant que possible les connexions aux serveurs avec délégation non contrainte.
• Bloquer l'accès à Internet sur les serveurs avec délégation non contrainte.

Les bonnes pratiques

Déployer un modèle par "Tier"

Microsoft a développé un modèle appelé "Administrative Tier Model" ou "Modèle de niveau d'administration" qui constitue une excellente façon de limiter le vol d'informations d'identification.

Ce modèle permet uniquement aux administrateurs de domaine, également appelés administrateurs de niveau 0 (Tier 0), de se connecter aux serveurs critiques (serveurs de niveau 0) tels que les contrôleurs de domaine, Azure AD Connect, Active Directory Federation Services (ADFS), Public Key Infrastructure (PKI), Network Protection Server (NPS).

Le modèle "Administrative Tier" se compose de trois niveaux : Tier 0, Tier 1 et Tier 2.

• Le Tier 0 comprend des serveurs tels que les contrôleurs de domaine, Azure AD Connect, ADFS, PKI, etc. Les administrateurs de domaine ou équivalents sont généralement ceux qui gèrent ces serveurs.
• Le Tier 1 comprend des serveurs importants, mais non critiques. Quelques exemples sont les serveurs SQL, les serveurs de fichiers, les serveurs d'impression, etc. Les administrateurs de serveurs sont généralement responsables de ce niveau.
• Le Tier 2 comprend les postes de travail. Les administrateurs de postes de travail, souvent le service d'assistance, s'occupent de ces postes. Ils aident à résoudre les problèmes lorsqu'un utilisateur contact le support informatique.

Chaque niveau d'administrateurs peut uniquement se connecter à sa propre "zone de niveau" ou Tier. Par exemple, les administrateurs de niveau 0 ne peuvent pas se connecter aux serveurs de niveau 1 ni aux postes de travail de niveau 2, et vice versa.

Pour en savoir plus voici le lien de la documentation officielle de Microsoft : Sécurisation de l’accès privilégié - Modèle d’accès d’entreprise | Microsoft Learn

Déployer un tel modèle peut s'avérer fastidieux car il faut le tester et le planifier, mais il n'en demeure pas moins efficace.

Étapes :

• Créer des Unités d'Organisations (Organizational Unit) avec les bons objets et utiliser la politique du groupe pour refuser l'accès

  Dans cet exemple, les administrateurs Tier 0 n'ont pas le droit d'accéder aux Tier 1 et 2, une politique de groupe doit être mise en place pour refuser l'accès par "Logon"

  

• Définir quels actifs appartiennent au Tier 0. Déterminer quels actifs appartiennent au Tier 0 a souvent été source de confusion. Les gens pensent généralement qu'il s'agit uniquement des contrôleurs de domaine, mais c'est une erreur. Les serveurs de Tier 0 sont les serveurs les plus critiques au sein d'une organisation. Si l'un de ces serveurs était compromis, cela aurait immédiatement un impact sur l'activité.

  Voici quelques exemples de serveurs qui doivent être gérés en tant que Tier 0 :

  • Contrôleurs de domaine;
  • Azure AD Connect;
  • ADFS (Active Directory Federation Services);
  • PKI (Infrastructure à clé publique).

  Il est fort probable que ces serveurs ne soient pas les seuls, car vous pourriez avoir d'autres serveurs critiques. Par conséquent, il est nécessaire d'effectuer une évaluation des risques pour déterminer si d'autres serveurs doivent être gérés en tant que Tier 0. Un exemple simple consiste à se poser la question suivante : "Si le serveur X tombe en panne, l'activité peut-elle continuer ?"

  Serveur	Description	Impact sur le Business
  Contrôleur de Domaine	Gère l'authentification des utilisateurs dans un réseau Windows	Grosses difficultés si plusieurs DC tombent en panne
  Azure AD Connect	Synchronise les mots de passe dans Azure	Un attaquant peut facilement escalader jusque AAD pour contrôler le domaine

• Gérer les GPO sous un modèle par Tier

  Les GPO qui sont liées aux actifs de Tier 0 doivent également être gérées par les administrateurs de Tier 0, sinon il pourrait y avoir une élévation potentielle de privilèges. Il est très courant de constater que les organisations ont mises en place un modèle d'administration par niveaux, mais il peut y avoir des erreurs de configuration qui permettent à quelqu'un du Tier 1 de faire une élévation de privilèges vers un actif de Tier 0.

  Voici un exemple où une reconfiguration serait nécessaire :

  

  Voici tous les éléments qui sont du ressort d'un Admin de Tier 0 :

  • Politique de Domaine;
  • Contrôleur de Domaines;
  • Tier 0 Servers;
  • Tier 0 Devices.

Sécuriser les administrateurs Tier 0

Cliquer ici pour voir comment déployer un modèle par Tier

Protected Users est un groupe qui a été introduit dans Windows Server 2012 R2. L'idée principale derrière les Protected Users est de prévenir l'abus des informations d'identification lors de la connexion.

• Une bonne pratique consiste à ajouter les administrateurs Tier 0 qui gèrent les serveurs critiques tels que les contrôleurs de domaine, Azure AD Connect, ADFS, etc. dans le groupe Protected Users de l'Active Directory.

• S'assurer que les administrateurs Tier 0 ont la case suivante cochée :

Sécuriser le DC

Sauvegarde et restauration

Le Contrôleur de Domaine est l'élément central de l'Active Directory. Il est donc primordial d'effectuer des sauvegardes (en ligne et hors ligne) de celui-ci, pour pouvoir réagir rapidement et limiter les dégâts en cas de problème.

Cliquer ici pour voir comment sauvegarder le Contrôleur de Domaine et auditer cette sauvegarde

Configuration

• Durcir les réglages pour les Contrôleur de Domaine

  Les paramètres par défaut des Contrôleurs de Domaine ne sont pas très bons. Chaque Contrôleur de Domaine dispose par défaut de la ''Default Domain Controller Policy'' en place, mais cette GPO crée différents chemins d'escalade vers le rôle d'administrateur de domaine. Si vous avez des membres dans les groupes "Opérateurs de sauvegarde" ou "Opérateurs de Serveur"par exemple, ils peuvent devenir Administrateurs de domaine.

  

  Commencer par remplacer la politique du Contrôleur de Domaine par défaut par une nouvelle GPO axée sur la sécurité.

  • Droits d'utilisateurs

    Stratégie	Paramètre de sécurité
    Accéder à cet ordinateur à partir du réseau	Administrateurs, Utilisateurs authentifiés, Contrôleur de Domaine d'entreprise
    Ajouter des stations de travail au domaine	Administrateurs
    Permettre l'ouverture d'une session locale	Administrateurs, Opérateurs de sauvegarde
    Sauvegarder les fichiers et les répertoires	Administrateurs, Opérateurs de sauvegarde
    Modifier l'heure système	Local Service, Administrateurs
    Déboguer les programmes	Administrateurs
    Interdire l'accès à cet ordinateur à partir du réseau	Invité
    Interdire l'ouverture de session par les services Bureau à distance	Invité
    Permettre à l’ordinateur et aux comptes d’utilisateurs d’être approuvés pour la délégation	Administrateurs
    Forcer l’arrêt à partir d’un système distant	Administrateurs
    Charger et décharger les pilotes de périphériques	Administrateurs
    Restaurer les fichiers et les répertoires	Administrateurs, Opérateurs de sauvegarde
    Arrêter le système	Administrateurs
    Prendre possession de fichiers ou d’autres objets	Administrateurs

    Note : supprimer les Opérateurs de Sauvegarde s'ils ne sont pas utilisés.

  • Options de sécurité

    

    Stratégie	Paramètre de sécurité
    Appareils : empêcher les utilisateurs d’installer des pilotes d’imprimante	Activé
    Contrôleur de domaine : permettre aux opérateurs du serveur de planifier des tâches	Activé
    Accès réseau : ne pas autoriser l’énumération anonyme des comptes SAM	Activé
    Accès réseau : ne pas autoriser l’énumération anonyme des comptes et partages SAM	Activé
    Sécurité réseau : niveau d’authentification LAN Manager	Envoyer des réponses NTLMv2 uniquement. Refuser LM & NTLM

    La dernière ligne requiert une attention plus particulière, cela doit être bien  testé avant d'être mis en production.

    Deux réglages NTLM doivent être activés pour traquer l'usage de NTLM :

    Stratégie	Paramètre de sécurité
    Sécurité réseau : restreindre NTLM : auditer le trafic NTLM entrant	Activer l’audit pour les comptes de domaine
    Sécurité réseau : restreindre NTLM : auditer l’authentification NTLM dans ce domaine	Activer tout

    L'évènement 4624 avec des champs de données tels que "Authentication Package" et "Package name (NTLM only)" doit être filtré.

    Si vous voyez quelque chose comme NTLMV1 dans le champ "Package Name", cela indique qu'une application utilise encore NTLMv1. Désactiver immédiatement NTLM peut entraîner une interruption de l'application. Il est conseiller de tester ceci dans un environnement virtuel par exemple.

• Désactiver les services non nécessaires sur le Contrôleur de Domaine

  Par défaut, il existe des services inutiles activés sur un contrôleur de domaine. Il est recommandé de désactiver les services inutiles pour améliorer les performances d'un contrôleur de domaine. ll existe même un service activé par défaut sur un contrôleur de domaine qui peut être utilisé comme une voie d'escalade pour compromettre Active Directory. Si les services suivants sont présents sur votre version de Windows Server, les désactiver.

  Réglage	Statut
  Xbox Live Auth Manager	Désactivé
  Xbox Live Game Save	Désactivé
  Spouleur d'impression	Désactivé

  

Évènements à surveiller

Voici les journaux d'évènements pertinents à surveiller sur le contrôleur de domaine. Il n'est pas nécessaire de filtrer quoi que ce soit, il suffit de surveiller l'ID d'évènement lui-même.

Evènement	Description
1100	Service du journal des évènements arrêté
1102	Le journal d'audit a été effacé
4704	Un droit utilisateur a été attribué
4705	Un droit utilisateur a été supprimé
4715	La stratégie d'audit (SACL) sur un objet a été modifiée
4719	La stratégie d'audit système a été modifiée
4728	Un membre a été ajouté à un groupe global sécurisé
4729	Un membre a été supprimé d'un groupe global sécurisé
4742	Un compte d'utilisateur a été modifié
4771	Échec de la pré-authentification Kerberos
4772	Échec d’une demande de ticket d’authentification Kerberos.
4773	Une demande de ticket de service Kerberos a échoué
4780	La liste de contrôle d’accès a été définie sur les comptes qui sont membres de groupes Administrateurs.
4946	Une modification a été apportée à la liste des exceptions du pare-feu Windows. Une règle a été ajoutée.
4947	Une modification a été apportée à la liste des exceptions du pare-feu Windows. Une règle a été modifiée.
5156	La plateforme de filtrage Windows a autorisé une connexion.
5141	Un objet du service d’annuaire a été déplacé.

Commencer par collecter les journaux d'évènements mentionnés ci-dessus et leur attribuer des priorités. Une fois cela fait, essayer de trouver une solution pour transférer tous ces journaux d'évènements vers un point central, tel qu'un système SIEM (Security Information and Event Management).

Pour aller plus loin, voir : Appendix L - Events to Monitor | Microsoft Learn

Auto-évaluation

• Ai-je un plan de sauvegarde et de restauration du Contrôleur de Domaine ?
• Est-ce la politique de sécurité par défaut qui est en place pour le Contrôleur de domaine ?
• Ai-je un moyen de surveiller les évènements sensibles concernant le DC ?

Sécuriser le DHCP

Sauvegarde et restauration

Le DHCP est une partie très importante à sauvegarder, mais comme nous le savons, les attaques par ransomware visent également les sauvegardes. Il est recommandé d'avoir une sauvegarde DHCP hors ligne également. Toutes les données de configuration qui sont stockées dans le dossier C:\Temp doivent également être stockées ailleurs, de préférence sur un serveur hors ligne (sans connexion Internet) qui n'est PAS connecté à Active Directory. Enfin, une procédure doit être mise en place pour avoir un plan de sauvegarde hors ligne de DHCP et un plan concret sur la façon de le restaurer.

Cliquer ici pour voir comment sauvegarder le DHCP et auditer cette sauvegarde

Évènements à surveiller

Les évènements suivants vous aident à identifier facilement quand les inscriptions DNS échouent en raison d'une zone de recherche inversée DNS mal configurée ou manquante.

Evènement	Description
20317	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche directe pour cet enregistrement n'existe pas sur le serveur DNS.
20318	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet %2 a échoué avec l'erreur %3.
20319	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche inversée pour cet enregistrement n'existe pas sur le serveur DNS.
20320	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20321	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche directe pour cet enregistrement n'existe pas sur le serveur DNS.
20322	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20323	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche inversée pour cet enregistrement n'existe pas sur le serveur DNS.
20324	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20325	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).
20326	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).
20327	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).

Les symboles %1, %2 et %3 (et éventuellement %4) dans la colonne "Valeur" sont des variables qui sont utilisées pour représenter des valeurs spécifiques qui varient en fonction du contexte. Par exemple, si le programme détecte une erreur lors de l'inscription d'un enregistrement de transfert pour une adresse IPv4 spécifique et un nom de domaine complet spécifique, il remplacera %1 par l'adresse IPv4, %2 par le nom de domaine complet et %3 par le message d'erreur correspondant.

Auto-évaluation

• Quelle est la procédure de sauvegarde pour le DHCP ? Quelle fréquence ?
• Les sauvegardes du DHCP sont-elles faites en ligne ET hors ligne ?
• Quand ai-je réalisé une procédure de restauration du DHCP ?
• Une procédure de surveillance des évènements sensibles est-elle mise en place ?

Sécuriser le DNS

Sauvegarde et Restauration

Le DNS est une partie cruciale à prendre en compte dans un plan de sauvegarde car il maintient une base de données des services en cours d'exécution sur un réseau.

Cliquer ici pour voir comment sauvegarder le DNS et auditer cette sauvegarde

Configuration

• Restreindre les permissions sur le DNS

Le service DNS est un composant critique d'Active Directory. Les utilisateurs pouvant accéder au DNS et le configurer sont souvent dans le groupe DnsAdmins. Comme ce groupe possède des droits élevés, il est recommandé de le restreindre le plus possible. La gestion du DNS ne nécessite pas les droits complets de DnsAdmins. Les administrateurs ont souvent besoin de créer certains enregistrements DNS. La création de Zone DNS est plus rare et nécessite le droit complet disponible au travers du groupe DndsAdmins.

Pour les administrateurs, il suffit de déléguer un groupe sur l'objet DNS avec uniquement des permissions de lecture. À partir de là, ils sont autorisés à créer des enregistrements DNS. Dans cet exemple, le groupe "Ingénieurs" dispose de permissions de lecture sur l'objet DNS. Chaque membre de l'équipe d'ingénierie peut désormais créer un enregistrement DNS, car par défaut, les utilisateurs authentifiés ont la permission "Créer tous les objets enfants" sur les zones de recherche directe.

Microsoft a mis en place un module de sécurisation du DNS en plusieurs étapes : Secure Windows Server DNS - Training | Microsoft Learn

Évènements à surveiller

Les évènements suivants vous aident à identifier facilement quand les inscriptions DNS échouent en raison d'une zone de recherche inversée DNS mal configurée ou manquante.

id	Valeur
20317	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche directe pour cet enregistrement n'existe pas sur le serveur DNS.
20318	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet %2 a échoué avec l'erreur %3.
20319	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche inversée pour cet enregistrement n'existe pas sur le serveur DNS.
20320	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20321	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche directe pour cet enregistrement n'existe pas sur le serveur DNS.
20322	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20323	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3. Cela est probablement dû au fait que la zone de recherche inversée pour cet enregistrement n'existe pas sur le serveur DNS.
20324	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3.
20325	L'inscription de l'enregistrement de transfert pour l'adresse IPv4 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).
20326	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).
20327	L'inscription de l'enregistrement de transfert pour l'adresse IPv6 %1 et le nom de domaine complet (FQDN) %2 a échoué avec l'erreur %3 (%4).

Les symboles %1, %2 et %3 (et éventuellement %4) dans la colonne "Valeur" sont des variables qui sont utilisées pour représenter des valeurs spécifiques qui varient en fonction du contexte. Par exemple, si le programme détecte une erreur lors de l'inscription d'un enregistrement de transfert pour une adresse IPv4 spécifique et un nom de domaine complet spécifique, il remplacera %1 par l'adresse IPv4, %2 par le nom de domaine complet et %3 par le message d'erreur correspondant.

Auto-évaluation

• Quelle est notre procédure de sauvegarde pour le DNS ?
• Des sauvegardes sont-elles faites tous les jours, toutes les semaines ou tous les mois ?
• Nos sauvegardes sont également stockées hors ligne ? Sont-elles directement accessibles ?
• Avons-nous déjà pratiqué une restauration DNS ?

Sécuriser la PKI

Sauvegardes et plan de restauration de PKI.

La PKI (Infrastructure à clé publique) est un composant de niveau 0, en particulier dans les institutions financières. Il est essentiel d'avoir des sauvegardes de la PKI et d'être en mesure de les restaurer. Une évaluation des risques appropriée doit être effectuée sur la PKI afin de comprendre la valeur commerciale qui y est associée. Que se passe-t-il lorsque qu'un attaquant a compromis ma PKI ?

• Faire des sauvegardes sur un serveur hors ligne qui n’est pas relié à Active Directory et faire un export de la clé d’enregistrement configurée du CA.

  

Cliquer ici pour voir comment sauvegarder la PKI et auditer cette sauvegarde

Configuration

• Activer les règles d'audit sur la PKI.

  Activer les règles d'audit est important, mais cela dépend beaucoup de l'utilisation de la PKI dans l'entreprise. Une évaluation des risques appropriée doit être réalisée pour comprendre s'il est utile de collecter les journaux d'évènements AD CS.

  Dans notre exemple, la PKI est un composant critique pour une organisation, ce qui signifie qu'elle doit être sécurisée à un niveau élevé. Un aspect important consiste à activer les règles d'audit pour collecter une visibilité.

  • Activer ces règles d'audit. Ne pas toutes les activer car cela peut perturber certaines fonctionnalités.  

  

  • Activer la politique d'audit suivante dans les propriétés d'audit des services de certifications.

  

• Créer un GPO (Group Policy Object) avec la configuration de sécurité suivante qui doit être appliquée sur les serveurs PKI.

  • Options de sécurité disponibles dans l'éditeur de gestion des stratégies de groupe :

    

  Stratégie	Paramètre de stratégie
  Comptes : statut du compte Administrateur	Désactivé
  Comptes : renommer le compte Administrateur	Compte PKI
  Comptes : Renommer le compte invité	Invité PKI
  Appareils : autoriser l’accès au CD-ROM uniquement aux utilisateurs ayant ouvert une session localement	Activé
  Sécurité réseau : niveau d’authentification LAN Manager	Activé
  Client réseau Microsoft : communications signées numériquement (toujours)	Activé

Évènements à Surveiller

Après avoir activé les stratégies d'audit au niveau de la PKI, il existe différents journaux d'évènements qui devraient constituer une base pour une organisation. Tous ces journaux d'évènements pourraient être intéressants à charger dans une solution SIEM et à surveiller, mais comme mentionné précédemment, une évaluation des risques doit d'abord être réalisée sur la PKI afin de déterminer s'il est nécessaire de surveiller la PKI.

Evènement	Description
4896	Une ou plusieurs lignes ont été supprimées de la base de données des certificats.
4891	Une entrée de configuration a été modifiée dans les services de certificats.
4873	Une extension de demande de certificat a été modifiée.
4877	La sauvegarde des services de certificats est terminée.
4879	La restauration des services de certificats est terminée.

Auto-évaluation

• Quelle est la procédure de sauvegarde de la PKI ?
• Les sauvegardes de la PKI sont-elles également stockées hors ligne ?
• Quand ai-je effectué la dernière restauration de la PKI ?

Activer Active Directory Recycle Bin

Supprimer accidentellement un objet peut être stressant, mais heureusement, il existe quelque chose appelé "Corbeille de récupération Active Directory" (Active Directory Recycle Bin). Cette fonctionnalité n'est pas activée par défaut, mais lorsqu'elle est activée, elle permet aux utilisateurs de restaurer des objets supprimés.

Étapes :

• Exécuter PowerShell avec des privilèges élevés et entrer la commande suivante :

  Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target corp.contoso.com

• Pour vérifier si la Corbeille de récupération Active Directory est activée :

  Get-ADOptionalFeature "Recycle Bin Feature" | select-object name, EnabledScopes

Déléguer les droits pour restaurer les objets de Recycle Bin

Cette tâche requiert le rang d'Administrateur Domaine par défaut mais cela peut être délégué à d'autres groupes. Attention à ne donner la permission que lorsque cela est nécessaire.

Étapes :

• Lancer le PowerShell avec les droits élevés (Domain Admin) et exécuter la commande suivante : LCRPWP

dsacls "CN=Deleted Objects,DC=corp,DC=contoso,DC=com" /takeownership

• dsacls "CN=Deleted Objects,DC=corp,DC=contoso,DC=com" /g CORP\Tier1:LCRPWP

  

Ne pas utiliser les groupes intégrés par défaut dans AD

Il est déconseillé d'utiliser les groupes intégrés hérités dans Active Directory. Ils ont été créés en 2003, à une époque où la sécurité n'était pas une préoccupation majeure. Des groupes tels que Opérateur de comptes, Opérateur de sauvegarde, Opérateur de sauvegarde et Opérateur d'impression disposent de droits plus étendus que nécessaire, ce qui peut permettre une élévation des privilèges vers un administrateur de domaine.

Si vous avez des membres dans ces groupes mentionnés, il est recommandé de trouver un moyen de les garder vides. Il est impossible de renommer, déplacer ou supprimer ces groupes.

Activer le filtrage des SID

La fonctionnalité de filtrage des SID (Security Identifier) est un sujet familier pour les administrateurs lorsqu'ils doivent gérer une migration de domaine. Lorsque vous configurez une relation de confiance entre des domaines ou des forêts, le filtrage des SID est activé par défaut. Microsoft a introduit le filtrage des SID pour atténuer les techniques d'escalade de privilèges. Un attaquant dans un domaine de confiance peut modifier l'historique des SID d'un utilisateur, ce qui pourrait lui accorder des privilèges élevés dans le domaine faisant confiance.

Lors d'une migration d'Active Directory, l'historique des SID est utilisé pour les comptes migrés dans le domaine de confiance afin d'accéder aux ressources de ce domaine. Cependant, cela ne fonctionne que si le filtrage des SID n'est PAS activé. Cela signifie que si les utilisateurs souhaitent accéder à un domaine de confiance, le filtrage des SID doit être désactivé, c'est pourquoi les attaquants exploitent ce vecteur d'attaque.

Étapes :

• Activer le filtrage des SID nécessite beaucoup d'essais et de la planification avant de pouvoir le faire.

• Vérifier si le filtrage des SID est activé

  Get-ADTrust -Filter { TargetName -eq "fabrikan.com" } | ForEach-Object { "Le filtrage des SID est $($_.SIDFilteringEnabled) pour la relation de confiance avec $($_.TargetName)." }
  Activer le filtrage des SID 

• Netdom trust cyberlab.local /Domain:fabrikam.com /EnableQuarantine:Yes

Cyberlab.local est le domaine faisant confiance et fabrikam.com est le domaine de confiance

Supprimer l'historique SID après migration

MITRE l'explique comme suit :

"L'identificateur de sécurité Windows (SID) est une valeur unique qui identifie un utilisateur ou un compte de groupe. Un compte peut contenir des SIDs supplémentaires dans l'attribut SID-History de l'Active Directory, permettant une migration inter-opérationnelle des comptes entre les domaines.

Les adversaires peuvent utiliser ce mécanisme pour l'élévation de privilèges. Avec des droits d'administrateur de domaine (ou équivalents), des valeurs SID récoltées ou bien connues peuvent être insérées dans SID-History afin de se faire passer pour des utilisateurs/groupes arbitraires, tels que les administrateurs d'entreprise."

Étapes :

• Ici, nous pouvons voir un attribut SIDHistory d'un utilisateur qui a été migré.

  

• Identifier les utilisateurs ayant une valeur SIDHistory :

  Get-aduser -filter * -properties sidhistory | Where-Object sidhistory

• Netdom trust cyberlab.local /domain:fabrikam.com /enablesidhistory:No

Cyberlab.local est le domaine faisant confiance et fabrikam.com est le domaine de confiance

Améliorer les règles d'audit

Les contrôleurs de domaine sont des serveurs cruciaux et il est essentiel de mettre en place une solide politique d'audit pour suivre les différentes modifications. Les stratégies d'audit par défaut ne sont pas suffisantes pour avoir une visibilité (meilleure) dans le suivi des comportements potentiellement malveillants.

• La commande suivante permet d'obtenir un état des lieux des règles d'audit

auditpol /get /category:*

La journalisation est importante, mais si vous ne savez pas ce qu'il faut enregistrer, cela peut devenir difficile. Le référentiel de sécurité de Windows fournit des conseils concernant les stratégies d'audit. Les stratégies d'audit avancées suivantes sont recommandées pour configurer les contrôleurs de domaine :

Étapes :

• Créer un GPO et configurer les politiques d'audit

Voici les paramètres de configuration recommandés pour les stratégies d'audit avancées :

Chemin de la stratégie	Paramètre de la stratégie	Configuration recommandée
Ouverture de session au compte	Auditer la validation des informations d’identification	Echec
Ouverture de session au compte	Auditer le service d’authentification Kerberos	Succès et Echec
Ouverture de session au compte	Auditer les opérations de ticket de service Kerberos	Echec
Gestion du compte	Auditer la gestion des comptes d’ordinateur	Succès
Gestion du compte	Auditer d’autres évènements de gestion des comptes	Succès
Gestion du compte	Auditer la gestion des groupes de sécurité	Succès
Gestion du compte	Auditer la gestion des comptes d’utilisateur	Succès et Echec
Suivi détaillé	Auditer l’activité PNP	Succès
Suivi détaillé	Auditer la création du processus	Succès
Accès DS	Auditer l’accès au service d’annuaire	Echec
Accès DS	Auditer les modifications du service d’annuaire	Succès
Ouverture de session / fermeture de session	Auditer le verrouillage du compte	Echec
Ouverture de session / fermeture de session	Auditer l’appartenance à un groupe	Succès
Ouverture de session / fermeture de session	Auditer l’ouverture de session	Succès et Echec
Ouverture de session / fermeture de session	Auditer d’autres évènements d’ouverture / fermeture de session	Succès et Echec
Ouverture de session / fermeture de session	Auditer l’ouverture de session spéciale	Succès
Accès aux objets	Auditer le partage de fichiers détaillé	Echec
Accès aux objets	Auditer le partage de fichiers	Succès et Echec
Accès aux objets	Auditer d’autres évènements d’accès à l’objet	Succès et Echec
Accès aux objets	Auditer le stockage amovible	Succès et Echec

Supprimer l'usage de protocoles non sécurisés pour Kerberos

Bien que la désactivation complète de RC4 soit une tâche importante, il est possible de configurer des comptes de service individuels pour qu'ils n'acceptent pas le protocole RC4. Il se peut que cette vulnérabilité ait été fixée sur votre version de Windows Server. Pour chercher des comptes où les protocoles RC4 et DES sont explicitement activé à l'inverse du protocole AES, taper cette commande :

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Étapes :

• Définir l'attribut msDS-SupportedEncryptionTypes sur 0x18 (décimal 24), afin que seules les méthodes de chiffrement AES128 et AES256 soient activées;

Ce changement améliore non seulement la sécurité, mais facilite également la détection d'activités malveillantes, car l'utilisation de RC4 dans une demande TGS (Ticket-Granting Service) est un indicateur plus fort.

• Rejeter les demandes d'authentification qui n'utilisent pas Kerberos Flexible Authentication Secure Tunneling (FAST). Cela la est également connu sous le nom de "Kerberos Armoring". Cette extension de pré-authentification crée un canal sécurisé entre le client et le contrôleur de domaine, dans le but d'améliorer la protection des tickets Kerberos contre les tentatives de craquage de mots de passe hors ligne. Bien que FAST puisse éliminer la menace posée par le "Kerberoasting", sa mise en œuvre rapide et efficace au sein d'une organisation peut s'avérer difficile.

  Pour en savoir plus : Authentification composée et revendications AD DS dans AD FS

Pour aller plus loin

Créer un faux utilisateur (Honey Pot)

Chaque compte de service qui contient un SPN (Service Principal Name) est en réalité exposé au risque, car chaque utilisateur authentifié a le droit de demander le ticket de service à partir de ce compte et de le cracker hors ligne. C'est pourquoi les comptes de service doivent avoir un mot de passe solide, d'au moins 20 caractères.

Une excellente façon de piéger un attaquant est de créer un faux compte de service contenant un SPN. Cet utilisateur permettra de détecter les attaques du types "Kerberoast". Voici un exemple de faux compte de service dans le groupe Domain Admins :

• Avec cette commande une fausse SPN sera attribuée au compte de service :    

setspn -s MSSQLSvc/corp.contoso.com:1443 SQL_Honey

Lancer les commandes suivantes :

• Add-Type -AssemblyName System.IdentityModel

  New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/corp.contoso.com:1443"

Maintenant, lorsque quelqu'un demande un ticket de service à partir de ce compte SQL_Honey, un journal d'évènements apparaîtra dans les journaux de sécurité. Étant donné que ce faux compte de service ne correspond à rien, une alerte devrait être déclenchée.

L'évènement 4769 sur les contrôleurs de domaine contiendra toutes les informations supplémentaires nécessaires.

Documentation Complémentaire

Il n'y a pas de sécurité parfaite, en particulier pour Active Directory, voici donc des mesures qu'il est possible de prendre dans l'optique d'améliorer sa défense face à des personnes malveillantes ou des intrus :

• Configurer un firewall pour Active Directory : Configure firewall for AD domain and trusts - Windows Server | Microsoft Learn
• Les Best Practices de sécurité Active Directory par Microsoft : Best Practices for Securing Active Directory | Microsoft Learn
• Comprendre les techniques d'attaques Active Directory (en Anglais): Télécharger PDF.

Conclusion

En conclusion, bien que la mise en œuvre des recommandations de ce guide puisse considérablement améliorer la sécurité de votre Active Directory, il est important de se rappeler que cela ne constitue pas une garantie contre les attaques. Cependant l'implémentation de quelques unes de ces mesures est déjà un frein pour toute personne qui souhaiterait nuire à l'entreprise. Des ressources et des outils supplémentaires sont disponibles sur le site web de Microsoft, et des recherches plus approfondies peuvent révéler d'autres conseils et outils pour renforcer davantage la sécurité de votre réseau.

Lexique

ACE : Access Control Entry (Entrée de contrôle d'accès) - C'est un élément d'une liste de contrôle d'accès (ACL) qui spécifie les permissions accordées ou refusées à un utilisateur ou à un groupe sur un objet.

ADFS : Active Directory Federation Services (Services de fédération Active Directory) - C'est un service de Microsoft permettant la fédération d'identités et l'authentification unique (SSO) entre différentes applications et systèmes, utilisant les technologies web standard telles que SAML et OAuth.

ACL : Access Control List (Liste de contrôle d'accès) - C'est une liste de permissions associée à un objet (par exemple, un fichier, un dossier ou un utilisateur) qui spécifie qui est autorisé à accéder à l'objet et quelles opérations peuvent être effectuées.

CA : Autorité de Certification (Certificate Authority) - C'est une entité de confiance qui délivre et gère des certificats numériques pour sécuriser les communications et authentifier les utilisateurs et les machines au sein du réseau. Ces certificats jouent un rôle essentiel dans l'infrastructure de sécurité d'Active Directory, permettant des connexions sécurisées et des échanges de données fiables.

DC : Contrôleur de Domaine (Domain Controller)- Il s'agit d'un serveur exécutant le service Active Directory dans un domaine. Il gère les authentifications, les autorisations et les stratégies de sécurité au sein du domaine.

DHCP : Dynamic Host Configuration Protocol (Protocole de configuration dynamique des hôtes) - C'est un protocole réseau qui permet aux ordinateurs d'obtenir automatiquement une configuration IP (adresse IP, masque de sous-réseau, passerelle par défaut, etc.) lorsqu'ils se connectent à un réseau.

DNS : Domain Name System (Système de noms de domaine) - C'est un service qui permet de traduire les noms de domaine en adresses IP. Il est utilisé dans Active Directory pour localiser les ressources réseau.

DNSSEC : Domain Name System Security Extensions (Extensions de sécurité du système de noms de domaine) - C'est une extension du protocole DNS qui fournit des mécanismes de sécurité supplémentaires, tels que la vérification de l'intégrité et de l'authenticité des données DNS, pour renforcer la sécurité des résolutions de noms.

DSRM : Directory Services Restore Mode (Mode de restauration des services d'annuaire) - C'est un mode de fonctionnement spécial dans lequel un contrôleur de domaine Active Directory peut être démarré pour effectuer des opérations de maintenance et de restauration de la base de données Active Directory.

GPO : Group Policy Object (Objet de stratégie de groupe) - C'est une fonctionnalité d'Active Directory qui permet de définir des règles de configuration et de sécurité pour les utilisateurs et les ordinateurs d'un domaine.

GUI : Graphical User Interface (Interface utilisateur graphique) - C'est une interface utilisateur qui utilise des éléments visuels tels que des fenêtres, des boutons et des icônes pour faciliter l'interaction avec un système ou une application.

KERBEROS : C'est un protocole d'authentification réseau sécurisé utilisé dans Active Directory. Il permet l'authentification mutuelle entre les clients et les serveurs en utilisant des tickets de sécurité.

KDC : Key Distribution Center (Centre de distribution de clés) - Il s'agit d'un composant d'Active Directory responsable de la gestion des demandes d'authentification Kerberos et de la distribution des clés de session aux entités autorisées.

KRBTGT : Key Distribution Center Service Account (Compte de service du centre de distribution de clés) - Il s'agit d'un compte de service système utilisé par le Key Distribution Center (KDC) dans Active Directory pour gérer les clés de chiffrement et les tickets Kerberos.

NTLM : NTLM (NT LAN Manager) et NTLMv2 (NT LAN Manager version 2) sont des protocoles d'authentification utilisés dans les environnements Windows pour vérifier l'identité des utilisateurs et des machines. NTLMv2 est une version améliorée de NTLM qui offre une sécurité accrue en utilisant des méthodes de hachage plus robustes et en améliorant la protection contre les attaques par rebond (pass-the-hash).

OU : Organizational Unit (Unité d'organisation) - C'est une unité logique dans Active Directory qui permet de regrouper des objets tels que des utilisateurs, des groupes et des ordinateurs pour faciliter la gestion et l'application de stratégies de groupe.

PKI : Public Key Infrastructure (Infrastructure à clé publique) - C'est un ensemble de technologies, de politiques et de procédures qui permettent de gérer et de distribuer des certificats numériques utilisés pour l'authentification et le chiffrement des communications.

RC4 : Rivest Cipher 4, protocole reposant sur un algorithme de chiffrement à flux utilisé pour sécuriser des communications sur Internet et d'autres réseaux, mais il est désormais considéré comme faible et obsolète en raison de ses vulnérabilités.

SID : Security Identifier (Identifiant de sécurité) - C'est un identifiant unique attribué à chaque compte utilisateur, groupe et objet de sécurité dans Active Directory. Il est utilisé pour contrôler l'accès aux ressources.

SIEM : Security Information and Event Management (Gestion des informations de sécurité et des évènements) - C'est une approche globale de la sécurité informatique qui combine la collecte, la corrélation et l'analyse des informations de sécurité provenant de diverses sources afin de détecter et de répondre aux incidents de sécurité.

SPN : Service Principal Name (Nom principal de service) - C'est un identifiant unique associé à un service exécuté sur un ordinateur au sein d'un domaine Active Directory. L'SPN est utilisé pour identifier de manière univoque les services qui s'exécutent sur des comptes d'utilisateur ou d'ordinateur.

TGT : Ticket-Granting Ticket (Ticket d'autorisation de ticket) - C'est un ticket généré par le KDC lorsqu'un utilisateur s'authentifie avec succès. Il est utilisé pour obtenir des tickets de session permettant d'accéder à des ressources protégées.

Les définitions fournies ci-dessus correspondent à des significations courantes de ces acronymes, mais elles peuvent varier légèrement en fonction du contexte ou de l'implémentation spécifique.