Étiquette : entra

Veeam Data Cloud pour Entra ID

Pourquoi devrais-je sauvegarder mes données Microsoft Entra ID ? Entra ID est la brique centrale qui pilote l’identité, l’accès et la sécurité de tout l’environnement cloud. Si Entra ID tombe, tout tombe : authentification, applications SaaS, accès aux ressources Azure, Polices d’accès conditionnel, MFA, etc…

Entra ID a son backup natif, n’est-ce pas ?

Non, Microsoft n’offre pas de fonctionnalité de sauvegarde ou de restauration complète d’Entra ID. Voici ce qui existe nativement, et surtout ce qui manque :

Élément Entra IDComportement natifLimite importante
Utilisateurs / Groupes supprimésCorbeille 30 joursObject ID parfois régénéré → casse des dépendances
Rôles / ApplicationsSuppression définitiveAucune corbeille, restauration impossible
Politiques d’accès conditionnelCorbeille 30 jours (préversion)Une erreur bloque l’accès global
Service Principals / App RegistrationsCorbeille 30 joursImpact direct sur les intégrations applicatives
Audit & sign-in logsConservation limitée (7 à 30 jours selon licence)Impossible de rejouer/restaurer

Avec une sauvegarde Entra ID dédiée, il vous serait possible de ?

  • Revenir à un état connu fonctionnel après une mauvaise config
  • Restaurer un objet précis (utilisateur, groupe, application…) sans impacter le reste
  • Comparer deux versions d’un objet et restaurer uniquement un champ
  • Auditer proprement ce qui a changé dans la configuration du tenant
  • Garder une preuve longue durée des logs de sécurité

Qu’est-ce que Veeam Data Cloud ?

Pour vous aider, j’en ai déjà parlé au travers de plusieurs articles :

Veeam Data Cloud est la plateforme SaaS de Veeam, hébergée dans Azure, qui permet de sauvegarder et restaurer les données Microsoft 365 et Microsoft Entra ID sans avoir à déployer d’infrastructure.

Tout est géré par Veeam ?

  • Pas de serveur VBR à installer, pas de SQL, pas de stockage à provisionner
  • Sauvegarde hébergée dans Azure, dans la région que tu choisis à l’activation
  • Rétention longue durée incluse, stockage illimité (modèle “as-a-service”)
  • Interface Web = tout se fait en ligne, y compris la restauration granulaire

En résumé : c’est le Veeam que tu connais, mais entièrement hébergé, pensé pour les environnements cloud first ou sans infrastructure on-prem, et surtout pour apporter une vraie sauvegarde de l’identité Entra ID, ce que Microsoft ne propose pas nativement.

Qu’est-ce que Veeam Data Cloud pour Microsoft Entra ID ?

Veeam Data Cloud pour Microsoft Entra ID est un service 100% SaaS, hébergé dans Microsoft Azure, qui permet de sauvegarder, restaurer et versionner les objets critiques d’un tenant Entra ID sans déployer de serveur Veeam ni gérer de stockage.

Il protège notamment :

  • Utilisateurs et groupes
  • Applications et principaux de service
  • Rôles, unités d’administration
  • Politiques d’accès conditionnel
  • Journaux d’audit et connexions

Tout se pilote depuis une interface web Veeam, avec :

  • Possibilité de rollback ciblé après une mauvaise configuration
  • Sauvegarde automatique et récurrente
  • Stockage inclus et géré par Veeam dans Azure
  • Restauration granulaire (objet complet ou propriété unique)

Combien coûte Veeam Data Cloud pour Microsoft Entra ID ?

D’après le site officiel de Veeam, on retrouve les prix suivants :

  • Offre Standalone Entra ID : 1 USD par utilisateur Entra ID / mois (facturé annuellement)
  • Bundle Flex (M365 + Entra ID) : l’ajout d’Entra ID revient à
    0,70 USD par utilisateur M365 et par mois     (soit ~30 % de réduction)
  • Bundle Premium (M365 + Entra ID + fonctionnalités avancées) : ~ 5 USD / utilisateur / mois (tarif promotionnel, coût standard jusqu’à 7 USD pour certains plans)

Cependant, il faut faire attention à :

  • Ces prix sont des MSRP (prix de référence) et peuvent varier selon le pays.
  • Pour les organisations de grande taille, des remises par volume peuvent s’appliquer.
  • Le stockage est inclus dans le service : tu ne paies pas séparément le stockage dans Azure.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cette démonstration de sauvegarde d’Entra ID via la solution Veeam Data Cloud pour Entra ID, j’ai eu besoin de :

  • Un tenant Microsoft
  • Une souscription Veeam Data Cloud for Entra ID

Commençons par configurer Veeam Data Cloud depuis l’ajout de la licence du produit.

Etape I – Configuration de Veeam Data Cloud for Entra ID :

Je me connecte à la console Veeam Data Cloud afin de vérifier la souscription disponible et le nombre d’utilisateurs éligibles à la sauvegarde :

Je clique sur les trois points, puis sur Manage pour accéder au menu de gestion :

Depuis la console VDC, je clique sur Entra ID parmi les produits proposés :

Je clique sur le bouton permettant d’ajouter mon tenant Entra ID :

Je clique sur Autoriser pour lancer la délégation d’accès au tenant :

Je m’authentifie avec un compte disposant du rôle Administrateur Général :

J’accepte les permissions demandées par l’application Veeam Data Cloud pour Entra ID :

Dans le portail Entra ID, je constate les permissions accordées ainsi que le consentement administrateur sur l’application Veeam Data Cloud pour Entra ID :

Je retourne dans la console Veeam et je confirme que l’autorisation a bien été prise en compte avant de cliquer sur Suivant :

Je choisis la région Azure parmi celles disponibles dans laquelle les données Entra ID seront stockées :

Je prends connaissance des différents types d’objets qui seront sauvegardés par le service :

Je définis la rétention des sauvegardes, puis j’active la protection des politiques d’accès conditionnel avant de cliquer sur Suivant :

Je vérifie la politique de sauvegarde, puis je clique sur Finaliser :

A partir de ce moment, l’infrastructure de sauvegarde de Veeam Data Cloud commence à se provisionner :

Quelques minutes plus tard, je constate que l’état de provisionnement est passé à Provisionné :

Je reçois également un e-mail confirmant que la sauvegarde Entra ID a bien été mise en place :

Attendons maintenant le premier cycle de sauvegarde prévu dès cette nuit pour contrôler ce qui aura été sauvegardé par Veeam Data Cloud.

Etape II – Contrôle des sauvegardes :

De retour sur le tableau de bord de VDC, je constate dès le lendemain la création des premiers objets sauvegardés (utilisateurs, groupes, applications, etc…) :

Je vérifie la consommation de licences et je note que 34 utilisateurs sont protégés :

Dans Entra ID, je constate que mon tenant contient bien 34 utilisateurs, la correspondance est donc correcte :

Je visualise la liste des objets sauvegardés dans la console Veeam :

Je confirme que le nombre d’objets utilisateurs sauvegardés correspond bien à Entra ID :

Je constate le même alignement sur le nombre de groupes sauvegardés :

Je vérifie également le nombre d’unités administratives sauvegardées :

Je contrôle les rôles pré-provisionnés et personnalisés pris en compte dans la sauvegarde :

Je constate la sauvegarde des applications et des principaux de service :

Je confirme la présence des politiques d’accès conditionnel sauvegardées :

Enfin, de retour dans l’onglet Configuration, je note que les paramètres ne sont plus modifiables après activation du service (un ticket au support sera nécessaire) :

Je constate progressivement, au fil des jours suivants, l’enchaînement des sauvegardes automatiques programmées :

Je peux à tout moment cliquer sur une exécution pour visualiser le détail des sauvegardes :

Je consulte l’entrée Backup Audit Logs qui liste les actions archivées :

Je constate également la présence des Sign-in Logs dans les éléments sauvegardés :

Testons maintenant les fonctionnalités de restauration d’objets sauvegardés.

Etape III – Test de restauration :

Je commence par supprimer un utilisateur dans Entra ID :

Dans la corbeille des utilisateurs supprimés, je confirme la suppression définitive de cet utilisateur :

Dans la console Veeam Data Cloud, je retourne dans la liste des objets utilisateurs sauvegardés, je clique sur l’utilisateur concerné, puis sur Restaurer :

Je peux sélectionner un point de restauration précis via le calendrier, puis je clique sur Suivant :

Je confirme les options de restauration proposées et je clique à nouveau sur Suivant :

Je clique sur Restaurer pour démarrer l’opération de récupération :

Je constate l’apparition d’une activité dans la liste des restaurations :

Une fois la restauration terminée, je constate des avertissements éventuels indiquant les sous-éléments qui n’ont pas pu être répliqués à l’identique :

De retour dans Microsoft Entra ID, je constate la recréation d’un nouvel objet utilisateur basé sur les informations sauvegardées. Le nouvel utilisateur restauré reprend bien tous les attributs d’origine :

Je modifie cette fois une caractéristique de l’utilisateur directement dans la console Entra ID :

Je retourne dans Veeam Data Cloud et je lance une comparaison/restauration sur cet utilisateur modifié :

Je constate que la différence sur la propriété modifiée est bien détectée, puis je clique sur Suivant :

Je peux renseigner un commentaire pour tracer l’action de restauration, puis je clique sur Restaurer :

Une fois la restauration terminée, je retourne dans Entra ID pour vérifier que la propriété a bien été restaurée à sa précédente valeur :

Je supprime cette fois un groupe Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :

Une fois la restauration terminée, je retourne dans Entra ID vérifier que le groupe a bien été restauré à son état d’origine avec un nouvel ID :

Je supprime cette fois un rôle personnalisé Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :

Une fois la restauration terminée, je retourne dans Entra ID vérifier que le rôle personnalisé a bien été restauré à son état d’origine ses permissions :

Je supprime cette fois une police d’accès conditionnel Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :

Une fois la restauration terminée, je retourne dans Entra ID vérifier que la police d’accès conditionnel a bien été restaurée à son état d’origine avec un nouvel ID :

Je supprime cette fois une Application Entra ID, retourne dans Veeam Data Cloud, puis je lance une restauration :

Une fois la restauration terminée, je retourne dans Entra ID vérifier que l’application a bien été restaurée à son état d’origine avec un nouvel ID :

Conclusion

Dans un contexte où l’identité est devenue le cœur de la sécurité cloud, disposer d’un historique exploitable et restaurable n’est plus un luxe, mais une nécessité opérationnelle.

Avec Veeam Data Cloud pour Microsoft Entra ID, on sort enfin du modèle « espérons que rien ne casse » pour entrer dans une vraie logique de sauvegarde et de restauration de l’identité cloud.

L’approche 100 % SaaS simplifie radicalement le déploiement : aucune infrastructure à maintenir, stockage inclus, rétention longue durée et surtout, une capacité à restaurer un objet critique Entra ID même après suppression définitive.

La prochaine étape ?

Explorer les scénarios avancés : restauration partielle de propriétés, rollback après mauvaise configuration, audit de versioning… et voir comment cette brique peut s’intégrer dans une stratégie globale de résilience Entra ID.

Azure Virtual Desktop – Invités

Comme pour Windows 365, Microsoft continue de faire évoluer Azure Virtual Desktop pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner dans votre AVD une ou plusieurs identités externes (invités B2B dans votre tenant Microsoft Entra ID).

Spoiler alert : cet article est la copie quasi-identique de celui consacré aux comptes invités sur Windows 365.

Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un accès à un environnement Azure Virtual Desktop créé sur votre tenant.

Qui peut bénéficier de cette nouveauté ?

Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.

Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…

Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?

Non, vous utilisez les mêmes pool d’hôtes Azure Virtual Desktop et les mêmes licences que pour les utilisateurs internes à votre tenant.

Depuis quelles plate-formes le compte invité fonctionne ?

A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :

  • Navigateur internet
  • Windows App

Quelles sont les conditions techniques ?

Plusieurs conditions sont actuellement en vigueur et sont rappelées sur cette page de la documentation Microsoft :

  • VM AVD sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
  • VM AVD jointe à Entra ID
  • Single Sign-On activé au niveau du pool d’hôtes AVD

Quelles sont les principales limitations actuellement dans cette préversion ?

  • FSLogix n’est pas encore pris en charge : un nouveau profil utilisateur sera créé sur chaque hôte de session auquel elles se connectent.
  • Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler les VMs AVD).
  • Pas de support pour le Cloud Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
  • Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
  • Quelques limites sur la Token Protection pour identités externes.

Quelle licence Azure Virtual Desktop faut-il pour ces utilisateurs invités ?

Comme dit plus haut, il faut toujours provisionner une licence dans votre tenant pour le compte invité.

Les licences détenues par un compte invité dans son propre tenant ne confèrent aucun droit pour utiliser Azure Virtual Desktop dans votre tenant :

Si vous déployez Azure Virtual Desktop pour une utilisation avec des identités externes (actuellement en préversion publique), certaines considérations particulières peuvent s’appliquer concernant la manière de licencier Azure Virtual Desktop ainsi que d’autres produits et services Microsoft.

Microsoft Learn

Vous devez donc acheter et attribuer les mêmes licences AVD que pour vos utilisateurs internes, et aussi une licence Microsoft 365, si nécessaire.

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

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Etape 0 – Rappel des prérequis :

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

  • Un abonnement Azure valide
  • Un tenant Microsoft
  • Une des licences requises pour Azure Virtual Desktop

Avant d’aller plus loin, commençons par vérifier que notre environnement AVD répondent bien aux prérequis de la fonctionnalité.

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page de votre pool d’hôtes AVD :

Vérifiez sur une des VMs AVD que la jointure est bien définie vers Entra :

Contrôlez également sur le pool d’hôtes que le Single Sign-On (SSO) est activé :

Vérifiez ensuite que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2, avec le correctif KB5065789, ou plus récent :

Si tous ces points sont OK, commençons par inviter un nouvel utilisateur externe à notre tenant.

Etape I – Création de l’utilisateur invité :

Pour cela, rendez-vous dans le portail Microsoft Entra ID pour créer un nouvel utilisateur invité.

Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :

Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité, puis cliquez ici :

Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :

Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :

Sur votre tenant, ouvrez le portail d’administration de Microsoft 365 :

Ouvrez la fiche de l’utilisateur invité et attribuez-lui la licence AVD nécessaire, puis enregistrez :

Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son accès à l’environnement AVD.

Etape II – Provisionnement de l’accès AVD à notre invité :

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page du groupe d’application concerné :

Ajoutez l’utilisateur invité à votre groupe d’applications Azure Virtual Desktop :

Pensez également à lui ajouter un droit de connexion à la machine AVD via un rôle Azure RBAC :

Le provisionnement de l’utilisateur invité à notre environnement AVD est terminé. Nous allons maintenant pouvoir tester la connexion de ce dernier à Azure Virtual Desktop.

Etape III – Test de connexion invité depuis le navigateur internet :

Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL historique d’Azure Virtual Desktop, puis authentifiez avec le compte invité de votre utilisateur :

https://client.wvd.microsoft.com/arm/webclient/index.html

Une fois authentifié, constatez l’absence d’accès à l’environnement Azure Virtual Desktop provisionné sur votre tenant pour votre compte invité :

Ouvrez alors une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL contenant le domaine de votre tenant :

https://client.wvd.microsoft.com/arm/webclient/index.html?tenant=<domainName>

Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que votre environnement AVD apparaît cette fois :

Testez au besoin une seconde URL, commune entre les services Azure Virtual Desktop et Windows 365 :

https://windows.cloud.microsoft?tenant=<domainName>

Peu importe le site internet utilisé, cliquez sur Connecter :

Cliquez à nouveau sur Connecter :

Cliquez sur Oui :

Constatez l’apparition du message de chargement de FSLogix :

Constatez la bonne ouverture de session de votre compte invité :

Ouvrez Windows PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement dans Entra ID :

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
  • EnterpriseJoined : NO
  • DomainJoined : NO :
  • TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
  • SSO / Primary Refresh Token :
    • AzureAdPrt : YES
    • DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du token de connexion pour le SSO :

Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :

Malgré l’absence de SSO, la connexion à AVD depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.

Etape IV – Test de connexion invité depuis Windows App :

Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :

Ouvrez localement PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier :

Avant de saisir votre e-mail, cliquez sur le bouton des options avancées :

Cliquez sur le menu Organisation :

Indiquez le domaine de votre organisation, puis cliquez sur Suivant :

Renseignez l’adresse e-mail et le mot de passe du compte invité :

Constatez la bonne ouverture de l’application Windows App connectée à votre tenant avec le compte invité :

Cliquez sur Connecter pour lancer la session Azure Virtual Desktop :

Constatez la bonne ouverture de session AVD pour votre compte invité, puis ouvrez PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement AVD dans Entra ID :

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
  • EnterpriseJoined : NO
  • DomainJoined : NO
  • TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
  • SSO / Primary Refresh Token :
    • AzureAdPrt : YES
    • DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Enfin, la console de gestion Azure Virtual Desktop affiche bien votre utilisateur invité :

Par contre, aucune information n’y est disponible pour notre utilisateur invité :

Mais en passant par l’hôte de session AVD, les actions semblent également fonctionner sur notre utilisateur invité :

Vous voilà bien connecté avec votre compte invité sur l’environnement AVD de votre tenant Microsoft.

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Souci I – Impossible de se connecter malgré une version 24H2 :

Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :

Commencez par vérifier que votre utilisateur invité est bien autorisé à ouvrir une session sur votre machine virtuelle AVD via le rôle Azure RBAC suivant :

Ensuite, cela vient peut-être de l’absence du correctif KB5065789 sur votre machine AVD, pourtant en version 24H2.

Pour remédier à cette mise à jour manquante, connectez-vous avec un administrateur sur votre machine AVD, puis lancez la commande PowerShell suivante pour vérifier les correctifs installés :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Si besoin, allez dans Windows Update, puis lancez la recherche de mises à jour :

Redémarrez si nécessaire :

Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Retournez sur la page web de Azure Virtual Desktop ouverte avec le compte invité :

Constatez cette fois la bonne ouverture de session sur votre compte invité :

Souci II – Impossible de choisir une entreprise via Windows App :

Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :

C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.

Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :

Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :

J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.

Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :

Suivi de ce seconde message :

Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.

Conclusion

L’arrivée des identités externes sur Azure Virtual Desktop simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.

La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.

C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.

Windows 365 – Invités

Microsoft continue de faire évoluer Windows 365 pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner un Cloud PC pour une identité externe (invité B2B dans votre tenant Microsoft Entra ID).

Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un poste Windows 365 sécurisé.

Qui peut bénéficier de cette nouveauté ?

Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.

Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…

Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?

Non. Vous utilisez les mêmes polices de provisionnement Windows 365 et le même processus de licence que pour les Cloud PC internes.

Depuis quelles plate-formes le compte invité fonctionne ?

A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :

  • Navigateur internet
  • Windows App

Quelles sont les conditions techniques ?

Plusieurs conditions sont actuellement en vigueur et sont rappelées sur cette page de la documentation Microsoft :

  • Cloud PC sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
  • Cloud PC joint à Entra ID
  • Police de provisionnement Windows 365 avec Single Sign-On activé

Quelles sont les principales limitations actuellement dans cette préversion ?

  • Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler le Cloud PC).
  • Pas de support pour Windows 365 Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
  • Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
  • Quelques limites sur la Token Protection pour identités externes.

Quelle licence Windows 365 faut-il pour ces utilisateurs invités ?

Comme dit plus haut, il faut bien provisionner une licence dans votre tenant sur le compte invité.

Les licences détenues par un collaborateur externe dans son propre tenant ne confèrent aucun droit pour utiliser un Cloud PC dans votre tenant :

Si vous utilisez Windows 365 avec des identités externes (actuellement en préversion), il peut y avoir des considérations spéciales à prendre en compte pour la façon dont vous accordez des licences à d’autres produits et services de Microsoft pour ces identités externes.

Les licences attribuées à un collaborateur externe dans son propre locataire d’origine ne confèrent généralement pas de droits à Windows 365 ou à d’autres produits au sein de votre locataire. Par conséquent, nous vous recommandons généralement d’acheter le même type de licence que vous achetez pour les utilisateurs internes et de l’attribuer à l’identité du collaborateur externe dans votre locataire.

Par exemple, si vous attribuez des licences Microsoft 365 Apps en même temps que vos PC Windows 365 cloud et que vos collaborateurs externes ont besoin des mêmes droits, achetez une licence Microsoft 365 Apps et attribuez-la au collaborateur externe de votre locataire.

Microsoft Learn

Vous devez donc acheter et attribuer les mêmes licences que pour vos utilisateurs internes (ex. Windows 365 Enterprise/Frontline, Microsoft 365 Apps si nécessaire).

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

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Etape 0 – Rappel des prérequis :

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

  • Un abonnement Azure valide
  • Un tenant Microsoft
  • Une licence Windows 365 Entreprise

Avant d’aller plus loin, commençons par vérifier que notre environnement répondent bien aux prérequis de la fonctionnalité pour Windows 365.

Pour cela, rendez-vous dans le portail Intune, puis ouvrez la politique que vous utilisez pour vos Cloud PC.

Vérifiez que la jointure est bien définie sur Microsoft Entra join :

Contrôlez également que le Single Sign-On (SSO) est activé :

Vérifiez ensuite que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2, avec le correctif KB5065789, ou plus récent :

Si tous ces points sont OK, commençons par inviter un nouvel utilisateur externe à notre tenant.

Etape I – Création de l’utilisateur invité :

Pour cela, rendez-vous dans le portail Microsoft Entra ID pour créer un nouvel utilisateur invité.

Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :

Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité puis cliquez ici :

Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :

Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :

Sur votre tenant, ouvrez le portail d’administration de Microsoft 365 :

Ouvrez la fiche de l’utilisateur invité et attribuez-lui la ou les licences Windows 365 nécessaires, puis enregistrez :

Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son Cloud PC.

Etape II – Provisionnement du Cloud PC invité :

Pour cela, rendez-vous dans le portail Intune :

Constatez l’absence du début du provisionnement du Cloud PC :

Vérifiez le groupe d’utilisateurs associé à votre politique de provisionnement Windows 365, puis et ajoutez-lui le nouvel utilisateur invité :

Constatez le début du provisionnement du Cloud PC :

Quelques temps plus tard, constatez le succès du provisionnement pour cet utilisateur invité :

Le provisionnement du Cloud PC est maintenant terminé. Nous allons maintenant pouvoir tester la connexion à ce poste avec notre utilisateur invité.

Etape III – Test de connexion invité depuis le navigateur internet :

Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL ci-dessous, puis authentifiez avec le compte invité de votre utilisateur :

https://windows.cloud.microsoft/

Une fois authentifié, constatez l’absence du nouveau Cloud PC provisionné sur votre tenant pour votre compte invité :

Ouvrez une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL, contenant le domaine de votre tenant :

https://windows.cloud.microsoft?tenant=<domainName>

Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que le Cloud PC invité apparaît :

Cliquez sur Connecter :

Cliquez à nouveau sur Se connecter :

Cliquez sur Oui :

Constatez la bonne ouverture de session de votre compte invité :

Ouvrez Windows Terminal :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement du Cloud PC dans Entra ID :

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID (prérequis principal pour les Cloud PC invités).
  • EnterpriseJoined : NO
  • DomainJoined : NO : Normal pour un Cloud PC moderne en mode Entra join (non hybride).
  • TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
  • SSO / Primary Refresh Token :
    • AzureAdPrt : YES
    • DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du jeton (token) de connexion pour le SSO :

Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :

Malgré l’absence de SSO, la connexion depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.

Etape IV – Test de connexion invité depuis Windows App :

Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :

Ouvrez PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier :

Avant de saisir votre e-mail, cliquez sur le bouton d’options avancées :

Cliquez sur le menu Organisation :

Indiquez le domaine de votre organisation, puis cliquez sur Suivant :

Renseignez l’adresse e-mail et le mot de passe du compte invité :

Constatez la bonne ouverture de l’application Windows App connectée à votre tenant avec le compte invité :

Cliquez sur Connecter pour lancer la session Cloud PC :

Constatez la bonne ouverture de session de votre compte invité, puis ouvrez Windows Terminal :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement du Cloud PC dans Entra ID :

dsregcmd /status

Vous voilà bien connecté avec votre compte invité sur un Cloud PC dans votre tenant Microsoft.

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Souci I – Impossible de se connecter malgré une version 24H2 :

Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :

Ou ce message d’erreur là :

Cela vient peut-être de l’absence du correctif KB5065789 sur votre Cloud PC, pourtant en version 24H2.

Pour remédier à cette mise à jour manquante, retournez sur le portail Entra ID pour ajouter un utilisateur de votre tenant aux administrateurs locaux des machines jointes à Entra ID :

Ensuite, retournez sur le portail Azure pour récupérer l’adresse IP locale du Cloud PC invité :

Depuis un autre Cloud PC auquel vous avez déjà accès, connectez-vous à cette IP locale avec un des comptes administrateurs :

Attendez que l’ouverture de session se fasse :

Lancez la commande PowerShell suivante pour vérifier les correctifs installés :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Si besoin, allez dans Windows Update puis lancez la recherche de mises à jour :

Redémarrez si nécessaire :

Rouvrez la session avec l’administrateur local, puis relancez Windows Update si besoin :

Redémarrez à nouveau, si nécessaire :

Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :

Retournez sur la page web de Windows 365 ouverte avec le compte invité :

Constatez cette fois la bonne ouverture de session sur votre compte invité :

Souci II – Impossible de choisir une entreprise via Windows App :

Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :

C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.

Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :

Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :

J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.

Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :

Suivi de ce seconde message :

Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.

Conclusion

L’arrivée des Cloud PC Windows 365 pour identités externes simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.

La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.

C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.

Attendez-vous au prochain article sur Azure Virtual Desktop 😎🤘😉

Mise en place d’une identité managée pour AVD

Dès ce mois de septembre 2025, Microsoft introduit l’identité managée (Managed identity) aux environnements Azure Virtual Desktop. Cet ajout permettra d’exécuter en toute sécurité des actions lors de la création, suppression et mise à jour des machines virtuelles du pool d’hôtes. Cette nouvelle identité managé, de type système ou utilisateur est encore en préversion, remplacera certains usages du bien connu service principal Azure Virtual Desktop, que l’on utilise jusqu’à présent sur Azure comme sur Entra.

A partir du 15 novembre 2025, toute configuration utilisant le système de gestion des mises à jour intégré à Azure Virtual Desktop devra obligatoirement être associée à une identité managée (Managed Identity) pour continuer à fonctionner.

Concrètement, cela signifie que l’ancien modèle basé sur le service principal AVD disparaît progressivement au profit d’une approche plus robuste, où les opérations de création, suppression et mise à jour des machines virtuelles, passent par une authentification native dans Microsoft Entra ID.

Voici le service principal que l’on utilise actuellement :

Pour les administrateurs, c’est une étape importante qu’il faut anticiper dès maintenant, car elle touche directement la gestion quotidienne des environnements AVD.

Pourquoi ce changement ?

Historiquement, AVD utilisait un service principal spécifique pour réaliser certaines actions sur les ressources Azure associées aux hôtes de session :

Une identité managée s’authentifie automatiquement auprès d’Entra ID sans qu’aucun mot de passe ou secret ne soit stocké dans vos scripts ou vos ressources. Cela réduit considérablement la surface d’attaque et améliore la conformité.

Côté gouvernance, tout passe par l’Azure RBAC, ce qui rend les permissions plus lisibles et plus faciles à auditer.

System-assigned ou User-assigned ? deux modèles possibles :

Azure propose deux types d’identités managées.

  • System-assigned : créée et rattachée directement au pool d’hôtes Son avantage principal est sa simplicité : elle vit et meurt avec la ressource. Si vous supprimez le pool d’hôtes , l’identité disparaît automatiquement.
  • User-assigned : ressource indépendante dans Azure que vous pouvez rattacher à un ou plusieurs pools d’hôtes. Elle est donc plus flexible, particulièrement utile dans des environnements complexes où plusieurs ressources doivent partager la même identité et les mêmes permissions. En revanche, elle demande une gestion supplémentaire : l’objet reste actif même si le pool d’hôtes est supprimé.

Quelles fonctionnalités AVD utiliseront cette identité managée ?

Pour le moment, toutes les fonctionnalités d’Azure Virtual Desktop ne basculent pas encore vers ce modèle. Seule la fonction de mise à jour d’un pool d’hotes est prévue actuellement :

Les autres fonctionnalités, telles que App Attach, Autoscale et Start VM on Connect s’appuient encore sur le service principal Azure Virtual Desktop :

Cela signifie que vous aurez peut-être à gérer une période de transition où les deux approches cohabitent.

Quels impacts pour vos environnements AVD existants et futurs ?

Pour les administrateurs AVD, ce changement implique de revoir la configuration des pool d’hôtes, en particulier ceux qui utilisent ou vont utiliser la session host configuration.

À partir de novembre 2025, il ne sera plus possible d’ajouter de nouveaux hôtes de session sans identité managée :

  • À partir du 19 septembre 2025, les nouveaux pools d’hôtes utilisant une configuration d’hôtes de session dans le portail Azure devront être créés avec une identité managée.
  • À partir du 15 octobre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus mettre à jour leur configuration tant qu’une identité managée n’aura pas été ajoutée.
  • À partir du 15 novembre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus créer de nouveaux hôtes de session tant qu’une identité managée n’aura pas été ajoutée.

Quels sont les rôles AVD nécessaires avec l’identité managée ?

Lorsqu’on assigne une identité managée à un pool d’hôtes AVD, il faut lui donner les bons rôles RBAC pour qu’Azure Virtual Desktop puisse automatiser les opérations sur les hôtes de session. Voici les rôles clés utilisés avec la session host configuration et leur utilité :

  • Desktop Virtualization Virtual Machine Contributor – Resource group of image gallery : Autorise l’accès à la Compute Gallery pour que l’identité managée puisse lire et utiliser les images servant de base au déploiement des VMs. Sans ce rôle, AVD ne peut pas provisionner une VM à partir de l’image de référence.
  • Desktop Virtualization Virtual Machine Contributor – Resource group for session hosts : Donne le droit de créer, mettre à jour et supprimer les machines virtuelles qui composent le pool d’hôtes. C’est le rôle central pour permettre à AVD de gérer le cycle de vie des hôtes de session.
  • Desktop Virtualization Virtual Machine Contributor – VNet / NSG : Permet à l’identité de connecter les cartes réseau des VMs au bon sous-réseau et d’appliquer les règles de sécurité (NSG). Ce rôle est indispensable pour que les hôtes de session soient correctement intégrés au réseau et puissent rejoindre le domaine ou accéder aux ressources.
  • Key Vault Secrets User – Domain join Key Vault : Autorise l’identité à récupérer les secrets nécessaires à la jointure au domaine, comme le mot de passe d’un compte de service stocké dans Azure Key Vault. Cela automatise le processus sans exposer les identifiants en clair.
  • Key Vault Secrets User – Admin account Key Vault : Permet à l’identité d’accéder aux identifiants administrateur stockés dans un Key Vault. Ces informations peuvent être nécessaires lors de la création ou de la configuration initiale des hôtes de session.

Pour illustrer concrètement la mise en place et l’utilisation d’une identité managée dans Azure Virtual Desktop, j’ai choisi de documenter deux scénarios distincts. Cela permettra de couvrir à la fois un environnement AVD neuf et un environnement AVD existant, afin que chacun puisse s’y retrouver selon sa situation.

Dans ce premier cas, je pars de zéro avec un déploiement complet d’Azure Virtual Desktop. Ce scénario illustre la nouvelle exigence imposée par Microsoft pour les nouveaux déploiements, et montre comment intégrer cette configuration proprement dès le départ.

Scénario I – Création d’un nouvel environnement AVD :

L’objectif est de créer un tout nouveau pool d’hôtes après le 19 septembre 2025, et en activant directement l’assignation d’une identité managée dès le processus de création.

Lors de la création de mon pool d’hôtes AVD, sur l’onglet Management, je constate que la case Identité managée est déjà cochée, ainsi que les permissions attribuées à cette identité :

Durant le déploiement, je vois les assignations de rôle automatiquement créées sur différentes ressources Azure pour cette identité managée :

Une fois l’environnement créé, la configuration de l’identité managée est visible directement dans les paramètres du pool d’hôtes :

En cliquant sur l’assignation de rôles, je peux voir les rôles effectivement appliqués sur les ressources du déploiement :

En vérifiant les rôles associés au pool d’hôtes, je constate la présence d’une identité managée de type system-assigned :

Dans le coffre Azure, je retrouve également cette identité managée avec les permissions nécessaires :

Afin de voir l’impact de celle-ci, je déclenche une mise à jour immédiate sur mon nouveau pool d’hôtes AVD :

La mise à jour se déclenche correctement :

Environ quinze minutes plus tard, la mise à jour se termine avec succès :

Les journaux montrent bien que c’est l’identité managée qui a été utilisée comme initiateur de la mise à jour :

Le deuxième test consiste maintenant à prendre un environnement AVD déjà déployé, avec un pool d’hôtes fonctionnel, et à lui associer une identité managée après coup.

Scénario II – Ajout d’une identité managée à un environnement AVD existant :

Ce scénario reflète les besoins de nombreuses organisations qui disposent déjà d’un parc en production AVD et qui doivent se mettre en conformité avant la date butoir de novembre 2025.

Sur mon environnement AVD déjà en place avant le 19 septembre 2025, je lance également une mise à jour via l’interface :

La mise à jour se déclenche correctement :

Après environ quinze minutes, la mise à jour se réalise avec succès :

Dans l’activité, je vois l’identité applicative AVD utilisée pour orchestrer l’opération.

Afin de mettre une identité managée sur mon ancien environnement AVD, je coche la case suivante sur ce pool d’hôtes, puis j’enregistre ma modification :

L’identité managée apparaît désormais dans la configuration du pool d’hôtes :

Une commande PowerShell permet de confirmer la présence de l’identité managée affectée au pool d’hôtes :

$parameters = @{
    Name = '<HostPoolName>'
    ResourceGroupName = '<ResourceGroupName>'
}

Get-AzWvdHostPool @parameters | Format-Table Name, IdentityType

Je constate cependant que cette identité n’a encore aucune assignation de rôle.

Malgré tout, je déclenche une mise à jour immédiate AVD :

Cette dernière échoue immédiatement :

Les journaux indiquent clairement que l’identité managée ne dispose pas des droits suffisants sur l’environnement AVD :

Je retourne dans la configuration et ajoute un par un les rôles nécessaires (Compute Gallery, Session Hosts, VNet/NSG, Key Vaults).

J’effectue l’opération autant de fois que nécessaire :

Je contrôle que les rôles sont bien en place sur le pool d’hôtes et sur le coffre associés :

Je relance la mise à jour du pool d’hôtes.

La mise à jour de mon environnement AVD se lance :

Après une quinzaine de minutes, la mise à jour est finalisée avec succès :

Les logs confirment que l’identité managée a bien été utilisée pour piloter la nouvelle mise à jour :

Conclusion

L’introduction des identités managées dans Azure Virtual Desktop marque une étape importante dans la sécurisation et la modernisation du service. Là où le service principal AVD imposait la gestion de secrets et une gouvernance parfois complexe, l’identité managée apporte une intégration native à Microsoft Entra ID et une simplification des processus.

Les deux scénarios que j’ai présentés montrent bien la dualité de la situation actuelle :

  • Pour les nouveaux environnements, l’identité managée est désormais intégrée par défaut, et il suffit de l’accepter et de valider les rôles nécessaires.
  • Pour les environnements existants, une phase d’adaptation est incontournable. Il faut ajouter manuellement l’identité managée, attribuer progressivement les bons rôles RBAC, et valider que toutes les opérations AVD critiques fonctionnent correctement.

Au-delà de l’exemple des mises à jour de pools d’hôtes, ce changement illustre surtout la direction que prend Microsoft : réduire la dépendance aux secrets et renforcer la sécurité par défaut. D’ici novembre 2025, l’identité managée sera obligatoire pour l’ensemble des environnements AVD utilisant la session host configuration.

Mon conseil : n’attendez pas la date butoir. Prenez le temps dès maintenant de tester, documenter et industrialiser vos déploiements AVD avec une identité managée. Cela vous évitera des blocages en production et vous assurera une transition fluide vers ce nouveau modèle de sécurité.

Test de clefs FIDO2 Token2

Aujourd’hui, on se retrouve pour tester ensemble une clef FIDO2 sur un environnement Microsoft Cloud. Fini les galères des mots de passe, place à une sécurité renforcée et simplifiée. Dans cet article, je vous partage mon expérience, étape par étape, de la configuration sur un tenant Microsoft à la vérification des connexions via USB et NFC. Venez découvrir comment, avec une approche à la fois technique et accessible, on peut repenser la manière de sécuriser nos identités en ligne.

Qu’est-ce que FIDO ?

FIDO, qui signifie Fast IDentity Online, désigne un ensemble de normes d’authentification qui utilisent la cryptographie à clé publique pour se passer des mots de passe traditionnels.

Concrètement, l’objectif de FIDO est de renforcer la sécurité en ligne en utilisant des méthodes d’authentification plus fiables et ergonomiques, comme les dispositifs matériels (clés de sécurité) ou l’authentification biométrique (empreintes digitales, reconnaissance faciale).

Pour moi, c’est une approche qui simplifie l’expérience utilisateur car, tout en augmentant considérablement la sécurité, ces passkeys sont interopérables, ce qui signifie qu’une seule passkey peut être utilisée sur plusieurs sites ou comptes.

D’ailleurs, j’avais déjà parlé de l’intégration d’une authentification FIDO2 pour le service Azure Virtual Desktop juste ici :

Qu’est-ce que l’Alliance FIDO ?

Créée en 2012, FIDO Alliance est une association d’entreprises du secteur technologique ayant pour objectif de changer la manière dont nous nous authentifions en ligne. L’idée de ce consortium est de se passer des mots de passe, souvent vulnérables, en favorisant des méthodes d’authentification plus sûres et plus simples à utiliser :

Pour résumer, FIDO Alliance réunit de nombreux acteurs du secteur (comme Google, Microsoft, mais pas que) pour développer des standards ouverts, tels que FIDO U2F et FIDO2, qui permettent par exemple d’utiliser des dispositifs matériels (clefs de sécurité) ou des méthodes biométriques pour s’authentifier.

FIDO vs U2F vs FIDO2 ?

Le protocole FIDO original, alias FIDO 1.0, était la première itération de la norme d’authentification FIDO. Publié en 2014, il visait à remplacer les mots de passe traditionnels par des données biométriques et des jetons matériels. Elle comportait à la fois FIDO UAF (Universal Authentication Framework) et FIDO U2F (Universal Second Factor).

En 2016, le World Wide Web Consortium (W3C) et la FIDO Alliance ont commencé à collaborer pour normaliser l’authentification FIDO. Cela a conduit au lancement de FIDO2 en 2018, qui offre une approche plus complète et standardisée de l’authentification sans mot de passe. De nombreux navigateurs célèbres, dont Firefox et Chrome, ont mis en œuvre la norme, ce qui a contribué à son adoption.

FIDO2 a deux composantes principales : WebAuthn et CTAP (Client to Authenticator Protocol). Ensemble, WebAuthn et CTAP offrent une expérience de connexion cryptographiquement sécurisée, pratique et interopérable.

En résumé, les principales différences entre FIDO 1.0 et FIDO2 sont la normalisation, la portée, l’interopérabilité et l’adoption. FIDO2 est un protocole plus complet et normalisé qui est pris en charge par tous les principaux navigateurs et systèmes d’exploitation, y compris Android, IOS, MacOS et Windows.

oneidentity.com

FIDO2.1 est une petite évolution de la spécification FIDO2 qui vise à combler certaines limites et à renforcer à la fois la sécurité et l’expérience utilisateur. Concrètement, FIDO2.1 apporte notamment :

  • Une gestion améliorée des PIN et des mécanismes d’authentification locales, avec des règles plus strictes pour éviter les codes trop faibles.
  • Des processus d’enrôlement et de récupération des identifiants optimisés, pour faciliter la réinitialisation ou le transfert sécurisé des clés.
  • Une meilleure interopérabilité entre les différents types d’authentificateur (qu’ils soient matériels ou intégrés à un appareil), ce qui simplifie leur déploiement dans des environnements hétérogènes.

En résumé, il ne s’agit pas d’un changement radical, mais plutôt d’un raffinement qui permet d’offrir une sécurité renforcée tout en rendant l’usage du système encore plus fluide et adaptable.

Quelles sont les méthodes de connexion d’une clef FIDO2 ?

USB-A et USB-C :

  • Pour les PC, on branche la clé directement dans un port USB-A ou USB-C.
  • Pour les smartphones, il est souvent possible de les utiliser via un câble OTG ou directement sur un port USB-C, selon le modèle.

NFC :

  • De nombreuses clés intègrent une puce NFC, ce qui permet une connexion sans contact avec des smartphones compatibles (par exemple, iPhone à partir d’iOS 13.3 et de nombreux appareils Android).
  • À noter toutefois que sur Android, les clés protégées par PIN ne supportent pas la connexion NFC.

La prise en charge des clés de passage de FIDO2.1 (à savoir les clés résidentes protégées par un code PIN) a été introduite dans le cadre de Google Play Services v23 et uniquement par le biais de la méthode de transport USB. Cela signifie donc que :

Android ne prend en charge les identifiants FIDO protégés par un code PIN que si Google Play Services est présent. Android ne prend pas en charge les informations d’identification FIDO protégées par un code PIN via NFC.

Token2

Quels sont les risques encourus si je perds ma clef FIDO2 ?

La perte de votre clé FIDO2 peut poser des problèmes d’accès à vos comptes, mais les risques de compromission sont fortement limités. En effet, ces clés reposent sur la cryptographie asymétrique : même si quelqu’un mettait la main sur votre clé, il ne pourrait pas extraire la clé privée qui reste protégée.

De plus, la plupart des dispositifs FIDO2 nécessitent un code PIN ou une authentification biométrique pour être utilisés, ce qui ajoute une couche de sécurité supplémentaire.

Néanmoins, il est important de prévoir une solution de secours. Par exemple, en enregistrant plusieurs clés ou en activant d’autres méthodes de récupération, vous pourrez rapidement révoquer une clé perdue et en associer une nouvelle, sans compromettre l’accès à vos comptes.

Dois-je acheter une licence payante d’Entra ID pour utiliser une clef FIDO2 ?

Non, il n’est pas nécessaire d’acheter une licence Entra ID spécifique pour utiliser une clé FIDO2 en authentification sans mot de passe.

Cette fonctionnalité est incluse dans toutes les éditions d’Entra ID, y compris la version gratuite, même si certaines fonctionnalités avancées (comme l’accès conditionnel) nécessitent des licences Entra ID Premium.

Qui sont Token2 ?

La société Token2 a vu le jour en 2014. Il s’agit d’une entreprise suisse spécialisée dans la cybersécurité, et plus précisément dans l’authentification multifactorielle.

Le siège de Token2 se situe à Versoix, dans la République et le Canton de Genève, en Suisse.

Pour faire simple, ils conçoivent et développent des solutions matérielles et logicielles qui rendent l’authentification en ligne à la fois plus sûre et plus pratique.

D’ailleurs, Token2 est aussi un membre certifié de l’alliance FIDO :

Token2, fier membre de l’Alliance FIDO, a obtenu son certificat FIDO initial en 2019 et fournit une variété de clés de sécurité FIDO depuis plus de 5 ans.

En plus des clés FIDO2 ordinaires, Token2 est ravie de présenter sa très attendue série PIN+, une ligne révolutionnaire de clés de sécurité FIDO2 qui a récemment reçu la certification de l’Alliance FIDO.

Ces clés de sécurité de pointe introduisent des règles avancées de complexité du code PIN qui redéfinissent les standards de sécurité.

fidoalliance.org

Aujourd’hui, ils proposent une gamme de clés de sécurité FIDO2, des tokens TOTP programmables et d’autres dispositifs qui remplacent les authentificateurs mobiles classiques.

Au travers de leur site web, Token2 propose aussi de nombreuses ressources utiles pour aider à la mise en place de ces mesures :

Pour aller toujours plus loin dans la sécurité de leurs produits, Token2 a également fait l’objet d’un audit indépendant (réalisé par Compass) en 2024 sur le firmware open source (disponible sur GitHub) de leurs clés Token2 PIN+ (voir leur outil de test de PIN), confirmant leur robustesse et leur transparence.

Enfin, j’en profite pour dire un grand merci à Manon, Emin et Naila pour me permettre de tester vos produits !

Ce qui m’a séduit d’emblée sur cette clef FIDO2.1 R3, c’est la présence du triple combo USB-A, USB-C et NFC, ainsi que le support des normes FIDO et FIDO2.1( avec le support d’OpenPGP et d’OTP) :

Je vous propose donc, au travers de cet article, de tester un de leur produit, à savoir la clef PIN+ Dual Release3 – FIDO2.1 Key with OpenPGP and OTP and Dual USB Ports via une configuration sur un environnement Cloud de Microsoft :

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

Etape 0 – Rappel des prérequis :

Pour réaliser nos tests sur une clef FIDO2.1, il vous faudra disposer de :

  • Un tenant Microsoft

J’ai choisi dans la première partie de l’article de tester la mise en place d’une clef FIDO2 sur un tenant ne disposant d’aucune licence Entra ID Premium.

Pour vérifier si votre tenant dispose de licences ou non Entra ID Premium, je vous propose de commencer par vérifier cette information

Etape I – Configuration du tenant :

Allez dans la page suivante d’Entra afin de constater la présence, ou non, de licences Entra Premium sur votre tenant :

Ensuite, basculez l’onglet des propriétés afin de déterminer la méthode de sécurité appliquée sur votre tenant :

Enfin, vérifiez l’activation, ou non, de différentes méthodes d’authentification sur cette page :

Notre environnement est donc dans sa configuration la plus basique. Avant de modifier celle-ci, je vous propose de constater les méthodes de sécurité déjà disponibles sur notre utilisateur.

Etape II – Ajout de la méthode d’authentification FIDO2 :

Pour cela, rendez-vous sur la page suivante de votre utilisateur, puis cliquez sur le bouton suivant :

Cliquez-ici pour ajouter une nouvelle méthode d’authentification :

Constatez la liste des méthodes d’authentification déjà accessibles à votre utilisateur :

Retournez sur la page des méthodes d’authentification Entra ID via cette page, puis cliquez-ici :

Activez la méthode FIDO2 :

Configurez au besoin les options de cette méthode, puis cliquez sur Sauvegarder :

Vérifiez le changement de statut pour cette méthode d’authentification :

Attendez environ 5 à 10 minutes avant de continuer la configuration de votre utilisateur.

Etape III – Ajout de la première clef FIDO2 :

Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez à nouveau sur le bouton suivant :

Cliquez-ici pour ajouter une nouvelle méthode d’authentification :

Constatez l’apparition de nouvelles méthodes dans la liste de celles disponibles pour votre utilisateur :

Sélectionnez la méthode appelée Clef de sécurité :

Avant cela, Microsoft souhaite vérifier votre identité par une autre méthode MFA déjà en place, cliquez donc sur Suivant :

Réussissez le challenge MFA avec Microsoft Authenticator :

Une fois réussi, recommencez le processus d’ajout, puis cliquez-ici :

Cliquez sur Suivant :

Microsoft communique alors avec votre OS Windows afin de vérifier et d’enrôler la clef FIDO2 :

Attendez encore quelques secondes :

Confirmez les informations de compte, puis cliquez sur OK :

Cliquez sur OK :

Saisissez le code PIN déjà configuré sur votre clef FIDO2, puis cliquez sur OK :

Touchez physiquement la zone prévue à cet effet pour terminer :

Windows confirme le bon enrôlement de la clef FIDO2 chez Microsoft, cliquez sur OK :

Nommez votre clef FIDO2 afin de l’identifier par la suite plus facilement, puis cliquez sur Suivant :

Cliquez sur Terminer :

Constatez l’apparition de celle-ci dans les informations de sécurité de votre utilisateur :

Il est très fortement conseillé d’enrôler toujours 2 clefs afin d’utiliser la seconde en cas de secours.

Testons maintenant comment l’expérience utilisateur est impactée par l’ajout de cette méthode d’authentification FIDO2.

Etape IV – Test de connexion FIDO2 sur PC :

Sur votre poste, ouvrez un navigateur internet en session privée :

Rendez-vous sur la page officielle de Microsoft office :

Au lieu de saisir le mot de passe de votre utilisateur, cliquez comme ceci :

Attendez quelques secondes :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Cliquez sur Oui :

Et vous voilà correctement authentifié sur le portail de Microsoft Office 365 :

Nous avons vu l’impact de l’authentification d’une clef FIDO2 pour un compte Cloud de Microsoft. Intéressons-nous maintenant à la nouvelle clef FIDO2 proposée par Token2 et ses différentes possibilités d’authentification.

Etape V – Ajout de la clef FIDO2 Token2 T2F2-Dual :

avant d’utiliser cette nouvelle clef FIDO2 pour un compte, il est nécessaire de lui configurer un code PIN.

Pour cela, rendez-vous dans le menu suivant des paramètres Windows :

Cliquez sur le bouton Gérer :

Touchez la zone prévue à cet effet de votre nouvelle clef FIDO2 :

Cliquez-ici pour configurer le code PIN :

Testez un code PIN simple à 4 caractères afin de constater le refus de la nouvelle clef FIDO2 d’accepter cette valeur trop courte :

Testez un code PIN reprenant une simple suite de chiffres à 6 caractères afin de constater un second refus pour accepter cette valeur trop simple :

Renseignez cette fois 6 caractères aléatoires afin de constater l’acceptation de la valeur complexe :

Si nécessaire, il vous est toujours possible de changer ce code PIN en cliquant ici :

Il vous sera demandé de renseigner l’ancien code PIN avant de pouvoir en configurer un nouveau dans le but de conserver les identités déjà configurées :

Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez sur le bouton suivant :

Cliquez-ici pour ajouter une nouvelle méthode d’authentification :

Sélectionnez à nouveau Clef de sécurité, puis repassez sur toutes les étapes afin que votre nouvelle clef FIDO2 apparaisse dans la liste de ses méthodes d’authentification :

Notre nouvelle clef FIDO2 est maintenant en place pour notre utilisateur.

Comme sa méthode d’authentification via le port USB est la même que pour la première clef, testons directement la possibilité de connexion via NFC depuis un smartphone.

Etape VI – Test de connexion NFC sur smartphone :

Si votre smartphone vous permet une connexion via NFC : ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :

Saisissez le compte de votre utilisateur, puis cliquez sur Suivant :

Sans même saisir son mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :

Le message suivant vous invite à rapprocher ou à connecter votre clef FIDO2 à votre smartphone :

Dans le cadre du NFC, approchez votre clef de sécurité FIDO2 en haut de votre smartphone comme ceci :

Retirez la clef, puis saisissez le code PIN de votre clef FIDO2 :

Le message suivant vous invite à rapprocher à nouveau votre clef FIDO2 à votre smartphone :

Rapprochez une seconde fois votre clef FIDO2 afin de confirmer l’authentification de votre compte, puis cliquez sur Oui :

Constatez la bonne connexion de votre utilisateur aux services de Microsoft :

Comme annoncé plus haut, certains smartphones de la marque Android ne permettent pas la connexion NFC à votre compte dans le cadre d’une clef FIDO2 protégée par un code PIN.

Etape VII – Test de connexion USB-C sur smartphone :

Si votre smartphone ne vous permet pas la connexion via NFC : ouvrez un navigateur internet en session privée, rendez-vous sur la page officielle de Microsoft office, saisissez le nom de compte, puis cliquez sur Suivant :

Sans même saisir de mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :

Cliquez sur le bouton ci-dessous :

Le message suivant vous invite à connecter votre clef FIDO2 à votre smartphone :

Connectez votre clef de sécurité FIDO2 via USB-C, puis saisissez le code PIN de celle-ci :

Touchez physiquement la zone prévue à cet effet pour terminer :

Cliquez sur Oui :

Constatez la bonne connexion de votre utilisateur aux services de Microsoft :

Etape VIII – Ajout d’un accès conditionnel FIDO2 :

Depuis votre portail Entra ID, rendez-vous dans le paramétrage des Accès conditionnels afin de constater le besoin de licence Entra ID Premium pour activer cette fonction :

Achetez une licence Entra ID Premium ou basculez sur un tenant en disposant déjà :

Vérifiez que la sécurité par défaut de votre tenant est désactivée au profit de l’accès conditionnel :

Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :

Configurez celle-ci :

Puis créez votre nouvelle Police d’accès conditionnel :

Saisissez un nom à votre police, sélectionnez votre utilisateur de test, ajoutez l’application Azure, puis cliquez ici :

Autorisez l’accès sous réserve de satisfaire votre méthode d’authentification renforcée :

Ajoutez si besoin une fréquence d’authentification, puis créez votre police d’accès conditionnel :

Attendez quelques minutes, ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :

Saisissez le nom et le mot de passe de votre compte de test, puis cliquez comme ceci :

Vous voilà correctement authentifié sur le portail de Microsoft Office 365 :

Toujours en navigation privée, ouvrez un nouvel onglet pour vous rendre sur le portail Azure, puis constatez le besoin d’un complément d’authentification FIDO2 :

Saisissez le code PIN de votre clef FIDO2 :

Touchez votre clé FIDO2 sur la zone prévue à cet effet :

Vous voilà correctement authentifié sur le portail Azure :

Avant de conclure cet article, je trouvais intéressant de parler de certains outils très pratiques et mis à disposition par Token2 sur leur site.

Annexe I – Démonstration FIDO2/Passkeys :

Token2 met à disposition sur son site internet un outil de démonstration pour les clefs FIDO2 :

Celui-ci vous permet de tester en direct l’enregistrement et l’authentification via des clés FIDO2 et passkeys. Concrètement, il offre une expérience pratique pour :

  • Enregistrement (Registration) : Vous pouvez inscrire votre clé de sécurité (physique ou intégrée, c’est-à-dire un authentificateur de plateforme) en utilisant l’API WebAuthn. Lorsque la clé clignote, il suffit de toucher le bouton, scanner l’empreinte ou utiliser le NFC (pour les appareils compatibles) pour finaliser l’inscription.
  • Authentification (Login) : Une fois la clé enregistrée, l’outil simule un processus de connexion sécurisé. Vous pouvez tester différentes configurations de demande de PIN (toujours, si un PIN est défini, ou jamais) pour voir comment cela influence le comportement de l’authentification.

Annexe II – Démonstration FIDO2.1 Manager :

Token2 met à disposition sur son site internet un utilitaire conçu pour gérer et interagir avec les clés de sécurité FIDO2.1 :

L’outil fido2-manage est un utilitaire de gestion pour les clés de sécurité conformes à la norme FIDO2.1. Concrètement, il permet de :

  • Lister les dispositifs connectés : Afficher la liste des clés FIDO2.1 détectées.
  • Afficher des informations détaillées : Consulter les données techniques de la clé (modèle, AAGUID, certificats d’attestation, etc.).
  • Gérer les passkeys : Visualiser et supprimer les clés résidentes (passkeys) stockées sur l’appareil.
  • Configurer ou modifier le PIN : Définir, changer ou forcer une modification du code PIN de la clé.
  • Réinitialiser la clé : Effectuer une réinitialisation aux paramètres d’usine (en notant que cette opération est possible uniquement dans un court laps de temps après la connexion).

Conclusion

En fin de compte, cette aventure avec la clef FIDO2, notamment la PIN+ Dual Release3, m’a prouvé que la sécurité peut être à la fois robuste et intuitive. Que ce soit pour se connecter via USB ou NFC, l’expérience utilisateur reste fluide et rassurante.

Tester ces solutions, c’est un peu comme prendre un virage vers l’avenir de l’authentification : simple, efficace et sans prise de tête.

Merci d’avoir suivi ce test avec moi, et à très bientôt pour de nouvelles explorations tech !

Protégez-vous des AiTM !

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

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

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

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

  • zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.
  • Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.

AiTM, kesako ?

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

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

Tehtris

Comment fonctionne-t-elle ?

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

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

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

Tehtris

Peut-on s’en protéger ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

Etape I – Configuration Teams :

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

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

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

Cliquez sur Ajouter :

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

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

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

Etape II – Méthode Cloudflare :

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

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

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

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

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

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

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

Copiez le code du fichier worker.js :

Collez ce dernier dans un éditeur de texte :

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

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

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

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

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

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

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

Cliquez sur Oui :

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

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

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

Copiez ce texte de cookies en entier :

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

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

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

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

Ouvrez Google Chrome en navigation privée :

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

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

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

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

allow pasting

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

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

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

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

La console Cloudflare de notre application frauduleuse devient alors inexploitable :

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

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

Etape III – Méthode locale :

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

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

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

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

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

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

Lancez l’installation, puis cliquez sur Suivant :

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

Cliquez sur Suivant :

Cliquez sur Installer :

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

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

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

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

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

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

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

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

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

Confirmez votre confiance en ce dernier :

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

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

func settings add TEAMS_WEBHOOK_URI "https://"

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

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

npm install @azure/functions --save

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

func start --verbose

Choisissez node :

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

Copiez l’URL suivante :

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

Cliquez sur Oui :

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

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

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

Copiez ce texte de cookies en entier :

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

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

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

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

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

allow pasting

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

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

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

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

Etape IV – Méthode Azure :

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

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

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

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

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

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

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

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

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

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

Copiez ce texte de cookies en entier :

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

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

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

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

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

allow pasting

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

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

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

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

Etape V – Ajout de Microsoft Authenticator :

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

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

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

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

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

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

Copiez ce texte de cookies en entier :

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

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

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

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

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

allow pasting

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

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

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

Etape VI – Restriction des adresses IPs :

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

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

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

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

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

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

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

Etape VIII – Restriction des postes locaux :

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

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

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

Conclusion

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

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

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

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

Windows 11 avec Web Sign-in

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

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

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

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

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

Microsoft Learn

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

Mé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 :

L’attribut alt de cette image est vide, son nom de fichier est image-17.png.

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 :

L’attribut alt de cette image est vide, son nom de fichier est image-18.png.

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

Shutdown -R
L’attribut alt de cette image est vide, son nom de fichier est image-19.png.

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

L’attribut alt de cette image est vide, son nom de fichier est image-20.png.

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

L’attribut alt de cette image est vide, son nom de fichier est image-21.png.

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
L’attribut alt de cette image est vide, son nom de fichier est image-22.png.

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
L’attribut alt de cette image est vide, son nom de fichier est image-23.png.

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

L’attribut alt de cette image est vide, son nom de fichier est image-24.png.

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

L’attribut alt de cette image est vide, son nom de fichier est image-25.png.

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

L’attribut alt de cette image est vide, son nom de fichier est image-26.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-27.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-28.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-29.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-30.png.

Cliquez sur Terminer :

L’attribut alt de cette image est vide, son nom de fichier est image-31.png.

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 :

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

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.