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

Aucun mappage de certificat fort n’a été trouvé et le certificat n’avait pas la nouvelle extension d’identificateur de sécurité (SID) que le KDC a pu valider.

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

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

Remarque Certains champs, tels que l’émetteur, l’objet et le numéro de série, sont déclarés dans un format « transféré ». 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 : 2B0000000011AC0000000012

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>1200000000AC11000000002B »

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>1200000000AC11000000002B"}

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 Procédure : Mapper un utilisateur à un certificat 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 seront en mode de compatibilité. Si un certificat peut être fortement associé à un utilisateur, l’authentification se produit comme prévu. Si un certificat ne peut être mappé que faiblement à un utilisateur, l’authentification se produit comme prévu. Toutefois, un message d’avertissement est enregistré, sauf si le certificat est plus ancien que celui de l’utilisateur. Si le certificat est plus ancien que l’utilisateur et que la clé de Registre antidatée du certificat n’est pas présente ou que la plage est en dehors de la compensation antidative, l’authentification échoue et un message d’erreur est enregistré.  Si la clé de registre antidatée du certificat est configurée, elle enregistre un message d’avertissement dans le journal des événements si les dates tombent dans la compensation d’antidatage.

Après avoir installé les mises à jour Windows du 10 mai 2022, soyez à l’affût de tout message d’avertissement qui pourrait s’afficher après un mois ou plus. Si aucun message d’avertissement ne s’affiche, il est vivement recommandé d’activer le mode de mise en conformité totale sur tous les contrôleurs de domaine à l’aide de l’authentification par certificat. Vous pouvez utiliser la clé de Registre KDC pour activer le mode de mise en conformité complète.

À moins d’avoir été mis à jour en mode Audit ou en mode Application à l’aide de la clé de Registre StrongCertificateBindingEnforcement plus tôt, les contrôleurs de domaine passeront en 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 associé. L’option permettant de revenir au mode de compatibilité restera en vigueur jusqu’à l’installation de la mise à jour de sécurité Windows du 9 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 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 le recommande pas , 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 pris en charge les clients avec la fonctionnalité facultative RSAT installée, le mappage de certificat dans Utilisateurs & ordinateurs Active Directory sélectionnera par défaut le mappage fort à l’aide de X509IssuerSerialNumber au lieu du mappage faible à l’aide de X509IssuerSubject. Le paramètre peut toujours être modifié comme vous le souhaitez.

Symptômes

Microsoft a reçu des rapports indiquant que le paramètre « Traiter même si les objets de la stratégie de groupe n’ont pas changé » sous l’objet de stratégie de groupe « Configuration ordinateur> Modèles >d’administrationSystème> :Stratégie de groupeConfigurer le traitement de la stratégie de > Registrepeut interférer par intermittence avec les mappages basés sur des noms sur les contrôleurs de domaine.

Solution de contournement

Pour contourner ce problème, désactivez le paramètre « Traiter même si les objets de la stratégie de groupe n’ont pas changé » sur les contrôleurs de domaine. Ne le faites que si des mappages basés sur le nom, tels que définis dans la stratégie de groupe« Configuration> de l’ordinateur,système de modèles d’administration,>> KDCAutoriser les mappages forts basés sur le nom pour les certificats » sont nécessaires.> Pour plus d’informations, reportez-vous à la rubrique Activer une mise en correspondance forte basée sur les noms dans les scénarios du secteur public.

Étape suivante

Nous enquêtons sur ces rapports et fournirons plus d’informations dès qu’ils seront disponibles.

• Utilisez le journal des opérations Kerberos sur l’ordinateur concerné pour déterminer le contrôleur de domaine qui échoue à la connexion. Accédez à l’observateur d’événementsJournaux\ d’applications >et de servicesMicrosoft \ Windows \Security-Kerberos\opérationnel.
• 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 plus ancien que le compte, rééditez-le ou ajoutez un mappage altSecurityIdentities sécurisé au compte (voir Mappages de certificat).
• 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 aura besoin d’un mappage altSecurityIdentities distinct.
• Si le certificat n’a pas de mappage sécurisé vers le 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 consiste à utiliser une application web intranet IIS.

• Après l’installation des protections CVE-2022-26391 et CVE-2022-26923 , ces scénarios utilisent le protocole S4U (Certificate Service For User) pour le mappage et l’authentification des certificats par défaut.
• Dans le protocole Kerberos Certificate S4U, la demande d’authentification circule du serveur d’applications au contrôleur de domaine, et non du client au contrôleur de domaine. Par conséquent, les événements pertinents se trouveront sur le serveur d’applications.

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.

Lorsqu’une application serveur nécessite une authentification client, Schannel tente automatiquement de mapper le certificat que le client TLS fournit à 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 du 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 essaiera de mapper chaque méthode de mappage de certificat que vous avez activée jusqu’à ce que l’une d’entre elles réussisse. Schannel essaie d’abord de mapper les mappages Service-For-User-To-Self (S4U2Self). Les mappages de certificat Subject/Issuer, Issuer et UPN sont désormais considérés comme faibles et ont été désactivés par défaut. La somme bitmasked 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 était 0x1F et est désormais 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, affectez-lui la valeur 0x1F et vérifiez si cela résout le problème. Pour plus d’informations, recherchez les erreurs répertoriées dans cet article dans les journaux d’événements système du contrôleur de domaine. N’oubliez pas que la modification de la valeur de clé de Registre SChannel par défaut précédente (0x1F) reviendra à l’utilisation de méthodes de mappage de certificat faibles.

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

Après avoir installé les mises à jour qui traitent de CVE-2022-26931 et CVE-2022-26923, l’authentification peut échouer dans les cas où les certificats utilisateur sont plus anciens que l’heure de création des utilisateurs. Cette clé de Registre permet une authentification réussie lorsque vous utilisez des mappages de certificat 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 ordinateurs avec des mappages de certificat 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 certificat forts. Cette clé de Registre n’a aucun effet lorsque StrongCertificateBindingEnforcement est défini sur 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 ne fonctionne qu’en mode de compatibilité à partir des mises à jour publiées le 10 mai 2022. L’authentification est autorisée dans le décalage de compensation antidateur, mais un avertissement du journal des événements est 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 comme 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.

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 de l’autorité de certification ou à un client Windows 10 joint à un domaine avec un 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 supprimera la protection fournie par la nouvelle extension. Envisagez de ne le faire qu’après l’une des situations 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 de protocole Kerberos auprès du KDC
2. Les certificats correspondants ont d’autres mappages de certificat forts configurés

Les environnements qui ont des déploiements non-Microsoft CA 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 collaborer 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 nécessaire. L’autorité de certification est 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 la mise en conformité (la valeur de registre StrongCertificateBindingEnforcement est définie sur 2) seront déplacés vers la mise en conformité. 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). À ce stade, vous aurez la possibilité de redéfinir la valeur de la clé de Registre sur 1 (mode de compatibilité).

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