Microsoft Defender for Endpoint : onboarding Windows avec Intune

L’essentiel

La connexion service-to-service permet à Intune de recevoir le package d’onboarding et, selon les options choisies, d’exploiter le risque Defender dans la conformité. Le connecteur doit être validé avant de créer la policy EDR.

Pour Windows géré par Intune, le package automatique issu du connecteur est la méthode recommandée. Une policy custom ciblée sur un groupe device pilote offre plus de contrôle qu’un déploiement immédiat sur All devices.

L’appareil doit apparaître dans le device inventory Defender, remonter un sensor health cohérent et recevoir les autres policies de protection prévues. L’offboarding arrête la télémétrie future mais ne supprime pas immédiatement les données déjà conservées dans le service.

La connexion service-to-service permet à Intune de recevoir le package d’onboarding et, selon les options choisies, d’exploiter le risque Defender dans la conformité. Le connecteur doit être validé avant de créer la policy EDR.

Pourquoi cette technologie existe

Le connecteur se configure dans Endpoint security > Microsoft Defender for Endpoint. Son état doit être Enabled et les choix de conformité, app protection ou security settings management doivent être documentés séparément.

L’onboarding est une action par appareil. La policy Endpoint detection and response peut utiliser Auto from connector lorsque l’intégration est opérationnelle, ou un blob signé dans les scénarios explicitement prévus.

Je privilégie une affectation device afin que l’onboarding ne dépende pas d’une nouvelle session utilisateur. Le groupe pilote exclut les machines déjà gérées par une autre autorité EDR jusqu’à la validation de coexistence.

Onboarding Defender for Endpoint avec Intune s’appuie sur la chaîne Connector → EDR policy → Sensor → Portal. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont licence Defender for Endpoint, rôles Intune et Defender minimaux, connecteur service-to-service, endpoints réseau autorisés. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Policy réussie, device absent, Connecteur non Enabled et Conflit EDR. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Connector ouvre la séquence: Relie Intune et Defender for Endpoint. EDR policy prend ensuite le relais: Livre l’onboarding au poste. Le traitement se poursuit avec Sensor, où S’exécute et communique avec le service. Enfin, Portal ferme la boucle: Inventory, alertes et risque device. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Policy réussie, device absent » conduit d’abord à vérifier SENSE log et connectivité, car la cause possible est Sensor non communicant. Pour « Connecteur non Enabled », la preuve utile devient État du connecteur. Les cas « Conflit EDR » et « Risque jamais remonté » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Onboarding Defender for Endpoint avec Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licence Defender for Endpoint, rôles Intune et Defender minimaux, connecteur service-to-service, endpoints réseau autorisés doivent être réunies en même temps. La validation porte ensuite sur Activer et vérifier le connecteur, Créer une policy EDR pilote, Contrôler service et événements locaux et Vérifier le device inventory Defender. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le connecteur se configure dans Endpoint security > Microsoft Defender for Endpoint. Son état doit être Enabled et les choix de conformité, app protection ou security settings management doivent être documentés séparément.

L’onboarding est une action par appareil. La policy Endpoint detection and response peut utiliser Auto from connector lorsque l’intégration est opérationnelle, ou un blob signé dans les scénarios explicitement prévus.

Je privilégie une affectation device afin que l’onboarding ne dépende pas d’une nouvelle session utilisateur. Le groupe pilote exclut les machines déjà gérées par une autre autorité EDR jusqu’à la validation de coexistence.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licence Defender for Endpoint, rôles Intune et Defender minimaux, connecteur service-to-service, endpoints réseau autorisés, groupe device pilote. Ces conditions permettent de distinguer une limite de Onboarding Defender for Endpoint avec Intune d’un scénario simplement non éligible.

• licence Defender for Endpoint
• rôles Intune et Defender minimaux
• connecteur service-to-service
• endpoints réseau autorisés
• groupe device pilote
• inventaire des antivirus/EDR existants
• package et procédure d’offboarding

Cycle de fonctionnement, étape par étape

Le cycle de Onboarding Defender for Endpoint avec Intune traverse Connector → EDR policy → Sensor → Portal. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Onboarding Defender for Endpoint avec Intune, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Onboarding Defender for Endpoint avec Intune

Le connecteur se configure dans Endpoint security > Microsoft Defender for Endpoint. Son état doit être Enabled et les choix de conformité, app protection ou security settings management doivent être documentés séparément.

L’onboarding est une action par appareil. La policy Endpoint detection and response peut utiliser Auto from connector lorsque l’intégration est opérationnelle, ou un blob signé dans les scénarios explicitement prévus.

Je privilégie une affectation device afin que l’onboarding ne dépende pas d’une nouvelle session utilisateur. Le groupe pilote exclut les machines déjà gérées par une autre autorité EDR jusqu’à la validation de coexistence.

• licence Defender for Endpoint
• rôles Intune et Defender minimaux
• connecteur service-to-service
• endpoints réseau autorisés

Traitement, exploitation et cas limites de Onboarding Defender for Endpoint avec Intune

Sense est le service du sensor EDR sur Windows concernés. Son démarrage, l’état de communication et les événements SENSE Operational complètent le statut Intune. La présence du service seul ne prouve pas la visibilité du portail.

L’onboarding ne remplace pas les policies Defender Antivirus, cloud-delivered protection, ASR, firewall, tamper protection ou exclusions. Chaque famille conserve un propriétaire pour éviter des valeurs concurrentes.

Dans une coexistence avec un antivirus tiers, Microsoft Defender Antivirus peut passer en mode passif selon licences et configuration. Les exclusions mutuelles, la performance et la responsabilité de remédiation doivent être testées.

• Exécuter le test de détection officiel
• Valider risque et conformité sans blocage
• Étendre par anneaux

Lire les états propres à Onboarding Defender for Endpoint avec Intune

Le risk signal peut alimenter une compliance policy puis Conditional Access. Je stabilise d’abord la couverture et les délais de remontée, définis une période de grâce et protège les comptes d’urgence avant tout blocage.

L’offboarding utilise une policy et un package limité dans le temps selon le workflow. Il ne désinstalle pas Windows Defender et ne supprime pas immédiatement l’historique cloud; je vérifie le comportement réglementaire et la rétention.

La validation inclut un appareil dans le device inventory, l’EDR onboarding status, le sensor health, une détection de test officielle, la télémétrie réseau et l’absence de conflit de policies.

• Policy réussie, device absent — SENSE log et connectivité
• Connecteur non Enabled — État du connecteur
• Conflit EDR — Per-setting et ConfigMgr
• Risque jamais remonté — Connecteur et timestamps

Pilote et suivi opérationnel de Onboarding Defender for Endpoint avec Intune

Le pilote couvre le périmètre Microsoft Defender for Endpoint, Intune, EDR, Onboarding et contrôle Activer et vérifier le connecteur. Créer une policy EDR pilote. Contrôler service et événements locaux. Les résultats sont segmentés selon les populations réellement concernées par Onboarding Defender for Endpoint avec Intune.

Les cas d’échec « Policy réussie, device absent », « Connecteur non Enabled », « Conflit EDR » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne pas cibler All devices au premier essai, onboarding EDR ne configure pas tout Defender, offboarding ne purge pas l’historique, protéger les comptes break-glass. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Activer et vérifier le connecteur. Créer une policy EDR pilote. Contrôler service et événements locaux. Vérifier le device inventory Defender. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Onboarding Defender for Endpoint avec Intune, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-Service -Name Sense,WinDefend | Select-Object Name,Status,StartType
  Get-MpComputerStatus | Select-Object AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled
  Get-WinEvent -LogName 'Microsoft-Windows-SENSE/Operational' -MaxEvents 80 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte MDE impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Onboarding Defender for Endpoint avec Intune relie Connector, EDR policy, Sensor, Portal. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Activer et vérifier le connecteur. Créer une policy EDR pilote. Contrôler service et événements locaux. Vérifier le device inventory Defender. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Sensor non communicant », « Autorisation ou délai », « Plusieurs authorities » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Activer et vérifier le connecteur.
• Créer une policy EDR pilote.
• Contrôler service et événements locaux.
• Vérifier le device inventory Defender.
• Exécuter le test de détection officiel
• Valider risque et conformité sans blocage
• Étendre par anneaux

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Activer et vérifier le connecteur, Créer une policy EDR pilote, Contrôler service et événements locaux et Vérifier le device inventory Defender. Ces contrôles relient la configuration du service au résultat réellement observé.

• Activer et vérifier le connecteur.
• Créer une policy EDR pilote.
• Contrôler service et événements locaux.
• Vérifier le device inventory Defender.
• Exécuter le test de détection officiel
• Valider risque et conformité sans blocage
• Étendre par anneaux

Limites, modes de panne et lecture des erreurs

Les écarts connus de Onboarding Defender for Endpoint avec Intune incluent Policy réussie, device absent, Connecteur non Enabled, Conflit EDR, Risque jamais remonté. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Onboarding Defender for Endpoint avec Intune commence sur le périmètre Microsoft Defender for Endpoint, Intune, EDR, Onboarding, Modern Management — Connector, EDR policy, Sensor, Portal, licence Defender for Endpoint, rôles Intune et Defender minimaux, connecteur service-to-service. Les limites et actions de réversibilité ci-dessous cadrent la progression.