Durcir Active Directory (3/4) : AD CS, ACL, délégations et approbations.

Les chemins traités ici ont une particularité qui les rend redoutables : ils n'exploitent aucune vulnérabilité. Rien n'est cassé, aucun correctif n'est manquant, tout fonctionne exactement comme le produit le prévoit. Un modèle de certificat trop ouvert, un droit d'écriture sur un groupe, une machine autorisée à déléguer : ce sont des configurations, et c'est précisément pour cela qu'elles survivent aux campagnes de correctifs et n'apparaissent dans aucun bulletin de sécurité.

Ce qu'il vous faut

• Des droits d'administration du domaine, et - si vous avez une autorité de certification interne - des droits d'administration sur celle-ci.
• Le module PowerShell Active Directory, et la console des modèles de certificats (certtmpl.msc) sur un poste d'administration.
• Idéalement, un outil d'audit d'annuaire (PingCastle, Purple Knight) pour dégrossir : les ACL ne se lisent pas à l'œil sur un domaine réel.

1. AD CS : l'autorité de certification est un contrôleur de domaine déguisé

Si votre annuaire héberge une autorité de certification interne, elle mérite exactement le même niveau de protection qu'un contrôleur de domaine. La raison est simple : un certificat d'authentification vaut une identité. Une autorité de certification qui accepte de délivrer un certificat au nom d'un administrateur de domaine délivre les droits d'administration du domaine, sans jamais toucher aux permissions de l'annuaire, et sans qu'aucun groupe à privilèges ne soit modifié.

Preuve que le sujet reste vivant : la vulnérabilité CVE-2026-54121 (« Certighost », CVSS 8,8), corrigée par Microsoft le 14 juillet 2026. Son mécanisme illustre bien le type de confiance implicite qui se cache dans AD CS : lorsque l'autorité de certification n'arrive pas à résoudre l'identité du demandeur, elle interroge en repli un contrôleur de domaine désigné par le demandeur lui-même, sans vérifier qu'il s'agit d'un véritable contrôleur de domaine. Un compte de domaine ordinaire suffisait alors à se faire passer pour un contrôleur de domaine, et à obtenir les droits correspondants. Un code d'exploitation public circule depuis le 24 juillet 2026 : si votre autorité de certification n'a pas reçu la mise à jour de juillet 2026, c'est la première chose à traiter en refermant cette page.

a. Inventorier

Recensez les autorités de certification, les modèles publiés, les groupes autorisés à s'inscrire, les agents d'inscription, l'inscription automatique, et les modèles inutilisés :

certutil -CATemplates
certutil -dump

b. Les deux réglages qui font la différence

Pour chaque modèle permettant une authentification (usage étendu « authentification du client », « ouverture de session par carte à puce », ou tout usage), examinez :

La combinaison qui doit déclencher une alerte immédiate : inscription ouverte largement + sujet fourni par le demandeur + usage d'authentification + aucune approbation. C'est la configuration connue sous le nom d'ESC1 dans la littérature de sécurité, et elle transforme n'importe quel compte du domaine en administrateur de domaine.

c. Réduire et séparer

• Dépubliez les modèles inutilisés : un modèle non publié n'est pas une surface d'attaque. C'est la mesure la plus rentable de cette section, et la moins risquée.
• Traitez les administrateurs de la PKI comme du palier 0 (voir la partie 1) : leurs comptes, leurs postes, leurs droits.
• Patchez l'autorité de certification au rythme d'un contrôleur de domaine, pas à celui d'un serveur applicatif.

2. Les ACL : le chemin invisible

Les listes de contrôle d'accès d'Active Directory sont sa mécanique la plus puissante et la plus opaque. Elles s'accumulent au fil des années : une délégation posée pour un projet, un droit accordé « temporairement » à un prestataire, un groupe imbriqué dans un autre. Personne ne les relit, et elles ne déclenchent jamais d'alerte.

Cinq droits transforment leur détenteur en propriétaire de fait de l'objet visé :

Ces droits sont à auditer en priorité sur : les comptes et groupes à privilèges, les unités d'organisation qui les contiennent, les objets des contrôleurs de domaine, et la racine du domaine.

$dn = (Get-ADDomain).DistinguishedName

# Racine du domaine
(Get-Acl "AD:\$dn").Access |
    Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner|ExtendedRight' } |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

# Une unite d'organisation sensible
(Get-Acl "AD:\OU=Serveurs,$dn").Access | Format-List

Un outil d'audit d'annuaire fait ce travail bien mieux qu'une lecture manuelle, parce qu'il suit les chaînes : l'utilisateur A peut modifier le groupe B, qui a un droit sur l'unité d'organisation C, qui contient le compte D qui est administrateur. Aucune de ces quatre étapes n'est anormale prise isolément.

AdminSDHolder : le mécanisme qu'on découvre trop tard

AdminSDHolder est un objet du domaine qui porte un modèle de permissions. Toutes les heures, un processus recopie ce modèle sur tous les comptes et groupes protégés (Domain Admins, Enterprise Admins, et une quinzaine d'autres). C'est une protection : elle rétablit les droits corrects même si quelqu'un les a modifiés.

C'est aussi, retournée, une porte dérobée redoutable : un attaquant qui ajoute un droit sur AdminSDHolder voit ce droit propagé automatiquement sur tous les comptes à privilèges, dans l'heure. Et si vous retirez le droit sur un compte sans nettoyer AdminSDHolder, il revient tout seul - beaucoup d'équipes ont passé des jours à chercher pourquoi une permission « supprimée » réapparaissait.

$dn = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\CN=AdminSDHolder,CN=System,$dn").Access |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

Cette liste doit être courte, connue, et surveillée : toute modification mérite une alerte (voir la partie 4).

3. Les délégations Kerberos

La délégation permet à un service d'agir au nom de l'utilisateur qui s'y est authentifié. C'est légitime - un serveur web qui interroge une base de données au nom de l'utilisateur connecté - mais la forme non contrainte est un chèque en blanc : la machine qui la détient conserve le ticket de tout compte qui s'y authentifie, et peut s'en servir vers n'importe quel service. Y compris le ticket d'un administrateur de domaine venu dépanner.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
               -Properties TrustedForDelegation, OperatingSystem

Get-ADUser -Filter {TrustedForDelegation -eq $true} `
           -Properties TrustedForDelegation

Les contrôleurs de domaine apparaissent normalement dans cette liste. Tout le reste doit avoir une justification métier écrite - ou perdre ce droit. Quand la délégation est réellement nécessaire, utilisez sa forme contrainte, qui limite les services accessibles.

Le pendant de cette mesure est côté comptes, et il est traité en partie 1 : marquer les comptes sensibles comme non délégables. Les deux se complètent : l'un réduit qui peut déléguer, l'autre protège qui ne doit jamais l'être.

4. Comptes de service : passer aux gMSA

Le compte de service à mot de passe statique est la dette de sécurité la plus répandue dans un Active Directory. Son mot de passe n'a pas changé depuis l'installation de l'application, il est souvent noté dans une documentation partagée, il porte un SPN qui le rend vulnérable au kerberoasting, et il détient fréquemment bien plus de droits que nécessaire parce que « ça ne marchait pas autrement ».

Commencez par les recenser :

Get-ADUser -Filter * -Properties ServicePrincipalName, PasswordNeverExpires, PasswordLastSet |
    Where-Object { $_.ServicePrincipalName -or $_.PasswordNeverExpires } |
    Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName

Les comptes de service administrés de groupe (gMSA) confient la gestion du mot de passe à l'annuaire lui-même : 240 caractères, renouvelé automatiquement tous les 30 jours, jamais connu d'un humain, jamais écrit nulle part.

# Une seule fois par foret : la cle racine KDS
Get-KdsRootKey        # verifier si elle existe deja
Add-KdsRootKey -EffectiveImmediately

# Un compte gMSA, utilisable par les membres d'un groupe donne
New-ADServiceAccount -Name "gmsa-web01" `
    -DNSHostName "web01.exemple.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-gMSA-Web01"

# Sur le serveur qui l'utilise
Install-ADServiceAccount gmsa-web01
Test-ADServiceAccount   gmsa-web01

Profitez de la migration pour réduire les droits : un compte de service ne doit détenir que les permissions applicatives dont il a besoin. Presque jamais Domain Admins, même si c'est ce que demande la documentation de l'éditeur.

5. Les relations d'approbation

Une approbation est une frontière de confiance : elle décide de ce qu'un domaine voisin - et donc un attaquant qui l'aurait compromis - peut atteindre chez vous. Elles survivent souvent aux projets qui les ont créées, aux fusions, aux prestataires partis depuis longtemps.

Get-ADTrust -Filter * |
    Select-Object Name, Direction, TrustType, ForestTransitive,
                  SelectiveAuthentication, SIDFilteringForestAware

Pour chacune, quatre questions : pourquoi existe-t-elle, qui l'utilise, pour quelle application, et depuis quand. Une approbation sans réponse à ces quatre questions se supprime.

Pour celles qui restent :

• La direction minimale. Une approbation bidirectionnelle double la surface de confiance ; si un seul sens est utilisé, n'en gardez qu'un.
• Le filtrage de SID (SID filtering). C'est le mécanisme qui empêche un domaine approuvé d'injecter, dans les jetons d'authentification qu'il vous envoie, des identifiants de sécurité appartenant à votre domaine - typiquement celui de vos administrateurs. Sans lui, compromettre le petit domaine d'une filiale suffit à se présenter chez vous comme administrateur du domaine principal. Il est actif par défaut sur les approbations externes et inter-forêts créées récemment, mais il est régulièrement désactivé à la main lors de migrations - parce qu'il empêche justement l'historique de SID de fonctionner - puis jamais réactivé une fois la migration terminée. Vérifiez-le explicitement plutôt que de le supposer : c'est un des rares réglages dont la désactivation est à la fois invisible et totale.
• L'authentification sélective. Par défaut, les comptes du domaine approuvé peuvent tenter de s'authentifier partout chez vous. L'authentification sélective inverse ce principe : ils n'accèdent qu'aux serveurs sur lesquels le droit leur a été explicitement accordé. C'est le bon réglage pour une approbation avec un partenaire externe.

6. Stratégies de groupe et SYSVOL

Une GPO liée à l'unité d'organisation des contrôleurs de domaine s'exécute sur les contrôleurs de domaine. C'est une prise de contrôle totale, automatique, et qui ne déclenche aucune alerte par défaut.

• Restreignez qui peut créer, modifier et lier une GPO - le droit de lier est le plus souvent oublié, alors que c'est lui qui décide où une stratégie s'applique.
• Préférez plusieurs GPO spécialisées à une seule très grosse : cela simplifie le dépannage, les tests, l'analyse des conflits, et surtout le retour arrière - qui est ce dont vous aurez besoin le jour où une mesure de ce guide cassera quelque chose.
• Vérifiez l'absence de mots de passe dans SYSVOL : la vulnérabilité historique dite « cpassword » stockait dans les préférences de GPO des mots de passe chiffrés avec une clé publiée par Microsoft. Corrigée depuis longtemps côté produit, elle laisse des traces dans les domaines anciens jamais nettoyés :

  Get-ChildItem "\\exemple.local\SYSVOL\exemple.local\Policies" -Recurse -Include *.xml |
      Select-String "cpassword"

• Auditez les modifications de GPO (événement 5136) - toute modification hors fenêtre de changement planifiée mérite une vérification immédiate.

Vérifier que c'est en place

1. AD CS : aucun modèle publié ne cumule inscription large, sujet fourni par le demandeur et usage d'authentification. Reprenez la liste modèle par modèle, pas de sondage.
2. Délégation : Get-ADComputer -Filter {TrustedForDelegation -eq $true} ne renvoie que des contrôleurs de domaine.
3. AdminSDHolder : sa liste de contrôle d'accès correspond à une liste de référence que vous avez écrite et datée.
4. gMSA : Test-ADServiceAccount renvoie True sur chaque serveur migré, et les anciens comptes de service correspondants sont désactivés.
5. Approbations : chaque ligne de Get-ADTrust a un propriétaire nommé et une justification écrite.
6. Un outil d'audit d'annuaire repassé après le chantier ne remonte plus les chemins de privilèges que vous venez de couper - c'est le seul contrôle qui vérifie les chaînes plutôt que les droits isolés.

Sources

• ANSSI - Recommandations de sécurité relatives à Active Directory (ANSSI-PA-099)
• Microsoft Learn - AD CS et modèles de certificats
• Microsoft MSRC - CVE-2026-54121 (correctif du 14 juillet 2026)
• Microsoft Learn - Comptes de service administrés de groupe (gMSA)
• Microsoft Learn - Identifiants de sécurité et filtrage de SID
• Kenawek - Kerberoasting : ce que c'est, comment ça marche, comment s'en protéger