Sophos Mobile: gerir a conectividade macOS através de políticas de dispositivo ou de utilizador

Este artigo aborda políticas do Sophos Mobile em Macs geridos, não a configuração geral de Wi-Fi/VPN da Apple, nem o Sophos Endpoint, o ZTNA ou a configuração de uma Sophos Firewall. Para instalar o cliente e configurar o acesso remoto pela firewall em vez de usar uma política do Mobile, consulte Sophos Connect no macOS. Os contextos de dispositivo e de utilizador são distintos: nomes de configuração idênticos não tornam intercambiáveis a identidade, o acesso aos certificados e o momento de aplicação. A simples atribuição de um perfil não prova que a ligação funciona.

Pré-requisitos: garantir primeiro o acesso de gestão e a via de recuperação

• Confirme que o Mac está registado no Sophos Mobile, qual a versão do macOS e que políticas já lhe estão atribuídas, bem como se a funcionalidade pretendida exige a gestão do dispositivo ou de um utilizador específico. Os Macs têm apenas um modo de gestão no Sophos Mobile, mas admitem políticas de dispositivo, declarativas e de utilizador. O User Enrollment da Apple para iPhones/iPads pessoais não é um modo de registo do macOS. No registo manual de um Mac, o utilizador a gerir tem de efetuar o registo e introduzir uma palavra-passe de administrador para o perfil de registo; no registo automático via Apple Business, verifique em Assign user to device se foi selecionado No (sem associação de utilizador durante o registo) ou Yes - LDAPS authentication. Não infira a associação do utilizador a partir da política de dispositivo.
• As políticas de dispositivo aplicam-se a todos os utilizadores do Mac. As políticas de utilizador aplicam-se ao utilizador que faz o registo localmente e aos utilizadores de rede conhecidos pelo Sophos Mobile através do diretório LDAP externo do Self Service Portal. Se a política de dispositivo ligar um Mac ao mesmo domínio AD do Self Service Portal, a política de utilizador aplica-se a todos os utilizadores AD que aí iniciem sessão. Verifique isto com as contas previstas antes de uma atribuição alargada.
• Além da política de dispositivo usada no registo, pode atribuir-se a um Mac uma política de dispositivo adicional, uma declarativa e uma de utilizador. Antes de alterar qualquer payload, identifique os Macs de destino, os utilizadores e grupos afetados e todas as atribuições da política existente: nunca altere para o piloto uma política já atribuída fora do piloto. Documente os payloads de Wi-Fi, VPN, proxy e certificados existentes e respetivos responsáveis; configurações contraditórias são, em regra, resolvidas pelo valor mais restritivo, com prioridade especial para as configurações declarativas de atualização de software/aplicações. Não sobreponha perfis existentes com atribuições adicionais não controladas.
• Verificação prévia apenas para macOS 26 com política de utilizador: se surgir o estado Failed to apply the policy, investigue o histórico das configurações Restrictions anteriormente atribuídas: a chave obsoleta Allow Time Machine pode persistir numa política antiga atribuída mesmo que já não apareça nas opções de configuração. Não exija encontrar a chave na interface atual. Se suspeitar desta causa histórica, pare o piloto e a avaliação dos payloads de Wi-Fi/VPN/certificados dessa política de utilizador: segundo a Sophos, nesse caso pode falhar a aplicação de toda a política de utilizador, não apenas da restrição. Coordene a remoção controlada e a nova verificação com os responsáveis pelas políticas de segurança e privacidade do macOS; não altere silenciosamente uma política de produção partilhada. Isto não é uma falha geral de todos os Macs com macOS 26 nem das políticas de dispositivo.
• Mantenha acesso independente ao Mac piloto (por exemplo, uma rede alternativa funcional e acesso de administração local). Confirme antecipadamente com os respetivos responsáveis o SSID, os endpoints RADIUS/VPN, DNS, a cadeia de confiança PKI, a validade dos certificados, a acessibilidade do PAC/proxy e, se necessário, a aplicação VPN de terceiros. Não inclua palavras-passe de acesso nem ficheiros .pfx em tickets ou repositórios públicos. Confirme no tenant as aprovações de produto/licença/SO para o ambiente concreto; as páginas de configuração não garantem compatibilidade universal com todas as versões do macOS.

Escolha: que política e que dependências?

Importante para Wi-Fi Enterprise: Para Identity certificate, o Sophos Mobile exige primeiro uma configuração Client certificate na mesma política; para Trusted certificates, uma configuração Root certificate prévia. O payload Wi-Fi também tem um campo próprio Proxy para definições manuais ou PAC; não é o mesmo que Global HTTP proxy. O certificado de cliente fica acessível a outras configurações da mesma política, não de outras políticas; carregue-o novamente nessas políticas. A Apple descreve, ao nível da plataforma, que uma identidade SCEP pode ser associada a um serviço no mesmo perfil de configuração; contudo, o exemplo concreto de Wi-Fi EAP-TLS da Apple usa um certificado AD. Isso não demonstra que o Sophos Mobile disponibilize uma identidade SCEP no seu campo Wi-Fi Identity certificate ou distribua a respetiva associação: a ajuda de Wi-Fi da Sophos indica antes a configuração de Client certificate como pré-requisito. Não planeie uma dependência de SCEP para a atribuição inicial nem para o Wi-Fi de produção. Considere essa opção operacional apenas depois de comprovar a associação efetiva no seu tenant, no Mac piloto gerido e através de uma autenticação EAP/RADIUS bem-sucedida; se não for possível comprovar nem a seleção nem a associação distribuída, interrompa essa opção. Para EAP-TTLS/PEAP/EAP-FAST, defina Outer identity sem dados sensíveis do utilizador; segundo a Sophos, é obrigatória com TLS 1.3. Defina o mínimo e o máximo de TLS em conjunto ou deixe ambos em branco.

SCEP e chaves: %_SCEPPROXYURL_% e %_CACHALLENGE_% referem-se às definições SCEP guardadas no Sophos Mobile. Após a substituição dos marcadores, o valor de subject tem de ser um nome X.500 válido: CN=%_USERNAME_% identifica um utilizador, CN=%_DEVPROP(SerialNumber)_% um Mac. Não conclua, pela escolha de uma política de utilizador, que a identidade de dispositivo é adequada. Verifique a confiança na CA, o período de validade do certificado, a exportação da chave, a data de expiração e o procedimento de reemissão antes de estabelecer a primeira dependência; certificados raiz não substituem um certificado de cliente. Adicione uma configuração Root certificate distinta para cada certificado raiz adicional.

Outros payloads de dispositivo: AirPrint insere o IP da impressora e o Resource path (por exemplo, ipp/print) na lista AirPrint. Directory service liga o Mac a um domínio AD quando a política é atribuída; a conta de adesão tem de possuir direitos para adicionar computadores e a OU tem de estar correta. Aviso: Alterações ao mapeamento de UID, User-GID ou Group-GID podem impedir os utilizadores de aceder a ficheiros que criaram anteriormente. Não altere o mapeamento para testar a rede; planeie separadamente a adesão ao AD e a sua reversão com os responsáveis por AD/Mac.

Directory service: definir contas, diretório pessoal e permissões

Antes da adesão ao AD, decida com os responsáveis por AD/Mac se é necessário um diretório pessoal local com conta móvel ou um diretório pessoal exclusivamente de rede. Se selecionar Create mobile account, o macOS cria a conta no primeiro início de sessão com ligação ao servidor AD; depois, é possível iniciar sessão com as credenciais AD mesmo sem ligação a esse servidor. Com Require confirmation before creating a mobile account, o utilizador decide se a conta móvel é criada — nesse caso, a criação não é garantida. As contas móveis exigem Force local home folder: o perfil do utilizador fica no volume de arranque. Se esta opção for desativada, são usados diretórios pessoais exclusivamente de rede. Por isso, não ative contas móveis indiscriminadamente em todos os Macs. Se usar Use UNC path from Active Directory, o macOS monta o diretório pessoal definido na conta do utilizador AD; acorde com os responsáveis o protocolo de montagem adequado em Network protocol e teste o acesso no piloto.

Em Administrative, obtenha aprovação para as seguintes decisões antes da atribuição:

• Rotação da palavra-passe da conta de computador: Password trust interval in days diz respeito à conta de computador no AD, não à palavra-passe do utilizador. Um campo em branco significa uma alteração automática a cada 14 dias; 0 impede alterações automáticas. Acorde o intervalo com a equipa de operação do AD; não defina 0 como solução rápida para um problema de ligação.
• Proteção LDAP: Packet signing / Packet encryption têm uma descrição conjunta: Allow deixa ao macOS a decisão de assinar e/ou cifrar as ligações LDAP; Disable desativa ambas as proteções; Require exige sempre assinatura e cifragem; SSL/TLS utiliza sempre LDAP sobre SSL/TLS. Não deduza daí que todos os valores estão disponíveis em ambos os campos: verifique as opções reais no tenant e defina com a equipa AD a proteção exigida. Não reduza a proteção para conseguir iniciar sessão.
• Limites do início de sessão: Multi-domain authentication permite iniciar sessão a utilizadores de todos os domínios da floresta AD. Isto alarga o âmbito do início de sessão; não corresponde à aplicação da política de utilizador do Self Service Portal descrita acima. Com Namespace = Forest, podem existir utilizadores com o mesmo nome em domínios diferentes; o início de sessão faz-se como DOMAIN\name. Com Domain, o suporte de namespace está desativado e os nomes de início de sessão têm de ser únicos. Registe previamente os domínios e as contas permitidos; a escolha dos nomes não substitui a aprovação do âmbito do início de sessão.
• Direitos de administrador local: Os membros dos grupos AD indicados em Domain administrator groups recebem direitos de administrador no Mac. Estes direitos são distintos dos direitos da conta de adesão para adicionar um computador. Introduza apenas grupos aprovados no formato DOMAIN\group e respeite as maiúsculas e minúsculas. Registe para o piloto que contas devem continuar como utilizadores padrão e quais devem receber direitos de administrador local.

Atribuir ao piloto e verificar o resultado

1. Delimite primeiro o piloto: verifique o inventário dos Macs identificados e utilizadores afetados, a pertença a grupos, os tipos de política e atribuições existentes, e um acesso alternativo funcional. Para uma política existente, identifique todos os dispositivos e grupos a que está atribuída; se também estiver atribuída fora do piloto ou se o alcance for incerto, não a edite. Antes de substituir uma política macOS de dispositivo ou de utilizador existente, compare todos os payloads e dependências e prepare uma via de recuperação do mesmo tipo para exatamente esses dispositivos de destino. Só use uma atribuição a grupo se a sua composição e futuras ampliações forem controladas; caso contrário, selecione dispositivos individuais.
2. Em Policies > macOS, use Create para criar uma nova política de teste isolada do tipo adequado; use uma cópia apenas como política nova e autónoma, sem herdar atribuições. Antes de alterar o primeiro payload, confirme que esta política de teste não está atribuída a nenhum dispositivo ou grupo fora do piloto aprovado. Deixe inalterada a política de produção atribuída a um conjunto alargado de dispositivos. Defina nome, descrição e nome da organização; com Add configuration, crie primeiro Root certificate e, se usar autenticação por certificado, Client certificate na mesma política para Wi-Fi Enterprise; depois configure Wi-Fi. Acrescente configurações VPN/proxy apenas depois de satisfazer as respetivas dependências. Se necessário, configure SCEP separadamente: as instruções gerais da Sophos para criar políticas mencionam um SCEP renewal interval ao adicionar SCEP ao nível da política, mas as listas de campos SCEP do macOS não incluem esse campo de configuração. Confirme no tenant se o intervalo ao nível da política está realmente disponível para o tipo macOS escolhido; esclareça com a PKI a data de expiração e o procedimento de reemissão. Não trate SCEP como fonte do campo Wi-Fi Identity certificate sem comprovação própria. Guarde e registe o âmbito do piloto, os payloads e o estado original para a recuperação.
3. Selecione o triângulo azul da política de teste isolada e Assign; em Select devices, selecione exclusivamente os Macs piloto inventariados ou o grupo de dispositivos previamente verificado e delimitado, e conclua com Finish. Antes de concluir, confira novamente os destinos selecionados com o inventário; depois, confirme as atribuições efetivas e pare se encontrar um grupo de destino inesperado. A seleção deste passo não protege contra alterações numa política previamente atribuída a um conjunto alargado de dispositivos. Neste percurso do macOS não existe um agendador Now/Date para a atribuição.
4. No Mac piloto, consulte os perfis atribuídos em System Settings / System Preferences > Profiles, no contexto correto. Uma alteração à política de dispositivo produz efeitos na sincronização seguinte do dispositivo; a política de utilizador, no próximo início de sessão do utilizador afetado. Uma alteração a políticas macOS não exige o passo manual Update devices típico de iOS. Registe o estado da atribuição/tarefa e os perfis apresentados localmente, mas não os considere um teste funcional.
5. Teste o funcionamento, não apenas o estado do perfil: com o utilizador previsto, confirme o SSID Wi-Fi e a ligação e, para Enterprise EAP, valide com a equipa RADIUS/PKI a cadeia de confiança do servidor esperada e a identidade do cliente utilizada. Estabeleça ativamente a VPN e verifique DNS/rotas, bem como destinos acessíveis e inacessíveis, face ao plano de túnel dividido/completo; para proxy/PAC, teste um acesso HTTP(S) real e o fluxo de autenticação. Verifique os certificados por impressão digital, validade e finalidade no porta-chaves correto. Teste também um segundo utilizador se for relevante o efeito ao nível do dispositivo ou de todo o AD. Faça uma impressão de teste AirPrint e teste o início de sessão AD apenas se esses payloads forem efetivamente introduzidos. Para Directory service, teste o primeiro início de sessão online com uma conta AD aprovada e o acesso ao diretório pessoal local ou de rede escolhido; se usar UNC, confirme também a montagem prevista. Se estiver prevista uma conta móvel, confirme que foi realmente criada, incluindo qualquer confirmação do utilizador, e depois volte a iniciar sessão sem ligação ao servidor AD. Mantenha entretanto o acesso local independente. Confirme também os direitos previstos de utilizador padrão ou administrador e, quando os limites do início de sessão o exigirem, use uma conta de teste autorizada para esse fim, fora do conjunto permitido de domínios e contas, para verificar que o início de sessão é recusado. Com a equipa AD, verifique a proteção LDAP acordada na ligação real e confirme o intervalo de rotação efetivo da conta de computador; verifique separadamente uma alteração de palavra-passe devida mais tarde, sem a considerar validada pelo primeiro início de sessão. Se o acesso ao diretório pessoal, o âmbito do início de sessão, a proteção ou os privilégios divergirem do previsto, interrompa a implementação e envolva os responsáveis por AD/Mac.
6. Só permita outra vaga piloto depois de confirmar a ligação, um novo início de sessão e a sincronização de gestão. Planeie a rotação de certificados com um período de sobreposição: confirme primeiro a nova confiança e a nova identidade, e só depois remova a CA antiga ou o mecanismo de autenticação antigo. A escolha de uma CA para inspeção TLS da firewall e os perfis de rede genéricos da Apple não fazem parte desta decisão sobre políticas macOS do Mobile.

Recuperação em caso de perda de ligação ou de grupo de destino incorreto

1. Pare a implementação e registe todas as contas, dispositivos, grupos e versões de perfil efetivamente afetados; através do acesso independente, compare o perfil atual com a última combinação funcional. Antes de qualquer correção, confirme novamente todas as atribuições da política de teste e da política de recuperação. Não elimine imediatamente a única ligação ou CA que ainda permite ao Sophos Mobile contactar o Mac.
2. No macOS, não pressuponha a disponibilidade da ação genérica Uninstall policy: segundo a ajuda de administração da Sophos, só está disponível para políticas de dispositivo Android, contentor Knox e dispositivo iOS. Apenas se estiver comprovado que a política de teste está atribuída exclusivamente ao piloto, corrija os seus payloads e aguarde a sincronização do dispositivo ou o início de sessão do utilizador. Caso contrário, não altere nenhuma política com atribuições fora do piloto: delimite primeiro o âmbito com os responsáveis e use o acesso independente. Em alternativa, atribua exclusivamente aos Macs piloto afetados uma política funcional previamente preparada do mesmo tipo; confirme antes as suas atribuições e payloads, não edite uma política de produção partilhada para recuperar e não acione uma operação global de grupo ou Unassign. Ao substituir uma política anteriormente atribuída, confira as suas dependências e o contexto efetivo de utilizador/dispositivo. Remover localmente uma política de utilizador não é uma solução duradoura: é atribuída de novo no início de sessão seguinte. Não remova o perfil de registo para reverter: isso cancela o registo do Mac e exige direitos de administrador.
3. Antes de retirar uma CA raiz antiga, verifique todos os certificados de Wi-Fi/VPN e SCEP/cliente que dependem dela e a via alternativa funcional; se a associação ao AD ou o mapeamento UID mudou, não arrisque as permissões dos ficheiros alternando perfis às cegas. Comprove no mesmo Mac piloto o restabelecimento da ligação de rede, o início de sessão, a cadeia de certificados e a sincronização com o Sophos Mobile. Se o Mac continuar sem acesso de gestão, contacte o suporte local de Mac/rede/PKI com os valores documentados antes e depois da alteração.

Âmbito da validação: Nenhuma combinação macOS/tenant foi aqui validada em laboratório. Esta orientação documental condicionada não exige testes gerais no tenant/laboratório antes da publicação. Antes de implementar em produção no ambiente específico ou afirmar que a ligação funciona, valide num Mac piloto autorizado a edição/licença, versão do macOS, âmbito da política e associação do utilizador no Apple Business, sincronização e início de sessão, confiança PKI, Wi-Fi EAP e identidade de cliente efetivamente usada. Para usar SCEP como identidade Wi-Fi, é necessário comprovar no próprio tenant se é possível selecionar a identidade emitida no campo Sophos Identity certificate ou se esta é efetivamente associada de outra forma ao perfil Wi-Fi distribuído; verifique também a identidade/impressão digital no porta-chaves de dispositivo/utilizador correto e uma autenticação EAP/RADIUS bem-sucedida com esse mesmo certificado no Mac piloto gerido. A emissão do certificado ou a instalação do perfil, por si só, não basta. Também para SCEP como identidade VPN é necessário comprovar a seleção ou associação distribuída, o contexto correto de porta-chaves/utilizador e uma autenticação VPN bem-sucedida com o certificado esperado no Mac piloto; a ajuda VPN da Sophos indica campos de certificados, mas não um mecanismo de associação SCEP. A associação SCEP ao Wi-Fi/VPN continua por resolver e não é uma via operacional sem um piloto autorizado bem-sucedido. Antes da utilização em produção, teste no dispositivo a aplicação/provider VPN/autenticação, rotação de certificados, acesso independente e substituição e recuperação de políticas.