Quelque chose que j'ai dû expliquer au sujet d'ADCS plus de fois que je peux compter : les modèles de certificats ne font pas partie d'ADCS.
Ils vivent dans la partition de configuration d'Active Directory, sous Services → Public Key Services → Certificate Templates. Le chemin LDAP complet est CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...
ADCS les lit. AD les possède.
Ce n'est pas une distinction pour le plaisir d'avoir raison. Ça change la façon de raisonner sur l'ensemble de la pile.
Désinstallez ADCS de tous les serveurs de votre forêt. Les modèles sont toujours là. Les modèles se répliquent par la réplication AD normale, comme les utilisateurs et les groupes. Chaque AC de la forêt voit les mêmes modèles parce qu'elles lisent toutes dans le même annuaire. Vous configurez un modèle une fois, chaque AC de la forêt peut émettre à partir de celui-ci.
AD est la couche d'identité et d'autorisation
Ce que ça veut dire concrètement, c'est qu'AD fournit la couche d'identité et d'autorisation pour l'AC. Qui vous êtes, dans quels groupes vous êtes, si vous avez le droit de vous inscrire à un modèle donné, tout ça se décide dans AD avant que l'AC entre en jeu. Le module de stratégie de l'AC évalue la demande et le moteur de signature fait le travail cryptographique, mais les décisions d'éligibilité vivent un étage plus haut, dans l'annuaire.
Dans l'architecture PKI classique, ce travail est partagé entre une AE (autorité d'enregistrement) et une AC. Dans Microsoft ADCS, AD fait la plus grande partie du travail d'une AE, et l'AC fait le reste. Dans un cas comme dans l'autre, la conséquence pratique est la même : si vous durcissez votre PKI en travaillant seulement sur l'AC, vous travaillez en aval de l'endroit où les décisions se prennent.
Pourquoi les chemins ESC sont en fait des problèmes AD
C'est aussi pour ça que les chemins ESC sont surtout des problèmes de permissions sur des objets AD déguisés en problèmes PKI. Les ACL des modèles sont des ACL AD. La permission d'inscription est un droit étendu AD. L'appartenance à un groupe décide qui peut s'inscrire parce que l'appartenance à un groupe est une construction AD.
La vulnérabilité n'est pas dans le comportement de l'AC. La vulnérabilité est dans les permissions AD qui gouvernent qui peut demander quoi à l'AC.
Vous êtes probablement au niveau AD depuis le début
Voici la partie qui surprend souvent : quand vous ouvrez la console Modèles de certificats et que vous modifiez un modèle, vous modifiez un objet AD. La console n'est qu'une interface plus conviviale par-dessus l'annuaire.
Faites le changement une fois, chaque AC de la forêt le voit. Parce que le modèle vit à un seul endroit, et cet endroit, c'est l'annuaire. Le PDF téléchargeable ci-dessus montre Sites et Services Active Directory avec le nœud Services activé, navigué jusqu'à Public Key Services — Certificate Templates à côté de Certification Authorities, Enrollment Services et NTAuthCertificates.
À quand remonte la dernière fois où vous avez ouvert Sites et Services Active Directory, activé Affichage → Afficher le nœud Services, et regardé où vos modèles vivent réellement?