Configurer Android Enterprise dans Sophos Mobile et inscrire les appareils en sécurité

Réponse courte : Pour inscrire des appareils en MDM, l’organisation a besoin d’une licence Sophos Mobile Device Management ou Sophos Mobile adaptée, d’une inscription Android Enterprise liée à Sophos Mobile et d’un package de stratégies et de tâches correspondant au type d’appareil prévu. Sophos Mobile Threat Defense seul ne donne pas droit à la gestion MDM décrite ici. En mode Full Device, Sophos Mobile peut gérer l’ensemble de l’appareil ; en mode Android Enterprise work profile sur un appareil confirmé comme personnel (BYOD) décrit ici, il ne gère que le profil professionnel. La propriété de l’entreprise ne prouve pas qu’un appareil est en mode Full Device, et une stratégie Work Profile ne transforme pas un appareil d’entreprise en appareil entièrement géré. Avant toute inscription, établir la propriété, le mode effectif, les données présentes, l’identité Google et la procédure de sortie autorisée. Ce guide ne constitue pas une autorisation de migration de flotte ni de réinitialisation.

Pour choisir l’édition et vérifier le décompte avant le pilote, consulter les licences Sophos Mobile ; les droits effectifs du tenant doivent néanmoins être vérifiés.

Vérification préalable : quel parcours cet appareil peut-il suivre ?

Appareil d’entreprise neuf ou réinitialisé — gestion complète autorisée. Utiliser Android Enterprise full device avec une Android Enterprise device policy. L’inscription en Full Device n’est possible qu’avant la première configuration ou après une réinitialisation d’usine ; la désinscription ultérieure exige également une réinitialisation d’usine. Ne pas effacer les données existantes sans sauvegarde vérifiée.

En Full Device, aucun compte Google personnel n’est nécessaire pour l’inscription. Par défaut, seules les applications approuvées dans Managed Google Play sont disponibles ; la configuration de Google Play peut autoriser l’accès à toutes les applications du Play Store. Au départ, seul un ensemble minimal d’applications est activé : Google Play Store, Contacts, Messages et Phone. L’absence d’applications préinstallées ne signifie donc pas que l’inscription a échoué. Les applications gérées peuvent être installées, supprimées ou mises à jour sans intervention de l’utilisateur ; les autorisations d’exécution et les configurations d’application prises en charge sont pilotées par la stratégie appropriée. Vérifier les applications effectivement présentes et les autorisations nécessaires pendant le pilote.

Appareil personnel — données professionnelles uniquement. Utiliser Android Enterprise work profile avec une Android Enterprise work profile policy. Ce n’est pas une gestion complète de l’appareil : ne pas présenter un Full-Device-Wipe comme procédure de sortie. La suppression du profil professionnel efface les applications et données de ce profil ; les données privées situées hors du profil ne relèvent pas de ce mode de gestion.

Le guide Android BYOD traite du consentement, de la configuration et de la suppression sur les appareils personnels ; il ne s’applique pas aux appareils d’entreprise dotés d’un profil professionnel.

Appareil d’entreprise avec profil professionnel souhaité ou classification incertaine — arrêt. Le parcours Work Profile décrit ici concerne le BYOD, et non un parcours de provisionnement propre aux profils professionnels sur appareils d’entreprise, avec d’autres conséquences pour la réinitialisation et la sortie de gestion. Ne pas classer l’appareil en Full Device ou en BYOD à partir de sa seule propriété ou du nom de la stratégie. Vérifier d’abord séparément le mode de l’appareil et de l’OEM, ainsi que l’inscription prise en charge pour ce tenant, et obtenir une autorisation. Les appareils d’entreprise dotés d’un profil professionnel (COPE) sont exclus des indications BYOD ci-dessous concernant la suppression du profil, la récupération et la sortie de gestion.

Appareil déjà géré en mode Device administrator — planifier la migration séparément. Ne pas simplement lancer une nouvelle inscription Enterprise par-dessus la gestion existante. Ce mode obsolète n’est disponible que sur Android 9 ou une version antérieure et n’est pas autorisé à partir d’Android 10. Examiner l’appareil existant et sa sauvegarde, puis établir un plan de migration distinct à l’aide du guide de migration Device Administrator. Il traite séparément la désinscription de l’ancien mode et la réinitialisation des appareils d’entreprise ; ce renvoi n’autorise pas une réinitialisation et ne remplace pas une suppression de la gestion confirmée sur l’appareil.

Appareil d’entreprise sans utilisateur ou en mode kiosque — parcours de provisionnement distinct. L’inscription comme appareil Android Enterprise entièrement géré est possible par QR ou Zero-touch. Pour les organisations inscrites en mode managed Google domain avant le 9 avril 2024, il faut d’abord activer Use managed Google domain device enrollment ; ne pas engager ce parcours sans cette option. Un package QR sans utilisateur contient Assign policy pour une Android Enterprise device policy, mais aucune tâche Enroll. Ne pas attribuer d’adresse e-mail lors de l’inscription. La configuration kiosque et son provisionnement constituent un processus distinct, et non le package utilisateur standard. Un Dedicated device résulte d’une configuration Kiosk mode sur un appareil entièrement géré et se limite à une application ou à une sélection d’applications.

L’inscription QR sans utilisateur se trouve sous Setup > Google setup > QR code enrollment (user-less). Pour Zero-touch, User authentication, dans l’onglet Zero-touch, détermine si l’inscription se fait avec ou sans utilisateur. Bien qu’aucune adresse e-mail ne soit liée et qu’aucun utilisateur Sophos Mobile ne soit attribué, Google crée un compte en interne. Sous Internal properties, son identifiant s’appelle android.enterprise.bte.userless-device.account-id pour managed Google domain et afw_play_emm_managed_device_account_user_id pour Managed Google Play Account. Cet identifiant ne prouve pas une attribution à un utilisateur personnel ; un utilisateur peut être attribué séparément par la suite si nécessaire. L’attribution chez le fournisseur, la création du QR et la configuration physique doivent être clarifiées dans le processus de provisionnement propre à l’organisation avant la mise en service. Pour cette préparation, utiliser le guide des appareils Android dédiés : il distingue QR, Zero-touch et KME et décrit le pilote QR autorisé. La correspondance encore non résolue entre le profil Sophos KME et l’interface Samsung actuelle impose un arrêt avant toute création exécutable de profil KME ; ni ce renvoi ni une réussite QR ne confirment KME, une réinitialisation ou une sortie physique du mode kiosque.

Prérequis KME : rapprocher l’inventaire des appareils entre le client et le revendeur

Avec Knox Mobile Enrollment (KME), la préparation commence avant l’attribution du profil : l’administration informatique du client et le revendeur doivent faire référence à la même organisation et aux mêmes appareils achetés. Les explications suivantes portent sur cette transmission préalable, et non sur la création d’un profil KME dans l’interface Samsung actuelle.

Échanger et vérifier les identifiants : L’administration informatique communique au revendeur le Knox Customer ID de l’organisation cliente prévue ; le revendeur communique à l’équipe informatique son Reseller ID. Il doit s’agir d’un revendeur de confiance agréé par Samsung dans le Knox Deployment Program. Avant d’autoriser cette collaboration, vérifier les deux identifiants et les organisations correspondantes : un identifiant client erroné rattacherait la transmission des appareils à l’inventaire d’un autre client. Ces identifiants ne sont ni des identifiants de connexion Google ni la clé de licence Knox décrite séparément.
Charger et partager les appareils achetés : Après l’achat, le revendeur charge la liste des identifiants des appareils achetés dans le Knox Reseller Portal. Ces identifiants sont partagés entre le portail du revendeur et KME et constituent l’inventaire initial des appareils pour la console du client. Ce chargement n’est pas encore une inscription dans Sophos. La vérification comprend le contrôle de l’organisation cliente et le rapprochement des identités des appareils avec la commande, la livraison et l’inventaire interne ; clarifier d’abord avec le revendeur les appareils manquants ou ne correspondant pas au client, au lieu de contourner l’écart par une attribution de profil.
Distinguer la notification de l’approbation du client : L’administration informatique reçoit une notification par e-mail concernant le chargement des appareils et approuve ce chargement côté client. Le message signale le chargement, mais ne remplace pas l’approbation. Avant cette approbation, vérifier à nouveau le Customer ID, le rattachement au revendeur et les identifiants des appareils signalés par rapport à l’inventaire prévu. Seul un inventaire d’appareils correctement rattaché et accepté constitue la base de l’attribution ultérieure des profils ; cela ne signifie pas encore qu’un appareil a été configuré avec succès.

Le chargement automatique et l’approbation automatique sont des décisions distinctes : Auto-upload concerne le chargement automatique des données des appareils ; Auto-approval concerne l’acceptation automatique, côté client, des chargements du revendeur de confiance. Ne pas déduire un paramètre de l’autre. L’attribution automatique des profils est également une décision distincte, et non une conséquence inévitable d’un chargement ou de son approbation. Avanet recommande d’autoriser séparément chaque automatisation prévue pour le revendeur et l’inventaire client désignés, et de vérifier les paramètres réellement en vigueur. Sans confirmation explicite de l’approbation automatique, ne pas considérer l’approbation manuelle du client comme effectuée. Même avec une automatisation autorisée, le rapprochement de l’identifiant client, des identités des appareils et de l’inventaire accepté reste nécessaire avant l’attribution des profils ; en cas d’écart, arrêter et faire intervenir l’administration informatique responsable ainsi que le revendeur. Aucun contrôle actuel ni aucune valeur par défaut de ces paramètres n’est présumé ici.

La transmission KME ne lève aucun arrêt opérationnel : L’inventaire vérifié ne confirme à lui seul ni la correspondance du profil Sophos KME avec l’interface Samsung actuelle ni le mode de gestion sur l’appareil. Le guide de provisionnement lié plus haut et son arrêt avant toute création exécutable de profil KME restent applicables sans modification. L’attribution du profil et la finalisation ultérieure de l’inscription par les utilisateurs des appareils sont des étapes suivantes ; leur résultat doit être vérifié séparément dans Sophos Mobile et sur l’appareil. Ces prérequis n’autorisent ni une réinitialisation, ni une libération par le fournisseur, ni une sortie physique du mode kiosque.

L’onglet Android sous Setup > Google setup comporte le choix Management mode > Android Enterprise > Save ; ce choix détermine aussi les types de stratégies visibles dans l’interface. Sophos Mobile Threat Defense ne donne pas droit à ce choix de mode MDM ; l’hébergement de l’application Intercept X est une tâche distincte. Les onglets Android Enterprise et Samsung Knox license remplissent encore d’autres fonctions : liaison du compte et FRP pour le premier ; licence Samsung Knox Premium facultative pour le conteneur Knox pour le second (types de clés KPE Premium ou KLM Workspace). Une clé de licence Knox n’est ni un prérequis pour tous les appareils Android Enterprise ni une attribution Knox Mobile Enrollment. N’enregistrer une clé que si l’organisation dispose effectivement des droits correspondants, sous Setup > Google setup > Samsung Knox license, puis sélectionner Save ; vérifier les appareils et conteneurs dépendants avant Remove. Remove désenregistre la clé, mais ne supprime pas une attribution chez le fournisseur KME.

Périmètre des paramètres : Host Sophos apps on your web server et Set synchronization interval (Android), dans l’onglet Android, sont des tâches distinctes ; l’hébergement des applications et le réglage de l’intervalle de synchronisation ne sont pas décrits ici. Dans l’onglet Android Enterprise, Configure email placeholder est une autre tâche distincte, à côté de la configuration et de la FRP. La vérification de l’adresse e-mail d’inscription dans cet article ne remplace pas la configuration de cet espace réservé. L’hébergement d’Intercept X dans l’édition Threat Defense ne fait pas non plus partie de cette procédure.

Vérifier la connexion push Android avant le pilote : pour Google Firebase Cloud Messaging (FCM), permettre les connexions sortantes de l’appareil Android vers Google via TCP 5228-5230 ; Sophos indique pour cela tous les blocs IP de l’ASN 15169 de Google. Google indique également TCP 443 pour FCM sur Android. Il ne s’agit pas d’une redirection de port entrante vers l’appareil. En cas de filtrage par IP, récupérer la liste actuelle des plages IP Google au format JSON en direct : prefixes contient les entrées ipv4Prefix et ipv6Prefix ; creationTime et syncToken permettent de documenter la version récupérée. Il s’agit d’une source de données opérationnelles évolutive, pas d’un guide externalisé ni d’une liste d’adresses exclusivement FCM. Google déconseille le filtrage FCM par IP, car ces plages vastes et fréquemment modifiées peuvent facilement devenir incomplètes ou obsolètes. Si ce filtrage est imposé, comparer toutes les plages actuelles aux objets de pare-feu autorisés, intégrer les modifications de manière contrôlée et vérifier la liste au moins une fois par mois, ainsi qu’en cas de problème de livraison ; ne pas utiliser une liste figée tirée de cet article ni uniquement la liste plus restreinte des plages Google Cloud.

Vérifier le chemin réseau réel de l’appareil avec l’administration réseau : réseau Wi-Fi/mobile prévu, VPN éventuel, règle sortante effective et trafic de retour. FCM push exige une connexion directe et ne peut pas être relayé par un proxy réseau ; avec NAT ou Stateful Packet Inspection, prévoir un délai d’expiration d’au moins 30 minutes pour les connexions via 5228-5230. Pendant le pilote autorisé, corréler les journaux du pare-feu ou une capture de paquets ciblée avec l’horodatage de l’appareil, puis vérifier la prise en charge des tâches dans Sophos Mobile et sur l’appareil. Si la connexion est bloquée ou interrompue, examiner d’abord la règle, la route, le VPN/proxy et le délai d’expiration, sans réenregistrer la liaison Google. Cette connexion push, y compris son chemin TCP 443, est distincte de HTTPS 443 vers l’hôte régional Sophos Mobile destiné aux appareils et des autorisations de trafic entrant SCEP ; vérifier chaque chemin nécessaire séparément. Une autorisation réseau, une récupération du JSON ou une liaison de compte réussie ne prouve à elle seule ni l’inscription des appareils ni la prise en charge des tâches.

Lier l’organisation à Google sans créer une seconde inscription

Dans Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, vérifier d’abord le Android Enterprise mode existant et les informations du compte. Si une inscription existe, ne pas créer aveuglément un second compte d’entreprise Google ni remplacer le lien existant. Documenter en interne le compte administrateur responsable, l’accès au domaine et les possibilités de récupération avant toute modification.
Uniquement si l’organisation n’est pas encore liée : ouvrir Configure > Register account. La redirection mène à Google. Saisir une adresse e-mail professionnelle contrôlée par l’organisation dans Create Admin Account, sélectionner Next, puis suivre les étapes d’inscription de l’entreprise affichées par Google pour cette identité. Si l’adresse e-mail est inconnue de Google, ouvrir le lien de confirmation reçu ; avec un domaine Google ou une identité Microsoft existants, les étapes peuvent différer. Sur la page des abonnements, sélectionner Android Enterprise ; cet abonnement Google est gratuit, mais d’autres abonnements Google peuvent être payants.
De retour dans Sophos Mobile, saisir la même adresse e-mail que celle du compte administrateur Android Enterprise créé, sélectionner Finalize setup et vérifier les informations du compte affichées dans l’onglet Android Enterprise. Une connexion Google réussie ne prouve pas que la gestion des appareils fonctionne.

Après l’inscription d’une adresse e-mail professionnelle auparavant inconnue de Google, Google connecte l’administrateur au nouveau Enterprise Google Account. Ce compte peut aussi être utilisé pour d’autres services Google, comme la Google Admin console à l’adresse admin.google.com. Avanet recommande d’y vérifier l’identité et l’organisation effectivement connectées avant toute autre modification. Il s’agit d’un contrôle prévu, et non d’un test de connexion effectué pour cet article. Un domaine Google ou une identité Microsoft existants peuvent suivre un autre parcours d’inscription ; cela ne justifie pas la création d’un second compte.

Ne pas confondre le lien organisationnel et les jetons temporaires : l’inscription Android Enterprise existante de l’organisation n’est ni le jeton Google à durée limitée servant à inscrire un nouvel appareil ni celui servant à mettre à niveau un appareil déjà inscrit. Une tâche d’inscription d’appareil expirée ou échouée ne justifie pas de relancer Configure/Register account ni de supprimer le lien Google existant. Documenter d’abord la propriété du compte et du domaine, le mode d’inscription et l’état de l’option, l’attribution de l’appareil et de l’utilisateur, ainsi que la tâche ; si le lien est incertain, arrêter et clarifier la situation administrativement au lieu d’utiliser une seconde inscription comme réparation. Les deux délais d’une heure ci-dessous ont des points de départ et d’arrivée différents.

Distinguer le mode d’inscription de l’organisation de celui des appareils : avant le 9 avril 2024, les organisations pouvaient choisir Managed Google Play Account ou managed Google domain comme mode d’inscription ; les nouvelles inscriptions d’organisations ultérieures utilisent managed Google domain. L’option supplémentaire Use managed Google domain device enrollment détermine l’inscription des nouveaux appareils : lorsqu’elle est activée, les utilisateurs s’authentifient auprès de Google plutôt que de Sophos Fusion et doivent disposer au préalable d’un compte Google Workspace/Cloud Identity (éventuellement via un IdP). L’inscription de l’organisation en managed Google domain n’implique pas à elle seule une connexion au domaine Google pour les appareils : sans cette option, Sophos Mobile gère lui-même les comptes Google pour les organisations inscrites après cette date. Pour les organisations inscrites avant cette date en mode managed Google domain, l’attribution des utilisateurs passe par Sophos Fusion ; Sophos Mobile crée le compte Google géré lors de l’inscription via le SSP, mais n’assure pas sa gestion ultérieure. Sans cette option, l’inscription par un administrateur est également limitée pour cette inscription historique : seuls les utilisateurs peuvent inscrire leurs appareils via le Sophos Fusion Self Service Portal. Si l’organisation est inscrite en mode Managed Google Play Account et n’a pas encore été mise à niveau vers managed Google domain, Sophos Mobile gère lui-même les comptes utilisateurs Google. Pour une inscription en mode Managed Google Play Account, il existe une limite technique de 10 appareils Android Enterprise inscrits simultanément par utilisateur ; ce n’est pas une formule de calcul des licences.

Uniquement si l’inscription des nouveaux appareils par le domaine est expressément autorisée : documenter le Android Enterprise mode existant, l’état de l’option et l’attribution des utilisateurs Google/Sophos ; tous les utilisateurs concernés doivent déjà être créés dans le domaine Google géré. Sous Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Managed Google domain device enrollment, sélectionner alors Use managed Google domain device enrollment, puis Save. Vérifier ensuite l’état de l’option et, dans le cadre du pilote, la connexion Google avec l’identité prévue ; l’enregistrement de l’option ne prouve pas que l’inscription d’un appareil réussit. Si l’option est absente, ne pas créer un nouveau lien pour la remplacer : vérifier d’abord le mode d’inscription de l’organisation et n’envisager la mise à niveau distincte vers managed Google domain qu’après autorisation spécifique. Pour les organisations inscrites en managed Google domain avant cette date, cette activation rend également disponibles QR, Zero-touch et Knox Mobile Enrollment ; ces méthodes étaient déjà disponibles avec les autres types d’inscription Android Enterprise. KME avec managed Google domain device enrollment ne prend pas en charge l’ancien mode Device administrator.

Préparer la stratégie, le package et l’identité utilisateur

Les options précises d’une stratégie Full Device sont décrites dans la stratégie Android Enterprise pour appareils d’entreprise ; celle-ci ne dispense pas de choisir le mode d’inscription.

Créer une Android Enterprise device policy pour Full Device, ou une Android Enterprise work profile policy pour Work Profile. Ne pas présenter une stratégie Work Profile comme preuve d’une gestion complète d’un appareil d’entreprise. Pour chaque type d’appareil utilisé, créer un package de tâches distinct comprenant au minimum Enroll et Assign policy pour la stratégie correspondante. Noter le groupe cible et les attributions existantes avant le pilote.
Avant les invitations, vérifier la configuration SSP enregistrée qui s’applique réellement : sous Setup > Self Service Portal, déterminer quelle configuration existante s’applique aux groupes d’utilisateurs prévus : si plusieurs attributions de groupes correspondent, la configuration ayant la priorité la plus élevée l’emporte ; Default ne s’applique que si aucune autre configuration ne correspond. Vérifier la configuration existante si elle convient, sans en créer une nouvelle. Sous Maximum number of devices, il doit rester une place pour l’inscription prévue ; cette limite SSP ne correspond ni au décompte des licences ni à la limite technique de Google. Dans les paramètres de la plateforme Android, vérifier que Owner, le groupe cible Device group et Enrollment package correspondent à la propriété de l’appareil, au mode de gestion autorisé et au package de tâches préparé ; il est possible d’utiliser des packages différents pour les appareils personnels et ceux de l’entreprise. Owner ne prouve pas à lui seul que le mode réel est Full Device. Si la configuration est incertaine ou inadaptée, arrêter et faire intervenir l’administration responsable ; ne pas contourner le problème en utilisant un autre compte ou un autre type d’inscription, ni modifier Default pour un large ensemble d’utilisateurs.
La vérification de la configuration et le pilote selon la procédure d’administration SSP sont obligatoires avant les invitations : si aucune configuration ne convient, en préparer une séparément en suivant cette procédure. Avant tout enregistrement, limiter les changements à un pilote autorisé, de périmètre restreint, avec uniquement les actions nécessaires : Save peut rendre les actions immédiatement accessibles aux groupes déjà attribués, avant même une correction de priorité. Si les paramètres de plateforme ont été modifiés, les appliquer avec Apply, puis enregistrer la configuration avec Save. Pour contrôler le résultat, Avanet recommande de rouvrir la configuration et de vérifier à nouveau les paramètres enregistrés ainsi que la priorité effective des groupes, y compris Default. Avant les invitations ou l’attribution à un large ensemble de groupes, effectuer le test d’inscription décrit dans la procédure d’administration SSP avec des personnes et des appareils de test autorisés, pour chaque groupe concerné et chaque combinaison prévue de propriété et de mode de gestion ; vérifier le résultat sur l’appareil et dans Sophos Mobile. La présence d’une option dans le portail ne suffit pas.
Autoriser l’application Sophos Mobile Control dans Managed Google Play, faute de quoi elle ne se mettra pas à jour automatiquement. Uniquement après ces vérifications et l’accord de l’IT, orienter les utilisateurs vers leur portail ou l’e-mail d’invitation envoyé par l’organisation, ainsi que vers le guide SSP destiné aux utilisateurs : ils installent et configurent Mobile Control selon les instructions précises qui y sont affichées. Ces étapes SSP générales ne remplacent pas une décision concernant le mode de gestion ou la réinitialisation.
Avec Use managed Google domain device enrollment, créer au préalable tous les utilisateurs concernés dans le domaine Google géré, clarifier avec eux leurs identifiants Google et vérifier l’attribution des appareils. Pour une tâche lancée par Sophos Mobile, l’adresse e-mail attribuée à l’appareil doit correspondre exactement à celle utilisée pour son inscription auprès de Google. L’utilisation de l’identité d’une autre personne ou la modification de l’adresse e-mail préremplie entraîne un échec. Sophos Mobile Control 9.8 ou version ultérieure est requis ; pour Work Profile, installer également toutes les mises à jour disponibles du système d’exploitation et des applications. Pour une nouvelle inscription d’appareil par le domaine, l’utilisateur doit terminer l’inscription sur l’appareil dans l’heure qui suit son début ; démarrer la procédure ou utiliser le jeton dans ce délai ne suffit pas. Preparing enrollment peut rester affiché plusieurs minutes sans progression visible : laisser l’application ouverte et ne pas éteindre l’appareil. Si cette étape échoue malgré tout, ne pas relancer aveuglément les tâches. Les solutions de récupération possibles sont la suppression manuelle du profil professionnel ou une réinitialisation d’usine de l’appareil. Ne pas choisir librement entre ces interventions : vérifier d’abord la propriété, le mode effectif et l’état de l’appareil ; uniquement pour un appareil identifié comme personnel, en mode Sophos BYOD Work Profile confirmé, examiner la suppression du profil comme solution de récupération et établir ses conséquences sur les données professionnelles ; pour un mode Full Device confirmé, établir les conséquences d’une réinitialisation d’usine sur toutes les données de l’appareil. Pour les appareils d’entreprise dotés d’un profil professionnel ou lorsque la propriété ou le mode est incertain, arrêter, puis vérifier séparément le parcours de récupération pris en charge par Sophos et l’OEM et obtenir une autorisation. Avant toute intervention, documenter la propriété, une sauvegarde vérifiée et la possibilité de restauration, l’utilisateur concerné et l’autorisation explicite ; avant une réinitialisation, vérifier en plus la configuration FRP et l’accès aux comptes Google prévus, ainsi qu’une nouvelle attribution QR/Zero-touch/KME et le parcours de provisionnement. Si les identifiants sont inconnus, ne pas réinitialiser. Ne relancer l’inscription qu’après confirmation de l’état de l’appareil ; ni un ancien jeton d’appareil ni une nouvelle inscription de l’organisation ne remplacent cette vérification préalable.

Pilote administrateur : sous Devices > Add > Add device wizard, rechercher la personne concernée via User > Search for user, puis la sélectionner sur User selection ; définir Android sous Device details > Platform, puis choisir le package Android Enterprise préparé sous Enrollment type. Le fait que l’appareil devienne fully managed ou work profile dépend de la stratégie attribuée au package ; le seul choix d’Android ne le détermine pas. Pour un tenant historique managed Google domain sans inscription des appareils par le domaine activée, emprunter plutôt le parcours SSP autorisé. Pour les appareils sans utilisateur, employer exclusivement la procédure QR/Zero-touch expressément configurée à cet effet selon le guide de provisionnement distinct.

Avant toute modification d’un lien Google existant, s’arrêter et vérifier

La mise à niveau de l’inscription de l’organisation de Managed Google Play Account vers managed Google domain est une intervention différente de l’activation de Use managed Google domain device enrollment pour les nouvelles inscriptions, et différente aussi de la mise à niveau d’un appareil déjà inscrit. Le changement à l’échelle de l’organisation rattache la gestion au domaine professionnel et à la Google Admin console plutôt qu’à un compte Gmail individuel. Clarifier auparavant la propriété du domaine, la gestion des identités, les comptes existants et l’autorisation ; ne pas prétendre qu’un retour en arrière est simple.

Clarifier le domaine et les coordonnées avant la confirmation

Vérifier le domaine exact de l’adresse e-mail professionnelle prévue et obtenir son autorisation pour ce changement à l’échelle de l’organisation. Le domaine choisi est définitivement fixé une fois la mise à niveau terminée. Pour un domaine Google géré existant, un accès autorisé avec son compte super-administrateur est nécessaire. Cette connexion authentifie la liaison ; la propriété reste rattachée au domaine, et non à cette personne en particulier.

Lorsque la mise à niveau réussit, Google supprime les coordonnées du lien précédent, notamment l’adresse Gmail ainsi que les informations du délégué à la protection des données et du représentant dans l’UE. Avanet recommande de sauvegarder les informations nécessaires avant la confirmation, conformément aux règles internes de protection des données et d’accès, et de désigner la personne responsable de leur gestion ultérieure. Cela concerne les métadonnées de contact du lien, et non une suppression documentée du compte Gmail. Si le domaine est incertain, si les droits de super-administrateur manquent ou si la reprise des coordonnées n’est pas clarifiée, arrêter avant Upgrade.

Poursuivre la mise à niveau Google depuis Sophos Mobile

Après autorisation spécifique, ouvrir la redirection vers Google sous Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Upgrade to managed Google domain. Cet EMM-initiated upgrade démarre depuis la console de gestion existante ; la redirection Sophos est le point d’entrée dans la transaction Google réelle, pas une seconde inscription initiale ni une connexion Google générale. Y suivre la configuration du compte administrateur pour le domaine Google géré et choisir le parcours approprié :

Si un domaine Google géré existe déjà, se connecter avec son compte super-administrateur. Vérifier à nouveau le domaine autorisé et sélectionner Upgrade. Si des utilisateurs sont déjà synchronisés, Google peut également proposer Authenticate using Google pendant la liaison. Faire autoriser séparément les effets de cette authentification Google par l’administration des identités ; ne pas l’activer si ses effets ne sont pas clarifiés. Cette étape Google conditionnelle n’est pas l’option Sophos Use managed Google domain device enrollment.
Si aucun domaine Google géré n’existe encore, le créer avec l’adresse e-mail professionnelle autorisée et configurer le compte administrateur. Confirmer l’adresse e-mail via le message de Google. La vérification complète du domaine est facultative dans cette procédure. Avant la confirmation, vérifier à nouveau le domaine et sélectionner Upgrade. Il s’agit de poursuivre le lien existant de l’organisation, et non d’effectuer une seconde inscription initiale via Configure > Register account.

Revenir ensuite dans Sophos Mobile, actualiser la page et vérifier Android Enterprise mode = Managed Google domain. Description doit afficher le compte administrateur utilisé pour l’inscription ; corriger si nécessaire. Ces contrôles doivent être effectués sur le tenant cible et n’ont pas déjà été réalisés pour cet article. Si l’affichage diffère, arrêter et clarifier le lien avec l’administration responsable.

Après une mise à niveau réussie, la gestion de l’entreprise s’effectue dans la Google Admin console du domaine désormais lié ; la gestion des applications reste dans Sophos Mobile en tant qu’EMM. Mettre à jour les coordonnées nécessaires dans la Google Admin console de ce domaine et vérifier les entrées. Leur nouvelle saisie restaure uniquement les métadonnées de contact et n’annule pas le changement de lien. Les étapes de configuration supplémentaires 3 à 6 recommandées par Google dans le guide de configuration EMM constituent une tâche d’administration Google distincte, et non un prérequis supplémentaire de licence ou de système d’exploitation pour cette mise à niveau.

Planifier séparément l’inscription des nouveaux appareils et la mise à niveau des appareils individuels

Ce n’est qu’ensuite qu’il faut évaluer l’inscription des nouveaux appareils par le domaine et la mise à niveau distincte des appareils existants. La mise à niveau réussie de l’organisation ne prouve pas qu’un appareil existant a changé de mode d’inscription.

Lors de l’activation du nouveau mode d’inscription des appareils, tous les utilisateurs doivent déjà exister dans le domaine Google ; pour les domaines inscrits avant la date charnière, les noms d’utilisateur existants doivent être conservés, faute de quoi Sophos Mobile ne pourra pas faire le rapprochement. Il s’agit de la partie du nom avant le @, et pas nécessairement du même domaine : le compte Fusion fictif anna@firma.example devient, dans le domaine Google géré google.firma.example, le compte anna@google.firma.example. Remplacer les noms et domaines par ceux du tenant ; pour une inscription d’appareil lancée par Sophos Mobile, l’exigence de correspondance exacte de l’adresse e-mail avec la connexion Google s’applique toujours en plus. Lors de l’ancienne inscription SSP, Sophos Mobile combine le nom d’utilisateur Fusion avec le domaine Google géré, recherche ce compte et ne le crée que s’il n’existe pas encore. La suppression d’un utilisateur Mobile ne supprime pas son compte du domaine Google. La gestion ultérieure des comptes s’effectue dans la Google Admin console ; la connexion d’un annuaire via Google Cloud Directory Sync (GCDS) est une tâche de gestion des identités distincte.

La mise à niveau d’un appareil individuel est irréversible. Uniquement pour un pilote autorisé, après vérification de l’attribution de l’utilisateur (y compris pour les appareils auparavant inscrits sans utilisateur), d’une adresse e-mail du domaine Google géré, des identifiants Google, de l’activation de l’inscription des appareils par le domaine et de Mobile Control 9.8+ : utiliser Devices > [Gerät] > Show device > Actions > Upgrade to managed Google domain enrollment ; l’utilisateur doit confirmer la notification sur l’appareil et se connecter à Google. L’utilisateur doit commencer la mise à niveau sur l’appareil dans l’heure suivant le déclenchement de l’action dans Sophos Mobile ; passé ce délai, le jeton Google de mise à niveau n’est plus valable. Ce délai concerne le début de la mise à niveau, et non la fin de l’inscription d’un nouvel appareil décrite plus haut. En cas d’expiration, ne pas supposer que le jeton reste valide ; vérifier l’état et l’attribution de l’utilisateur avant toute nouvelle action autorisée séparément, sans changer le lien ni relancer aveuglément l’opération. Une sauvegarde préalable et une solution de remplacement sont indispensables ; cette action n’est pas une migration de Device administrator vers Android Enterprise et ne constitue pas une solution générale de retour arrière après un échec d’inscription. L’action n’est pas disponible pour les appareils qui utilisent déjà managed Google domain enrollment ; son absence ne justifie donc pas de réinscrire l’organisation.

Vérifier le résultat et sortir de gestion en sécurité

Pendant le pilote, confronter au journal l’identité de l’appareil, sa propriété, le mode de gestion effectivement affiché, l’attribution au bon utilisateur, les tâches achevées et la stratégie appliquée ; confirmer aussi sur l’appareil que seules les applications et données gérées sont concernées dans le cas d’un appareil personnel BYOD confirmé avec Work Profile, ou que l’appareil d’entreprise est correctement configuré. La création d’une tâche ou d’un compte Google ne prouve pas que l’inscription est effective. En cas de dépassement du délai, d’adresse e-mail incorrecte ou de stratégie non appliquée, arrêter avant toute nouvelle tâche, conserver l’état de l’appareil et des tâches, puis diagnostiquer l’erreur précisément.

Ne pas réduire la sortie de gestion à une annulation de l’inscription : la désinscription d’un appareil Android Enterprise entièrement géré nécessite une réinitialisation d’usine ; avant de l’autoriser, clarifier séparément la propriété, la sauvegarde restaurable de toutes les données concernées, la procédure de réinitialisation, la Factory Reset Protection (FRP), la validité des comptes Google configurés à cet effet et la disponibilité de leurs identifiants, ainsi que le reprovisionnement. Si ces identifiants sont inconnus ou invalides, arrêter : après un effacement, l’appareil peut devenir inutilisable. Le QR exige un scan lors de la configuration de l’appareil ; pour Zero-touch/KME, clarifier l’attribution active chez le fournisseur et les modalités de restitution ou de réutilisation avant la réinitialisation, dans le cadre du processus de provisionnement distinct. Même la suppression de l’entrée d’un appareil Full Device encore géré peut déclencher une réinitialisation d’usine automatique ; ne pas s’en servir comme nettoyage sans risque. Uniquement pour un appareil confirmé comme personnel (BYOD) dont le mode Sophos Work Profile est effectivement confirmé, examiner après autorisation Devices > [Arbeitsprofilgerät] > Actions > Wipe Android work profile : cette action efface les applications et les données du profil professionnel, mais pas automatiquement l’ensemble de l’appareil personnel. Ne déclencher l’action avec Yes dans la boîte de confirmation qu’après vérification de la concordance entre l’appareil, le mode, la sauvegarde et l’autorisation. Avec une inscription Managed Google Play Account, un compte Google peut rester sur l’appareil après la désinscription et continuer à compter dans la limite des appareils inscrits simultanément ; dans ce cas, supprimer manuellement uniquement le compte géré identifié sans ambiguïté, pas le compte Google personnel de l’utilisateur, avant de considérer la place comme libérée. Ne nettoyer l’inventaire et les attributions qu’après confirmation de l’état de l’appareil ; la disparition d’une entrée de la console ne prouve pas une désinscription réussie. La fonction Unenroll de l’ancien mode Device administrator ne remplace pas l’effacement d’un appareil Full Device.

Pour vérifier les comptes FRP, la synchronisation des appareils et les procédures de réinitialisation avant autorisation, consulter Préparer et vérifier la récupération FRP Android ; ce n’est pas une autorisation générale de réinitialiser.

Périmètre de ce guide : l’inscription QR, Zero-touch et Knox Mobile Enrollment, y compris la réinitialisation et la libération par le fournisseur, la récupération des comptes FRP, la migration depuis Device administrator, la suppression détaillée en contexte BYOD et le déploiement des applications et stratégies sont des tâches distinctes. Aucun appareil, tenant, changement de jeton, réinitialisation ou désinscription n’a été mis en œuvre pour cet article ; les combinaisons OS/OEM prises en charge, la licence effective et les rôles Google/Sophos réels doivent être vérifiés sur le système cible.