Dostęp EAS w Sophos Mobile: różnice między trybem proxy a trybem PowerShell
Nazwa Sophos Mobile EAS-Proxy odnosi się do dwóch różnych sposobów kontrolowania Exchange ActiveSync (EAS), czyli protokołu synchronizacji poczty na urządzeniach mobilnych. W trybie proxy żądania EAS odpowiednio skonfigurowanych urządzeń przechodzą przez osobno zainstalowany serwer proxy Sophos do serwera pocztowego. W trybie PowerShell urządzenia łączą się bezpośrednio z Exchange, a usługa Sophos steruje dostępem urządzeń przez odrębne połączenie administracyjne. Pomylenie tych dwóch dróg może prowadzić do zaplanowania niewłaściwych ścieżek sieciowych lub przeoczenia zmiany dostępu do Exchange. To pomoc w podjęciu decyzji, a nie instrukcja konfiguracji, migracji ani naprawy.
Zatrzymaj się przed włączeniem kwarantanny w całej organizacji lub zmianą produkcyjną: Zmiana domyślnego poziomu dostępu w Exchange z „Allow” na „Quarantine” może natychmiast objąć również urządzenia EAS, które już się łączą, o ile nie dotyczy ich reguła dostępu urządzeń lub indywidualna decyzja Allow/Block. Nie wprowadzaj zmiany bez udokumentowania stanu wyjściowego, sprawdzenia stanu urządzeń i zgodności z zasadami, potwierdzenia logowania oraz zatwierdzonej drogi wycofania; nie jest to przełącznik dotyczący tylko jednego urządzenia pilotażowego.
Ścieżka decyzyjna: Najpierw ustal docelową usługę pocztową i aplikacje pocztowe faktycznie korzystające z EAS. W przypadku Exchange Server tryb proxy może stanowić ścieżkę ruchu pocztowego; dla Exchange Online Sophos wskazuje wyłącznie tryb PowerShell z bezpośrednim dostępem urządzeń. IBM Traveler to odrębny cel dla trybu proxy. Porównuj tryby tylko w odniesieniu do właściwego systemu docelowego. Jeżeli nie można potwierdzić identyfikacji urządzenia, uwierzytelnienia klienta, uwierzytelnienia połączenia administracyjnego albo wsparcia dla serwera docelowego, zatrzymaj się zamiast uznawać sam wybór trybu za zgodę na wdrożenie.
Migrację lub wdrożenie należy osobno zaplanować i zatwierdzić; w przypadku problemów zobacz diagnostyka EAS.
Granica licencji i platformy: Te informacje o EAS dotyczą zarządzania urządzeniami w Sophos Mobile, a nie samej licencji Sophos Mobile Threat Defense. Przed wyborem trybu sprawdź rzeczywiste uprawnienie dzierżawy do Sophos Mobile lub Sophos Mobile Device Management, rejestrację i raportowanie zgodności każdego planowanego urządzenia z Androidem lub iPhone’a/iPada oraz faktyczną aplikację i protokół pocztowy. Wymieniony przez Sophos plan Microsoft 365 Exchange Online jest warunkiem dotyczącym usługi pocztowej, nie dowodzi licencji Mobile ani objęcia natywnej synchronizacji Outlooka kontrolą EAS. Nie zakładaj ochrony Maców ani innych klientów niekorzystających z EAS.
Którędy przebiega ruch mobilnej poczty?
Granica prywatności: w trybie proxy ruch pocztowy przechodzi przez osobno obsługiwany serwer proxy; w trybie PowerShell poczta go omija, lecz Sophos nadal przetwarza identyfikator urządzenia i stan zgodności na potrzeby decyzji o dostępie. Żadna ze ścieżek nie dowodzi, jakie treści lub metadane są rejestrowane, zapisywane czy przechowywane. Przed zatwierdzeniem sprawdź rejestrowanie, dostęp i okresy przechowywania w rzeczywistym środowisku.
- Tryb proxy: urządzenie → Sophos Mobile EAS-Proxy → obsługiwany serwer pocztowy (dla Exchange: lokalny Exchange Server; Sophos wymienia również IBM Traveler). Na urządzeniach proxy musi być skonfigurowane jako serwer pocztowy EAS dla poczty przychodzącej i wychodzącej; nie wynika z tego konieczność osobnej konfiguracji SMTP. Proxy łączy się z Sophos Mobile przez interfejs HTTPS, weryfikuje identyfikację urządzenia i wymagany stan zgodności z zasadami, a następnie przekazuje odpowiednie żądania EAS. Dodatkowo proxy można skonfigurować tak, aby blokowało określone urządzenia; należy to odróżnić od kontroli zgodności z zasadami i indywidualnych wpisów Exchange ABQ. Właściwy serwer pocztowy nie musi być dostępny bezpośrednio z Internetu dla tej ścieżki poczty przez proxy. Nie gwarantuje to jednak sprawdzania każdego żądania: nadal obowiązuje opisany niżej wyjątek dotyczący Traveler. Proxy znajduje się tu na ścieżce poczty: jego awaria i przepustowość mają znaczenie dla dostępności mobilnej poczty.
- Tryb PowerShell: urządzenie → bezpośrednio Exchange; osobno usługa Sophos Mobile EAS → interfejs administracyjny Exchange. Dodatkowo usługa Sophos łączy się z Sophos Mobile przez interfejs HTTPS. Ruch pocztowy nie przechodzi przez proxy Sophos; dlatego na jego hoście nie jest potrzebny port zapory dla poczty przychodzącej. Nadal trzeba jednak zaplanować dostępność Exchange oraz połączenia administracyjne i kontrolne. Sophos wymienia jako cele Exchange Server 2016/2019 oraz Microsoft 365 z planem Exchange Online. Taka informacja o produkcie nie dowodzi jeszcze, że dostępna wersja proxy, konkretny klient, jego sposób uwierzytelniania i dzierżawa współpracują obecnie ze sobą. Wymiarowania przekaźnika poczty z trybu proxy nie można przenosić na ten tryb.
Ścieżki sieciowe w datowanym przykładzie z certyfikatami klienta: Diagram architektury Sophos (strona angielska z 12 kwietnia 2023 r., strona niemiecka z 27 kwietnia 2023 r.) przedstawia Sophos Mobile, EAS-Proxy i Exchange wewnątrz obszaru klienta oznaczonego przerywaną linią i napisem „Customer”; urządzenia znajdują się na zewnątrz. Jest to przedstawiona topologia obsługiwana przez klienta, a nie uniwersalny wymóg dla wdrożeń Sophos Mobile ani dowód granicy zapory lub DMZ. Oprócz ścieżki poczty EAS istnieje osobna ścieżka MDM urządzenie → Sophos Mobile przez HTTPS; na diagramie ta ścieżka zarządzania urządzeniami nie przechodzi przez EAS-Proxy. Należy ją odróżnić od opisanego już połączenia kontrolnego HTTPS EAS-Proxy → Sophos Mobile.
Tabela punktów końcowych tego diagramu zawiera wyłącznie schematyczne wartości przykładowe, a nie punkty końcowe do zastosowania w środowisku operacyjnym czy ogólne zgody na otwarcie zapory:
| Przedstawiona ścieżka urządzenia | Przykładowy zewnętrzny adres URL | Protokół i cel na diagramie |
|---|---|---|
| MDM → Sophos Mobile | https://smc.company.com/ | HTTPS → SMC Server:443 |
| ActiveSync → EAS-Proxy | https://eas.company.com/Microsoft-Server-ActiveSync | HTTPS → EAS Proxy:443 |
Nazwy smc.company.com i eas.company.com oraz porty docelowe należą do tego przykładu. Strzałka EAS-Proxy → Exchange ma natomiast tylko oznaczenie http/s; port backendu nie jest podany. Zachowuje to schematyczny opis HTTP/HTTPS, lecz nie wymaga nieszyfrowanego ruchu do backendu ani nie stanowi ogólnej zgody na taki ruch. Nie wynika z tego również nic o terminacji TLS ani zaufaniu do certyfikatów. Rzeczywiste punkty końcowe, porty i zabezpieczone połączenie z backendem trzeba osobno sprawdzić i zatwierdzić dla własnego środowiska; kierunki strzałek nie wykluczają ruchu odpowiedzi. Diagram nie rozszerza ani wymienionych niżej ograniczeń produktów i wersji, ani macierzy obsługiwanych serwerów pocztowych.
Przykład Central z odrębnym środowiskiem klienta: Inny zarchiwizowany diagram architektury przedstawia Sophos Mobile in Central w obszarze Sophos Central, natomiast EAS proxy i Exchange znajdują się w obszarze Customer. Urządzenia są poza obydwoma obszarami. Ich osobna ścieżka MDM prowadzi przez HTTPS do Sophos Mobile in Central; pole tekstowe wskazuje dla niej central.sophos.com. Natomiast ścieżka poczty ActiveSync prowadzi przez HTTPS do eas.company.com na EAS-Proxy po stronie klienta, a stamtąd przez http/s do Exchange. Dodatkowa, osobna strzałka HTTPS od EAS-Proxy do Sophos Mobile in Central przedstawia połączenie kontrolne przekraczające pokazaną granicę między środowiskiem klienta a Central. MDM, poczta i kontrola proxy to zatem trzy odrębne ścieżki, a nie jedna wspólna droga przez Central.
Tabela punktów końcowych tego przykładu Central zawiera dokładnie jedno przyporządkowanie: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. Nie podaje ani portu docelowego MDM w Central, ani portu backendu Exchange. Również tutaj nazwy hostów są schematycznymi przykładami z archiwum, a nie operacyjnymi punktami końcowymi własnej dzierżawy. Obszary zaznaczone przerywaną linią nie dowodzą układu zapory ani DMZ; z http/s nie wynika ani zgoda na nieszyfrowany ruch, ani informacja o terminacji TLS.
Dla trybu proxy Sophos opisuje obsługę wielu wspieranych serwerów pocztowych Exchange lub Traveler, z jedną instancją EAS-Proxy na każdy serwer pocztowy.
Osobną kwestią jest skalowanie jednej ścieżki pocztowej: w tym celu instancje mogą działać na wielu komputerach za modułem równoważenia obciążenia. Przewidziano również certyfikaty klienta: wybiera się certyfikat urzędu certyfikacji (CA), a certyfikaty klienta muszą być wystawione przez ten CA. W przedstawionym przez Sophos trybie certyfikatów klienta (przykład architektury z 12 kwietnia 2023) EAS-Proxy sprawdza przedstawione certyfikaty klienta względem wybranego certyfikatu CA i blokuje zarówno klientów bez certyfikatu klienta, jak i klientów z nieważnym certyfikatem klienta. Ten udokumentowany warunek blokowania dotyczy wyłącznie przedstawionego trybu certyfikatów klienta; nie dowodzi ani egzekwowania blokady we własnym buildzie, ani stosowania konkretnych kontroli nieważności lub unieważnienia certyfikatów. To uwierzytelnianie klienta należy odróżnić od certyfikatów połączenia PowerShell przesyłanych później do Sophos Mobile. Instancje, równoważenie obciążenia i zaufanie do certyfikatów trzeba zaplanować i przetestować w konkretnym środowisku.
Konkretny układ równoważenia obciążenia w zarchiwizowanym przykładzie: Diagram Load Balancer przedstawia Sophos Mobile, moduł równoważenia obciążenia, dwa serwery EAS-Proxy i Exchange wewnątrz obszaru Customer, a urządzenia na zewnątrz. Ścieżka MDM urządzeń prowadzi przez HTTPS bezpośrednio do Sophos Mobile (smc.company.com), a ścieżka ActiveSync urządzeń przez HTTPS do modułu równoważenia obciążenia (eas.company.com). Od modułu równoważenia obciążenia biegną dwie osobne strzałki do obu serwerów proxy, ze wspólnym oznaczeniem http/s. Każdy serwer proxy ma własne połączenie kontrolne HTTPS do Sophos Mobile i własną ścieżkę poczty http/s do Exchange. W tym przedstawieniu połączenie kontrolne nie prowadzi więc od modułu równoważenia obciążenia do Sophos Mobile.
Pełne przyporządkowania z tabeli na ilustracji można przedstawić bez szerokiej tabeli:
- MDM:
https://smc.company.com/*→ HTTPS →SMC Server:443; oba dalsze pola tabeli zawierają-. Gwiazdka należy do przedstawionego przykładowego adresu URL. - ActiveSync, Proxy 1:
https://eas.company.com/Microsoft-Server-ActiveSync→ HTTPS →Load balancer:443→http/s→EAS Proxy 1:81. - ActiveSync, Proxy 2:
https://eas.company.com/Microsoft-Server-ActiveSync→ HTTPS →Load balancer:443→http/s→EAS Proxy 2:81.
Port 81 oznacza tutaj cele proxy za modułem równoważenia obciążenia, a nie Exchange. Ilustracja nie zawiera portu backendu Exchange. Ten schematyczny obraz z archiwum nie stanowi ani ogólnej zgody na otwarcie zapory, ani dowodu odciążania TLS, przekazywania certyfikatów, przypinania sesji, kontroli kondycji, określonego algorytmu równoważenia obciążenia czy gwarantowanej wysokiej dostępności. Przyporządkowanie portów frontendu i proxy nie zastępuje planowania i zatwierdzenia rzeczywistych połączeń.
Oddzielić ilustrację PowerShell od dowodów tekstowych: Zarchiwizowana ilustracja Central PowerShell przedstawia EAS Proxy w obszarze Company, Sophos Mobile w odrębnym obszarze Sophos Central, a poniżej osobny obszar bez widocznej nazwy, zawierający Office 365 Exchange Online i outlook.office365.com. Między Company a Sophos Central znajdują się oznaczenia https i Query device compliance list. Przy EAS-Proxy widnieje Needs PowerShell 3.0 or higher. To historyczna informacja z ilustracji, a nie aktualny minimalny wymóg czy potwierdzenie wsparcia; nadal decydująca jest wymagana poniżej weryfikacja konkretnego buildu i hosta PowerShell. Na tej zarchiwizowanej ilustracji nie można wiarygodnie rozpoznać strzałek łączących elementy. Opisane powyżej rozdzielenie bezpośredniej ścieżki poczty urządzeń i odrębnego połączenia administracyjnego Exchange jest zatem stwierdzeniem udokumentowanym w tekście, a nie kierunkiem strzałek odczytanym z ilustracji. Ilustracja nie podaje również numerycznych portów ani tabeli punktów końcowych; oznaczenie hosta nie dowodzi aktualnej ścieżki uwierzytelniania ani transportu Exchange Online.
Jak interpretować starsze zalecenie dotyczące wymiarowania: W Sizing Considerations z 14 kwietnia 2022 Sophos opisuje niewielkie zapotrzebowanie EAS-Proxy na CPU i pamięć, wskazuje przepustowość jako główne ograniczenie i zaleca 1 CPU oraz 2 GB pamięci operacyjnej. Dla dużych instalacji źródło to zaleca wiele instancji EAS-Proxy za modułem równoważenia obciążenia; w trybie PowerShell taki układ przekaźników poczty nie jest wymagany. Jest to zalecenie z dokumentacji opatrzonej datą, a nie benchmark, potwierdzone aktualne minimum ani gwarancja wydajności. Z zespołem operacyjnym sprawdź konkretny build, obciążenie pocztą i dostępne ścieżki sieciowe oraz zweryfikuj wymiarowanie w autoryzowanym środowisku przed zatwierdzeniem; same te wartości nie stanowią zgody na wdrożenie produkcyjne.
Przed konfiguracją uzgodnij integrację sieciową z zespołem operacyjnym: osobno udokumentuj ścieżkę poczty urządzeń, połączenie kontrolne HTTPS z Sophos Mobile i ewentualne połączenie administracyjne z Exchange. Sophos wymienia obsługiwane serwery pocztowe w sekcji Requirements informacji o wydaniu Mobile. Przed przekazaniem do zespołu operacyjnego trzeba potwierdzić macierz obsługiwanych serwerów pocztowych obowiązującą dla planowanego buildu, docelowy build i cykl życia; ogólna lista produktów nie wystarczy. Wymagania dotyczące hosta, sieci i instalacji należą do osobnej weryfikacji przed instalacją EAS, a nie do dorozumianej zgody wynikającej z wyboru trybu.
Oba warianty kontrolują EAS, a nie dowolne protokoły mobilnej poczty. Sophos wyklucza komputery Mac z tej ścieżki kontroli, uzasadniając to brakiem obsługi ActiveSync w macOS; nie jest to stwierdzenie dotyczące każdego możliwego klienta pocztowego innego producenta na Macu. W przypadku IBM Traveler żądania urządzeń innych niż iOS, które nie mają identyfikatora urządzenia, mogą być przekazywane dalej bez możliwości sprawdzenia przez proxy ich uprawnień.
W trybie proxy powiązanie użytkownika z identyfikatorem ActiveSync może zawieść dla Outlooka na Androidzie/iOS, na przykład gdy istnieje kilka jeszcze nierozpoznanych urządzeń albo gdy ponowna instalacja aplikacji utworzy nowy identyfikator ActiveSync, który nie pasuje do zapisanego wpisu. Nie każda ponowna instalacja musi wywołać ten błąd; nie ma podstaw, by przypisywać ten sam błąd trybowi PowerShell. Według Sophos ten konkretny problem z powiązaniem nie występuje w Gmail na Androidzie ani w Mail na iOS, ponieważ Sophos Mobile otrzymuje ich identyfikator ActiveSync podczas rejestracji. Nie wyklucza to innych błędów poczty. W obu trybach sprawdź faktycznie używane aplikacje pocztowe, protokoły i identyfikatory urządzeń. Przy failed to resolve active sync id najpierw skorzystaj z diagnostyki EAS, aby zawęzić przyczynę bez wprowadzania zmian. Błąd powiązania nie upoważnia ani do resetowania identyfikatora, ani do zmiany przypisania użytkownika; ewentualny krok naprawczy uzgodnij z zespołem operacyjnym dopiero po jednoznacznym zidentyfikowaniu urządzenia i uzyskaniu osobnej zgody.
Odrębny wyjątek dla Exchange Online, Outlooka i Conditional Access: według Microsoft podczas logowania użytkownika do Outlooka na iOS lub Androidzie reguły dostępu urządzeń mobilnych Exchange Online Allow/Block/Quarantine (ABQ) są pomijane, jeśli przypisana temu użytkownikowi zasada Microsoft Entra Conditional Access obejmuje Exchange Online lub Office 365 jako aplikację w chmurze, iOS i/lub Android jako platformę, „Mobile apps and desktop client” jako aplikacje klienckie oraz co najmniej jeden warunek przyznania dostępu: wymaganie zgodnego urządzenia, zatwierdzonej aplikacji klienckiej lub zasad ochrony aplikacji. Nie dotyczy to każdego użytkownika Outlooka ani każdej zasady Conditional Access; dostęp warunkowy nadal może ograniczać dostęp. Microsoft ostrzega, że samo ABQ nie gwarantuje bezpieczeństwa: klient fałszujący nagłówek DeviceType może ominąć blokadę konkretnego typu urządzenia. W Exchange Online sprawdź też zasady i reguły dostępu Basic Mobility and Security: po rejestracji w tej usłudze mają one dla urządzenia pierwszeństwo przed zasadami mobilnych skrzynek pocztowych Exchange i regułami dostępu urządzeń. Nie traktuj ani decyzji ABQ, ani braku tego konkretnego wyjątku Conditional Access jako granicy bezpieczeństwa. To nie jest opisany wyżej problem powiązania identyfikatora ActiveSync w trybie proxy. Dla Exchange Online Microsoft opisuje natywną synchronizację Outlooka na iOS i Androidzie, a nie EAS; przed przypisaniem dostępu mechanizmom EAS sprawdź faktyczny protokół klienta. Poniższe kontrole logowania EAS dotyczą tylko klientów naprawdę korzystających z EAS; w pozostałych przypadkach testuj logowanie i ścieżkę danych faktycznie używanej aplikacji pocztowej. Na tej kwalifikującej się ścieżce nie zakładaj, że decyzje Exchange ABQ sterowane przez Sophos lub kwarantanna skutecznie egzekwują ograniczenia dostępu tylko dlatego, że działa połączenie administracyjne PowerShell. Przed rekomendacją architektury sprawdź w docelowej dzierżawie tożsamość użytkownika, aplikację pocztową, skuteczne warunki Conditional Access dotyczące aplikacji w chmurze/platformy/aplikacji klienckiej/przyznania dostępu oraz decyzję Exchange o dostępie urządzenia; w autoryzowanych testach zweryfikuj rzeczywiste logowanie, wysyłanie, odbieranie i synchronizację na każdym reprezentatywnym urządzeniu.
Oddzielnie oceń Exchange Online i cykl życia serwerów
Exchange Online – bez powrotu do Basic: Microsoft wyłączył Basic Authentication dla logowania klientów EAS oraz dla Remote PowerShell we wszystkich dzierżawach; nie można ponownie jej włączyć dla tych zastosowań. Awaryjne przejście na Basic nie naprawiłoby więc ani uwierzytelnienia połączenia administracyjnego, ani aplikacji pocztowej EAS korzystającej z Basic. Instrukcja konfiguracji Sophos z 9 września 2026 r. nie opisuje sekwencji „nowoczesne uwierzytelnianie, a w razie niepowodzenia Basic”; z jej braku nie można jednak wywnioskować żadnego innego przebiegu uwierzytelniania usługi. W tekście konfiguracji Sophos nadal występuje /powershell-liveid; Microsoft obsługuje połączenia REST dla Exchange Online PowerShell. Nie wyjaśnia to jednak, czy konkretny build Sophos korzysta z tej ścieżki. Instrukcja Sophos dotycząca Basic w katalogu PowerShell lokalnego Exchange nie jest instrukcją dla Exchange Online. Nie włączaj Basic ani WinRM Basic jako sposobu naprawy Exchange Online.
Exchange Online – sprawdź osobno TLS i uwierzytelnianie: Opcja Sophos „Allow all certificates” wyłącza weryfikację certyfikatu serwera i osłabia bezpieczeństwo połączenia; nie dowodzi obsługi ścieżki administracyjnej TLS lub REST ani nie rozwiązuje problemu wyłączenia Basic. Sprawdź zaufanie do certyfikatu i połączenie TLS, zamiast omijać weryfikację certyfikatu. Uzyskaj od Sophos potwierdzenie dla własnego środowiska obejmujące konkretny build proxy, wersję modułu ExchangeOnlineManagement, host PowerShell faktycznie używany przez usługę i jego wersję, wersję Windows oraz .NET Framework lub .NET zgodnie z macierzą zgodności modułu, hosta i systemu operacyjnego Microsoft, chmurę, ścieżkę administracyjną OAuth/REST, uprawnienia konta, a także MFA i Conditional Access. Ani zainstalowanie modułu, ani zgodna wersja hosta nie dowodzą, jakiego transportu rzeczywiście używa usługa Sophos ani czy jej uwierzytelnienie działa. W autoryzowanej dzierżawie testowej potrzebne są dwa odrębne sprawdzenia: czy usługa może zarządzać Exchange (połączenie i uprawnienia) oraz czy docelowe urządzenia mogą uwierzytelnić się w EAS i synchronizować pocztę przy użyciu faktycznie stosowanej aplikacji. Udane połączenie administracyjne nie dowodzi dostępu do poczty.
Lokalny Exchange Server: Instrukcja konfiguracji Sophos wymaga włączenia BasicAuthentication dla ścieżki katalogu PowerShell lokalnego Exchange. Nie dowodzi to, że każde lokalne połączenie administracyjne zawsze korzysta z Basic; nie dotyczy to ani logowania klienta EAS, ani Exchange Online i nie stanowi ogólnej zgody na włączenie Basic lokalnie. Lokalne uwierzytelnianie i zabezpieczenia wymagają osobnej akceptacji bezpieczeństwa. Sophos wymienia Exchange 2016/2019; standardowy okres wsparcia Microsoft dla obu zakończył się 14 października 2025 r. Ta informacja Sophos nie obejmuje Exchange Server Subscription Edition (SE). Możliwość migracji oferowana przez Microsoft nie jest certyfikacją Sophos. Zweryfikuj osobno build serwera, jego cykl życia lub ewentualne szczególne umowy oraz dopuszczenie przez Sophos dokładnie tego systemu docelowego, zamiast wywodzić zgodę na wdrożenie produkcyjne z diagramu architektury.
Co obejmuje zatwierdzona konfiguracja PowerShell
Konfiguracja PowerShell obejmuje przygotowanie hosta, dedykowane konto usługi Exchange, połączenie instancji i przypisanie do niego certyfikatu. Poniższe udokumentowane kroki i pola pomagają w przekazaniu prac zespołowi operacyjnemu; nie zastępują ani weryfikacji konkretnego buildu i ścieżki uwierzytelniania, ani zatwierdzonej zmiany. Osobna weryfikacja przed instalacją EAS obejmuje ustalenia dotyczące hosta, konta usługi i instalacji, ale również nie jest zatwierdzoną instrukcją wykonawczą konfiguracji. Nie zmieniaj zasad wykonywania skryptów, lokalnych ustawień Basic ani systemowych ustawień proxy i nie uruchamiaj ponownie usług wyłącznie na podstawie tego artykułu. Osobno udokumentuj i zatwierdź stan wyjściowy, skutki oraz procedurę wycofania tych zmian.
Host, lokalny Exchange i konto usługi
- Na hoście EAS: Sophos wskazuje instalację Windows PowerShell, jeśli jest potrzebna. Przed instalacją uzgodnij z zespołem operacyjnym jego wersję i przydatność dla konkretnego buildu. Następnie instrukcja opisuje zmianę zasad wykonywania skryptów na RemoteSigned w PowerShell otwartym jako administrator. To przygotowanie nie dowodzi jeszcze, z jakiego hosta PowerShell korzysta usługa Sophos ani czy jest z nim zgodna.
- Tylko dla lokalnego Exchange Server: W Exchange Management Shell Sophos opisuje osobny krok dotyczący RemoteSigned, a następnie ustalenie rzeczywistego katalogu PowerShell za pomocą
Get-PowerShellVirtualDirectory -Server <server name>. Symbol zastępczy oznacza nazwę komputera serwera Exchange, a nie hosta EAS ani nazwę instancji. Sophos podajePowerShell (Default Web Site)jako katalog wyłącznie dla instalacji standardowej. Dopiero po ustaleniu katalogu oficjalna instrukcja przewiduje włączenie BasicAuthentication dla odpowiedniego katalogu wirtualnego. Ta zmiana pozostaje częścią osobno zatwierdzonej konfiguracji lokalnej; wyraźnie nie należy do konfiguracji Exchange Online. - Konto usługi: Sophos używa dedykowanego konta użytkownika na serwerze pocztowym Exchange do wykonywania poleceń PowerShell. Sposób jego tworzenia różni się między Exchange Server a Exchange Online; tworzenie konta, uprawnienia i metodę uwierzytelniania należy uzgodnić z zespołem Exchange dla konkretnego systemu docelowego w ramach weryfikacji przed instalacją EAS. Samo pole hasła nie wystarczy; na tym etapie nie twórz ani konta, ani ról.
Kreator połączenia i zakończenie
Połączenie przygotowuje się w kreatorze instalacji; jego uruchomienie pozostaje częścią osobno zatwierdzonej zmiany instalacyjnej. Na ekranie EAS Proxy instance setup udokumentowano następujące pola:
- Instance type:
PowerShell Exchange/Office 365. - Instance name: Samodzielnie wybrana nazwa pozwalająca jednoznacznie zidentyfikować instancję.
- Exchange server: Dla lokalnego Exchange nazwa serwera lub jego adres IP; dla globalnej usługi Microsoft 365 Sophos podaje
outlook.office365.com. Dla innych chmur należy osobno potwierdzić właściwy punkt końcowy połączenia z zespołem Exchange; Sophos odsyła w tym celu do przyporządkowania-ConnectionUriwConnect-ExchangeOnline. Według Sophos w tym polu nie wpisuje sięhttps://ani/powershell-liveid, ponieważ kreator je dodaje. Dokumentuje to zachowanie pola, a nie transport Exchange Online zweryfikowany na 2026 r. Nie zgaduj zastępczego punktu końcowego; nadal wymagana jest wskazana wyżej weryfikacja buildu, chmury i uwierzytelniania. - Service account i Password: Nazwa i hasło wcześniej utworzonego konta usługi. Nie umieszczaj danych logowania w plikach audytowych, przykładach ani zgłoszeniach; same pola nie dowodzą stosowania określonej metody uwierzytelniania.
Add dodaje połączenie do listy Instances. Dla kolejnych instancji serwerów Exchange Sophos opisuje powtórzenie tej konfiguracji, a następnie zakończenie kreatora. Mimo tego przeglądu pól opcja Allow all certificates nadal nie jest zalecanym skrótem: sprawdź zaufanie do certyfikatów, zamiast wyłączać weryfikację serwera.
Opcjonalne proxy dla połączeń wychodzących: Jeśli host EAS musi łączyć się z Exchange Server lub Exchange Online przez sieciowy serwer proxy, Sophos opisuje w tym celu krok WinHTTP na hoście EAS w wierszu polecenia otwartym przez Run as administrator. Konkretna konfiguracja WinHTTP pozostaje w gestii zespołu operacyjnego i wymaga zatwierdzonej zmiany instalacyjnej; nie jest to tryb proxy dla poczty urządzeń. Ustawienie obowiązuje w całym systemie i może wpływać na inne programy na hoście Windows. Przed taką zmianą również dla tych zależności trzeba udokumentować stan wyjściowy i zatwierdzić procedurę wycofania; nie wynika z tego uniwersalna metoda naprawy błędów uwierzytelniania przez zmianę proxy.
Na zakończenie Sophos opisuje przesłanie wygenerowanego podczas konfiguracji certyfikatu połączenia PowerShell w My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. Przy wielu instancjach przesyła się wszystkie certyfikaty instancji, następnie wybiera Save i wykonuje zatwierdzone ponowne uruchomienie EASProxy w oknie Windows Services. Uzgodnij z zespołem operacyjnym okno serwisowe, stan usługi i procedurę wycofania. Zapisane certyfikaty ani nowa wartość Last active nie dowodzą udanego logowania urządzeń ani dostarczania poczty: logowanie, wysyłanie, odbieranie i synchronizację nadal trzeba sprawdzić dla każdego urządzenia objętego zmianą przed jej wprowadzeniem i po niej.
Przed każdą zmianą dostępu EAS
Przy już skonfigurowanym i sprawdzonym połączeniu kontrolnym PowerShell można skonfigurować Exchange tak, aby urządzenia niezarejestrowane w Sophos Mobile trafiały do kwarantanny i nie otrzymywały dostępu do poczty. Dotyczy to tylko ścieżek, na których opisane wyżej ograniczenia protokołów i ABQ pozwalają na taką kontrolę. Blokowanie niezarejestrowanych urządzeń jest osobną zmianą dostępu w całej organizacji dla zespołu operacyjnego Exchange/Mobile, a nie zakończeniem instalacji. Wstępna ocena architektury i bezpieczeństwa tej zmiany znajduje się poniżej; konfiguracja połączenia kontrolnego należy do osobnej weryfikacji przed instalacją EAS. Sophos opisuje przy tym powiadomienie Exchange zachęcające użytkowników do rejestracji. W udokumentowanym przykładzie Set-ActiveSyncOrganizationSettings z -DefaultAccessLevel quarantine ustawia domyślny poziom dostępu dla całej organizacji; -UserMailInsert dodaje do wiadomości o kwarantannie konfigurowalną informację o rejestracji. Ten artykuł nie zaleca wykonywania tego polecenia. Najpierw trzeba wyjaśnić wymagania, skutki i zatwierdzoną procedurę wycofania.
Kontekst administracyjny jest różny: dla lokalnego Exchange Server przewidziano Exchange Management Shell, a dla chmury osobno sprawdzone połączenie Exchange Online PowerShell z odpowiednim kontem oraz obsługiwaną ścieżką uwierzytelniania i transportu. Lokalna powłoka ani jej ustawienie Basic nie zastępują sprawdzonego połączenia z chmurą.
Kwarantanna Exchange w całej organizacji nie jest przełącznikiem pilotażowym dla pojedynczego urządzenia testowego. Tam, gdzie Exchange ABQ jest rzeczywiście stosowane, zmiana z „Allow” na „Quarantine” może natychmiast objąć już łączące się urządzenia EAS, nie tylko nowe lub nieznane, chyba że obowiązuje reguła dostępu albo indywidualna decyzja Allow/Block. Nie zakładaj tego skutku na opisanej wyżej kwalifikującej się ścieżce Exchange Online/Outlook/Conditional Access: reguły Exchange ABQ są tam pomijane. W trybie PowerShell kwarantanną mogą zostać objęte również urządzenia już zarejestrowane, jeśli ich stan zgodności z zasadami pozostaje nieznany po braku synchronizacji lub zakłóceniu połączenia z Sophos Mobile, pod warunkiem że ABQ dotyczy ich ścieżki. Automatyczne dopuszczenie po udanej rejestracji wymaga działającej ścieżki kontroli; nie gwarantuje usunięcia awarii.
Przed zatwierdzoną zmianą zapisz dotychczasowy Exchange DefaultAccessLevel, tekst powiadomienia, istniejące reguły dostępu urządzeń i indywidualne wpisy Allow/Block, a także inwentarz urządzeń i aplikacji pocztowych, bieżący stan synchronizacji i zgodności z zasadami, zaufanie do certyfikatów oraz osoby odpowiedzialne. Na uzgodnionych skrzynkach testowych obserwuj urządzenia dopuszczone, nieznane i takie, których stanu tymczasowo nie da się ocenić; sprawdź dostępne zdarzenia Sophos, Exchange i Entra pod kątem decyzji oraz błędów połączenia i potwierdź ich powiązanie z odpowiednim urządzeniem w docelowej dzierżawie. Przed zmianą sprawdź na uzgodnionych skrzynkach testowych dla każdego urządzenia objętego zmianą rzeczywiste logowanie EAS, wysyłanie, odbieranie i synchronizację; same zdarzenia nie dowodzą skutków zmiany. W menu Sophos My Products > Mobile > Setup > Sophos setup > EAS proxy wartość External > Last active wskazuje jedynie ostatni kontakt danej instancji proxy z Sophos Mobile, a nie udane logowanie, dostarczenie poczty czy dopuszczenie każdego urządzenia.
Zatwierdzona procedura wycofania musi obejmować przywrócenie udokumentowanego domyślnego poziomu dostępu, reguł, indywidualnych decyzji i tekstu powiadomienia, wraz z przypisaniem odpowiedzialności i kryteriami przerwania zmiany. Samo przywrócenie wartości domyślnej nie dowodzi przywrócenia działania: urządzenia mogą pozostać w nieoczekiwanym stanie; po wycofaniu zmiany sprawdź osobno na uzgodnionych skrzynkach testowych rzeczywiste logowanie EAS, wysyłanie, odbieranie i synchronizację każdego urządzenia objętego zmianą, również po dezaktualizacji stanu zgodności z zasadami lub awarii połączenia kontrolnego z Sophos. Dopóki uwierzytelnianie, ścieżka poczty i procedura wycofania nie zostaną potwierdzone, a zmiana zatwierdzona, ten artykuł nie zaleca ani instalacji, ani przełączenia kwarantanny, ani migracji.