Sophos Email: Report to Sophos Outlook-Add-in bereitstellen und reparieren

Das Report to Sophos Outlook-Add-in wird mit Sophos Email und Sophos Phish Threat verwendet. Dieses Runbook bleibt dem Sophos-Email-Meldeweg zugeordnet und behandelt zusätzlich den gemeinsamen Zugriffsfehler des Add-ins. Phish-Threat-Kampagnenlogik und deren Auswertung gehören nicht zu Sophos Email.

Es ist auch nicht das Sophos-Add-in für Email-Verschlüsselung: Jenes stellt beim Verfassen die Aktion Encrypt bereit und arbeitet mit einer Secure Message policy. Bereitstellung und Prüfung dieses separaten Produkts beschreibt das Outlook-Add-in für Verschlüsselung. Beim hier behandelten Add-in meldet der Benutzer dagegen eine vorhandene Nachricht mit Report to Sophos.

Meldewege von Sophos Email und Phish Threat abgrenzen

Bei einer gewöhnlichen verdächtigen oder unerwünschten Nachricht sendet das Add-in die Meldung an die für die Organisation konfigurierten Meldeziele; abhängig von der Konfiguration geht auch eine Kopie zur Analyse an SophosLabs. Eine Phish-Threat-Lizenz ist für diesen Spam-Meldeweg nicht erforderlich.

Erkennt das Add-in dagegen eine simulierte Phish-Threat-Kampagnennachricht, wird eine gemeldete Nachricht in den Kampagnenergebnissen als Reported Email erfasst und der Benutzer erhält in Outlook sofort positives Feedback. Für Installation, Konfiguration der Meldeziele, Upgrade, Endbenutzerablauf und Prüfung der Kampagnenergebnisse verwendet man das Phish-Threat-Runbook zum Sophos Outlook Add-in. Scheitert bei einem der beiden Meldewege bereits Report to Sophos mit dem unten genannten Zugriffsfehler, gilt die gemeinsame Fehlerdiagnose in diesem Runbook.

Voraussetzungen und sicheren Test festlegen

Erforderlich sind ein gültiges Sophos-Email- oder Sophos-Phish-Threat-Abonnement, Sophos-Central-Zugriff zum Prüfen von Lizenz und Add-in-Status sowie für organisationsweite Fehler Administratorzugriff auf das Microsoft 365 Admin Center oder Exchange Admin Center. Welches Abonnement erforderlich ist, richtet sich nach dem oben abgegrenzten Meldeweg.

Vor Änderungen dokumentiert man Tenant, betroffene Benutzer, Gerät, Betriebssystem, exakte Outlook-Version und -Variante, Zeitpunkt, Netzwerkpfad und Fehlerbild. Für den Abschlusstest verwendet man eine eindeutig erkennbare, nicht vertrauliche Nachricht, deren Übermittlung an Sophos freigegeben ist.

Auswirkungsbreite zuerst bestimmen

1. Derselbe Benutzer testet nach einem vollständigen Outlook-Neustart erneut.
2. Wenn möglich, testet er dieselbe Funktion in Outlook on the Web (OWA) oder New Outlook.
3. Ein zweiter Benutzer testet auf einem anderen Gerät und möglichst über einen anderen genehmigten Netzwerkpfad.
4. Man ordnet den Fehler danach als einzelner Benutzer/einzelnes Gerät, mehrere Benutzer/Geräte oder alle Benutzer der Organisation ein.

Lädt das Add-in, aber ein Klick auf Report zeigt We're sorry, we couldn't access report to Sophos. Make sure you have a network connection. If the problem continues, please try again later., folgt man dem passenden Zweig. Funktioniert OWA oder New Outlook, Classic Outlook aber nicht, spricht das zunächst für den lokalen Client oder dessen Web-Engine und nicht für eine fehlende tenantweite Bereitstellung.

Bereitstellung und Outlook-Variante prüfen

Für die erstmalige Bereitstellung in Microsoft 365 gilt:

1. Ein Microsoft-365-Administrator öffnet im Microsoft 365 Admin Center Settings > Integrated Apps und startet dort den Ablauf zum Hinzufügen einer App.
2. Im verfügbaren App-Katalog nach Report to Sophos suchen und diesen Eintrag auswählen. Vor dem Fortfahren Anbieter, Details und angeforderte Berechtigungen prüfen; kein ähnlich benanntes Melde- oder Verschlüsselungs-Add-in verwenden.
3. Im Zuweisungsschritt den zur Änderung passenden verfügbaren Bereich wählen: die gesamte Organisation, ausgewählte Benutzer oder Gruppen oder nur den Administrator für einen Pilottest. Falls die Änderungskontrolle eine stufenweise Einführung verlangt, mit einer kleinen Testgruppe beginnen.
4. Die Bereitstellung prüfen und bestätigen. Microsoft kann die Bezeichnungen in diesem Ablauf ändern; deshalb gilt die Abschlussbestätigung der Seite und nicht ein bestimmter Name der letzten Schaltfläche als Nachweis.
5. Zu Settings > Integrated Apps zurückkehren, den bereitgestellten Eintrag öffnen und Bereitstellungsstatus sowie zugewiesene Benutzer oder Gruppen kontrollieren. Nach der Verteilung startet ein zugewiesener Benutzer Outlook neu, prüft Report to Sophos an einer Nachricht und führt den unten beschriebenen freigegebenen Meldetest vollständig aus.

Nach einer neuen oder geänderten Bereitstellung kann die Verteilung bis zu 24 Stunden dauern. Erst nach diesem Fenster wird eine intakte Zuweisung als Fehler verworfen; falls nötig wird das Add-in über denselben administrativen Weg aktualisiert oder neu bereitgestellt.

Classic Outlook 2013, 2016 und 2019 verwendet für Add-ins eine Internet-Explorer-basierte Web-Engine, die Verbindungsfehler verursachen kann. Für diesen Fehlerpfad aktualisiert man auf Outlook 2021 oder Microsoft 365. OWA und New Outlook sind sinnvolle Gegenproben beziehungsweise vorübergehende Ausweichwege, aber kein Beleg dafür, dass der fehlerhafte Classic-Client repariert ist. Unter macOS hält man macOS und Outlook für Mac auf dem aktuellen Stand.

Einzelnen Windows-Benutzer oder ein Gerät reparieren

Man ändert nacheinander nur eine Ursache und testet nach jedem Schritt:

1. Falls Internet Explorer installiert ist, Internet Properties öffnen. Unter Security sicherstellen, dass Protected Mode für Internet und Restricted sites aktiviert ist und Internet Explorer nicht im Kompatibilitätsmodus läuft.
2. Unter Security > Trusted sites > Sites den Eintrag https://*.sophos.com hinzufügen, die Dialoge bestätigen und Outlook vollständig neu starten.
3. Outlook vollständig schliessen. Den Inhalt von %LOCALAPPDATA%\Microsoft\Office\16.0\Wef\ löschen, Outlook erneut öffnen und testen.
4. Nur auf Windows Server: In Server Manager > Local Server die IE Enhanced Security Configuration für Administratoren auf Off setzen, Outlook neu starten und testen. Diese Ausnahme nicht auf normale Windows-Endgeräte übertragen.

Diese Schritte ändern lokale Web-Engine- und Cache-Zustände. Sie ersetzen weder eine fehlende Benutzerzuweisung noch eine blockierte Netzwerkverbindung.

Mehrere Windows-Benutzer oder Geräte prüfen

Sind mehrere Geräte betroffen, prüft das Netzwerkteam Proxy, Firewall, Conditional Access und TLS/SSL-Inspection. TLS-Inspection darf nicht auf *.sophos.com oder *.hydra.sophos.com angewendet werden. Ausnahmen werden so eng wie möglich angelegt und anschliessend über den normalen Unternehmenspfad getestet.

Folgende Ziele müssen aus dem betroffenen Kontext erreichbar sein:

• https://cloud-assets.sophos.com — eine leere Seite ist die erwartete Antwort;
• https://phish-outlook.cloudstation.*.prod.hydra.sophos.com;
• https://graph.microsoft.com — erforderlich für Azure AD/Entra ID und/oder SSO-Authentifizierung.

Bei AD-/SSO-Benutzern prüft man ausserdem, ob Entra ID ein Benutzertoken ausstellt und ob Proxy- oder Conditional-Access-Regeln Tokenanforderungen von domänengebundenen Geräten blockieren. Wildcards werden entsprechend der verwendeten Netzwerkkomponente umgesetzt; sie werden nicht durch eine erfundene feste Region ersetzt.

Organisationsweiten Fehler behandeln

Sind alle Benutzer betroffen, werden zuerst Status, Zielbereich und letzte Änderung der Bereitstellung in Settings > Integrated Apps kontrolliert. Eine neue Zuweisung erhält bis zu 24 Stunden Replikationszeit. Danach kann der Administrator die bestehende Bereitstellung aktualisieren oder das Add-in kontrolliert neu bereitstellen und zunächst mit einer kleinen Benutzergruppe testen.

Parallel prüft man, ob derselbe Fehler in OWA und New Outlook auftritt. Funktionieren auch diese Varianten nach bestätigter Zuweisung und Replikation nicht, behandelt man den Fall als Netzwerk-, Authentifizierungs- oder Dienstproblem und sammelt Nachweise, statt lokale Caches auf allen Geräten zu löschen.

macOS-Cache und Anmeldetoken bereinigen

1. Outlook schliessen.
2. Unter ~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/ die zwischengespeicherten Add-in-Daten löschen.
3. Outlook erneut öffnen und testen.
4. Bleibt der Fehler bestehen, Keychain Access öffnen, nach adal oder office suchen und nur veraltete Tokens entfernen. Danach erneut authentifizieren.
5. Prüfen, dass macOS und Outlook für Mac aktuell sind; ältere Versionen können WebKit-Darstellungsprobleme zeigen.

Outlook für Mac bietet für diesen Ablauf kein Recover Deleted Items. Wenn eine gemeldete Nachricht wiederhergestellt werden muss, verwendet der Benutzer OWA beziehungsweise den Browser. Cache- und Tokenbereinigung werden nur beim betroffenen Benutzer ausgeführt, nicht pauschal im Tenant.

Ergebnis validieren und eskalieren

Outlook wird vollständig neu gestartet. Der Benutzer öffnet die freigegebene Testnachricht, klickt Report to Sophos, bestätigt die Rückfrage mit Yes und prüft, dass die Meldung ohne den genannten Zugriffsfehler abgeschlossen wird. Ein bloss geladenes Add-in ist noch kein erfolgreicher Test. Bei einem Ausweichweg hält man fest, dass nur OWA oder New Outlook funktioniert und Classic Outlook weiter fehlerhaft ist.

Für den technischen Funktionstest verwendet man keine aktive Phish-Threat-Kampagnennachricht, weil deren Meldung die Kampagnenergebnisse verändert. Soll ausdrücklich der Simulationsweg geprüft werden, stimmt der Kampagnenverantwortliche den Test ab und kontrolliert zusätzlich das sofortige positive Feedback in Outlook sowie, dass die gemeldete simulierte Nachricht in den Kampagnenergebnissen als Reported Email erfasst ist. Optional lässt sich dies unter Campaigns > [Kampagne] > By User prüfen. Ein erfolgreicher Spam-Meldetest belegt diesen Kampagnenweg nicht und umgekehrt.

Um die Testnachricht mit der Verarbeitung in Sophos Email abzugleichen oder ein separates Zustellergebnis zu untersuchen, folgt man dem Runbook zur Fehlersuche im Nachrichtenverlauf.

Für eine Eskalation sammelt man Tenant, Benutzerumfang, Geräte und Plattformen, genaue Outlook-Version und -Variante, Zeitpunkt mit Zeitzone, Bereitstellungs- und Zuweisungsstatus, Ablauf des 24-Stunden-Fensters, Resultate in Classic Outlook, New Outlook und OWA, betroffenen Netzwerkpfad, TLS-Inspection-Status, Erreichbarkeit der drei Endpunkte sowie bereits geleerte Caches oder Tokens. Keine vertrauliche Nachricht, Zugangsdaten oder vollständigen Tokens in das Fehlerprotokoll aufnehmen.