Applies ToWindows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Enterprise ESU Windows Server 2008 R2 Standard ESU Windows Server 2008 R2 Datacenter ESU Windows Server 2008 Service Pack 2 Windows Server 2016, all editions Windows Server, version 20H2, all editions Windows Server 2022 Windows Server 2019

Modifier la date

Description

10/24/2024

Texte mis à jour pour plus de clarté à l’étape 2 de la section « Agir », dans la description « Mode d’application complète » de la section « Chronologie des mises à jour Windows », et révisé les informations de date des rubriques « Clé de Registre du Centre de distribution de clés (KDC) » et « Clé de Registre de sauvegarde de certificat » dans la section « Informations sur la clé de Registre ».

9/10/2024

Modification de la description du mode d’application complète dans la section « Minutage des mises à jour Windows » pour refléter les nouvelles dates. Le 11 février 2025 déplacera les appareils vers le mode Application, mais laissera le support pour revenir au mode de compatibilité. La prise en charge complète des clés de Registre prendra fin le 10 septembre 2025.

7/5/2024

Ajout d’informations sur l’extension SID à la clé de Registre du centre de distribution de clés (KDC) dans la section « Informations sur la clé de Registre ».

10/10/2023

Ajout d’informations sur les modifications par défaut des mappages forts sous « Chronologie pour Windows Mises à jour »

6/30/2023

Modification de la date du mode d’application complète du 14 novembre 2023 au 11 février 2025 (ces dates étaient précédemment répertoriées comme étant du 19 mai 2023 au 14 novembre 2023).

1/26/2023

Modification de la suppression du mode Désactivé du 14 février 2023 au 11 avril 2023

Résumé

CVE-2022-34691, CVE-2022-26931 et CVE-2022-26923 résolvent une vulnérabilité d’élévation de privilège qui peut se produire lorsque le Centre de distribution de clés Kerberos (KDC) traite une demande d’authentification basée sur un certificat. Avant la mise à jour de sécurité du 10 mai 2022, l’authentification basée sur les certificats ne prendrait pas en compte un signe dollar ($) à la fin d’un nom de machine. Cela a permis d’émuler les certificats associés (usurpés) de différentes manières. En outre, les conflits entre les noms d’utilisateur principal (UPN) et sAMAccountName ont introduit d’autres vulnérabilités d’émulation (usurpation) que nous abordons également avec cette mise à jour de sécurité. 

Gérez activement vos projets

Pour protéger votre environnement, effectuez les étapes suivantes pour l’authentification basée sur les certificats :

  1. Mettez à jour tous les serveurs qui exécutent les services de certificats Active Directory et les contrôleurs de domaine Windows qui service l’authentification basée sur les certificats avec la mise à jour du 10 mai 2022 (voir Mode de compatibilité). La mise à jour du 10 mai 2022 fournira des événements d’audit qui identifient les certificats qui ne sont pas compatibles avec le mode d’application complète.

  2. Si aucun journal des événements d’audit n’est créé sur les contrôleurs de domaine pendant un mois après l’installation de la mise à jour, activez le mode Application complète sur tous les contrôleurs de domaine. D’ici février 2025, si la clé de Registre StrongCertificateBindingEnforcemenn’est pas configurée, les contrôleurs de domaine passent en mode d’application complète. Dans le cas contraire, le paramètre du mode de compatibilité des clés de Registre continuera d’être respecté. En mode Application complète, si un certificat ne respecte pas les critères de mappage fort (sécurisé) (voir Mappages de certificats), l’authentification est refusée. Toutefois, l’option permettant de revenir au mode de compatibilité reste jusqu’en septembre 2025. ​​​​​​​

Événements d’audit

La mise à jour Windows du 10 mai 2022 ajoute les journaux des événements suivants.

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.

Journal des événements

Système

Type d’événement

Avertissement si le KDC est en mode de compatibilité

Erreur si le KDC est en mode Application

Source de l’événement

Kdcsvc

ID d’événement

39

41 (Pour Windows Server 2008 R2 SP1 et Windows Server 2008 SP2)

Texte de l’événement

Le centre de distribution de clés (KDC) a rencontré un certificat utilisateur qui était valide, mais qui n’a pas pu être mappé à un utilisateur de manière forte (par exemple, par le biais d’un mappage explicite, d’un mappage d’approbation de clé ou d’un SID). Ces certificats doivent être remplacés ou mappés directement à l’utilisateur par le biais d’un mappage explicite. Consultez https://go.microsoft.com/fwlink/?linkid=2189925 pour en savoir plus.

Utilisateur : <nom principal>

Objet du certificat : <nom de l’objet dans l'> de certificat

Émetteur de certificat : nom de domaine complet (FQDN) de l’émetteur <>

Numéro de série du certificat : <numéro de série du> de certificat

Empreinte numérique du certificat : <empreinte du> de certificat

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é.

Journal des événements

Système

Type d’événement

Error

Source de l’événement

Kdcsvc

ID d’événement

40

48 (Pour Windows Server 2008 R2 SP1 et Windows Server 2008 SP2

Texte de l’événement

Le centre de distribution de clés (KDC) a rencontré un certificat utilisateur qui était valide, mais qui n’a pas pu être mappé à un utilisateur de manière forte (par exemple, par le biais d’un mappage explicite, d’un mappage d’approbation de clé ou d’un SID). Le certificat a également précédé l’utilisateur à qui il a été mappé, de sorte qu’il a été rejeté. Consultez https://go.microsoft.com/fwlink/?linkid=2189925 pour en savoir plus.

Utilisateur : <nom principal>

Objet du certificat : <nom de l’objet dans l'> de certificat

Émetteur de certificat : <nom de domaine complet de l’émetteur>

Numéro de série du certificat : <numéro de série du> de certificat

Empreinte numérique du certificat : <empreinte du> de certificat

Heure d’émission du certificat : <FILETIME des> de certificat

Heure de création du compte : <FILETIME de l’objet principal dans AD>

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.

Journal des événements

Système

Type d’événement

Error

Source de l’événement

Kdcsvc

ID d’événement

41

49 (Pour Windows Server 2008 R2 SP1 et Windows Server 2008 SP2)

Texte de l’événement

Le centre de distribution de clés (KDC) a rencontré un certificat utilisateur valide, mais contenant un SID différent de celui de l’utilisateur auquel il a été mappé. Par conséquent, la demande impliquant le certificat a échoué. Pour en savoir plus, consultez https://go.microsoft.cm/fwlink/?linkid=2189925.

Utilisateur : <nom principal>

SID utilisateur : <SID du principal d’authentification>

Objet du certificat : <nom de l’objet dans l'> de certificat

Émetteur de certificat : <nom de domaine complet de l’émetteur>

Numéro de série du certificat : <numéro de série du> de certificat

Empreinte numérique du certificat : <empreinte du> de certificat

SID de certificat : <SID trouvé dans le nouveau> d’extension de certificat

Mappages de certificats

Les administrateurs de domaine peuvent mapper manuellement des certificats à un utilisateur dans Active Directory à l’aide de l’attribut altSecurityIdentities de l’objet users. Il existe six valeurs prises en charge pour cet attribut, avec trois mappages considérés comme faibles (non sécurisés) et les trois autres considérés comme forts. En général, les types de mappage sont considérés comme forts s’ils sont basés sur des identificateurs que vous ne pouvez pas réutiliser. Par conséquent, tous les types de mappage basés sur les noms d’utilisateur et les adresses e-mail sont considérés comme faibles.

d’ingestion

Exemple

Type

Remarques

X509IssuerSubject

« X509 :<I>IssuerName<S>SubjectName »

Faible

X509SubjectOnly

« X509 :<S>SubjectName »

Faible

X509RFC822

« X509 :<RFC822>user@contoso.com »

Faible

Adresse de courrier

X509IssuerSerialNumber

« X509 :<I>IssuerName<SR>1234567890 »

Remarque

Recommandé

X509SKI

« X509 :<SKI>123456789abcdef »

Remarque

X509SHA1PublicKey

« X509 :<SHA1-PUKEY>123456789abcdef »

Remarque

Si les clients ne peuvent pas réémettre des certificats avec la nouvelle extension SID, nous vous recommandons de créer un mappage manuel à l’aide de l’un des mappages forts décrits ci-dessus. Pour ce faire, ajoutez la chaîne de mappage appropriée à un attribut altSecurityIdentities des utilisateurs dans Active Directory.

Remarque Certains 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.

Chronologie des mises à jour Windows

Important La phase d’activation commence par les mises à jour du 11 avril 2023 pour Windows, qui ignorent le paramètre de clé de Registre du mode Désactivé. 

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.

À moins qu’ils ne soient mis à jour vers le mode Audit ou le mode d’application à l’aide de la clé de Registre StrongCertificateBindingEnforcement précédemment , les contrôleurs de domaine passeront au mode Application complète lorsque la mise à jour de sécurité Windows de février 2025 sera installée. L’authentification est refusée si un certificat ne peut pas être fortement mappé. L’option permettant de revenir au mode de compatibilité est conservée jusqu’en septembre 2025. Après cette date, la clé de Registre StrongCertificateBindingEnforcement ne sera 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.

Résolution des problèmes

  • 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.

Informations sur la clé de Registre

Après avoir installé les protections CVE-2022-26931 et CVE-2022-26923 dans les mises à jour Windows publiées entre le 10 mai 2022 et le 10 septembre 2025 ou une version ultérieure, les clés de Registre suivantes sont disponibles.

Cette clé de Registre ne sera pas prise en charge après l’installation des mises à jour pour Windows publiées à partir de septembre 2025.

Important

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.

  • Cette clé de Registre ne sera pas prise en charge après l’installation des mises à jour pour Windows publiées le 10 septembre 2025.

  • La détection et la validation de l’extension SID utilisées par l’application de liaison de certificat forte dépendent de la valeur UseSubjectAltName de la clé de Registre KDC. L’extension SID est utilisée si la valeur de Registre n’existe pas ou si la valeur est définie sur une valeur de 0x1. L’extension SID n’est pas utilisée si UseSubjectAltName existe et que la valeur est définie sur 0x0.

Sous-clé de Registre

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Value (Valeur)

StrongCertificateBindingEnforcement

Type de données

REG_DWORD

Data (Données)

1 – Vérifie s’il existe un mappage de certificat fort. Si oui, l’authentification est autorisée. Sinon, le KDC case activée si le certificat a la nouvelle extension SID et la valide. Si cette extension n’est pas présente, l’authentification est autorisée si le compte d’utilisateur est antérieur au certificat.

2 – Vérifie s’il existe un mappage de certificat fort. Si oui, l’authentification est autorisée. Sinon, le KDC case activée si le certificat a la nouvelle extension SID et la valide. Si cette extension n’est pas présente, l’authentification est refusée.

0 : désactive les case activée de mappage de certificats forts. Non recommandé, car cela désactive toutes les améliorations de sécurité.

Si vous définissez cette valeur sur 0, vous devez également définir CertificateMappingMethods sur 0x1F comme décrit dans la section Clé de Registre Schannel ci-dessous pour que l’authentification basée sur les certificats d’ordinateur réussisse.

Redémarrage nécessaire ?

Non

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.

Sous-clé de Registre

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel

Value (Valeur)

CertificateMappingMethods

Type de données

DWORD

Data (Données)

0x0001 - Mappage de certificat d’objet/émetteur (faible – Désactivé par défaut)

0x0002 - Mappage du certificat émetteur (faible – Désactivé par défaut)

0x0004 - Mappage de certificat UPN (faible – Désactivé par défaut)

0x0008 - Mappage de certificat S4U2Self (fort)

0x0010 - Mappage de certificat explicite S4U2Self (fort)

Redémarrage nécessaire ?

Non

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 à partir de septembre 2025.

Sous-clé de Registre

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Value (Valeur)

CertificateBackdatingCompensation

Type de données

REG_DWORD

Data (Données)

Valeurs de la solution de contournement en années approximatives :

  • 50 ans : 0x5E0C89C0

  • 25 ans : 0x2EFE0780

  • 10 ans : 0x12CC0300

  • 5 ans : 0x9660180

  • 3 ans : 0x5A39A80

  • 1 an : 0x1E13380

Remarque Si vous connaissez la durée de vie des certificats dans votre environnement, définissez cette clé de Registre sur légèrement plus longue que la durée de vie du certificat.  Si vous ne connaissez pas la durée de vie des certificats pour votre environnement, définissez cette clé de Registre sur 50 ans. La valeur par défaut est 10 minutes lorsque cette clé n’est pas présente, ce qui correspond aux services de certificats Active Directory (ADCS). La valeur maximale est de 50 ans (0x5E0C89C0).

Cette clé définit la différence de temps, en secondes, que le Centre de distribution de clés (KDC) ignorera entre l’heure d’émission d’un certificat d’authentification et l’heure de création du compte pour les comptes d’utilisateur/ordinateur.

Important Définissez cette clé de Registre uniquement si votre environnement l’exige. L’utilisation de cette clé de Registre désactive un case activée de sécurité.

Redémarrage nécessaire ?

Non

Autorités de certification d’entreprise

Les autorités de certification d’entreprise commencent à ajouter une nouvelle extension non critique avec l’identificateur d’objet (OID) (1.3.6.1.4.1.311.25.2) par défaut dans tous les certificats émis sur les modèles en ligne après l’installation de la mise à jour Windows du 10 mai 2022. Vous pouvez arrêter l’ajout de cette extension en définissant le bit 0x00080000 dans la valeur msPKI-Enrollment-Flag du modèle correspondant.

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 ».

Forum aux questions

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. ​​​​​​​

Ressources supplémentaires

Pour plus d’informations sur le mappage de certificat client TLS, consultez les articles suivants :

Besoin d’aide ?

Vous voulez plus d’options ?

Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.

Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.