Sophos ITDR mit Microsoft Entra ID verbinden
Die Microsoft-Entra-ID-Integration verbindet einen Entra-Tenant mit Sophos ITDR. Prüfen Sie zuerst die Voraussetzungen und den Ziel-Tenant. Richten Sie danach unter Identity > Settings > Integrations die Karte Microsoft Entra ID ein. Kontrollieren Sie vor dem tenant-weiten Consent die angeforderten Berechtigungen und validieren Sie anschliessend die Integration und die importierten Daten getrennt.
Voraussetzungen und Change-Vorbereitung
Vor dem Setup müssen folgende Voraussetzungen erfüllt sein:
- ITDR ist im richtigen Sophos-Tenant aktiviert.
- Das ausführende Sophos-Konto hat die Rolle Sophos Fusion Administrator.
- Im Ziel-Tenant ist Microsoft Entra ID P1 oder P2 vorhanden. Entra ID Free stellt zwar Microsoft-APIs bereit, begrenzt aber abrufbare Daten und mögliche Posture Checks; eine solche Integration kann deshalb Provisioning Failed zeigen.
- Für den Microsoft-Schritt steht ein Entra-Konto zur Verfügung, das tenant-weiten Admin Consent für die tatsächlich angeforderten Berechtigungen erteilen darf. Verlassen Sie sich dabei nicht nur auf den Rollennamen: Microsoft unterscheidet unter anderem delegierte Berechtigungen und Microsoft-Graph-Anwendungsberechtigungen. Prüfen Sie anhand des angezeigten Consent-Dialogs, ob das Konto die erforderliche Berechtigung besitzt.
- Der Ziel-Tenant, ein eindeutiger Integrationsname, das Change-Fenster und die für den Consent verantwortliche Person sind festgelegt.
Ein sinnvoller Integrationsname enthält die Umgebung und den Tenant, aber keine Secrets, zum Beispiel Production Entra - example.onmicrosoft.com. Der Name ist frei wählbar; er muss vor allem bei mehreren Tenants eine eindeutige Zuordnung erlauben.
Vor der Änderung werden mindestens folgende Ausgangswerte dokumentiert:
- Ziel-Tenant und vorhandene Entra-Lizenz,
- bestehende Berechtigungen der betroffenen Entra-Unternehmensanwendung, soweit sie bereits vorhanden ist,
- verwendetes Sophos-Konto und dessen Fusion-Rolle,
- für den Consent vorgesehenes Entra-Konto und dessen relevante Rolle,
- geplanter Integrationsname sowie Startzeit mit Zeitzone.
Kennwörter, Tokens und andere Secrets gehören weder in Screenshots noch in das Change-Protokoll.
Entra-ID-Integration einrichten
Sophos verwendet beim Setup die Sophos Master Application in Azure, um die benötigte Anwendung im Azure-Tenant automatisch zu erstellen und die erforderlichen Berechtigungen anzufordern.
- In Sophos Fusion Identity > Settings > Integrations öffnen.
- Auf der Karte Microsoft Entra ID beziehungsweise Microsoft EntraID Integration auf Set Up klicken.
- Im Namensfeld den vorbereiteten eindeutigen Integrationsnamen eintragen und Next wählen.
- Entscheiden, ob Response Actions bereits eingerichtet werden sollen. Die Checkbox bleibt ausgeschaltet, wenn diese zusätzliche Autorisierung nicht ausdrücklich freigegeben ist; Response Actions können später separat konfiguriert werden.
- Authorize wählen. Damit wird zum Microsoft Identity Provider gewechselt.
- Vor der Anmeldung erneut kontrollieren, dass der Browser im vorgesehenen Entra-Tenant arbeitet.
- Mit dem Konto anmelden, das tenant-weiten Consent erteilen darf.
- Anwendungsherausgeber und sämtliche aufgelisteten Berechtigungen prüfen. Nur bei Übereinstimmung mit der Freigabe zustimmen.
- Nach erfolgreichem Consent kehrt der Ablauf zu Sophos ITDR zurück. View Identity Risk Posture öffnet das ITDR Overview Dashboard.
Je nach Grösse des Tenants kann es einige Minuten dauern, bis erste Daten erscheinen. Ein erfolgreicher Redirect allein ist daher noch keine vollständige Abnahme.
Integration und Daten abnehmen
Prüfen Sie Autorisierung, Provisioning und Datenqualität getrennt. Ein erfolgreicher Consent allein belegt noch nicht, dass die Datenübernahme funktioniert.
1. Autorisierung und Provisioning
Unter Identity > Settings in der Tabelle Configured Integrations kontrollieren, dass der vorbereitete Name dem richtigen Entra-Tenant zugeordnet ist und kein Status Provisioning Failed angezeigt wird. Halten Sie den sichtbaren Status und den Prüfzeitpunkt fest.
Erscheint Provisioning Failed, gilt die Einrichtung nicht als abgenommen. Prüfen Sie die Lizenz und die Microsoft-Quelldaten wie unten beschrieben und eskalieren Sie den weiterhin bestehenden Fehler, statt die Integration zu löschen, eine zweite Integration anzulegen oder den Consent erneut zu erteilen.
2. Repräsentative Daten
Nach dem initialen Laden werden mindestens folgende Stichproben geprüft:
- mehrere bekannte Benutzer, darunter ein normaler Benutzer und ein Benutzer mit einer bekannten administrativen oder privilegierten Entra-Rolle,
- eine bekannte Gruppe,
- eine bekannte Anwendung oder ein Service Principal,
- ein bekanntes Gerät,
- MFA-Registrierungsdaten eines aktiven, nicht gelöschten Testbenutzers mit bekannten Sollwerten.
ITDR setzt den Admin-Flag für Benutzer, deren Entra-Rollen als administrativ oder privilegiert erkannt werden. Dazu gehören verschiedene Standardrollen und gegebenenfalls vergleichbare Custom Roles. Da Microsoft Rollen und Verhalten ändern kann, verwenden Sie eine aktuelle, im Tenant sichtbare Rollenzuweisung als Vergleich. Eine statische Namensliste allein ist kein ausreichender Beleg.
Für MFA-Daten dient der Microsoft-Bericht als Referenz: Im Microsoft Entra admin center zu Entra ID > Authentication methods > Activity wechseln und auf dem Tab Registration einen aktiven, nicht gelöschten Testbenutzer mit bekannten Sollwerten prüfen. Für diesen Bericht sind Entra ID P1 oder P2 sowie eine dafür berechtigte Rolle erforderlich. Der Bericht zeigt unter anderem MFA Capable, registrierte Methoden und Last Updated Time. Deaktivierte und kürzlich gelöschte Benutzer erscheinen nicht in den Benutzerregistrierungsdetails und eignen sich daher nicht für diesen Vergleich.
3. Erfassungstakte berücksichtigen
Nach dem vollständigen initialen Datenimport prüft Sophos Änderungen je Datentyp in unterschiedlichen Intervallen:
| Datentyp | dokumentierter Takt |
|---|---|
| User Details | alle 10 Minuten |
| Service Principals and Apps Details | alle 10 Minuten |
| Groups | alle 10 Minuten |
| Devices | alle 10 Minuten |
| User MFA Configuration | alle 15 Minuten |
| User Activity (Last Sign On) | alle 6 Stunden |
| Domain Data | alle 24 Stunden |
Entra ID Posture Checks und Dormant Resource Checks laufen alle zwei Stunden. Werten Sie eine Änderung erst dann als ausgeblieben, wenn der Takt des betreffenden Datentyps und gegebenenfalls der anschliessende Posture Check verstrichen sind. Microsoft kann seine Quelldaten trotzdem später aktualisieren; die Tabelle nennt nur die Erfassungstakte von Sophos.
Die Integration ist abgenommen, wenn der Consent im richtigen Tenant abgeschlossen wurde, Configured Integrations keinen Provisioning-Fehler zeigt, repräsentative Objekte des vorgesehenen Tenants sichtbar sind und MFA- sowie Admin-Daten unter Berücksichtigung der dokumentierten Quell- und Erfassungslatenzen plausibel sind.
Consent-Fehler und applications weren’t found beheben
Meldet der Admin-Consent-Ablauf, dass Anwendungen nicht gefunden wurden, ist die dokumentierte Ursache typischerweise eine Replikationsverzögerung in der Microsoft-Infrastruktur. In diesem Fall wird nicht sofort eine neue Integration erstellt.
- Fehlertext, UTC- beziehungsweise Lokalzeit mit Zeitzone, Ziel-Tenant und Integrationsname sichern.
- 15 bis 30 Minuten warten, damit die Service Principals innerhalb der Microsoft-Infrastruktur repliziert werden können.
- In Sophos Fusion Identity > Settings öffnen.
- In Configured Integrations in der Spalte Actions das Drei-Punkte-Menü der betroffenen Integration öffnen und Grant Admin Consent wählen.
- Beim Microsoft Identity Provider mit einem Konto anmelden, das tenant-weiten Consent erteilen darf.
- Tenant, Anwendung und aufgelistete Berechtigungen erneut prüfen und nur bei Übereinstimmung genehmigen.
- Zu Identity > Settings zurückkehren und in Actions das Refresh-Symbol wählen, um die Integration erneut zu provisionieren.
- Status und Daten anhand der Abnahmekriterien erneut prüfen.
Ein anderer Consent-Fehler wird nicht automatisch als Replikationsfehler behandelt. Ist der Meldungstext nicht applications weren’t found, werden Tenant, Kontoberechtigung und angezeigter Berechtigungsumfang dokumentiert und vor einem erneuten Consent geklärt.
Provisioning Failed nach Lizenzwechsel behandeln
Eine Integration mit Entra ID Free kann wegen eingeschränkter API-Daten und Posture Checks Provisioning Failed anzeigen. Prüfen Sie zuerst im betroffenen Tenant, ob P1 oder P2 wirklich aktiv ist. Ein Kaufbeleg oder eine geplante Zuweisung ersetzt die sichtbare Aktivierung im richtigen Tenant nicht.
Nach einem Upgrade von Entra ID Free auf P1 oder P2 können Microsoft-APIs Informationen wie Admin-Status oder MFA-Registrierung verzögert liefern. Laut Sophos sind Verzögerungen von bis zu einer Woche möglich. Gehen Sie deshalb gestuft vor:
- Entra-Lizenz und Ziel-Tenant bestätigen.
- Unter Entra ID > Authentication methods > Activity > Registration prüfen, ob Microsoft die erwarteten MFA-Daten eines aktiven, nicht gelöschten Testbenutzers mit bekannten Sollwerten bereits zeigt.
- Last Updated Time und die Werte dieses Testbenutzers erfassen.
- Erst wenn Microsoft aktuelle Werte liefert, ITDR nach dem passenden Erfassungstakt erneut prüfen.
- Bleibt Provisioning Failed trotz aktiver P1-/P2-Lizenz und dieser Quelldatenprüfung bestehen, mit den unten genannten Belegen eskalieren. Ein generischer Provisioning-Fehler ist kein Grund, den tenant-weiten Consent erneut zu erteilen oder Refresh auszuführen.
Bei älteren Konfigurationen externer MFA-Anbieter wie Okta oder Duo kann Entra den MFA-Status nicht auf Benutzerebene speichern. Dann kann ITDR den Status nicht korrekt zurückmelden. Die neuen External Authentication Methods in Entra können Sophos dagegen erkennen. Ändern Sie eine produktive MFA-Architektur nicht nur, um eine ITDR-Anzeige zu korrigieren; zuerst muss geklärt werden, welche Entra-Konfiguration tatsächlich eingesetzt wird.
Response Actions bewusst getrennt autorisieren
Response Actions sind optional. Wenn sie beim ersten Setup nicht freigegeben wurden, erfolgt ihre Einrichtung separat:
- Identity > Settings > Integrations öffnen.
- Auf der Karte Response Actions Set Up wählen.
- Eine bereits konfigurierte Integration auswählen.
- Authorize wählen und beim Microsoft Identity Provider anmelden.
- Tenant, Anwendungsherausgeber und alle aufgelisteten Berechtigungen erneut nach denselben Sicherheitskriterien prüfen.
- Nur mit dokumentierter Freigabe tenant-weiten Consent erteilen und danach Close wählen.
Nach der Konfiguration stehen Response Actions im Menü Actions innerhalb der Sophos-ITDR-Anwendung zur Verfügung. Bevor Sie eine Response Action verwenden, müssen deren Art, Wirkung und Rückweg separat freigegeben und dokumentiert werden.
Rollback- und Änderungsgrenzen
Löschen Sie nach einem fehlgeschlagenen Setup-Versuch keine Integrationen, Enterprise Applications oder Berechtigungen auf Verdacht. Nur beim exakten Fehler applications weren’t found ist nach 15 bis 30 Minuten der Ablauf Grant Admin Consent und anschliessend Refresh dokumentiert. Für andere Fehler lässt sich daraus weder ein pauschaler Löschablauf noch ein vollständiger Widerruf ableiten.
Für den Rückweg gelten deshalb folgende Grenzen:
- Vor dem Consent: Mit Abbrechen bleibt der tenant-weite Consent aus. Die angezeigten Abweichungen werden dokumentiert und zuerst geklärt.
- Nach einem unerwarteten Consent: Entfernen Sie keine einzelne Berechtigung und löschen Sie die Anwendung nicht, bevor Sie den Ausgangszustand, die abhängige Verwendung und die tatsächlich erteilten Berechtigungen geprüft haben. Da ein erneuter tenant-weiter Consent bereits erteilte Berechtigungen derselben Anwendung beeinflussen kann, ist auch eine Wiederholung kein sicherer Rollback.
- Bei optionalen Response Actions: Nicht autorisieren, wenn Umfang oder Rückweg ungeklärt sind. Eine bereits erteilte Autorisierung wird nicht innerhalb dieses Runbooks entfernt.
- Bei einem generischen Provisioning-Fehler: P1-/P2-Lizenz und Microsoft-Quelldaten prüfen und einen weiterhin bestehenden Fehler eskalieren. Grant Admin Consent und Refresh bleiben ausschliesslich dem oben beschriebenen Recovery-Ablauf für applications weren’t found vorbehalten. Keine zweite gleichnamige Integration als Test anlegen.
Ist ein Widerruf oder die vollständige Entfernung erforderlich, wird daraus ein eigener, freigegebener Change mit den Verantwortlichen für Microsoft Entra und Sophos. Der Integrationsname, sichtbare Status und die vor dem Setup gesicherten Berechtigungen bilden dabei die Ausgangsbasis.
Wann und mit welchen Belegen eskalieren
Eskalieren Sie, wenn einer der folgenden Punkte zutrifft:
- applications weren’t found bleibt nach 30 Minuten, erneutem Grant Admin Consent und Refresh bestehen,
- der Consent schlägt mit einem anderen, nicht erklärten Fehler fehl,
- Provisioning Failed bleibt trotz bestätigter P1-/P2-Lizenz und Prüfung der Microsoft-Quelldaten bestehen,
- Microsoft zeigt aktuelle MFA-Daten, ITDR übernimmt sie aber auch nach dem 15-Minuten-Takt nicht,
- repräsentative Benutzer, Gruppen, Geräte, Apps oder Service Principals fehlen nach dem jeweiligen Erfassungstakt,
- Admin-Daten bleiben falsch, obwohl Entra die aktuelle Rollenzuweisung zeigt und eine mögliche Verzögerung nach dem Lizenzupgrade berücksichtigt wurde.
Für die Übergabe an Sophos Support beziehungsweise das zuständige Entra-Team sammeln Sie:
- Sophos-Tenant und Entra-Tenant, Integrationsname und betroffene Umgebung,
- aktive Entra-Lizenz und Zeitpunkt eines allfälligen Upgrades,
- exakten Fehlertext und Screenshots von Configured Integrations, jeweils mit Zeit und Zeitzone,
- Zeitpunkt und Resultat von Authorize sowie, falls der exakte Fehler applications weren’t found vorlag, von Grant Admin Consent und Refresh,
- verwendete Rollenbezeichnungen des Sophos- und Entra-Kontos, jedoch keine Anmeldedaten,
- bei MFA-Abweichungen den betroffenen Testbenutzer, sichtbare Werte und Last Updated Time aus Authentication methods > Activity > Registration,
- bei fehlenden Objekten den Objekttyp, ein anonymisiertes Beispiel und den bereits abgewarteten Erfassungstakt,
- eine Beschreibung aller seit dem Fehler vorgenommenen Consent-, Lizenz- oder Integrationsänderungen.
Berechtigungsdialoge dürfen für den Support dokumentiert werden, enthalten aber keine Kennwörter, Tokens oder andere Secrets. Bis zur Klärung bleiben Löschung, manuelle Änderungen an Berechtigungen und wiederholte Consent-Versuche ausserhalb des dokumentierten Recovery-Ablaufs ausgesetzt.