La gestion des mots de passe est une tâche critique, mais ô combien barbante, que cela concerne les comptes personnels ou professionnels. L’apparition des gestionnaires de mots de passes et des méthodes d’authentifications renforcées (2FA / MFA) ont permis d’accroîte la sécurité sur les identités.
Windows fonctionne de la même manière et dispose-lui aussi de comptes aux droits variés. Microsoft propose justement d’en gérer une partie pour vous via Entra ID (Azure AD).
Microsoft a annoncé en mai 2023, la prise en charge des mots de passe Windows LAPS (Windows Local Administrator Password Solution) par Entra ID (Azure AD).
En quelques mots, Entra ID est capable de stocker de façon sécurisé le mot de passe de l’administrateur local de chacun des postes Windows. Mais il y a mieux, Entra ID se chargera aussi de la rotation de ces derniers selon vos propres règles !
Qu’est-ce Windows LAPS ?
Chaque machine Windows dispose d’un compte d’administrateur local intégré qui ne peut pas être supprimé et qui dispose d’autorisations complètes sur l’appareil. La sécurisation de ce compte est une étape importante dans la sécurisation de votre organization. Les appareils Windows incluent la solution de mot de passe de l’administrateur local Windows (LAPS), une solution intégrée permettant de gérer les comptes d’administrateur local.
La configuration de Windows LAPS via Azure AD se fait via Microsoft Intune. Il faudra donc joindre en MDM les machines à ce dernier de afin de pouvoir leur appliquer la police de configuration.
Pour cela les jointures suivantes sont possibles :
Jointure à Azure AD
Jointure Hybride (Azure AD + Active Directory)
Intune prend en charge les fonctionnalités suivantes de Windows LAPS :
Définition des exigences de mot de passe
Rotation automatique et périodique du mot de passe
Choix du lieu de sauvegarde du mot de passe
Actions après utilisation du mot de passe
Avons-nous besoin de licence particulière ?
Pour profiter de la fonctionnalité Windows LAPS au travers d’Entra ID / Intune, il est nécessaire de disposer ces licences suivantes :
Microsoft Intune Plan 1
Microsoft Entra ID Free, anciennement Azure Active Directory Free
Existe-t-il des rôles RBAC dédiés à Windows LAPS ?
Windows LAPS est encore en préversion à l’heure où ces lignes sont écrites. Les rôles et permissions dédiés seront introduit par la suite. Pour l’instant, il est nécessaire d’utiliser l’un des deux rôles Azure AD suivants :
Global Administrator
Cloud Device Administrator
Enfin, Microsoft a commencé à mettre une FAQ sur Windows LAPS juste ici.
Afin de bien comprendre Windows LAPS, nous nous allons prendre de tester cette nouvelle fonctionnalité dans cet article :
Pour réaliser cet exercice sur Windows LAPS, il vous faudra disposer des ressources suivantes :
Une souscription Azure valide
Une Licence Intune Plan 1
Dans notre exercice, nous allons créer plusieurs machines virtuelles via Azure Virtual Desktop afin de servir de machines utilisateurs de test. Ces machines seront automatiquement jointes à Entra ID et Intune pour la suite de notre configuration.
Etape I – Préparation d’Azure Virtual Desktop :
Commençons par créer nos machines virtuelles AVD de test.
Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :
Cliquez ici pour créer votre réseau virtuel pour les VMs d’AVD :
Renseignez les différents champs, puis lancez validation du template par Azure :
Une fois la validation réussie, lancez la création de la ressource :
Attendez environ une minute que le réseau virtuel Azure soit créé, puis cliquez-ici :
Rendez-vous dans la section suivante afin de créer un futur accès aux VMs via le service Azure Bastion :
Le service Azure Bastion se créé en tâche de fond comme le montre les deux notifications suivantes :
N’attendez par la fin d’Azure Bastion et continuez la création des ressources AVD en utilisant la barre de recherche Azure :
Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :
Renseignez les champs du premier onglet, puis cliquez sur Suivant :
Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :
Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows LAPS :
Définissez le nombre de VMs voulues, puis renseignez le réseau virtuel créé précédemment :
Joignez vos VMs AVD à Azure AD et en gestion MDM avec Intune, puis renseignez un mot de passe administrateur local qui sera géré par Windows LAPS par la suite :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure passée, lancez la création des ressource AVD :
Le traitement Azure devrait durer une dizaine de minutes environ :
Pendant ce temps, recherchez Azure AD afin de créer les groupes et utilisateurs :
Créez si besoin les utilisateurs nécessaires à AVD :
Créez si besoin le groupe d’utilisateurs nécessaire à AVD :
Retournez sur le portail Azure afin d’ajouter des rôles RBAC Azure sur le groupe de ressources AVD :
Ajoutez les rôles suivants sur le groupe d’utilisateurs AVD :
Quelques minutes plus tard, les ressources Azure créées pour AVD sont bien disponibles, cliquez-ici pour consulter le pool d’hôtes :
Rafraichissez plusieurs fois afin que toutes les machines AVD soient prêtent et disponibles :
Quelques rafraichissements plus tard, toutes les machines virtuelles sont bien disponibles :
Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :
Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant configurer Windows LAPS.
Etape II – Préparation de Windows LAPS sur Entra ID :
Afin de pouvoir utiliser Windows LAPS sur nos machines virtuelles d’Azure Virtual Desktop, il est nécessaire de l’activer sur notre tenant.
Pour cela, rendez-vous sur le portail Entra afin d’activer l’option suivante, puis sauvegardez :
Profitez-en pour vérifier les présences des VMs AVD et la bonne gestion MDM par Intune :
Créez un nouveau groupe Azure AD dédié aux machines virtuelles AVD :
Ajoutez les VMs AVD à ce groupe, puis lancez la création :
Le travail sur Entra ID est maintenant terminé, il ne nous reste qu’à créer notre police de configuration dédiée à Windows LAPS sur Intune.
Etape III – Configuration de Windows LAPS sur Intune :
Pour cela, rendez vous sur le portail Intune sur l’adresse suivante.
Créer une nouvelle police de configuration comme ceci :
Choisissez le type de profile ci-dessous, puis cliquez sur Créer :
Nommez votre nouvelle police de profil, puis cliquez sur Suivant :
Définissez les règles de configuration, puis cliquez sur Suivant :
Dans mon exemple, après chaque authentification réussie de mon administrateur local JLO, un nouveau mot de passe sera redéfini 1 heure après.
Sinon, ce dernier est systématiquement changé tous les 7 jours.
Cliquez sur Suivant :
Ajoutez le groupe de VMs créé précédemment, puis cliquez sur Suivant :
Lancez la création de votre police Windows LAPS :
Toujours sur Intune, allez voir sur une des VMs AVD afin de voir la liste des configurations appliquées :
Attendez quelques minutes puis rafraichissez afin de constater la présence de votre nouvelle police Windows LAPS :
Notre configuration est enfin terminée, nous allons pouvoir tester Windows LAPS et son impact en nous connectant sur une des machines virtuelles AVD de test.
Etape IV – Test de Windows LAPS
Avant de vous connecter, retournez sur la liste des VMs AVD depuis le portail Azure AD :
Sur une des machines AVD, cliquez sur le menu suivant pour constater l’absence de mot de passe de l’administrateur local :
Sur le portail Azure, retournez sur la liste des machines virtuelles afin de vous y connecter à l’une d’entre-elles via Azure Bastion en utilisant le compte administrateur AVD renseigné :
Vérifiez la présence des droits administrateurs sur votre session :
Déconnectez-vous de la session Azure Bastion :
Attendez un peu, puis recommencez une connexion Azure Bastion avec les mêmes identifiants :
Constatez l’apparition du message d’erreur suivant :
Retournez sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une nouvelle connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous encore une fois de la session Azure Bastion :
Attendez environ une heure, puis recommencez une connexion Azure Bastion avec les mêmes nouveaux identifiants :
Constatez encore une fois l’apparition du message d’erreur suivant :
Retournez encore une fois sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une 3ème connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous une fois 3ème de la session Azure Bastion :
Une heure plus tard, le mot de passe aura encore tourné ✌️:
Petite anecdote :
Sur mon portail Intune, je ne vois pas le menu Local admin password 🥲🥲
Cela ne m’a pas empêché de retrouver l’info sur le portail d’Azure AD.
Conclusion
Très facile à mettre en oeuvre et fonctionnant aussi bien dans une architecture 100% Cloud ou Hybride, cette solution apporte une sécurité supplémentaire sur les postes physiques ou virtuels. Nul doute que la gestion de mots de passe administrateur Windows dans Azure va également faciliter le travail de fournis de certains administrateurs IT 😎
En ce moment, Azure Virtual Desktop a de quoi être jaloux de son petit frère Windows 365 🤣! De nouvelles fonctionnalités lui sont rajoutées afin de rendre l’expérience utilisateur toujours plus complète, comme par exemple, l’upgrade du Cloud PC. Maintenant, il est aussi possible de démarrer son PC et d’arriver directement sur son Cloud PC, sans passer par le bureau local.
Dans cet article, nous répondre à quelques questions et tester la mise en place de la fonctionnalité Windows 365 Boot, au travers d’une machine virtuelle sur Azure simulant un poste local.
Pourquoi utiliser le Windows 365 Boot ?
Nous savons que les façons de travailler ont changé ces dernières années. De plus en plus de données se retrouvent dans le Cloud, et les ressources rattachées ont également suivi ce chemin. C’est pour cela que Microsoft propose différents services d’accès distants au travers d’Azure.
Windows 365 est l’une d’entre elles, et permet à n’importe quel utilisateur, depuis n’importe quel terminal local de s’y connecter pour y retrouver un environnement sécurisé.
L’approche actuelle nécessitait alors de s’authentifier deux fois :
Première authentification sur le poste local avec un identifiant local, AD ou Azure AD.
Seconde authentification pour accéder au Cloud PC avec un identifiant Azure AD.
Microsoft a donc décidé d’aller plus loin en permettant au poste Windows 11 local de s’intégrer totalement dans le processus d’identification de Windows 365.
Y a-t-il d’autres avantages avec Windows 365 Boot ?
Un scénario se prête très bien dans ce type de configuration liée : Les postes partagés.
Les postes partagés par plusieurs utilisateurs pourront alors pleinement profiter de leur Cloud PC depuis un poste local qui n’est pas forcément le leur, sans crainte de laisser leurs données sur ce dernier.
Plusieurs utilisateurs peuvent utiliser le même appareil physique pour se connecter à leurs propres PC cloud personnels. Lorsque chaque utilisateur se connecte à l’appareil physique, son identité unique l’amène à son PC cloud attribué et sécurisé. Cette flexibilité fait de Windows 365 Boot une bonne solution pour les travailleurs tels que les infirmières, les vendeurs et les centres d’appels, qui partagent des appareils physiques de l’entreprise.
Le schéma ci-dessous montre que plusieurs utilisateurs peuvent utiliser le même poste local, car l’authentification combinée se base sur leur identifiant Azure AD pour ouvrir leur PC local mais également leur Cloud PC Windows 365 :
D’autres prérequis sont aussi nécessaires au niveau du poste local :
OS sous Windows 11 (Windows 11 Pro ou Enterprise) en version 22H2
Participation au programme Windows Insider (Dev)
Gestion MDM via Intune
Afin de vous faire une meilleure idée sur cette fonctionnalité, je vous propose de réaliser par vous-même le test depuis un poste Windows 11 hébergé sur Azure :
Modifiez les deux clefs de registre suivantes afin de mettre leur valeur à 0 :
SecurityLayer
UserAuthentication
Depuis le menu Démarrer, ouvrez la fenêtre de paramétrages Windows :
Dans la section Comptes, cliquez-ici pour associer votre poste local à votre compte Azure AD :
Cliquez sur Connecter :
Cliquez ici pour joindre le poste local à Azure Active Directory :
Renseignez les identifiants de votre utilisateur de test disposant de la licence Windows 365 :
Confirmez la jointure du poste à Azure AD :
Attendez environ deux minutes jusqu’à la fin du traitement de jointure :
Vérifiez qu’aucun message d’erreur n’apparaisse à ce moment-là (indiquant un souci éventuel de jointure à Azure AD) :
Déconnectez-vous de votre utilisateur local :
Une fois la session Windows fermée, Azure Bastion vous indique le message suivant. Fermez l’onglet d’Azure Bastion en cliquant ici :
Renseignez les identifiants de votre utilisateur de test en commençant par le domaine AzureAD :
AzureAD\
Vérifiez que l’ouverture de session Windows se fait bien sur votre utilisateur de test :
Notre machine virtuelle simulant notre poste local est enfin prête. Il ne nous reste qu’à mettre en place les premières pièces de configuration pour Windows 365 Boot.
Etape III – Activation du Programme Windows Insider :
Sur votre VM, retournez dans les paramétrages Windows :
Cliquez-ici pour rejoindre le programme Windows Insider :
Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur cette alerte afin d’activer la remontée de données de diagnostic :
Activez l’option, puis retournez sur la page principale des paramètres Windows :
Retournez dans la configuration du programme Windows Insider :
Cliquez sur Commencer afin d’activer le programme sur votre VM de test local :
Utilisez le compte de votre utilisateur de test pour joindre le programme :
Réutilisez le compte de votre utilisateur de test proposé dans la liste :
Cliquez sur Continuer pour accepter les conditions du programme liées aux données privées :
Choisissez le canal Dev, puis cliquez sur Continuer :
Considérez si besoin les particularités du canal Dev, puis cliquez sur Continuer :
Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :
Redémarrez la VM de test local :
Environ 30 secondes plus tard, réouvrez la session Windows de votre utilisateur de test :
Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celle-ci :
En attendant l’installation complète des mises à jour liées à Windows Insider, utilisez ce lien pour télécharger et installer Remote Desktop :
Cliquez sur Suivant :
Acceptez les conditions, puis cliquez sur Suivant :
Lancez l’installation de Remote Desktop :
Terminez l’installation :
Dans l’application Remote Desktop, cliquez sur Souscrire :
Réutilisez le compte de votre utilisateur de test lié à la session Windows 11 :
Constatez la présence du Cloud PC dans l’application Remote Desktop :
Retournez sur Windows Update et attendez l’installation complète de toutes les mises à jour :
Une fois les installations terminées, lancez à nouveau un redémarrage de la VM de test local :
Attendez que le redémarrage se termine :
Le redémarrage de la VM de test local peut prendre plusieurs minutes, cliquez-ici et plusieurs fois si nécessaire :
Vérifiez la présence des mentions suivantes en bas à droite de l’écran Windows :
Etape IV – Configuration Azure AD :
Sur le portail Azure AD, vérifiez la présence de la machine virtuelle de test local et sa gestion MDM via Intune :
Toujours sur le portail Azure AD, créez un nouveau groupe :
Donnez un nom à celui-ci, puis ajoutez un membre :
Recherchez le poste rajouté précédemment (VM de test local) :
Lancez la création de votre groupe Azure AD :
Etape V – Configuration Windows 365 Boot :
Maintenant, ouvrez le portail Intune afin de configurer Windows 365 Boot :
Prenez le temps de lire les informations indiquées, puis cliquez sur Suivant :
Renseignez si besoin les champs suivants, puis cliquez sur Suivant :
Renseignez toutes les périodes, exprimées en jours, puis cliquez sur Suivant :
Choisissez les informations de langue, puis cliquez sur Suivant :
Cliquez-ici pour reprendre le groupe Azure AD créé précédemment :
Choisissez le groupe contenant la VM de test local :
Cliquez sur Suivant :
Cliquez enfin sur Sauvegarder :
Intune déploie alors une configuration comprenant toutes les services suivants :
Profiles de configurations créés :
Politique de mise à jour Windows 10/11 créée :
Set de police créé :
Applications déployées au travers du Windows Store :
Profil de déploiement Autopilot créé :
Page du suivi de l’enrôlement Autopilot créée :
Toujours sur la console Intune, consultez le déploiement des 2 applications sur la VM de test local :
Attendez que le déploiement des deux applications soit confirmé sur la console Intune :
Etape VI – Test de Windows 365 Boot :
Fermez la session ouverte via Azure Bastion sur la VM de test local :
Rouvrez à nouveau une session Bastion sur votre utilisateur de test :
Constatez l’apparition du message de chargement suivant :
Vérifiez bien le chargement du bureau du Cloud PC de votre utilisateur de test :
La barre de session de bureau à distance devrait figurer en haut de votre fenêtre Azure Bastion :
Et voilà, la configuration de Windows 365 Boot est maintenant terminée ! Bravo 🤷♂️
Conclusion
Microsoft continue de rendre la solution Windows 365 encore plus simple et l’enrichie très régulièrement de nouvelles fonctionnalités. Cette approche unifiée entre le poste local et Windows 365 permet une fois de plus d’adoucir la barrière avec le Cloud.
Nul doute que le prochain Inspire de Microsoft sera source d’annonces encore plus intéressantes 😎🤞
Les Cloud PC de Microsoft sont disponibles depuis quelques temps déjà, et de nouvelles fonctionnalités sont leurs rajoutées très régulièrement. Acheté sous forme de licence mensuelle, le Cloud PC initialement commandé peut ne plus suffire à l’utilisateur. Microsoft propose, encore en préversion à cette date, le redimensionnement automatique de celui-ci.
Si vous n’avez pas encore eu l’occasion d’aller plus en profondeur sur les Cloud PC de Microsoft, voici quelques liens vers des articles précédemment écrits, et une excellente vidéo :
Qu’est-ce que le redimensionnement d’un Cloud PC Windows 365 ?
La documentation de Microsoft l’explique très bien :
L’action à distance Redimensionner vous permet de mettre à niveau la RAM, le processeur virtuel et la taille de stockage d’un PC cloud Windows 365 Entreprise pour répondre aux besoins de l’utilisateur.
Pourquoi ne pas simplement recréer un nouveau Cloud PC ?
La démarche de repartir sur un nouveau Cloud PC est tout à fait envisageable. Mais le redimensionnement du Cloud PC a pour principal avantage de conserver les données de l’utilisateurs, mais aussi ses applications et bien d’autres encore.
Peut-on redimensionner son Cloud PC à la baisse ?
La réponse est oui, dans une certaine mesure. Tant que le SKU choisi ne contient pas un disque plus petit que celui présent sur SKU de départ : aucun souci.
La taille d’un disque, et donc des partitions présentes sur celui-ci, est souvent problématique pour certains traitements automatisés.
Doit-on changer sa licence Windows 365 ?
La réponse est encore oui. Le redimensionnement d’un poste Windows 365 nécessite de disposer d’une licence vers la nouvelle taille.
Mais, à l’inverse de nombreuses licences Cloud achetées sous forme de souscription à travers le New Commerce Experience (NCE), je n’ai pas trouvé de moyen direct de migrer de licence Windows 365.
Cela est bien dommage car la licence Windows 365 peut-être prise pour une année, et il sera bien pratique de migrer sur un Cloud PC plus puissant si le besoin s’en fait sentir avant la date d’échéance.
Néanmoins, j’ai pu m’en sortir avec l’aide du Support de Microsoft. Pour cela, j’ai dû acheter une nouvelle licence Windows 365 avant que la précédente, moins puissante, soit annulée et que je sois remboursé.
Est-ce que les utilisateurs peuvent redimensionner leur propre Cloud PC ?
La réponse est non. Comme le rappelle Microsoft, il est nécessaire de disposer d’un des rôles ou combinaisons de rôles suivants pour y parvenir :
Administrateur global
Administrateur de service Intune
Rôles Administration Lecteur Intune + PC cloud
Le redimensionnement est-il disponible pour tous les SKUs Windows 365 ?
Sauf erreur, seuls les SKUs Enterprise sont concernés par cette nouveauté. En effet, un Cloud PC dont le SKU est de type Business ne pourra pas encore avoir cette fonctionnalité.
Que va-t-il se passer pour l’utilisateur durant le redimensionnement ?
Le redimensionnement d’un Cloud PC nécessite de déconnecter l’utilisateur. Il est donc nécessaire de le prévenir en amont afin que ce dernier soit au courant et qu’il ne perde aucune donnée.
Le traitement dure une trentaine de minutes environ.
Comment procède-t-on pour redimensionner ?
Le processus n’est pas bien compliqué. Voici en détail un pas à pas pour mieux vous guider. J’ai simulé la présence de fichiers à divers endroits pour vérifier l’impact du redimensionnement.
Comme vous le montre la copie d’écran ci-dessous, mon utilisateur est actuellement équipé d’un Cloud PC de 2 coeurs / 4Go de mémoire vive. Mon but est de redimensionner son Cloud PC vers une configuration avec deux fois plus de mémoire vive.
Un rapide tour dans son gestionnaire des tâches montre bien les 4Go de mémoire vive :
J’ai déposé un dossier contenant des photos sur le bureau du Cloud PC de départ. L’icône vert sur celui-ci nous montre une synchronisation vers son compte OneDrive :
Le dossier est bien présent sur le bureau du Cloud PC de départ :
J’en profite pour déposer un second dossier de photos à la racine de son disque C, non synchronisé avec OneDrive :
Ce dossier est plus petit que le précédent, mais il nous permettra de vérifier la bonne récupération des données sur le Cloud PC d’arrivée :
Retournez sur la console Intune afin de lancer le redimensionnement du Cloud PC via le menu suivant :
Choisissez la taille de nouvelle configuration du Cloud PC, puis cliquez sur Redimensionner :
Confirmez votre choix :
L’ordre de redimensionnement a bien été pris en compte. Du point de vue utilisateur, il ne nous reste qu’à patienter :
Une première notification apparaît sur le Cloud PC :
On retrouve également l’action dans l’historique des actions lancées depuis la console Intune :
Quelques minutes plus tard, l’utilisateur est bien déconnecté de son Cloud PC :
Un tour dans la console Intune nous montre bien que le redimensionnement est en cours sur le Cloud PC de notre utilisateur :
Si l’utilisateur tente de s’y reconnecter avant la fin du redimensionnement, le message d’erreur suivant apparaît :
Environ 20 minutes plus tard, le statut du Cloud PC change à nouveau :
Toujours sur cette même console Intune, le journal des opérations sur le poste affiche bien le statut suivant :
Afin que l’utilisateur puisse se connecter à son nouveau Cloud PC , un rafraîchement des accès est obligatoire dans l’application :
Juste après le rafraîchement, le nouveau Cloud PC apparaît bien en dessous du précédent, qui devient alors vide de poste :
Cliquez-dessus afin d’ouvrir une nouvelle session de bureau à distance :
Retournez sur le Gestionnaire des tâches afin de vérifier la nouvelle mémoire disponible :
Comme votre utilisateur de test ne doit pas être administrateur du poste, ouvrez la fenêtre suivante en mode Administrateur, puis lancez le programme suivant :
diskmgmt.msc
Vérifiez dans le Gestionnaire des disques la nouvelle taille de la partition du disque C :
Toujours sur le Cloud PC, vérifiez bien la présence :
du dossier présent sur le bureau de l’ancien Cloud PC
du dossier présent à la racine du disque C de l’ancien Cloud PC
Sur le portail Intune, retournez sur la fonction de redimensionnement du Cloud PC afin de constater l’impossibilité de retourner sur un SKU ayant un disque plus petit :
Conclusion
Rien à dire de spécial sur cette fonctionnalité si ce n’est qu’elle marche très bien, et qu’elle pourra faciliter la vie à de nombreux techniciens IT 😎💪
Le Cloud est présent dans beaucoup d’infrastructures IT. Utilisé à 100% ou seulement de manière partielle pour certains services, il offre une flexibilité inégalée, aussi bien dans son financement que dans les besoins techniques disponibles et les évolutions possibles.
Mais alors, si le cloud est merveilleux, pourquoi les principaux fournisseurs de cloud cherchent aussi à proposer des solutions dites hybrides (on-premise + cloud) ?
Peut-être qu’il en faut pour tous les goûts 😁?
D’abord, faisons un rapides tour de plusieurs concepts avant tester ensemble une solution hybride via un exercice que propose justement Microsoft.
Qu’est-ce que le cloud hybride ?
Le cloud hybride combine généralement deux types de cloud : public et privé. Par privé est souvent entendu local.
Un cloud hybride est un peu comme une voiture hybride. Les voitures hybrides combinent deux technologies totalement distinctes : un moteur qui brûle de l’essence et un autre qui consomme de l’énergie électrique. Chaque technologie fonctionne de manière totalement différente, et chacune a ses avantages et ses inconvénients. Cependant, lorsque les deux sont combinées efficacement, le résultat est une voiture plus performante que la plupart des voitures uniquement à essence et pourtant plus puissante que la plupart des voitures entièrement électriques. De même, les cloud hybrides combinent les avantages de plusieurs types d’environnements cloud pour une efficacité et une fonctionnalité accrue.
Azure Stack HCI est une solution développée par Microsoft pour justement aider les entreprises à exploiter les avantages d’un environnement hybride, expliqué précédemment, via les interfaces connues d’Azure et de Windows Admin Center.
Il s’agit d’une solution d’infrastructure hyperconvergée basée sur les technologies Azure de Microsoft. Elle permet de :
d’intégrer de façon transparente leur environnement
De créer une expérience hybride cohérente à Azure.
D’apporter toujours plus de scalabilité et flexibilité.
De conserver un haut niveau de sécurité et de conformité.
De profiter d’une passerelle de modernisation de l’infrastructure existante.
Existe-t-il du matériel certifié Azure Stack HCI ?
Microsoft met à disposition un site web dédié à Azure Stack HCI dont voici le lien. Vous pourrez y planifier votre solution en fonction des charges de travail prévues :
Peut-on tester Azure Stack HCI sans forcément acheter du matériel ?
Cela est possible, grâce à … Azure ! En effet, les fournisseurs de cloud autorisent pratiquement toutes les créations de ressources, donc on peut simuler un Azure Stack HCI dans le cloud de Microsoft.
Cette approche permet donc de ne pas dépenser de grandes sommes d’argent pour tester la solution Azure Stack HCI avant de se laisser convaincre. Pour cela je vous laisse lire les différentes étapes ci-dessous pour y parvenir :
La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur leur page GitHub juste ici.
Rappel des prérequis :
Pour réaliser cet exercice sur Azure Stack HCI, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de tester Azure Stack HCI, nous allons avoir besoin créer un environnement virtuel, dans lequel nous allons simuler la présence de nœuds HCI, mais aussi de Windows Admin Center.
Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Important : Attention à ne pas laisser tourner l’environnement de démonstration Azure Stack HCI tourner un peu trop longtemps. Beaucoup de ressources Azure sont créées et le compteur des € défile assez vite 🤑.
Etape I – Déploiement de l’environnement virtuel sur Azure :
Commencez par cliquez sur le lien ci-dessous afin déployer les ressources nécessaires sur votre souscription Azure :
Renseignez les champs suivants, puis lancez la validation Azure :
Une fois la validation Azure réussie, cliquez-ici pour commencer la création :
Le déploiement dure environ 30 minutes, attendez que celui-ci se termine, puis cliquez-ici :
Constatez la présence de nombreuses ressources Azure créées pour cette démonstration, puis cliquez sur la machine virtuelle présente, appelée AzSHCIHost001 :
Rendez-vous dans le menu Bastion, puis cliquez-ici pour en déployer un :
Attendez environ 5 minutes que la création d’Azure Bastion se termine :
Modifier la règle NSG suivante créée dans le template Microsoft afin de débloquer l’accès RDP à votre machine Hyper-V :
Retournez sur votre machine virtuelle Hyper-V, puis lancez une session Bastion avec les identifiants renseignés lors de la création du template :
Sur la session RDP ouverte via Azure Bastion, cliquez-ici pour modifier le script de déploiement d’Azure Stack HCI :
Rendez-vous sur la ligne suivante pour modifier la ligne comme ceci :
AVANT :
Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Vous avez aussi la possibilité de récupérer celui-ci en version corrigée sur mon GitHub
Lancez le script, puis faites preuve d’un petit peu de patience, car celui dure environ … 2 heures 🤣
Si aucune erreur ne s’est manifestée durant le traitement, vous devriez apercevoir le message de succès suivant :
Si le script ne s’est pas correctement terminé, la commande PowerShell suivante permet d’effacer les ressources crées dans Hyper-V afin de pouvoir recommencer le lancement du script :
.\New-AzSHCISandbox.ps1 -Delete $true
Un tour rapide dans la console Hyper-V montre l’apparition de 3 machines virtuelles :
AzSHOST1 : nœud Azure Stack HCI 1
AzSHOST2 : nœud Azure Stack HCI 2
AzSMGMT : Console de management pour Windows Admin Center
Sur le bureau de votre machine virtuelle Hyper-V, une icône de type RDP vient de faire son apparition :
Notre environnement fictif de départ est maintenant terminé. Nous avons besoin d’enregistrer notre cluster Azure Stack HCI sur le portail Azure afin de commencer la facturation mais aussi tester le déploiement de services depuis le portail Azure.
Etape II – Enregistrement du Cluster Azure Stack HCI sur Azure :
Pour cela, cliquez sur l’icône RDP pour ouvrir une session sur la VM WAC puis renseignez les identifiants suivants (mot de passe : Password01) :
Notez la présence d’un domaine Active Directory nommé Contoso. Attendez quelques minutes que la session se charge entièrement :
Sur le bureau, ouvrez le raccourci menant à la page suivante et ayant un icône Google Chrome :
https://admincenter.contoso.com/
Renseignez les identifiants suivants (mot de passe : Password01) :
Attendez quelques secondes que se charge la console de Windows Admin Center :
Fermez la fenêtre de notification de Windows Admin Center :
Attendez environ 10 minutes que tous les modules présents dans Windows Admin Center soient bien mis à jour :
Une fois les mises à jour effectuées, les notifications suivantes devraient apparaître dans WAC :
Afin de pouvoir piloter votre Cluster de serveurs Azure Stack HCI, il est nécessaire de le rajouter dans la console WAC pour terminer la configuration.
Cliquez-ici pour ajouter votre cluster Azure Stack HCI à WAC :
Saisissez le nom AzStackCluster, attendez quelques secondes que WAC retrouve ce dernier, puis cliquez sur Ajouter :
Une fois l’ajout réussi, vérifiez la liste des connexions existantes avec WAC, puis cliquez sur votre cluster de serveurs :
Rendez-vous dans le menu appelé SDN Infrastructure :
Renseignez les identifiants suivants (mot de passe : Password01), puis cochez la case suivante :
Renseignez le contrôleur de réseau suivant, puis cliquez sur Continuer :
Constatez l’apparition des nouveaux menus suivants sous la section Réseau :
Afin de pouvoir utiliser pleinement le portail Azure pour piloter notre cluster Azure Stack HCI, il est nécessaire de passer par quelques étapes d’enregistrement.
Pour cela, rendez-vous toujours depuis WAC dans la section Azure Arc, puis cliquez sur le bouton suivant :
Cliquez-ici pour démarrer l’enregistrement de notre cluster sur Azure :
Utilisez le code Azure pour valider l’authentification Azure AD avec un compte disposant de suffisamment de droits sur la souscription Azure :
Une fois l’authentification Azure AD réussie, vous devriez recevoir l’information suivante, puis cliquez sur Authentifier :
Acceptez la demande de permission de Windows Admin Center avec le consentement global de l’organisation :
Vérifiez la disparition du message sur la page Azure Arc de votre WAC :
Avant d’aller plus loin, retournez sur votre portail Azure afin d’activer le fournisseur de ressources suivant sur votre souscription Azure :
Attendez environ deux minutes que le statut soit correctement changé sur le fournisseur de ressources :
Retournez sur Windows Admin Center, puis cliquez-ici :
Cliquez-ici pour démarrer le processus avec la connexion Azure Arc précédemment créée :
Renseignez les informations qui vous conviennent, puis cliquez sur Enregistrer :
La notification suivante devrait alors apparaître dans WAC :
Attendez environ 5 minutes pour confirmer le bon enregistrement :
Retournez sur le portail Azure afin de constater la présence de votre Azure Stack HCI, puis cliquez dessus :
Naviguez dans les différents menus pour mieux comprendre les informations remontées sur Azure.
Nous allons avoir maintenant besoin d’un autre composant, appelé Azure Resource Bridge. Si l’on souhaite gérer et déployer des ressources sur son cluster depuis Azure, celui-ci est indispensable.
Etape III – Configuration d’Azure Ressource Bridge :
Le pont de ressources Arc est une machine virtuelle empaquetée qui héberge un cluster Kubernetes de gestion nécessitant une gestion minimale des utilisateurs. La machine virtuelle est déployée sur l’infrastructure locale et une ressource ARM du pont de ressources Arc est créée dans Azure. Les deux ressources sont ensuite connectées, ce qui permet la gestion et l’utilisation en libre-service des machines virtuelles à partir d’Azure
Ensuite, cliquez ici pour installer un second module, appelé Azure Resource Bridge :
Attention : certaines étapes sont à faire sur les 2 nœudsprésents dans votre cluster Azure Stack HCI
Cliquez sur le lien suivant pour ouvrir le guide d’installation d’Arc Resource Bridge :
Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :
Renseignez les identifiants suivants (mot de passe : Password01) :
Effectuez le choix 15 pour ouvrir une console PowerShell :
Profitez-en pour ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :
Saisissez la commande suivante pour installer les premiers modules nécessaires :
Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre premier nœud:
Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le second nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :
Renseignez les identifiants suivants (mot de passe : Password01) :
Effectuez le choix 15 pour ouvrir une console PowerShell :
Profitez-en pour également ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :
Saisissez la commande suivante pour installer les même premiers modules nécessaires :
Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre second nœud:
Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :
Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :
Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :
Saisissez la commande suivante pour installer le module CLI d’Azure, uniquement nécessaire sur le premier nœud :
Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer à nouveau votre premier nœud :
Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :
Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :
Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :
Rouvrez à nouveau Notepad depuis PowerShell afin de faciliter les copier / coller.
Préparer les variables suivantes puis lancez-les :
Retirer les extensions du module PowerShell Az si jamais elles existaient déjà :
az extension remove --name arcappliance
az extension remove --name k8s-extension
az extension remove --name customlocation
az extension remove --name azurestackhci
Installer à nouveaux ces mêmes extensions Az :
az extension add --upgrade --name arcappliance
az extension add --upgrade --name k8s-extension
az extension add --upgrade --name customlocation
az extension add --upgrade --name azurestackhci
Renseignez les informations sur votre environnement Azure :
Vérifiez que le statut soit bien sur Succeded, retentez quelques minutes plus tard si nécessaire :
az k8s-extension show --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --out table --query '[provisioningState]'
Terminez par la commande de création d’un emplacement personnalisé sur Azure. Ce dernier va nous être utile pour indiquer lors de la création de ressources depuis le portail Azure que celle-ci doit-être créée sur Azure Stack HCI :
az customlocation create --resource-group $resource_group --name paris --cluster-extension-ids "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name/providers/Microsoft.KubernetesConfiguration/extensions/hci-vmoperator" --namespace hci-vmoperator --host-resource-id "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name" --location $location
Constatez la bonne création de ce dernier depuis le portail Azure :
Retournez sur la page Azure de votre cluster Azure Stack HCI afin de constater l’avancement des prérequis :
Azure Resource Bridge est maintenant correctement installé. Nous allons enfin pouvoir créer notre machine virtuelle depuis le portail Azure, et déployée directement sur un des 2 nœuds de notre cluster.
Etape IV – Création de la VM sur le Stack :
Cliquez comme ceci pour transférer vers votre cluster une image de VM provenant de la marketplace Microsoft d’Azure :
Renseignez les champs comme ceci, puis lancez la validation :
Une fois la validation réussie, cliquez-ici pour commencer le transfert de données de l’image de Windows Server vers votre cluster :
Ce processus est assez long, comptez environ une bonne heure avant que le transfert de l’image ne se termine :
En cas d’erreur lors du transfert, relancez celui-ci afin d’avoir une image complète sur votre cluster :
De retour sur votre premier nœud de votre cluster Azure Stack HCI, lancez la commande suivante pour initialiser le réseau virtuel :
Retournez sur le portail Azure afin de constater sa bonne création :
Cliquez ensuite ici pour créer votre première VM sur votre Stack HCI :
Renseignez les informations de base :
Définissez sa taille et son identifiant local, puis cliquez sur Suivant :
Ajoutez si besoin des disques de données, puis cliquez sur Suivant :
Ajoutez une carte réseau :
Utilisez le réseau virtuel créé précédemment :
Cliquez-ici pour lancer la validation :
Une fois la validation Azure réussie, cliquez sur Créer :
Le déploiement des ressources est en cours sur votre cluster, comptez environ 30 minutes pour que celui-ci se termine :
Au bout de quelques minutes Il est aussi possible de suivre la création de la VM depuis la console WAC :
Une fois la création de la machine virtuelle terminée, cliquez-ici pour y accéder :
Prenez le temps de vérifier la configuration de celle-ci :
Retournez sur la console WAC afin d’initialiser une connection directe :
Renseignez les identifiant votre compte admin chez Contoso (mot de passe : Password01) :
Cliquez-ici pour déverrouiller la session distante :
Renseignez les identifiants indiqués lors de la création de la VM depuis le portail Azure :
Vous voilà connecté sur votre VM hébergée sur un stack HCI virtuel, hosté sur un serveur Hyper-V, lui-même hosté sur Azure 😁😎💪 :
Conclusion
Après quelques jours de tests, l’intégration des outils Azure et WAC pour piloter le Cluster un véritable tour de force de Microsoft ! Nul doute que certains projets ou infrastructures ne peuvent être hébergées sur le Cloud pour un grand nombre de raisons. C’est pour cela que Microsoft et les autres fournisseurs de Cloud se doivent de proposer des solutions « à mi-chemin ».
Il faudra enfin voir ce que ça donne dans la version publique généralisée car encore beaucoup de scripts à faire dont beaucoup encore en préversion.
La mise en place d’un processus de provisionnement des postes utilisateurs peut, par moment, virer au casse-tête ! Entre le spécifique nécessaire à certains utilisateurs, les besoins complexes, ou encore les contraintes géographiques pour la réception des matériels, les équipes IT doivent pouvoir se reposer sur des outils modernes, efficaces et facilement adaptables.
Le but n’étant pas de leur retirer tout travail, mais bien de leur faciliter la vie ! Après un premier article sur les GPOs poussées via Intune, je trouvais intéressant d’écrire un second article, dédié à la fonction d’Autopilot de celui-ci.
Intune, ou Microsoft Endpoint Manager, simplifie le processus de préparation des postes utilisateurs. Comme les services du Cloud Microsoft, Intune a la faculté de pousser des configurations de poste et des applications au travers d’une connexion internet.
Cette approche de connexion simplifie grandement le management des postes, que ces derniers soient sur le réseau d’entreprise ou en situation de mobilité.
Qu’est-ce qu’Autopilot ?
Windows Autopilot est un ensemble de technologies utilisées pour configurer et préconfigurer de nouveaux appareils de manière à les préparer à une utilisation productive. Windows Autopilot peut être utilisé pour déployer des PC Windows
Le bénéfice premier d’Autopilot est donc de combler la phase initiale, afin que le poste de l’utilisateur, à peine déballé par ce dernier, soit directement rattaché au tenant, et donc de fait « guidé » dans un processus de mise en route.
Cette méthode permet de retirer, dans certains cas, des étapes préparatoires réalisées par les équipes IT, ou des actions réalisées par l’utilisateur final pour la finalisation du processus de configuration du poste.
De quoi avons-nous besoin pour qu’un poste intègre le processus Autopilot ?
Dans la plupart des cas, l’importation des postes à un tenant 365 via Autopilot repose sur l’utilisation du Hash de l’appareil.
Un hachage d’appareil ou de matériel est une chaîne de chiffres et de lettres … qui contient des informations sur l’appareil et son utilisateur. Ces informations s’apparentent à l’identité de l’appareil.
Il est aussi possible de travailler avec le numéro de série du fabricant. Une fois la liste de hashs à disposition, il suffit de :
Importer celle-ci sur le tenant 365, via le portail Intune
Configurer un profil Autopilot associé aux machines importées
Ai-je besoin de licences spécifiques pour Autopilot ?
Comme il est rappelé dans la documentation Microsoft, Autopilot a besoin de plus que la licence Intune. Il est en effet nécessaire de disposer d’une licence Azure Active Directory Premium P1 ou P2.
Afin de se faire une meilleure idée sur le processus Autopilot, je vous propose un petit exercice à réaliser sur une souscription Azure. Dans cet exercice, nous allons effectuer les étapes suivantes :
Pour réaliser cet exercice sur Autopilot, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Une licence contenant Intune
Une licence contenant Azure AD Premium P1
Afin de tester la fonctionnalité Autopilot, nous allons avoir besoin d’intégrer une machine dans notre tenant 365. Plus exactement, il va être nécessaire de précharger son hash dans la console Intune sur le tenant 365 de test.
Pour cela, je vous propose de simuler un poste sous Windows 11 grâce à un environnement virtualisé de type Hyper-V.
Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs jaunes suivantes :
Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows 11),créée plus tard dans notre machine virtuelle hôte (Hyper-V) :
Conservez les options par défaut, puis cliquez sur OK :
Cliquez ensuite sur Suivant :
Retirez l’adresse IP publique (pour des questions de sécurité), puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :
Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :
Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Depuis la console Server Manager, ouvrez Hyper-V Manager :
Ouvrez le menu suivant :
Contrôlez la présence de votre switch virtuel créé précédemment :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle invitée (Windows 11).
Etape II – Création de la machine virtuelle invitée (Windows 11) :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin de créer la machine virtuelle invitée (Windows 11), puis d’y installer l’OS.
Toujours sur la machine virtuelle hôte (Hyper-V), ouvrez le navigateur internet Microsoft Edge.
Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :
Choisissez la langue désirée, puis cliquez sur Confirmer :
Cliquez sur la version 64 bits pour lancer le téléchargement :
Attendez quelques minutes pour que le téléchargement de l’ISO se termine :
Depuis votre VM hôte (Hyper-V), rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre première machine virtuelle invitée (Windows 11) :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
Modifier la taille de la mémoire vive allouée à la VM invitée (Windows 11), puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO de Windows 11 téléchargée précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée (Windows 11) :
Une fois la machine virtuelle créée, modifiez sa configuration comme ceci :
Dans la section Sécurité, cochez la case suivante pour activer TPM :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :
Double-cliquez sur votre machine virtuelle invitée (Windows 11) :
Cliquez-ici pour lancer le démarrage de la VM invitée (Windows 11) :
Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :
Attendez que le chargement se termine :
La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.
Etape III – Installation de Windows 11 sur la VM invitée (Windows 11) :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows 11 :
Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows 11 :
Choisissez une version de Windows 11, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows 11 :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows 11 commence :
Lancez le redémarrage de la machine virtuelle invitée (Windows 11) :
Attendez quelques minutes que le redémarrage se poursuivre :
Sélectionnez le pays adapté, puis cliquez sur Oui :
Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :
Ajoutez, si besoin, un second clavier :
Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :
Nommez votre machine virtuelle invitée (Windows 11) selon vos souhaits, puis cliquez sur Suivant :
Attendez que la configuration finale se termine :
Afin de récupérer le hash de notre machine virtuelle invitée (Windows 11), nous avons besoin d’un compte local.
Pour cela, configurer votre VM invitée (Windows 11) comme ceci, puis cliquez sur Suivant :
Donnez à nom à votre compte local Windows, puis cliquez sur Suivant :
Définissez un mot de passe à votre compte local Windows 11, puis cliquez sur Suivant :
Confirmez votre nouveau mot de passe une seconde fois, puis cliquez sur Suivant :
Adaptez la configuration des paramètres de confidentialité, puis cliquez sur Accepter :
Attendez quelques minutes durant la seconde vérification de mise à jour :
Attendez enfin la dernière finalisation de la configuration de Windows 11 :
Vous voilà enfin sur le bureau Windows de votre machine virtuelle invitée (Windows 11) :
Retournez sur la console Hyper-V de votre VM hôte (Hyper-V) afin de créer un snapshot de votre VM invitée (Windows 11) :
Attendez quelques secondes, puis cliquez sur OK sur le message de notification suivant :
La machine virtuelle invitée est maintenant en place avec un OS Windows 11. Nous allons maintenant récupérer son hash, l’intégrer dans notre tenant de test, puis réinitialiser celle-ci pour tester Autopilot.
Etape IV – Récupération et intégration du hash de la VM invitée (Windows 11)
Retournez sur le bureau de la machine virtuelle invitée (Windows 11), puis ouvrez PowerShell en mode administrateur :
Cliquez sur Oui pour confirmer votre choix :
Saisissez le script suivant dans la fenêtre PowerShell. Celui-ci a pour but de générer un fichier CSV contenant le Hash de notre machine virtuelle invitée (Windows 11) :
Pour cela, utilisez la fonction suivante dans la connexion Hyper-V afin de faciliter le copier // coller entre la VM hôte (Hyper-V) et la VM invitée (Windows 11) :
Au besoin, utilisez Notepad pour vérifier le bon fonctionnement du copier // coller :
La commande du script créée le fichier AutopilotHWID.csv, contenant le hash de notre machine virtuelle invitée (Windows 11) :
Retrouvez ce fichier dans l’explorateur de votre machine virtuelle invitée (Windows 11) :
Vérifiez que le contenu du fichier présente bien des informations similaires à l’exemple ci-dessous :
Pour plus de facilité, utilisez la fonction de partage Windows afin de reprendre le contenu du fichier hash vers la machine virtuelle hôte (Hyper-V).
Pour cela, depuis la VM invitée (Windows 11), activez le partage du dossier racine comme ceci :
Cliquez sur le menu suivant :
Activez le partage du dossier :
Copiez le chemin réseau du partage nouvellement activé :
Depuis la machine virtuelle hôte (Hyper-V), coller le chemin réseau dans l’explorateur, puis utilisez les identifiants renseignés lors de la configuration du compte local de la VM invitée (Windows 11) :
Ouvrez le fichier CSV avec Notepad :
Copiez le contenu du fichier puis collez-le sur votre poste local, afin de pouvoir charger le fichier sur le portail Intune :
Enregistrer ce fichier nouvellement créé au format CSV :
De retour sur la machine virtuelle invitée (Windows 11), recherchez dans le menu Démarrer le programme de réinitialisation Windows :
Lancez le programme de réinitialisation de Windows 11 :
Confirmez la suppression de toutes les données personnelles :
Attendez que le traitement prépare l’opération de réinitialisation :
Choisissez la réinstallation depuis une source locale :
Cliquez sur Suivant pour préparer le traitement :
Attendez une seconde fois que le traitement prépare l’opération de réinitialisation :
Cliquez sur Réinitialiser pour lancer le traitement :
Vérifiez que le traitement de réinitialisation s’enclenche bien :
Depuis le portail Intune, accessible à cette adresse, rendez-vous dans la section dédiée à l’import Autopilot de machines Windows :
Cliquez-ici pour importer le fichier CSV contenant le hash de notre machine virtuelle invitée (Windows 11) :
Sélectionnez le fichier CSV, puis cliquer sur Importer :
Une notification de travail en cours doit apparaître :
Environ 30 secondes plus tard, l’importation est terminée avec succès :
Attendez quelques secondes, puis rafraichissez la page afin de retrouver votre machine virtuelle invitée (Windows 11) dans la liste :
Assignez si besoin un utilisateur Azure AD à votre machine de test afin d’améliorer le test de l’expérience Autopilot :
Sur la page d’Azure AD, créez ou utilisez un groupe Azure AD existant, puis ajoutez-y la machine virtuelle importée via Autopilot :
De retour sur le portail Intune, rendez-vous dans le menu suivant pour configurer un profil de déploiement Autopilot :
Configurez à votre guise votre profil de configuration Autopilot, puis assignez ce dernier au groupe Azure AD contenant votre machine virtuelle invitée (Windows 11) :
Quelques minutes plus tard, vérifiez bien la présence de ladite machine dans la section ci-dessous de votre profil Autopilot :
Etape V – Test de la fonction Autopilot
Retournez sur la machine virtuelle invitée (Windows 11) afin de constater l’avancement de la préparation à la réinitialisation de Windows 11 :
Environ 20 minutes plus tard, le processus de préparation à la réinitialisation est maintenant terminé :
La machine va ensuite redémarrer :
Des mises à jour automatiques sont prises en compte :
Le processus de réinitialisation commence enfin :
Celui-ci se poursuit avec la réinstallation de Windows 11 :
Une fois la réinstallation terminée, Windows 11 s’ouvre et affiche une fenêtre vous invitant à vous authentifier avec un compte 365 du tenant concerné.
Veuillez saisir le mot de passe de l’utilisateur :
Attendez quelques instants que Windows 11 récupère les éléments de configuration liés au poste :
Attendez encore afin que les éléments récupérés soit installés sur le poste :
Ce processus peut durer une vingtaine de minutes environ :
Différentes étapes sont alors réalisées, dont le détail est visualisable si besoin :
Après cela, Windows 11 s’ouvre et l’utilisateur peut déjà percevoir les éléments installés par la configuration :
Conclusion
J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible grâce à Autopilot. Bien entendu, ce type de déploiement ne pourra pas prendre en compte tous les scénarios et toutes les configurations.
C’est pour cela que, bien souvent, plusieurs méthodes de déploiement sont à envisager afin de couvrir un spectre toujours plus grand sur les besoins des utilisateurs et les exigences de configuration IT.
Continuons à nous intéresser à un autre service disponible sur Azure : le conteneur, aussi appelé virtualisation en micro-service. La conteneurisation est une méthode populaire pour le déploiement et la mise à l’échelle des applications depuis déjà plusieurs années. Peu importe l’hébergeur de Cloud public choisi, le conteneur reste un modèle très plébiscité par son fonctionnement, ses coûts et sa rapidité de mise en œuvre.
Avant de partir dans un exercice sur Azure, je vous propose de parcourir ensemble quelques notions importantes.
Qu’est-ce qu’un conteneur ?
Les conteneurs sont des environnements virtualisés, dont le but est d’exécuter généralement un micro-service. A la différence des machines virtuelles IaaS, les conteneurs sont dépourvus du système d’exploitation, car cette gestion OS est réalisée à un niveau supérieur. Cela rend leur création plus facile et ils sont beaucoup plus légers.
Un orchestrateur de conteneurs est utile pour gérer les conteneurs, mais également aussi pour manager les ressources exécutants ces conteneurs.
Conteneur ou machines virtuelles ?
Les machines virtuelles s’exécutent dans un hyperviseur (hôte) dans lequel chacune d’entre elles doit inclure son propre système d’exploitation invité (guest). En revanche, chaque conteneur partage le même système d’exploitation hôte ou noyau système. Donc l’un s’appuie sur l’autre :
Par contre, construire une application dans des conteneurs apportent plusieurs avantages non négligeables :
Moins lourd : Les conteneurs requièrent moins de ressources que les environnements de machines virtuelles, car ils n’incluent pas les images du système d’exploitation.
Plus rapide : Le démarrage d’un conteneur ne prend donc généralement que quelques secondes, contre plusieurs minutes pour une machine virtuelle.
Amélioration de la portabilité : Les applications qui s’exécutent dans des conteneurs peuvent être facilement déployées sur différents types de systèmes d’exploitation et de plateformes matérielles.
Efficacité accrue : Les conteneurs permettent de déployer, de corriger ou de faire évoluer les applications beaucoup plus rapidement.
Optimisation du développement d’applications : Les conteneurs accélèrent les cycles de développement, de test et de production grâce à la méthodologie agile et DevOps.
ACI vs AKS (K8s) ?
AKS et ACI sont deux plateformes populaires d’orchestration de conteneurs proposées par Microsoft Azure.
AKS est un service Kubernetes entièrement géré qui fournit une plateforme d’orchestration de conteneurs hautement disponible, évolutive et sécurisée.
ACI est une plateforme de conteneurs sans serveur qui vous permet d’exécuter des conteneurs sans avoir à gérer l’infrastructure sous-jacente.
Nodes vs Pods ?
Node : Un nœud correspond à une machine virtuelle. Cependant, vous pourriez créer un nœud à partir de presque n’importe quoi. Considérons un node comme un ensemble de ressources CPU et RAM qui peuvent être utilisées.
Pods : Kubernetes n’exécute pas les conteneurs directement ; ces derniers sont contenus dans une structure intermédiaire appelée Pod. Tous les conteneurs d’un même pod partagent les mêmes ressources et le même réseau local. Les conteneurs peuvent facilement communiquer avec d’autres conteneurs dans le même pod, comme s’ils étaient sur la même machine, tout en maintenant un certain degré d’isolation par rapport aux autres.
Kubernetes vs. Docker ?
Docker est une plateforme de conteneurisation et un moteur d’exécution, tandis que Kubernetes est une plateforme permettant d’exécuter et de gérer des conteneurs à partir de nombreux moteurs d’exécution de conteneurs. Kubernetes prend en charge de nombreux moteurs d’exécution de conteneurs, y compris Docker.
En résumé, Docker et Kubernetes ne poursuivent pas le même objectif : Docker vous permet de développer, déployer et donc itérer plus vite sur votre produit, tandis que Kubernetes est la solution pour le “runner” en production.
Afin de vous familiariser les conteneurs disponibles sur Azure sous différentes formes, je vous propose de suivre cet exercice dédié à ACI et AKS. La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur la page GitHub juste ici.
Voici la liste des tâches modifiées que nous allons réaliser :
Comme je le répète régulièrement, une ressource déployée entraîne un début de facturation de la part de Microsoft. Il est donc important de correctement dimensionner les ressources, et de les supprimer quand elles ne sont plus utilisées.
Rappel des prérequis :
Pour réaliser cet exercice sur ASK / ACI, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Mon environnement Azure de départ ne contient aucune autre ressource, commençons par Azure Container Instances.
Etape I – Test d’Azure Container Instances :
Connectez-vous sur le portail Azure, puis authentifiez-vous :
Commencez par rechercher le service Container instances depuis la barre, en haut de votre portail Azure :
Cliquez-ici pour créer votre service Azure Container Instance :
Remplissez tous les champs comme ceci, puis cliquez sur Suivant :
Dans l’onglet Réseau, nommez votre ACI. Celui-ci doit être valide et unique, puis cliquez sur Suivant :
Lancez la validation Azure :
Une fois la validation Azure réussie, cliquez-ici pour commencer la création :
Attendez environ une minute que le processus de création se termine, puis cliquez ici :
Reprenez le FQDN de votre instance ACI :
Ouvrez un nouvel onglet de navigateur, puis collez l’URL correspondante :
Retournez sur votre portail afin de consulter le log de votre instance.
Vérifiez l’entrée représentant la requête HTTP GET générée par l’affichage de l’application dans le navigateur :
Cette première étape très rapide sur ACI est maintenant terminé. Intéressons-nous maintenant à Azure Kubernetes Service (AKS), un orchestrateur managé de conteneurs disponible sur Azure.
Etape II – Enregistrement les fournisseurs de ressources AKS :
Pour cela, ouvrez Azure Cloud Shell depuis la barre bleue en haut de votre portail Azure :
Si besoin, créez un compte de stockage si celui-ci vous le demande :
Saisissez les deux commandes suivantes pour enregistrer les fournisseurs de ressources suivants :
Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :
Exécutez l’application à l’aide de la commande suivante :
kubectl apply -f azure-vote-v2.yaml
Constatez l’apparition de l’application sur votre portail Azure, puis attendez :
Environ 2 minutes plus, constatez le changement de statut en vert :
Vérifiez la bonne affectation de votre application sur le nœud ACI :
Cette information avait été renseigné dans le fichier YAML :
Ouvrez un nouvel onglet de navigateur en collant l’adresse IP correspondante :
Vérifiez que la page du navigateur affiche bien l’application de vote :
Testez l’application en votant pour Chiens ou Chats :
Ouvrez un nouvel onglet en navigation privée :
Vérifiez la persistance des votes précédemment réalisés :
Effacez votre résultat, puis fermez l’onglet de navigation privé :
Rafraichissez la page de test, puis constatez le même effacement des précédents votes :
Conclusion
Grâce à ce petit exercice, nous avons bien compris que le conteneur n’est qu’un moyen parmi d’autres pour faire tourner une application, avec de nombreux avantages.
Mais, quelle que soit la plateforme choisie, il est toujours primordial de suivre les bonnes pratiques pour concevoir, mettre en œuvre et gérer vos applications : à savoir la surveillance, optimisations, sécurité, confirmé et coûts 😎.
Par moment, les machines virtuelles ont besoin de passer entre les mains de l’IT pour différentes tâches : mises à jour OS, installation d’applications, résolution de problème, etc … A l’inverse des accès utilisateurs, les connexions réalisées par les équipes IT, dont les privilèges sont potentiellement plus élevés, sont souvent occasionnelles et externes.
Ce besoin de connexion irrégulier ne doit pas pourtant donner lieu à abaissement de la sécurité, car des risques pour vos VMs Azure sont toujours présents :
Risques d’attaque plus élevés si la sécurité de l’accès IT est dégradée
Risques de dégâts plus importants compte tenu des privilèges IT élevés
Comme pour n’importe quel accès, des mesures de sécurité en couche sont nécessaires, même pour les équipes IT. Voici des liens vers des articles précédemment écrits de blog :
Voici la définition d’Azure Bastion donnée par Microsoft
Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell) plus sécurisé et transparent pour les machines virtuelles sans aucune exposition via des adresses IP publiques. Approvisionnez le service directement dans votre réseau virtuel local ou appairé pour prendre en charge toutes les machines virtuelles qu’il contient.
Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux.
Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :
J’ai également trouvé une vidéo dédiée à Azure Bastion en français, dont voici le lien :
Quel est son point fort ?
Un seul mot doit vous venir en tête :
La sécurité
Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.
De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …
L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.
Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.
Combien coûte Azure Bastion ?
Disons-le tout de suite, Azure Bastion n’est pas un service gratuit 🤣. La documentation Azure nous donne toutes les informations tarifaires. Voici la copie d’écran du service dans la région Azure Suisse Nord :
Voici ces mêmes données tarifaires pour un mois complet, dans le cas où le service reste actif :
Azure Bastion Basic : 125 CHF environ
Azure Bastion Standard : 192 CHF environ
Gardez à l’esprit que ce service ne nécessite pas systématiquement un déploiement aussi long. Dans beaucoup d’infrastructures IT, il est possible d’envisager son déploiement à la demande.
Cinq petites minutes vous suffiront pour déployer Azure Bastion !
Comment choisir son SKU Bastion ?
Choisir le SKU d’Azure Bastion adapté à vos besoins doit reposer sur les fonctionnalités voulues. Quelques fonctionnalités diffèrent entre les versions Basic et Standard :
A noter qu’il est possible de migrer du SKU Basic au SKU Standard après le déploiement de Bastion, mais pas le chemin inverse n’est plus possible.
Comment mettre en place Azure Bastion ?
Rien de plus simple ! Quelques clics suffisent pour déployer Azure Bastion.
Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités de connexion. Bref, ne perdons pas de temps :
Pour réaliser cet exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Mon environnement Azure de départ ne contient aucune autre ressource, commençons par la préparation d’un nouvel environnement Azure :
Etape I – Préparation de votre environnement Azure :
Commencez par rechercher le service Réseau Virtuel dans la barre de recherche tout en haut :
Cliquez ici pour créer votre premier réseau virtuel Azure :
Créez un premier groupe de ressources, donnez un nom à votre réseau virtuel, puis lancez la validation Azure :
Une fois la validation Azure réussie, cliquez-ici pour commencer la création :
Attendez environ une minute que le processus de création se termine :
Une fois terminé, recherchez le service des Machines Virtuelles Azure :
Cliquez-ici pour créer une première machine virtuelle Azure :
Renseignez les informations de base relatives à votre VM :
Pensez à désactiver les règles publiques de port entrant, puis cliquez sur Suivant :
Aucune option n’est à modifier sur l’onglet des disques, cliquez sur Suivant :
Dans l’onglet réseau, effectuez les modifications suivantes :
Retirez l’adresse IP publique proposée par Azure
Vérifiez que les règles publiques du NSG lié à la carte réseau de la VM sont bien désactivées
Puis, cliquez-ici pour lancer la validation :
Une fois la validation réussie, cliquez-ici pour démarrer le processus de création :
Environ deux minutes plus tard, cliquez-ici pour accéder à votre machine virtuelle Azure :
Cliquez sur Connecter pour démarrer une session de bureau à distance :
Azure commence par effectuer contrôles d’accès. Deux points sur trois sont déjà considérés comme des blocages potentiels :
Port RDP fermé : L’accès publique au port RDP a été volontairement fermé lors de la création de la machine virtuelle.
Absence d’adresse IP publique : celle-ci a volontairement été retirée lors de la création de la machine virtuelle.
Cliquez-ici pour télécharger le fichier RDP préconfiguré pour vous connecter à votre VM :
Exécutez le fichier RDP téléchargé précédemment, puis attendez :
Environ vingt secondes plus tard, un message d’échec de connexion doit apparaître :
Pas d’adresse IP publique et pas de port RDPouvert en public sont bien les explications logiques du blocage de l’accès distant.
Retrouvez la configuration de ces deux points justes ici :
L’accès RDP à notre machine virtuelle est bien sécurisé. Mais du coup … personne en dehors d’Azure peut s’y connecter ! Il nous faut trouver une solution sans exposer la machine virtuelle.
C’est ici qu’Azure Bastion rentre en scène.
Etape II – Déploiement d’Azure Bastion :
Comme l’indique le schéma ci-dessous, Azure Bastion s’installe sur un sous-réseau dédié dont son nom est normé : AzureBastionSubnet.
Sur votre Portail Azure, recherchez le réseau virtuel créé précédemment :
Dans la section des sous-réseaux, ajoutez-en un :
Le sous-réseau doit avoir la configuration suivante :
Le nom du sous-réseau doit être AzureBastionSubnet.
La taille du sous-réseau doit être /26 ou plus grand
Le sous-réseau ne pourra pas contenir d’autres ressources Azure
Renseignez les champs, puis sauvegardez-le :
Recherchez ensuite le service Bastion dans la barre de recherche du portail Azure :
Cliquez-ici pour créer votre Azure Bastion :
Renseignez les champs nécessaires, en prenant soin de sélectionner un SKU de type Basic, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création de votre Azure Bastion :
Attendez environ 5 minutes pour que le service soit entièrement déployé sur votre environnement :
Retournez sur votre machine virtuelle de test, puis lancez une connexion comme ceci :
Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :
Un nouvel onglet dans votre navigateur interne s’ouvre et ouvre une session Windows sur votre machine virtuelle :
Gardez ouverte la session de bureau à distance via Azure Bastion.
Sur la partie gauche de votre session, notez la présence de deux flèches, cliquez dessus, puis constatez le presse-papier de base :
Retournez sur le portail Azure, le menu Session affiche une liste des utilisateurs connectés à Azure Bastion.
Note : Il est en effet possible d’ouvrir plusieurs sessions Bastions vers différentes machines virtuelles.
Votre service Bastion fonctionne bien, l’accès RDP à votre machine virtuelle Windows est sécurisé. Continuons un peu en testant une autre méthode de connexion grâce à Azure Bastion.
Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure :
Bien souvent, les infrastructures Azure contiennent plusieurs réseaux virtuels. Cela fait sens dans le cadre d’architecture multi-régions. Ici, nul besoin de créer et de payer plusieurs Bastion !
Afin de tester le bon fonctionnement d’un seul service Azure Bastion sur un autre réseau virtuel, j’ai créé les ressources Azure suivantes :
Second réseau virtuel Azure
Seconde machine virtuelle Azure
Appairage entre les 2 réseaux virtuels
Voici l’appairage et son statut Connecté sur un des 2 réseaux virtuels :
Sur la seconde machine virtuelle, cliquez sur le service Azure Bastion pour m’y connecter :
Azure recherche si un service Bastion est déployé sur le même réseau virtuel
Si non, Azure recherche un Bastion sur un réseau virtuel appairé à celui-ci
Renseignez les identifiants de l’administrateur local de ma seconde VM, puis cliquez sur Connecter :
Constatez la bonne connexion RDP à ma seconde machine virtuelle :
Azure Bastion fonctionne donc de manière étendue à plusieurs réseaux virtuels. Cette fonction est accessible dès le SKU Basic. Aucun doute que cela est fortement apprécié car il simplifie les méthodes de connexion, mais réduit aussi les coûts !
D’autres méthodes de connexion sont disponibles via Azure Bastion, mais elles nécessitent de changer le SKU de notre service.
Etape IV – Upgrade d’Azure Bastion vers le SKU Standard :
Pour tester les autres méthodes de connexion, il nous est nécessaire de changer le SKU d’Azure Bastion de Basic vers Standard :
Attendez quelques minutes qu’Azure applique votre upgrade :
Le changement de SKU d’Azure Bastion entraine d’ailleurs une fermeture des sessions ouvertes via Azure Bastion :
Quelques minutes plus tard, le traitement d’upgrade est terminé :
Notre Azure Bastion est maintenant Standard. Nous allons pouvoir tester d’autres moyens de connexion, comme par exemple via le client natif.
Etape V – Support du client natif d’Azure Bastion :
La fonctionnalité de client natif vous permet de vous connecter à vos machines virtuelles cibles par le biais de Bastion en utilisant Azure CLI
En quelques mots, cette méthode est utile quand on souhaite se passer du portail Azure. Pour utiliser ce moyen de connexion, il est nécessaire d’activer ce service sur Bastion.
Comme les options supplémentaires de Bastion sont maintenant dégrisées, cochez la case Support du client natif, puis cliquez sur Appliquer :
Attendez quelques minutes qu’Azure applique votre modification :
Sur votre poste local, ouvrez une session Terminal :
Commencez par mettre à jour le sous-module réseau d’Azure, utilisé par Azure Bastion :
Update-Module Az.Network -Force
Attendez quelques minutes que le téléchargement, puis l’installation du module se termine :
Copiez l’ID de la souscription contenant votre service Azure Bastion :
Dans votre fenêtre Terminal, lancez le processus d’authentification à Azure :
az login
Microsoft Edge doit alors s’ouvrir pour vous proposer de réutiliser un compte Azure déjà authentifié. Cliquez sur celui-ci si cela est votre cas :
Le message suivant apparaît alors dans votre navigateur :
De retour sur Terminal, saisissez la commande pour vous positionner sur la souscription Azure de votre Bastion :
az account set --subscription "<subscription ID>"
Sur le portail Azure, récupérez l’ID de ressource de votre première machine virtuelle :
Dans votre fenêtre Terminal, saisissez la commande suivante en prenant soin de modifier les 3 variables suivantes :
Nom de votre ressource Azure Bastion
Groupe de ressources votre service Azure Bastion
ID de ressource de votre machine virtuelle
az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>"
Un pop-up RDP s’ouvre alors, cliquez sur Connecter :
Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM :
Acceptez le risque en cliquant sur Oui :
Une connexion RDP s’ouvre sur le bureau de votre VM :
Fermez la session de bureau à distance.
Comme Microsoft et d’autres le rappellent, la sécurité de la connexion native peut être renforcée en limitant l’accès uniquement aux ports 22/3389 :
Continuons en testant une autre méthode de connexion à Azure Bastion: les liens partageables.
Etape VI – Utilisation de liens partageables Azure Bastion :
La fonctionnalité lien partageable Bastion permet aux utilisateurs de se connecter à une ressource cible (machine virtuelle ou groupe de machines virtuelles identiques) à l’aide d’Azure Bastion sans accéder au Portail Azure.
Là encore, l’accès au portail Azure n’est peut-être pas possible ou voulue. Le lien partageable peut être communiqué à un tier afin que celui-ci puisse se connecter à la machine virtuelle et y effectuer des opérations IT.
Dans l’écran de configuration d’Azure Bastion, cochez la case suivante, puis cliquez sur Appliquer :
Attendez quelques minutes afin qu’Azure applique votre modification :
Un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion. Cliquez-ici pour créer votre premier lien partagé :
Cochez la ou les machines virtuelles accessibles grâce à ce lien, puis cliquer sur Appliquer :
Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :
Ouvrez un navigateur privé :
Collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez-ici pour ouvrir la session :
Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :
Avant de fermer la session ouverte grâce au lien partagé, supprimez le lien généré :
Constatez l’absence de fermeture de session, malgré la suppression du lien.
Fermez la session puis retentez l’ouverture par la même URL précédemment copiée :
L’utilisateur est bien bloqué dans sa seconde tentative de connexion.
Ces liens partagés sont donc intéressant si les utilisateurs sont externes au service IT doivent intervenir très ponctuellement sur une machine virtuelle.
Continuons nos tests sur une autre méthode de connexion : les adresses IP privées.
Etape VII – Utilisations des adresses IP privées :
Une connexion basée sur IP vous permet de vous connecter à vos machines virtuelles Azure et non Azure locales via Azure Bastion sur ExpressRoute ou une connexion VPN site à site en utilisant une adresse IP privée spécifiée.
Grâce à cette fonctionnalité, les équipes IT peuvent se connecter à presque tous les VMS grâce à Azure Bastion ! Peu importe où la ressource se trouve : dans ou en dehors d’Azure.
Pour tester cette fonctionnalité, j’ai modifié quelques peu mon infrastructure Azure déjà en place. J’ai simulé une connexion site à site entre mes 2 réseaux virtuels comme ceci :
J’ai supprimé l’appairage entre mes deux réseaux virtuels
Sur chacun de mes deux réseaux virtuels Azure, j’ai déployé les ressources suivantes :
Passerelle VPN Basic
Passerelle de réseau local reprenant l’IP publique du VPN opposé
Connexion VPN IP Sec
Une des 2 passerelles VPNs configurées :
Une des 2 passerelles de réseau local configurées :
Une des 2 connexions VPN configurées :
Une fois l’infrastructure réseau en place, cochez la case suivante dans la configuration d’Azure Bastion, puis cliquez sur Appliquer :
Attendez quelques minutes qu’Azure applique votre modification :
Un nouveau menu dédié aux adresses IP privées fait son apparition sur votre configuration Azure Bastion. Cliquez-ici pour créer établir une connexion directe :
Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :
Sur une des 2 connexions VPNs, modifiez la clef partagée afin de briser la connexion entre les 2 réseaux virtuels, et de ce fait, couper la session de bureau à distance :
Attendez quelques secondes :
La session d’Azure Bastion fini bien par s’interrompre :
Restaurez la bonne clef partagée, puis sauvegardez :
La connexion du bureau à distance transitant par Bastion est alors automatiquement rétablie :
Conclusion
Bastion rejoint la liste des services managés Azure très utile et très facile à mettre en oeuvre. La non-maîtrise des réseaux rend l’outil encore plus accessible aux débutants, et apporte une première couche de sécurité.
Il ne faut jamais douter des capacités d’attaque de pirates quand des ressources se retrouvent exposées sur internet, Cloud ou pas.
Azure Virtual Desktop n’en finit plus d’évoluer ! Aujourd’hui est une grande journée pour l’automatisation des environnements AVD. Jusqu’à présent, Azure proposait peu de solutions adéquates pour AVD pour faciliter le processus de gestion des images des VMs. Pour enfoncer le clou(d), d’autres solutions tierces faisaient déjà mieux et rendaient le travail IT beaucoup plus léger.
Microsoft vient donc de sortir une nouvelle fonctionnalité à son produit AVD, encore en préversion à ce jour, mais attendue depuis fort longtemps : Custom image templates, ou Modèles d’images personnalisés pour les francophones.
Aucun doute que les administrateurs d’AVD vont aimer !
Pourquoi doit-on gérer des images avec Azure Virtual Desktop ?
La gestion des applications et des mises à jour d’un environnement AVD reste très proche d’un environnement RDS traditionnel. De temps à autre, il vous faut penser à :
Les applications doivent être mises à jour
Les mises à jour correctives ou sécuritaires doivent être appliquées
Les besoins logiciels des utilisateurs évoluent
De nouvelles optimisations sont disponibles
Toutes ces raisons et encore d’autres font que les machines virtuelles d’un environnement Azure Virtual Desktop doivent être mises à jour régulièrement, et si possible, avec un mode opératoire le plus automatisé.
Que proposait Azure Virtual Desktop avant cette fonctionnalité ?
En cherchant un peu, on retrouvait déjà plusieurs méthodes qui avaient déjà fait leurs preuves :
Gestion 100% manuelle via Golden Image / Sysprep / Snapshot :
Gestion 50% manuelle via l’utilisation d’un Template d’Azure Image Builder :
Solutions tierces, comme par exemple la très connue Nerdio :
Sur quoi repose la fonction Custom image templates d’AVD ?
Disons-le tout de suite, Custom image templates fonctionne toujours avec Azure Image Builder.
Mais tout est maintenant intégré dans la console Azure Virtual Desktop. Et le meilleur dans tout ça :
l’intégration d’optimisations est gérée dans le template, qu’elles soient préconstruites par Microsoft ou créées par vos soins !
C’est tout le processus de préparation qui peut alors s’intégrer dans la seule étape de création du template. Fini les aller et retours !
Bref, ne perdons pas de temps, et testons ensemble cette fonctionnalité.
Pour réaliser cet exercice sur les templates d’Azure Virtual Desktop, encore en préversion, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de ne pas rendre cet article trop long, j’ai déjà préparé un environnement Azure. Je vous liste dans l’étape suivante tous les composants déjà mis en place sur mon environnement avant de démarrer le test.
Etape I – Préparation de votre environnement Azure Virtual Desktop :
J’ai créé un premier groupe de ressources Azure, dans lequel j’ai déployé 2 VMs :
Une première machine virtuelle Windows Server avec des rôles AD DS / DNS
Une seconde machine virtuelle Windows Server avec Azure AD Connect
J’ai également déployé dans un second groupe de ressources pour :
Un réseau virtuel pour l’ensemble de mon infrastructure AD DS / AVD :
Un service Azure Bastion pour me connecter aux différentes machines de mon domaine
Dans ce réseau virtuel Azure, nous retrouvons les sous-réseaux suivants :
Sous-réseau pour la partie domaine / Azure AD Connect
Sous-réseau pour les machines virtuelles AVD
Sous-réseau dédié au service Azure Bastion
Je n’ai pas oublié non plus de renseigner l’adresse IP locale de mon AD en tant que DNS de premier niveau sur mon réseau virtuel :
J’ai également déployé une Azure Compute Gallery, dans laquelle se trouvent une définition de base d’une image pour mon environnement AVD :
Grâce à la mise en place du domaine Active Directory et d’Azure AD Connect, j’ai pu synchroniser deux utilisateurs AD vers Azure AD :
J’ai également créé un compte de stockage Azure. Grâce à la tâche 6 de cet article, j’ai configuré ce compte de stockage pour être joint à mon Active Directory.
J’ai également créé un partage de fichier pour la gestion des profiles en itinérance via FSLogix :
Je n’ai pas oublié de rajouter les rôles Azure RBAC spécifiques au partage SMB FSLogix :
J’ai également transposé ces droits Azure RBAC en droits NTFS sur ce même partage FSLogix :
J’ai enfin vérifié, au niveau de ma souscription Azure, le bon enregistrement des fournisseurs de ressources suivants :
Microsoft.VirtualMachineImages
Microsoft.KeyVault
Si cela n’est pas fait, voici la procédure qui vous prendra à peine deux minutes :
Votre environnement de départ est enfin prêt pour commencer la mise en place de Modèles d’images personnalisés pour AVD.
L’étape suivante est donc consacré à la mise en place d’une identité managée pour Azure VM Image Builder.
Etape II – Azure VM Image Builder :
VM Image Builder est un service Azure complètement managé qui est accessible aux fournisseurs de ressources Azure. Les fournisseurs de ressources le configurent en spécifiant une image source, une personnalisation à effectuer et l’emplacement où la nouvelle image doit être distribuée.
Pour que Azure VM Image Builder gère des images AVD, il est nécessaire de lui créer une identité managée Azure. Celle-ci disposera des autorisations nécessaires pour lire et écrire des images :
Au niveau de votre souscription Azure, rendez-vous dans le menu suivant pour commencer la création d’un rôle personnalisé :
Donnez-lui un nom, puis cliquez sur Suivant :
Parcourez la liste des permissions disponibles afin d’ajouter celles ci-dessous :
Dean met aussi à disposition sur son GitHub un template JSON contenant ces permissions.
Définissez le périmètre de la souscription Azure pour ce nouveau rôle :
Lancez la création en cliquant sur Créer :
Sur votre portail, recherchez dans la barre du haut le services des Identités Managées :
Cliquez-ici pour créer votre Identité Managée dédiée à Azure VM Image Builder :
Nommez celle-ci, puis lancez la validation :
Une fois la validation passée, cliquez sur Créer :
Retournez au niveau de la souscription Azure pour assigner le rôle personnalisé à votre nouvelle identité managée :
Recherchez le rôle personnalisé en utilisant le filtre :
Cliquez ici pour rechercher dans Azure AD votre nouvelle identité managée :
Lancez la validation de votre affectation :
Une fois la validation passée, cliquez sur Assigner :
Toutes les étapes préparatoires à la création d’un modèle d’image personnalisé sont maintenant terminées. Nous allons pouvoir maintenant commencer la création de notre template AVD.
Comme le rappelle Dean durant sa vidéo, d’autres options seront prochainement rajoutées par la suite.
Etape III – Création d’un modèle d’image personnalisé :
Recherchez le service Azure Virtual Desktop en utilisant la barre du haut :
Dans le menu Modèle d’image personnalisés, cliquez-ici pour ajouter votre premier template :
Nommez votre template, choisissez sa localisation, reprenez l’identité managée créée et affectée précédemment, puis cliquez sur Suivant :
Sélectionnez votre image source, en utilisant par exemple la Marketplace Microsoft :
Concernant le stockage de votre template AVD, deux destinations sont possibles avec Azure VM Image Builder :
Image managée : utilisable pour AVD ou Windows 365
Azure Compute Gallery : utilisable pour AVD
Cochez la cible Azure Compute Gallery, renseignez les informations nécessaires, puis cliquez sur Suivant :
Azure VM Image Builder a besoin de quelques informations durant le processus de fabrication :
Timeout : à définir si besoin. Si vide, alors 240 minutes
Taille de la VM : taille sans rapport direct avec les futures VMs AVD
Taille du disque OS : taille avec rapport direct sur celui des futures VMs AVD
Groupe de ressources temporaire : Si laissé vide, le groupe sera créé par Azure
Réseau Virtuel : champs facultatifs
Puis cliquez sur Suivant :
Azure VM Image Builder vous propose d’exécuter à votre place des traitements post-déploiement. Vous pouvez lancer vos propres scripts, ou piochez dans la longue liste mise à disposition par Microsoft.
Cliquez-ici pour ajouter votre propre script, si besoin :
Cliquez-ici pour consulter la liste des scripts dédiés à AVD et construits par Microsoft :
Choix dans la liste les options voulues, puis sauvegardez :
Vérifier une dernière fois les options choisies, puis cliquez sur Suivant :
Ajoutez les étiquettes pour une meilleure classification de vos ressources Azure, puis cliquez sur Suivant :
Lancez la création de votre template en cliquant sur Créer :
Environ quelques secondes plus tard, le processus de création du template se lance, le statut passe alors en Création :
La création d’un template est assez rapide, le statut doit alors changer en Succès et le nom du groupe de ressources temporaire doit apparaître.
Cliquez dessus pour voir la première ressource créée :
Seul un compte de stockage est pour l’instant créé, cliquez dessus :
Un premier conteneur Blob est créé, dans lequel se trouvent les optimisations de votre template AVD :
Retournez sur les Modèles d’images personnalisés, puis cliquez sur le groupe de ressources de votre template :
Constatez la présence de votre template :
Le template, ou la recette de votre VM AVD, est maintenant prêt. Un second processus doit être lancé pour créer l’image AVD en elle-même. Azure VM Image Builder va réaliser les actions suivantes :
Créer une machine virtuelle à partir de la marketplace
Lui appliquer votre configuration personnalisée
La capturer et la stocker dans votre Azure Compute Gallery
Etape IV – Préparation de l’image AVD :
Ce processus peut prendre beaucoup de temp. Celui-ci dépendra également des personnalisations choisies à appliquer.
Cliquez-ici pour démarrer le processus de construction de votre image :
Le statut de construction change comme ceci :
Deux nouveaux conteneurs sont créés sur votre compte de stockage temporaire :
packerlogs : Journal d’évènements d’Azure VM Image Builder
vhds : fichier VHD de votre image créé par Azure VM Image Builder
Cliquez sur le premier conteneur afin de consulter, si besoin, le journal de log d’Azure VM Image Builder :
Rafraichissez cette page afin de voir le changement de statut :
Rafraichissez également cette seconde page afin de voir les changements de date de modification du journal d’évènements :
Environ 2 heures plus tard, le statut est enfin passé à Succès :
Vérifiez que la définition de votre image est bien stockée dans votre Azure Compute Gallery :
La version de l’image est également visible dans le groupe de ressources cible :
Notre image est enfin prête à intégrer un environnement Azure Virtual Desktop.
L’étape suivante consiste donc à créer un premier pool AVD en choisissant comme source cette nouvelle image personnalisée.
Etape V – Création de l’environnement AVD :
Sur la page Azure Virtual Desktop, commencez la création de votre environnement Azure Virtual Desktop comme ceci :
Définissez les options de base de votre pool d’hôtes :
Ajoutez une ou plusieurs machines virtuelles en prenant le soin de choisir l’image créée et stockée dans votre Azure Compute Gallery :
Renseignez les informations réseaux pour que votre VMs AVD se trouve sur le même réseau virtuel que votre AD :
Renseignez les informations liées à votre AD et les identifiants pour disposer d’un compte administrateur local, puis cliquez sur Suivant :
Créez un nouvel Espace de travail, puis lancez la validation :
Une fois la validation terminée, cliquez sur Créer :
Attendez environ 5 à 10 minutes, le temps que la création de votre environnement AVD se termine, puis cliquez ici :
Changez l’option d’authentification d’Azure AD, puis sauvegardez :
Cliquez sur le groupe d’applications AVD :
Ajoutez vos utilisateurs ou votre groupe d’utilisateurs de test :
C’est enfin fini ! Toutes les configurations sont faites ! Il ne vous reste plus qu’à tester votre nouvel environnement Azure Virtual Desktop.
Etape VI – Test de connexion à votre environnement AVD :
Pour cela, utilisez le client Remote Desktop disponible ici, ou l’URL suivante pour une connexion en HTLML5 via le navigateur internet.
Ouvrez votre application, souscrivez à un nouvel espace de travail, puis authentifiez-vous avec un compte utilisateur de test :
Réauthentifiez-vous une seconde fois, localement :
Attendez que la session de bureau à distance s’ouvre :
Vérifiez quelques paramétrages personnalisés, comme la langue ou les applications installées :
Les choses semblent pas mal pour moi sauf le pays et encore l’heure de la VM :
Vérifiez également sur votre compte de stockage dédié à FSLogix que l’ouverture de session AVD génère bien la création d’un profil itinérant :
On peut dire qu’on est pas mal, non ? 😎
Conclusion :
L’intégration Azure VM Image Builder dans la console Azure Virtual Desktop, mais aussi l’ajout direct de personnalisations, proposées par Microsoft, est un véritable pas en avant concernant la simplification !
Azure Virtual Desktop conserve malgré tout la caractéristique de pouvoir être personnalisé manuellement, mais apporte en parallèle une couche d’automatisme pour les petits environnements.
Nul doute que tout cela sera très fortement apprécié !
Beaucoup de projets d’infrastructure Cloud contiennent des services Cloud de type IaaS. Entièrement configurable, une machine virtuelle en est un bon exemple chez tous les principaux fournisseurs de Cloud. Le IaaS apporte des avantages par une grande flexibilité, mais aussi des inconvénients, comme par exemple sa gestion des mises à jour.
Dans le cadre d’un hébergement d’un service web, la machine virtuelle n’est d’ailleurs pas le premier choix proposé par les fournisseurs Cloud. Néanmoins, il arrive qu’une machine virtuelle soit le seul choix technique possible.
Dans cet article, nous n’allons pas nous intéresser au choix VM / App Service. Mais à la mise en place d’une alerte de disponibilité HTTP, dans le but vérifier le bon fonctionnement de l’accès externe.
Que sont les alertes d’Azure Monitor ?
Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.
Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.
Il est très facile de créer une alerte sur un Web App. Mais il est aussi possible d’en créer sur d’autres services, comme sur un service IIS hébergé sur une machine virtuelle.
Afin des tester ce scénario, nous allons créer une machine virtuelle avec un rôle IIS afin de créer une alerte HTTP pour vérifier sa bonne disponibilité à travers le globe :
Pour réaliser cet exercice sur les alertes d’Azure Monitor, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Si vous ne disposez pas de machine virtuelle Azure sur votre environnement, commencez par l’étape I afin de préparer l’environnement nécessaire à la mise en place de l’alerte.
Etape I – Création de la machine virtuelle Azure :
Commencez par créer une Machine Virtuelle Azure en utilisant la barre de recherche en haut du portail :
Sélectionnez le premier choix pour créer votre machine virtuelle :
Sur le premier onglet, renseignez les champs relatifs aux principales caractéristiques de votre VM :
Définissez un compte d’administrateur local, ouvrez le port HTTP pour le traffic entrant, puis cliquez sur Suivant :
Cliquez sur Suivant pour continuer la configuration :
Vérifiez sur cet onglet que le port HTTP est toujours listé, puis cliquez-ici pour lancer la validation de la configuration :
Une fois la validation correctement terminée, cliquez sur Créer :
Environ 3 minutes plus tard, votre machine virtuelle est créée et est accessible.
Cliquez-ici pour rentrer dans la configuration de votre VM :
Copiez l’adresse IP publique de votre machine virtuelle :
Ouvrez un nouvel onglet dans votre navigateur, puis collez l’adresse IP publique précédemment copiée :
Le message d’erreur affiché s’explique par l’absence d’écoute sur le port 80 (HTTP) de votre machine virtuelle.
Pour y remédier, nous allons installer le rôle IIS (Internet Information Services) sur votre machine virtuelle.
Etape II – Installer un rôle IIS sur votre machine virtuelle :
Comme aucun port RDP n’est ouvert sur la machine virtuelle, utilisez le menu suivant pour lancer le script d’installation de IIS depuis le portail Azure :
Lancez le script, puis attendez que celui-ci se termine :
Environ 2 minutes plus tard, constatez la bonne exécution du script :
Dans l’onglet précédemment ouvert avec l’adresse IP publique de votre machine virtuelle, rafraichissez la page web, puis constatez l’apparition de la page d’accueil de IIS :
Notre environnement est maintenant en place, il ne nous reste qu’à installer le mécanisme d’alerte. Avant cela, il est nécessaire d’ajouter d’autres composants Azure.
Etape III – Configuration du test de disponibilité HTTP :
Sur votre portail Azure, commencez par rechercher le service Application Insights :
Créez votre premier application Insights :
Renseignez tous les champs, également ceux concernant la création d’un Log Analytics Workspace, puis lancez la validation :
Une fois validation terminée, lancez le processus de création des ressources :
Environ 3 minutes plus tard, cliquez-ici pour configurer votre Application insights :
Cliquez-ici pour ajouter votre test HTTP :
Renseignez les informations demandées, ainsi que l’adresse IP publique de votre VM au format HTTP://, puis choisissez la fréquence et les régions Azure dont le signal de test doit provenir :
Le test est maintenant en place
Etape IV – Vérification du test de disponibilité HTTP :
Attendez environ 2 minutes, puis cliquez sur Rafraichir :
Les premiers succès de réponse apparaissent :
A droite se trouvent des compteurs de succès et d’échecs
Le détail par région source est affiché en bas
Un graphique avec un taux de disponibilité est présent en haut à gauche
Un tour dans les logs de notre Application Insights affiche bien toutes les informations stockées par chaque test :
Toutes ces informations bien pratiques, mais les administrateurs IT doivent aussi être alertés quand le service HTTP est en panne. Il est donc nécessaire de mettre en place une règle d’alerte pour les avertir au plus tôt.
Un mail sur une messagerie surveillée est une bonne pratique.
Etape V – Configuration des alertes de disponibilité :
Toujours dans votre Application Insights, rendez-vous dans la section des alertes pour modifier la règle d’alerte déjà en place :
Cliquez sur la règle d’alerte portant le nom combo « alerte »-« Application Insight » :
Cliquez ensuite sur Editer :
Sous la section Actions, cliquez-ci dessous :
Cliquez-ici pour créer un groupe d’actions :
Nommez-le, puis passer sur l’onglet suivant :
Dans l’onglet Notifications, définissez un type de notification Email, puis nommez-le également :
Renseignez une adresse email à cibler :
Cliquez sur Créer votre groupe d’actions :
Sauvegardez votre règle d’alerte :
Attendez quelques secondes, puis constatez la bonne modification de celle-ci :
Quelques secondes après, le destinataire du groupe d’actions reçoit un email lui informant son intégration dans un système de règle d’alerte Azure :
Il ne nous reste plus qu’à tester la notification par email. Pour cela, rien de plus simple, un arrêt de la machine virtuelle Azure devrait suffire.
Etape VI – Test de la notification d’alerte :
Avant d’arrêter votre machine virtuelle, vérifier la bonne santé du test de disponibilité de votre HTTP :
Retournez sur la page des machines virtuelles, puis déclenchez un arrêt de celle-ci :
Confirmez la procédure d’arrêt :
Retournez sur l’onglet internet ouvert sur l’adresse IP publique de votre machine virtuelle, puis constatez l’apparition d’un message d’indisponibilité :
Retournez sur le test d’alerte de votre Application Insights, les premiers échecs devraient apparaître.
Notez que la notion de 5 minutes entre deux tests ne s’applique que pour chaque région Azure. C’est donc pour cela que les tests sont très fréquents, car le test de disponibilité repose ici sur 5 régions :
Une fois que 2 localisations sur 5 constatent des échecs, l’alerte est déclenchée et le mail est envoyé sur l’adresse de message renseignée sur le groupe d’actions :
Consultez le détail de cette alerte :
Retournez sur la page des machines virtuelles, puis redémarrez la VM précédemment éteinte :
Quelques minutes plus tard, un autre email arrive sur la boite de messagerie. Celui-ci indique une bonne reprise de la disponibilité sur les régions concernées :
De retour sur la page des alertes de notre Applications Insights, l’alerte n’y figure plus car elle a été automatiquement levée :
Il est malgré tout possible de retrouver l’historique de cette alerte en retirant un filtre :
Conclusion :
L’architecture Cloud n’est pas infaillible et la mise en place d’alerte permet de gérer au plus tôt un incident. Ce type de règle alerte ne coûte pas cher et permet de centraliser l’information sur un seul point. Un autre test intéressant serait de créer une alerte sur la charge d’une machine virtuelle ou d’un autre service de calcul.
A l’ère des environnements Cloud ou hybride, la façon dont on consomme la donnée a complètement changé. Maintenant, tout est question de mobilité, d’accessibilité et de collaboration. Mais cette ouverture s’accompagne aussi de risques dont les origines, humaines ou logicielles, sont intrinsèques.
Microsoft, et comme d’autres acteurs du marché, s’efforce depuis plusieurs années d’y remédier via sa suite Microsoft 365 Defender. Dans cet article, nous allons nous intéresser à une licence apparue fin 2021 : Microsoft Defender for Business.
Avant de rentrer dans le vif du sujet, je vous propose de revenir sur plusieurs grands aspects relatifs à la sécurité, dont certains font déjà l’objet d’articles sur ce blog :
Quel que soit l’environnement IT, le principe des couches sécurité s’applique.
Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de l’entreprise :
Une architecture Cloud n’échappe pas non plus à cette règle, il est naif de penser que les solutions d’hébergement publics sont toutes à 100% protégées par le fournisseur. Les mesures et l’intelligence dédiée à la sécurité y sont certes plus avancées, mais plusieurs couches nécessiteront obligatoirement votre contribution.
Qu’est-ce que Microsoft 365 Defender ?
Voici comment Microsoft le définit :
Microsoft 365 Defender est une suite de défense d’entreprise pré-et post-violation unifiée qui coordonne en natif la détection, la prévention, les examens et la réponse sur les points de terminaison, les identités, les messages électroniques et les applications pour fournir une protection intégrée contre les attaques sophistiquées.
Pour simplifier au maximum, Microsoft Defender vous propose des services de sécurité dans 4 grands domaines :
Sécurité I – Identités avec Defender for Identity :
Solution de sécurité basée sur le cloud qui tire parti de votre AD local signaux pour identifier, détecter et examiner les menaces avancées, les identités compromises et les actions internes malveillantes dirigées contre votre organisation.
Sécurité II – Périphériques grâce Defender for Endpoint :
Plateforme unifiée pour la protection préventive, curative, ainsi pour que des méthodes d’investigation et de réponse automatisées sur les postes et les serveurs.
Sécurité III – Applications avec Defender for Cloud Apps et Defender for Office 365 :
Defender pour Office 365 protège votre organisation contre les menaces malveillantes posées par les messages électroniques, les liens (URL) et via les outils de collaboration.
Microsoft Defender for Cloud Apps est une solution multi-SaaS complète qui offre une visibilité approfondie, des contrôles de données forts et une protection renforcée contre les menaces à vos applications cloud.
Sécurité IV – Données avec Microsoft Purview :
Famille de solutions en matière de gouvernance, de risques et de conformité des données qui peuvent aider votre organisation à régir, protéger et gérer l’ensemble de votre patrimoine de données.
La donnée est la valeur la plus importante pour une entreprise. Que celle-ci porte sur des secrets industriels, des informations clients ou des mesures financières, il est toujours nécessaire de l’appréhender selon ces 3 grands principes :
Les données ne sont pas créées de manière égale. Certaines données sont plus sensibles et nécessitent un niveau de protection et de contrôle plus fort que d’autres types.
Quand est-ce que Microsoft 365 Defender for Business rentre en scène ?
Les petites et moyennes entreprises sont-elles-aussi soumises aux mêmes risques que certaines multinationales. La solution gérant la sécurité des postes ne doit surtout pas être dégradée :
Au-delà de toutes les fonctionnalités proposées par cette licence, voici pourquoi je la trouve intéressante pour les SMB dans la gestion de la sécurité des postes et des serveurs :
Simplification dans la gestion et dans le processus l’onboarding
Intégration avec Microsoft Intune
Recommandations de sécurité activées dès le départ
Tableau de bord orienté vers l’action aidant à hiérarchiser les tâches
Centralisation des environnements avec Microsoft 365 Lighthouse
Afin de tester la protection des périphériques grâce à cette licence, je vous propose de créer un environnement de démonstration sur Azure.
Pour cela, nous utiliserons des machines virtuelles en Windows 11 issues d’Azure Virtual Desktop. Ces machines seront alors jointes à Azure AD, Intune, puis Microsoft 365 Defender.
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice sur Microsoft Defender for Business, il vous faudra disposer de :
Un tenant Microsoft
Un ou plusieurs licences Microsoft 365 Business Premium
Une souscription Azure valide
Etape I – Vérification de l’environnement de départ :
Avant de commencer le déploiement de ressources Azure, consultez les licences présentes sur votre tenant par ce lien :
Consultez également les périphériques déjà chargés dans votre Azure AD par ce lien :
Votre environnement IT est enfin prêt. Nous allons maintenant utiliser le portail Defender.
Afin de mettre en route Microsoft Defender for Business, il est nécessaire de commencer par une étape de configuration, côté Intune et côté Defender .
Etape III – Configuration de Microsoft 365 Defender for Business :
Pour cela cliquez-ici pour vous rendre sur le portail Defender, puis lancez le démarrage de la configuration :
Quelques minutes plus tard, cliquez-ici pour démarrer la configuration :
Assignez des utilisateurs de votre tenant aux deux rôles suivants :
Administrateur de sécurité : autorisés à gérer les fonctionnalités liées à la sécurité dans les portails Microsoft 365 Defender, Azure Active Directory Identity Protection, Azure Active Directory Authentication, Azure Information Protection et Microsoft Purview
Lecteur Sécurité : accès en lecture seule au niveau global à la fonctionnalité liée à la sécurité, notamment à toutes les informations dans le portail Microsoft 365 Defender, Azure Active Directory, Identity Protection, Privileged Identity Management, mais également les rapports sur les connexions Azure Active Directory et les journaux d’audit, ainsi que dans le portail de conformité Microsoft Purview.
Cliquez ensuite sur Continuer :
Définissez une ou plusieurs adresses emails afin de recevoir des notifications concernant les incidents et les vulnérabilités :
Choisissiez la méthode d’enrôlement des périphériques à Defender. Dans mon cas, je choisi l’intégration automatique via Intune :
Validez votre configuration si tout est OK pour vous :
Attendez environ 5 minutes pour que Microsoft finalise la configuration :
Le message suivant doit alors apparaître :
Le processus de mise en oeuvre est terminé ! Plutôt rapide non ?
Avant de voir les périphériques apparaitre, profitons-en pour faire le tour de certains paramétrages.
Etape IV – Paramétrages disponibles :
Cliquez-ici pour ouvrir activer la fonctionnalité de Live Response de Defender :
Activez si vous le souhaitez les fonctionnalités encore en préversion, puis cliquer sur Sauvegarder.
Profitez-en pour élargir le périmètre de Defender en permettant aux paramètres de sécurité d’Intune d’être appliqués par Microsoft Defender for Endpoint (MDE) aux appareils qui ne sont pas encore inscrits à Intune :
Configurez également et facilement un filtrage web grâce à un blocage de catégories :
Nommez votre police de filtrage web :
Ajoutez une ou plusieurs catégories à bloquer :
Validez la création en sauvegardant votre police :
Retournez sur le portail pour vérifier la bonne connection entre Intune et Microsoft Defender for Endpoint, validez l’option suivante, puis cliquer sur Sauvegarder :
Retournez sur votre portail Defender pour constater la présence de vos machines AVD.
Note : Il est possible que cela prenne environ 30 minutes pour voir les VMs AVD apparaître.
Comme la configuration de base est terminée et que les VMs sont remontées, nous allons pouvoir tester la bonne remontée des alertes et incidents dans Microsoft 365 Defender.
Etape V – Alerte / incident de test :
Récupérez le script PowerShell disponible sur le portail Defender :
Téléchargez le client Azure Virtual Desktop via cette page Microsoft, installez-le, lancez-le, puis cliquez-ici pour ajouter vos accès AVD de test :
Ajoutez vos 4 utilisateurs de test paramétré pour utiliser AVD :
Renseignez les mots de passe pour chacun d’eux :
Cliquez sur une session AVD et renseignez à nouveau le mot de passe utilisateur :
Acceptez la configuration SSO entre votre Azure AD et votre VM AVD :
Ouvrez le programme de ligne de commande Windows en mode Administrateur :
Renseignez le compte de l’administrateur local saisi dans Azure :
Collez le script récupéré précédemment, puis lancez-le :
Quelques minutes plus tard, toujours dans la page de configuration, constatez la validation du test de détection :
Vérifiez la boite de messagerie renseignée lors de la configuration de Microsoft 365 Defender for Business :
Dans la page d’incident, vous devriez voir votre premier cas, issu de votre script de test :
Cliquez dessus, parcourez les différents onglets, puis cliquez ici :
Une fois analysé, changez le statut de votre incident pour le clôturer :
Jusqu’à présent, nous n’avons pas modifié la politique de configuration concernant la sécurité des postes. Comme nos machines virtuelles AVD de test sont présentes dans Intune et dans Microsoft 365 Defender, nous devons choisir le lieu de configuration.
Etape VI – Configuration de polices de sécurité via Defender :
Rappelez-vous dans mon exemple que mon environnement ne contenait aucun poste dans ma console Intune. Je n’avais donc encore rien configuré. Cela ne sera pas forcément le cas dans un environnement déjà en place.
Microsoft recommande la mise en place de la gestion des polices de sécurité via Microsoft Defender 365. Cela rendra l’outil plus performant et facilitera la tâche des personnes spécifiquement dédiées à la sécurité des postes.
Dans le menu suivant, cliquez comme ceci :
Prenez le temps de bien lire l’avertissement de Microsoft :
Validez si vous êtes toujours d’accord avec cette gestion :
Environ une minute plus tard, la configuration des périphériques est disponible sur deux points :
Protection Next-Gen
Firewall
Celles-ci sont déjà sont déjà configurés et installés sur tous les périphériques. Cliquez sur l’une d’entre-elles pour comprendre sa configuration :
Faites-en de même avec la seconde :
Retournez sur le portail Intune pour constater d’éventuels changements.
Section Antivirus :
Section Firewall :
Section EDR :
Section des profils de configuration :
De retour sur le portail Defender, constatez la bonne application des 2 configurations à vos machines virtuelles Azure Virtual Desktop :
Etape VI – Tests de fonctionnalités de Defender :
Afin de voir comment se comporte Defender for business, je vous conseille d’attendre quelques heures, le temps que toutes les configurations soient bien appliquées aux VMs AVD.
Commencez par le filtrage web en recherchant un jeu sur votre moteur de recherche favori :
Cliquez sur un résultat de la liste :
Environ une seconde plus tard, constatez le blocage par la fenêtre suivante :
Il ne vous reste rien qu’à tester d’autres fonctionnalités depuis le portail Defender !
Etape VII – Quelques fonctions Defender
Comme les fonctionnalités sont nombreuses sur Defender, je trouve intéressant de vous en sélectionner quelques-unes liées aux périphériques et accompagnées de copies d’écran.
Incidents & Alertes
Tableaux de bord & Analyses
Actions sur le périphérique
Incidents & Alertes :
Tableaux de bord & Analyses :
Actions sur le périphérique :
Bloquer un processus considéré comme suspicieux :
Restreindre le lancement d’application non signée :
Lancer un scan antivirus sur le périphérique :
Démarrer une session de Live Response :
Isoler un périphérique du réseau :
Conclusion :
Après seulement quelques temps passé sur le portail de Microsoft 365 Defender, on ne peut que constater la facilité de mise en oeuvre de la solution sur des périphériques. L’intégration avec Intune, Azure AD et les autres mesures de sécurité créé un ensemble cohérent.
On comprend aisément le bénéfice à passer à Microsoft 365 Business Premium.
Cette imbrication permet sans aucun doute une prise en main facile et rapide au sein de nombreuses entreprises SMB.