Saltar para o conteudo
Avanet

Configurar vários controladores de domínio com o Sophos ZTNA

Zero Trust Network Access

Quando dispositivos Windows precisam acessar o Active Directory pelo Sophos ZTNA, um único controlador de domínio representa um ponto único de falha que pode ser evitado. A partir do Sophos Endpoint 2026.1, o ZTNA oferece suporte a vários recursos de DC com prioridade e peso. Assim, é possível usar dois controladores de domínio na operação normal e manter outro DC como destino alternativo.

Para isso, cada controlador de domínio é criado como um recurso separado baseado em agente do tipo Domain Controller (DC). O Sophos ZTNA disponibiliza a conexão e responde às consultas DNS-SRV correspondentes no endpoint. A estrutura de AD existente, a resolução de DNS e as relações de confiança continuam sendo responsabilidade do ambiente do Active Directory.

Para conhecer a sequência geral de configuração, consulte primeiro Configurar o Sophos ZTNA: visão geral e sequência. O planejamento, o DNS e a acessibilidade do gateway são abordados em Planejar e criar um Sophos ZTNA Gateway.

Distinguir recursos de DC e Identity Provider

Vários recursos de DC não significam automaticamente que o ZTNA Identity Provider possa autenticar usuários de vários domínios AD independentes.

  • Recursos de DC transportam pelo túnel ZTNA o tráfego de DNS, Kerberos, LDAP e outros tráfegos de AD necessários.
  • O Identity Provider autentica o usuário para o ZTNA. Com o Microsoft AD Identity Provider local, a Sophos continua oferecendo suporte a um domínio; Primary e Secondary AD Server devem pertencer ao mesmo domínio.
  • AD DNS e Forest Trusts já devem estar funcionando. O ZTNA não cria encaminhamentos de DNS, relações de confiança nem sincronização de usuários entre domínios.

Assim, a função é diretamente adequada a vários DCs do mesmo domínio. Em ambientes com vários domínios ou forests, também é necessário verificar se o Identity Provider, o DNS e as relações de confiança existentes realmente permitem o acesso planejado.

Pré-requisitos

Antes da configuração, os seguintes requisitos devem ser atendidos:

  • Sophos Central com uma licença ZTNA ativa.
  • Um ZTNA Gateway configurado e acessível pelo endpoint.
  • Dispositivos Windows com ZTNA Agent e Sophos Endpoint 2026.1 ou mais recente.
  • Grupos de usuários sincronizados e uma ZTNA Policy adequada baseada em agente.
  • Um FQDN exclusivo para cada controlador de domínio, por exemplo, dc01.example.com.
  • Acessibilidade de cada DC a partir do ZTNA Gateway pelos serviços de AD realmente necessários.
  • Resolução de DNS interno funcional, além de relações de confiança e encaminhamentos de DNS existentes em ambientes com vários domínios ou forests.

A versão do Endpoint aparece no Sophos Central em My Environment > Computers & Servers > <Dispositivo> > Summary. Em Assigned Products e Installed component versions, é possível verificar se o dispositivo piloto já usa a versão necessária.

Criar cada controlador de domínio como recurso

Um recurso separado é criado para cada DC:

  1. No Sophos Central, abra My Products > ZTNA > Resources & Access e selecione Add Resource.
  2. Insira um nome exclusivo e uma breve descrição, por exemplo, dc01-example e Controlador de domínio da unidade de Zurique.
  3. Selecione o Gateway responsável.
  4. Em Access method, selecione o valor Agent.
  5. Atribua a Policy adequada baseada em agente.
  6. Em Resource type, selecione o valor Domain Controller (DC).
  7. Em External FQDN, insira o nome completo desse DC, por exemplo, dc01.example.com – não apenas o domínio raiz example.com.
  8. Preencha Internal FQDN/IP address somente se o destino interno for diferente do External FQDN. Sem um valor, a Sophos usa o External FQDN.
  9. Verifique as portas inseridas automaticamente e adicione apenas os serviços realmente necessários nesse ambiente.
  10. Em Advanced Domain Controller settings, verifique os registros SRV.
  11. Em Assign User Groups, atribua os grupos que precisam dos serviços de AD por meio desse DC.
  12. Salve e, em seguida, teste o DC com um dispositivo Windows piloto.

A Sophos não cria um Resource Alias para um recurso de DC baseado em agente. Portanto, não se deve criar um CNAME público nem um registro DNS curinga para o DC; o External FQDN também não pode estar disponível publicamente. Um CNAME de gateway necessário para o Sophos Cloud Gateway não é afetado por essa regra. O ZTNA Agent intercepta o FQDN configurado no endpoint. O acesso direto pelo endereço IP não é interceptado automaticamente.

Verificar as portas de acordo com o ambiente

O tipo de recurso Domain Controller (DC) preenche automaticamente uma série de portas. Essa lista é um ponto de partida, mas não substitui a verificação das funções de AD realmente usadas. Um teste simples de LDAP requer conexões diferentes de um login com Kerberos, políticas de grupo, DNS, SMB ou RPC dinâmico.

Por isso, listas estáticas de portas não devem ser copiadas sem análise. Os pontos decisivos são:

  • as portas preenchidas automaticamente na interface atual do Sophos Central,
  • os serviços e as portas usados em Advanced Domain Controller settings,
  • os requisitos de portas da Microsoft para as funções de AD usadas nesse ambiente,
  • a acessibilidade dessas portas do ZTNA Gateway até o respectivo DC.

Se uma porta necessária estiver ausente no campo normal de portas do recurso, apenas um registro SRV correspondente nas configurações avançadas não será suficiente. Nesse caso, a conexão poderá falhar apesar da resposta de DNS correta.

Entender prioridade e peso de SRV

O Active Directory usa registros DNS-SRV para que os clientes encontrem um serviço e um controlador de domínio adequados. O Sophos ZTNA representa esses registros em Advanced Domain Controller settings.

Os campos mais importantes são:

  • Services: Serviço de AD, por exemplo, LDAP ou Kerberos.
  • Domain name: Domínio DNS ao qual o registro SRV se aplica.
  • Protocol: TCP ou UDP.
  • Port numbers: Porta do respectivo serviço, por exemplo, 389 para LDAP ou 88 para Kerberos.
  • Priority: Um número menor significa prioridade maior. Os DCs com a menor prioridade numérica disponível são usados primeiro.
  • Weight: Distribui a seleção entre DCs com a mesma prioridade.
  • TTL: Tempo em segundos durante o qual uma resposta pode permanecer em cache. O valor padrão 86400 corresponde a 24 horas.

Assim, a prioridade define o grupo preferido. O peso influencia apenas a seleção dentro do mesmo grupo. Ele não garante uma distribuição percentual exata do tráfego, pois o cache de DNS, o comportamento do cliente e a quantidade de consultas também influenciam o resultado.

Exemplo com dois DCs ativos e um DC alternativo

Para o domínio example.com, a carga normal deve ser distribuída entre dois DCs. Um terceiro DC será usado apenas como destino alternativo:

  • dc01.example.com: Priority 1, Weight 60
  • dc02.example.com: Priority 1, Weight 40
  • dc03.example.com: Priority 2

Como têm a mesma Priority, dc01 e dc02 pertencem ao grupo preferido. O peso controla a seleção aproximada na proporção de 60 para 40. O dc03, com Priority 2, só é considerado quando nenhum DC com Priority 1 está disponível.

Os três recursos precisam de registros SRV adequados para o mesmo domínio e para os serviços realmente necessários. No entanto, o valor numérico maior 2 e, portanto, a menor prioridade de seleção não tornam automaticamente o dc03 uma substituição completa: a replicação, o DNS, a função de Global Catalog e os serviços de AD acessíveis também devem ser adequados ao failover planejado.

Testar o funcionamento em um dispositivo Windows

Primeiro, verifique a resposta SRV do domínio desejado:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.example.com

A resposta deve conter os controladores de domínio configurados com Priority e Weight. Em seguida, force uma nova pesquisa de DC:

nltest /dsgetdc:example.com /force

O nltest mostra o DC acessível selecionado, mas não necessariamente todos os destinos disponíveis. Por isso, a conexão com serviços individuais também pode ser testada:

Test-NetConnection dc01.example.com -Port 389
Test-NetConnection dc02.example.com -Port 389
Test-NetConnection dc03.example.com -Port 389

Neste exemplo, a porta 389 testa LDAP por TCP. Para Kerberos, DNS, SMB ou RPC, devem ser realizados testes adequados ao caso de uso real. Uma validação completa também inclui um login real no Windows ou o acesso ao aplicativo que precisa do AD pelo ZTNA.

Para uma captura de pacotes no endpoint, este filtro do Wireshark exibe somente consultas DNS-SRV:

dns.qry.type == 33

Um teste de failover deve ser realizado em um dispositivo piloto e durante uma janela de manutenção. Não se deve desligar um DC de produção para esse teste; em vez disso, deve-se interromper de forma controlada o caminho primário apenas para o teste. Depois, verifique novamente o nltest, a resolução SRV e o aplicativo afetado. Após alterações em Priority ou Weight, o TTL e os caches de DNS locais podem atrasar o resultado.

Quando nenhum controlador de domínio está acessível

Em caso de falha, verifique os seguintes pontos nesta ordem:

  1. Cada DC está criado como recurso com Access method: Agent e Resource type: Domain Controller (DC)?
  2. O External FQDN usa o nome específico do DC, e não apenas o domínio do AD?
  3. Domínio, serviço, protocolo, porta, Priority e Weight dos registros SRV estão corretos?
  4. Todas as portas usadas nesses registros também estão presentes no campo normal de portas do recurso?
  5. O ZTNA Gateway consegue acessar cada DC por essas portas?
  6. Usuários piloto, grupos e Policy estão atribuídos corretamente?
  7. O dispositivo Windows executa o Sophos Endpoint 2026.1 ou mais recente?
  8. Resolve-DnsName, nltest e dns.qry.type == 33 mostram os mesmos DCs que o Sophos Central?

Para o ZTNA Gateway 2.2, a Sophos também inclui NZT-10022 na Known Issues List atual: pacotes grandes de AD podem ser descartados esporadicamente. Possíveis sintomas incluem conexões não confiáveis de Kerberos, RDP ou compartilhamento de arquivos. Como solução alternativa, a Sophos informa uma MTU de 1420 bytes para o adaptador Sophos ZTNA TAP. Essa alteração só se aplica a esse cenário de erro específico e não deve ser definida preventivamente em todos os dispositivos.

A descrição oficial dos campos e a interface atual estão disponíveis na documentação da Sophos em Add resources. A Microsoft descreve os requisitos de portas dos serviços Windows utilizados em Service overview and network port requirements.