Connectez Sophos ITDR à Microsoft Entra ID
L’intégration Microsoft Entra ID relie un locataire Entra à Sophos ITDR. Vérifiez d’abord les prérequis et le locataire cible. Configurez ensuite la carte Microsoft Entra ID sous Identity > Settings > Integrations. Avant d’accorder le consentement à l’échelle du locataire, examinez les autorisations demandées, puis validez séparément l’intégration et les données importées.
Prérequis et préparation du changement
Les prérequis suivants doivent être remplis avant la configuration :
- ITDR est activé dans le bon locataire Sophos.
- Le compte Sophos exécutant la configuration a le rôle Sophos Fusion Administrator.
- Le locataire cible a Microsoft Entra ID P1 ou P2. Entra ID Free fournit des API Microsoft, mais limite les données qui peuvent être récupérées et les contrôles de posture disponibles; une intégration utilisant cette édition peut donc afficher Provisioning Failed.
- Un compte Entra qui est autorisé à accorder le consentement d’administration à l’échelle du locataire pour les autorisations réellement demandées est disponible pour l’étape Microsoft. Ne vous fiez pas uniquement au nom du rôle : Microsoft distingue entre les autorisations déléguées et les autorisations d’application Microsoft Graph, entre autres. Utilisez la boîte de dialogue de consentement affichée pour vérifier que le compte a l’autorité requise.
- Le locataire cible, un nom d’intégration unique, la fenêtre de changement et la personne responsable du consentement ont été définis.
Un nom d’intégration utile inclut l’environnement et le locataire, mais sans contenir de secrets, par exemple Production Entra - example.onmicrosoft.com. Vous pouvez choisir n’importe quel nom, mais il doit fournir une identification sans ambiguïté, surtout quand il y a plusieurs locataires.
Consignez au minimum les informations de référence suivantes avant le changement :
- Locataire cible et licence Entra actuelle.
- Autorisations existantes pour l’application d’entreprise Entra touchée, si elle existe déjà.
- Le compte Sophos utilisé et son rôle Fusion.
- Compte Entra destiné au consentement et son rôle pertinent.
- Nom d’intégration prévu et heure de début, y compris le fuseau horaire.
Les mots de passe, jetons et autres secrets ne doivent pas apparaître dans les captures d’écran ou l’enregistrement de changement.
Configuration de l’intégration Entra ID
Lors de la configuration, Sophos utilise le Sophos Master Application dans Azure pour créer l’application requise automatiquement dans le locataire Azure et demander les autorisations nécessaires.
- Dans Sophos Fusion, ouvrez Identity > Settings > Integrations.
- Sur la carte Microsoft Entra ID ou Microsoft EntraID Integration, sélectionnez Set Up.
- Saisissez le nom d’intégration unique préparé dans le champ Nom et sélectionnez Next.
- Décidez si vous souhaitez configurer Response Actions maintenant. Laissez la case décochée si cette autorisation supplémentaire n’a pas été explicitement approuvée; Response Actions peut être configuré séparément plus tard.
- Sélectionnez Authorize. Vous êtes redirigé vers le Microsoft Identity Provider.
- Avant de vous connecter, vérifiez à nouveau que le navigateur utilise le locataire Entra prévu.
- Connectez-vous avec le compte qui est autorisé à accorder le consentement à l’ensemble du locataire.
- Vérifiez l’éditeur de l’application et toutes les autorisations énumérées. N’approuvez que si elles correspondent à l’autorisation.
- Après avoir obtenu le consentement, le processus retourne à Sophos ITDR. View Identity Risk Posture ouvre le tableau de bord de l’aperçu ITDR.
Selon la taille du locataire, les premières données peuvent mettre plusieurs minutes à apparaître. Une redirection réussie seule n’est donc pas une acceptation complète.
Valider l’intégration et les données
Vérifiez séparément l’autorisation, le provisionnement et la qualité des données. Un consentement réussi ne prouve pas à lui seul que l’ingestion des données fonctionne.
1. Autorisation et provisionnement
Sous Identity > Settings, vérifiez le tableau Configured Integrations pour confirmer que le nom préparé est attribué au locataire correspondant et que Provisioning Failed n’est pas affiché. Enregistrez l’état visible et l’heure de la vérification.
Si Provisioning Failed apparaît, la configuration n’est pas validée. Vérifiez la licence et les données source de Microsoft comme décrit ci-dessous, et escaladez toute erreur persistante au lieu de supprimer l’intégration, de créer une seconde intégration, ou d’accorder à nouveau le consentement.
2. Données représentatives
Après le chargement initial, vérifiez au moins les échantillons suivants:
- Plusieurs utilisateurs connus, dont un utilisateur standard et un utilisateur ayant un rôle administratif ou privilégié connu Entra.
- Un groupe connu.
- Une application ou un principal de service connu.
- Un appareil connu.
- Données d’enregistrement MFA pour un utilisateur actif et non supprimé dont les valeurs attendues sont connues.
ITDR active l’indicateur d’administration pour les utilisateurs dont les rôles Entra sont reconnus comme administratifs ou privilégiés. Il s’agit notamment de différents rôles standard et, éventuellement, de Custom Roles comparables. Microsoft pouvant modifier les rôles et leur comportement, utilisez comme référence une attribution de rôle actuelle et visible dans le locataire. Une liste statique de noms ne constitue pas, à elle seule, une preuve suffisante.
Utilisez le rapport Microsoft comme référence pour les données MFA : dans le Microsoft Entra admin center, accédez à Entra ID > Authentication methods > Activity et, sous l’onglet Registration, vérifiez un utilisateur de test actif et non supprimé dont les valeurs attendues sont connues. Ce rapport exige Entra ID P1 ou P2 et un rôle autorisé pour le visualiser. Le rapport comprend MFA Capable, les méthodes enregistrées et Last Updated Time. Les utilisateurs désactivés et récemment supprimés n’apparaissent pas dans les détails de l’enregistrement de l’utilisateur et ne conviennent donc pas à cette comparaison.
3. Comptabiliser les intervalles de collecte
Après l’importation complète des données initiales, Sophos vérifie les changements à différents intervalles pour chaque type de données:
| Type de données | Intervalle documenté |
|---|---|
| User Details | toutes les 10 minutes |
| Service Principals and Apps Details | toutes les 10 minutes |
| Groups | toutes les 10 minutes |
| Devices | toutes les 10 minutes |
| User MFA Configuration | toutes les 15 minutes |
| User Activity (Last Sign On) | toutes les 6 heures |
| Domain Data | toutes les 24 heures |
Entra ID Posture Checks et Dormant Resource Checks s’exécutent toutes les deux heures. Ne traitez pas un changement comme manquant jusqu’à ce que l’intervalle pour le type de données pertinent et, le cas échéant, la vérification de posture subséquente se soient écoulés. Microsoft peut encore mettre à jour ses données sources plus tard; le tableau ne répertorie que les intervalles de collecte de Sophos.
L’intégration est validée lorsque le consentement a été accordé dans le locataire correct, Configured Integrations ne montre aucune erreur de provisionnement, les objets représentatifs du locataire prévu sont visibles, et les données de MFA et d’administration sont plausibles après avoir pris en compte la latence documentée de la source et de la collecte.
Résoudre les erreurs de consentement et applications weren’t found
Si le processus de consentement de l’administrateur indique que les applications n’ont pas été trouvées, la cause documentée est généralement un retard de réplication dans l’infrastructure Microsoft. Dans ce cas, ne créez pas immédiatement une nouvelle intégration.
- Consignez le texte d’erreur, l’heure UTC ou locale avec le fuseau horaire, le locataire cible et le nom de l’intégration.
- Attendez 15 à 30 minutes afin que les principaux de service puissent se répliquer dans l’infrastructure Microsoft.
- Dans Sophos Fusion, ouvrez Identity > Settings.
- Dans Configured Integrations, ouvrez le menu à trois points dans la colonne Actions pour l’intégration touchée et sélectionnez Grant Admin Consent.
- Dans le Microsoft Identity Provider, connectez-vous avec un compte qui est autorisé à accorder le consentement à l’ensemble du locataire.
- Vérifiez à nouveau le locataire, l’application et les autorisations énumérées, et n’approuvez que si elles correspondent.
- Revenez à Identity > Settings et sélectionnez l’icône Refresh sous Actions pour provisionner à nouveau l’intégration.
- Vérifiez à nouveau l’état et les données en fonction des critères d’acceptation.
Ne traitez pas automatiquement une erreur de consentement différente comme une erreur de réplication. Si le message n’est pas applications weren’t found, enregistrez le locataire, les autorisations du compte, et l’étendue affichée, et résolvez-les avant d’essayer de nouveau le consentement.
Traiter Provisioning Failed après un changement de licence
Une intégration avec Entra ID Free peut afficher Provisioning Failed parce que les données de l’API et les vérifications de posture sont limitées. Vérifiez d’abord dans le locataire concerné que P1 ou P2 est réellement actif. La preuve d’achat ou une affectation planifiée ne remplace pas l’activation visible dans le locataire correct.
Après une mise à niveau d’Entra ID Free vers P1 ou P2, les API Microsoft peuvent fournir avec retard des informations telles que le statut d’administrateur ou l’enregistrement MFA. Selon Sophos, ce retard peut atteindre une semaine. Procédez par étapes :
- Confirmez la licence Entra et le locataire cible.
- Sous Entra ID > Authentication methods > Activity > Registration, vérifiez si Microsoft affiche déjà les données MFA attendues pour un utilisateur actif et non supprimé de test avec des valeurs attendues connues.
- Enregistrez Last Updated Time et les valeurs pour cet utilisateur de test.
- Ce n’est qu’une fois que Microsoft fournit des valeurs actuelles, vérifiez à nouveau ITDR après l’intervalle de collecte applicable.
- Si Provisioning Failed persiste malgré une licence active de P1/P2 et cette vérification des données sources, escaladez le cas avec les éléments énumérés ci-dessous. Une erreur de provisionnement générique n’est pas une raison pour accorder à nouveau le consentement à l’échelle du locataire ou sélectionner Refresh.
Avec des configurations plus anciennes de fournisseurs MFA externes tels que Okta ou Duo, Entra ne peut pas stocker le statut MFA au niveau utilisateur. ITDR ne peut alors pas afficher l’état correctement. Sophos peut cependant reconnaître la nouvelle External Authentication Methods dans Entra. Ne modifiez pas une architecture MFA de production simplement pour corriger un affichage ITDR; déterminez d’abord quelle configuration Entra est effectivement en cours d’utilisation.
Autoriser les Response Actions séparément et de manière délibérée
Les Response Actions sont facultatives. Si elles n’ont pas été approuvées lors de la configuration initiale, configurez-les séparément:
- Ouvrez Identity > Settings > Integrations.
- Sur la carte Response Actions, sélectionnez Set Up.
- Sélectionnez une Integration déjà configurée.
- Sélectionnez Authorize, puis connectez-vous au Microsoft Identity Provider.
- Vérifiez à nouveau le locataire, l’éditeur d’applications et chaque autorisation inscrite en fonction des mêmes critères de sécurité.
- Accordez le consentement à l’échelle du locataire seulement avec l’approbation documentée, puis sélectionnez Close.
Après la configuration, les Response Actions sont disponibles dans le menu Actions de l’application Sophos ITDR. Avant d’utiliser un Response Action, son type, son effet et son chemin de récupération doivent être approuvés et documentés séparément.
Limites du retour arrière et des changements
Après une tentative de configuration infructueuse, ne supprimez pas d’intégrations, d’Enterprise Applications ou d’autorisations sur la base d’une simple supposition. La procédure Grant Admin Consent, suivie de Refresh après 15 à 30 minutes, n’est documentée que pour l’erreur exacte applications weren’t found. Pour les autres erreurs, il ne faut en déduire ni procédure générale de suppression ni révocation complète.
Les limites suivantes s’appliquent donc au rétablissement :
- Avant le consentement : L’annulation empêche le consentement à l’échelle du locataire. Enregistrez les écarts affichés et corrigez-les d’abord.
- Après un consentement inattendu : Ne retirez aucune autorisation et ne supprimez pas l’application tant que vous n’avez pas vérifié l’état initial, les utilisations qui en dépendent et les autorisations réellement accordées. Un nouveau consentement à l’échelle du locataire pouvant modifier les autorisations déjà accordées à la même application, répéter l’opération ne constitue pas un retour arrière sûr.
- Pour les Response Actions facultatives: Ne pas les autoriser si la portée ou le chemin de récupération n’est pas clair. L’autorisation déjà accordée n’est pas supprimée dans ce runbook.
- Pour une erreur de provisionnement générique : Vérifiez la licence P1/P2 et les données source de Microsoft, et escaladez toute erreur persistante. Grant Admin Consent et Refresh restent réservés exclusivement à la procédure de récupération décrite ci-dessus pour applications weren’t found. Ne créez pas une seconde intégration avec le même nom qu’un test.
Si une révocation ou une suppression complète est nécessaire, traitez-la comme un changement approuvé séparé avec les équipes responsables de Microsoft Entra et Sophos. Le nom de l’intégration, l’état visible et les permissions enregistrées avant la configuration fournissent la base de référence.
Quand procéder à une escalade et quels éléments fournir
Procédez à une escalade dans l’un des cas suivants :
- applications weren’t found persiste après 30 minutes, un autre Grant Admin Consent et Refresh.
- Le consentement échoue avec une erreur différente et inexpliquée.
- Provisioning Failed persiste malgré une licence P1/P2 confirmée et la vérification des données source de Microsoft.
- Microsoft affiche les données MFA actuelles, mais ITDR ne les ingère toujours pas après l’intervalle de 15 minutes.
- Les utilisateurs représentatifs, les groupes, les appareils, les applications ou les principaux de service sont absents après l’intervalle de collecte applicable.
- Les données d’administration restent incorrectes même si Entra montre l’attribution de rôle actuelle et qu’un éventuel retard après la mise à niveau de la licence a été pris en compte.
Rassemblez les éléments suivants pour l’escalade vers Sophos Support ou l’équipe responsable Entra:
- Locataire de Sophos et locataire d’Entra, nom de l’intégration et environnement affecté.
- Licence Entra active et l’heure de toute mise à niveau.
- Texte exact de l’erreur et captures d’écran de Configured Integrations, avec l’heure et le fuseau horaire.
- Heure et résultat de Authorize, puis, si l’erreur exacte applications weren’t found s’est produite, de Grant Admin Consent et Refresh.
- Les noms de rôles utilisés pour les comptes Sophos et Entra, mais pas d’identifiants.
- Pour les écarts MFA, l’utilisateur de test touché, les valeurs visibles et Last Updated Time de Authentication methods > Activity > Registration.
- Pour les objets manquants, le type d’objet, un exemple anonymisé et l’intervalle de collecte déjà écoulé.
- Une description de chaque consentement, licence ou changement d’intégration effectué depuis l’erreur.
Les boîtes de dialogue d’autorisation peuvent être documentées pour le support, mais ne doivent pas contenir de mots de passe, jetons ou autres secrets. Jusqu’à ce que le problème soit résolu, suspendez les suppressions, les modifications manuelles d’autorisations et les nouvelles tentatives de consentement en dehors de la procédure de récupération documentée.