Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.
Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.
Microsoft préconise cette approche pour AVD :
À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.
Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.
La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.
En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.
Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.
Voici donc les quelques chapitres dans mon article :
Pour réaliser mon test, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle sous Windows 11.
Etape I – Création d’une machine virtuelle :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :
Comme attendu, l’écran de démarrage est par défaut en anglais :
L’interface utilisateur l’est également :
Allons voir dans Language et région :
Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :
Seul le pack Anglais (USA) semble installé :
Cela se confirme par la commande suivante :
Get-InstalledLanguage
Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :
Le pays est là encore défini sur USA, peu importe le région Azure utilisée :
De façon logique, le formatage Anglais (USA)y est également appliqué :
Continuons avec l’administration des paramètres de la langue :
Un clic pour consulter les 3 types de paramétrage :
Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA):
Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.
Etape II – Modification de la langue via script :
Commençons par ouvrir une fenêtre PowerShell ISE :
Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :
Get-InstalledLanguage
Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :
$regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
$RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
$Language : modifier au besoin le language (liste)
En cette fin juin 2024, Microsoft nous partage un peu plus d’informations sur la future MFA obligatoire à venir pour Azure à partir de juillet 2024. Plusieurs grandes étapes sont maintenant mentionnées et intégrées dans un planning qui démarre dès cet été et se terminera début 2025. De plus, Microsoft nous propose également donc quelques outils pour nous y préparer.
Un second post sur le Tech Community est apparu hier sur ce même sujet, et nous donne quelques informations sur les 2 phases de cette obligation liée à Azure :
Phase 1 – À partir de juillet 2024 : La notification puis l’obligation de la MFA pour le portail Azure sera progressivement étendue à tous les tenants.
Phase 2 – À partir de début 2025 : La notification puis l’obligation de la MFA aux outils de commande liés à Azure : CLI, Azure PowerShell et les outils Infrastructure as Code (IaaC) sera progressivement étendue à tous les tenants.
Partant de ces informations, nous pouvons en déduire les points suivants :
Portail Azure : Le portail Azure est utilisé par les humains, il faudra alors former les utilisateurs et configurer pour chacun d’entre eux une méthode MFA.
Autres outils : D’autres outils (CLI, Cloud Shell, …) sont utilisés par les humains et certains applications. Ces dernières pourront elles faire l’objet d’une bascule vers des identités managés ou des comptes de service.
Impact progressif : Les entreprises utilisant Azure doivent se préparer à une transition progressive des tenants. Elles auront le temps d’ajuster leurs configurations et de résoudre les problèmes potentiels avant que l’implémentation complète ne soit réalisée.
Microsoft a t-il prévu de notifier les administrateurs Azure ?
Microsoft a privilégié la notification des administrateurs globaux 60 jours avant la mise en application des phases 1 et 2. Cela sans doute pour laisser les entreprises organiser les messages et notifications en interne aux personnels Azure impactés par cette mesure.
Le compte à rebours de la mise en application pour votre/vos tenant(s) ne commence pas tant que vous n’avez pas reçu cette première notification de notre part. En outre, nous enverrons des rappels périodiques aux administrateurs globaux à intervalles réguliers entre la première notification et le début de la mise en application pour votre/vos tenant(s).
Pourrons-nous déroger temporairement à cette règle pour un tenant ?
Les mails de notification envoyés par Microsoft devraient comporter un lien pour activer une période de grâce, afin de pouvoir gérer les imprévus :
La première notification de notre part indiquant la date de mise en application pour votre/vos tenant(s) inclura également un lien pour demander la période de grâce. Des détails supplémentaires sur les types de clients, les cas d’utilisation et les scénarios éligibles à la période de grâce seront inclus dans la notification.
MFA pour tout Azure, mais vraiment pour tout le monde ?
Microsoft avait déjà été clair sur ce point, j’en avais également parlé dans mon précédent article :
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement.
Malgré cette information, une confusion a déjà pu s’installer, et c’est pour cela que ce second post de Microsoft reprécise que les utilisateurs finaux non gestionnaires d’Azure ne seront pas impactés :
Les utilisateurs finaux qui accèdent à des applications, des sites web ou des services hébergés sur Azure, mais qui ne se connectent pas au portail Azure, à la CLI ou à PowerShell, ne sont pas soumis à cette exigence de Microsoft. Les exigences d’authentification pour les utilisateurs finaux seront toujours contrôlées par les propriétaires de l’application, du site web ou du service.
Quid des accès conditionnels d’Entra ID ou de la sécurité par défaut ?
Microsoft a décidé d’implémenter ce contrôle MFA en amont des mesures de sécurité actuelles :
Sécurité par défaut activée : aucun changement car la MFA est déjà requise pour accéder aux outils Azure.
Accès conditionnel Azure : une police d’accès conditionnel plus restrictive et nécessitant une authentification plus forte que cette nouvelle règle sera appliquée en priorité.
Quid des comptes « brise-glace » ?
En mai dernier, Microsoft ne donnait pas encore de méthodes spécifiques pour ces comptes d’urgence. C’est maintenant chose faite :
Nous avons pris connaissance de vos questions concernant les comptes « verre cassé » ou « accès d’urgence ». Nous recommandons de mettre à jour ces comptes pour qu’ils utilisent FIDO2 ou l’authentification basée sur un certificat (lorsqu’elle est configurée en tant qu’AMF) au lieu de s’appuyer uniquement sur un mot de passe long. Ces deux méthodes satisferont aux exigences de l’AMF.
Pour éviter les soucis de connexion le jour J, Microsoft propose un outil de type tableau de bord, et une commande PowerShell d’extraction sous format EXCEL. Ces deux outils donne plus de visibilité sur les utilisateurs Azure concernés et mal préparés. Voici les deux liens directs mis à disposition par Microsoft :
Authentifiez-vous avec un compte disposants des autorisations nécessaires :
Acceptez les permissions demandées :
Une fois l’authentification terminée, fermez la fenêtre du navigateur :
Attendez que l’export Excel se termine :
Ouvrez le fichier Excel généré :
Constatez sur le premier onglet un tableau récapitulatif des utilisateurs qui se sont connectés au portail Azure, à Azure CLI ou à Azure PowerShell au cours des 30 derniers jours en interrogeant les journaux de connexion et de leur méthodes MFA enregistrées :
✅ MFA Capable + Signed in with MFA : L’utilisateur a enregistré des méthodes d’authentification MFA et s’est connecté avec succès au moins une fois à Azure en utilisant MFA.
✅ MFA Capable : L’utilisateur a enregistré des méthodes d’authentification MFA mais s’est toujours connecté à Azure en utilisant l’authentification à facteur unique.
❌ Not MFA Capable : L’utilisateur n‘a pas encore enregistré de méthode d’authentification multifacteur et ne s’est pas connecté à Azure à l’aide de MFA.
Constatez sur le second onglet un graphique et des totaux des utilisateurs prêts ou non :
Conclusion – Comment se préparer avant le jour J ?
Commencez dès à présent à créer une nouvelle règle d’accès conditionnel équivalente à la future implémentation prévue par Microsoft. Il existe un template de police d’accès conditionnel très proche du résultat attendu :
Cette police cible la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement est un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Vous pourrez par la suite changer son statut sur ON :
Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.
Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :
Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.
You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.
This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.
Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.
Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45
If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.
Required action
We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.
Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.
If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.
If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.
————————————————————-
Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :
Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.
La date limite de transition est prévue pour le 26 juin 2024 :
Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.
Les actions requises :
Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
Contactez votre administrateur global Azure pour planifier ces mises à jour.
Mettre à jour votre documentation interne et informer votre service d’assistance.
Le support :
Pour des questions, consultez la communauté Microsoft Q&A ou ouvrez un cas de support dans le portail Azure.
En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :
Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.
Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :
Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.
Tâche I – Premier test AVD sans SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de l’utilisateur AVD :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau votre identifiant et mot de passe utilisateur :
Confirmez à nouveau votre choix en cliquant sur Continuer :
Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :
Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :
Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.
L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :
Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.
Tâche IV – Configuration AVD pour activer l’authentification unique:
Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :
Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :
Tâche V – Second test AVD avec SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :
La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.
Tâche VI – Accès conditionnel actuel AVD (Portail) :
Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :
Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)
Voici l’impact sur l’utilisateur AVD quand cette première police est activée :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce premier utilisateur AVD :
L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Tâche VII – Accès conditionnel actuel AVD (VM) :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce second utilisateur AVD :
Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :
L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Conclusion
Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.
En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘
Type d’authentification du protocole OAuth 2.0, le Device Code Flow est spécifiquement conçu pour les appareils sans navigateur ou avec une méthode de saisie restreinte, comme les téléviseurs, les consoles de jeux ou encore les appareils IoT. Cette méthode d’identification est déjà très répandue au travers des plateformes de streaming audio ou vidéo. Mais quid de sa sécurité ?
Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.
Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.
Qu’est-ce que le Device Code Flow ?
Le principal avantage du Device Code Flow est de proposer une méthode d’authentification « conviviale » pour des périphériques à saisie restreinte. On peut découper le processus d’authentification du device code flow dans les étapes suivantes :
Demande d’un code de dispositif:
L’appareil (par exemple, une télévision) envoie une demande à l’API d’autorisation du service (par exemple, un serveur OAuth).
En réponse, il reçoit un code de dispositif et une URL d’authentification.
Affichage du code et de l’URL à l’utilisateur:
L’appareil affiche le code de dispositif et l’URL d’authentification à l’utilisateur.
L’utilisateur utilise un appareil avec un navigateur (par exemple, un smartphone ou un ordinateur) pour visiter l’URL fournie.
L’utilisateur entre le code de dispositif affiché sur l’appareil et s’authentifie (par exemple, via un login et un mot de passe).
Appareil poll l’API d’autorisation:
Pendant que l’utilisateur s’authentifie, l’appareil envoie régulièrement des requêtes (polling) à l’API d’autorisation pour vérifier si l’utilisateur a terminé le processus d’autorisation.
Si l’utilisateur autorise l’accès, l’API renvoie un jeton d’accès à l’appareil.
Accès accordé:
L’appareil peut maintenant utiliser le jeton d’accès pour accéder aux ressources protégées au nom de l’utilisateur.
Pourquoi alors se passer du Device Code Flow si pratique ?
Disons-le tout de suite, Microsoft est très clair quant à la sécurité d’Entra ID uniquement basée sur un Device code flow :
Le flux de code d’appareil est un flux d’authentification à haut risque qui peut être utilisé dans le cadre d’une attaque par hameçonnage ou pour accéder aux ressources de l’entreprise sur des appareils non gérés.
Merci à Seyfallah pour son explication très claire sur les risques :
Mais pourquoi alors proposer quelque chose de risqué ?
Comme dit plus haut, certains scénarios spécifiques sont plus facilement gérables via Device Code Flow. D’ailleurs, tous les principaux cmdlets PowerShell, les outils AZ et de nombreux autres prennent en charge ce flux d’authentification depuis déjà un bon moment.
Vous pouvez configurer le contrôle de flux de code de l’appareil avec d’autres contrôles dans vos stratégies d’accès conditionnel. Par exemple, si le flux de codes d’appareils est utilisé pour les appareils Android utilisés dans les salles de conférence, vous pouvez choisir de bloquer le flux de codes d’appareils partout, sauf pour les appareils Android situés dans un emplacement spécifique du réseau.
Mais le principal risque pour la méthode d’authentification via Device Code Flow reste le Phishing ou hameçonnage. Les attaquants peuvent tenter de créer de fausses pages ou emails de phishing :
Et l’arrivée massive de l’IA n’a fait qu’accroitre le risque des attaques basées sur l’ingénierie sociale. Les utilisateurs peuvent être facilement manipulés pour valider des devices code flows à leur insu.
Mais comment peut-on y remédier ?
Bien que la première méthode sécuritaire doive être construite autour de l’éducation des utilisateurs, des pratiques de sécurité rigoureuses et une surveillance continue peuvent aider à atténuer ces risques et à protéger les utilisateurs contre ces attaques :
Entra ID propose depuis peu et encore en préversion, la gestion de polices d’accès conditionnels proposant justement de bloquer les Device code flow selon certains usages :
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur le Device code Flow et son impact :
Important : Cet exercice n’est reflète pas une attaque dans son intégralité, mais démontre quelques points intéressants dans le cadre d’une prise de contrôle d’un administrateur global.
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice, il vous faudra disposer de :
Deux tenants Microsoft
Plusieurs adresses emails pour une première campagne d’hameçonnage
Commençons par l’hameçonnage d’utilisateurs 365 lambda afin de récupérer l’accès à la messagerie 365.
Etape I – Préparation du premier hameçonnage :
Une campagne d’hameçonnage réussie et reposant sur de l’ingénierie sociale doit faire l’objet d’un travail poussé afin d’augmenter ses chances de succès.
Dans mon cas, je suis passé par ChatGPT pour rédiger rapidement un email d’hameçonnage destiné à mes utilisateurs lambda :
ChatGPT m’a alors généré en quelques secondes le texte de mon email au format HTML :
<!DOCTYPE html>
<html>
<head>
<title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
<p>Bonjour [Nom du destinataire],</p>
<p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
<p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
<p>
<a href="https://www.fakewebsite.com/register" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
</p>
<p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">UNIQUECODE12345</strong></p>
<p><strong>Ce code est valable seulement 15 minutes.</strong></p>
<p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
<p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
Il ne me reste qu’à y remplacer l’URL et le Device Code Flow.
J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma première campagne d’hameçonnage :
# SMTP : Serveur
$SMTPServer = "smtp.office365.com"
# SMTP : Port
$SMTPPort = 587
# SMTP : Expéditeur
$SMTPSender = "jlou07@jloudev.onmicrosoft.com"
# E-mail : objet
$EmailSubject = "🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔"
# E-mail : corps
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
<title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
<p>Bonjour [Nom du destinataire],</p>
<p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
<p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
<p>
<a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
</p>
<p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">LS9475723</strong></p>
<p><strong>Ce code est valable seulement 15 minutes.</strong></p>
<p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
<p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@
# SMTP : Destinataire(s)
$SMTPRecipient = "teacher1@tdcheduc.onmicrosoft.com"
$SMTPRecipientList = @()
$SMTPRecipientList += @{
EmailAddress = @{
Address = $SMTPRecipient
}
}
Je charge toutes ces informations dans les propriétés du message :
Quelques secondes plus tard, l’email apparaît en boite de réception :
Bien évidemment, une campagne d’hameçonnage repose toujours sur une volume important d’emails, comparé aux faibles chances de clics des utilisateurs.
Etape II – Récupération du premier token :
Admettons un instant qu’un utilisateur 365 lambda se fasse berner et clique sur le lien en pensant que ce dernier est légitime. Ce dernier est invité à recopier le code indiqué dans l’email d’hameçonnage :
Etant déjà authentifié, il ne lui reste qu’à choisir son compte 365 :
Pensant toujours l’action légitime, l’utilisateur clique sur Continuer :
Entra ID lui informe alors que le processus d’authentification est terminé :
De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :
La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de l’application Microsoft Office :
(Get-MgContext).Scopes
Parmi les autorisations obtenues figure justement le droit d’envoyer des emails :
Nous sommes maintenant à l’intérieur d’un environnement Entra ID avec déjà quelques autorisations. Afin de réussir l’objectif de réinitialiser le mot de passe d’un compte Administrateur Global, nous allons avoir besoin de plus de droits que ceux déjà obtenus.
Etape III – Préparation du second hameçonnage :
La plus rapide est de cibler tous les comptes Entra ID ayant le rôle d’Administrateur Global. Bien souvent, d’autres personnes non IT (gérants, actionnaires, …) ont également ce rôle critique malgré les risques que cela comporte.
Depuis l’accès obtenu via mon utilisateur lambda, la commande PowerShell suivante me permet de récupérer des informations sur les comptes Administrateur Global du tenant :
Une fois ma nouvelle liste de cibles établie, je peux créer une seconde campagne d’hameçonnage interne.
Avant besoin de plus de droits que ceux octroyés par l’application Microsoft Office, je décide de créer une nouvelle application sur un autre tenant dont je suis le propriétaire :
Je nomme mon application selon le contexte voulu et j’active la fonction multi-tenant :
Depuis l’onglet Authentification, je clique sur le menu suivant :
Je clique sur le type de plate-forme suivant :
Je coche et rajoute les URIs suivantes :
J’active également la fonction suivante, puis je clique sur Sauvegarder :
Depuis le menu Permissions API, je rajoute une permission API par le bouton suivant :
Je choisi alors Microsoft Graph :
Je sélectionne Permissions déléguées :
Je recherche la permissions suivante, puis je clique sur Ajouter :
UserAuthenticationMethod.ReadWrite.All
Ici, aucun besoin de consentement d’administration :
Sur la page principale de mon application, je récupère son Application ID :
Comme pour la première campagne, j’exécute les commandes suivantes pour de générer un Device Code Flow destiné à ma nouvelle application :
Là encore, le code généré n’est valable que 15 minutes :
Je repasse par ChatGPT pour rédiger rapidement un second email d’hameçonnage interne destiné à mes utilisateurs Administrateur Global :
J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma seconde campagne d’hameçonnage interne :
# SMTP : Serveur
$SMTPServer = "smtp.office365.com"
# SMTP : Port
$SMTPPort = 587
# SMTP : Expéditeur
$SMTPSender = "teacher1@tdcheduc.onmicrosoft.com"
# E-mail : objet
$EmailSubject = "Activation de l'essai de Copilot for Security toujours en attente"
# E-mail : corps
#$EmailBody = "<h1>Démo Microsoft Graph</h1>"
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
<title>Découvrez Copilot for Security</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🚀 Découvrez Copilot for Security 🚀</h1>
<p>Bonjour,</p>
<p>Nous sommes ravis de vous présenter <strong>Copilot for Security</strong> - votre nouvel allié de confiance pour une sécurité renforcée !</p>
<p>Copilot for Security est une solution révolutionnaire conçue pour simplifier et améliorer la sécurité de votre organisation. Imaginez une intelligence artificielle capable d'analyser vos systèmes en temps réel, de détecter les menaces potentielles avant qu'elles ne deviennent des problèmes, et de vous fournir des recommandations personnalisées pour renforcer votre posture de sécurité. C'est exactement ce que vous offre Copilot for Security !</p>
<p>Mais ce n'est pas tout ! Nous avons une nouvelle excitante à partager : <strong>une préversion privée de Copilot for Security est désormais accessible sur demande</strong> !</p>
<p>Ne manquez pas cette opportunité exclusive de tester notre solution avant tout le monde et de contribuer à façonner l'avenir de la sécurité informatique.</p>
<p>Pour vous inscrire à la préversion privée, rendez-vous sur <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none;">notre page d'inscription</a> et utilisez le code suivant :</p>
<p style="font-size: 1.2em; font-weight: bold; color: #d32f2f;">CUA75XNUX</p>
<p>Nous avons hâte de vous accueillir parmi nos premiers utilisateurs et de vous voir profiter des nombreux avantages de Copilot for Security.</p>
<p>Avec enthousiasme,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@
# SMTP : Destinataire(s)
$SMTPRecipient = "ADMTeacher@TDCHEduc.onmicrosoft.com"
$SMTPRecipientList = @()
$SMTPRecipientList += @{
EmailAddress = @{
Address = $SMTPRecipient
}
}
Je charge toutes ces informations dans les propriétés du message :
Une fois cette police en place, l’utilisateur lambda peut cliquer sur le lien :
Renseigner un code actif :
Choisir son identifiant 365 :
Et se retrouver bloqué et donc protégé de cette tentative d’usurpation :
Conclusion
En conclusion, le Device Code Flow offre une solution pratique pour l’authentification des appareils avec des capacités limitées tout en maintenant une expérience utilisateur fluide. Cependant, il est crucial de mettre en œuvre des mesures de sécurité robustes pour atténuer les risques potentiels associés à ce flux.
Microsoft vient d’annoncer, via un article posté sur le Techcommunity, une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous! Quand cela va arriver ? Qu’est-ce que cela implique ? Ces questions et bien d’autres encore sont légitimes. Tentons d’y voir plus clair ensemble.
Dans cet article sous forme de FAQ, je vous propose de commencer quelques notions important :
L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.
La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Entra ID impose de mettre en place les 3 méthodes d’authentification suivantes :
Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit (ex. identifiant biométrique, tel qu’une empreinte digitale)
Voici l’écran de configuration utilisateur d’une méthode MFA possible :
Quelle licence est nécessaire pour la disposer d’une MFA ?
Les choses ont quelque peu évolué ces dernières années chez Microsoft. Les licences Entra ID présentes et assignées aux utilisateurs concernés sont le point de départ aux méthodes de MFA disponibles.
Cette information au niveau tenant est disponible sur la page principale d’Entra ID :
Entra ID Gratuit : paramètres de sécurité par défaut activés
Entra ID Gratuit
Office 365
Entra ID P1
Entra ID P2
Protection des comptes avec authentification multifacteur
●
● (comptes d’administrateur général uniquement)
●
●
●
Application mobile comme second facteur
●
●
●
●
●
Appel téléphonique comme second facteur
●
●
●
Le SMS comme deuxième facteur
●
●
●
●
Contrôle d’administration sur les méthodes de vérification
●
●
●
●
Alerte de fraude
●
●
Rapports MFA
●
●
Messages de bienvenue personnalisés pour les appels téléphoniques
●
●
ID d’appelant personnalisé pour les appels téléphoniques
●
●
Adresses IP approuvées
●
●
Mémoriser MFA pour les appareils fiables
●
●
●
●
MFA pour les applications locales
●
●
Accès conditionnel
●
●
Accès conditionnel en fonction du risque
●
Autrement dit, un tenant même gratuit (ou non) et ayant la sécurité par défautactivée dispose d’une MFA accessible à tous ses utilisateurs :
Tous les utilisateurs d’un locataire Microsoft Entra ID Gratuit peuvent utiliser l’authentification multifacteur Microsoft Entra à l’aide des paramètres de sécurité par défaut. L’application d’authentification mobile peut être utilisée pour l’authentification multifacteur Microsoft Entra lors de l’utilisation des paramètres de sécurité par défaut Microsoft Entra ID Gratuit.
Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l’authentification multifacteur à l’aide de l’application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.
Mais pourquoi alors payer pour un service MFA disponible gratuitement ?
L’activation de la sécurité par défaut sur un tenant est gratuite, mais reste non personnalisable. Microsoft recommande d’ailleurs une utilisation agile de la MFA grâce à l’utilisation de polices d’accès conditionnel, disponibles dans les licences Microsoft Entra ID P1 ou P2.
Un précédent article dédié aux accès conditionnels est disponible juste ici :
Existe-t-il des différentes configurations MFA possibles sur un tenant ?
Pour rappel, il est actuellement possible de configurer le challenge MFA via 3 méthodes distinctes :
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur (per-user MFA)
Important : N’activez pas ou n’appliquez pas l’authentification MFA par utilisateur si vous utilisez également des polices d’accès conditionnel.
Stratégie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
●
●
Flexibilité de la configuration
●
Fonctionnalité
Exempter les utilisateurs de la stratégie
●
●
Authentification par appel téléphonique ou SMS
●
●
●
S’authentifier par Microsoft Authenticator et jetons logiciels
●
●
●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
●
●
Bloque les protocoles d’authentification hérités
●
●
●
Les nouveaux employés sont automatiquement protégés
●
●
Déclencheurs MFA dynamiques en fonction des événements à risque
●
Stratégies d’authentification et d’autorisation
●
Configurable en fonction de l’emplacement et de l’état de l’appareil
●
Prise en charge du mode « Rapport seul »
●
Possibilité de bloquer complètement les utilisateurs/services
●
Attention la méthode appelée Authentification multifacteur par utilisateur ou Per-user MFA est vouée à disparaitre :
En mars 2023, nous avons annoncé la dépréciation de la gestion des méthodes d’authentification dans les stratégies héritées de l’authentification multifacteur et de la réinitialisation de mot de passe en libre-service (SSPR). À compter du 30 septembre 2025, les méthodes d’authentification ne pourront pas être managées dans ces stratégies MFA et SSPR héritées.
Peut-on migrer d’une configuration MFA à une autre ?
A cause de ce décommissionnement prévu pour 2025, Microsoft a déjà mis à disposition une documentation expliquant différentes étapes pour assurer une transition réussie :
Le SSPR (Réinitialisation du mot de passe en libre-service) et l’ancienne méthode MFA seront donc gérés par les Méthodes d’authentification unifiées :
Qu’est-ce qui se passe en juillet 2024 ?
La nouvelle est passée un peu inaperçue, mais juillet 2024 marque un pas important pour la sécurité Azure :
En juillet (2024), les équipes Azure commenceront à déployer des mesures de sécurité supplémentaires au niveau des locataires pour exiger l’authentification multifactorielle (MFA).
Autrement dit, le déploiement de cette règle MFA sera progressif et concernera à terme l’ensemble des tenants hébergés sur le Cloud public de Microsoft.
Quels sont les services impactés par ce changement ?
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :
Portail Azure
CLI
PowerShell
Terraform
À partir de juillet 2024, un déploiement progressif de cette application pour le portail uniquement commencera. Une fois le déploiement terminé pour le portail, un déploiement progressif similaire commencera pour CLI, PowerShell et Terraform.
Il s’agit donc d’assurer un contrôle MFA systématique afin de protéger les actions en relation avec la gestion des ressources Azure.
Quelles seront les méthodes de MFA possibles pour Azure ?
Les méthodes MFA classiques suivantes pourront être utilisées pour l’authentification Azure :
Microsoft Authenticator
Authenticator Lite (dans Outlook)
Windows Hello Entreprise
Clé de sécurité FIDO2
Token matériel OATH (préversion)
Token logiciel OATH
SMS
Appel vocal
Quelles sont les identités concernées / non concernées ?
Merci à John Savill pour ce schéma expliquant l’impact entre tous les types d’identités possibles sur Entra ID :
Sont donc concernées :
Toutes les identités humaines accédant à Azure dans le cadre de l’administration de ressources (membres et invités)
Sont donc non concernées :
Principaux de services
Identités managées (user ou système)
Comptes basés sur des tokens et utilisés pour l’automatisation
Un travail chez les utilisateurs est donc nécessaire. Mais un contrôle est aussi à prévoir sur les process automatisés utilisant des identités utilisateurs au lieu de des principaux de service ou d’identités managées.
Comment se rendre compte de l’impact avant le jour J ?
Après investigations, Il existe un template de police d’accès conditionnel qui semblerait très proche du résultat attendu par l’évolution de Microsoft prévue pour juillet 2024 :
Cette police semble bien cibler la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement serait alors un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Conclusion
Dans tous les cas, gardez en tête les points suivants, et je ne peux que vous conseiller de prendre les devants dès que possible :
Microsoft recueille encore les feedbacks pour certains scénarios tels que les comptes « break-glass ».
Commencez à examiner les identifiants Entra utilisés pour les opérations de management, développement et les accès API à Azure Resource Manager.
Si nécessaire, remplacer les identités des utilisateurs par des principaux de service ou des identités managées.
Les disques éphémères existent depuis déjà quelques années sur Azure. Mais est-ce qu’un environnement de bureau à distance comme Azure Virtual Desktop associé à ce type de disque est possible ? Si oui, qu’est-ce que cela donne en termes de performances, mais également quelles en seraient les contraintes ?
Qu’est-ce qu’un disque éphémère sur Azure ?
Contrairement aux disques persistants, les disques éphémères sont :
temporaires et ne conservent pas les données au-delà du cycle de vie de la machine virtuelle.
Ils offrent généralement des performances supérieures aux disques persistants car ils sont directement attachés à l’hôte physique sous-jacent.
Ils sont également sujets à la perte de données en cas de panne de la machine virtuelle ou de redémarrage.
Leur prix est inclus dans le coût de la taille de la machine virtuelle.
Leur taille dépend exclusivement de la taille de la machine virtuelle choisie.
Peut se présenter sous deux formes possibles : cache ou disque temporaire (D).
L’excellente vidéo de John Savill vous permettra de bien comprendre le principe des différents disques éphémères sur Azure :
Quels sont les risques à utiliser un disque éphémère ?
Ces disques sont souvent utilisés pour des charges de travail temporaires qui ne nécessitent pas de stockage permanent ou pour des applications qui peuvent reconstruire leurs données en cas de perte.
Il est donc essentiel de sauvegarder les données importantes sur des disques persistants ou d’autres services de stockage Azure si la persistance des données est nécessaire.
Voici 2 pages utiles pour mettre en pratique les disques éphémères :
Comparé à un disque de système d’exploitation standard, un disque éphémère offre une latence plus faible pour les opérations de lecture/écriture et permet une réinitialisation plus rapide des machines virtuelles.
Enfin, Microsoft a mis à disposition la FAQ suivante sur Microsoft Learn.
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur Azure Virtual Desktop combiné à plusieurs types de disque :
Pour réaliser cet exercice sur les disques éphémères intégrés à un Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Préparation de l’environnement AVD :
Avant de pouvoir déployer un environnement Azure Virtual Desktop, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :
Nommez votre réseau virtuel, puis cliquez sur Vérifier:
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1minute :
Cliquez-ici pour accéder à votre réseau virtuel :
Dans le menu suivant, cliquez ici pour déployer Azure Bastion :
Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :
Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :
Choisissez le type Partagé pour l’environnement AVD, puis cliquez sur Suivant :
Choisissez une image OS sous Windows 11 :
Sélectionnez la taille de VM suivante ainsi que le disque OS en Premium SSD :
Note : comme vous pouvez le voir, il n’est pas possible depuis l’interface actuelle d’AVD d’y spécifier un disque OS éphémère.
Joignez votre VM à Microsoft Entra ID, puis cliquez sur Suivant :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :
Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :
Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :
Cliquez sur le nombre de machines AVD hôtes :
Cliquez sur le premier hôte AVD :
Cliquez sur la machine virtuelle AVD correspondante :
Vérifiez la présence d’un disque OS managé Premium SSD, puis cliquez-dessus :
Vérifiez les caractéristiques du disque :
Notre environnement Azure Virtual Desktop est maintenant en place. Nous devons maintenant rajouter 2 machines virtuelles supplémentaires pour comparer les performances des disques :
Création d’une VM AVD avec un disque éphémère cache
Création d’une VM AVD avec un disque éphémère temporaire
Commençons par la machine virtuelle dont le disque OS sera sur le cache.
Etape II – Création d’une VM AVD avec un disque éphémère CACHE :
Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :
Renseignez les informations de votre seconde machine virtuelle en choisissant une image OS sous Windows 11 :
Choisissez une machine virtuelle de type D8ds_v3 :
Définissez un compte administrateur local, puis cliquez sur Suivant :
Activez l’option de placement du disque OS sur le cache, puis cliquez sur Suivant :
Retirez l’adresse IP publique, puis cliquez sur Suivant :
Retirer l’extinction automatique, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la machine virtuelle :
Environ 4 minutes plus tard, la machine virtuelle est créée :
Connectez-vous à cette dernière via le service Azure Bastion :
Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :
Machine virtuelle AVD avec disque OS Premium SSD :
Voici un tableau affichant les informations de la VM D8ds v5 :
Le disque temporaire est bien de 300 Go :
Lancement des 2 scripts diskspd :
Quelques minutes après la fin des traitements diskspd :
Machine virtuelle AVD avec disque OS CACHE :
Voici un tableau affichant les informations de la VM D8s v3 :
Le disque temporaire est bien de 64 Go :
Lancement des 2 scripts diskspd :
Quelques minutes après la fin des traitements diskspd :
Machine virtuelle AVD avec disque OS TEMPORAIRE :
Voici un tableau affichant les informations de la VM D8ds v5 :
Le disque temporaire est bien la soustraction de 300 Go – 128 Go, soit environ 172 Go :
Lancement des 2 scripts diskspd :
Quelques minutes après la fin des traitements diskspd :
Voyons ensemble les différentes de performances des 3 machines virtuelles AVD.
Etape V – Synthèse des résultats :
Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :
j’ai également synthétisé tous mes résultats Throughput dans le tableau ci-dessous :
Conclusion
Il n’y a rien à dire, l’écart de performances entre ces 3 types de disque est très impressionnant ! Et cet écart se creuse encore plus si on change la taille de la machine virtuelle TEMP en D16ds v5 :
De plus, j’ai utilisé le Calculateur Azure afin de comparer les prix des 3 types de disque selon les performances relevées plus haut :
Enfin, Microsoft nous rappelle certaines contraintes liées à l’utilisation de disque OS éphémères :
Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :
Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :
Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :
En somme, ces points ne devraient pas être des blocages pour des environnements Azure Virtual Desktop dans la mesure où ces derniers, généralement, ne stockent pas d’informations utilisateurs et sont constitués à partir d’une golden image 😎🙏.
Microsoft vient d’annoncer il y a quelques heures l’extension de la prise en charge des clés de sécurité dans Microsoft Entra ID via l’application Microsoft Authenticator sur iOS et Android. C’est le moment de mettre un coup d’arrêt aux attaques de types Adversary-in-the-Middle (AitM) ! 💪🔌
Pourquoi utiliser une méthode d’authentification renforcée ?
Microsoft n’est pas le seul à le dire, tous les grands acteurs recommandent des méthodes d’authentification sans mot de passe. Elles apportent expérience de connexion plus sécurisée :
Microsoft propose juste ici une comparaison claire concernant les différentes méthodes les plus répendues :
Une passkey est une méthode qui permet aux utilisateurs d’accéder à des systèmes ou des services sans utiliser les mots de passe traditionnels. En général, elle repose sur des méthodes de déverrouillage d’appareils familières telles que la biométrie (comme les empreintes digitales ou la reconnaissance faciale) ou les codes PIN pour vérifier l’identité des utilisateurs.
Voici justement une courte vidéo en français expliquant les passkeys :
Merci à Merill Fernando pour cette illustration qui montre le processus d’ouverture de session sur votre iPhone ou Android :
Quelles sont les différences entre les passkeys et les clefs FIDO ?
Un premier article avait déjà été écrit sur les clefs FIDO, dont voici le lien. Mais l’excellent article de BIO-key explique les différences de façon assez claire, dont voici une traduction en français :
Sécurité :
Résistance aux attaques : Les passkeys reposent sur des méthodes de déverrouillage d’appareils et sont vulnérables aux attaques ciblant les mesures de sécurité de l’appareil (comme le spoofing biométrique ou le devinage de PIN) ou les techniques d’ingénierie sociale. En revanche, les clés de sécurité utilisent des méthodes cryptographiques robustes et offrent une protection supérieure contre une large gamme d’attaques à distance, y compris le phishing, l’homme du milieu et le bourrage d’identifiants.
Stockage et gestion des clés : Les passkeys stockent généralement les clés sur l’appareil de l’utilisateur, ce qui peut les rendre vulnérables à un accès non autorisé. Les clés de sécurité stockent quant à elles les clés cryptographiques dans le jeton matériel lui-même, réduisant ainsi le risque de compromission des clés.
Facilité d’utilisation :
Expérience utilisateur : Les passkeys offrent une expérience plus conviviale, car elles utilisent des méthodes de déverrouillage d’appareils familières telles que la biométrie ou les PIN. En revanche, les clés de sécurité peuvent nécessiter des étapes supplémentaires ou la possession physique, ce qui peut affecter leur facilité d’utilisation.
Formation et intégration : Évaluez la facilité de former les utilisateurs à l’utilisation efficace des passkeys ou des clés de sécurité. Les passkeys peuvent avoir une courbe d’apprentissage plus courte, tandis que les clés de sécurité peuvent nécessiter plus de guidage et d’éducation.
Commodité :
Dépendance à l’appareil : Les passkeys reposent sur l’appareil de l’utilisateur pour l’authentification, ce qui les rend plus pratiques pour les utilisateurs qui changent fréquemment d’appareil. En revanche, les clés de sécurité, en tant que jetons physiques, nécessitent que les utilisateurs les portent pour l’authentification, ce qui peut être moins pratique pour certains individus.
Perte ou oubli des identifiants : Évaluez l’impact de la perte ou de l’oubli des passkeys ou des clés de sécurité sur l’accès des utilisateurs. Les passkeys peuvent offrir des options de récupération plus faciles, tandis que les clés de sécurité peuvent nécessiter des étapes supplémentaires ou une intervention administrative.
Scalabilité :
Déploiement et gestion : Évaluez la facilité de déploiement et de gestion des passkeys ou des clés de sécurité auprès d’une population d’utilisateurs diversifiée. Tenez compte de facteurs tels que la provision, la révocation et les capacités de gestion centralisée.
Considérations financières : Évaluez les implications financières de la mise en œuvre des passkeys ou des clés de sécurité à grande échelle. Tenez compte de facteurs tels que les coûts initiaux, la maintenance continue et les besoins éventuels de remplacement des appareils.
Compatibilité :
Normes et support : Les passkeys et les clés de sécurité doivent être conformes à des normes largement adoptées telles que FIDO2 (Fast Identity Online) pour assurer la compatibilité avec diverses plateformes et services.
Intégration des applications : Évaluez la compatibilité des passkeys ou des clés de sécurité avec les applications et systèmes cibles. Tenez compte de facteurs tels que les API disponibles, les SDK et le niveau d’effort d’intégration requis.
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur la mise en place d’une passkey sur un utilisateur d’un tenant Azure :
Pour réaliser ces tests de passkey sur votre tenant Microsoft, il vous faudra disposer de :
Un tenant Microsoft 😎
Voici une vue de la page des informations de sécurité de l’utilisateur avant l’activation de la fonctionnalité Passkey :
Il n’est pour l’instant pas possible de lui ajouter une passkey, bien que le tenant soit déjà correctement configuré pour les clefs FIDO :
Avant de pouvoir ajouter une passkey sur un utilisateur de test, il est nécessaire d’activer cette fonctionnalité (encore en préversion) via le portail Entra ID.
Etape I – Configuration passkey du tenant :
Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, rendez-vous dans le menu suivant, puis cliquez sur la rubrique FIDO2 :
Sur le second onglet, configurer ou reconfigurer les options comme ceci :
Comme il est nécessaire d’ajouter des AAGUID spécifiques (Apple / Android) aux passkeys, il est important de reprendre également ceux utilisés pour les clefs FIDO (Un grand merci à Nathan McNulty pour le script !)
Pour cela, commencez par installer le module Graph :
Install-Module Microsoft.Graph
Connectez-vous à votre tenant via le module Graph en utilisant un compte ayant les permissions nécessaires :
Copiez les valeurs AAGUID dans la configuration, puis ajoutez les deux AAGUID correspondants respectivement aux Microsoft Authenticator pour Android / Apple
Cela donne la vue suivant, puis cliquez sur Sauvegarder :
Notre tenant est maintenant correctement configuré. Il faudrait attendre environ 5 à 10 minutes afin que l’utilisateur puisse retrouvez la nouvelle option.
Etape II – Configuration passkey de l’utilisateur :
Avant cela, pensez à activer le Bluetooth sur votre ordinateur :
Retournez sur la page des informations de sécurité de l’utilisateur, puis cliquez-ici pour ajouter une passkey :
Choisissez Passkey, puis cliquez sur Suivant :
Avant confirmez votre identité par un premier challenge MFA :
Une fois le challenge MFA réussi, cliquez sur Suivant :
Lisez la consigne, puis cliquez sur Suivant :
Choisissez la marque correspondante à votre téléphone :
Lisez la consigne, puis cliquez sur Continuer :
Lisez la consigne, puis cliquez sur Suivant :
Lisez le message, puis cliquez sur Je comprends :
Cliquez sur Suivant :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Cliquez sur Pas maintenant :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Sur votre téléphone, cliquez sur Enregistrer autrement :
Choisissez Microsoft Authenticator :
Cliquez sur Créer :
Cliquez sur Utiliser une fois :
Votre ordinateur vous confirme la bonne sauvegarde de la clef sur votre téléphone, cliquez sur OK :
Nommez votre nouvelle passkey :
Celle-ci fait maintenant partie de vos méthodes de connexion :
Notre environnement de test est maintenant en place ! Il ne nous reste plus qu’à tester la connexion en utilisant la passkey.
Etape III – Création d’une méthode d’authentification renforcée :
Par la suite, la mise en place d’une méthode d’une méthode d’authentification renforcée est une bonne pratique pour obliger l’utilisateur a utiliser cette nouvelle méthode MFA résistante à l’hameçonnage.
Rendez-vous sur le portail Entra ID pour y créer cette nouvelle méthode renforcée.
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle, puis cliquez sur Suivant :
Cliquer sur sur Créer :
Créer une nouvelle police d’accès conditionnel :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Ajoutez la ou les applications :
Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :
Attendez quelques minutes avant de pouvoir tester les changement.
Etape IV – Test passkey sans mémorisation du téléphone :
Pour cela, ouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Cliquez sur Pas maintenant :
Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.
Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Afin de gagner du temps et d’éviter d’utiliser l’appareil photo de votre téléphone, il est possible de mémoriser le téléphone sur votre ordinateur de confiance.
Etape V – Test passkey avec mémorisation du téléphone :
Pour cela, réouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Cliquez cette fois sur OK :
Cliquez sur Créer pour enregistrer la même clef sur Samsung Pass :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes. Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Afin de vérifier le changement, réouvrez un navigateur internet en mode privé, rendez-vous sur la page office.com, puis cliquez-ici :
Cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez le téléphone mémorisé précédement :
Attendez quelques secondes l’envoi de la notification à votre téléphone :
Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.
Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Etape VI – Suppression d’une Passkey :
Enfin, il est possible de supprimer une passkey sur un utilisateur. L’utilisateur peut le faire lui-même via sa propre page de sécurité :
Ou par le biais d’un administrateur via le portail Entra ID :
Dans les deux cas, l’utilisateur devra toujours retirer la passkey stockée sur son application Authenticator de son smartphone.
Si l’utilisateur ne dispose pas encore de passkey sur son compte et tente d’accéder à une ressource protégée par un accès conditionnel, le message suivant devrait apparaître :
La mise en place de méthodes renforcées d’authentification pour les identités Cloud est une excellente chose pour la sécurité. Cette démarche doit par la suite être compagné d’un renforcement des accès conditionnels afin que créer une couche de protection supplémentaire 💪
Vous la souhaitez plus longue ou plus courte votre URL d’accès à Azure Virtual Desktop ? C’est à vous de choisir ! Mettez en place une URL raccourcie pour accéder à la page d’authentification AVD, vos utilisateurs vous remercieront ! Sinon, il y aussi l’URL AKA.MS d’Azure Virtual Desktop 😎🤘
Aucun doute que cette fonctionnalité pourra être très utile car plusieurs longues URLs Microsoft sont actuellement disponibles pour accéder aux services HTML5 d’Azure Virtual Desktop ou Windows 365:
Mais comment faire pour ajouter une URL de redirection depuis un nom de domaine personnalisé ?
On peut utiliser des sites comme Long URL Maker 🤣, ou faire comme moi en suivant le conseil de George Markou disponible juste ici. Cela donnera alors des URLs courtes pour AVD comme par exemple :
Pour réaliser ces tests sur la personnalisation de l’URL d’Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Un nom de domaine
Commençons par la première méthode basée sur une Static Web App.
Méthode I – Utilisation d’une Static Web App :
Avec ce service, vous pouvez rapidement et facilement déployer un site web statique qui redirige vers un autre site web, dans notre cas il s’agirait du client HTML5 Azure Virtual Desktop. En général, Azure Static Web Apps est un service qui construit et déploie automatiquement des applications web complètes sur Azure à partir d’un dépôt de code.
Un rapide tour dans le calculateur Azure nous montre l’avantage principal d’une Static Web App : son prix :
Disponible en version gratuite, cette Static Web App devrait correspondre à la majorité des scénarios de redirection Azure Virtual Desktop.
Le schéma ci-dessous nous montre le fonctionnement de redirection de notre Static Web App :
Vous l’aurez probablement compris, nous allons utiliser un peu de code pour effectuer cette direction.
Pour cela, commencez par créer votre compte GitHub si cela n’est pas déjà fait :
Une fois votre compte GitHub créé, rendez-vous sur le répertoire de George via ce lien afin de cloner son répertoire template vers votre compte GitHub :
Nommez ce nouveau répertoire selon vos souhaits, puis cliquer sur Créer :
Attendez quelques secondes que le traitement de copie se termine :
Retournez sur la page du portail Azure afin de recherche le service Static Web App :
Créez votre Static Web App en cliquant ici :
Renseignez les informations de base, dont le nom de votre Static Web App :
Choisissez la source GitHub, authentifiez-vous avec votre compte, choisissez le répertoire nouvellement importé, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la ressource :
Environ 1 minute plus tard, cliquez-ici pour consulter votre Static Web App :
Un dossier workflow est maintenant présent sur votre GitHub :
Cliquez sur l’URL suivante pour éditer le workflow :
Cliquez sur le bouton suivant pour éditer le fichier yaml présent sur votre GitHub :
Modifiez la ligne 31 comme ceci :
Avant :
app_location: "/" # App source code path
Après :
app_location: "/src" # App source code path
Cliquez sur Commit changes :
Indiquez si besoin une description, puis cliquez sur Commit changes :
Après quelques secondes, une action GitHub sera déclenchée, poussant le code vers la Static Web App nouvellement créée.
Retournez sur votre Static Web App afin de lui ajouter votre nom de domaine personnalisé :
Saisissez le nom de votre domaine ou sous-domaine, puis cliquez sur Suivant :
Sélectionnez le type CNAME, puis copiez la valeur de celle-ci dans votre presse-papier :
Sur la page de gestion de votre nom de domaine personnalisé, créez un nouvel enregistrement de type CNAME avec comme valeur celle copiée :
Confirmez votre création d’enregistrement DNS :
Attendez quelques secondes l’actualisation de vos enregistrements DNS :
Retournez sur le portail Azure afin de cliquer sur Ajouter :
Attendez quelques secondes qu’Azure confirme la présence de votre enregistrement DNS pointant vers le CNAME indiqué :
Une fois le domaine validé, cliquez sur Fermer :
Dans la liste des domaines personnalisés, vérifiez la présence de votre nouvel ajout :
Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :
Constatez apparition rapide du message de transfert suivant :
Constatez le changement d’URL :
Une fois les services AVD accessibles, cliquez sur l’un d’eux :
Attendez quelques secondes l’établissement de la connexion :
Attendez quelques secondes l’ouverture de la session :
L’URL personnalisée pour Azure Virtual Desktop fonctionne sans souci avec une Static Web App.
Il ne nous reste qu’à tester la même chose avec Azure Front Door.
Méthode II – Utilisation d’Azure Front Door :
Un second tour dans le calculateur Azure nous montre le coût Azure Front Door :
Bien évidemment cela s’explique par la multitude de fonctionnalités disponibles sur Azure Front Door :
Le tableau suivant fournit une comparaison entre 2 SKUs Azure Front Door :
Fonctionnalités et optimisations
Front Door Standard
Front Door Premium
Livraison et accélération
Remise de fichiers statiques
Oui
Oui
Livraison de site dynamique
Oui
Oui
Domaines et certificats
Domaines personnalisés
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPS
Oui
Oui
HTTPS sur un domaine personnalisé
Oui
Oui
Apportez votre propre certificat
Oui
Oui
Versions prises en charge de TLS
TLS1.2, TLS1.0
TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requête
Oui
Oui
Gestion du cache (vidage, règles et compression)
Oui
Oui
Purge rapide
No
Non
Préchargement de ressources
No
Non
Paramètres de comportement du curseur
Oui à l’aide du moteur de règles standard
Oui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origine
Oui
Oui
Routage basé sur le chemin
Oui
Oui
Moteur de règles
Oui
Oui
Variable de serveur
Oui
Oui
Expression régulière dans le moteur de règles
Oui
Oui
Redirection/Réécriture d’URL
Oui
Oui
Double pile IPv4/IPv6
Oui
Oui
Assistance HTTP/2
Oui
Oui
Préférence de routage non mesurée
Non requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connecté
Non requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connecté
Port de l’origine
Tous les ports TCP
Tous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règles
Oui
Oui
Règles pour appareils mobiles
Oui
Oui
Sécurité
Règles personnalisées du pare-feu d’applications web
Oui
Oui
Ensemble de règles managées Microsoft
Non
Oui
Protection des bots
Non
Oui
Connexion de liaison privée à l’origine
Non
Oui
Géofiltrage
Oui
Oui
Jeton d’authentification
No
Non
Protection DDOS
Oui
Oui
Analytique et création de rapports
Surveillance Métriques
Oui (plus de métriques que Classic)
Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrés
Oui
Oui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAF
Oui
Oui
Journal des sondes d’intégrité
Oui
Oui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications Web
Oui
Oui
Gestion via REST API, .NET, Node.js ou PowerShell
Oui
Oui
Types MIME de compression
Configurable
Configurable
Encodages de compression
gzip, brotli
gzip, brotli
Intégration d’Azure Policy
No
Non
Intégration des conseils Azure
Oui
Oui
Identités managées avec Azure Key Vault
Oui
Oui
Tarification
Tarification simplifiée
Oui
Oui
Dans mon cas, j’utilise déjà un service Azure Front pour mon blog, lui-même hébergé sur une Wep app Azure.
Une fois Azure Front Door en place, rendez-vous dans le menu suivant :
Ajoutez la règle de configuration suivante :
Attendez environ une minute la fin de la création, puis associez à votre règle la route via le menu suivant :
Choisissez une route, puis cliquez sur Suivant :
Modifiez au besoin l’ordre d’exécution des règles, puis cliquez sur Associer :
Attendez environ une minute la fin de l’association :
Retournez dans le menu suivant afin d’ajouter le domaine ou sous-domaine dédié à votre URL Azure Virtual Desktop :
Auprès de votre fournisseur de nom de domaine, ajoutez les 3 enregistrements DNS suivants :
A
AAAA
TXT
Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :
Constatez le changement d’URL :
Une fois les services AVD accessibles, cliquez sur l’un d’eux :
Attendez quelques secondes l’ouverture de la session :
L’URL personnalisée pour Azure Virtual Desktop fonctionne là aussi sans souci avec Azure Front Door.
Conclusion
Quelle que soit la méthode choisie pour la personnalisation de votre URL Azure Virtual Desktop, celles-ci sont simple et facile à mettre en oeuvre et facilitera la vie de vos utilisateurs 🥳
Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :
Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?
La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.
Qu’est-ce qu’Azure Arc Jumpstart ?
Il s’agit de solutions de type bac à sable proposées par Microsoft :
L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.
Comme le montre la page suivante, beaucoup de scénarios y sont proposés :
Mais qu’est-ce qu’HCIBox ?
En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :
HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.
Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.
Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :
Enfin, une FAQ de la HCIBox est disponible juste ici.
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :
Pour réaliser cet exercice, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Préparation de l’environnement Azure :
Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.
Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :
Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.
Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :
Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :
Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :
Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :
az --version
Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :
az account list --query "[?isDefault]"
Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :
az account set
Utilisez la commande suivante afin de vérifier le bon changement de sélection :
az account list --query "[?isDefault]"
Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :
az vm list-usage --location westeurope --output table
Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :
az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId
Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :
Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :
Le statut du fournisseur de ressources change durant cette phase :
Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :
De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep
az bicep upgrade
Récupérez l’identifiant d’objet du fournisseur de ressources Azure Stack HCI de votre tenant :
az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"
Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.
Etape II – Déploiement des ressources Azure :
Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :
spnClientId : Votre identifiant de principal de service Azure
spnClientSecret : Votre secret de principal de service Azure
spnTenantId : Votre identifiant de tenant Azure
spnProviderId : Votre identifiant de fournisseur de ressources Azure Stack HCI
WindowsAdminUsername : Nom d’utilisateur de l’administrateur
windowsAdminPassword : Mot de passe de l’administrateur
logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
deployBastion : Option pour déployer ou non Azure Bastion
Téléversez le fichier template au format JSON modifié sur Azure :
Déplacez le fichier template dans le dossier Bicep :
Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :
az group create --name "jlohci" --location "westeurope"
Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :
az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"
Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :
Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :
Les ressources Azure servant à votre HCIBox sont maintenant en place :
L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Stack HCI. Pour cela, nous utiliserons un script PowerShell déjà préparé.
Etape III – Déploiement des nœudsconnectés via Azure Arc :
Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :
Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :
Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :
Note : Une fois terminé, la fenêtre PowerShell du script se fermera automatiquement :
Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.
Téléchargement des fichiers VHDX de l’OS Azure Stack HCI :
Configuration de la virtualisation :
Création de la VM de management sous Hyper-V :
Création des 2 VMs représentants les 2 nœuds Azure Stack HCI :
Démarrage des 3 machines virtuelles :
Configurations réseaux et stockages :
A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :
Finalisation du déploiement de l’infrastructure Azure Stack HCI dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:
Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :
Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :
C:\HCIBox\Logs\
Il existe également une page officielle de Troubleshoot juste ici :
Log file
Description
C:\HCIBox\Logs\Bootstrap.log
Output from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.log
Output of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.log
Log output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.log
Log output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.log
Log output from tools installation during bootstrap
Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :
Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :
Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :
TelemetryAndDiagnostics
AzureEdgeLifecycleManager
AzureEdgeDeviceManagement
Vérifiez également sur le second nœud la présence de ces 3 extensions :
Enfin comme le montre l’image ci-dessous, votre Cluster Azure Stack HCI n’est pas encore déployé :
Azure Stack HCI utilise un processus en 2 étapes pour valider et déployer des clusters Azure Stack HCI dans Azure à l’aide d’un modèle ARM.
Etape IV – Déploiement du cluster Azure Stack HCI :
Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :
Administrateur Key Vault
Contributeur au compte de stockage
Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :
Cliquez-ici pour continuer :
Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :
Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :
Sélectionnez Construire votre propre modèle dans l’éditeur :
Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :
Cliquez sur Editer les paramètres :
Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :
Renseignez votre groupe de ressources, puis lancez la validation Azure :
Une fois la validation Azure réussie, exécutez le template ARM :
Attendez que ce dernier soit terminé :
Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :
Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Stack HCI :
Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :
La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :
Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :
Suivez l’avancement du déploiement du cluster Azure Stack HCI via le menu suivant :
Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Stack HCI :
Retournez sur la page principale de votre cluster Azure Stack HCI afin de lancer au besoin les mises à jour disponibles (2402) :
Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :
Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Stack HCI :
Votre cluster Azure Stack HCI est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :
les images OS
les réseaux logiques
Etape V – Images OS et réseaux logiques d’Azure Stack HCI :
Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.
Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :
Dans mon exemple, j’importe les deux images OS suivantes :
Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
Windows Server 2022 Datacenter: Azure Edition
La première étape consiste à télécharger sur votre cluster les deux images OS :
Environ 2 heures plus tard, le téléchargement des 2 images est terminé :
Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :
Network details
Subnet
192.168.200.0/24
Gateway
192.168.200.1
VLAN Id
200
DNS Server
192.168.1.254
Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.
Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Stack HCI :
Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :
Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :
Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Stack HCI.
Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.
Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :
Depuis la page de votre cluster Azure Stack HCI, cliquez-ici pour créer votre première machine virtuelle :
Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :
Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :
Cochez la case suivant, puis définissez un compte administrateur local :
Joignez la VM au domaine AD créé pour votre Azure Stack HCI, puis cliquez sur Suivant :
Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :
Cliquez-ici pour ajouter une carte réseau :
Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :
Cliquez sur Suivant :
Ajoutez au besoin des tags, puis cliquez sur Suivant :
Cliquez sur Créer :
Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :
Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :
Copiez l’adresse IP privée de votre nouvelle VM :
Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :
Utilisez le compte suivant :
Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :
Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :
Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Stack HCI.
Etape VII – Déploiement d’Azure Virtual Desktop :
Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.
Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :
Utilisez le compte de domaine suivant :
Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :
Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :
Retournez sur la page de votre cluster Azure Stack HCI, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :
Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :
Ajoutez un ou des VMs Azure Stack HCI à votre AVD en reprenant l’image Windows 11 Enterprise multisession :
Définissez sa taille, sa mémoire et son réseau logique :
Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, puis cliquez sur Suivant :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 1 heure :
L’image ci-dessous vous montre l’apparition des VMs AVD :
Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :
Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :
Attendez environ 2 minutes le temps de la préparation :
Copiez le script suivant pour sa mise en place :
Récupérez l’adresse IP privée de votre VM AVD :
Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :
Collez le script sur la VM AVD :
Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :
Suivez l’activation du management invité par le menu suivant :
Rafraichissez la page plusieurs fois si nécessaire :
Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :
Consultez votre pool d’hôtes AVD depuis le portail Azure :
Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :
Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :
Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :
Renseignez à nouveau le mot de passe de votre utilisateur :
Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :
Conclusion
Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.
Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :
Ce rappel des coûts de la HCIBox m’amène à une autre question :
Est-il rentable de faire fonctionner Azure Virtual Desktop sur Azure Stack HCI quand d’autres solutions on-premise existent également ?
Les avis de la communauté sont partagés, comme l’article écrit par PureRDS :
Plusieurs coûts sont en effet présents pour un Azure Virtual Desktop hébergé sur Azure Stack HCI.
Coûts licences utilisateurs :
Coûts licences infra :
Enfin voici quelques vidéos pour vous faire votre propre opinion 😎 :
Windows 365 est un service de Cloud PC créé par Microsoft et disponible via un système licence mensuelle fixe. Le service Windows 365 est en évolution constante depuis sa sortie en 2021. Très proche d’Azure Virtual Desktop, Windows 365 se distingue principalement par l’absence de connaissances nécessaires sur Azure. Mais que se passe-t-il quand un utilisateur rencontre des difficultés sur son poste Windows 365 ?
J’ai écrit cet article à la suite d’un souci technique sur un poste Windows 365. Pour des questions de commodités, nous avons pris la décision de cloner ce Cloud PC afin de l’analyser et de le redéployer par la suite.
Avant d’aller plus loin, et si Windows 365 nous vous semble pas familier, voici quelques articles très intéressants et disponibles sur ce blog :
Windows 365 est un service cloud qui crée automatiquement un nouveau type de machine virtuelle Windows (PC cloud) pour vos utilisateurs finaux. Chaque PC cloud est attribué à un utilisateur et devient ainsi son appareil Windows dédié. Windows 365 offre les avantages de productivité, de sécurité et de collaboration de Microsoft 365.
Saviez-vous que votre Cloud PC est accessible avec un simple smartphone comme ressource local ?
Disons-le franchement, la documentation Microsoft ne m’a pas vraiment aidé 😥. Je vous propose donc ici de suivre un exercice étape par étape concernant le clonage du poste Windows 365 déjà en place, dans le but de l’analyser en dehors de l’environnement de production.
Renseignez les champs relatifs au réseau virtuel Azure créé précédemment, puis cliquez sur Suivant :
Démarrez la validation Intune, puis lancez la création de la connexion Azure :
La création de la connexion vers Azure apparaît alors, et les premiers contrôles de conformité démarrent automatiquement :
Attendez environ 5 minutes que les contrôles sur la connexion Azure soit terminés :
Cliquez-ici pour définir les paramètres utilisateurs :
Choisissez parmi les options suivantes :
Assignez les paramétrages utilisateurs au groupe Entra ID, puis lancez la création :
Afin de créer le premier poste Windows 365, cliquez sur le menu suivant afin d’assigner une police de provisionnement à votre utilisateur de test :
Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :
Choisissez une image déjà présente dans la galerie Microsoft, puis cliquez sur Suivant :
Personnalisez au besoin la configuration, puis cliquez sur Suivant :
Assignez la police de provisionnement à votre groupe Entra ID, puis cliquez sur Suivant :
Lancez la création de votre police de provisionnement Windows 365 :
Vérifiez la bonne apparition de celle-ci :
Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre Cloud PC assigné à votre utilisateur de test :
Environ 15 minutes plus tard, le provisionnement du poste Windows 365 est terminé :
Sur votre poste local, téléchargez l’application Remote Desktop depuis la page officielle Microsoft, installez-là, puis ouvrez une session avec votre utilisateur de test :
Acceptez en cliquant sur Oui :
Ouvrez une session Windows 365 afin de constater le bon fonctionnement du Cloud PC :
Choisissez la version MSI, puis démarrez le téléchargement :
Une fois téléchargé, ouvrez l’exécutable :
Lancez l’installation de Google Chrome :
Notre environnement de départ est en place et fonctionne correctement. Nous allons maintenant nous intéresser au clonage du poste Windows 365.
Etape II – Sauvegarde du poste Windows 365 :
Afin de stocker l’image de notre Cloud PC Windows 365, commençons par rechercher le service de compte de stockage sur le portail Azure :
Cliquez-ici pour créer le compte de stockage :
Renseignez les informations de base dont le nom unique de votre compte de stockage, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre ressource Azure :
Environ 30 secondes plus tard, cliquez-ici pour ouvrir la page de votre compte de stockage :
Ajoutez un role RBAC sur votre compte stockage par le menu suivant :
Recherchez le rôle Azure RBAC ci-dessous, puis cliquez sur Suivant :
Ajoutez l’application Windows 365, puis lancez la validation :
Lancez l’assignation RBAC par le bouton suivant :
Ajoutez également le rôle RBAC suivant sur la souscription Azure contenant le compte de stockage :
Depuis le portail Intune, retournez sur le Cloud PC afin de déclencher la création d’un point des restauration manuel par le menu suivant :
Confirmez votre choix en cliquant sur Oui :
Quelques minutes plus tard, votre point de restauration apparaît dans la liste ci-dessous. Cliquez-ici pour copier ce dernier sur votre compte de stockage :
Sélectionnez la souscription Azure et le compte de stockage correspondants, puis cliquez sur Partager :
L’ordre de copie est déclenché, attendez maintenant quelques minutes :
Le status du partage est consultable ici :
Depuis le portail Azure, retournez sur votre compte de stockage puis lancez plusieurs rafraichissements si besoin :
Constatez la création d’un nouveau conteneur blob, puis cliquez sur celui-ci :
Constatez la création d’un nouveau blob au format VHD :
Une image de notre poste Windows 365 est maintenant présente dans Azure. La prochaine étape sera de créer une machine virtuelle reprenant ce VHD.
Etape III – Création d’une machine virtuelle Azure :
Avant de créer directement la machine virtuelle, commencez par créer un disque OS via le service Azure suivant :
Cliquez-ici pour créer le disque OS :
Renseignez les informations de base pour votre disque OS, dont l’URL de votre blob VHD :
Vérifiez les champs suivants, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre disque OS :
Environ 1 minute plus tard, cliquez-ici pour consulter la page de votre disque OS :
Cliquez-ici pour réutiliser votre disque OS dans la création d’une machine virtuelle Azure :
Renseignez les champs de base votre machine virtuelle, dont le disque OS :
Choisissez la taille de votre VM, puis cliquez sur Suivant :
Cliquez sur Suivant :
Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :
Décochez la case d’extinction automatique, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre machine virtuelle :
Environ 2 minutes plus tard, votre VM est créée, cliquez-ici :
Vérifiez le bon démarrage de votre VM par le biais du menu suivant :
Déployez Azure Bastion de pouvoir vous y connecter en RDP de façon sécurisée :
Afin de vous connecter à votre VM en utilisant le compte Entra ID de votre utilisateur de test via Azure Bastion, passez la commande PowerShell suivante via le menu dédié :
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1
Attendez la confirmation de la bonne exécution de votre script PowerShell :
Ouvrez une connexion RDP à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :
Constatez la bonne ouverture de votre session Windows :
Constatez la présence de l’icône Google Chrome sur le bureau de la VM :
Notre machine virtuelle Azure est maintenant en place. Nous pourrions alors effectuer tous les tests ou des modifications nécessaires sur celle-ci. Afin de donner un exemple banal, nous allons installer Mozilla sur notre VM.
Etape IV – Modification de la VM :
Rendez-vous sur la page officielle de Mozilla pour y télécharger et installer une version MSI du navigateur :
Constatez la présence de l’icône Firefox sur le bureau de la VM :
Profitez-en pour installer toutes les dernières mises à jour de Windows 11 :
Redémarrez la machine virtuelle Azure si nécessaire :
Vérifiez que Windows Update ne vous propose plus d’autres mises à jour Windows :
Depuis le portail Azure, relancez le script en sens inverse :
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '2' # was before 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '1' # was before 0
Depuis la session RDP déjà ouverte via Azure Bastion, lancez la commande sysprep suivante en mode administrateur :
Sysprep /generalize /oobe /mode:vm /shutdown
Attendez qu’Azure Bastion vous indique une fermeture de session inattendue :
Une fois la machine virtuelle arrêtée au niveau OS, lancez un arrêt depuis le portail afin de désallouer les ressources Azure :
Une fois la machine virtuelle arrêtée et désallouée, lancez une capture de celle-ci :
Renseignez les champs de base de votre image, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre image :
Environ 3 minutes plus tard, constatez la bonne création de votre image :
Nous allons maintenant pouvoir recréer un second Cloud PC Windows 365 à partir de cette nouvelle image modifiée.
Etape V – Nouvel environnement Windows 365 :
Pour plus de facilité, j’ai recréé un second groupe Entra ID avec un second utilisateur de test que celui utilisé précédemment :
J’ai réassigné la licence Windows 365 précédemment assignée à mon nouvel utilisateur de test :
A partir du portail Intune, cliquez sur le menu suivant pour importer votre propre image Windows 365 :
Renseignez les informations de votre nouvelle image Windows 365, dont la source de votre image présente sur votre environnement Azure :
Le téléversement de votre image depuis Azure et vers Intune commence alors :
Environ 30 minutes plus tard, votre image personnalisée est bien chargée et reconnue par Intune :
Cliquez-ici pour créer une seconde police de provisionnement Windows 365 :
Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :
Choisissez votre image personnalisée, puis cliquez sur Suivant :
Personnalisez au besoin la configuration, puis cliquez sur Suivant :
Assignez votre police de provisionnement à votre second groupe Entra ID, puis cliquez sur Suivant :
Lancez la création de votre police de provisionnement Windows 365 :
Vérifiez la bonne apparition de celle-ci :
Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre nouveau Cloud PC, assigné cette fois à votre second utilisateur de test :
Environ 15 minutes plus tard, le provisionnement du nouveau poste Windows 365 est terminé :
Depuis l’application Remote Desktop, ouvrez une session avec votre second utilisateur de test :
Acceptez en cliquant sur Oui :
Constatez la bonne ouverture de votre session Windows :
Constatez la présence de deux icônes Chrome et Firefox sur le bureau Windows :
😎
Troubleshooting – Quelques erreurs possibles :
Voici quelques erreurs que j’ai pu rencontrer lors de cet exercice :
Erreur rencontrée lors du lancement de la commande sysprep car des mises à jour Windows étaient encore en attente :
Erreur rencontrée lors du téléversement de mon image créée directement depuis mon blob VHD, sans avoir créé de machine virtuelle Azure entre temps :
Erreur rencontrée lors de la création d’une VM depuis une image sans avoir créé le disque OS entre temps :
Conclusion :
Cette opération nous montre encore une fois les synergies fortes entre tous les outils Cloud de Microsoft. J’espère que ce petit exercice pourra en aider quelques-uns sur les interventions IT sur des postes Windows 365 🤘🙏