« Active Directory Securisation » : différence entre les versions

Version du 22 juillet 2024 à 10:15

Installation du rôle ADCS | Gestion des certificats | Authentification par cartes à puce

Installation du rôle ADDS | Sécuriser son environnement Active Directory | Windows LAPS | gMSA

Archives : Contrôleur de domaine Windows Server 2003 | Intégration Client Ubuntu sur AD Windows Server 2003 | Windows Server 2008


	Cet article est en cours de rédaction.

Outils d'évaluation

Les outils d'évaluation présentés sont exécutés sur un environnement Active Directory de test. Cet environnement est basé sur Windows Server 2019 Standard Edition avec les dernières mises à jour de sécurité (juillet 2024).

Auditer son environnement Active Directory permet d'identifier et de corriger des failles de sécurités. Si certaines failles de sécurités se corrigent à l'aide d'un patch ou d'une mise à jour, d'autres peuvent nécessiter de modifier la configuration standard de l'environnement Active Directory. Dans certains cas, cela peut avoir une incidence directe sur le bon fonctionnement de l'environnement Active Directory (clients et serveurs).


	Il est vivement conseillé d'appliquer ces recommandations avec prudence. Cela peut affecter le bon fonctionnement de votre installation si ces modifications ne sont pas maîtrisées. Dans le doute, et dans la mesure du possible, procédez toujours à l'audit de votre environnement avant de généraliser l'application d'une mesure de protection. Pour certains points sensibles, vous trouverez une section audit qui vous permettra d'identifier les éléments de votre infrastructure qui ne sont pas compatible avec la mesure de sécurité étudiée.

Outils d'audit

PingCastle


	PingCastle est un outil d'audit notant la vulnérabilité d'un environnement Active Directory en fonction du nombre de points collectés. Plus le score est élevé, plus l'infrastructure est vulnérable. Cet outil dispose d'une version gratuite.

Récupérer la dernière version de PingCastle depuis le site de l'éditeur https://www.pingcastle.com/.
Extraire le contenu de l'archive ZIP puis lancer l'exécution du fichier .
Un terminal de commande s'affiche. Par défaut, la sélection courante est positionnée sur l'analyse de type healthcheck-Score the risk of a domain. Appuyer sur la touche Entrée pour poursuivre.
À l'étape Select a domain or server, le script détecte automatiquement le domaine. Le cas échéant, renseigner le domaine à auditer. Appuyer sur la touche Entrée pour poursuivre.
Après quelques minutes d'analyse, le programme vous invitera à appuyer sur n'importe quelle touche pour quitter l'analyse.
Un rapport au format html est généré dans le dossier d'extraction de PingCastle. Ouvrir ce rapport à l'aide d'un navigateur web.
Au début du rapport, la section Indicator nous indique le score affecté à notre environnement Active Directory. Ensuite, ce score est détaillé autour de quatre thématiques :
- Les objets, paramètres ou encore protocoles obsolètes.
- Les problèmes de configuration au niveau des privilèges utilisateurs.
- Le niveau de confiance entre les différentes composantes Active Directory (dans le cas des configurations avec plusieurs forêts).
- Les anomalies ou dysfonctionnements de l'infrastructure Active Directory.
Les quatre thématiques décrites à l'instant sont ensuite détaillées dans un tableau d'analyse des risques.
Le rapport détaille ensuite chacun des risque en reprenant chacune des vulnérabilité avec le niveau de criticité et une proposition de remédiation.


	Il est vivement recommandé de traiter les points catégorisés INFO dans le rapport. Le traitement de ces points améliore de manière significative la sécurité de l'environnement.

ORADAD

ORADAD est un outil d'audit fournit et maintenu par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Informations).

Cet outil vérifie si la configuration de l'environnement Active Directory, à savoir s'il respecte les bonnes pratiques. Une note entre 1 et 5 est attribuée en fonction du niveau de sécurité de l'environnement. Sachant qu'une note de 3 correspond à la configuration d'origine Active Directory, un score inférieure équivaut à une infrastructure vulnérable présentant des carences importances.

L'outil est disponible pour les opérateurs règlementés et les organismes de la sphère publique gratuitement.

Les points de contrôle effectués par ORADAD sont consultables depuis la page web dédiée sur le site du CERT-FR.

Outils de Pentest


	Une utilisation inappropriée de ces outils engage votre responsabilité et peut être passible d'une amende et/ou d'une peine d'emprisonnement en cas d'atteinte au bon fonctionnement d'un système de traitement automatisé de données. Pour de plus amples informations, veuillez vous référez aux textes de lois sur Légifrance.

Mimikatz

Nmap

Sécuriser l'exécution du service spouler d'impression

Niveau ORADAD :
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	CVE-2021-34527 (CVS:8.8)
Correctif(s) :	KB5005010

Objet de la stratégie

Bien que le service spouleur d'impression semble inoffensif, tout utilisateur authentifié peut se connecter à distance au service du spouleur d’impression d’un contrôleur de domaine et demander une mise à jour sur les nouveaux travaux d’impression. En outre, les utilisateurs peuvent indiquer au contrôleur de domaine d’envoyer la notification au système avec une délégation non contrainte. Ces actions testent la connexion et exposent les informations d’identification du compte d’ordinateur du contrôleur de domaine (le spouleur d’impression appartient à SYSTEM).

— Source: Support Microsoft

Correction au niveau des Contrôleurs de Domaine

L'opération consiste à désactiver le service spouleur d'impression sur les contrôleurs de domaine.

Correction manuelle

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Services.
Accéder aux Propriétés du service nommé Spouleur d'impression.
La boîte de dialogue Propriétés de Spouleur d'impression s'ouvre :
1. Cliquer sur le bouton Arrêter¹ pour stopper le service.
2. Depuis le menu de sélection Type de démarrage, sélectionner la valeur Désactivé².
3. Cliquer sur le bouton OK pour enregistrer et appliquer les paramètres.

Correction via GPO

Correction au niveau des postes clients

L'opération consiste à demander une élévation du niveau de privilèges pour l'installation de pilotes d'impression sur la machine. L'utilisateur doit être membre du groupe Opérateurs d'impression pour pouvoir effectuer cette action.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_PRINT_DRIVERS_INSTALL puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèles d'administration / Imprimantes¹ puis accéder aux propriétés de la stratégie Restrictions Pointer et imprimer².
Depuis la boîte de dialogue des Propriétés :
1. Sélectionner l'option Activer¹.
2. À la section Invites de sécurité, depuis le menu de sélection Lors de l'installation des pilotes pour une nouvelle connexion, sélectionner la valeur Afficher l'avertissement et l'invite d'élévation².
3. Depuis le menu de sélection Lors de la mise à jour des pilotes pour une connexion existante, sélectionner la valeur Afficher l'avertissement et l'invite d'élévation³.

Configuration de Active Directory

Activer la corbeille Active Directory

Niveau ORADAD :	—
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2012 et ultérieure
CVE :	—
Correctif(s) :	Recommandations Microsoft M1047

Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs de l'Entreprise.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Effectuer un clic droit sur la racine du domaine puis cliquer sur Activer la corbeille....
Une boîte de dialogue de type avertissement s'affiche. Cliquer sur le bouton OK pour confirmer l'opération.
La fonctionnalité ne sera pas opérationnelle avant la duplication du paramètre sur l'ensemble des contrôleurs de domaine.
Lorsque la fonction est opérationnelle, un conteneur Deleted Objects doit apparaître dans l'arborescence du domaine.

Déclaration des sous réseaux

Niveau ORADAD :	—
Score PingCastle :	5 Pt(s)
Mise en oeuvre :
Criticité :	—
Compatibilité :	—
CVE :	—
Correctif(s) :	M1015

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Sites et services Active Directory.
Faire un clic droit sur le dossier Subnets présent dans le dossier Site, puis cliquer sur Nouveau sous-réseau....
Depuis la boîte de dialogue Nouvel objet - Sous-réseau, dans le champ Préfixe renseigner l'adresse réseau sur laquelle est déployée le contrôleur de domaine.
- Renseigner également tout les autres sous-réseaux pour lesquels le domaine Active Directory fait autorité.
- Cliquer sur le bouton OK pour enregistrer les paramètres.

Négociation des échanges entre les clients et Active Directory

Niveau d'authentification LAN Manager pour les clients

Niveau ORADAD :
Score PingCastle :	15 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2003 et ultérieure Windows NT4 et ultérieure
CVE :	—
Correctif(s) :	T1557 Support Microsoft

Objet de la stratégie

Ce paramètre de sécurité détermine quel est le protocole d’authentification de stimulation/réponse des ouvertures de session réseau utilisé. Ce choix a une incidence sur le niveau du protocole d’authentification qu’utilisent les clients, le niveau de sécurité de session que négocient les systèmes et le niveau d’authentification qu’acceptent les serveurs.

Auditer les connexion NTLMv.1

À l’aide du script PowerShell ci-dessous, il est possible d’extraire la liste des authentifications réalisées avec le protocole NTLMv.1 :


	$Events = Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4624)]]and Event[EventData[Data[@Name='LmPackageName']='NTLM V1']]" \| Select-Object ` @{Label='Time';Expression={$_.TimeCreated.ToString('g')}}, @{Label='UserName';Expression={$_.Properties[5].Value}}, @{Label='WorkstationName';Expression={$_.Properties[11].Value}}, @{Label='LogonType';Expression={$_.properties[8].value}}, @{Label='IP Address';Expression={$_.properties[18].value}}, @{Label='ImpersonationLevel';Expression={$_.properties[20].value}} `$Events \| Out-GridView`


	Si le script PowerShell retourne un résultat, il n'est pas recommandé d'appliquer cette stratégie de sécurité.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur la racine domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_NTLMv2_ONLY puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité¹ puis accéder aux propriétés de la stratégie Sécurité réseau : niveau d'authentification LAN Manager².
Depuis la boîte de dialogue des Propriétés, activer l'option Définir ce paramètre de stratégie¹ puis sélectionner Envoyer uniquement une réponse NTLM version 2. Refuser LM et NTLM². Cliquer sur le bouton OK pour enregistrer les paramètres.

Restriction des types de chiffrement autorisés pour Kerberos

Niveau ORADAD :	2 3 4
Score PingCastle :	— Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 R2 et ultérieure Windows 7 et ultérieure
CVE :	—
Correctif(s) :	—

Objet de la stratégie

Ce paramètre de stratégie permet de définir les types de chiffrement que Kerberos est autorisé à utiliser. Ce paramètre peut avoir des répercussions en termes de compatibilité avec les ordinateurs clients ou les services et applications.

L’outil ORADAD audite les algorithmes de chiffrement pris en charge par Active Directory. En fonction des algorithmes pris en charge, les vulnérabilités suivantes peuvent remonter dans le rapport final :

Une vulnérabilité de 2 si les algorithmes DES-CBC-CRC ou DES-CBC-MD5 sont activés.
Une vulnérabilité de 3 si les algorithmes de chiffrement AES ne sont pas supportés.
Une vulnérabilité de 4 si l’algorithme RC4-HMAC est activé.

Mise en place de la stratégie


	Adaptez la sélection des protocoles de chiffrement en fonction de la compatibilité de vos clients. Le cas échéant, ces derniers ne pourront plus s'authentifier sur Active Directory.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet Domain Controllers puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_CIPHERS_AD puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales¹ puis accéder aux propriétés de la stratégie Sécurité réseau : Configurer les types de chiffrement autorisées pour Kerberos².
Depuis la boîte de dialogue des Propriétés :
1. Activer l'option Définir ces paramètres de stratégie¹.
2. Sélectionner les options de chiffrement AES256_HMAC_SHA1² et Futurs types de chiffrement² depuis la liste de sélection.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Sur le(s) contrôleur(s) de domaine, exécuter la commande :
gpupdate /force
Redémarrer le(s) contrôleur(s) de domaine pour appliquer la nouvelle stratégie.


	Pour que les mots de passes des comptes utilisateurs respectent les nouvelles exigences, il sera nécessaire de les changer.

Auditer la stratégie

Les évènements TGS sont visibles depuis l’Observateur d’évènement à l’emplacement Journaux des applications et des services / Journaux Windows / Sécurité.

Événement	Description	Valeur
4769	Cet événement génère chaque fois que le Centre de distribution de clés reçoit une demande de ticket TGS (Ticket Granting Service) Kerberos. Cet événement est généré uniquement sur les contrôleurs de domaine. Si le problème TGS échoue, l’événement Échec avec le champ Code d’échec n’est pas égal à « 0x0 ».	En fonction de la suite de chiffrement utilisée pour l’émission du TGS, la valeur du champ Ticket Encryption Type sera affectée comme ceci : 0x1 : DES-CBC-CRC Obsolète 0x3 : DES-CBC-MD5 Obsolète 0x11 : AES128-CTS-HMAC-SHA1-96 Acceptable 0x12 : AES256-CTS-HMAC-SHA1-96 Recommandé 0x17 : RC4-HMAC Windows Vista / Server 2008 0x18 : RC4-HMAC-EXP Windows Vista / Server 2008 0xffffff : Echec de l’audit

Pour vérifier les clients se connectant avec le chiffrement RC4 sur le contrôleur de domaine, exécuter la commande suivante sur les contrôleurs de domaine :


	$Events = Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4769)]]and Event[EventData[Data[@Name='TicketEncryptionType']='0x17']]or Event[EventData[Data[@Name='TicketEncryptionType']='0x18']]" \| Select-Object ` @{Label='Time';Expression={$_.TimeCreated.ToString('g')}}, @{Label='UserName';Expression={$_.Properties[0].Value}}, @{Label='IPAddress';Expression={$_.Properties[6].Value}}, @{Label="ServiceName";Expression={$_.properties[2].value}}, @{Label="EncryptionType";Expression={$_.properties[5].value}} $Events \| Out-Gridview

Pour vérifier les clients se connectant avec le chiffrement DES sur le contrôleur de domaine, exécuter la commande suivante sur les contrôleurs de domaine :


	$Events = Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4769)]]and Event[EventData[Data[@Name='TicketEncryptionType']='0x1']]or Event[EventData[Data[@Name='TicketEncryptionType']='0x3']]" \| Select-Object ` @{Label='Time';Expression={$_.TimeCreated.ToString('g')}}, @{Label='UserName';Expression={$_.Properties[0].Value}}, @{Label='IPAddress';Expression={$_.Properties[6].Value}}, @{Label="ServiceName";Expression={$_.properties[2].value}}, @{Label="EncryptionType";Expression={$_.properties[5].value}} $Events \| Out-Gridview

Renforcement des chemins d’accès UNC

Niveau ORADAD :	—
Score PingCastle :	5 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Vista et ultérieure Windows Server 2008 et ultérieure
CVE :	—
Correctif(s) :	MS15-011


	Les équipements tierces configurés avec un connecteur LDAP peuvent rencontrer des problèmes de fonctionnement après ces opérations.

Objet de la stratégie

Ce paramètre de stratégie permet de configurer un accès sécurisé aux chemins UNC.
Si vous activez cette stratégie, Windows n'autorisera l'accès aux chemins UNC spécifiés qu'après avoir rempli les exigences de sécurité supplémentaires.

— Source : Aide Microsoft

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur la racine domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_HARDENEDPATH puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèles d’administration / Réseau / Fournisseur réseau, puis accéder aux propriétés de la stratégie Chemins d'accès UNC renforcés.
Depuis la boîte de dialogue des Propriétés, sélectionner l'option Activé¹, puis cliquer sur le bouton Afficher...² présent dans la section Options.
1. Dans la boite de dialogue Afficher le contenu, renseigner un première ligne avec :
  - Dans le champ Nom de la valeur, saisir \\*\NETLOGON.
  - Dans le champ Valeur, saisir RequireMutualAuthentication=1,RequireIntegrity=1.
2. Puis, ajouter une seconde ligne avec les éléments suivants :
  - Dans le champ Nom de la valeur, saisir \\*\SYSVOL.
  - Dans le champ Valeur, saisir RequireMutualAuthentication=1,RequireIntegrity=1.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
De retour sur la boîte de dialogue Propriétés, cliquer sur le bouton OK pour enregistrer la GPO.


	Un redémarrage des postes clients pourra être requis pour la bonne application des paramètres.

Blindage Kerberos

Niveau ORADAD :	1 2
Score PingCastle :	0 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2012 et ultérieure Windows 8 et ultérieure
CVE :	—
Correctif(s) :	—

Le blindage Kerberos sécurise la transaction avec les informations du compte d’ordinateur. Sa mise en œuvre est opérée sur plusieurs niveaux :

Au niveau des contrôleurs de domaine selon deux modes appelés hybride ou forcé (c.f. Application au niveau des contrôleurs de domaine (DC)).
Au niveau du silo d’authentification (c.f. Exiger le blindage pour les comptes membres des groupes spéciaux).

La préauthentification permet de s'assurer que l'utilisateur connaît un de ses secrets d'authentification lors d'une demande de TGT (ticket Kerberos obtenu auprès d'un contrôleur de domaine). Sans préauthentification il est possible d'obtenir un ticket chiffré avec un des secrets associés au compte correspondant. Il est ensuite possible de lancer une attaque afin de retrouver le mot de passe de l'utilisateur, ce qui peut être facilité s'il n'est pas assez robuste. La propriété DONT_REQUIRE_PREAUTH doit être supprimée pour ces comptes et le mot de passe doit être changé. Par défaut, tous les comptes utilisateur imposent la préauthentification car la propriété DONT_REQUIRE_PREAUTH n'est pas positionnée. Cette propriété ne doit jamais être positionnée pour les comptes privilégiés du domaine. En cas d'incompatibilité avec une application, celle-ci doit faire l'objet d'une évolution applicative.

— Source : ANSSI / ORADAD vulnérabilité vuln_kerberos_properties_preauth_priv https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html

Application par GPO au niveau des clients

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur la racine du domaine puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_KEBEROSARMORING puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèle d'administration / Paramètres de sécurité / Système / Kerberos.
Accéder aux propriétés de la stratégie Prise en charge du client Kerberos pour les revendications, l'authentification composée et le blindage Kerberos puis sélectionner l'option Activé et cliquer sur le bouton OK pour valider.

Application au niveau des contrôleurs de domaine (DC)

Deux modes de fonctionnement sont possibles :

Hybride : pour les parcs hétérogènes composés de systèmes d’exploitation supportant l’option et d’autres ne la supportant pas, on peut définir ce paramètre à Activé.
Forcé : pour autoriser uniquement les requêtes Kerberos blindés sur le réseau on peut définir ce paramètre sur Rejeter les demandes d’authentification non blindées.


	Si votre parc est équipé de machines vétustes de type Windows 7 et Windows Serveur 2008, privilégiez un fonctionnement « hybride ».


	Ce paramètre est susceptible de bloquer toutes authentifications sur Active Directory. Veuillez agir avec prudence.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur Domain Controllers puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_KEBEROSARMORING_AD puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèle d'administration / Système / KDC.
Accéder aux propriétés de la stratégie Prise en charge du contrôleur de domaine Kerberos pour les revendications, l'authentification composée et le blindage Kerberos :
1. Sélectionner l'option Activé.
2. Depuis le menu de sélection Options de revendications, d'authentification composée pour le contrôle d'accès dynamique et de blindage Kerberos, sélectionner Rejeter les demandes d'authentification non blindées.
3. Cliquer sur le bouton OK pour valider.


	Vous pouvez positionner la valeur de cette stratégie à Pris en charge. Ainsi, les clients le supportant utiliseront le blindage Kerberos sans pour autant bloquer les clients compatibles.

Paramétrage du silos d'authentification avec blindage Kerberos

Pour des raisons de sécurité et de préservation des comptes sensibles, il est nécessaire de forcer le blindage Kerberos. Pour cette raison, le blindage est paramétré au niveau d’une stratégie d’authentification qui contiendra les ordinateurs pour lesquels le blindage sera requis.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Accéder à l'arborescence Authentification / Authentication Policies¹ puis - depuis le menu Tâches - cliquer sur Nouveau² / Stratégie d'authentification³.
La fenêtre Créer Stratégie d'authentification s'ouvre. Depuis la section Général :
1. Dans le champ Nom complet, saisir Force-Auth-KerberosArmoring¹.
2. Sélectionner l'option Appliquer les restrictions de stratégie².
Depuis la section Authentification de l'utilisateur :
1. Cocher l'option Spécifiez la durée de vue du ticket TGT pour les comptes utilisateur¹.
2. Dans le champ Durée de vie du ticket TGT en minutes, saisir la valeur 120¹.
3. Dans la zone Cliquez sur Modifier pour définir les conditions, cliquer sur le bouton Modifier...².
  1. Depuis la boîte de dialogue Modifier les conditions de contrôle d'accès, sélectionner le critère AuthenticationSilo¹ puis comme valeur saisir Silo-Auth-Admin-Restrictions². Cliquer sur le bouton OK pour enregistrer la condition.
4. De retour sur la fenêtre Créer Stratégie d'authentification, cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder à l'arborescence Authentification / Authentication Policy Silos¹ puis - depuis le menu Tâches - cliquer sur Nouveau² / Silo de stratégie d'authentification³.
La fenêtre Créer Silo de stratégie d'authentification s'ouvre. Depuis la section Général :
1. Dans le champ Nom complet, saisir Silo-Auth-Admin-Restrictions¹.
2. Sélectionner l'option Appliquer les stratégies du silo².
Depuis la section Stratégie d'authentification :
1. Sélectionner l'option Utilisez une seule stratégie pour tous les principaux qui appartiennent à ce silo de stratégies d'authentification³.
Cliquer sur le bouton OK pour enregistrer les paramètres.

Affectation du silo de stratégie d'authentification

Cette stratégie s'applique aussi bien aux comptes utilisateurs qu'aux comptes machines.

Dans notre exemple, le silo de stratégie d'authentification sera définit pour :

Le compte utilisateur Administrateur (compte utilisateur Administrateur du domaine).
Le compte ordinateur AD01SRV (Serveur Active Directory).
Le compte ordinateur ORD080 (Ordinateur du domaine dédié aux administrateur IT).

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Depuis l'arborescence ncad (local) / Users, accéder aux Propriétés du compte Administrateur.
Depuis la section Silo de stratégies d'authentification, activer la fonction Affecter un silo de stratégies d'authentification puis, depuis la liste déroulante, sélectionner la stratégie Silo-Auth-Admin-Restrictions. Cliquer sur le bouton OK pour enregistrer les paramètres.
Répéter cette opération pour les comptes ordinateur ORD080 et AD01SRV.
On peut aussi observer la liste des comptes pour lesquels le silo de stratégies d'authentification est positionné en accédant aux propriétés du silo et en observant le listing dans la section Comptes autorisés.

Authentification

Protection LSA renforcée

Niveau ORADAD :	—
Score PingCastle :	— Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2012 R2 et ultérieure Windows 8.1 et ultérieure
CVE :	—
Correctif(s) :	Présentation de la fonctionnalité Documentation Microsoft Exploit HackTricks

Objet de la stratégie

L’autorité LSA, qui comprend le processus LSASS (Local Security Authority Server Service), valide les utilisateurs pour les connexions locales et à distance, et applique les stratégies de sécurité locales. À compter de Windows 8.1 et ultérieur, une protection renforcée pour l’autorité LSA est fournie pour empêcher une lecture de la mémoire et une injection de code par des processus non protégés. Cette fonctionnalité renforce la sécurité des informations d’identification stockées et gérées par l’autorité LSA.

— Source: Documentation Microsoft


	Les applications tierces non signées utilisant l'autorité LSA pour l'authentification Active Directory ne fonctionneront plus après cette mesure.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_LSA puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Préférences / Paramètres Windows / Registre¹ puis faire un clic droit sur l'item et Nouveau² / Elément de registre³.
Depuis la boîte de dialogue des Nouvelles propriétés de Registre :
1. Depuis le menu de sélection Action, sélectionner la valeur Remplacer¹.
2. Depuis le menu de sélection Ruche, sélectionner la valeur HKEY_LOCAL_MACHINE².
3. Depuis le champs Chemin d'accès de la clé , saisir SYSTEM\CurrentControlSet\Control\Lsa³.
4. Depuis le champs Nom de la valeur, saisir RunAsPPL⁴.
5. Depuis le menu de sélection Type de valeur, sélectionner la valeur REG_DWORD⁵.
6. Depuis le champs Données de valeur, saisir 1⁶.
7. Cliquer sur le bouton OK pour enregistrer les paramètres.


	Vous pouvez auditer cette stratégie en affectant la valeur 8 au lieu de 1. Un évènement d'audit apparaîtra dans les journaux Windows sans pour autant bloquer l'application non signée.

Auditer la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Editeur du Registre.
Se rendre dans la ruche HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe. Si cette clé n’existe pas, la créer.
Créer / Modifier la clé de type DWORD nommée AuditLevel.
Renseigner comme valeur décimal 8 puis cliquer sur le bouton OK.
Les évènements LSASS.exe sont visibles depuis l’Observateur d’évènement à l’emplacement Journaux des applications et des services / Microsoft / Windows / CodeIntegrity / Opérationnel.

Evènements	Description
3065	Signale qu’une vérification de l’intégrité du code a déterminé qu’un processus, généralement LSASS.exe, a tenté de charger un pilote qui ne répondait pas aux conditions requises en matière de sécurité pour les sections partagées. Toutefois, en raison de la stratégie système actuellement définie, le chargement de l’image a été autorisé.
3066	Signale qu’une vérification de l’intégrité du code a déterminé qu’un processus, généralement LSASS.exe, a tenté de charger un pilote qui ne répondait pas aux conditions requises en matière de niveau de signature Microsoft. Toutefois, en raison de la stratégie système actuellement définie, le chargement de l’image a été autorisé.
3033	Signale qu’une vérification de l’intégrité du code a déterminé qu’un processus, généralement LSASS.exe, a tenté de charger un pilote qui ne répondait pas aux conditions requises en matière de niveau de signature Microsoft.
3063	Signale qu’une vérification de l’intégrité du code a déterminé qu’un processus, généralement LSASS.exe, a tenté de charger un pilote qui ne répondait pas aux conditions requises en matière de sécurité pour les sections partagées.

Pour vérifier les s’il y a des processus d’authentification ne parvenant pas à communiquer correctement avec l’autorité LSA, exécuter le code PowerShell ci-dessous sur les contrôleurs de domaine :


	`$Events = Get-WinEvent -Logname Microsoft-Windows-CodeIntegrity/operational -FilterXPath "Event[System[(EventID=3065)]] or Event[System[(EventID=3066)]] or Event[System[(EventID=3063)]] or Event[System[(EventID=3033)]]" $Events \| Out-Gridview`


	Les événement 3065 et 3066 indiquent que la stratégie - si elle est mise en production - va impacter le bon fonctionnement de certains programmes. Il est nécessaire de se rapprocher des éditeurs des logiciels pour lesquels ces événements sont déclenchés.

Restrictions des comptes standards

Attribut dsHeuristics

Niveau ORADAD :	3¹
Score PingCastle :	0 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 SP2 et ultérieure
CVE :	CVE-2021-42291 (CVS:8.8)
Correctif(s) :	KB5008383

Définition de l’attribut

Le comportement d'un Active Directory peut être contrôlé via l'attribut DsHeuristics de CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.
Un paramètre stocké dans son attribut et dont la valeur est LDAPAddAutZVerifications et LDAPOwnerModify peut être défini pour modifier l'atténuation de la CVE-2021-42291.
La KB5008383 a introduit des modifications au descripteur de sécurité par défaut des conteneurs informatiques pour ajouter un audit et limiter la création d'ordinateurs sans être administrateur. En effet, il est recommandé de ne laisser personne créer de comptes informatiques car ceux-ci peuvent être utilisés pour abuser de Kerberos ou pour effectuer des attaques par relais.
Les atténuations dans CVE-2021-42291 consistent en 3 choix à définir sur 2 paramètres. Ils sont nommés LDAPAddAutZVerifications et LDAPOwnerModify et constituent respectivement le 28ème et le 29ème caractère de cette chaîne. Pour les valeurs attendues :

Avec la valeur 0 (la valeur par défaut), il active un mécanisme d'audit supplémentaire.

Avec la valeur 1 (recommandé), il applique de nouvelles autorisations de sécurité, notamment pour requérir une action de l'administrateur du domaine lorsque des actions inhabituelles sont effectuées.

Avec la valeur 2 (non recommandé), cela désactive le mécanisme d'audit qui a été ajouté par défaut et n'active pas les nouvelles autorisations de sécurité.

— Source : PingCastle

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Modification ADSI.
Basculer sur le contexte d’attribution Configuration, si cela n’est pas déjà fait :
1. Effectuer un clic droit sur l’objet Contexte d'attribution de noms par défaut [AD1SRV.ncad.fr] puis cliquer sur Paramètres….
2. Depuis la boîte de dialogue, dans la section Sélectionner un contexte d’attribution de noms connu, choisir Configuration puis cliquer sur le bouton OK.
Développer l’arborescence LDAP CN=Windows NT,CN=Services,CN=Configuration,DC=domaine,DC=tld puis accéder aux Propriétés de l'objet CN=Directory Service.
Depuis la boîte de dialogue des Propriétés sélectionner l'attribut dsHeuristics puis cliquer sur le bouton Modifier.
- Saisir la valeur 00000000010000000002000000011 puis cliquer sur le bouton OK.
De retour sur la boîte de dialogue des Propriétés, cliquer sur le bouton OK pour sauvegarder les paramètres.

Interdire aux utilisateur de pouvoir ajouter des ordinateurs au domaine

Niveau ORADAD :	4
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 et ultérieure
CVE :	CVE-2021-42287 (CVS:7.5)
Correctif(s) :	KB5008380

Objet de la stratégie

Par défaut les utilisateurs authentifiés peuvent joindre 10 machines au domaine. Cette valeur est contrôlée par l'attribut ms-DS-MachineAccountQuota de la racine du domaine.
Les comptes machine ajoutés ont alors pour propriétaire le compte utilisé, lui offrant un contrôle total dessus. La vulnérabilité CVE-2021-42287 utilisait des machines jointes pour réaliser une élévation de privilèges.

— Source : ANSSI / ORADAD vulnérabilité vuln_user_accounts_machineaccountquota https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Modification ADSI.
Effectuer un clic droit sur l'objet Modification ADSI puis cliquer sur Connexion....
1. Depuis la boîte de dialogue Paramètres de connexion, conserver les paramètres par défaut puis cliquer sur le bouton OK.
Effectuer un clic droit sur l'objet racine du domaine (DC=ncad,DC=fr), puis cliquer sur Propriétés.
Depuis la boîte de dialogue des Propriétés sélectionner l'attribut ms-DS-MachineAccountQuota, puis cliquer sur le bouton Modifier.
- Saisir la valeur 0, puis cliquer sur le bouton OK.
De retour sur la boîte de dialogue des Propriétés, cliquer sur le bouton OK pour sauvegarder les paramètres.
Redémarrer le(s) contrôleur(s) de domaine pour appliquer la nouvelle stratégie.

Restrictions des comptes à privilèges

Définition

Les groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Administrateurs.

Contrôleurs de domaine.

Administrateurs du schéma.

Administrateurs de l'entreprise.

Administrateurs du domaine : ces administrateurs ont les privilèges de lire la base des secrets de tous les comptes et donc d'extraire les secrets de l'ensemble des comptes privilégiés ;

Administrateurs de clés et Administrateurs de clés de l'entreprise: ces administrateurs peuvent fixer des valeurs arbitraires aux attributs relatifs à Windows Hello for Business, pour tous les utilisateurs sauf ceux protégés par le mécanisme d'adminSDHolder. Si l'authentification basée sur les certificats a été activée, ils peuvent générer un certificat sous leur contrôle, l'assigner à un compte privilégié (par exemple, un contrôleur de domaine), et s'authentifier en tant que lui.

Opérateurs de compte : ces opérateurs peuvent administrer tous les comptes d'utilisateurs, machines et groupes; à l'exception des comptes protégés par l'adminSDHolder ;

Opérateurs de serveur : ces opérateurs peuvent administrer les contrôleurs de domaine, et donc récupérer les secrets de tous les comptes privilégiés ;

Opérateurs de sauvegarde : ces opérateurs peuvent sauvegarder un contrôleur de domaine et donc extraire les secrets de tous les comptes privilégiés depuis cette sauvegarde ;

Opérateurs d'impression : ces opérateurs peuvent charger des pilotes d'impression sur les contrôleurs de domaine et donc charger un pilote malveillant pour par exemple extraire les secrets de tous les comptes privilégiés.

Les groupes opérateurs sont vides par défaut et ne devraient contenir aucun membre.

— Source : ANSSI / ORADAD vulnérabilité VULN_DONT_EXPIRE_PRIV https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html

Pour tout utilisateur membre de l’un de ces groupes privilégiés, les paramètres suivants devront être positionnés directement sur le compte utilisateur :

Activer l’indicateur Le compte est sensible et ne peut pas être délégué.
Activer l’indicateur Une carte à puce est nécessaire pour ouvrir une session interactive, si vous disposez de ce type de technologie d'authentification dans votre structure.

De plus, ces comptes auront les restrictions d’accès suivantes pour limiter leur utilisation sur le parc :

Interdire l’accès à cet ordinateur à partir du réseau.
Interdire l’ouverture de session en tant que tâche.
Interdire l’ouverture de session en tant que service.
Interdire l’ouverture d’une session locale.
Interdire l’ouverture de session par les services Terminal Server.

Pour veiller à ce que les comptes à privilèges ne puissent pas se connecter sur des machines non autorisées, il sera nécessaire d’activer la fonction suivante :

Configurer l’audit des comptes administrateur.

Il est aussi nécessaire d’exiger pour ce type de compte une connexion sécurisée utilisant des méthodes de chiffrement fortes ainsi qu’une limitation de la durée de vie du TGT. Pour cela, le compte doit appartenir au groupe de sécurité suivant :

Protected User.

Désactiver la délégation

Niveau ORADAD :	3
Score PingCastle :	20 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Antérieure à Windows Server 2012 R2
CVE :	—
Correctif(s) :	M1015

Définition du paramètre

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Accéder aux propriétés des comptes utilisateurs membre d'au moins un groupe privilégié.
Pour chacun des comptes listés, activer l'option Le compte est sensible et ne peut pas être délégué.

Protection du compte avec le groupe Protected Users

Niveau ORADAD :	3
Score PingCastle :	20 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2012 R2 et ultérieure
CVE :	—
Correctif(s) :	—

Définition du paramètre

L'ensemble des comptes privilégiés doivent être ajoutés au groupe Protected users afin de :

Forcer l'authentification en Kerberos.

Réduire la durée de vie des tickets Kerberos.

Forcer l'utilisation d'algorithmes de chiffrement forts (AES).

Interdire la mise en cache du mot de passe sur les postes de travail.

Interdire toute forme de délégation.

— Source : ANSSI / ORADAD vuln_protected_users https://www.cert.ssi.gouv.fr/uploads/ad_checklist.html#vuln_protected_users

Les membres du groupe Utilisateurs protégés qui se sont authentifiés sur des appareils Windows 8.1 et des hôtes Windows Server 2012 R2 ne peuvent plus utiliser :

La délégation d'informations d'identification par défaut (CredSSP) : les informations d'identification en texte brut ne sont pas mises en cache même si la stratégie Autoriser la délégation d'informations d'identification par défaut est activée.
Windows Digest : les informations d'identification en texte brut ne sont pas mises en cache même si elles sont activées.
NTLM : NTOWF n'est pas mis en cache.
Les clés à long terme Kerberos : le ticket TGT (Ticket-Granting Ticket) Kerberos s'obtient à l'ouverture de session et ne peut pas être à nouveau obtenu automatiquement.
L'authentification hors ligne : le vérificateur d'ouverture de session en cache n'est pas créé.
Effectuer l'authentifications NTLM.
Utiliser les suites de chiffrement DES (Data Encryption Standard) ou RC4 dans la pré-authentification Kerberos.
Être délégués en utilisant la délégation non contrainte ou contrainte.
Renouveler les tickets TGT utilisateur au-delà de la durée de vie initiale de 4 heures.

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Accéder aux propriétés des comptes utilisateurs membre d'au moins un groupe privilégié.
Pour chacun des comptes listés, les ajouter comme membre du groupe Protected Users.

Suppression de l'appartenance au groupe Administrateurs du schéma

Niveau ORADAD :	—
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	—
Correctif(s) :	Recommandations Microsoft

Définition du paramètre

Seuls les membres du groupe Administrateurs du schéma peuvent modifier le schéma. Des comptes doivent donc uniquement être ajoutés à ce groupe lorsqu’une modification au schéma est requise, et ils doivent être supprimés après cette opération. Cette approche permet d’empêcher un attaquant de compromettre le compte Administrateurs du schéma, et d’ainsi éviter de graves conséquences.

Action corrective

Par défaut, le compte Administrateur est membre du groupe Administrateurs du schéma.

Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs du domaine.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Accéder aux Propriétés du compte Administrateur situé dans l'OU Users.
Depuis la section Membre de, supprimer l'appartenance de l'utilisateur au groupe Administrateurs du Schéma.
Il est possible de lister l'ensemble des comptes du domaine où l'appartenance au groupe est vérifiée avec la commande PowerShell :
Get-ADGroupMember -Identity "Administrateurs du schéma"
Dans la mesure du possible, supprimer cette appartenance sur l'ensemble des comptes listés.

Interdire la connexion des comptes à privilèges sur les postes clients du domaine

Objet de la stratégie

Les comptes à privilèges ne sont pas censés se connecter sur des terminaux utilisateurs ou même des serveurs applicatifs. Idéalement, vous devez disposer d'équipements dédiés à la connexion de ce type de compte exclusivement.

Le déploiement de cette stratégie fait partit de la Recommandation à l’état de l’art n°R29 du guide de l’ANSSI intitulé Recommandations relatives à l’administration sécurisée des systèmes d’information en date du 11/05/2021.

Mise en place de la stratégie


	Cette stratégie sera configurée pour ne pas s'appliquer aux ordinateurs membres du groupe de sécurité GPO-NO-ADMINLOGONSURVEY. Ce groupe sera créé spécialement pour cette occasion.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Depuis l'arborescence ncad (local) / NCAD.FR-ADM / Groupes / Permissions, créer le groupe de sécurité GPO-NO-ADMINLOGONSURVEY.
Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_AdminLogonSurvey puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Attribution des droits utilisateur.
Accéder aux Propriétés de la stratégie Interdire l'accès à cet ordinateur à partir du réseau :
1. Sélectionner l'option Définir ces paramètres de stratégie.
2. Cliquer sur le bouton Ajouter un utilisateur ou un groupe... puis rechercher et ajouter le groupe Admins du domaine.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder aux Propriétés de la stratégie Interdire l'ouverture d'une session locale :
1. Sélectionner l'option Définir ces paramètres de stratégie.
2. Cliquer sur le bouton Ajouter un utilisateur ou un groupe... puis rechercher et ajouter le groupe Admins du domaine.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder aux Propriétés de la stratégie Interdire l'ouverture de session en tant que service :
1. Sélectionner l'option Définir ces paramètres de stratégie.
2. Cliquer sur le bouton Ajouter un utilisateur ou un groupe... puis rechercher et ajouter le groupe Admins du domaine.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder aux Propriétés de la stratégie Interdire l'ouverture de session en tant que tâche :
1. Sélectionner l'option Définir ces paramètres de stratégie.
2. Cliquer sur le bouton Ajouter un utilisateur ou un groupe... puis rechercher et ajouter le groupe Admins du domaine.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder aux Propriétés de la stratégie Interdire l'ouverture de session par les services Bureau à distance :
1. Sélectionner l'option Définir ces paramètres de stratégie.
2. Cliquer sur le bouton Ajouter un utilisateur ou un groupe... puis rechercher et ajouter le groupe Admins du domaine.
3. Cliquer sur le bouton OK pour enregistrer les paramètres.
Depuis la fenêtre des Propriétés de la GPO O_WINDOWS_AdminLogonSurvey¹, cliquer sur l'onglet Délégation² puis sur le bouton Ajouter³.
1. Depuis la boîte de dialogue Ajouter un utilisateur ou un groupe, sélectionner le groupe GPO-NO-ADMINLOGONSURVEY puis cliquer sur le bouton OK.
De retour sur fenêtre des Propriétés de la GPO O_WINDOWS_AdminLogonSurvey, cliquer sur le bouton Avancée....
1. Depuis la boîte de dialogue Paramètres de sécurité pour O_WINDOWS_AdminLogonSurvey, sélectionner le groupe GPO-NO-ADMINLOGONSURVEY¹ puis, depuis la section Autorisation pour, cliquer sur l'option Refuser² pour l'autorisation Appliquer la stratégie de groupe².

Suppression des comptes administrateurs locaux sur les postes clients du domaine

Objet de la stratégie

Les droits d’administration locaux sur les machines sont octroyés par délégation de privilèges. En l'occurrence, pour bénéficier de droits d'administration sur les machines du domaine, l'utilisateur devra être membre du groupe LOG-AD-ADMINPC (créé spécialement pour l'occasion).
Le mot de passe des comptes administrateurs locaux des postes sont régénérés de manière périodique par le service LAPS.
Tout autre compte administrateur local sur les machines joint au domaine est de ce fait rétrogradé en compte utilisateur sans privilèges.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Depuis l'arborescence ncad (local) / NCAD.FR-ADM / Groupes / Permissions, créer le groupe de sécurité LOG-AD-ADMINPC.
Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_AdminLocReset puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Préférences / Paramètres du Panneau de configuration / Utilisateurs et groupes locaux¹, puis effectuer un clic droit Nouveau² / Groupe local³.
La boîte de dialogue Nouvelles propriétés de Groupe local s'affiche. Renseigner les paramètres suivants :
1. Depuis le menu de sélection Action, sélectionner la valeur Mettre à jour¹.
2. Depuis le menu de sélection Nom du groupe, sélectionner la valeur Administrateurs (intégré)².
3. Activer les options Supprimer les utilisateurs et Supprimer les groupes³.
4. Depuis la section Membres, cliquer sur le bouton Ajouter...⁴.
  1. Depuis la boîte de dialogue Membre de groupe local, dans le champ Nom saisir la valeur Administrateur puis depuis le menu de sélection Action, choisir Ajouter à ce groupe. Cliquer sur le bouton OK pour ajouter le groupe.
  2. Répéter cette opération pour les groupes Admins du domaine et LOG-AD-ADMINPC.
5. De retour sur le boîte de dialogue Nouvelles propriétés de Groupe local, cliquer sur le bouton OK pour enregistrer les paramètres.

Auditer les connexions administrateur du domaine

Stratégie de journalisation

Pour identifier des activités suspectes comme des tentatives d’utilisation de violation de compte à privilèges, il est nécessaire d’auditer et de vérifier l’utilisation qui est faites de ces comptes.

Extraire la liste des connexions établies avec succès

Le script PowerShell ci-dessous permet d’extraire la liste des authentifications effectuées depuis un compte membre du groupe Admins du domaine. La requêtes consulte le journal d’événement Windows en filtrant l’ID d’événement (4624) ainsi que l’identifiant de l’utilisateur (SamAccountName).

$LIST_ADMINACCOUNT=(Get-ADGroupMember -Identity "Admins du domaine")

$Events=$null

foreach ($ADMINACCOUNT in $LIST_ADMINACCOUNT) {
   Write-Host Vérification des connexions pour $($ADMINACCOUNT.SamAccountName)
   $Events += Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4624)]]and Event[EventData[Data[@Name='TargetUserName']='$($ADMINACCOUNT.SamAccountName)']]" | Select-Object `
   @{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
   @{Label='UserName';Expression={$_.Properties[5].Value}},
   @{Label='WorkstationName';Expression={$_.Properties[11].Value}},
   @{Label='LogonType';Expression={$_.properties[8].value}},
   @{Label='IP Address';Expression={$_.properties[18].value}},
   @{Label='ImpersonationLevel';Expression={$_.properties[20].value}}
}
$Events | Out-GridView

Il est également possible de jouer le script sur des journaux d’événements archivés :

$LIST_ADMINACCOUNT=(Get-ADGroupMember -Identity "Admins du domaine")

$Events=$null

foreach ($ADMINACCOUNT in $LIST_ADMINACCOUNT) {
   Write-Host Vérification des connexions pour $($ADMINACCOUNT.SamAccountName)
   $Events += Get-WinEvent -FilterHashtable @{Path="C:\Windows\System32\winevt\Logs\Security.evtx";Id="4624";Data="$($ADMINACCOUNT.SamAccountName)"} | Select-Object `
       @{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
       @{Label='UserName';Expression={$_.Properties[5].Value}},
       @{Label='WorkstationName';Expression={$_.Properties[11].Value}},
       @{Label='LogonType';Expression={$_.properties[8].value}},
       @{Label='IP';Expression={$_.properties[18].value}},
       @{Label='ImpersonationLevel';Expression={$_.properties[20].value}} 
}
$Events | Out-GridView

Ou encore de la jouer directement sur le journal d’événements Système depuis l’onglet XML en précisant le nom du compte utilisateur à rechercher :

<QueryList>
   <Query Id="0" Path="Security">
   <Select Path="Security">
       *[System[(EventID=4624)] and EventData[Data[@Name='TargetUserName']='USERNAME']] 
   </Select>
   </Query>
</QueryList>

Extraire la liste des connexions en échec

Le script PowerShell ci-dessous permet d’extraire la liste des authentifications effectuées depuis un compte membre du groupe Admins du domaine. La requêtes consulte le journal d’événement Windows en filtrant l’ID d’événement (4625) ainsi que l’identifiant de l’utilisateur (SamAccountName).

$LIST_ADMINACCOUNT=(Get-ADGroupMember -Identity "Admins du domaine")

$Events=$null

foreach ($ADMINACCOUNT in $LIST_ADMINACCOUNT) {
   Write-Host Vérification des connexions pour $($ADMINACCOUNT.SamAccountName)
   $Events += Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4625)]]and Event[EventData[Data[@Name='TargetUserName']='$($ADMINACCOUNT.SamAccountName)']]" | Select-Object `
   @{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
   @{Label='UserName';Expression={$_.Properties[5].Value}},
   @{Label='WorkstationName';Expression={$_.Properties[11].Value}},
   @{Label='LogonType';Expression={$_.properties[8].value}},
   @{Label='IP Address';Expression={$_.properties[18].value}},
   @{Label='ImpersonationLevel';Expression={$_.properties[20].value}}
}
$Events | Out-GridView

Il est également possible de jouer le script sur des journaux d’événements archivés :

$LIST_ADMINACCOUNT=(Get-ADGroupMember -Identity "Admins du domaine")

$Events=$null

foreach ($ADMINACCOUNT in $LIST_ADMINACCOUNT) {
   Write-Host Vérification des connexions pour $($ADMINACCOUNT.SamAccountName)
   $Events += Get-WinEvent -FilterHashtable @{Path="C:\Windows\System32\winevt\Logs\Security.evtx";Id="4625";Data="$($ADMINACCOUNT.SamAccountName)"} | Select-Object `
       @{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
       @{Label='UserName';Expression={$_.Properties[5].Value}},
       @{Label='WorkstationName';Expression={$_.Properties[11].Value}},
       @{Label='LogonType';Expression={$_.properties[8].value}},
       @{Label='IP';Expression={$_.properties[18].value}},
       @{Label='ImpersonationLevel';Expression={$_.properties[20].value}} 
}
$Events | Out-GridView

Ou encore de la jouer directement sur le journal d’événements Système depuis l’onglet XML en précisant le nom du compte utilisateur à rechercher :

<QueryList>
   <Query Id="0" Path="Security">
   <Select Path="Security">
       *[System[(EventID=4625)] and EventData[Data[@Name='TargetUserName']='USERNAME']] 
   </Select>
   </Query>
</QueryList>

Stratégie des mots de passe

Expiration des mots de passe

Niveau ORADAD :	1 2
Score PingCastle :	1 - 10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 et ultérieure
CVE :	—
Correctif(s) :	—

Objet de la stratégie

ORADAD et PingCastle vérifient la politique de mot de passe pour les comptes à privilèges :

Dans le cas où le compte dispose de l'option ce mot de passe n'expire jamais, le critère d'analyse vuln_dont_expire_priv remonte en anomalie avec un score de 1. PingCastle attribut 1 point pour ce critère.
Si le mot de passe n'a pas été changé depuis plus de 3 ans, le critère d'analyse vuln_password_change_priv remonte en anomalie avec un score de 1. PingCastle attribut 10 points pour ce critère.

Dans tous les cas, si plus de 10% des comptes de l'Active Directory disposent d'un mot de passe n'expirant jamais, alors le critère d'analyse vuln_dont_expire remonte dans ORADAD avec un score de 2.

Action corrective

Par défaut, cette option est active sur le compte Administrateur du domaine.

Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs du domaine.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Accéder aux Propriétés du compte Administrateur situé dans l'OU Users.
Décocher l'option Le mot de passe n'expire jamais présente dans la section Compte puis cliquer sur le bouton OK.
Il est possible de lister l'ensemble des comptes du domaine où l'option est active en exécutant la commande PowerShell suivante :


	Get-ADUser -Filter * -Properties Enabled, PasswordLastSet, Displayname, mail, passwordneverexpires ` \| Where-Object {$_.Enabled -like "True" -and $_.passwordNeverExpires -eq $true} ` \| Sort-Object -Property PasswordLastSet ` \| Select -Property UserPrincipalname, DisplayName, mail, PasswordLastSet ` \| Out-GridView

Dans la mesure du possible, désactiver l'option sur l'ensemble des comptes listés.

Complexité des mots de passe

Niveau ORADAD :	2
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 et ultérieure
CVE :	—
Correctif(s) :	—

Objet de la stratégie

Il est recommandé d'adopter une politique de complexité des mots de passes sur l'ensemble du domaine avec pour critères :

La longueur minimale du mot de passe doit être de 8 caractères.
Il doit contenir au moins un chiffre.
Il doit contenir au moins un caractère minuscule.
Il doit contenir au moins un caractère majuscule.
Il doit contenir au moins un caractère spéciale.

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Modifier la GPO Default Domain Policy, puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies de comptes / Stratégie de mot de passe¹ puis accéder aux propriétés de la stratégie Longueur minimale du mot de passe².
Depuis la boîte de dialogue des Propriétés, activer l'option Définir ce paramètre de stratégie, puis dans le champ Le mot de passe doit faire au minimum renseigner 12. Cliquer sur le bouton OK pour enregistrer les paramètres.

Forcer une longueur de mot de passe de 20 caractères pour les comptes gMSA

Niveau ORADAD :
Score PingCastle :	0 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2016 et ultérieure
CVE :	—
Correctif(s) :	—

Objet de la stratégie

Les mots de passe des comptes de service sont automatiquement renouvelés par la machine utilisant le compte. La longueur du mot de passe est – par défaut – calquée sur les paramètres globaux du domaine.

Or, si pour un compte utilisateur il peut être toléré d’avoir une longueur de mot de passe inférieure à 15 caractères, pour un compte de service il est recommandé d’avoir une longueur minimale de 20 caractères.

Cette stratégie de sécurité est vérifiée par l’outil d’audit PingCastle. Cependant, elle n’apparaît qu’à titre d’information dans le rapport final et n’est pas jugée critique.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Centre d'administration Active Directory.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Depuis l'arborescence ncad (local) / NCAD.FR-ADM / Groupes / Mots de passe, créer le groupe de sécurité PWD-20C.
Accéder à l'arborescence ncad (local) / System / Password Settings¹ puis - depuis le menu Tâches - cliquer sur Nouveau² / Paramètres de mot de passe³.
La boîte de dialogue Créer Paramètres de mot de passe s'affiche :
1. Dans le champ Nom, renseigner un nom pour la politique de mot de passe configurée.
2. Activer l'option Appliquer la longueur minimale du mot de passe puis renseigner comme valeur 24.
3. Activer l'option Le mot de passe doit respecter des exigences de complexité.
4. Activer l'option Appliquer l'âge maximal de mot de passe puis renseigner comme valeur 30.
5. Depuis la section S'applique directement à, cliquer sur le bouton Ajouter... puis rechercher le groupe de sécurité nommé PWD-20C.


	Lorsque vous créé un compte gMSA, assurez-vous qu'il soit bien membre du groupe PWD-20C afin qu'il hérite de la stratégie de mot de passe adéquate.

Gestion de la version de TLS supportée

Niveau ORADAD :	—
Score PingCastle :	0 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	—
Correctif(s) :	KB5017811

Objet de la stratégie

TLS 1.0 est un protocole de sécurité qui a été défini pour la première fois en 1999 pour établir des canaux de chiffrement sur les réseaux informatiques. Microsoft prend en charge ce protocole depuis Windows XP/Server 2003. Même s'il n'est plus le protocole de sécurité par défaut des systèmes d'exploitation modernes, TLS 1.0 est toujours pris en charge à des fins de compatibilité descendante. Face à l'évolution de la réglementation et à l'apparition de nouvelles vulnérabilités de sécurité dans TLS 1.0, les entreprises sont appelées à désactiver complètement TLS 1.0.

— Source: Documentation Microsoft

Depuis le 30 juin 2018, les protocoles SSL v2, SSL v3, TLS 1.0 et TLS 1.1 ont été classifiés comme étant obsolètes. Cette classification est notamment dû à leur vulnérabilité aux attaques de type BEAST, CRIME, POODLE, RC4, FREAK et Logjam.


	Pour des raisons de rétrocompatibilité, Microsoft ne désactive pas par défaut ce protocole.

Mise en place de la stratégie

La version de TLS prise en charge sur les serveurs Microsoft Windows se configure au niveau du FrameWork .NET depuis la base de registre Windows.

La modification de ces paramètres peut avoir une incidence sur les équipements tiers dotés d’un connecteur LDAP.

Les version 1.0' et 1.1 du protocole TLS étant obsolètes depuis le 20 septembre 2022, leur désactivation est requise par les principales instances de cyber sécurité ainsi que les outils d’audit (ORADAD, PingCastle, HealthChecker).

Ces recommandations peuvent également être consultées dans le guide de Recommandations de sécurité relatives à TLS rédigé par l’ANSSI en date de juillet 2017.

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Editeur du Registre.
Se rendre dans la ruche HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
Les paramètres décrits ici concernent les protocoles TLS version 1.0 et 1.1. Pour désactiver le protocole :
1. Positionner le paramètre DisabledByDefault sur la valeur 1.
2. Positionner le paramètre Enabled sur la valeur 0.
3. Cette opération doit être réalisée dans les clés Client et Server.

Exiger la signature des requêtes LDAP

Niveau ORADAD :	—
Score PingCastle :	5 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows 7 et ultérieure Windows Server 2008 SP2 et ultérieure
CVE :	CVE-2017-8563 (CVS:8.1)
Correctif(s) :	KB4520412 Pentest LDAP HackTrick

Activer la journalisation des événements

Objet de la stratégie

L’application des règles énoncées dans cette section peuvent être auditées en activant la journalisation des événements de diagnostic Active Directory et LDS.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Editeur du Registre.
Se rendre dans la ruche HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
Modifier la clé de type DWORD nommée 16 LDAP Interface Events et affecter la valeur en fonction du niveau de journalisation souhaité :
- 0 (Aucun) : seuls les événements critiques et les événements d’erreur sont enregistrés à ce niveau. Il s’agit du paramètre par défaut pour toutes les entrées. Il ne doit être modifié que si un problème que vous souhaitez examiner se produit.
- 1 (Minimal) : les événements de haut niveau sont enregistrés dans le journal des événements à ce paramètre. Les événements peuvent inclure un message pour chaque tâche principale effectuée par le service. Utilisez ce paramètre pour démarrer une investigation lorsque vous ne connaissez pas l’emplacement du problème.
- 2 (De base)
- 3 (Étendu) : ce niveau enregistre des informations plus détaillées que les niveaux inférieurs, comme les étapes effectuées pour effectuer une tâche. Utilisez ce paramètre lorsque vous avez limité le problème à un service ou à un groupe de catégories.
- 4 (Détaillé)
- 5 (Interne) : ce niveau journalise tous les événements, y compris les chaînes de débogage et les modifications de configuration. Un journal complet du service est enregistré. Utilisez ce paramètre lorsque vous avez suivi le problème vers une catégorie particulière d’un petit ensemble de catégories.
Dans notre cas, nous affectons la valeur 2 au paramètre 16 LDAP Interface Events.

Accéder aux journaux

Les journaux d’évènements sont accessibles depuis une console Observateur d’évènement depuis la racine Journaux des applications et des services / Directory Service.

Signature LDAP par les clients

Objet de la stratégie

Le trafic réseau non signé est vulnérable aux attaques de l’intercepteur dans lequel un intrus capture les paquets entre l’ordinateur client et le serveur, les modifie, puis les transfère au serveur. Pour un serveur LDAP, cette sensibilité signifie qu’un attaquant peut amener un serveur à prendre des décisions basées sur des données fausses ou modifiées à partir des requêtes LDAP.

Auditer les connexions LDAP

Depuis la console Observateur d'événements, dans le journal Journaux des applications et des services / Directory Service sur serveur Active Directory, observer les événements suivants :

Evènement	Description	Déclencheur
2886	La sécurité de ces contrôleurs de domaine peut être considérablement améliorée en configurant le serveur pour appliquer la validation de la signature LDAP.	Déclenchée toutes les 24 heures, au démarrage ou au début du service si la stratégie de groupe est définie sur Aucun. Niveau de journalisation minimal : 0 ou plus
2887	La sécurité de ces contrôleurs de domaine peut être améliorée en les configurant pour rejeter les demandes de liaison LDAP simples et d’autres demandes de liaison qui n’incluent pas de signature LDAP.	Déclenchée toutes les 24 heures lorsque stratégie de groupe est défini sur Aucun et qu’au moins une liaison non protégée a été effectuée. Niveau de journalisation minimal : 0 ou plus
2888	La sécurité de ces contrôleurs de domaine peut être améliorée en les configurant pour rejeter les demandes de liaison LDAP simples et d’autres demandes de liaison qui n’incluent pas de signature LDAP.	Déclenchée toutes les 24 heures lorsque stratégie de groupe est défini sur Exiger la signature et qu’au moins une liaison non protégée a été rejetée. Niveau de journalisation minimal : 0 ou plus
2889	La sécurité de ces contrôleurs de domaine peut être améliorée en les configurant pour rejeter les demandes de liaison LDAP simples et d’autres demandes de liaison qui n’incluent pas de signature LDAP.	Déclenchée lorsqu’un client n’utilise pas la signature pour les liaisons sur les sessions sur le port 389. Niveau de journalisation minimal : 2 ou supérieur

Exemple de script PowerShell pour vérifier la présence des événements #2889 sur les serveurs Active Directory :


	$Events = Get-WinEvent -Logname "Directory Service" -FilterXPath "Event[System[(EventID=2889)]]" ¦ Select-Object ` @{Label='Time';Expression={$_.TimeCreated.ToString('g')}}, @{Label='UserName';Expression={$_.Properties[1].Value}}, @{Label='RemoteHost';Expression={$_.Properties[0].Value}}, @{Label='LogonType';Expression={$_.properties[2].value}} $Events ¦ Out-GridView


	Les événement 2886 et 2887 indiquent que la stratégie - si elle est mise en production - va impacter le bon fonctionnement de certains clients nécessitant une authentification Active Directory (ordinateurs, serveurs, photocopieurs, pare-feu, ...). Vérifier la configuration des équipements listés et plus précisément si il est possible de les configurer en authentification chiffrée LDAPS.

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur la racine du domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_LDAPSIGN puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité, puis accéder aux propriétés de la stratégie Sécurité réseau : conditions requises pour la signature de client LDAP.
Depuis la boîte de dialogue des Propriétés, cocher l'option Définir ce paramètre de stratégie¹ et sélectionner la valeur Exiger la signature depuis le menu de sélection. Cliquer sur le bouton OK pour valider les paramètres.
- Un message d'avertissement s'affichera pour indiquer ce paramètre peut empêcher le bon fonctionnement des clients non compatibles. Cliquer sur le bouton Oui.

Signature LDAP par les serveurs LDAP


	Les clients s’appuyant sur le connecteur LDAP TCP/389 ne fonctionneront plus après application de cette stratégie.

Objet de la stratégie

Le trafic réseau non signé est vulnérable aux attaques de l’intercepteur dans lequel un intrus capture les paquets entre l’ordinateur client et le serveur, les modifie, puis les transfère au serveur. Pour un serveur LDAP, cette sensibilité signifie qu’un attaquant peut amener un serveur à prendre des décisions basées sur des données fausses ou modifiées à partir des requêtes LDAP.

Auditer les connexions LDAP

Depuis la console Observateur d'événements, dans le journal Journaux des applications et des services / Directory Service sur serveur Active Directory, observer les événements suivants :

Evènement	Description	Déclencheur
3039	Le client suivant a effectué une liaison LDAP sur SSL/TLS et a échoué la validation du jeton de liaison de canal LDAP.	Déclenchée dans l’une des circonstances suivantes : Lorsqu’un client tente d’établir une liaison avec un jeton de liaison de canal (CBT) mal mis en forme, si la stratégie de groupe CBT est défini sur Quand pris en charge ou Toujours. Lorsqu’un client capable de liaison de canal n’envoie pas de cbt si la stratégie de groupe CBT est défini sur Quand pris en charge. Un client est capable de liaison de canal si la fonctionnalité EPA est installée ou disponible dans le système d’exploitation et n’est pas désactivée via le paramètre de Registre SuppressExtendedProtection. Pour en savoir plus, consultez KB5021989. Lorsqu’un client n’envoie pas de cbt si la stratégie de groupe CBT est défini sur Toujours. Niveau de journalisation minimal : 2
3040	Au cours de la période précédente de 24 heures, nombre de liaisons LDAPs non protégées ont été effectuées.	Déclenchée toutes les 24 heures lorsque la stratégie de groupe CBT est définie sur Jamais et qu’au moins une liaison non protégée a été effectuée. Niveau de journalisation minimal : 0
3041	La sécurité de ce serveur d’annuaire peut être considérablement améliorée en configurant le serveur pour appliquer la validation des jetons de liaison de canal LDAP.	Déclenchée toutes les 24 heures, au démarrage ou au début du service si la stratégie de groupe CBT est défini sur Jamais. Niveau de journalisation minimal : 0

Action corrective

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur Domain Controllers puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_LDAPSIGN_AD puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité, puis accéder aux propriétés de la stratégie Contrôleur de domaine : conditions requises pour la signature de serveur LDAP.
- Depuis la boîte de dialogue des Propriétés, cocher l'option Définir ce paramètre de stratégie et sélectionner la valeur Exiger la signature depuis le menu de sélection. Cliquer sur le bouton OK pour valider les paramètres.
- Un message d'avertissement s'affichera pour indiquer ce paramètre peut empêcher le bon fonctionnement des clients non compatibles. Cliquer sur le bouton Oui.
Toujours depuis cette même GPO, accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité, puis accéder aux propriétés de la stratégie Contrôleur de domaine : configuration requise pour le jeton de liaison du canal du serveur LDAP.
- Depuis la boîte de dialogue des Propriétés, cocher l'option Définir ce paramètre de stratégie et sélectionner la valeur Toujours depuis le menu de sélection. Cliquer sur le bouton OK pour valider les paramètres.
- Un message d'avertissement s'affichera pour indiquer que ce paramètre peut empêcher le bon fonctionnement des clients non compatibles. Cliquer sur le bouton Oui.

Vérification de la stratégie

Pour vérifier si la stratégie fonctionne :

Ouvrir une console LDP.
Depuis le menu Connexion cliquer sur Se connecter.
La boîte de dialogue Connexion s'affiche :
1. Dans le champ Serveur, renseigner l'adresse IP locale du Contrôleur de domaine.
2. Cliquer sur le bouton OK pour valider.
Une fois la connexion au Contrôleur de domaine effectuée, depuis le menu Connexion cliquer sur Lier....
La boîte de dialogue Liaison s'affiche :
1. Dans le champ Utilisateur, renseigner un identifiant Active Directory.
2. Dans le champ Mot de passe, renseigner le mot de passe associé.
3. Dans la section Type de liaison, choisir l'option Liaison simple.
4. Cliquer sur le bouton OK pour lancer la liaison.
Si la liaison chiffrée LDAPS est bien configurée en mode exigé, alors la connexion sera refusée :
Le cas échéan, la connexion sera acceptée :

Gestion des protocoles

Désactivation de LLMNR

Niveau ORADAD :	—
Score PingCastle :	2 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	—
Correctif(s) :	T1557

Objet de la stratégie

LLMNR est un protocole de résolution de nom de domaine. LLMNR a été conçu pour traduire le nom localement au cas où le protocole DNS par défaut n’est pas disponible. Concernant Active Directory, le DNS est obligatoire ce qui rend LLMNR inutile.
Le protocole LLMNR peut intervenir en cas de faute de frappe d'une adresse réseau. Il peut aussi répondre plus rapidement que le protocole DNS classique pour rediriger les utilisateurs vers un partage, un serveur ou un site Web spécialement conçu.
Étant approuvé, ce service déclenchera la procédure d’authentification unique qui peut être utilisée de manière abusive pour récupérer les informations d’identification de l’utilisateur.

LLMNR est activé par défaut sur tous les systèmes d’exploitation, sauf à partir de Windows 10 v1903 et Windows Server v1903 où il est désactivé.

— Source : PingCastle

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur la racine du domaine puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_LLMNR puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèle d'administration / Réseau / Client DNS.
Accéder aux propriétés de la stratégie Désactiver la résolution de noms multidiffusion puis sélectionner l'option Activé et cliquer sur le bouton OK pour valider.

Stratégies d'énumération sur le domaine

Définition

L’énumération désigne la capacité à pouvoir collecter des données sur un environnement informatique dans le but d'identifier et exploiter des chemins de compromission sur un environnement ciblé. Par défaut, un environnement Active Directory permet l'énumération de l'annuaire LDAP aussi bien pour les utilisateurs anonymes qu’à l’aide d’un compte utilisateur standard.


	Si vous disposez d'applications connectées à votre domaine Active Directory, l'application des stratégies présentées dans ce chapitre peuvent empêcher le bon fonctionnement de vos applications. Pour gérer les autorisations d’énumération, se référer à la section Autoriser l’énumération pour des comptes utilisateurs spécifiques

Membres du groupe Accès compatible pré-Windows 2000

Niveau ORADAD :	2 3
Score PingCastle :	2 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	—
Correctif(s) :	—

Objet de la stratégie

Le groupe d'accès compatible pré-Windows 2000 accorde l'accès à certains appels RPC.
Par défaut, le groupe utilisateurs « Utilisateurs authentifiés » est positionné dans ce groupe d’accès, ce qui permet aux utilisateurs d'effectuer une recherche de groupe à l'aide des protocoles existants.
Si ce groupe contient des « Utilisateurs authentifiés », cela augmente l'impact sur la vulnérabilité d'exploitation sur les protocoles existants tels que le spouleur d'imprimante.
En effet, dans l'attaque PrintNightmare, il permet de contourner les correctifs sur les contrôleurs de domaine car la propriété Elevated Token est activée lors de l'établissement d'une session sur le DC.
La suppression du groupe peut avoir des effets secondaires et, par conséquent, ceci est signalé ici comme une mesure de durcissement spéciale.

— Source : PingCastle

Pour les requêtes, la liste de contrôle d’accès par défaut permet à Tous les utilisateurs et Membres authentifiés du groupe Accès compatible pré-Windows 2000 de lire et d’énumérer des informations. Les fonctions répertoriées suivantes sont affectées :

NetGroupEnum, NetGroupGetInfo, NetGroupGetUsers
NetLocalGroupEnum, NetLocalGroupGetInfo, NetLocalGroupGetMembers
NetQueryDisplayInformation
NetSessionGetInfo (niveaux 1 et 2 uniquement)
NetShareEnum (niveaux 2 et 502 uniquement)
NetUserEnum, NetUserGetGroups, NetUserGetInfo, NetUserGetLocalGroups, NetUserModalsGet
NetWkstaGetInfo, NetWkstaUserEnum

L’accès anonyme aux informations de groupe nécessite que l’utilisateur Anonyme soit explicitement ajouté au groupe Accès compatible pré-Windows 2000. Cela est dû au fait que les jetons anonymes n’incluent pas le SID du groupe Tout le monde.

Si identifiant de sécurité Anonyme (S-1-5-7) est présent dans ce groupe de sécurité, ORADAD remontera dans son rapport ce critère d'analyse avec un score d'évaluation de 2. Pour tout autre objet autre que Utilisateurs authentifiés présent dans ce groupe, ORADAD remontera dans son rapport ce critère d'analyse avec un score d'évaluation de 3.

Action corrective

Suppression de tous les objets membres du groupe de sécurité Accès compatible pré-Windows 2000.

Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs du domaine.
Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
Accéder aux Propriétés du groupe de sécurité Accès compatible pré-Windows 2000 situé dans l'OU Builtin.
Depuis la section Membres, supprimer tous les objets listés.


	Pour les comptes nécessitant un droit d'énumération spécifique sur la forêt Active Directory, se reporter à la section Autoriser l’énumération pour des comptes utilisateurs spécifiques.

Autoriser l’énumération pour des comptes utilisateurs spécifiques

Objet de la stratégie

Il est possible que certaines applications liées à l’annuaire Active Directory (pour de l’authentification SSO par exemple) nécessitent des privilèges d’énumération spécifiques. Ces applications peuvent nécessiter une autorisation de lecture de l’attribut Member of sur les comptes utilisateurs, par exemple.

Nous allons définir un groupe de sécurité spécifique qui sera autorisé à énumérer les objets Active Directory contenus dans l'OU NCAD.FR.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Utilisateurs et ordinateurs Active Directory.
Depuis l'arborescence ncad (local) / NCAD.FR-ADM / Groupes / Permissions, créer le groupe de sécurité LOG-AD-ENUM.
Effectuer un clic droit sur l'OU NCAD.FR puis cliquer sur Délégation de contrôle....
La fenêtre Assistant Délégation de contrôle s'affiche avec l'écran de Bienvenue !. Cliquer sur le bouton Suivant pour commencer.
1. À l'étape Utilisateurs ou groupes, sélectionner le groupe de sécurité autorisé à énumérer les objets Active Directory en cliquant sur le bouton Ajouter....
2. Depuis la boîte de dialogue, sélectionner le nom du groupe. Dans notre cas, il s'agit du groupe LOG-AD-ENUM.
3. De retour à l'écran Utilisateurs ou groupe, après avoir sélectionné le groupe adéquate, cliquer sur le bouton Suivant.
4. À l'étape Tâches à déléguer, sélectionner l'option Créer une tâche personnalisée à déléguer.
5. À l'étape Type d'objet Active Directory, sélectionner l'option De ce dossier et des objets qui s'y trouvent. Déléguer aussi la création de nouveaux objets dans ce dossier.
6. À l'étape Autorisations :
  1. Dans la section Afficher les autorisations, cocher l'option Générales.
  2. Dans la section Autorisations, cocher l'option Lire.
  3. Cliquer sur le bouton Suivant pour valider les paramètres.
7. Une fois les paramètres enregistrés, vérifier la synthèse des droits appliqués puis cliquer sur le bouton Terminer pour appliquer les paramètres.

Journalisation des évènements

Niveau ORADAD :	—
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	—
CVE :	—
Correctif(s) :	—

Environnement Active Directory

Objet de la stratégie

La journalisation des événements est essentielle pour pouvoir investiguer sur le systèmes selon différentes situations :

Lorsque vous déployez de nouvelles fonctionnalités.
Lorsque vous souhaitez vous assurer qu'un paramètre est correctement propagé sur l'environnement.
Lorsque vous souhaitez avoir des détails sur un dysfonctionnement.
Lorsque vous souhaitez détecter des comportements suspects.
Ou encore, en cas d'attaque, pour tenter d'identifier les chemins de compromission sur l'environnement.

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_AUDIT puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Stratégie d'audit :
1. Accéder aux Propriétés de la stratégie Auditer l'accès au service d'annuaire puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer l'accès aux objets puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
3. Accéder aux Propriétés de la stratégie Auditer l'utilisation des privilèges puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
4. Accéder aux Propriétés de la stratégie Auditer la gestion des comptes puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
5. Accéder aux Propriétés de la stratégie Auditer le suivi des processus puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
6. Accéder aux Propriétés de la stratégie Auditer les événements de connexion puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
7. Accéder aux Propriétés de la stratégie Auditer les événements de connexion aux comptes puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
8. Accéder aux Propriétés de la stratégie Auditer les événements système puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
9. Accéder aux Propriétés de la stratégie Auditer les modifications de stratégie puis cocher les options Définir ces paramètres de stratégie, ainsi que Réussite et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité puis accéder aux propriétés de la stratégie Audit : force les paramètres de sous-catégorie de stratégie d'audit.
1. Depuis la boîte de dialogue des Propriétés, activer l'option Définir ce paramètre de stratégie puis sélectionner l'option Activé. Cliquer sur le bouton OK pour enregistrer les paramètres.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Connexion de compte :
1. Accéder aux Propriétés de la stratégie Auditer la validation des informations d'identification puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer le service d'authentification Kerberos puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
3. Accéder aux Propriétés de la stratégie Auditer les opérations de ticket du service Kerberos puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Gestion du compte :
1. Accéder aux Propriétés de la stratégie Auditer la gestion des comptes d'ordinateur puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer la gestion des groupes de sécurité puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
3. Accéder aux Propriétés de la stratégie Auditer d'autres événements de gestion des comptes puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
4. Accéder aux Propriétés de la stratégie Auditer la gestion des comptes utilisateur puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Ouvrir/fermer la session :
1. Accéder aux Propriétés de la stratégie Auditer le vérouillage du compte puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer la fermeture de session puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
3. Accéder aux Propriétés de la stratégie Auditer l'ouverture de session puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
4. Accéder aux Propriétés de la stratégie Auditer l'ouverture de session spéciale puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Système :
1. Accéder aux Propriétés de la stratégie Auditer le pilote IPSEC puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer la modification de l'état de la sécurité puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
3. Accéder aux Propriétés de la stratégie Auditer l'extension du système de sécurité puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Utilisation de privilège :
1. Accéder aux Propriétés de la stratégie Auditer l'utilisation de privilèges sensibles puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / CHangement de stratégie :
1. Accéder aux Propriétés de la stratégie Auditer la modification de stratégie d'authentification puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Accès DS :
1. Accéder aux Propriétés de la stratégie Auditer l'accès au service d'annuaire puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer les modifications du service d'annuaire puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
Accéder à la stratégie Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Configuration avancée de la stratégie / Suivi détaillé :
1. Accéder aux Propriétés de la stratégie Auditer l'activité DPAPI puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Auditer la création du processus puis cocher les options Configurer les événements d'audit suivants, ainsi que Succès et Echec. Cliquer sur le bouton OK pour enregistrer.

Environnement PowerShell

Objet de la stratégie

Mise en place de la stratégie

Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
Faire un clic droit sur l'objet NCAD.FR puis Créer un objet GPO dans ce domaine, et le lier ici... .
Nommer la GPO O_WINDOWS_PWSHAUDIT puis cliquer sur le bouton OK.
Modifier la GPO puis accéder à la stratégie Configuration ordinateur / Stratégies / Modèles d'administration / Composants Windows / Windows PowerShell :
1. Accéder aux Propriétés de la stratégie Activer l'enregistrement des modules :
  1. Sélectionner l'option Activé¹ puis cliquer sue le bouton Afficher...².
  2. Depuis la boîte de dialogue Afficher le contenu, ajouter les modules Microsoft.PowerShell.* et Microsoft.WSMan.Management et cliquer sur le bouton OK pour valider.
  3. De retour sur la fenêtre des Propriétés, cliquer sur le bouton OK pour enregistrer.
2. Accéder aux Propriétés de la stratégie Activer la journalisation des blocs de scripts PowerShell :
  1. Sélectionner l'option Activé.
  2. Cocher l'option Consigner les événements de début/de fin des appels de blocs de script.
  3. Cliquer sur le bouton OK pour enregistrer les modifications.

Evénements à surveiller

Activités suspectes

Evénement	Description	Impact
1102/517	Le Journal des événements a été effacé	Les attaquants peuvent effacer les journaux des événements Windows pour masquer leurs traces.
4610/4611/4614/4622	Modification de l’autorité locale de sécurité	Les attaquants peuvent modifier LSA pour l’escalade/persistance.
4648	Connexion explicite aux informations d’identification	En règle générale, lorsqu’un utilisateur connecté fournit des informations d’identification différentes pour accéder à une ressource. Nécessite un filtrage de « normal ».
4661	Un handle vers un objet a été demandé	Accès SAM/DSA. Nécessite un filtrage de « normal ».
4672	Privilèges spéciaux attribués à la nouvelle ouverture de session	Surveillez quand une personne disposant de droits d’administrateur se connecte. S’agit-il d’un compte qui devrait avoir des droits d’administrateur ou d’un utilisateur normal ?
4723	Tentative de changement de mot de passe de compte	S’il ne s’agit pas d’un changement de pw approuvé/connu, vous devriez le savoir.
4964	Suivi personnalisé de la connexion à un groupe spécial	Suivez les connexions des administrateurs et des utilisateurs d’intérêt.
7045/4697	Un nouveau service a été installé	Les attaquants installent souvent un nouveau service pour la persistance.
4698 et 4702	Création/modification de tâches planifiées	Les attaquants créent/modifient souvent des tâches planifiées pour la persistance. Extraire tous les événements dans Microsoft-Windows-TaskScheduler/Operational
4719/612	La politique d’audit du système a été modifiée	Les attaquants peuvent modifier la politique d’audit du système.
4732	Un membre a été ajouté à un groupe local (sécurisé activé)	Les attaquants peuvent créer un nouveau compte local et l’ajouter au groupe Administrateurs local.
4720	Un compte utilisateur (local) a été créé	Les attaquants peuvent créer un nouveau compte local pour la persistance.
3065/3066	Audit LSASS – vérifie l’intégrité du code	Surveille les pilotes et les plugins LSA. Testez de manière approfondie avant de déployer !
3033/3063	Protection LSA : pilotes qui n’ont pas pu se charger	Surveille les pilotes et les plugins LSA et bloque ceux qui ne sont pas correctement signés.
4798	L’appartenance d’un utilisateur à un groupe local a été énumérée.	Activité de reconnaissance potentielle de l’appartenance à un groupe local. Filtrez l’activité normale.

Types d'ouverture de session (événement #4624)

Type ID	Nom	Description	Crédits sur disque	Crédits en mémoire
0	Système	Généralement rare, mais peut alerter d’une activité malveillante	Oui	Oui
2	Interactif	Connexion à la console (clavier local) qui inclut le serveur KVM ou l’ouverture de session au client virtuel. Aussi des RunAs standard.	Non	Oui
3	Réseau	distance PowerShell	Non	Non
4	Lot	Tâches planifiées	Oui	Oui
5	Service	Services	Oui	Oui
7	Ouvrir	Déverrouiller le système	Non	Oui
8	Texte clair réseau	probablement bien.	Peut-être	Oui
9	Nouvelles informations d’identification	RunAs /NetOnly qui démarre un programme avec des informations d’identification différentes de celles de l’utilisateur connecté	Non	Oui
10	Interactif à distance	RDP : Services Terminal, Assistance à distance, R.Desktop	Peut-être	Oui*
11	Interactif mis en cache	Ouvrir une session avec des informations d’identification mises en cache (pas de contrôleur de domaine en ligne)	Oui	Oui

https://adsecurity.org/?p=3299

Windows LAPS

Niveau ORADAD :	—
Score PingCastle :	15 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2019 et ultérieure Windows 10 éd. PRO/EDU/Enterprise et ultérieure
CVE :	—
Correctif(s) :	KB5025229


	Pour de plus amples informations sur la mise en place de cette sécurité, veuillez-vous référer à l'article dédié Windows LAPS.

Activer la protection étendue pour le rôle ADCS

Niveau ORADAD :	—
Score PingCastle :	10 Pt(s)
Mise en oeuvre :
Criticité :
Compatibilité :	Windows Server 2008 et ultérieure
CVE :	—
Correctif(s) :	KB5005413 T1557


	Cette stratégie concerne les environnements Active Directory disposant d'un serveur hébergeant le rôle Services de Certificats Active Directory (AD CS).

Objet de la stratégie

Une faille de sécurité récemment découverte dans le système d'exploitation Windows peut être exploitée pour forcer des serveurs Windows distants, y compris des contrôleurs de domaine, à s'authentifier auprès d'une destination considérée comme malveillante, permettant ainsi à un attaquant de mener une attaque par relais NTLM et in fine de prendre le contrôle complet d'un domaine Windows. La vulnérabilité, baptisée "PetitPotam", a été découvert par un chercheur, qui a partagé les détails techniques et les preuves de concept (PoC) la semaine dernière, notant que la faille fonctionne en forçant "les hôtes Windows à s'authentifier auprès d'autres machines via la fonction MS-EFSRPC EfsRpcOpenFileRaw".

— Source: CERT-FR Bulletin CERTFR-2021-ACT-032 du 26 juillet 2021

Mise en place de la stratégie


	Pour de plus amples informations sur la mise en place de cette sécurité, veuillez-vous référer à l'article dédié Activer la protection étendue et désactiver le protocole http pour les Services de certificats Active Directory.

Pour aller plus loin

@@ Ligne 975 : / Ligne 975 : @@
 ==== Objet de la stratégie ====
-{{Citation|'''LLMNR''' est un protocole de résolution de nom de domaine. '''LLMNR''' a été conçu pour traduire le nom localement au cas où le protocole DNS par défaut n’est pas disponible.
+{{Citation|'''LLMNR''' est un protocole de résolution de nom de domaine. '''LLMNR''' a été conçu pour traduire le nom localement au cas où le '''protocole DNS''' par défaut n’est pas disponible.
 Concernant '''Active Directory''', le DNS est obligatoire ce qui rend LLMNR inutile.<br />
-Le protocole LLMNR peut intervenir en cas de faute de frappe d'une adresse réseau. Il peut aussi répondre plus rapidement que le protocole DNS classique pour rediriger les utilisateurs vers un partage, un serveur ou un site Web spécialement conçu.<br />
+Le protocole '''LLMNR''' peut intervenir en cas de faute de frappe d'une adresse réseau. Il peut aussi répondre plus rapidement que le '''protocole DNS''' classique pour rediriger les utilisateurs vers un partage, un serveur ou un site Web spécialement conçu.<br />
 Étant approuvé, ce service déclenchera la procédure d’authentification unique qui peut être utilisée de manière abusive pour récupérer les informations d’identification de l’utilisateur.<br /><br />
-LLMNR est activé par défaut sur tous les systèmes d’exploitation, sauf à partir de Windows 10 v1903 et Windows Server v1903 où il est désactivé.|Source : PingCastle}}
+'''LLMNR''' est activé par défaut sur tous les systèmes d’exploitation, sauf à partir de Windows 10 v1903 et Windows Server v1903 où il est désactivé.|Source : PingCastle}}
 ==== Mise en place de la stratégie ====

« Active Directory Securisation » : différence entre les versions

Version du 22 juillet 2024 à 10:15

Outils d'évaluation

Outils d'audit

PingCastle

ORADAD

Outils de Pentest

Mimikatz

Nmap

Sécuriser l'exécution du service spouler d'impression

Objet de la stratégie

Correction au niveau des Contrôleurs de Domaine

Correction manuelle

Correction via GPO

Correction au niveau des postes clients

Configuration de Active Directory

Activer la corbeille Active Directory

Déclaration des sous réseaux

Négociation des échanges entre les clients et Active Directory

Niveau d'authentification LAN Manager pour les clients

Objet de la stratégie

Auditer les connexion NTLMv.1

Mise en place de la stratégie

Restriction des types de chiffrement autorisés pour Kerberos

Objet de la stratégie

Mise en place de la stratégie

Auditer la stratégie

Renforcement des chemins d’accès UNC

Objet de la stratégie

Mise en place de la stratégie

Blindage Kerberos

Application par GPO au niveau des clients

Application au niveau des contrôleurs de domaine (DC)

Paramétrage du silos d'authentification avec blindage Kerberos

Affectation du silo de stratégie d'authentification

Authentification

Protection LSA renforcée

Objet de la stratégie

Mise en place de la stratégie

Auditer la stratégie

Restrictions des comptes standards

Attribut dsHeuristics

Définition de l’attribut

Action corrective

Interdire aux utilisateur de pouvoir ajouter des ordinateurs au domaine

Objet de la stratégie

Action corrective

Restrictions des comptes à privilèges

Définition

Désactiver la délégation

Définition du paramètre

Action corrective

Protection du compte avec le groupe Protected Users

Définition du paramètre

Action corrective

Suppression de l'appartenance au groupe Administrateurs du schéma

Définition du paramètre

Action corrective

Interdire la connexion des comptes à privilèges sur les postes clients du domaine

Objet de la stratégie

Mise en place de la stratégie

Suppression des comptes administrateurs locaux sur les postes clients du domaine

Objet de la stratégie

Mise en place de la stratégie

Auditer les connexions administrateur du domaine

Stratégie de journalisation

Extraire la liste des connexions établies avec succès

Extraire la liste des connexions en échec

Stratégie des mots de passe

Expiration des mots de passe

Objet de la stratégie

Action corrective

Complexité des mots de passe

Objet de la stratégie

Action corrective

Forcer une longueur de mot de passe de 20 caractères pour les comptes gMSA

Objet de la stratégie

Mise en place de la stratégie

Gestion de la version de TLS supportée

Objet de la stratégie

« Active Directory Securisation » : différence entre les versions