Strong Certificate Mapping : préparez votre MDM/UEM à l’application stricte

Le problème : l’application complète de KB5014754

Microsoft introduit le Strong Certificate Mapping Enforcement pour corriger des vulnérabilités dans l’authentification par certificat d’Active Directory.

À partir des mises à jour Windows de février 2025, les contrôleurs de domaine exigeront que tout certificat utilisé pour l’authentification client comporte un mappage sécurisé vers son compte utilisateur, concrètement en intégrant le Security Identifier (SID) de l’utilisateur. Ce changement (décrit dans la KB5014754) vise à empêcher les attaquants d’usurper des identités à l’aide de certificats en imposant un mappage plus strict.

Auparavant, les certificats étaient mappés aux utilisateurs via des attributs comme l’UPN ou le nom du sujet, ce qui est désormais considéré comme un mappage « faible ». Avec la nouvelle règle, seuls les mappages « forts » (mappages explicites ou SID correspondant intégré dans le certificat) seront acceptés pour l’ouverture de session Kerberos.

Pour la mobilité d’entreprise, ce point concerne tout particulièrement l’authentification Kerberos sur les appareils mobiles. Hypergate Authenticator (qui fournit le SSO Kerberos sur Android) s’appuie sur des certificats utilisateur pour obtenir des tickets Kerberos. Ces certificats sont généralement émis via un MDM (comme Ivanti Neurons, MobileIron, etc.) au moyen de SCEP ou d’un mécanisme similaire, et ils n’incluent pas encore le SID Active Directory. Avec cette nouvelle exigence, les connexions mobiles par certificat commenceront à échouer par défaut dès que l’application complète sera active, sauf mise à jour préalable. Autrement dit, l’authentification Kerberos des clients mobiles (Android, iOS, etc.) reposant sur un certificat cessera de fonctionner si les certificats ne sont pas mis à jour.

Les versions de Windows Server concernées sont les suivantes :

• Windows Server 2025
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 avec ESU

Ainsi que tous les MDM/UEM, quelle que soit leur version :

• Microsoft Intune
• Ivanti Neurons, anciennement MobileIron Core/Cloud
• Omnissa Workspace One, anciennement VmWare AirWatch
• BlackBerry UEM
• Soti Mobicontrol
• Samsung Knox

Microsoft a prévu une période de transition en « mode de compatibilité » (journalisation d’avertissements sans blocage de l’authentification), mais depuis le 11 février 2025, le mappage fort est le comportement par défaut, et à partir du 10 septembre 2025, le mode de compatibilité disparaîtra complètement.

Impact sur Hypergate Authenticator

Dans les déploiements MDM actuels, les utilisateurs Android équipés de Hypergate Authenticator reçoivent un certificat utilisateur (distribué via le MDM) et l’utilisent pour l’authentification Kerberos (PKINIT). Sans mappage fort, ces ouvertures de session ne réussissent aujourd’hui que grâce au mode de compatibilité et elles génèrent des avertissements sur vos contrôleurs de domaine. Une fois le mappage fort strictement appliqué (au plus tard en septembre 2025), tout certificat dépourvu de la liaison SID appropriée sera rejeté, ce qui empêchera les utilisateurs mobiles de s’authentifier auprès des services intranet via Kerberos.

Concrètement, un certificat utilisateur déployé aujourd’hui par votre MDM contient généralement l’UPN de l’utilisateur dans le Subject ou le SAN, qu’Active Directory mappe au compte. Avec l’application stricte, le KDC exigera un mappage sécurisé (soit un mappage explicite altSecurityIdentities dans AD, soit l’extension SID intégrée). Si le certificat ne contient pas le SID, le KDC refusera d’émettre un TGT. Les sessions SSO Kerberos (via Hypergate Authenticator) commenceront donc à échouer. Microsoft indique explicitement que les certificats émis via un MDM ou NDES (qui utilisent des « offline templates ») sont à risque et que des échecs d’authentification sont probables si ces certificats ne respectent pas les nouvelles exigences. En bref, vos collaborateurs mobiles pourraient perdre du jour au lendemain l’accès aux ressources authentifiées par Kerberos si rien n’est fait.

Erreurs à prévoir en cas d’échec du mappage de certificat

Voici des exemples d’erreurs que vous pouvez rencontrer à cause de ce problème :

• Observateur d’événements Windows (contrôleur de domaine, KDC) : Event ID 39 (avertissement ou erreur) :

  « The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID)… ».

  Cela signifie que le certificat présenté ne disposait d’aucun mappage fort (ni extension SID ni mappage explicite). En mode de compatibilité, un avertissement est journalisé et la connexion est autorisée ; en mode d’application complète, il s’agira d’une erreur et la connexion sera rejetée.

• Observateur d’événements Windows (contrôleur de domaine, KDC) : Event ID 41 (erreur) :

  « The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed. »

  Cela signifie que le certificat contenait bien un SID, mais qu’il ne correspondait pas au SID du compte utilisateur cible (échec d’un contrôle de mappage sécurisé). L’authentification est refusée pour des raisons de sécurité.

• Journaux du client Kerberos (Hypergate Authenticator) : dans les journaux Kerberos détaillés (ou les journaux de débogage Hypergate), vous verrez une erreur du type « Received error from KDC: … Certificate mismatch » lors de la tentative d’obtention d’un TGT.

  Par exemple, une tentative kinit peut renvoyer KDC_ERR_CERTIFICATE_MISMATCH. Cela correspond à l’événement ci-dessus côté KDC : le contrôleur de domaine indique en substance « je ne peux pas accepter ce certificat pour cet utilisateur ».

Ces erreurs montrent clairement que le mappage entre le certificat et le compte n’est pas considéré comme sécurisé. L’exigence d’extension SID est la clé pour les résoudre. Voyons maintenant comment procéder dans un environnement MDM/UEM avec Hypergate.

Solution : le mappage fort de certificats via votre MDM

Pour garantir la continuité du SSO Kerberos mobile, deux approches existent : activer le mode de compatibilité puis mettre à jour les certificats, ou mettre à jour les certificats directement.

L’objectif final est de mettre à jour les certificats au plus tard en septembre 2025 afin que tous les certificats clients Kerberos portent le mappage SID approprié.

Contournement temporaire : activer le mode de compatibilité sur les contrôleurs de domaine

En mesure d’atténuation immédiate, activez le mode de compatibilité pour le mappage de certificats sur tous les contrôleurs de domaine. L’authentification continuera ainsi de fonctionner avec des certificats à mappage « faible » jusqu’à leur mise à jour, ce qui évite toute interruption avant l’échéance. Microsoft recommande de définir une clé de registre sur chaque DC :

• Chemin de registre : HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Nom de la valeur : StrongCertificateBindingEnforcement (REG_DWORD)

• Données de la valeur : 1 (pour le mode de compatibilité, où les certificats sans SID restent autorisés mais journalisés)

Les valeurs possibles sont :

• 0 : Mode de compatibilité : désactive le contrôle du mappage fort de certificats. Déconseillé, car cela désactive toutes les améliorations de sécurité. (plus possible après le 11 février 2025)
• 1 : Mode de compatibilité avec avertissements : vérifie s’il existe un mappage fort de certificat. Si oui, l’authentification est autorisée. Sinon, le KDC vérifie si le certificat comporte la nouvelle extension SID et la valide. Si cette extension est absente, l’authentification est autorisée si le compte utilisateur est antérieur au certificat.
• 2 : Application stricte : vérifie s’il existe un mappage fort de certificat. Si oui, l’authentification est autorisée. Sinon, le KDC vérifie si le certificat comporte la nouvelle extension SID et la valide. Si cette extension est absente, l’authentification est refusée.

La valeur 1 maintient les DC en mode de compatibilité (journaliser et autoriser). (La valeur 2 correspond à l’application complète : journaliser et rejeter les certificats sans SID, ce qui deviendra le comportement par défaut après les mises à jour ; la valeur 0 désactiverait entièrement les nouveaux contrôles, option que Microsoft a déjà supprimée dans des mises à jour précédentes. Aucun redémarrage n’est nécessaire pour que la modification prenne effet.

Vous devrez très probablement aussi prendre en compte la clé de registre CertificateBackdatingCompensation. Cette clé couvre le cas particulier où la date d’émission d’un certificat est antérieure à la date de création du compte utilisateur (ce que le KDC juge suspect). En mode de compatibilité, le KDC n’autorise par défaut qu’un écart de 10 minutes :

• Chemin de registre : HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Nom de la valeur : CertificateBackdatingCompensation (REG_DWORD)

• Données de la valeur : 5E0C89C0 (hexadécimal : omettez le 0x pour saisir la valeur correcte via regedit)

Les valeurs possibles sont (choisissez une valeur juste supérieure à la durée de vie de vos certificats) :

• 0x5E0C89C0 : 50 ans
• 0x2EFE0780 : 25 ans
• 0x12CC0300 : 10 ans
• 0x9660180 : 5 ans
• 0x5A39A80 : 3 ans
• 0x1E13380 : 1 an

Cette clé permet aux certificats plus anciens de s’authentifier via un mappage faible dans la limite de cet écart. N’utilisez cette option qu’en cas de besoin et gardez à l’esprit qu’elle ne fonctionne qu’en mode de compatibilité et qu’il s’agit d’un autre contournement temporaire.

Avec le mode de compatibilité activé, les connexions Hypergate de vos utilisateurs continueront de fonctionner pendant la transition (les DC journaliseront toutefois des avertissements). Vous gagnez ainsi le temps nécessaire pour mettre en place le correctif définitif sans interrompre le service.

Correctif définitif : mettre à jour les certificats avec le mappage SID

La solution à long terme consiste à intégrer le SID de l’utilisateur dans le certificat client utilisé par Hypergate (et d’autres services), afin que le certificat puisse être mappé de manière sécurisée au compte de l’utilisateur. Cela passe généralement par la mise à jour de vos modèles de certificats et de la configuration des profils SCEP ou PKCS de votre MDM/UEM. Nous allons l’illustrer dans un environnement Ivanti Neurons :

1. Accédez à Configurations, filtrez sur Identity Certificate et sélectionnez votre configuration de certificat actuelle :
   
2. Ajoutez le Subject Alternate Name supplémentaire suivant, de type Uniform Resource Identifier : tag:microsoft.com,2022-09-14:sid:${user.sid}. Il s’agit d’une date statique : ne la modifiez pas, la date doit être exactement 2022-09-14.
   Les identifiants corrects sont :

   Microsoft Intune : {{OnPremisesSecurityIdentifier}}
   Ivanti EPMM / MobileIron Core : tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Ivanti Neuron / MobileIron Cloud : tag:microsoft.com,2022-09-14:sid:{user.sid}
   BlackBerry UEM : tag:microsoft.com,2022-09-14:sid:%UserSID%
   Soti Mobicontrol : tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Samsung Knox : tag:microsoft.com,2022-09-14:sid:<UserSID>

3. 
5. La configuration du certificat doit ressembler à ceci :
   

6. Le certificat produit contiendra au final les Subject Alternative Names suivants :

   
   

7. Vérifiez le nouveau mappage de certificat : une fois que l’appareil a reçu le nouveau certificat, tentez une authentification Kerberos (PKINIT) via Hypergate Authenticator. Elle doit réussir comme auparavant. Consultez de nouveau les journaux de votre contrôleur de domaine : vous ne devriez plus voir d’avertissements Event 39 pour l’ouverture de session de cet utilisateur. Si le SID est présent et correct, le KDC considérera le mappage comme fort et ne journalisera aucune erreur.

8. Après avoir vérifié le bon fonctionnement du mappage de certificat, nous pouvons désormais passer en application stricte. Cette étape n’est nécessaire que si vous souhaitez imposer les liaisons fortes de certificats avant septembre 2025. Passé cette date, la clé de registre devient sans objet et la liaison sera de toute façon appliquée. Pour l’activer dès aujourd’hui, définissez une clé de registre sur chaque DC :

   • Chemin de registre : HKLM\SYSTEM\CurrentControlSet\Services\Kdc

   • Nom de la valeur : StrongCertificateBindingEnforcement (REG_DWORD)

   • Données de la valeur : 2 (pour le mode strict)

En suivant ces étapes, vous répondez aux nouvelles exigences de Microsoft et votre SSO mobile d’entreprise reste opérationnel. Avec le Strong Certificate Mapping Enforcement pleinement en vigueur, vos utilisateurs Android peuvent continuer à s’authentifier via Kerberos avec Hypergate en toute sécurité, et vos contrôleurs de domaine accepteront le mappage fort basé sur le SID de chaque certificat.