Endormez vos VMs AVD inutilisées 🛏

Azure Virtual Desktop propose deux types d’environnement virtualisé en fonction des usages attendus. Voici une méthode simple de les différencier :

  • Environnement partagé : plusieurs utilisateurs sur une machine virtuelle
  • Environnement individuel : un utilisateur par machine virtuelle

Seulement ces types d’environnement ne conviennent pas à tous les usages. Par exemple, des besoins variés entre les utilisateurs, des droits d’administrateurs ou encore une fréquence d’utilisation ponctuelle d’Azure Virtual Desktop correspondent plus à un environnement AVD individuel.

Dans cet article, nous allons justement nous intéresser aux environnements AVD individuels. La configuration de ces machines mono-utilisateur permet de diminuer les coûts quand ces dernières sont uniquement démarrées si leur utilisateur a en réellement besoin.

Justement, que propose Azure pour allumer et éteindre les machines AVD ?

Pour les environnements AVD partagés, le démarrage et l’arrêt des machines virtuelles est configurable dynamiquement grâce à la nouvelle fonction d’autoscalling : un article est déjà disponible sur ce blog juste ici.

En quelques mots, la fonction de mise à l’échelle automatique (autoscalling) vous permet de démarrer des machines virtuelles Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre selon les besoins à l’instant T.

Est-ce aussi compatible pour les environnements AVD individuels ?

Oui pour le démarrage des machines virtuelle. Appelé démarrage à la demande, sa mise en place est très simple. Un autre article de ce blog en parle juste ici.

En quelques mots, l’utilisateur se connecte et attend quelques minutes, si la machine est éteinte, le temps qu’Azure démarre sa machine virtuelle AVD. Voici également une vidéo de Dean qui en parle très bien :

Quand s’éteindra alors sa machine individuelle AVD ?

Concernant l’arrêt de sa machine virtuelle individuelle AVD, il n’existe pas encore d’option native qui agit dynamiquement. Par défaut, l’arrêt d’une machine virtuelle Azure est :

  • Manuel : réalisé par script ou depuis le portail Azure.
  • Programmé : via la fonction auto-shutdown, configurable individuellement sur chaque VM.

Cette seconde option pose un souci dans un environnement AVD : l’absence de corrélation entre un auto-shutdown à heure fixe durant l’utilisation d’AVD risque de déconnecter à tort des utilisateurs.

Est-il envisageable de laisser l’utilisateur éteindre sa propre machine virtuelle ?

Cela vous oblige à lui donner des droits sur une ressource Azure : sa machine virtuelle 🤷‍♀️

Que peut-on faire pour gérer dynamiquement l’arrêt des machines virtuelles individuelles AVD ?

Azure est une chose flexible 😋 Une combinaison de services est possible pour arriver à cet objectif. Soyons clair, je n’ai rien trouvé n’y inventé, mais je me suis appuyé sur cette excellente documentation Microsoft.

Comme le montre le schéma ci-dessous, différentes étapes sont présents pour arriver à l’arrêt complet du service Azure :

  • Premier déclencheur = déconnecte l’utilisateur inactif
  • Second déclencheur = éteint l’OS de la machine virtuelle
  • Troisième déclencheur = désalloue la ressource Azure
Un mécanisme anticipe le retour de l’utilisateur avant l’arrêt de l’OS.

Différents composants sont nécessaires pour réaliser toutes ces étapes :

  • Ressources Azure :
    • Automation Account / Runbook / Identité managé
    • Alertes journalisées / Groupe d’action
  • Ressources Windows :
    • GPOs ou Polices locales
    • Tâches planifiées
    • Scripts

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ce test sur un environnement individuel AVD :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement de l’environnement AVD :

Pour déployer rapidement un environnement AVD joint à Azure AD, déployez un réseau virtuel Azure :

Continuez en déployant un environnement individuel AVD :

Ajoutez une ou plusieurs machines virtuelles pour les tests :

Renseignez les informations de réseau et un identifiant / mot de passe pour l’administrateur local :

Créez votre espace de travail AVD :

Une fois validation terminée, lancez la création des ressources Azure Virtual Desktop :

Attendez que le déploiement de votre AVD se termine :

Etape III – Finalisation de la configuration initiale :

Quelques opérations sont nécessaires pour finaliser l’installation de l’environnement AVD.

Ajoutez les 3 rôles Azure RBAC suivants sur votre groupe de ressources AVD :

  • Contributeur à la mise en route de la virtualisation des postes de travail : permet à l’application AVD de démarrer une machine virtuelle éteinte.
  • Utilisateur de la virtualisation du poste de travail : assigne l’utilisateur au groupe d’applications AVD.
  • Connexion de l’administrateur de la machine virtuelle : autorise l’utilisateur à se connecter à distance sur sa machine virtuelle avec les droits d’administrateur local.

Activez cette option pour mettre en route la fonction d’authentification SSO entre Azure AD la machine virtuelle AVD (expliquée juste ici) :

Activez la fonction de démarrage à la demande (expliquée juste ici et documentée officiellement ) :

Assignez votre utilisateur AVD de test à une des machines virtuelles :

Etape IV – Test de l’environnement AVD :

Avant de déployer la solution de configuration d’arrêt dynamique, testez le bon fonctionnement de l’accès à votre environnement AVD avec votre utilisateur de test.

Depuis votre poste local, connectez-vous à l’URL suivante, puis renseignez vos identifiants :

Ouvrez la session de bureau à distance AVD :

Acceptez la fin de la configuration SSO :

Attendez que la session Windows s’ouvre :

Une fois connecté, fermez la session utilisateur :

Depuis votre portail Azure, éteignez la machine virtuelle AVD :

Relancez la même connexion AVD depuis la page web de votre utilisateur de test :

Constatez la présence du message du démarrage de la machine virtuelle, vous invitant à patienter :

Attendez quelques minutes et constatez l’ouverture de la session Windows AVD :

Si tout fonctionne correctement pour vous, continuez la suite de cet article pour configurer l’arrêt dynamique AVD.

Etape V – Configuration des composants Azure

Pour cela, créez un compte Azure Automation :

Une fois la validation terminée, lancez sa création :

Une fois la ressource créée, allez dans le service appelé Azure Monitor :

Ajoutez une Règle d’alerte d’état de santé comme ceci :

Cochez uniquement les 4 conditions suivantes de cette façon :

Créez un nouveau Groupe d’action :

Rattachez le Groupe d’action à votre compte Azure Automation précédemment créé :

Lancez la création de votre Groupe d’action :

Nommez votre Règle d’alerte :

Lancez la création de votre Règle d’alerte :

L’étape suivante concerne maintenant la configuration Windows des machines virtuelles AVD. Il est possible de l’établir cela par :

  • des Polices locales sur chaque VM AVD
  • des GPOs créées sur un Active Directory

N’ayant pas d’Active Directory dans mon environnement de test, nous allons créer des polices locales sur la machine AVD de test. C’est aussi votre cas si les machines virtuelles AVD sont jointes à Azure AD.

Etape VI – Configuration des composants Windows

Comme votre utilisateur de test est considéré comme un administrateur local, ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

Créez une nouvelle Tâche planifiée :

Nommez la Tâche planifiée, puis cochez les cases suivantes :

Ajoutez un déclencheur sur le second onglet :

Choisissez le motif de déconnexion avec un délai de 30 minutes :

Sur l’onglet des actions, ajoutez le lancement du programme Shutdown avec les arguments suivants:

/f /s /t 0

Validez la création de la Tâche planifiée, puis lancez la création d’une seconde Tâche planifiée :

Choisissez le démarrage de la Tâche planifiée avec l’ouverture d’une session utilisateur :

Sur la VM AVD, créez un nouveau fichier texte avec les lignes ci-dessous :

@echo off
schtasks /change /tn  Disconnect /disable
schtasks /change /tn  Disconnect /enable
exit

Enregistrez-le sous le nom reset.cmd dans le dossier C:\Windows\System32 :

Appelez-le dans l’action de la Tâche planifiée :

Validez la création de la Tâche planifiée :

Ouvrez le Gestionnaire de police locale :

Naviguez dans l’arborescence suivante :

  • Configuration utilisateur
    • Paramètres Windows
      • Scripts (Logon/Logoff)

Cliquez sur le script suivant :

Cliquez sur Ajouter :

Ajoutez le nom de script suivant :

C:\Windows\System32\tsdiscon.exe

Validez ce script en cliquant sur OK :

Toujours dans le Gestionnaire de police locale, naviguez dans la seconde arborescence suivante :

  • Configuration utilisateur
    • Modèle administratif
      • Composants Windows
        • Services de bureau à distance
          • Hôte de session de bureau à distance
            • Limite de temp de session

Cliquez sur la configuration suivante :

Configurez comme ceci, puis validez vos modifications :

Etape VII – Test de la configuration

Il ne reste qu’à tester tout ça 🤣🤣 Voici un rappel des temps de phase configurés :

Avant la première authentification de mon utilisateur AVD, la VM qui lui est attitrée est désallouée, comme le montre le portail Azure ci-dessous :

Je connecte mon utilisateur de test au bureau AVD. Comme sa machine virtuelle est en statut désalloué, je dois attendre quelques minutes pour accéder à son bureau Windows :

Quelques minutes plus tard, la session Windows s’ouvre sans autre action de sa part ni de la mienne :

Le statut de la machine virtuelle AVD a lui aussi changé dans Azure :

Son horloge Windows indique 19:31, j’attends donc les 30 minutes nécessaires, sans effectuer aucune activité sur la session AVD. Environ 30 minutes plus tard, le message suivant apparaît sur sa session AVD :

Si rien n’est fait pendant ces deux minutes, la suite logique est la déconnexion de cet utilisateur :

A ce moment-là, Le portail Azure nous affiche que la machine virtuelle est toujours bien fonctionnelle :

Par contre, AVD reconnait bien que sa session AVD est bien en statut déconnecté :

Environ 30 minutes après la déconnexion de l’utilisateur de test, sa machine virtuelle AVD passe en statut arrêté :

La machine virtuelle devient alors indisponible pour le service AVD :

Environ 5 minutes plus tard , la machine virtuelle passe en statut désalloué :

Une nouvelle tentative d’ouverture AVD depuis le portail utilisateur relancera le démarrage de sa machine virtuelle :

Conclusion

La mise en place de la configuration de déconnexion des sessions inactives fonctionne très bien dans les environnements individuels d’Azure Virtual Desktop. Cette approche va sans nul doute diminuer les coûts liés au Cloud pour des besoins spécifiques et/ou périodiques, sans avoir à se soucier du démarrage et de l’arrêt des machines virtuelles individuelles.

Il sera même intéressant de combiner cette approche avec des instances réservées. Le nombre d’instances réservées approprié dépendra du plancher constant d’utilisateurs AVD connectés.

Peut-on booster les FPS de votre Azure Virtual Desktop ?

L’amélioration de l’expérience utilisateur est une tâche constante. Azure Virtual Desktop simplifie et sécurise grandement l’accès aux ressources de l’entreprise. Mais AVD reste un environnement de bureau à distance. A caractéristiques égales, une ressource IT distante a un désavantage en comparaison avec une ressource locale de même grandeur : plusieurs paramètres rentrent en ligne de compte, comme le choix des réseaux (performances, types, …) ou encore le protocole de transmission utilisé.

Azure Virtual Desktop se doit donc de continuer d’évoluer. Plusieurs améliorations consacrées à l’expérience utilisateur ont déjà fait l’objet d’articles sur ce blog :

Concernant ce dernier point, je viens de faire remarque intéressante sur la généralisation du protocole UDP sur les réseaux publics pour un environnement AVD, dont je vous partage l’info juste ici.

Dernièrement, Microsoft propose quelques améliorations pour augmenter la fréquence du nombre d’images sur une session AVD. Cette donnée est importante pour la fluidité des animations ou des vidéos.

Je tiens à remercier Alexandre Moreaux pour son aide précieuse dans la réalisation des tests nécessaire à la rédaction de cet article !

Voici un site web montrant différents exemples de fréquence d’affichage sur un poste local :

M’appuyant sur cette vidéo de Dean, j’ai souhaité mettre en pratique ses conseils.

Pour avoir une meilleure idée sur le sujet, cet article va comparer différentes configurations pour en mesurer l’impact sur les FPS.

Plusieurs environnements Azure Virtual Desktop sont donc nécessaires. Les 4 premiers sont basés sur une machine virtuelle de type D8s v5 et vont servir à effectuer les tests suivants :

  • Environnement 0 : témoin de base, aucune modification
  • Environnement 1 : augmentation de la limite FPS pour les connexions RDS
  • Environnement 2 : augmentation FPS + priorité du décoding graphique
  • Environnement 3 : augmentation FPS + priorité + configuration du décoding graphique

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ces tests sur AVD :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • 4 réseaux virtuels Azure, un par environnement AVD
  • 4 machines virtuelles AVD jointes à Azure AD

Vous pouvez créer rapidement et simplement les environnements AVD en suivant cet article. Voici quelques copies d’écran d’un des 4 environnements AVD créés pour mes tests :

N’oubliez pas de configurer les éléments suivants pour rendre accessible vos environnements AVD :

  • Rôle RBAC Connexion de l’utilisateur de la machine virtuelle à votre utilisateur de test
  • Rôle RBAC Connexion de l’administrateur de la machine virtuelle à votre utilisateur admin
  • Assignation du groupe d’application AVD à votre utilisateur de test + utilisateur admin

Etape I – Test sur votre poste local

Afin de se faire une meilleure idée de l’impact d’une session ouverte via RDP, rendez-vous sur la page suivante depuis votre poste physique. Vous devriez obtenir généralement les 3 fréquences FPS suivantes : 60 / 30 / 15.

Dans cet ordre de grandeur, l’œil humain distingue assez facilement l’impact du nombre d’images par seconde. Il est temps de comparer le poste physique avec la première machine AVD.

Etape II – Test de l’environnement témoin :

Connectez-vous à votre premier environnement AVD, appelé témoin :

Réouvrez cette même page de test FPS sur la session AVD via un navigateur internet. Le plafonnement devrait être aux alentours de 30 FPS :

Un clic sur l’icône d’information de connexion RDP vous indique également le nombre d’image traitées et le protocole utilisé :

Les sessions à distance par le protocole RDP sont en effet limité par défaut sur le nombre maximal d’images.

L’étape suivante va vous permettre de modifier cette limite et de recomparer le rendu sur les deux environnements AVD.

Etape III – Test de la modification de la limite FPS

Pour bien différencier ce premier changement, connectez-vous sur votre seconde machine AVD de test :

Cet article sur Microsoft Learn explique comment augmenter la limite de fréquence d’images dans une session à distance :

Depuis le menu Démarrer, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’éditeur de registre Windows :

Saisissez l’arborescence suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations

Créez une nouvelle clef DWORD

Donnez-lui le nom suivant :

DWMFRAMEINTERVAL

Assignez-lui la valeur décimale suivante, puis cliquez sur OK :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f

Fermez la session de votre utilisateur AVD.

Rouvrez la session sur la même machine AVD.

Ouvrez la même page de test FPS que sur la première machine AVD. Le plafonnement devrait être maintenant aux alentours de 60 FPS :

Avons-nous donc maintenant 60 FPS ?

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique en revanche un nombre bien plus faible pour le nombre d’image traitées, malgré la grandeur du débit disponible par le protocole UDP.

Continuons les tests en suivant toujours les conseils de Microsoft.

Etape IV – Test de la modification de la limite FPS + Priorité au décoding

Ce nouveau test reprend la modification de registre apportée par l’étape III et rajoute en plus la priorité au décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les deux modifications :

  • Modification de la limite FPS (Etape III)
  • Priorité au décoding

Pour ce second point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’Éditeur de stratégie de groupe locale :

Ouvrez l’arborescence suivante :

  • Computer Configuration
    • Administrative Templates
      • Windows Components
        • Remote Desktop Services
          • Remonte Desktop Session Host
            • Remote Session Environment

Ouvrez la police suivante :

Activez-là et cliquez sur OK pour sauvegarder :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait être toujours aux alentours de 60 FPS :

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique toujours un nombre bien plus faible de FPS :

Continuions notre troisième test avec en ajout la configuration du décoding graphique.

Etape V – Test limite FPS + Priorité au décoding + Configuration du décoding

Ce troisième reprend les deux modifications apportées par les étape III et IV, et ajoute en plus la configuration du décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les trois modifications suivantes :

  • Modification de la limite FPS (Etape III)
  • Priorité au décoding (Etape IV)
  • Configuration du décoding

Pour configurer ce troisième point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’Éditeur de stratégie de groupe locale :

Ouvrez l’arborescence suivante :

  • Computer Configuration
    • Administrative Templates
      • Windows Components
        • Remote Desktop Services
          • Remonte Desktop Session Host
            • Remote Session Environment

Ouvrez la police suivante :

Activez-là et cliquez sur OK pour sauvegarder :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait encore et toujours être aux alentours de 60 FPS :

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique encore et toujours un nombre bien plus faible de FPS :

Que faire alors ? Sommes-nous bloqués quoi que nous fassions avec 30 FPS sur Azure Virtual Desktop ?

Etape VI – Test sur une machine virtuelle graphique

J’ai donc décidé d’aller un peu plus loin en testant AVD sur une machine virtuelle graphique disponible sur Azure. J’ai choisi de prendre la taille Standard_NV6 de la série des NV, elle dispose d’une puissance graphique bien plus conséquente que les machines de la famille D :

Comme ces machines graphiques ne supporte pas le GEN 2, j’ai choisi sur une image en Windows 10 en GEN 1:

Comme lors de la précédente salve de tests, j’ai utilisé deux environnements de même configuration pour mesurer l’impact ou non des modifications Microsoft sur les FPS :

  • Environnement 5 : Environnement graphique de base
  • Environnement 6 : Environnement graphique de base + modifications

Sur les deux environnements graphiques, j’ai commencé par mettre à jour les pilotes de la carte graphique à jour grâce au compte d’administrateur local :

J’ai continué par configurer l’outil de configuration GPU spécifique à Nvidia :

nvidia-smi.exe -fdm 0 -g 00000001:00:00.0

J’ai effectué par la suite un redémarrage nécessaire des deux VMs.

J’ai ensuite installé sur les deux environnements graphiques les applications suivantes :

Enfin, j’ai réalisé la configuration suivante uniquement sur l’environnement 6 :

  • Lancement des 3 modifications précédentes par des clefs de registre :
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f
gpupdate.exe /force 

Un dernier redémarrage de la machine virtuelle de l’environnement 6 est encore nécessaire.

J’ai lancé Fraps suivi d’une nouvelle partie de jeu Age of Empires II. Sans plus attendre, voici les résultats FPS donnés par FRAPS et par la connexion RDP :

Environnement 5 : Graphique sans modification :

Environnement 6 : Graphique avec modifications :

Dans les deux environnements, Fraps indique un nombre très conséquent de 120 FPS. Cela s’explique par la faible exigence graphique Age of Empires II et de la performance graphique de ces machines virtuelles.

Concernant les FPS relevés par la connexion RDP, un écart se creuse d’environ 10 FPS entre les deux environnements tests. L’environnement 6 est meilleur, sans pour autant rapprocher le nombre de FPS généré par la carte graphique de machine virtuelle AVD.

Conclusion

Tous ces tests montrent l’importance relative de la configuration des FPS sur des machines classiques d’AVD et pour des tâches de bureautique. 30 FPS suffisent à beaucoup d’actions. On pourra néanmoins être gêné si le volume d’utilisateurs est important, et que des besoins graphiques (Teams ?) sont présents.

Les machines graphiques disponibles sur Azure montre de belles performances et peuvent convenir dans bien des scénarios graphiques quand elles sont combinées avec Azure Virtual Desktop.

Réduisez les coûts de votre AVD 🤑

Beaucoup d’articles sur ce blog parlent déjà d’Azure Virtual Desktop 🤣. Au fil des mois, nous avons constaté ses améliorations, la simplification du déploiement, l’augmentation de sa sécurité, de ses performances ou encore une meilleure compatibilité. Un point important n’a pas encore été abordé : l’optimisation des coûts sur AVD.

D’ailleurs, plusieurs articles parlant des coûts sur Azure sont déjà disponibles sur ce blog :

C’est un premier pas vers la compréhension de la facturation de Microsoft selon vos usages. Ce modèle de facturation, basé sur la consommation est la norme pour les principaux fournisseurs de Cloud.

Quels sont les principaux coûts d’Azure Virtual Desktop ?

Avant de parler d’optimisations sur les coûts, il est nécessaire de lister les principales charges d’une architecture Azure Virtual Desktop. Certains coûts sont systématiques, tandis que d’autres sont optionnels :

  • Gestion des identités : Azure Virtual Desktop repose sur une gestion des utilisateurs, de même que pour l’OS, les fichiers ou encore certaines applications. Plusieurs options sont disponibles : Azure AD, Active Directory ou le service managé Azure AD DS.
  • Machine virtuelle : Que l’environnement AVD soit composé pour des machines individuelles ou partagées, elles représentent toujours un coût important dans l’infrastructure AVD.
  • Stockage : Plusieurs types de stockage sont nécessaires dans une architecture AVD. Un premier stockage est déjà présent sur chaque machine virtuelle pour stocker l’OS, les applications, … Un second est créé pour stocker les données et les informations de session des utilisateurs AVD.
  • Licence : Que l’environnement AVD fonctionne sur Windows 10/11 ou Windows Server, des licences Microsoft sont nécessaires. Le choix de l’OS pour AVD repose sur les besoins applicatifs ou la méthode de gestion du parc souhaitée.
  • Réseau : Toute donnée sortante du Cloud Microsoft est facturée. Chaque utilisateur d’AVD génère un petit coût lorsqu’il ouvre et utilise sa session de bureau à distance. Cette somme varie selon le volume de Gio envoyés en dehors du Cloud, en sachant que le protocole RDP n’est pas réputé comme gourmand en traffic.
  • Gestion de la sécurité : Toute infrastructure IT a besoin de mesures de protection. Ces coûts ne sont pas obligatoirement liés à Microsoft, mais ils doivent être pris en compte dans l’enveloppe finale.
  • Sauvegarde : La sauvegarde de certaines données est indispensable pour se prémunir d’un accident ou d’une fraude. Le volume de donnée à sauvegarder, la fréquence ou la redondance de la sauvegarde influent sur son prix.
  • Plan de reprise d’activité : Le PRA n’est pas un système de sauvegarde au premier sens du terme. Il n’est pas non plus obligatoire. Mais il doit être perçu comme un point majeur dans la protection de services critiques, afin qu’ils continuent à fonctionner. Sur Azure, un doublement de certaines ressources AVD est envisageable dans une seconde région du Cloud.

Et le coût d’un AVD dans tout ça ?

Il n’existe pas de prix fixe pour Azure Virtual Desktop. La liste des éléments précédemment listés vous montre les principaux axes de coûts, mais le choix de chaque composant dépend du projet AVD.

Il existe un objet Azure Virtual Desktop dans le Calculateur de prix Azure, mais je trouve que celui-ci passe très vite sur certains points et oublie d’en mentionner d’autres.

Alors, comment procède-t-on pour estimer le prix d’un projet AVD ?

Aucune baguette magique n’existe ! Comme pour toute infrastructure IT, il est conseillé de récolter quelques métriques sur les besoins utilisateurs pour commencer à composer. Voici quelques exemples de questions qui me paraissent essentielles pour démarrer un projet AVD :

  • Nombre d’utilisateurs totaux
  • Nombre d’utilisateurs simultanés
  • Horaires de travail
  • Nature des besoins (Répartition des utilisateurs selon des types de population)
  • Exigences OS de l’équipe IT / des applications
  • Ont-ils déjà des licences 365 en place ?
  • Préférence géographique sur Azure ?
  • Volonté d’engagement dans la durée ?
  • Perspective de croissance des besoins AVD
  • Ressources IT locales à interconnecter

Ces données sont utiles pour estimer les principaux coûts listés précédemment.

Et si l’on ne souhaite pas réaliser tous ces calculs ?

Azure facture sur la consommation mensuellement. Le but sur Azure n’est pas de produire un coût fixe mensuel. Si cela n’est pas votre souhait, Microsoft a aussi pensé à vous et propose également une solution clef en main, appelé Windows 365 au tarif mensuel fixe.

Windows 365 est proche d’un système de licence comme pour Office 365, pour le provisionnement d’un PC Cloud. La puissance de ce PC dépend du prix de la licence Windows 365 choisie. Un premier article sous la solution est disponible juste ici

Bien que basé sur la même technologie, Windows 365 est un service hautement managé. Cela réduit donc la configuration possible sur certaines fonctionnalités, comme le montre ce tableau ci-dessous :

Êtes-vous êtes toujours là ? 😉

Je vous propose de reprendre les 6 principaux coûts Azure Virtual Desktop et d’envisager des économies possibles.

Coût I – Gestion des identités :

Azure Virtual Desktop fonctionne avec les 3 systèmes de gestion identitaire suivants :

Il ne s’agit pas de solutions 100% équivalentes en termes de fonctionnalités, chacune apporte une plus-value selon le scénario AVD souhaité.

Quelles sont les économies possibles ?

L’économie consiste à prendre la bonne gestion identitaire à votre projet. Voici un classement croissant par ordre de prix et des usages les plus courants :

  • Azure AD : Azure AD de base est gratuit ! Évidemment, certaines fonctionnalités sont bridées, mais cela allège déjà un peu la facture. La gestion identitaire par Azure AD est conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
  • Azure AD DS : Solution intermédiaire en termes de coûts, de fonctionnalités et de management. Il s’agit d’un domaine géré par Microsoft et donc partiellement restreint. Azure AD DS est lui aussi conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
  • Active Directory : idéalement utilisé si l’on souhaite avoir la main complète sur les paramétrages du domaine AD, ou si un domaine AD existe déjà en on-premise. Il est alors possible d’étendre l’AD local à Azure via une liaison Azure VPN et une machine ayant le rôle d’AD dans Azure.

Coût II – Machine virtuelle :

Comme annoncé plus haut, les machines virtuelles représentent une part importante du coût total de l’architecture Azure Virtual Desktop. Bien souvent, il est difficile d’estimer au mieux le nombre et la puissance des machines virtuelles AVD. Les métriques de l’environnement actuel, un cahier des charges précis et des phases de POC sont de vrais facilitateurs.

De mon côté, j’essaie d’imaginer, selon mes expériences antérieures, les possibilités de machines virtuelles AVD adaptées aux besoins des utilisateurs. Je compile alors le tout dans un tableau Excel : le nombre d’utilisateurs par population et différents scénarios où les ressources allouées varient :

Quelles sont les économies possibles ?

Trois économies sont possibles sur les coûts des machines virtuelles AVD :

  • Adaptez la puissance de vos machines virtuelles : cela risque de ne pas plaire aux utilisateurs AVD, ou pas. Des machines correctement dimensionnées selon les usages diminuent fortement les coûts. Il est important d’analyser le nombre d’utilisateurs maximal que la machine supporte sans que l’expérience utilisateur ne soit dégradée.
  • Réservez vos machines virtuelles pendant 1 ou 3 ans : Deux méthodes de facturations sont disponibles sur Azure. Prendre un engagement sur une machine virtuelle est une méthode pratique pour diminuer les coûts quand l’utilisation de la ressource est en 24/7.
  • Privilégiez Windows 10/11 quand cela est possible : Une licence Windows Server + CAL RDS coûtent toujours plus cher que des licences ayant des droits d’accès utilisateur, comme Microsoft 365 Business Premium ou Microsoft E3/E5.

Coût III – Stockage :

Il existe deux principaux coûts au stockage sur Azure. La taille du stockage et les transactions influent sur le montant :

  • Taille du stockage : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
  • Transactions : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.

Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :

  • Premium SSD : 20.13 CHF / mois
  • Premium SSD v2 : 11.49 CHF / mois
  • Standard SSD : 12.63 CHF / mois
  • Standard HDD : 6.39 CHF / mois
  • Ultra disk : 88.73 CHF / mois

Quelles sont les économies possibles ?

  • Le type de disque le moins cher n’est pas forcément le plus économe. Les transactions risquent de faire exploser le coût du stockage des machines virtuelles ou des partages de fichiers.
  • Surveillez les consommations d’espace : un espace réservé et inutilisé est facturé par Azure. Ajustez la taille et les performances selon les besoins.

Coût IV – Licence :

Azure Virtual Desktop nécessite des licences adéquates en fonction de l’environnement choisi, Windows 10/11 ou Windows Server :

  • Windows 10/11 : On licencie les utilisateurs et non les machines virtuelles.
  • Windows Server : On licencie les machines virtuelles (+ CAL RDS) et non les utilisateurs.
Tarification Azure Virtual Desktop

Quelles sont les économies possibles ?

Pour moi, la meilleure économie possible est de partir sur une licence Microsoft 365 Business Premium pour chaque utilisateur AVD. Cette dernière comprend entre autres :

  • Azure AD Premium P1
  • Les droits d’utilisation d’Azure Virtual Desktop sous environnement Windows 10/11
  • Les principaux outils de la suite bureautique d’Office 365
  • Et encore bien d’autres fonctionnalités de sécurité

Si le choix de partir sur un environnement AVD sous Windows Server est non négociable, privilégiez Azure Hybrid Benefit grâce à l’achat de licences Windows Server et CAL RDS en mode souscription CSP. La rentabilité est atteignable en 1 ou 2 mois seulement !

Coût V – Réseau :

Pensez à consulter régulièrement l’excellent site m365maps pour vous aider à choisir la meilleure licence selon vos besoins.

Les services hébergés dans le cloud sont accessibles depuis une architecture on-premise ou pour des utilisateurs simplement connectés à internet. Le schéma réseau ci-dessous montre les étapes de mise en place du bureau à distance AVD pour un utilisateur se connectant depuis internet :

Quelles sont les économies possibles ?

Vous l’avez compris, l’utilisation d’Azure AD et du protocole HTTPS inversé apportent une couche de sécurité dans le transfert de données entre l’infrastructure AVD et l’utilisateur.

Dans beaucoup de scénarios, il n’est pas systématiquement nécessaire d’exiger un accès VPN. Ce service est payant dans Azure, et son prix dépend principalement de son débit.

Enfin, les volumes de bande passante sortante ne sont pas élevés pour un environnement AVD. Il est donc inutile d’acheter un circuit ExpressRoute en formule illimité :

Coût VI – Gestion de la sécurité :

Une série d’articles dédiée à la sécurité est disponible juste ici. Pour éviter de vous endormir lors de longues lectures d’hiver et pour rester focalisé sur Azure Virtual Desktop, je vous conseille ces deux articles là :

Prenons en exemple la sécurité sur Azure AD :

Azure AD est gratuit ! 🤣 Azure Active Directory est bien proposé en quatre éditions : Gratuite, Applications Office 365, Premium P1 et Premium P2. Pour des questions de sécurité, je recommande de licencier vos utilisateurs AVD avec une licence Azure AD Premium P1.

Grâce à lui, l’accès conditionnel sur votre AVD apporte des mesures de restriction et bloque les connexions suspectes :

FonctionnalitéAzure AD Free – Paramètres de sécurité par défautAzure AD Free – Administrateurs généraux uniquementOffice 
365
Azure AD Premium P1Azure AD Premium P2
Accès conditionnel
Accès conditionnel basé sur les risques

Quelles sont les économies possibles ?

Je pense qu’il n’est pas nécessaire de s’orienter vers une licence Azure AD Premium P2 pour vos utilisateurs AVD. Ses fonctionnalités sont certes très intéressantes, mais ce besoin n’est pas utile pour des « utilisateurs lambda ».

Conclusion :

Aucun doute qu’il existe plein d’autres optimisations possibles pour un environnement AVD. Un exercice que je conseille est de suivre régulièrement les évolutions de Microsoft sur les services Cloud. Le blog officiel et les vidéos disponibles sur YouTube vous donneront toujours des informations et des astuces auxquelles vous n’avez pas pensées.

Enfin n’oubliez pas de suivre et d’analyser la consommation Azure grâce au Cost Management 😉😉

AVD : Protocole UDP pour tous !

Ce nouvel article est focalisé sur la partie réseau d’AVD, il reste dans la continuité de celui déjà consacré à RDP Shortpath, écrit il y a plusieurs mois déjà. Azure Virtual Desktop est capable d’établir des connexions de bureau à distance via deux protocoles : TCP et UDP. L’utilisation du second permet d’améliorer les performances grâce à un débit plus important et une gestion différente des paquets.

Pour vous remettre dans le bain, voici un rappel de l’excellente vidéo de Dean à ce sujet :

Pourquoi doit-on se préoccuper du protocole UDP ?

L’impact du protocole dans un environnement dédié au bureau à distance est majeur. Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP dans le cadre d’une connexion RDP :

TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.

Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.

Pour vous donner une meilleure idée, voici une vidéo comparative montrant visuellement l’impact du protocole si une partie de paquets est perdue :

Pourquoi refaire un article sur ce sujet ?

En faisant différents tests sur des environnements Azure Virtual Desktop, je me suis rendu compte « par hasard » de l’activation quasi systématique du protocole UDP lors des ouvertures de session, sans aucune action ni configuration de ma part.

J’ai donc effectué différents tests sur 3 environnements AVD distincts :

  • VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 10 21H2
  • VM : Standard D2s v3 (2 vCPU, 8 GiB memory) / OS : Windows 11 22H2
  • VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 11 21H2

Dans les 3 environnements, j’ai constaté exactement le même mécanisme :

  • Première ouverture de session en TCP
  • Seconde ouverture de session en UDP

Aucune configuration via la règle de registre ICEControl, pour activer le RDP Shortpath, n’a été mise en place avant ces tests :

Comment cela est-ce possible ?

Tout simplement car la fonctionnalité UDP a été déployée sur l’ensemble des environnements AVD, de production et de validation : RDP Shortpath for public networks in Azure Virtual Desktop – Microsoft Community Hub.

Comme l’indique ce billet Microsoft , la disponibilité générale du routage via le protocole UDP pour les connexions transitant via un réseau public est disponible depuis la date du 6 septembre dernier. Ils recommandent même de retirer la précédente clef de registre.

A noter que certaines ouvertures de sessions se sont malgré faites tout en TCP. Bien souvent, la fermeture / réouverture de la session m’a permis de retrouver un protocole UDP. Je pense que certains éléments influent sur cela, sans vraies certitudes.

Peut-on désactiver le protocole UDP afin de rester systématiquement en TCP ?

Cela est parfaitement possible et nécessaire dans certains scénarios. Microsoft propose 3 méthodes pour retrouver l’état initial en TCP :

  • Désactivation au niveau de la machine virtuelle AVD
  • Désactivation au niveau du client AVD
  • Désactivation via Intune

Pour la première méthode, il est nécessaire d’intervenir au niveau de la machine AVD, ou de l’implémenter via une GPO.

Connectez-vous sur la machine virtuelle AVD avec un compte administrateur.

Ouvrez l‘Editeur de groupes polices locales :

Rendez-vous dans le menu suivant :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

Ouvrez le paramètre ci-dessous :

Cochez les options comme ceci, puis fermez la session et rouvrez là :

Constatez bien que votre connexion RDP utilise le protocole TCP :

La configuration et le résultat sont identiques pour les machines en Windows 10.

Annexe

Durant ces tests j’ai également remarqué que mes environnements Azure Virtual Desktop fonctionnaient très bien malgré l’absence de l’argument RDP targetisaadjoined dans les propriétés RDP du pool d’hôtes AVD :

Avant :

Maintenant :

C’est toujours appréciable d’avoir une chose de moins à penser dans la configuration 😎.

Conclusion

Microsoft continue d’améliorer son outil et facilite sa configuration. La simplification et l’automatisation du protocole UDP améliore les performances et donc l’expérience utilisateur. Nul doute que Microsoft va continuer à travailler dans ce domaine pour accroitre le nombre d’utilisateurs sur un de leurs produits phares.

Azure Virtual Desktop ❤️ FIDO2

Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.

Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.

Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?

La réponse de l’industrie au problème des mots de passe.

FIDO Alliance

Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.

FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.

Cette vidéo en français explique plusieurs de ces avantages :

  • USB-A ou C ou encore NFC
  • Absence de donnée personnelle sur la clef
  • Code PIN de protection
  • Zone de contact pour valider une présence physique
  • Utilisation pour plusieurs comptes
Bon conseil : toujours avoir deux clefs 😊.

Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?

Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :

D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :

  • Windows Hello Entreprise
  • Microsoft Authenticator
  • Clés de sécurité FIDO2

Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?

FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.

FonctionnalitéAzure AD Free – Paramètres de sécurité par défaut Azure AD Free – Administrateurs généraux uniquementOffice 
365
Azure AD Premium P1Azure AD Premium P2
Accès conditionnel
Accès conditionnel basé sur les risques

Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :

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

Où peut-on se procurer des clefs FIDO2 ?

Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :

FournisseurBiométrieUSBNFCBLECertifié FIPSContact
AuthenTrendyyyynhttps://authentrend.com/about-us/#pg-35-3
Cirightnnynnhttps://www.cyberonecard.com/
Ensurityyynnnhttps://www.ensurity.com/contact
Excelsecuyyyynhttps://www.excelsecu.com/productdetail/esecufido2secu.html
Feitianyyyyyhttps://shop.ftsafe.us/pages/microsoft
Fortinetnynnnhttps://www.fortinet.com/
Giesecke + Devrient (G+D)yyyynhttps://www.gi-de.com/en/identities/enterprise-security/hardware-based-authentication
GoTrustID Inc.nyyynhttps://www.gotrustid.com/idem-key
HIDnyynnhttps://www.hidglobal.com/contact-us
Hypersecunynnnhttps://www.hypersecu.com/hyperfido
IDmelon Technologies Inc.yyyynhttps://www.idmelon.com/#idmelon
Kensingtonyynnnhttps://www.kensington.com/solutions/product-category/why-biometrics/
KONA Iynyynhttps://konai.com/business/security/fido
NeoWavenyynnhttps://neowave.fr/en/products/fido-range/
Nymiynynnhttps://www.nymi.com/nymi-band
Octatcoyynnnhttps://octatco.com/
OneSpan Inc.nynynhttps://www.onespan.com/products/fido
Swissbitnyynnhttps://www.swissbit.com/en/products/ishield-fido2/
Thales Groupnyynyhttps://cpl.thalesgroup.com/access-management/authenticators/fido-devices
Thetisyyyynhttps://thetis.io/collections/fido2
Token2 Switzerlandyyynnhttps://www.token2.swiss/shop/product/token2-t2f2-alu-fido2-u2f-and-totp-security-key
Solutions TrustKeyyynnnhttps://www.trustkeysolutions.com/security-keys/
VinCSSnynnnhttps://passwordless.vincss.net
Yubicoyyynyhttps://www.yubico.com/solutions/passwordless/

Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :

Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?

Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :

Etape 0 – Rappel des prérequis :

Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :

  • Un poste sous Windows 10 (1903) ou supérieur
  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
  • Une licence Azure AD Premium Plan 1 ou Plan 2

Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.

Etape I – Configuration du code PIN :

Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :

Cliquez ici pour configurer la clef :

Touchez la zone prévue à cet effet pour continuer :

Définissez un code PIN et confirmez-le :

Etape II – Activation de FIDO2 sur Azure AD :

Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :

Cliquez sur Méthodes d’authentification :

Cliquez sur la ligne FIDO2 :

Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :

Sauvegardez-là avec les options de base :

Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.

Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :

Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.

Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.

Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :

Cliquez ici pour ajouter la première clef FIDO2 :

Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :

Une fois terminé, recommencez le processus pour arriver sur cet écran :

Azure AD entame une communication avec la clef FIDO2 :

Plusieurs messages d’information de Windows 10 vont se succéder :

Renseignez le PIN de votre clef FIDO2, puis continuez :

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

Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :

Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :

Etape IV – Test de FIDO2 :

Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.

Cliquez-ici pour vous authentifier :

Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :

Renseignez le code PIN de votre clef FIDO2 :

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

Cliquez enfin sur Non :

Et vous voilà correctement authentifié sur le portail Office365 😎

Etape V – Création d’une méthode d’authentification renforcée :

En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.

Pour rappel, je suis partie d’un environnement Azure Virtual Desktop existant et équivalent à ce qui est détaillé dans cet article : Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on – Jean-Loup & Azure (jlou.eu).

Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu Sécurité :

Cliquez sur Méthodes d’authentification :

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

Terminez la création de celle-ci :

Etape VI – Test de l’accès conditionnel au premier niveau :

Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :

Créez votre nouvelle Police :

Saisissez un nom à votre police et sélectionnez votre utilisateur de test :

Ajoutez l’application Azure Virtual Desktop :

Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :

Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :

Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :

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

Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 😎.

Etape VII – Test de l’accès conditionnel au second niveau :

En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :

J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :

Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :

Attendez que le processus continue :

Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :

Renseignez le code PIN de votre clef FIDO2 :

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

Attendez que la session AVD s’ouvre :

Conclusion

Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.

Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous 🤣

Privatisez l’accès de votre AVD

Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.

Pourquoi restreindre un service Cloud ?

Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.

Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.

Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :

Qu’est-ce qu’Azure Private Link ?

En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :

Voici une vidéo qui aborde le sujet dans son entièreté :

Comment va fonctionner Azure Virtual Desktop avec Private Link ?

Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.

En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.

A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?

Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.

C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :

  • La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
  • La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.

Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?

Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.

Etape 0 – Rappel des prérequis

Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :

  • Poste Windows 10 avec Azure VPN
  • Environnement AVD avec jointure Azure AD

On retrouve ainsi mon premier réseau virtuel comprenant :

  • La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
  • Le service Azure Bastion pour m’y connecter plus facilement

J’ai également déployé un second réseau virtuel. Celui-ci comprend

  • Mon environnement Azure Virtual Desktop
  • Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD

La connexion VPN Point à Site est bien fonctionnelle :

L’accès direct à une des machines virtuelles AVD répond bien.

Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :

Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.

Etape I – Activation de la fonction de préversion d’Azure Private Link

Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :

N’oubliez pas de sélectionner la bonne souscription Azure.

Une fois enregistrée, attendez environ 15 minutes.

Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :

Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :

  • Entre le client et le service Azure Virtual Desktop
  • Entre le service Azure Virtual Desktop et les machines virtuelles AVD

Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :

Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuel Azure

La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :

Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :

Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.

Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :

Pour réactiver les connexions, vous devrez créer un private endpoint pour chaque pool d’hôtes AVD que vous souhaitez autoriser.

Donnez-lui un nom, puis passez à l’onglet suivant :

Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.

Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :

Type de resourceType de sous-resourceQuantité
Microsoft.DesktopVirtualization/workspacesglobalUn pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspacesfeedUn par workspace
Microsoft.DesktopVirtualization/hostpoolsconnectionUn par pool d’hôtes

Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :

Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :

Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :

Lancez la création puis attendez :

Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :

Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.

Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :

Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.

Pour bien comprendre ce qui s’est passé, un test intéressant est de

  • Créer un groupe de sécurité réseau (NSG)
  • Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
  • L’associer au sous-réseau contenant les machines virtuelles AVD

Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.

J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :

Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.

Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :

Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :

Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :

Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.

Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :

Comme précédemment, commencez par créer un private endpoint comme ceci :

Nommez-le différemment du premier private endpoint créé durant l’étape précédente :

Choisissez cette fois-ci la sous-resource cible de type Feed :

Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :

Là encore, des adresses IP privées seront allouées pour les services suivants :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :

Lancez la création puis attendez :

Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.

Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.

Pour cela, créez un nouvel espace de travail AVD :

Nommez-le et lancez sa création :

Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.

Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :

Choisissez le type de sous-resource cible Global :

Choisissez un réseau en relation directe avec votre environnement AVD :

Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :

Lancez la création puis attendez :

Etape IV : Configuration du réseau on-premise

Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.

Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :

Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints.

Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.

Etape V : Test de la connexion via Azure VPN Point à Site

Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :

aka.ms/wvdarmweb

Constatez avant tout que la page n’est dorénavant plus joignable :

Démarrez votre connexion VPN grâce au client Azure VPN :

Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Renseignez une seconde fois son mot de passe :

Et vus voilà dans votre session AVD !

Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :

Réactiver la connexion VPN pour retrouver la session AVD.

Etape VI : Résumé des ressources Azure créées

Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :

  • 3 private endpoints :
  • 3 cartes réseaux :
  • 2 zones DNS privées :
  • 1 second espace de travail AVD :

Etape VI : Aide à la résolution

Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :

Absence du premier private endpoint sur le pool d’hôtes AVD.
Connexion VPN non démarrée.
Authentification correcte, mais absence d’enregistrements DNS www, rdweb et client sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS .rdweb sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.

Conclusion

Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.

Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route 😎

Augmentez la résilience de votre AVD

De manière générale, la grande majorité des services proposés par les principaux hébergeurs Cloud s’accompagnent d’un niveau de service (SLA). Ce Service-level agreement est un point d’accord concernant la disponibilité d’un service entre les utilisateurs et l’hébergeur Cloud. Une architecture entière dispose elle aussi de sa propre SLA. La SLA de ce produit final combine alors toutes les SLAs de ses sous-produits dont elle dépend.

Dans cet article, nous allons parcourir ensemble quelques mécanismes de résilience disponibles sur Azure. Nous testerons aussi ces méthodes dans le cadre de déploiement d’environnement AVD via le portail Azure.

Qu’est-ce que la SLA selon Microsoft ?

Les Contrats de Niveau de Service (« Service-level agreements », SLA) décrivent les engagements de Microsoft en termes de temps de disponibilité et de connectivité. Les SLA pour les différents services Azure sont énumérés ci-dessous.

SLA selon Microsoft

Azure élabore différentes SLAs pour chaque service qu’ils proposent. Certains services encore en préversion, destinés à du développement ou même gratuits peuvent être dépourvus de SLA. Tout naturellement, une SLA plus élevée apporte une meilleure disponibilité au service attendu.

Prenons en exemple la SLA des machines virtuelles créées sur Azure. Cette SLA dépend par exemple des performances des disques rattachés à la machine virtuelle :

Le choix de disques plus performant est une chose facile à comprendre et à mettre en place. Elle est donc la une première démarche à effectuer pour renforcer la résilience.

Quelle SLA dans le cadre d’un Azure Virtual Desktop ?

Azure Virtual Desktop s’appuie lui aussi sur des machines virtuelles Azure. Microsoft propose le un tableau comparant les cinq types de disques disponibles pour vous aider à choisir celui que vous allez utiliser selon votre scénario d’utilisation :

Disque UltraSSD Premium v2SSD PremiumSSD StandardHDD Standard
Type de disqueSSDSSDSSDSSDHDD
ScénarioCharges de travail gourmandes en E/S, telles que le système SAP HANA, les bases de données de niveau supérieur (par exemple, SQL et Oracle), et autres charges de travail très lourdes en transactions.Charges de travail de production et sensibles aux performances qui nécessitent systématiquement une latence faible, des IOPS et un débit élevéCharges de travail de production et sensibles aux performancesServeurs web, applications d’entreprise peu utilisées et Dev/TestSauvegarde, non critique, accès peu fréquent

Microsoft vous recommande donc de créer vos machines virtuelles AVD avec des disques Premium SSD, et cela pour trois raisons :

  • SLA de haut niveau, 99.9 %, indispensable pour environnement de production.
  • Performances élevées, bande passante et IOPS satisfaisantes.
  • Rapport qualité / prix en intégrant les coûts transactionnels dans son prix mensuel fixe.

Dans le cadre d’un pool de machines virtuelles AVD avec des disques Premium SSD, la SLA est alors à 99.9 % pour chacune d’elle.

Un autre paramètre rentre en ligne de compte pour renforcer la SLA de machines virtuelles : Nombre de machines virtuelles jouant un rôle identique :

Qu’est-ce qu’un Groupe à haute disponibilité ?

Un Groupe à haute disponibilité est un regroupement logique d’au moins deux machines virtuelles, de manière à fournir une application hautement disponible et à répondre aux exigences du niveau de 99,95 % inscrit dans les contrats de niveau de service Azure. Le groupe à haute disponibilité proprement dit ne vous coûte rien ; vous payez uniquement pour chaque instance de machine virtuelle que vous créez.

Microsoft Learn

Deux notions importantes sont alors configurables grâce à cette fonctionnalité d’Azure :

  • Domaine de mise à jour : regroupe des machines virtuelles pouvant être mises à jour et donc potentiellement redémarrées en même temps. Le redémarrage des domaines de mise à jour effectue un redémarrage que sur un seul un seul domaine à la fois. (Max 20 domaines de mise à jour par Groupe à haute disponibilité)
  • Domaine d’erreur : regroupe des machines virtuelles partageant une source d’alimentation et réseau en commune. Cela a pour effet de limiter l’effet des défaillances des équipements physiques, des pannes du serveur et des coupures d’électricité. (Max 3 domaines d’erreur par Groupe à haute disponibilité)

Autrement dit, Azure vous permet de positionner gratuitement vos machines virtuelles dans un Groupe à haute disponibilité, de telle sorte que si l’une d’entre-elles rencontre des difficultés ou une mise à jour Azure, une continuité de service de votre application est assurée via la disponibilité garantie des autres machines virtuelles.

Dans le cas d’un environnement Azure Virtual Desktop, certains services critiques peuvent alors être répartis sur plusieurs Groupes de disponibilité. Par exemple :

  • Groupe de disponibilité 1 : Les machines virtuelles dédiées au pool d’hôtes AVD
  • Groupe de disponibilité 2 : Les machines virtuelles dédiées au domaine AD

Qu’est-ce que les Zones de disponibilité ?

Un schéma est souvent plus clair que de longues explications. Voici un empilement hiérarchique du Cloud Microsoft. Chaque service Azure est défini par toutes ces strates ici présentes.

Les géographies d’Azure n’ont pas d’impact direct sur les architectures déployées dans le Cloud. Il faut juste garder en tête qu’une géographie Azure regroupe plusieurs régions Azure.

Le niveau le plus important à retenir est bien la Région Azure. Le Cloud de Microsoft est réparti sur environ une soixantaine de régions Azure. La plupart de ces régions Azure forment une paire de 2 régions. Cette liaison forte apporte des services spécifiques, comme le but d’accroitre les capacités de de reprise après sinistre.

Enfin, de plus en plus de régions Azure disposent de plusieurs Zones de disponibilité :

Les Zones de disponibilité Azure sont des emplacements physiquement séparés au sein de région Azure, qui sont tolérants aux défaillances de centre de données en raison de l’infrastructure redondante et de l’isolation logique des services Azure.

Microsoft Learn

L’intérêt de disposer de lieux géographiques séparés de plusieurs kilomètres, voir dizaines de kilomètres, est d’apporter une meilleure résilience que celle générée via les Groupes à haute disponibilité, toujours présent dans un seul site physique, pour faire face à des sinistres de grande envergure.

A titre d’information, les zones de disponibilité sont disponibles dans la région Azure Suisse Nord depuis mai 2022.

Afin de garantir un haut niveau de performance, Microsoft signale que l’impact sur la latence d’une architecture Azure répartie sur plusieurs Zones de disponibilité est minime voire nul, et cela grâce à une latence inférieure à deux millisecondes entre ces zones.

Il est possible de combiner les Zones de de disponibilité avec les Groupes à haute disponibilité.

Microsoft met également à disposition un outil graphique intéressant sur les composantes de l’infrastructure Azure afin d’en savoir un peu plus :

Comme pour presque tous les articles dédiés Azure Virtual Desktop, voici différents tests pour en évaluer l’impact dans le déploiement de vos ressources.

Etape 0 : Rappel des prérequis

Des prérequis sont nécessaires pour réaliser ces démonstrations AVD :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un réseau virtuel existant sur Azure

La mise en place d’une notion de disponibilité doit se faire lors de la création des machines virtuelles. Il n’est plus possible d’agir dessus une fois les machines virtuelles déployées. Cela est donc paramétrable uniquement :

  • Lors de la création du pool d’hôtes AVD
  • Lors de l’ajout de nouvelles machines virtuelles à un environnement AVD existant.

Test A : AVD + Groupe à haute disponibilité

Commencez par déployer un pool d’hôtes AVD grâce à la barre de recherche du portail Azure :

Tapez « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.

Remplissez le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

L’option ci-dessous nous invite à préciser la notion de disponibilité voulue. Choisissez ici Groupe à haute disponibilité :

Cliquez comme ceci pour en créer un nouveau Groupe à haute disponibilité :

Spécifiez le nom et les nombres de domaines de mise à jour et d’erreurs voulus :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez également un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez le Groupe à haute disponibilité dont elles dépendent :

Consultez l’ensemble des informations de votre Groupe à haute disponibilité en recherchant directement cette ressource Azure depuis votre groupe de ressources :

Ses paramétrages de base ne sont malheureusement plus modifiables :

L’ajout de nouvelle machines virtuelles à votre pool d’hôtes AVD avec ce même Groupe à haute disponibilité est toujours accessible.

La répartition des machines virtuelles est toujours faite en round-robin (équitable)

Finalement, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend bien en charge la répartition des machines virtuelles du pool d’hôtes dans un Groupe à haute disponibilité.

Continuons maintenant avec un second test dédié aux Zones de disponibilité.

Test B : AVD + Zones de disponibilité

Là encore, nous allons commencer par déployer un second pool d’hôtes AVD. Repartez depuis la barre de recherche du portail Azure pour accéder au service AVD :

Tapez « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.

Remplissez là encore le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

Choisissez dans le même menu déroulant Zones de disponibilité, puis sélectionnez les 3 Zones disponibles dans la région Suisse Nord :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez là encore un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre second déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez la Zone de disponibilité dont elles dépendent :

A l’inverse du Groupe à haute disponibilité, il n’existe pas de ressource Azure symbolisant la Zones de disponibilité. Là encore, plus aucun paramétrage n’est modifiable après création.

Ici aussi, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend lui aussi en charge la répartition des machines virtuelles du pool d’hôtes dans plusieurs Zones de disponibilité.

Remarque importante

Une différence subtile existe les Groupes à haute disponibilité et les Zones de disponibilité. Le premier est bien un groupe dont sont associées plusieurs machines virtuelles, tandis que le second est une affectation d’une machine virtuelle à un datacenter (zone) spécifique.

Au final, pour que ces deux services Azure fassent sens dans votre architecture :

  • Je n’ai besoin que d’un seul groupe à haute disponibilité pour plusieurs VMs
  • J’ai besoin de plusieurs zones de disponibilité pour plusieurs VMs

Pourquoi cette précision ?

Car il arrive souvent qu’un doute s’installe sur lesquelles et combien de ces ressources (Groupe à haute disponibilité / Zones de disponibilité) sont nécessaires.

Conclusion

Azure Virtual Desktop continue de progresser en automatisation et en simplicité de déploiement. Le fait que de plus en plus de régions Azure disposent de Zones de disponibilité est une très bonne nouvelle pour la résilience des services Cloud. Enfin Dean de l’Azure Academy nous en reparle en détail dans cette vidéo 😎😎

Conditionnez l’accès de votre AVD

Je souhaitais faire cet article depuis quelques temps déjà. Comme pour les autres services disponibles sur le Cloud Microsoft, Azure Virtual Desktop nécessite une sécurité renforcée. Hors de question de laisser un accès ouvert aux applications de l’entreprise avec un simple identifiant / mot de passe.

Dans cet article, nous allons commencer par reprendre quelques bases sur l’accès conditionnel disponible sur Azure AD. Puis nous allons le mettre en oeuvre dans un environnement Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel proposé par Azure AD ?

Tous les environnements informatiques sont quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers d’un hébergeur Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations à gérer pour la sécurité IT.

Le périmètre de sécurité moderne s’étend désormais au-delà du réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations peuvent utiliser des signaux d’identité dans le cadre de leurs décisions de contrôle d’accès.

Microsoft Doc

Pour cela, Microsoft propose d’intégrer dans le processus d’authentification à Azure AD de nouvelles étapes, sous forme de police :

Le schéma ci-dessus est une vue simplifiée des 3 étapes du processus d’accès conditionnel.

Signal : pour Azure AD, l’accès conditionnel repose sur un certain nombre de signaux ou paramètres. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :

  • Emplacement (adresse IP)
  • Appareil (OS, version, conformité, …)
  • Utilisateur Azure AD
  • Application interrogée
  • IA (Détection des risques en temps réel par Azure AD Identity Protection)

Décision : la décision sera alors le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est question ici de bloquer l’accès à l’utilisateur, ou de l’autoriser selon les conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :

  • Exiger une authentification multifacteur (cas plus utilisé)
  • Exiger que l’appareil soit marqué comme conforme
  • Exiger un appareil joint en hybride à Azure AD
  • Exiger une stratégie de protection des applications

Application : apporte une supervision des sessions et des accès utilisateur aux applications en fonction des stratégies d’accès et de session, telles que :

  • Empêcher l’exfiltration des données
  • Protéger lors du téléchargement
  • Empêcher le chargement de fichiers sans label
  • Bloquer les programmes malveillants potentiels
  • Surveiller les sessions utilisateur pour la conformité
  • Bloquer l’accès

Quelles sont les licences nécessaires pour l’accès conditionnel d’Azure AD ?

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Azure AD Premium P1. Cela est donc bien différent des offres disponibles pour disposer de l’authentification multifacteur (Challenge MFA).

Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

  • Azure AD Premium P1
  • Azure AD Premium P2
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 Business Premium
  • Microsoft 365 A3
  • Microsoft 365 A5
  • Microsoft 365 F1
  • Microsoft 365 F3
  • Microsoft 365 F5 Security
  • Microsoft 365 F5 Security + Compliance

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :

Certains services clients ne sont actuellement pas capables de limiter les avantages à des utilisateurs spécifiques. Des efforts doivent être déployés pour limiter les avantages du service aux utilisateurs sous licence.

Doc Microsoft

Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.

Voici un autre tenant Azure ne disposant d’aucune licence.

Comment l’accès conditionnel est vécu par un utilisateur ?

Une fois l’accès conditionnel mis en place via une police, la sécurité est immédiatement renforcée par l’application de celle-ci. L’image ci-dessous montre en exemple une authentification multifacteur déployée par ce mécanisme pour protéger le portail Azure :

L’accès au portail Azure est conditionné à une authentification multifacteur pour cet utilisateur : challenge MFA.

L’absence de réponse entraîne alors un blocage dans le processus d’authentification et donc de l’accès au portail Azure pour l’utilisateur :

En alternative, si l’utilisateur ne peut pas utiliser cette méthode, Il lui est malgré tout possible de continuer le processus d’authentification par une autre mesure disponible dans la double authentification :

Les réussites ou les échecs des connexions d’utilisateurs sont directement visibles dans le journal des connexions de l’utilisateur sur Azure AD :

Un clic sur une authentification affiche alors les détails et l’application de la police utilisée :

Essai I : Absence de règle d’accès conditionnel

Le premier essai que nous allons faire repose sur aucune configuration particulière.

L’accès au service Azure Virtual Desktop se fait en HTML 5 via l’URL officielle. L’accès conditionnel marcherait également avec les applications installées sur le poste en local, comme le client Remote Desktop, disponible ici au téléchargement.

Aucun blocage ni contrainte pour l’utilisateur n’est constaté :

La sécurité y est donc minimale et l’obtention du login et du mot de passe par un tier permet de se connecter à son environnement et d’accéder aux données.

Essai II : Mise en place d’une règle de blocage total

Le second essai nécessite la création d’une police d’accès conditionnel. Connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu de la Sécurité :

Rentrez dans la section d’Accès conditionnel :

Créez votre nouvelle Police :

Saisissez un nom à votre police et sélectionnez votre utilisateur de test :

Cherchez l’application Azure Virtual Desktop dans la section suivante :

Définissez la décision sur Bloquer l’accès :

Activez votre police et validez sa création :

Attendez quelques minutes et retester l’accès à Azure Virtual Desktop sur votre utilisateur. Pour information, l’accès conditionnel d’Azure AD dispose d’une fonction Et Si pour tester vos règles avant de les appliquer :

Quelques minutes plus tard, le test de connexion nous montre que blocage est bien effectif pour cet utilisateur :

Les conditions d’authentification sont bien réunies, mais ici l’utilisateur n’a tout simplement par le droit de se connecter à AVD.

Essai III : Mise en place d’une règle pour exiger la MFA

Retournez sur votre accès conditionnel et cliquez sur votre police pour la modifier :

Modifiez la décision pour autoriser l’accès à Azure Virtual Desktop, sous réserve d’un succès au challenge MFA par votre utilisateur de test :

Retentez la connexion à Azure Virtual Desktop avec votre utilisateur de test. La modification MFA de la police est bien prise en compte ici :

Dans mon cas, l’utilisateur est alors invité à enregistrer une ou des méthodes pour le challenge MFA pour poursuivre cette nouvelle opération d’authentification. L’application Microsoft Authenticator est proposée en tant que première méthode du challenge à configurer :

Il est possible de choisir une autre méthode.

La méthode MFA choisie est immédiatement vérifiée pour éviter un blocage ultérieur :

Essai IV : Mise en place d’une règle pour bloquer la connexion autre qu’au bureau

La restriction ou le blocage d’un service comme Azure Virtual Desktop est possible selon la localisation de l’utilisateur par son adresse IP. Retournez sur votre police pour la modifier comme ceci :

Pensez à créer votre location de confiance, en reprenant votre propre IP publique :

Retentez la connexion de votre utilisateur à AVD et constatez l’absence de blocage ou de challenge MFA :

Un contrôle dans le journal des connexions nous montre bien le processus d’exclusion de la police d’accès conditionnel grâce à mon adresse IP publique, exclue :

Essai V : Mise en place d’une règle pour exiger le challenge MFA toutes les heures

La mémorisation constante du challenge MFA sur une poste peut être considérée comme un risque sécuritaire, spécialement si le poste est en accès libre pour différents utilisateurs.

Retournez sur votre police pour la modifier comme ceci :

Effectuez l’authentification de votre utilisateur et réussissez le challenge MFA :

Validez la présence des icônes et attendez une heure. Une heure plus tard, rafraîchissez votre AVD :

Une MFA est bien redemandée après le délai défini dans la police d’accès conditionnel.

Conclusion :

Grâce à l’accès conditionnel d’Azure AD, il est assez facile de renforcer la sécurité d’Azure Virtual Desktop. Comme toujours, Microsoft rappelle les risques encourus à seulement utiliser un login et mot de passe pour seule sécurité. L’excellente vidéo de Dean nous montre cela en détail :

En espérant que cela a pu vous aider à mieux sécuriser votre environnement Cloud 😎

Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on

Après ces quelques chaudes semaines d’été, il est pour nous l’occasion de nous replonger dans Azure Virtual Desktop et ses dernières nouveautés. Comme vous le savez peut-être, AVD repose sur une authentification d’Azure AD, potentiellement combinée avec un Active Directory classique. Cette méthode apporte une couche de sécurité dans l’accès au service grâce aux mesures de protections disponibles sur Azure AD.

Dans cet article, nous allons nous intéresser au Single Sign-on, ou Authentification Unique, dans Azure Virtual Desktop à travers une première méthode de gestion des identités Cloud : Azure AD. Enfin, nous finirons ce billet par un rapide troubleshooting concernant cette évolution, encore en préversion à l’heure où les lignes de cet article sont écrites.

Avant de commencer, voici un rappel de la définition du Single Sign-on par Wikipédia :

L’authentification unique, souvent désignée par le sigle anglais SSO est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.

Wikipédia

Rappel de l’existant

Afin de bien comprendre l’évolution du SSO dans Azure Virtual Desktop, l’authentification utilisateur s’effectue en deux étapes. Voici un rappel du processus depuis le client Windows Remote Desktop utilisé pour AVD, disponible ici :

Première authentification Azure AD (ou serveur AD FS si besoin) :

Seconde authentification pour l’ouverture de la session Windows :

La mémorisation du mot de passe de session Windows est bien disponible via la case à cocher ci-dessous, mais elle pose un souci de sécurité. Il ne s’agit pas ici de SSO mais d’un classique stockage de mot de passe en local. En effet, le mot de passe sera alors sauvegardé sur le Credential Manager de Windows :

Sur un ordinateur partagé, cela rendrait simplement l’accès à Azure Virtual Desktop ouvert à tous !

Microsoft travaille depuis déjà pas mal de temps sur du SSO pour Azure Virtual Desktop. L’excellente vidéo ci-dessous faite il y a quelques mois par Dean Cefola de l’Azure Academy nous montre son processus de mise en place, mais uniquement si l’infrastructure dispose d’un Active Directory avec un serveur AD FS :

Comment faire du SSO sans serveur AD FS ?

C’est dans ce cas précis que la nouveauté de Microsoft intervient ! Une nouvelle option RDP vient de se faire son apparition sur Azure Virtual Desktop. Cette option apporte le SSO de manière 100% native. Petit rappel toujours utile, voici la liste des propriétés RDP acceptées par AVD.

Comme pour presque tous les articles de ce blog, nous allons détailler le processus de mise en place de cette nouvelle fonctionnalité d’AVD :

Etape 0 : Rappel des prérequis

Cette fonctionnalité d’AVD est encore en préversion. Nous allons donc partir d’un environnement Azure vierge et y installer un environnement AVD joint à Azure AD. Voici la courte liste des composants déjà présents sur mon environnement de test :

  • Tenant Azure
  • Souscription Azure valide

Etape I : Création du réseau virtuel

Dans un environnement vide, il faut donc commencer par la création d’un réseau virtuel :

Dans mon exemple de test, je ne modifie pas l’adressage réseau :

Attendez que la création se termine pour continuer :

Etape II : Déploiement d’Azure Virtual Desktop

Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :

Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.

La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI :

Il n’est toujours pas possible de stocker les métadatas d’AVD sur un centre de données en Suisse.

Le choix de l’image Windows utilisée pour Azure Virtual Desktop a son importance ! Actuellement, la fonctionnalité de préversion du SSO repose sur une modification de l’OS Windows, et n’est pour l’instant déployée que sur la version 22H2 de Windows 11 :

La suite des options concernant les machines virtuelles AVD ne changent pas :

  • Type de domaine à joindre : Choisissez Azure Active Directory
  • Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.

La création de l’espace de travail ne change pas :

Lancez la création et attendez plusieurs minutes :

Une fois le déploiement terminé, constatez la présence des ressources suivantes dans le groupe de ressources :

Etape III : Affectation des utilisateurs AVD

Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou groupes pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par le groupe d’application AVD :

Il est aussi possible de passer par l’attribution d’un rôle RBAC pour cette même opération :

Etape IV : Ajout des rôles RBAC

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles AVD jointes à Azure AD, l’attribution d’un rôle RBAC spécifique est nécessaire. Affectez les deux rôles RBAC suivants sur le groupe de ressources :

  • Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
  • Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Etape V : Implémentation de la fonctionnalité SSO

Retournez sur votre pool d’hôtes afin de profiter très facilement de cette nouvelle fonctionnalité :

La sauvegarde de cette option impacte les arguments RDP affichés dans l’onglet Avancé :

Pensez bien à sauvegarder 😎.

Un clic sur la session RDP vous affiche toujours la demande d’authentification de la session Windows :

Lancez un rafraîchissement pour mettre à jour les options RDP :

Retentez l’opération de connexion RDP pour voir cette nouvelle fenêtre apparaître :

Confirmez votre identité :

Acceptez la demande d’autorisation pour autoriser les connexion RDP :

Il semble que cette demande soit valable pour une machine du pool uniquement.

La session Windows 11 devrait alors s’ouvrir :

Retentez l’opération une seconde fois pour vérifier le bon fonctionnement du SSO 😎

Conclusion

On peut dire que Microsoft a fait le maximum pour simplifier les choses concernant le déploiement de cette nouvelle fonctionnalité AVD ! D’autres articles suivront pour tester les autres cas de gestions des identités via Active Directory.

Encore merci à Dean pour cette annonce et sa vidéo sur le sujet.

Troubleshoot

Depuis l’apparition de cette nouvelle fonctionnalité, je me suis retrouvé embêté dans le déploiement d’environnements AVD joint à Azure AD et sous Windows 10/11 sans utiliser cette nouvelle option.

En effet, mes utilisateurs de test n’étaient plus en mesure de passer l’authentification de la session Windows :

La faute revient à l’impossibilité de remettre l’ancien argument RDP suivant dans ma configuration RDP, comme indiqué dans mon premier article sur le sujet.

targetisaadjoined:i:1

Voici le message d’erreur en question sur mon AVD depuis le portail Azure :

😒

La solution

Pour contourner ce blocage, il est nécessaire de passer cet argument RDP targetisaadjoined:i:1 via une commande PowerShell :

$properties = "drivestoredirect:s:*;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:*;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;use multimon:i:1;targetisaadjoined:i:1"

Update-AzWvdHostPool -ResourceGroupName toto-rg -Name toto-hp -CustomRdpProperty $properties

Retournez sur votre client Remote Destop et lancez un rafraîchissement :

Et sa refonctionne !

YOUPIIII !!

En espérant que cela a pu vous aider 😁

Programmez la mise à jour de l’agent AVD

La maintenance informatique est une fenêtre nécessaire dans laquelle un service est volontairement indisponible et annoncé en amont. Les architectures basées sur des services Azure n’échappent pas à cette règle car il est toujours nécessaire d’effectuer des maintenances régulières pour des sauvegardes, des mises à jour, des refontes, des réplications, …

Dans cet article, nous allons nous intéresser une nouvelle fonctionnalité disponible sous Azure Virtual Desktop. Encore en préversion à l’heure où ces lignes sont écrites, elle permet de gérer les périodes de mise à jour des agents AVD sur les machines virtuelles qui composent votre pool d’hôtes.

Qu’est qu’un agent AVD ?

Un environnement Azure Virtual Desktop est composée d’une ou plusieurs machines virtuelles. Pour que la communication entre le contrôleur de structure Azure et ces dernières soit assurée, un agent est présent sur chaque machine virtuelle. Un tour dans les programmes installés nous montre tout cela :

L’installation de ces agents est entièrement transparente si la création de la machine virtuelle est réalisée depuis le portail Azure. Si vous créez la machine virtuelle via un script PowerShell, vous devrez alors télécharger et installer manuellement les fichiers MSI.

Quand est-ce que l’agent AVD est mis à jour ?

Avant l’apparition de cette nouvelle fonctionnalité, l’agent AVD se mettait à jour à son rythme sans logique particulière. A ce ceci près qu’il existait une option ayant un impact sur le rythme de mise à jour : environnement de validation.

Qu’est-ce que l’environnement de validation ?

Nous (Microsoft) vous recommandons vivement de créer un pool d’hôtes de validation dans lequel les mises à jour de service seront appliquées en premier. Les pools d’hôtes de validation vous permettent de superviser les mises à jour de service avant que celui-ci ne les applique à votre environnement standard ou de non-validation. Sans pool d’hôtes de validation, vous risquez de ne pas détecter les modifications qui génèrent des erreurs, ce qui peut entraîner des temps d’arrêt pour les utilisateurs de votre environnement standard.

Microsoft Doc

Autrement dit, la mise à jour est orientée en premier lieu vers les pools d’hôtes marqués comme environnement de validation. Une fois la mise à jour déployée avec succès en grand nombre sur des environnements de validation, elle est aussi installée sur les machines virtuelles d’environnements AVD de production.

De manière générale, un environnement de validation a tout son sens dans une solution de bureau à distance car il apporte une couche supplémentaire de tests via des utilisateurs spécifiques et évite ainsi un déploiement pouvant provoquer un blocage massif.

Mises à jour planifiées de l’agent

Toujours dans la volonté d’apporter une meilleure maîtrise de l’environnement Azure Virtual Desktop, Microsoft introduit la fonctionnalité de planification. Celle-ci ne concerne que la mise à jour de l’agent AVD présent sur les machines virtuelles du pool d’hôtes.

Comme vous allez le voir dans les écrans ci-dessous, cette option se configure au niveau du pool d’hôtes et impacte alors toutes les machines virtuelles rattachées de la même manière.

Via le portail Azure, rendez-vous sur votre pool d’hôtes et cliquez sur Mises à jour programmées des agents :

Cliquez sur la case ci-dessous pour activer la gestion manuelle des mises à jour :

Il vous est alors possible de définir une ou deux fenêtres de maintenance. Comme indiqué sur la page, 4 tentatives de mise à jour seront effectuées avant que celle-ci soit reportée la prochaine fois que les hôtes de session seront allumés.

Commencez par définir le fuseau horaire. Vous avez le choix entre celui employé par la machine virtuelle ou un parmi la liste déroulante :

Définissez le jour et l’heure de la première fenêtre de mise à jour :

Ajoutez au besoin une seconde fenêtre de mise à jour :

Enfin cliquez pour appliquer la configuration :

Et c’est tout ! 💕

Conclusion

Azure Virtual Desktop continue son chemin et évolue en permanence 😊. Pour rester sur ce sujet, retrouvez la vidéo très bien expliquée faite par Dean de l’Azure Academy. Dean y aborde également la possibilité de consulter l’historique des mises à jour installées via l’utilisation du Log Analytics Workspace d’Azure :