Defender XDR : contrôler les requêtes Entra après l’échéance de migration du 19 octobre
Microsoft a fixé au 19 octobre 2026 le remplacement des tables de connexion Entra AADSignInEventsBeta et AADSpnSignInEventsBeta dans Advanced Hunting, avec migration automatique des requêtes. Les équipes Workplace qui les utilisent pour leurs diagnostics doivent vérifier la continuité des résultats, sans réécrire préventivement leurs détections personnalisées.
- Impact
- utilisateurs d’Advanced Hunting exploitant les connexions Entra ; une licence Microsoft Entra ID P2 est requise pour collecter et consulter les activités de ces tables.
- Action
- exécuter les requêtes de diagnostic habituelles, contrôler les événements récents et les champs utilisés, puis examiner les références conservées dans les scripts externes.
- Statut
- À tester
Une échéance atteinte, pas une nouvelle annonce
Les deux références Microsoft annoncent les correspondances suivantes :
| Ancienne table | Table de remplacement | Événements |
|---|---|---|
AADSignInEventsBeta |
EntraIdSignInEvents |
Connexions utilisateur interactives et non interactives |
AADSpnSignInEventsBeta |
EntraIdSpnSignInEvents |
Connexions des principaux de service et identités managées |
Microsoft prévoit une migration automatique des requêtes le 19 octobre et précise que les détections personnalisées ne nécessitent aucun changement. Ce n’est donc pas une consigne de remplacement manuel généralisé.
La documentation annonce aussi la sortie du statut Preview, mais les titres des nouvelles références portent encore cette mention. Au 20 octobre, les notices consultées décrivent toujours la migration au futur : elles établissent l’échéance, pas son achèvement dans chaque tenant. Ce contrôle est proposé maintenant parce que cette date vient de passer, et non parce que Microsoft aurait publié l’annonce aujourd’hui.
Vérifier les diagnostics réellement utilisés
Pour le Workplace, la table des connexions utilisateur est la plus directement utile : elle documente notamment DeviceName, EntraIdDeviceId, IsManaged, IsCompliant et ConditionalAccessStatus. La seconde table n’est à vérifier que si vos diagnostics incluent les identités applicatives.
Rejouer quelques requêtes représentatives dans Advanced Hunting, avec un compte déjà autorisé à consulter ces données. Choisir une fenêtre contenant des connexions connues et vérifier l’absence d’erreur, la présence d’événements récents et les colonnes nécessaires au diagnostic. Comparer les résultats à ces connexions connues, pas seulement le nombre de lignes avant et après une date donnée.
Examiner les dépendances hors du portail. Rechercher les anciens noms de tables dans les scripts, modèles de requêtes et rapports conservés par l’équipe. La promesse de migration automatique ne démontre pas que ces fichiers locaux ont été réécrits. Pour une requête utilisant AadDeviceId, vérifier aussi la référence à EntraIdDeviceId : l’ancienne documentation désigne explicitement le premier comme identifiant historique en cours de remplacement.
Le résultat attendu est la continuité des diagnostics et des rapprochements avec les appareils. Une absence de données ne prouve pas une panne de migration : vérifier d’abord période, licence et droits. Si une erreur de table ou de colonne persiste, conserver la requête et le message d’erreur pour investigation avec l’équipe sécurité ou le support Microsoft. Ne pas modifier une règle de détection fonctionnelle sur la seule base du renommage.
Ces contrôles sont une recommandation PatchFactory ; aucun tenant ni aucune requête n’a été testé pour cet article.