Configurare Android Enterprise in Sophos Mobile e registrare i dispositivi in sicurezza

In breve: Per la registrazione MDM, l’organizzazione necessita di una licenza Sophos Mobile Device Management o Sophos Mobile appropriata, di una registrazione Android Enterprise collegata a Sophos Mobile e di un pacchetto di criteri/attività adatto al tipo di dispositivo previsto. Sophos Mobile Threat Defense da solo non dà diritto alla gestione MDM descritta qui. In modalità Full Device, Sophos Mobile può gestire l’intero dispositivo; con Android Enterprise work profile su un dispositivo di proprietà personale accertata (BYOD), nel caso qui descritto, soltanto il profilo di lavoro. La proprietà aziendale non dimostra che il dispositivo sia Full Device e un criterio Work Profile non rende un dispositivo aziendale completamente gestito. Prima di qualsiasi registrazione, accertare proprietà, modalità effettiva, dati presenti, identità Google e procedura di uscita autorizzata. Questa guida non autorizza la migrazione di una flotta né un ripristino.

Per scegliere l’edizione e verificare il conteggio prima del progetto pilota, consultare Licenze Sophos Mobile; occorre comunque verificare i diritti effettivi nel proprio tenant.

Verifica preliminare: quale percorso è consentito per questo dispositivo?

Dispositivo aziendale nuovo o ripristinato: gestione completa approvata. Usare Android Enterprise full device con Android Enterprise device policy. L’enrollment Full Device è possibile soltanto prima della configurazione iniziale o dopo un ripristino alle impostazioni di fabbrica; anche la successiva rimozione dalla gestione richiede un ripristino alle impostazioni di fabbrica. Non cancellare i dati presenti sul dispositivo con un ripristino senza aver verificato il backup.

Per l’enrollment Full Device non occorre un account Google personale. Per impostazione predefinita sono disponibili soltanto le app approvate in Managed Google Play; la configurazione di Google Play può consentire l’accesso a tutte le app del Play Store. All’inizio è attivo solo un insieme minimo di app: Google Play Store, Contacts, Messages e Phone. Non considerare quindi l’assenza di app preinstallate come prova di un enrollment fallito. Le app gestite possono essere installate, rimosse o aggiornate senza intervento dell’utente; le autorizzazioni in fase di esecuzione e le configurazioni delle app supportate sono controllate dal criterio appropriato. Verificare nel progetto pilota le app effettivamente presenti e le approvazioni necessarie.

Dispositivo personale: soltanto dati di lavoro. Usare Android Enterprise work profile con Android Enterprise work profile policy. Non si tratta di gestione completa del dispositivo: non eseguire un Full-Device-Wipe come presunta procedura di uscita. La rimozione del profilo di lavoro elimina le app e i dati al suo interno; i dati personali esterni al profilo non rientrano in questo percorso di gestione.

La guida Android BYOD tratta consenso, configurazione e rimozione sui dispositivi personali; non si applica ai dispositivi aziendali con profilo di lavoro.

Dispositivo aziendale per il quale si desidera un profilo di lavoro, oppure classificazione incerta: fermarsi. Il percorso Work Profile descritto qui vale per BYOD, non per un percorso di provisioning del profilo di lavoro aziendale con conseguenze diverse per ripristino e dismissione. Non classificare il dispositivo come Full Device o BYOD in base alla sola proprietà o al nome del criterio. Verificare prima, separatamente, la modalità del dispositivo e dell’OEM e l’enrollment supportato per questo tenant, e ottenere la relativa autorizzazione. I dispositivi aziendali con profilo di lavoro (COPE) sono esclusi dalle indicazioni BYOD seguenti sulla rimozione del profilo, sul recupero e sulla dismissione.

Dispositivo già gestito in modalità Device administrator: pianificare la migrazione separatamente. Non avviare semplicemente una nuova registrazione Enterprise sul dispositivo esistente. Questa modalità obsoleta è disponibile soltanto per Android 9 o versioni precedenti e non è consentita con Android 10 o versioni successive. Esaminare il dispositivo esistente e il backup dei dati; predisporre un piano di migrazione distinto seguendo la guida alla migrazione da Device Administrator. La guida tratta separatamente la deregistrazione dalla vecchia modalità e il ripristino dei dispositivi aziendali; questo rimando non autorizza un ripristino e non sostituisce la rimozione della gestione confermata sul dispositivo.

Dispositivo aziendale senza utente o destinato a kiosk: percorso di provisioning dedicato. È possibile configurarlo come dispositivo Android Enterprise completamente gestito tramite QR o Zero-touch. Per le organizzazioni registrate in modalità managed Google domain prima del 9 aprile 2024 è necessario attivare prima Use managed Google domain device enrollment; senza questa opzione non avviare il percorso. Un pacchetto QR senza utente include Assign policy per una Android Enterprise device policy, ma non un’attività Enroll. Non assegnare un indirizzo e-mail durante l’enrollment. La configurazione kiosk/provisioning segue una procedura distinta, non il pacchetto standard per gli utenti. Un Dedicated device si ottiene configurando Kiosk mode su un dispositivo completamente gestito ed è limitato a un’app o a una selezione di app.

Per la registrazione QR senza utente è disponibile Setup > Google setup > QR code enrollment (user-less). Per Zero-touch, User authentication nella scheda Zero-touch determina se la registrazione avviene con o senza utente. Anche se non viene collegata un’e-mail né assegnato un utente Sophos Mobile, Google crea internamente un account. In Internal properties, il suo ID si chiama android.enterprise.bte.userless-device.account-id per managed Google domain e afw_play_emm_managed_device_account_user_id per Managed Google Play Account. Questo ID non dimostra un’associazione a un utente personale; se necessario, un utente può essere assegnato successivamente con un’operazione separata. Prima dell’impiego, chiarire assegnazione presso il provider, creazione del QR e configurazione fisica nel proprio flusso di provisioning. Per questa preparazione utilizzare la guida ai dispositivi Android dedicati: distingue QR, Zero-touch e KME e descrive il progetto pilota QR autorizzato. La corrispondenza ancora irrisolta tra il profilo Sophos KME e l’attuale interfaccia Samsung impone di fermarsi prima della creazione eseguibile di un profilo KME; né questo rimando né un esito QR positivo confermano KME, un ripristino o l’uscita fisica dalla modalità kiosk.

Prerequisito KME: riconciliare l’inventario dei dispositivi tra cliente e rivenditore

Con Knox Mobile Enrollment (KME), la preparazione inizia prima dell’assegnazione del profilo: l’amministrazione IT del cliente e il rivenditore devono fare riferimento alla stessa organizzazione e agli stessi dispositivi acquistati. Quanto segue spiega questo passaggio preliminare, non la creazione di un profilo KME nell’attuale interfaccia Samsung.

Scambiare e verificare gli identificativi: l’amministrazione IT comunica al rivenditore il Knox Customer ID dell’organizzazione cliente prevista; il rivenditore comunica all’IT il proprio Reseller ID. Deve trattarsi di un rivenditore affidabile autorizzato da Samsung nell’ambito del Knox Deployment Program. Prima di autorizzare questa collaborazione, verificare entrambi gli ID e le organizzazioni associate: un ID cliente errato farebbe confluire il passaggio dei dispositivi nell’inventario di un altro cliente. Questi ID non sono credenziali di accesso Google né la chiave di licenza Knox descritta separatamente.
Caricare e condividere i dispositivi acquistati: dopo l’acquisto, il rivenditore carica l’elenco degli ID dei dispositivi acquistati nel Knox Reseller Portal. Questi ID vengono condivisi tra il portale del rivenditore e KME e costituiscono l’inventario iniziale dei dispositivi per la console del cliente. Il caricamento non è ancora una registrazione in Sophos. La verifica comprende il controllo dell’organizzazione cliente corretta e il confronto delle identità dei dispositivi con ordine, consegna e inventario interno; chiarire prima con il rivenditore i dispositivi mancanti o non appartenenti al cliente, senza aggirare la discrepanza assegnando un profilo.
Distinguere la notifica dall’approvazione del cliente: l’amministrazione IT riceve via e-mail una notifica del caricamento dei dispositivi e approva il caricamento dal lato cliente. Il messaggio segnala il caricamento, ma non sostituisce l’approvazione. Prima di approvare, confrontare nuovamente Customer ID, associazione al rivenditore e ID dei dispositivi comunicati con l’inventario previsto. Solo un inventario di dispositivi correttamente associato e accettato costituisce la base per la successiva assegnazione dei profili; ciò non implica ancora che un dispositivo sia stato configurato correttamente.

Il caricamento automatico e l’approvazione automatica sono decisioni diverse: Auto-upload riguarda il caricamento automatico dei dati dei dispositivi; Auto-approval riguarda l’accettazione automatica, da parte del cliente, dei caricamenti del rivenditore affidabile. Non dedurre un’impostazione dall’altra. Anche l’assegnazione automatica dei profili è una decisione separata, non una conseguenza inevitabile di un caricamento o della sua approvazione. Avanet raccomanda di autorizzare separatamente ogni automazione prevista per il rivenditore e l’inventario del cliente identificati e di verificare le impostazioni effettivamente in vigore. Senza una conferma esplicita dell’approvazione automatica, non considerare completata l’approvazione manuale del cliente. Anche con un’automazione autorizzata, resta necessario confrontare ID cliente, identità dei dispositivi e inventario accettato prima di assegnare i profili; in caso di discrepanze, fermarsi e coinvolgere l’amministrazione IT responsabile e il rivenditore. Qui non si presuppongono né i controlli attuali né i valori predefiniti di queste impostazioni.

Il passaggio KME non rimuove alcun blocco operativo: il solo inventario verificato non conferma né la corrispondenza del profilo Sophos KME con l’attuale interfaccia Samsung né la modalità di gestione sul dispositivo. La guida al provisioning collegata sopra e il suo obbligo di fermarsi prima della creazione eseguibile di un profilo KME restano invariati. L’assegnazione del profilo e il successivo completamento della registrazione da parte degli utenti dei dispositivi sono passaggi successivi; il loro risultato deve essere verificato separatamente in Sophos Mobile e sul dispositivo. Questi prerequisiti non autorizzano un ripristino, un rilascio da parte del fornitore o l’uscita fisica dalla modalità kiosk.

La scheda Android in Setup > Google setup contiene la selezione Management mode > Android Enterprise > Save; questa scelta determina anche quali tipi di criteri compaiono nell’interfaccia. Sophos Mobile Threat Defense, invece, non dà diritto a questa selezione della modalità MDM; l’hosting dell’app Intercept X è un’attività separata. Le schede Android Enterprise e Samsung Knox license hanno ancora altre funzioni: collegamento dell’account/FRP e, rispettivamente, licenza Samsung Knox Premium opzionale per il container Knox (tipi di chiave KPE Premium o KLM Workspace). Una chiave di licenza Knox non è né necessaria per ogni dispositivo Android Enterprise né un’assegnazione Knox Mobile Enrollment. Inserire la chiave in Setup > Google setup > Samsung Knox license soltanto se si possiede effettivamente il relativo diritto e scegliere Save; prima di Remove, verificare dispositivi e container dipendenti. Remove deregistra la chiave, non un’assegnazione presso il provider KME.

Ambito delle impostazioni: Host Sophos apps on your web server e Set synchronization interval (Android) nella scheda Android sono attività separate; questo articolo non descrive l’hosting delle app né l’impostazione dell’intervallo di sincronizzazione. Nella scheda Android Enterprise, Configure email placeholder è un’altra attività distinta dalla configurazione iniziale e da FRP. La verifica dell’e-mail usata per la registrazione in questo articolo non sostituisce la configurazione di tale segnaposto. Anche l’hosting di Intercept X nell’edizione Threat Defense non rientra in questa procedura.

Verificare la connessione push Android prima del progetto pilota: per Google Firebase Cloud Messaging (FCM), consentire connessioni in uscita dal dispositivo Android verso Google tramite TCP 5228-5230; Sophos indica a questo scopo tutti i blocchi IP dell’ASN 15169 di Google. Google indica anche TCP 443 per FCM su Android. Non si tratta di un port forwarding in ingresso verso il dispositivo. Se si applica un filtro IP, recuperare l’elenco attuale degli intervalli IP Google come JSON live: prefixes contiene le voci ipv4Prefix e ipv6Prefix; creationTime e syncToken aiutano a documentare la versione recuperata. È una fonte variabile di dati operativi, non una guida esternalizzata né un elenco di indirizzi esclusivo di FCM. Google sconsiglia il filtraggio FCM basato su IP perché gli intervalli ampi e frequentemente modificati possono facilmente diventare incompleti o obsoleti. Se il filtraggio è obbligatorio, confrontare tutti gli intervalli attuali con gli oggetti firewall autorizzati, applicare le modifiche in modo controllato e verificare l’elenco almeno una volta al mese e in caso di problemi di consegna; non usare un elenco congelato tratto da questo articolo né soltanto il più piccolo elenco degli intervalli Google Cloud.

Confrontare il percorso di rete effettivo del dispositivo con l’amministrazione di rete: verificare la rete Wi-Fi/mobile prevista, eventuali VPN, la regola effettiva in uscita e il traffico di ritorno. FCM push richiede una connessione diretta e non può essere inoltrato tramite un proxy di rete; con NAT o Stateful Packet Inspection prevedere un timeout di almeno 30 minuti per le connessioni su 5228-5230. Nel progetto pilota autorizzato, correlare i log del firewall o una cattura mirata dei pacchetti con l’orario del dispositivo, quindi verificare la ricezione delle attività in Sophos Mobile e sul dispositivo. Se la connessione è bloccata o si interrompe, chiarire prima regola, percorso, VPN/proxy e timeout, senza registrare nuovamente il collegamento Google. Questa connessione push, incluso il percorso TCP 443, è distinta da HTTPS 443 verso l’host regionale dei dispositivi Sophos Mobile e dalle autorizzazioni SCEP in ingresso; verificare separatamente ogni percorso necessario. La sola autorizzazione di rete, il recupero del JSON o un collegamento dell’account riuscito non dimostrano né l’enrollment dei dispositivi né la ricezione delle attività.

Collegare l’organizzazione a Google: preservare la continuità, non creare una seconda registrazione

In Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, verificare prima l’Android Enterprise mode esistente e i dettagli dell’account. Se esiste già una registrazione, non creare alla cieca un secondo account Google aziendale né sostituire un collegamento esistente. Documentare internamente l’account amministratore responsabile, l’accesso al dominio e le modalità di recupero prima di apportare modifiche.
Soltanto se l’organizzazione non è ancora collegata: aprire Configure > Register account. Il reindirizzamento porta a Google. Inserire in Create Admin Account un indirizzo e-mail di lavoro controllato dall’organizzazione, scegliere Next e seguire i passaggi mostrati da Google per la registrazione aziendale di tale identità. Se Google non conosce ancora l’indirizzo e-mail, aprire il link di conferma ricevuto; i passaggi possono variare in presenza di un dominio Google o di un’identità Microsoft già esistenti. Nella pagina degli abbonamenti selezionare Android Enterprise; l’abbonamento Google Android Enterprise è gratuito, mentre altri abbonamenti Google possono essere a pagamento.
Tornati in Sophos Mobile, inserire lo stesso indirizzo e-mail dell’account amministratore Android Enterprise creato, scegliere Finalize setup e controllare i dettagli dell’account visualizzati nella scheda Android Enterprise. Non dedurre da un accesso a Google riuscito che la gestione dei dispositivi sia già operativa.

Dopo la registrazione di un indirizzo e-mail di lavoro prima sconosciuto a Google, Google fa accedere l’amministratore al nuovo Enterprise Google Account. Questo account può essere usato anche per altri servizi Google, come la Google Admin console all’indirizzo admin.google.com. Avanet consiglia di verificare lì, prima di ulteriori modifiche, l’identità effettivamente connessa e l’organizzazione. Si tratta di un controllo previsto, non di un test di accesso eseguito per questo articolo. Un dominio Google o un’identità Microsoft già esistenti possono prevedere una procedura di registrazione diversa; ciò non giustifica la creazione di un secondo account.

Non confondere il collegamento con i token temporanei: La registrazione Android Enterprise esistente dell’organizzazione non è il token Google con durata limitata per l’enrollment di un nuovo dispositivo, né quello per l’upgrade di un dispositivo già registrato. Un’attività per un dispositivo scaduta o non riuscita non giustifica un nuovo Configure/Register account né la rimozione del collegamento Google esistente. Documentare prima titolarità dell’account/dominio, modalità e opzioni di registrazione attuali, associazione tra dispositivo e utente e attività interessata; se il collegamento non è chiaro, fermarsi e risolvere il problema a livello amministrativo invece di tentare una seconda registrazione come rimedio. I due termini di un’ora descritti più avanti hanno punti di inizio e di fine diversi.

Distinguere modalità di registrazione dell’organizzazione e modalità di enrollment dei dispositivi: Prima del 9 aprile 2024, le organizzazioni potevano scegliere fra Managed Google Play Account e managed Google domain come modalità di registrazione; le nuove registrazioni successive utilizzano managed Google domain. L’impostazione aggiuntiva Use managed Google domain device enrollment determina come si registrano i nuovi dispositivi: quando è attiva, gli utenti si autenticano con Google invece che con Sophos Fusion e devono disporre in anticipo di un account Google Workspace/Cloud Identity (eventualmente tramite IdP). La registrazione managed Google domain, da sola, non implica l’accesso Google per l’enrollment dei dispositivi: senza l’opzione, Sophos Mobile gestisce autonomamente gli account Google delle organizzazioni registrate dopo tale data. Nelle organizzazioni registrate prima di tale data in modalità managed Google domain, l’associazione degli utenti avviene tramite Sophos Fusion; Sophos Mobile crea l’account Google gestito al momento dell’enrollment tramite SSP, ma non ne cura la successiva gestione. Per questa registrazione preesistente, senza l’opzione anche l’enrollment da parte dell’amministratore è limitato: soltanto gli utenti possono effettuare l’enrollment tramite il Sophos Fusion Self Service Portal. Se l’organizzazione è registrata in modalità Managed Google Play Account e non è ancora passata a managed Google domain, Sophos Mobile gestisce autonomamente gli account Google degli utenti. Per la registrazione Managed Google Play Account vale un limite tecnico di 10 dispositivi Android Enterprise registrati contemporaneamente per utente; non è una formula per calcolare le licenze.

Soltanto se l’enrollment dei nuovi dispositivi tramite dominio è espressamente autorizzato: Documentare l’Android Enterprise mode esistente, lo stato dell’opzione e l’associazione degli utenti Google/Sophos; tutti gli utenti previsti devono già essere presenti nel dominio Google gestito. Poi, in Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Managed Google domain device enrollment, selezionare Use managed Google domain device enrollment e scegliere Save. Verificare quindi lo stato dell’opzione e, per il progetto pilota, l’accesso a Google con l’identità prevista; il salvataggio non prova che l’enrollment del dispositivo sia riuscito. Se l’opzione manca, non creare un nuovo collegamento come soluzione alternativa: verificare prima la modalità di registrazione dell’organizzazione e valutare l’upgrade separato a managed Google domain solo con un’autorizzazione specifica. Per le organizzazioni managed Google domain registrate prima della data indicata diventano così disponibili anche QR, Zero-touch e Knox Mobile Enrollment; questi metodi erano già disponibili per le altre modalità di registrazione Android Enterprise. KME con managed Google domain device enrollment non supporta la modalità legacy Device administrator.

Preparare criterio, pacchetto e identità degli utenti

La guida ai criteri Android Enterprise per i dispositivi aziendali spiega le opzioni specifiche di un criterio Full Device; non sostituisce la scelta della modalità di enrollment.

Creare una Android Enterprise device policy per Full Device e una Android Enterprise work profile policy per Work Profile. Non presentare un criterio Work Profile come prova della gestione completa dei dispositivi aziendali. Per ciascun tipo di dispositivo utilizzato, creare un pacchetto di attività distinto che comprenda almeno Enroll e Assign policy per il criterio corrispondente. Annotare destinatari e assegnazioni esistenti prima del progetto pilota.
Prima degli inviti, verificare la configurazione SSP salvata ed effettivamente applicabile: In Setup > Self Service Portal, stabilire quale configurazione esistente si applica ai gruppi di utenti previsti: se un utente rientra in più gruppi con configurazioni applicabili, prevale la priorità più alta; Default si applica solo se nessun’altra configurazione corrisponde. Verificare una configurazione già adeguata, senza crearne una nuova. In Maximum number of devices deve esserci ancora disponibilità per l’enrollment pianificato; questo limite SSP non coincide né con il conteggio delle licenze né con il limite tecnico di Google. Nelle impostazioni della piattaforma Android, verificare che Owner, il Device group di destinazione e Enrollment package siano coerenti con la proprietà del dispositivo, la modalità di gestione approvata e il pacchetto di attività predisposto; per i dispositivi personali e aziendali si possono utilizzare pacchetti diversi. Owner da solo non dimostra che il dispositivo sia effettivamente in modalità Full Device. Se la configurazione non è chiara o non è adeguata, fermarsi e coinvolgere l’amministrazione competente, senza ricorrere a un altro account o a un altro tipo di enrollment né modificare Default in modo generalizzato.
La verifica della configurazione e il progetto pilota secondo la procedura amministrativa SSP sono prerequisiti per gli inviti: Se manca una configurazione adeguata, predisporla separatamente seguendo tale procedura. Prima di salvare, limitare le modifiche a un progetto pilota autorizzato e strettamente circoscritto, con le sole azioni necessarie: Save può rendere immediatamente disponibili le azioni ai gruppi già assegnati, anche prima di una correzione della priorità. Se le impostazioni della piattaforma sono state modificate, applicarle con Apply, quindi salvare la configurazione con Save. Per la verifica, Avanet consiglia di riaprire la configurazione e ricontrollare le impostazioni salvate e la priorità effettiva dei gruppi, incluso Default. Prima degli inviti o di un’assegnazione estesa ai gruppi, eseguire il test di enrollment descritto nella procedura amministrativa SSP con persone e dispositivi di test autorizzati, per ogni gruppo interessato e ogni combinazione prevista di proprietà e modalità di gestione, e verificarne l’esito sul dispositivo e in Sophos Mobile; la presenza di un’opzione visibile nel portale non è sufficiente.
Approvare l’app Sophos Mobile Control in Managed Google Play, altrimenti non si aggiornerà automaticamente. Solo dopo queste verifiche e l’approvazione dell’IT, indirizzare gli utenti al loro portale oppure all’e-mail di invito inviata dall’organizzazione e alle istruzioni SSP per gli utenti: gli utenti installano e configurano Mobile Control seguendo le istruzioni specifiche visualizzate. Questi passaggi generali dell’SSP non sostituiscono la decisione sulla modalità o sul ripristino.
Con Use managed Google domain device enrollment, creare in anticipo tutti gli utenti previsti nel dominio Google gestito, chiarire con ciascuno le credenziali Google e verificare l’associazione dei dispositivi. Per un’attività avviata da Sophos Mobile, l’indirizzo e-mail assegnato al dispositivo deve corrispondere esattamente a quello usato per l’enrollment su Google. L’accesso di un’altra persona o la modifica dell’e-mail precompilata causa il fallimento dell’enrollment. È necessario Sophos Mobile Control 9.8 o versione successiva; per Work Profile occorrono inoltre tutti gli aggiornamenti disponibili del sistema operativo e delle app. In un nuovo enrollment di dispositivi tramite dominio, l’utente deve completare l’enrollment sul dispositivo entro un’ora dal suo inizio; il solo avvio o l’uso del token entro tale periodo non basta. Preparing enrollment può rimanere per diversi minuti senza progressi visibili: lasciare aperta l’app e non spegnere il dispositivo. Se questo passaggio fallisce comunque, non riavviare ripetutamente le attività alla cieca. I possibili percorsi di recupero sono la rimozione manuale del profilo di lavoro oppure un ripristino alle impostazioni di fabbrica del dispositivo. Non scegliere liberamente fra questi interventi: verificare prima proprietà, modalità effettiva e stato del dispositivo; valutare la rimozione del profilo come percorso di recupero solo per un dispositivo di proprietà personale accertata, nella modalità Sophos BYOD Work Profile confermata, chiarendone le conseguenze per i dati di lavoro, e per un Full Device confermato chiarire le conseguenze del ripristino su tutti i dati del dispositivo. Per i dispositivi aziendali con profilo di lavoro, oppure se proprietà o modalità non sono chiare, fermarsi e verificare separatamente il percorso di recupero supportato da Sophos/OEM, ottenendo la relativa autorizzazione. Prima di qualsiasi intervento documentare proprietà, backup verificato e possibilità di recupero, utente interessato e autorizzazione esplicita; prima di un ripristino controllare inoltre configurazione FRP e accesso agli account Google previsti, nuova assegnazione QR/Zero-touch/KME e percorso di provisioning. Se le credenziali sono sconosciute, non eseguire il ripristino. Solo dopo aver confermato lo stato del dispositivo, avviare nuovamente l’enrollment; né un vecchio token del dispositivo né una nuova registrazione dell’organizzazione sostituiscono questa verifica preliminare.

Progetto pilota con amministratore: In Devices > Add > Add device wizard, cercare la persona appropriata in User > Search for user e selezionarla in User selection, impostare Android in Device details > Platform e scegliere il pacchetto Android Enterprise preparato in Enrollment type. La classificazione del dispositivo come fully managed o work profile dipende dal criterio assegnato al pacchetto; la sola selezione di Android non la determina. Per un tenant managed Google domain preesistente senza enrollment dei dispositivi tramite dominio attivato, usare invece il percorso SSP consentito. Per i dispositivi senza utente, usare esclusivamente la procedura QR/Zero-touch configurata esplicitamente a tale scopo, seguendo la guida separata al provisioning.

Fermarsi e verificare prima di modificare un collegamento Google esistente

L’upgrade della registrazione dell’organizzazione da Managed Google Play Account a managed Google domain è un intervento distinto dall’attivazione di Use managed Google domain device enrollment per i nuovi enrollments e diverso ancora dall’upgrade di un singolo dispositivo già registrato. La modifica dell’organizzazione lega la gestione al dominio di lavoro e alla Google Admin console, anziché a un singolo account Gmail. Chiarire prima titolarità del dominio, gestione delle identità, account esistenti e autorizzazione; non presumere che sia possibile annullare facilmente la modifica.

Chiarire dominio e dati di contatto prima della conferma

Verificare il dominio esatto dell’e-mail di lavoro prevista e ottenerne l’approvazione per questa modifica dell’organizzazione. Una volta completato l’upgrade, il dominio scelto è fissato in modo permanente. Per un dominio Google gestito esistente occorre un accesso autorizzato con il relativo account super amministratore. Questo accesso autentica il collegamento; la titolarità resta legata al dominio, non alla singola persona.

Quando l’upgrade riesce, Google elimina le informazioni di contatto del collegamento precedente, tra cui l’indirizzo Gmail e i dati del responsabile della protezione dei dati e del rappresentante nell’UE. Avanet consiglia di salvare le informazioni necessarie prima della conferma, rispettando le regole interne sulla privacy e sull’accesso, e di designare la persona responsabile della loro successiva gestione. Questo riguarda i metadati di contatto del collegamento, non un’eliminazione documentata dell’account Gmail. Se il dominio non è chiaro, manca l’autorizzazione di super amministratore o non è stato chiarito come trasferire i contatti, fermarsi prima di Upgrade.

Proseguire l’upgrade Google da Sophos Mobile

Dopo un’autorizzazione specifica, aprire il reindirizzamento a Google in Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Upgrade to managed Google domain. Questo EMM-initiated upgrade viene avviato dalla console di gestione esistente; il reindirizzamento Sophos è il punto di ingresso nella transazione Google effettiva, non una seconda registrazione iniziale né un accesso generico a Google. Procedere lì alla configurazione dell’account amministratore per il dominio Google gestito e seguire il caso pertinente:

Se esiste già un dominio Google gestito, accedere con il relativo account super amministratore. Verificare nuovamente che il dominio corrisponda a quello approvato e scegliere Upgrade. Se gli utenti sono già sincronizzati, Google può proporre anche Authenticate using Google durante il collegamento. Ottenere dall’amministrazione delle identità un’approvazione separata per gli effetti di questa autenticazione Google; non attivarla se gli effetti non sono chiari. Questo passaggio condizionale di Google non coincide con l’opzione Sophos Use managed Google domain device enrollment.
Se non esiste ancora un dominio Google gestito, crearlo con l’e-mail di lavoro approvata e configurare l’account amministratore. Confermare l’e-mail tramite il messaggio di Google. In questa procedura, la verifica completa del dominio è facoltativa. Prima della conferma, verificare nuovamente il dominio e scegliere Upgrade. Si tratta della continuazione del collegamento esistente dell’organizzazione, non di una seconda registrazione iniziale tramite Configure > Register account.

Tornare quindi in Sophos Mobile, aggiornare la pagina e verificare Android Enterprise mode = Managed Google domain. Description deve mostrare l’account amministratore usato per la registrazione; correggerlo se necessario. Questi controlli devono essere eseguiti nel tenant di destinazione e non sono già stati effettuati per questo articolo. Se quanto visualizzato non corrisponde, fermarsi e chiarire il collegamento con l’amministrazione competente.

Dopo l’upgrade riuscito, la gestione dell’organizzazione avviene nella Google Admin console del dominio ora collegato; la gestione delle app resta in Sophos Mobile come EMM. Aggiornare i dati di contatto necessari nella Google Admin console di questo dominio e verificare le voci. Il reinserimento ripristina soltanto i metadati di contatto e non annulla la modifica del collegamento. Gli ulteriori passaggi di configurazione da 3 a 6 consigliati da Google nella guida alla configurazione EMM sono un’attività amministrativa Google separata, non un requisito aggiuntivo di licenza o sistema operativo per questo upgrade.

Pianificare separatamente l’enrollment dei nuovi dispositivi e l’upgrade dei singoli dispositivi

Solo dopo valutare l’enrollment tramite dominio per i nuovi dispositivi e l’upgrade separato dei dispositivi esistenti. La modifica riuscita dell’organizzazione non dimostra che un dispositivo esistente abbia cambiato modalità di enrollment.

Prima di attivare la nuova modalità di enrollment dei dispositivi, tutti gli utenti devono essere già presenti nel dominio Google; per i domini registrati prima della data indicata occorre mantenere i nomi utente esistenti, altrimenti Sophos Mobile non può associarli. Si intende la parte del nome prima della @, non necessariamente lo stesso dominio: dall’account Fusion fittizio anna@firma.example, con il dominio Google gestito google.firma.example, si ottiene l’account anna@google.firma.example. Sostituire nomi e domini con quelli del proprio tenant; per l’enrollment avviato da Sophos Mobile resta inoltre necessaria la corrispondenza esatta dell’e-mail con l’accesso Google. Con il vecchio enrollment SSP, Sophos Mobile combina il nome utente Fusion con il dominio Google gestito, cerca tale account e lo crea solo se non esiste già. Eliminare un utente Mobile non elimina il suo account nel dominio Google. La successiva gestione degli account avviene nella Google Admin console; il collegamento a una directory tramite Google Cloud Directory Sync (GCDS) è un’attività di gestione delle identità separata.

L’upgrade del singolo dispositivo è irreversibile. Procedere soltanto nell’ambito di un progetto pilota autorizzato e dopo aver verificato l’associazione dell’utente (anche per i dispositivi finora registrati senza utente), un indirizzo e-mail appartenente al dominio Google gestito, le credenziali Google, l’attivazione dell’enrollment dei dispositivi tramite dominio e Mobile Control 9.8+: Devices > [Gerät] > Show device > Actions > Upgrade to managed Google domain enrollment; l’utente deve confermare la notifica sul dispositivo e accedere a Google. L’utente deve iniziare l’upgrade sul dispositivo entro un’ora dall’avvio dell’azione in Sophos Mobile; trascorso tale termine il token di upgrade Google non è più valido. Questo termine riguarda l’inizio dell’upgrade, a differenza del completamento del nuovo enrollment del dispositivo descritto sopra. Alla scadenza non presumere che il token sia ancora valido: verificare stato e associazione dell’utente prima di una nuova azione autorizzata separatamente; non cambiare il collegamento né riavviare l’azione alla cieca. Sono necessari un backup preventivo e una procedura alternativa; questa azione non è una migrazione da Device administrator ad Android Enterprise né una procedura generale di ritorno dopo un enrollment non riuscito. L’azione non è disponibile sui dispositivi che usano già managed Google domain enrollment; la sua assenza non giustifica quindi una nuova registrazione dell’organizzazione.

Verificare il risultato e uscire in sicurezza

Nel progetto pilota, confrontare con il registro identità del dispositivo, proprietà, modalità di gestione effettivamente visualizzata, corretta associazione dell’utente, attività completate e criterio applicato; verificare inoltre sul dispositivo che, nel caso di un dispositivo BYOD personale confermato con Work Profile, siano interessate soltanto le app e i dati gestiti, oppure che il dispositivo aziendale sia configurato correttamente. La presenza di un’attività creata o di una voce per l’account Google non dimostra che l’enrollment abbia avuto effetto. In caso di superamento del termine, e-mail errata o criterio non applicato, fermarsi prima di inviare un’altra attività, acquisire lo stato del dispositivo e delle attività e individuare il problema.

Non ridurre la dismissione a un semplice rollback dell’enrollment: Per rimuovere dalla gestione un dispositivo Android Enterprise completamente gestito occorre un ripristino alle impostazioni di fabbrica; prima di autorizzarlo, chiarire separatamente proprietà, backup recuperabile di tutti i dati interessati, procedura di ripristino, Factory Reset Protection (FRP), validità e disponibilità delle credenziali degli account Google configurati a questo scopo, nonché nuova procedura di provisioning. Se le credenziali sono sconosciute o non valide, fermarsi: dopo un wipe il dispositivo potrebbe diventare inutilizzabile. Il QR richiede una scansione durante la configurazione del dispositivo; per Zero-touch/KME, verificare l’assegnazione attiva presso il provider e la procedura di restituzione/riutilizzo prima del ripristino, nel flusso di provisioning separato. Anche l’eliminazione della voce di un Full Device ancora gestito può provocare un ripristino automatico alle impostazioni di fabbrica; non usarla come pulizia senza rischi. Soltanto per un dispositivo di proprietà personale accertata (BYOD), con modalità Sophos Work Profile effettivamente confermata, valutare dopo l’autorizzazione Devices > [Arbeitsprofilgerät] > Actions > Wipe Android work profile: vengono eliminate le app e i dati nel profilo di lavoro, non automaticamente l’intero dispositivo personale. Avviare l’azione con Yes nella finestra di conferma solo dopo aver verificato dispositivo, modalità, backup e autorizzazione. Con la registrazione Managed Google Play Account, dopo la rimozione dalla gestione può rimanere sul dispositivo un account Google che continua a essere conteggiato nel limite dei dispositivi registrati contemporaneamente; in tal caso, rimuovere manualmente soltanto l’account gestito identificato senza ambiguità, non l’account Google privato dell’utente, prima di considerare liberato il posto. Solo dopo aver confermato lo stato del dispositivo, aggiornare inventario e associazione; la scomparsa di una voce dalla console non dimostra che la rimozione dalla gestione sia riuscita. Il comando legacy Unenroll di Device administrator non sostituisce il Full-Device-Wipe.

Per la verifica degli account FRP, della sincronizzazione del dispositivo e delle procedure di ripristino prima dell’autorizzazione, consultare Preparare e verificare Android FRP; non costituisce un’autorizzazione generale al ripristino.

Ambito della guida: QR, Zero-touch e Knox Mobile Enrollment, compresi ripristino e autorizzazione del provider, recupero degli account FRP, migrazione da Device administrator, rimozione BYOD in dettaglio e distribuzione di app/criteri richiedono procedure distinte. Per questo articolo non sono stati eseguiti interventi su dispositivi, tenant o token, né ripristini o rimozioni dalla gestione; le combinazioni OS/OEM supportate, la licenza effettiva e i ruoli Google/Sophos reali vanno verificati nel sistema di destinazione.