En cette fin juin 2024, Microsoft nous partage un peu plus d’informations sur la future MFA obligatoire à venir pour Azure à partir de juillet 2024. Plusieurs grandes étapes sont maintenant mentionnées et intégrées dans un planning qui démarre dès cet été et se terminera début 2025. De plus, Microsoft nous propose également donc quelques outils pour nous y préparer.
Mi-mai, Microsoft annonçait via le Tech Community une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous ! A ce moment-là, j’avais déjà rédigé un premier article, dont voici le lien MFA pour tous les utilisateurs d’Azure à partir de juillet 2024.
Un second post sur le Tech Community est apparu hier sur ce même sujet, et nous donne quelques informations sur les 2 phases de cette obligation liée à Azure :
- Phase 1 – À partir de juillet 2024 : La notification puis l’obligation de la MFA pour le portail Azure sera progressivement étendue à tous les tenants.
- Phase 2 – À partir de début 2025 : La notification puis l’obligation de la MFA aux outils de commande liés à Azure : CLI, Azure PowerShell et les outils Infrastructure as Code (IaaC) sera progressivement étendue à tous les tenants.
Merci à Merill Fernando pour ce schéma :
Partant de ces informations, nous pouvons en déduire les points suivants :
- Portail Azure : Le portail Azure est utilisé par les humains, il faudra alors former les utilisateurs et configurer pour chacun d’entre eux une méthode MFA.
- Autres outils : D’autres outils (CLI, Cloud Shell, …) sont utilisés par les humains et certains applications. Ces dernières pourront elles faire l’objet d’une bascule vers des identités managés ou des comptes de service.
- Impact progressif : Les entreprises utilisant Azure doivent se préparer à une transition progressive des tenants. Elles auront le temps d’ajuster leurs configurations et de résoudre les problèmes potentiels avant que l’implémentation complète ne soit réalisée.
Microsoft a t-il prévu de notifier les administrateurs Azure ?
Microsoft a privilégié la notification des administrateurs globaux 60 jours avant la mise en application des phases 1 et 2. Cela sans doute pour laisser les entreprises organiser les messages et notifications en interne aux personnels Azure impactés par cette mesure.
Le compte à rebours de la mise en application pour votre/vos tenant(s) ne commence pas tant que vous n’avez pas reçu cette première notification de notre part. En outre, nous enverrons des rappels périodiques aux administrateurs globaux à intervalles réguliers entre la première notification et le début de la mise en application pour votre/vos tenant(s).
Tech Community
Pourrons-nous déroger temporairement à cette règle pour un tenant ?
Les mails de notification envoyés par Microsoft devraient comporter un lien pour activer une période de grâce, afin de pouvoir gérer les imprévus :
La première notification de notre part indiquant la date de mise en application pour votre/vos tenant(s) inclura également un lien pour demander la période de grâce. Des détails supplémentaires sur les types de clients, les cas d’utilisation et les scénarios éligibles à la période de grâce seront inclus dans la notification.
Tech Community
MFA pour tout Azure, mais vraiment pour tout le monde ?
Microsoft avait déjà été clair sur ce point, j’en avais également parlé dans mon précédent article :
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement.
Jlou.eu
Malgré cette information, une confusion a déjà pu s’installer, et c’est pour cela que ce second post de Microsoft reprécise que les utilisateurs finaux non gestionnaires d’Azure ne seront pas impactés :
Les utilisateurs finaux qui accèdent à des applications, des sites web ou des services hébergés sur Azure, mais qui ne se connectent pas au portail Azure, à la CLI ou à PowerShell, ne sont pas soumis à cette exigence de Microsoft. Les exigences d’authentification pour les utilisateurs finaux seront toujours contrôlées par les propriétaires de l’application, du site web ou du service.
Tech Community
Quid des accès conditionnels d’Entra ID ou de la sécurité par défaut ?
Microsoft a décidé d’implémenter ce contrôle MFA en amont des mesures de sécurité actuelles :
- Sécurité par défaut activée : aucun changement car la MFA est déjà requise pour accéder aux outils Azure.
- Accès conditionnel Azure : une police d’accès conditionnel plus restrictive et nécessitant une authentification plus forte que cette nouvelle règle sera appliquée en priorité.
Quid des comptes « brise-glace » ?
En mai dernier, Microsoft ne donnait pas encore de méthodes spécifiques pour ces comptes d’urgence. C’est maintenant chose faite :
Nous avons pris connaissance de vos questions concernant les comptes « verre cassé » ou « accès d’urgence ». Nous recommandons de mettre à jour ces comptes pour qu’ils utilisent FIDO2 ou l’authentification basée sur un certificat (lorsqu’elle est configurée en tant qu’AMF) au lieu de s’appuyer uniquement sur un mot de passe long. Ces deux méthodes satisferont aux exigences de l’AMF.
Tech Community
Existe-t-il des outils pour nous y préparer ?
Pour éviter les soucis de connexion le jour J, Microsoft propose un outil de type tableau de bord, et une commande PowerShell d’extraction sous format EXCEL. Ces deux outils donne plus de visibilité sur les utilisateurs Azure concernés et mal préparés. Voici les deux liens directs mis à disposition par Microsoft :
Voici des liens directs sur deux tests réalisés dans cet article :
- Test I – Configuration du Tableau de bord Entra ID
- Test II – Lancement du script PowerShell Entra ID
Test I – Configuration du Tableau de bord Entra ID :
L’utilisation de ce tableau de bord Entra ID exige certains prérequis Microsoft :
- Un tenant Microsoft avec une licence Entra ID Premium P1
- Une souscription Azure valide
- Un Log Analytics workspace créé sur une souscription Azure
Voici le message d’erreur si vous souhaitez accéder aux workbooks d’Entra ID si la configuration n’est pas faite :
Si cela n’est donc pas déjà fait, commencez par créer un Log Analytics workspace via le portail Azure :
Cliquer sur Créer :
Renseignez les informations de votre LAW, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre LAW :
Attendez 2 minutes que le déploiement se termine :
Retournez sur Entra ID afin d’activer ou de modifier le paramétrage de sauvegarde des journaux :
Activez l’option pour sauvegarder vers votre LAW, puis Sauvegardez :
Attendez environ 5 minutes, puis Créez un nouveau workbook :
Cliquez-ici pour ajoutez du code à votre workbook :
Rendez-vous sur la page GitHub suivante afin d’y copier le code présent :
Collez le code précédemment copié, puis cliquez sur Appliquer :
Cliquez sur Enregistrer-sous pour sauvegarder votre workbook :
Renseignez les champs, puis cliquez sur Appliquer :
Attendez quelques secondes que le workbook s’enregistre :
Retournez sur le menu suivant pour vérifiez le bon enregistrement :
Cliquez sur votre workbook afin de connaitre les connexions sans MFA de votre tenant :
Afin d’avoir plus de matière dans mes logs, voici un exemple d’un autre tenant :
Filtrez les résultats avec uniquement comme application le portail Azure :
Identifiez le ou les utilisateurs connectés sans MFA :
Terminons ces tests la seconde méthode proposée par Microsoft : le script PowerShell.
Test II – Lancement du script PowerShell Entra ID :
L’utilisation de ce script PowerShell n’exige qu’un prérequis :
- Windows PowerShell en version 7.0 ou supérieure
Si besoin, installez la dernière version de PowerShell. Commencez par rechercher la version la plus récente de PowerShell :
winget search Microsoft.PowerShell
Installez PowerShell et/ou PowerShell en préversion :
winget install --id Microsoft.Powershell --source winget
winget install --id Microsoft.Powershell.Preview --source winget
Validez si besoin les droits administrateurs :
Attendez que la version soit entièrement installée :
Recherchez la version 7 de PowerShell :
Lancez le script PowerShell de Microsoft :
Install-Module MsIdentityTools -Scope CurrentUser
Import-Module MSIdentityTools
Connect-MgGraph -Scopes Directory.Read.All, AuditLog.Read.All, UserAuthenticationMethod.Read.All
Export-MsIdAzureMfaReport .\report.xlsx
Authentifiez-vous avec un compte disposants des autorisations nécessaires :
Acceptez les permissions demandées :
Une fois l’authentification terminée, fermez la fenêtre du navigateur :
Attendez que l’export Excel se termine :
Ouvrez le fichier Excel généré :
Constatez sur le premier onglet un tableau récapitulatif des utilisateurs qui se sont connectés au portail Azure, à Azure CLI ou à Azure PowerShell au cours des 30 derniers jours en interrogeant les journaux de connexion et de leur méthodes MFA enregistrées :
- ✅ MFA Capable + Signed in with MFA : L’utilisateur a enregistré des méthodes d’authentification MFA et s’est connecté avec succès au moins une fois à Azure en utilisant MFA.
- ✅ MFA Capable : L’utilisateur a enregistré des méthodes d’authentification MFA mais s’est toujours connecté à Azure en utilisant l’authentification à facteur unique.
- ❌ Not MFA Capable : L’utilisateur n‘a pas encore enregistré de méthode d’authentification multifacteur et ne s’est pas connecté à Azure à l’aide de MFA.
Constatez sur le second onglet un graphique et des totaux des utilisateurs prêts ou non :
Conclusion – Comment se préparer avant le jour J ?
Commencez dès à présent à créer une nouvelle règle d’accès conditionnel équivalente à la future implémentation prévue par Microsoft. Il existe un template de police d’accès conditionnel très proche du résultat attendu :
Cette police cible la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement est un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Vous pourrez par la suite changer son statut sur ON :
Bon courage à tous 💪🙏😎
