Sophos Mobile : gérer le Wi-Fi et les certificats pour Windows

En bref : Pour un appareil Windows déjà géré par Sophos Mobile, créer sous Policies > Windows une stratégie pilote distincte, ajouter les configurations Wi-Fi et, si nécessaire, Root certificate, Client Certificate ou SCEP, enregistrer et attribuer la stratégie à un seul appareil de test. Au préalable, conserver un accès indépendant du nouveau réseau Wi-Fi ainsi que la connexion actuelle qui fonctionne. Vérifier ensuite sur l’appareil la connexion et l’accès à Sophos Mobile. L’enregistrement d’une stratégie ne prouve pas que l’appareil a adopté le nouveau profil.

Cette procédure concerne Sophos Mobile MDM pour des ordinateurs Windows déjà inscrits, et non l’agent Sophos Endpoint, la configuration VPN de Sophos Firewall ou le client Sophos Connect. Les pages consacrées aux stratégies Windows décrivent des configurations, mais ne prouvent pas leur prise en charge par chaque build et chaque édition de Windows. Avant toute attribution en production, vérifier indépendamment, pour l’appareil concerné, l’édition et le build de Windows, le statut du support Microsoft (y compris une éventuelle autorisation ESU nécessaire), le mode d’inscription à Sophos Mobile et la compatibilité Sophos actuelle. La prise en charge de Windows 10 n’est pas garantie ici. Aucun test sur un tenant ou un appareil n’a été effectué.

Avant toute modification

Vérifier que l’appareil concerné est déjà inscrit dans Sophos Mobile, que Policies > Windows et les configurations requises sont disponibles dans le tenant, et que la personne responsable a autorisé l’attribution. L’inscription est une procédure distincte ; la présence d’un agent Endpoint ne la remplace pas.
Confirmer le SSID, l’authentification, la chaîne de confiance existante et l’identité utilisateur ou appareil requise auprès des responsables Wi-Fi et PKI. Un profil de test WPA2-Personal ne remplace pas une connexion 802.1X avec certificats. L’interface de configuration manuelle Wi-Fi ne documente que WPA (Personal) et WPA2 (Personal). Pour d’autres connexions existantes, Sophos décrit l’importation d’un profil XML préalablement exporté depuis Windows ; l’adéquation du réseau Wi-Fi concerné doit être vérifiée sur l’appareil pilote.
Prévoir pour l’appareil pilote une seconde voie réseau fonctionnelle, par exemple une connexion filaire autorisée, ainsi qu’un accès local. Si le Wi-Fi est la seule voie de gestion, ne pas commencer par supprimer le profil actuel ou l’autorité de certification (CA) actuelle. Organiser un second accès et désigner une personne responsable du retour arrière.
Ne pas activer l’option Forbid manual configuration dans Restrictions pour cet appareil pilote : Sophos indique qu’à l’application, elle supprime les profils Wi-Fi existants configurés par les utilisateurs ainsi que ceux de Wi-Fi Sense. De plus, l’ensemble de la configuration Restrictions ne s’applique pas à Windows Pro. Disable VPN settings bloque seulement des paramètres Windows ; ce n’est pas une configuration VPN.
Pour les certificats, faire valider la CA émettrice, la période de validité, le Target store souhaité et le stockage des clés autorisé. Un certificat racine est une ancre de confiance, pas un certificat client. N’activer Key is exportable qu’en cas de besoin justifié ; une clé privée et un fichier Wi-Fi exporté n’ont pas leur place dans des tickets, des conversations ou des espaces de stockage publics.

Configurer la stratégie et le Wi-Fi sur l’appareil pilote

Dans Sophos Mobile, ouvrir Policies > Windows > Create, sélectionner un type de stratégie Windows et, sur Edit policy, saisir un nom qui identifie clairement le pilote ainsi qu’une description. Ajouter les éléments nécessaires avec Add configuration, puis modifier chacun en cliquant sur son nom.
Pour un réseau de test simple, choisir Wi-Fi > Configure manually. Exemple : remplacer SSID PILOT-WLAN par le SSID réel ; régler Security type sur WPA (Personal) ou WPA2 (Personal) selon la configuration effective, puis saisir le mot de passe correspondant. N’utiliser Hidden network que pour un réseau réellement masqué et Connect automatically que si une connexion automatique est souhaitée. Cet exemple ne constitue pas une recommandation sur la sécurité d’une architecture Wi-Fi de production.
Autre possibilité, pour reprendre une connexion Windows existante : sur un ordinateur Windows autorisé où le réseau figure sous Known networks, ouvrir l’invite de commandes en tant qu’administrateur. Vérifier le nom du profil avec netsh wlan show profiles, puis exporter le profil vers un dossier préalablement créé et à accès restreint avec netsh wlan export profile "<SSID>" key=clear folder=<Destination>. Remplacer <SSID> par le nom de profil affiché et <Destination> par le dossier de destination. Le fichier XML produit contient le mot de passe Wi-Fi en clair. Sous Wi-Fi > Create from existing connection > Wi-Fi profile, téléverser le fichier XML, puis supprimer de manière sécurisée le fichier d’exportation local ; ne copier ni la sortie de la commande ni le fichier dans un ticket. Ne pas exécuter key=clear sur des ordinateurs partagés ou non protégés.
Enregistrer sur Edit policy avec Save. Dans Policies > Windows, sélectionner le triangle bleu de la stratégie pilote, puis Assign ; sur Select devices, cocher exclusivement l’appareil de test désigné et cliquer sur Finish. Ne pas choisir par erreur Select device groups pour un groupe de production : selon Sophos, les stratégies Windows ne proposent pas ensuite d’écran Schedule task.
Sur l’appareil pilote, tout en conservant l’accès indépendant, vérifier la connexion Wi-Fi disponible ainsi qu’une ressource interne effectivement nécessaire ; s’assurer ensuite que l’appareil continue de communiquer avec Sophos Mobile. Si la stratégie ne produit pas l’effet attendu, vérifier d’abord l’appareil ciblé, l’attribution de la stratégie, le prochain contact de l’appareil, le SSID et le type de sécurité, ainsi que l’état de la connexion Wi-Fi existante. Ne pas masquer un problème par des réattributions massives.

Certificats : distinguer confiance, identité et SCEP

Pour une connexion 802.1X ou toute autre connexion dépendant de certificats, l’exemple WPA-Personal ci-dessus ne suffit pas. L’importation d’un profil XML de Wi-Fi d’entreprise avec un certificat client ou SCEP n’est pas une procédure 802.1X opérationnelle documentée par Sophos : le fonctionnement de l’importation, de la sélection du certificat, de l’authentification et de l’ordre d’application dans la combinaison précise Windows/inscription/PKI/Wi-Fi reste à vérifier. Les composants de certificat suivants ne doivent donc être testés que sur un appareil individuel, avec les responsables Wi-Fi/PKI et un accès réseau indépendant :

Root certificate : téléverser l’ancre de confiance approuvée

Avant le téléversement, vérifier le fichier de CA X.509 approuvé (PEM ou DER) indépendamment de l’affichage Sophos par rapport à la validation PKI : identité du fichier/empreinte, Subject, Issuer, validité et chaîne de certificats prévue. Les extensions courantes sont .cer, .crt et .pem pour PEM, et .cer et .der pour DER. Il s’agit d’exemples, pas d’une liste exhaustive des extensions autorisées. En particulier, un fichier .cer peut contenir l’un ou l’autre encodage ; l’extension seule ne détermine pas le format.

Téléverser le fichier approuvé sous Edit policy > Add configuration > Root certificate > Upload a file. Il est également possible de le faire glisser depuis l’Explorateur de fichiers et de le déposer dans la zone File. Selon Sophos, Certificate name affiche le Issuer Distinguished Name (DN) du certificat téléversé, et non une identité vérifiée du certificat de CA ; ce champ seul ne prouve pas que l’ancre de confiance est la bonne. Cliquer sur Apply, puis sur Save.

Pour chaque certificat racine supplémentaire, ajouter une configuration Root certificate distincte à la même stratégie. Les certificats de cette stratégie peuvent ensuite être sélectionnés comme Root certificate dans sa configuration SCEP. Ne distribuer que l’ancre de confiance prévue, pas un certificat quelconque téléchargé.

Client Certificate : définir l’identité et le stockage de la clé privée

Pour un certificat client déjà émis, File accepte les formats PEM ou PKCS #12. Dans la configuration Client Certificate, cliquer sur Upload a file et sélectionner le fichier contenant le certificat. Il est également possible de faire glisser le fichier depuis l’Explorateur de fichiers vers la zone Upload a file. Après le téléversement, Certificate name affiche la valeur Subject. Target store > User concerne l’utilisateur inscrit auprès de Sophos Mobile ; Device rend le certificat accessible à tous les utilisateurs de cet ordinateur.

Key location > Software conserve la clé privée dans un magasin de clés logiciel ; TPM or software utilise un TPM s’il est disponible, sinon un magasin de clés logiciel. TPM n’installe pas le certificat si aucun TPM n’est présent ou s’il est désactivé dans le BIOS. Windows Hello for Business stocke la clé privée dans un conteneur Windows Hello for Business. Container name désigne précisément le conteneur dans lequel la clé privée de ce certificat est stockée ; choisir un conteneur adapté à l’environnement.

Avec Key is exportable, les utilisateurs peuvent exporter la clé privée du certificat en même temps que celui-ci. Ce n’est donc pas seulement le certificat public qui devient copiable, mais aussi la clé secrète associée. Le choix de l’emplacement de stockage et de l’exportabilité doit respecter les exigences de sécurité de la PKI, et non simplement permettre le téléversement. La consigne donnée dans les prérequis reste valable : n’activer cette option qu’en cas de besoin justifié et ne pas copier de clés privées dans des tickets, des conversations ou des espaces de stockage publics. Vérifier sur l’appareil pilote le magasin de certificats réel et l’authentification visée.

SCEP : convenir de l’émission et de l’identité avec l’équipe PKI

Au lieu de téléverser une identité existante, le client demande un certificat à la CA. Pour l’intégration à une CA Windows compatible SCEP documentée par Sophos, Sophos Fusion doit en principe pouvoir joindre par HTTP(S) deux chemins distincts : <YOUR-SCEP-SERVER>/CertSrv/MSCEP (URL du serveur SCEP) et <YOUR-SCEP-SERVER>/CertSrv/MSCEP_ADMIN (URL du challenge) ; vérifier séparément auprès de l’équipe PKI les autorisations du pare-feu et les identifiants habilités. Pour un serveur SCEP Windows 2003, Sophos indique exceptionnellement /CertSrv/MSCEP comme URL du challenge également ; ne pas étendre cette exception à d’autres serveurs.

Avant d’autoriser les connexions réseau, ouvrir My Products > Mobile dans Sophos Fusion et vérifier le nom d’hôte dans la barre d’adresse du navigateur : dans la première partie de l’URL, la région du compte figure immédiatement après smc-user-if-cloudstation-. C’est cette région qui compte, et non l’emplacement de l’administrateur ou de l’appareil. Pour SCEP, autoriser les connexions entrantes de Sophos Fusion vers le serveur SCEP sur TCP 443 et limiter les adresses sources à celles documentées pour cette région. Avant de créer ou d’activer la règle de pare-feu, la personne responsable du changement PKI/réseau doit récupérer maintenant la liste actuelle des adresses sources Sophos pour SCEP, y sélectionner uniquement les adresses de la région du compte identifiée et les approuver pour ce changement précis. Consigner la région du compte, la date de consultation et les adresses sources approuvées dans le journal du changement. Cette consultation en direct fournit les adresses variables, et non un guide de configuration supplémentaire ; ne pas déduire d’un ancien exemple une liste d’adresses IP valable indéfiniment. En l’absence d’une liste actuelle approuvée pour cette région du compte, s’arrêter ici et ne créer ni activer la règle de pare-feu ; ne jamais élargir les sources autorisées à d’autres régions ou à des adresses arbitraires.

Ces URL sont définies globalement dans Setup > Sophos setup > SCEP. Cette configuration globale constitue un changement PKI distinct ; ne pas présumer que ces chemins de CA Windows conviennent à d’autres implémentations SCEP. Convenir aussi des paramètres suivants avec l’équipe PKI :

Dans User et Password, saisir les identifiants du compte autorisé à créer un code de challenge et disposant des droits nécessaires à l’inscription des certificats. Dans User, utiliser le format de connexion username@domain. Ce compte de service SCEP global n’est pas l’identité utilisateur qui doit figurer ensuite dans le Subject du certificat ; ne pas copier d’identifiants dans les exemples ou les tickets.
Dans Challenge characters, sélectionner les types de caractères du mot de passe de challenge. Dans Challenge length, conserver la longueur prédéfinie. Ces champs concernent le mot de passe, et non l’URL Challenge de la stratégie Windows.
Ne désactiver Use HTTP proxy que si Sophos Mobile doit délibérément contourner le proxy HTTP lors de la connexion au serveur SCEP. Cette option n’est disponible que si le proxy HTTP est activé ; son contournement n’est pas un prérequis général à SCEP.

Selon Sophos, Save teste uniquement la connexion au serveur SCEP, pas l’émission ou le renouvellement du certificat sur l’appareil.

Dans la stratégie Windows, ajouter d’abord le certificat de CA en tant que Root certificate, puis SCEP, et définir les champs avec l’équipe PKI :

Description décrit cette configuration SCEP particulière, pas l’ensemble de la stratégie. Dans URL, saisir l’adresse web du serveur de CA ; %_SCEPPROXYURL_% renvoie à l’URL du serveur SCEP définie globalement.
Subject est le nom de la personne ou de l’appareil qui doit recevoir le certificat. Des variables représentant des données utilisateur ou des propriétés de l’appareil peuvent être utilisées. C’est la valeur obtenue après remplacement de toutes les variables par les données réelles qui compte : elle doit être un nom X.500 valide et correspondre à l’identité prévue. CN=%_USERNAME_% n’est qu’un exemple de syntaxe pour une identité utilisateur, pas un Subject d’appareil universel. Lors de l’attribution de la stratégie, %_USERNAME_% est remplacé par la propriété Exchange Login de l’utilisateur affecté à l’appareil. Il ne s’agit pas automatiquement de son adresse e-mail, de son nom de connexion Windows ou du compte de service SCEP global défini sous User. Vérifier cette propriété avant l’attribution et, sur l’appareil pilote, confronter le nom X.500 obtenu à Exchange Login et aux exigences de la PKI ; n’utiliser une variable d’appareil que si son adéquation au mode Windows/inscription concerné est confirmée.
Sous Subject Alternative Name, ajouter si nécessaire une ou plusieurs entrées SAN. Pour chaque entrée, cliquer sur Add, puis saisir le type et la valeur du SAN. Vérifier les valeurs par rapport à l’identité requise et aux exigences de la CA ; un Subject approprié ne remplace pas cette vérification.
Challenge est l’adresse web permettant d’obtenir un mot de passe de challenge auprès du serveur SCEP. %_CACHALLENGE_% renvoie à l’URL du challenge définie globalement ; c’est une variable d’URL, pas le mot de passe de challenge lui-même. Sous Root certificate, sélectionner le certificat de CA approprié. La liste contient tous les certificats téléversés dans les configurations Root certificate de la stratégie actuelle ; ce n’est pas un inventaire général des certificats du tenant.
Retries définit le nombre de nouvelles tentatives lorsque le serveur répond pending, c’est-à-dire que l’émission est encore en attente. Retry delay est l’intervalle entre ces tentatives en secondes. Définir ces deux valeurs en fonction du processus d’émission de la PKI ; des tentatives supplémentaires ne corrigent ni des droits de challenge incorrects ni une identité invalide.
Key size est la taille de la clé publique dans le certificat émis. La valeur doit correspondre à la taille de clé configurée sur le serveur SCEP, et pas seulement aux exigences générales de la CA. Confirmer la valeur précise avec l’équipe PKI ; elle ne détermine pas un emplacement de stockage ou une exportabilité de la clé comme dans Client Certificate.
Sous Certificate usage, définir l’usage prévu : Use as digital signature autorise l’utilisation pour des signatures numériques, Use for encryption pour le chiffrement de données. Ne pas assimiler ces usages à un accès Wi-Fi ou à un tunnel VPN déjà fonctionnel ; le choix doit correspondre au certificat prévu et aux exigences de la CA.

Lors de la création de la stratégie, définir SCEP renewal interval, puis vérifier l’émission et le renouvellement réels auprès de la CA sur l’appareil pilote. Sans connexion à la CA confirmée ni correspondance univoque des identités, ne rien attribuer en production.

Le succès ne se résume pas à « stratégie attribuée » : le bon certificat, avec la bonne identité et une validité adéquate, doit apparaître sur l’appareil pilote dans le contexte utilisateur ou appareil prévu, permettre l’authentification de la connexion visée et préserver le contact avec Sophos Mobile. Si SCEP échoue, vérifier d’abord avec l’équipe PKI l’accès à la CA, les droits liés au challenge, Subject/SAN, la confiance dans la CA, les paramètres des clés et l’état de l’appareil ; ne pas désactiver la vérification des certificats ou la validation du serveur pour faire réussir le test.

Préparer un retour arrière avec un accès indépendant

En cas d’échec, laisser autant que possible intactes la connexion fonctionnelle et la CA existantes ; un retour arrière sans interruption n’est pas garanti. Par l’accès indépendant vérifié au préalable, contrôler d’abord sur l’appareil concerné le nom de la stratégie réellement attribuée et la connexion locale. Corriger la stratégie pilote ou attribuer de façon ciblée une stratégie Windows fonctionnelle préparée à l’avance au même appareil individuel ; ne retirer la configuration de test qu’après un nouveau contact et la confirmation du bon fonctionnement du Wi-Fi. Sophos ne documente aucune action Uninstall policy propre à un appareil pour les stratégies Windows : cette action ne s’applique qu’aux stratégies Android, Knox et iOS. Selon la documentation, Unassign agit sur tous les appareils d’une stratégie et ne constitue donc pas un retour arrière sûr pour un seul appareil. Les modifications apportées à d’autres stratégies se synchronisent automatiquement au prochain contact de l’appareil ; sans contact, il ne faut pas prétendre que le retour arrière a réussi. Avant toute modification en production, la synchronisation de la stratégie, l’authentification Wi-Fi réelle et la possibilité d’un retour arrière local doivent avoir été observées et validées sur l’appareil Windows précisément inscrit, avec un second accès sécurisé.

Si l’appareil est déjà hors ligne, ne pas révoquer de manière centralisée la CA, les identifiants SCEP ou les anciens profils Wi-Fi, ni modifier une stratégie de groupe au hasard. Rétablir d’abord l’accès local par la seconde voie convenue et relever l’état réel ; revérifier ensuite l’attribution pilote et la validité des certificats. La suppression éventuelle des certificats ou profils restés sur le client après un changement de stratégie n’est pas documentée ici comme un mécanisme automatique garanti et doit être vérifiée pour le mode Windows/Sophos Mobile utilisé.

Limite concernant le VPN : La liste actuelle des configurations de stratégies Windows de Sophos comprend le Wi-Fi, les certificats racines/clients et SCEP, mais aucun composant VPN Windows autonome. L’option Disable VPN settings de Restrictions bloque des paramètres ; elle ne déploie pas de VPN. Pour une connexion VPN, prévoir séparément le client, le protocole de tunnel, la passerelle et l’authentification ; l’installation d’un certificat ne crée pas à elle seule un tunnel VPN. Les étapes de déploiement de Sophos Connect pour Windows décrivent la voie distincte du client pare-feu/VPN.