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

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.

1. 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 la console Modification ADSI avec un compte appartenant au groupe Admins. du domaine.
2. Basculer sur le contexte d’attribution Configuration, si cela n’est pas déjà fait :
   1. Effectuer un clic droit sur l’objet [AD1SRV.domaine.tld] puis sur l’item Paramètres… depuis le menu contextuel.
      [Image:DSH_ADSI_SETTINGS.png]
   2. Depuis la boîte de dialogue, dans la section Sélectionner un contexte d’attribution, choisir Configuration puis cliquer sur le bouton OK.
      [Image:DSH_ADSI_SETTINGS_CONNEXION.png]
3. Développer l’arborescence LDAP pour pouvoir accéder aux paramètres de l’objet CN=Directory Service présent depuis le chemin CN=Windows NT,CN=Services,CN=Configuration,DC=domaine,DC=tld.
   [Image:DSH_ADSI_CONFIGURATION_DIRECTORY_SERVICE.png]
4. Accéder aux Propriétés de l’objet en faisant un clic droit puis Propriétés… .
   1. Sélectionner l’attribut dSHeuristics puis cliquer sur le bouton Modifier.
   2. Saisir la valeur 00000000010000000002000000011 puis cliquer sur le bouton Modifier.
      [Image:DSH_ADSI_CONFIGURATION_DIRECTORY_SERVICE_PROPERTIES.png]