Sophos Mobile EAS-åtkomst: skilj mellan proxy- och PowerShell-läge

Namnet Sophos Mobile EAS-proxy avser två olika sätt att kontrollera Exchange ActiveSync (EAS), protokollet för mobil e-postsynkronisering. I proxyläge går EAS-förfrågningar från enheter som konfigurerats för detta genom den separat installerade Sophos-proxyn till e-postservern. I PowerShell-läge ansluter enheterna direkt till Exchange; Sophos-tjänsten styr enhetsåtkomsten via en separat administrationsanslutning. Den som förväxlar dessa vägar kan planera fel nätverksvägar eller missa en ändring av Exchange-åtkomsten. Detta är ett beslutsunderlag, inte en guide för installation, migrering eller reparation.

Stanna upp före en organisationsomfattande karantän eller en ändring i produktion: En ändring av Exchange standardåtkomstnivå från ”Allow” till ”Quarantine” kan omedelbart påverka redan anslutna EAS-enheter om ingen enhetsåtkomstregel eller individuell Allow-/Block-åtgärd gäller för dem. Gör ingen omställning utan dokumenterat utgångsläge, kontrollerade enhets- och efterlevnadsstatusar, verifierad inloggning och en godkänd återgångsväg; detta är ingen omkopplare för en enskild pilotenhet.

Beslutsväg: Fastställ först måltjänsten för e-post och vilka EAS-appar för e-post som faktiskt används. För Exchange Server kan proxyläge vara aktuellt som e-postväg; för Exchange Online anger Sophos endast PowerShell-läge med direkt åtkomst för enheterna. IBM Traveler är ett separat proxymål. Jämför lägena endast för respektive mål. Om enhetsidentitet, klientinloggning, administrationsinloggning eller stöd för målservern inte kan verifieras, stanna här i stället för att dra slutsatsen att valet av läge innebär ett godkännande.

En migrering eller implementering måste planeras och godkännas separat; vid störningar, se EAS-felsökning.

Licens- och plattformsgräns: Dessa EAS-anvisningar gäller enhetshantering med Sophos Mobile, inte en fristående Sophos Mobile Threat Defense-licens. Kontrollera före val av läge tenantens faktiska rätt till Sophos Mobile eller Sophos Mobile Device Management, registrering och efterlevnadsrapportering för varje avsedd Android-enhet eller iPhone/iPad samt vilken e-postapp och vilket protokoll som faktiskt används. Den Microsoft 365 Exchange Online-plan som Sophos nämner är en förutsättning för e-posttjänsten, inte ett bevis på Mobile-rättigheter eller att EAS-kontroller omfattar Outlooks inbyggda synkronisering. Härled inte täckning för Mac-datorer eller andra klienter som inte använder EAS.

Var går den mobila e-posttrafiken?

Integritetsgräns: I proxyläge passerar e-posttrafiken den separat drivna proxyn; i PowerShell-läge går e-posten inte genom den, men Sophos hanterar fortfarande enhetsidentitet och efterlevnadsstatus för åtkomstbeslut. Ingen av vägarna visar vilket innehåll eller vilka metadata som loggas, lagras eller bevaras. Kontrollera loggning, åtkomst och lagringstider i den faktiska miljön före godkännande.

• Proxyläge: Enhet → Sophos Mobile EAS-proxy → e-postserver som stöds (för Exchange: lokal Exchange Server; Sophos nämner även IBM Traveler). På enheterna måste proxyn vara konfigurerad som EAS-e-postserver för inkommande och utgående e-post; detta innebär inte någon separat SMTP-konfiguration. Proxyn ansluter till Sophos Mobile via ett HTTPS-webbgränssnitt, stämmer av enhetsidentitet och nödvändig status för efterlevnad av policyer och vidarebefordrar EAS-förfrågningar som uppfyller kraven. Proxyn kan dessutom konfigureras för att blockera vissa enheter; detta ska skiljas från efterlevnadskontrollen och individuella Exchange ABQ-poster. Den faktiska e-postservern behöver inte vara direkt åtkomlig från internet för denna e-postväg via proxyn. Detta garanterar inte att varje förfrågan kontrolleras: Traveler-undantaget som beskrivs nedan gäller fortfarande. Här ligger proxyn i e-postvägen: proxyfel och proxykapacitet påverkar tillgängligheten för mobil e-post.
• PowerShell-läge: Enhet → Exchange direkt; separat från detta Sophos Mobile EAS-tjänst → administrationsgränssnittet för Exchange. Sophos-tjänsten ansluter dessutom till Sophos Mobile via ett HTTPS-webbgränssnitt. E-posttrafiken går inte genom Sophos-proxyn; dess värd behöver därför ingen brandväggsport för inkommande e-post. Åtkomligheten till Exchange samt administrations- och kontrollanslutningarna måste ändå planeras. Sophos anger Exchange Server 2016/2019 och Microsoft 365 med Exchange Online-plan som mål. Den produktuppgiften är ännu inget bevis för att den befintliga proxyversionen, den aktuella klienten, dess inloggning och tenantmiljön fungerar tillsammans i dag. Dimensioneringen av e-postreläet i proxyläge kan inte överföras till detta läge.

Nätverksvägar i det daterade klientcertifikatsexemplet: Sophos arkitekturdiagram (den engelska sidan från 12 april 2023, den tyska från 27 april 2023) visar Sophos Mobile, EAS-proxyn och Exchange inom en streckad kundmiljö märkt ”Customer”; enheterna visas utanför. Detta är en avbildad kunddriven topologi, inte ett generellt krav för Sophos Mobile-installationer eller ett belägg för en brandväggs- eller DMZ-gräns. Utöver EAS-e-postvägen finns en separat MDM-väg från enhet → Sophos Mobile via HTTPS; denna enhetshanteringsväg går inte genom EAS-proxyn i diagrammet. Den ska skiljas från den redan beskrivna HTTPS-kontrollanslutningen EAS-proxy → Sophos Mobile.

Diagrammets tabell över slutpunkter anger endast schematiska exempelvärden, inte driftsslutpunkter att använda eller generella brandväggsgodkännanden:

Namnen smc.company.com och eas.company.com samt målportarna hör till detta exempel. Pilen EAS-proxy → Exchange är däremot endast märkt http/s; ingen backend-port anges. Detta bevarar den schematiska HTTP-/HTTPS-framställningen, men innebär varken ett krav på okrypterad backend-trafik eller ett generellt godkännande av sådan trafik. Det ger inte heller några besked om TLS-terminering eller certifikatförtroende. Faktiska slutpunkter, portar och den skyddade backend-anslutningen ska kontrolleras och godkännas separat för den egna miljön; pilarnas riktning utesluter inte svarstrafik. Diagrammet utökar varken produkt- och versionsgränserna nedan eller matrisen över e-postservrar som stöds.

Central-exempel med separat kundmiljö: En annan arkiverad arkitektur visar Sophos Mobile in Central inom området Sophos Central, medan EAS proxy och Exchange finns inom området Customer. Enheterna befinner sig utanför båda områdena. Deras separata MDM-väg går via HTTPS till Sophos Mobile i Central; textrutan anger central.sophos.com för detta. ActiveSync-vägen för e-post går däremot via HTTPS till eas.company.com på kundens EAS-proxy och därifrån via http/s till Exchange. En separat HTTPS-pil från EAS-proxyn till Sophos Mobile i Central visar dessutom kontrollanslutningen över den avbildade gränsen mellan kunden och Central. MDM, e-post och proxykontroll är alltså tre separata vägar, inte en gemensam väg genom Central.

Tabellen över slutpunkter i detta Central-exempel innehåller exakt en koppling: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. Den anger varken en målport för Central-MDM eller en backend-port för Exchange. Även här är värdnamnen schematiska arkivexempel, inte driftsslutpunkter för den egna tenanten. De streckade områdena visar inte någon brandväggs- eller DMZ-uppställning; http/s innebär varken ett godkännande för okrypterad trafik eller besked om TLS-terminering.

För proxyläge beskriver Sophos stöd för flera Exchange- eller Traveler-e-postservrar med en EAS-proxyinstans per e-postserver.

Skalning av en e-postväg är en separat fråga: för detta kan instanser köras på flera datorer bakom en lastbalanserare. Även klientcertifikat stöds: ett certifikat från en certifikatutfärdare (CA) väljs, och klientcertifikaten måste vara utfärdade av denna CA. I det klientcertifikatsläge som Sophos visar (arkitekturexemplet från 12 april 2023) kontrollerar EAS-proxyn de klientcertifikat som presenteras mot det valda CA-certifikatet och blockerar både klienter utan klientcertifikat och klienter med ett ogiltigt klientcertifikat. Detta dokumenterade blockeringsvillkor gäller endast det visade klientcertifikatsläget; det bevisar varken att villkoret upprätthålls i det egna bygget eller att specifika kontroller av ogiltighet eller återkallelse utförs. Denna klientautentisering ska skiljas från de PowerShell-anslutningscertifikat som senare laddas upp till Sophos Mobile. Instanser, lastbalansering och certifikatförtroende måste planeras och testas för den aktuella miljön.

Konkret lastbalansering i det arkiverade exemplet: Lastbalanserardiagrammet visar Sophos Mobile, en lastbalanserare, två EAS-proxyer och Exchange inom Customer, med enheterna utanför. Enheternas MDM-väg går via HTTPS direkt till Sophos Mobile (smc.company.com), medan deras ActiveSync-väg går via HTTPS till lastbalanseraren (eas.company.com). Från lastbalanseraren går två separata pilar till de båda proxyerna, med den gemensamma märkningen http/s. Varje proxy har en egen HTTPS-kontrollanslutning till Sophos Mobile och en egen e-postväg via http/s till Exchange. I denna framställning går kontrollen alltså inte från lastbalanseraren till Sophos Mobile.

Bildtabellens fullständiga kopplingar kan läsas utan en bred tabell:

• MDM: https://smc.company.com/* → HTTPS → SMC Server:443; båda efterföljande tabellfälten är -. Asterisken hör till det avbildade URL-exemplet.
• 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 avser här proxymålen bakom lastbalanseraren, inte Exchange. Bilden anger ingen backend-port för Exchange. Denna schematiska arkivframställning är varken ett generellt brandväggsgodkännande eller ett bevis på TLS-avlastning, vidarebefordran av certifikat, sessionsbindning, Health Checks, en viss lastbalanseringsalgoritm eller garanterad hög tillgänglighet. Kopplingen mellan frontend- och proxyportar ersätter inte planering och godkännande av de faktiska anslutningarna.

Skilj mellan PowerShell-bilden och textbelägget: Den arkiverade Central-PowerShell-bilden visar EAS Proxy inom området Company, Sophos Mobile inom det separata området Sophos Central och därunder ett eget område utan synligt namn med Office 365 Exchange Online och outlook.office365.com. Mellan Company och Sophos Central finns märkningarna https och Query device compliance list. Vid EAS-proxyn står Needs PowerShell 3.0 or higher. Detta är en historisk uppgift i bilden, inte ett aktuellt minimikrav eller bevis på stöd; kontrollen av det specifika bygget och PowerShell-värden som krävs nedan är fortfarande avgörande. Anslutande pilar kan inte urskiljas tillförlitligt i dessa arkiverade bildpunkter. Den ovan beskrivna uppdelningen mellan direkt e-postväg för enheterna och separat administrationsanslutning till Exchange är därför en dokumenterad textuppgift, inte en pilriktning som har avlästs i denna bild. Bilden anger inte heller numeriska portar eller någon tabell över slutpunkter; värdnamnet i bilden bevisar inte någon aktuell inloggnings- eller transportväg för Exchange Online.

Bedöm det daterade dimensioneringsrådet: I Sizing Considerations från 14 april 2022 beskriver Sophos ett lågt CPU- och minnesbehov för EAS-proxyn, anger bandbredden som den huvudsakliga begränsningen och rekommenderar 1 CPU och 2 GB arbetsminne. För stora installationer rekommenderar denna källa flera EAS-proxyinstanser bakom en lastbalanserare; i PowerShell-läge behövs inte denna uppställning med e-postreläer. Detta är en daterad rekommendation i dokumentationen, inte ett prestandatest, ett verifierat aktuellt minimikrav eller en kapacitetsgaranti. Kontrollera det specifika bygget, e-postbelastningen och tillgängliga nätverksvägar med driftteamet och validera dimensioneringen i en auktoriserad miljö före godkännande; dessa värden ensamma innebär inget godkännande för produktion.

Klargör nätverksintegrationen med driftteamet före installationen: dokumentera enheternas e-postväg, HTTPS-kontrollanslutningen till Sophos Mobile och eventuell administrationsanslutning till Exchange separat. Sophos listar de e-postservrar som stöds i avsnittet Requirements i versionsinformationen för Mobile. Inför överlämningen måste e-postservermatrisen för det avsedda bygget, målbygget och livscykeln vara bekräftade; en allmän produktlista räcker inte. Förutsättningarna för värd, nätverk och installation hör till den separata förkontrollen inför EAS-installation, inte till ett underförstått godkännande genom detta val av läge.

Båda varianterna kontrollerar EAS, inte godtyckliga protokoll för mobil e-post. Sophos utesluter Mac-datorer från denna kontrollväg med hänvisning till att macOS saknar ActiveSync-stöd; detta är inget påstående om alla tänkbara e-postklienter från tredje part på en Mac. För IBM Traveler kan förfrågningar från andra enheter än iOS-enheter utan enhets-ID släppas igenom utan att proxyn kan kontrollera deras behörighet.

I proxyläge kan Outlook på Android/iOS misslyckas med kopplingen mellan användare och ActiveSync-ID, till exempel när flera enheter fortfarande är okända eller när en ominstallation av appen skapar ett nytt ActiveSync-ID som inte matchar den sparade posten. Alla ominstallationer behöver inte orsaka detta fel; det finns därmed inget belägg för att samma fel uppstår i PowerShell-läge. Enligt Sophos uppstår detta specifika kopplingsproblem inte med Gmail på Android eller Mail på iOS, eftersom Sophos Mobile får deras ActiveSync-ID vid registreringen. Det utesluter inte andra e-postfel. Kontrollera de e-postappar, protokoll och enhets-ID:n som faktiskt används i båda lägena. Vid failed to resolve active sync id, använd först EAS-felsökning för att avgränsa problemet utan att göra ändringar. Ett kopplingsfel innebär inget godkännande för att återställa ett ID eller ändra användarkopplingen; klargör en eventuell reparationsåtgärd med driftteamet först efter att enheten har identifierats entydigt och åtgärden har godkänts separat.

Separat undantag för Exchange Online, Outlook och Conditional Access: När en användare loggar in i Outlook för iOS eller Android anger Microsoft att Exchange Onlines regler för mobil enhetsåtkomst Allow/Block/Quarantine (ABQ) hoppas över om en Microsoft Entra Conditional Access-policy som gäller användaren omfattar Exchange Online eller Office 365 som molnapp, iOS och/eller Android som enhetsplattform, ”Mobile apps and desktop client” som klientappar och minst ett av följande tillträdeskrav: enhet som uppfyller efterlevnadskraven, godkänd klientapp eller appskyddspolicy. Detta gäller inte varje Outlook-användare eller varje Conditional Access-policy; Conditional Access kan fortfarande begränsa åtkomsten. Microsoft varnar för att ABQ ensamt inte ger någon säkerhetsgaranti: en klient som förfalskar DeviceType-huvudet kan kringgå blockering av en viss enhetstyp. Kontrollera för Exchange Online även policyer och åtkomstregler i Basic Mobility and Security: efter registrering i den tjänsten åsidosätter de för enheten Exchanges policyer för mobila enheters postlådor och enhetsåtkomstregler. Betrakta varken ett ABQ-beslut eller avsaknaden av detta specifika Conditional Access-undantag som en säkerhetsgräns. Undantaget är skilt från problemet med Outlooks ActiveSync-ID-koppling i proxyläge ovan. För Exchange Online beskriver Microsoft inbyggd synkronisering för Outlook på iOS och Android, inte EAS; kontrollera klientens faktiska protokoll innan åtkomst tillskrivs EAS-kontroller. EAS-inloggningskontrollerna nedan gäller bara klienter som faktiskt använder EAS; testa annars den verkliga e-postappens inloggning och dataväg. Utgå inte från att Sophos-styrda Exchange ABQ-beslut eller karantän tvingar fram åtkomstkontroll på denna kvalificerade väg bara för att PowerShell-administrationsanslutningen fungerar. Innan arkitekturen rekommenderas, kontrollera i måltenanten användaridentiteten, e-postappen, de tillämpliga Conditional Access-villkoren för molnapp/plattform/klientapp/tillträdeskrav och Exchange-beslutet om enhetsåtkomst; verifiera genom auktoriserade tester faktisk inloggning, sändning, mottagning och synkronisering för varje representativ enhet.

Bedöm Exchange Online och serverns livscykel var för sig

Exchange Online – ingen återgång till Basic: Microsoft har stängt av Basic Authentication för EAS-klientinloggningar och för Remote PowerShell i alla tenants; det går inte att aktivera igen för dessa ändamål. En återgång till Basic skulle därför varken lösa administrationsinloggningen eller en EAS-app för e-post som använder Basic-inloggning. Sophos installationsanvisning från 9 september 2026 beskriver inget förlopp med ”modern autentisering, Basic vid misslyckande”; avsaknaden av detta ger dock inte heller stöd för att dra slutsatser om något annat inloggningsförlopp för tjänsten. Sophos installationstext nämner fortfarande /powershell-liveid; Microsoft stöder REST-anslutningar för Exchange Online PowerShell. Därmed är det inte klarlagt om ett visst Sophos-bygge använder den vägen. Sophos instruktion om Basic för den lokala Exchange PowerShell-katalogen är inte en instruktion för Exchange Online. Aktivera inte Basic eller WinRM Basic som åtgärd för Exchange Online.

Exchange Online – kontrollera TLS och inloggning var för sig: Sophos-alternativet ”Allow all certificates” stänger av kontrollen av servercertifikatet och försvagar anslutningens säkerhet; det bevisar inte att en TLS- eller REST-administrationsväg stöds och löser inte avstängningen av Basic. Kontrollera certifikatförtroende och TLS-anslutning i stället för att kringgå certifikatkontrollen. Begär från Sophos ett godkännande för den egna miljön som omfattar det specifika proxybygget, versionen av ExchangeOnlineManagement-modulen, den PowerShell-värd inklusive version som tjänsten faktiskt använder, Windows-versionen och .NET Framework- respektive .NET-versionen enligt Microsofts modul-/värd-/OS-matris, molnmiljön, administrationsvägen via OAuth/REST, kontobehörigheterna samt MFA och Conditional Access; varken en modulinstallation eller en passande värdversion visar vilken transport Sophos-tjänsten faktiskt använder eller om dess inloggning fungerar. I en auktoriserad testtenant behövs två separata kontroller: Kan tjänsten administrera Exchange (anslutning och behörighet), och kan de avsedda enheterna logga in på EAS och synkronisera med sina faktiska e-postappar? En lyckad administrationsanslutning bevisar inte att e-poståtkomsten fungerar.

Lokal Exchange Server: Sophos installationsanvisning kräver att BasicAuthentication aktiveras för den lokala Exchange PowerShell-katalogen. Detta visar inte att varje lokal administrationsanslutning alltid använder Basic; det gäller varken EAS-klientinloggningen eller Exchange Online och är inget generellt godkännande för att aktivera Basic lokalt. Lokal autentisering och säkerhetshärdning kräver ett separat säkerhetsgodkännande. Sophos anger Exchange 2016/2019; Microsofts ordinarie support för båda upphörde den 14 oktober 2025. Exchange Server Subscription Edition (SE) omfattas inte av denna Sophos-uppgift. Ett migreringsalternativ från Microsoft är ingen Sophos-certifiering. Begär separata besked om serverbygge, livscykel respektive eventuella särskilda avtal och Sophos godkännande för just detta mål, i stället för att tolka ett arkitekturdiagram som ett godkännande för produktion.

Vad som ingår i en godkänd PowerShell-installation

PowerShell-installationen omfattar förberedelse av värden, ett dedikerat Exchange-tjänstekonto, instansanslutningen och dess certifikatkoppling. Följande dokumenterade steg och fält underlättar överlämningen till driftteamet; de ersätter varken kontrollen av det specifika bygget och inloggningsvägen eller en godkänd ändring. Den separata förkontrollen inför EAS-installation behandlar förutsättningarna för värd, tjänstekonto och installation, men är inte heller en godkänd körinstruktion för installation. Ändra inte körningsprinciper, lokala Basic-inställningar eller systemomfattande proxyinställningar och starta inte om tjänster enbart med stöd av denna artikel. Dokumentera och godkänn utgångsläge, konsekvenser och återgångsväg separat för dessa åtgärder.

Värd, lokal Exchange och tjänstekonto

• På EAS-värden: Sophos anger installation av Windows PowerShell vid behov. Före installationen måste versionen och dess lämplighet för det specifika bygget stämmas av med driftteamet. Därefter beskriver anvisningen att körningsprincipen ändras till RemoteSigned i ett PowerShell-fönster som öppnats som administratör. Denna förberedelse visar ännu inte vilken PowerShell-värd Sophos-tjänsten använder eller om tjänsten är kompatibel med den.
• Endast för lokal Exchange Server: I Exchange Management Shell beskriver Sophos ett separat RemoteSigned-steg och därefter hur den faktiska PowerShell-katalogen identifieras med Get-PowerShellVirtualDirectory -Server <server name>. Platshållaren avser Exchange-serverns datornamn, inte EAS-värden eller instansnamnet. Sophos anger PowerShell (Default Web Site) som katalog endast vid en standardinstallation. Först efter denna identifiering följer i den officiella anvisningen aktivering av BasicAuthentication för den aktuella virtuella katalogen. Denna ändring får endast göras inom den separat godkända lokala installationen; den hör uttryckligen inte till en Exchange Online-installation.
• Tjänstekonto: Sophos använder ett dedikerat användarkonto på Exchange-e-postservern för att köra PowerShell-kommandon. Hur kontot skapas skiljer sig mellan Exchange Server och Exchange Online; klargör kontoskapande, behörigheter och inloggningsförfarande med Exchange-teamet för det specifika målet inom ramen för förkontrollen inför EAS-installation. Ett lösenordsfält räcker inte för detta; skapa varken ett konto eller roller här.

Anslutningsguide och slutförande

Anslutningen förbereds i installationsguiden; guiden får endast köras inom den separat godkända installationsändringen. På EAS Proxy instance setup är följande fält dokumenterade:

• Instance type: PowerShell Exchange/Office 365.
• Instance name: Ett valfritt namn som identifierar instansen entydigt.
• Exchange server: För lokal Exchange anges servernamnet eller dess IP-adress; för den globala Microsoft 365-tjänsten anger Sophos outlook.office365.com. För andra molnmiljöer måste rätt anslutningsslutpunkt bekräftas separat med Exchange-teamet; Sophos hänvisar för detta till kopplingen till -ConnectionUri i Connect-ExchangeOnline. Enligt Sophos ska https:// och /powershell-liveid inte anges i detta fält, eftersom guiden lägger till dem. Detta dokumenterar fältets beteende, inte en Exchange Online-transport som har verifierats för 2026. Gissa inte en ersättningsslutpunkt; kontrollen av bygge, molnmiljö och inloggning som krävs ovan behövs fortfarande.
• Service account och Password: Namn och lösenord för det tjänstekonto som skapats tidigare. Ta inte med inloggningsuppgifter i granskningsfiler, exempel eller ärenden; fälten i sig visar inte vilken autentiseringsmetod som används.

Med Add läggs anslutningen till i listan Instances. För ytterligare Exchange Server-instanser beskriver Sophos att denna konfiguration upprepas och att guiden därefter slutförs. Alternativet Allow all certificates är fortfarande ingen rekommenderad genväg trots denna fältöversikt: kontrollera certifikatförtroendet i stället för att stänga av servercertifikatkontrollen.

Valfri proxy för utgående anslutningar: Om EAS-värden måste nå Exchange Server eller Exchange Online via en nätverksproxy beskriver Sophos ett WinHTTP-steg på EAS-värden i en kommandotolk som öppnats med Run as administrator. Den konkreta WinHTTP-konfigurationen är förbehållen driftteamet och den godkända installationsändringen; den är inte ett proxyläge för enheternas e-post. Inställningen gäller för hela systemet och kan påverka andra program på Windows-värden. Före en sådan ändring kräver även dessa beroenden ett dokumenterat utgångsläge och en godkänd återgångsväg; detta är ingen generell proxyåtgärd för inloggningsfel.

Som avslutning beskriver Sophos uppladdning av det PowerShell-anslutningscertifikat som skapats vid konfigurationen under My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. Vid flera instanser laddas alla instanscertifikat upp, följt av Save och en godkänd omstart av EASProxy i Windows-dialogen Services. Klargör underhållsfönster, tjänstens tillstånd och återgångsväg med driftteamet. Sparade certifikat eller ett nytt Last active-värde bevisar varken lyckad enhetsinloggning eller e-postleverans: inloggning, sändning, mottagning och synkronisering måste fortfarande kontrolleras för varje berörd enhet före och efter ändringen.

Före varje ändring av EAS-åtkomsten

Med en redan konfigurerad och kontrollerad PowerShell-kontrollanslutning kan Exchange konfigureras så att enheter utan registrering i Sophos Mobile hamnar i karantän och inte får e-poståtkomst. Detta gäller endast där protokoll- och ABQ-begränsningarna ovan medger denna kontroll. Blockering av oregistrerade enheter är en separat organisationsomfattande åtkomständring för Exchange-/Mobile-driftteamet, inte ett avslutande installationssteg. Förkontrollen av arkitektur och säkerhet för denna ändring följer här; konfigureringen av kontrollanslutningen hör till den separata förkontrollen inför EAS-installation. Sophos beskriver en Exchange-avisering som uppmanar användare att registrera sina enheter. I det dokumenterade exemplet anger Set-ActiveSyncOrganizationSettings med -DefaultAccessLevel quarantine standardnivån för hela organisationen; -UserMailInsert lägger till en anpassningsbar registreringsanvisning i karantänmeddelandet. Denna artikel rekommenderar inte att kommandot körs. Förutsättningarna, konsekvenserna och den godkända återgångsvägen måste först klargöras.

Administrationskontexten skiljer sig åt: för lokal Exchange Server används Exchange Management Shell, för molnet en separat kontrollerad Exchange Online PowerShell-anslutning med rätt konto och en inloggnings-/transportväg som stöds. En lokal shell eller dess Basic-inställning ersätter inte en kontrollerad molnanslutning.

En organisationsomfattande Exchange-karantän är ingen pilotomkopplare för en enskild testenhet. Där Exchange ABQ faktiskt tillämpas kan en ändring från ”Allow” till ”Quarantine” omedelbart påverka redan anslutna EAS-enheter, inte bara nya eller okända, om ingen enhetsåtkomstregel eller individuell Allow-/Block-åtgärd gäller. Förutsätt inte den effekten på den kvalificerade Exchange Online/Outlook/Conditional Access-vägen ovan: Exchange ABQ-regler hoppas över där. I PowerShell-läge kan även redan registrerade enheter hamna i karantän om deras efterlevnadsstatus är okänd efter utebliven synkronisering eller vid en störd anslutning till Sophos Mobile, förutsatt att ABQ gäller deras väg. Automatisk tillåtelse efter en lyckad registrering förutsätter en fungerande kontrollförbindelse; den garanterar inte att ett fel avhjälps.

Före en godkänd ändring: dokumentera tidigare Exchange DefaultAccessLevel, aviseringstexten, befintliga enhetsåtkomstregler och individuella Allow-/Block-poster samt inventering av enheter och e-postappar, aktuell synkroniserings- och efterlevnadsstatus, certifikatförtroende och ansvariga. Observera tillåtna, okända och tillfälligt obestämbara enheter för testbrevlådor; granska tillgängliga Sophos-, Exchange- och Entra-händelser för beslut och anslutningsfel och verifiera att de kan kopplas till respektive enhet i måltenanten. Före ändringen, kontrollera med överenskomna testbrevlådor för varje berörd enhet att faktisk EAS-inloggning, sändning, mottagning och synkronisering fungerar; enbart händelser visar inte effekten. I Sophos-menyn My Products > Mobile > Setup > Sophos setup > EAS proxy visar värdet under External > Last active för varje proxyinstans endast dess senaste kontakt med Sophos Mobile, inte lyckad inloggning, leverans eller tillåtelse för varje enhet.

Den godkända återgångsvägen måste omfatta återställning av den dokumenterade standardåtkomstnivån, reglerna, de individuella besluten och aviseringstexten samt ansvarsfördelning och avbrottskriterier. Att bara återställa standardnivån bevisar inte att allt är återställt: Enheter kan fortfarande befinna sig i ett oväntat tillstånd; kontrollera efter återgången faktisk EAS-inloggning, sändning, mottagning och synkronisering individuellt för de berörda enheterna med de överenskomna testbrevlådorna, även efter inaktuell efterlevnadsstatus eller avbrott i Sophos kontrollanslutning. Tills autentisering, e-postväg och återgångsväg har verifierats och ändringen godkänts rekommenderar denna artikel varken installation, omställning till karantän eller migrering.