Planifier le Wi-Fi, les certificats, le VPN et le proxy Apple avec Sophos Mobile

Périmètre : Sophos Mobile dans Sophos Fusion (anciennement Sophos Central), sur iPhone et iPad sous iOS/iPadOS. Ce document distingue les stratégies d’appareil iOS (Device Policy) des stratégies d’utilisateur iOS (User Policy). Il ne constitue ni une procédure de configuration pas à pas testée pour un tenant précis, ni un guide macOS, ni une autorisation de déploiement massif en production. Vérifiez d’abord sur l’appareil cible la version du système, le mode d’inscription, la supervision (Supervision), le type de stratégie et les fonctions disponibles dans votre tenant.

⚠️ Ne coupez pas la connexion : un mauvais certificat Wi-Fi/EAP, une autorité de certification SCEP inaccessible, un PAC/WPAD défaillant ou un tunnel VPN peuvent aussi interrompre le canal de retour des tâches MDM. Avant toute modification, démontrez qu’une connexion indépendante du profil modifié et une solution de dépannage sur place sont disponibles. Un retour arrière enregistré dans la console n’atteint pas automatiquement un appareil bloqué hors ligne.

Distinguer d’abord le mode d’administration

Device Enrollment n’implique pas automatiquement la supervision : Automated Device Enrollment supervise l’appareil, mais ce n’est pas nécessairement le cas des autres méthodes. Apple User Enrollment ne le supervise jamais et concerne les données administrées, non l’ensemble de l’appareil personnel. Pour le BYOD, un Managed Apple Account et le consentement de la personne sont des préalables. Ce mode ne permet ni proxy HTTP global, ni VPN classique couvrant tout l’appareil, ni paramètres de proxy dans la configuration Wi-Fi administrée ; Sophos ne peut pas interroger les identifiants MAC/UDID/IMEI pour une identification NAC.

Sophos limite le User Enrollment fondé sur un profil à iOS/iPadOS 17 ou antérieur ; cela ne signifie pas la suppression générale du User Enrollment account-driven. Lors de la désinscription, le volume APFS administré et le compte Apple administré sont supprimés de l’appareil ; ce n’est pas un retour arrière général du Wi-Fi ou du VPN. Apple décrit le VPN par application comme une fonction possible de User Enrollment, et non comme la preuve qu’une méthode d’affectation des applications fonctionne dans Sophos.

Planifier ensemble le Wi-Fi et la chaîne de certificats

Isoler le pilote BYOD avant chaque modification : pour les stratégies d’utilisateur iOS/iPadOS, Sophos synchronise automatiquement les modifications à chaque nouvelle connexion de l’appareil à Sophos Mobile ; aucune opération manuelle Update devices n’est nécessaire. Utilisez donc une stratégie d’utilisateur distincte, affectée uniquement à l’appareil BYOD de test autorisé, et vérifiez ses affectations actuelles ainsi que le nombre d’appareils cibles avant de la modifier et avant Save. Ne modifiez pas pour le pilote une stratégie déjà partagée avec des appareils BYOD en production. Une affectation ultérieure aux seuls appareils de test sélectionnés ne limite pas la synchronisation des modifications sur les autres appareils auxquels cette même stratégie est déjà affectée. Cette règle de périmètre vaut aussi pour les changements de certificats et les corrections lors du retour arrière ; la synchronisation ne confirme à elle seule ni le fonctionnement du réseau ni la voie de retour MDM.

Qui vérifie qui ? Sur un réseau Wi-Fi d’entreprise avec EAP (authentification entre l’appareil et le réseau), l’appareil vérifie le nom et la chaîne de certificats du serveur RADIUS. Avec une authentification par certificat, RADIUS vérifie en retour l’identité cliente émise. L’autorité de certification du serveur et l’identité cliente remplissent donc des rôles distincts. Le choix d’un Identity certificate dans la configuration Wi-Fi suppose une configuration Client certificate dans la même stratégie ; le certificat du serveur dans Trusted certificates suppose une configuration Root certificate dans cette stratégie.

Exemples fictifs uniquement, à ne pas réutiliser : radius.test.invalid comme nom de serveur, Test-CA comme autorité de certification du serveur jugée fiable et CN=Testperson,OU=Pilot,O=Beispiel comme sujet X.500 (champs de l’identité cliente). Remplacez toutes ces valeurs par les noms, l’autorité de certification et les champs d’identité confirmés par votre équipe PKI/RADIUS. Sur l’appareil de test, vérifiez que l’identité du serveur configurée correspond à la chaîne réelle et que RADIUS accepte le certificat client émis. Le certificat racine est un certificat X.509 au format PEM/DER ; un certificat client importé est au format PKCS#12 (.pfx). Le chargement d’un fichier .pfx ne le rend pas automatiquement réutilisable dans plusieurs stratégies : si vous avez besoin du certificat client dans une autre stratégie, vous devez l’y charger à nouveau. Vérifiez l’origine de l’autorité de certification, la possession de la clé, la validité et l’usage prévu. Charger une autorité de certification racine ne prouve pas qu’elle est reconnue par toutes les applications.

Pour Root certificate dans une stratégie d’appareil iOS, ouvrez la configuration sur Edit policy via Add configuration > Root certificate. Sélectionnez le fichier X.509 au format PEM/DER avec Upload a file, puis ouvrez-le avec Open. Après le chargement, Certificate name affiche le Distinguished Name (DN) de l’émetteur, et non l’identité cliente. Enregistrez la configuration avec Apply, puis la stratégie avec Save sur Edit policy. Selon Sophos, l’affectation de la stratégie installe le certificat racine chargé sur l’appareil. L’affichage et l’enregistrement ne prouvent à eux seuls ni la confiance accordée au certificat, ni sa validité, ni la réussite de son installation. Chaque certificat racine supplémentaire nécessite sa propre configuration Root certificate dans la même stratégie.

Pour Root certificate dans une stratégie d’utilisateur iOS, Sophos décrit l’importation depuis Edit policy, via Add configuration > Root certificate. Sélectionnez le fichier X.509 au format PEM/DER avec Upload a file, puis ouvrez-le avec Open. Après le chargement, Certificate name affiche le Distinguished Name de l’émetteur. Enregistrez la configuration avec Apply, puis la stratégie avec Save sur Edit policy. Ajoutez une configuration Root certificate distincte pour chaque certificat racine supplémentaire. Selon Sophos, l’affectation de la stratégie d’utilisateur installe le certificat sur l’appareil ; il peut servir, dans la même stratégie, de certificat de serveur EAP pour le Wi-Fi, par exemple. Ni l’affichage après chargement ni la stratégie enregistrée ne prouvent la réussite de l’installation, la confiance accordée au certificat ou le fonctionnement de l’authentification Wi-Fi.

Dans la configuration Client certificate de la stratégie d’appareil iOS, sélectionnez d’abord Upload a file sous File, puis le fichier de certificat PKCS#12 (.pfx). Sous Certificate name, Sophos Mobile affiche le nom lu dans le fichier de certificat. Ce nom ne prouve à lui seul ni la confiance accordée au certificat, ni sa validité, ni la réussite de son installation.

Avant de configurer SCEP : si vous utilisez la connexion SCEP configurée dans Sophos setup avec les variables indiquées ci-dessous, vérifiez d’abord le parcours des prérequis SCEP et des certificats : accessibilité de l’autorité de certification depuis Sophos Fusion, règles de pare-feu limitées à la région concernée et, pour ce parcours documenté avec une autorité de certification Windows, compte autorisé à créer les challenges et à demander l’émission des certificats. Avant SCEP, ajoutez le certificat de l’autorité de certification du serveur SCEP comme Root certificate dans la même stratégie. Cette confiance envers le serveur est distincte de celle envers le serveur RADIUS et de l’identité cliente émise ; cela ne fait pas de Windows un prérequis de toute implémentation SCEP directe.

SCEP (Simple Certificate Enrollment Protocol) permet à un appareil de demander un certificat à l’autorité de certification. Il faut pour cela une URL d’autorité de certification accessible ou la variable de proxy SCEP Sophos correctement configurée. Faites valider par l’équipe PKI les champs du sujet X.500 et les SAN/UPN (noms d’identité supplémentaires), le challenge, les paramètres de nouvelle tentative pour les demandes en attente, la longueur de clé et les bits d’usage, en fonction de votre autorité de certification. Pour la configuration SCEP d’une stratégie d’appareil iOS, les décisions suivantes sont importantes :

• Point de terminaison et nom de l’autorité de certification : URL est l’adresse Web du serveur de l’autorité de certification. %_SCEPPROXYURL_% renvoie à l’URL du serveur dans l’onglet SCEP de la page Sophos setup. CA name est un nom reconnu par l’autorité de certification ; il peut, par exemple, servir à distinguer ses différentes instances. Confirmez avec l’équipe PKI le nom attendu par votre autorité de certification. Ce champ n’est ni l’affichage Certificate name d’un certificat importé ni le nom fictif de l’autorité de certification du serveur RADIUS jugée fiable.
• Identité de l’utilisateur ou de l’appareil : Subject peut contenir des paramètres substituables pour les données utilisateur ou les propriétés de l’appareil. Sophos donne CN=%_USERNAME_% pour un utilisateur et CN=%_DEVPROP(SerialNumber)_% pour un iPhone ou un iPad. Ce sont des exemples de syntaxe documentés, non des valeurs vérifiées pour votre tenant. Faites valider l’identité souhaitée par l’équipe PKI ; vérifiez que les données sont disponibles et que le sujet obtenu après substitution est un nom X.500 valide. BYOD : l’existence d’un paramètre substituable documenté pour le numéro de série ne prouve pas qu’une identité fondée sur ce numéro puisse être résolue en User Enrollment ; Sophos ne peut pas y interroger les identifiants de l’appareil. Vérifiez le sujet et l’émission avec une personne participant au test.
• Type et valeur du SAN : choisissez le type validé par l’équipe PKI sous Type of Subject Alternative Name, puis saisissez la valeur correspondante sous Value of Subject Alternative Name. RFC 822 name désigne une adresse e-mail valide. Pour cette configuration SCEP iOS, Sophos décrit DNS name comme le nom DNS du serveur de l’autorité de certification, et Uniform resource identifier comme son URL complète — non comme le nom du serveur RADIUS ou l’adresse du challenge. AD user logon name est distinct et désigne l’UPN défini dans Active Directory. Challenge est l’adresse Web à laquelle l’appareil obtient un mot de passe de challenge auprès du serveur SCEP. %_CACHALLENGE_% renvoie à l’URL de challenge configurée dans l’onglet SCEP de la page Sophos setup, et non au mot de passe lui-même. Ne copiez aucun secret réel dans des exemples publics ou des tickets.
• Demandes en attente : Retries définit le nombre de nouvelles tentatives lorsque le serveur répond pending ; ce n’est pas un compteur général de tentatives pour toutes les erreurs réseau. Retry delay est l’intervalle entre ces tentatives, en secondes. Convenez du nombre et de l’intervalle avec l’équipe PKI ; ne les confondez pas avec le renouvellement des certificats.
• Clés et usage : Key size désigne la taille de la clé publique dans le certificat émis et doit correspondre à celle configurée sur le serveur SCEP. Certificate usage définit l’usage autorisé : Use as digital signature pour les signatures numériques, Use for encryption pour le chiffrement des données. Le choix doit correspondre aux exigences PKI et au service cible ; il ne prouve ni la réussite de l’authentification Wi-Fi/VPN ni le chiffrement de l’ensemble du trafic de l’appareil.

Lors de la création de la stratégie, le champ SCEP renewal interval est disponible. Vérifiez l’intervalle, l’expiration, la révocation et le remplacement avec l’équipe PKI ; définir un intervalle ne garantit ni le renouvellement réussi, ni la récupération d’un appareil resté hors ligne.

Substitution de l’identité dans les stratégies d’appareil et d’utilisateur : dans l’exemple CN=%_USERNAME_% ci-dessus, %_USERNAME_% est remplacé par Exchange Login de l’utilisateur affecté à l’appareil, pas nécessairement par son nom d’affichage ni automatiquement par son UPN Active Directory. Vérifiez l’affectation au bon utilisateur et la valeur de cette propriété avant l’affectation de la stratégie ; le sujet obtenu doit rester un nom X.500 valide et approuvé par l’équipe PKI. AD user logon name reste le champ UPN distinct.

Pour SCEP dans une stratégie d’utilisateur iOS, définissez les points de terminaison séparément. URL est l’adresse Web du serveur de l’autorité de certification. La variable %_SCEPPROXYURL_% renvoie à l’URL du serveur dans l’onglet SCEP de la page Sophos setup. Challenge est l’URL permettant d’obtenir un mot de passe de challenge auprès du serveur SCEP, et non le mot de passe lui-même. %_CACHALLENGE_% renvoie à l’URL de challenge configurée dans ce même onglet SCEP. Comme pour les paramètres de demande décrits plus haut, Retries ne compte que les nouvelles tentatives après une réponse pending ; Retry delay indique leur intervalle en secondes. Key size doit correspondre à la taille de la clé publique configurée sur le serveur SCEP. Confirmez ces paramètres avec l’équipe PKI ; ce ne sont ni des intervalles de renouvellement ni une preuve de réussite de l’émission.

Wi-Fi d’entreprise et adresse Wi-Fi privée

Pour un pilote Wi-Fi d’appareil isolé, le parcours suivant relie les paramètres réseau à l’affectation de la stratégie. Assurez d’abord la voie réseau indépendante et la voie de retour décrites dans la section du pilote ; ne modifiez aucune stratégie affectée en production.

1. Sous Policies, ouvrez la plateforme Apple correspondant à l’appareil cible, créez une stratégie d’appareil avec Create et renseignez son nom, sa description et le nom de l’organisation. Sur Edit policy, ajoutez la configuration Wi-Fi avec Add configuration, puis ouvrez son nom pour la modifier. Pour le Wi-Fi Enterprise, préparez d’abord les certificats clients et racines nécessaires dans la même stratégie, comme indiqué plus haut ; Apply pour les configurations de certificats racines ne remplace pas Save pour la stratégie entière.
2. Sous SSID, saisissez le nom Wi-Fi confirmé par l’équipe réseau et adaptez Security type à la méthode réelle, y compris à sa variante Personal ou Enterprise. Personal nécessite le mot de passe Wi-Fi ; pour Enterprise, utilisez les paramètres EAP, d’authentification et de confiance décrits ci-dessous. Connect automatically établit automatiquement la connexion lorsque le réseau est disponible ; Hidden network désigne un réseau qui ne diffuse pas son SSID. Ne choisissez ces deux options qu’en fonction du réseau prévu, et non comme preuve de sécurité.
3. Vérifiez toutes les configurations et enregistrez la stratégie avec Save sur Edit policy. Pour l’affectation qui suit, utilisez le parcours « Créer et affecter une stratégie » : sélectionnez la stratégie pilote enregistrée, cochez uniquement les appareils de test individuels autorisés et vérifiez la liste ainsi que leur nombre avant Finish. Respectez les réserves de ce parcours concernant la planification et iPadOS. Observez ensuite séparément l’état des tâches et de l’affectation, l’authentification Wi-Fi réelle et la prise de contact MDM selon les critères ci-dessous ; l’enregistrement et l’affectation ne sont pas des résultats de connexion confirmés.

Pour la configuration Wi-Fi d’une stratégie d’appareil iOS, choisissez d’abord Security type en fonction du réseau. Une variante Personal permet de renseigner le mot de passe Wi-Fi. Seule une variante Enterprise propose Protocols, Authentication et Trusted certificates. Sous Accepted EAP types, alignez les méthodes acceptées par l’appareil sur l’authentification réseau avec l’équipe RADIUS. Les certificats clients et racines décrits plus haut restent liés à la même stratégie.

Sous Authentication de la stratégie d’appareil iOS, User est le nom d’utilisateur Wi-Fi et Password le mot de passe Wi-Fi pour l’authentification par identifiants. Selon Sophos, Require password on each connect envoie le mot de passe à chaque authentification ; cette option ne garantit pas une demande interactive de mot de passe. Validez la méthode d’authentification par identifiants et ce choix avec l’équipe RADIUS. Pour une authentification par certificat, choisissez plutôt l’Identity certificate approprié dans une configuration Client certificate de la même stratégie d’appareil. Sur l’appareil de test, vérifiez selon la méthode choisie que RADIUS accepte les identifiants ou le certificat client ; dans les deux cas, l’identité du serveur et la chaîne de confiance restent à vérifier séparément.

Pour TTLS, Internal identity désigne le protocole d’authentification de l’utilisateur à l’intérieur du tunnel. Ce n’est pas l’identité externe. Pour EAP-FAST, il est possible de configurer un Protected Access Credential (PAC) ; ce PAC n’est pas un script de configuration automatique du proxy. Clarifiez avec l’équipe RADIUS le protocole TTLS et, si nécessaire, les données d’authentification EAP-FAST, puis vérifiez l’authentification sur l’appareil cible. Sans cette clarification, écartez la branche EAP concernée du pilote.

Pour EAP, fixez les deux limites TLS ou laissez-les toutes deux non définies. Sophos décrit Outer identity pour TTLS, PEAP et EAP-FAST et exige une identité externe pour TLS 1.3. N’y inscrivez ni nom d’utilisateur ni secret, car cette identité est transmise en clair. Si nécessaire, faites vérifier par l’équipe PKI/RADIUS une identité externe anonyme avec un domaine (realm) adapté au routage. Observez l’authentification négociée et la version TLS sur l’appareil de test ; le choix de ces paramètres ne prouve pas à lui seul que la connexion fonctionne.

Turn off private address fait utiliser à l’appareil son adresse MAC matérielle pour ce Wi-Fi, plutôt qu’une adresse propre au réseau générée par iOS. Cela réduit la confidentialité. N’utilisez cette option que si l’appareil doit impérativement être identifié par la même adresse MAC sur vos différents réseaux. Selon Sophos, Synchronized Security ne fonctionne pas avec les adresses MAC privées : Sophos Fusion Wireless ne connaît que l’adresse privée, et Sophos Mobile uniquement l’adresse matérielle. La désactivation ne garantit toutefois pas à elle seule le fonctionnement de Synchronized Security ; vérifiez la correspondance et le comportement attendu dans le réseau prévu. N’en faites pas un contournement NAC pour le BYOD. Avec User Enrollment, Sophos ne dispose pas de l’adresse MAC pour NAC.

Pour Wi-Fi dans une stratégie d’utilisateur iOS, Sophos distingue également Personal et Enterprise sous Security type. Personal utilise le mot de passe Wi-Fi. Protocols, Authentication et Trusted certificates ne sont disponibles que pour Enterprise. Pour une authentification par identifiants, User est le nom d’utilisateur Wi-Fi et Password le mot de passe Wi-Fi. Selon Sophos, Require password on each connect envoie le mot de passe à chaque authentification. Validez ce choix avec l’équipe RADIUS ; n’y voyez pas la garantie qu’un mot de passe sera demandé à l’utilisateur. Pour une authentification par certificat, choisissez plutôt l’Identity certificate approprié dans une configuration Client certificate de la même stratégie d’utilisateur. Le certificat du serveur sous Trusted certificates nécessite lui aussi une configuration Root certificate dans cette stratégie. N’utilisez le certificat client et son acceptation par RADIUS comme critères de vérification que pour l’authentification par certificat.

Selon la description Wi-Fi, les décisions EAP exposées plus haut s’appliquent aussi à cette stratégie d’utilisateur. Alignez Accepted EAP types sur l’authentification réseau ; pour TTLS, clarifiez le protocole sous Internal identity et, pour EAP-FAST, si nécessaire, le Protected Access Credential (PAC). Ces données d’authentification ne sont pas un script PAC de proxy. Fixez les deux limites TLS ou laissez-les toutes deux non définies. Outer identity est décrit pour TTLS, PEAP et EAP-FAST et est obligatoire pour TLS 1.3. Respectez les précautions relatives à la transmission en clair et au domaine (realm) indiquées plus haut. N’en déduisez ni la disponibilité de toutes les options dans votre tenant ni la réussite de l’authentification ; l’exclusion d’un proxy Wi-Fi administré et les réserves MAC/NAC pour User Enrollment restent valables.

Proxy et VPN sont deux interventions distinctes

• Proxy Wi-Fi : configurable manuellement ou au moyen de PAC (fichier de règles de proxy) dans la stratégie d’appareil iOS. Avec Apple User Enrollment, la configuration Wi-Fi ne prend en charge aucun proxy. Sophos indique comme solution de repli possible WPAD (découverte automatique d’un proxy) au point d’accès et le choix, par l’utilisateur, de la configuration automatique du proxy HTTP dans les réglages Wi-Fi : il ne s’agit pas d’une configuration de proxy BYOD administrée à distance. Testez séparément PAC/WPAD, le DNS et l’accessibilité.
• Proxy HTTP global : Sophos n’autorise cette configuration d’appareil iOS que sur les appareils supervisés ; configuration manuelle avec serveur, port et, le cas échéant, identifiants, ou automatique avec une URL PAC. En mode manuel, Server est le nom ou l’adresse IP du proxy HTTP et Port son numéro de port. Authentication est le nom d’utilisateur pour la connexion au serveur proxy, et Password le mot de passe associé. Elle ne constitue ni une promesse de fonctionnement sur BYOD ni une garantie de continuité en cas de panne.
• VPN couvrant tout l’appareil : la stratégie d’appareil iOS prévoit le type de connexion, le serveur et l’authentification ; avec Custom SSL/TLS, l’application du fournisseur doit être installée. Ne transposez pas cette configuration à Apple User Enrollment : Apple n’y autorise pas le VPN classique couvrant tout l’appareil.
• VPN par application : configuration distincte pour les applications choisies, à ne pas confondre avec un VPN d’appareil. Vérifiez séparément l’application du fournisseur avec Custom SSL/TLS, le serveur, l’authentification, les éventuels certificats et proxy, la connexion à la demande et les règles de domaine pour Safari et les autres navigateurs, Calendrier, Contacts et Mail. Vérifiez également la portée réelle de Send all traffic through VPN ; ne déduisez pas de son nom une isolation universelle des applications ni un effet sur tout l’appareil. La documentation Sophos est ici incohérente : la description de User Policy inclut le VPN par application, mais celle de l’affectation des applications ne mentionne que les Device Policies comme prérequis et choix possibles. N’affirmez donc pas qu’une procédure d’affectation BYOD fonctionne : démontrez-le d’abord dans le tenant actuel avec une application et un appareil de test.

VPN d’appareil : fournisseur, authentification et chemin du trafic

Les indications suivantes concernent la configuration VPN d’une stratégie d’appareil iOS, et non la configuration VPN par application ou Apple User Enrollment. Vérifiez la disponibilité et la prise en charge du fournisseur dans votre tenant. Connection name est le nom de la connexion affiché sur l’appareil. Sous Server, saisissez le nom d’hôte ou l’adresse IP du serveur VPN ; confirmez le point de terminaison approprié avec le responsable VPN.

• Sous Connection type, choisissez le fournisseur ou le type de connexion approprié. Pour une application de fournisseur VPN disponible dans l’App Store, Sophos décrit Custom SSL/TLS. L’application doit être installée ; saisissez son identifiant au format DNS inversé sous Identifier (reverse DNS format). Si le fournisseur impose ses propres paramètres de connexion, renseignez les clés et valeurs confirmées sous Third-party settings comme propriétés de connexion. Ne réutilisez pas les clés ou valeurs de configurations d’autres fournisseurs.
• User authentication concerne l’authentification de l’utilisateur. Account est le compte utilisateur de la connexion VPN ; Group peut préciser le groupe d’authentification nécessaire. Avec Password, indiquez le mot de passe VPN ; avec Certificate, le certificat d’authentification VPN. Clarifiez avec le responsable VPN si un groupe est nécessaire et quelle identité doit être utilisée. Ces identifiants ne sont pas ceux du proxy.
• Device authentication est distinct. Avec Keys (Shared Secret)/Group name, indiquez le groupe requis sous Group name et la clé partagée sous Keys (Shared Secret). Sophos mentionne Use hybrid authentication et Request password, mais cette page indique seulement de les sélectionner selon les besoins. Leur effet et le choix nécessaire ne sont pas clarifiés ici ; n’intégrez ces deux options au pilote qu’après confirmation par le fournisseur. Avec Certificate, sélectionnez le certificat d’authentification de l’appareil requis. Selon Sophos, Including user PIN inclut facultativement le code PIN de l’utilisateur dans l’authentification de l’appareil. Ne transposez aucune de ces branches à tous les fournisseurs sans vérification et ne consignez aucune clé ou aucun code PIN réel dans les tickets.
• Send all traffic through VPN est le paramètre qui envoie tout le trafic par cette connexion VPN. Sophos indique que l’ensemble du trafic est envoyé par le VPN. Vérifiez le chemin réel du trafic sur l’appareil de test avec le fournisseur et le mode de tunnel choisis, et contrôlez séparément le canal de retour MDM. Ce n’est pas une preuve de prise en charge exhaustive du trafic ou d’isolation des applications.
• Sous Proxy, définissez le proxy de cette connexion VPN. No proxy signifie sans proxy de connexion. Avec Manually, saisissez l’adresse et le port du proxy sous Server and port ; Authentication est le nom d’utilisateur du proxy et Password son mot de passe. Avec Automatic, indiquez sous Proxy server URL l’URL du serveur contenant les paramètres de proxy. Ce choix n’est ni le proxy Wi-Fi ni la configuration de proxy HTTP global ; n’en déduisez aucune exigence de supervision ni aucune garantie de continuité en cas de panne.
• Provider type distingue la couche de transport, et non le fournisseur choisi sous Connection type. App proxy transporte le trafic dans le tunnel VPN à la couche applicative ; Packet tunnel, à la couche réseau. App proxy n’est donc pas synonyme de VPN par application. Vérifiez sur l’appareil cible quel choix le fournisseur prend en charge et quel trafic il achemine réellement.

VPN par application : paramètres et démarrage de la connexion

Pour Per app VPN dans une stratégie d’appareil iOS, Sophos décrit les paramètres et comportements suivants ; leur effet reste à vérifier dans le pilote. Ces indications ne résolvent pas la contradiction citée plus haut concernant l’affectation des applications dans une User Policy.

Pour Per app VPN, aussi bien dans les stratégies d’appareil iOS que dans les stratégies d’utilisateur iOS, Connection name est le nom de la connexion affiché sur l’appareil. Il s’agit du libellé visible de la connexion, et non de l’identifiant DNS inversé de l’application du fournisseur, de l’adresse du serveur ou du compte utilisateur.

• Application du fournisseur : si le fournisseur VPN propose dans l’App Store une application qui établit la connexion VPN, choisissez Custom SSL/TLS. Cette application VPN doit être installée sur l’appareil ; saisissez sous Identifier (reverse DNS format) son identifiant au format DNS inversé, et non celui de l’application métier dont le trafic doit emprunter le tunnel.
• Authentification VPN : Server est le nom d’hôte ou l’adresse IP du serveur VPN ; Account, le compte utilisateur servant à authentifier la connexion. Sous User authentication, choisissez Password ou Certificate, puis indiquez le mot de passe VPN sous Password ou le certificat d’authentification VPN sous Certificate. Ces paramètres sont distincts des identifiants du proxy de connexion.
• Démarrage de la connexion : si Connect automatically on demand est activé, l’appareil active le VPN lorsque l’application établit une connexion réseau, selon Sophos. Si cette option est désactivée, les utilisateurs doivent activer eux-mêmes le VPN. Vérifiez les deux comportements sur l’appareil de test prévu.
• Proxy de connexion : Proxy propose No proxy, Manually et Automatic. Pour une configuration manuelle, indiquez l’adresse valide et le port du proxy sous Server and port, le nom d’utilisateur du proxy sous Authentication, et son mot de passe sous Password. Pour une configuration automatique, saisissez sous Proxy server URL l’URL du serveur contenant les paramètres de proxy. Il s’agit du proxy de cette connexion VPN, et non de la configuration de proxy HTTP global.

La même syntaxe s’applique à Domains in Safari, Domains in Calendar, Domains in Contacts et Domains in Mail : un domaine, une partie de domaine ou un nom d’hôte par ligne. Une partie de domaine correspond lorsque tous les composants séparés par des points concordent en partant de la droite ; les points en début et en fin sont ignorés. Une chaîne sans point ne correspond qu’à l’hôte portant ce nom, et non à tous les domaines ayant cette terminaison. La règle supplémentaire relative au domaine de deuxième niveau pour Calendrier, Contacts et Mail reste applicable ; la section consacrée au pilote décrit le test positif approprié.

VPN par application dans la stratégie d’utilisateur et affectation de l’application

La description Sophos de Per app VPN dans une stratégie d’utilisateur iOS documente également les paramètres expliqués plus haut pour l’application VPN du fournisseur installée et son identifiant DNS inversé, l’authentification avec Password ou Certificate, le démarrage à la demande, le proxy de connexion et la syntaxe des domaines. Ces points communs documentés ne prouvent pas qu’une méthode d’affectation fonctionne avec Apple User Enrollment.

Sophos documente les champs conditionnels suivants pour Per app VPN, aussi bien dans les stratégies d’appareil iOS que dans les stratégies d’utilisateur iOS. Les conditions s’appliquent aux deux types de stratégies ; vérifiez la disponibilité et la prise en charge du fournisseur dans votre tenant :

• Third-party settings permet de saisir les propriétés de connexion définies par le fournisseur VPN. Ce champ n’est disponible que pour Custom SSL/TLS. Utilisez Add pour saisir les valeurs confirmées de Key et Value. Ces propriétés de connexion ne sont pas la Managed configuration de l’application métier dont le trafic doit emprunter le tunnel.
• Group désigne le groupe requis pour l’authentification. Ce champ n’est disponible que pour Cisco AnyConnect et Cisco Legacy AnyConnect. Ne transposez pas cette condition aux autres types de connexion.
• Sous Provider type, App proxy transporte le trafic dans le tunnel VPN à la couche applicative ; Packet tunnel, à la couche réseau. Ce paramètre n’est pas disponible pour Cisco AnyConnect. Vérifiez sur l’appareil de test prévu quel choix le fournisseur prend en charge et quel trafic il achemine réellement. La couche de transport ne prouve à elle seule ni l’isolation des applications ni un effet VPN sur tout l’appareil.

L’affectation d’une connexion existante à l’application métier relève du processus de distribution des applications, dans la section « Vérifier la configuration gérée et le comportement de l’application ». L’affectation du VPN par application y est expressément limitée aux stratégies d’appareil existantes. Les responsables des stratégies fournissent la connexion appropriée ; les responsables des applications la sélectionnent sous VPN connection used by the app. Ce renvoi ne résout pas l’incertitude décrite plus haut pour les stratégies d’utilisateur et n’autorise pas une méthode d’affectation BYOD non vérifiée.

Vérifier avant, observer pendant le pilote, cerner les incidents

1. Inventaire et voie de retour : relevez le propriétaire, le mode d’inscription, la supervision, la version d’iOS/iPadOS, la stratégie concernée et son affectation. Pour un appareil d’entreprise supervisé et un appareil BYOD volontaire, consignez pour chacun une voie réseau indépendante (par exemple réseau mobile ou autre Wi-Fi) et une personne à contacter. Sans cette voie, ne déployez aucune modification susceptible de bloquer l’accès. Pour modifier une stratégie d’appareil iOS, utilisez une stratégie de test affectée uniquement à l’appareil pilote d’entreprise ; avant toute mise à jour, vérifiez ses affectations actuelles et le nombre d’appareils concernés. Ne modifiez pas une stratégie déjà affectée en production pour mener le pilote.
2. Dépendances : testez l’accessibilité du DNS, d’APNs/MDM, de l’autorité de certification/SCEP/RA, du serveur RADIUS/EAP, de PAC/WPAD et du point de terminaison VPN avant et après la modification. Vérifiez la chaîne de certificats, les noms des serveurs, l’expiration et le remplacement prévu ; ne copiez pas les clés privées, challenges ou identifiants dans les tickets. Une affectation de stratégie valide ne prouve pas à elle seule que le Wi-Fi ou le VPN fonctionne.
3. Pilote ciblé : commencez avec des appareils de test distincts et une affectation minimale. Consignez les éléments suivants comme critères de vérification, non comme résultats confirmés : l’appareil accepte l’identité vérifiée du serveur RADIUS et se connecte au Wi-Fi d’entreprise. Pour une authentification par certificat, vérifiez également la réception du certificat client et son acceptation par RADIUS ; pour une authentification par nom d’utilisateur et mot de passe, vérifiez la méthode d’authentification par identifiants prévue. Pour le VPN par application, vérifiez le trafic dans le tunnel de l’application de test administrée et affectée ; n’utilisez l’accès d’autres applications comme test négatif que si elles ne sont soumises ni à une autre affectation VPN ni à une règle de domaine configurée. Si des domaines sont définis pour Safari ou d’autres navigateurs, Calendrier, Contacts ou Mail, vérifiez aussi les accès prévus aux domaines correspondants et ne supposez pas systématiquement que « les autres accès ne passent pas par le tunnel ». Vérifiez séparément les domaines Safari/navigateurs : pour qu’un test positif avec Calendrier, Contacts ou Mail soit valable selon Sophos, le domaine de deuxième niveau du domaine renseigné doit aussi correspondre à celui du serveur VPN. Un domaine différent ne constitue pas un test positif valable du tunnel ; son absence de passage par le tunnel ne prouve pas à elle seule l’échec du déploiement VPN. Vérifiez les règles de domaine dans votre tenant plutôt que d’en déduire une procédure de configuration non testée. Testez séparément sur l’appareil l’effet de Send all traffic through VPN avec le fournisseur et le mode de tunnel choisis ; n’en concluez pas, sans vérification, qu’il agit sur tout l’appareil ou isole les applications. Pour le VPN par application d’une User Policy, démontrez que l’affectation de l’application est effectivement disponible, ou écartez provisoirement cette fonction. Pour PAC/WPAD, observez le comportement prévu en cas de panne du Web ou du proxy ; après chaque modification, confirmez séparément une nouvelle prise de contact MDM et le fonctionnement réel du réseau. Si cette prise de contact n’a pas lieu ou si la voie réseau indépendante manque, arrêtez le pilote et n’affectez aucun autre appareil.
4. Cerner l’incident : en l’absence de Wi-Fi, vérifiez d’abord le SSID et le type de sécurité, le nom du serveur EAP et l’autorité de certification fiable ; pour une authentification par identifiants, vérifiez le nom d’utilisateur, le mot de passe et la méthode d’authentification RADIUS prévue ; pour une authentification par certificat, vérifiez l’identité cliente émise et l’accessibilité de l’autorité de certification ; si le Web ne fonctionne pas, vérifiez PAC/WPAD/DNS et l’accès au proxy ; si une application ne fonctionne pas, vérifiez l’application du fournisseur, le tunnel, le certificat et l’affectation. Observez séparément la tâche et la prise de contact MDM, d’une part, et la connexion réelle, d’autre part. Ne provoquez pas une seconde panne en supprimant sans contrôle des certificats ou des profils.

Revenir en arrière sans réinitialiser l’appareil

Avant le pilote, préparez une stratégie de remplacement et une chaîne de confiance de remplacement fonctionnelles, avec un réseau accessible. Ne supprimez l’ancienne autorité de certification et les certificats d’identité qu’après avoir confirmé le remplacement sur l’appareil cible et une prise de contact MDM.

D’après Sophos, les changements apportés aux stratégies d’appareil iOS nécessitent Update devices : cette opération crée une tâche de mise à jour pour tous les appareils auxquels la stratégie modifiée est affectée, et non pour le seul appareil pilote. Ne mettez donc à jour que la stratégie pilote isolée, après vérification de ses affectations actuelles ; une tâche Assign policy ciblant certains appareils n’équivaut pas à la mise à jour d’une stratégie affectée à plusieurs appareils. La tâche ciblée Uninstall policy est prévue pour Device Enrollment, mais elle peut elle-même supprimer la voie réseau. Pour les stratégies d’utilisateur iOS sur les appareils en User Enrollment, cette tâche Uninstall policy n’existe pas : Sophos propose à la place la tâche ciblée Unassign iOS user policy. Selon le cas de panne, mettre à jour la stratégie ou en affecter une autre peut également être pertinent. Ne confondez pas cette tâche ciblée avec Unassign pour tous les appareils.

iPadOS : distinguer les actions directes des types de tâches. Le guide des stratégies explique les différences de désignation entre les parcours directs de mise à jour et de désinstallation : la liste des types mentionne iOS/iPadOS, mais les procédures directes ne citent que iOS device policies. Ne transposez donc pas leurs étapes à iPadOS sans vérification ; clarifiez le parcours direct disponible dans le tenant et sur l’appareil pilote. Cela ne signifie pas que le retrait sur iPadOS serait généralement non documenté ou impossible : les types de tâches iOS/iPadOS documentent Uninstall policy pour Device Enrollment et Unassign iOS user policy pour User Enrollment. Le parcours des bundles de tâches selon le mode de gestion décrit ce choix ; continuez à vérifier séparément le transfert de la tâche et l’effet réel du retrait.

Vérifiez le retour arrière séparément sur un appareil de test d’entreprise encore joignable sous Device Enrollment et sur un appareil BYOD de test encore joignable sous User Enrollment : sur l’appareil d’entreprise, essayez la tâche Uninstall policy ciblée pour ce seul appareil ; sur l’appareil BYOD, essayez la tâche Unassign iOS user policy ciblée. Pour chacun, confirmez l’état de la tâche et de la prise de contact MDM ainsi que l’état de la stratégie réellement synchronisée ; testez ensuite à nouveau et séparément le Wi-Fi/VPN et le contact MDM. Limitez les autres affectations ou retraits aux seuls appareils de test effectivement vérifiés, tant que les deux voies de retour ne sont pas démontrées. Une tâche enregistrée ou envoyée n’atteint pas automatiquement un appareil bloqué hors ligne. Il faut alors utiliser la voie réseau indépendante et la solution de dépannage sur place prévues auparavant ; appliquer Unassign à tous les appareils n’est pas une mesure d’urgence à faible risque. Ni l’effacement complet (Wipe) ni la désinscription de l’utilisateur ne sont des méthodes générales de retour arrière d’une stratégie.