Sophos Mobile EAS Proxy : ne planifier l’installation qu’après vérification de la compatibilité

Vérifications documentaires préalables, aucune autorisation d’installation. Le proxy EAS autonome de Sophos Mobile peut se placer sur le trajet de la messagerie EAS en mode proxy ou gérer l’accès par Exchange en mode PowerShell, tandis que les appareils communiquent directement avec Exchange. Ces modes, leurs serveurs cibles et leurs mécanismes d’authentification ne sont pas interchangeables. Avant toute installation ou modification de l’accès à la messagerie en production, faire confirmer la version précise de Sophos, la cible, le client de messagerie utilisé et la procédure par Sophos et l’équipe Exchange. L’aide au choix de l’architecture EAS traite du chemin de messagerie et de la quarantaine ; la migration Exchange et le dépannage EAS sont des tâches distinctes.

Vérifications préalables sans intervention

• Consigner la cible et le mode : l’architecture Sophos et la description du mode PowerShell distinguent le mode proxy, réservé à Exchange Server, du mode PowerShell, prévu pour Exchange Server ou Exchange Online : dans ce dernier cas, les appareils communiquent directement avec Exchange et le service pilote l’accès par la connexion d’administration. La liste générale des serveurs de messagerie dans les notes de version n’autorise pas Exchange Online en mode proxy. IBM Traveler y figure comme serveur de messagerie ; pour certains clients Traveler autres qu’iOS, Sophos ne peut pas vérifier l’autorisation de chaque requête en l’absence d’identifiant d’appareil. Recenser le tenant/cloud, les appareils EAS concernés et les applications de messagerie. Selon Sophos, faute d’ActiveSync, le trafic de messagerie des Mac ne peut être ni filtré par le proxy EAS ni contrôlé en mode PowerShell. Une connexion d’administration fonctionnelle ne démontre à elle seule ni le chemin de messagerie ni l’application effective d’un blocage d’appareil.
• Faire vérifier l’hôte et les serveurs de messagerie : les notes de version de Sophos Mobile, section Requirements > Sophos Mobile EAS proxy citent comme hôtes d’installation Windows 10 ou version ultérieure et Windows Server 2016 ou version ultérieure ; leur liste générale des serveurs de messagerie mentionne Exchange Server 2016 et 2019, Microsoft 365 (Exchange Online) et IBM Traveler 9.0. Cette liste de produits ne démontre ni la prise en charge actuelle de ces versions de Windows et d’Exchange au regard du cycle de vie Microsoft, ni la compatibilité d’un installateur précis avec l’hôte et le tenant ; vérifier ces points séparément. Selon l’aide à l’installation Sophos, des droits d’administrateur sur la machine d’installation, l’URL du serveur Sophos Mobile et l’accès aux serveurs de messagerie nécessaires sont requis. L’installateur ne configure pas de connexion vers un serveur de messagerie injoignable. Selon l’aide Sophos pour trouver l’URL du serveur, l’URL affichée se trouve dans l’interface Sophos Mobile sous Setup > Sophos setup > EAS proxy > External ; il ne faut pas inventer une URL de tenant. Obtenir l’accord de l’équipe d’exploitation sur l’hôte, les chemins réseau et la cible de messagerie avant toute modification.
• Ne pas confondre téléchargement et validation : l’aide Sophos au téléchargement indique un lien vers l’installateur sous External. Les pages de téléchargement officielles en-us et sans code de langue sont des listes dynamiques, pas une vérification du binaire téléchargé. Lors de la consultation du 29 septembre 2026, la page en-us affichait Standalone EAS Proxy Installer 9.8.2 ; l’URL sans code de langue redirigeait vers en-gb, qui affichait 9.8.1. Lors d’une consultation antérieure, cette même URL redirigeait vers de-de, qui affichait 9.8.2 ; des expirations de délai intermédiaires ne prouvent pas une indisponibilité permanente. La liste contient aussi d’anciens téléchargements On-Premise ; l’arrêt de cette branche du produit ne préjuge pas du statut de Sophos Mobile géré par Central. La redirection et la version affichée varient selon le contexte : elles ne permettent de conclure ni à une version mondialement la plus récente ni à la prise en charge d’un build pour l’hôte concerné ou Exchange Online. Le fichier téléchargé, sa signature et son origine, sa version, l’environnement hôte pris en charge et la validation par Sophos n’ont pas été vérifiés ici. Ne pas lancer d’installateur à partir de cette page.
• Distinguer les chaînes de confiance des certificats : en mode proxy, vérifier séparément le certificat HTTPS présenté aux clients par le proxy, la connexion TLS à Exchange et le certificat créé pour chaque instance pour sa connexion à Sophos Mobile. Pour la cible Exchange, le nom du serveur ActiveSync configuré doit correspondre au CN ou à un SAN du certificat Exchange ; vérifier aussi la chaîne de certification et la confiance. Le certificat d’instance doit être téléversé dans Sophos Mobile. L’aide Sophos à la configuration avertit que, si le service démarre avant ce téléversement, Sophos Mobile refuse la connexion et le service ne démarre pas. Pourtant, la procédure d’installation citée plus haut décrit un démarrage avant le téléversement, puis un redémarrage : ne pas reprendre sans examen cet ordre comme procédure d’exploitation sûre. Avant la mise en service, clarifier l’association de chaque instance, la sauvegarde des fichiers de certificats et la fenêtre de démarrage approuvée. Remarque distincte relative au SSL Certificate Wizard : la page Sophos consacrée au SSL Certificate Wizard avertit qu’un certificat autosigné ou émis par une autorité de certification interne nécessite de distribuer manuellement la confiance aux appareils avant leur inscription (sinon l’application Sophos Mobile Control ne fait pas confiance au serveur), et exclut Android zero-touch et Knox Mobile Enrollment. Cette source n’attribue pas le défaut de confiance à l’inscription qu’elle décrit à un point de terminaison TLS de messagerie précis ; ne pas l’attribuer sans preuve au certificat du proxy présenté aux clients, à celui du serveur Exchange ni au certificat d’instance. Ne pas désactiver la vérification des certificats pour résoudre un problème.
• Évaluer les effets de l’installation selon le mode : en mode proxy, l’assistant vérifie les ports des instances du proxy et configure des règles entrantes du pare-feu Windows ; le filtrage des User-Agent de messagerie peut exclure certains clients. En mode PowerShell, les appareils communiquent directement avec Exchange ; selon Sophos, le proxy EAS n’a alors pas besoin d’un port de messagerie entrant. Autoriser et vérifier séparément la connexion d’administration sortante vers Exchange et le chemin de messagerie direct des appareils ; ne pas présenter les ports et filtres User-Agent des instances proxy comme le chemin de messagerie PowerShell. Selon Sophos, les journaux sont renouvelés quotidiennement, mais ne sont pas supprimés automatiquement. Les modifications, la protection des journaux et la gestion de l’espace et de leur conservation exigent une demande de changement distincte ; ne considérer aucun réglage par défaut comme validé ici.
• Limiter séparément le pilote Outlook en mode proxy : Sophos documente de possibles blocages à tort d’Outlook sur Android/iOS : lors du premier contact avec le proxy ou après une réinstallation, l’association du nom d’utilisateur et de l’identifiant ActiveSync peut échouer si plusieurs appareils sont concernés ou si l’identifiant a changé. Avant le pilote, relever les utilisateurs et appareils concernés ainsi que le fonctionnement initial de la messagerie ; après le premier contact, vérifier l’association et le flux de messagerie sur chaque appareil de test. Si un appareil ne peut être associé sans ambiguïté ou si la messagerie est bloquée, arrêter le pilote et rétablir le chemin de messagerie précédent approuvé ; ne pas appliquer d’autorisation générale ni inventer une correction d’identifiant.
• Réserver le compte de service au mode PowerShell : l’aide Sophos relative au compte de service décrit un compte dédié qui lit les informations sur les appareils ActiveSync, autorise ou bloque l’accès des appareils et gère les règles d’accès des appareils ActiveSync. Pour ces tâches, Sophos indique les rôles RBAC Exchange Mail Recipients et Organization Client Access ; selon Sophos, ni boîte aux lettres Microsoft 365, ni licence Microsoft 365, ni rôle Azure/Microsoft Entra ne sont nécessaires. Il s’agit de noms de rôles documentés, pas d’une validation des autorisations ou de l’authentification dans ce tenant. Vérifier avec l’équipe Exchange l’identité, l’attribution des rôles, la gestion des mots de passe et secrets, la MFA, l’accès conditionnel et la révocation ; ne créer ni compte ni attribution de rôle sur la seule base de cet article. La vérification des exigences de connexion du tenant est distincte de l’attribution des droits et ne justifie pas l’attribution de rôles d’annuaire supplémentaires.

Compte de service : variantes documentées et limites des modifications

La présentation suivante reprend l’aide Sophos relative au compte de service citée ci-dessus ; elle ne constitue pas une autorisation de configuration. La création du compte, les modifications des exigences relatives aux mots de passe, le retrait de licence ainsi que les modifications des rôles et des groupes nécessitent chacun une autorisation distincte, avec un état initial documenté et un retour arrière convenu. Les commandes sont des exemples tirés de la source ; aucune n’a été exécutée ici.

Préparer le compte : Exchange Online ou Exchange Server

Pour les deux variantes, Sophos décrit un nom d’utilisateur qui permet d’identifier la finalité du compte, par exemple smc_powershell, et la désactivation du paramètre imposant un changement de mot de passe à la prochaine connexion. Le nom donné en exemple n’est pas obligatoire. Pour Exchange Online, Sophos décrit également le retrait d’une licence Microsoft 365 attribuée automatiquement, car ce compte de service ne nécessite ni licence ni boîte aux lettres. Il ne s’agit pas d’une invitation à modifier des comptes existants, des exigences relatives aux mots de passe ou des licences pendant la vérification préalable.

Attribuer les rôles : deux alternatives cloud, une variante locale par groupe

Pour Exchange Online, Sophos documente deux méthodes d’attribution alternatives :

• Groupe de rôles dans Exchange admin center : sur admin.exchange.microsoft.com, le chemin Roles > Admin roles mène au groupe de rôles. Le nouveau groupe décrit reçoit un nom lié à sa finalité, par exemple smc_powershell_role, les rôles Mail Recipients et Organization Client Access, ainsi que le compte de service comme membre. Ce nom de groupe n’est lui aussi qu’un exemple.
• Attribution directe avec Exchange Online PowerShell : Sophos mentionne cette alternative pour les déploiements automatisés ou par script, ou lorsque la ligne de commande est privilégiée. Une session Exchange Online PowerShell est nécessaire ; pour attribuer les rôles, l’identité administrative qui exécute les commandes doit disposer de droits d’attribution autorisés séparément. Elle ne doit pas être confondue avec le compte de service dont l’accès sera vérifié ultérieurement. Sophos présente à cet effet l’ouverture de session suivante et les deux commandes d’attribution qui modifient l’état, et non une autorisation d’exécution :

Connect-ExchangeOnline
New-ManagementRoleAssignment -Role "Mail Recipients" -User "smc_powershell@<tenant>.onmicrosoft.com"
New-ManagementRoleAssignment -Role "Organization Client Access" -User "smc_powershell@<tenant>.onmicrosoft.com"

smc_powershell@<tenant>.onmicrosoft.com est l’adresse d’exemple inchangée provenant de la source : le nom du compte et <tenant> doivent correspondre à l’identité réelle du compte de service dans le cadre d’un changement autorisé séparément. Ne pas exécuter les commandes avec les espaces réservés tels quels. Sophos présente ensuite ce contrôle en lecture seule des attributions avec les colonnes Role et RoleAssigneeName :

Get-ManagementRoleAssignment -RoleAssignee smc_powershell@<tenant>.onmicrosoft.com | Select-Object Role, RoleAssigneeName

Selon Sophos, les attributions directes constituent un mécanisme RBAC Exchange Online valide et se comportent à l’exécution de la même manière que les attributions via un groupe de rôles. Cela ne vaut pas autorisation de connexion ou d’utilisation du service Sophos dans le tenant concerné.

Pour Exchange Server local, Sophos décrit un nouveau groupe de rôles portant un nom lié à sa finalité, doté des rôles Mail Recipients et Organization Client Access, et dont le compte créé précédemment est membre. L’alternative cloud par commandes ne fait pas partie de cette variante locale décrite par la source.

Vérifier séparément l’accès du compte à Exchange Online

Pour une vérification de l’accès du compte de service autorisée séparément, Sophos décrit une session Exchange Online PowerShell avec Connect-ExchangeOnline, suivie des cmdlets en lecture seule ci-dessous. La session doit vérifier l’accès du compte de service à contrôler, et non simplement celui d’une autre identité administrative :

Get-MobileDevice
Get-ActiveSyncDeviceAccessRule

Si l’une des cmdlets échoue, Sophos indique comme étape de vérification suivante l’attribution des deux rôles au compte de service. Les requêtes elles-mêmes ne corrigent aucune erreur ; aucun résultat de test ni aucune liste attendue d’appareils ou de règles ne sont disponibles ici. Des requêtes réussies attestent uniquement de cet accès à l’administration Exchange, et non de la compatibilité à l’exécution ou du chemin d’authentification du service Sophos, ni de l’envoi, de la réception ou de la synchronisation dans une application de messagerie.

Pas de solution de production par l’octroi de droits supplémentaires : Sophos avertit que Exchange Administrator fonctionne, mais accorde nettement plus de droits que nécessaire. La source limite l’exception au dépannage temporaire et déconseille expressément et vivement l’utilisation de ce rôle dans l’environnement de production ; une attribution permanente est donc également exclue. Il s’agit d’une description de l’éditeur, et non d’une réparation recommandée ou d’une autorisation d’élévation des droits. Même les modifications temporaires de privilèges nécessitent une autorisation propre et une planification de leur révocation. La source ne fournit à cet effet ni durée fixe ni commandes précises de révocation ou de restauration ; aucun retour arrière testé n’est affirmé ici.

Authentification EAS PowerShell : tentative d’authentification moderne et limite du repli vers Basic

La page Sophos sur l’authentification moderne concerne expressément le mode PowerShell uniquement. Pour Exchange Online, elle décrit une tentative d’authentification moderne si le module ExchangeOnlineManagement est disponible, suivie d’un repli vers Basic en cas d’échec ; pour un serveur Exchange local, elle décrit Basic pour la connexion d’administration, pas pour toute connexion d’un client de messagerie. Microsoft précise que Basic Authentication a été désactivée pour EAS et Remote PowerShell dans Exchange Online et ne peut être réactivée. Le repli décrit par Sophos n’est donc pas une solution utilisable pour Exchange Online. La présence du module ne démontre à elle seule ni le transport réellement utilisé par le service Sophos installé ni la prise en charge de l’authentification pour le cloud, le tenant et le compte de service. Ne déduire de ces sources aucune commande PowerShell à exécuter, réactivation de Basic, désactivation de la vérification TLS ou attribution générale de rôles.

Contradiction précise entre les sources : la configuration PowerShell Sophos indique outlook.office365.com pour le cloud mondial et précise que l’assistant ajoute /powershell-liveid ; la documentation Microsoft sur la connexion ne présente plus cette connexion Remote PowerShell que comme une méthode historique non prise en charge et décrit les connexions actuelles du module reposant sur REST. L’indication de Sophos sur la tentative d’authentification moderne ne permet pas de déterminer si le build précis du proxy utilise encore l’ancien chemin ou emploie plutôt des cmdlets REST prises en charge. Ni la présence du module ni une connexion Connect-ExchangeOnline réussie séparément ne confirment le chemin d’authentification emprunté par le service Sophos.

ARRÊT DE VALIDATION pour Exchange Online : avant tout pilote autorisé, Sophos et l’équipe Exchange doivent confirmer le build précis du proxy, la compatibilité hôte/module/environnement d’exécution, le cloud et le point de terminaison du protocole, le comportement OAuth/REST du service, les autorisations du compte de service et les exigences du tenant en matière de MFA et d’accès conditionnel. Séparément, l’application de messagerie réelle doit pouvoir s’authentifier auprès de la boîte aux lettres prévue, envoyer, recevoir et synchroniser les messages ; une connexion PowerShell réussie ou la mention « Last active » ne le prouvent pas. Si l’un de ces points demeure ouvert, ne recommander ni installation, ni modification de DefaultAccessLevel ou de la quarantaine, ni basculement général des clients.

Ordre documenté pour une nouvelle installation et un proxy existant — aucune autorisation d’exécution

L’aide Sophos sur l’authentification moderne citée ci-dessus distingue deux cas pour Exchange Online en mode PowerShell. Pour une nouvelle installation, elle décrit, sur l’hôte EAS prévu, l’ouverture de Windows PowerShell en tant qu’administrateur, l’installation du module ExchangeOnlineManagement, puis seulement l’installation ou la configuration PowerShell du proxy EAS. Pour un proxy déjà installé, elle décrit également l’ouverture de Windows PowerShell en tant qu’administrateur sur l’hôte du proxy : d’abord comparer la version installée du proxy à celle proposée par l’éditeur sous Standalone EAS Proxy Installer, puis installer le module et enfin relancer l’assistant de configuration. Cette comparaison de versions ne démontre ni qu’il s’agit de la version mondialement la plus récente ni qu’une mise à niveau est autorisée ; la prise en charge du build précis et la compatibilité hôte/module/environnement d’exécution restent à confirmer séparément. Cet ordre est documenté par la source et ne constitue pas une autorisation d’installation ou de mise à jour dans cet article. Le HOLD indiqué ci-dessus et un changement approuvé séparément, avec un état initial documenté et un retour arrière convenu, restent des prérequis.

Pour le proxy existant, Sophos décrit, après la préparation du module, la relance de l’application Windows Sophos Mobile EAS Proxy - Configuration Wizard. Dans l’assistant, la sélection d’une instance avec Instance type PowerShell Exchange/Office 365 est suivie de Save, sans modification des valeurs. La source décrit la répétition de cette sélection et de cet enregistrement sans modification pour chaque autre instance de ce type, puis l’achèvement des étapes restantes de l’assistant. Il s’agit d’une opération de configuration distincte, et non de Add pour une nouvelle connexion ou de Save après le téléversement d’un certificat dans Sophos Mobile. Même un enregistrement sans modification ne constitue pas un diagnostic en lecture seule et nécessite un changement approuvé séparément. Cette séquence ne permet de déduire ni un mécanisme interne précis de mise à jour, ni la nécessité d’un redémarrage ou d’un nouveau téléversement de certificat ; elle ne démontre ni une authentification moderne réussie ni une correction testée.

Critères d’acceptation et limite du retour arrière

Avant tout pilote ultérieur approuvé séparément, documenter l’état initial selon le mode : points de terminaison EAS/DNS et profils de messagerie actuels des appareils concernés, règles d’accès Exchange existantes et décisions individuelles, instances du proxy, ports, pare-feu et filtres User-Agent, association des certificats, compte de service et rôles, Email-Account-Policies et tâches SSP, ainsi que le flux de messagerie avec des boîtes aux lettres de test. Le retour arrière doit être approuvé au préalable avec les équipes d’exploitation Exchange et Mobile pour le chemin de messagerie concerné et inclure le rétablissement du trajet client précédent, des décisions d’accès et des attributions ; le seul arrêt du service proxy ne suffit pas après une modification de la configuration des clients. Fixer la fenêtre de changement et les critères d’interruption également pour un échec du téléversement d’un certificat ou un basculement partiel. Dans un pilote autorisé et limité, surveiller séparément la connexion du service à Sophos Mobile, l’authentification d’administration auprès d’Exchange et le flux de messagerie des appareils ; après interruption, vérifier le rétablissement de l’envoi, de la réception et de la synchronisation pour chaque application de test concernée. Ni l’apparition d’une instance dans Sophos Mobile ni une connexion réussie du service ne prouvent l’accès des clients. Tant que l’installateur, le chemin d’authentification, la chaîne de confiance et un retour arrière testé ne sont pas vérifiés, l’installation et le basculement en production ne sont pas autorisés. Ces conditions concernent l’autorisation opérationnelle, pas la publication de ces vérifications documentaires préalables.