Acceso EAS de Sophos Mobile: diferencias entre los modos proxy y PowerShell
El nombre Sophos Mobile EAS Proxy designa dos formas distintas de controlar Exchange ActiveSync (EAS), el protocolo de sincronización del correo móvil. En modo proxy, las solicitudes EAS de los dispositivos configurados para ello pasan por el proxy de Sophos, instalado por separado, antes de llegar al servidor de correo. En modo PowerShell, los dispositivos se conectan directamente a Exchange; el servicio de Sophos controla el acceso de los dispositivos mediante una conexión de administración independiente. Confundir estas dos vías puede llevar a planificar rutas de red equivocadas o a pasar por alto un cambio en el acceso a Exchange. Este artículo ayuda a tomar una decisión; no es una guía de configuración, migración ni reparación.
Deténgase antes de activar una cuarentena para toda la organización o de efectuar un cambio en producción: cambiar el nivel de acceso predeterminado de Exchange de «Allow» a «Quarantine» puede afectar inmediatamente a dispositivos EAS que ya están conectados, salvo que se les aplique una regla de acceso de dispositivos o una decisión individual de Allow/Block. No haga el cambio sin documentar la situación inicial, comprobar los dispositivos y sus estados de cumplimiento, verificar el inicio de sesión y contar con un procedimiento de reversión aprobado; no es un interruptor de prueba para un único dispositivo piloto.
Ruta de decisión: determine primero el servicio de correo de destino y las aplicaciones de correo EAS realmente utilizadas. Para Exchange Server, el modo proxy puede servir como ruta del correo; para Exchange Online, Sophos solo indica el modo PowerShell, con acceso directo desde los dispositivos. IBM Traveler es otro destino distinto para el proxy. Compare los modos únicamente para el destino correspondiente. Si no puede demostrar la identidad del dispositivo, la autenticación del cliente, la autenticación administrativa o la compatibilidad con el servidor de destino, deténgase aquí en lugar de inferir una autorización a partir de la elección del modo.
Una migración o implementación debe planificarse y autorizarse por separado; para incidencias, consulte diagnóstico de EAS.
Límite de licencia y plataforma: estas indicaciones EAS corresponden a la gestión de dispositivos con Sophos Mobile, no a una licencia exclusiva de Sophos Mobile Threat Defense. Antes de elegir un modo, compruebe la licencia real Sophos Mobile o Sophos Mobile Device Management del tenant, la inscripción y la comunicación del estado de cumplimiento de cada dispositivo Android o iPhone/iPad previsto, así como su aplicación y protocolo de correo reales. El plan Microsoft 365 Exchange Online citado por Sophos es un requisito del servicio de correo, no una prueba de licencia Mobile ni de que los controles EAS abarquen la sincronización nativa de Outlook. No infiera cobertura para Mac u otros clientes que no usen EAS.
¿Por dónde circula el correo móvil?
Límite de privacidad: En modo proxy, el tráfico de correo pasa por el proxy operado por separado; en modo PowerShell, el correo no pasa por él, pero Sophos sigue tratando la identidad del dispositivo y su estado de cumplimiento para decidir el acceso. Ninguna de las dos rutas demuestra qué contenido o metadatos se registran, almacenan o conservan. Antes de aprobar el cambio, compruebe el registro, el acceso y la conservación de datos en el entorno real.
- Modo proxy: dispositivo → Sophos Mobile EAS Proxy → servidor de correo compatible (en el caso de Exchange, Exchange Server local; Sophos también menciona IBM Traveler). En los dispositivos, el proxy debe estar configurado como servidor de correo EAS para el correo entrante y saliente; esto no implica una configuración SMTP independiente. El proxy se conecta a Sophos Mobile mediante una interfaz web HTTPS, coteja la identidad del dispositivo y el estado exigido de las políticas y reenvía las solicitudes EAS que cumplen los requisitos. Además, puede configurarse para bloquear determinados dispositivos; esto es distinto de la comprobación de cumplimiento y de las entradas individuales ABQ de Exchange. El servidor de correo real no necesita ser accesible directamente desde Internet para esta ruta de correo a través del proxy. Esto no garantiza que se comprueben todas las solicitudes: sigue existiendo la excepción de Traveler descrita más adelante. Aquí el proxy está en la ruta del correo: sus fallos y su capacidad afectan a la disponibilidad del correo móvil.
- Modo PowerShell: dispositivo → Exchange directamente; por separado, servicio EAS de Sophos Mobile → interfaz de administración de Exchange. Además, el servicio de Sophos se conecta a Sophos Mobile mediante una interfaz web HTTPS. El tráfico de correo no pasa por el proxy de Sophos; por ello, su host no necesita un puerto de firewall para correo entrante. Aun así, hay que planificar la accesibilidad de Exchange y las conexiones de administración y control. Sophos menciona como destinos Exchange Server 2016/2019 y Microsoft 365 con un plan de Exchange Online. Esta indicación del producto no demuestra que la versión del proxy disponible, el cliente concreto, su autenticación y el tenant funcionen juntos actualmente. Los cálculos de capacidad del relay de correo del modo proxy no pueden trasladarse a este modo.
Rutas de red en el ejemplo fechado de certificados de cliente: El diagrama de arquitectura de Sophos (página inglesa del 12 de abril de 2023, página alemana del 27 de abril de 2023) muestra Sophos Mobile, EAS Proxy y Exchange dentro de un entorno del cliente delimitado por una línea discontinua y rotulado «Customer»; los dispositivos quedan fuera. Representa una topología operada por el cliente, no un requisito universal para los despliegues de Sophos Mobile ni una prueba de un límite de firewall o DMZ. Además de la ruta de correo EAS, hay una ruta MDM independiente: dispositivo → Sophos Mobile mediante HTTPS; en el diagrama, esta ruta de administración de dispositivos no pasa por EAS Proxy. También es distinta de la conexión de control HTTPS EAS Proxy → Sophos Mobile descrita anteriormente.
La tabla de puntos de conexión del diagrama contiene únicamente valores de ejemplo esquemáticos, no puntos de conexión que deban adoptarse en producción ni autorizaciones generales de firewall:
| Ruta del dispositivo representada | Ejemplo de URL externa | Protocolo y destino en el diagrama |
|---|---|---|
| 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 |
Los nombres smc.company.com y eas.company.com, así como los puertos de destino, pertenecen a este ejemplo. En cambio, la flecha EAS Proxy → Exchange solo lleva la etiqueta http/s; no se indica un puerto de backend. Esto conserva la representación esquemática de HTTP/HTTPS, pero no exige tráfico de backend sin cifrar ni lo autoriza de forma general. Tampoco permite deducir dónde termina TLS ni qué confianza existe en los certificados. Los puntos de conexión y puertos reales y la conexión protegida al backend deben comprobarse y autorizarse por separado para el entorno propio; las direcciones de las flechas no excluyen el tráfico de respuesta. El diagrama no amplía los límites de producto y versión indicados más abajo ni la matriz de servidores de correo compatibles.
Ejemplo de Central con un entorno del cliente separado: Otra arquitectura archivada muestra Sophos Mobile in Central dentro del área Sophos Central, mientras que EAS proxy y Exchange se encuentran en el área Customer. Los dispositivos están fuera de ambas áreas. Su ruta MDM independiente llega mediante HTTPS a Sophos Mobile in Central; el recuadro de texto indica para ello central.sophos.com. En cambio, la ruta de correo ActiveSync llega mediante HTTPS a eas.company.com, en el EAS Proxy del cliente, y desde allí mediante http/s a Exchange. Además, una flecha HTTPS independiente desde EAS Proxy hasta Sophos Mobile in Central muestra la conexión de control que atraviesa el límite representado entre el cliente y Central. MDM, correo y control del proxy son, por tanto, tres rutas distintas, no una única ruta a través de Central.
La tabla de puntos de conexión de este ejemplo de Central contiene exactamente una correspondencia: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. No indica un puerto de destino MDM de Central ni un puerto de backend de Exchange. También aquí los nombres de host son ejemplos esquemáticos del archivo, no puntos de conexión operativos del propio tenant. Las áreas delimitadas por líneas discontinuas no demuestran una disposición de firewall o DMZ; http/s no implica ni una autorización para tráfico sin cifrar ni información sobre la terminación de TLS.
Para el modo proxy, Sophos describe varios servidores de correo Exchange o Traveler compatibles, con una instancia de EAS Proxy por servidor de correo.
La ampliación de capacidad de una ruta de correo es otro aspecto distinto: pueden utilizarse instancias en varios equipos detrás de un balanceador de carga. También se contemplan certificados de cliente: se selecciona un certificado de una autoridad de certificación (CA); los certificados de cliente deben derivarse de esa CA. En el modo de certificados de cliente ilustrado por Sophos (ejemplo de arquitectura del 12 de abril de 2023), EAS Proxy comprueba los certificados de cliente presentados frente al certificado de CA seleccionado y bloquea tanto a los clientes sin certificado de cliente como a los que presentan uno no válido. Esta condición de bloqueo documentada se limita al modo de certificados de cliente ilustrado; no demuestra que se aplique en la compilación propia ni que se realicen comprobaciones concretas de invalidez o revocación. Esta autenticación de cliente es distinta de los certificados de conexión PowerShell que se cargan posteriormente en Sophos Mobile. Las instancias, el reparto de carga y la confianza en los certificados deben planificarse y probarse para el entorno concreto.
Reparto de carga concreto en el ejemplo archivado: El diagrama del balanceador de carga muestra Sophos Mobile, un balanceador de carga, dos EAS Proxy y Exchange dentro de Customer, y los dispositivos fuera. La ruta MDM de los dispositivos llega mediante HTTPS directamente a Sophos Mobile (smc.company.com); la ruta ActiveSync de los dispositivos llega mediante HTTPS al balanceador de carga (eas.company.com). Desde el balanceador de carga salen dos flechas independientes hacia los dos proxies, rotuladas conjuntamente con http/s. Cada proxy tiene su propia conexión de control HTTPS con Sophos Mobile y su propia ruta de correo http/s hacia Exchange. Por tanto, en esta representación el control no va del balanceador de carga a Sophos Mobile.
Las correspondencias completas de la tabla de la imagen pueden leerse sin una tabla ancha:
- MDM:
https://smc.company.com/*→ HTTPS →SMC Server:443; los dos campos posteriores de la tabla contienen-. El asterisco forma parte del ejemplo de URL representado. - 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.
Aquí el puerto 81 corresponde a los destinos proxy detrás del balanceador de carga, no a Exchange. La imagen no contiene ningún puerto de backend para Exchange. Esta representación esquemática archivada no constituye una autorización general de firewall ni demuestra descarga de TLS, transferencia de certificados, persistencia de sesiones, Health Checks, un algoritmo de reparto de carga concreto ni alta disponibilidad garantizada. La correspondencia entre los puertos de frontend y de proxy no sustituye la planificación y autorización de las conexiones reales.
Distinguir la imagen de PowerShell de la evidencia textual: La imagen archivada de Central y PowerShell muestra EAS Proxy en el área Company, Sophos Mobile en el área separada Sophos Central y, debajo, un área independiente sin nombre visible que contiene Office 365 Exchange Online y outlook.office365.com. Entre Company y Sophos Central figuran las etiquetas https y Query device compliance list. Junto a EAS Proxy figura Needs PowerShell 3.0 or higher. Es una indicación histórica de la imagen, no un requisito mínimo vigente ni una prueba de compatibilidad actual; sigue siendo decisiva la comprobación de la compilación y del host PowerShell concretos exigida más abajo. En estos píxeles archivados no se distinguen de forma fiable las flechas de conexión. Por tanto, la separación descrita anteriormente entre la ruta directa de correo del dispositivo y la conexión independiente de administración de Exchange es una afirmación documentada en el texto, no una dirección de flecha deducida de esta imagen. La imagen tampoco aporta puertos numéricos ni una tabla de puntos de conexión; la etiqueta del host no demuestra una ruta actual de autenticación o transporte de Exchange Online.
Interpretar la recomendación de dimensionamiento según su fecha: En las Sizing Considerations del 14 de abril de 2022, Sophos describe un consumo reducido de CPU y memoria de EAS Proxy, señala el ancho de banda como principal limitación y recomienda 1 CPU y 2 GB de memoria RAM. Para instalaciones grandes, esta fuente recomienda varias instancias de EAS Proxy detrás de un balanceador de carga; esta disposición de relay de correo no es necesaria en modo PowerShell. Es una recomendación documental fechada, no un benchmark, un mínimo vigente demostrado ni una garantía de capacidad. Comprobar con el equipo de operaciones la compilación concreta, la carga de correo y las rutas de red disponibles, y validar el dimensionamiento en un entorno autorizado antes de aprobarlo; estos valores por sí solos no autorizan el uso en producción.
Antes de la configuración, acordar la integración de red con el equipo de operaciones: documentar por separado la ruta del correo de los dispositivos, la conexión de control HTTPS con Sophos Mobile y, si procede, la conexión de administración de Exchange. Sophos enumera los servidores de correo compatibles en Requirements de las notas de versión de Mobile. Para la entrega al equipo, hay que confirmar la matriz de servidores de correo aplicable a la compilación prevista, la compilación de destino y su ciclo de vida; una lista general de productos no basta. Los requisitos del host, la red y la instalación corresponden a la comprobación previa de instalación de EAS, no a una autorización implícita derivada de esta elección de modo.
Ambas variantes controlan EAS, no cualquier protocolo de correo móvil. Sophos excluye los Mac de este mecanismo de control por la falta de compatibilidad con ActiveSync en macOS; esto no es una afirmación sobre todos los posibles clientes de correo de terceros en un Mac. Con IBM Traveler, las solicitudes de dispositivos que no son iOS y carecen de ID de dispositivo pueden pasar sin que el proxy pueda comprobar su autorización.
En modo proxy, Outlook para Android/iOS puede fallar al asociar el usuario con el ID de ActiveSync, por ejemplo si hay varios dispositivos aún desconocidos o si una reinstalación de la aplicación genera un nuevo ID de ActiveSync que no coincide con el registro guardado. No todas las reinstalaciones tienen que provocar este error; esto tampoco demuestra que exista el mismo fallo en modo PowerShell. Según Sophos, este problema concreto de asociación no se produce con Gmail en Android ni Mail en iOS, porque Sophos Mobile obtiene sus ID de ActiveSync durante la inscripción. Esto no descarta otros fallos de correo. Compruebe las aplicaciones de correo, los protocolos y los ID de dispositivo realmente utilizados en ambos modos. Ante failed to resolve active sync id, use primero el diagnóstico de EAS para acotar el problema mediante comprobaciones de solo lectura. Un error de asociación no autoriza a restablecer el ID ni a cambiar la asignación de usuario; cualquier reparación necesaria debe acordarse con el equipo de operaciones únicamente tras identificar inequívocamente el dispositivo y obtener una autorización independiente.
Excepción distinta para Exchange Online, Outlook y Conditional Access: cuando un usuario se autentica en Outlook para iOS o Android, Microsoft indica que se omiten las reglas de acceso a dispositivos móviles Allow/Block/Quarantine (ABQ) de Exchange Online si una directiva de Microsoft Entra Conditional Access aplicable a ese usuario incluye Exchange Online u Office 365 como aplicación en la nube, iOS y/o Android como plataforma, «Mobile apps and desktop client» como aplicaciones cliente y al menos un control de concesión: exigir un dispositivo conforme, una aplicación cliente aprobada o una directiva de protección de aplicaciones. No afecta a todos los usuarios de Outlook ni a todas las directivas de Conditional Access; este último puede seguir restringiendo el acceso. Microsoft advierte que ABQ por sí solo no ofrece garantías de seguridad: un cliente que falsifique la cabecera DeviceType podría eludir el bloqueo de un tipo de dispositivo concreto. En Exchange Online, compruebe también las directivas y reglas de acceso de Basic Mobility and Security: tras inscribirse en ese servicio, prevalecen para el dispositivo sobre las directivas de buzón para dispositivos móviles y las reglas de acceso a dispositivos de Exchange. No considere una decisión ABQ ni la ausencia de esta excepción concreta de Conditional Access como una barrera de seguridad. No es el problema de asociación del ID de ActiveSync de Outlook en modo proxy descrito arriba. Para Exchange Online, Microsoft describe la sincronización nativa de Outlook para iOS y Android, no EAS; compruebe el protocolo real del cliente antes de atribuir el acceso a controles EAS. Las comprobaciones de inicio de sesión EAS siguientes solo corresponden a clientes que realmente usan EAS; para otros, pruebe el inicio de sesión y la ruta de datos de su aplicación de correo. Para esa ruta concreta, no suponga que las decisiones ABQ de Exchange respaldadas por Sophos ni la cuarentena controlan el acceso solo porque funcione la conexión administrativa PowerShell. Antes de recomendar la arquitectura, compruebe en el tenant de destino la identidad del usuario, la aplicación de correo, las condiciones efectivas de Conditional Access para aplicación en la nube/plataforma/aplicación cliente/concesión y la decisión de acceso del dispositivo en Exchange; verifique con pruebas autorizadas el inicio de sesión, envío, recepción y sincronización reales de cada dispositivo representativo.
Evaluar por separado Exchange Online y el ciclo de vida del servidor
Exchange Online: no existe una vía de retorno a Basic: Microsoft ha desactivado Basic Authentication para los inicios de sesión de clientes EAS y para Remote PowerShell en todos los tenants; no puede volver a activarse para esos usos. Una alternativa Basic no repararía ni la autenticación administrativa ni una aplicación de correo EAS que use Basic. La guía de configuración de Sophos del 9 de septiembre de 2026 no describe una secuencia de «autenticación moderna y, si falla, Basic»; su ausencia tampoco permite deducir otro procedimiento de autenticación del servicio. El texto de configuración de Sophos todavía menciona /powershell-liveid; Microsoft admite conexiones REST para Exchange Online PowerShell. Esto no aclara si una compilación concreta de Sophos utiliza esa vía. La indicación de Sophos sobre Basic en el directorio PowerShell de un Exchange local no es una instrucción para Exchange Online. No active Basic ni WinRM Basic como solución para Exchange Online.
Exchange Online: comprobar TLS y la autenticación por separado: la opción de Sophos «Allow all certificates» desactiva la comprobación del certificado del servidor y debilita la seguridad de la conexión; no demuestra que exista una vía administrativa TLS o REST compatible ni resuelve la retirada de Basic. Compruebe la confianza en el certificado y la conexión TLS; no eluda la verificación del certificado. Solicite a Sophos confirmación, para su entorno, de la compatibilidad de la compilación concreta del proxy, la versión del módulo ExchangeOnlineManagement, el host PowerShell y la versión que usa realmente el servicio, la versión de Windows y la versión de .NET Framework o .NET conforme a la matriz de Microsoft para módulo, host y sistema operativo, la nube, la vía administrativa OAuth/REST, los permisos de la cuenta, así como MFA y Conditional Access; ni instalar el módulo ni disponer de una versión adecuada del host demuestra qué transporte usa realmente el servicio de Sophos o si su autenticación funciona. En un tenant de prueba autorizado hacen falta dos comprobaciones independientes: ¿puede el servicio administrar Exchange (conexión y permisos) y pueden los dispositivos previstos iniciar sesión en EAS y sincronizar con su aplicación de correo real? Una conexión administrativa correcta no demuestra que funcione el acceso al correo.
Exchange Server local: La guía de configuración de Sophos exige activar BasicAuthentication para la ruta del directorio PowerShell de Exchange local. Esto no demuestra que todas las conexiones administrativas locales utilicen siempre Basic; no afecta ni a la autenticación de clientes EAS ni a Exchange Online, y no constituye una autorización general para activar Basic localmente. La autenticación y el endurecimiento locales requieren una aprobación de seguridad independiente. Sophos menciona Exchange 2016/2019; el soporte ordinario de Microsoft para ambos finalizó el 14 de octubre de 2025. Exchange Server Subscription Edition (SE) no figura en esa indicación de Sophos. Una opción de migración de Microsoft no equivale a una certificación de Sophos. Obtenga por separado la compilación del servidor, su situación en el ciclo de vida o posibles acuerdos especiales y la aprobación de Sophos para ese destino preciso, en vez de deducir una autorización para producción de un diagrama de arquitectura.
Qué incluye una configuración PowerShell autorizada
La configuración PowerShell comprende la preparación del host, una cuenta de servicio dedicada de Exchange, la conexión de la instancia y la asignación de su certificado. Los siguientes pasos y campos documentados facilitan la entrega al equipo de operaciones; no sustituyen la comprobación de la compilación y la vía de autenticación concretas ni un cambio aprobado. La comprobación previa de instalación de EAS se ocupa por separado del host, la cuenta de servicio y los requisitos de instalación, pero tampoco es un procedimiento de configuración autorizado. No modificar políticas de ejecución, ajustes locales de Basic ni ajustes de proxy del sistema, ni reiniciar servicios basándose únicamente en este artículo. Documentar y autorizar por separado el estado inicial, las consecuencias y el procedimiento de reversión.
Host, Exchange local y cuenta de servicio
- En el host EAS: Sophos indica instalar Windows PowerShell si es necesario. Antes de instalarlo, acordar con el equipo de operaciones su versión y adecuación para la compilación concreta. Después, la guía describe cambiar la política de ejecución a RemoteSigned en una sesión de PowerShell abierta como administrador. Esta preparación aún no demuestra qué host PowerShell utiliza el servicio de Sophos ni si es compatible con él.
- Solo con Exchange Server local: En la Exchange Management Shell, Sophos describe un paso independiente de RemoteSigned y, a continuación, la identificación del directorio PowerShell real mediante
Get-PowerShellVirtualDirectory -Server <server name>. El marcador de posición representa el nombre del equipo Exchange Server, no el host EAS ni el nombre de la instancia. Sophos solo indicaPowerShell (Default Web Site)como directorio para una instalación estándar. Únicamente después de identificarlo, la guía oficial describe la activación de BasicAuthentication para ese directorio virtual. Este cambio queda reservado a la configuración local autorizada por separado; no forma parte de una configuración de Exchange Online. - Cuenta de servicio: Sophos utiliza una cuenta de usuario dedicada en el servidor de correo Exchange para ejecutar comandos PowerShell. Su creación difiere entre Exchange Server y Exchange Online; acordar con el equipo de Exchange la creación, los permisos y el método de autenticación para el destino concreto durante la comprobación previa de instalación de EAS. Un campo de contraseña no basta; no crear aquí cuentas ni roles.
Asistente de conexión y finalización
La conexión se prepara en el asistente de instalación; ejecutarlo queda reservado al cambio de instalación autorizado por separado. En EAS Proxy instance setup se documentan estos campos:
- Instance type:
PowerShell Exchange/Office 365. - Instance name: Un nombre elegido por el administrador para identificar inequívocamente la instancia.
- Exchange server: Para Exchange local, el nombre del servidor o su dirección IP; para el servicio global de Microsoft 365, Sophos indica
outlook.office365.com. En otras nubes, confirmar por separado el punto de conexión adecuado con el equipo de Exchange; Sophos remite para ello a la correspondencia de-ConnectionUrienConnect-ExchangeOnline. Según Sophos, no se introducenhttps://ni/powershell-liveiden este campo porque el asistente los añade. Esto documenta el comportamiento del campo, no un transporte de Exchange Online verificado para 2026. No inventar un punto de conexión alternativo; sigue siendo necesaria la comprobación de compilación, nube y autenticación exigida anteriormente. - Service account y Password: Nombre y contraseña de la cuenta de servicio creada previamente. No copiar credenciales en archivos de auditoría, ejemplos ni tickets; los campos por sí solos no demuestran un método de autenticación.
Add incorpora la conexión a la lista Instances. Para más instancias de Exchange Server, Sophos describe repetir esta configuración y después finalizar el asistente. La opción Allow all certificates no se convierte en un atajo recomendado por figurar en esta descripción de campos: comprobar la confianza en los certificados en lugar de desactivar la verificación del servidor.
Proxy opcional para conexiones salientes: Si el host EAS debe acceder a Exchange Server o Exchange Online mediante un proxy de red, Sophos describe un paso de WinHTTP en el host EAS, desde un símbolo del sistema abierto con Run as administrator. La configuración concreta de WinHTTP queda reservada al equipo de operaciones y al cambio de instalación aprobado para ello; no es el modo proxy para el correo de los dispositivos. El ajuste afecta a todo el sistema y puede repercutir en otros programas del host Windows. Antes de cambiarlo, estas dependencias también necesitan un estado inicial documentado y una reversión autorizada; no se trata de una solución general de proxy para fallos de autenticación.
Para finalizar, Sophos describe cargar el certificado de conexión PowerShell generado durante la configuración en My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. Si hay varias instancias, se cargan todos los certificados de instancia; después se selecciona Save y se realiza un reinicio autorizado de EASProxy en el diálogo Services de Windows. Acordar con el equipo de operaciones la ventana de mantenimiento, el estado del servicio y la reversión. Los certificados guardados o un nuevo valor de Last active no prueban que los dispositivos se autentiquen correctamente ni que se entregue el correo: seguir comprobando la autenticación, el envío, la recepción y la sincronización en cada dispositivo afectado antes y después del cambio.
Antes de cualquier cambio en el acceso EAS
Con una conexión de control PowerShell ya configurada y comprobada, Exchange puede configurarse para poner en cuarentena los dispositivos no inscritos en Sophos Mobile y denegarles el acceso al correo. Esto solo se aplica donde los límites de protocolo y ABQ descritos anteriormente permiten ese control. Bloquear dispositivos no inscritos es un cambio de acceso independiente para toda la organización, que corresponde al equipo de operaciones de Exchange/Mobile, no la finalización de la instalación. Su comprobación previa de arquitectura y seguridad se describe aquí; configurar la conexión de control corresponde a la comprobación previa de instalación de EAS independiente. Sophos describe una notificación de Exchange que solicita al usuario inscribirse. En el ejemplo documentado, Set-ActiveSyncOrganizationSettings con -DefaultAccessLevel quarantine establece el valor predeterminado para toda la organización; -UserMailInsert añade al correo de cuarentena un aviso de inscripción personalizable. Este artículo no recomienda ejecutar el comando. Primero hay que aclarar los requisitos, las consecuencias y la reversión autorizada.
El contexto de administración es distinto: para Exchange Server local se utiliza la Exchange Management Shell; para la nube, una conexión PowerShell de Exchange Online comprobada por separado, con una cuenta adecuada y una vía de autenticación y transporte compatible. Una shell local o su ajuste Basic no sustituyen una conexión de nube comprobada.
Una cuarentena de Exchange para toda la organización no es un interruptor piloto para un solo dispositivo de prueba. Donde Exchange ABQ se aplica realmente, cambiar el nivel de acceso predeterminado de «Allow» a «Quarantine» puede afectar de inmediato a dispositivos EAS ya conectados, no solo a los desconocidos o nuevos, salvo que se aplique una regla de acceso o una decisión individual Allow/Block. No dé por supuesto este efecto en la ruta Exchange Online/Outlook/Conditional Access que cumple las condiciones anteriores: allí se omiten las reglas ABQ de Exchange. En modo PowerShell, incluso los dispositivos ya inscritos pueden quedar en cuarentena por un estado de cumplimiento desconocido tras faltar la sincronización o interrumpirse la conexión con Sophos Mobile, siempre que ABQ se aplique a su ruta. La autorización automática tras una inscripción correcta depende de que funcione el canal de control; no garantiza que se resuelva una incidencia.
Antes de un cambio aprobado, registre el DefaultAccessLevel anterior de Exchange, el texto de notificación, las reglas de acceso de dispositivos y las entradas individuales Allow/Block existentes, así como el inventario de dispositivos y aplicaciones de correo, el estado actual de sincronización y cumplimiento, la confianza en los certificados y las personas responsables. Observe los dispositivos permitidos, desconocidos y temporalmente no evaluables para los buzones de prueba; consulte los eventos disponibles de Sophos, Exchange y Entra en busca de decisiones y errores de conexión y verifique su asociación con cada dispositivo en el tenant de destino. Antes del cambio, compruebe con los buzones de prueba acordados, para cada dispositivo afectado, el inicio de sesión EAS real, el envío, la recepción y la sincronización; los eventos por sí solos no demuestran el efecto. En el menú de Sophos My Products > Mobile > Setup > Sophos setup > EAS proxy, el valor de External > Last active indica únicamente el último contacto de cada instancia del proxy con Sophos Mobile, no que cada dispositivo haya iniciado sesión, recibido correo o sido autorizado correctamente.
El procedimiento de reversión aprobado debe contemplar la restauración del nivel de acceso predeterminado, las reglas, las decisiones individuales y el texto de notificación documentados, junto con los responsables y los criterios para abortar el cambio. Restablecer solo el valor predeterminado no demuestra que se haya recuperado el estado anterior: los dispositivos pueden seguir en un estado inesperado; tras la reversión, compruebe individualmente con los buzones de prueba acordados el inicio de sesión EAS real, el envío, la recepción y la sincronización de los dispositivos afectados, incluso después de un estado de cumplimiento obsoleto o un fallo de la conexión de control de Sophos. Hasta que se demuestren la autenticación, la ruta del correo y el procedimiento de reversión y se apruebe el cambio, este artículo no recomienda instalar el producto, activar la cuarentena ni migrar.