AVD/W365 : Redirections basées sur le contexte

Que peut bien dire le titre de cet article ? Vous avez peut être déjà entendu parler des Context-based Redirections à droite à gauche, vous savez vaguement ce dont ça parle, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On va dérouler, écran après écran, jusqu’à voir une redirection (presse-papiers, lecteurs, imprimante, USB…) s’activer pour une machine conforme et se couper net pour une machine non conforme.

Pour rappel, jusqu’ici une politique de redirection sur AVD ou Windows 365 était binaire : si vous bloquiez le presse-papiers (ou les lecteurs, l’USB, l’imprimante), c’était bloqué pour tout le monde, sur tous les appareils : le portable corporate conforme comme le téléphone perso en BYOD. La seule parade, c’était de maintenir deux host pools séparés.

Avec les Context-based Redirections, on peut enfin faire varier la redirection au niveau de chaque connexion, selon la conformité de l’appareil, le réseau, ou le rôle de l’utilisateur. Un seul host pool, deux comportements. C’est du Zero Trust appliqué à la redirection.

Attention : au moment où j’écris ces lignes, la fonctionnalité est en Public Preview. À tester en lab, pas en prod. Et elle n’est supportée que via les clients Windows App (Windows, web, Android, iOS, macOS), le bon vieux mstsc ne participe pas au mécanisme.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. C’est quoi, les Context-based Redirections ?
2. Pourquoi maintenant ? Le durcissement par défaut depuis mi-2025
3. Comment ça marche : l’architecture en 3 couches
4. Pré-requis
5. Étape 0 : Débrayer les restrictions par défaut
6. Étape 1 : Créer le contexte d’authentification (c1)
7. Étape 2 : La policy d’accès conditionnel (les 3 cas)
8. Étape 3 : La policy Remote Connection Experience (et la variante AVD)
9. Pièges & retour terrain
10. Conclusion

1. C’est quoi, les Context-based Redirections ?

Concrètement, ça donne quoi ? C’est une capacité qui applique des politiques d’accès granulaires aux redirections client, en s’appuyant sur un contexte d’authentification Microsoft Entra. L’idée : la redirection n’est autorisée que si la session atteint le niveau de confiance exigé.

La redirection contextuelle permet aux organisations de contrôler le comportement de redirection en fonction des conditions d’utilisateur et de session.

À l’aide du contexte d’authentification, les administrateurs peuvent définir quand des fonctionnalités client spécifiques doivent être autorisées ou restreintes en fonction de facteurs tels que le rôle d’utilisateur, la conformité de l’appareil ou l’emplacement réseau.

Cela permet de s’assurer que les données sensibles sont accessibles uniquement lorsque la session répond au niveau de confiance requis.
Source : Context-based redirections (Preview) — Microsoft Learn

Le point que je veux marteler tout de suite, parce que je vais beaucoup parler du presse-papiers dans la démonstration : la fonctionnalité ne se limite pas au copier-coller. Microsoft documente quatre redirections pilotables par contexte d’authentification :

Clipboard : le presse-papiers (copier-coller texte, image, fichier… dans un sens ou dans l’autre).
Drive : les lecteurs locaux (fixes, amovibles, réseau) remontés dans la session distante.
Printer : la redirection d’imprimante.
USB : la redirection des périphériques USB.

Dans cet article, je teste le clipboard et les lecteurs, tout simplement parce que ce sont les deux redirections que j’avais déjà sous la main, restreintes via mes anciennes polices (j’y reviens juste en dessous). Mais le principe, l’enchaînement des trois couches, la logique d’évaluation à la connexion : tout est rigoureusement identique pour l’imprimante et l’USB. Si vous savez piloter le presse-papiers par contexte, vous savez piloter les quatre. Vous remplacez juste la redirection ciblée dans la dernière couche.

Pour info : la policy Remote Connection Experience expose chacune de ces redirections avec le même menu déroulant. Pour chaque ligne, vous choisissez « activé », « non configuré » ou « contexte d’authentification ». C’est ce dernier choix qui déclenche tout le mécanisme, et il se présente exactement de la même façon que vous soyez sur Clipboard, Drive, Printer ou USB.

2. Pourquoi maintenant ? Le durcissement par défaut depuis mi-2025

Petit détour utile pour comprendre pourquoi cette fonctionnalité tombe à pic. Depuis mi-2025, Microsoft a basculé d’une logique « tout ouvert, à vous de durcir » vers du secure by default : sur les nouvelles images Windows 365 et les nouveaux host pools AVD, les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désactivées nativement. C’est aligné avec la Microsoft Secure Future Initiative (SFI).

J’ai déjà décortiqué ces deux sujets dans le détail, et je vous renvoie à mes articles précédents si vous voulez creuser le sujet :

Configurez le presse-papier dans AVD/W365 : le durcissement par défaut depuis le 18 juin 2025, la logique des deux couches (propriétés RDP côté client + polices GPO/Intune côté serveur), et le détail des niveaux SCClipLevel / CSClipLevel.
AVD : Restriction du Presse-papier : comment restreindre finement le copier-coller via Intune et les propriétés RDP, sens par sens et type de donnée par type de donnée.

Là où le bât blessait : cette restriction par défaut, bien qu’affinée, restait globale :

Au niveau des configurations RDP d’Azure Virtual Desktop :

Au niveau des polices de configuration Intune :

Une fois le presse-papiers (ou les autres) bloqué ou débloqué, il l’était pour toutes les connexions, sans distinction de l’appareil ou du réseau :

C’est exactement le mur que les Context-based Redirections font tomber : on garde la posture « fermé par défaut », mais on rouvre dynamiquement pour les connexions de confiance.

D’où l’enchaînement logique de cet article : on part d’un environnement où la redirection est restreinte, et on la rend conditionnelle :

3. Comment ça marche : l’architecture en 3 couches

C’est LE point à comprendre avant de cliquer partout. Le mécanisme repose sur trois couches qui s’enchaînent :

Le contexte d’authentification : un simple « jeton » d’exigence que l’on définit dans Entra et que l’on « publie ».
La policy d’accès conditionnel (CA) : elle cible ce contexte et impose une exigence (appareil conforme, réseau de confiance, MFA…). C’est elle qui décide si le claim c1 est émis ou non dans le token de session.
La policy Remote Connection Experience (RCE) côté Windows 365 (ou la propriété RDP du host pool côté AVD), qui lie une redirection donnée (clipboard, drive, printer ou USB) au contexte.

La logique de bout en bout, à la connexion :

La redirection est liée à c1 → elle est OFF par défaut, et ne s’allume que si le claim c1 est présent dans le token de session.
Le claim c1 n’est présent que si le step-up d’authentification pour c1 réussit.
Ce step-up réussit si aucune CA ne le bloque, ou si une CA qui le cible est satisfaite.

Mon retour terrain : la CA ne sert qu’à poser des exigences sur l’émission du claim c1. S’il n’y a aucune CA qui cible c1, rien ne bloque → le claim passe → vous avez vos redirections (selon ce que la RCE autorise). Dès qu’une CA cible c1, il faut la satisfaire ; si vous êtes bloqué par elle, le claim n’est jamais émis → redirection coupée. C’est aussi simple que ça, mais ça m’a pris un paquet de tests pour le formuler clairement.

4. Pré-requis

Brique	Ce qu’il vous faut
Poste de travail virtuel	Windows 365 Enterprise (Cloud PC) ou Azure Virtual Desktop
Identité & accès conditionnel	Microsoft Entra ID P1 (minimum) pour le Conditional Access
Gestion des stratégies	Microsoft Intune (config + RCE policy + conformité)
Client de connexion	Windows App (Windows / web / Android / iOS / macOS). Pas `mstsc`.
Image / agent	Cloud PC sur image récente prenant en charge la preview

Pré-requis à valider selon votre déploiement (W365 ou AVD).

5. Étape 0 : Débrayer les restrictions par défaut

Le piège classique, et il est sournois : sur les images récentes de Cloud PC (et les nouveaux pools d’hôtes AVD), les redirections client sont désactivées par défaut :

C’est précisément le durcissement dont je parlais à la section 2. Si vous laissez ça en l’état, vous allez croire que votre conf context-based « bloque bien »… alors qu’en réalité c’est juste le défaut restrictif qui parle. Et surtout : la policy la plus restrictive l’emporte. Tant qu’une stratégie restreint la redirection « en dur », le mécanisme context-based ne pourra jamais l’autoriser.

Si vous utilisez une image de galerie récente pour tester votre PC cloud ou si vous avez des stratégies existantes dans votre environnement qui affectent les redirections, modifiez-les avant le test, car la stratégie la plus restrictive l’emporte.

Par conséquent, vous devez définir les redirections que vous souhaitez tester pour qu’elles soient « non configurées » ou « activées » pour que la redirection basée sur le contexte fonctionne correctement.
Source : Context-based redirections (Preview) — Microsoft Learn

La parade : créer (ou réutiliser) une policy Settings catalog dans Intune qui remet les redirections que l’on veut tester sur Disabled au sens « Do not allow… = Disabled » :

Autrement dit, on désactive la désactivation, donc on autorise. 😅

Dans mon lab, je m’appuie justement sur le groupe et les polices que j’avais montés pour mes articles précédents sur le presse-papiers : c’est mon point de départ « fermé », que je vais rouvrir conditionnellement.

Pas à pas, dans Intune :

Intune → Devices → Manage devices → Configuration → Create → New Policy.
Plateforme : Windows 10 and later ; type de profil : Settings catalog → Create.
Basics : donnez un nom parlant et une description.
Configuration settings → + Add settings.

Pour le presse-papiers, les lecteurs et l’USB : recherchez Device and Resource Redirection, sélectionnez la catégorie, puis cochez les réglages à piloter :

Pour l’imprimante : recherchez Printer Redirection (catégorie distincte) et cochez les réglages voulus :

Basculez chaque réglage « Do not allow… » sur Disabled. On ne veut aucune interdiction « en dur » sur les redirections qu’on va confier au contexte
Scope tags (facultatif) → Next
Assignments : ciblez le groupe qui doit recevoir la policy → Next
Review + create → Create

Une fois la configuration poussée sur le poste, cela nous donne la configuration de registre suivante :

Pour info : sous le capot, ces réglages pilotent les valeurs de registre RDP côté session (par ex. fDisableClip pour le presse-papiers, fDisableCdm pour les lecteurs). « Débrayé à 0 » = redirection autorisée. Si vous voulez le détail de ces clés, des deux couches client/serveur et des niveaux SCClipLevel / CSClipLevel, tout est dans mon article Configurez le presse-papier dans AVD/W365.

6. Étape 1 : Créer le contexte d’authentification (c1)

Première vraie brique du mécanisme. Le contexte d’authentification, c’est ce « jeton d’exigence » qu’on va ensuite cibler depuis la CA et lier depuis la RCE. Pas à pas :

Entra (ou Intune → Devices) → Conditional Access → Authentication contexts
New authentication context
Donnez un nom et une description explicites
Cochez impérativement Publish to apps, puis choisissez une valeur dans le menu ID (ici c1)
Sauvegardez

Attention : si Publish to apps n’est pas coché, vous pourrez bien référencer c1 dans la RCE policy, mais il ne sera jamais sollicité à la connexion. Résultat : la CA reste en « Not Applied » et rien ne se déclenche. C’est l’oubli n°1.

7. Étape 2 : La police d’accès conditionnel (les 3 cas)

C’est ici que se joue la « condition de confiance ». Le squelette est toujours le même : la CA cible le contexte d’authentification c1 (dans Target resources, pas dans les conditions !), et c’est le Grant (ou l’exclusion) qui décide. Je vous donne trois cas de figure que j’ai testés.

Cas n°1 : Exiger un appareil conforme compliant

Le scénario BYOD par excellence : redirection autorisée depuis une machine gérée et conforme, coupée depuis une machine perso non gérée.

Conditional Access → Policies → New Policy :

Donnez un nom, puis des utilisateurs : All users sous Include (ou votre groupe de test) :

Target resources → menu Select what this policy applies to → Authentication context → cochez c1 :

Grant → Grant access → cochez Require device to be marked as compliant → Select.
Enable policy = On → Create.

Cas n°2 : Restreindre par adresse IP (Named location)

Ici on veut : redirection autorisée uniquement depuis un réseau de confiance (votre plage IP publique), coupée ailleurs.

Le point clé à intégrer : une location, c’est une CONDITION, pas un grant. On ne peut pas dire « autorise si IP de confiance ». La bonne logique est inversée : « Bloque c1 partout, SAUF depuis l’IP de confiance ».

D’abord, créez la Named location :

Conditional Access → Named locations → + New location (IP ranges)
Nommez-la et saisissez votre plage IP publique en CIDR (ex. 203.0.113.42/32)
Cochez Mark as trusted location si proposé → Create

Ensuite, la CA :

Users : All users (ou groupe de test)
Target resources → Authentication context → c1
Conditions → Locations : Include = Any location ; Exclude = Loc-Confiance
Grant → Block access → Select
Enable policy = On → Create

Attention : le Conditional Access voit l’IP publique de sortie du client. Derrière un NAT ou un proxy d’entreprise, c’est l’IP du NAT qu’il faut déclarer, pas celle du poste. Et si votre IP est dynamique (box FAI), le test peut « sauter » quand elle change. Élargissez la plage plutôt qu’un /32 figé.

Cas n°3 : Combiner conformité & adresse IP

Pourquoi pas les deux ? Pour exiger à la fois un appareil conforme et un réseau de confiance, deux approches :

Une seule CA : ciblez c1, Grant = Require device to be marked as compliant, ET ajoutez la condition Locations (Include = la location de confiance) pour ne l’évaluer que sur ce réseau. Hors réseau de confiance, prévoyez une seconde CA de blocage.
Deux CA qui ciblent c1 : une exige le compliant, l’autre bloque hors réseau de confiance. Comme toutes les CA ciblant c1 doivent passer, le claim n’est émis que si appareil conforme et sur réseau de confiance.

Mon retour terrain : quand plusieurs CA ciblent c1, elles se cumulent (« most restrictive wins » côté claim). Pour un test propre d’un seul cas, mettez les autres CA ciblant c1 sur Off le temps de l’essai, sinon vous ne saurez plus laquelle bloque.

8. Étape 3 : La police Remote Connection Experience (et la variante AVD)

C’est la couche qui lie une redirection au contexte c1. Côté Windows 365, ça passe par une policy Remote Connection Experience (preview). C’est aussi ici que vous décidez quelle(s) redirection(s) parmi les quatre (Clipboard, Drive, Printer, USB) vous confiez au contexte :

Intune → Devices → Manage Windows 365 Cloud PCs → Cloud PC Settings
Create → Remote Connection Experience (preview) :

Basics : nom et description de la police :

Dans Configuration settings → Device redirections, repérez la redirection à piloter (Clipboard, Drive, Printer ou USB) et choisissez Authentication context: Context-based redirection :
Dans le champ Entra Authentication context qui apparaît, sélectionnez c1.
Laissez les redirections non voulues sur Not configured.

Scope tags (facultatif) → Next :

Assignments → Add groups → sélectionnez un groupe de DEVICES (les Cloud PC), surtout pas un groupe d’utilisateurs → Next :

Review + create → Create :

Veillez à affecter cette stratégie d’expérience de connexion à distance Windows 365 à des groupes d’appareils (PC cloud), et non à des groupes d’utilisateurs.

La redirection basée sur le contexte étant appliquée au niveau de l’appareil, l’attribution de la stratégie aux utilisateurs n’applique pas le comportement de redirection attendu.
Source : Context-based redirections (Preview) — Microsoft Learn

Et sur AVD ?

Pas de RCE policy : la liaison se fait dans les propriétés RDP du host pool. Dans l’onglet Device redirection, au lieu d’un toggle activé/désactivé, vous choisissez « Dynamically configure using authentication context » et sélectionnez le contexte. La logique d’évaluation à la connexion est la même qu’en Windows 365.

9. Pièges & retour terrain

Le piège qui m’a rendu fou : la persistance du token Windows App : Windows App garde un token de session en cache. Tant que ce token vit, le résultat du step-up c1 (présent ou absent) est figé dedans. Vous pouvez changer la CA et la RCE mille fois, la session en cours ne réévalue rien. Il faut un token frais : vraie déconnexion/reconnexion. Ne perdez pas trois heures comme moi à modifier des policies : reconnectez-vous avec une session neuve.

Client non supporté : avec mstsc / Bureau à distance legacy, c1 n’est jamais demandé. Passez par Windows App.
Assignation RCE sur des users : la RCE/context-based s’applique au device. Assignée à un groupe d’utilisateurs, elle ne fait rien. Groupe de devices (Cloud PC) obligatoire.
« Publish to apps » oublié sur le contexte d’authentification → c1 jamais sollicité → CA « Not Applied ».
Restrictions par défaut non débrayées → « most restrictive wins » → la redirection reste coupée quoi que vous fassiez.
Direction du clipboard : le binding porte sur une direction précise (ex. « clipboard local disponible dans la session distante » = copie sur votre PC → colle DANS le Cloud PC). Testez bien la direction que vous avez liée à c1.
Propagation lente : comptez quelques minutes côté CA, et au premier déploiement la RCE peut nécessiter un redémarrage du Cloud PC avant d’être prise en compte.

10. Conclusion

Voilà, comment en 4 étapes, on est passé d’un Cloud PC tout neuf à une redirection dynamique qui s’adapte à la confiance de la connexion. Concrètement, ça donne quoi ? Un seul host pool / une seule conf, et la redirection (presse-papiers, lecteurs, mais aussi imprimante et USB sur exactement le même modèle) qui s’ouvre pour les machines conformes (ou sur le bon réseau) et qui se ferme pour le reste.

Le rêve du BYOD sans compromis. J’ai testé le clipboard et les lecteurs, mais gardez bien en tête que les quatre redirections se pilotent à l’identique : c’est la même mécanique de bout en bout.

Foncez tester en lab, c’est clairement l’une des évolutions sécurité les plus utiles de l’année sur AVD / Windows 365. Einfin pour aller plus loin : quelques lectures qui complètent bien le sujet, et que je vous recommande :

Context-based redirections (Preview) : la doc officielle Microsoft Learn, la source de vérité sur les quatre redirections pilotables.
Context-based redirection in Azure Virtual Desktop and Windows 365 — a practical guide (modern-euc.com) : un guide pas-à-pas très complet sur le même sujet.
Azure Virtual Desktop Introduces Context-Based Redirections — Big Hat Group (Kevin Kaminski) : la mise en perspective Zero Trust et BYOD, avec l’historique du durcissement AVD.
Configure Advanced Clipboard and Drive Redirection for AVD and Windows 365 — Dieter Kempeneers : pour creuser la configuration fine du presse-papiers et des lecteurs en amont du contexte.