Changement de l'authentification basée sur les certificats

Rappels

L'extension PKINIT (Public Key Cryptography for Initial Authentication) du protocole Kerberos permet une authentification basée sur l'utilisation de la cryptographie asymétrique lors de l'échange initial AS de Kerberos.

Ceci permet à un utilisateur d'un Active Directory de s'authentifier à l'aide d'un certificat et de la clé privée associée en lieu et place du traditionnel mot de passe. Le certificat et la clé privée peuvent par exemple se situer dans le gestionnaire de certificat Windows (certmgr.msc), dans un fichier au format PKCS#12 ou dans un token de sécurité (carte à puce, dispositif USB, etc.).

En pratique, chaque certificat doit référencer un utilisateur de l'Active Directory soit :

• de façon explicite par l'attribut Active Directory altSecurityIdentities de l'objet utilisateur ou ordinateur (par exemple via l'émetteur et le numéro de série du certificat) ;
• de façon implicite par l'attribut x509 Subject Alternative Name qui référence l'UPN (pour les utilisateurs) ou le DNS (pour les comptes ordinateurs). La deuxième forme est la plus souvent utilisée et c'est notamment le cas lorsque la PKI (Public Key Infrastructure) est gérée par un serveur ADCS (Active Directory Certificate Services) Microsoft.

Changement de l'authentification par certificat dans les domaines Active Directory de Microsoft

Dans le but de prévenir une certaine classe de vulnérabilité (CVE-2022-34691, CVE-2022-26931 et CVE-2022-26923) qui exploite une confusion entre le propriétaire légitime d'un certificat et l'utilisateur pouvant réellement s'authentifier à l'aide de ce certificat, Microsoft a publié le KB5014754 le 10 mai 2022.

Pour être pleinement opérationnelle, cette mise à jour doit être déployée sur les contrôleurs de domaine ainsi que sur les serveurs ADCS dans le cas où la PKI est portée par des serveurs Microsoft. Après l'application du correctif, les certificats émis par les serveurs ADCS vont contenir une extension (OID 1.3.6.1.4.1.311.25.2) qui référence le SID de l'utilisateur en plus de l'UPN (ou du DNS pour un objet machine). Ce SID permet d'identifier de façon incontestable le propriétaire légitime du certificat.

En parallèle, lors d'une authentification Kerberos avec PKINIT, le service KDC des contrôleurs de domaine va vérifier la présence :

• soit d'une référence forte du certificat pour un utilisateur (strong certificate mapping à l'aide de l'attribut altSecurityIdentities de l'objet utilisateur) ;
• soit de la présence de l'extension référençant le SID de l'utilisateur dans le certificat (OID 1.3.6.1.4.1.311.25.2).

De plus, les contrôleurs de domaines vont émettre de nouveaux évènements dans le journal évènements system (numéro d'évènements 39, 40 et 41 ou 41, 48 et 49 pour Windows Server 2008 R2 SP1 et Windows Server 2008 SP2) lorsqu'une authentification Kerberos avec PKINIT n'est pas correctement réalisée selon ce nouveau standard de sécurité.

À partir du 14 novembre 2023, le comportement par défaut sera de refuser une authentification Kerberos avec PKINIT dont le certificat ne présente ni de strong mapping ni l'extension référençant le SID de l'utilisateur.

Afin d'empêcher que l'authentification Kerberos échoue, il est nécessaire de procéder au renouvellement des certificats dans le but de rajouter l'extension référençant le SID. Dans le cas d'une PKI ADCS, l'ajout de cet attribut est automatique après l'application du correctif de sécurité. Dans le cas d'une PKI tierce, il est nécessaire de se rapprocher de l'éditeur de PKI.

Afin de vérifier que l'authentification est correctement réalisée, il convient de s'assurer de l'absence des évènements précédemment mentionnés dans le journal d'évènements system des contrôleurs de domaine après la mise à jour du 10 mai 2022.

Dans le cas où ces évènements sont présents, il convient de :

• si les certificats sont émis par des serveurs ADCS :

  • vérifier que les serveurs ADCS ont correctement appliqué la mise à jour du 10 mai 2022.
  • réémettre les certificats utilisateurs utilisés pour l'authentification et vérifier la présence de l'extension ajoutant l'OID 1.3.6.1.4.1.311.25.2. Pour un certificat présent sur une carte à puce par exemple, lorsque cette dernière est branchée dans un poste Windows, lancer l'utilitaire certmgr.msc, puis dans Personal -> Certificates, double-cliquer sur le certificat et vérifier la présence de l'extension dans l'onglet Details.

• si les certificats sont émis par une IGC tierce, il faut :

  • soit mettre en place le strong mapping en éditant l'attribut altSecurityIdentities de l'objet utilisateur pour y ajouter l'IssuerName et le serial number du certificat (voir la documentation Microsoft pour plus d'information à ce sujet)
  • soit modifier le gabarit de certificat utilisé pour que les nouveaux certificats émis contiennent l'extension ajoutant le SID de l'utilisateur. Par exemple, dans le cas d'une PKI basée sur OpenSSL, la configuration suivante permet de délivrer des certificats faisant apparaître cette extension (dans l'exemple suivant, le SID est lu depuis la variable d'environnement SID) :
  [pastacode lang="markdown" manual="oid_section%20%3D%20OIDs%0A%0A%5B%20OIDs%20%5D%0A%0AOID_NTDS_CA_SECURITY_EXT%3D1.3.6.1.4.1.311.25.2%0AOID_NTDS_OBJECTSID%3D1.3.6.1.4.1.311.25.2.1%0A%0A%5B%20ca%20%5D%0A%0Ax509_extensions%20%3D%20CERT_CLIENTS_ext%0A%0A%5B%20CERT_CLIENTS_ext%20%5D%0A%0AOID_NTDS_CA_SECURITY_EXT%3DASN1%3ASEQUENCE%3ASIDExtensionOIDSequence%0A%0A%5B%20SIDExtensionOIDSequence%20%5D%0A%0Acontext_specific%3DIMPLICIT%3A0C%2CSEQUENCE%3ASIDExtensionOIDSequenceImplicit%0A%0A%5B%20SIDExtensionOIDSequenceImplicit%20%5D%0A%0Aoid%3DOID%3AOID_NTDS_OBJECTSID%0A%0Avalue%3DEXPLICIT%3A0C%2COCTETSTRING%3A%24%7BENV%3A%3ASID%7D" message="" highlight="" provider="manual"/]

Le CERT-FR recommande de mettre en oeuvre ces recommandations dès maintenant afin d'éviter une situation de blocage le 14 novembre 2023 et de disposer d'un délai suffisamment conséquent pour tester et déployer les changements nécessaires. De même, le CERT-FR recommande de passer en mode "enforced" (StrongCertificateBindingEnforcement à 2) dès maintenant et après validation des points évoqués dans ce bulletin. Seul le passage en mode "enforced" permet de se protéger efficacement contre les vulnérabilités décrites dans les CVE.

Référence:

• https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
• https://learn.microsoft.com/en-us/archive/blogs/spatdsg/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute