Modèles de certificats de contrôleur de domaine et inscription par carte à puce

Pour que les contrôleurs de domaine puissent traiter les inscriptions par carte à puce, ils ont besoin de certificats qui fournissent cette fonction.

L'une des conditions suivantes doit être remplie par le Certificat de contrôleur de domaine pour qu'il soit utilisable pour l'inscription par carte à puce :

• La chaîne "DomainController" dans l'extension du nom de modèle de certificat (Cette extension est disponible uniquement dans les modèles de certificats de la version 1).
• L'OID Smartcard Logon (1.3.6.1.4.1.311.20.2.2) dans l'extension Extended Key Usages.
• L'OID d'authentification KDC (1.3.6.1.5.2.3.5) dans l'extension Extended Key Usages

Microsoft utilise le terme "Enhanced Key Usage" (utilisation améliorée des clés), mais la désignation correcte selon le RFC 5280 est "Extended Key Usage"..

L'extension "Nom du modèle de certificat" n'est présente que dans les modèles de certificat version 1 datant de l'époque de Windows 2000. Le seul modèle de certificat qui a rempli cette extension avec la chaîne "DomainController" est le modèle de la version 1 du même nom. Ces modèles de certificats ne supportent pas encore l'auto-enrollment, c'est pourquoi jusqu'à l'actuel Windows Server 2019, le KDC contient un code qui veille à ce que ces certificats soient demandés par les contrôleurs de domaine lorsqu'il existe une autorité de certification qui les propose sur le réseau.

L'Extended Key Usage "Smartcard Logon" a été introduit avec le modèle de certificat "Domain Controller Authentication" avec Windows Server 2003. Il a été utilisé à la fois du côté client (certificat d'utilisateur) et du côté serveur (certificat de contrôleur de domaine).

L'utilisation de la clé étendue "KDC Authentication" a été introduite avec le modèle de certificat "Kerberos Authentication" avec Windows Server 2008. Il permettait une séparation entre la partie serveur (KDC Authentication dans le certificat du contrôleur de domaine) et la partie client (Smartcard Logon dans le certificat de l'utilisateur).

Voici quelques exemples de la manière dont le processus KDC se comporte en relation avec les différents types de certificats.

Modèle de certificat standard "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.

Ce modèle de certificat se caractérise par le fait que le certificat qui en résulte contient les Extended Key Usages suivants :

• Authentification du serveur
• Authentification du client

En outre, comme il s'agit d'un modèle de certificat de la version 1 du schéma, il contient également une extension "Nom du modèle de certificat" qui contient la valeur "DomainController".

L'inscription par carte à puce fonctionne avec ce certificat, mais il faut utiliser le Événement n° 32 dans l'Observateur d'événements du contrôleur de domaine, indiquant que le certificat ne contient pas l'utilisation étendue de la clé "KDC Authentication", ce qui peut éventuellement entraîner des problèmes de compatibilité.

Modèle de certificat standard "Domain Controller Authentication

Ce modèle de certificat se caractérise par le fait que le certificat qui en résulte contient les Extended Key Usages suivants :

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

Comme il s'agit d'un modèle de certificat de la version 2 du schéma, aucune extension "Nom du modèle de certificat" n'est incluse.

L'inscription par carte à puce fonctionne avec ce certificat, mais il faut utiliser le Événement n° 32 dans l'Observateur d'événements du contrôleur de domaine, indiquant que le certificat ne contient pas l'utilisation étendue de la clé "KDC Authentication", ce qui peut éventuellement entraîner des problèmes de compatibilité.

Modèle de certificat standard "Kerberos Authentication

Ce modèle de certificat se caractérise par le fait que le certificat qui en résulte contient les Extended Key Usages suivants :

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

Comme il s'agit d'un modèle de certificat de la version 2 du schéma, aucune extension "Nom du modèle de certificat" n'est incluse.

L'inscription par carte à puce fonctionne avec ce certificat et aucun avertissement n'est consigné dans l'Observateur d'événements du contrôleur de domaine.

Modèle de certificat personnalisé basé sur "Kerberos Authentication", mais sans le Smartcard Logon Extended Key Usage

Ce modèle de certificat se caractérise par le fait que le certificat qui en résulte contient les Extended Key Usages suivants :

• Authentification du serveur
• Authentification du client
• Authentification KDC

Comme il s'agit d'un modèle de certificat de la version 2 du schéma, aucune extension "Nom du modèle de certificat" n'est incluse.

L'inscription par carte à puce fonctionne avec ce certificat et aucun avertissement n'est consigné dans l'observateur d'événements du contrôleur de domaine. Ce modèle de certificat remplit donc toutes les exigences minimales pour un traitement sans erreur des inscriptions par carte à puce.

Modèle de certificat personnalisé basé sur le "Domain Controller

Ce modèle de certificat se caractérise par le fait que le certificat qui en résulte contient les Extended Key Usages suivants :

• Authentification du serveur
• Authentification du client

Toutefois, contrairement au modèle de certificat original, il ne contient pas l'extension "Nom du modèle de certificat", car il s'agit d'un modèle de certificat de la version 2 du schéma, qui n'est pas identifié par son nom, mais par son OID.

Ce modèle de certificat ne peut pas être utilisé par le KDC pour la connexion par carte à puce. Les événements n 19 et 29 dans le journal des événements du contrôleur de domaine lorsqu'un utilisateur tente de se connecter par carte à puce :

This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate.

The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.

Pour un utilisateur qui se connecte, l'erreur se manifeste par le message d'erreur suivant : " ".L'inscription avec un dispositif de sécurité n'est pas prise en charge pour votre compte. Pour plus d'informations, contactez votre administrateur.„

Quel modèle de certificat faut-il donc utiliser pour les contrôleurs de domaine ?

En principe, il convient de créer son propre modèle, qui découle du modèle de certificat Kerberos Authentication.

Même s'il n'est pas directement pertinent pour l'inscription par carte à puce, seul le modèle de certificat "Kerberos Authentication" contient le drapeau CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS, qui garantit que le nom de domaine entièrement qualifié et le nom NETBIOS du domaine sont inscrits dans l'extension Subject Alternative Name (SAN) du certificat du contrôleur de domaine.

Les modifications suivantes peuvent être apportées.

• Si l'on souhaite empêcher les contrôleurs de domaine d'accepter les connexions par carte à puce, on peut y parvenir en supprimant les deux Extended Key Usages pour "Smartcard Logon" et "KDC Authentication".
• Même si les contrôleurs de domaine doivent traiter les inscriptions par carte à puce, l'utilisation de clé étendue "Smartcard Logon" peut être supprimée, car la partie côté serveur de l'inscription par carte à puce est représentée par l'utilisation de clé étendue "KDC Authentication".

Liens complémentaires :

• Aperçu des différentes générations de certificats de contrôleur de domaine
• Quelles conditions doivent être remplies du côté de l'infrastructure pour que les inscriptions par carte à puce soient possibles ?
• La connexion via carte à puce échoue avec le message d'erreur "Signing in with a security device isn't supported for your account".
• Les certificats de contrôleur de domaine ne contiennent pas le nom de domaine dans le Subject Alternative Name (SAN).

Sources externes

• Connexion par carte à puce à l'aide de certificats d'une tierce partie sur un contrôleur de domaine et KDC Event ID 29 (Microsoft)