Protégez-vous des AiTM !

D’abord, un grand merci à Merill Fernando pour ses newsletters toujours intéressantes sur Entra, dont voici le lien. Beaucoup d’articles écrits sur ce blog proviennent de différentes sources en anglais, et dont les travaux et réflexions méritent des tests et une retranscription en français. J’ai toujours du plaisir à essayer de comprendre certains types d’attaque visant le Cloud. Je voulais donc partager avec vous un exemple basé sur du phishing et dont la mise en place est d’une grande simplicité

Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.

Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.

Un précédent article décrivant un autre scénario d’attaque, via le Device Code Flow, est disponible juste ici. Plusieurs sources m’ont aidé à écrire ce nouvel article :

zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.

Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.

AiTM, kesako ?

Une attaque AITM exploite un proxy intermédiaire pour intercepter les informations d’authentification pendant qu’un utilisateur se connecte à un service légitime, ce qui permet à l’attaquant de détourner la session et de contourner certaines sécurités mises en place par l’authentification multi-facteurs :

Il s’agit d’une nouvelle technique de phishing encore plus efficace. Cette méthode utilise des sites Web usurpés qui déploient un serveur proxy entre un utilisateur cible et le site Web que l’utilisateur souhaite visiter.

Tehtris

Comment fonctionne-t-elle ?

Contrairement au phishing classique, elles ne se contentent pas de tromper l’utilisateur pour lui soutirer ses identifiants. Voici en quoi elles consistent :

Interception en temps réel : L’attaquant crée une page de connexion factice qui sert d’intermédiaire (un proxy) entre la victime et le véritable site légitime. Ainsi, l’utilisateur se connecte en pensant accéder au service habituel, tandis que l’attaquant intercepte les identifiants, cookies et autres données sensibles en temps réel.
Bypass des mesures de sécurité : Puisque l’authentification se fait sur la vraie page (via le proxy), même si l’utilisateur passe une authentification multifacteur (MFA), les tokens et sessions générés peuvent être capturés par l’attaquant, qui peut ensuite les réutiliser pour prendre le contrôle du compte.
Utilisation d’outils serverless : Des plateformes comme Cloudflare Workers ou Azure Functions permettent de déployer rapidement ce type d’attaque sans gérer d’infrastructures traditionnelles, rendant ainsi l’attaque plus facile à mettre en œuvre et plus discrète.

L’attaquant peut voler et intercepter le mot de passe de la victime, détourner les sessions de connexion et le cookie de session (un cookie permet d’authentifier un utilisateur chaque fois qu’il visite un site) et ignorer le processus d’authentification, car le phishing AiTM n’est pas lié à une vulnérabilité dans l’authentification.

Tehtris

Peut-on s’en protéger ?

Oui, il est possible de réduire le risque contre les attaques AITM en mettant en œuvre une combinaison de mesures préventives et de détection. Voici quelques axes de défense :

Authentification renforcée :
- MFA résistant au phishing : Adopter des méthodes d’authentification fortes et moins vulnérables au phishing (comme FIDO2, Windows Hello ou l’utilisation de certificats) permet de réduire les risques, car ces solutions reposent sur des mécanismes difficiles à intercepter via un proxy.
- Politiques d’accès conditionnel : Restreindre l’accès aux services sensibles uniquement depuis des dispositifs conformes (registered devices) ou depuis des réseaux de confiance peut empêcher l’exploitation des sessions capturées.
Surveillance et détection :
- Analyse comportementale : Mettre en place des outils de détection qui surveillent les anomalies dans les logs de connexion (par exemple, des connexions depuis des adresses IP inhabituelles ou issues des plages d’IP cloud reconnues) permet d’identifier rapidement une activité suspecte.
- Canary tokens et autres mécanismes de vigilance : Bien qu’ils puissent parfois être contournés, ces outils permettent de détecter des modifications inattendues sur la page de connexion ou d’autres indices d’une attaque.
Sensibilisation des utilisateurs :
- Former les utilisateurs à reconnaître les signes d’une tentative de phishing (URL étranges, absence de certificats de sécurité attendus, etc.) est une barrière importante contre ces attaques.
- Encourager la vérification de l’authenticité des sites et des notifications de sécurité peut réduire le risque de compromission.
Gestion des sessions et réponses rapides :
- En cas de compromission, disposer de procédures de réinitialisation rapides (révocation des sessions, changements de mots de passe, etc.) permet de limiter les dommages.
- L’implémentation de solutions de sécurité capables d’alerter en temps réel sur des activités anormales (via par exemple Microsoft Entra ID Protection ou d’autres outils SIEM) renforce la réaction face à une attaque.

Dans cet article, je vous propose donc de tester 3 déploiements d’une application frauduleuse :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de mettre en place notre application frauduleuse de démonstration, nous allons avoir besoin de :

Une licence Microsoft Teams
Une souscription Azure valide pour le déploiement sur Azure (Etape IV)

Commençons par configurer Teams afin que nous puissions recevoir les notifications et les messages lorsque notre utilisateur de test s’est authentifié au travers de notre application frauduleuse.

Etape I – Configuration Teams :

Ouvrez votre console client de Teams afin de créer un nouveau canal dans l’équipe de votre choix :

Une fois le canal Teams créé, cliquez sur le bouton ci-dessous pour ajouter un connecteur externe :

Cliquez-ici pour ajouter le connecteur Webhook entrant en utilisant la barre de recherche :

Cliquez sur Ajouter :

Une fois le connecteur ajouté, cliquez sur Créer :

Copiez l’URI du connecteur Webhook dans un éditeur de texte :

Commençons par tester la méthode de déploiement proposée par zolder.io via Cloudflare.

Etape II – Méthode Cloudflare :

Cloudflare propose justement un plan gratuit qui permet d’utiliser les Cloudflare Workers, une plateforme serverless pour exécuter du code JavaScript.

Pour cela, connectez-vous sur la page suivante, puis créez un compte Cloudflare :

Si nécessaire, vérifiez votre compte Cloudflare grâce à l’e-mail reçu sur l’adresse renseignée :

Une fois sur votre tableau de bord Cloudflare, rendez-vous dans le menu suivant afin de créer un Worker :

Conservez ses propriétés de base, puis cliquez sur Déployer :

Une fois le Worker déployé, modifiez le code par le bouton ci-dessous :

Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez sur le fichier suivant :

Copiez le code du fichier worker.js :

Collez ce dernier dans un éditeur de texte :

Collez l’URI du connecteur Webhook Teams sur la ligne suivante :

Collez l’ensemble pour remplacer le code déjà présent sur votre worker Cloudflare, puis cliquez sur Déployer :

Attendez quelques secondes la mention de la sauvegarde en bas de page :

Cliquez sur ce lien afin d’ouvrir un nouvel onglet sur votre application frauduleuse :

Attendez quelques minutes et/ou rafraîchissez la page web plusieurs fois au besoin afin d’obtenir le résultat suivant :

Renseignez le nom de compte de votre utilisateur de test, puis cliquez sur Suivant :

Renseignez le mot de passe de votre utilisateur de test, puis cliquez sur Suivant :

Cliquez sur Oui :

Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :

Retournez sur le canal Teams créé précédemment afin de constater l’apparition d’un premier message provenant du connecteur Webhook, et contenant le login et mot de passe de l’utilisateur de test :

Un second message Teams apparaît également dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Demandez à n’importe quelle IA générative de parser ce texte en JSON avec le prompt suivant :

Convertis cette chaîne de cookies en un snippet JavaScript qui utilise JSON.parse pour créer un tableau d’objets cookies, puis qui les applique avec document.cookie en leur assignant une date d’expiration fixe, comme dans cet exemple :

JSON.parse('[{"name":"ESTSAUTHPERSISTENT","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"ESTSAUTH","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"SignInStateCookie","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true}]').forEach(c => document.cookie = c.name + "=" + c.value + "; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/");

Copiez / collez le résultat obtenu par l’IA dans un éditeur de texte :

Ouvrez Google Chrome en navigation privée :

Rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Moins d’une heure après la publication de notre application frauduleuse chez Cloudflare, un nouvel e-mail nous informe de la détection de notre application et la fermeture de celle-ci :

La console Cloudflare de notre application frauduleuse devient alors inexploitable :

Enfin, il en est de même côté client pour l’URL générée pour notre application frauduleuse :

Continuons les tests en effectuant un déploiement en local de l’application frauduleuse.

Etape III – Méthode locale :

Rendez-vous sur la page suivante pour télécharger Node.js :

Lancez l’installation de Node.js, puis cliquez sur Suivant :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois Node.js correctement installé, cliquez sur Terminer :

Rendez-vous sur la page suivante pour télécharger les outils d’exécution locale d’Azure Functions :

Lancez l’installation, puis cliquez sur Suivant :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois les outils Azure Functions correctement installés, cliquez sur Terminer :

Rendez-vous sur la page suivante pour télécharger Visual Studio Code :

Cochez la case pour accepter les termes, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Une fois Visual Studio Code correctement installé, cliquez sur Terminer :

Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez-ici pour télécharger l’archive au format ZIP :

Décompressez l’archive ZIP dans un dossier local de votre choix :

Ouvrez Visual Studio Code, puis cliquez sur le bouton ci-dessous :

Choisissez le dossier précédemment créé en local :

Confirmez votre confiance en ce dernier :

Ouvrez par le menu suivant la console Terminal intégrée à Visual Studio Code :

Saisissez la commande suivante afin d’ajouter le webhook de votre canal Teams :

func settings add TEAMS_WEBHOOK_URI "https://"

Constatez l’apparition de votre configuration webhook Teams dans le fichier suivant :

Lancez la commande suivante pour installer le package @azure/functions dans votre projet Node.js et l’ajouter comme dépendance dans le fichier package.json.

npm install @azure/functions --save

Lancez la commande suivante pour démarrer l’application frauduleuse en local tout en affichant des informations détaillées de log pour le diagnostic.

func start --verbose

Choisissez node :

Attendez quelques secondes afin de constater le bon démarrages des 4 fonctions de l’application frauduleuse :

Copiez l’URL suivante :

Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :

Cliquez sur Oui :

Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :

Retournez sur le canal Teams créé précédemment afin de constater l’apparition :

d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Terminons nos tests par un déploiement de notre application frauduleuse sur Azure.

Etape IV – Méthode Azure :

Ouvrez un onglet vers ce répertoire GitHub, puis cliquez-ici pour déployer votre application frauduleuse sur Azure :

Renseignez tous les champs ci-dessous dont également l’URI de votre webhook Teams, puis lancez la validation Azure:

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

Attendez environ 10 minutes la fin de la création des ressources Azure, puis cliquez-ici :

Cliquez sur la fonction Azure créée lors du déploiement :

Copiez l’URL de votre application frauduleuse, puis vérifiez la bonne activation des différentes fonctionnalités :

Ajoutez au besoin un domaine personnalisé afin de rendre l’URL de votre site moins suspicieux :

Retournez sur le canal Teams précédemment créé afin de constater l’apparition :

d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :

Testons maintenant si l’ajout d’une MFA renforce la protection de notre compte de test.

Etape V – Ajout de Microsoft Authenticator :

Configurez une méthode MFA de type Microsoft Authenticator sur votre utilisateur de test :

Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA à votre utilisateur de test :

Réussissez le challenge MFA demandé par Microsoft via la notification reçue sur votre compte Microsoft Authenticator :

Retournez sur le canal Teams précédemment créé afin de constater l’apparition :

d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :

Copiez ce texte de cookies en entier :

Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :

Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :

Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :

Collez le texte de cookies précédemment copié :

Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :

allow pasting

Collez à nouveau le texte de cookies précédemment copié, appuyez sur la touche Entrée, puis fermer la fenêtre du mode Console :

Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :

Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application, sans souci particulier concernant l’instauration de la MFA :

Etape VI – Restriction des adresses IPs :

Configurez une police d’accès conditionnel avec une restriction sur votre adresse IP publique sur votre utilisateur de test afin d’empêcher toute autre lieu de s’y connecter :

L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès malgré sa bonne localisation :

Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :

Etape VII – Ajout d’une méthode MFA résistante au phishing :

Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA résistante au phishing à votre utilisateur de test :

L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :

Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :

Etape VIII – Restriction des postes locaux :

Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une machine locale jointe à Entra ID pour votre utilisateur de test :

Malgré que la machine soit jointe à Entra ID et conforme, l’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :

Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :

Conclusion

Qu’il s’agisse d’un déploiement via Cloudflare, d’un environnement local ou d’un déploiement sur Azure, cela illustre la facilité avec laquelle ces attaques peuvent être exécutées.

Pourtant, elles soulignent également l’importance cruciale d’une authentification renforcée (avec des solutions telles que FIDO2 ou autres) et de politiques d’accès conditionnel strictes.

La surveillance continue, la gestion proactive des sessions et la sensibilisation des utilisateurs complètent ce dispositif de défense pour mieux protéger les environnements Cloud. Ces mesures, lorsqu’elles sont correctement implémentées, offrent une barrière robuste contre l’exploitation des failles de sécurité et renforcent significativement la protection des systèmes face aux menaces modernes.

Pour information, environ 12 heures après mon déploiement, la fonction Azure était toujours opérationnelle mais l’URL personnalisée avait bien été détectée et bloquée :

Windows 11 avec Web Sign-in

Le Web Sign-in de Windows 11 est une fonctionnalité innovante qui permet aux utilisateurs de se connecter à leur appareil Windows en utilisant autre chose que le mot de passe pour s’identifier. Introduite avec la version 22H2, cette méthode de connexion dite Passwordless utilise l’application Microsoft Authenticator. Elle est particulièrement utile dans les environnements nécessitant des connexions rapides et sécurisées, tout en éliminant le besoin de mémoriser un mot de passe complexe.

Cet article est la suite de l’article écrit précédemment et consacré à la mise en place du Passwordless sur les comptes Microsoft 365. Voici un lien direct de ce dernier.

Plusieurs méthodes d’authentification et pour quoi faire ?

Il est en effet possible d’avoir des méthodes utilisées en tant que méthode principale, tandis que d’autres ne seront acceptées que dans le cadre de la MFA, comme le rappelle très justement Microsoft :

Certaines méthodes d’authentification peuvent être utilisées en tant que facteur principal lorsque vous vous connectez à une application ou un appareil, par exemple à l’aide d’une clé de sécurité FIDO2 ou d’un mot de passe. D’autres méthodes d’authentification sont disponibles uniquement comme facteur secondaire lorsque vous utilisez une authentification multifacteur Microsoft Entra ou une SSPR.

Microsoft Learn

Voici un tableau détaillant les différentes méthodes acceptées avec leur périmètre

Méthode	Authentification principale	Authentification secondaire
Windows Hello Entreprise	Oui	MFA
Notification Push Microsoft Authenticator	Non	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Microsoft Authenticator sans mot de passe	Oui	Non
Clé d’accès dans Microsoft Authenticator (préversion)	Oui	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Authenticator Lite	Non	MFA
Clef d’accès (FIDO2)	Oui	MFA
Authentification par certificat	Oui	MFA
Jetons matériels OATH (version préliminaire)	Non	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Jetons logiciels OATH	Non	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Méthodes d’authentification externes (préversion)	Non	MFA
Passe d’accès temporaire (TAP)	Oui	MFA
SMS	Oui	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Appel vocal	Non	Authentification multi-facteur et réinitialisation de mot de passe en libre-service
Mot de passe	Oui	Non

Quel est le rapport entre Web sign-in et Passwordless ?

Web Sign-in est donc une méthode principale de type Passwordless. Plusieurs articles sur ce blog parlent déjà d’autres méthodes Passwordless comme :

Voici d’ailleurs d’autres liens en anglais très intéressants :

Dois-je avoir une connexion internet active pour m’authentifier via Web Sign-in ?

La réponse est oui : Il faut disposer d’une connectivité internet active car l’authentification web Sign-in se fera obligatoirement par cette dernière.

A partir de quelle version Windows 11 Web Sign-in est compatible ?

Windows Pro	Windows Entreprise	Windows Pro Education/SE	Windows Éducation
Oui	Oui	Oui	Oui

À compter de Windows 11, version 22H2 avec KB5030310, vous pouvez activer une expérience de connexion web sur Microsoft Entra appareils joints. Cette fonctionnalité est appelée Connexion web et déverrouille de nouvelles options et fonctionnalités de connexion.

Microsoft Learn

Dans cet article, je vous propose de mettre en place et de tester l’authentification Web Sign-in sur un poste Windows 11 via le Passwordless de l’application Microsoft Authenticator :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice consacré au web Sign-in Windows, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator

Souhaitant faire un test sur une version propre d’un poste sous Windows 11, j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure. Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Mais avant cela, quelques configurations sont nécessaires au niveau du tenant.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin d’activer l’inscription automatique Windows, puis vérifiez le paramètre suivant :

Toujours sur le portail Entra ID, cliquez ici afin d’activer la méthode d’authentification principale via Microsoft Authenticator :

Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator (article explicatif) :

Notre tenant dispose de la configuration nécessaire pour profiter du web Sign-in via le Passwordless. Nous allons pouvoir continuer la configuration de Windows 11 via une VM créée sous Azure.

Etape II – Préparation de la machine virtuelle Hyper-V :

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

Cliquez-ici pour créer votre machine virtuelle 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 :

Cliquez sur Suivant :

Rajoutez un second disque pour stocker la VM Windows 11, puis cliquez 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 :

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM Hyper-V :

Une fois connecté sur votre machine virtuelle Hyper-V, ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux 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 immédiat de votre VM Hyper-V :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour vous reconnecter à celle-ci, toujours via le service 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 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, couplé au 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

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 Terminer :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape III – Préparation de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle, puis d’y installer l’OS.

Pour ma part, je suis passé par mon abonnement Visual Studio :

Stockez le fichier ISO sur le disque F de votre VM Hyper-V :

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 :

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

Pensez à bien choisir Génération 2 :

Modifier 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 créée, modifiez sa configuration comme ceci :

Dans la section Sécurité, cochez la case suivante pour activer la puce 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 :

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 à installer Windows 11. Suivez toutes les étapes de l’installation.

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

Lancez l’installation de Windows 11 :

Attendez que le démarrage de l’installation se lance, puis 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 :

Attendez quelques minutes que le redémarrage se poursuivre :

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 OS sont disponibles :

Nommez votre machine virtuelle Windows 11 selon vos souhaits, puis cliquez sur Suivant :

Attendez quelques minutes la fin de la configuration :

Adaptez la configuration des paramètres de confidentialité, puis cliquez sur Accepter :

Attendez quelques minutes la seconde vérification des mises à jour OS :

Attendez enfin la finalisation de la configuration de Windows 11 :

Finaliser la sécurisation de votre poste en configurant Windows Hello en cliquant sur OK :

Définissez le code PIN de votre choix, puis cliquez sur OK :

Cliquez à nouveau sur OK :

Vous voilà enfin sur le bureau Windows de votre machine virtuelle Windows 11 :

L’environnement Windows 11 pour notre test est maintenant opérationnel. Afin de déployer la configuration Web Sign-in, nous allons la pousser via la console de gestion Intune.

Etape IV – Configuration Intune – Web Sign-in :

Rendez-vous à nouveau sur le portail Entra ID afin de vérifier que la machine virtuelle Windows 11 jointe grâce à notre utilisateur de test y figure bien :

Rendez-vous également sur le portail Intune afin de vérifier que la machine virtuelle Windows 11 y figure également :

Cliquez-ici pour créer une nouvelle police de configuration Windows :

Choisissez la configuration de profil suivante, puis cliquer sur Créer :

Nommez votre profil de configuration, puis cliquez sur Suivant :

Cliquez ici pour ajouter un ou des paramètres à votre profil :

Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :

Activez le paramètre repris, puis cliquez sur Suivant :

Cliquez sur Suivant :

Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :

Vérifiez la configuration de votre profil, puis lancez sa création :

La nouvelle police de configuration apparaît alors dans la liste :

Continuer la configuration Intune via la création d’une seconde police de configuration si vous souhaitez désactiver l’ouverture de session Windows via le mot de passe.

Etape V – Configuration Intune – Passwordless :

Cliquez-ici pour créer une seconde police de configuration Windows :

Choisissez la même configuration de profil, puis cliquer sur Créer :

Nommez votre second profil de configuration, puis cliquez sur Suivant :

Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :

Activez le paramètre ci-dessous, puis cliquez sur Suivant :

Cliquez sur Suivant :

Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :

Vérifiez la configuration de votre second profil, puis lancez sa création :

La seconde police de configuration apparaît alors dans la liste :

Cliquez ici pour voir le détail de son déploiement sur votre poste de test, attendez plusieurs minutes, puis rafraîchissez cette page plusieurs fois au besoin :

Afin d’accélérer le processus, vous pouvez déclencher une synchronisation Intune via le menu suivant sous Windows 11 :

Cliquez sur le bouton suivant, puis attendez environ 5 minutes :

Une fois la configuration correctement déployée, il ne nous reste qu’à tester l’ouverture de session Windows de notre utilisateur.

Alternative :

En alternative à Intune, il aurait été possible travailler sur le registre Windows pour agir directement sur la configuration Passwordless et Web Sign-in :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Authentication

Etape VI – Test d’authentification utilisateur :

Pour cela, fermez la session Windows 11 actuellement ouverte :

De retour sur la mire d’authentification, cliquez sur le bouton suivant afin de constater la différentes méthodes d’authentification autorisées :

Cliquez selon votre cas sur le bouton Sign in ou Web Sign in :

Constatez l’apparition d’une fenêtre d’authentification Entra ID vous proposant d’envoyer une notification sur votre Smartphone configuré comme Passwordless :

Sur votre smartphone, saisissez le nombre précédemment affiché :

Juste après, constatez la bonne ouverture de la session Windows 11 :

Enfin, ouvrez les propriétés Windows de votre compte de test afin d’y constater l’absence de méthode consacrée au mot de passe :

Conclusion

La fonctionnalité Web Sign-in de Windows 11 marque une avancée notable dans la sécurisation et la simplification des méthodes de connexion.

En éliminant l’usage des mots de passe traditionnels, elle permet aux utilisateurs de s’authentifier via un navigateur web en utilisant l’application Microsoft Authenticator.

Disponible à partir de la version 22H2 de Windows 11, cette solution s’inscrit dans la continuité de la stratégie Passwordless Cloud de Microsoft.

Enfin, Windows 11 web Sign-in est également compatible avec Temporary Access Pass 😎

Soyez Passwordless grâce à Microsoft Authenticator

Très souvent, la sécurité d’un périmètre ou d’un environnement focalise une attention particulière aux processus d’authentification ainsi qu’aux moyens mis à disposition aux utilisateurs pour y parvenir. Quelles méthodes, quelles conditions, quels protocoles mettre en place ? La MFA est un principe de base maintenant acquis pour tous et set présent dans une majorité de systèmes, mais le mot de passe reste alors encore de la partie.

Qu’est-ce que le Passwordless ?

Le concept de Passwordless (sans mot de passe) désigne une méthode d’authentification qui permet aux utilisateurs de se connecter à des systèmes ou des services sans avoir à utiliser un mot de passe traditionnel.

Autrement dit, le concept de Passwordless regroupe plusieurs méthodes d’authentification différentes, comme :

Passkey via Microsoft Authenticator
Push via Microsoft Authenticator
FIDO2
Windows Hello
SmartCard

Pourquoi vouloir se débarrasser du mot de passe ?

L’objectif principal du Passwordless est de réduire les risques de compromission liés aux mots de passe traditionnels, comme les attaques par hameçonnage (phishing), les vols de mot de passe, ou encore les mauvaises pratiques liées à la gestion des mots de passe (mots de passe faibles ou réutilisés).

Passwordless vs MFA ?

Passwordless et MFA (Multi-Factor Authentication) sont 2 méthodes d’authentification sécurisée, mais elles diffèrent dans leur approche et leur mise en œuvre.

Des fonctionnalités telles que l’authentification multifacteur (MFA) sont un excellent moyen de sécuriser votre organisation, mais les utilisateurs sont souvent frustrés par la couche de sécurité supplémentaire en plus de devoir mémoriser leurs mots de passe.

Les méthodes d’authentification sans mot de passe sont plus pratiques, car le mot de passe est supprimé et remplacé par quelque chose que vous avez ou quelque chose que vous êtes ou connaissez.

Microsoft Learn

Voici une comparaison entre ces 2 concepts :

Caractéristique	Passwordless	MFA (Multi-Factor Authentication)
Utilisation des mots de passe	Aucune utilisation de mot de passe	Utilise souvent un mot de passe + autre facteur
Sécurité	Très sécurisé (aucun mot de passe à compromettre)	Très sécurisé (nécessite plusieurs facteurs)
Expérience utilisateur	Fluide et simplifiée	Peut être plus complexe (plusieurs étapes)
Technologie utilisée	Biométrie, clés de sécurité, lien magique, etc.	Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisation	Connexion par empreinte digitale, lien magique	Connexion par mot de passe + code SMS ou app Authenticator

Dans cet article, je vous propose de mettre en place et de tester l’authentification Passwordless via l’application Microsoft Authenticator sur smartphone pour une identité 365 :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la méthode Passwordless de Microsoft, il vous faudra disposer de :

Un tenant Microsoft
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator

Important : à l’issue de cette démonstration, gardez en tête que votre smartphone sera enregistré (mais non managé) dans chaque tenant Microsoft où il sera utilisé pour se connecter en Passwordless.

Commençons par activer le service Passwordless sur le tenant 365.

Etape I – Configuration du tenant :

Pour cela, rendez-vous dans la section suivante de votre portail Entra, puis cliquez sur Microsoft Authenticator :

Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator :

Définissez le périmètre des utilisateurs concernés en laissant le mode d’authentification à Any ou Passwordless :

Basculez sur le second onglet afin d’activer ou non Microsoft Authenticator OTP :

L’option suivante exigeant de retaper le numéro affiché n’est pas modifiable :

Choisissez au besoin ou non d’afficher l’application demandant l’authentification Passwordless :

Choisissez au besoin ou non d’afficher la localisation du demandeur de l’authentification Passwordless :

Choisissez au besoin ou non d’afficher Microsoft Authenticator sur les applications de type Compagnon :

Enfin, cliquez sur Sauvegarder :

Afin de comprendre le fonctionnement du processus depuis l’enrôlement de départ de Microsoft Authenticator, il est préférable de créer un utilisateur de test.

Etape II – Configuration du l’utilisateur :

Toujours sur votre portail Entra, cliquez ici pour créer un nouvel utilisateur sur votre tenant Microsoft :

Renseignez-lui un UPN, un nom d’affichage, ainsi qu’un mot de passe temporaire, puis lancez la validation Entra :

Une fois la validation Entra réussie, lancez la création de votre utilisateur des test :

Une fois l’utilisateur créé, ouvrez le navigateur internet de votre choix en mode privé :

Rendez-vous sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test ainsi que son mot de passe provisoire :

Définissez un nouveau mot de passe :

Cliquez sur Oui :

Notre environnement 365 et notre utilisateur sont maintenant créé.

Passons maintenant à l’étape suivante qui consiste à associer Microsoft Authenticator à notre compte de test.

Etape III – Configuration MFA :

En haut à droite, cliquez ici pour afficher les propriétés de votre compte 365 :

Dans l’onglet dédié aux informations de sécurité, ajoutez une nouvelle méthode d’authentification :

Choisissez la méthode suivante pour configurer Microsoft Authenticator :

Installez au besoin l’application Microsoft Authenticator depuis un store d’applications, puis cliquez sur Suivant :

Cliquez sur Suivant :

Choisissez le type Compte professionnel ou scolaire :

Cliquez ici pour utiliser l’appareil photo afin de scanner le QR code :

Scanner le QR code présenté par Microsoft :

Une fois scanné, cliquez sur Suivant :

Une notification est alors envoyée à votre smartphone :

Saisissez le nombre précédemment affiché, puis cliquez sur Oui :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

La méthode Microsoft Authenticator est maintenant correctement configurée sur votre compte de test, cliquez alors sur Suivant :

La méthode Microsoft Authenticator apparaît alors sur votre compte en tant que méthode dite MFA :

L’utilisateur de test est maintenant correctement configuré avec un mot de passe traditionnel et une méthode de sécurité de type MFA.

Etape IV – Configuration Passwordless :

Afin d’activer la méthode Passwordless, nous allons transformer le compte de test enregistré sur l’application Microsoft Authenticator.

Pour cela, ouvrez l’application Microsoft Authenticator, sélectionnez votre compte de test, puis cliquez ici pour activer la fonctionnalité Passwordless :

Microsoft vous informe que l’appareil sera inscrit dans le tenant ID correspondant, cliquez sur Continuer

Sur l’application Microsoft Authenticator, renseignez le mot de passe de votre compte de test :

Un nombre apparaît alors sur la fenêtre, ainsi qu’une notification Microsoft Authenticator, vous demandant de ressaisir ce dernier :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

Cliquez ici pour confirmer l’enregistrement de votre smartphone sur le tenant ID concerné :

Microsoft Authenticator vous confirme le succès des opérations et de l’activation de la fonctionnalité Passwordless, cliquez alors sur Terminer :

Retournez sur le portail Entra afin de constater l’apparition de votre smartphone en tant que périphérique enregistré :

De retour sur les éléments de sécurité de votre utilisateur de test, la méthode Microsoft Authenticator s’est transformée de MFA à Passwordless :

Tout notre environnement de test est maintenant configuré. Il ne nous reste qu’à tester que la méthode Passwordless fonctionne correctement à la place du mot de passe.

Etape V – Test du Passwordless :

Rouvrez à nouveau un navigateur internet en mode privée :

Rendez-vous à nouveau sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test, puis, au lieu de renseigner son mot de passe, cliquez sur le choix suivant :

Microsoft envoie alors une notification sur le smartphone configuré comme Passwordless :

Ouvrez la notification Microsoft Authenticator, puis ressaisissez le nombre précédemment indiqué par Microsoft :

De retour sur votre navigateur, confirmez votre souhait de rester authentifié en cliquant sur Oui :

La page d’accueil d’Office 365 s’ouvre bien, l’utilisateur s’est correctement authentifié sans mot de passe :

Côté traçabilité, il est possible de retrouver des logs des authentifications Passwordless dans plusieurs écrans de Microsoft :

Côté utilisateur, via sa gestion de compte :

Côté Administrateur, via la vue des logs d’un utilisateur sur Entra ID :

Ou via une requête KQL après l’activation Log Analytics sur Entra ID :

SigninLogs
| where AuthenticationDetails has "passwordless"
| project TimeGenerated, UserPrincipalName, AuthenticationDetails , ResultDescription
| order by TimeGenerated desc

Conclusion

En conclusion, l’adoption du Passwordless avec Microsoft Authenticator constitue une avancée significative dans la sécurisation des environnements numériques tout en améliorant l’expérience utilisateur.

En éliminant la nécessité de mémoriser et de gérer des mots de passe, cette méthode réduit les risques liés aux compromissions, telles que les attaques de phishing ou le vol de mots de passe.

De plus, elle simplifie les processus d’authentification, rendant l’accès aux services plus fluide. Pour les entreprises, c’est une opportunité d’offrir un meilleur équilibre entre sécurité et facilité d’utilisation, tout en renforçant la confiance des utilisateurs dans la protection de leurs données.

Bref, aucune méthode n’est jamais parfaite 😎 :

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 :

Un tenant Microsoft active
Visual Studio Code
.NET 6.0
ngrok
Un smartphone disposant de la dernière version de Microsoft Authenticator

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és	Prise 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 (HoloLens, Salle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Modes pris en charge	Piloté par l’utilisateur;	Piloté par l’utilisateur; Préprovisionné. Déploiement automatique. Appareils existants.
Types de jointure pris en charge	Rejoindre 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 Windows	Windows 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 requises	Windows 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 :

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.

Identificateurs décentralisés W3C

Justificatifs vérifiables W3C

DIF Sidetree

DIF Well Known DID Configuration

DIF DID-SIOP

DIF Presentation Exchange

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 :