AD FS, Okta, Entra ID : l'identité fédérée est devenue

Une CVE critique dans AD FS activement exploitée, un incident Okta dont les techniques circulent toujours, des tokens SAML forgés qui déverrouillent Microsoft 365, Azure et AWS sans laisser la moindre trace dans les logs réseau : le constat est sans appel. Le périmètre réseau a cessé d'être une frontière défendable, et les attaquants l'ont intégré bien avant beaucoup de RSSI. Désormais, quiconque contrôle le fournisseur d'identité contrôle l'ensemble du système d'information, quel que soit le nombre de pare-feux déployés en amont. C'est précisément pourquoi l'identité fédérée sécurité AD FS, Okta ou Entra ID constitue le point de bascule des architectures modernes. Cet article détaille les vecteurs d'attaque réellement observés, les angles morts de la détection et les mesures de durcissement à mettre en œuvre en priorité sur vos infrastructures d'authentification.

Le périmètre réseau est mort. L'identité l'a remplacé.

La métaphore du château fort avec ses douves et ses remparts résume parfaitement ce que les équipes sécurité ont passé vingt ans à construire : un périmètre réseau solide, avec un pare-feu en entrée, des zones DMZ, des VLAN segmentés. Le problème ? Ce modèle part du principe que tout ce qui est à l'intérieur du périmètre est de confiance, et tout ce qui est dehors est suspect. Cette hypothèse s'est effondrée avec la mobilité, le cloud, et le télétravail généralisé.

Aujourd'hui, un employé accède à Microsoft 365 depuis son domicile, à Salesforce depuis l'aéroport, et à l'ERP de l'entreprise via un VPN SSL. Ses identifiants sont le seul fil qui relie ces accès. Le pare-feu ne voit rien de tout ça — ou plutôt, il voit du HTTPS vers des domaines cloud légitimes, qu'il ne peut pas inspecter. Ce qui contrôle réellement l'accès à l'ensemble du système d'information, c'est l'infrastructure d'identité : l'Active Directory, le serveur AD FS qui fédère vers le cloud, l'Entra ID (anciennement Azure AD), le fournisseur d'identité tiers comme Okta ou PingFederate.

Les attaquants ont fait cette transition bien avant la majorité des équipes de défense. Selon le CrowdStrike Global Threat Report 2026, 80% des intrusions initiales observées en 2025 impliquaient l'utilisation d'identifiants valides — non pas de malwares sophistiqués, non pas d'exploits 0-day, mais simplement des credentials volés, phishés ou obtenus via un accès à l'infrastructure d'identité. Ce chiffre est en hausse de 12 points par rapport à 2023. Les groupes cybercriminels sont rationnels : ils ciblent ce qui est rentable et difficile à défendre. Et aujourd'hui, l'identité est l'actif le moins bien protégé dans la majorité des organisations.

La raison de cette vulnérabilité structurelle est simple : l'infrastructure d'identité a été construite pour la disponibilité et la facilité d'usage, pas pour la sécurité. Active Directory date de 1999. AD FS a été conçu à une époque où les déploiements cloud n'existaient pas. La configuration par défaut d'un serveur AD FS laisse des portes ouvertes que les attaquants exploitent systématiquement. Et pendant des années, ces systèmes n'ont pas été traités comme des actifs critiques au même titre qu'un pare-feu ou un antivirus.

Le changement de paradigme est brutal dans sa logique : si l'identité est ce qui contrôle l'accès à tout, alors l'identité est ce que les attaquants doivent compromettre en priorité. C'est exactement ce qu'ils font. Les campagnes APT les plus sophistiquées ne commencent plus par exploiter un service web exposé — elles commencent par du spear-phishing ciblé vers des administrateurs d'identité, par l'exploitation de vulnérabilités dans les providers SSO, ou par l'achat d'accès initiaux à des systèmes d'authentification sur des forums spécialisés.

Anatomie d'une compromission AD FS : du foothold au token SAML forgé

Pour comprendre pourquoi AD FS est si attractif pour les attaquants, il faut comprendre ce qu'il fait et quelle puissance il représente pour quelqu'un qui le contrôle.

AD FS est le service qui émet des tokens SAML (Security Assertion Markup Language) ou des tokens WS-Federation pour permettre aux utilisateurs de s'authentifier auprès de services tiers sans saisir de nouveau leur mot de passe. Concrètement, quand un utilisateur clique sur "Se connecter avec le compte de votre entreprise" dans une application SaaS, c'est AD FS qui entre en jeu : il vérifie l'identité de l'utilisateur auprès d'Active Directory, puis émet un token signé cryptographiquement que l'application SaaS accepte comme preuve d'authentification valide.

La clé de cette mécanique est la clé de signature de token — le certificat privé qu'AD FS utilise pour signer ses assertions SAML. Si un attaquant accède à cette clé, il peut forger des tokens SAML valides pour n'importe quel utilisateur, sans connaître son mot de passe, sans déclencher d'alerte dans Active Directory, et sans laisser de trace dans les logs de l'application cible. C'est le "Golden SAML" — l'équivalent du Golden Ticket Kerberos, mais pour le monde fédéré.

La chaîne d'exploitation typique se déroule ainsi. Première étape : accès initial via phishing, exploitation d'une vulnérabilité sur un système exposé (VPN, Outlook Web Access, serveur web), ou achat d'un accès initial sur le marché noir. Deuxième étape : reconnaissance interne, identification des serveurs AD FS, généralement accessibles depuis Internet pour l'authentification en mobilité. Troisième étape : lateral movement vers le serveur AD FS via les credentials récupérés ou une vulnérabilité d'élévation de privilèges comme CVE-2026-56155. Quatrième étape : extraction de la clé de signature de token stockée dans le conteneur DKM d'Active Directory. Cinquième étape : fabrication de tokens SAML pour accéder à Microsoft 365, Azure, AWS, Salesforce, ou tout service fédéré — sans limite de durée, sans MFA, sans aucune contrainte.

Ce scénario n'est pas théorique. C'est exactement la technique qu'a utilisée le groupe APT29 (Midnight Blizzard, Cozy Bear) lors de la compromission de SolarWinds en 2020-2021, qui avait abouti à l'accès à des dizaines d'agences gouvernementales américaines et à Microsoft lui-même. En 2023, le même groupe a de nouveau utilisé des techniques Golden SAML pour accéder à des boîtes mail de diplomates européens via des comptes Microsoft 365 compromis. En 2026, CVE-2026-56155 a été découvert par le DART de Microsoft lors de l'investigation d'incidents réels — ce qui confirme que la technique est toujours active et opérationnelle, avec des variantes qui s'adaptent aux correctifs précédents.

Ce qui rend la technique Golden SAML particulièrement dangereuse, c'est son invisibilité dans les outils de détection traditionnels. Un token SAML forgé est cryptographiquement valide — il est signé avec la vraie clé de l'organisation, accepté par les applications fédérées sans aucune vérification supplémentaire. Les logs de l'application cloud montrent une authentification réussie d'un utilisateur légitime. Seule une analyse des timestamps d'émission et de consommation des tokens, ou une surveillance spécifique des accès à la clé de signing dans AD, peut révéler une anomalie.

CVE-2026-56155 : pourquoi ce zero-day est particulièrement inquiétant

CVE-2026-56155, corrigé dans le Patch Tuesday du 14 juillet 2026, mérite qu'on s'y attarde au-delà du simple numéro de CVE. La faille réside dans la gestion des ACL du conteneur DKM d'Active Directory — le conteneur où sont stockées les clés cryptographiques qu'AD FS utilise pour signer ses tokens SAML.

La vulnérabilité CWE-1220 (Insufficient Granularity of Access Control) signifie que les permissions sur ce conteneur sont trop larges : un compte avec de faibles privilèges locaux sur le serveur AD FS peut lire les clés de chiffrement qui ne devraient être accessibles qu'aux administrateurs AD FS. En termes pratiques, cela veut dire qu'un attaquant qui a compromis n'importe quel compte de service sur un serveur AD FS — un compte de monitoring, un compte de backup, un compte d'application — peut extraire les clés de signature et forger des tokens SAML pour l'ensemble de l'infrastructure fédérée.

Ce qui est particulièrement inquiétant dans CVE-2026-56155, c'est la faiblesse du prérequis. Un score CVSS de 7.8 peut sembler moins sévère qu'un CVSS 10.0, mais ce score cache une réalité opérationnelle : dans le contexte d'une attaque en cours, l'attaquant qui a déjà un foothold dans le SI dispose presque toujours d'un compte à faibles privilèges. La barre d'accès à "faibles privilèges locaux sur un serveur AD FS" est franchissable depuis un ordinateur utilisateur standard via le lateral movement — surtout si le serveur AD FS n'est pas isolé dans un segment réseau dédié, ce qui est la norme dans beaucoup d'organisations.

La correction proposée par Microsoft introduit un mécanisme en deux phases. Le mode audit d'abord (Event ID 1132, détecte sans corriger), puis une remédiation activable via la clé de registre RemediateDkmAcl. Microsoft a annoncé une remédiation automatique pour octobre 2026 — trois mois après le patch. Ce délai est compréhensible d'un point de vue de compatibilité (modifier les ACL DKM peut affecter les environnements multi-serveurs AD FS non correctement configurés), mais il laisse une fenêtre d'exploitation pour les organisations qui n'activent pas manuellement la remédiation. Si vous avez appliqué le patch de juillet 2026 sans activer RemediateDkmAcl, vous avez détecté votre exposition sans la corriger — et c'est exactement la situation que les attaquants espèrent.

Okta, Entra ID, PingFederate : le pattern se répète sur tous les providers

AD FS n'est pas un cas isolé. Le pattern d'attaque sur l'infrastructure d'identité se répète sur l'ensemble des providers SSO, qu'ils soient on-premises ou cloud.

Okta a subi une compromission majeure en octobre 2023, lorsque le groupe Lapsus$ a utilisé les accès d'un employé d'un sous-traitant (Sitel Group) pour accéder au panneau d'administration d'Okta pendant cinq jours. Durant ces cinq jours, les attaquants ont pu voir les données des tenants clients, potentiellement réinitialiser des mots de passe, et accéder à des configurations de sécurité. L'incident a touché environ 2,5% des clients Okta, parmi lesquels des entreprises comme Cloudflare, Coinbase et FedEx. La leçon : même un provider d'identité cloud géré par des milliers d'ingénieurs de sécurité peut être compromis via son maillon le plus faible — le support client externalisé.

Microsoft Entra ID a lui aussi fait l'objet d'attaques ciblant ses mécanismes de fédération. L'OAuth client ID spoofing documenté sur ce site dans un article récent illustre comment des lacunes dans la validation des identités clients OAuth permettent d'accéder à des ressources Entra ID sans déclencher d'alerte dans Defender for Identity. Le vecteur est différent (OAuth plutôt que SAML), mais le principe reste le même : exploiter une faiblesse dans le mécanisme de confiance entre le provider d'identité et les applications pour obtenir un accès non autorisé sans credentials valides.

PingFederate, largement déployé dans les grandes entreprises américaines et les banques, a connu trois vulnérabilités critiques en 2025-2026, dont une permettant l'exécution de code à distance sur le serveur d'identité (CVE-2025-26869, CVSS 9.8). La compromission d'un serveur PingFederate donne les mêmes pouvoirs qu'une compromission AD FS : accès aux clés de signature, capacité à forger des assertions SAML valides pour tous les services fédérés.

Le dénominateur commun de tous ces incidents est la concentration du risque. Un seul serveur AD FS, un seul tenant Okta, un seul serveur PingFederate concentre l'accès à l'ensemble des services de l'organisation. C'est à la fois la force de ces architectures (expérience utilisateur unifiée, gestion centralisée) et leur talon d'Achille majeur : single point of failure de sécurité. Les attaquants l'ont compris : pourquoi tenter de compromettre cinquante applications séparément quand on peut compromettre le provider d'identité et accéder à toutes simultanément ?

Les cinq erreurs de configuration qui font le bonheur des attaquants

Dans mes missions d'audit, je retrouve systématiquement les mêmes problèmes sur les infrastructures AD FS et SSO. Ces cinq erreurs constituent le tableau clinique type de l'organisation exposée.

Erreur 1 : Le serveur AD FS exposé directement sur Internet sans proxy applicatif. AD FS est conçu pour être accessible en dehors du réseau d'entreprise (pour l'authentification en mobilité), mais il doit être exposé derrière un Web Application Proxy (WAP) ou un reverse proxy de sécurité, jamais directement. Exposer le service AD FS en direct augmente la surface d'attaque et permet aux attaquants d'interagir directement avec des endpoints qui ne devraient pas être accessibles, notamment les endpoints d'administration et de configuration. Dans les audits que je conduis, environ un tiers des organisations ayant AD FS l'exposent sans proxy dédié, souvent pour des raisons de simplification de la configuration initiale qui n'ont jamais été revisitées.

Erreur 2 : Les ACL DKM trop permissives. C'est exactement la configuration que corrige CVE-2026-56155. Le conteneur DKM dans Active Directory qui stocke les clés de chiffrement AD FS dispose de permissions trop larges dans une configuration par défaut. Des comptes de service avec des droits étendus sur Active Directory peuvent lire ces clés. Avant le patch de juillet 2026, cette configuration existait dans quasiment tous les déploiements AD FS standards. Après le patch, il faut activer activement RemediateDkmAcl pour corriger — une action que beaucoup d'équipes ne feront pas spontanément si elles n'en comprennent pas l'importance.

Erreur 3 : Pas de MFA sur les comptes d'administration AD FS et Active Directory. La sécurité d'AD FS est aussi forte que la sécurité des comptes Domain Admin qui le gèrent. Si ces comptes ne sont pas protégés par MFA et par des privilèges d'administration à accès juste à temps via PAM/PIM, un attaquant qui compromet les credentials d'un Domain Admin contrôle l'intégralité de l'infrastructure d'identité. C'est un problème fondamental mais que je retrouve dans une majorité des organisations auditées, même parmi celles qui ont déployé le MFA pour leurs utilisateurs finaux.

Erreur 4 : Durée de vie excessive des tokens et absence de révocation. Les tokens SAML et OAuth émis par AD FS ont une durée de vie configurable. Dans beaucoup d'organisations, cette durée est laissée à sa valeur par défaut (souvent 8 à 24 heures pour les tokens d'accès, plusieurs jours pour les tokens de rafraîchissement). Un attaquant qui forge ou vole un token valide dispose d'une fenêtre d'accès longue, sans possibilité de révocation rapide si l'infrastructure de détection ne surveille pas les anomalies de comportement des sessions. Implémenter un Conditional Access avec évaluation continue de l'accès (CAE) réduit significativement cette fenêtre en permettant une révocation quasi-instantanée.

Erreur 5 : Logging insuffisant et absence de détection comportementale sur l'identité. AD FS génère des logs dans le journal AD FS Admin et dans les logs de sécurité Windows. Ces logs contiennent des informations précieuses : authentifications, changements de configuration, accès aux endpoints administratifs. Dans les organisations que j'audite, moins de 30% ingèrent ces logs dans leur SIEM de façon complète et les associent à des règles de détection actives. Sans cette visibilité, la compromission d'AD FS peut passer des semaines ou des mois sans être détectée — exactement comme dans l'incident SolarWinds où la compromission a duré neuf mois avant d'être découverte.

Durcissement de l'identité fédérée : les actions concrètes

La bonne nouvelle, c'est que durcir une infrastructure AD FS ou SSO n'est pas un projet de plusieurs années. Les actions à forte valeur ajoutée sont identifiables et implémentables en quelques semaines pour une organisation décidée. Voici ce que je recommande systématiquement en sortie d'audit.

Patch immédiat et activation de RemediateDkmAcl. Si vous avez un serveur AD FS, appliquer le Patch Tuesday du 14 juillet 2026 n'est pas optionnel. Après le patch, activer immédiatement la clé de registre RemediateDkmAcl plutôt qu'attendre l'enforcement automatique d'octobre 2026. Vérifier les Event ID 1132 dans le journal AD FS Admin pour confirmer que la configuration DKM était vulnérable et a bien été corrigée.

Surveillance des Event ID clés d'AD FS. Configurer votre SIEM pour ingérer et corréler les Event ID suivants : 1007 (authentification réussie — surveiller volumes et origines géographiques inhabituelles), 1008 (authentification échouée — détecter les brute force), 1021 et 1022 (accès à des claims restreints), 1132 (configuration DKM vulnérable détectée). Croiser ces events avec les alertes Entra ID et Defender for Identity pour détecter les comportements Golden SAML, notamment des tokens émis pour un utilisateur sans authentification Active Directory correspondante dans la même fenêtre temporelle.

Isolation réseau du serveur AD FS. Le serveur AD FS ne devrait jamais être exposé directement sur Internet. Déployer un Web Application Proxy dédié en DMZ qui relaie les requêtes d'authentification externes vers le serveur AD FS interne. Restreindre les flux entre le WAP et le serveur AD FS aux seuls ports et protocoles nécessaires (443 et 49443 pour AD FS). Le serveur AD FS lui-même ne devrait être accessible qu'depuis le segment d'administration interne et depuis le WAP.

Durcissement des comptes de service AD FS. Le compte de service sous lequel tourne AD FS (ou le gMSA, Group Managed Service Account) doit être restreint au strict minimum nécessaire. Il ne doit pas être membre de Domain Admins, ne doit pas avoir d'accès interactif aux serveurs, et son utilisation doit être surveillée. Tout accès interactif de ce compte devrait déclencher une alerte immédiate dans votre SIEM.

Conditional Access et évaluation continue des sessions. Configurer des politiques de Conditional Access dans Entra ID qui réévaluent en permanence le risque des sessions actives (Continuous Access Evaluation, CAE). CAE permet de révoquer une session en cours si un token de risque élevé est émis, si l'utilisateur est désactivé, ou si sa localisation change de façon suspecte — sans attendre l'expiration naturelle du token. C'est la réponse technique au problème de la durée de vie excessive des tokens SAML ou OAuth.

Plan de rotation des clés de signing token. Définir et tester un processus de rotation des clés de signature de token AD FS. Par défaut, AD FS gère automatiquement la rotation annuelle des certificats, mais ce processus doit être documenté et testé pour éviter des interruptions de service lors d'une rotation d'urgence post-incident. Si les clés de signing ont été potentiellement compromises lors d'un incident de sécurité, une rotation d'urgence s'impose — et vous devez savoir le faire en moins d'une heure, pas en découvrir le processus sous pression.

Ce qui va changer dans les six prochains mois

L'écosystème de l'identité fédérée est en pleine transformation sous la pression combinée des attaquants et des régulateurs. Voici les évolutions que j'anticipe d'ici janvier 2027.

Microsoft va accélérer la pression pour migrer d'AD FS on-premises vers Entra ID cloud. L'enforcement automatique de RemediateDkmAcl en octobre 2026 n'est qu'une étape. Les annonces récentes sur la fin de vie de certaines fonctionnalités AD FS dans Windows Server 2025 envoient un signal clair : Microsoft veut que ses clients abandonnent AD FS on-premises au profit d'Entra ID. Du point de vue de la sécurité, c'est généralement une bonne chose — un provider d'identité cloud avec des milliers d'ingénieurs de sécurité dédiés offre une surface d'attaque mieux contrôlée qu'un serveur Windows on-premises géré par une équipe IT généraliste. Du point de vue de la souveraineté et de la conformité, c'est plus complexe, notamment pour les organisations soumises à des contraintes SecNumCloud ou RGPD avec hébergement en France.

NIS2, entrée en application en France depuis octobre 2024 et dont l'ANSSI publie progressivement les guides de mise en conformité, va renforcer les obligations autour de la gestion de l'identité et des accès privilégiés. Les organisations assujetties (OES, OIV, fournisseurs critiques) vont devoir démontrer un niveau de maîtrise de leur infrastructure d'identité qui dépasse largement ce que la majorité font aujourd'hui. Cela va se traduire par des audits AD FS, des revues des ACL DKM, des tests de Golden SAML, et des exercices de rotation de clés dans les plans de réponse aux incidents.

Le standard FIDO2 et les passkeys vont continuer à progresser comme alternative à l'authentification fédérée classique pour les cas d'usage utilisateur. L'un des avantages fondamentaux de FIDO2 est qu'il élimine le token SAML comme surface d'attaque pour les authentifications utilisateur : pas d'assertion transmise sur le réseau, pas de clé de signing centralisée, pas de risque de Golden SAML. Microsoft, Google, Apple et les principaux fournisseurs d'identité supportent désormais FIDO2, et plusieurs grandes organisations ont commencé des programmes de migration de leurs populations d'utilisateurs vers des passkeys. Ce n'est pas une solution universelle pour les authentifications machine-à-machine ou les fédérations complexes, mais c'est la direction du marché pour réduire la surface d'attaque côté utilisateur final.

Questions fréquentes

Qu'est-ce que identité fédérée sécurité AD FS et pourquoi est-ce important ?

La réponse dépend du contexte organisationnel, mais les principes fondamentaux restent constants : évaluation du périmètre, identification des actifs critiques et priorisation par risque réel plutôt que par vulnérabilité isolée.

Comment mettre en oeuvre les bonnes pratiques liées à identité fédérée sécurité AD FS ?

Une approche structurée et documentée est clé. Les outils et méthodologies évoluent rapidement — rester informé des ressources ANSSI, NIST et MITRE ATT&CK est indispensable pour adapter les recommandations génériques à chaque contexte.

Quelles ressources pour approfondir identité fédérée sécurité AD FS ?

Les ressources officielles (ANSSI, CISA, CERT-FR) constituent le point de départ. Complétées par des retours d'expérience terrain, elles permettent d'adapter les recommandations aux réalités opérationnelles de chaque organisation.

Conclusion

L'identité fédérée est devenue le périmètre du SI moderne. AD FS, Okta, Entra ID, PingFederate — ces systèmes concentrent les accès à l'ensemble de votre infrastructure et représentent une cible de valeur exceptionnelle pour les attaquants sophistiqués. CVE-2026-56155 est la dernière démonstration en date de cette réalité : un zero-day découvert lors d'incidents réels, activement exploité, permettant de compromettre l'ensemble de l'écosystème fédéré depuis un seul point d'entrée.

La réponse immédiate est claire : patcher, activer RemediateDkmAcl, surveiller les Event ID critiques. Mais la réponse durable demande un changement de perspective : considérer votre infrastructure d'identité avec le même niveau d'exigence que vous accordez à votre infrastructure réseau ou à vos systèmes de production. Auditer les configurations DKM, isoler les serveurs AD FS, protéger les comptes de service, implémenter le Conditional Access, planifier la rotation des clés. Ce n'est pas de la sécurité théorique — c'est ce qui différencie les organisations qui détectent une compromission en quelques heures de celles qui la découvrent neuf mois plus tard dans un rapport du DART de Microsoft.