Active Directory sobre VPN: qué falla primero (DNS, hora, puertos) y cómo arreglarlo

noviembre 20, 2025 • febrero 3, 2026 • Lectura: 29 min • Views: 10

¿Te fue útil?

La VPN se levanta. Los pings funcionan. Alguien declara victoria. Entonces los usuarios no pueden iniciar sesión, las Políticas de Grupo tardan una eternidad y “la relación de confianza falló”
empieza a aparecer como tostadas en una cocina compartida de oficina.

Active Directory no falla con educación sobre una VPN. Falla de maneras específicas y repetibles: el DNS se comporta de forma extraña, el tiempo deriva, los puertos se “estrechan” y
la latencia hace que protocolos diseñados para LAN rápidas de pronto parezcan caminar por cemento húmedo. Esta es la guía de campo de lo que
falla primero —y las soluciones que realmente aguantan en producción.

Qué falla primero: el orden habitual del dolor

Si estás moviendo o extendiendo Active Directory a través de una VPN —site-to-site IPsec, WireGuard, OpenVPN, lo que sea— los modos de fallo son notablemente
consistentes. El orden que sigue no es teórico. Es lo que te despierta con una alerta a las 2 a.m.

1) DNS falla primero (o siempre estuvo roto y solo lo notaste)

AD es un directorio, pero se comporta como una aplicación DNS con funciones de identidad. Los controladores de dominio se descubren mediante registros SRV.
Los clientes encuentran LDAP, Kerberos y GC a través del DNS. Si tu VPN cambia qué servidor DNS usa un cliente, si el DNS dividido está mal configurado,
o si los reenviadores condicionales apuntan a una dirección muerta, el dominio desaparece efectivamente.

2) La hora falla segundo (Kerberos se niega a negociar con mentirosos)

Kerberos usa la hora para evitar ataques de reproducción. Si el reloj del cliente deriva más allá de la tolerancia permitida (comúnmente 5 minutos), la autenticación falla.
En una LAN, las inconsistencias de NTP suelen enmascararse con “lo suficientemente cerca”. Sobre VPN introduces nuevas fuentes de tiempo, comportamiento de suspensión/reanudación en portátiles,
y a veces dispositivos NAT que interfieren con el comportamiento NTP/UDP.

3) Los puertos fallan tercero (los firewalls hacen llorar a los adultos)

Alguien propondrá “solo permitir 88 y 389”. Alguien más insistirá “ahora es todo 443”. Ninguno es cierto para las operaciones clásicas de AD.
Necesitas un conjunto de puertos conocidos y una estrategia para los puertos RPC dinámicos. Sobre VPN, la postura “deny por defecto” es buena para seguridad,
pero también es como crear dominios misteriosos y medio funcionales.

4) Latencia y pérdida de paquetes arruinan la experiencia de usuario (incluso si nada está “caído”)

AD puede estar técnicamente funcionando mientras los inicios de sesión tardan 90 segundos, la Políticas de Grupo caducan o la cola de DFSR crece como una enredadera de película de terror.
Sobre VPN, el RTT y la variación importan. Los protocolos parlanchines de AD—especialmente durante el inicio de sesión y el procesamiento de políticas—castigan las idas y vueltas largas.

Broma #1: Active Directory sobre una VPN es como una relación a distancia: funciona hasta que alguien deja de comunicarse de forma fiable, y DNS suele ser “alguien”.

Hechos interesantes y contexto histórico (para que lo raro tenga sentido)

Hecho 1: El descubrimiento de servicios de AD depende mucho de los registros SRV de DNS (RFC 2782). Por eso “el DNS está bien” rara vez está bien.
Hecho 2: El desfase máximo de reloj por defecto de Kerberos en dominios Windows suele ser típicamente 5 minutos—lo suficientemente pequeño como para que la suspensión de un portátil arruine tu día.
Hecho 3: La replicación de AD usa RPC, lo que históricamente significó rangos de puertos dinámicos. Windows moderno puede restringir el rango, pero hay que hacerlo intencionalmente.
Hecho 4: La replicación de SYSVOL pasó de FRS a DFSR porque FRS era frágil a escala y notoriamente malo manejando conflictos.
Hecho 5: “Sites and Services” existe porque AD asumía enlaces rápidos y fiables dentro de un sitio y enlaces más lentos entre sitios—básicamente, diseño consciente de WAN antes de que “la nube” fuera moda.
Hecho 6: El Catálogo Global (GC) usa los puertos 3268/3269 porque Microsoft necesitaba una forma de consultar a todo el bosque sin perseguir referencias por todas partes.
Hecho 7: El firmado de LDAP y el binding de canal se endurecieron con los años porque LDAP era demasiado permisivo para modelos de amenaza modernos; las VPN no vuelven mágicamente seguro a un LDAP débil.
Hecho 8: La unión a dominio de Windows todavía depende de un conjunto de protocolos antiguos (SMB, RPC, Netlogon) porque la compatibilidad hacia atrás en empresas es un estilo de vida, no una fase.

Guion de diagnóstico rápido (compruébalo en este orden)

Quieres velocidad. No una lista de 40 pasos que parezca una auditoría de cumplimiento. Esta es la secuencia para “encontrar el cuello de botella en 10 minutos”.

Paso 1: Confirma que el cliente usa los servidores DNS correctos (no “los que sugiere el Wi‑Fi del hotel”)

Si el cliente no puede resolver _ldap._tcp.dc._msdcs para el dominio, para ahí. Arregla DNS primero.
Si la resolución DNS funciona pero apunta a IPs de DC inalcanzables, corrige el enrutamiento/VPN split tunneling/subredes.

Paso 2: Comprueba la desviación de hora en el cliente y en el DC que intenta usar

Si la desviación de hora es > 300 segundos, arregla la jerarquía NTP y la fuente de tiempo del cliente. No “aumentes el desfase de Kerberos”.

Paso 3: Valida los puertos básicos de AD desde la red con problema a un DC específico

Prueba TCP 88, 389/636, 445, 135, 53, 464 y un puerto RPC alto representativo (o tu rango restringido).
Si 445 falla: espera problemas con SYSVOL/GPO, unión al dominio y errores de “relación de confianza”.

Paso 4: Identifica qué DC eligió el cliente y si es el sitio correcto

Si un sitio remoto usa un DC a través del túnel mientras existe un DC más cercano, corrige Sites/Subnets y el comportamiento del localizador de DC.

Paso 5: Si todo “funciona” pero va lento, mide RTT y pérdida y busca problemas MTU/MSS

RTT alto + pérdida de paquetes + SMB + RPC = inicios de sesión lentos y timeouts de políticas.
Los agujeros negros MTU causan fallos intermitentes que parecen “problemas de autenticación aleatorios”. No son aleatorios.

DNS: el saboteador silencioso

DNS no es un actor secundario en AD. DNS es co‑protagonista. El mecanismo de descubrimiento de AD es “preguntar al DNS quiénes son los controladores de dominio”
y “preguntar al DNS qué DC está más cerca”. Cuando los clientes VPN o sitios remotos no pueden usar de forma fiable el DNS integrado en AD, obtienes fallos parciales:
avisos de inicio de sesión, uniones a dominio lentas, errores de GPO y aplicaciones que no encuentran LDAP.

DNS dividido y clientes VPN: elige un diseño y cúmplelo

Básicamente tienes dos opciones sensatas:

Forzar DNS interno cuando están conectados a la VPN (túnel completo o split tunnel con DNS forzado). Esto es lo más sencillo para la corrección de AD.
Usar reenviadores condicionales/DNS split‑horizon donde las zonas internas de AD se resuelven por DNS interno aun cuando otras consultas vayan a externo.

La opción insensata es “dejar que el cliente use cualquier servidor DNS obtenido por DHCP o Wi‑Fi y esperar”. Esperar no es una estrategia; es una caída con un póster motivacional.

Registros SRV: lo que los clientes realmente consultan

Cuando un cliente Windows necesita un DC, consulta registros como:
_ldap._tcp.dc._msdcs.<domain> y _kerberos._tcp.<domain>.
Si esos no se resuelven, el cliente no está “un poco confundido”. Está ciego.

Por qué el DNS de AD se rompe específicamente sobre VPN

Servidor DNS incorrecto empujado por la VPN: empujaste DNS público “por velocidad” y ahora los registros de AD no existen.
Split tunneling sin ruta al servidor DNS: el cliente se le dice usar DNS interno pero no puede alcanzarlo por la política de enrutamiento.
Reenviadores condicionales apuntan a través del túnel: cuando el túnel oscila, la resolución DNS se queda esperando (y lo mismo pasa con el inicio de sesión).
Problemas EDNS/fragmentación: las respuestas DNS con registros SRV pueden crecer; problemas de MTU pueden hacer que DNS parezca inestable.

Hora: Kerberos es rencoroso y guarda recibos

Kerberos se basa en “tickets” que expiran y están ligados al tiempo. Si tus relojes no coinciden, el protocolo asume que alguien miente—o está reproduciendo mensajes.
Sobre VPN, los problemas de hora se amplifican porque los portátiles deambulan, duermen, se reanudan y toman diferentes fuentes NTP según la red.

Cómo se manifiesta la “desviación de hora” en producción

El usuario recibe repetidos avisos para introducir credenciales.
La unión al dominio falla con errores genéricos que no mencionan la hora.
LDAP bind funciona (a veces), pero SSO Kerberos no.
Los logs muestran errores de Kerberos (como fallos de preautenticación) que se diagnostican mal como “contraseña incorrecta”.

Haz lo aburrido: una jerarquía de tiempo autorizada

En un dominio Windows, quieres:

El PDC Emulator en el dominio raíz del bosque sincronizado con fuentes de tiempo externas fiables.
Todos los demás DC se sincronizan desde la jerarquía del dominio.
Todos los miembros se sincronizan desde la jerarquía del dominio.

No permitas que los clientes VPN usen servidores NTP públicos aleatorios mientras intentan autenticarse con Kerberos contra tus DC. Así es como obtienes “funciona en casa, falla en hoteles”.

Puertos: cuando “solo abrimos 443” choca con la realidad

AD no es un único protocolo. Es un conjunto. Sobre una VPN, puede que no tengas “un firewall” en el sentido tradicional, pero sí tienes grupos de seguridad,
ACLs, enrutamiento por políticas, reglas NAT y personas con opiniones fuertes. Los puertos siguen importando.

Puertos centrales que normalmente necesitas (no exhaustivo, pero real)

DNS: TCP/UDP 53
Kerberos: TCP/UDP 88
Cambio de contraseña Kerberos: TCP/UDP 464
LDAP: TCP/UDP 389 (UDP se usa en escenarios antiguos; la mayoría de binds son TCP)
LDAPS: TCP 636 (si se usa)
Catálogo Global: TCP 3268 / 3269
SMB (SYSVOL, NETLOGON): TCP 445
Mapeador de endpoints RPC: TCP 135
Puertos RPC dinámicos: TCP puertos altos (rango depende de OS/config)

El problema de los puertos RPC dinámicos (y la solución adulta)

La replicación de AD y muchas operaciones de gestión de Windows usan RPC. RPC usa TCP 135 para encontrar un servicio y luego delega a un puerto alto dinámico.
Si la política de “firewall de la VPN” solo permite unos pocos puertos, la replicación se rompe de formas extrañas.

El enfoque correcto es: restringir el rango de puertos RPC dinámicos en los controladores de dominio (y en los servidores relevantes) a un rango pequeño definido, y luego permitir ese rango a través de la VPN.
No es glamuroso. Es estable.

Broma #2: Bloquear puertos RPC dinámicos por “seguridad” es como quitar todas las manillas de las puertas para prevenir allanamientos—felicidades, ahora también vives afuera.

Latencia y pérdida de paquetes: muerte por mil idas y vueltas

Puedes tener DNS perfecto, tiempo perfecto y puertos abiertos, y aun así tener un mal día. Ese día se llama “la VPN tiene 120ms RTT y 1% de pérdida”.
El inicio de sesión y el procesamiento de GPO implican múltiples operaciones en red: consultas LDAP, intercambios Kerberos, lecturas SMB de políticas, a veces comprobaciones de certificados.
Cada una añade idas y vueltas. Multiplica. Luego añade pérdida de paquetes, lo que desencadena retransmisiones y timeouts.

MTU/MSS: el gremlin detrás de “funciona para cosas pequeñas”

Las VPN suelen reducir la MTU efectiva. Si no limitas MSS o configuras la MTU apropiadamente, puedes tener fragmentación en agujero negro:
los paquetes pequeños funcionan, los grandes desaparecen. DNS con respuestas grandes, tickets Kerberos y tráfico SMB pueden comportarse mal.
El síntoma son fallos intermitentes que no se correlacionan con la carga. La gente culpabiliza “a AD por ser AD.” No es AD. Es tu ruta de paquetes.

Cuando “optimizar” significa “empeorar”

La compresión, DPI agresivo y dispositivos de “optimización WAN” pueden dañar el tráfico AD, especialmente SMB y RPC.
Algunos dispositivos son aceptables. Otros no. Si introduces una caja que reordena paquetes o tiene timeouts extraños, AD te castigará con miseria impredecible.

Sitios, subredes y replicación: haz que la topología AD refleje la red

Si ejecutas AD sobre VPN y no configuras Sites and Services correctamente, estás dejando tu destino a heurísticas del localizador de DC.
A veces tendrás suerte. Otras veces una sucursal en Singapur autenticará contra un DC en Virginia porque el cliente piensa que es “el más cercano”.
Esto es a la vez gracioso y caro.

Haz estas tres cosas o no te molestes

Crea un Sitio AD para cada ubicación conectada por VPN que tenga diferencias significativas de latencia/ancho de banda.
Mapea subredes IP al sitio correcto para que los clientes elijan DCs locales y la topología de replicación tenga sentido.
Configura enlaces de sitio y horarios de replicación si el enlace VPN está restringido o medido.

Replicación sobre VPN: estable gana a rápido

La replicación no es solo “abrir los puertos”. También se trata de evitar aleteos. Si tu VPN es inestable, la replicación hará cola.
Obtendrás riesgo de objetos persistentes, backlog de DFSR y rarezas que no aparecen inmediatamente.

La prioridad operativa: mantén el túnel estable, el tiempo estable, el DNS consistente y regula la replicación intencionalmente si es necesario.
“Dejarlo a su suerte” es cómo saturas un enlace y luego culpas a AD por las consecuencias.

SYSVOL, DFSR y GPO sobre VPN

Las Políticas de Grupo son donde “AD está arriba” se encuentra con “los usuarios están enojados”. El procesamiento de GPO depende de:
LDAP para metadatos de política y filtrado de seguridad, y acceso SMB a SYSVOL para los archivos reales de política.
Sobre VPN, SMB (445) y la salud de la replicación DFSR se vuelven críticos.

Patrones comunes de dolor de GPO sobre VPN

Inicio de sesión lento: el cliente espera lecturas de SYSVOL sobre enlaces de alta latencia.
GPO falla de forma intermitente: timeouts SMB por pérdida de paquetes o problemas MTU.
Nuevas políticas no se aplican: backlog de DFSR o fallos de replicación hacen que SYSVOL no sea consistente entre DCs.

Consejos con opinión

Para usuarios remotos con VPN inestable, favorece políticas que no requieran grandes lecturas de SYSVOL en el inicio de sesión.
Mantén SYSVOL ordenado. No lo trates como un recurso compartido para “scripts útiles”.
Si necesitas paquetes grandes, usa distribución de software adecuada, no SYSVOL como CDN no oficial.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los comandos que ejecutas cuando las cosas están en llamas. Cada tarea incluye: comando, salida representativa, qué significa y la decisión que tomas.
La mezcla de Windows y Linux es intencional—muchos gateways VPN y hosts de monitorización son Linux, y aún necesitas probar desde el camino que está fallando.

Tarea 1: Comprueba qué servidores DNS usa un cliente Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {10.20.0.10, 10.20.0.11}
Wi-Fi          {8.8.8.8}

Significado: Wi‑Fi está usando DNS público. Si el cliente VPN no anula el DNS en la interfaz activa, las búsquedas de AD pueden ir a público y fallar.
Decisión: Forzar DNS interno cuando la VPN esté conectada, o implementar NRPT/reenviadores condicionales para que las zonas AD se resuelvan internamente.

Tarea 2: Verificar resolución de registros SRV para controladores de dominio

cr0x@server:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com 10.20.0.10
Server:  dns01.corp.example.com
Address: 10.20.0.10

_ldap._tcp.dc._msdcs.corp.example.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc01.corp.example.com
_ldap._tcp.dc._msdcs.corp.example.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc02.corp.example.com

Significado: DNS puede encontrar DCs mediante registros SRV. Si esto falla, el descubrimiento de AD falla.
Decisión: Si devuelve NXDOMAIN/timeout, arregla la alcanzabilidad DNS o la replicación de la zona; no toques Kerberos todavía.

Tarea 3: Confirma que el DC resuelto es accesible sobre la VPN

cr0x@server:~$ ping -c 3 dc01.corp.example.com
PING dc01.corp.example.com (10.20.0.21) 56(84) bytes of data.
64 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.1 ms
64 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=41.8 ms
64 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.4 ms

--- dc01.corp.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 41.8/42.1/42.4/0.2 ms

Significado: La alcanzabilidad básica existe y el RTT es ~42ms. Eso es usable.
Decisión: Si ping falla, revisa enrutamiento VPN, ACLs y si ICMP está bloqueado (y prueba puertos TCP de todos modos).

Tarea 4: Probar puertos críticos hacia un DC desde un jump host Linux

cr0x@server:~$ nc -vz dc01.corp.example.com 53 88 135 389 445 464 3268
Connection to dc01.corp.example.com (10.20.0.21) 53 port [tcp/domain] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 88 port [tcp/kerberos] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 135 port [tcp/msrpc] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 389 port [tcp/ldap] succeeded!
nc: connect to dc01.corp.example.com (10.20.0.21) port 445 (tcp) failed: Operation timed out
Connection to dc01.corp.example.com (10.20.0.21) 464 port [tcp/kpasswd] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 3268 port [tcp/globalcatLDAP] succeeded!

Significado: SMB (445) está bloqueado o roto. Espera problemas con GPO/SYSVOL y unión a dominio.
Decisión: Arregla la ruta 445 a través de la VPN, o diseña explícitamente alrededor de ello (rara vez factible si quieres comportamiento normal de dominio Windows).

Tarea 5: Comprobar la salud del canal seguro de Windows

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "WIN11-042".
True

Significado: La confianza de la máquina con el dominio está intacta.
Decisión: Si es False, puede que necesites reparar el canal seguro (después de arreglar DNS/hora/puertos).

Tarea 6: Reparar un canal seguro roto (tras verificar conectividad)

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Repair -Credential (Get-Credential)"
PowerShell credential request
Enter your credentials.
User: CORP\adminuser
Password for user CORP\adminuser: ********

True

Significado: La contraseña de la cuenta de máquina fue reiniciada y la confianza restaurada.
Decisión: Si la reparación falla, vuelve a comprobar la desviación de hora y el acceso RPC/SMB; no sigas intentando hasta bloquear credenciales administrativas.

Tarea 7: Verificar el estado de sincronización de hora en Windows

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/28/2025 11:22:10 AM
Source: dc01.corp.example.com
Poll Interval: 6 (64s)

Significado: El cliente se sincroniza desde el dominio (bien).
Decisión: Si la fuente es “Local CMOS Clock” o un NTP público mientras está en VPN, arregla la configuración del servicio de hora y el DNS/enrutamiento de la VPN.

Tarea 8: Medir el desfase de hora desde un host Linux (chequeo rápido)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140015 (dc01.corp.example.com)
Stratum         : 4
Ref time (UTC)  : Sun Dec 28 11:22:15 2025
System time     : 0.000412345 seconds fast of NTP time
Last offset     : -0.000120113 seconds
RMS offset      : 0.000231009 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.120 ppm
Skew            : 0.210 ppm
Root delay      : 0.042123456 seconds
Root dispersion : 0.001234567 seconds

Significado: El desfase es submilisegundo. La hora no es tu problema.
Decisión: Si el desfase son segundos/minutos, arregla la ruta NTP antes de tocar Kerberos/GPO.

Tarea 9: Ver qué DC eligió realmente un cliente Windows

cr0x@server:~$ nltest /dsgetdc:corp.example.com
           DC: \\dc02.corp.example.com
      Address: \\10.20.0.22
     Dom Guid: 3d1d5d8a-1111-2222-3333-aaaaaaaaaaaa
     Dom Name: corp.example.com
  Forest Name: corp.example.com
 Dc Site Name: HQ
Our Site Name: BRANCH01
        Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE

Significado: El sitio del cliente es BRANCH01 pero eligió un DC en HQ; “CLOSE_SITE” sugiere que no encontró un DC local o el mapeo de subred está mal.
Decisión: Corrige el mapeo Sites/Subnets o asegúrate de que exista un DC/RODC en BRANCH01 si eso es lo previsto.

Tarea 10: Comprobar resumen de salud del controlador de dominio

cr0x@server:~$ dcdiag /s:dc01 /q
cr0x@server:~$ echo $?
0

Significado: Código de salida 0 implica que no hay problemas mayores en la ejecución silenciosa.
Decisión: Si aparecen errores (fallos en test de DNS, fallos de publicidad), arregla la salud del DC antes de culpar a la VPN.

Tarea 11: Comprobar estado de replicación AD entre DCs

cr0x@server:~$ repadmin /replsummary
Replication Summary Start Time: 2025-12-28 11:24:31

Beginning data collection for replication summary, this may take awhile:
  ......

Source DSA          largest delta    fails/total %%   error
 dc01                    00:05:12    0 / 20    0
 dc02                    00:06:01    2 / 20   10    (1722) The RPC server is unavailable.

Destination DSA     largest delta    fails/total %%   error
 dc01                    00:06:01    0 / 20    0
 dc02                    03:42:19    2 / 20   10    (1722) The RPC server is unavailable.

Significado: La replicación hacia/desde dc02 falla con RPC no disponible. Eso casi siempre es puertos, reglas de firewall o enrutamiento.
Decisión: Valida TCP 135 y el rango RPC dinámico entre DCs a través de la VPN; restringe el rango RPC si es necesario y permítelo.

Tarea 12: Inspeccionar el rango de puertos RPC dinámicos en Windows

cr0x@server:~$ netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

Significado: El rango dinámico moderno por defecto es 49152–65535. Si tu política VPN no lo permite, las operaciones basadas en RPC pueden fallar.
Decisión: Considera restringir el rango en los DCs a un bloque más pequeño y permitirlo a través de la VPN.

Tarea 13: Probar acceso SMB a SYSVOL desde un cliente Windows

cr0x@server:~$ powershell -NoProfile -Command "dir \\corp.example.com\SYSVOL | Select-Object -First 3"
    Directory: \\corp.example.com\SYSVOL

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          12/12/2025  10:10 AM                corp.example.com
d----          12/12/2025  10:10 AM                staging
d----          12/12/2025  10:10 AM                sysvol

Significado: SYSVOL es accesible y navegable. El acceso a archivos de GPO debería funcionar.
Decisión: Si esto cuelga o da error, arregla TCP 445, problemas MTU/MSS o resolución de nombres al DC que hospeda las referencias de SYSVOL.

Tarea 14: Forzar actualización de Políticas de Grupo y leer el resultado

cr0x@server:~$ gpupdate /force
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Significado: Al menos una pasada tuvo éxito. Si es lenta, aún podrías tener problemas de latencia/SMB.
Decisión: Si gpupdate falla con “cannot read gpt.ini,” céntrate en SYSVOL/SMB y salud de DFSR.

Tarea 15: Comprobar MTU efectiva en el camino (Linux)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.0.21
PING 10.20.0.21 (10.20.0.21) 1372(1400) bytes of data.
1380 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.5 ms
1380 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=42.0 ms
1380 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.2 ms

--- 10.20.0.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Significado: El camino soporta paquetes de 1400 bytes sin fragmentación. Eso es buena señal para muchas configuraciones VPN.
Decisión: Si aparece “Frag needed”, limita MSS en los bordes VPN o ajusta MTU; muchos problemas intermitentes de AD desaparecen después de esto.

Tarea 16: Validar el handshake LDAPS (si usas LDAPS)

cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=dc01.corp.example.com
Verification: OK

Significado: LDAPS es accesible y el certificado valida (desde el trust store de este host).
Decisión: Si esto falla, abre 636, arregla el certificado del DC, o deja de insistir en LDAPS para aplicaciones que no pueden alcanzarlo por VPN.

Tres mini-historias del mundo corporativo (lo que realmente pasa)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana adquirió una firma más pequeña y decidió “conectar temporalmente” las redes mediante VPN site‑to‑site. La suposición fue simple:
“Si podemos hacer ping al controlador de dominio, la unión al dominio funcionará.”

La primera semana pareció bien porque solo unas pocas laptops de TI estaban probando—y esas laptops tenían credenciales en caché y usaban DNS interno manualmente.
Luego desplegaron un lote de máquinas nuevas. La unión al dominio falló de forma intermitente. Algunas máquinas se unieron, otras no, y las que se unieron tardaron una eternidad en aplicar políticas.

El análisis posterior fue brutal en su simplicidad. La VPN no empujaba ninguna configuración DNS. Los clientes usaban cualquier DNS que tuvieran—por lo general el router de la sucursal reenviando al resolutor del ISP.
El resolutor del ISP, sorprendentemente, no alojaba _ldap._tcp.dc._msdcs para su zona privada de AD. Así que el proceso de unión recurría a descubrimiento lento y a veces equivocado.

La solución no fue heroica. Forzaron DNS interno sobre la VPN y añadieron reenviadores condicionales para la zona AD en el reenviador DNS de la sucursal.
Todo se estabilizó de inmediato. La lección: “ping funciona” es una prueba de ICMP, no una prueba de la infraestructura de identidad.

Mini-historia 2: La optimización que salió mal

Otra organización tenía un diseño AD sólido: DCs en cada sitio importante, Sites and Services configurado, replicación programada. Era aburrido.
Luego el equipo de red introdujo una “optimización de rendimiento” en el concentrador VPN: manejo UDP agresivo con una nueva política que priorizaba “tráfico importante”
y despriorizaba “tráfico a granel.” Adivina en qué cubo cayeron SMB y algunos flujos RPC.

Los síntomas fueron raros. La autenticación normalmente funcionaba, pero los scripts de inicio fallaban a veces. El procesamiento de Políticas de Grupo aleatoriamente tomaba minutos.
El backlog de DFSR empezó a crecer, pero no de forma uniforme—solo un enlace de sitio mostró retraso persistente.

Lo persiguieron como un “problema de replicación AD” durante demasiado tiempo. Cuando alguien finalmente graficó pérdida de paquetes en el túnel y la correlacionó con reintentos SMB,
el patrón fue obvio: el optimizador estaba descartando o retrasando segmentos bajo carga. Los clientes Windows luego martillaban el enlace con retransmisiones,
haciendo que la “optimización” estuviera aún más segura de que veía “tráfico a granel” y lo castigara más. Un bucle de retroalimentación, del mejor tipo.

La solución fue eliminar la política e implementar QoS simple que protegiera el túnel de la saturación en lugar de intentar engañar a TCP.
El rendimiento volvió y la replicación AD dejó de parecer que tenía depresión estacional.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía global tenía sitios de manufactura remotos conectados por VPN sobre circuitos last‑mile poco fiables. Sabían que los enlaces fallarían.
Así que hicieron tres cosas aburridas temprano: instalaron un RODC en cada sitio remoto, mapearon subredes a sitios correctamente, y establecieron una jerarquía de tiempo estricta
con el PDC emulator como fuente externa.

Meses después, una caída de ISP regional dejó fuera un conjunto de túneles por medio día. La gente esperaba caos de autenticación.
En cambio, los usuarios en las plantas siguieron iniciando sesión. Las credenciales en caché ayudaron, pero el verdadero héroe fue la autenticación local contra el RODC para muchas operaciones,
más la sincronización de hora consistente que evitó que Kerberos se fuera por la tangente cuando la conectividad regresó.

Cuando los túneles volvieron, la replicación se puso al día de forma controlada porque los enlaces de sitio y horarios estaban configurados para ancho de banda restringido.
Sin intervenciones manuales frenéticas. Sin “reiniciamos el DC por motivos desconocidos.” El incidente fue principalmente un problema de red, y se mantuvo como tal.

Así funciona la buena infraestructura: falla dentro de su propio radio de explosión. Aburrido es una característica.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: La unión al dominio falla con mensajes genéricos

Causa raíz: El cliente no puede resolver registros SRV de AD o está usando DNS público; o puertos SMB/RPC bloqueados.

Solución: Forzar DNS interno sobre VPN; verificar búsquedas SRV; asegurar 445/135 y el rango RPC; confirmar rutas del cliente hacia las subredes de los DC.

2) Síntoma: “La relación de confianza entre este equipo y el dominio primario falló”

Causa raíz: Canal seguro roto tras desajuste de contraseña de máquina, frecuentemente provocado por periodos offline largos y reconexiones inestables; a veces desviación de hora.

Solución: Arregla DNS/hora primero; luego Test-ComputerSecureChannel -Repair o vuelve a unir el equipo al dominio si hace falta; verifica alcanzabilidad DC y SMB/RPC.

3) Síntoma: Los usuarios pueden iniciar sesión, pero la Política de Grupo es lenta o falla

Causa raíz: SMB (445) degradado; SYSVOL inaccesible; backlog de DFSR; alta latencia y pérdida de paquetes.

Solución: Valida el acceso a \\domain\SYSVOL; arregla 445 y MTU/MSS; comprueba salud de DFSR; reduce el bloat de GPO.

4) Síntoma: Repetición de avisos de autenticación, o SSO falla mientras la contraseña funciona

Causa raíz: Desviación de hora Kerberos; cliente usando KDC equivocado por DNS o mal mapeo de sitios.

Solución: Hacer cumplir la jerarquía de tiempo del dominio; comprobar estado con w32tm; corregir Sites/Subnets para que los clientes elijan DCs locales.

5) Síntoma: Errores de replicación como “RPC server unavailable”

Causa raíz: TCP 135 o puertos RPC dinámicos bloqueados; enrutamiento asimétrico por split tunnels; interferencia NAT.

Solución: Permitir 135 y el rango dinámico; o restringir el rango RPC en los DCs y permitir ese rango. Valida con repadmin y pruebas de puertos.

6) Síntoma: Todo funciona hasta las horas pico, luego AD “se comporta mal”

Causa raíz: Saturación de VPN, colas, pérdida de paquetes; a veces dispositivos “optimizadores” dañando SMB/RPC.

Solución: Planificar capacidad del túnel; añadir QoS sensato; evitar optimizadores WAN intrusivos; medir RTT/pérdida y correlacionar con tiempos de auth/GPO.

7) Síntoma: Solo algunas subredes/usuarios fallan

Causa raíz: Sites/Subnets incompletos; rutas split tunneling faltantes; reenviadores condicionales aplicados solo a algunos clientes.

Solución: Auditar mapeos de subred; estandarizar perfiles VPN; asegurar que políticas DNS se apliquen de forma consistente entre tipos de clientes.

Listas de verificación / plan paso a paso (hazlo para que siga fijo)

Paso a paso: hacer que AD sobre VPN sea fiable

Inventaria tus DCs y roles. Saber dónde está el PDC emulator y qué DCs son GC.
Elige la estrategia DNS para clientes VPN. Forzar DNS interno al conectarse, o implementar DNS dividido correctamente.
Validar resolución SRV desde cada red remota. Hacerlo un chequeo de monitorización, no una prueba única.
Endurecer la jerarquía de tiempo. El PDC se sincroniza a externo; todos los demás al dominio. Verificar con w32tm y monitorización.
Definir puertos requeridos y estrategia RPC. Decidir si permitir el rango dinámico por defecto o restringirlo. Documentarlo y aplicarlo.
Arreglar MTU/MSS temprano. Configurar clamping MSS en los bordes VPN. Probar con pings “do not fragment” y respuestas DNS grandes.
Implementar mapeo Sitios/Subredes de AD. Cada subred remota debe mapearse a un sitio. Sin excepciones. Las excepciones se convierten en fallos.
Decidir DC local vs RODC para sitios remotos. Si el sitio debe funcionar durante caídas de túnel, instalar un RODC o DC local.
Planificar horarios de replicación para enlaces restringidos. No satures el túnel con replicación durante horas laborales.
Probar GPO y acceso a SYSVOL. Validar periódicamente reachabilidad SMB y salud de DFSR.
Crear una prueba sintética de “inicio de sesión remoto”. Desde un host en la red remota, comprobar periódicamente SRV DNS, Kerberos, LDAP, SMB.
Escribir el plan de rollback. Si un cambio en la VPN rompe AD, necesitas una ruta rápida de reversión. “Depuraremos en vivo” no es un plan.

Lista operativa: antes de culpar a AD

¿Túnel VPN estable? Sin aleteos, sin rekeys frecuentes que causen caídas?
¿Enrutamiento simétrico? Sin rarezas de split tunnel donde las peticiones van por un lado y las respuestas regresan por otro?
¿DNS consistente? ¿Los clientes usan resolutores internos y pueden resolver registros SRV?
¿Hora estable? ¿Clientes y DCs dentro de 5 minutos, idealmente dentro de segundos?
¿Puertos verificados? ¿53/88/389/445/135 + rango RPC accesibles?
¿Latencia aceptable? Si RTT > ~150ms y pérdida > ~0.5%, espera problemas sin rediseño.

FAQ (las preguntas que la gente hace justo después de que se rompe)

1) ¿Puede Active Directory funcionar sobre una VPN en absoluto?

Sí. Funciona todos los días en empresas reales. Pero requiere DNS disciplinado, jerarquía de tiempo, política de puertos correcta (incluida estrategia RPC),
y Sitios/Subredes de AD que reflejen la topología de la VPN.

2) ¿Qué falla primero en la práctica: DNS, hora o puertos?

DNS. Casi siempre DNS. La hora es lo segundo. Los puertos son lo tercero. La latencia es el problema de combustión lenta que te hace pensar que AD es inestable cuando es el enlace.

3) ¿De verdad necesitamos SMB (445) a través de la VPN?

Si quieres comportamiento normal de dominio: sí. SYSVOL y muchos flujos de inicio de sesión/GPO dependen de SMB.
Puedes reducir la dependencia (por ejemplo, minimizar scripts y archivos de política grandes), pero bloquear 445 suele convertirse en disfunción de identidad autoinfligida.

4) ¿Podemos “simplemente usar LDAPS” y cerrar LDAP 389?

Algunos entornos pueden, pero no es una sustitución universal. Operaciones de dominio, apps heredadas y ciertos mecanismos de descubrimiento pueden seguir usando 389.
Si aplicas LDAPS, hazlo como proyecto planificado con inventario de apps y ciclo de vida de certificados, no como un cambio de firewall un viernes.

5) ¿Deberíamos aumentar el desfase de reloj permitido de Kerberos para evitar fallos?

No. Arregla la sincronización de tiempo. Aumentar el desfase es como aflojar las tuercas porque la rueda sigue vibrando.
El coste de seguridad es real, y aún tendrás rarezas porque otras partes del sistema asumen coherencia temporal.

6) ¿Es compatible el split tunneling con AD?

Puede serlo, pero complica las cosas. Debes asegurar que las consultas DNS para zonas AD vayan a resolutores internos y que existan rutas hacia DCs, SYSVOL y servicios requeridos.
El split tunneling sin disciplina DNS/enrutamiento es una forma fiable de crear tickets de “funciona a veces”.

7) ¿Necesitamos un RODC en cada sitio remoto?

Si el sitio debe seguir autenticando cuando el túnel cae, sí—considerarlo fuertemente.
Si el sitio puede tolerar dependencia de la VPN y usar credenciales en caché, quizá no. Pero sé honesto sobre los requisitos del negocio, no esperanzado.

8) ¿Por qué la replicación AD se queja de RPC cuando DNS parece estar bien?

DNS te lleva al DC. RPC necesita TCP 135 y luego puertos dinámicos. Si esos puertos dinámicos no están permitidos, la replicación falla con “RPC server unavailable.”
Por eso la política de puertos debe incluir una estrategia para RPC dinámico.

9) ¿Cuál es la forma más rápida de demostrar que es un problema MTU?

Usa pings “do not fragment” con tamaño cercano al MTU sospechado y observa fallos, luego compara comportamiento con y sin clamping MSS.
Los problemas MTU suelen aparecer como rarezas intermitentes en SMB y DNS más que como eventos claros de “caída”.

10) ¿Cómo monitorizamos esto para no enterarnos por el CEO?

Ejecuta pruebas sintéticas desde cada red remota: búsqueda SRV, alcanzabilidad Kerberos, bind LDAP (si procede), listado SMB de SYSVOL y un resumen de replicación en los DCs.
Alerta ante fallos y ante umbrales de latencia/pérdida. El mejor incidente es el que arreglaste en silencio antes de que alguien lo nombrara.

Siguientes pasos (prácticos)

Si solo haces tres cosas esta semana: fuerza el DNS correcto sobre la VPN, aplica una jerarquía de tiempo sensata del dominio y deja explícita y testeable tu política de puertos/RPC.
Luego haz el trabajo de adulto: mapea Sitios/Subredes adecuadamente y decide dónde necesitas DCs locales/RODCs.

Una idea parafraseada frecuentemente atribuida a voces de ingeniería de fiabilidad como John Allspaw: Los sistemas fallan de maneras predecibles; tu trabajo es hacer esas fallas visibles y recuperables.
Ese es el juego aquí. AD sobre VPN no es magia. Es plomería. Haz la plomería bien y seguirá siendo aburrida.