Configurar varios controladores de dominio con Sophos ZTNA

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.

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, licencia y roles

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

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

Antes de realizar el cambio, compruebe que ZTNA > Resources & Access esté disponible en el tenant y que la cuenta de administrador utilizada pueda añadir y editar recursos allí. Si falta la opción de menú o el botón, no continúe presuponiendo un rol o una licencia: aclare el permiso de ZTNA y el alcance contratado en su tenant o con el partner de Sophos responsable.

Cómo añadir recursos: crear cada controlador de dominio

Cree cada DC por separado como Domain Controller con método de acceso basado en agente:

En Sophos Fusion, abra My Products > ZTNA > Resources & Access y seleccione Add Resource.
Introduzca un nombre único y una descripción breve, por ejemplo, dc01-example y Controlador de dominio sede de Zúrich.
Mantenga activada la opción Show resource in user portal según el acceso de usuario deseado.
Seleccione el Gateway correspondiente.
En Access method, seleccione Agent y asigne la Policy basada en agente adecuada.
En Resource type, seleccione Domain Controller (DC).
En External FQDN, introduzca el nombre completo de este DC, por ejemplo, dc01.example.com, no solo el dominio raíz example.com.
Introduzca Internal FQDN/IP address únicamente si el destino interno difiere del External FQDN. Si no se especifica ningún valor, Sophos utiliza automáticamente el External FQDN.
Revise los puertos añadidos automáticamente y agregue solo los servicios que este entorno necesite realmente.
En Advanced Domain Controller settings, revise los registros SRV.
En Assign User Groups, mueva de Available User Groups a Assigned User Groups todos los grupos que necesiten recursos detrás de este DC.
Seleccione Save y pruebe después el DC con un dispositivo Windows piloto.

Los recursos sin agente y los recursos basados en agente requieren registros DNS diferentes. Sophos no crea un dominio 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 basado en IP no queda interceptado automáticamente por este mecanismo.

Comprobar los registros DNS y 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.

Sophos indica además los siguientes puertos para este tipo de recurso:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (en la ayuda de Sophos en alemán, esta línea aparece como UCP)

El formulario general de recursos solicita Specify the port type and port number (por ejemplo, HTTPS y 443 para una aplicación web). Para un controlador de dominio, en cambio, se aplican los servicios TCP y UDP necesarios.

No adopte sin revisión los valores UDP inusuales como recomendación general de AD. Proceden de la guía de recursos actual de Sophos; lo determinante es qué servicios ofrece realmente el DC propio y qué conexiones necesita la función de AD. Un recurso puede contener un total de hasta 20 entradas de puertos TCP y UDP. Introduzca los rangos con guion y separe varias entradas con comas, por ejemplo, 49152-65535.

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

Para recursos compartidos de archivos CIFS o SMB sensibles a la latencia, Sophos recomienda un gateway local. Esto no modifica la comprobación necesaria de puertos y funciones, pero acorta la ruta de datos frente a un Cloud Gateway.

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 los DC de producción. En su lugar, use dos reglas de red temporales limitadas al dispositivo piloto para aislar las rutas hacia dc01.example.com y dc02.example.com sin afectar a otros clientes. El TTL y las cachés locales de DNS y DC pueden retrasar la conmutación, por lo que debe incluir el TTL configurado y el retraso de las cachés en el calendario de la prueba.

Mientras ambos DC con Priority 1 estén aislados, use Resolve-DnsName para confirmar que la respuesta SRV contiene dc03.example.com con Priority 2, use nltest /dsgetdc:example.com /force para demostrar que se selecciona dc03 y complete correctamente el flujo real de inicio de sesión o de la aplicación dependiente de AD. Después, retire ambas reglas de prueba, vuelva a tener en cuenta el retraso de las cachés y confirme mediante la resolución SRV, nltest y el mismo flujo que la selección regresa a dc01 o dc02 del grupo con Priority 1.

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

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

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

El acceso mediante FQDN falla, pero funciona mediante la dirección IP

El ZTNA Agent solo intercepta recursos por FQDN. Por tanto, el acceso directo por IP puede eludir ZTNA y no constituye una prueba satisfactoria de ZTNA. Repita el acceso con el nombre especificado en External FQDN. Si los usuarios deben acceder obligatoriamente a los recursos internos mediante ZTNA, bloquee además la ruta IP directa con reglas de firewall adecuadas.

Un grupo de Entra ID renombrado ya no tiene acceso

Si posteriormente se cambia el nombre de un grupo de Microsoft Entra ID ya asignado, Sophos no actualiza automáticamente la lista de grupos del recurso. Vuelva a asignar el grupo afectado en Assign User Groups, guarde y pruebe el acceso con un miembro del grupo.

El FQDN externo se resuelve públicamente

En un recurso basado en agente, el FQDN externo no debe estar disponible públicamente. Es el caso opuesto al de un recurso sin agente, cuyo FQDN externo sí debe estar disponible públicamente. Compruebe conjuntamente la publicación DNS y el Access method; para el recurso de DC aquí descrito, el método de acceso sigue siendo Agent.

Varios usuarios pierden esporádicamente la conexión con AD

ZTNA Gateway 2.2 tiene el problema conocido NZT-10022: el servidor websocket del gateway puede descartar de forma intermitente paquetes grandes de AD. Como consecuencia, varios usuarios pueden perder aparentemente al azar la conectividad con AD, o Kerberos, RDP, los recursos compartidos de Windows y otras aplicaciones basadas en AD pueden responder con lentitud o fallar. La solución temporal limitada consiste en configurar una MTU de 1420 bytes en el adaptador TAP de Sophos ZTNA del endpoint afectado; no aplique este valor de forma preventiva a todos los dispositivos.

Realice primero el cambio en un dispositivo piloto desde PowerShell con permisos de administrador. Antes, anote el alias y la MTU original de IPv4 e IPv6:

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

Sustituya <TAP-ALIAS> por el alias mostrado, configure la MTU y compruebe el valor efectivo:

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

Después, vuelva a conectar ZTNA y repita varias veces la operación de Kerberos, RDP o recurso compartido que fallaba. Si el fallo continúa o aparecen otros problemas de conectividad, restaure los valores anotados; sustituya <ORIGINAL_MTU> por el valor original de cada familia de direcciones:

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

Si la primera consulta no devuelve ningún adaptador, use Get-NetAdapter para identificar el alias exacto y no modifique otra interfaz. Si la MTU vuelve al valor anterior tras reconectar o reiniciar, o 1420 no ayuda claramente, no siga reduciéndola. Recopile las versiones del gateway y del endpoint, los usuarios y servicios afectados, las marcas de tiempo, la MTU antes y después del cambio y una captura de paquetes, y escale el caso con NZT-10022.

Microsoft describe los requisitos de puertos de los servicios Windows utilizados en Service overview and network port requirements.

Reversión segura y retirada

No elimine un recurso de DC durante un inicio de sesión en curso ni durante una prueba de conmutación por error en producción. Anote primero los grupos de usuarios, puertos, registros SRV, Priority y Weight asignados, y compruebe que siga accesible al menos un DC probado del mismo grupo de prioridad o el DC alternativo previsto.

Para revertir un cambio, abra My Products > ZTNA > Resources & Access y seleccione el resource name. Allí puede editar los detalles del recurso o eliminarlo. Restaure primero cualquier cambio incorrecto de puertos, valores SRV o grupos a los valores iniciales anotados y guarde. Elimine un recurso solo cuando los usuarios y las aplicaciones ya no necesiten su FQDN.

Después, vuelva a comprobar en el dispositivo piloto la resolución SRV, nltest /dsgetdc:example.com /force y el flujo de inicio de sesión o de la aplicación afectada. Si no queda ningún DC probado accesible, deténgase antes de eliminar el recurso y escale el caso con los valores guardados. Una eliminación completada no se puede deshacer. Si el recurso ya se ha eliminado, solo un administrador cualificado debe recrearlo manualmente a partir de la configuración anotada, reasignar los grupos y repetir después toda la validación. Si es necesario conservar la identidad o el estado del recurso, o si los registros están incompletos, no lo recree y escale el caso.

Operación, revisión y ciclo de vida

Priority, Weight y TTL deben figurar en la documentación operativa del entorno de AD. Revise la asignación después de cambios en las ubicaciones de los DC, FQDN, servicios ofrecidos, puertos o grupos de usuarios. Volver a asignar un grupo de Entra ID renombrado es un paso operativo independiente; no se actualiza automáticamente.

No se documenta ninguna instrucción específica de migración, retirada ni fin de vida para esta función. Tras actualizar el producto, compruebe primero la ayuda de recursos vigente y los campos visibles en el tenant, y vuelva a validar los cambios en un dispositivo piloto limitado.

Guías existentes relacionadas

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.