1.     Prérequis

• 1 Pool AVD + Workspace Fonctionnel. Les tests décrits ici sont dans un fonctionnement avd Entra Join (Pour un fonctionnement avec DC, la partie des zones DNS et à créer sur le(s) contrôleur(s) de domaine).
• Entra P1 minimum
• Ordinateurs de travail enrôlés dans intune + entra join
• 1 licence Microsoft Entra Private Access par utilisateur souhaitant se connecter via GSA
• 1 serveur sur le même Vnet Azure que les AVD (Serveur qui servira de connecteur GSA)

2.     Préparation du connecteur GSA

Sur Entra : aller dans le menu Accès Global sécurisé -> Connecteurs et capteurs pour aller télécharger l’exécutable.

Sur le serveur qui servira de connecteur (Attention, ce serveur doit être impérativement dans le même Vnet que les ressources que vous souhaitez atteindre via GSA)

Lancer l’exécutable et laisser par défaut

De retour dans Entra, au niveau des connecteurs, vous constatez que votre serveur est attaché au groupe « Default ». Personnellement je préfère créer un groupe de connecteur dédié. Il suffit de cliquer sur « Nouveau Groupe de connecteurs » dans la page des Connecteurs et capteurs.

Donner un Nom à votre groupe et associer directement le connecteur ajouté précédemment

Cliquer sur Enregistrer.

3.     Paramétrage du Pool AVD et Workspace en Privé

Sur Votre Pool AVD dans les Paramètres -> Réseau, l’accès public est actuellement Activé

Dans un premier temps Aller sur le menu « Shortpath RDP » puis Désactiver « les 2 Shortpath RDP pour les réseaux publics (sinon il y’aura une erreur lors du passage en privé !)

Puis revenir sur « Accès public » et désactiver l’accès public

Enfin, aller sur le menu « Connexions de point de terminaison privé » et cliquer sur « Nouveau point de terminaison privé »

Sélectionner, votre abonnement Azure, Groupe de ressource pour le déploiement, et donner un nom :

Suivant

Suivant, sélectionner le Réseau virtuel et le sous réseau ainsi que si IP statique ou dynamique attribué aux Endpoint privés.

Suivant, Ici, dans notre cas nous allons créer et intégrer à une zone DNS privé sur Azure. Comme dit dans les prérequis, si vos avd sont joint à un DC, sélectionner Non ici.

Suivant, créer.

Maintenant, nous allons aller sécurisé le workspace. Aller sur votre espace de travail AVD puis dans le menu paramètres -> Réseau et désactiver l’accès public.

Aller sur le menu « Connexions de point de terminaison privé » et cliquer sur « Nouveau point de terminaison privé ». ici nous allons en créer 2 , un en mode de connexion « Feed » et l’autre en mode de connexion « Global »

Nous allons commencer par le « Feed » Sélectionner, votre abonnement Azure, Groupe de ressource pour le déploiement, et donner un nom (je mets Feed dans le nom personnellement pour plus de lisibilité par la suite) :

Suivant puis sélectionner Sous-ressouce cible :  « feed »

Suivant, sélectionner le Réseau virtuel et le sous réseau ainsi que si IP statique ou dynamique attribué aux Endpoint privés

Suivant, Ici, dans notre cas nous allons créer et intégrer à une zone DNS privé sur Azure. Comme dit dans les prérequis, si vos avd sont joint à un DC, sélectionner Non ici.

Suivant, Vérifier créer et Créer.

Et on recommence avec « Global », donc de retour dans les paramètres réseau de votre Workspace, Ajouter une nouvelle connexion de point de terminaison (au passage, veuillez noter que le Endpoint Feed est bien créé) :

Sélectionner, votre abonnement Azure, Groupe de ressource pour le déploiement, et donner un nom (je mets Global dans le nom personnellement pour plus de lisibilité par la suite) :

Suivant puis sélectionner Sous-ressouce cible :  « global »

Suivant, sélectionner le Réseau virtuel et le sous réseau ainsi que si IP statique ou dynamique attribué aux Endpoint privés

Suivant, Ici, dans notre cas nous allons créer et intégrer à une zone DNS privé sur Azure. Comme dit dans les prérequis, si vos avd sont joint à un DC, sélectionner Non ici.

Suivant, Vérifier créer et Créer.

4.     Tests depuis serveur connecteur GSA et externe

Premier test à faire : depuis un ordinateur externe vérifier que votre Workspace n’apparait plus dans « Windows App ». Pour plus de clarté, j’utilise en parallèle « Remote Desktop » même si il n’est plus maintenu

Ensuite, faire un test sur le serveur qui fait « Connecteur GSA » :

Je lance la connexion sur un avd du Pool :

Notre Pool AVD et notre workspace sont bien privés et accessible, pour le moment uniquement depuis le réseau virtuel Azure.

5.     Paramétrage de GSA pour accès sécurisé sur le Pool AVD hors vnet

De retour dans Entra, aller dans le paramétrage Global Secure Access sur entra -> Menu Application -> Application d’entreprise. 

Puis renseigner un Nom, le Groupe de connecteurs (Attention, il faut sélectionner le groupe où se trouve votre connecteur GSA) :

Pour les segments, nous allons voir cela Après Enregistrer et retourner dans le Menu Global Secure Access sur entra -> Menu Application -> Application d’entreprise. 

Cliquer sur votre application, puis dans Utilisateurs et groupes, affecter les personnes qui pourront accéder à GSA-AVD, pour notre test seul Benoit y aura accès

Pour les Segments, vous pouvez les retrouver dans le menu de votre application (GSA-AVD pour notre test) dans le menu « Propriétés d’accès réseau ».

Un Segment d’application est tout simplement une IP, nom FQDN que GSA va intercepter et donc transférer le Traffic vers notre connecteur GSA (donc notre serveur srv-gsa) et pouvoir ainsi  se connecter à des ressources du Vnet.

Pour connaitre les FQDN a créer pour les connexions AVD, il faut aller noter toutes les entrées DNS de notre 3 Endpoint (1 sur le pool et 2 sur le Workspace) créés !

Pour ce faire, dans azure, il va falloir aller sur ces 3 Endpoint :

Prenons l’exemple avec AVDGSA-PE : Noter tous les FQDN dans un fichier texte ou autre pour que cela soit plus simple :

Faire de même sur les 2 autres Endpoint.

Une fois cela fait, retourner dans Entra -> Accès global sécurisé -> application -> Application d’entreprise -> votre application (ici GSA-AVD) -> Propriétés d’accès réseau

Ensuite pour chaque enregistrement FQDN, créer un nouveau segment de type « Nom de domaine complet » :

Exemple avec « rdweb.privatelink-global.wvd.microsoft.com »

Sur toute la liste ne pas ajouter les 3 enregistrements globaux :

• rdweb.wvd.microsoft.com
• www.wvd.microsoft.com
• client.wvd.microsoft.com

Pour tout le reste en fonction de ce que l’enregistrement contient :

* (ou Protocole UDP si vous souhaitez utiliser UDP Shotpath)

Type de FQDN	Ports recommandés	Protocole
*.privatelink-global (rdweb/www/client)	443	TCP
<workspaceID>.rdweb.* (public + privatelink)	443	TCP
<hostpoolID>.rdbroker.*	1-65535	TCP
<hostpoolID>.rdgateway-* / afdfp-rdgateway-*	1-65535	TCP
<hostpoolID>.rddiagnostics.*	1-65535	TCP
	Si Shortpath	Mettre le protocole UDP

Ce qui donne en partie :

6.     Installation du client GSA sur un ordinateur enrôlé

Pour installer le client (Attention, il faut que l’ordinateur soit Entra-join !) 

1. Aller dans https://entra.microsoft.com 
2. Menu « Accès Global Sécuriser » -> « Se connecter » -> « Téléchargement du client » 
3. Sélectionner votre client 

4. Installation sur le poste utilisateur final 

Une fois installé, Le client apparait dans la barre des tâches à côté de l’heure. 

Pour vérifier son état, il suffit de cliquer dessus et de vérifier le statut ainsi que le Channels « Private » 

Pour vérifier jusqu’au bout les droits utilisateurs finals : aller dans le client GSA sur  

Dans le menu « Forwarding » è Rules è Private access rules 

Vous devez voir les règles (Segments) créées. Si vous ne les voyez pas, vérifier que l’utilisateur est autorisé sur l’application GSA ! 

Si les règles n’apparaissent toujours pas, vérifier dans Entra -> Accès Global Sécurisé -> Transfert du trafic : le profil d’accès privé doit être activé

7.     Test accès AVD via GSA

Une fois la vérification faite et le client GSA connecté, lancer Windows App (idem je le fais également avec le client Remote Desktop

Le Workspace apparait bien.

Test de connexion :

Donc le fonctionnement est ok. La seule chose à retenir : si je me déconnecte du client GSA la connexion est maintenue ; cependant si vous fermer la session et tenter une reconnexion, cela ne fonctionnera pas 

Pourquoi la session survit quand nous coupons GSA

Le rôle de GSA est surtout au moment de l’établissement de la connexion

GSA, via son client, fait deux choses :

1. Il intercepte la résolution DNS des FQDN AVD (via la NRPT et les IP synthétiques 6.6.x.x) ;
2. Il route le flux vers le connecteur privé au moment où la connexion s’établit.

Une fois que la session TCP est établie et orchestrée par la Gateway, le flux de session s’appuie sur une connexion déjà négociée. Le rôle critique de GSA -> la résolution DNS et l’aiguillage initial a déjà été joué.

Quand le client GSA est déconnecté :

La session TCP existante est déjà montée

• Pas de nouvelle résolution DNS nécessaire (session en cours)
• Le socket reste établi
• La session AVD se maintient