Sophos Mobile: gestire la connettività macOS con criteri per dispositivo o per utente
Questo articolo riguarda i criteri di Sophos Mobile sui Mac gestiti, non la configurazione generale di Wi-Fi/VPN Apple né Sophos Endpoint, ZTNA o la configurazione di Sophos Firewall. Per l’installazione del client e l’accesso remoto tramite firewall, anziché tramite criteri di Mobile, consulta Sophos Connect su macOS. Il contesto del dispositivo e quello dell’utente sono distinti: nomi di configurazione uguali non rendono intercambiabili identità, accesso ai certificati e momento dell’applicazione. La sola assegnazione di un profilo non dimostra che la connessione funzioni.
Prerequisiti: mettere prima al sicuro l’accesso di gestione e il percorso di ripristino
- Licenza MDM necessaria: Per gestire i Mac è necessario Sophos Mobile Device Management, disponibile come licenza autonoma o incluso nella licenza combinata Sophos Mobile. Sophos Mobile Threat Defense da solo non è sufficiente: questa licenza copre la gestione di Sophos Intercept X for Mobile e Sophos Chrome Security, non la gestione MDM dei Mac. Verificare nel tenant il diritto d’uso MDM corrispondente prima di creare i criteri.
- Verificare che il Mac sia registrato in Sophos Mobile, quale versione di macOS esegua, quali criteri siano già assegnati e se la funzione richiesta debba essere gestita per un dispositivo o per uno specifico utente. In Sophos Mobile i Mac hanno un solo metodo di gestione, ma dispongono di criteri per dispositivo, dichiarativi e per utente. Apple User Enrollment per iPhone/iPad personali non è una modalità di registrazione macOS. Nella registrazione manuale del Mac, l’utente da gestire deve eseguire la registrazione e inserire una password di amministratore per il profilo di registrazione; nella registrazione automatica tramite Apple Business, verificare in Assign user to device se sia selezionato No (nessuna associazione dell’utente durante la registrazione) oppure Yes - LDAPS authentication. Non dedurre l’associazione dell’utente dal criterio per dispositivo.
- I criteri per dispositivo valgono per tutti gli utenti del Mac. I criteri per utente valgono per l’utente che effettua la registrazione locale e per gli utenti di rete noti a Sophos Mobile tramite la directory LDAP esterna del Self Service Portal. Se un Mac viene associato, tramite il criterio per dispositivo, allo stesso dominio AD del Self Service Portal, il criterio per utente viene applicato a tutti gli utenti AD che vi accedono. Verificarlo con gli account previsti prima di un’assegnazione estesa.
- Oltre al criterio di registrazione del dispositivo, a un Mac si possono assegnare un ulteriore criterio per dispositivo, uno dichiarativo e uno per utente. Prima di modificare qualsiasi payload, rilevare i Mac destinatari, gli utenti e i gruppi interessati e tutte le assegnazioni del criterio esistente: non modificare mai per il pilota un criterio già assegnato anche al di fuori del pilota. Documentare i payload Wi-Fi, VPN, proxy e certificati esistenti e i relativi responsabili; le impostazioni in conflitto vengono in generale risolte secondo il valore più restrittivo, con una precedenza particolare per le configurazioni dichiarative di aggiornamento software e app. Non sovrapporre profili esistenti con ulteriori assegnazioni non controllate.
- Verifica preliminare solo per macOS 26 con un criterio per utente: se compare lo stato
Failed to apply the policy, esaminare la cronologia delle configurazioniRestrictionsprecedentemente assegnate: la chiave obsoletaAllow Time Machinepuò persistere in un vecchio criterio assegnato anche quando non è più visibile nelle opzioni di configurazione. Non richiedere di trovare la chiave nell’interfaccia attuale. Se si sospetta questa causa storica, sospendere il pilota e la valutazione dei payload Wi-Fi/VPN/certificati di quel criterio per utente: secondo Sophos potrebbe non essere applicato l’intero criterio per utente, non soltanto la restrizione. Concordare la rimozione controllata e una nuova verifica con i responsabili dei criteri di sicurezza e privacy macOS; non modificare senza preavviso un criterio di produzione condiviso. Non è un errore generalizzato di tutti i Mac con macOS 26 o dei criteri per dispositivo. - Tenere disponibile un accesso indipendente al Mac pilota (per esempio una rete alternativa funzionante e un accesso amministrativo locale). Chiarire in anticipo con i rispettivi responsabili SSID, endpoint RADIUS/VPN, DNS, catena di attendibilità PKI, scadenza dei certificati, raggiungibilità PAC/proxy ed eventuale app VPN di terze parti. Non inserire password di accesso o file
.pfxnei ticket o in archivi pubblici. Verificare nel tenant approvazioni di prodotto, licenza e sistema operativo per l’ambiente specifico; le pagine delle configurazioni non dichiarano un supporto universale per ogni versione di macOS.
Scelta: quale criterio e quali dipendenze?
| Esigenza | Scelta nel pilota | Da predisporre / chiarire prima |
|---|---|---|
| Wi-Fi per chiunque acceda | Criterio macOS per dispositivo > Wi-Fi | SSID, Security type e, per Enterprise-EAP, attendibilità appropriata del server e identità client nello stesso criterio. |
| Wi-Fi per gli utenti gestiti | Criterio macOS per utente > Wi-Fi | Associazione e accesso dell’utente; anche il certificato root/client nello stesso criterio per utente. Non presupporre che sostituisca una rete disponibile prima dell’accesso dell’utente. |
| VPN | Criterio per dispositivo o per utente > VPN secondo il contesto richiesto | Verificare Connection type supportato, server, account, autenticazione ed eventuale app di terze parti già installata con il suo identificatore Reverse-DNS; Send all traffic through VPN solo se è previsto un tunnel completo. I campi VPN documentati per i certificati non dimostrano un’associazione automatica a un’identità SCEP: verificare separatamente nel pilota la selezione del certificato e l’autenticazione effettiva. |
| Proxy HTTP | Criterio per dispositivo o per utente > Global HTTP proxy | In modalità manuale server/porta/autenticazione, oppure una PAC URL raggiungibile in modalità automatica; il proxy specifico di una VPN è un’opzione distinta. |
| Attendibilità della CA | Root certificate nel contesto del criterio che lo utilizza | Certificato root X.509 pubblico in PEM/DER ottenuto dalla PKI competente; per Trusted certificates di Wi-Fi Enterprise aggiungerlo prima allo stesso criterio. Non selezionare una CA solo in base al nome visualizzato. |
| Identità client per Wi-Fi Enterprise | Client certificate nello stesso criterio per dispositivo o per utente del Wi-Fi | PKCS #12 (.pfx) contiene una chiave privata; consentire l’esportazione dal portachiavi solo se espressamente necessaria. Non pianificare SCEP come sostituto di questo percorso di selezione documentato da Sophos: la guida Sophos non documenta la selezione di un’identità SCEP nel campo Wi-Fi Identity certificate. Verificare separatamente richieste SCEP (URL della CA/challenge, subject X.500, SAN, dimensione della chiave) e scadenza dei certificati; gli elenchi dei campi SCEP macOS dei criteri per dispositivo e per utente non documentano un intervallo di rinnovo configurabile. |
| Unione ad AD / stampanti | Solo criterio per dispositivo > Directory service / AirPrint | DNS AD/account di join e OU oppure IP AirPrint e Resource path; non sono payload dei criteri per utente. |
Per un Global HTTP proxy configurato manualmente con credenziali, inserire il nome utente del proxy in Authentication e la relativa password in Password. Authentication è qui un campo per il nome utente, non una selezione del metodo di autenticazione. Chiarire con il responsabile del proxy se siano necessarie credenziali; non inserire le password nei ticket o in archivi pubblici.
Wi-Fi: definire rete e autenticazione
Le seguenti descrizioni dei campi riportano le impostazioni documentate da Sophos, non una connessione verificata sul Mac. Connect automatically connette automaticamente il Mac quando la rete Wi-Fi è disponibile. Hidden network identifica una rete che non trasmette la propria SSID. La scelta deve corrispondere alla rete di destinazione; una SSID nascosta non costituisce un’approvazione di sicurezza.
Security type definisce il metodo di sicurezza e la variante Personal o Enterprise. Concordare entrambi con il responsabile della rete Wi-Fi. Per Personal, inserire la password Wi-Fi in Password. Per Enterprise sono disponibili Protocols per i protocolli di autenticazione e Authentication per l’autenticazione del client:
- In Protocols > Accepted EAP types, definire i tipi EAP che il Mac accetta per l’autenticazione, in accordo con il servizio RADIUS. Per EAP-FAST è possibile configurare una Protected Access Credential (PAC). Questa PAC non è un file di configurazione automatica del proxy. Per TTLS, Internal identity seleziona il protocollo di autenticazione dell’utente all’interno del tunnel, non il nome utente.
- Se il metodo Enterprise scelto usa nome utente e password, inserire il nome utente Wi-Fi in Authentication > User e la password Wi-Fi in Password. L’assegnazione del criterio a un utente non sostituisce questi dati. Secondo Sophos, Require password on each connect significa che la password viene inviata a ogni autenticazione. Non dedurne una richiesta di inserimento della password, una modalità specifica di memorizzazione o una trasmissione in chiaro della password. Non aggiungere indiscriminatamente una password ai metodi basati su certificati.
Outer identity è un’identità segnaposto con cui EAP avvia l’autenticazione senza esporre le credenziali effettive dell’utente. Viene trasmessa in chiaro. Non usare quindi il nome utente reale né dati sensibili. Se il servizio RADIUS richiede l’inoltro in base al realm, l’identità segnaposto deve contenere il realm concordato con il responsabile del servizio. Senza questo inoltro, può bastare un’identità semplice come anonymous. Restano determinanti le condizioni EAP e TLS 1.3 indicate di seguito.
Importante per Wi-Fi Enterprise: per Identity certificate Sophos Mobile richiede prima una configurazione Client certificate nello stesso criterio; per Trusted certificates richiede prima una configurazione Root certificate. Il payload Wi-Fi dispone inoltre di un campo Proxy proprio per impostazioni manuali o PAC, distinto da Global HTTP proxy. Il certificato client è accessibile anche ad altre configurazioni dello stesso criterio, non di altri criteri: caricarlo nuovamente in questi ultimi. Apple descrive a livello di piattaforma la possibilità di associare un’identità SCEP a un servizio nello stesso profilo di configurazione; il suo esempio concreto di Wi-Fi EAP-TLS usa tuttavia un certificato AD. Questo non dimostra che Sophos Mobile offra un’identità SCEP nel campo Wi-Fi Identity certificate o distribuisca il relativo collegamento: la guida Sophos per Wi-Fi indica invece come prerequisito la configurazione Client certificate. Non prevedere una dipendenza da SCEP per la prima assegnazione o per il Wi-Fi di produzione. Considerare questa variante come procedura operativa solo dopo aver verificato l’effettivo collegamento nel proprio tenant e sul Mac pilota gestito e aver ottenuto un accesso EAP/RADIUS riuscito; se non si riesce a dimostrare né la selezione né il collegamento distribuito, interrompere questa strada. Con EAP-TTLS/PEAP/EAP-FAST impostare Outer identity senza dati sensibili dell’utente; secondo Sophos è obbligatoria con TLS 1.3. Impostare insieme TLS-Minimum e -Maximum oppure lasciare entrambi vuoti.
VPN: concordare fornitore, autenticazione e proxy
Connection name è il nome della connessione che l’utente vede sul Mac, non il nome del criterio. L’elenco dei campi Sophos indica per Connection type le opzioni Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point e Custom SSL/TLS. Custom SSL/TLS è previsto per i fornitori la cui app nell’App Store fornisce la connessione VPN. Questo elenco non approva ogni combinazione di fornitore e macOS. L’app necessaria deve essere già installata; chiarire con il fornitore il suo effettivo identificatore Reverse-DNS.
Usare le seguenti opzioni soltanto se il tipo di connessione e il fornitore scelti le rendono disponibili e le richiedono. Se il fornitore specifica proprietà di connessione proprie, inserire Key e Value per ciascuna tramite Add in Third-party settings. Non copiare proprietà da un’altra VPN. Group è un gruppo eventualmente necessario per l’autenticazione VPN, non un gruppo di dispositivi per l’assegnazione del criterio.
Definire separatamente con il responsabile della VPN l’autenticazione dell’utente e quella del dispositivo:
- In User authentication, scegliere tra Password e Certificate. Il campo corrispondente Password contiene la password VPN, Certificate il certificato per l’autenticazione dell’utente VPN.
- Con Device authentication = Keys (Shared Secret)/Group name, compaiono Group name, Keys (Shared Secret), Use hybrid authentication e Request password. Inserire i dati di autenticazione forniti dal responsabile in Group name e Keys (Shared Secret). Selezionare Use hybrid authentication e Request password soltanto in base ai suoi requisiti, non come soluzione generica a un problema di connessione.
- Con Device authentication = Certificate, compaiono Certificate e Including user PIN. Selezionare il certificato del dispositivo necessario dall’elenco Certificate. Including user PIN include il PIN dell’utente nell’autenticazione del dispositivo. La fonte non specifica quando venga richiesto il PIN né come venga memorizzato.
Proteggere le password VPN e i segreti condivisi come le altre credenziali. I campi dei certificati continuano a non dimostrare un percorso di collegamento SCEP; verificare identità e autenticazione effettive nel contesto utente o dispositivo previsto.
Nel Proxy specifico della VPN, No proxy significa che non viene configurato un proxy per questa connessione. Con Manually, compaiono Server and port, Authentication e Password. Inserire indirizzo e porta del proxy e, se necessari, nome utente e password del proxy. Anche qui Authentication è il campo per il nome utente. Con Automatic, compare Proxy server URL per l’URL del server con le impostazioni del proxy. È un’impostazione di questa connessione VPN, non una modifica a Global HTTP proxy.
Provider type distingue App proxy, un tunnel VPN a livello applicazione, da Packet tunnel, un tunnel VPN a livello rete. Concordare con il fornitore l’opzione appropriata. Non dedurne un tunnel parziale o completo; restano necessari il piano del traffico e la verifica di DNS e route nel pilota.
SCEP: verificare endpoint, identità e chiavi
URL contiene l’indirizzo web del server CA. %_SCEPPROXYURL_% si riferisce all’URL del server nella scheda SCEP della pagina Sophos setup. Challenge è l’indirizzo web tramite cui viene ottenuta una password challenge dal server SCEP, non la password stessa. %_CACHALLENGE_% si riferisce all’URL della challenge nella stessa scheda. CA name deve essere un nome riconosciuto dalla CA; può, per esempio, distinguere diverse istanze della CA. Concordare il valore appropriato con la PKI, senza presumere un nome universale o l’obbligo di compilare il campo.
Per aggiungere un Subject Alternative Name, scegliere prima il tipo in Type of Subject Alternative Name, poi inserire il valore in Value of Subject Alternative Name. Sophos descrive RFC 822 name come un indirizzo email valido, DNS name come il nome DNS del server CA e Uniform resource identifier come un URL completo del server CA. Non sostituire tacitamente queste descrizioni riferite al server CA con supposizioni generali sui SAN. Chiarire con la PKI tipo e valore per lo scopo previsto del certificato; non dimostrano un’associazione dell’identità a Wi-Fi o VPN. Se si usa un’identità utente AD, AD user logon name indica il User logon name registrato in AD, cioè lo User Principal Name (UPN). SAN e dati AD non sono un prerequisito generale per ogni certificato Mac.
Retries definisce il numero di tentativi ripetuti quando il server SCEP risponde pending. Retry delay è l’intervallo in secondi tra questi tentativi. Non è un intervallo di rinnovo né una garanzia che l’emissione riesca dopo tale attesa. Key size indica la dimensione della chiave pubblica nel certificato emesso e deve corrispondere alla dimensione configurata sul server SCEP. Anche la configurazione SCEP ha Allow export from keychain, che consente agli utenti di esportare la chiave privata del certificato dal portachiavi. Come per il certificato client caricato, attivare l’opzione soltanto per una necessità espressamente approvata.
SCEP e chiavi: Le variabili degli endpoint si riferiscono alle impostazioni SCEP descritte sopra. Dopo la sostituzione dei segnaposto, il valore Subject deve essere un nome X.500 valido: CN=%_USERNAME_% indica un utente, CN=%_DEVPROP(SerialNumber)_% un Mac. Non dedurre dalla scelta di un criterio per utente che l’identità del dispositivo sia appropriata. Verificare attendibilità della CA, durata dei certificati, esportazione delle chiavi, data di scadenza e procedura di riemissione prima della prima dipendenza; i certificati root non sostituiscono un certificato client. Per più certificati root, aggiungere una configurazione Root certificate distinta per ciascuno.
Altri payload per dispositivo: AirPrint inserisce IP della stampante e Resource path (per esempio ipp/print) nell’elenco AirPrint. Directory service associa il Mac a un dominio AD quando viene assegnato il criterio; l’account di join deve avere i permessi per aggiungere computer e la OU deve essere corretta. Attenzione: modifiche alla mappatura UID, User-GID o Group-GID possono impedire agli utenti di accedere a file creati in precedenza. Non modificare la mappatura come test di rete; pianificare separatamente l’unione ad AD e il suo annullamento con i responsabili AD/Mac.
Directory service: definire account, directory home e permessi
In General settings, concordare con i responsabili AD i dati per l’unione al dominio:
- Domain host name contiene il nome host DNS del dominio AD a cui deve unirsi il Mac. Non inserire qui l’indirizzo di un server DNS né il controller di dominio specificato separatamente in Preferred DC server.
- AD administrator name e Password contengono il nome e la password dell’account usato per connettersi al server AD. Questo account di join deve avere i permessi per aggiungere dispositivi al database AD. Non inserire la password nei ticket o in archivi pubblici.
- Organizational unit definisce l’unità organizzativa (OU) in AD in cui viene aggiunto il computer che si unisce al dominio. Concordare con i responsabili AD il valore della OU approvata; il campo non determina l’assegnazione di utenti o gruppi né la directory home.
Prima dell’unione ad AD, decidere con i responsabili AD/Mac se sia necessaria una directory home locale con un account mobile oppure una home esclusivamente di rete. Se si seleziona Create mobile account, macOS crea l’account al primo accesso con una connessione al server AD; in seguito è possibile accedere con le credenziali AD anche senza connessione a quel server. Con Require confirmation before creating a mobile account, l’utente decide se creare l’account mobile: la sua creazione non è quindi garantita. Per gli account mobili è necessario Force local home folder: il profilo utente si trova sul volume di avvio. Se questa opzione viene disattivata, vengono utilizzate directory home esclusivamente di rete. Non attivare quindi gli account mobili indiscriminatamente per ogni Mac. Se si usa Use UNC path from Active Directory, macOS monta la directory home specificata nell’account utente AD; concordare con i responsabili il protocollo di montaggio appropriato in Network protocol e verificare l’accesso nel pilota.
Default user shell definisce la shell da riga di comando dell’utente. Secondo Sophos, se il campo rimane vuoto viene usato /bin/bash. È un valore predefinito documentato per il campo, non un generico valore predefinito di macOS; concordare la shell desiderata con i responsabili Mac.
In Mapping, gli attributi AD vengono associati ai seguenti identificatori macOS:
- UID attribute associa un attributo AD all’identificatore univoco dell’utente in macOS.
- User GID attribute associa un attributo AD all’identificatore del gruppo primario di un account utente macOS.
- Group GID attribute associa un attributo AD all’identificatore del gruppo di un account di gruppo macOS. Questa associazione non concede privilegi di amministratore locale; a questo serve Domain administrator groups.
Prima dell’assegnazione, confrontare con i responsabili AD/Mac le associazioni esistenti e quelle approvate. Non presumere un attributo AD universale né che lasciare vuoti questi campi sia sicuro. In caso di modifiche successive resta il rischio, descritto sopra, di perdere l’accesso ai file esistenti.
Prima dell’assegnazione, far approvare le seguenti decisioni in Administrative:
- Preferred DC server definisce il controller di dominio AD che macOS contatta per primo. Se il campo rimane vuoto, macOS sceglie il controller in base alle informazioni sui siti AD e alla capacità di risposta dei controller. Concordare la scelta con il team AD; un valore inserito non implica un’associazione esclusiva a quel controller.
- Restrict DDNS limita le interfacce di rete per le quali macOS utilizza Dynamic DNS. Per impostazione predefinita, macOS utilizza DDNS per tutte le interfacce di rete. Per limitarne l’uso, inserire i nomi BSD delle interfacce previste e premere Enter dopo ogni voce. Sophos cita
en0come esempio di porta Ethernet integrata; non dedurne quale sia l’interfaccia appropriata su ogni Mac. Individuare le interfacce effettive sul Mac pilota e concordare le registrazioni DNS desiderate con il team AD/DNS. L’impostazione limita DDNS, non disattiva interfacce né tunnel VPN. - Rotazione della password dell’account computer: Password trust interval in days riguarda l’account computer AD, non la password dell’utente. Un campo vuoto indica una modifica automatica ogni 14 giorni;
0impedisce le modifiche automatiche. Concordare l’intervallo con i responsabili operativi AD; non impostare0come soluzione rapida a un problema di connessione. - Protezione LDAP: per Packet signing / Packet encryption vale una descrizione comune:
Allowlascia a macOS la decisione di firmare e/o crittografare le connessioni LDAP;Disabledisattiva entrambe le protezioni;Requirerichiede sempre firma e crittografia;SSL/TLSutilizza sempre LDAP su SSL/TLS. Non dedurne che ogni valore sia disponibile in entrambi i campi: verificare le opzioni effettive nel tenant e definire con il team AD la protezione richiesta. Non ridurre la protezione per ottenere un accesso riuscito. - Limiti di accesso: Multi-domain authentication consente l’accesso agli utenti di tutti i domini della foresta AD. Si tratta di un ampliamento dell’ambito di accesso, non dell’applicazione del criterio per utente del Self Service Portal descritta sopra. Con Namespace = Forest sono possibili utenti con lo stesso nome in domini diversi; l’accesso avviene come
DOMAIN\name. Con Domain il supporto del namespace è disattivato e i nomi di accesso devono essere univoci. Registrare in anticipo i domini e gli account consentiti; la scelta dei nomi non sostituisce l’approvazione dell’ambito di accesso. - Privilegi di amministratore locale: i membri dei gruppi AD inseriti in Domain administrator groups ricevono privilegi di amministratore sul Mac. Questi sono distinti dai permessi dell’account di join per aggiungere un computer. Inserire solo gruppi approvati nel formato
DOMAIN\group, rispettando maiuscole e minuscole. Registrare per il pilota quali account debbano restare utenti standard e quali debbano ricevere privilegi di amministratore locale.
Assegnare il pilota e verificarne gli effetti
- Delimitare anzitutto il pilota: controllare l’inventario nominativo dei Mac previsti e degli utenti interessati, l’appartenenza ai gruppi, i tipi e le assegnazioni dei criteri esistenti e un accesso alternativo funzionante. Per un criterio esistente individuare tutti i dispositivi e i gruppi a cui è assegnato; se è assegnato anche al di fuori del pilota o se la portata degli effetti non è chiara, non modificarlo. Prima di sostituire il precedente criterio macOS per dispositivo o per utente, confrontare tutti i payload e le dipendenze e preparare una via di ripristino dello stesso tipo per esattamente quei dispositivi destinatari. Usare anche l’assegnazione a un gruppo solo se la composizione attuale e l’eventuale ampliamento futuro sono controllati; altrimenti scegliere i singoli dispositivi.
- In Policies > macOS, usare Create per creare un nuovo criterio di prova isolato del tipo appropriato; usare una copia solo come nuovo criterio autonomo, senza assegnazioni ereditate. Prima della prima modifica ai payload verificare che il criterio di prova non sia assegnato a dispositivi o gruppi al di fuori del pilota autorizzato. Lasciare invariato il criterio di produzione assegnato su larga scala. Impostare nome, descrizione e nome dell’organizzazione; per Wi-Fi Enterprise creare prima la configurazione root con Add configuration > Root certificate. Scegliere Upload a file, selezionare il certificato root X.509 pubblico predisposto in codifica PEM o DER e fare clic su Open. Dopo il caricamento, salvare la configurazione root con Apply. Se si usa l’autenticazione con certificato, creare poi Client certificate nello stesso criterio. In questa configurazione Client certificate, scegliere l’azione Upload a file sotto File e selezionare il file PKCS #12 (
.pfx) predisposto. Attivare Allow export from keychain solo se l’esportazione della chiave privata è espressamente necessaria. Configurare quindi il Wi-Fi. Aggiungere configurazioni VPN/proxy solo dopo averne soddisfatto le rispettive dipendenze. Se necessario, configurare SCEP separatamente: la guida generale Sophos alla creazione di criteri menziona uno SCEP renewal interval a livello di criterio quando viene aggiunto SCEP, ma gli elenchi dei campi SCEP macOS non includono tale campo di configurazione. Verificare nel tenant se l’intervallo a livello di criterio sia effettivamente disponibile per il tipo macOS scelto; chiarire con la PKI data di scadenza e procedura di riemissione. Non trattare SCEP come fonte per il campo Wi-FiIdentity certificatesenza una verifica specifica. Infine, salvare il criterio con Save in Edit policy e registrare ambito del pilota, payload e stato originale per il ripristino. - Selezionare il triangolo blu del criterio di prova isolato e Assign, quindi in Select devices scegliere esclusivamente i Mac pilota inventariati o il gruppo di dispositivi precedentemente verificato e delimitato, e infine Finish. Prima di completare, confrontare ancora i destinatari selezionati con l’inventario; successivamente controllare le assegnazioni effettive e fermarsi se compare un gruppo di destinatari inatteso. La selezione in questo passaggio non protegge dalle modifiche a un criterio già assegnato in precedenza su larga scala. In questo percorso macOS non è disponibile uno scheduler di assegnazione
Now/Date. - Sul Mac pilota, controllare i profili assegnati nel contesto corretto in System Settings / System Preferences > Profiles. Una modifica al criterio per dispositivo ha effetto alla successiva sincronizzazione del dispositivo; il criterio per utente al successivo accesso dell’utente interessato. La modifica dei criteri macOS non richiede il passaggio manuale Update devices tipico di iOS. Registrare stato dell’assegnazione/dell’attività e visualizzazione locale del profilo, senza considerarli una verifica del funzionamento.
- Verificare gli effetti, non solo lo stato del profilo: con l’utente previsto, confrontare SSID Wi-Fi, connessione e, per Enterprise-EAP, catena di attendibilità del server prevista e identità client usata con il team RADIUS/PKI. Stabilire attivamente la VPN e verificare DNS/route nonché destinazioni raggiungibili e non raggiungibili rispetto al piano di tunnel parziale/completo; per proxy/PAC testare un accesso HTTP(S) reale e il percorso di autenticazione. Verificare i certificati per impronta digitale, validità e finalità nel portachiavi corretto. Testare inoltre un secondo utente se sono rilevanti gli effetti su tutto il dispositivo o su tutto il dominio AD. Eseguire una stampa di prova AirPrint e un accesso AD solo se questi payload sono effettivamente introdotti. Per
Directory service, verificare il primo accesso online con un account AD approvato e l’accesso alla home locale o di rete scelta; se si usa UNC, verificare anche il montaggio previsto. Se è previsto un account mobile, verificarne l’effettiva creazione, inclusa l’eventuale conferma dell’utente, quindi accedere nuovamente senza connessione al server AD. Mantenere durante queste verifiche l’accesso locale indipendente. Verificare con il team AD/DNS che il controller di dominio effettivamente contattato e le registrazioni DDNS effettive corrispondano alla scelta concordata e all’ambito delle interfacce previsto. In caso di controller o registrazioni DNS inattesi, interrompere la distribuzione e chiarire la causa con questi responsabili. Controllare inoltre i permessi previsti per utenti standard e amministratori e, dove i limiti di accesso lo richiedono, verificare che l’accesso venga rifiutato usando un account di prova appositamente autorizzato al di fuori dell’ambito di domini/account consentito. Verificare con il team AD la protezione LDAP concordata sulla connessione effettiva e confrontare l’intervallo di rotazione effettivo dell’account computer con quello concordato; verificare separatamente una modifica della password prevista in seguito, senza considerarla superata sulla base del primo accesso. Se l’accesso alla home, l’ambito di accesso, la protezione o i privilegi non corrispondono a quanto previsto, interrompere la distribuzione e coinvolgere i responsabili AD/Mac. - Consentire un’ulteriore fase pilota solo dopo che connessione, nuovo accesso e sincronizzazione della gestione sono andati a buon fine. Pianificare la rotazione dei certificati con un periodo di sovrapposizione: verificare prima che la nuova attendibilità e la nuova identità funzionino, poi rimuovere la vecchia CA o il vecchio metodo di autenticazione. La scelta di una CA per l’ispezione TLS del firewall e i profili di rete Apple generici non fanno parte di questa decisione sui criteri macOS di Mobile.
Ripristino in caso di perdita della connessione o destinatari errati
- Interrompere la distribuzione e registrare tutti gli account, i dispositivi, i gruppi e le versioni dei profili effettivamente interessati; tramite l’accesso indipendente, confrontare il profilo corrente e l’ultima combinazione funzionante. Prima di qualsiasi correzione, verificare di nuovo tutte le assegnazioni del criterio di prova e di quello di ripristino. Non eliminare immediatamente l’unica connessione o CA attraverso cui Sophos Mobile può ancora raggiungere il Mac.
- Su macOS non dare per disponibile l’azione generica Uninstall policy: secondo la guida per amministratori Sophos è consentita solo per i criteri per dispositivi Android, i container Knox e i dispositivi iOS. Solo se è comprovato che il criterio di prova è assegnato esclusivamente al pilota, correggerne i payload e attendere la sincronizzazione del dispositivo o l’accesso dell’utente. In caso contrario, non modificare un criterio assegnato anche al di fuori del pilota: delimitarne prima l’ambito con i responsabili e usare l’accesso indipendente. In alternativa, assegnare esclusivamente ai Mac pilota interessati un criterio funzionante già predisposto dello stesso tipo; controllarne prima assegnazioni e payload, non modificare un criterio di produzione condiviso per il ripristino e non avviare alcuna azione globale sul gruppo o Unassign. Quando si sostituisce un criterio precedentemente assegnato, controllarne le dipendenze e il contesto utente/dispositivo effettivo. La rimozione locale di un criterio per utente non è un ripristino permanente: viene riassegnato all’accesso successivo. Non rimuovere il profilo di registrazione per tornare indietro: ciò annulla la registrazione del Mac e richiede privilegi di amministratore.
- Prima di revocare una vecchia CA root, verificare tutti i certificati Wi-Fi/VPN e SCEP/client che ne dipendono e il percorso alternativo funzionante; se è cambiata l’associazione AD o la mappatura UID, non rischiare i permessi dei file scambiando i profili alla cieca. Dimostrare sullo stesso Mac pilota che siano stati ripristinati connessione di rete, accesso, catena dei certificati e sincronizzazione di Sophos Mobile. Se il Mac resta senza accesso di gestione, coinvolgere il supporto locale Mac/rete/PKI fornendo i valori documentati prima e dopo la modifica.
Ambito della verifica: Nessuna combinazione macOS/tenant è stata verificata qui in laboratorio. Questa guida documentale condizionata non richiede un test generale del tenant/in laboratorio prima della pubblicazione. Prima del rilascio in produzione in un ambiente specifico o di dichiarare funzionante la connettività, verificare su un Mac pilota autorizzato edizione/licenza, versione macOS, ambito del criterio e associazione utente tramite Apple Business, sincronizzazione e accesso, attendibilità PKI, Wi-Fi EAP e identità client effettivamente impiegata. Per usare SCEP come identità Wi-Fi occorre dimostrare nel proprio tenant se l’identità emessa sia selezionabile nel campo Sophos Identity certificate o venga effettivamente associata in altro modo nel profilo Wi-Fi distribuito; occorre inoltre verificare identità/impronta digitale nel portachiavi corretto del dispositivo/dell’utente e un accesso EAP/RADIUS riuscito con esattamente quel certificato sul Mac pilota gestito. La sola emissione di un certificato o installazione di un profilo non basta. Anche per SCEP come identità VPN occorre dimostrare la selezione o l’associazione distribuita, il contesto corretto del portachiavi/dell’utente e un accesso VPN riuscito con il certificato previsto sul Mac pilota; la guida Sophos per VPN indica campi per certificati ma non un percorso di collegamento SCEP. L’associazione SCEP a Wi-Fi/VPN resta irrisolta e non è un percorso operativo senza un pilota autorizzato concluso con successo. Prima dell’uso in produzione, verificare sul dispositivo app VPN/provider/autenticazione, rotazione dei certificati, accesso indipendente, sostituzione dei criteri e ripristino.