Accesso EAS con Sophos Mobile: distinguere la modalità proxy dalla modalità PowerShell

Il nome Sophos Mobile EAS Proxy indica due modalità diverse per controllare Exchange ActiveSync (EAS), il protocollo di sincronizzazione della posta su dispositivi mobili. Nella modalità proxy, le richieste EAS dei dispositivi configurati a tale scopo passano attraverso il proxy Sophos installato separatamente prima di raggiungere il server di posta. Nella modalità PowerShell, i dispositivi si collegano direttamente a Exchange; il servizio Sophos controlla l’accesso dei dispositivi tramite una connessione amministrativa separata. Confondere le due modalità può portare a pianificare percorsi di rete sbagliati o a trascurare una modifica all’accesso a Exchange. Questo articolo aiuta a prendere una decisione; non è una guida alla configurazione, alla migrazione o alla risoluzione dei problemi.

Fermarsi prima di una quarantena estesa all’organizzazione o di un passaggio in produzione: cambiare il livello di accesso predefinito di Exchange da «Allow» a «Quarantine» può avere effetti immediati sui dispositivi EAS già connessi, salvo che si applichi una regola di accesso ai dispositivi o una decisione individuale Allow/Block. Non effettuare il cambio senza aver documentato la situazione iniziale, verificato lo stato dei dispositivi e della conformità, dimostrato che l’autenticazione funziona e approvato una procedura di ripristino; non è un interruttore per un singolo dispositivo pilota.

Percorso decisionale: individuare prima il servizio di posta di destinazione e le app di posta che utilizzano effettivamente EAS. Per Exchange Server, la modalità proxy può essere considerata come percorso della posta; per Exchange Online, Sophos indica soltanto la modalità PowerShell con accesso diretto dei dispositivi. IBM Traveler è una destinazione proxy distinta. Confrontare le modalità solo per la rispettiva destinazione. Se non è possibile dimostrare l’identità dei dispositivi, l’autenticazione dei client, l’autenticazione amministrativa o il supporto del server di destinazione, fermarsi qui anziché dedurre un’approvazione dalla scelta della modalità.

Una migrazione o implementazione deve essere pianificata e approvata separatamente; in caso di problemi, consultare la diagnostica EAS.

Limite di licenza e piattaforma: queste indicazioni EAS riguardano la gestione dei dispositivi con Sophos Mobile, non una sola licenza Sophos Mobile Threat Defense. Prima di scegliere una modalità, verificare l’effettiva licenza Sophos Mobile o Sophos Mobile Device Management del tenant, la registrazione e la comunicazione dello stato di conformità di ogni dispositivo Android o iPhone/iPad previsto, nonché l’app e il protocollo di posta realmente utilizzati. Il piano Microsoft 365 Exchange Online citato da Sophos è un prerequisito del servizio di posta, non una prova della licenza Mobile o che i controlli EAS coprano la sincronizzazione nativa di Outlook. Non dedurre una copertura per i Mac o altri client non-EAS.

Da dove passa il traffico della posta mobile?

Limite per la privacy: in modalità proxy, il traffico di posta passa attraverso il proxy gestito separatamente; in modalità PowerShell, la posta non lo attraversa, ma Sophos tratta comunque l’identità del dispositivo e lo stato di conformità per decidere l’accesso. Nessuno dei due percorsi dimostra quali contenuti o metadati vengano registrati, archiviati o conservati. Prima dell’approvazione, verificare registrazione, accessi e conservazione nell’ambiente effettivo.

• Modalità proxy: dispositivo → Sophos Mobile EAS Proxy → server di posta supportato (per Exchange: Exchange Server locale; Sophos menziona anche IBM Traveler). Sui dispositivi occorre configurare il proxy come server di posta EAS per la posta in entrata e in uscita; questo non implica una configurazione SMTP separata. Il proxy si collega a Sophos Mobile tramite un’interfaccia web HTTPS, confronta l’identità del dispositivo e lo stato richiesto dalle policy e inoltra le richieste EAS idonee. È inoltre possibile configurarlo per bloccare determinati dispositivi; questa funzione va distinta dal controllo di conformità e dalle voci ABQ individuali di Exchange. Per questo percorso della posta tramite proxy, il server di posta effettivo non deve essere direttamente raggiungibile da Internet. Non è però una garanzia che ogni richiesta venga controllata: resta valida l’eccezione Traveler descritta sotto. Qui il proxy si trova sul percorso della posta: la sua disponibilità e capacità incidono sulla raggiungibilità della posta mobile.
• Modalità PowerShell: dispositivo → Exchange direttamente; separatamente, servizio EAS di Sophos Mobile → interfaccia di amministrazione di Exchange. Inoltre, il servizio Sophos si collega a Sophos Mobile tramite un’interfaccia web HTTPS. Il traffico della posta non passa attraverso il proxy Sophos; sul suo host non serve quindi una porta firewall per la posta in entrata. Occorre comunque pianificare la raggiungibilità di Exchange e le connessioni amministrative e di controllo. Sophos indica come destinazioni Exchange Server 2016/2019 e Microsoft 365 con piano Exchange Online. Questa indicazione di prodotto non dimostra ancora che la versione del proxy in uso, il client specifico, la sua autenticazione e il tenant funzionino oggi insieme. I criteri di dimensionamento del relay di posta della modalità proxy non sono trasferibili a questa modalità.

Percorsi di rete nell’esempio datato con certificati client: il diagramma architetturale di Sophos (pagina inglese del 12 aprile 2023, pagina tedesca del 27 aprile 2023) mostra Sophos Mobile, EAS Proxy ed Exchange all’interno di un’area delimitata da una linea tratteggiata e denominata «Customer»; i dispositivi sono all’esterno. È una topologia illustrata gestita dal cliente, non un requisito universale per le implementazioni Sophos Mobile né la prova di un confine firewall o DMZ. Oltre al percorso della posta EAS, esiste un percorso MDM separato dispositivo → Sophos Mobile tramite HTTPS; nel diagramma questo percorso di gestione dei dispositivi non passa attraverso EAS Proxy. È distinto dalla connessione di controllo HTTPS EAS Proxy → Sophos Mobile già descritta.

La tabella degli endpoint del diagramma riporta esclusivamente valori di esempio schematici, non endpoint operativi da adottare né autorizzazioni generali del firewall:

I nomi smc.company.com ed eas.company.com e le porte di destinazione appartengono a questo esempio. La freccia EAS Proxy → Exchange, invece, riporta solo l’etichetta http/s; non indica una porta del backend. Questo conserva la rappresentazione schematica HTTP/HTTPS, ma non richiede né autorizza in generale traffico backend non cifrato. Non consente neppure di dedurre dove termini TLS o quale sia l’attendibilità dei certificati. Gli endpoint effettivi, le porte e la connessione backend protetta devono essere verificati e approvati separatamente per il proprio ambiente; la direzione delle frecce non esclude il traffico di risposta. Il diagramma non amplia né i limiti di prodotto e versione indicati sotto né la matrice dei server di posta supportati.

Esempio Central con ambiente del cliente separato: un’altra architettura archiviata mostra Sophos Mobile in Central nell’area Sophos Central, mentre EAS proxy ed Exchange si trovano nell’area Customer. I dispositivi sono all’esterno di entrambe le aree. Il loro percorso MDM separato raggiunge Sophos Mobile in Central tramite HTTPS; il riquadro di testo indica central.sophos.com. Il percorso della posta ActiveSync raggiunge invece tramite HTTPS eas.company.com sul proxy EAS del cliente e da lì prosegue tramite http/s verso Exchange. Una freccia HTTPS distinta da EAS Proxy a Sophos Mobile in Central mostra inoltre la connessione di controllo attraverso il confine cliente/Central illustrato. MDM, posta e controllo del proxy sono quindi tre percorsi separati, non un unico percorso attraverso Central.

La tabella degli endpoint di questo esempio Central contiene una sola corrispondenza: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. Non indica né una porta di destinazione MDM per Central né una porta del backend Exchange. Anche qui i nomi host sono esempi schematici d’archivio, non endpoint operativi del proprio tenant. Le aree tratteggiate non dimostrano una disposizione di firewall o DMZ; da http/s non si deducono né un’autorizzazione al traffico non cifrato né informazioni sulla terminazione TLS.

Per la modalità proxy, Sophos descrive il supporto di più server di posta Exchange o Traveler, con un’istanza EAS Proxy per ciascun server.

Il dimensionamento di un singolo percorso della posta è un aspetto distinto: a questo scopo si possono eseguire istanze su più computer dietro un bilanciatore di carico. Sono previsti anche certificati client: si seleziona il certificato di un’autorità di certificazione (CA) e i certificati client devono derivare da tale CA. Nella modalità con certificati client illustrata da Sophos (esempio architetturale del 12 aprile 2023), EAS Proxy verifica i certificati client presentati rispetto al certificato CA selezionato e blocca sia i client privi di certificato client sia quelli con un certificato client non valido. Questa condizione di blocco documentata riguarda solo la modalità con certificati client illustrata; non dimostra né l’applicazione del blocco nella propria build né l’esecuzione di specifiche verifiche di invalidità o revoca. Questa autenticazione client è distinta dai certificati di connessione PowerShell caricati successivamente in Sophos Mobile. Istanze, bilanciamento del carico e attendibilità dei certificati vanno pianificati e verificati nell’ambiente specifico.

Bilanciamento del carico concreto nell’esempio archiviato: il diagramma del bilanciatore di carico mostra Sophos Mobile, un bilanciatore di carico, due proxy EAS ed Exchange all’interno di Customer, con i dispositivi all’esterno. Il percorso MDM dei dispositivi raggiunge direttamente Sophos Mobile (smc.company.com) tramite HTTPS; il percorso ActiveSync raggiunge il bilanciatore di carico (eas.company.com) tramite HTTPS. Dal bilanciatore partono due frecce distinte verso i due proxy, contrassegnate con l’etichetta comune http/s. Ogni proxy ha una propria connessione di controllo HTTPS a Sophos Mobile e un proprio percorso della posta http/s verso Exchange. In questa rappresentazione, quindi, il controllo non passa dal bilanciatore di carico a Sophos Mobile.

Le corrispondenze complete della tabella nell’immagine si possono leggere senza una tabella larga:

• MDM: https://smc.company.com/* → HTTPS → SMC Server:443; entrambi i campi successivi della tabella contengono -. L’asterisco fa parte dell’URL di esempio illustrato.
• 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.

La porta 81 indica qui le destinazioni proxy dietro il bilanciatore di carico, non Exchange. Per Exchange, l’immagine non riporta alcuna porta del backend. Questa rappresentazione schematica d’archivio non costituisce né un’autorizzazione generale del firewall né una prova di TLS offloading, inoltro dei certificati, affinità di sessione, Health Checks, uno specifico algoritmo di bilanciamento o alta disponibilità garantita. La corrispondenza tra porte frontend e proxy non sostituisce la pianificazione e l’approvazione delle connessioni effettive.

Distinguere l’immagine PowerShell dalle evidenze testuali: l’immagine Central-PowerShell archiviata mostra EAS Proxy nell’area Company, Sophos Mobile nell’area separata Sophos Central e, sotto, un’altra area priva di un nome visibile con Office 365 Exchange Online e outlook.office365.com. Tra Company e Sophos Central compaiono le etichette https e Query device compliance list. Accanto a EAS Proxy compare Needs PowerShell 3.0 or higher. È un’indicazione storica dell’immagine, non un requisito minimo valido oggi né una prova di supporto; resta determinante la verifica della build specifica e dell’host PowerShell richiesta sotto. In questi pixel archiviati, le frecce di collegamento non sono riconoscibili in modo affidabile. La distinzione già descritta tra percorso diretto della posta dei dispositivi e connessione amministrativa separata a Exchange è quindi un’affermazione documentata nel testo, non una direzione delle frecce ricavata dall’immagine. L’immagine non fornisce neppure porte numeriche o una tabella degli endpoint; l’etichetta dell’host non dimostra un percorso attuale di autenticazione o trasporto per Exchange Online.

Contestualizzare le indicazioni di dimensionamento datate: nelle Sizing Considerations del 14 aprile 2022, Sophos descrive un fabbisogno ridotto di CPU e memoria per EAS Proxy, indica la larghezza di banda come principale limite e raccomanda 1 CPU e 2 GB di memoria. Per le installazioni di grandi dimensioni, questa fonte raccomanda più istanze EAS Proxy dietro un bilanciatore di carico; nella modalità PowerShell questa architettura di relay della posta non è necessaria. Si tratta di una raccomandazione documentale datata, non di un benchmark, di un requisito minimo attuale dimostrato o di una garanzia di capacità. Verificare con il team operativo la build specifica, il carico di posta e i percorsi di rete disponibili, e convalidare il dimensionamento in un ambiente autorizzato prima dell’approvazione; questi valori da soli non autorizzano l’uso in produzione.

Prima della configurazione, concordare l’integrazione di rete con il team operativo: documentare separatamente il percorso della posta dei dispositivi, la connessione di controllo HTTPS a Sophos Mobile e l’eventuale connessione amministrativa a Exchange. Sophos elenca i server di posta supportati nella sezione Requirements delle note di rilascio di Mobile. Per il passaggio di consegne, confermare la matrice dei server di posta applicabile alla build prevista, la build di destinazione e il ciclo di vita; un elenco generico di prodotti non basta. I prerequisiti dell’host, della rete e dell’installazione appartengono alla verifica preliminare separata dell’installazione EAS, non a un’approvazione implicita derivata dalla scelta della modalità.

Entrambe le varianti controllano EAS, non qualsiasi protocollo di posta mobile. Sophos esclude i Mac da questo percorso di controllo motivandolo con la mancanza di supporto ActiveSync in macOS; ciò non costituisce un’affermazione su ogni possibile client di posta di terze parti su un Mac. Con IBM Traveler, le richieste dei dispositivi non iOS privi di ID dispositivo possono essere inoltrate senza che il proxy possa verificarne l’autorizzazione.

Nella modalità proxy, Outlook su Android/iOS può non riuscire ad associare utente e ID ActiveSync, ad esempio in presenza di più dispositivi ancora sconosciuti o quando una reinstallazione dell’app genera un nuovo ID ActiveSync che non corrisponde alla voce salvata. Non tutte le reinstallazioni devono provocare questo errore; non è dimostrato che lo stesso errore si verifichi nella modalità PowerShell. Secondo Sophos, questo specifico problema di associazione non si verifica con Gmail su Android e Mail su iOS, perché Sophos Mobile riceve il loro ID ActiveSync durante la registrazione. Ciò non esclude altri errori di posta. Verificare le app di posta, i protocolli e gli ID dispositivo effettivamente utilizzati in entrambe le modalità. In caso di failed to resolve active sync id, usare prima la diagnostica EAS per circoscrivere il problema in sola lettura. Un errore di associazione non autorizza né un reset dell’ID né una modifica dell’assegnazione dell’utente; concordare con il team operativo l’eventuale riparazione solo dopo aver identificato inequivocabilmente il dispositivo e ottenuto un’approvazione specifica.

Eccezione distinta per Exchange Online, Outlook e Conditional Access: quando un utente si autentica in Outlook per iOS o Android, secondo Microsoft le regole di accesso ai dispositivi mobili Allow/Block/Quarantine (ABQ) di Exchange Online vengono ignorate se un criterio Microsoft Entra Conditional Access applicato a quell’utente include Exchange Online o Office 365 come app cloud, iOS e/o Android come piattaforma, «Mobile apps and desktop client» come app client e almeno un controllo di concessione: richiedere un dispositivo conforme, un’app client approvata o un criterio di protezione delle app. Non vale per tutti gli utenti Outlook né per tutti i criteri Conditional Access; quest’ultimo può comunque limitare l’accesso. Microsoft avverte che ABQ da solo non offre garanzie di sicurezza: un client che falsifica l’intestazione DeviceType potrebbe aggirare il blocco di uno specifico tipo di dispositivo. Per Exchange Online verificare inoltre i criteri e le regole di accesso di Basic Mobility and Security: dopo la registrazione a tale servizio prevalgono per il dispositivo sui criteri delle cassette postali mobili e sulle regole di accesso ai dispositivi di Exchange. Non trattare né una decisione ABQ né l’assenza di questa specifica eccezione Conditional Access come un confine di sicurezza. È un’eccezione distinta dal problema di associazione dell’ID ActiveSync di Outlook nella modalità proxy sopra descritto. Per Exchange Online, Microsoft descrive la sincronizzazione nativa di Outlook per iOS e Android, non EAS; verificare il protocollo effettivo del client prima di attribuire l’accesso ai controlli EAS. Le verifiche dell’autenticazione EAS riportate sotto valgono solo per i client che usano realmente EAS; per gli altri, testare l’autenticazione e il percorso dei dati dell’app di posta effettiva. Su questo percorso qualificato non presumere che le decisioni ABQ di Exchange gestite da Sophos o la quarantena impongano l’accesso solo perché funziona la connessione amministrativa PowerShell. Prima di raccomandare l’architettura, controllare nel tenant di destinazione l’identità dell’utente, l’app di posta, le condizioni Conditional Access effettive per app cloud/piattaforma/app client/concessione e la decisione di accesso Exchange per il dispositivo; verificare con test autorizzati autenticazione, invio, ricezione e sincronizzazione reali di ogni dispositivo rappresentativo.

Valutare separatamente Exchange Online e il ciclo di vita dei server

Exchange Online – nessun ritorno a Basic: Microsoft ha disattivato Basic Authentication per l’autenticazione dei client EAS e per Remote PowerShell in tutti i tenant; non è possibile riattivarla per questi usi. Un eventuale fallback a Basic non riparerebbe quindi né l’autenticazione amministrativa né quella di un’app di posta EAS che utilizza Basic. La guida di configurazione Sophos del 9 settembre 2026 non descrive un flusso «autenticazione moderna, Basic in caso di errore»; dalla sua assenza non si può però dedurre un altro flusso di autenticazione del servizio. Il testo di configurazione Sophos menziona ancora /powershell-liveid; Microsoft supporta connessioni REST per Exchange Online PowerShell. Ciò non chiarisce se una determinata build Sophos utilizzi quel percorso. L’istruzione Sophos relativa a Basic nella directory PowerShell di Exchange locale non è una procedura per Exchange Online. Non abilitare Basic o WinRM Basic come rimedio per Exchange Online.

Exchange Online – verificare TLS e autenticazione separatamente: l’opzione Sophos «Allow all certificates» disabilita la verifica del certificato del server e indebolisce la sicurezza della connessione; non dimostra la disponibilità di un percorso amministrativo TLS o REST supportato e non risolve la disattivazione di Basic. Verificare l’attendibilità del certificato e la connessione TLS senza aggirare la verifica dei certificati. Per il proprio ambiente, richiedere a Sophos la conferma della compatibilità della build specifica del proxy, della versione del modulo ExchangeOnlineManagement, dell’host PowerShell effettivamente utilizzato dal servizio e della relativa versione, della versione di Windows e della versione di .NET Framework o .NET secondo la matrice Microsoft per modulo, host e sistema operativo, del cloud, del percorso amministrativo OAuth/REST, delle autorizzazioni dell’account, nonché di MFA e Conditional Access; né l’installazione di un modulo né una versione adeguata dell’host dimostrano quale trasporto utilizzi effettivamente il servizio Sophos o che la sua autenticazione funzioni. In un tenant di test autorizzato servono due verifiche separate: il servizio riesce ad amministrare Exchange (connessione e autorizzazioni)? E i dispositivi previsti riescono ad autenticarsi a EAS e a sincronizzare con la loro effettiva app di posta? Una connessione amministrativa riuscita non dimostra l’accesso alla posta.

Exchange Server locale: la guida di configurazione Sophos richiede di attivare BasicAuthentication per il percorso della directory PowerShell di Exchange locale. Questo non dimostra che ogni connessione amministrativa locale utilizzi sempre Basic; non riguarda né l’autenticazione EAS dei client né Exchange Online e non costituisce un’approvazione generale per abilitare Basic in locale. L’autenticazione e il rafforzamento della sicurezza locali richiedono un’approvazione di sicurezza separata. Sophos indica Exchange 2016/2019; il supporto ordinario Microsoft per entrambi è terminato il 14 ottobre 2025. Exchange Server Subscription Edition (SE) non è incluso in tale indicazione di Sophos. Un’opzione di migrazione Microsoft non equivale a una certificazione Sophos. Ottenere separatamente conferma della build del server, del ciclo di vita o di eventuali accordi speciali e dell’approvazione Sophos per questa precisa destinazione, anziché dedurre un’approvazione per la produzione da un diagramma architetturale.

Che cosa comprende la configurazione PowerShell approvata

La configurazione PowerShell comprende la preparazione dell’host, un account di servizio Exchange dedicato, la connessione dell’istanza e l’associazione dei relativi certificati. I passaggi e i campi documentati qui sotto aiutano nel passaggio di consegne al team operativo; non sostituiscono né la verifica della build specifica e del percorso di autenticazione né una modifica approvata. La verifica preliminare separata dell’installazione EAS tratta la verifica dell’host, dell’account di servizio e dell’installazione, ma neppure questa è una procedura di configurazione approvata. Non modificare criteri di esecuzione, impostazioni Basic locali, impostazioni proxy di sistema o riavviare servizi sulla sola base di questo articolo. Documentare e approvare separatamente la situazione iniziale, gli effetti e la procedura di ripristino.

Host, Exchange locale e account di servizio

• Sull’host EAS: Sophos indica, se necessaria, l’installazione di Windows PowerShell. Prima di installarlo, concordarne versione e idoneità con il team operativo per la build specifica. La guida descrive poi la modifica del criterio di esecuzione a RemoteSigned in una PowerShell aperta come amministratore. Questa preparazione non dimostra ancora quale host PowerShell utilizzi il servizio Sophos o se sia compatibile con esso.
• Solo con Exchange Server locale: nella Exchange Management Shell, Sophos descrive un passaggio RemoteSigned separato e poi l’individuazione della directory PowerShell effettiva con Get-PowerShellVirtualDirectory -Server <server name>. Il segnaposto indica il nome del computer Exchange Server, non l’host EAS o il nome dell’istanza. Sophos indica PowerShell (Default Web Site) come directory solo per un’installazione standard. Nella guida ufficiale, solo dopo questa individuazione si procede all’attivazione di BasicAuthentication per la directory virtuale interessata. Questa modifica resta riservata alla configurazione locale approvata separatamente; è espressamente esclusa dalla configurazione di Exchange Online.
• Account di servizio: Sophos utilizza un account utente dedicato sul server di posta Exchange per eseguire comandi PowerShell. La creazione è diversa per Exchange Server e Exchange Online; concordare con il team Exchange la creazione dell’account, le autorizzazioni e il metodo di autenticazione per la destinazione specifica nell’ambito della verifica preliminare dell’installazione EAS. Un campo password non basta a chiarire questi aspetti; non creare qui né account né ruoli.

Assistente di connessione e completamento

La connessione viene predisposta nell’assistente di installazione; la sua esecuzione resta riservata alla modifica di installazione approvata separatamente. In EAS Proxy instance setup sono documentati questi campi:

• Instance type: PowerShell Exchange/Office 365.
• Instance name: un nome scelto liberamente per identificare inequivocabilmente l’istanza.
• Exchange server: per Exchange locale, il nome del server o il suo indirizzo IP; per il servizio Microsoft 365 globale, Sophos indica outlook.office365.com. Per altri cloud, confermare separatamente con il team Exchange l’endpoint di connessione appropriato; Sophos rimanda alla corrispondenza -ConnectionUri di Connect-ExchangeOnline. Secondo Sophos, https:// e /powershell-liveid non vanno inseriti in questo campo perché li aggiunge l’assistente. Questo documenta il comportamento del campo, non un trasporto Exchange Online verificato per il 2026. Non ipotizzare un endpoint alternativo; restano necessarie le verifiche di build, cloud e autenticazione richieste sopra.
• Service account e Password: nome e password dell’account di servizio creato in precedenza. Non riportare credenziali in file di audit, esempi o ticket; i campi, da soli, non dimostrano un metodo di autenticazione.

Con Add, la connessione viene aggiunta all’elenco Instances. Per ulteriori istanze Exchange Server, Sophos descrive la ripetizione di questa configurazione e poi il completamento dell’assistente. Anche con questa panoramica dei campi, l’opzione Allow all certificates non è una scorciatoia raccomandata: verificare l’attendibilità dei certificati anziché disattivare la verifica del server.

Proxy di connessione in uscita opzionale: se l’host EAS deve raggiungere Exchange Server o Exchange Online tramite un proxy di rete, Sophos descrive un passaggio WinHTTP sull’host EAS in un prompt dei comandi aperto con Run as administrator. La configurazione WinHTTP concreta resta di competenza del team operativo e della modifica di installazione approvata a tale scopo; non è una modalità proxy per la posta dei dispositivi. L’impostazione ha effetto sull’intero sistema e può interessare altri programmi sull’host Windows. Prima di modificarla, documentare anche per queste dipendenze la situazione iniziale e una procedura di ripristino approvata; non ne deriva un rimedio proxy generico per gli errori di autenticazione.

Per concludere, Sophos descrive il caricamento del certificato di connessione PowerShell generato durante la configurazione in My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. Se sono presenti più istanze, si caricano tutti i certificati delle istanze, quindi si seleziona Save e si esegue un riavvio approvato di EASProxy nella finestra Windows Services. Concordare con il team operativo finestra di manutenzione, stato del servizio e procedura di ripristino. Certificati salvati o un nuovo valore Last active non dimostrano né l’autenticazione riuscita dei dispositivi né la consegna della posta: autenticazione, invio, ricezione e sincronizzazione vanno ancora verificati per ogni dispositivo interessato prima e dopo la modifica.

Prima di qualsiasi modifica all’accesso EAS

Con una connessione di controllo PowerShell già configurata e verificata, è possibile configurare Exchange affinché i dispositivi non registrati in Sophos Mobile vengano messi in quarantena e non possano accedere alla posta. Questo vale solo dove i limiti di protocollo e ABQ descritti sopra consentono tale controllo. Il blocco dei dispositivi non registrati è una modifica dell’accesso distinta, estesa all’organizzazione e di competenza del team operativo Exchange/Mobile, non il completamento dell’installazione. La verifica preliminare architetturale e di sicurezza segue qui; la configurazione della connessione di controllo appartiene alla verifica preliminare separata dell’installazione EAS. Sophos descrive una notifica Exchange che invita gli utenti a registrarsi. Nell’esempio documentato, Set-ActiveSyncOrganizationSettings con -DefaultAccessLevel quarantine imposta il valore predefinito per l’intera organizzazione; -UserMailInsert aggiunge alla mail di quarantena un messaggio di registrazione personalizzabile. Questo articolo non raccomanda di eseguire il comando. Occorre chiarire prima prerequisiti, effetti e procedura di ripristino approvata.

Il contesto amministrativo è diverso: per Exchange Server locale è prevista la Exchange Management Shell, per il cloud una connessione Exchange Online PowerShell verificata separatamente, con un account adeguato e un percorso di autenticazione e trasporto supportato. Una shell locale o la sua impostazione Basic non sostituiscono una connessione cloud verificata.

Una quarantena di Exchange estesa all’organizzazione non è un interruttore pilota per un singolo dispositivo di test. Dove Exchange ABQ è effettivamente applicato, passare da «Allow» a «Quarantine» può interessare immediatamente dispositivi EAS già connessi, non solo quelli nuovi o sconosciuti, salvo che si applichi una regola di accesso o una decisione individuale Allow/Block. Non presumere questo effetto sul percorso Exchange Online/Outlook/Conditional Access qualificato sopra descritto: lì le regole ABQ di Exchange vengono ignorate. Nella modalità PowerShell anche i dispositivi già registrati possono finire in quarantena se il loro stato di conformità è sconosciuto dopo una mancata sincronizzazione o quando la connessione a Sophos Mobile è interrotta, purché ABQ si applichi al loro percorso. L’approvazione automatica dopo la registrazione riuscita presuppone un percorso di controllo funzionante; non garantisce il ripristino del servizio.

Prima di una modifica approvata, documentare il precedente Exchange DefaultAccessLevel, il testo delle notifiche, le regole di accesso ai dispositivi e le voci individuali Allow/Block esistenti, nonché l’inventario dei dispositivi e delle app di posta, lo stato attuale di sincronizzazione e conformità, l’attendibilità dei certificati e i responsabili. Osservare sui conti di posta di test i dispositivi consentiti, sconosciuti e temporaneamente non valutabili; verificare gli eventi Sophos, Exchange ed Entra disponibili relativi a decisioni ed errori di connessione, e confermare la loro associazione al rispettivo dispositivo nel tenant di destinazione. Prima della modifica, con i conti di posta di test concordati, verificare per ogni dispositivo interessato l’effettiva autenticazione EAS, l’invio, la ricezione e la sincronizzazione; i soli eventi non dimostrano l’impatto. Nel menu Sophos My Products > Mobile > Setup > Sophos setup > EAS proxy, il valore External > Last active indica per ciascuna istanza proxy soltanto il suo ultimo contatto con Sophos Mobile, non la riuscita dell’autenticazione, della consegna o dell’autorizzazione di ogni dispositivo.

La procedura di ripristino approvata deve prevedere il ripristino del livello di accesso predefinito documentato, delle regole, delle decisioni individuali e del testo delle notifiche, oltre a responsabilità e criteri di interruzione. Ripristinare soltanto il valore predefinito non dimostra che il servizio sia stato ripristinato: i dispositivi possono restare in uno stato inatteso; dopo il ripristino, verificare individualmente con i conti di posta di test concordati l’effettiva autenticazione EAS, l’invio, la ricezione e la sincronizzazione dei dispositivi interessati, anche dopo uno stato di conformità obsoleto o un’interruzione della connessione di controllo Sophos. Finché autenticazione, percorso della posta e procedura di ripristino non sono dimostrati e la modifica non è approvata, questo articolo non raccomanda né l’installazione né il passaggio alla quarantena né la migrazione.