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.

Copilot + données on-premise

Le cloud est devenu le quotidien pour un grand nombre d’entreprises, mais les sites on-premise gardent encore une belle part des infrastructures et du stockage de données. Les principales IA ont compris cela, et elles proposent différents moyens de connecter ces données stockées on-premise à elles, afin ces informations soient elles-aussi indexées dans les mêmes outils pour une meilleure expérience utilisateur.

Le connecteur Partage de fichiers Microsoft Graph permet aux utilisateurs de votre organization de rechercher des partages de fichiers Windows locaux.

Microsoft Learn

Avant d’attaquer le sujet central de cet article, voici un rappel des articles écrits autour des solutions Copilot de Microsoft :

Pour notre démonstration, Microsoft a mis à disposition 3 documentations relatives à la mise en place de l’agent on-premise pour un serveur de fichiers local :

Quels sont les formats de fichiers pris en charge par l’agent de connecteur ?

Microsoft rappelle ici les formats supportant l’indexation au travers de l’agent on-premise pour un partage de fichier :

DOC, DOCM, DOCX, DOT, DOTX, EML, GIF, HTML, JPEG, JPG, MHT, MHTML, MSG, NWS, OBD, OBT, ODP, ODS, ODS, ODT, ONE, PDF, PNG, POT, PPS, PPT, PPTM, PPTX, TXT, XLB, XLC, XLSB, XLSB, XLSX, XLT, XLXM, XML, XPS et ZIP

Rappel : Seul le contenu texte sera indexé et les fichiers supérieurs à 100 Mo seront ignorés.

Existe-t-il une configuration recommandée pour installer l’agent on-premise ?

Microsoft recommande d’installer l’agent on-premise sur une machine ou un poste ayant les caractéristiques suivantes :

  • Windows 10, Windows Server 2016 R2 et versions ultérieures
  • 8 cœurs, 3 GHz
  • 16 Go de RAM, 2 Go d’espace disque
  • Accès réseau à la source de données et à Internet via 443

Afin de bien comprendre le fonctionnement de l’agent on-premise sur un serveur partage de fichiers local vers Copilot pour Microsoft 365, je vous propose de réaliser ce petit exercice :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Copilot pour Microsoft 365
  • Une des licences 365 suivantes :
    • Microsoft 365 E5
    • Microsoft 365 E3
    • Office 365 E3
    • Office 365 E5
    • Microsoft 365 A5
    • Microsoft 365 A3
    • Office 365 A5
    • Office 365 A3
    • Microsoft 365 Business Standard
    • Microsoft 365 Business Premium

Avant d’installation le connecteur sur le serveur on-premise, faisons un premier de test de prompt à Copilot pour évaluer les réponses obtenues.

Etape I – Premier test Copilot sans connecteur :

Pour cela, ouvrez votre navigateur internet sur la page web de Copilot en mode Work :

Saisissez le prompt suivant :

cherche un document parlant de associez fslogix avec azure ad

Copilot vous informe qu’il trouve bien des documents sur SharePoint ou Teams, mais aucun document stocké depuis un serveur de fichiers local.

Afin de pouvoir tester ce connecteur, il m’est nécessaire de créer une machine virtuelle.

Etape II – Préparation du serveur de fichiers local :

Afin de faciliter la démonstration, j’ai donc créé la machine virtuelle suivante sur Azure :

Cette machine virtuelle fonctionne sous Windows Server et est jointe à un domaine Active Directory. De plus, elle se trouve sur le même réseau que le Cloud PC Windows 365 contenant les outils 365 et la licence Copilot pour Microsoft 365.

Important : La liaison réseau directe sera nécessaire pour ouvrir le document indexé et proposé dans les résultats de Copilot.

J’ai également déployé le service Azure Bastion pour m’y connecter plus facilement en RDP :

Commençons par la préparation de notre tenant à gérer les authentification de notre connecteur à Microsoft 365 à l’API Microsoft Graph.

Etape III – Création d’une Inscription d’application Entra :

Rendez-vous sur la page du portail Azure disponible juste ici, puis ouvrez le service Microsoft Entra ID :

Dans le menu Inscriptions d’applications, cliquez-ici pour créer une nouvelle Inscription :

Nommez votre application, puis cliquez sur Inscrire :

Cliquez sur le menu Certificats et secrets, puis ajoutez un nouveau secret client comme ceci :

Donnez-lui une description, puis cliquez sur Ajouter :

Copiez la valeur de votre secret. Ce dernier sera utilisé par votre connecteur on-premise afin qu’il s’authentifie automatiquement :

Dans le menu des Permissions API, cliquez-ici pour ajouter des permissions supplémentaires :

Choisissez l’API Microsoft Graph :

Cliquez sur Permissions d’application :

Recherchez et cochez les 3 permissions suivantes en utilisant la barre de recherche, puis cliquez sur Ajouter les permissions :

  • ExternalConnection
    • ExternalConnection.ReadWrite.OwnedBy
  • ExternalItem
    • ExternalItem.ReadWrite.OwnedBy
  • Directory
    • Directory.Read.All

Enfin, cliquez sur le bouton suivant afin d’appliquer ces permissions au niveau du tenant :

Confirmez votre choix en cliquant sur Oui :

Copiez également l’ID de votre application pour la configuration de l’agent on-premise :

La configuration du côté du tenant est en partie terminée. Nous allons maintenant nous intéresser l’installation de l’Agent on-premise.

Etape IV – Installation de l’agent on-premise :

Avant de de configurer l’agent on-premise installé sur votre serveur de fichiers local, il est nécessaire de dispose d’un rôle RBAC spécifique sur Entra ID :

Sur votre serveur de fichiers, ouvrez une session à distance avec un compte administrateur via le service Azure Bastion :

Sur votre serveur de fichiers, préparez une arborescence partagée sur le réseau et contenant des fichiers de données à indexer :

Avant d’installer l’agent on-premise, il est nécessaire de disposer au minimum de .NET Core Desktop Runtime en version 7.0.

Pour cela, téléchargez-le depuis cette page :

Lancez l’installation de .NET 7.0 :

Continuez en téléchargeant l’agent on-premise depuis cette page :

Cliquez-ici pour commencer le téléchargement, puis lancez l’installation :

Cliquez sur Suivant :

Acceptez les conditions, puis cliquez sur Suivant :

Cliquez sur Installer :

Validez en cliquant sur Oui sur les différents messages d’avertissement Windows :

L’installation est finie, cliquez sur Terminer :

Le configurateur de l’agent on-premise s’ouvre automatiquement, cliquez-ici pour associez ce dernier à votre tenant Microsoft :

Nommez cet agent on-premise, reprenez les informations récupérées de l’inscription d’application créée précédemment, puis cliquez sur Enregistrer :

Attendez quelques minutes la finalisation de la configuration de l’agent on-premise :

Une fois la configuration terminée, cliquez sur Fermer :

La configuration sur le serveur de fichiers local est maintenant terminée, nous allons mettre en place la liaison avec 365 depuis la console d’administration 365 dédiée : Recherche et intelligence.

Etape V – Configuration de la source de données 365 :

Pour cela, retournez sur cette page d’administration du tenant Microsoft 365 afin de finaliser la configuration de l’agent on-premise en tant que nouvelle source de données :

Sélectionnez le Partage de fichiers, puis cliquez sur Suivant :

Nommez votre connexion ainsi que les informations visibles pour l’utilisateur Copilot, puis cliquez ici :

Reprenez les informations liées au partage de fichier en y incluant l’agent on-premise ainsi que les identifiants Windows de votre domaine, testez la bonne connexion, puis cliquez-ici :

Regardez les choix possibles, puis cliquez-ici :

Regardez les choix possibles, puis cliquez-ici :

Regardez les choix possibles, puis cliquez-ici :

Déterminez les droits d’exploitation des fichiers stockées sur votre partage local, puis cliquez-ici :

Regardez les choix possibles, puis cliquez-ici :

Regardez les choix possibles, puis cliquez-ici :

Définissez le fuseau horaire adéquat et la fréquence de synchronisation, puis cliquez-ici :

Enfin cliquez sur Publier :

Cliquez sur Fermez :

Attendez quelques minutes afin que le connecteur soit entièrement publié, que la première synchronisation soit finie et que des premiers documents soient indexés :

Votre configuration est enfin terminée. Passez à la suite pour constater d’éventuels changements.

Etape VI – Second test Copilot avec connecteur :

Sur votre utilisateur ayant la licence Copilot pour Microsoft 365, retournez sur la page de Copilot en mode Work en ayant toujours aucun plugin d’actif :

Saisissez à nouveau le prompt suivant :

cherche un document parlant de associez fslogix avec azure ad

Constatez l’apparition d’un résultat avec une ou plusieurs références de provenant de notre connecteur en relation avec l’agent installé sur le serveur de fichiers local :

De mon côté, je n’ai pas été en mesure de cliquer directement sur la source et d’obtenir automatiquement le fichiers attendu directement depuis la console Copilot.

Pourtant, en copiant l’URL de la source Copilot, le fichier est bien accessible et est téléchargeable :

Je cherche toujours pourquoi…

Etape VII – Test depuis Microsoft Search :

Malgré cela, j’ai souhaité refaire le même test depuis la barre de recherche Microsoft Search située sur la page d’Office :

Saisissez les mots clefs suivants :

associez fslogix avec azure ad

Le même résultat apparaît alors, cliquez sur le nom du fichier proposé par Microsoft Search :

Acceptez le risque en cliquant sur Oui :

Constatez la bonne ouverture du fichier depuis la source locale en lecture seule :

Conclusion

La mise en place de l’agent on-premise dédié au partage de fichiers pour Copilot pour Microsoft 365 est assez facile à mettre en place et fonctionne plutôt bien.

Grâce à Microsoft Graph, Microsoft propose à tous un très grand nombre de possibilités pour créer les liaisons vers Copilot selon vos exigences et vos besoins :

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 :

Importez dans Copilot via un connecteur 🔌

J’ai reçu un mail il y a quelques jours de la part de Microsoft (oui oui, seulement un 🤣) m’invitant tester par moi-même un premier connecteur Copilot pour Microsoft 365, en suivant simplement un pas à pas technique. N’ayant pas d’expérience en .NET, je me suis dit … pourquoi pas ! Je vous propose de le réaliser ensemble pour que vous puissiez vous-même reproduire cet exercice sur votre tenant Copilot.

Dans cet article, nous reprendrons brièvement quelques concepts et nous testerons nous-même de créer un connecteur Microsoft Graph personnalisé afin d’enrichir les résultats Copilot dans Microsoft 365.

Voici encore un rappel des articles écrits autour des solutions Copilot de Microsoft :

Qu’est-ce qu’un connecteur Microsoft Graph ?

Les connecteurs Microsoft Graph vous permettent d’ingérer vos données métier non structurées dans Microsoft Graph, afin que Copilot pour Microsoft 365 puissent raisonner sur l’intégralité du contenu de votre entreprise. Le contenu ingéré via les connecteurs Graph est ajouté à Microsoft Graph ; cela déverrouille la compréhension sémantique des invites de vos utilisateurs dans Copilot pour Microsoft 365.

Microsoft Learn

Quel est l’impact d’un connecteur dans Copilot pour 365 ?

L’impact de connecteur dans les résultats Copilot peut changer la donne dans les résultats de recherche documentaire car il va fouiner en dehors de Microsoft 365.

Voici un exemple montrant des résultats avec des références externes à Microsoft 365, améliorant donc l’expérience de recherche de l’utilisateur Copilot :