TLDR

En récap :

• si accès à un portail admin -> demande MFA (obligatoire à compter d’octobre 2025)
• si accès à la page de gestion des moyens MFA -> demande MFA
• si MFA est “enforced” pour l’utilisateur -> demande MFA quelle que soit le portail (mais bypass possible en fonction de l’IP)
• si self-service password reset activé -> MFA obligatoire même pour Office

Software TOTP

Les jetons utilisés par MS Authenticator ne sont pas standards ; ils ne peuvent être utilisés que dans l’applis MS Authenticator (qui doit avoir accès aux notifications push pour fonctionner).
Pour utiliser un TOTP standard, il faut utiliser l’option “Je souhaite utiliser une autre application d’authentification”.

Les 2 méthodes génèrent des QRCode, mais ceux de MS encodent une URL de type “phonefactor://” alors que ceux standard encodent une URL de type “otpauth://” .
Il est pertinent de sauvegarder les QRcode standards, car ils contiennent juste un secret (une graine) qui peut être réutilisée à tout moment.
Ceux de MS permettent une communication limitée dans le temps avec les serveurs de MS, donc ça ne sert à rien de les conserver.

Si on scanne un code “phonefactor://” avec une appli standard, certaines renverront juste une erreur, alors que d’autres (comme Aegis) signifieront explicitement ne pas être compatibles avec la méthode propriétaire de MS.

MS Auth permet l’identification soit par notification push, soit par un code type TOTP.
À noter que le code TOTP généré par MS Auth n’est pas le même qu’avec une appli standard !

Si les 2 méthodes sont activées pour un compte donné, on peut alors utiliser soit le code TOTP, soit le code MS Auth lors de la demande MFA.

Paramètres de sécurité par défaut

L’accès conditionnel du MFA nécessite des licences Entra P1/P2.

Si l’organisation n’a pas ces licences, la MFA peut être forcée pour tous les utilisateurs via le mécanisme des “paramètres de sécurité par défaut”. Ceux-ci exigent (entre autres) la MFA pour tous les utilisateurs.
Ils peuvent s’activer et se désactiver dans
Entra admin center -> Entra ID -> Overview -> Properties -> Manage security defaults (tout en bas de la page)

Il est aussi possible de forcer les utilisateurs 1 par 1 via le menu Per-user MFA (voir plus bas).

Paramètrage général

Le menu “Entra ID -> Multifactor authentication” n’est pas toujours disponible ; à voir si cela dépend de la date de création du tenant, ou bien des licences Entra Premium ?
Il semble que ces paramètres sont de toute façon dépréciés par MS, et voués à être remplacés par ce qui suit.

Entra admin center -> Entra ID -> Authentication methods
Contient les paramétrages globaux pour la MFA.

Policies (Stratégies) : permet de choisir quels modes de MFA sont autorisés selon les groupes d’utilisateurs.

• Software OATH token : TOTP standard ; sera proposé sous l’intitulé “MS Authenticator” mais avec l’option “Autre appli”
• MS Authenticator : option “phonefactor://” de MS

Certaines stratégies peuvent être paramétrées en cliquant sur leur nom.

Note sur les codes TOTP (MS Auth / OATH Soft token) :

• si seulement MS Auth activé : absence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Pro ou scolaire”
• si les MS Auth + OATH activés : présence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Pro ou scolaire”
• si seulement OATH activé : présence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Autre”

Settings -> “System-preferred multifactor authentication” :
Ceci force les utilisateurs à être, en premier lieu, exposé à la méthode MFA considéré la + sécurisée par MS. Celle-ci peut changer au fil du temps.
Si cette fonctionnalité est désactivée, les utilisteurs peuvent choisir eux-même la méthode proposée en 1er (voir paragraphe sur la gestion par les utilisateurs finaux).
Ceci n’empêche jamais les utilisateurs d’utiliser une autre méthode ; ça définit juste la première méthode proposée. Ils peuvent toujours en choisir une autre (à condition qu’elle soit autorisée par les stratégies) en déclarant la 1e méthode inaccessible.

“Registration campaign” : ne supporte actuellement (septembre 2025) que MS Authenticator

Obligation MFA pour les centres d’admin

https://aka.ms/mfaforazure
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

Activée de force le 30 septembre 2025 au + tard.
Contrairement à ce qui est indiqué sur la doc MS, le centre d’admin M365 (https://admin.microsoft.com) n’est pas encore concerné (même si ça va surement finir par venir).
Mais activée pour le centre d’admin Entra, d’Intune, et le portail Azure, notamment.

Le paramétrage pour désactiver la MFA en provenance de certaines plages d’IP ne s’appliquent pas à l’accès aux centres d’admin ; la MFA sera demandée en tous les cas.

Se gère ici :
https://entra.microsoft.com/#view/Microsoft_Azure_Resources/MfaSettings.ReactView
Besoin d’être avec “accès élevé” pour modifier les paramètres.

(note : la même page est aussi accessible via les portails Intune et Azure ; c’est bien le même paramétrage accessible de 3 endroits différents)

Les options proposées semblent être un sous-ensemble de celles autorisées dans les “Stratégies”. En activant tout, j’ai le choix entre :

• MS Auth
• TOTP
• Hardware token
• SMS
• Appel

Pour pouvoir accéder aux centres d’admin, il faut qu’une des méthodes ci-dessus soit activée dans les Stratégies, et que l’utilisateur s’enregistre via cette méthode.

Paramètres MFA par utilisateur

Peut se gérer dans Entra ID -> Users -> onglet “Per-user MFA”
(le menu Entra admin center -> Entra ID -> Multifactor authentication -> Additional cloud-based multifactor authentication settings envoie dans le même menu)

Lorsqu’on active la MFA pour un utilisateur, son état passe à “enabled”. Cela signifie qu’il sera contraint d’activer la MFA à sa prochaine connexion.
Une fois la MFA enregistrée par l’utilisateur final, son état passe à “enforced”. À partir de là, elle est nécessaire même pour une simple connexion à Office.

Lorsque l’état est “disabled”, la MFA est ignorée pour les connexions simples à Office. Elle reste nécessaire pour les centres d’admin, ou l’accès à la page utilisateur final de gestion de la MFA.

Entra ID -> Users -> choisir user -> Authentication methods
permet de visualiser les modes d’auth disponibles, indisponibles (activées par l’utilisateur, mais désactivées par les stratégies) et par-défaut pour l’utilisateur sélectionné ; permet d’ajouter certains modes (mail, tél) et d’en supprimer d’autres.

On ne peut pas voir ses propres méthodes d’auth via ce menu ; il faut passer par le lien du paragraphe “Utilisateur final”.

Services settings

Dans l’onglet “Per-user MFA”, il y a un onglet “Service settings”.
C’est ici que l’on peut autoriser la mémorisation d’une réponse MFA pendant plusieurs jours.
On peut aussi y désactiver la MFA pour certaines plages d’IP (fonctionne pour les accès standards à Office, mais pas aux centres d’admin ni à la gestion MFA par l’utilisateur final).

Self-service password recovery

Entra -> Entra ID -> Password reset
Les utilisateurs pour lesquels SSPR est activé ont l’obligation d’activer la MFA, avant de pouvoir se connecter via la connexion web (navigateur, connexion Office etc).

La réinitialisation se fait ici :
https://passwordreset.microsoftonline.com

Il faut valider la MFA par une des méthodes enregistrées et on peut reset son propre mot de passe.

Gestion par l’utilisateur final

https://mysignins.microsoft.com/security-info

L’accès à cette page est lui-même soumis à la MFA.
Les stratégies listées ici sont celles pour lesquelles il y’a une donnée enregistrée. Cela ne signifie pas que ce mode d’auth est accepté par Entra. Il peut avoir été désactivé.

À noter que l’utilisateur peut gérer ses moyens de MFA, mais pas les demandes de MFA elles-mêmes, ni les moyens acceptés et ceux refusés.
Ceci est paramétré par MS et/ou les admins.

App password

Il faut que la MFA soit “enforced” pour l’utilisateur qui veut créer un “app password”.
Ensuite, dans la gestion par l’utilisateur final, il devrait être possible de créer un app password.