Configurer un modèle de certificat pour les contrôleurs de domaine

Même dans le cas d'un modèle de certificat pour contrôleurs de domaine supposé simple à configurer, certains points doivent être pris en compte.

Le modèle de certificat doit toujours partir du modèle de certificat „Kerberos Authentication“.

Seul le modèle de certificat d'authentification Kerberos contient le drapeau CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS, qui veille à ce que le nom de domaine soit inscrit dans l'extension Subject Alternative Name (SAN) du certificat délivré. Voir aussi l'article „Les certificats de contrôleur de domaine ne contiennent pas le nom de domaine dans le Subject Alternative Name (SAN).„ .

Configuration du modèle de certificat

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Fiche "Général

Dans l'onglet „General“, un nom significatif est attribué au modèle de certificat. Une convention de nommage devrait être appliquée ici afin de simplifier l'administration ultérieure.

Fiche "Cryptographie

Les paramètres par défaut peuvent être laissés ici. Même si courbes elliptiques sur Fournisseur de stockage clé (KSP) peuvent être utilisés pour les services de domaine Active Directory, ce n'est pas le cas pour les Active Directory Web Services (ADWS), qui ne supportent que les fournisseurs de services cryptographiques.

Il est donc recommandé d'utiliser l'algorithme RSA avec longueur de clé minimale de 3072 bits et d'utiliser un fournisseur de services cryptographiques.

Fiche „Modèles superposés“

L'onglet „Superseded Templates“ contient tous les modèles de certificats par défaut pour les contrôleurs de domaine ainsi que d'éventuels modèles de certificats personnels antérieurs. Les modèles de certificats par défaut pour les contrôleurs de domaine sont les suivants :

Contrôleur de domaine
Authentification du contrôleur de domaine
Authentification Kerberos

Voir aussi à ce sujet l'article "Aperçu des différentes générations de certificats de contrôleur de domaine„ .

Fiche „ Extensions “

L'extension „Application Policies“ est en cours d'édition.

Les entrées suivantes doivent en principe être supprimées :

Authentification du client
Connexion par carte à puce

Si des certificats de contrôleur de domaine falsifiés devaient être émis (par exemple par une attaque de relais NTLM ou par une attaque par déni de service), il est possible de les utiliser. Falsification d'un compte correspondant), les certificats ne peuvent pas être utilisés pour une connexion PKINIT au nom du contrôleur de domaine (ce qui pourrait sinon entraîner la compromission de l'Active Directory).

Si l'on ne souhaite pas utiliser PKINIT (également connu sous le nom de Smartcard Logon) dans l'ensemble de l'entreprise, il est également recommandé de supprimer l'Extended Key Usage pour l'authentification „KDC“ du modèle de certificat, afin que les contrôleurs de domaine ne puissent en principe pas traiter de telles inscriptions.

Si des certificats d'utilisateur falsifiés sont émis (par exemple en raison d'autorisations trop larges sur un modèle de certificat, d'une une autorité de certification configurée de manière non sécurisée ou même leur compromission), il n'est alors pas possible de se connecter avec ceux-ci (ce qui pourrait sinon entraîner la compromission d'Active Directory).

Voir aussi à ce sujet l'article "Vecteur d'attaque sur le service d'annuaire Active Directory via le mécanisme de connexion par carte à puce„ .

Fiche "Nom du sujet

Cette option est décrite dans l'article „Sur l'option "Build this from Active Directory information" pour les modèles de certificats“ décrit plus en détail.

Pour des raisons de compatibilité, il est recommandé de définir dans l'onglet „Subject Name“ que le sujet des certificats émis soit rempli avec le nom du serveur du contrôleur de domaine (option „Common Name“).

Par défaut, le sujet sera vide, ce qui est tout à fait conforme au RFC 4514.

Le client détermine le type (par exemple, le nom DNS ou l'adresse IP) de l'identité de référence et effectue une comparaison entre l'identité de référence et chaque valeur SubjectAltName du type correspondant jusqu'à ce qu'une correspondance soit produite.
RFC 4513 - Lightweight Directory Access Protocol (LDAP) : méthodes d'authentification et mécanismes de sécurité

L'identité du serveur peut également être vérifiée en comparant l'identité de référence avec la valeur Nom Commun (CN) [RFC4519] dans le champ Nom Distingué Relatif (RDN) du champ subjectName du certificat du serveur. [...] Bien que l'utilisation de la valeur Common Name soit une pratique existante, elle est déconseillée et les autorités de certification sont encouragées à fournir des valeurs subjectAltName à la place.
RFC 4513 - Lightweight Directory Access Protocol (LDAP) : méthodes d'authentification et mécanismes de sécurité

Toutefois, les applications qui ne sont pas conformes à ce RFC (et il en existe dans la pratique) ne pourront pas traiter le certificat.

Si un sujet est rempli avec le nom de serveur du contrôleur de domaine et que l'application est conforme à la RFC 4513, le sujet est de toute façon ignoré, il n'y a donc pas de désavantage.

Fiche "Sécurité

Dans l'onglet „Sécurité“, il faut absolument veiller à ce que seul le cercle des personnes autorisées puisse utiliser le modèle de certificat. éditer peut.

Les droits pour la demande de certificat peuvent être repris du modèle de certificat „Kerberos Authentication“ sous-jacent.

Liens complémentaires :

Sources externes

RFC 4513 - Lightweight Directory Access Protocol (LDAP) : méthodes d'authentification et mécanismes de sécurité (Internet Engineering Task Force)
RFC 2818 - HTTP sur TLS (Internet Engineering Task Force)