Sophos Email: wdrażanie i naprawa dodatku Report to Sophos dla Outlooka

Dodatek Report to Sophos dla Outlooka jest używany z Sophos Email i Sophos Phish Threat. Ta procedura pozostaje przypisana do ścieżki zgłaszania Sophos Email, a dodatkowo obejmuje wspólny błąd dostępu do dodatku. Logika kampanii Phish Threat i analiza ich wyników nie należą do Sophos Email.

Nie jest to również dodatek szyfrujący Sophos Email. Tamten udostępnia podczas redagowania akcję Encrypt i współpracuje z Secure Message policy. Instrukcja dodatku szyfrującego dla Outlooka opisuje wdrożenie i testowanie tego odrębnego produktu. Opisywany tutaj dodatek służy natomiast do zgłaszania istniejącej wiadomości za pomocą Report to Sophos.

Rozróżnienie ścieżek zgłaszania Sophos Email i Phish Threat

W przypadku zwykłej podejrzanej lub niechcianej wiadomości dodatek wysyła zgłoszenie do miejsc docelowych skonfigurowanych dla organizacji; zależnie od konfiguracji kopia trafia również do SophosLabs w celu analizy. Ta ścieżka zgłaszania spamu nie wymaga licencji Phish Threat.

Jeśli natomiast dodatek rozpozna symulowaną wiadomość z kampanii Phish Threat, zgłoszona wiadomość zostaje zapisana jako Reported Email w wynikach kampanii, a użytkownik natychmiast otrzymuje pozytywną informację zwrotną w Outlooku. W kwestiach instalacji, konfiguracji miejsc docelowych zgłoszeń, uaktualniania, procesu użytkownika końcowego i sprawdzania wyników kampanii należy korzystać z procedury Phish Threat dotyczącej dodatku Sophos dla Outlooka. Jeśli w którejkolwiek ścieżce Report to Sophos od razu kończy się opisanym niżej błędem dostępu, obowiązuje wspólna diagnostyka z tej procedury.

Określenie wymagań i bezpiecznego testu

Potrzebna jest ważna subskrypcja Sophos Email lub Sophos Phish Threat, dostęp do Sophos Fusion (dawniej Sophos Central) w celu sprawdzenia licencji i stanu wdrożenia oraz — przy problemach w całej organizacji — dostęp administratora do Microsoft 365 Admin Center lub Exchange Admin Center. Wymagana subskrypcja zależy od rozróżnionej wyżej ścieżki zgłaszania.

Przed zmianami należy zapisać tenant, użytkowników, urządzenie, system operacyjny, dokładną wersję i wariant Outlooka, czas, ścieżkę sieciową oraz objaw. Do testu końcowego należy użyć rozpoznawalnej, niepoufnej wiadomości, której wysłanie do Sophos zostało zatwierdzone.

Najpierw ustalenie zakresu

1. Ten sam użytkownik ponawia test po całkowitym ponownym uruchomieniu Outlooka.
2. Jeśli to możliwe, testuje tę samą funkcję w Outlook on the Web (OWA) lub New Outlook.
3. Drugi użytkownik wykonuje test na innym urządzeniu i, jeśli to możliwe, przez inną zatwierdzoną ścieżkę sieciową.
4. Problem klasyfikuje się jako dotyczący jednego użytkownika/urządzenia, kilku użytkowników/urządzeń albo wszystkich użytkowników organizacji.

Jeżeli dodatek się ładuje, lecz po kliknięciu Report pojawia się 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., należy wybrać odpowiednią gałąź poniżej. Jeśli OWA lub New Outlook działa, a Classic Outlook nie, najpierw należy podejrzewać lokalnego klienta lub jego silnik WWW, a nie brak wdrożenia w całym tenantcie.

Sprawdzenie wdrożenia i wariantu Outlooka

Pierwsze wdrożenie w Microsoft 365 przebiega następująco:

1. Administrator Microsoft 365 otwiera Settings > Integrated Apps w Microsoft 365 Admin Center i rozpoczyna proces dodawania aplikacji.
2. Wyszukuje Report to Sophos w dostępnym katalogu aplikacji i wybiera ten wpis. Przed kontynuowaniem sprawdza wydawcę, szczegóły i wymagane uprawnienia; nie zastępuje go podobnie nazwanym dodatkiem do zgłaszania ani szyfrowania.
3. Na etapie przypisywania wybiera dostępny zakres zgodny ze zmianą: całą organizację, wybranych użytkowników lub grupy albo tylko administratora na potrzeby pilotażu. Jeśli kontrola zmian wymaga wdrożenia etapowego, zaczyna od małej grupy testowej.
4. Sprawdza i potwierdza wdrożenie. Microsoft może zmieniać etykiety w tym procesie, dlatego dowodem jest komunikat strony o ukończeniu, a nie nazwa konkretnego przycisku końcowego.
5. Wraca do Settings > Integrated Apps, otwiera wdrożony wpis i sprawdza stan wdrożenia oraz przypisanych użytkowników lub grupy. Po propagacji przypisany użytkownik ponownie uruchamia Outlooka, potwierdza dostępność Report to Sophos dla wiadomości i wykonuje zatwierdzony test zgłoszenia opisany poniżej.

Propagacja nowego lub zmienionego wdrożenia może potrwać do 24 godzin. Nie należy odrzucać poprawnego przypisania przed upływem tego czasu; w razie potrzeby dodatek aktualizuje się lub wdraża ponownie tą samą drogą administracyjną.

Classic Outlook 2013, 2016 i 2019 używa dla dodatków silnika WWW opartego na Internet Explorer, co może powodować błędy połączenia. W tym scenariuszu należy przejść na Outlook 2021 lub Microsoft 365. OWA i New Outlook są przydatnymi testami porównawczymi i rozwiązaniami tymczasowymi, ale nie dowodzą naprawy Classic Outlook. W macOS należy utrzymywać aktualne wersje macOS i Outlooka dla komputerów Mac.

Naprawa jednego użytkownika lub urządzenia Windows

Należy zmieniać jedną możliwą przyczynę naraz i testować po każdym kroku:

1. Jeśli zainstalowano Internet Explorer, otworzyć Internet Properties. W Security upewnić się, że Protected Mode jest włączony dla Internet i Restricted sites, a Internet Explorer nie działa w trybie zgodności.
2. W Security > Trusted sites > Sites dodać https://*.sophos.com, potwierdzić okna i całkowicie ponownie uruchomić Outlooka.
3. Całkowicie zamknąć Outlooka. Usunąć zawartość %LOCALAPPDATA%\Microsoft\Office\16.0\Wef\, otworzyć Outlooka i przetestować.
4. Tylko w Windows Server: otworzyć Server Manager > Local Server, ustawić IE Enhanced Security Configuration na Off dla administratorów, ponownie uruchomić Outlooka i przetestować. Nie stosować tego wyjątku na zwykłych endpointach Windows.

Te czynności resetują lokalny silnik WWW i pamięć podręczną. Nie zastępują brakującego przypisania użytkownika ani nie odblokowują połączenia sieciowego.

Sprawdzenie kilku użytkowników lub urządzeń Windows

Jeśli problem dotyczy wielu urządzeń, zespół sieciowy sprawdza proxy, zaporę, Conditional Access i inspekcję TLS/SSL. Inspekcja TLS nie może obejmować *.sophos.com ani *.hydra.sophos.com. Wyjątki należy ograniczyć do minimum, a następnie przetestować zwykłą trasą firmową.

Z dotkniętego kontekstu muszą być osiągalne:

• https://cloud-assets.sophos.com — oczekiwana odpowiedź to pusta strona;
• https://phish-outlook.cloudstation.*.prod.hydra.sophos.com;
• https://graph.microsoft.com — wymagany do uwierzytelniania Azure AD/Entra ID i/lub SSO.

Dla użytkowników AD/SSO należy również potwierdzić, że Entra ID wystawia token użytkownika, a reguły proxy lub Conditional Access nie blokują żądań z komputerów dołączonych do domeny. Symbole wieloznaczne wdraża się w formie wymaganej przez mechanizm sieciowy; nie wolno zastępować ich wymyślonym stałym regionem.

Obsługa awarii w całej organizacji

Jeśli problem dotyczy wszystkich, najpierw sprawdza się stan, zakres docelowy i ostatnią zmianę wdrożenia w Settings > Integrated Apps. Na replikację nowego przypisania należy przeznaczyć do 24 godzin. Następnie administrator może zaktualizować wdrożenie lub kontrolowanie wdrożyć dodatek ponownie, testując najpierw małą grupę.

Równolegle należy sprawdzić OWA i New Outlook. Jeśli te warianty również zawodzą po potwierdzeniu przypisania i propagacji, incydent traktuje się jako problem sieci, uwierzytelniania lub usługi i zbiera dowody zamiast czyścić lokalne pamięci podręczne na każdym urządzeniu.

Czyszczenie pamięci podręcznej i tokenów w macOS

1. Zamknąć Outlooka.
2. Usunąć dane dodatku z pamięci podręcznej w ~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/.
3. Ponownie otworzyć Outlooka i przetestować.
4. Jeśli błąd pozostaje, otworzyć Keychain Access, wyszukać adal lub office i usunąć tylko nieaktualne tokeny. Następnie ponownie się uwierzytelnić.
5. Potwierdzić aktualność macOS i Outlooka dla Mac; starsze wersje mogą mieć problemy z renderowaniem WebKit.

Outlook dla Mac nie udostępnia w tym procesie funkcji Recover Deleted Items. Jeśli zgłoszoną wiadomość trzeba odzyskać, należy użyć OWA lub przeglądarki. Pamięć podręczną i tokeny czyści się tylko dla dotkniętego użytkownika, nie w całym tenantcie.

Weryfikacja wyniku i eskalacja

Całkowicie ponownie uruchomić Outlooka. Użytkownik otwiera zatwierdzoną wiadomość testową, klika Report to Sophos, potwierdza monit przyciskiem Yes i sprawdza ukończenie zgłoszenia bez wskazanego błędu dostępu. Samo załadowanie dodatku nie oznacza udanego testu. Przy rozwiązaniu tymczasowym należy zapisać, że działa tylko OWA lub New Outlook, a Classic Outlook pozostaje niesprawny.

Do technicznego testu działania nie należy używać wiadomości z aktywnej kampanii Phish Threat, ponieważ jej zgłoszenie zmienia wyniki kampanii. Jeśli trzeba jawnie przetestować ścieżkę symulacji, właściciel kampanii koordynuje test oraz sprawdza natychmiastową pozytywną informację zwrotną w Outlooku i zapisanie zgłoszonej wiadomości symulacyjnej jako Reported Email w wynikach kampanii. Opcjonalnie można to sprawdzić w Campaigns > [Kampania] > By User. Udany test zgłaszania spamu nie potwierdza działania tej ścieżki kampanii i odwrotnie.

Aby powiązać wiadomość testową z przetwarzaniem przez Sophos Email lub zbadać osobny wynik dostarczenia, należy skorzystać z instrukcji rozwiązywania problemów w Message History.

Do eskalacji zbiera się tenant, zakres użytkowników, urządzenia i platformy, dokładną wersję i wariant Outlooka, czas ze strefą, stan wdrożenia i przypisania, zakończenie 24-godzinnego okna, wyniki w Classic Outlook, New Outlook i OWA, ścieżkę sieciową, stan inspekcji TLS, osiągalność trzech endpointów oraz wyczyszczone pamięci podręczne lub tokeny. Nie wolno dołączać poufnych wiadomości, danych logowania ani pełnych tokenów.