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

Outils d'évaluation

Les outils d'évaluation présentés ont fonctionné sur un environnement Active Directory de test (issue de la configuration par défaut de Windows Server 2019).

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.

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écrite à 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 :	1 si fAllowAnonNSPI est différent de 0 1 si dwAdminSDExMask est différent de 0 2 si fLDAPBlockAnonOps est égal à 2 2 si DoNotVerifyUPNAndOrSPNUniqueness est différent de 0 (KB5008382) 2 si AttributeAuthorizationOnLDAPAdd est égal à 2 (KB5008383) 2 si BlockOwnerImplicitRights est égal à 2 (KB5008383) 4 si AttributeAuthorizationOnLDAPAdd est différent de 1 (KB5008383) 4 si BlockOwnerImplicitRights est différent de 1 (KB5008383) 1
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.