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.
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.
- Scénario I – Création d’un nouvel environnement AVD
- Scénario II – Ajout d’une identité managée à un environnement AVD existant
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é.
