Entra ID SSPR failles de sécurité : non activé, admins exemptés, méthodes de réinitialisation faibles

Entra ID SSPR failles de sécurité : de quoi s'agit-il

La réinitialisation libre-service du mot de passe (SSPR) dans Microsoft Entra ID est censée refermer la boucle de récupération de compte que l'authentification multifacteur ouvre par ailleurs dans le tenant (voir aussi pourquoi le MFA seul ne suffit pas). En pratique, les mêmes trois entra id sspr failles de sécurité reviennent sans cesse sur les tenants réels : SSPR laissé désactivé pour tout le tenant, des administrateurs exclus d'une politique censée exiger une vérification forte, et des méthodes de réinitialisation faibles — questions de sécurité ou SMS — acceptées comme preuve d'identité suffisante à elles seules.

SSPR permet aux utilisateurs de retrouver l'accès à un compte verrouillé sans ouvrir de ticket au helpdesk, en vérifiant leur identité via une ou plusieurs méthodes enregistrées (application Authenticator, e-mail, téléphone, ou questions de sécurité) sur passwordreset.microsoftonline.com. L'activer nécessite au minimum une licence Microsoft Entra ID P1 et le rôle Authentication Policy Administrator, et sa portée peut être définie sur None, un seul groupe (éventuellement imbriqué), ou All (tous les utilisateurs), selon le tutoriel d'activation de Microsoft.

La plupart des déploiements s'arrêtent là, présentés uniquement comme une économie de coûts — moins d'appels au helpdesk, réinitialisation plus rapide pour les utilisateurs finaux, une ligne de plus sur un tableau de licences. C'est ce cadrage qui permet aux trois lacunes suivantes de passer inaperçues :

• SSPR entièrement désactivé (SSPR_NOT_ENABLED) — aucun parcours libre-service n'existe, donc chaque réinitialisation passe par un humain.
• Administrateurs non couverts par une politique de réinitialisation exigeant réellement une vérification forte (SSPR_NOT_REQUIRED_ADMINS) — les comptes à privilèges retombent sur le même parcours manuel, exploitable par ingénierie sociale.
• Méthodes faibles acceptées comme preuve d'identité suffisante (SSPR_METHODS_WEAK) — questions de sécurité ou appels SMS/vocal qui satisfont à eux seuls la politique de réinitialisation.

Aucune de ces situations n'est une mauvaise configuration exotique. Ce sont des états proches du défaut d'usine dans lesquels un tenant dérive simplement en ne revisitant jamais SSPR après la configuration initiale — ce qui explique aussi pourquoi elles sont rarement détectées lors d'une revue de routine : un test d'intrusion ou un audit MFA vérifie généralement si la connexion exige un second facteur, pas si le parcours de récupération de ce même compte est tout aussi solide. Un attaquant n'a pas besoin de contourner le MFA à la porte d'entrée si la porte de derrière — la récupération de mot de passe — ne nécessite qu'une question de sécurité devinée ou un appel téléphonique convaincant.

Les trois lacunes de sécurité SSPR, une par une

Lacune 1 — SSPR entièrement désactivé

Lorsque la portée de SSPR est None, chaque réinitialisation de mot de passe doit passer par l'IT ou le helpdesk. Ce parcours manuel est exactement le vecteur décrit dans l'avis CISA sur Scattered Spider (AA23-320A) : les acteurs malveillants appellent ou envoient un SMS au personnel du helpdesk en se faisant passer pour un employé, demandant une réinitialisation de mot de passe ou un changement d'appareil MFA comme vecteur d'accès initial. Un tenant avec SSPR désactivé n'a pas supprimé le parcours de réinitialisation — il a forcé 100 % des réinitialisations à passer par exactement le canal que cette technique cible, sans donner au helpdesk de référence libre-service à laquelle comparer une demande inhabituelle.

Lacune 2 — Admins non tenus d'utiliser SSPR

Par défaut, Microsoft Entra traite les comptes administrateurs différemment : ils sont couverts par une politique à deux portes intégrée et non modifiable, exigeant deux éléments d'authentification, distincte de la politique (souvent à une seule porte) appliquée aux utilisateurs standards, selon la documentation de Microsoft sur la politique SSPR. Les tenants qui désactivent la politique de réinitialisation admin — sans exclure explicitement les admins de la politique destinée aux utilisateurs — laissent les comptes à privilèges se réinitialiser de la même façon que dans la Lacune 1 : manuellement, via le helpdesk. C'est le compte à protéger en priorité absolue de ce parcours, car une réinitialisation obtenue par ingénierie sociale sur un Global Administrator est une compromission totale du tenant, pas seulement d'une boîte mail.

Lacune 3 — Méthodes de réinitialisation faibles acceptées

Les questions de sécurité peuvent être devinées par quiconque a mené une reconnaissance légère sur une cible, et Microsoft les retire entièrement de SSPR d'ici mars 2027 pour cette raison précise — la documentation de Microsoft elle-même les signale comme « moins sûres que les autres méthodes » et recommande de les associer à une seconde méthode si elles sont utilisées. Les méthodes par téléphone mobile (SMS/appel vocal) portent leur propre risque bien connu d'interception et de SIM-swap — les lignes directrices du NIST sur l'identité numérique classent les codes délivrés par réseau téléphonique comme un authentificateur restreint pour cette raison précise, demandant aux vérificateurs de contrôler les changements de carte SIM et le portage de numéro avant de s'y fier, selon NIST SP 800-63B. Une politique de réinitialisation qui accepte l'une ou l'autre comme unique porte suffisante est fonctionnellement aussi faible que l'absence de politique — le compte n'est qu'à une réponse devinée ou un SMS intercepté de la prise de contrôle.

Détection

Si vous menez une revue de sécurité Entra ID plus large, la posture SSPR doit être vérifiée dans la même passe que Conditional Access et PIM — elle se contrôle avec les mêmes permissions Graph et la même session dans l'admin center.

Interroger directement la couverture d'enregistrement

Connect-MgGraph -Scopes "Reports.Read.All", "Policy.Read.All"

# Posture SSPR des admins
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" |
  Select-Object -ExpandProperty allowedToUseSSPR

# Utilisateurs activés pour SSPR mais pas réellement enregistrés
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
  Select-Object UserPrincipalName, IsAdmin, IsSsprRegistered, MethodsRegistered

Tout compte renvoyé par cette seconde requête peut être activé pour SSPR sur le papier tout en n'ayant aucune méthode conforme réellement enregistrée — ce qui signifie que son parcours de réinitialisation réel, aujourd'hui, reste le helpdesk. Croisez d'abord la colonne IsAdmin avec votre liste de rôles à privilèges ; un compte Global Administrator ou d'annuaire présent dans ce résultat cumule Lacune 2 et Lacune 3 sur la même identité, ce qui en fait la combinaison à trier en priorité sur cette liste.

Remédiation

Fermer la Lacune 1 — Activer SSPR pour tout le tenant

Dans l'admin center Entra, sous Protection → Password reset → Properties, définissez la portée sur All plutôt que None ou un seul groupe pilote. Cela nécessite le rôle Authentication Policy Administrator et une licence Entra ID P1+, selon le tutoriel de Microsoft.

Fermer la Lacune 2 — Soumettre les comptes admin à une vraie politique de réinitialisation

Confirmez que allowedToUseSSPR sur authorizationPolicy reflète une décision intentionnelle, et que les rôles à privilèges sont couverts par la politique admin intégrée à deux portes d'Entra plutôt que silencieusement exclus, selon la documentation de Microsoft sur la politique SSPR. Pour vos rôles les plus sensibles (Global Administrator et équivalents), associez cela à des méthodes résistantes au phishing et à des comptes d'accès d'urgence break-glass étroitement surveillés et exclus du Conditional Access, afin que la récupération ne dépende jamais uniquement de SSPR ou d'un appel au helpdesk. Recoupez les attributions permanentes avec votre revue des accès à privilèges — un compte qui ne devrait pas être admin permanent en premier lieu n'a pas besoin que ce problème lui soit résolu.

Fermer la Lacune 3 — Exiger deux méthodes et supprimer les faibles

Configurez la politique de réinitialisation pour exiger au moins deux portes, et retirez Security questions comme option autonome — Microsoft les retire de toute façon de SSPR d'ici mars 2027, selon sa documentation. Privilégiez l'application Authenticator ou l'enregistrement de passkey plutôt que le SMS/appel vocal.

Ensuite, boucler sur l'enregistrement et la surveillance

Activez la campagne d'enregistrement des méthodes d'authentification pour que les utilisateurs aient des méthodes conformes enregistrées avant même d'avoir besoin de réinitialiser un mot de passe, ce qui referme AUTH_METHODS_NO_REGISTRATION en même temps que les trois autres lacunes. Si votre tenant travaille aussi sur l'application SSPR méthodes enregistrées uniquement de novembre 2026, le même rapport d'enregistrement alimente les deux corrections — ce changement arrête d'accepter le téléphone/e-mail d'annuaire non enregistré comme solution de repli, ce qui ne compte que si la couverture d'enregistrement est effectivement suivie en premier lieu.

Enfin, surveillez les deux activités d'audit les plus importantes — Self-service password reset policy changes et Reset password (by admin) — pour qu'un futur affaiblissement de la portée, du nombre de méthodes, ou des méthodes autorisées, apparaisse immédiatement au lieu de rouvrir silencieusement ces lacunes. Un pic de réinitialisations effectuées par un admin pour la même poignée d'utilisateurs est généralement le premier signe visible que SSPR a cessé de fonctionner pour eux, bien avant que quiconque n'ouvre un ticket à ce sujet.

Comment EtcSec détecte cela

L'audit Entra ID d'EtcSec vérifie SSPR_NOT_ENABLED (SSPR limité à None), SSPR_NOT_REQUIRED_ADMINS (administrateurs non couverts par une politique de réinitialisation conforme), et SSPR_METHODS_WEAK (questions de sécurité ou téléphone mobile seul satisfaisant la politique), aux côtés de AUTH_METHODS_SMS_ENABLED et AUTH_METHODS_NO_REGISTRATION pour la posture environnante des méthodes d'authentification. Ensemble, ces cinq contrôles donnent une vue unique de savoir si le parcours de récupération de compte est réellement aussi solide que le parcours de connexion qu'il est censé appuyer — car un tenant qui a durci chaque connexion avec Conditional Access et MFA, mais laissé la récupération de mot de passe sur une configuration SSPR par défaut, vient tout simplement de construire une porte d'entrée solide à côté d'une entrée latérale déverrouillée.