05 · Planifier et mettre en œuvre l'identité et la sécurité d'Azure Virtual Desktop

Version : 1.1 · Date : 2026-10-22 · Domaine 2 : Plan and implement identity and security (15–20 %)

En une phrase : une connexion AVD enchaîne trois authentifications (le service, le session host, la session) qu'on protège avec Microsoft Entra ID, Conditional Access et le single sign-on, puis on durcit le session host lui-même : rôles Azure RBAC au plus juste, Defender for Cloud et Defender for Endpoint en mode VDI, réseau sans aucun flux entrant, administration par Bastion ou JIT, App Control, Controlled Folder Access et Trusted launch.

Ce chapitre ne répète pas les bases d'identité et de sécurité Azure, déjà traitées ailleurs : Conditional Access et les authentication strengths (SC-500 01), NSG et Azure Firewall (SC-500 06), Bastion, JIT et Trusted launch (SC-500 08), la conception des stratégies (SC-300 05). Il se concentre sur ce qui est propre à AVD : les applications à cibler, le join des session hosts, les rôles Desktop Virtualization, le mode VDI des agents Defender, les flux réseau du service.

Ce que l'examen demande#

Compétences 2.1 Plan and implement identity integration et 2.2 Plan and implement security du guide d'étude AZ-140 (compétences au 20/07/2026) :

1. Les trois authentifications d'une connexion#

Une connexion AVD n'est pas une seule authentification, mais trois, chacune avec ses méthodes et ses pièges :

Deux règles conditionnent tout le reste :

• Les utilisateurs doivent exister dans Microsoft Entra ID. Une identité présente seulement dans AD DS n'est pas prise en charge : AD DS doit être synchronisé (Microsoft Entra Connect Sync ou Cloud Sync).
• En hybride, l'utilisateur Entra et l'utilisateur AD doivent correspondre : même UPN, ou même SID (attribut OnPremisesSecurityIdentifier). Ne pas se connecter au session host avec une autre identité que celle utilisée pour le service.

2. Choisir le scénario d'identité#

2.1 Les combinaisons prises en charge#

Points qui tombent à l'examen :

• Un host pool = un seul type de join : ne pas mélanger des VM Entra joined et AD DS joined dans le même host pool.
• Cloud-only n'est possible qu'avec des session hosts Microsoft Entra joined.
• Entra Domain Services : la synchronisation exige le password hash sync depuis Entra ID ; les VM jointes à Entra DS ne peuvent pas être hybrid joined ; le SSO Microsoft Entra n'est pas pris en charge.
• Fournisseur d'identité fédéré tiers : possible si les session hosts sont Entra joined ou hybrid joined et que l'authentification Microsoft Entra (SSO) est activée.
• Identités externes : session hosts Entra joined, SSO activé, Windows 11 24H2 avec KB5065789 (ou Windows Server 2025 avec KB5073379), connexion par Windows App. Les comptes Microsoft personnels et B2B ne servent pas au domain join.

2.2 Choisir en trois questions#

flowchart TD
    A[Les utilisateurs ont-ils un compte AD DS ?] -->|Non, cloud-only| E[Session hosts Microsoft Entra joined]
    A -->|Oui| B[Faut-il des GPO, Kerberos ou NetApp Files sur les hosts ?]
    B -->|Non| E2[Microsoft Entra joined + Intune<br/>Kerberos server object pour les ressources locales]
    B -->|Oui| C[Garder un AD DS géré par l'équipe ?]
    C -->|Oui| D[AD DS joined]
    C -->|Non| F[Microsoft Entra Domain Services joined]

Le stockage des profils selon l'identité est détaillé au chapitre 02 · 5.

3. Préparer les session hosts selon le scénario#

3.1 Les prérequis par type de join#

Le compte de domain join est utilisé de façon non interactive : il ne doit pas être soumis à la MFA ni à une stratégie Conditional Access qui l'exige. Le stocker dans Key Vault quand le déploiement le permet, jamais en clair dans un template.

3.2 Les compléments pour les VM Microsoft Entra joined#

• Rôle de connexion : pour un host pool sans session host configuration, attribuer Virtual Machine User Login aux utilisateurs (et Virtual Machine Administrator Login aux administrateurs) sur les VM, le resource group ou l'abonnement. Avec une session host configuration, cette attribution n'est plus nécessaire. Microsoft conseille le même groupe que celui de l'application group, au niveau du resource group.
• Clients non joints au même tenant (Mac, iOS, Android, web, PC personnel) sans SSO : ajouter la propriété RDP targetisaadjoined:i:1. La connexion se limite alors au nom d'utilisateur et mot de passe. Avec le SSO, ce n'est plus nécessaire.
• MFA : désactiver la MFA par utilisateur (legacy per-user MFA) pour les comptes concernés, sinon l'erreur The sign-in method you're trying to use isn't allowed apparaît ; passer par Conditional Access (section 5).
• Ressources locales : un Entra joined n'a pas besoin d'AD pour fonctionner, mais il lui faut une ligne de vue vers AD et le SSO avec Kerberos server object pour accéder aux partages et applications Kerberos.

3.3 Déploiement : ce que demande le portail#

Dans l'onglet Virtual machines de la création du host pool, la section Domain to join propose Microsoft Entra ID (avec la case Enroll VM with Intune) ou Active Directory (domaine, OU, compte de join). Le security type (section 15) et le choix du NSG (section 12) se règlent dans le même onglet.

4. Azure RBAC pour Azure Virtual Desktop#

4.1 Les rôles intégrés#

AVD sépare la gestion par objet : host pool, application group, workspace. Il n'y a pas de rôle Owner propre à AVD (on utilise Owner générique).

Pour déployer un host pool avec session host configuration, l'administrateur a besoin au minimum de Desktop Virtualization Contributor, Virtual Machine Contributor et Key Vault Secrets User (secrets du compte de join et de l'administrateur local).

4.2 Les bonnes pratiques#

• Attribuer Desktop Virtualization User à un groupe sur l'application group, jamais un par un.
• Donner les rôles d'exploitation au plus petit périmètre : User Session Operator sur le host pool du helpdesk, pas au resource group.
• Les rôles Power On (Off) Contributor vont au service principal Azure Virtual Desktop (ou à la managed identity du host pool), pas aux personnes : Power On à l'abonnement ou au resource group des VM, Power On Off à l'abonnement (autoscale ne fonctionne pas correctement à une portée plus basse).
• Les rôles AVD ne donnent aucun droit dans Windows : les administrateurs locaux se gèrent à part (section 7).

4.3 Mise en œuvre#

Portail : Azure Virtual Desktop › Application groups › ag-desktop › Assignments › + Add (crée le rôle Desktop Virtualization User), ou Access control (IAM) pour les autres rôles.

# Accès des utilisateurs : rôle Desktop Virtualization User sur l'application group
$ag = Get-AzWvdApplicationGroup -Name 'ag-desktop' -ResourceGroupName 'rg-avd'
New-AzRoleAssignment -ObjectId '{groupObjectId}' -RoleDefinitionName 'Desktop Virtualization User' -Scope $ag.Id

# Helpdesk : opérations de session sur un seul host pool
$hp = Get-AzWvdHostPool -Name 'hp-pooled' -ResourceGroupName 'rg-avd'
New-AzRoleAssignment -ObjectId '{helpdeskGroupId}' -RoleDefinitionName 'Desktop Virtualization User Session Operator' -Scope $hp.Id

# Autoscale : le service principal Azure Virtual Desktop peut démarrer et arrêter les VM (portée abonnement obligatoire)
az role assignment create --assignee "9cdead84-a844-4324-93f2-b2e6bb768d07" \
  --role "Desktop Virtualization Power On Off Contributor" \
  --scope "/subscriptions/{subscriptionId}"

5. Conditional Access pour Azure Virtual Desktop#

5.1 Les applications à cibler#

Dans les sign-in logs du client web, la connexion apparaît sous l'App ID a85cf173-4192-42f8-81fa-777a763e6e2c.

5.2 La stratégie recommandée#

Prérequis : Microsoft Entra ID P1 (P2 pour le risque), security defaults désactivés (incompatibles avec Conditional Access), comptes d'urgence exclus.

1. Stratégie 1 : Users = groupe des utilisateurs AVD ; Target resources = Azure Virtual Desktop ; Grant = Require multifactor authentication ou une authentication strength (phishing-resistant de préférence) ; Session = Sign-in frequency (par exemple 8 heures).
2. Stratégie 2, si le SSO est activé : même groupe, Target resources = Windows Cloud Login, mêmes contrôles, même fréquence. C'est la seule où Every time a du sens (par exemple pour réauthentifier à chaque ouverture de session host, avec une tolérance de 5 à 10 minutes).
3. Tester en Report-only, puis vérifier dans les sign-in logs (onglet Conditional Access) avant d'activer.

Autres contrôles utiles :

5.3 Les erreurs classiques#

6. Les méthodes d'authentification#

6.1 Vers le service (étape ①)#

Toutes les méthodes Microsoft Entra sont possibles : passwordless (Windows Hello for Business, passkeys FIDO2, Microsoft Authenticator), certificate-based authentication pour les smart cards (CBA), mot de passe + MFA, fédération. Le choix se pilote dans Authentication methods et s'impose par Conditional Access.

6.2 Vers le session host (étape ②)#

KDC proxy : pour les utilisateurs distants qui ouvrent la session avec une smart card sans ligne de vue vers les DC. On installe le rôle (RD Gateway, Windows Server 2016+) puis on ajoute dans les RDP properties du host pool, onglet Advanced : kdcproxyname:s:{fqdn}.

6.3 Dans la session (étape ③)#

• WebAuthn redirection : les demandes WebAuthn de la session (sites, apps) sont redirigées vers le poste local, qui utilise Windows Hello ou une clé FIDO2. Activée par défaut (redirectwebauthn:i:1) ; mettre 0 pour la couper. La méthode passkey (FIDO2) doit être activée dans Entra ID.
• Smart card redirection : pilotes de la carte installés sur le session host, propriété redirectsmartcards:i:1 (défaut). Quand Intune ou GPO et la propriété RDP se contredisent, le réglage le plus restrictif gagne.

# Exemple : garder WebAuthn, désactiver la redirection de smart card (la chaîne remplace toutes les propriétés personnalisées)
Update-AzWvdHostPool -ResourceGroupName 'rg-avd' -Name 'hp-pooled' `
  -CustomRdpProperty 'enablerdsaadauth:i:1;redirectwebauthn:i:1;redirectsmartcards:i:0'

7. Rôles, groupes et droits sur les session hosts#

Les rôles Azure RBAC (section 4) donnent l'accès au service. Les droits dans Windows (administrateur local, groupes locaux, droits utilisateur) se gèrent séparément, selon le type de join.

7.1 Les administrateurs locaux#

Pièges documentés :

• Les groupes Microsoft Entra déployés par la stratégie Local user group membership ne s'appliquent pas aux connexions Remote Desktop : pour ces droits, ajouter le SID de l'utilisateur.
• Windows évalue au plus 20 groupes Microsoft Entra pour les droits d'administration.
• Administrator protection de Windows 11 n'est pas pris en charge sur AVD : rester en Legacy Admin Approval Mode.

7.2 Les règles de sécurité#

• Aucun utilisateur administrateur local sur un host pool pooled : il pourrait lire les sessions des autres. Un administrateur qui en a besoin reçoit un host pool personal.
• Pas d'installation de logiciel par les utilisateurs en multi-session : publier les applications par Intune ou App Attach (chapitre 07 · 6).
• Des utilisateurs d'organisations différentes : tenant et abonnement séparés, pas seulement des host pools séparés.
• Accès aux fichiers locaux et distants par ACL au moindre privilège.

8. Microsoft Entra single sign-on#

Le SSO remplace la deuxième saisie du mot de passe par un jeton émis par Microsoft Entra ID pour l'app Windows Cloud Login. Il rend possibles le passwordless et les fournisseurs fédérés jusqu'au session host.

8.1 Prérequis#

• Rôle Application Administrator ou Cloud Application Administrator pour configurer le service principal.
• Session hosts Microsoft Entra joined ou hybrid joined (pas AD DS seul, pas Entra DS), sous Windows 11, Windows 10 avec la mise à jour cumulative 2022-10, ou Windows Server 2022.
• Approbation bidirectionnelle si les utilisateurs et les session hosts sont dans des domaines AD différents.
• Microsoft Graph PowerShell SDK 2.9.0 ou plus.

8.2 Les cinq étapes#

1. Activer l'authentification Microsoft Entra pour RDP sur le service principal Windows Cloud Login (portail : Entra ID › Devices › Remote connection configuration, ou PowerShell ci-dessous).
2. Masquer l'invite de consentement (Allow remote desktop connection?, qui retient 15 hôtes pendant 30 jours) : ajouter jusqu'à 10 groupes d'appareils cibles (un groupe dynamique demande P1).
3. Créer un Kerberos server object dans AD si les session hosts sont hybrid joined (obligatoire), ou s'ils sont Entra joined et doivent accéder à des ressources AD. C'est le même mécanisme que Microsoft Entra Kerberos.
4. Revoir les stratégies Conditional Access : ajouter Windows Cloud Login (section 5).
5. Activer la propriété RDP du host pool : RDP Properties › Connection information › Microsoft Entra single sign-on = Connections will use Microsoft Entra authentication to provide single sign-on, soit enablerdsaadauth:i:1.

# Étapes 1 et 2 avec Microsoft Graph PowerShell (session interactive de l'administrateur, aucun secret)
Connect-MgGraph -Scopes 'Application.Read.All','Application-RemoteDesktopConfig.ReadWrite.All'
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId   # IsRemoteDesktopProtocolEnabled : True

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = '{deviceGroupObjectId}'
$tdg.DisplayName = 'grp-avd-sessionhosts'
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

8.3 Comportements à connaître#

• Verrouillage de session : avec le SSO, le verrouillage déconnecte la session par défaut (l'écran de verrouillage Windows ne sait pas valider un jeton Entra). Ce comportement se règle (session lock behavior).
• Comptes Domain Admins : bloqués par la Password Replication Policy du Kerberos server object (objet RODC) ; ils ne bénéficient pas du SSO Kerberos.
• Le SSO est obligatoire pour les identités externes (section 2.1) et évite targetisaadjoined sur les VM Entra joined.

9. Microsoft Defender for Cloud#

Les session hosts sont des VM Azure : Defender for Cloud les évalue comme les autres serveurs. Le détail des plans est dans SC-500 08.

9.1 Ce qu'il faut activer#

9.2 La licence Defender for Endpoint en multi-session#

Réponse attendue à l'examen (page Onboard Windows devices in Azure Virtual Desktop) : pour Windows Enterprise multi-session, la VM est licenciée par Defender for Servers, ou bien tous ses utilisateurs par une licence utilisateur : Defender for Endpoint Plan 1 ou 2, Windows Enterprise E3/E5, Microsoft 365 E3/E5 ou Microsoft Defender Suite.

État actuel : à partir du 1er novembre 2026, Defender for Servers Plan 1 ne facture plus comme serveurs les OS client, Windows Enterprise multi-session compris : ils relèvent d'une licence Defender for Endpoint (notes de version Defender for Cloud, septembre 2026). Defender for Cloud indique déjà que MDE ne s'applique pas aux machines sous OS client sans licence utilisateur. Dans tous les cas, les session hosts Windows 10/11 s'intègrent par l'onboarding VDI (section 11).

9.3 Gérer la posture#

• Secure Score et recommandations : EDR installé, vulnérabilités corrigées, mises à jour système, Secure Boot, vTPM et Guest Attestation sur les VM Trusted launch (section 15).
• Defender Vulnerability Management : inventaire logiciel et vulnérabilités, à corriger dans l'image (mise à jour mensuelle de l'image de référence, chapitre 04 · 7) plutôt que VM par VM.
• Regulatory compliance et la baseline de sécurité Azure Virtual Desktop du Microsoft cloud security benchmark.
• Alertes dans Defender for Cloud, investigation dans le Microsoft Defender portal.

10. Microsoft Defender Antivirus#

10.1 La configuration VDI recommandée#

Configuration par GPO (Computer Configuration › Administrative Templates › Windows Components › Microsoft Defender Antivirus), par Intune (Endpoint security › Antivirus) ou par PowerShell.

10.2 Les exclusions FSLogix#

Sans exclusions, l'antivirus analyse les VHD(X) de profils au montage et ralentit l'ouverture de session.

# Exclusions FSLogix (profils sur Azure Files) : à pousser par GPO ou Intune en production
Add-MpPreference -ExclusionProcess '%ProgramFiles%\FSLogix\Apps\frxsvc.exe','%ProgramFiles%\FSLogix\Apps\frxccds.exe'
Add-MpPreference -ExclusionPath '%TEMP%\*\*.VHD','%TEMP%\*\*.VHDX','%Windir%\TEMP\*\*.VHD','%Windir%\TEMP\*\*.VHDX',
  '\\{storageAccount}.file.core.windows.net\{share}\*\*.VHD','\\{storageAccount}.file.core.windows.net\{share}\*\*.VHDX'
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess

11. Microsoft Defender for Endpoint#

11.1 Persistant ou non persistant#

11.2 L'onboarding VDI non persistant#

1. Dans le Microsoft Defender portal (rôle Security Administrator) : Settings › Endpoints › Device management › Onboarding, système Windows 10 and 11, méthode VDI onboarding scripts for non-persistent endpoints, télécharger le paquet.
2. Copier WindowsDefenderATPOnboardingScript.cmd et Onboard-NonPersistentMachine.ps1 dans C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup de l'image.
3. Déclarer Onboard-NonPersistentMachine.ps1 comme script de démarrage PowerShell (stratégie locale ou GPO) : chaque VM s'inscrit à son premier démarrage, sous une entrée unique par nom d'appareil.
4. Ne jamais exécuter l'onboarding sur l'image dorée elle-même : toutes les VM hériteraient du même identifiant de capteur. Si l'image a été inscrite par erreur, la désinscrire (offboarding), vérifier le service (sc query sense) et nettoyer avant de la capturer.
5. Vérifier dans Assets › Devices : la première remontée peut prendre plusieurs heures.

11.3 Les options d'analyse#

Defender for Endpoint en multi-session suit les connexions de chaque utilisateur. Garder les exclusions FSLogix côté antivirus et EDR activé : l'EDR ne remplace pas l'antivirus, il le complète.

12. Sécurité réseau : NSG, UDR et Azure Firewall#

12.1 Le principe : reverse connect#

Le session host ouvre lui-même une connexion sortante vers le service AVD ; l'utilisateur se connecte au service, pas à la VM. Aucun port entrant n'est nécessaire, ni IP publique sur les session hosts. L'architecture réseau complète (Private Link, RDP Shortpath, hub-spoke) est au chapitre 01 · 4.

12.2 Les flux sortants obligatoires des session hosts#

L'outil Azure Virtual Desktop Agent URL Tool (WVDAgentUrlTool.exe, installé avec l'agent) vérifie l'accès à chaque URL ; l'événement 3701 du journal WVD-Agent liste les URL bloquées.

12.3 NSG#

• Aucune règle entrante à ouvrir pour AVD. Le choix Basic du portail qui propose des « public inbound ports » est à laisser vide.
• En sortie, si l'on restreint, autoriser au minimum WindowsVirtualDesktop, AzureActiveDirectory, AzureMonitor en 443, puis le reste via Azure Firewall.
• RDP Shortpath for managed networks avec listener (connexion directe depuis le réseau privé) demande UDP 3390 (port par défaut, modifiable) entrant depuis les plages des clients internes ; les variantes ICE/STUN n'ont besoin d'aucun port entrant (chapitre 01 · 5).

12.4 Azure Firewall et UDR#

Microsoft publie un modèle de stratégie prêt à l'emploi (AzureFirewallPolicyForAVD). Le reste d'Azure Firewall (règles DNAT, Premium, Firewall Manager) est dans SC-500 06.

# UDR : le trafic AVD sort directement, le reste passe par le Firewall (exemple pour un abonnement de test)
az network route-table route create -g rg-avd-net --route-table-name rt-sessionhosts \
  -n default-to-fw --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address {firewallPrivateIp}
az network route-table route create -g rg-avd-net --route-table-name rt-sessionhosts \
  -n avd-direct --address-prefix WindowsVirtualDesktop --next-hop-type Internet

13. Accès d'administration : Azure Bastion ou JIT#

Le guide de sécurité AVD demande d'éviter tout RDP direct vers les session hosts. Deux façons d'administrer quand même :

Limites JIT : pas pris en charge derrière un Azure Firewall géré par Firewall Manager ; nom de la stratégie + nom de VM ≤ 56 caractères. SKU, prérequis réseau et droits de Bastion : SC-500 08 · 3 ; JIT pas à pas : SC-500 08 · 4.

Bonnes pratiques propres à AVD :

• Passer d'abord le session host en drain mode (rôle Session Host Operator) avant une intervention, pour ne pas y envoyer de nouvelles sessions.
• Pour un session host Microsoft Entra joined, l'administrateur se connecte avec son compte Entra (rôle Virtual Machine Administrator Login ou administrateur local géré par Intune), jamais avec le compte local partagé : Windows LAPS pour ce dernier.
• Pour une image pooled, corriger l'image et redéployer plutôt que modifier une VM à la main.

14. Windows threat protection : App Control for Business et Controlled Folder Access#

14.1 Pourquoi c'est indispensable sur AVD#

RemoteApp n'est pas une frontière de sécurité : publier seulement Excel n'empêche pas l'utilisateur de lancer d'autres exécutables présents sur le session host. Pour n'autoriser que les applications voulues, on utilise le contrôle d'applications de Windows.

14.2 App Control for Business ou AppLocker#

Démarche : créer la stratégie depuis un session host de référence, la déployer en audit, lire le journal CodeIntegrity/Operational (événement 3076 en audit, 3077 en blocage), ajuster, puis passer en enforced, par vagues de host pools.

14.3 Controlled Folder Access#

Controlled Folder Access (CFA) fait partie de la réduction de surface d'attaque de Microsoft Defender : seules les applications fiables (ou explicitement autorisées) peuvent modifier les fichiers des dossiers protégés (Documents, Images, Bureau…). C'est une protection anti-ransomware. Elle exige la protection en temps réel de Defender Antivirus.

# Test sur un session host de lab : audit d'abord, puis Enabled ; en production, Intune (Endpoint security › Attack surface reduction)
Set-MpPreference -EnableControlledFolderAccess AuditMode
Add-MpPreference -ControlledFolderAccessProtectedFolders 'D:\Projets'
Add-MpPreference -ControlledFolderAccessAllowedApplications '%ProgramFiles%\Fabrikam\App\app.exe'
Get-MpPreference | Select-Object EnableControlledFolderAccess, ControlledFolderAccessProtectedFolders

Avec les notifications Defender masquées (section 10), les blocages ne sont visibles que dans les journaux et le Defender portal : le prévoir dans le support utilisateur.

14.4 Les autres protections Windows à connaître#

• ASR rules : bloquer les scripts obfusqués, le lancement d'exécutables par Office, etc. (audit puis Block).
• Virtualization-based security, memory integrity (HVCI) et Credential Guard : protègent les secrets de la session (exigent Trusted launch, section 15).
• Network protection et SmartScreen pour Microsoft Edge.
• Screen capture protection et watermarking d'AVD contre la fuite d'écran (chapitre 06 · 8).
• Restreindre les redirections (lecteurs, presse-papiers, imprimantes, USB) selon le besoin : voir chapitre 06 · 5.

15. Trusted launch et confidential VMs#

15.1 Les trois security types#

Trusted launch protège contre les rootkits et bootkits (démarrage vérifié, clés dans le vTPM) et répond aux exigences de Windows 11 : c'est pourquoi c'est le choix par défaut. Defender for Cloud surveille les VM Trusted launch (recommandations Secure Boot, vTPM, Guest Attestation) : détail dans SC-500 08 · 9.

Confidential VM : la mémoire est chiffrée par une clé générée dans le processeur, illisible par l'hyperviseur et l'hôte. Systèmes pris en charge comme session hosts : Windows 11 et 10 Enterprise (single et multi-session), Windows Server 2022 et 2019. Pour les données les plus sensibles (santé, défense, finance).

15.2 Ce qu'il faut prévoir#

• Image Gen2 compatible (Marketplace ou Azure Compute Gallery avec le bon security type, chapitre 04 · 5.2). On ne peut pas convertir une VM non confidentielle en confidential VM.
• Quotas des familles DC / EC et régions disponibles à vérifier avant de dimensionner le host pool.
• Confidential OS disk : clé plateforme ou clé client dans Key Vault ou Managed HSM.
• BitLocker : le guide de sécurité AVD le déconseille sur les disques de profils FSLogix.
• Démarrer les VBS, HVCI et Credential Guard sur ces bases (section 14).

16. Labs conseillés#

À faire dans un abonnement et un tenant de test (essai Microsoft Entra ID P2, essai Defender for Servers de 30 jours), avec un compte d'urgence exclu de toute stratégie.

1. Host pool Entra joined avec SSO et MFA
   • Créer un host pool pooled de 1 VM Windows 11 multi-session, Microsoft Entra ID + Enroll with Intune, Trusted launch.
   • Étapes SSO 1, 2 et 5 (section 8) ; deux stratégies Conditional Access en Report-only puis On.
   • Attendu : une seule invite MFA, pas de deuxième mot de passe ; les sign-in logs montrent Azure Virtual Desktop puis Windows Cloud Login.
2. RBAC au moindre privilège
   • Attribuer Desktop Virtualization User à un groupe sur l'application group, User Session Operator à un compte helpdesk sur le host pool.
   • Attendu : le helpdesk déconnecte une session mais ne peut pas passer le host en drain mode.
3. Defender en mode VDI
   • Activer Defender for Servers Plan 2 sur l'abonnement de test ; ajouter les exclusions FSLogix (section 10.2) ; préparer l'onboarding non persistant dans l'image.
   • Attendu : une entrée unique par session host dans le Defender portal, même après recréation de la VM.
4. Sortie par Azure Firewall
   • Firewall Standard + Firewall Policy avec FQDN tag WindowsVirtualDesktop, UDR 0.0.0.0/0 et UDR WindowsVirtualDesktop → Internet.
   • Lancer WVDAgentUrlTool.exe sur le session host.
   • Attendu : toutes les URL Accessible, session host Available.
5. App Control et CFA en audit
   • Sur le session host de lab, CFA en AuditMode et une stratégie App Control en audit via Intune.
   • Attendu : événements d'audit dans Microsoft-Windows-Windows Defender/Operational et CodeIntegrity, sans blocage.

Coût : Azure Firewall et Bastion sont facturés à l'heure et coûtent le plus cher : les supprimer le jour même. VM en B-series ou D2s, arrêtées (désallouées) entre deux séances. Nettoyage : supprimer les resource groups, les stratégies Conditional Access de test et désactiver les essais.

17. Les pièges d'examen#

18. Scénarios d'entraînement#

1. Contoso a 3 000 utilisateurs synchronisés depuis AD DS, des applications métier qui exigent Kerberos et des GPO. Elle veut aussi Intune à terme. Quel scénario d'identité pour le premier host pool ?

AD DS joined (ou hybrid joined) avec les utilisateurs synchronisés dans Entra ID : GPO et Kerberos fonctionnent tels quels. Pour la suite, un host pool Entra joined + Intune avec SSO et Kerberos server object garde l'accès aux ressources AD.

2. Une filiale cloud-only (aucun AD) doit utiliser AVD avec ses profils FSLogix sur Azure Files. Que configurer ?

Session hosts Microsoft Entra joined (+ Intune), SSO activé, Azure Files avec Microsoft Entra Kerberos pour les profils (identités cloud prises en charge), Conditional Access sur les deux apps.

3. Après déploiement de VM Entra joined dans un host pool classique, les utilisateurs voient leur bureau dans le flux mais la connexion échoue. Le SSO n'est pas activé. Causes possibles ?

Rôle Virtual Machine User Login non attribué (requis sans session host configuration), MFA par utilisateur active, ou client non joint au tenant sans targetisaadjoined:i:1.

4. L'équipe AVD a Desktop Virtualization Contributor sur le resource group mais l'onglet Assignments de l'application group lui renvoie une erreur. Correction minimale ?

Ajouter User Access Administrator au même périmètre (ou limité à l'application group). Contributor gère les objets mais n'attribue pas de rôle.

5. Le helpdesk doit pouvoir envoyer des messages et fermer les sessions bloquées du host pool hp-compta, rien d'autre.

Desktop Virtualization User Session Operator attribué sur le host pool hp-compta (pas au resource group, qui donnerait la lecture de tous les host pools).

6. Le RSSI exige une MFA résistante au phishing pour AVD et une réauthentification à chaque ouverture de session sur un session host. Comment ?

Activer le SSO ; stratégie 1 sur Azure Virtual Desktop avec l'authentication strength Phishing-resistant MFA et une sign-in frequency ; stratégie 2 sur Windows Cloud Login avec les mêmes exigences et Every time. Ne pas cibler l'ARM Provider.

7. Des agents en télétravail doivent ouvrir leur session Windows avec une smart card ; les session hosts sont AD DS joined et les postes n'ont pas de VPN. Que faut-il ?

Un KDC proxy (rôle RD Gateway) joignable depuis Internet, et la propriété RDP kdcproxyname:s:{fqdn} sur le host pool ; pilotes de carte sur les session hosts et smart card redirection active. Client Windows (pas le client web).

8. Les session hosts sont hybrid joined. Le SSO est activé et la propriété RDP aussi, mais les utilisateurs ne peuvent pas ouvrir les partages de fichiers locaux.

Il manque le Kerberos server object dans AD (étape 3 du SSO), obligatoire pour les session hosts hybrid joined. Vérifier aussi la ligne de vue réseau vers les DC.

9. Un host pool pooled est recréé chaque semaine depuis l'image. Le Defender portal affiche des centaines de doublons et plusieurs VM ont le même identifiant de capteur.

L'image a été inscrite : la désinscrire et la nettoyer, puis utiliser le paquet VDI onboarding scripts for non-persistent endpoints avec Onboard-NonPersistentMachine.ps1 en script de démarrage : une entrée unique par appareil.

10. Le trafic des session hosts doit passer par l'Azure Firewall du hub. Depuis la mise en place, des déconnexions surviennent le soir. Que corriger ?

Ajouter sur le subnet une UDR WindowsVirtualDesktop → Internet : le trafic RDP ne passe plus par le Firewall et n'est plus coupé au scale-in. Garder l'application rule FQDN tag WindowsVirtualDesktop, le DNS proxy et aucune inspection TLS.

11. L'exploitation ouvre le port 3389 sur Internet pour dépanner les session hosts. Que proposer ?

Supprimer la règle ; Azure Bastion dans le hub (RDP privé depuis le portail) ou JIT VM access (Defender for Servers Plan 2) ; passer le host en drain mode avant l'intervention ; LAPS pour le compte local.

12. Une banque publie Excel en RemoteApp et découvre que des utilisateurs lancent PowerShell sur les session hosts. Elle veut aussi chiffrer la mémoire des VM qui traitent des données de cartes. Recommandations ?

App Control for Business (managed installer Intune, audit puis enforced, PowerShell en Constrained Language Mode) : RemoteApp n'est pas une frontière de sécurité. Pour la mémoire : host pool en confidential VMs (séries DC/EC, confidential OS disk encryption), image Gen2 compatible, quotas vérifiés.

19. Pour aller plus loin#

• Token Protection dans Conditional Access pour Windows App (sur le poste client), et Global Secure Access sur les session hosts pour étendre les contrôles Zero Trust aux applications privées et Internet, y compris pour les identités externes.
• Microsoft Sentinel et le connecteur Defender XDR pour corréler les connexions AVD et les alertes des session hosts.
• Azure Policy : imposer Trusted launch, interdire les IP publiques sur les subnets AVD, déployer les exclusions Defender.
• Session host update et images mensuelles : la meilleure correction de vulnérabilité en pooled est une nouvelle image (chapitre 04 · 8.2).
• Kerberos RC4 → AES (avril 2026 selon la page FSLogix, juillet 2026 selon la page Azure Files) : passer en AES les comptes de stockage FSLogix joints à AD DS avant la mise à jour (chapitre 02 · 4.2).

20. Fiche à retenir#

• Trois authentifications : service (Entra ID + CA), session host (SSO ou NTLM, smart card), dans la session (WebAuthn, smart card).
• Utilisateurs toujours dans Entra ID ; UPN ou SID identiques en hybride ; cloud-only → Entra joined.
• Un host pool = un type de join ; Entra DS : PHS, pas de hybrid join, pas de SSO Entra ; compte de join non interactif.
• Entra joined sans session host configuration : Virtual Machine User Login ; client non joint sans SSO : targetisaadjoined:i:1.
• Accès utilisateur : Desktop Virtualization User sur l'application group, à un groupe.
• Contributor sans attribution d'utilisateurs → User Access Administrator ; Host Pool Contributor + Virtual Machine Contributor pour créer des VM.
• Helpdesk : User Session Operator (sessions) ou Session Host Operator (drain mode) sur le host pool.
• Service principal AVD : Power On (Start VM on Connect), Power On Off (autoscale), Virtual Machine Contributor (session host configuration).
• CA : Azure Virtual Desktop (9cdead84…) + Windows Cloud Login (270efc09…) ; jamais l'ARM Provider (50e95039…) ; P1 ; pas de security defaults.
• Every time seulement sur Windows Cloud Login ; fréquences alignées ; MFA par utilisateur désactivée.
• Smart card sans ligne de vue DC : KDC proxy (kdcproxyname:s:) ; in-session : redirectwebauthn, redirectsmartcards.
• SSO : 5 étapes, IsRemoteDesktopProtocolEnabled, 10 groupes d'appareils, Kerberos server object en hybride, enablerdsaadauth:i:1, verrouillage = déconnexion.
• Admins locaux Entra joined : rôle Device Local Administrator (tout le tenant) ou Intune Local user group membership (groupes Entra ≠ droits RDP).
• Pas d'admin local en pooled ; organisations différentes = tenants séparés ; LAPS.
• Defender for Servers P1 = MDE, P2 = + JIT, FIM, MDVM premium ; licence MDE multi-session : Defender for Servers ou licence utilisateur (examen), licence utilisateur seule à partir du 01/11/2026.
• Antivirus VDI : shared security intelligence, cache maintenance sur l'image, scans aléatoires, tamper protection, exclusions FSLogix.
• MDE pooled : VDI onboarding non persistant, script de démarrage, une entrée par appareil, jamais sur l'image dorée.
• Réseau : aucun port entrant ; sortie 443 WindowsVirtualDesktop, AzureActiveDirectory, AzureMonitor ; TURN UDP 3478 vers 51.5.0.0/16.
• Azure Firewall : Firewall Policy, DNS proxy, FQDN tag WindowsVirtualDesktop, IP Group, pas de TLS inspection ; UDR WindowsVirtualDesktop → Internet.
• Admin : Bastion ou JIT (Defender for Servers P2) ; drain mode avant intervention.
• RemoteApp ≠ sécurité → App Control for Business (appareil) ou AppLocker (par groupe) ; CFA en audit puis Block.
• Trusted launch par défaut (Secure Boot, vTPM, Gen2) ; confidential VM = mémoire chiffrée, DC/EC, vTPM imposé, pas d'Accelerated Networking.

Références#

Toutes lues le 22/10/2026 sur Microsoft Learn :

• Study guide for Exam AZ-140
• Supported identities and authentication methods
• Prerequisites for Azure Virtual Desktop
• Microsoft Entra joined session hosts in Azure Virtual Desktop
• Configure single sign-on for Azure Virtual Desktop using Microsoft Entra ID
• Enforce Microsoft Entra multifactor authentication for Azure Virtual Desktop using Conditional Access
• Built-in Azure RBAC roles for Azure Virtual Desktop
• Configure a Kerberos Key Distribution Center proxy
• Configure smart card redirection
• Set custom RDP properties on a host pool
• How to manage the local administrators group on Microsoft Entra joined devices
• Account protection policy for endpoint security in Intune
• Security recommendations for Azure Virtual Desktop
• Security and governance for Azure Virtual Desktop (Cloud Adoption Framework)
• Defender for Servers overview
• Defender for Endpoint integration in Defender for Cloud
• Support matrices for Defender for Cloud
• Configure Microsoft Defender Antivirus on a remote desktop or VDI environment
• FSLogix prerequisites: antivirus exclusions
• Onboard non-persistent VDI devices in Microsoft Defender
• Onboard Windows devices in Azure Virtual Desktop
• Required FQDNs and endpoints for Azure Virtual Desktop
• Use Azure Firewall to protect Azure Virtual Desktop deployments
• Enable just-in-time access
• What is Azure Bastion?
• App Control for Business
• Configure controlled folder access
• Trusted launch for Azure virtual machines
• About Azure confidential VMs
• Deploy Azure Virtual Desktop (security type)