Sophos Mobile : gérer la connectivité macOS par stratégie d’appareil ou d’utilisateur

Cet article traite des stratégies Sophos Mobile sur les Mac gérés, et non de la configuration générale du Wi-Fi ou du VPN d’Apple, de Sophos Endpoint, de ZTNA ou d’un pare-feu Sophos. Pour l’installation du client et l’accès distant par pare-feu plutôt que par stratégie Mobile, voir Sophos Connect sur macOS. Les contextes appareil et utilisateur sont distincts : des configurations portant le même nom n’impliquent pas que l’identité, l’accès aux certificats et le moment de leur application soient interchangeables. L’attribution d’un profil ne prouve pas, à elle seule, que la connexion fonctionne.

Prérequis : sécuriser d’abord l’accès de gestion et le retour arrière

• Licence MDM requise : La gestion des Mac nécessite Sophos Mobile Device Management, sous forme de licence autonome ou inclus dans la licence groupée Sophos Mobile. Sophos Mobile Threat Defense seul ne suffit pas : cette licence couvre la gestion de Sophos Intercept X for Mobile et de Sophos Chrome Security, pas la gestion MDM des Mac. Vérifier dans le tenant le droit d’utilisation MDM correspondant avant de créer les stratégies.
• Vérifier que le Mac est inscrit dans Sophos Mobile, relever sa version de macOS et les stratégies déjà attribuées, puis déterminer si la fonction requise doit être gérée pour un appareil ou pour un utilisateur précis. Les Mac n’ont qu’un seul mode de gestion dans Sophos Mobile, mais disposent de stratégies d’appareil, déclaratives et d’utilisateur. L’User Enrollment d’Apple pour les iPhone et iPad personnels n’est pas un mode d’inscription macOS. En cas d’inscription manuelle d’un Mac, l’utilisateur à gérer doit effectuer l’inscription et saisir un mot de passe administrateur pour le profil d’inscription ; en cas d’inscription automatique via Apple Business, vérifier sous Assign user to device si No (aucune association à un utilisateur lors de l’inscription) ou Yes - LDAPS authentication est sélectionné. Ne pas déduire l’association à un utilisateur de la stratégie d’appareil.
• Les stratégies d’appareil s’appliquent à tous les utilisateurs du Mac. Les stratégies d’utilisateur s’appliquent à l’utilisateur qui effectue l’inscription locale ainsi qu’aux utilisateurs réseau connus de Sophos Mobile via l’annuaire LDAP externe du Self Service Portal. Si une stratégie d’appareil joint un Mac au même domaine AD que le Self Service Portal, la stratégie d’utilisateur s’applique à tous les utilisateurs AD qui ouvrent une session sur ce Mac. Vérifier ce comportement avec les comptes prévus avant toute attribution étendue.
• Outre la stratégie d’appareil liée à l’inscription, on peut attribuer à un Mac une autre stratégie d’appareil, une stratégie déclarative et une stratégie d’utilisateur. Avant toute modification d’une charge utile, inventorier les Mac cibles, les utilisateurs et groupes concernés ainsi que toutes les attributions de la stratégie existante : ne jamais modifier pour le pilote une stratégie déjà attribuée hors du pilote. Documenter les charges utiles Wi-Fi, VPN, proxy et certificats existantes ainsi que leurs responsables ; les paramètres contradictoires sont généralement résolus en faveur de la valeur la plus restrictive, sauf priorité particulière des configurations déclaratives de mise à jour logicielle et d’applications. Ne pas superposer des profils existants au moyen d’attributions supplémentaires non maîtrisées.
• Contrôle préalable uniquement pour macOS 26 avec une stratégie d’utilisateur : si l’état indique Failed to apply the policy, examiner l’historique des configurations Restrictions précédemment attribuées : la clé obsolète Allow Time Machine peut subsister dans une ancienne stratégie attribuée même si elle n’est plus visible dans les options de configuration. Ne pas exiger de retrouver cette clé dans l’interface actuelle. Si cette cause historique est suspectée, arrêter le pilote et l’évaluation des charges utiles Wi-Fi/VPN/certificats de cette stratégie d’utilisateur : selon Sophos, c’est alors la stratégie d’utilisateur entière qui peut ne pas être appliquée, et non la seule restriction. Convenir d’un nettoyage contrôlé et d’un nouveau contrôle avec les responsables des stratégies de sécurité et de confidentialité macOS ; ne pas modifier silencieusement une stratégie de production partagée. Il ne s’agit pas d’un défaut général de tous les Mac sous macOS 26 ni des stratégies d’appareil.
• Prévoir un accès indépendant au Mac pilote (par exemple, un autre réseau fonctionnel et un accès administrateur local). Vérifier au préalable avec les exploitants concernés le SSID, les points de terminaison RADIUS/VPN, le DNS, la chaîne de confiance PKI, l’expiration des certificats, l’accessibilité du PAC/proxy et, le cas échéant, l’application VPN tierce. Ne pas placer de mots de passe d’accès ni de fichiers .pfx dans les tickets ou les espaces publics. Vérifier dans le tenant les validations de produit, de licence et de système d’exploitation propres à l’environnement ; les pages de configuration ne garantissent pas une prise en charge universelle de chaque version de macOS.

Choix : quelle stratégie et quelles dépendances ?

Pour un Global HTTP proxy configuré manuellement avec des identifiants, saisir le nom d’utilisateur du proxy dans Authentication et le mot de passe du proxy correspondant dans Password. Authentication est ici un champ de nom d’utilisateur, et non un choix de méthode d’authentification. Vérifier avec l’exploitant du proxy si des identifiants sont nécessaires ; ne pas placer les mots de passe dans les tickets ou les espaces publics.

Wi-Fi : définir le réseau et l’authentification

Les descriptions de champs suivantes reprennent les paramètres documentés par Sophos, sans attester la réussite d’une connexion testée sur le Mac. Connect automatically connecte automatiquement le Mac lorsque le réseau Wi-Fi est disponible. Hidden network désigne un réseau qui ne diffuse pas son SSID. Le choix doit correspondre au réseau cible ; un SSID masqué ne constitue pas une validation de sécurité.

Security type définit le mécanisme de sécurité et la variante Personal ou Enterprise. Convenir des deux avec l’exploitant du réseau Wi-Fi. Pour Personal, saisir le mot de passe Wi-Fi dans Password. Pour Enterprise, Protocols permet de définir les protocoles d’authentification et Authentication, l’authentification du client :

• Sous Protocols > Accepted EAP types, définir les types EAP que le Mac accepte pour l’authentification, en fonction du service RADIUS. Pour EAP-FAST, il est possible de configurer une Protected Access Credential (PAC). Cette PAC n’est pas un fichier de configuration automatique de proxy. Avec TTLS, Internal identity sélectionne le protocole d’authentification de l’utilisateur à l’intérieur du tunnel, et non le nom d’utilisateur.
• Si le mécanisme Enterprise choisi utilise un nom d’utilisateur et un mot de passe, saisir le nom d’utilisateur Wi-Fi sous Authentication > User et le mot de passe Wi-Fi sous Password. L’attribution de la stratégie à un utilisateur ne remplace pas ces informations. Selon Sophos, Require password on each connect signifie que le mot de passe est envoyé à chaque authentification. Ne pas en déduire une demande de saisie du mot de passe, un mode de stockage particulier ou une transmission du mot de passe en clair. Ne pas ajouter systématiquement un mot de passe aux mécanismes reposant sur des certificats.

Outer identity est une identité de substitution avec laquelle EAP démarre l’authentification sans divulguer les véritables identifiants de l’utilisateur. Elle est transmise en clair. Ne pas utiliser le nom d’utilisateur réel ni des informations sensibles. Si le service RADIUS nécessite un routage fondé sur un realm, l’identité de substitution doit contenir le realm convenu avec l’exploitant. Sans ce routage, une identité simple comme anonymous peut suffire. Les conditions relatives à EAP et à TLS 1.3 mentionnées ci-dessous restent applicables.

Important pour le Wi-Fi d’entreprise : pour Identity certificate, Sophos Mobile exige au préalable une configuration Client certificate dans la même stratégie ; pour Trusted certificates, une configuration Root certificate. La charge utile Wi-Fi possède également son propre champ Proxy pour les réglages manuels ou PAC ; il ne correspond pas à Global HTTP proxy. Le certificat client est accessible aux autres configurations de la même stratégie, pas aux autres stratégies : il faut l’y téléverser à nouveau. Apple indique, au niveau de sa plateforme, qu’une identité SCEP peut être associée à un service dans le même profil de configuration ; son exemple concret de Wi-Fi EAP-TLS utilise toutefois un certificat AD. Cela ne démontre pas que Sophos Mobile propose une identité SCEP dans son champ Wi-Fi Identity certificate ni qu’il fournit l’association correspondante : l’aide Wi-Fi de Sophos indique au contraire la configuration Client certificate comme prérequis. Ne pas faire dépendre une première attribution ou un Wi-Fi de production de SCEP. N’envisager cette variante comme mode d’exploitation qu’après avoir démontré l’association effective dans son propre tenant, sur le Mac pilote géré, ainsi qu’une authentification EAP/RADIUS réussie ; si ni la sélection ni l’association dans le profil déployé ne peuvent être démontrées, arrêter cette voie. Pour EAP-TTLS/PEAP/EAP-FAST, définir Outer identity sans données utilisateur sensibles ; selon Sophos, ce champ est obligatoire avec TLS 1.3. Définir conjointement le minimum et le maximum TLS, ou laisser les deux champs vides.

VPN : convenir du fournisseur, de l’authentification et du proxy

Connection name est le nom de connexion que l’utilisateur voit sur le Mac, et non le nom de la stratégie. La liste des champs Sophos indique les options Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point et Custom SSL/TLS sous Connection type. Custom SSL/TLS est prévu pour les fournisseurs dont l’app disponible dans l’App Store assure la connexion VPN. Cette liste ne constitue pas une validation de chaque combinaison de fournisseur et de version de macOS. L’app nécessaire doit déjà être installée ; vérifier son identifiant DNS inversé réel avec le fournisseur.

N’utiliser les options suivantes que dans la mesure où le type de connexion et le fournisseur choisis les proposent et les nécessitent. Si le fournisseur impose des propriétés de connexion spécifiques, saisir pour chacune Key et Value sous Third-party settings avec Add. Ne pas reprendre les propriétés d’un autre VPN. Group désigne un groupe éventuellement nécessaire à l’authentification VPN, et non un groupe d’appareils pour l’attribution de la stratégie.

Définir séparément l’authentification de l’utilisateur et celle de l’appareil avec l’exploitant du VPN :

• Sous User authentication, choisir entre Password et Certificate. Le champ Password correspondant contient le mot de passe VPN, et Certificate, le certificat d’authentification de l’utilisateur VPN.
• Avec Device authentication = Keys (Shared Secret)/Group name, les champs Group name, Keys (Shared Secret), Use hybrid authentication et Request password apparaissent. Saisir les informations d’authentification fournies par l’exploitant dans Group name et Keys (Shared Secret). Ne sélectionner Use hybrid authentication et Request password qu’en fonction de ses exigences, et non comme solution systématique à un problème de connexion.
• Avec Device authentication = Certificate, les champs Certificate et Including user PIN apparaissent. Sélectionner le certificat d’appareil nécessaire dans la liste Certificate. Including user PIN inclut le code PIN de l’utilisateur dans l’authentification de l’appareil. La source ne précise ni le moment de la demande de saisie ni le stockage du code PIN.

Protéger les mots de passe VPN et les secrets partagés comme les autres identifiants d’accès. Les champs de certificat ne démontrent toujours aucune procédure d’association SCEP ; vérifier l’identité et l’authentification effectives dans le contexte utilisateur ou appareil prévu.

Sous le Proxy propre au VPN, No proxy signifie qu’aucun proxy n’est configuré pour cette connexion. Avec Manually, les champs Server and port, Authentication et Password apparaissent. Y saisir l’adresse et le port du proxy ainsi que, si nécessaire, le nom d’utilisateur et le mot de passe du proxy. Authentication est ici aussi le champ de nom d’utilisateur. Avec Automatic, Proxy server URL apparaît pour saisir l’URL du serveur contenant les paramètres de proxy. Il s’agit d’un paramètre de cette connexion VPN, et non d’une modification de Global HTTP proxy.

Provider type distingue App proxy, un tunnel VPN au niveau applicatif, de Packet tunnel, un tunnel VPN au niveau réseau. Convenir de l’option appropriée avec le fournisseur. Ne pas en déduire un tunnel fractionné ou complet ; la planification du trafic et la vérification du DNS et des routes lors du pilote restent nécessaires.

SCEP : vérifier les points de terminaison, l’identité et les clés

URL contient l’adresse web du serveur de l’AC. %_SCEPPROXYURL_% renvoie à l’URL du serveur dans l’onglet SCEP de la page Sophos setup. Challenge est l’adresse web 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 dans le même onglet. CA name doit être un nom compris par l’AC ; il peut, par exemple, distinguer différentes instances d’AC. Convenir de la valeur appropriée avec la PKI, sans supposer un nom universel ni une obligation de renseigner ce champ.

Pour ajouter un Subject Alternative Name, choisir d’abord le type sous Type of Subject Alternative Name, puis saisir la valeur sous Value of Subject Alternative Name. Sophos décrit RFC 822 name comme une adresse e-mail valide, DNS name comme le nom DNS du serveur de l’AC et Uniform resource identifier comme l’URL pleinement qualifiée du serveur de l’AC. Ne pas remplacer tacitement ces descriptions relatives au serveur de l’AC par des suppositions générales sur les SAN. Clarifier le type et la valeur avec la PKI en fonction de l’usage prévu du certificat ; ils ne prouvent aucune association d’identité au Wi-Fi ou au VPN. Si une identité d’utilisateur AD est utilisée, AD user logon name désigne le User logon name enregistré dans AD, c’est-à-dire le User Principal Name (UPN). Le SAN et les informations AD ne sont pas des prérequis systématiques pour chaque certificat Mac.

Retries définit le nombre de nouvelles tentatives lorsque le serveur SCEP répond pending. Retry delay est l’intervalle, en secondes, entre ces tentatives. Il ne s’agit ni d’un intervalle de renouvellement ni d’une garantie que la délivrance aboutira après ce délai d’attente. Key size désigne la taille de la clé publique dans le certificat délivré et doit correspondre à la taille configurée sur le serveur SCEP. La configuration SCEP comporte elle aussi Allow export from keychain. Cette option permet aux utilisateurs d’exporter la clé privée du certificat depuis le trousseau. Comme pour le certificat client téléversé, ne l’activer que pour un besoin expressément approuvé.

SCEP et clés : Après substitution des variables, la valeur du sujet doit être un nom X.500 valide : CN=%_USERNAME_% désigne un utilisateur, CN=%_DEVPROP(SerialNumber)_% un Mac. Ne pas déduire du choix d’une stratégie d’utilisateur qu’une identité d’appareil adéquate sera disponible. Vérifier la confiance envers l’AC, la durée de validité des certificats, l’exportation des clés ainsi que la date d’expiration et la procédure de réémission avant la première dépendance. Un certificat racine ne remplace pas un certificat client. Ajouter une configuration Root certificate distincte pour chaque racine supplémentaire.

Autres charges utiles d’appareil : AirPrint ajoute l’adresse IP de l’imprimante et son Resource path (par exemple ipp/print) à la liste AirPrint. Directory service joint le Mac à un domaine AD lors de l’attribution de la stratégie ; le compte de jonction doit être autorisé à ajouter des ordinateurs et l’OU doit être correcte. Attention : modifier les correspondances UID, User-GID ou Group-GID peut empêcher les utilisateurs d’accéder aux fichiers créés auparavant. Ne pas modifier ces correspondances pour tester le réseau ; planifier séparément la jonction à AD et son annulation avec les responsables AD/Mac.

Directory service : définir les comptes, le dossier de départ et les droits

Sous General settings, convenir des paramètres de jonction à AD avec les responsables AD :

• Domain host name contient le nom d’hôte DNS du domaine AD auquel le Mac doit être joint. Ne pas y saisir l’adresse d’un serveur DNS ni le contrôleur de domaine défini séparément sous Preferred DC server.
• AD administrator name et Password contiennent le nom et le mot de passe du compte utilisé pour se connecter au serveur AD. Ce compte de jonction doit être autorisé à ajouter des appareils à la base de données AD. Ne pas placer le mot de passe dans les tickets ou les espaces publics.
• Organizational unit définit l’unité d’organisation (OU) dans AD où sera ajouté l’ordinateur qui rejoint le domaine. Convenir de la valeur d’OU approuvée avec les responsables AD ; ce champ ne définit ni l’association aux utilisateurs ou aux groupes, ni le dossier de départ.

Avant la jonction à AD, décider avec les responsables AD/Mac s’il faut un dossier de départ local avec un compte mobile ou un dossier de départ exclusivement réseau. Si Create mobile account est sélectionné, macOS crée le compte lors de la première ouverture de session avec une connexion au serveur AD ; les identifiants AD permettent ensuite d’ouvrir une session même sans connexion à ce serveur. Avec Require confirmation before creating a mobile account, l’utilisateur décide si le compte mobile est créé : sa création n’est donc pas garantie. Force local home folder est nécessaire pour les comptes mobiles : le profil utilisateur réside sur le volume de démarrage. Si cette option est désactivée, les dossiers de départ sont exclusivement réseau. Ne pas activer systématiquement les comptes mobiles pour tous les Mac. Avec Use UNC path from Active Directory, macOS monte le dossier de départ renseigné dans le compte utilisateur AD ; convenir avec les responsables du protocole de montage approprié sous Network protocol et vérifier l’accès lors du pilote.

Default user shell définit le shell de ligne de commande de l’utilisateur. Si le champ reste vide, Sophos indique que /bin/bash est utilisé. Il s’agit d’une valeur par défaut documentée pour ce champ, et non de la reprise d’une valeur par défaut macOS indéterminée ; convenir du shell souhaité avec les responsables Mac.

Sous Mapping, les attributs AD sont associés aux identifiants macOS suivants :

• UID attribute associe un attribut AD à l’identifiant unique de l’utilisateur dans macOS.
• User GID attribute associe un attribut AD à l’identifiant du groupe principal d’un compte utilisateur macOS.
• Group GID attribute associe un attribut AD à l’identifiant de groupe d’un compte de groupe macOS. Cette correspondance n’accorde pas de droits d’administrateur local ; ces droits relèvent de Domain administrator groups.

Avant l’attribution, comparer les correspondances existantes et approuvées avec les responsables AD/Mac. Ne supposer ni un attribut AD universel ni qu’un champ vide est sans risque pour ces correspondances. Le risque décrit plus haut pour l’accès aux fichiers existants demeure en cas de modifications ultérieures.

Sous Administrative, faire approuver les décisions suivantes avant l’attribution :

• Preferred DC server définit le contrôleur de domaine AD que macOS contacte en premier. Si le champ reste vide, macOS choisit le contrôleur selon les informations de sites AD et la réactivité des contrôleurs. Convenir de ce choix avec l’équipe AD ; renseigner ce champ ne signifie pas que le Mac est lié exclusivement à ce contrôleur.
• Restrict DDNS limite les interfaces réseau pour lesquelles macOS utilise le DNS dynamique. Par défaut, macOS utilise DDNS pour toutes les interfaces réseau. Pour limiter ce périmètre, saisir les noms BSD des interfaces prévues et appuyer sur Enter après chaque entrée. Sophos cite en0 comme exemple de port Ethernet intégré ; ne pas en déduire qu’il s’agit de l’interface appropriée sur tous les Mac. Identifier les interfaces réelles du Mac pilote et convenir des enregistrements DNS souhaités avec l’équipe AD/DNS. Ce paramètre limite DDNS ; il ne désactive ni une interface ni un tunnel VPN.
• Rotation du mot de passe du compte ordinateur : Password trust interval in days concerne le compte ordinateur AD, pas le mot de passe utilisateur. Un champ vide entraîne un changement automatique tous les 14 jours ; 0 empêche les changements automatiques. Convenir de l’intervalle avec l’équipe d’exploitation AD ; ne pas utiliser 0 comme solution rapide à un problème de connexion.
• Protection LDAP : Packet signing / Packet encryption partagent une description commune : Allow laisse macOS décider de signer et/ou de chiffrer les connexions LDAP ; Disable désactive les deux protections ; Require impose toujours la signature et le chiffrement ; SSL/TLS utilise toujours LDAP sur SSL/TLS. Ne pas en déduire que chaque valeur est disponible dans les deux champs : vérifier les choix réellement proposés dans le tenant et définir la protection requise avec l’équipe AD. Ne pas réduire la protection pour réussir une connexion.
• Périmètre de connexion : Multi-domain authentication permet aux utilisateurs de tous les domaines de la forêt AD d’ouvrir une session. Cela élargit le périmètre de connexion et ne correspond pas à l’application de la stratégie d’utilisateur du Self Service Portal décrite plus haut. Avec Namespace = Forest, des utilisateurs de domaines différents peuvent porter le même nom ; ils se connectent sous la forme DOMAIN\name. Avec Domain, la prise en charge des espaces de noms est désactivée et les noms de connexion doivent être uniques. Consigner au préalable les domaines et comptes autorisés ; le choix des noms ne remplace pas l’approbation du périmètre de connexion.
• Droits d’administrateur local : les membres des groupes AD renseignés sous Domain administrator groups reçoivent des droits d’administrateur sur le Mac. Ces droits sont distincts de ceux du compte de jonction permettant d’ajouter un ordinateur. Ne saisir que des groupes approuvés sous la forme DOMAIN\group, en respectant la casse. Consigner pour le pilote quels comptes doivent rester des utilisateurs standard et lesquels doivent recevoir des droits d’administrateur local.

Attribuer la stratégie au pilote et vérifier son effet

1. Délimiter d’abord le pilote : vérifier l’inventaire nominatif des Mac et utilisateurs concernés, l’appartenance aux groupes, les types de stratégies et attributions existants, ainsi qu’un accès de secours fonctionnel. Pour une stratégie existante, relever tous les appareils et groupes auxquels elle est attribuée ; si elle est également attribuée hors du pilote ou si sa portée est incertaine, ne pas la modifier. Avant de remplacer une stratégie macOS d’appareil ou d’utilisateur existante, comparer toutes ses charges utiles et dépendances et préparer un retour arrière avec une stratégie de même type pour ces seuls appareils cibles. N’utiliser une attribution de groupe que si la composition du groupe et ses futures extensions sont maîtrisées ; sinon, choisir les appareils individuellement.
2. Dans Policies > macOS, utiliser Create pour créer une nouvelle stratégie de test isolée du type approprié ; n’utiliser une copie que comme nouvelle stratégie indépendante, sans attributions reprises. Avant toute modification initiale des charges utiles, vérifier que cette stratégie de test n’est attribuée à aucun appareil ni groupe hors du pilote approuvé. Ne pas modifier la stratégie de production largement attribuée. Définir le nom, la description et le nom de l’organisation ; avec Add configuration > Root certificate, créer d’abord la configuration racine pour le Wi-Fi d’entreprise. Y sélectionner Upload a file, choisir le certificat racine X.509 public préparé, encodé en PEM ou DER, puis cliquer sur Open. Après le téléversement, enregistrer la configuration racine avec Apply. En cas d’authentification par certificat, créer ensuite Client certificate dans la même stratégie. Dans cette configuration Client certificate, sélectionner l’action Upload a file sous File, puis choisir le fichier PKCS #12 (.pfx) préparé. N’activer Allow export from keychain que si l’exportation de la clé privée est expressément nécessaire. Configurer ensuite le Wi-Fi. N’ajouter les configurations VPN/proxy qu’après vérification de leurs dépendances propres. Si nécessaire, configurer SCEP séparément : les instructions générales de Sophos relatives à la création d’une stratégie mentionnent un SCEP renewal interval au niveau de la stratégie lorsqu’on ajoute SCEP, mais les listes des champs SCEP macOS ne comprennent aucun champ de configuration de ce type. Vérifier dans le tenant si l’intervalle au niveau de la stratégie est effectivement disponible pour le type macOS choisi ; clarifier avec la PKI la date d’expiration et la procédure de réémission. Sans preuve spécifique, ne pas traiter SCEP comme source du champ Wi-Fi Identity certificate. Pour terminer, enregistrer la stratégie avec Save sur Edit policy ; consigner le périmètre du pilote, les charges utiles et l’état initial nécessaires au retour arrière.
3. Sélectionner le triangle bleu de la stratégie de test isolée, puis Assign ; sous Select devices, choisir exclusivement les Mac pilotes inventoriés ou le groupe d’appareils préalablement vérifié et limité, puis Finish. Avant de terminer, comparer à nouveau les cibles sélectionnées à l’inventaire ; ensuite, contrôler les attributions effectives et arrêter en cas de groupe cible inattendu. La sélection effectuée à cette étape ne protège pas contre les modifications d’une stratégie déjà largement attribuée. Le parcours macOS ne propose ici aucun planificateur Now/Date pour l’attribution.
4. Sur le Mac pilote, vérifier les profils attribués sous System Settings / System Preferences > Profiles, dans le bon contexte. Une modification de la stratégie d’appareil prend effet à la prochaine synchronisation de l’appareil ; une modification de la stratégie d’utilisateur, à la prochaine ouverture de session de l’utilisateur concerné. La modification d’une stratégie macOS ne nécessite pas l’étape manuelle Update devices propre à iOS. Consigner l’état de l’attribution/des tâches et l’affichage local des profils, sans les considérer comme un test fonctionnel.
5. Vérifier le fonctionnement, pas seulement l’état du profil : avec l’utilisateur prévu, vérifier le SSID Wi-Fi et la connexion et, pour l’EAP d’entreprise, confronter la chaîne de confiance attendue du serveur et l’identité client utilisée aux informations de l’équipe RADIUS/PKI. Établir activement le VPN, puis vérifier le DNS, les routes ainsi que les destinations accessibles et inaccessibles par rapport au plan de tunnel fractionné/complet ; pour le proxy/PAC, tester un accès HTTP(S) réel et le parcours d’authentification. Vérifier les certificats par empreinte, validité et usage dans le trousseau approprié. Tester également un second utilisateur si la portée à tout l’appareil ou à AD est pertinente. N’effectuer un test d’impression AirPrint et de connexion AD que si ces charges utiles sont réellement déployées. Pour Directory service, vérifier la première ouverture de session en ligne avec un compte AD approuvé et l’accès au dossier de départ local ou réseau choisi ; en cas d’utilisation d’UNC, vérifier aussi le montage attendu. Si un compte mobile est prévu, vérifier sa création effective, y compris l’éventuelle confirmation de l’utilisateur, puis ouvrir à nouveau une session sans connexion au serveur AD. Maintenir l’accès local indépendant pendant ces vérifications. Avec l’équipe AD/DNS, vérifier que le contrôleur de domaine réellement contacté et les enregistrements DDNS effectifs correspondent au choix convenu et au périmètre d’interfaces prévu. En cas de contrôleur ou d’enregistrement DNS inattendu, arrêter le déploiement et clarifier la cause avec ces responsables. Contrôler également les droits attendus d’utilisateur standard ou d’administrateur et, lorsque le périmètre de connexion l’exige, vérifier le refus de connexion avec un compte de test autorisé à cet effet, situé hors du périmètre de domaines ou de comptes permis. Avec l’équipe AD, vérifier la protection LDAP convenue sur la connexion réelle et l’intervalle effectif de rotation du mot de passe du compte ordinateur ; vérifier séparément un changement de mot de passe arrivé à échéance ultérieurement, sans le considérer comme validé par la première connexion. En cas d’accès au dossier de départ, de périmètre de connexion, de protection ou de privilèges inattendus, arrêter le déploiement et solliciter les responsables AD/Mac.
6. N’autoriser une autre vague pilote qu’après validation de la connexion, d’une nouvelle ouverture de session et d’une synchronisation de gestion. Prévoir une période de chevauchement pour la rotation des certificats : vérifier d’abord la nouvelle confiance et la nouvelle identité, puis retirer l’ancienne AC ou l’ancienne authentification. Le choix d’une AC d’inspection TLS du pare-feu et les profils réseau Apple généraux n’entrent pas dans cette décision relative aux stratégies macOS de Sophos Mobile.

Retour arrière en cas de perte de connexion ou de mauvaise cible

1. Arrêter le déploiement et relever tous les comptes, appareils, groupes et versions de profils réellement concernés ; à l’aide de l’accès indépendant, comparer le profil actuel à la dernière combinaison fonctionnelle. Avant toute correction, vérifier de nouveau l’ensemble des attributions de la stratégie de test et de la stratégie de restauration. Ne pas supprimer immédiatement la seule connexion ou AC par laquelle Sophos Mobile peut encore joindre le Mac.
2. Sous macOS, ne pas présumer que l’action générique Uninstall policy est disponible : selon l’aide d’administration de Sophos, elle n’est autorisée que pour les stratégies d’appareil Android, de conteneur Knox et d’appareil iOS. Uniquement si la stratégie de test est attribuée de façon vérifiable au seul pilote, corriger ses charges utiles et attendre la synchronisation de l’appareil ou la prochaine ouverture de session de l’utilisateur. Sinon, ne modifier aucune stratégie attribuée hors du pilote : délimiter d’abord sa portée avec les responsables et utiliser l’accès indépendant. À titre d’alternative, attribuer exclusivement aux Mac pilotes concernés une stratégie préparée, fonctionnelle et du même type ; vérifier auparavant ses attributions et ses charges utiles, ne pas modifier une stratégie de production partagée pour revenir en arrière et ne déclencher aucune action globale sur un groupe ni Unassign. Lors du remplacement d’une stratégie précédemment attribuée, vérifier ses dépendances et le contexte utilisateur/appareil effectif. Retirer localement une stratégie d’utilisateur n’est pas une solution durable : elle sera réattribuée à la prochaine ouverture de session. Ne pas supprimer le profil d’inscription pour revenir en arrière : cela désinscrit le Mac et nécessite des droits d’administrateur.
3. Avant de retirer une ancienne AC racine, vérifier tous les certificats Wi-Fi/VPN et SCEP/client qui en dépendent ainsi qu’un autre accès fonctionnel ; si l’association AD ou les correspondances UID ont changé, éviter de compromettre les droits d’accès aux fichiers par un basculement aveugle de profil. Démontrer le rétablissement de la connexion réseau, de l’ouverture de session, de la chaîne de certificats et de la synchronisation Sophos Mobile sur le même Mac pilote. Si le Mac reste inaccessible à la gestion, solliciter l’assistance locale Mac/réseau/PKI avec les valeurs documentées avant/après.

Portée de la validation : Aucune combinaison macOS/tenant n’a été vérifiée ici en laboratoire. Ces indications documentaires conditionnelles ne nécessitent pas de test général du tenant/en laboratoire avant publication. Avant un déploiement en production dans un environnement donné ou toute affirmation de connectivité effective, vérifier sur un Mac pilote autorisé l’édition/la licence, la version de macOS, la portée de la stratégie et l’association Apple Business de l’utilisateur, la synchronisation et l’ouverture de session, la confiance PKI, le Wi-Fi EAP et l’identité client réellement utilisée. Pour utiliser SCEP comme identité Wi-Fi, démontrer dans son propre tenant si l’identité délivrée peut être sélectionnée dans le champ Sophos Identity certificate ou si elle est effectivement associée au profil Wi-Fi déployé par un autre moyen ; vérifier également l’identité/l’empreinte dans le bon trousseau d’appareil ou d’utilisateur, ainsi qu’une authentification EAP/RADIUS réussie avec ce certificat précis sur le Mac pilote géré. La seule délivrance d’un certificat ou installation d’un profil ne suffit pas. Pour utiliser SCEP comme identité VPN, démontrer également la sélection ou l’association dans le profil déployé, le bon contexte de trousseau/utilisateur et une connexion VPN réussie avec le certificat attendu sur le Mac pilote ; l’aide VPN de Sophos décrit des champs de certificat, mais pas de procédure d’association SCEP. L’association SCEP au Wi-Fi/VPN reste non résolue et ne constitue pas une voie opérationnelle sans pilote autorisé concluant. Avant une mise en production, vérifier sur l’appareil l’application/le fournisseur VPN et l’authentification, la rotation des certificats, l’accès indépendant, le remplacement et la restauration des stratégies.