Accès EAS avec Sophos Mobile : distinguer les modes proxy et PowerShell

Le nom Sophos Mobile EAS Proxy désigne deux façons distinctes de contrôler Exchange ActiveSync (EAS), le protocole de synchronisation de la messagerie mobile. En mode proxy, les requêtes EAS des appareils configurés à cet effet passent par le proxy Sophos installé séparément avant d’atteindre le serveur de messagerie. En mode PowerShell, les appareils se connectent directement à Exchange ; le service Sophos contrôle leur accès au moyen d’une connexion d’administration distincte. Confondre ces deux modes peut conduire à prévoir les mauvais chemins réseau ou à négliger une modification de l’accès à Exchange. Cet article aide à choisir une architecture ; ce n’est pas un guide d’installation, de migration ou de dépannage.

Arrêt avant toute mise en quarantaine à l’échelle de l’organisation ou tout basculement en production : faire passer le niveau d’accès par défaut d’Exchange de « Allow » à « Quarantine » peut toucher immédiatement des appareils EAS déjà connectés, sauf si une règle d’accès aux appareils ou une décision individuelle Allow/Block s’applique. Ne rien basculer sans état initial consigné, vérification des appareils et de leur conformité, authentification démontrée et procédure de retour arrière approuvée : ce réglage ne vise pas un seul appareil pilote.

Chemin de décision : déterminer d’abord le service de messagerie cible et les applications de messagerie qui utilisent réellement EAS. Pour Exchange Server, le mode proxy peut constituer le chemin de la messagerie ; pour Exchange Online, Sophos ne mentionne que le mode PowerShell avec accès direct des appareils. IBM Traveler est une cible proxy distincte. Comparer les modes uniquement pour la cible concernée. Si l’identité des appareils, l’authentification des clients, l’authentification de l’administration ou la prise en charge du serveur cible ne peuvent pas être établies, s’arrêter ici plutôt que de déduire une autorisation du seul choix du mode.

Une migration ou une mise en œuvre doit être planifiée et approuvée séparément ; en cas d’incident, consulter le dépannage EAS.

Limite de licence et de plateforme : ces indications EAS concernent la gestion des appareils avec Sophos Mobile, et non une licence Sophos Mobile Threat Defense seule. Avant de choisir un mode, vérifier les droits réels du tenant pour Sophos Mobile ou Sophos Mobile Device Management, l’inscription et la remontée de conformité de chaque appareil Android ou iPhone/iPad concerné, ainsi que son application et protocole de messagerie réels. Le forfait Microsoft 365 Exchange Online cité par Sophos est un prérequis du service de messagerie, pas une preuve des droits Mobile ni de l’application des contrôles EAS à la synchronisation native d’Outlook. Ne pas en déduire une couverture des Mac ou d’autres clients non-EAS.

Par où passe le trafic de messagerie mobile ?

Limite de confidentialité : en mode proxy, le trafic de messagerie traverse le proxy exploité séparément ; en mode PowerShell, il ne le traverse pas, mais Sophos traite toujours l’identité et l’état de conformité de l’appareil pour décider de l’accès. Aucun des deux trajets ne permet de déduire quels contenus ou métadonnées sont journalisés, stockés ou conservés. Avant toute approbation, vérifier la journalisation, les accès et la conservation dans l’environnement réel.

• Mode proxy : appareil → Sophos Mobile EAS Proxy → serveur de messagerie pris en charge (pour Exchange : serveur Exchange local ; Sophos mentionne aussi IBM Traveler). Sur les appareils, le proxy doit être configuré comme serveur de messagerie EAS pour les messages entrants et sortants ; cela n’implique pas une configuration SMTP distincte. Le proxy se connecte à Sophos Mobile par une interface web HTTPS, vérifie l’identité de l’appareil et le statut requis par les politiques, puis transmet les requêtes EAS admissibles. Le proxy peut aussi être configuré pour bloquer certains appareils ; ce blocage est à distinguer de la vérification de conformité et des entrées ABQ individuelles d’Exchange. Pour ce chemin de messagerie via le proxy, le serveur de messagerie lui-même n’a pas besoin d’être directement accessible depuis Internet. Cela ne garantit pas que chaque requête soit vérifiée : l’exception Traveler décrite ci-dessous reste applicable. Ici, le proxy est sur le chemin de la messagerie : sa disponibilité et son débit conditionnent l’accès à la messagerie mobile.
• Mode PowerShell : appareil → Exchange directement ; séparément, service EAS de Sophos Mobile → interface d’administration d’Exchange. Le service Sophos se connecte également à Sophos Mobile par une interface web HTTPS. Le trafic de messagerie ne passe pas par le proxy Sophos ; aucun port de pare-feu pour la messagerie entrante n’est donc nécessaire sur son hôte. L’accessibilité d’Exchange et les connexions d’administration et de contrôle doivent néanmoins être planifiées. Sophos cite comme cibles Exchange Server 2016/2019 et Microsoft 365 avec un forfait Exchange Online. Cette indication produit ne démontre pas que la version du proxy en place, le client concerné, son authentification et le tenant fonctionnent aujourd’hui ensemble. Le dimensionnement du relais de messagerie propre au mode proxy ne s’applique pas à ce mode.

Chemins réseau dans l’exemple daté à certificats clients : Le schéma d’architecture Sophos (page anglaise du 12 avril 2023, page allemande du 27 avril 2023) place Sophos Mobile, le proxy EAS et Exchange à l’intérieur d’un périmètre en pointillés intitulé « Customer » ; les appareils se trouvent à l’extérieur. Il illustre une topologie exploitée côté client, et non une exigence universelle pour les déploiements Sophos Mobile ni une preuve de frontière de pare-feu ou de DMZ. Outre le chemin de messagerie EAS, un chemin MDM distinct relie l’appareil à Sophos Mobile en HTTPS ; dans le schéma, ce chemin de gestion des appareils ne traverse pas le proxy EAS. Il est également distinct de la connexion de contrôle HTTPS proxy EAS → Sophos Mobile déjà décrite.

Le tableau des points de terminaison de ce schéma ne fournit que des valeurs d’exemple schématiques, et non des points de terminaison à reprendre en exploitation ou des autorisations générales de pare-feu :

Les noms smc.company.com et eas.company.com, ainsi que les ports cibles, appartiennent à cet exemple. En revanche, la flèche proxy EAS → Exchange porte uniquement la mention http/s ; aucun port backend n’est indiqué. Cela conserve la représentation schématique HTTP/HTTPS, sans exiger du trafic backend non chiffré ni l’autoriser de manière générale. On ne peut pas non plus en déduire où TLS se termine ni quelle confiance est accordée aux certificats. Les points de terminaison réels, les ports et la connexion backend sécurisée doivent être vérifiés et approuvés séparément pour l’environnement concerné ; le sens des flèches n’exclut pas le trafic de réponse. Le schéma n’élargit ni les limites de produit et de version indiquées ci-dessous ni la matrice des serveurs de messagerie pris en charge.

Exemple Central avec un environnement client distinct : une autre architecture archivée montre Sophos Mobile in Central dans le périmètre Sophos Central, tandis que EAS proxy et Exchange se trouvent dans le périmètre Customer. Les appareils sont à l’extérieur des deux périmètres. Leur chemin MDM distinct mène en HTTPS à Sophos Mobile in Central ; l’encadré indique à cet effet central.sophos.com. Le chemin de messagerie ActiveSync mène en revanche en HTTPS à eas.company.com, sur le proxy EAS côté client, puis de celui-ci à Exchange via http/s. Une flèche HTTPS distincte allant du proxy EAS à Sophos Mobile in Central représente également la connexion de contrôle à travers la frontière client/Central illustrée. MDM, messagerie et contrôle du proxy constituent donc trois chemins distincts, et non un chemin commun passant par Central.

Le tableau des points de terminaison de cet exemple Central contient exactement une correspondance : https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. Il n’indique ni port cible MDM pour Central ni port backend pour Exchange. Ici aussi, les noms d’hôte sont des exemples schématiques archivés, et non des points de terminaison d’exploitation du tenant concerné. Les périmètres en pointillés ne démontrent aucune disposition de pare-feu ou de DMZ ; http/s n’implique ni autorisation de trafic non chiffré ni indication sur la terminaison TLS.

Pour le mode proxy, Sophos décrit la prise en charge de plusieurs serveurs de messagerie Exchange ou Traveler, avec une instance EAS Proxy par serveur de messagerie.

La mise à l’échelle d’un chemin de messagerie est une question distincte : des instances peuvent à cet effet être exécutées sur plusieurs ordinateurs derrière un répartiteur de charge. Des certificats clients sont également prévus : on sélectionne un certificat d’une autorité de certification (CA) ; les certificats clients doivent être issus de cette CA. Dans le mode à certificats clients illustré par Sophos (exemple d’architecture du 12 avril 2023), le proxy EAS vérifie les certificats clients présentés par rapport au certificat de CA sélectionné et bloque aussi bien les clients sans certificat client que ceux dont le certificat client est invalide. Cette condition de blocage documentée ne concerne que le mode à certificats clients illustré ; elle ne prouve ni son application dans le build utilisé ni la réalisation de contrôles précis d’invalidité ou de révocation. Cette authentification client est à distinguer des certificats de connexion PowerShell téléversés ultérieurement dans Sophos Mobile. Les instances, la répartition de charge et la confiance accordée aux certificats doivent être planifiées et testées dans l’environnement concerné.

Répartition de charge concrète dans l’exemple archivé : le schéma de répartition de charge place Sophos Mobile, un répartiteur de charge, deux proxys EAS et Exchange dans Customer, et les appareils à l’extérieur. Le chemin MDM des appareils mène directement en HTTPS à Sophos Mobile (smc.company.com), tandis que leur chemin ActiveSync mène en HTTPS au répartiteur de charge (eas.company.com). Deux flèches distinctes, portant ensemble la mention http/s, partent du répartiteur vers les deux proxys. Chaque proxy dispose de sa propre connexion de contrôle HTTPS à Sophos Mobile et de son propre chemin de messagerie http/s vers Exchange. Dans cette représentation, le contrôle ne va donc pas du répartiteur de charge à Sophos Mobile.

Les correspondances complètes du tableau de l’image peuvent être présentées sans tableau large :

• MDM: https://smc.company.com/* → HTTPS → SMC Server:443 ; les deux champs suivants du tableau contiennent -. L’astérisque fait partie de l’exemple d’URL représenté.
• 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.

Le port 81 désigne ici les cibles proxy derrière le répartiteur de charge, et non Exchange. L’image ne fournit aucun port backend pour Exchange. Cette représentation schématique archivée ne constitue ni une autorisation générale de pare-feu ni une preuve de déchargement TLS, de transmission des certificats, de persistance des sessions, de contrôles d’état, d’un algorithme particulier de répartition de charge ou de haute disponibilité garantie. La correspondance des ports frontend/proxy ne remplace pas la planification et l’approbation des connexions réelles.

Distinguer l’image PowerShell des éléments attestés par le texte : l’image Central-PowerShell archivée montre EAS Proxy dans le périmètre Company, Sophos Mobile dans le périmètre distinct Sophos Central et, en dessous, un autre périmètre sans nom visible contenant Office 365 Exchange Online et outlook.office365.com. Entre Company et Sophos Central figurent les mentions https et Query device compliance list. À côté du proxy EAS figure Needs PowerShell 3.0 or higher. Il s’agit d’une indication historique de l’image, et non d’une version minimale actuellement valable ou d’une preuve de prise en charge ; la vérification du build précis et de l’hôte PowerShell exigée ci-dessous reste déterminante. Les flèches de connexion ne sont pas discernables de manière fiable dans ces pixels archivés. La séparation décrite plus haut entre chemin direct de messagerie des appareils et connexion d’administration Exchange distincte est donc une affirmation documentée par le texte, et non un sens de flèche lu dans cette image. L’image ne fournit pas non plus de ports numériques ni de tableau des points de terminaison ; le nom d’hôte indiqué ne prouve aucun chemin actuel d’authentification ou de transport Exchange Online.

Interpréter la recommandation de dimensionnement datée : dans les Sizing Considerations du 14 avril 2022, Sophos décrit de faibles besoins en CPU et en mémoire pour le proxy EAS, indique que la bande passante est la principale limite et recommande 1 CPU et 2 Go de mémoire vive. Pour les grandes installations, cette source recommande plusieurs instances du proxy EAS derrière un répartiteur de charge ; cette architecture de relais de messagerie n’est pas nécessaire en mode PowerShell. Il s’agit d’une recommandation documentaire datée, et non d’un test de performance, d’un minimum actuel démontré ou d’un engagement de capacité. Vérifier le build précis, la charge de messagerie et les chemins réseau disponibles avec l’équipe d’exploitation, puis valider le dimensionnement dans un environnement autorisé avant toute approbation ; ces valeurs seules ne constituent pas une autorisation de mise en production.

Avant la configuration, clarifier l’intégration réseau avec l’équipe d’exploitation : recenser séparément le chemin de messagerie des appareils, la connexion de contrôle HTTPS à Sophos Mobile et, le cas échéant, la connexion d’administration d’Exchange. Sophos répertorie les serveurs de messagerie pris en charge dans la section Requirements des notes de version Mobile. Pour la transmission à l’équipe d’exploitation, la matrice des serveurs de messagerie applicable au build prévu, le build cible et le cycle de vie doivent être confirmés ; une liste générale de produits ne suffit pas. Les prérequis relatifs à l’hôte, au réseau et à l’installation relèvent de la vérification préalable à l’installation EAS distincte, et non d’une autorisation implicite découlant de ce choix de mode.

Les deux modes contrôlent EAS, pas tous les protocoles de messagerie mobile. Sophos exclut les Mac de ce chemin de contrôle en invoquant l’absence de prise en charge d’ActiveSync dans macOS ; cela ne constitue pas une affirmation sur tous les clients de messagerie tiers possibles sur Mac. Avec IBM Traveler, les requêtes d’appareils autres qu’iOS dépourvus d’identifiant d’appareil peuvent être transmises sans que le proxy puisse vérifier leur autorisation.

En mode proxy, Outlook sur Android/iOS peut ne pas parvenir à associer l’utilisateur à l’identifiant ActiveSync, par exemple si plusieurs appareils sont encore inconnus ou si une réinstallation de l’application génère un nouvel identifiant ActiveSync qui ne correspond pas à l’entrée enregistrée. Toutes les réinstallations ne provoquent pas nécessairement cette erreur ; rien ne démontre que la même erreur se produit en mode PowerShell. Selon Sophos, ce problème précis d’association ne se produit pas avec Gmail sur Android ni Mail sur iOS, car Sophos Mobile reçoit leur identifiant ActiveSync lors de l’inscription. Cela n’exclut pas d’autres erreurs de messagerie. Vérifier les applications, protocoles et identifiants d’appareil réellement utilisés dans les deux modes. En cas de failed to resolve active sync id, utiliser d’abord le dépannage EAS pour circonscrire le problème en lecture seule. Une erreur d’association n’autorise ni une réinitialisation de l’identifiant ni une modification de l’attribution de l’utilisateur ; ne clarifier une réparation nécessaire avec l’équipe d’exploitation qu’après identification certaine de l’appareil et obtention d’une autorisation distincte.

Exception distincte pour Exchange Online, Outlook et l’accès conditionnel : lors de l’authentification d’un utilisateur dans Outlook pour iOS ou Android, Microsoft indique que les règles d’accès aux appareils mobiles Allow/Block/Quarantine (ABQ) d’Exchange Online sont ignorées si une stratégie d’accès conditionnel Microsoft Entra applicable à cet utilisateur inclut Exchange Online ou Office 365 comme application cloud, iOS et/ou Android comme plateforme, « Mobile apps and desktop client » comme applications clientes et au moins un contrôle d’octroi : exiger un appareil conforme, une application cliente approuvée ou une stratégie de protection des applications. Cette exception ne concerne pas toutes les utilisations d’Outlook ni toutes les stratégies d’accès conditionnel ; ce dernier peut toujours restreindre l’accès. Microsoft avertit qu’ABQ seul n’offre aucune garantie de sécurité : un client falsifiant l’en-tête DeviceType peut contourner le blocage d’un type d’appareil donné. Pour Exchange Online, vérifier aussi les stratégies et règles d’accès de Basic Mobility and Security : après l’inscription à ce service, elles prévalent pour l’appareil sur les stratégies de boîte aux lettres pour appareils mobiles et les règles d’accès aux appareils d’Exchange. Ne considérer ni une décision ABQ ni l’absence de cette exception précise d’accès conditionnel comme une barrière de sécurité. Elle est distincte du problème d’association de l’identifiant ActiveSync d’Outlook en mode proxy décrit plus haut. Pour Exchange Online, Microsoft décrit la synchronisation native d’Outlook sur iOS et Android, et non EAS ; vérifier le protocole réellement utilisé avant d’attribuer l’accès aux contrôles EAS. Les contrôles d’authentification EAS ci-dessous ne concernent que les clients utilisant réellement EAS ; pour les autres, tester l’authentification et le chemin des données de leur application de messagerie. Pour ce chemin admissible, ne pas présumer que les décisions ABQ d’Exchange pilotées par Sophos ou la quarantaine imposent l’accès au seul motif que la connexion d’administration PowerShell fonctionne. Avant de recommander l’architecture, vérifier dans le tenant cible l’identité de l’utilisateur, l’application de messagerie, les conditions effectives d’accès conditionnel (application cloud, plateforme, application cliente, octroi) et la décision d’accès Exchange pour l’appareil ; vérifier par des tests autorisés l’authentification, l’envoi, la réception et la synchronisation réels de chaque appareil représentatif.

Évaluer séparément Exchange Online et le cycle de vie des serveurs

Exchange Online — pas de retour à Basic : Microsoft a désactivé Basic Authentication pour l’authentification des clients EAS et pour Remote PowerShell dans tous les tenants ; il n’est pas possible de la réactiver pour ces usages. Un repli vers Basic ne réparerait donc ni l’authentification de l’administration ni celle d’une application de messagerie EAS utilisant Basic. Le guide d’installation Sophos du 9 septembre 2026 ne décrit pas de séquence « authentification moderne, puis Basic en cas d’échec » ; son absence ne permet toutefois pas non plus de déduire une autre séquence d’authentification du service. Le texte d’installation Sophos mentionne encore /powershell-liveid ; Microsoft prend en charge les connexions REST pour Exchange Online PowerShell. Cela ne permet pas de savoir si une version donnée du composant Sophos utilise ce chemin. L’instruction de Sophos concernant Basic sur le répertoire PowerShell d’un serveur Exchange local ne s’applique pas à Exchange Online. Ne pas activer Basic ou WinRM Basic comme solution pour Exchange Online.

Exchange Online — vérifier séparément TLS et l’authentification : l’option Sophos « Allow all certificates » désactive la vérification du certificat du serveur et affaiblit la sécurité de la connexion ; elle ne prouve pas qu’un chemin d’administration TLS ou REST est pris en charge et ne résout pas l’arrêt de Basic. Vérifier la confiance accordée au certificat et la connexion TLS, sans contourner la vérification du certificat. Faire confirmer par Sophos, pour l’environnement concerné, la prise en charge de la version précise du proxy, la version du module ExchangeOnlineManagement, l’hôte PowerShell réellement utilisé par le service et sa version, la version de Windows et celle de .NET Framework ou de .NET selon la matrice de compatibilité module/hôte/système d’exploitation de Microsoft, le cloud, le chemin d’administration OAuth/REST, les autorisations du compte ainsi que la MFA et l’accès conditionnel. Ni l’installation du module ni une version d’hôte compatible ne prouvent quel transport le service Sophos utilise réellement ou que son authentification fonctionne. Dans un tenant de test autorisé, deux vérifications distinctes sont nécessaires : le service peut-il administrer Exchange (connexion et autorisations), et les appareils prévus peuvent-ils s’authentifier en EAS et synchroniser avec leur véritable application de messagerie ? Une connexion d’administration réussie ne prouve pas l’accès à la messagerie.

Serveur Exchange local : Le guide d’installation Sophos demande l’activation de BasicAuthentication pour le chemin du répertoire PowerShell d’Exchange local. Cela ne prouve pas que toutes les connexions d’administration locales utilisent systématiquement Basic ; cela ne concerne ni l’authentification des clients EAS ni Exchange Online et ne constitue pas une autorisation générale d’activer Basic en local. L’authentification locale et le durcissement exigent une validation de sécurité distincte. Sophos cite Exchange 2016/2019 ; le support standard de Microsoft pour les deux a pris fin le 14 octobre 2025. Exchange Server Subscription Edition (SE) ne figure pas dans cette indication de Sophos. Une option de migration proposée par Microsoft n’équivaut pas à une certification par Sophos. Obtenir séparément confirmation de la version du serveur, de son cycle de vie ou d’éventuels accords particuliers, et de la prise en charge par Sophos de cette cible précise, au lieu de déduire une autorisation de production d’un schéma d’architecture.

Ce que comprend la configuration PowerShell approuvée

La configuration PowerShell comprend la préparation de l’hôte, un compte de service Exchange dédié, la connexion de l’instance et l’association de son certificat. Les étapes et champs documentés ci-dessous facilitent la transmission à l’équipe d’exploitation ; ils ne remplacent ni la vérification du build et du chemin d’authentification précis ni un changement approuvé. La vérification préalable à l’installation EAS distincte couvre les vérifications relatives à l’hôte, au compte de service et à l’installation, mais ne constitue pas non plus une procédure de configuration approuvée. Ne pas modifier les politiques d’exécution, les paramètres Basic locaux ou les paramètres proxy à l’échelle du système, ni redémarrer les services sur la seule base de cet article. Documenter et faire approuver séparément l’état initial, les effets et le retour arrière correspondants.

Hôte, Exchange local et compte de service

• Sur l’hôte EAS : Sophos mentionne l’installation de Windows PowerShell si nécessaire. Avant toute installation, vérifier avec l’équipe d’exploitation sa version et son adéquation au build concerné. Le guide décrit ensuite le passage de la politique d’exécution à RemoteSigned dans une fenêtre PowerShell ouverte en tant qu’administrateur. Cette préparation ne prouve pas encore quel hôte PowerShell le service Sophos utilise ni s’il est compatible avec celui-ci.
• Uniquement pour un serveur Exchange local : Dans Exchange Management Shell, Sophos décrit une étape RemoteSigned distincte, puis l’identification du répertoire PowerShell réel avec Get-PowerShellVirtualDirectory -Server <server name>. Le paramètre fictif désigne le nom de l’ordinateur du serveur Exchange, et non l’hôte EAS ou le nom de l’instance. Sophos ne mentionne PowerShell (Default Web Site) comme répertoire que pour une installation standard. Dans le guide officiel, l’activation de BasicAuthentication pour le répertoire virtuel concerné ne suit qu’après cette identification. Cette modification reste réservée à la configuration locale approuvée séparément ; elle ne fait expressément pas partie d’une configuration Exchange Online.
• Compte de service : Sophos utilise un compte utilisateur dédié sur le serveur de messagerie Exchange pour exécuter les commandes PowerShell. Sa création diffère entre Exchange Server et Exchange Online ; la création du compte, les autorisations et la méthode d’authentification sont à clarifier avec l’équipe Exchange pour la cible précise dans le cadre de la vérification préalable à l’installation EAS. Un champ de mot de passe ne suffit pas ; ne créer ici ni compte ni rôles.

Assistant de connexion et finalisation

La connexion est préparée dans l’assistant d’installation ; son exécution reste réservée au changement d’installation approuvé séparément. Les champs suivants sont documentés sur EAS Proxy instance setup :

• Instance type: PowerShell Exchange/Office 365.
• Instance name: Un nom choisi librement pour identifier l’instance de manière unique.
• Exchange server: Pour Exchange local, le nom du serveur ou son adresse IP ; pour le service Microsoft 365 global, Sophos mentionne outlook.office365.com. Pour les autres clouds, confirmer séparément le point de terminaison de connexion adapté avec l’équipe Exchange ; Sophos renvoie à cet effet à la correspondance -ConnectionUri de Connect-ExchangeOnline. Selon Sophos, https:// et /powershell-liveid ne sont pas saisis dans ce champ, car l’assistant les ajoute. Cela documente le comportement du champ, et non un transport Exchange Online vérifié pour 2026. Ne pas proposer de point de terminaison de remplacement au hasard ; la vérification du build, du cloud et de l’authentification exigée plus haut reste nécessaire.
• Service account et Password: Nom et mot de passe du compte de service créé précédemment. Ne pas recopier les identifiants dans des fichiers d’audit, des exemples ou des tickets ; les champs ne prouvent pas à eux seuls une méthode d’authentification.

Add ajoute la connexion à la liste Instances. Pour d’autres instances de serveurs Exchange, Sophos décrit la répétition de cette configuration, puis la finalisation de l’assistant. Malgré cette présentation des champs, l’option Allow all certificates ne constitue pas un raccourci recommandé : vérifier la confiance accordée aux certificats plutôt que de désactiver la vérification du serveur.

Proxy facultatif pour les connexions sortantes : Si l’hôte EAS doit atteindre Exchange Server ou Exchange Online via un proxy réseau, Sophos décrit à cet effet une étape WinHTTP sur l’hôte EAS dans une invite de commandes ouverte avec Run as administrator. La configuration WinHTTP précise reste réservée à l’équipe d’exploitation et au changement d’installation approuvé à cet effet ; il ne s’agit pas du mode proxy pour la messagerie des appareils. Le paramètre s’applique à l’échelle du système et peut affecter d’autres programmes sur l’hôte Windows. Avant une telle modification, ces dépendances nécessitent elles aussi un état initial documenté et un retour arrière approuvé ; cela ne constitue pas une correction proxy générale pour les erreurs d’authentification.

Pour terminer, Sophos décrit le téléversement du certificat de connexion PowerShell généré lors de la configuration sous My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. S’il y a plusieurs instances, tous les certificats d’instance sont téléversés, puis viennent Save et un redémarrage approuvé de EASProxy dans la fenêtre Windows Services. Clarifier à cet effet la fenêtre de maintenance, l’état du service et le retour arrière avec l’équipe d’exploitation. Des certificats enregistrés ou une nouvelle valeur Last active ne prouvent ni la réussite de l’authentification des appareils ni la remise des messages : l’authentification, l’envoi, la réception et la synchronisation restent à vérifier pour chaque appareil concerné avant et après le changement.

Avant toute modification de l’accès EAS

Avec une connexion de contrôle PowerShell déjà configurée et vérifiée, Exchange peut être configuré pour placer les appareils non inscrits dans Sophos Mobile en quarantaine et leur refuser l’accès à la messagerie. Cela ne s’applique que là où les limites de protocole et d’ABQ décrites plus haut permettent ce contrôle. Le blocage des appareils non inscrits constitue une modification distincte de l’accès à l’échelle de l’organisation, relevant de l’équipe d’exploitation Exchange/Mobile, et non la finalisation de l’installation. Sa vérification préalable d’architecture et de sécurité suit ici ; la configuration de la connexion de contrôle relève de la vérification préalable à l’installation EAS distincte. Sophos décrit dans ce cadre une notification Exchange invitant les utilisateurs à s’inscrire. Dans l’exemple documenté, Set-ActiveSyncOrganizationSettings avec -DefaultAccessLevel quarantine définit la valeur par défaut à l’échelle de l’organisation ; -UserMailInsert ajoute au message de quarantaine une invitation à l’inscription personnalisable. Cet article ne recommande pas d’exécuter la commande. Les prérequis, les effets et le retour arrière approuvé doivent d’abord être clarifiés.

Le contexte d’administration diffère : Exchange Management Shell est prévu pour un serveur Exchange local ; pour le cloud, il faut une connexion Exchange Online PowerShell vérifiée séparément, avec un compte adapté et un chemin d’authentification et de transport pris en charge. Une console locale ou son paramètre Basic ne remplace pas une connexion cloud vérifiée.

Une quarantaine Exchange à l’échelle de l’organisation n’est pas un réglage pilote réservé à un appareil de test. Là où Exchange ABQ est effectivement appliqué, passer de « Allow » à « Quarantine » peut toucher immédiatement des appareils EAS déjà connectés, et pas seulement les nouveaux ou inconnus, sauf si une règle d’accès ou une décision individuelle Allow/Block s’applique. Ne pas supposer cet effet pour le chemin Exchange Online/Outlook/accès conditionnel admissible décrit plus haut : les règles ABQ d’Exchange y sont ignorées. En mode PowerShell, même des appareils déjà inscrits peuvent être mis en quarantaine si leur état de conformité devient inconnu faute de synchronisation ou à cause d’une connexion perturbée à Sophos Mobile, à condition qu’ABQ s’applique à leur chemin. L’autorisation automatique après une inscription réussie dépend du bon fonctionnement du circuit de contrôle ; elle ne garantit pas le rétablissement du service.

Avant un changement approuvé, consigner l’ancien Exchange-DefaultAccessLevel, le texte de notification, les règles d’accès aux appareils et les entrées Allow/Block individuelles existantes, ainsi que l’inventaire des appareils et des applications de messagerie, l’état actuel de synchronisation et de conformité, la confiance accordée aux certificats et les responsables désignés. Pour les boîtes aux lettres de test, observer les appareils autorisés, inconnus et temporairement impossibles à évaluer ; examiner les événements Sophos, Exchange et Entra disponibles pour les décisions d’accès et les erreurs de connexion, puis vérifier leur correspondance avec chaque appareil dans le tenant cible. Avant la modification, vérifier avec les boîtes aux lettres de test convenues, pour chaque appareil concerné, l’authentification EAS réelle, l’envoi, la réception et la synchronisation ; les événements seuls ne démontrent pas l’effet du changement. Dans le menu Sophos My Products > Mobile > Setup > Sophos setup > EAS proxy, la valeur External > Last active indique uniquement, pour chaque instance du proxy, son dernier contact avec Sophos Mobile, et non la réussite de l’authentification, de la remise des messages ou de l’autorisation de chaque appareil.

La procédure de retour arrière approuvée doit prévoir le rétablissement du niveau d’accès par défaut documenté, des règles, des décisions individuelles et du texte de notification, ainsi que les responsabilités et les critères d’arrêt. Rétablir seulement la valeur par défaut ne prouve pas que l’état initial est restauré : certains appareils peuvent rester dans un état inattendu. Après le retour arrière, vérifier individuellement, avec les boîtes aux lettres de test convenues, l’authentification EAS réelle, l’envoi, la réception et la synchronisation des appareils concernés, y compris après une obsolescence de leur état de conformité ou une panne de la connexion de contrôle Sophos. Tant que l’authentification, le chemin de la messagerie et le retour arrière n’ont pas été démontrés et que le changement n’a pas été approuvé, cet article ne recommande ni installation, ni basculement en quarantaine, ni migration.