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 la description Sophos de l’installation, 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 Sophos, 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 : la description Sophos du 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. La description distincte de la configuration Sophos 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 Sophos 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 description Sophos du 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 entrées de journal sont déplacées chaque jour dans un nouveau fichier nommé selon le modèle EASProxy.log.yyyy-mm-dd. Ces fichiers quotidiens ne sont pas supprimés automatiquement et peuvent, avec le temps, poser des problèmes d’espace disque. Sophos recommande donc de mettre en place un processus qui déplace les fichiers journaux vers un emplacement de sauvegarde. La destination de sauvegarde, la protection des accès, la protection des données personnelles et la durée de conservation doivent être définies avec l’équipe d’exploitation ; cette recommandation n’autorise pas l’exécution ici d’un processus d’archivage ou de suppression. 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 : Sophos décrit à cet effet 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.

Mode proxy : assistants et périmètre de configuration

Les sections suivantes décrivent les écrans et les choix documentés par Sophos pour EAS proxy, et non pour l’instance PowerShell. Elles servent à préparer complètement un changement ultérieur. Ne rien installer, ajouter, importer, téléverser, enregistrer ou redémarrer ici. Ces opérations exigent un changement approuvé séparément, une compatibilité build/hôte/serveur de messagerie confirmée, une confiance des certificats planifiée ainsi qu’un état initial, une fenêtre de maintenance, des critères d’interruption et un retour arrière vérifié. La contradiction entre les sources sur le premier démarrage du service reste ouverte ; la description ci-dessous ne la résout pas.

Du Setup Wizard au Configuration Wizard

Sophos décrit Sophos Mobile EAS Proxy Setup.exe comme point d’entrée du Sophos Mobile EAS Proxy - Setup Wizard. Sur Choose Install Location, le dossier de destination est sélectionné ; Install lance l’installation. Une fois celle-ci terminée, le Sophos Mobile EAS Proxy - Configuration Wizard démarre automatiquement. Le dossier de destination et ce passage automatique font donc partie de la planification, mais ne constituent pas une invitation à lancer un installateur non vérifié.

Dans Sophos Mobile server configuration, l’URL du serveur Sophos Mobile déterminée au préalable est saisie. Use proxy server est un paramètre facultatif si le proxy EAS a besoin d’un proxy réseau pour sa connexion à Sophos Mobile. Il s’agit du chemin de contrôle HTTPS, et non du chemin de messagerie des appareils ni de la configuration WinHTTP distincte, à l’échelle du système, pour la connexion à Exchange. Modifier l’un de ces chemins ne remplace ni la vérification ni l’autorisation de l’autre.

TLS entrant, importation de certificats et authentification des clients

Sophos recommande Use SSL for incoming connections (Clients to EAS Proxy) pour protéger la connexion des clients de messagerie au proxy. Ce choix fait apparaître Configure server certificate pour le certificat HTTPS de ce point de terminaison. L’assistant distingue :

• Create self-signed certificate : option documentée lorsqu’aucun certificat de confiance n’est encore disponible. La page suivante demande un serveur accessible depuis les appareils clients. L’accessibilité seule n’établit pas la confiance dans le certificat ; cette option n’est pas une recommandation générale pour le chemin de messagerie en production.
• Import a certificate from a trusted issuer : pour un certificat de confiance existant, les choix sont PKCS12 with certificate, private key and certificate chain (intermediate and CA) ou Separate files for certificate, private key, intermediate and CA certificate. Les informations de certificat correspondant au type choisi sont ensuite renseignées. L’importation comprend donc aussi la clé privée et la chaîne ; les fichiers et les clés doivent être protégés et associés au bon point de terminaison.

L’option Use client certificates for authentication ajoute un certificat client aux identifiants du proxy EAS ; elle ne remplace pas ces identifiants. Ce choix fait apparaître SMC client authentication configuration. Le certificat de l’autorité de certification (CA) dont doivent être issus les certificats clients y est sélectionné. Lors de la tentative de connexion, le proxy EAS vérifie cette filiation. Distinguer cette CA du certificat serveur HTTPS, du certificat du serveur Exchange et des certificats d’instance à téléverser ultérieurement. Avant toute autorisation, les clients de messagerie prévus et leur approvisionnement en certificats doivent prendre en charge ce parcours ; l’écran seul ne le prouve pas.

SSL Certificate Wizard distinct : demande et exigences historiques Apple

Il s’agit d’un inventaire documentaire, pas d’une autorisation de créer un certificat. Le programme d’installation place cet assistant distinct dans C:\Program Files (x86)\Sophos\Sophos Mobile EAS Proxy\tools\Wizard ; son exécutable est Sophos Mobile SSL Certificate Wizard.exe. Sur Upload CSR, Open CSR ouvre la demande de signature de certificat (CSR) si l’autorité de certification accepte le texte collé d’une demande. Sur Import Certificate Files, le certificat de la CA téléchargé lors de Upload CSR doit être renseigné dans Select CA certificate file. Certificate created indique le dossier du certificat terminé pour la configuration ultérieure. Consigner cet emplacement et sauvegarder tout le dossier de manière protégée, clés privées comprises. Ne pas lancer l’assistant ni créer ou importer de fichiers ici ; les limites existantes concernant les changements, la confiance et le rétablissement restent applicables.

Pour un certificat autosigné créé hors de Sophos Mobile Configuration Wizard et de SSL Certificate Wizard, Sophos renvoie aux exigences historiques Apple pour iOS 13 et macOS 10.15 : les clés RSA du certificat serveur TLS et de la CA émettrice doivent compter au moins 2048 bits, leurs signatures doivent utiliser SHA-2 et le nom DNS du serveur doit figurer dans Subject Alternative Name (SAN) ; sa présence dans le seul Common Name ne suffit pas. Pour les certificats serveur TLS émis après le 1er juillet 2019 (selon NotBefore), ces exigences historiques imposent aussi l’Extended Key Usage id-kp-serverAuth et une validité maximale de 825 jours entre NotBefore et NotAfter. Leur non-respect peut empêcher les connexions TLS sur ces plateformes. Cette limite historique ne constitue ni une validation suffisante pour les plateformes ou durées actuelles ni une preuve de confiance. Vérifier séparément les exigences actuelles et la distribution de confiance ; les exclusions d’inscription et l’interdiction de contourner TLS restent applicables.

Champs de chaque instance du proxy EAS

Sur EAS Proxy instance setup, Sophos décrit une ou plusieurs instances. Pour chaque instance prévue, consigner séparément les valeurs et leur association :

• Instance type : EAS proxy, et non PowerShell Exchange/Office 365.
• Instance name : un nom librement choisi pour identifier l’instance.
• Server port : le port de messagerie entrant du proxy EAS. Avec plusieurs instances proxy, chacune doit utiliser un port différent. Ne pas déduire de cette description un port par défaut ; l’occupation des ports, les autorisations réseau et le trajet des clients doivent correspondre à l’architecture approuvée.
• Require client certificate authentication : exigence propre à l’instance imposant aux clients de messagerie de s’authentifier avec un certificat client lors de la connexion. Vérifier ce choix par rapport à la CA client décrite plus haut et à l’approvisionnement réel en certificats.
• ActiveSync server : nom ou adresse IP de l’instance de serveur Exchange ActiveSync à laquelle cette instance proxy se connecte. La valeur saisie doit correspondre au CN ou SAN de son certificat TLS ; une adresse IP quelconque accessible ne suffit pas.
• SSL : protection de la connexion de l’instance proxy au serveur Exchange ActiveSync par SSL ou TLS selon sa prise en charge. Cette connexion est distincte de Use SSL for incoming connections (Clients to EAS Proxy) ; le libellé du champ n’autorise ni protocoles obsolètes ni contournement TLS.
• Enable Traveler client access : selon Sophos, uniquement pour un accès nécessaire de clients Traveler sur des appareils autres qu’iOS. La limite liée à l’absence d’identifiant d’appareil indiquée plus haut demeure ; ce choix n’étend pas l’autorisation d’Exchange Online en mode proxy et ne garantit pas la vérification de l’autorisation de chaque requête.

Add et exportation du certificat d’instance

Après la saisie des données de l’instance, Add ajoute la nouvelle instance à la liste Instances. L’installateur génère pour chaque instance proxy un certificat distinct pour sa future connexion à Sophos Mobile. Après Add, un message relatif au téléversement apparaît ; OK ouvre une boîte de dialogue indiquant le dossier du certificat généré.

La même boîte de dialogue peut aussi être ouverte sur EAS Proxy instance setup en sélectionnant l’instance concernée puis Export config and upload to Sophos Mobile server. Documenter le dossier du certificat et l’instance associée, puis conserver le fichier de manière protégée : ce dossier sera nécessaire pour le téléversement ultérieur. Selon Sophos, les autres instances sont configurées par un nouvel Add. Il ne s’agit ni du Save sans modification d’une instance PowerShell existante ni de l’enregistrement d’un certificat téléversé dans Sophos Mobile.

Une fois toutes les instances nécessaires définies, la procédure d’installation indique Next, avec vérification des ports et création de règles entrantes du pare-feu Windows. Allowed mail user agents propose Allow all mail user agents, sans restriction, ou Only allow the specified mail user agents, avec sélection et répétition de Add pour chaque client de messagerie autorisé. Dans la variante limitée, les clients non répertoriés sont rejetés. Ni une autorisation générale ni une restriction non vérifiée ne sont approuvées ici.

Téléverser tous les certificats d’instance — ordre de démarrage non résolu

Le premier démarrage documenté est contradictoire. La procédure d’installation revient au Setup depuis Sophos Mobile EAS Proxy - Configuration Wizard finished avec Finish. Elle demande ensuite Start Sophos Mobile EAS Proxy server now et Finish, donc un premier démarrage du service avant le téléversement du certificat. La description distincte de la configuration avertit au contraire que Sophos Mobile rejette la connexion sans téléversement préalable et que le service ne démarre pas. Aucune clarification de l’éditeur ni aucun ordre sûr testé ne sont établis ici. Ne pas en déduire une modification de case à cocher ou un autre contournement ; avant le premier démarrage, clarifier l’ordre pour le build précis avec Sophos et l’équipe d’exploitation.

Le téléversement documenté ensuite couvre expressément chaque instance proxy, et pas seulement les connexions PowerShell :

1. Dans Sophos Fusion, ouvrir My Products > Mobile, puis Setup > Sophos setup et l’onglet EAS proxy.
2. Sous External > Upload a file, sélectionner le certificat généré lors de la configuration et associé à l’instance concernée. S’il existe plusieurs instances, répéter le téléversement pour tous les certificats d’instance.
3. Enregistrer avec Save. Il s’agit de l’enregistrement dans Sophos Mobile, et non de Add dans l’assistant Windows.
4. Dans Windows, Sophos indique la boîte de dialogue Services et le redémarrage du service EASProxy.

Cette liste constitue un inventaire de configuration, pas une autorisation d’exécution malgré la contradiction sur le démarrage. Le téléversement, Save et surtout le redémarrage du service, qui provoque une interruption, relèvent exclusivement du changement autorisé séparément. Conserver au préalable l’association complète des instances et des certificats ainsi que l’état du service ; les critères d’interruption et de retour arrière convenus s’appliquent aux téléversements partiels, aux connexions rejetées ou à l’échec du démarrage. Un téléversement ou un redémarrage réussi ne garantit ni l’authentification des appareils ni le flux de messagerie. Les vérifications et la restauration réelles restent limitées au pilote approuvé et à ses boîtes aux lettres de test.

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

La présentation suivante reprend la description Sophos du compte de service ; 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 description Sophos de 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 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 une installation existante, la source recense cette commande de registre en lecture seule, sur l’hôte Windows : Get-Item -Path "Registry::HKLM\SOFTWARE\Wow6432Node\Sophos\Sophos Mobile Control EAS Proxy\". Elle dépend du chemin de registre indiqué ; une clé absente ou son contenu ne prouvent ni la version de chaque build ni sa compatibilité d’exécution. Aucune sortie ni propriété du registre n’a été observée ou inventée ici. Pour les installations nouvelles comme existantes, la source mentionne également Install-Module -Name ExchangeOnlineManagement comme installation de module modifiant le système, dans Windows PowerShell avec droits administratifs. Ce n’est pas une recommandation de réparation automatique : une autorisation de changement distincte, une vérification du support et de la compatibilité hôte/module/environnement d’exécution ainsi qu’un plan de rétablissement sont requis. Aucune de ces commandes n’a été exécutée ici. Ni l’inventaire du registre ni la présence du module ne prouvent le comportement OAuth/REST du service ; le HOLD et Save sans modification pour chaque instance PowerShell existante restent applicables.

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.

Quarantaine : exemple distinct tiré de la source, pas une finalisation de l’installation

La quarantaine à l’échelle de l’organisation constitue un changement d’accès distinct, et non la finalisation de l’installation. L’aide au choix de l’architecture EAS décrit les prérequis, les limites d’ABQ et des protocoles, les effets et le retour arrière. L’exemple documenté dans la source tient expressément sur une seule ligne et son exécution n’est pas autorisée ici :

Set-ActiveSyncOrganizationSettings -DefaultAccessLevel quarantine -UserMailInsert "Bitte registrieren Sie Ihr Gerät bei Sophos Mobile."

-DefaultAccessLevel quarantine définit le niveau d’accès par défaut à l’échelle de l’organisation ; le texte entre guillemets après -UserMailInsert est une invitation à l’inscription personnalisable pour le message de quarantaine. Le HOLD indiqué plus haut et l’approbation distincte du changement et du retour arrière restent nécessaires.

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.