Attendu depuis longtemps par la communauté Azure Virtual Desktop, Azure AD Join est enfin là ! Lancé il y a seulement quelques jours en public preview, la possibilité de se passer d’un Active Directory pour environnement AVD permet d’envisager certains projets avec une architecture 100% Cloud. Dans cet article, nous allons voir ensemble cette fonctionnalité et les bénéfices apportés par cette dernière.
Point important : cette amélioration pose un souci pour l’utilisation de la gestion des profiles via FSLogix, car l’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la gestion des identités Azure AD.
Introduction
Gestion des identités sur Azure Virtual Desktop : Rappel de l’existant
Jusqu’à présent, un environnement Azure Virtual Desktop (anciennement Windows Virtual Desktop) nécessitait de joindre les machines virtuelles Azure à un domaine Active Directory. Ce domaine pouvait provenir d’un Windows Server, ayant le rôle d’Active Directory sur un machine virtuelle Azure, ou via le service de domaine managé Azure AD DS.
Qu’est-ce qu’un périphérique joint à Azure AD ?
La jonction Azure AD est destinée aux organisations axées en priorité ou uniquement sur le cloud. Toute organisation peut déployer des appareils joints Azure AD, quels que soient leur taille et leur secteur d’activité. La jonction Azure AD fonctionne même dans un environnement hybride et permet l’accès aux applications et ressources locales et cloud
Documentation Microsoft
Attention, il est possible de joindre des machines en Windows 10 à Azure AD, à l’exception de Windows 10 Famille.
Cette jointure à Azure AD est prévu à l’origine pour des entreprises ne disposant pas d’une infrastructure Windows Server Active Directory locale.
Dans le cas contraire, il est malgré tout possible de fonctionner de manière hybride. L’avantage sera de protéger les appareils Windows 10, tout en conservant l’accès aux ressources locales qui nécessitent une authentification locale. Dans ce cas précis, nous parlerons alors des machines jointes à Azure AD hybride. Ces appareils sont joints à votre annuaire Active Directory local et à votre Azure AD.
Pourquoi se passer d’un contrôleur de domaine pour AVD ?
Le premier argument est le coût ! Beaucoup de projets Azure Virtual Desktop sont petits et concernent un petit nombre d’utilisateurs en Remote Desktop. L’ajout d’un domaine sur des VMs ou via un domaine managé augmente la facture environ plus une centaine d’euros par mois .
Enfin, la gestion des machines AVD peut également se faire via Intune (Endpoint Manager). Que vous utilisiez des machines virtuelles partagées ou individuelles pour AVD, Intune peut gérer les deux ????Un précédent article en parle et explique le processus d’intégration sur Intune pour les machines AVD partagées ici.
Déploiement d’un AVD utilisant Azure AD
On y est ! On va détailler ici, étapes par étapes, la création d’un environnement Azure Virtual Desktop en ne disposant d’aucun domaine Active Directory en place. Pour rappel, à l’heure où ces lignes sont écrites, la fonctionnalité de jointure avec Azure AD est toujours en public preview.
Etape I : Création du réseau virtuel
Habituellement, le réseau virtuel hébergeant AVD est déjà présent par le domaine existant. Dans un environnement vide, il faut donc commencer la création de celui-ci en premier :
La configuration de la plage réseau et des sous-réseaux ne change pas d’un projet classique AVD. Dans mon exemple rapide, on ira au plus simple :
Une fois la création du réseau virtuel terminée, je peux passer à la création de mon environnement Azure Virtual Desktop.
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 pour réussir la jointure avec Azure AD :
Note : l’assignement de type automatique dans le cadre de machines virtuelles individuelles va directement affecter ces dernières aux personnes se connectant à AVD dans la mesure où ces utilisateurs y sont autorisés.
Dans l’onglet des machines virtuelles, je défini les options relatives à ces dernières. Aucune particularité concernant la jointure avec Azure AD dans la première partie :
La copie d’écran ci-dessous concernant Azure AD et connaît une évolution sur deux points :
- Type de domaine à joindre : il est maintenant possible de choisir 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.
Plus besoin ici de renseigner un login du domaine.
La création de l’espace de travail ne change pas par rapport aux environnements AVD classiques :
Une fois tous les champs correctement renseignés, il ne reste plus qu’à lancer la création des ressources :
Une fois la création terminée, nous pouvons constater les ressources suivantes dans notre groupe de ressources :
Etape III : Affectation des utilisateurs
Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou des groupes d’utilisateurs pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par ici :
Etape IV : Ajout d’un argument RDP
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :
targetisaadjoined:i:1
Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :
drivestoredirect:s:;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;enablecredsspsupport:i:1;use multimon:i:1;targetisaadjoined:i:1
Etape V : Ajout des rôles RBAC
Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :
- 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 VI : Test de la solution côté utilisateur via Remote Desktop
Une fois les étapes précédentes terminées, il ne reste plus qu’à tester le bon fonctionnent de la solution. Cela se fait en téléchargeant le client Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible là)
Application Remote Desktop
L’écran ci-dessous nous emmène sur l’environnement Azure Virtual Desktop. Ici se trouvent tous les espaces de travail affectés à l’utilisateur, dans lesquels se trouvent toutes les applications (Remote Desktop ou Remote Apps) affectées à l’utilisateurs :
Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :
Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 10 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :
Etape VII : Test de la solution côté utilisateur via HTML 5
Il est également possible de se connecter à Azure Virtual Desktop via un navigateur internet. Pour rappel, la page d’accès est la suivante : aka.ms/wvdarmweb :
On se retrouve alors, de la même manière que précédemment, sur une page donnant accès aux espaces de travail et aux applications :
Etape VIII : Vérifications Azure Virtual Desktop
Vérification de la jointure sur la machine virtuelle
Afin de regarder plus en détail cette jointure, la commande dsregcmd /status sur la machine virtuelle AVD nous en dit plus :
Vérification de l’ajout des machines virtuelles dans Azure AD
Les machines virtuelles créées par Azure Virtual Desktop sont bien retranscrites dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :
Vérification de l’ajout des machines virtuelles dans Intune
Comme j’ai coché la gestion des machines virtuelles AVD via la solution Intune, je retrouve bien mes machines virtuelles dans la console de cette dernière (lien ici)
Vérification du pool d’hôtes d’Azure Virtual Desktop
Comme cet exemple reposait sur un environnement AVD avec des machines virtuelles individuelles, je retrouve bien sur chacune un utilisateur assigné :
Etape IX : Gestion des erreurs liées à la jointure avec Azure AD
Il est possible de rencontrer des erreurs lors du déploiement de cet environnement AVD, en jointure avec Azure AD. Pour vous aider, Microsoft met à votre disposition cette page d’aide. Voici quelques exemples d’erreurs possibles :
Les machines virtuelles sont bien déployées, mais elles sont encore marquées comme indisponibles, plusieurs minutes après le déploiement d’AVD :
>> Avez-vous bien marqué à OUI la case de validation de l’environnement ?
Erreur de mot de passe de l’ouverture de la session RDP : « The logon attempt failed »
>> Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :
- Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
- Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
- Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session
La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :
Conclusion
Comme à chaque fois, Dean de l’Azure Academy nous met à disposition une vidéo très explicative sur tout le processus de cette nouvelle fonctionnalité d’Azure Virtual Desktop :
On attend bien évidemment avec impatience la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????
