AVD hybride sur Proxmox

À la fin de mon article sur Azure Virtual Desktop Hybride, je terminais par une question ouverte : et si quelqu’un testait sur un hyperviseur que je n’avais pas couvert, du Proxmox par exemple ? Personne ne m’a répondu. Alors je l’ai fait moi-même. Le résultat tient en une phrase : ça marche, et exactement de la même façon que sur Hyper-V ou vSphere. La VM Windows 11 montée dans le premier article Proxmox sur Azure, jointe à Entra ID, devient un session host Azure Virtual Desktop à part entière. On se connecte dessus depuis la Windows App, et le bureau qui s’affiche tourne dans Proxmox.

Ce qui rend ce lab amusant, c’est l’empilement : un service AVD dans Azure, qui pilote un session host qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure. Trois couches, et tout le monde s’en accommode.

Si vous débarquez ici sans contexte, lisez peut-être d’abord l’article Azure Virtual Desktop Hybride, qui explique ce qu’est cette préversion, ce qu’elle apporte et ses limites. Celui-ci se concentre sur un seul point : le cas Proxmox, et les deux ou trois choses qui diffèrent quand l’hyperviseur n’est pas dans la liste officielle.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Proxmox est-il supporté ?
2. Le point qui mérite d’être posé clairement : Arc dans une VM imbriquée
3. Étape 0 : l’état de départ et les pré-requis
4. Étape 1 : vérifier l’Entra Join du session host
5. Étape 2 : vérifier la sortie réseau du session host
6. Étape 3 : enregistrer les resource providers
7. Étape 4 : créer le host pool et son identité managée
8. Étape 5 : enrôler la VM Proxmox dans Azure Arc
9. Étape 6 : poser l’extension AVD
10. Étape 7 : assigner les utilisateurs et se connecter
11. Ce qui change vraiment avec Proxmox
12. Les pièges à retenir

1. Proxmox est-il supporté ?

La question mérite une réponse honnête, parce qu’elle a deux niveaux.

Dans son annonce, Microsoft cite nommément Hyper-V, Nutanix AHV, VMware vSphere et les serveurs Windows physiques. Proxmox n’y figure pas. Si vous cherchez une ligne de documentation qui écrit le mot Proxmox, vous ne la trouverez pas, et un support Microsoft pourra légitimement vous le rappeler.

Mais la page d’aperçu de la fonctionnalité est nettement plus large, et c’est elle qui décrit la règle réelle.

You can run Azure Virtual Desktop session hosts on your preferred on-premises hypervisor that supports Windows virtual machines.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

La même page pose la seule contrainte technique qui compte vraiment.

Session hosts must be Azure Arc-enabled. The Azure Arc extension installs the AVD components and registers the device with a host pool.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

Autrement dit, l’hyperviseur n’est pas un participant de la mécanique, il est juste le meuble sur lequel la VM est posée. Azure Arc parle à un Windows, pas à un hyperviseur. Tant que ce Windows est éligible, qu’il sort en TCP 443 et que l’agent Connected Machine s’installe, le reste suit. C’est très exactement ce que j’avais constaté entre mes trois cas Hyper-V et vSphere : la procédure est rigoureusement identique.

Attention : supporté et fonctionnel ne sont pas synonymes. Proxmox fonctionne, je l’ai vérifié de bout en bout, mais il n’est pas nommé dans la matrice Microsoft. Pour un lab, une démonstration ou un PoC, aucun problème. Pour un déploiement de production, gardez en tête que vous sortez de la liste explicitement citée, ce qui s’ajoute au fait que la fonctionnalité est déjà en préversion.

2. Le point qui mérite d’être posé clairement : Arc dans une VM imbriquée

Il y a une bizarrerie dans ce lab, et je préfère la traiter tout de suite plutôt que de laisser quelqu’un la relever en commentaire.

Azure Arc sert à gérer des machines qui ne sont pas dans Azure. Or mon nœud Proxmox est, lui, une machine virtuelle Azure. On pourrait croire qu’on essaie d’enrôler une VM Azure dans Arc, ce qui n’a pas de sens et n’est pas pris en charge :

Ce n’est pas ce qui se passe. Ce que j’enrôle, c’est la VM Windows 11 qui tourne dans Proxmox, et cette machine n’a rien d’une ressource Azure : elle n’apparaît dans aucun groupe de ressources, elle n’a pas d’identité managée, elle n’atteint pas le service de métadonnées d’instance, et son adresse est une 10.10.10.x distribuée par le dnsmasq du nœud, derrière le NAT nftables mis en place dans le premier article. Du point de vue d’Azure Arc, c’est une machine anonyme quelque part sur Internet qui sort en 443. Exactement le profil d’un serveur de datacenter.

Mon retour terrain : cette nuance n’est pas un détail de présentation, c’est ce qui fait que le lab est représentatif. Si vous refaites l’exercice sur un Proxmox posé sur une vraie machine dans votre garage ou votre salle serveur, vous obtiendrez le même résultat par le même chemin. Azure n’est ici qu’un moyen commode de disposer d’un hyperviseur.

3. Étape 0 : l’état de départ et les pré-requis

Je repars de la machine construite dans les deux articles précédents, sans rien y changer d’autre que l’identité.

Élément	Ce que j’ai
Hyperviseur	Proxmox VE 9, nœud `proxmox-ve`, dans une VM Azure Standard_D16s_v3
Réseau des invités	Bridge `vmbr0` en 10.10.10.0/24, NAT nftables, DHCP et DNS par dnsmasq
Session host	VM Windows 11 Entreprise mono-session, 2 cœurs, 8 Gio, disque de 64 Gio
Identité	Microsoft Entra Join pur, aucun contrôleur de domaine
Licence utilisateur	Microsoft 365, éligible AVD
Abonnement	Un abonnement Azure actif, rôles Azure Connected Machine Onboarding et Desktop Virtualization Contributor

Les pré-requis côté Azure restent ceux de l’article Azure Virtual Desktop Hybride dans leurs grandes lignes, mais la documentation a évolué depuis que je l’ai écrit, et deux points ont changé. Je les signale au fil des étapes.

Pré-requis	Détail
Resource providers	`Microsoft.HybridCompute`, `Microsoft.HybridConnectivity`, `Microsoft.GuestConfiguration`, `Microsoft.DesktopVirtualization`
RBAC	Azure Connected Machine Onboarding, et Desktop Virtualization Contributor
Identité du session host	Entra Join, jointure AD, ou jointure hybride pour un Windows client
Réseau	Sortie TCP 443 vers les URL requises par AVD et vers les endpoints Azure Arc
Agent Arc	Azure Connected Machine agent installé sur chaque session host
Identité managée	À assigner au host pool, avec le rôle Reader sur le groupe de ressources des machines Arc

Attention : un point d’identité que je n’avais pas détaillé dans mon article de mai et que la documentation précise désormais : un session host Windows Server ne peut pas être en Entra Join pur, à cause de la dépendance au serveur de licences Bureau à distance. Il lui faut une jointure AD ou hybride. C’est seulement sur un Windows client, comme le Windows 11 de ce lab, que l’Entra Join seul est accepté.

Attention : un rappel qui vaut pour tous les hyperviseurs et que je répète ici parce qu’il coûte cher : l’identité doit être fixée avant l’enrôlement Arc. Si vous faites l’Entra Join après avoir posé l’agent, il faut désinstaller l’agent et recommencer. Sur une VM neuve, faites l’Entra Join d’abord, Arc ensuite, extension AVD en dernier.

4. Étape 1 : vérifier l’Entra Join du session host

Ma VM Windows 11 a été jointe au tenant pendant l’OOBE, avec l’option Set up for work or school. Si la vôtre est en compte local, faites-le maintenant par Paramètres, Comptes, Accès Professionnel ou Scolaire, puis Connecter et l’option de jointure à Microsoft Entra.

La vérification se fait en une commande, dans une invite en administrateur.

dsregcmd /status

Dans la section Device State, il faut lire AzureAdJoined : YES et DomainJoined : NO. C’est la signature d’un Entra Join pur :

Vérifiez au passage dans le centre d’administration Entra que l’appareil est bien apparu dans la liste, avec son nom d’hôte :

Mon retour terrain : c’est le scénario que je préférais déjà dans mon article AVD hybride, et Proxmox ne change rien à cette préférence. Pas de contrôleur de domaine à rendre joignable depuis le réseau interne de l’hyperviseur, pas de Kerberos, pas de GPO. Avec un bridge NAT comme le nôtre, où les invités sont derrière une translation d’adresses, c’est même un vrai confort : un DC aurait demandé du routage supplémentaire. Gardez juste en tête que ce raccourci n’est ouvert qu’aux Windows client, un Windows Server exigeant une jointure AD ou hybride.

5. Étape 2 : vérifier la sortie réseau du session host

C’est le seul point où la configuration Proxmox de notre lab demande une attention particulière. Les invités sont derrière le NAT nftables du nœud, et l’agent Arc comme les composants AVD ont besoin de sortir en TCP 443.

Un test simple depuis la VM Windows, en PowerShell.

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName management.azure.com -Port 443

Si ces tests échouent, reprenez la configuration réseau du premier article : le routage IPv4 activé, la règle de masquerade dans la table nat, et la chaîne forward qui accepte les flux de 10.10.10.0/24 vers eth0. Côté nœud, une vérification rapide.

sudo nft list ruleset
sysctl net.ipv4.ip_forward

Attention : l’agent Arc et AVD ont besoin d’un flux sortant uniquement. Vous n’avez rien à ouvrir en entrée sur le NSG Azure, et surtout pas de RDP : la connexion utilisateur passe par le service AVD via une passerelle inversée, pas par une exposition directe du port 3389. C’est l’un des vrais bénéfices de la mécanique, et il tombe particulièrement bien dans notre montage où les invités n’ont de toute façon aucune adresse publique.

6. Étape 3 : enregistrer les resource providers

Rien de spécifique à Proxmox ici, mais c’est le préalable à tout le reste. Sur l’abonnement cible.

'Microsoft.HybridCompute','Microsoft.HybridConnectivity','Microsoft.GuestConfiguration','Microsoft.DesktopVirtualization' |
  ForEach-Object { Register-AzResourceProvider -ProviderNamespace $_ }

N’oubliez pas Microsoft.HybridConnectivity, qui porte la connectivité via Arc. Son absence laisse l’enrôlement réussir tout en faisant échouer silencieusement des opérations plus loin.

7. Étape 4 : créer le host pool et son identité managée

Ici, deux choses ont bougé depuis mon article de mai, et la seconde est un vrai piège si vous travaillez de mémoire.

Le host pool, désormais standard

Au lancement de la préversion, seul un host pool marqué comme environnement de validation acceptait un session host hybride. Ce n’est plus ce que dit la documentation, qui demande simplement de créer un host pool ordinaire sans y ajouter de machines.

Follow the Deploy Azure Virtual Desktop instructions to deploy a standard host pool without adding session hosts. Do not add virtual machines to this host pool.
Source : Deploy Azure Virtual Desktop Hybrid, Microsoft Learn

Dans le portail, cherchez Azure Virtual Desktop, puis Host pools et Create.
Dans Basics, nommez le pool, choisissez la région des métadonnées et le type Pooled ou Personal.
Dans Virtual machines, choisissez No, I’ll add VMs later. La machine arrivera par Arc, pas par l’assistant.
Dans Workspace, créez ou rattachez un workspace, puis validez.
Dans Identity, assignez une identité managée. Ne sautez pas cet onglet, la suite en dépend.

L’identité managée et son rôle Reader

C’est la nouveauté qui coûte le plus cher à ignorer. L’identité managée du host pool doit disposer du rôle Reader sur le groupe de ressources qui contient vos machines Azure Arc. La documentation est explicite sur les conséquences.

If the managed identity doesn’t have Reader access to the Arc resource group, a future release will prevent session hosts from becoming available.
Source : Deploy Azure Virtual Desktop Hybrid, Microsoft Learn

Ouvrez le groupe de ressources qui contient vos serveurs Arc.
Allez dans Access control (IAM), puis Add et Add role assignment.
Cherchez Reader, sélectionnez-le, puis Next.
Dans Assign access to, choisissez Managed identity, puis Select members.
Choisissez votre abonnement, le type Host pool, sélectionnez l’identité de votre host pool, et validez.

Attention : cette exigence n’existait pas au lancement de la préversion et n’apparaît donc pas dans mon article de mai. Si vous rejouez une procédure notée il y a quelques mois, c’est très précisément l’étape qui vous manquera, avec un symptôme différé et peu explicite : un session host qui ne devient jamais disponible.

8. Étape 5 : enrôler la VM Proxmox dans Azure Arc

On y est. Dans le portail, allez dans Azure Arc, Machines, Add, puis Add a single server. Renseignez l’abonnement, le groupe de ressources et la région, et téléchargez le script PowerShell d’onboarding généré :

Ouvrez PowerShell ISE puis lancez la commande suivante :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

Collez le script d’Azure ARC dans la VM Windows 11 et exécutez-le. Il télécharge AzureConnectedMachineAgent.msi, l’installe, puis lance azcmagent connect avec les paramètres de votre tenant :

Une fenêtre d’authentification s’ouvre pour valider :

Au bout de deux à cinq minutes, la machine apparaît dans Azure Arc, Machines, avec le statut Connected :

Ouvrez la ressource et regardez ses propriétés. C’est l’écran le plus intéressant de tout l’article :

Mon retour terrain : vérifiez la valeur d’azcmagent plutôt que de vous fier au portail seul. Sur la machine, azcmagent show vous donne l’état de l’agent, le statut de la connexion et les endpoints atteints. C’est le premier endroit où regarder si quelque chose coince, et c’est beaucoup plus parlant qu’un statut dans une liste.

azcmagent show

9. Étape 6 : poser l’extension AVD

C’est l’extension Azure Arc qui installe les composants AVD sur la machine et l’enregistre auprès du host pool. La documentation précise au passage ce qu’elle fait selon le système : sur Windows Server, elle active le rôle Hôte de session Bureau à distance, et sur Windows 11, elle active la connexion en RDP.

Attention : sur un Windows Server, l’activation du rôle entraîne un redémarrage de la machine. La documentation conseille d’installer le rôle avant de déployer l’extension pour éviter un redémarrage au milieu de la configuration. Sur notre Windows 11, la question ne se pose pas.

Bonne nouvelle par rapport à mon article de mai : il existe maintenant un chemin portail, sans génération de clé d’enregistrement à la main.

Option 1 : depuis le portail

Dans le portail, cherchez Azure Arc, dépliez Infrastructure et sélectionnez Machines.
Cliquez sur le nom de votre machine, puis dans le menu de gauche dépliez Settings et choisissez Extensions.
Cliquez sur Add, sélectionnez l’extension Azure Virtual Desktop Hybrid, puis Next.
Choisissez l’abonnement, le groupe de ressources et le host pool auquel rattacher le session host.
Validez par Review + Create puis Create.

Option 2 : en PowerShell

Le chemin script reste parfaitement valable, et c’est celui qu’on garde pour industrialiser. Installez les modules, puis connectez-vous en fixant explicitement l’abonnement :

Install-Module -Name Az.DesktopVirtualization
Install-Module -Name Az.ConnectedMachine

Connect-AzAccount
Set-AzContext -Subscription '<SubscriptionId>'
Get-AzContext

Générez une clé d’enregistrement pour le host pool :

$HostPoolRG   = '<VotreResourceGroupHostPool>'
$HostPoolName = '<VotreHostPool>'

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString('yyyy-MM-ddTHH:mm:ss.fffffffZ')
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

Puis posez l’extension sur la machine Arc :

$settings          = @{ isCloudDevice = $false }
$protectedSettings = @{ registrationToken = $token }

$ResourceGroupName = '<VotreResourceGroupArc>'
$MachineName       = '<NomDeLaMachineDansArc>'
$Region            = '<RegionDuResourceGroupArc>'

New-AzConnectedMachineExtension `
    -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' `
    -ResourceGroupName $ResourceGroupName `
    -MachineName $MachineName `
    -Location $Region `
    -Publisher 'Microsoft.AzureVirtualDesktop' `
    -ExtensionType 'CloudDeviceExtension' `
    -Setting $settings `
    -ProtectedSetting $protectedSettings

isCloudDevice = $false est le drapeau qui indique le mode hybride. Sans lui, rien ne fonctionne.
MachineName est le nom de la ressource dans Azure Arc, pas forcément le nom d’hôte Windows brut.
Location est la région du groupe de ressources Arc, pas l’endroit où tourne physiquement la machine.
La clé d’enregistrement a une durée de vie limitée, générez-la juste avant de jouer le script.

Vérifier le résultat

Dans la vue Extensions de la machine Arc, la colonne de statut de Microsoft.AzureVirtualDesktop.CloudDeviceExtension doit afficher Succeeded.

Les différentes applications commencent à faire leur apparition dans le gestionnaire des programmes Windows :

Puis, dans le host pool, la machine apparaît dans la liste Session hosts avec le statut Available :

Mon retour terrain : ne paniquez pas si le session host n’apparaît pas immédiatement après le Succeeded de l’extension. La documentation annonce jusqu’à quinze minutes de délai entre les deux, et c’est exactement le genre d’attente pendant laquelle on relance inutilement un script qui avait très bien fonctionné.

Attention : si vous partez sur le chemin PowerShell et obtenez une erreur du type machine introuvable, vérifiez Get-AzContext. Avec plusieurs abonnements rattachés au compte, l’applet va chercher la ressource Arc au mauvais endroit et le message d’erreur n’aide pas beaucoup. C’est le piège sur lequel j’avais déjà perdu du temps lors de mes premiers tests.

10. Étape 7 : assigner les utilisateurs et se connecter

Dernière ligne droite. Ouvrez l’application group, allez dans Assignments et ajoutez l’utilisateur ou le groupe Entra qui doit pouvoir se connecter :

Puis, côté utilisateur, ouvrez la Windows App et connectez-vous avec ce compte. Le bureau publié par le host pool apparaît :

Cliquez, et le bureau s’ouvre :

Pour le plaisir de la démonstration, ouvrez côté Proxmox la console de la même VM et regardez les deux écrans côte à côte. C’est la capture que je trouve la plus parlante de tout ce lab : le même Windows, vu par son hyperviseur et vu par le service AVD :

11. Ce qui change vraiment avec Proxmox

Après ce test, la réponse honnête est : presque rien du côté d’AVD, et un peu plus du côté de l’exploitation.

Sujet	Sur Hyper-V ou vSphere	Sur Proxmox
Enrôlement Arc	Script d’onboarding standard	Identique, l’agent ignore l’hyperviseur
Extension AVD	Depuis le portail, ou `CloudDeviceExtension` en PowerShell	Identique
Identité	Entra Join ou jointure de domaine	Identique, Entra Join testé ici
Connexion utilisateur	Windows App	Identique
Support Microsoft	Hyperviseurs nommés dans l’annonce	Non nommé, couvert par la formulation générale de l’aperçu
Gestion de l’alimentation	Console de l’hyperviseur	Interface Proxmox ou `qm start` et `qm shutdown`
Arrêt propre du session host	Services d’intégration ou VMware Tools	QEMU guest agent, à installer
Provisionnement en série	Templates et outils partenaires	Modèles Proxmox, `qm clone`, éventuellement Terraform

Les deux dernières lignes sont les seules qui demandent un vrai effort d’adaptation, et elles découlent toutes les deux d’une limite de la préversion : AVD hybride ne pilote ni l’alimentation ni le cycle de vie des machines. Ce n’est pas propre à Proxmox, c’est documenté.

Azure Virtual Desktop Hybrid doesn’t provision or manage virtual machine state, so the following capabilities aren’t supported: Power management, Autoscale, Start VM on Connect, Session Host Configuration.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

Concrètement, si vous vouliez industrialiser, c’est du côté de Proxmox que se ferait le travail : un modèle de VM Windows préparé et généralisé, un clone par session host, et un script qui enchaîne l’enrôlement Arc et la pose de l’extension. La bonne nouvelle est que l’API de Proxmox se prête bien à l’exercice, la moins bonne est qu’aucun des partenaires cités au lancement de la préversion ne couvre Proxmox aujourd’hui.

Mon retour terrain : n’oubliez pas le QEMU guest agent sur vos session hosts, dont je parle dans le second article sur les pilotes VirtIO. Sans lui, l’ordre d’arrêt envoyé depuis Proxmox n’est pas relayé proprement au Windows, et vous finissez par couper l’alimentation d’une machine qui avait des sessions utilisateurs ouvertes. Sur un hôte AVD, c’est exactement ce qu’on ne veut pas.

12. Les pièges à retenir

Le piège	Le symptôme	La parade
Entra Join après l’enrôlement Arc	Session host qui ne s’enregistre pas correctement	Fixer l’identité avant de poser l’agent Arc, sinon désinstaller et recommencer
`Microsoft.HybridConnectivity` oublié	Enrôlement réussi mais échecs silencieux ensuite	Enregistrer les quatre resource providers avant de commencer
Identité managée sans rôle Reader	Session host qui ne devient jamais disponible	Assigner une identité managée au host pool et lui donner Reader sur le groupe de ressources Arc
Windows Server en Entra Join pur	Non supporté, dépendance au serveur de licences RDS	Jointure AD ou hybride pour un Windows Server, Entra Join réservé au client
Impatience après le Succeeded	On relance un script qui avait marché	Attendre jusqu’à quinze minutes avant de conclure à un échec
`isCloudDevice` absent ou à `$true`	L’extension se pose mais n’enregistre rien	Passer explicitement `isCloudDevice = $false`
Mauvais abonnement dans le contexte	Erreur de machine introuvable	Vérifier `Get-AzContext` après le `Set-AzContext`
Sortie 443 bloquée par le NAT	L’agent Arc n’arrive pas à se connecter	Vérifier la chaîne forward nftables et le routage IPv4 sur le nœud
Windows 11 multi-session	Non éligible hors Azure	Mono-session, ou Windows Server avec le rôle RDS
Pas de guest agent sur le session host	Arrêts brutaux depuis Proxmox	Installer le QEMU guest agent sur chaque session host
Clé d’enregistrement expirée	L’extension échoue à enregistrer la machine	Générer le token juste avant de lancer le script

Conclusion

Voilà, en sept étapes, une machine Windows 11 qui tourne dans Proxmox et qui se comporte comme un session host Azure Virtual Desktop à part entière, avec sa Windows App, son identité Entra et son host pool dans le portail.

Concrètement, ça donne quoi ? Ça confirme ce que je pressentais en écrivant mon article sur AVD hybride : la mécanique ne s’intéresse pas à votre hyperviseur. Azure Arc parle à un Windows, l’extension AVD parle à Azure Arc, et ce qu’il y a en dessous est votre affaire. Microsoft a nommé quatre plateformes dans son annonce, mais la formulation de l’aperçu est délibérément plus large, et le test le vérifie.

Les trois points que je retiens : la procédure est strictement celle des autres hyperviseurs, sans le moindre ajustement ; l’Entra Join pur reste le chemin le plus court, surtout derrière un réseau NAT où un contrôleur de domaine aurait compliqué les choses ; et l’absence de gestion d’alimentation, qui est une limite de la préversion et pas de Proxmox, est ce qui demanderait le plus de travail si on voulait industrialiser.

Foncez tester, et dites-moi en commentaire si vous l’avez fait sur un hyperviseur encore différent. La dernière fois que j’ai posé la question, personne n’avait essayé Proxmox, alors j’ai fini par m’en charger.

🤖

Contenu assisté par IA Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.

Entra Passkey sous Windows

Microsoft a enfin fait passer les Microsoft Entra passkeys on Windows en General Availability fin avril 2026. Concrètement, ça veut dire qu’on peut maintenant enregistrer des passkeys FIDO2 directement dans le conteneur Windows Hello et s’authentifier à Entra ID en passwordless. Cela fonctionne que le PC soit Entra-joined, registered, ou rien !

Personnel, partagé, BYOD, peu importe. Avec le rollout en cours jusqu’à mi-juin 2026, c’est le bon moment pour tester en lab avant que la migration auto vers les passkey profiles ne tombe sur votre tenant.

Dans cet article, on va voir comment configurer ça côté tenant (avec un focus sur la distinction entre l’ancienne UI Passkey (FIDO2) settings et la nouvelle expérience Passkey profiles), comment l’utilisateur enregistre sa passkey côté poste.

Au programme

Un peu d’histoire …
Entra passkey on Windows : c’est quoi exactement ?
Pré-requis tenant, poste et utilisateur
Ancienne UI : configuration via « Passkey (FIDO2) settings »
Nouvelle UI : configuration via « Passkey profiles »
Côté utilisateur : enregistrer sa première passkey Windows Hello
Le piège du Enforce attestation
Retex : les erreurs qu’on a croisées en lab

0. Un peu d’histoire …

Au début, l’authentification sur les environnements Microsoft reposait presque exclusivement sur le mot de passe. Un simple login + password suffisait pour accéder aux ressources d’entreprise, aussi bien on-premises que cloud.

Rapidement, les limites de ce modèle sont devenues évidentes :

mots de passe faibles
réutilisation entre services
phishing
fuites de credentials
attaques par bruteforce

Pour renforcer la sécurité, le MFA est alors devenu la norme. La première vague de MFA a surtout reposé sur les SMS, les appels téléphoniques ou les codes OTP. Cela améliorait clairement la sécurité, mais avec plusieurs problèmes :

fatigue utilisateur
dépendance au réseau mobile
vulnérabilités SIM swap
expérience parfois lourde

Ensuite sont arrivées les applications d’authentification comme Microsoft Authenticator, avec les notifications push, le number matching ou les OTP locaux.

L’expérience devenait plus fluide, mais on restait encore dans un modèle “mot de passe + validation secondaire”. Puis Microsoft a commencé à pousser fortement le passwordless avec :

Windows Hello for Business
les clés FIDO2 comme YubiKey

Cette fois, l’objectif était clair : supprimer complètement le mot de passe. Le problème, c’est que ces solutions restaient souvent liées à un device d’entreprise, à un PC Entra joined, ou à une clé hardware dédiée.

Les environnements BYOD, postes partagés ou machines temporaires restaient donc compliqués à gérer proprement en passwordless. Puis sont arrivées les passkeys synchronisées sur mobile :

iPhone via iCloud Keychain
Android via Google Password Manager
Microsoft Authenticator

Et c’est là qu’apparaît aujourd’hui “Entra passkey on Windows”. Le principe change beaucoup de choses : le PC Windows peut désormais héberger lui-même une passkey FIDO2 sans avoir à être joint au tenant.

1. Entra passkey on Windows : c’est quoi exactement ?

Pour rappel, jusqu’ici, si vous vouliez du passwordless FIDO2 sur Entra ID, il fallait soit une clé hardware type YubiKey, soit Windows Hello for Business (qui exige un device Entra-joined ou registered).

Les PC perso ou partagés étaient alors condamnés au mot de passe + MFA classique.

Avec Entra passkey on Windows, Microsoft permet désormais de créer une passkey FIDO2 directement dans le conteneur Windows Hello local, sans que le device soit joint au tenant. La passkey est device-bound (elle ne quitte jamais le poste), stockée dans le TPM, et débloquée par PIN, empreinte ou reconnaissance faciale.

Plusieurs passkeys peuvent cohabiter pour plusieurs comptes Entra sur le même PC.

Attention, le piège classique : ne confondez pas Entra passkey on Windows avec Windows Hello for Business.

Les deux utilisent Windows Hello, mais ce sont deux mécanismes distincts. Voici le tableau qui devrait vous éviter de mélanger les deux en réunion :

Critère	Entra passkey on Windows	Windows Hello for Business
Standard	FIDO2	Protocole 1P Microsoft (pas FIDO2)
Device join requis	Non	Oui (Entra-joined ou registered)
Sign-in OS Windows	Non	Oui
SSO Entra après login	Non	Oui
Provisionnement	User-initiated	Auto au device registration
Plusieurs comptes / device	Oui	Non (1 device = 1 compte)
Pilotage	Authentication Methods + passkey profiles	Intune / GPO

En clair : sur un device managé Entra-joined, gardez Windows Hello for Business. Sur un poste non-joined, perso ou partagé, Entra passkey on Windows est ce qu’il vous faut.

2. Pré-requis tenant, poste et utilisateur

Avant de vous lancer dans la conf, vérifiez que vous cochez tout ça :

Périmètre	Pré-requis
Tenant	Microsoft Entra ID (toute édition). Authentication Policy Admin ou Global Admin pour configurer.
Tenant	Méthode Passkey (FIDO2) activée dans Authentication methods.
Tenant	Conditional Access qui n’exige pas un device compliant ou Entra-joined sur le flux d’enregistrement.
Poste	Windows 11 24H2 minimum (build 26100+). Le provider passkey natif n’existe pas sur 23H2 ou Windows 10.
Poste	Edge ou Chrome à jour (≥ version 124).
Poste	TPM 2.0 opérationnel (`tpm.msc` doit afficher « prêt »).
Poste	Windows Hello configuré : PIN obligatoire, biométrie recommandée.
User	Une MFA réussie dans les 5 dernières minutes avant de cliquer « Add » sur la passkey.

Attention : sans Windows 11 24H2, le flux WebAuthn ne propose pas Windows Hello comme provider de passkey, et vous retombez sur l’ancien flux « Security key » qui demande un device externe (YubiKey, smartphone). C’est la cause numéro 1 d’enregistrements qui échouent.

3. Ancienne UI : configuration via « Passkey (FIDO2) settings »

Si vous n’avez pas encore migré vers la nouvelle expérience, vous êtes encore sur la vue legacy Passkey (FIDO2) settings. Vous la reconnaissez à un bandeau bleu en haut : « Synced passkeys and passkey profiles are now available. Upgrade to the new experience » :

Tant que vous n’avez pas cliqué sur ce lien, vous restez sur l’ancien modèle, et il fonctionne très bien pour Entra passkey on Windows, à condition de bien renseigner manuellement les AAGUIDs :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 0 : Connectez-vous au Microsoft Entra admin center, allez dans Protection → Authentication methods → Policies → Passkey (FIDO2) :

Étape 1 : Onglet Enable and Target : activez la méthode et scopez les utilisateurs concernés (un groupe pilote pour démarrer, c’est plus sain).

Étape 2 : Onglet Configure, dans la section General :

Allow self-service set up : Yes
Enforce attestation : No (j’insiste, on en reparle plus bas)

Étape 3 : Section Key Restriction Policy :

Enforce key restrictions : Yes
Restrict specific keys : Allow

Cliquez sur Add AAGUID et ajoutez les 3 AAGUIDs Windows Hello :

AAGUID	Authenticator
`08987058-cadc-4b81-b6e1-30de50dcbe96`	Windows Hello Hardware Authenticator (TPM matériel)
`9ddd1817-af5a-4672-a2b9-3e3dd95000a9`	Windows Hello VBS Hardware Authenticator (VBS + TPM)
`6028b017-b1d4-4c02-b4b3-afcdafc96bb2`	Windows Hello Software Authenticator (TPM logiciel)

Vous pouvez aussi ajouter les AAGUIDs Microsoft Authenticator si vous voulez autoriser les passkeys via l’app mobile :

90a3ccdf-635c-4729-a248-9b709135078f : Microsoft Authenticator Android
de1e552d-db1d-4423-a619-566b625cdc84 : Microsoft Authenticator Apple

Étape 4 : Cliquez sur Save en bas. Et c’est tout pour l’ancienne UI.

4. Nouvelle UI : configuration via « Passkey profiles »

Microsoft a introduit en mars 2026 le modèle des passkey profiles, qui remplace progressivement l’ancienne config FIDO2. L’idée : pouvoir définir plusieurs profils (jusqu’à 3 par tenant) avec des règles différentes selon les groupes :

Par exemple un profil avec attestation enforced pour les admins (YubiKey obligatoire), et un autre sans pour les utilisateurs standards (Windows Hello autorisé).

L’auto-enablement de la nouvelle UI court d’avril à fin mai 2026 sur les tenants. Donc même si vous ne faites rien, Microsoft va finir par migrer votre tenant. Mon conseil : faites la bascule volontairement, comme ça vous maitrisez le moment et ce qui change.

Étape 0 : Toujours dans Authentication methods → Passkey (FIDO2), cliquez sur le lien « Upgrade to the new experience » dans le bandeau bleu.

Étape 1 : Microsoft migre votre conf existante dans un Default passkey profile. Vos AAGUIDs et restrictions actuels sont préservés. Le passkeyType du profil est déterminé par votre réglage d’attestation :

Enforce attestation	Types autorisés par défaut
Enabled	Device-bound uniquement
Disabled	Device-bound + Synced (configurable)

Attention : si vous aviez Enforce attestation = No, l’upgrade activera aussi les synced passkeys par défaut (iCloud Keychain, Google Password Manager). Si vous ne voulez pas ça pour des raisons de gouvernance (clés hors du périmètre maitrisé), repassez le profil sur « Device-bound only » juste après l’upgrade.

Étape 2 : Cliquez sur le Default passkey profile pour l’éditer. Le panneau latéral s’ouvre avec :

Name : Default passkey profile (verrouillé, on ne peut pas le supprimer ni le renommer)
Enforce attestation : décoché
Passkey types : Device-bound, Synced (ajustez si besoin)
Target specific AAGUIDs : à cocher si vous voulez forcer une allow-list explicite

Étape 3 : En théorie, depuis la GA de fin avril 2026, Microsoft a supprimé l’obligation d’allow-lister les AAGUIDs Windows Hello. Donc si votre tenant a bien reçu la bascule, vous n’avez rien d’autre à faire.

En pratique pendant le rollout (qui finit mi-juin 2026), le tenant peut ne pas encore avoir basculé. Si l’enregistrement échoue côté utilisateur sans raison apparente, cochez Target specific et ajoutez les 3 AAGUIDs Windows Hello. C’est le contournement que j’ai dû appliquer en lab en mai 2026 :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 4 : Save. Vous pouvez créer jusqu’à 3 profils différents et les assigner à des groupes différents via l’onglet Enable and target.

5. Côté utilisateur : enregistrer sa première passkey Windows Hello

Maintenant qu’on est bon côté tenant, voyons l’expérience utilisateur. Le poste doit être en Windows 11 24H2, avec PIN Hello configuré et Edge à jour. C’est important.

Étape 0 : L’utilisateur ouvre Edge en session normale, et fait une MFA fraîche sur My Sign-Ins | Security Info | Microsoft.com → Add sign-in method → choisissez Passkey dans la liste :

Attention : ne sélectionnez pas « Security key » ou « USB security key » si vous avez ces options. C’est l’ancien flux FIDO2 qui ne déclenche pas le provider Windows Hello. Le bon choix est « Passkey », qui appelle le picker WebAuthn de l’OS et propose Windows Hello comme provider.

Étape 1 : Windows ouvre une fenêtre qui demande où enregistrer la passkey. Choisissez « This Windows device » (ou « Windows Hello » selon la version d’Edge).

Étape 2 : Le prompt Windows Hello apparaît. Authentifiez-vous avec visage, empreinte ou PIN Hello.

Étape 3 : Donnez un nom à la passkey (ex : « Laptop perso », « PC bureau »). Validez.

C’est bien enregistré sur votre compte :

Mais aussi sur votre poste :

Concrètement, ça donne quoi à la prochaine connexion ? L’utilisateur tape son email sur la page de login Microsoft, le navigateur propose la passkey du device, Windows Hello se déclenche (visage / PIN) et il est connecté. Plus de mot de passe, plus de SMS, plus de prompt MFA séparé. Le rêve.

6. Le piège du Enforce attestation

C’est LE piège qui m’a fait perdre du temps en lab et que vous allez forcément rencontrer si vous avez le réflexe sécu de tout durcir :

Le réglage Enforce attestation dans le profil passkey demande à l’authentificateur de fournir une preuve cryptographique signée par le constructeur, garantissant qu’il s’agit bien d’un device authentique (typiquement une YubiKey certifiée FIDO). Sur le papier, c’est une bonne pratique sécu.

Le problème : Windows Hello ne fournit pas encore d’attestation reconnue par Entra. Microsoft le dit explicitement dans la doc :

À noter : la doc MS Learn parle encore de public preview à la date de rédaction, mais la limite est confirmée post-GA :

Attestation isn’t supported for Microsoft Entra passkey on Windows during public preview. As a result, if Enforce attestation is enabled in a passkey profile that allows Windows Hello AAGUIDs, passkey registration attempts to Windows Hello will fail.

In the Authentication methods policy in the Microsoft Entra admin center, ensure that Enforce attestation is set to No for any passkey profile that includes Windows Hello AAGUIDs during public preview.
Enable Microsoft Entra passkey on Windows — Microsoft Learn

Concrètement, si vous cochez Enforce attestation = Yes sur un profil qui scope des utilisateurs sur Windows Hello, l’enregistrement échoue à la dernière étape (juste au moment où l’utilisateur nomme la passkey).

Côté serveur Entra, la requête est rejetée parce que la « preuve » attendue n’arrive pas :

Le piège classique : vous activez Enforce attestation en pensant durcir la conf, et vous cassez tout l’enregistrement Windows Hello sans message d’erreur clair. Vos utilisateurs vous appellent en disant « ça marche pas », et vous galérez à comprendre pourquoi parce que la conf semble propre.

La solution propre : deux profils séparés

Profil « YubiKey / clés certifiées » : Enforce attestation = Yes, scopé aux admins / users à fort privilège. AAGUIDs des modèles YubiKey autorisés en allow-list.
Profil « Windows Hello » : Enforce attestation = No, scopé aux utilisateurs standards. Allow-list avec les 3 AAGUIDs Windows Hello.

C’est exactement ce que la nouvelle UI passkey profiles permet de faire (jusqu’à 3 profils par tenant). Sur l’ancienne UI, vous étiez obligé de choisir un seul réglage tenant-wide, d’où l’intérêt de migrer si vous avez des cas d’usage mixtes.

Mon retour terrain : pour le moment, sur les Windows Hello passkeys, on accepte de se passer d’attestation. Le risque est limité parce que les credentials sont stockés dans le TPM et device-bound. Le jour où Microsoft livrera l’attestation Windows Hello, on rebascule. Pour les YubiKeys, l’attestation reste obligatoire.

7. Retex : les erreurs qu’on a croisées en lab

Pour finir, le vrai retour de tests, parce que la doc Microsoft ne couvre pas les cas où ça part en sucette. Voici les deux erreurs principales rencontrées en lab et comment les diagnostiquer.

Erreur 1 : « We’re sorry, we ran into a problem »

Message qui apparait juste à l’étape Name your security key, après que la clé ait été reconnue. Avec un Correlation ID dans les détails. Frustrant parce que tout semble fonctionner jusqu’à la dernière seconde.

Cause la plus fréquente : vous êtes sur le mauvais flux. Vous avez cliqué sur « Security key » au lieu de « Passkey » dans Add sign-in method. Le flux Security key n’utilise pas Windows Hello comme provider et tente de s’enregistrer comme une clé externe, d’où le crash final.

Erreur 2 : « Passkey not registered »

Message qui apparait sur le bon flux (Passkey, pas Security key), avec le texte « This might be due to a timeout, a canceled request or a private browsing window ». Le message officiel suggère timeout / cancel / private mode, mais en pratique la cause est ailleurs.

De mon côté, je n’ai eu aucun souci en navigation privée :

Cause #1 : Windows Hello pas configuré. Vérifiez Paramètres → Comptes → Options de connexion → Code PIN (Windows Hello). Sans PIN Hello, le provider n’a rien à appeler.

Cause #2 : rollout GA pas encore activé sur votre tenant. C’est la cause que j’ai rencontrée. Microsoft a annoncé que la GA enlève l’obligation d’allow-lister les AAGUIDs Windows Hello, mais cette bascule se déploie progressivement jusqu’à mi-juin 2026. Si votre tenant n’a pas encore reçu la modification, l’enregistrement échoue silencieusement.

Fix : dans le passkey profile, cochez Target specific AAGUIDs et ajoutez explicitement les 3 AAGUIDs Windows Hello. Save, retentez. Ça contourne le délai de rollout.

Cause #3 : Windows trop vieux. Sur 23H2 ou Windows 10, le picker n’affiche pas « This Windows device » dans la liste des providers. Vous voyez seulement « iPhone/Android » et « Security key ». Pas de chemin valide pour Windows Hello passkey.

Fix : passez en 24H2.

Cause #4 : Enforce attestation = Yes sur un profil scopant Windows Hello (cf. section précédente).

Fix : vérifiez que Enforce attestation est bien à No.

Conclusion

Entra passkey on Windows comble enfin un trou dans la stratégie passwordless de Microsoft : les PC non-managés peuvent désormais s’authentifier en FIDO2 sans avoir à sortir une YubiKey ni à passer par le téléphone. Pour les contractors, les postes partagés, les BYOD, c’est une vraie avancée.

Les pièges principaux à retenir :

Windows 11 24H2 minimum côté poste, sinon vous restez bloqué sur l’ancien flux Security key
Choisir « Passkey » et pas « Security key » dans Add sign-in method
Ne pas cocher Enforce attestation sur le profil qui scope Windows Hello
Pendant le rollout GA (avril → mi-juin 2026), allow-lister explicitement les 3 AAGUIDs Windows Hello si l’enregistrement échoue
Migrer volontairement vers les passkey profiles avant l’auto-enablement de fin mai 2026

Foncez tester en lab avec un compte de test, validez le flux, puis pilotez le déploiement sur un groupe pilote avant d’ouvrir vanne large. Et surtout, anticipez la migration auto vers les passkey profiles qui tombe entre maintenant et fin mai — autant maitriser le moment plutôt que le subir.

Enfin, pour aller plus loin :

À tester d’urgence en lab !

Entra ID Account Recovery

La perte totale d’accès à un compte Microsoft Entra ID reste l’un des scénarios les plus critiques en matière d’identité : plus de mot de passe, plus de MFA, plus de clés physiques. Historiquement, ce type de situation reposait sur des procédures manuelles, souvent longues, impliquant les équipes IT internes, voire le support Microsoft pour les comptes à privilèges élevés. Lors de Microsoft Ignite 2025, Microsoft a officiellement mis en avant Entra ID Account Recovery comme une réponse structurante à ce problème historique, en l’inscrivant clairement dans sa vision Zero Trust et Identity-first.

Avec Entra ID Account Recovery, Microsoft introduit une nouvelle approche : une récupération de compte en libre-service, basée non plus sur des facteurs préenregistrés, mais sur une vérification d’identité à haute assurance, intégrée nativement à l’écosystème Entra via Verified ID et Face Check.

Comment faisait-on auparavant en cas de blocage total d’un compte ?

Avant l’arrivée d’Entra ID Account Recovery, la gestion d’un blocage total de compte dépendait fortement du type d’utilisateur concerné :

Pour un utilisateur standard, la récupération passait généralement par les équipes de support IT internes. Ces équipes procédaient à des actions manuelles (réinitialisation, suppression/recréation de méthodes d’authentification, Temporary Access Pass, etc.), après avoir vérifié l’identité de l’utilisateur selon les processus internes de l’organisation.

Pour un utilisateur à privilèges élevés, et en particulier un administrateur général, la situation était plus complexe. En cas de perte totale des moyens d’authentification, il était souvent nécessaire de contacter le Microsoft Data Protection Team via un ticket de support Microsoft.

Cette distinction rendait la récupération :

relativement gérable pour les utilisateurs standards,
mais particulièrement contraignante et chronophage pour les comptes administrateurs, avec un fort impact opérationnel.

Qu’est-ce qu’Entra ID Account Recovery ?

Entra ID Account Recovery est une solution de récupération d’accès, conçue pour les scénarios où toutes les méthodes de connexion sont perdues.

Plutôt que de simplement réinitialiser un mot de passe, elle repose sur une vérification d’identité à haute assurance pour prouver qui est l’utilisateur avant de lui permettre de rétablir ses méthodes d’authentification.

Microsoft Entra ID Account Recovery traite ces scénarios critiques en permettant aux utilisateurs de récupérer l’accès à leurs comptes via un processus de vérification d’identité robuste.

Microsoft Learn

Contrairement à la réinitialisation de mot de passe, qui suppose que les utilisateurs conservent une certaine forme de méthode d’authentification, la récupération de compte se concentre sur la recréation de l’approbation dans l’identité de l’utilisateur lorsqu’il a perdu l’accès à tous les mécanismes d’authentification.

Microsoft Learn

Entra ID Account Recovery vs réinitialisation de mot de passe en libre-service (SSPR)

Voici une comparaison proposée par Microsoft entre la récupération de compte et la réinitialisation de mot de passe en libre-service (SSPR) :

Aspect	Réinitialisation du mot de passe libre-service (SSPR)	Récupération de compte (Entra ID Account recovery)
Cas d’usage principal	Mot de passe oublié par l’utilisateur, mais conserve l’accès aux méthodes d’authentification	L’utilisateur a perdu l’accès à toutes les méthodes d’authentification
Exigence d’authentification	Au moins une méthode d’authentification inscrite (les contrôles de stratégie peuvent nécessiter jusqu’à 2 méthodes)	Vérification d’identité par le biais d’un partenaire certifié
Hypothèse de confiance	L’identité de l’utilisateur est vérifiée par le biais de méthodes existantes	L’identité de l’utilisateur doit être rétablie
Étendue de récupération	Mot de passe uniquement	Réinitialisation complète de la méthode d’authentification
Dépendance technologique	Méthodes MFA existantes, questions de sécurité	Services de vérification d’identité, ID vérifié
Niveau de sécurité	Moyen – s’appuie sur des méthodes préinscrites	Élevé : nécessite une vérification complète des identités

Quels sont les prérequis ?

Voici les prérequis connus pour utiliser Entra ID Account Recovery dans Microsoft Entra ID, toujours en préversion à l’heure où ces lignes sont écrites :

Licence Microsoft Entra ID P1 pour la récupération du compte
Avoir activé Verified ID et Face Check

Concernant le second point, plusieurs articles présents sur mon blog avaient déjà été écrits sur le sujet :

Quels sont les fournisseurs IDV disponibles ?

Voici une liste de fournisseurs d’Identity Verification Providers (IDV) actuellement disponible avec Microsoft Entra ID Account Recovery, dont les souscriptions sont accessibles via le Microsoft Security Store :

Combien coûte le processus de récupération Entra ID Account Recovery ?

Plusieurs éléments de coût sont à prendre en compte pour comprendre le prix d’Entra ID Account Recovery :

Le coût de la licence Microsoft Entra ID P1,
Le coût du fournisseur de vérification d’identité externe (voir plus bas),
Le coût d’Entra Verified ID via Face Check ($0.25 par vérification).

Voici le détail des coûts affichés pour chacun des trois fournisseurs IDV :

TrueCredential :

Modèle de tarification à la transaction (PAYG)
Pas de coût fixe mensuel
Facturation purement à l’usage
Support optionnel
Disponible en essai gratuit :
- 100 Issuances de Verified ID
- 100 Présentations de Verified ID
- Identity proofing inclus (LexisNexis IDVerse)

Tarifs après l’essai :

Action	Prix
Issuance (émission d’un Verified ID)	1,00 $ / transaction
Presentation (présentation du Verified ID)	1,00 $ / transaction

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

1 issuance (nouvelle identité vérifiée)
1 présentation (preuve lors de l’accès)

AU10TIX

Tarification par utilisateur (paiement unique)
Essai gratuit un mois
- Coût : 0 $ le premier mois
- Jusqu’à 100 Verified IDs émis
- Jusqu’à 10 présentations par utilisateur
- Détection de fraude temps réel incluse

Tarifs après l’essai :

Volume	Prix
1 → 1 000 000 utilisateurs	2,00 $ par utilisateur (paiement unique)
Présentations incluses	Jusqu’à 10 par utilisateur
Durée	1 an

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

Le coût est indépendant du nombre de récupérations, tant que l’utilisateur reste dans son quota de présentations.

IDEMIA

Modèle de tarification à la transaction (PAYG)
Essai gratuit
- Coût : 0 $
- 100 Vérifications d’identité réussies
- 100 Vérifications d’identité échouées
- 100 Présentation de VC

Tarifs après l’essai :

Action	Prix
Vérification ID réussie	1,00 $
Vérification ID échouée	1,00 $
Présentation de VC	1,00 $

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

1 tentative =
- 1 vérification (succès ou échec)
- 1 présentation ≈
  - 2 $ minimum, 3 $ si échec + nouvelle tentative

Ce qui nous amène aux coûts suivants quand Entra ID Account Recovery rentre en production :

Fournisseur	Modèle	Coût typique par récupération	Risque coût
TrueCredential	Transaction	~2 $	Faible
AU10TIX	Par utilisateur	~2 $ / an	Très prévisible
IDEMIA	Transaction	2–3 $	Échecs facturés

Microsoft met également à disposition un calculateur accessible depuis le portail Entra :

Les demandes de récupération de compte concernent généralement environ 1 à 3 % des utilisateurs chaque mois. Le calculateur compare vos dépenses actuelles aux coûts de récupération en libre-service prévus, ce qui vous permet de modéliser facilement les économies pour votre scénario.

Microsoft Learn

Account Recovery – Deux modes disponibles :

Voici la comparaison des modes Évaluation et Production pour Account Recovery dans Microsoft Entra :

Critère	Évaluation	Production
Objectif	Tester la vérification d’identité	Permettre la récupération réelle du compte
Abonnement IDV requis	Oui	Oui
Vérification d’identité	Face check	Face check
Récupération du compte	❌ Non	✅ Oui
Accès utilisateur restauré	❌ Non	✅ Oui
Temporary Access Pass	❌ Non	✅ Oui
Ré-enrôlement MFA	❌ Non	✅ Oui
Impact sur le compte	Aucun	Compte récupéré
Usage recommandé	Tests, POC, validation sécurité	Production, utilisateurs autorisés
Population cible	Équipe IT / sécurité	Groupes restreints d’utilisateurs
Cas d’usage	Validation du fournisseur IDV	Perte totale des facteurs

Comme Entra ID Account Recovery se trouve toujours en préversion, je vous propose au travers de cet article de tester la solution en l’activant sur un tenant de test dans le mode Évaluation.

En mode Évaluation, les utilisateurs peuvent uniquement tester le processus de vérification d’identité sans récupérer réellement leurs comptes :

Avant de mettre en place la solution, certains composants sont nécessaires en tant que prérequis.

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants prérequis à la mise en place de Entra ID Account Recovery.

Configuration d’Entra Verified ID :

Configuration d’Entra Face Check :

Achat de licences Microsoft Entra ID P1/P2 :

Commençons par activer Entra ID Account Recovery depuis le portail du même nom.

Etape I – Activation d’Entra ID Account Recovery :

Microsoft documente la procédure de façon très claire juste ici.

Pour cela, connectez-vous au centre d’administration Microsoft Entra au moins en tant qu’administrateur d’authentification, puis cliquez ici pour démarrer le processus :

Sous Choisir un mode de récupération, sélectionnez Évaluation :

Sous Sélection du groupe d’utilisateurs, cliquez sur Sélectionner des groupes, choisissez les groupes que vous souhaitez inclure pour la récupération de compte, puis cliquez sur Suivant :

Sous Fournisseurs de vérification d’identité, choisissez un fournisseur, puis sélectionnez Obtenir la solution :

Connectez-vous au Microsoft Security Store :

Dans la page de votre fournisseur de vérification d’identité, sélectionnez Obtenir la solution :

Sélectionnez un abonnement Azure, un groupe de ressources, puis saisissez un nom de ressource :

Cliquez ici pour choisir le plan tarifaire :

Sélectionnez un plan tarifaire :

Définissez le nombre d’utilisateurs ainsi que la fonction d’auto-renouvellement, puis cliquez sur Suivant :

Confirmez les détails, puis sélectionnez Passer la commande :

Attendez quelques minutes que le processus d’achat se termine :

Entre-temps, constatez la génération d’une ressource sur le portail Azure :

Lorsque votre abonnement SaaS est prêt, sélectionnez Configurer le compte maintenant :

Acceptez la demande de permissions de votre fournisseur de vérification d’identité :

Dans la page Général de l’abonnement SaaS, fournissez les détails requis demandés par le fournisseur SaaS (par exemple, le nom du contact, l’e-mail et le numéro de téléphone), puis sélectionnez Souscrire :

Attendez quelques minutes la fin du traitement :

Quelques minutes plus tard, recevez le mail suivant vous confirmant que la souscription SaaS est bien activée :

Une fois le processus d’achat terminé, revenez au processus de configuration de la récupération de compte dans le Centre d’administration Microsoft Entra pour effectuer les étapes restantes.

Revenez au menu fournisseur de vérification d’identité dans le processus de configuration de la récupération de compte, puis sélectionnez Sélectionner :

Le message en vert ci-dessous vous indique que le provisionnement de l’étape précédente s’est correctement terminé, puis cliquez sur Suivant :

Dans la page Révision et finalisation , passez en revue les détails de la configuration de récupération de compte, puis sélectionnez Terminé :

Une fois l’installation terminée, la page d’accueil de récupération de compte s’ouvre dans le Centre d’administration Microsoft Entra :

Une fois l’installation terminée, tous les utilisateurs limités à la récupération de compte peuvent essayer la récupération et terminer la vérification de l’identité. Mais ils ne peuvent pas récupérer leurs comptes, car la récupération est définie en mode d’évaluation.

Etape II – Préparation du compte utilisateur de test :

Dans sa version actuelle, la vérification repose uniquement sur les deux champs suivants :

Afin de tester facilement la solution, créez un utilisateur ayant ces deux attributs :

Vérifiez que la propriété First Name et la propriété Last Name sont renseignées. S’ils sont vides, il n’existe aucun moyen pour Microsoft Entra ID Account Recovery de correspondre aux valeurs de revendications d’ID retournées par le fournisseur de vérification d’identité.

Souvent, le vrai nom d’un utilisateur sur son ID de gouvernement ne correspond pas à ce qui est répertorié pour son compte d’utilisateur dans l’ID Microsoft Entra.

Le nom complet n’est pas utilisé dans le processus de récupération du compte ; seules les propriétés Prénom et Nom sont utilisées.

Microsoft Learn

Configurez-lui une ou des méthodes MFA ou passkey :

Déconnectez-vous de votre utilisateur.

Notre utilisateur de test est maintenant correctement configuré. Imaginons que ce dernier a perdu son mot de passe, son smartphone, mais également sa clef FIDO.

Nous allons maintenant tester le processus de récupération de compte afin de comprendre comment les utilisateurs peuvent récupérer leurs comptes en quelques étapes simples.

Etape III – Test de récupération de compte :

Microsoft documente la procédure de façon très claire juste ici.

Ouvrez un navigateur privé, puis rendez-vous sur la page suivante, saisissez votre nom de compte, puis cliquez sur Suivant :

Il vous est proposé une méthode d’authentification initiale, comme le mot de passe, pour vous connecter. Comme vous ne parvenez pas à utiliser cette méthode, sélectionnez d’autres façons de vous connecter. Vous disposez d’options de connexion supplémentaires.

Comme vous ne parvenez pas à vous connecter avec des méthodes, cliquez sur Récupérer votre compte :

Cliquez sur Suivant afin d’être redirigé vers le service de vérification des identités configuré par votre organisation :

Démarrez le processus en cliquant ici :

Basculez sur votre smartphone ou continuez sur votre poste :

Autorisez votre navigateur internet à utiliser votre caméra, puis cliquez sur Continuer :

Acceptez les conditions d’utilisation de l’application :

Passez en revue comment prendre une photo de document claire, puis sélectionnez Continuer :

Prenez la photo recto et/ou verso de votre document d’identité (carte d’identité, passeport, permis de conduire, permis de travail), puis sélectionnez Envoyer les photos :

Attendez la confirmation de la part de l’application sur la qualité de votre photo :

Passez en revue comment prendre une photo claire de votre visage, puis sélectionnez Continuer :

Réalisez une photo de vous :

L’application vérifie votre identité, deux résultats sont alors possibles :

Vérification échouée : l’application vous informe de l’échec de l’opération sans plus de détail :

Dans la vidéo de John Savill, nous avons pu voir une copie d’écran de la partie backend de l’application AU10TIX :

Vérification réussie : l’application émet des justificatifs vérifiables (Verified ID) à sauvegarder dans votre application Microsoft Authenticator. Ouvrez Microsoft Authenticator, puis scannez le QR Code ci-dessous :

Effectuez une vérification du visage avant que la propriété de votre compte puisse être validée :

Une fois l’identité vérifiée présente dans votre Microsoft Authenticator, cliquez sur Partager afin de l’utiliser dans le processus de récupération de compte :

Une fois terminé, vous obtenez un pass d’accès temporaire, copiez ce code :

Comme le montre la capture d’écran ci-dessus, aucun TAP n’est visible dans le mode Évaluation, le message d’erreur suivant apparaît d’ailleurs systématiquement :

Mais la suite de la procédure devrait ressembler à cela :

Microsoft a déjà écrit une aide au Troubleshooting pour les utilisateurs juste ici :

L’utilisateur ne peut pas récupérer son compte en mode Évaluation
L’utilisateur n’a pas reçu de TAP
L’utilisateur peut ne pas voir l’option Récupérer votre compte
L’utilisateur peut obtenir une erreur indiquant que les demandes ne peuvent pas être traitées au début de la récupération.
Erreurs du fournisseur de vérification d’identité.
Erreurs lors de la vérification faciale.
Problèmes liés au code d’accès temporaire après la vérification d’identité.
Clé d’accès non émise.

Enfin, des événements sont inscrits dans les journaux d’audit d’Entra ID pour retracer toutes ces opérations de récupération de compte :

Conclusion

Avec Entra ID Account Recovery, Microsoft adresse enfin un angle mort historique de la gestion des identités : la récupération d’un compte après une perte totale des moyens d’authentification, y compris pour les comptes sensibles et à privilèges élevés.

Cela confirme qu’Entra ID Account Recovery n’est pas un simple ajout fonctionnel, mais un pilier de la stratégie identité de Microsoft, aux côtés de Verified ID, du Face Check et des mécanismes d’accès conditionnel.

Là où les approches traditionnelles reposaient sur des processus manuels, difficiles à industrialiser et fortement dépendants du support, Entra ID Account Recovery propose une alternative structurée, traçable et alignée avec les principes Zero Trust, en s’appuyant sur une vérification d’identité forte plutôt que sur des secrets ou des facteurs existants.

Même si la fonctionnalité est encore en préversion, elle ouvre des perspectives intéressantes pour :

réduire la dépendance au support, y compris pour les comptes administrateurs,
améliorer l’expérience utilisateur dans des scénarios critiques,
et renforcer la sécurité globale des processus de récupération.

Comme toujours, une activation progressive, en mode Évaluation, sur un tenant de test et avec une population restreinte, reste la meilleure approche avant toute mise en production.

Azure Virtual Desktop hybride + SSO

Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.

Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.

Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :

Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?

Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.

Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.

Quels sont les tokens utilisés par Microsoft Entra ID ?

Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :

Primary Refresh Token (PRT)
- Jeton long terme
- Spécifique à l’appareil
- Sert à demander d’autres tokens
- Utilisé par Windows (WAM – Web Account Manager)

Access Token
- Jeton court terme
- Présenté aux applications (API, Office, AVD…)
- Contient les claims utilisateur

Refresh Token
- Permet de renouveler un Access Token
- Généralement géré automatiquement par le système

Qu’est-ce que le Primary Refresh Token (PRT) ?

Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.

Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.

Microsoft Learn

Le PRT est stocké localement sur la machine et sert de jeton racine pour :

obtenir des tokens d’accès OAuth 2.0
s’authentifier automatiquement aux services cloud Microsoft
éviter toute ressaisie de mot de passe pour les applications modernes

Concrètement, le PRT permet :

l’ouverture automatique de session dans Edge
l’authentification transparente à Office, Teams, OneDrive
l’utilisation de Windows App / Azure Virtual Desktop web

Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.

Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?

Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :

Accès au service AVD (broker / portail)
→ Authentification Microsoft Entra ID
→ Le PRT suffit
Ouverture de la session Windows sur le session host
→ Authentification Active Directory
→ Un TGT Kerberos est obligatoire

Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.

Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.

Qu’est-ce qu’un TGT Kerberos Active Directory ?

Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.

Il est obtenu :

lors de l’ouverture de session Windows
après une authentification réussie auprès de l’AD

Le TGT permet ensuite :

d’accéder aux ressources Active Directory
d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
d’ouvrir une session Windows locale ou distante

Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.

Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?

Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :

générer un TGT Kerberos Active Directory
à partir d’une authentification cloud
sans nécessiter ADFS

Techniquement :

un objet Kerberos spécial est créé dans l’Active Directory
les clés sont synchronisées avec Microsoft Entra ID
Entra devient capable d’émettre un TGT valide pour l’AD

C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.

Pourquoi la jointure hybride améliore l’expérience SSO ?

Avec Microsoft Entra Hybrid Join :

l’appareil est reconnu par Entra
un PRT est délivré
les applications cloud utilisent un SSO moderne

En ajoutant Microsoft Entra Kerberos :

Entra peut aussi délivrer un TGT AD
Windows peut ouvrir la session sans redemande de mot de passe

On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.

À quoi sert la case “Single sign-on” dans Entra Connect ?

La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.

Seamless SSO repose sur :

Kerberos
le compte AD AZUREADSSOACC
le site autologon.microsoftazuread-sso.com

Son objectif est volontairement limité :

éviter la saisie du mot de passe AD
lors d’une authentification navigateur vers Entra ID
sur une machine AD-only

Il est important de distinguer Seamless SSO des autres mécanismes :

ne crée PAS de PRT
ne remplace PAS Microsoft Entra Kerberos
ne supprime PAS tous les écrans de login

Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.

Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et là :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants.

Un environnement Active Directory
Microsoft Entra Connect configuré avec
- Password Hash Synchronization (PHS)
- sans Single sign-on,
- avec Hybrid Joined pour les machines Windows 10/11
- Synchronisation de l’OU des utilisateurs AVD
- Synchronisation de l’OU des machines hôtes AVD

Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :

Notre environnement AVD en mode hybride est en place, commençons par un premier test.

Etape I – Test sans configuration SSO :

Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :

Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :

La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :

AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).

Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :

OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.

Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.

Commençons étape par étape les changements pour arriver à une configuration complète.

Etape II – Configuration SSO du pool d’hotes AVD :

Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :

J’effectue un nouveau test avec mon utilisateur :

À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :

Etape III – Création d’un objet serveur Kerberos :

Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :

Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Je lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :

Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :

J’effectue un nouveau test avec mon utilisateur :

Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :

Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :

Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.

L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.

Etape IV – Activation de l’authentification Microsoft Entra pour RDP :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :

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

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

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabled sur True :

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

Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.

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

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, je vérifie la bonne assignation du groupe :

J’effectue un nouveau test avec mon utilisateur :

Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.

Cela permet d’observer que :

La machine est Hybrid Entra ID Joined
Le PRT est valide
Le Kerberos cloud fonctionne
Le Kerberos AD DS fonctionne
Les deux mondes coexistent simultanément dans la même session

Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.

Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.

Etape V – Activation du SSO d’Entra Connect Sync :

Pour cela, je décide de rajouter une troisième machine AVD :

Celle-ci est bien présente dans l’Active Directory :

Mais elle n’est pas présente dans Entra ID :

Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :

J’effectue un test avec mon utilisateur :

Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :

Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :

La machine est jointe uniquement à Active Directory on-premises
Elle n’est pas jointe à Entra ID
Elle n’est pas Hybrid Join
Aucun PRT
Aucun SSO cloud
Aucune authentification Entra ID
Une tentative d’Entra ID Join / Hybrid Join a eu lieu
- Elle a échoué côté Entra ID
- La machine AVD n’existe pas ou n’est pas reconnu dans le tenant

L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :

Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :

Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :

Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :

établir une relation de confiance Kerberos avec l’AD on-prem
permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID

J’effectue donc un nouveau test avec mon utilisateur :

Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :

Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.

Pour cela, j’ouvre inetcpl.cpl :

Je clique sur Site dans Intranet local :

Je clique sur Avancée :

Je rajoute l’URL suivante :

https://autologon.microsoftazuread-sso.com

Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :

Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :

La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.

klist

Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).

Conclusion

À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.

Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.

Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Ajout de la prise en charge des groupes dans le manifeste :

["kdc_enable_cloud_group_sids"],

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

!!! Redémarrage des machines virtuelles du host pool pour appliquer la configuration !!!

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
- IOPS
- Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

Scenario	IOPS	Bandwidth MB/s
Avec Entra ID	12,446.88	299.95
Sans Entra ID	15,032.54	341.17
Premium SSD v2	20,378.31	1,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft 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 ID	Comportement natif	Limite importante
Utilisateurs / Groupes supprimés	Corbeille 30 jours	Object ID parfois régénéré → casse des dépendances
Rôles / Applications	Suppression définitive	Aucune corbeille, restauration impossible
Politiques d’accès conditionnel	Corbeille 30 jours (préversion)	Une erreur bloque l’accès global
Service Principals / App Registrations	Corbeille 30 jours	Impact direct sur les intégrations applicatives
Audit & sign-in logs	Conservation 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é ?

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.

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 :

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.

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.

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 su i vante 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 !