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

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.

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, licença e funções

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

Sophos Fusion (anteriormente 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 Fusion 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.

Antes da alteração, confirme se ZTNA > Resources & Access está disponível no tenant e se a conta de administrador usada pode adicionar e editar recursos nessa área. Se a opção de menu ou o botão não aparecer, não prossiga supondo uma função ou licença; esclareça a permissão de ZTNA e o escopo contratado no seu tenant ou com o parceiro Sophos responsável.

Como adicionar recursos: criar cada controlador de domínio

Crie cada DC separadamente como Domain Controller com método de acesso baseado em agente:

No Sophos Fusion, abra My Products > ZTNA > Resources & Access e selecione Add Resource.
Insira um nome exclusivo e uma breve descrição, por exemplo, dc01-example e Controlador de domínio da unidade de Zurique.
Mantenha Show resource in user portal ativado de acordo com o acesso de usuário desejado.
Selecione o Gateway responsável.
Em Access method, selecione o valor Agent e atribua a Policy adequada baseada em agente.
Em Resource type, selecione o valor Domain Controller (DC).
Em External FQDN, insira o nome completo desse DC, por exemplo, dc01.example.com – não apenas o domínio raiz example.com.
Preencha Internal FQDN/IP address somente se o destino interno for diferente do External FQDN. Sem um valor, a Sophos usa automaticamente o External FQDN.
Verifique as portas inseridas automaticamente e adicione apenas os serviços realmente necessários nesse ambiente.
Em Advanced Domain Controller settings, verifique os registros SRV.
Em Assign User Groups, mova de Available User Groups para Assigned User Groups todos os grupos que precisam de recursos por trás desse DC.
Selecione Save e, em seguida, teste o DC com um dispositivo Windows piloto.

Recursos sem agente e recursos baseados em agente exigem registros DNS diferentes. A Sophos não cria um domínio de 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 baseado em IP não é interceptado automaticamente.

Verificar os registros DNS e 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.

A Sophos também relaciona as seguintes portas para esse tipo de recurso:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (na ajuda da Sophos em alemão, essa linha está identificada como UCP)

O formulário geral de recursos solicita Specify the port type and port number (por exemplo, HTTPS e 443 para um aplicativo web). Para um controlador de domínio, aplicam-se os serviços TCP e UDP necessários.

Não adote os valores UDP incomuns sem análise como recomendação geral de AD. Eles vêm do guia atual de recursos da Sophos; o que importa é quais serviços o seu DC realmente oferece e quais conexões a função de AD exige. Um recurso pode conter até 20 entradas de portas TCP e UDP no total. Insira intervalos com hífen e separe várias entradas por vírgulas, por exemplo, 49152-65535.

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 Fusion,
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.

Para compartilhamentos de arquivos CIFS ou SMB sensíveis à latência, a Sophos recomenda um gateway local. Isso não altera a verificação necessária de portas e funções, mas reduz o caminho dos dados em comparação com um Cloud Gateway.

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 desligue os DCs de produção. Em vez disso, use duas regras de rede temporárias limitadas ao dispositivo piloto para isolar os caminhos até dc01.example.com e dc02.example.com sem afetar outros clientes. O TTL e os caches locais de DNS e DC podem atrasar o failover; portanto, inclua o TTL configurado e o atraso dos caches no cronograma do teste.

Enquanto os dois DCs com Priority 1 estiverem isolados, use Resolve-DnsName para confirmar que a resposta SRV contém dc03.example.com com Priority 2, use nltest /dsgetdc:example.com /force para comprovar que dc03 foi selecionado e conclua com êxito o fluxo real de login ou do aplicativo dependente do AD. Depois, remova as duas regras de teste, considere novamente o atraso dos caches e confirme com a resolução SRV, o nltest e o mesmo fluxo que a seleção retorna a dc01 ou dc02 no grupo com Priority 1.

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

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

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

O acesso por FQDN falha, mas por endereço IP funciona

O ZTNA Agent intercepta recursos apenas com base no FQDN. Portanto, o acesso direto por IP pode contornar o ZTNA e não constitui um teste bem-sucedido do ZTNA. Repita o acesso usando o nome inserido em External FQDN. Se os usuários precisarem acessar recursos internos exclusivamente pelo ZTNA, bloqueie também o caminho IP direto com regras de firewall adequadas.

Um grupo do Entra ID renomeado deixou de ter acesso

Se um grupo do Microsoft Entra ID já atribuído for renomeado posteriormente, a Sophos não atualizará automaticamente a lista de grupos do recurso. Atribua novamente o grupo afetado em Assign User Groups, salve e teste o acesso com um membro desse grupo.

O FQDN externo é resolvido publicamente

Em um recurso baseado em agente, o FQDN externo não pode estar disponível publicamente. É o caso oposto de um recurso sem agente, cujo FQDN externo deve estar disponível publicamente. Portanto, verifique em conjunto a publicação de DNS e o Access method; para o recurso de DC descrito aqui, o método de acesso continua sendo Agent.

Vários usuários perdem esporadicamente a conexão com o AD

O ZTNA Gateway 2.2 tem o problema conhecido NZT-10022: o servidor websocket do gateway pode descartar esporadicamente pacotes grandes de AD. Como resultado, vários usuários podem perder a conectividade com o AD de forma aparentemente aleatória, ou Kerberos, RDP, compartilhamentos de arquivos do Windows e outros aplicativos baseados em AD podem ficar lentos ou falhar. A solução alternativa limitada é definir uma MTU de 1420 bytes no adaptador Sophos ZTNA TAP do endpoint afetado; não aplique esse valor preventivamente a todos os dispositivos.

Faça a alteração primeiro em um dispositivo piloto, em uma sessão do PowerShell executada como administrador. Antes, anote o alias e a MTU original de IPv4 e IPv6:

Get-NetIPInterface | Where-Object InterfaceAlias -Like '*Sophos*ZTNA*TAP*' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Substitua <TAP-ALIAS> pelo alias exibido, defina a MTU e confirme o valor efetivo:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -NlMtuBytes 1420
Get-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Em seguida, reconecte o ZTNA e repita várias vezes a operação Kerberos, RDP ou de compartilhamento de arquivos que falhava anteriormente. Se a falha continuar ou surgirem outros problemas de conectividade, restaure os valores anotados; substitua <ORIGINAL_MTU> pelo valor original de cada família de endereços:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv4 -NlMtuBytes <ORIGINAL_MTU>
Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv6 -NlMtuBytes <ORIGINAL_MTU>

Se a primeira consulta não retornar nenhum adaptador, use Get-NetAdapter para identificar o alias exato e não altere outra interface. Se a MTU voltar ao valor anterior após a reconexão ou reinicialização, ou se 1420 não produzir uma melhora clara, não continue a reduzi-la. Em vez disso, reúna as versões do gateway e do endpoint, os usuários e serviços afetados, os horários, a MTU antes e depois da alteração e uma captura de pacotes, e escale o caso com NZT-10022.

A Microsoft descreve os requisitos de portas dos serviços Windows utilizados em Service overview and network port requirements.

Reversão segura e desativação

Não remova um recurso de DC durante um login em andamento nem durante um teste de failover em produção. Primeiro, registre os grupos de usuários, portas, registros SRV, Priority e Weight atribuídos e confirme que pelo menos um DC testado do mesmo grupo de prioridade ou o DC alternativo previsto continue acessível.

Para reverter uma alteração, abra My Products > ZTNA > Resources & Access e selecione o resource name. Nesse local, é possível editar os detalhes do recurso ou removê-lo. Primeiro, restaure qualquer alteração incorreta em portas, valores SRV ou grupos para os valores iniciais anotados e salve. Remova um recurso somente quando seu FQDN não for mais necessário para usuários ou aplicativos.

Em seguida, verifique novamente no dispositivo piloto a resolução SRV, nltest /dsgetdc:example.com /force e o fluxo de login ou do aplicativo afetado. Se nenhum DC testado continuar acessível, pare antes da remoção e escale o caso com os valores salvos. Uma remoção concluída não pode ser desfeita. Se o recurso já tiver sido removido, somente um administrador qualificado poderá recriá-lo manualmente com base nas configurações registradas, reatribuir os grupos e repetir toda a validação. Se for necessário preservar a identidade ou o estado do recurso, ou se os registros estiverem incompletos, não o recrie; escale o caso.

Operação, revisão e ciclo de vida

Priority, Weight e TTL devem fazer parte da documentação operacional do ambiente de AD. Revise a atribuição após alterações em locais de DC, FQDNs, serviços oferecidos, portas ou grupos de usuários. A reatribuição de um grupo do Entra ID renomeado é uma etapa operacional separada; não ocorre atualização automática.

Não há instruções específicas documentadas de migração, desativação ou fim de vida para essa função. Após atualizações do produto, primeiro verifique a ajuda atual de recursos e os campos visíveis no tenant e, depois, valide novamente as alterações em um dispositivo piloto limitado.

Guias existentes relacionados

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.