Active Directory Securisation

— Rôles Active Directory —

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 (issue de la configuration par défaut de Windows Server 2019).

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, d'autres peuvent nécessiter de modifier la configuration de l'environnement Active Directory. Dans certain cas, cela peut avoir une incidence directe sur le bon fonctionnement de l'environnement Active Directory (clients et serveurs).

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.

1. Récupérer la dernière version de PingCastle depuis le site de l'éditeur https://www.pingcastle.com/.
2. Extraire le contenu de l'archive ZIP puis lancer l'exécution du fichier .
   
3. 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.
   
4. À 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.
   
5. Après quelques minutes d'analyse, le programme vous invitera à appuyer sur n'importe quelle touche pour quitter l'analyse.
   
6. 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.
   
7. 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.
     
8. Les quatre thématiques décrites à l'instant sont ensuite détaillées dans un tableau d'analyse des risques.
   
9. 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.

Niveau d'authentification LAN Manager pour les clients

Niveau ORADAD :
Score PingCastle :	15 Pt(s)
Mise en oeuvre :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

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

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
2. Faire un clic droit l'objet domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
3. Nommer la GPO O_WINDOWS_NTLMv2_ONLY puis cliquer sur le bouton OK.
   
4. 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².
   
5. 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.
   

Blindage Kerberos

Niveau ORADAD :	1
Score PingCastle :	— Pt(s)
Mise en oeuvre :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

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

Prérequis

Ce paramètre est compatible avec les systèmes d’exploitation à partir de Windows Server 2012, Windows 8 ou Windows RT.

Le mode forcé n’est pas compatible avec les environnement Windows 7 et Windows serveur 2008 et antérieur.

Application par GPO au niveau des clients

1. Ouvrir la console Gestion des stratégies de groupe avec un compte de privilèges Administrateurs du domaine.
2. Créer / Modifier la GPO nommée O_WINDOWS_KEBEROSARMORING puis renseigner les paramètres suivants :
   
3. Lier la GPO O_WINDOWS_KEBEROSARMORING à l’Unité d’Organisation racine du domaine.

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.

En l’état, le parc est équipé de machines vétustes de type Windows 7 et Windows Serveur 2008. On choisira un fonctionnement « hybride ».

1. Ouvrir la console Gestion des stratégies de groupe avec un compte de privilèges Administrateurs du domaine.
2. Créer / Modifier la GPO nommée O_WINDOWS_KERBEROSARMORING_AD puis renseigner les paramètres suivants :
   
3. Lier la GPO O_WINDOWS_KERBEROSARMORING_AD à l’Unité d’Organisation Domain Controllers.

Exiger le blindage pour les comptes membres des groupes spéciaux

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.

1. Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs du domaine.
2. Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
3. Se rendre dans le dossier Authentification / Authentification Policies puis créer / éditer la stratégie d’authentification nommée Force-auth-KerberosArmoring.
4. Depuis la section Général, sélectionner l’option Appliquer les restrictions de stratégie.
   

Imposer la préauthentification Kerberos

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.

1. Ouvrir le Centre d’administration Active Directory avec un compte de privilèges Administrateurs du domaine.
2. Basculer sur la vue Arborescence en cliquant sur l’onglet liste.
3. Se rendre dans le dossier Authentification / Authentification Policies puis créer / éditer la stratégie d’authentification nommée Force-auth-KerberosArmoring.
   1. Depuis la section Authentification de l’utilisateur :
      1. Activer l’option Spécifiez la durée de vie du ticket TGT pour les comptes d’utilisateur puis renseigner comme valeur 120¹.
      2. Pour définir les conditions d’application, cliquer sur le bouton Modifier… situé juste à côté du champ texte puis renseigner Utilisateur.AuthenticationSilo Est égal à « Silo-Auth-Admin-Restrictions »². Cliquer sur le bouton OK pour enregistrer la stratégie.
4. Se rendre dans le dossier Authentification / Authentification Policy Silos puis créer / éditer la stratégie de silos d’authentification nommée Silo-Auth-Admin-Restrictions.
   1. Depuis la section Général, sélectionner l’option Appliquer les stratégies du silo.
   2. Depuis la section Comptes autorisés, ajouter :
      1. Les comptes ordinateurs utilisés pour l’administration du système.
      2. Les comptes utilisateurs utilisés pour l’administration du système.
      3. Les comptes ordinateurs des équipements composant l’infrastructure du SI (Active Directory, Serveur de fichiers, Autorité de Certification locale).
   3. Depuis la section Stratégie d’authentification, sélectionner l’option Utilisez une seule stratégie pour tous les principaux qui appartiennent à ce silo de stratégies d’authentification puis sélectionner Force-Auth-KerberosArmoring. Cliquer sur le bouton OK pour enregistrer la stratégie.

Un redémarrage des équipements concernés pourra être requis pour la bonne application des paramètres.

Restrictions des comptes standards

Attribut dsHeuristics

Niveau ORADAD :	31
Score PingCastle :	— Pt(s)
Mise en oeuvre :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

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

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Modification ADSI.
2. 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.
      
3. 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.
   
4. 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.
     
5. 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 :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

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

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Modification ADSI.
2. Effectuer un clic droit sur l'objet racine du domaine (DC=ncad,DC=fr), puis cliquer sur Propriétés.
3. 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.
     
4. De retour sur la boîte de dialogue des Propriétés, cliquer sur le bouton OK pour sauvegarder les paramètres.
   

La stratégie par défaut de longueur des mots de passe est inférieure à 8 caractères

Niveau ORADAD :	2
Score PingCastle :	10 Pt(s)
Mise en oeuvre :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

Action corrective

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
2. 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 locales / 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².
   
3. 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.
   

Renforcement des chemins d’accès UNC

Niveau ORADAD :
Score PingCastle :	5 Pt(s)
Mise en oeuvre :	{{{mo}}}
Criticité :	{{{criticite}}}
Compatibilité :	{{{compatibilite}}}
CVE :	{{{CVE}}}
Correctif(s) :	{{{correctifs}}}

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

Action corrective

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
2. Faire un clic droit l'objet domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
3. Nommer la GPO O_WINDOWS_HARDENEDPATH puis cliquer sur le bouton OK.
   
4. 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.
   
5. 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 \\*\NETLOGON.
      • Dans le champ Valeur, saisir RequireMutualAuthentication=1,RequireIntegrity=1.
        
   3. Cliquer sur le bouton OK pour enregistrer les paramètres.
6. De retour sur la boîte de dialogue Propriétés, cliquer sur le bouton OK pour enregistrer la GPO.

Exiger la signature des requêtes 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.

Cette stratégie s’applique uniquement aux systèmes d’exploitation Microsoft à partir de Windows 10.

Auditer les connexions LDAP

	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

Action corrective

1. Ouvrir le Tableau de bord du Gestionnaire de serveur puis depuis le menu Outils, cliquer sur Gestions des stratégies de groupe.
2. Faire un clic droit la racine du domaine Active Directory puis Créer un objet GPO dans ce domaine, et le lier ici... .
3. Nommer la GPO O_WINDOWS_LDAPSIGN puis cliquer sur le bouton OK.
   
4. 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.
   
5. 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.