KB5014754 : Modifications de l’authentification basée sur les certificats sur les contrôleurs de domaine Windows

Aucun mappage de certificat fort n’a pu être trouvé et le certificat n’avait pas l’extension de nouvel identificateur de sécurité (SID) que le KDC a pu valider.

Le certificat a été émis à l’utilisateur avant l’existence de l’utilisateur dans Active Directory et aucun mappage fort n’a pu être trouvé. Cet événement est journalisé uniquement lorsque le KDC est en mode de compatibilité.

Le SID contenu dans la nouvelle extension du certificat d’utilisateur ne correspond pas au SID de l’utilisateur, ce qui implique que le certificat a été émis à un autre utilisateur.

RemarqueCertains champs, tels que l’émetteur, l’objet et le numéro de série, sont signalés au format « forward ». Vous devez inverser ce format lorsque vous ajoutez la chaîne de mappage à l’attribut altSecurityIdentities . Par exemple, pour ajouter le mappage X509IssuerSerialNumber à un utilisateur, recherchez les champs « Émetteur » et « Numéro de série » du certificat que vous souhaitez mapper à l’utilisateur. Consultez l’exemple de sortie ci-dessous.

• Émetteur : CN=CONTOSO-DC-CA, DC=contoso, DC=com

• Numéro de série : 2B0000000011AC00000000012

Ensuite, mettez à jour l’attribut altSecurityIdentities de l’utilisateur dans Active Directory avec la chaîne suivante :

• « X509 :<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>120000000000AC110000000002B »

Pour mettre à jour cet attribut à l’aide de PowerShell, vous pouvez utiliser la commande ci-dessous. Gardez à l’esprit que, par défaut, seuls les administrateurs de domaine ont l’autorisation de mettre à jour cet attribut.

• set-aduser 'DomainUser' -replace @{altSecurityIdentities= « X509 :<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>12000000000AC1100000000002B"}

Notez que lorsque vous inversez serialnumber, vous devez conserver l’ordre des octets. Cela signifie que l’inversion du SerialNumber « A1B2C3 » doit entraîner la chaîne « C3B2A1 » et non « 3C2B1A ». Pour plus d’informations, consultez HowTo : Map a user to a certificate via toutes les méthodes disponibles dans l’attribut altSecurityIdentities.

Une fois que vous avez installé les mises à jour Windows du 10 mai 2022, les appareils sont en mode de compatibilité. Si un certificat peut être fortement mappé à un utilisateur, l’authentification se produit comme prévu. Si un certificat peut uniquement être faiblement mappé à un utilisateur, l’authentification se produit comme prévu. Toutefois, un message d’avertissement est enregistré, sauf si le certificat est antérieur à l’utilisateur. Si le certificat est antérieur à l’utilisateur et que la clé de Registre De backdating du certificat n’est pas présente ou si la plage se trouve en dehors de la compensation de backdating, l’authentification échoue et un message d’erreur est enregistré.  Si la clé de Registre De backdating de certificat est configurée, un message d’avertissement est journalisé dans le journal des événements si les dates sont comprises dans la compensation de backdating.

Après avoir installé les mises à jour Windows du 10 mai 2022, watch pour tout message d’avertissement susceptible d’apparaître après un mois ou plus. S’il n’y a pas de message d’avertissement, nous vous recommandons vivement d’activer le mode Application complète sur tous les contrôleurs de domaine à l’aide de l’authentification basée sur les certificats. Vous pouvez utiliser la clé de Registre KDC pour activer le mode Application complète.

Sauf si ce mode est mis à jour précédemment, nous allons mettre à jour tous les appareils vers le mode Application complète d’après le 11 février 2025 ou une version ultérieure. Si un certificat ne peut pas être fortement mappé, l’authentification est refusée. L’option permettant de revenir en mode de compatibilité reste jusqu’au 10 septembre 2025. Après cette date, la valeur de Registre StrongCertificateBindingEnforcement n’est plus prise en charge.

Si l’authentification basée sur les certificats repose sur un mappage faible que vous ne pouvez pas déplacer à partir de l’environnement, vous pouvez placer les contrôleurs de domaine en mode Désactivé à l’aide d’un paramètre de clé de Registre. Microsoft ne recommande pas cette option et nous supprimerons le mode Désactivé le 11 avril 2023.

Une fois que vous avez installé les mises à jour Windows du 13 février 2024 ou ultérieures sur Server 2019 et versions ultérieures et les clients pris en charge avec la fonctionnalité facultative RSAT installée, le mappage de certificat dans Utilisateurs Active Directory & Ordinateurs sélectionne par défaut un mappage fort à l’aide du X509IssuerSerialNumber au lieu d’un mappage faible à l’aide de X509IssuerSubject. Le paramètre peut toujours être modifié comme vous le souhaitez.

• Utilisez le journal opérationnel Kerberos sur l’ordinateur approprié pour déterminer quel contrôleur de domaine échoue la connexion. Accédez à observateur d'événements > Journaux des applications et des services\Microsoft \Windows\Security-Kerberos\Operational.

• Recherchez les événements pertinents dans le journal des événements système sur le contrôleur de domaine sur lequel le compte tente de s’authentifier.

• Si le certificat est antérieur au compte, réexécutez le certificat ou ajoutez un mappage altSecurityIdentities sécurisé au compte (voir Mappages de certificats).

• Si le certificat contient une extension SID, vérifiez que le SID correspond au compte.

• Si le certificat est utilisé pour authentifier plusieurs comptes différents, chaque compte a besoin d’un mappage altSecurityIdentities distinct.

• Si le certificat n’a pas de mappage sécurisé au compte, ajoutez-en un ou laissez le domaine en mode de compatibilité jusqu’à ce qu’il soit possible d’en ajouter un.

Un exemple de mappage de certificat TLS est l’utilisation d’une application web intranet IIS.

• Après avoir installé les protections CVE-2022-26391 et CVE-2022-26923 , ces scénarios utilisent le protocole S4U (Service de certificats Kerberos pour les utilisateurs) pour le mappage et l’authentification des certificats par défaut.

• Dans le protocole S4U de certificat Kerberos, la demande d’authentification circule du serveur d’applications vers le contrôleur de domaine, et non du client vers le contrôleur de domaine. Par conséquent, les événements pertinents se trouveront sur le serveur d’applications.

Cette clé de Registre modifie le mode d’application du KDC en mode Désactivé, Mode de compatibilité ou Mode Application complète.

Lorsqu’une application serveur nécessite l’authentification du client, Schannel tente automatiquement de mapper le certificat fourni par le client TLS à un compte d’utilisateur. Vous pouvez authentifier les utilisateurs qui se connectent avec un certificat client en créant des mappages qui associent les informations de certificat à un compte d’utilisateur Windows. Après avoir créé et activé un mappage de certificat, chaque fois qu’un client présente un certificat client, votre application serveur associe automatiquement cet utilisateur au compte d’utilisateur Windows approprié.

Schannel tente de mapper chaque méthode de mappage de certificat que vous avez activée jusqu’à ce que l’une d’elles réussisse. Schannel tente d’abord de mapper les mappages Service-For-User-To-Self (S4U2Self). Les mappages objet/émetteur, émetteur et certificat UPN sont désormais considérés comme faibles et ont été désactivés par défaut. La somme du masque de bits des options sélectionnées détermine la liste des méthodes de mappage de certificat disponibles.

La clé de Registre SChannel par défaut a été 0x1F et est maintenant 0x18. Si vous rencontrez des échecs d’authentification avec des applications serveur basées sur Schannel, nous vous suggérons d’effectuer un test. Ajoutez ou modifiez la valeur de clé de Registre CertificateMappingMethods sur le contrôleur de domaine et définissez-la sur 0x1F et vérifiez si cela résout le problème. Pour plus d’informations, consultez les journaux des événements système sur le contrôleur de domaine pour rechercher les erreurs répertoriées dans cet article. N’oubliez pas que la modification de la valeur de la clé de Registre SChannel à la valeur par défaut précédente (0x1F) revient à l’utilisation de méthodes de mappage de certificats faibles.

Pour obtenir des ressources et un support supplémentaires, consultez la section « Ressources supplémentaires ».

Après avoir installé les mises à jour qui adressent CVE-2022-26931 et CVE-2022-26923, l’authentification peut échouer dans les cas où les certificats utilisateur sont antérieurs à l’heure de création des utilisateurs. Cette clé de Registre permet une authentification réussie lorsque vous utilisez des mappages de certificats faibles dans votre environnement et que l’heure du certificat est antérieure à l’heure de création de l’utilisateur dans une plage définie. Cette clé de Registre n’affecte pas les utilisateurs ou les machines avec des mappages de certificats forts, car l’heure du certificat et l’heure de création de l’utilisateur ne sont pas vérifiées avec des mappages de certificats forts. Cette clé de Registre n’a aucun effet lorsque StrongCertificateBindingEnforcement a la valeur 2.

L’utilisation de cette clé de Registre est une solution de contournement temporaire pour les environnements qui en ont besoin et doit être effectuée avec prudence. L’utilisation de cette clé de Registre signifie ce qui suit pour votre environnement :

• Cette clé de Registre fonctionne uniquement en mode de compatibilité à compter des mises à jour publiées le 10 mai 2022. L’authentification sera autorisée dans le décalage de compensation de backdating, mais un avertissement du journal des événements sera enregistré pour la liaison faible.

• L’activation de cette clé de Registre permet l’authentification de l’utilisateur lorsque l’heure du certificat est antérieure à l’heure de création de l’utilisateur dans une plage définie en tant que mappage faible. Les mappages faibles ne seront pas pris en charge après l’installation des mises à jour pour Windows publiées le 10 septembre 2025.

Vous exécutez la commande certutil suivante pour exclure les certificats du modèle utilisateur de l’obtention de la nouvelle extension.

1. Connectez-vous à un serveur d’autorité de certification ou à un client Windows 10 joint à un domaine avec l’administrateur d’entreprise ou les informations d’identification équivalentes.

2. Ouvrez une invite de commandes et choisissez Exécuter en tant qu’administrateur.

3. Exécutez certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000. 

La désactivation de l’ajout de cette extension supprime la protection fournie par la nouvelle extension. Envisagez de le faire uniquement après l’une des opérations suivantes :

1. Vous confirmez que les certificats correspondants ne sont pas acceptables pour le chiffrement à clé publique pour l’authentification initiale (PKINIT) dans les authentifications du protocole Kerberos sur KDC

2. Les certificats correspondants ont d’autres mappages de certificats forts configurés

Les environnements qui ont des déploiements d’autorité de certification non-Microsoft ne seront pas protégés à l’aide de la nouvelle extension SID après l’installation de la mise à jour Windows du 10 mai 2022. Les clients concernés doivent travailler avec les fournisseurs d’autorité de certification correspondants pour résoudre ce problème ou envisager d’utiliser d’autres mappages de certificats forts décrits ci-dessus.

Pour obtenir des ressources et un support supplémentaires, consultez la section « Ressources supplémentaires ».

Non, le renouvellement n’est pas requis. L’autorité de certification sera livrée en mode de compatibilité. Si vous souhaitez un mappage fort à l’aide de l’extension ObjectSID, vous aurez besoin d’un nouveau certificat.

Dans la mise à jour Windows du 11 février 2025, les appareils qui ne sont pas déjà dans Enforcement (la valeur de Registre StrongCertificateBindingEnforcement est définie sur 2) seront déplacés vers Application. Si l’authentification est refusée, vous verrez l’ID d’événement 39 (ou l’ID d’événement 41 pour Windows Server 2008 R2 SP1 et Windows Server 2008 SP2). Vous aurez la possibilité de définir à nouveau la valeur de la clé de Registre sur 1 (mode de compatibilité) à ce stade.

Dans la mise à jour Windows du 10 septembre 2025, la valeur de Registre StrongCertificateBindingEnforcement ne sera plus prise en charge. ​​​​​​​