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

• Licença MDM necessária: A gestão de Macs requer Sophos Mobile Device Management, como licença autónoma ou incluído na licença combinada Sophos Mobile. Sophos Mobile Threat Defense, por si só, não é suficiente: esta licença abrange a gestão do Sophos Intercept X for Mobile e do Sophos Chrome Security, não a gestão MDM dos Macs. Confirme no tenant o direito de utilização MDM correspondente antes de criar as políticas.
• 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?

Ao configurar manualmente Global HTTP proxy com credenciais, introduza o nome de utilizador do proxy em Authentication e a respetiva palavra-passe do proxy em Password. Authentication é aqui um campo de nome de utilizador, não uma seleção do método de autenticação. Confirme com o responsável pelo proxy se são necessárias credenciais; não inclua as palavras-passe em tickets ou repositórios públicos.

Wi-Fi: definir a rede e a autenticação

As descrições dos campos seguintes correspondem às definições documentadas pela Sophos, não a uma ligação testada no Mac. Connect automatically liga automaticamente o Mac quando a rede Wi-Fi está disponível. Hidden network identifica uma rede que não anuncia o seu SSID. A seleção tem de corresponder à rede de destino; um SSID oculto não constitui uma aprovação de segurança.

Security type define o método de segurança e a variante Personal ou Enterprise. Acordar ambos com o responsável pela rede Wi-Fi. Para Personal, introduzir a palavra-passe da rede Wi-Fi em Password. Para Enterprise, Protocols disponibiliza os protocolos de autenticação e Authentication a autenticação do cliente:

• Em Protocols > Accepted EAP types, definir os tipos EAP que o Mac aceita para autenticação, de acordo com o serviço RADIUS. Para EAP-FAST, pode configurar-se uma Protected Access Credential (PAC). Esta PAC não é um ficheiro de configuração automática de proxy. Com TTLS, Internal identity seleciona o protocolo de autenticação do utilizador dentro do túnel, não o nome de utilizador.
• Se o método Enterprise escolhido usar nome de utilizador e palavra-passe, introduzir o nome de utilizador Wi-Fi em Authentication > User e a palavra-passe Wi-Fi em Password. A associação da política a um utilizador não substitui estes dados. Segundo a Sophos, Require password on each connect significa que a palavra-passe é enviada em cada autenticação. Não deduzir daí um pedido de palavra-passe, uma forma específica de armazenamento ou a transmissão da palavra-passe em texto simples. Não acrescentar indiscriminadamente uma palavra-passe aos métodos baseados em certificados.

Outer identity é uma identidade de substituição com a qual o EAP inicia a autenticação sem revelar as credenciais reais do utilizador. É transmitida em texto simples. Por isso, não usar o nome de utilizador real nem dados sensíveis. Se o serviço RADIUS exigir encaminhamento baseado em realm, esta identidade tem de incluir o realm acordado com o responsável pelo serviço. Sem esse encaminhamento, uma identidade simples como anonymous pode bastar. Continuam a aplicar-se as condições de EAP e TLS 1.3 indicadas abaixo.

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.

VPN: acordar o fornecedor, a autenticação e o proxy

Connection name é o nome da ligação que o utilizador vê no Mac, não o nome da política. A lista de campos da Sophos indica em Connection type as opções Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point e Custom SSL/TLS. Custom SSL/TLS destina-se a fornecedores cuja aplicação na App Store disponibiliza a ligação VPN. Esta lista não aprova todas as combinações de fornecedor e macOS. A aplicação necessária já tem de estar instalada; confirmar com o fornecedor o seu identificador Reverse-DNS real.

Usar as opções seguintes apenas se o tipo de ligação e o fornecedor escolhidos as disponibilizarem e exigirem. Se o fornecedor indicar propriedades de ligação próprias, introduzir cada Key e Value em Third-party settings, através de Add. Não copiar propriedades de outra VPN. Group é um grupo eventualmente necessário para a autenticação VPN, não um grupo de dispositivos para atribuir a política.

Definir separadamente com o responsável pela VPN a autenticação do utilizador e do dispositivo:

• Em User authentication, escolher entre Password e Certificate. O campo correspondente Password contém a palavra-passe VPN; Certificate contém o certificado para a autenticação do utilizador na VPN.
• Com Device authentication = Keys (Shared Secret)/Group name, aparecem Group name, Keys (Shared Secret), Use hybrid authentication e Request password. Introduzir em Group name e Keys (Shared Secret) os dados de autenticação indicados pelo responsável pela VPN. Selecionar Use hybrid authentication e Request password apenas de acordo com os seus requisitos, não como solução genérica para falhas de ligação.
• Com Device authentication = Certificate, aparecem Certificate e Including user PIN. Selecionar o certificado de dispositivo necessário na lista Certificate. Including user PIN inclui o PIN do utilizador na autenticação do dispositivo. A fonte não define quando o PIN é pedido nem como é guardado.

Proteger as palavras-passe VPN e os Shared Secrets como as restantes credenciais. Os campos de certificados continuam a não comprovar um mecanismo de associação SCEP; verificar a identidade e a autenticação reais no contexto de utilizador ou dispositivo previsto.

No Proxy próprio da VPN, No proxy significa que não é configurado um proxy para esta ligação. Com Manually, aparecem Server and port, Authentication e Password. Introduzir aí o endereço e a porta do proxy e, se necessário, o nome de utilizador e a palavra-passe do proxy. Também aqui Authentication é o campo de nome de utilizador. Com Automatic, aparece Proxy server URL para o URL do servidor com as definições de proxy. É uma definição desta ligação VPN, não uma alteração a Global HTTP proxy.

Provider type distingue App proxy, um túnel VPN ao nível da aplicação, de Packet tunnel, um túnel VPN ao nível da rede. Acordar a opção adequada com o fornecedor. Não deduzir daí um túnel dividido ou completo; continuam a ser necessários o planeamento do tráfego e a verificação de DNS e rotas no piloto.

SCEP: verificar endpoints, identidade e chaves

URL contém o endereço Web do servidor CA. %_SCEPPROXYURL_% refere-se ao URL do servidor no separador SCEP da página Sophos setup. Challenge é o endereço Web através do qual se obtém uma palavra-passe de challenge do servidor SCEP, não a própria palavra-passe. %_CACHALLENGE_% refere-se ao URL de challenge no mesmo separador. CA name tem de ser um nome que a CA reconheça; pode, por exemplo, distinguir diferentes instâncias de CA. Acordar o valor adequado com a PKI, sem presumir um nome universal ou a obrigatoriedade de preencher o campo.

Para um Subject Alternative Name adicional, escolher primeiro o tipo em Type of Subject Alternative Name e introduzir depois o valor em Value of Subject Alternative Name. A Sophos descreve RFC 822 name como um endereço de e-mail válido, DNS name como o nome DNS do servidor CA e Uniform resource identifier como um URL completo do servidor CA. Não substituir silenciosamente estas descrições relativas ao servidor CA por pressupostos gerais sobre SAN. Esclarecer com a PKI o tipo e o valor para a finalidade prevista do certificado; estes não comprovam uma associação de identidade ao Wi-Fi ou à VPN. Se for usada uma identidade de utilizador AD, AD user logon name designa o User logon name guardado no AD, ou seja, o User Principal Name (UPN). Os dados SAN e AD não são um pré-requisito universal para todos os certificados de Mac.

Retries define o número de repetições quando o servidor SCEP responde com pending. Retry delay é o intervalo entre essas repetições, em segundos. Não é um intervalo de renovação nem uma garantia de emissão após esse tempo de espera. Key size designa o tamanho da chave pública no certificado emitido e tem de corresponder ao tamanho configurado no servidor SCEP. A configuração SCEP também tem Allow export from keychain. Esta opção permite aos utilizadores exportar a chave privada do certificado do porta-chaves. Tal como para o certificado de cliente carregado, ativá-la apenas para uma necessidade expressamente aprovada.

SCEP e chaves: As variáveis dos endpoints referem-se às definições SCEP descritas acima. 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

Em General settings, acorde com os responsáveis pelo AD os dados para a adesão ao domínio:

• Domain host name contém o nome DNS do domínio AD ao qual o Mac deve aderir. Não introduza aqui o endereço de um servidor DNS nem o controlador de domínio definido separadamente em Preferred DC server.
• AD administrator name e Password contêm o nome e a palavra-passe da conta usada para estabelecer a ligação ao servidor AD. Esta conta de adesão tem de ter permissão para adicionar dispositivos à base de dados do AD. Não inclua a palavra-passe em tickets ou repositórios públicos.
• Organizational unit define a unidade organizacional (OU) no AD em que será adicionado o computador que adere ao domínio. Acorde o valor aprovado da OU com os responsáveis pelo AD; este campo não define a associação de utilizadores ou grupos nem o diretório pessoal.

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.

Default user shell define a shell de linha de comandos do utilizador. Segundo a Sophos, se o campo ficar em branco, é usada /bin/bash. É um valor predefinido documentado para este campo, não a adoção de um valor predefinido indeterminado do macOS; acordar a shell pretendida com os responsáveis pelos Macs.

Em Mapping, os atributos AD são associados aos seguintes identificadores do macOS:

• UID attribute associa um atributo AD ao identificador único do utilizador no macOS.
• User GID attribute associa um atributo AD ao identificador do grupo principal de uma conta de utilizador macOS.
• Group GID attribute associa um atributo AD ao identificador de grupo de uma conta de grupo macOS. Esta associação não concede direitos de administrador local; essa função cabe a Domain administrator groups.

Antes da atribuição, conferir os mapeamentos existentes e aprovados com os responsáveis por AD/Mac. Não presumir um atributo AD universal nem que deixar estes campos em branco seja seguro. O risco acima descrito para o acesso a ficheiros existentes mantém-se em alterações posteriores.

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

• Preferred DC server define o controlador de domínio AD que o macOS contacta primeiro. Se o campo ficar em branco, o macOS seleciona o controlador com base nas informações de site do AD e na capacidade de resposta dos controladores. Acorde a escolha com a equipa AD; preencher o campo não significa uma vinculação exclusiva a esse controlador.
• Restrict DDNS limita as interfaces de rede para as quais o macOS utiliza Dynamic DNS. Por predefinição, o macOS utiliza DDNS para todas as interfaces de rede. Para impor uma limitação, introduza os nomes BSD das interfaces previstas e prima Enter após cada entrada. A Sophos indica en0 como exemplo de uma porta Ethernet integrada; não deduza daí qual é a interface adequada de cada Mac. Identifique as interfaces reais no Mac piloto e acorde os registos DNS pretendidos com a equipa AD/DNS. A definição limita o DDNS; não desativa nenhuma interface nem nenhum túnel VPN.
• 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 > Root certificate, crie primeiro a configuração raiz para Wi-Fi Enterprise. Selecione aí Upload a file, escolha o certificado raiz X.509 público preparado, em codificação PEM ou DER, e clique em Open. Após o carregamento, guarde a configuração raiz com Apply. Se usar autenticação por certificado, crie depois Client certificate na mesma política. Nessa configuração de Client certificate, selecione a ação Upload a file em File e escolha o ficheiro PKCS #12 (.pfx) preparado. Ative Allow export from keychain apenas se a exportação da chave privada for expressamente necessária. 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. Para concluir, guarde a política com Save em Edit policy 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. Com a equipa AD/DNS, compare o controlador de domínio efetivamente contactado e os registos DDNS reais com a seleção acordada e o conjunto de interfaces previsto. Se encontrar um controlador ou registo DNS inesperado, interrompa a implementação e esclareça a causa com esses responsáveis. 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.