Clonez votre Windows 365

Windows 365 est un service de Cloud PC créé par Microsoft et disponible via un système licence mensuelle fixe. Le service Windows 365 est en évolution constante depuis sa sortie en 2021. Très proche d’Azure Virtual Desktop, Windows 365 se distingue principalement par l’absence de connaissances nécessaires sur Azure. Mais que se passe-t-il quand un utilisateur rencontre des difficultés sur son poste Windows 365 ?

J’ai écrit cet article à la suite d’un souci technique sur un poste Windows 365. Pour des questions de commodités, nous avons pris la décision de cloner ce Cloud PC afin de l’analyser et de le redéployer par la suite.

Avant d’aller plus loin, et si Windows 365 nous vous semble pas familier, voici quelques articles très intéressants et disponibles sur ce blog :

Voici ce que Microsoft en dit en quelques mots :

Windows 365 est un service cloud qui crée automatiquement un nouveau type de machine virtuelle Windows (PC cloud) pour vos utilisateurs finaux. Chaque PC cloud est attribué à un utilisateur et devient ainsi son appareil Windows dédié. Windows 365 offre les avantages de productivité, de sécurité et de collaboration de Microsoft 365.

Microsoft Learn

Saviez-vous que votre Cloud PC est accessible avec un simple smartphone comme ressource local ?

Disons-le franchement, la documentation Microsoft ne m’a pas vraiment aidé 😥. Je vous propose donc ici de suivre un exercice étape par étape concernant le clonage du poste Windows 365 déjà en place, dans le but de l’analyser en dehors de l’environnement de production.

Pour des questions de confidentialité, l’environnement présent ci-dessous sera une copie approchante de l’environnement réel du client concerné.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Windows 365, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Windows 365

Commençons par recréer un environnement Windows 365 fonctionnel

Etape I – Environnement Windows 365 de départ :

Pour cela, commencez par créer un groupe Entra ID dans lequel votre utilisateur de test Windows 365 est présent :

Assignez à cet utilisateur une licence Windows 365 :

Depuis le portail Azure, recherchez le service des réseaux virtuels :

Créez un réseau virtuel Azure, ce dernier sera utilisé pour créer le poste Windows 365 :

Renseignez les champs de base de votre nouveau réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :

Environ 30 secondes plus tard, votre réseau virtuel Azure est créé :

Retournez sur la page dédiée à Windows 365 sur le portail Intune, puis lancez la création d’une connexion vers Azure :

Renseignez les champs relatifs au réseau virtuel Azure créé précédemment, puis cliquez sur Suivant :

Démarrez la validation Intune, puis lancez la création de la connexion Azure :

La création de la connexion vers Azure apparaît alors, et les premiers contrôles de conformité démarrent automatiquement :

Attendez environ 5 minutes que les contrôles sur la connexion Azure soit terminés :

Cliquez-ici pour définir les paramètres utilisateurs :

Choisissez parmi les options suivantes :

Assignez les paramétrages utilisateurs au groupe Entra ID, puis lancez la création :

Afin de créer le premier poste Windows 365, cliquez sur le menu suivant afin d’assigner une police de provisionnement à votre utilisateur de test :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez une image déjà présente dans la galerie Microsoft, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez la police de provisionnement à votre groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre Cloud PC assigné à votre utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du poste Windows 365 est terminé :

Sur votre poste local, téléchargez l’application Remote Desktop depuis la page officielle Microsoft, installez-là, puis ouvrez une session avec votre utilisateur de test :

Acceptez en cliquant sur Oui :

Ouvrez une session Windows 365 afin de constater le bon fonctionnement du Cloud PC :

Téléchargez le logiciel Google Chrome depuis la page officielle suivante :

Choisissez la version MSI, puis démarrez le téléchargement :

Une fois téléchargé, ouvrez l’exécutable :

Lancez l’installation de Google Chrome :

Notre environnement de départ est en place et fonctionne correctement. Nous allons maintenant nous intéresser au clonage du poste Windows 365.

Etape II – Sauvegarde du poste Windows 365 :

Afin de stocker l’image de notre Cloud PC Windows 365, commençons par rechercher le service de compte de stockage sur le portail Azure :

Cliquez-ici pour créer le compte de stockage :

Renseignez les informations de base dont le nom unique de votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre ressource Azure :

Environ 30 secondes plus tard, cliquez-ici pour ouvrir la page de votre compte de stockage :

Ajoutez un role RBAC sur votre compte stockage par le menu suivant :

Recherchez le rôle Azure RBAC ci-dessous, puis cliquez sur Suivant :

Ajoutez l’application Windows 365, puis lancez la validation :

Lancez l’assignation RBAC par le bouton suivant :

Depuis le portail Intune, retournez sur le Cloud PC afin de déclencher la création d’un point des restauration manuel par le menu suivant :

Confirmez votre choix en cliquant sur Oui :

Quelques minutes plus tard, votre point de restauration apparaît dans la liste ci-dessous. Cliquez-ici pour copier ce dernier sur votre compte de stockage :

Sélectionnez la souscription Azure et le compte de stockage correspondants, puis cliquez sur Partager :

L’ordre de copie est déclenché, attendez maintenant quelques minutes :

Depuis le portail Azure, retournez sur votre compte de stockage puis lancez plusieurs rafraichissements si besoin :

Constatez la création d’un nouveau conteneur blob, puis cliquez sur celui-ci :

Constatez la création d’un nouveau blob au format VHD :

Une image de notre poste Windows 365 est maintenant présente dans Azure. La prochaine étape sera de créer une machine virtuelle reprenant ce VHD.

Etape III – Création d’une machine virtuelle Azure :

Avant de créer directement la machine virtuelle, commencez par créer un disque OS via le service Azure suivant :

Cliquez-ici pour créer le disque OS :

Renseignez les informations de base pour votre disque OS, dont l’URL de votre blob VHD :

Vérifiez les champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre disque OS :

Environ 1 minute plus tard, cliquez-ici pour consulter la page de votre disque OS :

Cliquez-ici pour réutiliser votre disque OS dans la création d’une machine virtuelle Azure :

Renseignez les champs de base votre machine virtuelle, dont le disque OS :

Choisissez la taille de votre VM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez la case d’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre machine virtuelle :

Environ 2 minutes plus tard, votre VM est créée, cliquez-ici :

Vérifiez le bon démarrage de votre VM par le biais du menu suivant :

Déployez Azure Bastion de pouvoir vous y connecter en RDP de façon sécurisée :

Afin de vous connecter à votre VM en utilisant le compte Entra ID de votre utilisateur de test via Azure Bastion, passez la commande PowerShell suivante via le menu dédié :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1

Attendez la confirmation de la bonne exécution de votre script PowerShell :

Ouvrez une connexion RDP à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de l’icône Google Chrome sur le bureau de la VM :

Notre machine virtuelle Azure est maintenant en place. Nous pourrions alors effectuer tous les tests ou des modifications nécessaires sur celle-ci. Afin de donner un exemple banal, nous allons installer Mozilla sur notre VM.

Etape IV – Modification de la VM :

Rendez-vous sur la page officielle de Mozilla pour y télécharger et installer une version MSI du navigateur :

Constatez la présence de l’icône Firefox sur le bureau de la VM :

Profitez-en pour installer toutes les dernières mises à jour de Windows 11 :

Redémarrez la machine virtuelle Azure si nécessaire :

Vérifiez que Windows Update ne vous propose plus d’autres mises à jour Windows :

Depuis le portail Azure, relancez le script en sens inverse :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '2' # was before 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '1' # was before 0

Depuis la session RDP déjà ouverte via Azure Bastion, lancez la commande sysprep suivante en mode administrateur :

Sysprep /generalize /oobe /mode:vm /shutdown

Attendez qu’Azure Bastion vous indique une fermeture de session inattendue :

Une fois la machine virtuelle arrêtée au niveau OS, lancez un arrêt depuis le portail afin de désallouer les ressources Azure :

Une fois la machine virtuelle arrêtée et désallouée, lancez une capture de celle-ci :

Renseignez les champs de base de votre image, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre image :

Environ 3 minutes plus tard, constatez la bonne création de votre image :

Nous allons maintenant pouvoir recréer un second Cloud PC Windows 365 à partir de cette nouvelle image modifiée.

Etape V – Nouvel environnement Windows 365 :

Pour plus de facilité, j’ai recréé un second groupe Entra ID avec un second utilisateur de test que celui utilisé précédemment :

J’ai réassigné la licence Windows 365 précédemment assignée à mon nouvel utilisateur de test :

A partir du portail Intune, cliquez sur le menu suivant pour importer votre propre image Windows 365 :

Renseignez les informations de votre nouvelle image Windows 365, dont la source de votre image présente sur votre environnement Azure :

Le téléversement de votre image depuis Azure et vers Intune commence alors :

Environ 30 minutes plus tard, votre image personnalisée est bien chargée et reconnue par Intune :

Cliquez-ici pour créer une seconde police de provisionnement Windows 365 :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez votre image personnalisée, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez votre police de provisionnement à votre second groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre nouveau Cloud PC, assigné cette fois à votre second utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du nouveau poste Windows 365 est terminé :

Depuis l’application Remote Desktop, ouvrez une session avec votre second utilisateur de test :

Acceptez en cliquant sur Oui :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de deux icônes Chrome et Firefox sur le bureau Windows :

😎

Troubleshooting Quelques erreurs possibles :

Voici quelques erreurs que j’ai pu rencontrer lors de cet exercice :

  • Erreur rencontrée lors du lancement de la commande sysprep car des mises à jour Windows étaient encore en attente :
  • Erreur rencontrée lors du téléversement de mon image créée directement depuis mon blob VHD, sans avoir créé de machine virtuelle Azure entre temps :
  • Erreur rencontrée lors de la création d’une VM depuis une image sans avoir créé le disque OS entre temps :

Conclusion :

Cette opération nous montre encore une fois les synergies fortes entre tous les outils Cloud de Microsoft. J’espère que ce petit exercice pourra en aider quelques-uns sur les interventions IT sur des postes Windows 365 🤘🙏

FSLogix sont nos amis 🙏!

FSLogix est une excellente solution pour assurer la gestion des profils de vos utilisateurs. Très souvent utilisé dans différents types d’environnement VDI, FSLogix s’adapte très bien et très facilement à Azure Virtual Desktop. Mais la configuration de FSLogix a besoin d’être manipulée avec précaution pour ne pas devenir un cauchemar pour vos utilisateurs et par ricochet sur vous.

Un précédent article sur ce blog parle déjà de la mise en place de la solution FSLogix au sein d’un environnement Azure Virtual Desktop, dont voici le lien.

La solution FSLogix en quelques mots & vidéos :

Azure Virtual Desktop recommande les conteneurs de profil FSLogix. FSLogix est société acquise par Microsoft en novembre 2018. Elle propose une solution de conteneurisation des profils utilisateurs en itinérance, utilisable dans une large gamme de scénarios sous format VHD ou VHDX. Avec FSLogix, vous allez pouvoir réaliser les actions suivantes pour vos utilisateurs :

  • Centralisation des profils utilisateurs Azure Virtual Desktop
  • Dissociation possible entre les conteneurs Office365 avec les conteneurs profils utilisateurs
  • Gestion des applications visibles ou non via la fonction AppMasking
  • Contrôle des versions JAVA
  • Customisation de l’installation via de nombreuses règles ou via GPO
  • Sans les conteneurs de profil FSLogix, OneDrive Entreprise n’est pas pris en charge dans les environnements RDSH ou VDI non persistants

Un grand merci à Dean Cefola de l’Azure Academy pour cette playlist YouTube très complète autour de FSLogix :

Il est important de comprendre que la configuration FSLogix dépendra de beaucoup de paramètres, et qu’il est difficile d’en établir une adaptée à tous les cas d’usages.

Durant l’écriture de cet article, j’ai retrouvé un grand nombre de documentations utiles à une meilleure compréhension de FSLogix, dont certaines proviennent Microsoft Learn :

Mais aussi d’autres sources non-Microsoft :

Ce nouvel article a donc pour but de partager avec vous une problématique FSLogix possible ainsi qu’une méthode de résolution :

Pour des questions de confidentialité, l’environnement présent ci-dessous est une copie approchante de l’environnement réel du client concerné.

Etape 0 – Contexte :

Je suis intervenu sur un environnement Azure Virtual Desktop sur lequel les utilisateurs se plaignaient d’être constamment obligés de se réauthentifier à leurs outils Microsoft 365 à chaque ouverture :

Cela concernait les outils de productivités (Word, Excel, PowerPoint), mais également les outils de collaborations (Outlook, OneDrive, Teams). La gêne pour les utilisateurs était donc évidente.

Voici une description des ressources Azure déjà en place :

  • Domain managé Entra Domain Services
  • Environnement AVD avec 2 hôtes
  • Stockage des profiles FSLogix sur un Azure File Share + sauvegarde
  • Gestion des images via une Azure compute gallery
  • Accès RDP via Azure Bastion

Voici le groupe de ressources Azure contenant le domaine managé Microsoft :

Voici le groupe de ressources Azure contenant l’environnement AVD et le compte de stockage utilisé pour les profils FSLogix :

Voici le groupe de ressources Azure contenant l’image Windows 11 stockée dans une Azure compute gallery :

Voici une vue de l’environnement Azure Virtual Desktop :

Voici une vue des groupes Entra ID en relation avec Azure Virtual Desktop :

Voici une vue du compte stockage contenant le partage de fichiers dédié aux profils FSLogix :

Voici le paramétrage indiquant que le compte de stockage est joint au domaine managé Microsoft et les droits RBAC de base pour le partage :

Concernant la partie administration d’AVD, je retrouve bien des droits d’administration RBAC plus élevés et dédiés à la configuration des droits NTFS :

La sauvegarde concernant la partie FSLogix est également bien en place :

Sur ce même compte de stockage dédié à FSLogix, l’accès réseau Internet est bien coupé :

En lieu et place, un point d’accès privé pour connecter le compte de stockage au réseau virtuel AVD :

En me connectant avec un compte administrateur sur l’environnement AVD, j’ai pu vérifier que les droits NTFS appliqués au partage de fichiers FSLogix étaient bien cohérent :

Enfin les règles de registres implémentés directement sur la VM AVD et donc sur l’image reprennent les recommandations de base de Microsoft, disponible juste ici :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

L’environnement semble bon, et le problème semble à priori en relation avec les tokens.

L’étape suivante est alors la reproduction sur problème rencontré par les utilisateurs d’Azure Virtual Desktop.

Etape I – Premier test d’un l’utilisateur impacté :

Pour cela, j’utilise le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur impacté :

Je renseigne les identifiants :

La session Windows 11 s’ouvre bien et indique un chargement du profil via la solution FSLogix :

Le dossier du profil est bien présent sur le partage de fichier Azure comme indiqué dans la configuration registre Windows :

J’ouvre une première fois l’outil Power Point :

Je m’identifie dans l’application avec un compte Microsoft 365 correctement licencié :

L’authentification d’Office 365 fonctionne bien et sans erreur :

Je ferme et réouvre la session Azure Virtual Desktop avec ce même utilisateur :

Je réouvre PowerPoint et je constate le besoin de réauthentification systématique, comme dans toutes les autres applications Microsoft 365 :

Par le bais de l’explorateur Windows, je me rends dans le dossier suivant pour ouvrir l’application frxtray :

  • C:\Program Files\FSLogix\Apps\
    • frxtray.exe

J’affiche les différents journaux d’évènements à la recherche d’erreurs potentielles, sans succès :

Afin de poursuivre mon investigation, je décide d’appliquer la stratégie suivante :

  • Création d’une nouvelle machine virtuelle AVD depuis la dernière image
  • Mise à jour de l’OS Windows 11
  • Mise à jour des applications Office 365
  • Mise à jour de FSLogix

Pour cela, je commence par créer cette nouvelle machine virtuelle Azure.

Etape II – Création d’une première VM image AVD :

Je créé une nouvelle machine virtuelle en prenant soin de sélectionner la dernière image AVD en Windows 11 personnalisée et stockée dans la galerie :

Une fois créée, je m’y connecte en utilisant le service Azure Bastion :

Je lance toutes les mises à jour Windows 11 disponibles :

Pour effectuer les mises à jour d’Office365, je réactive la règle de registre suivante :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
    • UpdatesEnabled
      • True

J’ouvre un programme Office 365 et lance la recherche des mises à jour :

J’attends le message suivant signifiant la bonne installation des mises à jour Office 365 :

Je retourne dans le registre Windows pour remettre la valeur suivante :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
    • UpdatesEnabled
      • False

Dans la liste des applications installées, je vérifie et désinstalle si besoin l’ancienne version de FSLogix :

Je redémarre la machine et retourne sur le site officiel de Microsoft pour y télécharger la dernière version de FSLogix :

J’en profite pour parcourir les notes des dernières versions de FSLogix :

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

J’en profite pour parcourir les bogues connus de FSLogix :

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

Je décide donc de rajouter cette clef de registre sur mon image AVD à jour :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles
    • RoamIdentity
      • 1

La correction est maintenant appliquée sur ma machine virtuelle image. Je décide donc de créer une nouvelle image contenant les mises à jour Windows 11, Office 365 et FSLogix, mais également la correction apportée par la clef de registre.

Etape IV – Création d’une seconde VM image AVD :

Sur la machine virtuelle image, je lance la commande Sysprep suivante selon la documentation Microsoft :

Sysprep /generalize /oobe /mode:vm /shutdown

Sysprep s’exécute et m’invite à patienter quelques minutes :

La session de bureau à distance ouverte via Azure Bastion se ferme quand la machine virtuelle commence sa phase d’extinction :

Quelques secondes plus tard, le portail Azure affiche bien la machine virtuelle image comme étant arrêtée, je décide donc de l’arrêter complètement :

Une fois entièrement désallouée, je lance la capture :

Je créé une nouvelle version dans la galerie utilisée précédemment, et attends environ 20 minutes que le traitement se termine :

L’environnement Azure Virtual Desktop est maintenant prêt pour recevoir une nouvelle machine virtuelle à partir de cette image.

Etape V – Création d’une nouvelle hôte AVD :

Je retourne sur la page de mon pool d’hôte AVD afin d’y ajouter une nouvelle VM comme ceci :

Je reprends la même taille de VM qu’utilisée précédemment tout en choisissant la dernière version de mon image, puis lance la création des ressources Azure :

Environ 10 minutes plus tard, une nouvelle hôte apparaît dans mon environnement Azure Virtual Desktop. Enfin j’active le mode Drain sur les autres machines virtuelles encore sous ancienne version d’image AVD :

Il ne me reste plus maintenant qu’à retester avec le compte d’un utilisateur impacté pour constater un changement après plusieurs réouvertures d’une session AVD.

Etape VI – Second test d’un l’utilisateur impacté :

J’utilise à nouveau le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur de test :

Après plusieurs connexions / déconnexions, l’authentification 365 persiste bien dans les différentes applications 365. Pour en être sûr, plusieurs tests sont effectués dans les applications Word, Excel, PowerPoint, Outlook, OneDrive, Teams. 😎💪

Conclusion

Dans mon cas le problème a été résolu car plusieurs informations ont été partagées sur des forums IT et sur la documentation Microsoft. Cela n’est pas toujours le cas et peut engendrer une certaine frustration quand aucune solution n’est trouvée.

Néanmoins, je souhaitais partager avec vous au travers de cet article une approche assez classique dans la résolution de souci liée à des produits IT en général (chose que l’on ne fait pas toujours, moi le premier)

  • Lire les documentations officielles 😎
  • Ne pas touchez aux environnements de productions
  • Mettez à jour les OS (Windows 11)
  • Mettez à jour les applications (Office 365)
  • Mettez à jour les intermédiaires (FSLogix)
  • Appliquez les méthodes correctives préconisées par les éditeurs

Créez votre premier tenant Microsoft Entra

Je suis sûr que certains d’entre vous ont déjà créé plusieurs dizaines de tenants Microsoft Entra, possiblement plus 💪. Mais certains d’autres n’ont peut-être jamais osé franchir le pas ! Rassurez-vous, rien de bien compliqué. En cette année 2024, je vous propose de repartir sur les basiques et de créer ensemble un nouveau tenant afin de comprendre les premiers paramètres appliqués par Microsoft.

Avant de commencer le petit exercice, reparcourons ensemble quelques notions essentielles.

Qu’est-ce qu’un tenant Microsoft Entra ?

C’est probablement une des premières questions à laquelle on tente de répondre quand on commence à s’intéresser au cloud de Microsoft. Inutile d’aller bien loin, Microsoft explique assez bien le concept :

Le locataire (tenant) Microsoft Entra est une limite de sécurité d’identité qui est sous le contrôle du service informatique de votre organization. Dans cette limite de sécurité, l’administration des objets (tels que les objets utilisateur) et la configuration des paramètres à l’échelle du locataire sont contrôlées par vos administrateurs informatiques.

Microsoft Learn

A l’intérieur d’un tenant Microsoft Entra, on y retrouvera donc principalement :

  • un annuaire ou répertoire (= directory) contenant des identités humaines, machines ou applicatives
  • Des applications Microsoft comme la suite office 365
  • Des ressources comme des machines virtuelles sur Azure
  • Des applications tierces
  • Des configurations comme des droits, des polices ou mesures de sécurité

Cette vidéo est assez ancienne, mais elle explique assez bien le concept d’Azure Active Directory (Entra ID) et de ses différences avec Windows Server Active Directory :

Combien coûte un tenant Microsoft ?

Un tenant Microsoft en lui-même ne coûte rien, mais les services comme Office 365, les licences pour renforcer la sécurité de votre tenant, ou encore les ressource Azure déployées vont pour la plupart être payantes.

Quelle est la différence entre Microsoft Entra et Microsoft Entra ID ?

Microsoft Entra est une famille de plusieurs produits comprenant également Microsoft Entra ID. Le tableau suivant et disponible sur cette page montre certaines fonctionnalités disponible sur Microsoft Entra :

Ce portail complet est disponible à cette adresse :

Combien coûte Microsoft Entra ID ?

Le tableau ci-dessous et également disponible sur cette page Microsoft nous explique bien les différentes versions de Microsoft Entra ID :

  • La première colonne de gauche nous montre qu’il existe une version gratuite de Microsoft Entra ID comprenant des bases de sécurité suffisantes.
  • D’autres versions avec plus de fonctionnalités et des mesures de sécurité personnalisées sont disponibles sous forme de licences par utilisateur.

Afin de rentrer plus en détail dans le fonctionnement de Microsoft Entra, je vous propose de regarder l’excellente vidéo de Seyfallah Tagrerout :

Plusieurs méthodes de création d’un tenant Microsoft existent. Il est généralement possible de créer son propre nouveau tenant en partant d’une identité Cloud existante sans en perturber le fonctionnement.

Afin de vous faire une meilleure idée, je vous propose un petit exercice à ce sujet, et de voir certains éléments liés à votre création :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

Pour réaliser mon exercice sur la création d’un nouveau tenant Microsoft, il vous faudra disposer de :

  • Un tenant Microsoft 🤣

La suite se passera directement par la création du nouveau tenant.

Etape I – Création du nouveau tenant :

Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, puis cliquez-ici pour lister les tenants vous étant accessibles :

Cliquez sur Créer pour démarrer la procédure :

Deux types de tenants sont possibles : B2C ou B2B (plus d’informations ici)

Choisissez le tenant B2B, puis cliquez sur Continuer :

Renseignez les 3 champs suivants puis cliquez sur Créer :

Réussissez le CAPTCHA, puis cliquez sur Soumettre :

La création de votre nouveau tenant Microsoft a commencé, attendez environ 5 minutes :

Environ 5 minutes plus tard, votre nouveau tenant Microsoft est maintenant prêt, cliquez-ici pour basculer sur celui-ci :

La bascule vers le nouveau tenant est également possible depuis le bouton de paramètre suivant :

Le nouveau tenant s’ouvre directement sur le portail Azure. Constatez la présence de ces 2 valeurs uniques qui définissent votre nouveau tenant :

Consultez les utilisateurs présents sur votre nouveau tenant par cette page.

A ce stade, le compte utilisateur du tenant initial devrait être le seul présent, cliquez sur son nom :

Prenez soin de vérifier l’origine de cette identité externe à votre nouveau tenant, puis cliquez-ici pour consulter ses rôles Entra ID :

Constatez la présence logique du rôle d’Administrateur Général, naturellement attribué au créateur du tenant :

Votre tenant fonctionne bien, mais est pour l’instant assez vide. Je vous propose donc de continuer en créant un premier utilisateur dans Entra ID.

Etape II – Création d’un nouvel utilisateur :

Créez votre premier utilisateur rattaché à votre nouveau tenant par le menu suivant :

Remplissez les champs obligatoires, puis cliquez sur Suivant :

Remplissez les champs que vous souhaitez, puis cliquez sur Suivant :

Cliquez ici pour lui un ajouter un rôle Entra ID :

Recherchez le rôle d’Administrateur général, puis cliquez sur Sélectionnez :

Lancez la validation de votre création :

Une fois la validation terminée, sauvegardez le mot de passe provisoire, puis lancez la création :

La notification suivante devrait apparaître :

Rafraichissez la page des utilisateurs Entra ID afin de voir votre création :

Ouvrez un navigateur privé, lancez la page web d’Entra ID, puis renseignez les identifiants de votre nouvel utilisateur :

A l’issue de cette première connexion, définissez un nouveau mot de passe à cet utilisateur :

Dans le but de supprimer l’utilisateur créateur du nouveau tenant dans ce dernier, retournez sur la page des utilisateurs, puis cliquez-ici :

Confirmez votre choix en cliquant sur OK :

Rafraichissez la page des utilisateurs Entra ID afin de voir uniquement votre nouveau compte :

Etape III – Création d’autres utilisateurs :

Vous pourriez créer ou inviter d’autres utilisateurs comme le montre les exemples d’identités visibles sur l’image ci-dessous :

Microsoft nous liste certaines identités sur cette page :

Voici un exemple de connexion d’un compte invité de type mail essayant de se connecter à un site SharePoint dont l’accès se fera via un code envoyé par email :

Intéressons-nous enfin à la sécurité de base d’un tenant Microsoft.

Etape IV – Paramètres de sécurité par défaut :

Depuis octobre 2019, les nouveaux tenants ont la sécurité par défaut d’activé. Microsoft le justifie par l’argument suivant :

Selon nos connaissances, plus de 99,9% de ces attaques liées à l’identité sont stoppées en utilisant l’authentification multifacteur et en bloquant l’authentification héritée. Notre but est de nous assurer que toutes les organisations ont activé au moins un niveau de sécurité de base, sans coût supplémentaire.

Microsoft Learn

La sécurité par défaut est entièrement gérée par Microsoft. Elle fait sens dans le cadre de tenants dépourvus de licences Microsoft Entra ID payantes et agira sur les points suivants :

L’activation ou la désactivation de la sécurité par défaut est possible depuis l’écran suivant d’Entra ID :

Terminons cet exercice par un test de la sécurité par défaut d’activé d’Entra ID.

Etape V – Test des paramètres de sécurité par défaut :

Pour cela, connectez-vous avec un compte administrateur sur le portail Microsoft Entra ID depuis un navigateur privé :

Dans cet exemple, notre compte utilisateur est un administrateur et essaye d’accès à un ressource sensible.

Comme la MFA n’est pas encore configuré sur ce compte, nous sommes invités à y remédier en cliquant sur Suivant :

Afin de configurer Microsoft Authenticator, téléchargez l’application sur votre Smartphone, puis cliquez sur Suivant :

Cliquez sur Suivant :

Scannez le QR code depuis l’application installé sur votre Smartphone, puis cliquez sur suivant :

Saisissez sur votre Smartphone le nombre affiché à l’écran :

Une fois le nombre correctement saisi, cliquez sur Suivant :

Cliquez sur Terminer :

Cliquez sur Non :

Le portail de Microsoft Entra ID s’ouvre bien :

Refermer votre navigateur privé, puis réouvrez-le à nouveau.

Connectez-vous à nouveau avec le même compte administrateur sur le portail Microsoft Entra ID :

La MFA étant déjà configuré sur ce compte, saisissez à nouveau sur votre Smartphone le nombre affiché à l’écran :

Cliquez sur Non :

Le portail de Microsoft Entra ID s’ouvre bien une nouvelle fois :

Conclusion

Cet exercice nous montre qu’il n’y a vraiment rien de sorcier dans la création d’un nouveau tenant Microsoft Entra dans sa configuration de base, même si beaucoup d’autres paramétrages non montrés ici seront à configurer selon les cas. Enfin, d’autres mesures de sécurité très intéressantes à mettre en place devraient bientôt suivre dans de prochains articles 😎.

Trustez votre Entra Domain Services

Anciennement appelé AADDS pour Azure Active Directory Domain Services, ce service a lui aussi subi le renommage d’Entra ID de 2023. Très facile à déployer et à maintenir, le domaine managé de Microsoft a tout pour plaire. Mais depuis quelques temps, peu d’évolutions lui ont été apportées. Dean Cefola de la Cloud Academy refait parler de lui et des possibles trusts pour notre plus grand plaisir.

Pour commencer, quelques notions intéressantes sur ce service managé par Microsoft :

Qu’est-ce que Microsoft Entra Domain Services ?

Grâce à Entra Domain Services, il va vous être possible de générer rapidement et facilement un domaine AD, au sens classique du terme, managé par Microsoft et à partir de votre Entra ID :

Microsoft Entra Domain Services offres des services de domaine managé, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos et NTLM. Vous utilisez ces services de domaine sans avoir à déployer, gérer et apporter des correctifs aux contrôleurs de domaine dans le cloud.

Microsoft Learn

La partie de gauche de ce schéma nous montre le potentiel de synchronisation d’Entra Domain Services depuis des données stockées dans Entra ID :

Mais alors quelles sont les différences entre un AD DS classique, Entra ID et Entra Domain Services ?

Cet article ne date pas d’hier mais répond très bien à la question !

Afin de rentrer directement dans le vif du sujet, voici donc la vidéo de Dean ayant servi de base à cet article ainsi que le tutoriel officiel de Microsoft :

Vous l’aurez compris, le but est donc tester le trust entre un environnement on-premise et un domaine managé par Microsoft hébergé sous Azure. Grâce à cette approche séparée, chaque domaine impactera en premier lieu sa localité, tout en ayant des adhérences avec les annexes.

Afin de bien comprendre la mise en place du trust entre le domain Active Directory on-premise et le service managé Entra Domain Services, je vous propose de réaliser ce petit exercice :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de Trust, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer plusieurs ressources détaillées par la suite.

Etape I – Création du domaine managé Entra Domain Services :

Commençons par créer notre service de domaine active Directory managé. Pour cela, rechercher le service Microsoft Entra Domain Services sur votre portail Azure :

Cliquez-ici pour créer le service managé sur votre tenant :

Renseignez ses informations de base dont son nom et le SKU Enterprise, puis cliquez sur Suivant :

Validez ses propriétés réseaux, puis cliquez sur Suivant :

Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :

Définissez le périmètre de synchronisation, puis cliquez sur Suivant :

Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :

Cliquez sur Créer pour lancez la création de toutes les ressources Azure :

Lisez bien l’avertissement sur le blocage de modification après création, puis cliquez sur OK :

La notification Azure suivante apparaît en haut à droite de votre portail :

Attendez environ 30 minutes la première phase de déploiement des ressources Azure :

Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :

Comme vous le constatez ici, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :

Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée.

Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :

Lancez-le diagnostique en cliquant sur Lancer :

Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :

Confirmez votre choix en cliquant à nouveau sur Réparer :

Constatez la présence d’une notification Azure impactant votre réseau virtuel :

Vérifiez la disparition de la notification d’alerte sur votre domaine managé :

Afin de gérer plus facilement le partage côté domaine managé, vous pouvez créer une machine virtuelle Azure sur le même réseau que votre domaine managé avec la fonctionnalité suivante :

Enfin, rendez-vous sur la console d’administration de Microsoft 365 afin de créer un utilisateur de test Cloud :

Notre domaine managé par Microsoft est configuré dans sa partie initiale.

Nous allons reproduire maintenant une seconde configuration pour notre domaine AD non managé et représentant un environnement on-premise.

Etape II – Création du domaine non managé Active Directory :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Ajoutez un disque secondaire pour les dossiers systèmes AD, puis cliquez sur Suivant :

Prenez soin de définir un réseau virtuel différent du domaine managé, retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Retournez sur le réseau virtuel nouvellement créé par la machine virtuelle afin de renseigner l’adresse IP locale de votre VM en tant que serveur DNS, puis Sauvegardez :

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Une fois connecté, rendez-vous dans le Gestionnaire des disques :

A l’ouverture du gestionnaire des disques, il vous est proposé d’initialiser le disque de données :

Par la suite créez un nouveau volume simple :

Puis formatez ce dernier en NTFS :

Continuez en ajoutant un nouveau rôle à votre Windows via Server Manager :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les 2 rôles ci-dessous, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 5 minutes que l’installation des 2 rôles se termine :

Démarrez la promotion de ce serveur en tant que contrôleur de domaine AD :

Créez une nouvelle forêt locale :

Définissez un mot de passe DSRM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Renseignez la lettre de votre disque de données, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Quelques minutes plus tard, Windows vous avertit d’une déconnexion imminente :

Attendez quelques minutes qu’Azure Bastion vous reconnecte une fois la machine virtuelle redémarrée avec le compte administrateur de domaine :

Attendez la fin de l’initialisation pendant environ 5 minutes :

Vérifiez la présence de votre domaine AD dans la console Server Manager :

Enfin, créez une nouvelle OU ainsi qu’un nouvel utilisateur local à votre domaine AD :

Continuons la suite de l’exercice en reliant les deux réseaux virtuels Azure entre eux.

Etape III – Appairage des réseaux virtuels :

Sélectionnez le réseau virtuel contenant votre domaine managé par Microsoft :

Ajoutez un appairage de réseau virtuel comme ceci :

Configurez votre appairage comme-ci, puis cliquez sur Ajouter :

Les deux notifications Azure suivantes devraient apparaître :

Vérifiez le changement de statut de votre appairage :

Le lien réseau est maintenant opérationnel. La suite consiste à élaborer la relation de confiance entre les deux domaines Active Directory.

Etape IV – Mise en place du Trust Active Directory :

Copiez les 2 adresses IPs présentes sur votre domaine managé par Microsoft :

Sur votre contrôleur de domaine local, ouvrez l’outil DNS :

Ajoutez un nouveau transit conditionnel via un clic droit :

Reprenez le nom de votre domaine managé, ajoutez-y ses deux adresses IPs, cochez la case suivante, puis cliquez sur OK :

Testez le bon transfert des requêtes du domaine managé via la commande suivante :

nslookup jloudev.cloud

Toujours sur votre contrôleur de domaine, ouvrez le menu suivant :

Rendez-vous dans les propriétés de votre domaine :

Dans l’onglet suivant, cliquez sur Nouveau Trust :

Cliquez sur Suivant :

Reprenez le nom de votre domaine managé, puis cliquez sur Suivant :

Définissez le trust au niveau de la forêt, puis cliquez sur Suivant :

Activez le trust bidirectionnel, puis cliquez sur Suivant :

Configurez le trust simplement pour ce domaine, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez un mot de passe trust, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

N’activez pas le trust sortant, puis cliquez sur Suivant :

Cliquez enfin sur Terminer :

Vérifiez la présence du lien dans le tableau des trusts :

Continuons avec la configuration de trust sur le domaine managé par Microsoft.

Etape V – Mise en place du Trust Entra Domain Services :

Pour cela, retournez sur la page Azure de votre domaine managé par Microsoft, puis ajoutez le trust par le menu suivant :

Renseignez les informations dont les adresses IP de vos serveurs DNS / AD, puis cliquez sur Sauvegarder :

Confirmez votre choix en cliquant sur OK :

Quelques minutes plus tard, le trust apparait bien comme côté Entra Domain Services :

La liaison Trust est maintenant opérationnelle des 2 côtés. Avant de tester les accès, il est nécessaire d’inscrire les droits sur les 2 partages de fichiers.

Etape VI – Configuration du partage Active Directory :

Retournez dans la gestion de l’Active Directory afin d’y créer un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :

Créez un nouveau dossier sur votre serveur local, puis ajoutez ce nouveau groupe AD avec des droits en modification :

Sur l’onglet de Partage cliquez sur le Partage avancé :

Activez le partage, puis définissez les permissions :

Ajoutez le même groupe AD avec les droits suivants :

Il ne nous reste qu’à répéter cette opération sur le second partage Cloud.

Etape VII – Configuration du partage Entra Domain Services :

Retournez dans la gestion AD d’Entra Domain Services afin d’y créer là aussi un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :

Créez un nouveau dossier sur votre serveur Cloud, puis ajoutez ce même groupe Cloud avec des droits en modification :

Sur l’onglet de Partage, cliquez sur le Partage avancé :

Activez le partage, puis définissez les permissions :

Ajoutez le même groupe Cloud avec les droits suivants :

Tout est enfin prêt pour passer aux tests utilisateurs. Croisons les doigts ! 🤞

Etape VIII – Test d’accès Active Directory :

Créez une nouvelle machine virtuelle sous Windows 11 et jointe au domaine Active Directory, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :

Renseignez le chemin d’accès du partage réseau Cloud dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :

Effectuons maintenant un second test côté Entra Domain Services.

Etape IX – Test d’accès Entra Domain Services :

Créez une seconde machine virtuelle sous Windows 11 et jointe cette fois au domaine managé par Microsoft, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :

Renseignez le chemin d’accès du partage réseau local dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :

Conclusion :

L’accès aux 2 partages de fichiers fonctionnent sans souci 😎 ! La mise en place de trust est grandement facilité depuis le service Entra Domain Services. Il s’agit d’une raison supplémentaire d’utiliser ce service, tout en prenant soin de mesurer ces différences juste ici.

VM – Traquez les changements

Azure est une excellente plateforme pour déployer rapidement et facilement des ressources IT. Seulement, la phase de déploiement de ressources ne représente que la première partie du travail d’une infrastructure. Bien souvent, plusieurs agents ou équipes interviendront sur ces mêmes ressources Azure. Un système de suivi des changements apparait alors comme très utile pour traquer efficacement les modifications faites par les uns et par les autres.

Qu’est-ce que le Suivi des modifications et inventaire (Change Tracking et Inventory) ?

En quelques mots, le Suivi des modifications et inventaire va vous permettre de comprendre les modifications faites sur vos ressources Azure, mais aussi à l’intérieur de celles-ci.

Voici un exemple de 2 vues disponibles retraçant différents types de modifications :

Le Suivi des modifications et inventaire effectue le suivi des modifications apportées aux machines virtuelles hébergées sur Azure, locales et d’autres environnements cloud pour vous aider à identifier les problèmes opérationnels et environnementaux liés aux logiciels gérés par le gestionnaire de package de distribution. 

Microsoft Learn

On y retrouve donc des modifications de registres, de fichiers, de programmes et bien d’autres encore.

Que pouvons-nous traquer dans le Suivi des modifications et inventaire ?

A ce jour, plusieurs éléments sont traçables au travers du Suivi des modifications et inventaire. Voici la liste des modifications traçables :

  • Logiciels Windows
  • Logiciel Linux (packages)
  • Fichiers Windows et Linux
  • Clés de Registre Windows
  • Services Windows
  • Démons Linux

Doit-on payer pour utiliser Suivi des modifications et inventaire ?

Oui. En effet, le Suivi des modifications et inventaire est un service payant. Il repose sur stockage appelé Log Analytics Workspace pour stocker les données liées aux modifications. Comme à chaque fois, le Log Analytics Workspace est facturé au Go de données écrites.

Niveau agent : AMA ou MMA, lequel choisir ?

Microsoft avait annoncé la préversion de Suivi des modifications et inventaire via l’agent AMA en janvier 2023. L’agent AMA prend le pas sur l’agent LOA pour des raisons de sécurité, de fiabilité, et facilite également les multi-environnements. De plus, il n’est plus nécessaire d’intégrer un compte Azure Automation.

D’ailleurs Microsoft a également annoncé une date de retrait pour MMA/LOA :

Actuellement, le suivi des modifications et l’inventaire utilisent Log Analytics Agent et son retrait est prévu d’ici le 31 août 2024. Nous vous recommandons d’utiliser Azure Monitoring Agent comme nouvel agent de prise en charge.

Microsoft Learn

Agent, Extension, Kesako ?

Il existe des différences entre un agent et une extension. Microsoft apporte sur cette page quelques infos bien utiles :

  • Agent : Il s’agit d’une application légère, toujours en cours d’exécution (le plus souvent exécutée en tant que service/daemon), qui collecte des informations auprès de la machine et les transmet quelque part ou maintient l’état de la machine elle-même en fonction d’une certaine configuration.
  • Extension : Dans Azure, les extensions fournissent des tâches de configuration et d’automatisation post-déploiement sur les VM Azure. Les extensions peuvent faire partie de la définition de la VM elle-même, et donc être utilisées pour déployer quelque chose dans le cadre du déploiement de la ressource hôte elle-même. Dans le cas d’Azure Monitor, il existe des extensions qui déploient l’agent de surveillance dans le cadre du déploiement de la VM/VMSS.
  • AzureMonitoringWindowsAgent : Il s’agit de l’extension la plus récente et la plus recommandée d’Azure Monitor Agent (AMA) pour une VM. Elle est disponible pour les VM Windows avec le nom AzureMonitoringWindowsAgent. De même, AzureMonitorLinuxAgent est le nom de l’extension pour l’AMA sur la VM Linux.
  • MMAExtension : C’est le nom de l’extension qui installe l’ancien agent sur la VM Windows. L’agent lui-même est appelé Log Analytics Agent ou LA Agent, également appelé « Microsoft Monitoring Agent » ou MMA. Pour les machines virtuelles Linux, cette extension installe un paquetage d’agent appelé OMSAgentforLinux.

Enfin, cette page détaille les différences techniques des agents en relation avec Azure Monitor.

Afin de bien comprendre ce que le Suivi des modifications et inventaire d’Azure est capable de faire avec un agent AMA, je vous propose de suivre ce petit exercice :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur le Suivi des modifications et inventaire d’Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer une machine virtuelle.

Etape I – Préparation de l’environnement :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Les notifications suivantes devraient apparaitre :

Sans attendre la fin du déploiement d’Azure Bastion, recherchez le service Log Analytics Workspace :

Cliquez-ici pour déployer votre Log Analytics Workspace :

Renseignez tous les champs dont son nom devant être unique sur Azure :

Attendez maintenant que le Log Analytics Workspace et Azure Bastion soient entièrement déployés pour continuer cet exercice.

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Notre environnement de base est maintenant en place. Nous allons pouvoir continuer en activant le service Suivi des modifications et inventaire.

Etape II – Activation du Suivi des modifications et inventaire :

Pour cela, retournez sur votre machine virtuelle afin d’activer le Suivi des modifications et inventaire en utilisant un agent AMA :

La mise en place de ce service déploie 2 extensions sur votre machine virtuelle et vous invite à patienter :

Quelques minutes plus tard, consultez les extensions installées sur votre machine virtuelle :

Afin que toutes les modifications soient bien prises en compte dans le Suivi des modifications et inventaire, je vous conseille d’attendre 30 minutes avant de continuer la suite de cet exercice.

Etape III – Sauvegarde des évènements Azure :

La sauvegarde d’évènements Azure est utile afin de bien comprendre par exemple les modifications faites directement sur les ressources Azure.

Pour cela, cliquez sur le menu suivant dans votre machine virtuelle :

Puis cliquez-ici :

Enfin cliquez-ici pour connecter votre journal d’activité Azure :

Quelques secondes plus tard, constatez le bon changement du statut de la connexion :

Effectuez ensuite un changement de taille de votre machine virtuelle :

Attendez que le redimensionnement soit terminé :

Quelques minutes plus tard, constatez l’apparition d’une ligne d’évènement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi des fichiers Windows.

Etape IV – Sauvegarde du suivi de fichiers Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de fichiers Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez le fichier correspondant à votre règle de suivi :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi du registre Windows.

Etape V – Sauvegarde du suivi du registre Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de registre Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez la clef de registre correspondante à votre règle :

Quelques minutes plus tard, constatez l’apparition d’une ligne de changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en ajoutant le suivi des services Windows.

Etape VI – Sauvegarde du suivi de services Windows :

Modifiez si besoin la fréquence des remontées d’informations sur les services Windows :

Sur votre machine virtuelle de test, lancez le script PowerShell d’installation suivant :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Attendez la fin de l’installation du rôle IIS :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en modifiant la sauvegarde du suivi des modifications du contenu de fichiers.

Etape VII – Sauvegarde du suivi des modifications du contenu de fichiers :

Avant d’activer la fonction du suivi des modifications de fichiers, recherchez le service des comptes de stockage Azure :

Créez un compte de stockage dédié à la fonction du suivi de modification des fichiers :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du compte de stockage, puis attendez environ 1 minute :

Une fois le compte de stockage créé, retournez dans la configuration du Suivi des modifications et inventaire afin d’y ajouter ce dernier :

Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :

Retournez sur votre compte de stockage, puis ouvrez le conteneur suivant créé automatiquement par le Suivi des modifications et inventaire :

Cliquez-ici pour ajouter des droits RBAC sur ce conteneur blob :

Choisissez le rôle ci-dessous, puis cliquez sur Suivant :

Ajoutez l’identité managée de votre machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de l’assignation RBAC :

Modifiez le contenu d’un fichier de texte présent sur votre machine virtuelle de test, puis retournez sur votre compte de stockage afin de constater le téléversement du fichier modifié quelques minutes plus tard :

Terminons les tests du Suivi des modifications et inventaire en installant un logiciel sur la machine virtuelle.

Etape VIII – Inventaire des logiciels :

Téléchargez par exemple Google Chrome depuis une source officielle :

Lancez son installation :

Quelques minutes plus tard, Google Chrome apparait bien dans le Suivi des modifications et inventaire en tant qu’application installée :

Conclusion

Bien que le Suivi des modifications et inventaire soit très intéressant dans certains scénarios, je ne sais pas ce que l’avenir va donner sur cet outil Microsoft.

Un autre outil très intéressant et accessible sans aucun déploiement est le Change Analysis. Cet outil ne fait pas la même chose que le Suivi des modifications et inventaire.

Comme la copie d’écran ci-dessous le montre, Change Analysis est un moyen simple et rapide de voir les changement de propriétés effectués sur une ressources Azure :

Pour rester sur le sujet, John Savill a également fait une vidéo très intéressante sur la gestion des modifications Azure et les alertes possibles :

Enfin, un autre outil présent nativement dans Azure pourra vous aider dans votre investigation Azure, il appelé Resource Explorer :

Connectez votre réseau local à Global Secure Access

Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.

Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :

J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.

Qu’est-ce qu’un réseau distant ?

A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :

Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.

Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).

Microsoft Learn

Comment fonctionne la connectivité réseau à distance Global Secure Access ?

Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :

Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche. 

Microsoft Learn

Pourquoi utiliser Global Secure Access pour nos réseaux ?

Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :

Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.

Microsoft Learn

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :

J’ai été assez surpris de voir que Microsoft a même écrit un mode opératoire en simulant comme moi le réseau distant sous Azure 😎

Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.

Etape I – Préparation de la VM de test :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant une image sous Windows Server 2022 :

Choisissez la taille de votre VM, puis définissez un compte administrateur local :

Bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 3 minutes que la notification Azure suivante apparaisse :

Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.

Etape II – Création de la passerelle VPN Azure :

Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.

Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :

Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :

Cliquez sur Sauvegarder :

Attendez environ 15 secondes que la notification suivante apparaisse :

Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :

Cliquez-ici pour créer votre passerelle VPN Azure :

Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :

Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :

Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :

Allez dans l’onglet Configuration afin de copier ces informations :

Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.

Etape III – Configuration du réseau distant sur GSA :

Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :

Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :

Ajoutez un lien réseau à votre connexion :

Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :

Conservez les options suivantes, puis cliquez sur Suivant :

Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :

Cliquez sur suivant :

Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :

Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :

Une notification Entra ID apparaît alors :

Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :

Retournez sur le menu des connexions réseaux afin de récupérer des informations :

Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :

La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.

Etape IV – Configuration du réseau GSA sur Azure :

Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.

Pour cela, recherchez le service suivant sur le portail Azure :

Cliquez-ici pour commencer la création :

Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :

Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle de réseau local, puis attendez environ 2 minutes :

Attendez que le déploiement de la passerelle de réseau local soit terminé :

Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.

Etape V – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites via Global Secure Access :

Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :

Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :

Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Constatez le blocage de l’accès conditionnel mis en place précédemment :

Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.

Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.

Etape VI – Connexion entre le réseau distant et GSA :

De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :

Définissez la connexion en IP Sec, puis cliquez sur Suivant :

Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la connexion, puis attendez environ 1 minute :

Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :

Constatez le statut inconnu de celle-ci :

Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :

Le statut devrait changer sous environ 3 minutes :

Consultez la page suivante pour voir les impacts de routage via les communications BGP :

L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.

Etape VII – Global Secure Access + Accès Conditionnel v2 :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :

Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Cliquez sur Non :

Constatez la bonne connexion au service de Microsoft 365 :

Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.

Etape VIII – Retrait de la connexion VPN :

De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :

Confirmez votre choix en cliquant sur Oui :

Attendez que la notification Azure suivante apparaisse :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :

Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :

Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :

Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :

Conclusion

Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏

Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣

Microsoft 365 via Global Secure Access

2024 est à peine là, mais certaines choses ne changent pas. La sécurité IT reste encore au cœur des préoccupations pour cette nouvelle année. Les façons de consommer la donnée au travers des outils informatiques ont été bouleversées depuis l’arrivée des Cloud publics. Mais ces usages doivent s’accompagner de mesures de sécurité toujours plus performantes.

Microsoft veut changer la partie avec son Global Secure Access. Parcourons ensemble quelques notions sur ce sujet.

Pourquoi Microsoft s’intéresse aux réseaux ?

L’émergence des outils 365, les nombreuses applications disponibles sous format SaaS, les ressources hébergées sur Azure, ou encore les effets du COVID ont fait voler en éclat les approches réseaux traditionnelles.

Partant de ce constat, la sécurité des réseaux, pensée de manière centralisée, a dû elle aussi s’adapter face à au nouveaux usages et fait face à de nouvelles menaces potentielles.

Microsoft est un acteur majeur du Cloud public, et la nouvelle approche sécuritaire des réseaux au-delà de leurs centre de données est donc une évidence pour eux.

Secure Access Service Edge (SASE) vs Security Service Edge (SSE) ?

Il s’agit avant tout de structurer les produits et les services de manière plus cohérentes selon les besoins :

Le SSE définit un cadre limité de la sécurité réseau convergente, qui allie des fonctions SWG, CASB/DLP et ZTNA dans un service cloud natif. Il permet un accès sécurisé aux applications Web, SaaS et métier internes, sans prise en charge directe des ressources WAN. Ce dernier aspect relève toujours d’une solution technologique distincte, englobant des fonctions comme le SD-WAN, les pare-feux nouvelle génération et les backbones réseau globaux.

Cato Networks

Voici d’ailleurs une vidéo pour vous en faire une meilleure idée :

On dit merci qui ? Merci Gartner🤣 !

On peut donc voir le SSE comme un pan clé du pilier sécurité du SASE :

Qu’est-ce que le Zéro Trust (ZT) ?

Le concept Zéro Trust vous dit peut-être déjà quelque chose (ou pas encore) ? Une règle simple et appliquée tout le temps : Ne jamais faire confiance, toujours vérifier.

Considérez simplement chaque demande d’accès comme suspecte :

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Qu’est-ce que le Global Secure Access proposé par Microsoft ?

Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :

Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.

Microsoft Learn

Comme le montre le schéma ci-dessous, Global Secure Access regroupe 2 principaux services :

Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur le Global Secure Access :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un petit exercice. Mon premier but étant de mesurer son impact dans l’accès aux services 365 en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.

Les tâches que nous allons réaliser sont donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Microsoft Entra ID P1 licence (obligatoire)
  • Une licence Microsoft 365 E3 (recommandée)

Etape I – Configuration du tenant :

Global Service Access est un service intégré à Microsoft Entra. Vous le trouverez donc uniquement dans ce portail.

Rendez-vous sur la page du portail d’Entra, puis cliquez-ici :

Certains prérequis sont vérifiés automatiquement. Une fois tous ces derniers en vert, cliquez sur le bouton Activer :

Attendez quelques secondes l’apparition de cette notification :

Cliquez-ici afin de continuer :

Cette page vous remontre les 2 principaux services de Global Secure Access :

Cliquez sur le service de votre choix pour en savoir un peu plus :

La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :

De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :

Activez la sauvegarde en passant par le menu suivant :

Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :

Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :

La configuration de base de Global Secure Access est maintenant terminée.

Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.

Etape II – Préparation de postes utilisateurs :

Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :

Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :

Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :

Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :

Nos machines virtuelles de test sont prêtes.

Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :

Créez une second groupe Entra ID contenant vos 2 machines Azure de test :

L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié aux services Microsoft 365.

Etape III – Configuration du Profil d’accès à Microsoft 365 :

Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :

Confirmez votre action en cliquant sur OK :

Attendez quelques secondes l’apparition de cette notification :

Vérifiez le changement de statut pour le Profil d’accès à Microsoft 365 :

Pour gérer les détails de la politique de transfert de trafic Microsoft 365, sélectionnez le lien suivant :

Continuons maintenant par l’installation du client Global Secure Access.

Etape IV – Déploiement du client Global Secure Access :

Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.

Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :

Attendez que le téléchargement se termine :

Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.

Créez votre application sur la console Intune comme Microsoft le préconise :

Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :

L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.

Etape V – Test de Global Secure Access :

Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :

Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :

Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :

Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :

Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :

Comparez les deux checklist et leurs différences :

Vérifiez la présence de la règle concernant le profil Microsoft 365 sur les 2 VMs :

Sur les 2 machines virtuelles de test :

  • Ouvrez la page d’Outlook sur Edge afin de constater la connexion au service
  • Lancez une requête PING afin de constater les variations d’adresses IP

Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :

En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec l’Accès Conditionnel d’Entra ID.

Etape VI – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, rendez-vous sur la page suivante d’Entra afin de constater la situation avant activation :

Activez l’option nommée Accès adaptatif sur cette page, puis sauvegardez :

Attendez quelques secondes l’apparition de cette notification :

Retournez sur page suivante d’Entra afin de constater la situation après activation :

Créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites depuis Global Secure Access :

Bloquez l’accès pour les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis ouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Continuons avec un dernier test de restriction de tenant pour Global Secure Access.

Etape VII – Global Secure Access + Restriction au tenant :

Les restrictions imposées aux locataires permettent aux administrateurs de contrôler si leurs utilisateurs peuvent accéder aux ressources d’une organisation externe avec des comptes émis par cette dernière, tout en utilisant le réseau ou l’appareil de votre organisation.

Microsoft Entra

En d’autres termes, une fois connecté au Global Secure Access, plus moyen de s’authentifier sur un tenant tiers si cette option est activée et sans y ajouter le second tenant comme exception.

Pour cela, rendez-vous sur cette même page d’Entra ID, activez l’option suivante puis sauvegardez :

Attendez quelques minutes, puis réouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Conclusion

Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.

Enfin, d’autres articles vont bientôt suivre sur la gestion de trafic des autres profils (Private access profile, Internet access profile) 😎

Déplacez votre VM dans une Zone Azure

Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.

Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏

Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.

Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :

Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :

En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :

ScénarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilitéNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilitéNon pris en chargeLe déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)Prise en charge
Machines virtuelles dans des groupes de placement de proximitéPrise en chargeLe groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)Prise en charge
Machines virtuelles avec hôtes dédiésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise en charge
Machines virtuelles créées à partir d’images de la Place de marchéPrise en charge
Machines virtuelles créées à partir d’images personnaliséesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseauPrise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

Les avantages à utiliser les zones de disponibilité Azure sont les suivants:

  • Pour des raisons de besoins de fiabilité et de performance.
  • Pour une reprise après sinistre sans compromettre la résidence des données.

Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :

Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).

Etape I – Préparation de la VM Régionale :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Ouvrez une ou plusieurs applications en enregistrant le travail effectué :

Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.

Etape II – Déplacement de la VM Régionale dans une Zone :

Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :

  • Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
  • Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.

Cliquez-ici pour démarrer le processus de migration :

Choisissez la zone cible pour la migration :

Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :

Une notification Azure apparaît également :

Un nouveau groupe de ressources est créé par cette même occasion :

Des droits RBAC sont également générés au niveau de la souscription Azure concernée :

Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :

Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :

  • Création d’un nouveau groupe de ressources
  • Création de nouvelles ressources pour tous les objets existants
  • Modification des noms des ressources

La validation entraine une seconde vérification des paramètres modifiés :

Une nouvelle notification Azure apparait indiquant que le traitement est en cours :

Environ 30 secondes plus tard, le traitement de validation se termine :

Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :

Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :

Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :

La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :

Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :

Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :

Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :

Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :

  • La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
  • La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3

Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :

Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :

De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :

Etape III – Contrôle de la VM zonée :

Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :

Vérifiez la présence de la zone 3, puis cliquez sur le Editer :

Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :

Cette information de zone de notre machine virtuelle est aussi disponible ici :

Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :

  • Redéployer un service Azure Bastion
  • Utiliser l’adresse IP publique
  • Appairer les 2 réseaux virtuels entre eux

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :

Vérifiez la présence du travail effectué précédemment :

Etape IV – Nettoyage des ressources non zonées :

Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.

Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :

  • Groupe de ressources contenant l’ancienne machine virtuelle
  • Groupe de ressource contenant les composants liés à la migration

La suppression d’un groupe de ressources Azure s’effectue très simplement :

Confirmez l’ordre de suppression :

Conclusion

Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.

On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎

Copilot for Azure 💙

Comme pour Microsoft 365, Azure a lui aussi droit à son propre Copilot, appelé Copilot for Azure. Par contre, aucune GA n’a pour l’instant encore été annoncée pour ce dernier, seule la préversion est actuellement disponible sur demande et sur approbation de Microsoft. Copilot for Azure est bien une IA fonctionnant sous forme d’assistant, tout en ayant un accès direct aux ressources Azure selon vos droits RBAC.

Un premier article sur ce blog parlant déjà de plusieurs Copilot est disponible juste ici, tandis qu’un autre consacré à l’IA de façon généraliste est accessible juste .

L’annonce de l’ouverture de la préversion de Copilot for Azure s’est faite durant l’Ignite, la procédure pour la rejoindre avait été détaillée sur le blog Azure :

Microsoft Copilot for Azure est déjà utilisé en interne par les employés de Microsoft et par un petit groupe de clients.

Aujourd’hui, nous sommes ravis de passer à l’étape suivante en annonçant et en lançant l’avant-première pour vous ! Cliquez ici pour vous inscrire.

Nous intégrerons les clients à l’avant-première sur une base hebdomadaire. Dans les semaines à venir, nous ajouterons continuellement de nouvelles fonctionnalités et apporterons des améliorations en fonction de vos commentaires.

Azure Blog

Comme l’indique encore le blog Azure, Copilot for Azure va vous aider principalement à :

  • Conception : créer et configurer les services nécessaires tout en s’alignant sur les politiques de l’organisation
  • Exploitation : répondre aux questions, créer des commandes complexes et gérer les ressources
  • Dépannage : orchestrer les services Azure pour obtenir des informations permettant de résumer les problèmes, d’identifier les causes et de suggérer des solutions
  • Optimisation : améliorer les coûts, l’évolutivité et la fiabilité par le biais de recommandations pour votre environnement

Que peut-on rêver de mieux? Voici d’ailleurs ce que son grand frère en dit de lui quand on lui pose la question 🤣 :

Voici également une vidéo sur Copilot for Azure déjà réalisée par John Savill :

Tout comme John, je souhaitais partager avec vous mes premières expériences de Copilot for Azure, depuis la demande d’accès jusqu’aux premiers tests sur le portail Azure. Voici quelques prompts réalisés sur mon environnement Azure autorisé :

Avant de pouvoir jouer à Copilot for Azure, il est nécessaire de le mettre en place sur Copilot for Azure sur votre environnment.

Etape 0 – Mise en place de Copilot for Azure :

Comme pour tout produit en préversion chez Microsoft, des contraintes sont présentes :

  • L’autorisation pour Copilot for Azure portera sur toutes les souscriptions Azure.
  • Uniquement disponible certains partenaires agréés par Microsoft.
  • Uniquement disponible sur le Cloud publique d’Azure (Pas de Gov ou China).
  • Seulement l’anglais est disponible durant la préversion publique.
  • La préversion publique est gratuite.

Tout commence par le formulaire officiel à accessible par ce lien :

Des informations personnelles et professionnelles sont nécessaires, et il vous faudra également donner votre Tenant ID :

Après avoir rempli votre formulaire, il ne vous reste qu’à l’envoyer :

Voici le message email que vous devriez immédiatement recevoir après l’envoi du formulaire :

Exactement 15 jours plus tard, j’ai reçu avec un immense plaisir le second email suivant :

J’ai donc immédiatement vérifié un éventuel changement sur le portail Azure, rien à ce moment-là :

Par contre, le lendemain, les choses ont bougé et le bouton Copilot y a fait son apparition :

En cliquant dessus, on remarque que Copilot est toujours en préversion, c’est important de le rappeler :

Quelques explications apparaissent, cliquez sur Suivant :

On y apprend les 3 principales limitations à la préversion :

  • 5 ressources impactées max par une action Copilot
  • 10 requêtes max par session de chat avec Copilot
  • 5 chats max par tranche de 24 heures avec Copilot

Enfin l’avertissement sur le besoin actuel et indispensable de vérifier toutes les réponses d’une IA :

Le prompt est maintenant à nous, nous allons pouvoir effectuer quelques tests :

Commençons par une chose simple sur des ressources Azure déjà en place.

Test I – Prompt Analyse (nombre de VMs) :

Demandons à Copilot le calculer nombre de VMs Azure présentes sur mon environnement Azure :

Copilot for Azure nous montre qu’il tient compte des souscriptions filtrées dans ma console et la requête qu’il compte faire sous forme de requête :

La réponse affichée dans le prompt par Copilot for Azure est bien correct :

Je n’ai bien qu’une seule machine virtuelle actuellement visible sur mon tenant de test :

Continuons maintenant avec un prompt de type action sur une ressource Azure.

Test II – Prompt Action (démarrage VM) :

Demandons à Copilot de nous démarrer cette machine virtuelle précédemment listée :

Copilot for Azure comprend la demande et nous demande juste de confirmer l’ordre d’allumage :

Copilot démarre la machine virtuelle et nous invite à suivre l’évolution via la notification Azure :

Une notification Azure apparaît bien suite à la confirmation à Copilot de l’ordre de démarrage :

Environ 1 minute plus tard, la notification Azure confirme bien le démarrage de la VM :

Le statut de la machine virtuelle a bien changé dans la liste des VMs Azure :

Continuons avec un second ordre sur une ressource Azure.

Test III – Prompt Contre-Action (arrêt VM) :

Admettons que la commande précédente ne soit pas celle finalement voulue. Voici ce qui passe avec Copilot si l’on souhaite faire modifier cette action par une autre.

Ma machine virtuelle ci-dessous supporte le mode hibernation décrit sur ce blog ici et :

Je souhaite que Copilot change son statut, actuellement démarrée, en mode hibernation :

Visiblement, la fonction d’hibernation, encore en préversion, n’est pas encore reconnue par Copilot for Azure :

Copilot me propose malgré tout une autre action proche de celle demandée :

Je confirme mon choix en cliquant sur Oui :

Une nouvelle notification Azure apparait alors :

Le message suivant de Copilot apparaît dans le prompt au même moment :

Environ 30 secondes plus tard, la notification Azure de succès de l’action apparaît :

Le statut de la machine virtuelle a bien changé comme attendu :

Continuons nos tests avec des questions financières relative au Cost Management d’Azure.

Test IV – Prompt Analyse (Coûts Azure) :

Cette machine virtuelle est opérationnelle depuis déjà plusieurs semaines. Posons la question suivante à Copilot afin d’obtenir les coûts depuis le 1er novembre 2023 :

Le résultat n’est selon moi pas correct comme le montre les coûts présents :

Posons la même question afin d’obtenir les coûts depuis le 1er décembre 2023 :

Posons la question en ciblant la VM afin d’obtenir ses coûts depuis le 1er décembre 2023 :

Là encore, et malgré que cette VM est bien souvent en état d’hibernation, des coûts sont constamment présents sur la partie stockage, comme le montre le Cost Management suivant :

Afin d’approcher différemment cette requête financière, j’ajoute un tag sur toutes les ressources Azure concernées :

Et je repose la question à Copilot en ciblant uniquement le tag :

La requête est bien comprise par Copilot for Azure puisque seules des ressources taggées me sont affichées en réponse dans le prompt :

Mais la même réponse d’absence de coûts m’est retournée quand je cherche à savoir combien me coûte les ressources Azure ayant ce même tag :

Continuons nos tests avec d’autres exemples de prompt.

Test V – Prompt Analyse (Infos VM) :

Posons une question simple à Copilot concernant le statut de votre VM :

Les informations retournées sont précises et informatives :

Continuons nos tests avec d’autres exemples de prompt.

Test VI – Prompt Action (création VM) :

Une autre demande à Copilot sur la création de ressource Azure vous donnera toutes les étapes nécessaires, sous forme de commandes CLI, sans pour autant les réaliser pour vous pour l’instannt :

En ouvrant soi-même une fenêtre Azure Cloud Shell et en y copiant les 2 commandes proposées par Copilot, la création de la VM démarre bien :

Voici un second test de création de VM avec plus de paramètres :

Continuons nos tests dans le cas où l’on souhaiterait modifier une ressource Azure déjà en place.

Test VII – Prompt Action (Modification VM) :

Demandons à Copilot de changer la taille de la VM récemment créée :

Malheureseument, Copilot n’effectue pas directement l’action mais repropose une commande CLI.

Une fois la commande manuellement lancée dans Azure Cloud Shell, la taille de la VM est bien modifiée :

Continuons nos tests avec d’autres exemples de prompt.

Test VIII – Prompt Optimisation (Protection VM) :

Demandons à Copilot de l’aide dans la protection d’une machine virtuelle déjà en place :

L’ordre suivant apparaît alors :

Je sélectionne le premier compte de stockage de la liste :

Je confirme mon choix en cliquant sur Oui :

Le traitement d’analyse suivant ce lance alors :

Copilot for Azure m’affiche des conseils de sécurité concernant le compte de stockage sélectionné :

C’est une bonne chose, mais je voulais obtenir des conseils pour ma machine virtuelle😎

Continuons nos tests avec d’autres exemples de prompt.

Test IX – Prompt Analyse (Suppression VM) :

Continuons les tests Copilot par une demande de suppression d’une machine virtuelle Azure :

Copilot for Azure comprend bien la requête et me confirmer l’action de suppression :

La fenêtre habituelle de suppression de ressources apparaît alors :

Je confirme mon choix :

La notification Azure de suppression apparaît alors :

Celle-ci se confirme environ 1 minute plus tard :

La machine virtuelle est bien supprimée :

Continuons nos tests avec un dernier exemple de prompt.

Test X – Prompt Documentation (Azure Virtual Desktop) :

Terminons par une question documentaire sur le déploiement d’un environnement Azure Virtual Desktop :

Plusieurs documentations Microsoft me sont retournées. Peut-être qu’un jour ce blog y sera également en tant que réponse Copilot 🤣

Conclusion

Cette première préversion de Copilot for Azure montre déjà un certain potentiel dans la gestion, la création et l’optimisation des ressources du Cloud. J’ai eu aussi quelques petites erreurs de prompt ou de perte connexion avec les serveurs Copilot.

Nul doute que Copilot va très rapidement gagner en stabilité, apprendre plus de commandes et proposer d’interactions afin de faciliter la vie dans certaines actions basiques ou avancées sur le Cloud Azure.

Azure Site Recovery pour des serveurs sur site

En cas de sinistre informatique, il n’y a aucun moyen de savoir ce qui peut frapper ou comment votre l’infrastructure peut en être affectée. Toutefois, en adoptant une approche réfléchie de la planification en cas de catastrophe, vous créer une tranquillité d’esprit si votre entreprise devait être confrontée à un sinistre.

Azure Site Recovery : permet d’assurer la continuité de l’activité en maintenant l’exécution des charges de travail et applications métier lors des interruptions. Site Recovery réplique les charges de travail s’exécutant sur des machines virtuelles et physiques depuis un site principal vers un emplacement secondaire.

En cas d’interruption au niveau de votre site principal, vous basculez vers un emplacement secondaire, depuis lequel vous pouvez accéder aux applications. Quand l’emplacement principal est de nouveau fonctionnel, vous pouvez effectuer une restauration automatique vers celui-ci.

Microsoft Learn

Voici une vidéo qui parle des mécanismes d’Azure Site Recovery :

Afin de se faire une meilleure idée sur Azure Site Recovery, je vous propose de réaliser un petit exercice combinant Azure Site Recovery et Hyper-V :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Site Recovery, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Important : Pour cela, je vous propose de simuler deux serveurs sous Windows Server 2019 grâce à un environnement virtualisé de type Hyper-V hébergé lui sur Azure

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 de base de votre machine virtuelle Hyper-V :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3 :

Définissez un compte administrateur local, 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 cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle Hyper-V :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

La configuration Azure est maintenant terminée, la suite va se passer sur la machine virtuelle Hyper-V.

Etape II – Configuration Hyper-V :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

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 :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V, et de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

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 deux machine virtuelles :

  • Windows Server 2019 pour jouer le rôle d’Appliance Azure Site Recovery
  • Windows Server 2019 pour jouer le rôle d’un serveur on-premise

Etape III – Création des machines virtuelles (Appliance / SRV) :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Server 2019 afin de créer la machine virtuelle Appliance, 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 Server 2019, puis effectuez les actions suivantes :

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 Appliance :

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 Appliance, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO de Windows Server 2019 téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle archive :

Modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

Cliquez-ici pour lancer le démarrage de la VM archive :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows Server 2019 :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows Server 2019 :

Choisissez une version suivante de Windows Server 2019, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Sélectionnez l’installation personnalisée de Windows Server 2019 :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Attendez maintenant que l’installation de Windows Server 2019 commence :

En attentant que l’installation de Windows Server 2019 se finisse sur la machine virtuelle Appliance, créez une seconde machine virtuelle appelée et SRV de génération 1 :

De la même manière que pour la VM appliance, lancez l’installation de Windows Server 2019 sur la VM SRV :

Une fois les deux installations terminées, définissez un mot de passe pour le compte administrateur local :

Sur les 2 VMs, renseignez le mot de passe administrateur pour ouvrir une sessions Windows :

Désactivez la sécurité Internet Explorer, puis cliquez sur OK :

Depuis Internet Explorer, recherchez puis installez Edge :

Nous deux machines virtuelles sont correctement installées. La suite consiste à mettre en place l’appliance d’Azure Site Recovery.

Etape IV – Configuration Azure Site Recovery :

Retournez sur le portail Azure afin de créer le Coffre de restauration (Azure Recovery Vault) :

Renseignez les informations de base de votre Coffre de restauration, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de Coffre de restauration, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez-ici pour commencer la configuration de Coffre de restauration :

Préparer l’infrastructure on-premise en cliquant ici :

Cliquez sur le lien suivant afin d’ouvrir la documentation Microsoft :

Copiez le lien ci-dessous (ou ici) afin de télécharger l’appliance dédiée à Azure Site Recovery :

Collez ce lien dans la machine virtuelle Appliance, puis attendez la fin du téléchargement :

Une fois l’archive ZIP téléchargé, ouvrez le dossier contenant celle-ci :

Avant de décompresser l’archive ZIP, débloquez celle-ci grâce à la case suivante, puis cliquez sur OK :

Lancez l’extraction dans le dossier de votre choix :

Attendez environ 3 minutes que l’archive ZIP se décompresse en totalité :

Sur la machine virtuelle Appliance, ouvrez une session PowerShell, puis positionnez-vous le dossier où l’archive ZIP a été extraite :

Lancez la commande PowerShell suivante :

.\DRInstaller.ps1

Confirmez la réponse avec Y :

Attendez environ 2 minutes que le traitement PowerShell se termine :

Vérifiez qu’aucune erreur n’a été remontée dans la fenêtre PowerShell :

Toujours sur la VM Appliance, retrouvez le dossier Software créé à la racine du disque Q afin de modifier ses propriétés :

Dans l’onglet Partage, cliquez sur le bouton Partager :

Confirmez les utilisateurs voulus, puis cliquez sur Partager :

Copiez le chemin du partage puis fermez la fenêtre de configuration du partage :

Lancez les 2 actions suivantes respectivement sur les deux VMs :

  • Sur la machine virtuelle Appliance, ouvrez Microsoft Azure Appliance Configuration Manager (présent sur le bureau )
  • Sur la machine virtuelle SRV, utilisez l’explorateur Windows pour vous rendre sur le chemin du partage activé précédemment

Sur la VM Appliance, vérifiez le bon fonctionnement réseau ainsi que les préconisations minimales, puis cliquez sur Continuer :

Attendez le contrôle de version, puis cliquez sur Continuer :

Cliquez sur Sauvegarder :

Cliquez sur Continuer :

Coller la clef précédemment présentée sur votre Coffre de restauration Azure, puis cliquez sur Login :

La fenêtre suivante s’ouvre afin que vous puissiez copier le code d’identification dans Azure :

Renseignez ce code dans la fenêtre d’authentification Azure, puis cliquez sur Suivant :

Renseignez vos identifiants Azure :

Réussissez le challenge MFA si nécessaire :

Cliquez sur Continuer afin d’autoriser la configuration avec Azure :

Vérifiez la confirmation Azure :

Attendez que l’enregistrement sur Azure se termine :

Cliquez sur Continuer :

Cochez la case suivante puis cliquez sur Continuer :

Ajoutez les informations relatives (identifiants / IP) à la machine virtuelle SRV :

Une fois ces informations renseignées, cliquez sur Continuer :

Comme indiqué, attendez jusqu’à 30 minutes que le traitement se termine :

En attendant, lancez l’installation de l’agent sur la machine virtuelle SRV disponible sur le partage réseau activé précédemment :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée, cliquez ici pour configurer l’agent :

Copiez les détails de la machine virtuelle SRV dans le bloc-notes :

Créez sur le partage réseau un fichier texte contenant les détails de la machine virtuelle SRV, collez le contenu de ce fichier texte sur la machine virtuelle Appliance, puis téléchargez le fichier de configuration :

Sauvegardez le fichier de configuration téléchargé précédemment sur le partage réseau, puis insérez le dans la configuration de la machine virtuelle SRV :

Lancez le traitement de configuration, puis attendez environ 1 minute :

Cliquez sur terminer une fois tous les voyants au vert :

De retour sur Azure, vérifiez la bonne configuration de l’infrastructure de reprise dans le Coffre de restauration :

La configuration d’Azure Site Recovery est maintenant terminée. La prochaine étape consiste en la mise en place de la réplication vers Azure.

Etape V – Activation de la réplication :

Activez la réplication de votre VM SRV via le menu suivant :

Choisissez votre VM SRV dans la liste des machines à répliquer, puis cliquez sur Suivant :

Cliquez sur Suivant :

Renseignez tous les champs ci-dessous, puis cliquez sur Suivant :

Activez la réplication Azure :

Une première notification Azure apparaît pour vous signaler la mise en place des ressources :

Puis une seconde notification Azure apparaît pour vous indiquer le démarrage de la réplication de votre VM SRV :

Un clic sur cette notification nous affiche toutes les étapes et travaux réalisés au sein du Coffre de restauration :

Environ 10 minutes, une nouvelle notification nous indique le succès de la configuration de réplication :

Cliquez ici pour suivre l’avancement de la réplication des données vers Azure :

La machine virtuelle SRV est maintenant répliquée dans Azure. Nous allons maintenant pouvoir tester la réplication ASR via la fonction de bascule (failover).

Etape VI – Test de la réplication :

Environ 45 minutes après, la machine virtuelle SRV est enfin répliquée dans Azure et son statut change en Protégée :

Consultez les informations dont le RPO :

Consultez le schéma complet de réplication ASR :

Vérifiez et modifiez ci-dessous les informations VM et réseau :

Vérifiez et modifiez ci-dessous les informations des disques :

De retour sur la machine virtuelle SRV, créez un fichier image, puis enregistrez-le sur le bureau :

Attendez environ 10 minutes, puis lancez l’opération de bascule vers Azure :

Cochez la case suivante, plus cliquez-ici :

Confirmez votre action en cliquant ici :

Une nouvelle notification Azure apparaît pour vous indiquer la création de la machine virtuelle SRV dans Azure :

Consultez le nouveau groupe de ressources Azure créé pour la réplication :

Attendez la seconde notification Azure vous indiquant le succès du traitement de bascule :

Rafraichissez la page du groupe de ressources créé par ASR afin de constate la présence de la nouvelle machine virtuelle SRV :

Vérifiez la configuration CPU / Mémoire :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

Lancez le script PowerShell suivant afin d’activer le service de bureau à distance :

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Environ 30 secondes plus tard, le traitement est exécuté avec succès :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les mêmes identifiants administrateurs :

Réouvrez le fichier image créé précédemment avant la bascule :

Conclusion :

Malgré une mise en place un peu longue et des exigences de puissance CPU / Mémoire concernant la machine virtuelle appliance, la mise en place d’Azure Site Recovery a bien fonctionné. Que demandez de plus 😎🥳