Ir al contenido
Avanet

Configurar varios controladores de dominio con Sophos ZTNA

Zero Trust Network Access

Cuando los dispositivos Windows necesitan acceder a Active Directory a través de Sophos ZTNA, un único controlador de dominio crea un punto único de fallo evitable. A partir de Sophos Endpoint 2026.1, ZTNA admite varios recursos de DC con prioridad y ponderación. De este modo, se pueden utilizar dos controladores de dominio durante el funcionamiento normal y disponer de otro DC como destino alternativo.

Cada controlador de dominio se crea como un recurso independiente basado en agente del tipo Domain Controller (DC). Sophos ZTNA proporciona la conexión y responde a las consultas DNS SRV correspondientes en el endpoint. La estructura de AD existente, la resolución DNS y las relaciones de confianza siguen siendo responsabilidad del entorno de Active Directory.

Para consultar el orden general de configuración, comience por Configurar Sophos ZTNA: visión general y orden de los pasos. Planificar y crear un Sophos ZTNA Gateway explica la planificación, el DNS y la conectividad del gateway.

Diferenciar los recursos de DC del Identity Provider

Disponer de varios recursos de DC no significa automáticamente que el Identity Provider de ZTNA pueda autenticar usuarios de varios dominios de AD independientes.

  • Los recursos de DC transportan el tráfico DNS, Kerberos, LDAP y otros flujos de AD necesarios a través del túnel ZTNA.
  • El Identity Provider autentica al usuario para ZTNA. Con el Identity Provider de Microsoft AD local, Sophos sigue admitiendo un solo dominio; los Primary y Secondary AD Servers deben pertenecer al mismo dominio.
  • El DNS de AD y las relaciones de confianza entre bosques deben funcionar previamente. ZTNA no crea reenvíos DNS, relaciones de confianza ni sincronización de usuarios entre dominios.

Por tanto, esta función es adecuada directamente para varios DC del mismo dominio. Cuando hay varios dominios o bosques, también es necesario comprobar si el Identity Provider, el DNS y las relaciones de confianza existentes permiten realmente el acceso previsto.

Requisitos

Antes de la configuración, deben cumplirse los siguientes requisitos:

  • Sophos Central con una licencia ZTNA activa.
  • Un ZTNA Gateway configurado y accesible desde el endpoint.
  • Dispositivos Windows con el ZTNA Agent y Sophos Endpoint 2026.1 o posterior.
  • Grupos de usuarios sincronizados y una ZTNA Policy basada en agente adecuada.
  • Un FQDN único para cada controlador de dominio, por ejemplo, dc01.example.com.
  • Conectividad desde el ZTNA Gateway hasta cada DC a través de los servicios de AD realmente necesarios.
  • Resolución DNS interna operativa, así como relaciones de confianza y reenvíos DNS existentes cuando haya varios dominios o bosques.

La versión del endpoint aparece en Sophos Central en My Environment > Computers & Servers > <Dispositivo> > Summary. En Assigned Products e Installed component versions, compruebe si el dispositivo piloto ya utiliza la versión necesaria.

Crear cada controlador de dominio como recurso

Cree un recurso independiente para cada DC:

  1. En Sophos Central, abra My Products > ZTNA > Resources & Access y seleccione Add Resource.
  2. Introduzca un nombre único y una descripción breve, por ejemplo, dc01-example y Controlador de dominio sede de Zúrich.
  3. Seleccione el Gateway correspondiente.
  4. En Access method, seleccione Agent.
  5. Asigne la Policy basada en agente adecuada.
  6. En Resource type, seleccione Domain Controller (DC).
  7. En External FQDN, introduzca el nombre completo de este DC, por ejemplo, dc01.example.com, no solo el dominio raíz example.com.
  8. Introduzca Internal FQDN/IP address únicamente si el destino interno difiere del External FQDN. Si no se especifica ningún valor, Sophos utiliza el External FQDN.
  9. Revise los puertos añadidos automáticamente y agregue solo los servicios que este entorno necesite realmente.
  10. En Advanced Domain Controller settings, revise los registros SRV.
  11. En Assign User Groups, asigne los grupos que necesiten servicios de AD a través de este DC.
  12. Guarde el recurso y pruebe después el DC con un dispositivo Windows piloto.

Sophos no crea un Resource Alias para un recurso de DC basado en agente. Por tanto, no deben crearse ni un CNAME público ni un registro DNS comodín para el DC, y el External FQDN tampoco debe estar disponible públicamente. Esto no afecta al CNAME del gateway necesario para Sophos Cloud Gateway. El ZTNA Agent intercepta el FQDN configurado en el endpoint. El acceso directo mediante la dirección IP no queda interceptado automáticamente por este mecanismo.

Comprobar los puertos adecuados para el entorno

El tipo de recurso Domain Controller (DC) añade automáticamente una serie de puertos. Esta lista es un punto de partida, pero no sustituye la comprobación de las funciones de AD que se utilizan realmente. Una prueba LDAP sencilla requiere conexiones distintas de un inicio de sesión con Kerberos, las directivas de grupo, DNS, SMB o RPC dinámico.

Por tanto, las listas de puertos estáticas no deben adoptarse sin revisión. Los factores determinantes son:

  • los puertos preconfigurados automáticamente en la interfaz actual de Sophos Central,
  • los servicios y puertos utilizados en Advanced Domain Controller settings,
  • los requisitos de puertos de Microsoft para las funciones de AD utilizadas en este entorno,
  • la conectividad de estos puertos desde el ZTNA Gateway hasta el DC correspondiente.

Si falta un puerto necesario en el campo de puertos normal del recurso, un registro SRV adecuado en la configuración avanzada no es suficiente por sí solo. La conexión puede fallar a pesar de una respuesta DNS correcta.

Comprender la prioridad y la ponderación SRV

Active Directory utiliza registros DNS SRV para que los clientes encuentren un servicio y un controlador de dominio adecuados. Sophos ZTNA representa estos registros en Advanced Domain Controller settings.

Los campos más importantes son:

  • Services: Servicio de AD, por ejemplo, LDAP o Kerberos.
  • Domain name: Dominio DNS al que se aplica el registro SRV.
  • Protocol: TCP o UDP.
  • Port numbers: Puerto del servicio correspondiente, por ejemplo, 389 para LDAP u 88 para Kerberos.
  • Priority: Un número menor significa una prioridad mayor. Los DC con el valor de prioridad disponible más bajo se utilizan primero.
  • Weight: Distribuye la selección entre DC con la misma prioridad.
  • TTL: Tiempo en segundos durante el que se puede almacenar en caché una respuesta. El valor predeterminado 86400 equivale a 24 horas.

Por tanto, la prioridad determina el grupo preferido. La ponderación solo influye en la selección dentro del mismo grupo. No garantiza una distribución porcentual exacta del tráfico, ya que la caché DNS, el comportamiento del cliente y el número de solicitudes también influyen en el resultado.

Ejemplo con dos DC activos y uno alternativo

Para el dominio example.com, la carga normal debe distribuirse entre dos DC. Un tercer DC se utiliza únicamente como destino alternativo:

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

Como tienen la misma Priority, dc01 y dc02 pertenecen al grupo preferido. La ponderación controla su selección aproximada en una proporción de 60 a 40. dc03, con Priority 2, solo se tiene en cuenta cuando no hay ningún DC con Priority 1 disponible.

Los tres recursos necesitan registros SRV adecuados para el mismo dominio y los servicios realmente necesarios. Sin embargo, el valor numérico superior 2 y, por tanto, la prioridad de selección inferior no convierten automáticamente a dc03 en un sustituto completo: la replicación, el DNS, el rol de catálogo global y los servicios de AD accesibles también deben ser adecuados para la conmutación por error prevista.

Probar el funcionamiento en un dispositivo Windows

Primero, compruebe la respuesta SRV para el dominio deseado:

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

La respuesta debe contener los controladores de dominio configurados con Priority y Weight. A continuación, fuerce una nueva búsqueda de DC:

nltest /dsgetdc:example.com /force

nltest muestra el DC accesible seleccionado, pero no necesariamente todos los destinos disponibles. Por tanto, compruebe además la conexión con cada servicio:

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

En este ejemplo, el puerto 389 prueba LDAP sobre TCP. Kerberos, DNS, SMB o RPC requieren pruebas adecuadas al caso de uso real. Una prueba de aceptación completa también incluye un inicio de sesión real de Windows o el acceso a la aplicación que necesita AD a través de ZTNA.

Para una captura de paquetes en el endpoint, este filtro de Wireshark muestra exclusivamente consultas DNS SRV:

dns.qry.type == 33

Una prueba de conmutación por error debe realizarse en un dispositivo piloto y durante una ventana de mantenimiento. No apague un DC de producción para ello; interrumpa la ruta principal de forma controlada únicamente durante la prueba. A continuación, vuelva a comprobar nltest, la resolución SRV y la aplicación afectada. Tras modificar Priority o Weight, el TTL y las cachés DNS locales pueden retrasar el resultado.

Cuando no se puede acceder a ningún controlador de dominio

En caso de avería, compruebe los siguientes puntos en este orden:

  1. ¿Se ha creado cada DC como recurso con Access method: Agent y Resource type: Domain Controller (DC)?
  2. ¿Utiliza External FQDN el nombre específico del DC en lugar de solo el dominio de AD?
  3. ¿Son correctos el dominio, el servicio, el protocolo, el puerto, la Priority y el Weight de los registros SRV?
  4. ¿Todos los puertos utilizados allí también están incluidos en el campo de puertos normal del recurso?
  5. ¿Puede el ZTNA Gateway acceder a cada DC a través de esos puertos?
  6. ¿Están asignados correctamente los usuarios piloto, los grupos y la Policy?
  7. ¿El dispositivo Windows ejecuta Sophos Endpoint 2026.1 o posterior?
  8. ¿Muestran Resolve-DnsName, nltest y dns.qry.type == 33 los mismos DC que Sophos Central?

Para ZTNA Gateway 2.2, Sophos también incluye NZT-10022 en la Known Issues List actual: los paquetes de AD grandes pueden descartarse de forma intermitente. Los posibles síntomas incluyen conexiones Kerberos, RDP o de recursos compartidos de archivos poco fiables. Como solución temporal, Sophos indica una MTU de 1420 bytes para el adaptador TAP de Sophos ZTNA. Este cambio solo corresponde a este problema concreto y no debe configurarse de forma preventiva en todos los dispositivos.

Sophos ofrece la descripción oficial de los campos y la interfaz actual en Add resources. Microsoft describe los requisitos de puertos de los servicios Windows utilizados en Service overview and network port requirements.