Aperçu des différentes générations de certificats de contrôleur de domaine

Au fil des générations de systèmes d'exploitation Windows, différents modèles de certificats ont été établis pour les contrôleurs de domaine. Dans un service d'annuaire Active Directory actuel, on trouvera trois modèles différents à cette fin.

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

Vous trouverez ci-dessous une description de chaque modèle et une recommandation pour la configuration des modèles de certificats de contrôleur de domaine.

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.

Contrôleur de domaine

Le modèle de certificat de contrôleur de domaine a été introduit avec Windows 2000 Server.

Il s'agit d'un modèle de certificat de la version 1 en raison des racines de Windows 2000, ce qui signifie qu'il ne peut pas être modifié.

Le modèle de certificat comprend les éléments suivants Utilisation étendue des clés (Extended Key Usage, EKU):

• Authentification du serveur
• Authentification du client

Si ce modèle de certificat est publié, les contrôleurs de domaine seront toujours (même si AutoEnrollment n'est pas activé) demander un certificat à partir de ce modèle. Il s'agit d'un héritage de l'époque de Windows 2000, car la première génération de modèles de certificats n'avait pas encore d'auto-enrollment.

Les contrôleurs de domaine reconnaissent à l'aide de l'extension "Certificate Template Name" que le certificat peut être utilisé pour la connexion par carte à puce et acceptent donc également les connexions par carte à puce. Il s'agit là aussi d'un héritage de l'époque de Windows 2000, car l'utilisation de la clé étendue "Smart Card Logon" n'était pas encore définie à l'époque.

Authentification du contrôleur de domaine

Le modèle de certificat d'authentification du contrôleur de domaine a été introduit avec Windows Server 2003.

Il s'agit d'un modèle de la version 2, qui a été introduit avec Windows Server 2003. Ces modèles de certificats peuvent être modifiés.

Une autre nouveauté importante a été l'introduction du "Smart Card Logon" Extended Key Usage. Auparavant, la connexion par carte à puce était représentée par l'Extended Key Usage "Client Authentication" (du côté de l'utilisateur) ainsi que "Server Authentication" (du côté du serveur).

Le modèle de certificat comprend les éléments suivants Utilisation étendue des clés (Extended Key Usage, EKU):

• Authentification du serveur
• Authentification du client
• Connexion par carte à puce

Comme le projet de loi contient déjà le RFC 2818 est pris en compte, l'identité du demandeur (du contrôleur de domaine) est déjà formée par le Subject Alternative Name. Le champ Subject n'est pas renseigné conformément au RFC.

L'extension "Certificate Template Name" n'existe plus pour la version 2 des modèles de certificats et les plus récentes - mais elle n'est plus nécessaire non plus. L'identification du modèle de certificat peut se faire à l'aide de l'extension "Certificate Template Information". L'activation de la connexion de la carte à puce se fait par la présence du "Smart Card Logon" Extended Key Usage. La demande doit être gérée via AutoEnrollment.

Authentification Kerberos

Le modèle de certificat d'authentification Kerberos a été introduit avec Windows Server 2008.

Une nouveauté importante est l'utilisation étendue de la clé "Kerberos Authentication" qui Strict KDC Validation est possible. Cette fonction doit toutefois être explicitement activée. En outre, il est ainsi possible de séparer la partie côté utilisateur ("Smart Card Logon" EKU) de la partie côté serveur ("Kerberos Authentication" EKU) pour la connexion par carte à puce.

Le projet de loi comprend les éléments suivants Utilisation étendue des clés (Extended Key Usage, EKU):

• Authentification du serveur
• Authentification du client
• Connexion par carte à puce
• Authentification KDC

En outre, ce modèle de certificat a introduit l'indicateur CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS, qui veille à ce que le nom de domaine pleinement qualifié et le nom NETBIOS du domaine soient inscrits dans l'extension Subject Alternative Name (SAN) du certificat de contrôleur de domaine.

Quel modèle de certificat dois-je utiliser ?

En principe, il convient de créer son propre modèle, issu du modèle de certificat Kerberos Authentication. Seul celui-ci contient l'indicateur CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS, qui veille à ce que le nom de domaine pleinement qualifié et le nom NETBIOS du domaine soient inscrits dans l'extension Subject Alternative Name (SAN) du certificat du contrôleur de domaine.

Celle-ci devrait être adaptée comme suit :

• Si aucune connexion par carte à puce n'est utilisée dans l'entreprise, la fonction peut être désactivée en supprimant les Extended Key Usages "Smart Card Logon" ainsi que "KDC Authentication", les contrôleurs de domaine peuvent alors continuer à proposer LDAP via des connexions SSL, mais ne peuvent pas accepter les connexions par carte à puce.
• Pour des raisons de compatibilité, il est conseillé de remplir le champ Subject avec l'attribut Common Name dans l'onglet Subject Name. Certaines applications (par exemple Microsoft Network Policy Service, NPS) ne peuvent pas déterminer l'identité dans le certificat à l'aide de l'extension Subject Alternative Name dans le certificat, mais ont besoin d'un Subject. Les applications qui peuvent évaluer les Subject Alternative Names devraient également les utiliser de préférence et ignorer le Subject, de sorte que le Subject puisse être rempli sans risque.

Liens complémentaires :

• Modèles de certificats de contrôleur de domaine et inscription par carte à puce
• Les certificats de contrôleur de domaine ne contiennent pas le nom de domaine dans le Subject Alternative Name (SAN).

Sources externes

• Enabling Strict KDC Validation dans Windows Kerberos (Microsoft)
• RFC 2818 - HTTP sur TLS (Internet Engineering Task Force)