Active Directory Certificate Services (AD CS) : Principes et Fonctionnement

Dans le cadre de nos missions d’audit interne, nous rencontrons régulièrement des infrastructures AD CS (Active Directory Certificate Services) déployées sur les réseaux d’entreprise.

Ce composant retient systématiquement notre attention, car une configuration inadéquate peut rapidement ouvrir la voie à une compromission totale du domaine Active Directory.

Malheureusement, AD CS est souvent déployé sans les précautions de sécurité nécessaires. Ce manque de rigueur offre des opportunités pour les attaquants. En 2021, plusieurs travaux ont mis en lumière les risques liés à AD CS. Les recherches de SpecterOps ont notamment démontré comment exploiter des déploiements mal configurés. La même année, la vulnérabilité PetitPotam a été révélée. Elle permet à un attaquant non authentifié de compromettre un domaine entier via AD CS.

Nous reviendrons plus en détail sur les failles spécifiques d’AD CS et les techniques d’exploitation (notamment les attaques ESC) dans un prochain article. Celui-ci se concentre sur les principes de fonctionnement d’AD CS, son rôle dans un environnement Active Directory, ainsi que les mécanismes de gestion des certificats qu’il met en œuvre.

Guide complet sur le fonctionnement d’AD CS

Qu’est-ce qu’AD CS ?

Dans un environnement Active Directory, Active Directory Certificate Services (AD CS) constitue l’implémentation de l’infrastructure à clé publique (PKI – Public Key Infrastructure) de Microsoft. Ce service permet de gérer les mécanismes de chiffrement, les certificats numériques et les signatures électroniques.

Grâce à AD CS, il devient possible de renforcer la sécurité des échanges et des authentifications en associant l’identité d’un utilisateur, d’une machine ou d’un service à une clé privée correspondante. Pour faire simple, AD CS est utilisé pour émettre, gérer et révoquer des certificats numériques.

AD CS repose sur plusieurs composants fondamentaux :

• L’Autorité de Certification (CA) : au sommet de la hiérarchie PKI, elle est chargée de signer les certificats. La Root CA (CA racine), souvent conservée hors ligne pour des raisons de sécurité, peut être intégrée à Active Directory ; on parle alors d’Enterprise CA.
• L’Autorité de Certification Subordonnée (Subordinate CA) : elle s’occupe de l’émission, la gestion et la révocation des certificats au quotidien. Contrairement à la Root CA, elle est maintenue en ligne.
• Les Points de Distribution des Certificats (CDP) : ils hébergent les Listes de Révocation des Certificats (CRL), permettant de vérifier si un certificat est toujours valide ou a été révoqué.
• Le service Online Responder : il utilise le protocole OCSP (Online Certificate Status Protocol) pour fournir une réponse rapide sur le statut d’un certificat.
• Les clients : ce sont les entités (utilisateurs, machines, services) qui utilisent les certificats pour s’authentifier, chiffrer des données ou signer des documents.

Comprendre l’architecture AD CS, c’est bien. Mais depuis le début, nous parlons de certificats. Il est donc pertinent de regarder de plus près ce qu’ils contiennent, comment ils sont générés et pourquoi leur intégrité est si cruciale.

Comprendre les certificats AD CS

Informations principales d’un certificat

Les certificats délivrés par AD CS respectent la norme X.509 (RFC 5280). Chaque certificat inclut un ensemble de champs standards, parmi lesquels :

1. La version du certificat : indique la version du format X.509 (généralement la version 3).
2. Le numéro de série : identifie de manière unique chaque certificat émis par une CA. Ce numéro est notamment utilisé lors de la révocation.
3. l’émetteur (Issuer) : autorité ayant délivré le certificat, exprimée sous forme de Distinguished Name (DN), par exemple DC=local, DC=essos, CN=ESSOS-CA.
4. La période de validité : plage temporelle pendant laquelle le certificat est valide (date de début et date d’expiration).
5. Le sujet (Subject) : entité à laquelle le certificat est attribué, également sous forme de DN, ex : DC=local, DC=essos, CN=Users, CN=khal.drogo.
6. La clé publique : associée au sujet du certificat, elle sert au chiffrement des données et à la vérification des signatures.
7. La signature du certificat : elle est produite par la CA émettrice pour garantir l’intégrité du certificat et éviter toute falsification.

À noter qu’en possédant uniquement le certificat, il n’est pas possible de s’authentifier sur un service ou de demander un ticket TGT, car il faut être en possession de la clé privée.

Extensions de certificat

Un certificat X.509 délivré par AD CS ne se limite pas aux seules informations de base. Il embarque également un ensemble d’extensions, qui jouent un rôle essentiel dans la définition des usages autorisés et dans le renforcement (ou non) de la sécurité.

Ces champs supplémentaires apportent des fonctionnalités avancées, mais ils sont également une porte d’entrée pour des attaquants.

Parmi les extensions les plus couramment rencontrées, certaines méritent une attention particulière.

Key Usage

Key Usage (1) spécifie les opérations cryptographiques que le certificat est autorisé à effectuer.

Le standard X.509 définit neuf usages possibles, tels que la signature numérique (Digital Signature), le chiffrement de clé (Key Encipherment), la signature de certificat, ou encore la signature de liste de révocation.

Ce champ permet donc de restreindre, ou au contraire d’élargir, l’usage technique du certificat.

Extended Key Usage (EKU)

Extended Key Usage (2) affine encore davantage les possibilités d’utilisation en précisant les cas d’usage applicatifs prévus pour le certificat.

On y trouve, par exemple, les valeurs « Client Authentication », « Email Protection » ou encore « Smartcard Logon ». Ces indications permettent aux services consommateurs de certificats de vérifier que le certificat présenté correspond bien au contexte attendu.

Une mauvaise configuration de ces EKU peut entraîner de graves conséquences, notamment en permettant à un certificat de s’authentifier à des services auxquels il ne devrait pas avoir accès.

Subject Alternative Name (SAN)

L’extension Subject Alternative Name (2) complète l’identification de l’entité titulaire du certificat.

Elle permet d’ajouter des identifiants secondaires, tels que des noms DNS ou des UPN (User Principal Name). Cette flexibilité est particulièrement exploitée dans les certificats de serveurs web ou dans les scénarios d’authentification où un même certificat doit être reconnu sous plusieurs identités.

Là encore, une configuration trop permissive peut créer des opportunités pour un attaquant, en autorisant par exemple l’usurpation d’un nom DNS critique.

Formats de fichiers

Impossible de passer à côté d’un élément crucial des certificats : les formats de fichiers.

Sur le terrain, en audit ou en phase de post-exploitation, on tombe souvent sur des extensions aussi variées que mystérieuses : .pem, .crt, .pfx, etc.

p12/pfx

Le format .p12 (ou .pfx sous Windows) est certainement le plus répandu lorsqu’il s’agit de gérer des certificats utilisateurs.

Décrit dans la RFC 7292 (PKCS #12), ce format a une particularité intéressante : il contient à la fois le certificat X.509 et la clé privée associée. Et pour éviter les mauvaises surprises, l’ensemble est protégé par un mot de passe.

Côté Windows, .pfx est la norme historique imposée par Microsoft, mais dans les faits, .p12 et .pfx sont techniquement identiques.

Sur un système Linux, on peut facilement les inspecter ou les convertir avec openssl :

# Afficher le contenu d’un fichier .p12/.pfx
openssl pkcs12 -in certificat.p12 -info

# Extraire le certificat sans la clé privée
openssl pkcs12 -in certificat.pfx -clcerts -nokeys -out certificat.pem

pem/crt

Les extensions .pem et .crt désignent des fichiers contenant uniquement le certificat public, sans la clé privée.

• Le .pem est le plus explicite : il s’agit d’un encodage Base64, encadré par les fameuses balises -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----.
• Le .crt, quant à lui, est un peu plus ambigu : il peut désigner un certificat encodé en Base64 (comme un .pem) ou en binaire pur (format DER). En pratique, tout dépend du contexte d’utilisation.

Pour lire le contenu d’un certificat .pem ou .crt, la commande suivante suffit :

openssl x509 -in certificat.crt -text -noout

Comment AD CS génère les certificats ?

Après avoir exploré le fonctionnement général d’AD CS et la structure d’un certificat, il reste une question clé : comment ces certificats sont-ils générés ?

Templates des certificats AD CS

Pour mieux comprendre, imaginons que les certificats délivrés dans un domaine soient comparables à des badges d’accès. Ces badges permettent aux utilisateurs de prouver leur identité, d’accéder à certaines ressources ou d’authentifier des services.

Plutôt que de concevoir chaque badge manuellement, on établit des modèles standards, appelés templates. Il existe par exemple un modèle pour les visiteurs, un pour les employés, un pour les administrateurs, etc.

Chaque template spécifie un ensemble de caractéristiques comme :

• Les autorisations associées (accès à certaines ressources ou services)
• La durée de validité du certificat
• Les critères d’attribution
• Et les entités autorisées à faire une demande basée sur ce modèle

Dans AD CS, les templates permettent de normaliser l’émission des certificats, d’automatiser leur déploiement, et d’en contrôler l’usage selon les rôles et les besoins des utilisateurs ou des machines. Autrement dit, ils assurent que chaque utilisateur reçoit un certificat qui correspond précisément à son profil.

Mais attention : une mauvaise configuration d’un template peut vite devenir un vecteur d’attaque. Si, par exemple, le modèle prévu pour les visiteurs permet accidentellement un accès privilégié aux systèmes critiques, alors n’importe quel utilisateur disposant de ce certificat pourrait en profiter.

Propriétés des templates AD CS

Les propriétés des templates sont identifiées par des OID (Object Identifiers). Ces propriétés déterminent avec précision les conditions d’émission d’un certificat, son usage et les droits associés.

Chaque template est défini par :

• Un nom interne, utilisé par le service de certification pour sa gestion, et par un nom complet, plus lisible, destiné à faciliter son identification par les administrateurs.
• Un numéro de version, permettant de suivre les modifications.
• Et un type, indiquant s’il s’agit d’un certificat destiné à un utilisateur, une machine ou un service particulier.

Concernant la durée de vie du certificat, deux paramètres sont clés :

• La période de validité, généralement exprimée en mois ou en années.
• La période de renouvellement, qui détermine à partir de quand un certificat peut être renouvelé avant son expiration. Ce mécanisme permet d’anticiper les interruptions de service ou d’éviter une gestion manuelle des renouvellements.

Les droits d’accès à un template sont gérés via une ACL (Access Control List). Celle-ci permet par exemple d’autoriser certains utilisateurs ou groupes à demander un certificat via le droit « Enroll », ou de permettre une délivrance automatique via le droit « Autoenroll », souvent utilisé pour les machines ou comptes intégrés dans Active Directory. Le droit « Read », quant à lui, donne accès à la lecture des propriétés du template.

Un autre élément clé est la manière dont le nom du sujet (Subject Name) est défini. Ce nom représente l’identité qui figurera dans le certificat final. Il peut être construit automatiquement à partir des attributs Active Directory de l’utilisateur ou de la machine, ou bien saisi manuellement.

Enfin, les templates intègrent des extensions qui précisent ce que le certificat est autorisé à faire.

• L’extension « Key Usage », identifiée par l’OID 2.5.29.15, définit les opérations cryptographiques permises, comme la signature numérique ou le chiffrement.
• De son côté, « Extended Key Usage » (OID 2.5.29.37) précise les usages applicatifs du certificat. Elle peut, par exemple, indiquer qu’un certificat est destiné à l’authentification d’un client (OID 1.3.6.1.5.5.7.3.2) ou à une connexion via carte à puce (OID 1.3.6.1.4.1.311.20.2.2).

Processus d’émission d’un certificat par AD CS

Après avoir exploré la manière dont sont définis les modèles de certificats, il est temps de se pencher sur le processus concret d’émission d’un certificat par AD CS.

Préparation de la demande

Le point de départ se situe toujours du côté du client, qu’il s’agisse d’un utilisateur ou d’une machine.

Ce dernier génère une paire de clés cryptographiques : une clé privée, conservée précieusement en local, et une clé publique destinée à être communiquée. En parallèle, le client crée une demande de certificat, connue sous le nom de CSR (Certificate Signing Request).

Ce fichier contient toutes les informations nécessaires pour que l’autorité de certification puisse émettre un certificat valide : identité du demandeur, usages souhaités, extensions, et bien sûr la clé publique.

Il est essentiel de souligner que la clé privée ne quitte jamais le client. Seule la clé publique est incluse dans la CSR, ce qui constitue une garantie de sécurité fondamentale dans le processus.

Envoi de la demande

Une fois la demande prête, le client transmet son CSR à l’autorité de certification, en l’occurrence AD CS, pour traitement.

Cette opération peut se faire automatiquement, selon la configuration du système et les droits attribués au client.

Vérification par l’AD CS

Avant de délivrer un certificat, AD CS procède à une série de contrôles rigoureux.

• Elle s’assure tout d’abord que le modèle de certificat demandé existe bien et qu’il est actif.
• Ensuite, elle vérifie si le client dispose bien des autorisations nécessaires pour utiliser ce modèle, notamment les droits « Enroll » ou « Autoenroll », tels que définis dans le template.
• Enfin, AD CS examine le contenu même de la demande pour s’assurer de sa conformité avec les contraintes définies dans le modèle : Subject Name, usages, extensions, etc.

Émission ou rejet du certificat

Si toutes les conditions sont réunies, AD CS procède à la création du certificat. Elle le signe à l’aide de sa propre clé privée, garantissant ainsi l’authenticité du document, puis le transmet au client.

Cependant, certains paramètres de sécurité supplémentaires peuvent altérer ce processus ou empêcher sa finalisation automatique. Il existe notamment deux protections souvent méconnues, mais pourtant cruciales.

• La première est l’approbation manuelle par un administrateur, connue sous le nom de CA certificate manager approval. Lorsqu’elle est activée, chaque demande doit être examinée et approuvée manuellement.
• La seconde concerne les signatures autorisées. Il est possible de configurer un modèle de certificat pour exiger que chaque CSR soit signée par un certificat émis par une autorité spécifique. Cette exigence revient à demander une validation hiérarchique, comme si toute demande d’accès devait être approuvée par un responsable sécurité.

Dans le cadre d’un pentest Active Directory, ces deux mécanismes doivent être absents pour que les scénarios d’exploitation soient valides. Fort heureusement (ou malheureusement, selon le point de vue), dans les environnements que nous auditons, ces protections sont rarement mises en œuvre.

Stockage du certificat

Une fois le certificat délivré, celui-ci est automatiquement stocké sur le poste client, dans le Windows Certificate Store. Il est alors immédiatement disponible pour les usages prévus : authentification, signature électronique ou encore chiffrement.

Ce certificat devient ainsi un élément central du fonctionnement sécurisé de l’environnement Active Directory.

Fonctionnement du mapping des certificats

Le mapping des certificats désigne le processus par lequel un contrôleur de domaine (DC) associe un certificat reçu à un compte utilisateur ou machine dans Active Directory.

Ce mécanisme peut être implicite ou explicite, et qualifié de fort (strong) ou de faible (weak), selon le niveau de vérification effectué.

Mapping implicite et mapping explicite

Dans le cas du mapping implicite, le DC s’appuie sur le contenu même du certificat pour identifier son porteur.

Il commence par extraire l’attribut Subject Alternative Name (SAN). S’il s’agit d’un certificat utilisateur, il tente de faire correspondre l’entrée otherName de type UPN (User Principal Name) avec l’attribut userPrincipalName dans l’AD. Si cette tentative échoue, il vérifie l’attribut sAMAccountName, voire ce dernier suffixé d’un dollar ($) dans le cas des comptes machines. Pour un certificat destiné à une machine, le DC utilise la valeur dNSName et cherche une correspondance avec l’attribut dNSHostName de l’objet correspondant. À défaut, les mêmes vérifications que pour un certificat utilisateur peuvent être appliquées.

Le mapping explicite, quant à lui, repose sur une association manuelle entre un certificat et un compte AD.

Celle-ci est enregistrée dans l’attribut altSecurityIdentities de l’objet concerné. Cette méthode offre un contrôle précis sur quels certificats sont autorisés, mais implique une gestion plus lourde.

Mapping faible, mapping fort et sécurité

La distinction entre un mapping faible et un mapping fort repose sur le niveau de confiance accordé aux informations extraites du certificat.

Un mapping faible consiste simplement à associer un certificat à un compte en se basant sur des champs comme le UPN ou le DNS Name, sans réelle vérification de l’identité. Cela ouvre la voie à des attaques, notamment si un attaquant parvient à se procurer un certificat avec un SAN forgé.

Pour contrer cela, Microsoft a introduit en mai 2022, à la suite de la vulnérabilité Certifried (CVE-2022-26923), plusieurs mécanismes renforçant le mapping fort :

• Les certificats incluent désormais une extension de sécurité szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2), contenant le objectSid de l’utilisateur demandeur. Ce champ, unique à chaque utilisateur AD, permet au DC de vérifier avec précision l’identité du porteur.
• Cette vérification peut toutefois être contournée si le modèle de certificat est mal configuré. En activant le flag CT_FLAG_NO_SECURITY_EXTENSION (0x80000) dans l’attribut msPKI-Enrollment-Flag, l’extension de sécurité est désactivée, ramenant le mapping à un mode faible.
• Deux clés de registre peuvent être configurées sur les DC pour renforcer ce comportement : CertificateMappingMethods, qui contrôle la méthode de mappage pour l’authentification TLS/SSL (Schannel), et StrongCertificateBindingEnforcement, qui impose la vérification du propriétaire du certificat.

Conséquences pratiques et posture actuelle

Depuis mai 2022, les environnements Active Directory correctement mis à jour et configurés peuvent imposer un mapping fort, rendant l’exploitation des certificats beaucoup plus difficile pour un attaquant.

En pratique toutefois, ces mesures de sécurité sont rarement activées, que ce soit par méconnaissance ou pour éviter une surcharge administrative.

Ainsi, le mapping implicite faible reste la configuration par défaut dans la majorité des environnements audités. Combiné à une mauvaise configuration des templates de certificats, il constitue un vecteur d’attaque particulièrement attractif, que les attaquants exploitent pour usurper des identités et compromettre des systèmes entiers.

Conclusion

Active Directory Certificate Services (AD CS) joue un rôle central dans la gestion des identités, des accès et de la confiance au sein des environnements Windows. En permettant la délivrance, la gestion et la révocation de certificats numériques, il constitue la pierre angulaire de nombreuses fonctions de sécurité.

Dans cet article, nous avons exploré notamment les composants clés d’AD CS et le fonctionnement des modèles de certificats (templates). Ces éléments, souvent en arrière-plan du quotidien des utilisateurs, sont pourtant essentiels à la sécurité et au bon fonctionnement de l’infrastructure Active Directory dans son ensemble.

Les infrastructures AD CS restent encore trop souvent mal sécurisées. Comme nous avons pu le voir, un simple mauvais paramétrage (par exemple un template permissif) peut offrir à un attaquant un accès privilégié aux systèmes les plus sensibles.

Dans un prochain article, nous reviendrons en détail sur les vulnérabilités courantes liées à AD CS, les scénarios d’attaque concrets qui en découlent, ainsi que les bonnes pratiques pour sécuriser efficacement cette brique souvent sous-estimée mais hautement stratégique.

Auteur : Adrien HOC – Pentester @Vaadata