Migrer la détection d’identité, pas seulement un agent
Un contrôleur de domaine peut être visible dans Microsoft Defender for Endpoint (MDE) sans que la couverture Defender for Identity (MDI) soit correctement activée et validée. Une migration réussie doit préserver les signaux d’identité, les paramètres d’audit et la capacité de réponse, pas seulement afficher une nouvelle version.
La migration v2 vers v3 est généralement disponible depuis juillet 2026, y compris pour les contrôleurs de domaine Windows Server 2025 admissibles. Certaines fonctions arrivent progressivement selon le locataire. Les étapes ci-dessous constituent une méthode de déploiement recommandée; les exemples doivent être adaptés et validés dans votre environnement.
Choisir les serveurs admissibles et conserver les exceptions
Un parc mixte v2/v3 est pris en charge dans le même espace MDI. Ne regroupez pas des rôles d’identité sur un DC uniquement pour accélérer cette migration.
Attention à la distinction entre prise en charge et chemin de migration : la page de migration limite encore son prérequis aux DC sans rôle d’identité additionnel. Les notes de nouveautés mentionnent aussi une extension de l’audit automatique, mais la matrice de déploiement conserve v2 pour les serveurs non-DC. En cas d’écart documentaire, validez le cas auprès de Microsoft plutôt que de forcer l’installation.
| Situation | Décision de déploiement |
|---|---|
| DC Windows Server 2019, 2022 ou 2025 à jour | Candidat v3; confirmer l’admissibilité dans le portail. |
| DC Windows Server 2016 | Conserver v2 et planifier la modernisation du système. |
| Serveur AD FS, AD CS ou Entra Connect qui n’est pas DC | La matrice de déploiement prescrit encore v2. |
| DC hébergeant aussi un rôle d’identité | v3 est pris en charge en déploiement; ne pas présumer que la migration sur place est admissible. |
| Dépendance à l’intégration VPN ou aux notifications syslog | Conserver v2 sur les DC concernés tant que cette dépendance existe. |
Vérifier MDE, les correctifs et les ressources
Les prérequis v3 actuels demandent Windows Server 2019 ou ultérieur, la mise à jour cumulative de juillet 2026 ou ultérieure et un véritable onboarding MDE. La présence de l’antivirus ne suffit pas; Microsoft Defender Antivirus peut être actif ou passif. Pour migrer, le capteur v2 doit être au minimum en version 2.254.19112.470.
La VM doit disposer de toute sa mémoire allouée : pas de mémoire dynamique Hyper-V; réservation complète sous VMware. Le plafond du capteur v3 est de 30 % CPU et 1,5 Go de mémoire; ce n’est ni un dimensionnement du DC ni une garantie de collecte intégrale sous forte charge. Les exigences ExpressRoute doivent aussi être revues.
Confirmer les licences et les accès avant le changement
Vérifiez les droits Defender for Identity pour les utilisateurs couverts et les droits MDE applicables aux serveurs. Ne déduisez pas qu’un agent installé ou un abonnement Microsoft 365 quelconque couvre automatiquement tous les usages. Faites confirmer les droits par votre responsable des licences.
Pour l’opération MDI, utilisez Security Administrator ou les permissions Unified RBAC requises par Microsoft : System settings (Read and manage) et Security settings (All permissions). Distinguez cet accès au portail des droits Windows nécessaires aux vérifications locales. Évitez d’utiliser Global Administrator comme compte de travail permanent.
Faire un état des lieux PowerShell sans modifier AD
Commencez par un DC pilote. Ces commandes de consultation s’exécutent dans une console PowerShell administrateur; elles ne migrent rien. Conservez les résultats avant et après, dans un emplacement d’administration protégé.
La liste Get-HotFix est une aide d’inventaire, pas une preuve autonome de conformité. Comparez le numéro de build, l’état du redémarrage et les correctifs applicables à votre version Windows Server. Vérifiez séparément la réplication, DNS et la disponibilité des autres DC avant toute maintenance.
- Complétez l’inventaire avec Entra Connect, les agents tiers, les intégrations VPN/syslog et les dépendances réseau.
- Notez les alertes de santé déjà présentes : elles ne doivent pas être attribuées automatiquement à la migration.
- Créez une fiche par DC : site AD, OS/build, version MDI, état MDE, rôle, responsable, décision et preuve de validation.
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber, LastBootUpTime
Get-Service -Name Sense,AATPSensor,AATPSensorUpdater -ErrorAction SilentlyContinue |
Select-Object Name, Status, StartType
Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 8 HotFixID, InstalledOn
Get-WindowsFeature AD-Domain-Services,ADFS-Federation,ADCS-Cert-Authority |
Select-Object Name, InstallState
auditpol.exe /get /category:*Utiliser le diagnostic officiel plutôt qu’un script de correction global
Téléchargez Test-MdiReadiness.ps1 depuis le dépôt Microsoft lié ci-dessous, examinez-le et utilisez une copie approuvée. Il produit des rapports sur les prérequis et la configuration; ne traitez pas son résultat comme un remplacement de l’admissibilité affichée dans le portail.
Le script peut inspecter d’autres serveurs d’identité du domaine selon ses paramètres et sa version. Relisez son aide avant exécution et limitez le périmètre au besoin. Ses rapports contiennent des détails sur votre infrastructure : ne les publiez pas dans un billet de soutien public.
Get-Help .\Test-MdiReadiness.ps1 -Full
.\Test-MdiReadiness.ps1 -Domain "corp.example" `
-DomainController "dc01.corp.example" `
-Path "C:\Admin\MDI-Readiness" -OpenHtmlReportMigrer un DC pilote depuis le portail Defender
Dans security.microsoft.com, ouvrez Settings > Identities > On-premises > Sensors. Sélectionnez un DC marqué Ready for migration, puis Migrate et confirmez. La transition prend généralement jusqu’à 20 minutes; v2 continue de fonctionner pendant la préparation de v3. N’enlevez donc pas v2 avant cette migration.
Suivez Migrating, puis Up to date. Si Not ready for migration apparaît, consultez l’infobulle explicative et corrigez le prérequis signalé. Une bascule sans interruption annoncée par Microsoft ne dispense pas d’une fenêtre de changement, notamment pour les correctifs et le nettoyage ultérieur.
Séparer comptes de lecture et comptes d’action
Le compte de lecture de l’annuaire (DSA) et le compte d’action n’ont pas le même rôle. Dès qu’un capteur v3 est présent, Microsoft demande de sélectionner Automatically use the sensor’s local system account dans Manage action accounts. Les actions v3 utilisent LocalSystem, pas un gMSA.
Ne supprimez pas pour autant tous les gMSA. Les capteurs v2 restants peuvent encore dépendre du DSA, et un compte peut être utilisé ailleurs. La validation des identifiants demeure à l’échelle de l’espace MDI. Répertoriez séparément les dépendances de lecture, de réponse et des applications avant le retrait des comptes.
Aligner l’audit automatique avec vos GPO
Activez Automatic Windows auditing configuration sous Settings > Identities > General > Advanced features après revue du changement. Le capteur applique des paramètres locaux et des SACL; une GPO contradictoire peut les écraser. L’audit automatique s’exécute toutes les 24 heures.
Pour une configuration manuelle, partez d’une GPO dédiée aux DC : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration. Suivez la matrice Microsoft, y compris les SACL requises. Une stratégie d’audit seule ne suffit pas pour toutes les catégories.
Comparer la configuration effective, pas seulement les liens GPO
Si le module DefenderForIdentity approuvé est déjà installé, Get-MDIConfiguration permet une consultation locale. Les commandes suivantes ne créent pas de GPO. N’exécutez pas un Set-MDIConfiguration global simplement pour faire disparaître une alerte.
Comparez le résultat après un rafraîchissement normal des stratégies et après le prochain cycle d’audit automatique. Toute dérive récurrente doit être corrigée dans la source de configuration qui fait autorité, plutôt que par une suite de corrections locales.
Import-Module DefenderForIdentity
Get-Command Get-MDIConfiguration -Syntax
Get-MDIConfiguration -Mode LocalMachine -Configuration All
gpresult.exe /scope computer /rRPC et mises à jour : abandonner les anciennes recettes
Depuis v3.0.8, l’audit RPC est activé automatiquement; les anciens guides qui demandent le tag Unified Sensor RPC Audit ne décrivent plus le parcours courant. Le capteur v3 se met à jour avec Windows Update, et l’option Delayed update des capteurs v2 ne s’applique pas.
Intégrez donc MDI aux anneaux de correctifs Windows Server. Recommandation terrain : mettez à jour un DC représentatif, vérifiez les signaux et les services, puis passez au groupe suivant. Évitez de redémarrer simultanément tous les DC d’un site.
Prouver que la télémétrie arrive avec KQL
Validez les chronologies des appareils, utilisateurs et groupes dans Defender, ainsi que les alertes de santé. Faites une modification autorisée sur un groupe de test non privilégié, puis vérifiez sa visibilité. Aucun test de validation ne doit ajouter un utilisateur à un groupe d’administration de production.
Ces requêtes sont des exemples de consultation, pas des règles de détection ni une certification du capteur. Adaptez le FQDN. Les champs de machine décrivent les entités impliquées, pas toujours le capteur collecteur; combinez les résultats avec l’état du portail et un événement de test connu.
- Un résultat vide ne prouve pas une panne : vérifiez l’activité réelle, la fenêtre, les noms observés, les droits et les délais d’ingestion.
- Une ligne récente ne prouve pas que tous les protocoles et tous les DC sont couverts.
- Archivez une preuve horodatée par DC et comparez des périodes d’activité comparables avant et après.
IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where TargetDeviceName =~ "dc01.corp.example"
| summarize Events=count(), LastSeen=max(Timestamp) by ActionType
| order by LastSeen descIdentityQueryEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "dc01.corp.example"
or DestinationDeviceName =~ "dc01.corp.example"
| summarize Events=count(), LastSeen=max(Timestamp) by Protocol, ActionType
| order by LastSeen descTraiter les échecs et décider quand arrêter la vague
En cas d’échec, utilisez MDE Client Analyzer pour vérifier onboarding, service Sense, connectivité et santé. Un navigateur qui rejoint Internet n’est pas une preuve que le service MDE peut communiquer dans son propre contexte. Protégez le rapport de diagnostic, qui peut contenir des données sensibles.
Recommandation : suspendez la vague si un DC perd ses signaux, présente une nouvelle pression mémoire ou montre des erreurs AD. Conservez les heures, versions, messages et résultats de diagnostic pour le soutien Microsoft. Ne désactivez pas MDE et ne désinstallez pas des agents au hasard pour réinitialiser la situation.
| Observation | Prochaine vérification |
|---|---|
| Not ready for migration | Motif exact du portail, OS/build, version v2 et onboarding MDE. |
| Migration failed | Client Analyzer, puis soutien si MDE est sain. |
| Capteur connecté, peu de signaux | Audit effectif, activité attendue, ingestion et droits de consultation. |
| Alertes DSA sur un capteur v3 | Dépendances v2 et validation des comptes à l’échelle de l’espace MDI. |
| Alerte de ressources | Charge du DC, mémoire réservée et événements partiellement surveillés. |
Nettoyer après validation et préparer la reprise
La migration désactive le service v2, mais laisse son logiciel installé. Après acceptation du pilote, planifiez sa désinstallation; un redémarrage peut être nécessaire. Npcap peut être retiré seulement si aucune autre application ne l’utilise.
Ne confondez pas nettoyer v2 et supprimer l’entrée v3 : supprimer un capteur v3 arrête sa surveillance. N’improvisez pas un retour arrière en redémarrant l’ancien service. Documentez avant le changement une procédure de reprise validée pour votre cas avec Microsoft; garder les fichiers v2 ne garantit pas un retour arrière pris en charge.
Un plan réaliste pour une petite équipe TI
Exemple de plan interne, à ajuster : jour 1 pour l’inventaire et les écarts; jour 2 pour un pilote; observation pendant au moins un cycle d’activité et de stratégies; puis vagues par site avec validation individuelle. Ce délai est une recommandation d’exploitation, pas un engagement Microsoft.
Définissez la fin du projet par les preuves : DC admissibles couverts, exceptions v2 documentées, audits cohérents, télémétrie récente, mécanismes de réponse validés dans un cadre contrôlé et responsables des correctifs identifiés. La migration ne remplace pas le durcissement AD.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →