Microsoft Defender for Identity : ce que les capteurs détectent vraiment, et ce qu'ils ne remplacent pas
Microsoft Defender for Identity observe ce qui se passe au cœur de l'annuaire : authentifications, requêtes, réplications, modifications sensibles. Bien déployé, il détecte des attaques qui passent inaperçues ailleurs. Mal déployé, il laisse des angles morts et noie les équipes sous des alertes. Tour d'horizon par des auditeurs qui le rencontrent sur le terrain.
Où installer les capteurs
Defender for Identity repose sur des capteurs installés sur les serveurs qui détiennent l'identité. Les contrôleurs de domaine sont la priorité : tous les contrôleurs de domaine, y compris les contrôleurs en lecture seule et ceux des sites distants. Un seul DC non couvert suffit à créer un angle mort, car un attaquant qui cible ce serveur échappe à l'analyse du trafic.
La couverture doit ensuite s'étendre aux autres composants de niveau 0 :
- AD FS, pour surveiller les authentifications fédérées et les accès suspects aux serveurs de fédération ;
- AD CS, pour détecter les demandes de certificats anormales et les modifications de l'autorité de certification ;
- Microsoft Entra Connect, dont le compte de synchronisation et la base locale sont des cibles de choix.
Microsoft propose deux familles de capteurs : le capteur classique, installé séparément, et un capteur plus récent intégré à Microsoft Defender for Endpoint et activable depuis le portail Defender sur les versions de Windows Server prises en charge. Les prérequis, les versions supportées et les fonctionnalités couvertes par chaque type évoluent : vérifiez la documentation Microsoft à jour avant de choisir.
Les prérequis souvent négligés
Un capteur installé ne signifie pas un capteur efficace. Plusieurs détections dépendent de journaux Windows que la stratégie d'audit par défaut ne génère pas. Il faut configurer la stratégie d'audit avancée sur les contrôleurs de domaine, activer l'audit NTLM et, pour certaines détections, poser des listes de contrôle d'accès système (SACL) sur des objets précis. Microsoft documente ces paramètres et le portail signale les écarts via des alertes de santé.
Le compte de service d'annuaire utilisé par le produit pour interroger AD doit être un compte de service administré de groupe (gMSA) de préférence, avec des droits de lecture uniquement. Enfin, les capteurs doivent joindre le service cloud, en général à travers un proxy ; c'est l'un des rares flux sortants légitimes d'un contrôleur de domaine.
Ce que le produit détecte
Les détections suivent les étapes d'une attaque sur l'annuaire :
| Phase | Exemples de comportements détectés |
|---|---|
| Reconnaissance | énumération de comptes, requêtes LDAP de reconnaissance, énumération des sessions SMB |
| Accès aux identifiants | force brute, pulvérisation de mots de passe, demandes de tickets suspectes évoquant le Kerberoasting ou l'AS-REP roasting |
| Mouvement latéral | pass-the-hash, pass-the-ticket, overpass-the-hash |
| Domination du domaine | DCSync, DCShadow, usage de tickets forgés, modification de groupes sensibles |
Les alertes remontent dans le portail Microsoft Defender XDR, où elles sont corrélées avec celles des terminaux, de la messagerie et des applications cloud pour former des incidents. C'est cette corrélation qui fait la valeur de l'outil : une alerte isolée sur un DC prend un autre sens lorsqu'elle suit un hameçonnage réussi sur un poste.
Les évaluations de posture
Au-delà de la détection, Defender for Identity publie des évaluations de posture de sécurité des identités, intégrées au Secure Score et aux outils de gestion de l'exposition. Elles signalent par exemple des délégations Kerberos non contraintes, des protocoles hérités encore utilisés, des identifiants exposés en clair, le service Spouleur d'impression actif sur des contrôleurs de domaine ou des modèles de certificats dangereux. Ces recommandations constituent une excellente liste de travail, à condition que quelqu'un soit chargé de la traiter.
Régler sans aveugler
Les faux positifs viennent souvent d'outils légitimes : scanners de vulnérabilités, solutions de gestion des identités, outils de supervision qui interrogent massivement l'annuaire. Les exclusions doivent être ciblées (une machine ou un compte précis, pour une détection précise), documentées et revues. Une exclusion globale d'un serveur d'administration revient à offrir une cachette à l'attaquant qui le compromettrait.
Deux réglages apportent beaucoup : déclarer des comptes « pots de miel » (honeytokens), dont toute utilisation déclenche une alerte, et marquer comme sensibles les comptes et groupes à forte valeur qui ne le sont pas par défaut. Les actions de réponse, comme la désactivation d'un compte, nécessitent un compte d'action dédié dont les droits doivent être maîtrisés.
Détecter n'est pas protéger. Defender for Identity ne remplace ni le durcissement de l'annuaire, ni le modèle de tiering, ni les sauvegardes hors ligne, ni la conservation longue des journaux dans un SIEM. Il signale une attaque en cours ; il ne supprime pas les chemins qui la rendent possible.
Ce qu'un audit vérifie
- la présence d'un capteur sain sur chaque contrôleur de domaine et sur les serveurs AD FS, AD CS et Entra Connect ;
- la configuration des journaux et SACL requis, et l'absence d'alertes de santé ouvertes ;
- la nature et la portée des exclusions, ainsi que leur justification ;
- le traitement effectif des évaluations de posture et le délai de prise en charge des alertes.