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 :
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 :
La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI :
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é :
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 :
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.
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:1Voici 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 $propertiesRetournez sur votre client Remote Destop et lancez un rafraîchissement :
Et sa refonctionne !
En espérant que cela a pu vous aider ????