No se pudo contactar con el controlador de dominio de AD

Intentas unir un equipo a un dominio de Active Directory y Windows responde con un mensaje que lo detiene todo: «No se pudo contactar con un controlador de dominio de Active Directory (AD DC) para el dominio ‘empresa.local'». A veces va seguido de explicaciones como «el dominio especificado no existe o no se pudo contactar con él». El mensaje es genérico, pero la causa casi siempre está en el mismo sitio: el equipo no consigue localizar un controlador de dominio (por DNS) o no consigue hablar con él (por red). En esta guía verás un método ordenado para diagnosticarlo, con los comandos para cada paso, desde el lado del cliente y desde el del servidor.

Cómo encuentra Windows un controlador de dominio

Para entender el error conviene saber qué ocurre al pulsar «Aceptar» al unir un equipo al dominio. Windows no tiene una lista de controladores de dominio: los busca usando el DNS. Pregunta al servidor DNS configurado en la tarjeta de red por unos registros especiales (registros SRV) del tipo _ldap._tcp.dc._msdcs.empresa.local, que cada controlador de dominio publica al arrancar. Con esa lista, el equipo prueba a conectarse con ellos por varios puertos (LDAP, Kerberos, RPC, SMB). Si el DNS no sabe responder, o si la conexión no llega, aparece el error.

Paso 1: usa el nombre DNS completo del dominio

Si has escrito el nombre corto (el NetBIOS, por ejemplo EMPRESA) en lugar del completo (empresa.local), prueba con el nombre DNS. La resolución de nombres cortos depende de servicios heredados que suelen estar deshabilitados o no funcionar entre subredes. Es el cambio más sencillo y a veces ya lo resuelve.

Paso 2: revisa el DNS del equipo (la causa más frecuente)

El equipo debe usar como servidor DNS un controlador de dominio o un servidor DNS interno que sepa resolver el dominio. Si tiene configurado solo el DNS del router, el de tu proveedor o uno público (como el de Google o Cloudflare), no encontrará nunca los registros del dominio. Compruébalo:

# ¿Qué DNS usa este equipo?
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

# ¿Resuelve el nombre del dominio?
Resolve-DnsName empresa.local

# ¿Resuelve los registros de los controladores de dominio?
nslookup -type=SRV _ldap._tcp.dc._msdcs.empresa.local

# ¿Qué controlador de dominio localiza Windows?
nltest /dsgetdc:empresa.local

Si nslookup falla o devuelve la dirección de un servidor que no es tu controlador de dominio, cambia el DNS de la tarjeta de red por el del controlador. No dejes un DNS público como secundario: Windows alterna entre ambos y, cuando consulta el público, no encuentra el dominio y el error aparece de forma intermitente. Después ejecuta ipconfig /flushdns y repite las pruebas.

Si usas una VPN, comprueba que el cliente VPN entrega el DNS corporativo; los equipos conectados desde casa fallan a menudo por esta razón.

Paso 3: comprueba la conectividad con el controlador de dominio

Aunque el DNS responda, el equipo debe alcanzar los puertos que usa Active Directory. Prueba los principales con PowerShell:

$dc = 'dc01.empresa.local'
53, 88, 135, 389, 445, 464, 3268 | ForEach-Object {
    $r = Test-NetConnection $dc -Port $_ -WarningAction SilentlyContinue
    [pscustomobject]@{ Puerto = $_; Abierto = $r.TcpTestSucceeded }
}

Si tienes que comprobar varios equipos o varios controladores, recorre una lista con un bucle (te lo explicamos en la guía de bucles en PowerShell) y guarda el resultado en un archivo para compararlo después.

Los puertos significan: 53 (DNS), 88 (Kerberos), 135 (asignador de extremos de RPC), 389 (LDAP), 445 (SMB), 464 (cambio de contraseña de Kerberos) y 3268 (catálogo global). Además, RPC usa un intervalo dinámico de puertos (49152-65535 en las versiones actuales de Windows) que también debe estar permitido entre el equipo y el controlador. Si algún puerto está cerrado, revisa el cortafuegos de Windows del controlador, los cortafuegos de red y las reglas entre VLAN o sedes. Si el equipo está en una red de invitados o aislada, la conexión al dominio no es posible hasta que esté en la red correcta.

Tampoco te fíes únicamente del ping: algunos cortafuegos bloquean ICMP y el controlador funciona perfectamente. Las pruebas de puerto son más fiables. Si necesitas repasar el uso de este cmdlet, tienes más ejemplos en la guía de 10 comandos de PowerShell imprescindibles.

Paso 4: comprueba la hora

La autenticación Kerberos tolera como máximo cinco minutos de diferencia entre el equipo y el controlador. Si el reloj de tu equipo está desajustado (una batería de CMOS agotada, una máquina virtual restaurada), falla la autenticación y a veces el síntoma es este mismo error. Ajusta la fecha, la hora y la zona horaria y vuelve a intentarlo. Puedes consultar la diferencia con el controlador con w32tm /stripchart /computer:dc01.empresa.local /samples:3 /dataonly.

Paso 5: revisa el registro de la unión al dominio

Windows anota todo el proceso en un archivo de texto muy útil: C:\Windows\debug\NetSetup.log. Ábrelo y busca las últimas líneas con NetpDsGetDcName, DsGetDcName o los códigos de error. Te dirá si falló la resolución de DNS (status 0x54b, dominio no encontrado), la conexión o la autenticación, lo que te señala qué paso repasar:

Select-String -Path C:\Windows\debug\NetSetup.log -Pattern 'DsGetDcName|NetpDsGetDcName|error|0x' | Select-Object -Last 25 | ForEach-Object { $_.Line }

Paso 6: revisa el lado del controlador de dominio

Si el problema afecta a varios equipos a la vez, no es el cliente: es el servidor. Comprueba en el controlador:

# Estado de los servicios clave
Get-Service NTDS, DNS, Netlogon, KDC | Select-Object Name, Status

# Diagnóstico general (solo errores)
dcdiag /q

# Diagnóstico específico de DNS
dcdiag /test:dns /v

# Volver a registrar los registros DNS del controlador
ipconfig /registerdns
nltest /dsregdns

Registros SRV ausentes: la zona _msdcs debe contener los registros del controlador. Si faltan, reinicia el servicio Inicio de sesión de red (Restart-Service Netlogon) y vuelve a registrar el DNS.
DNS del propio controlador mal configurado: un controlador debería usar su propio DNS (o el de otro controlador del dominio) como servidor principal, y nunca uno externo. Un DNS erróneo impide que se registre correctamente.
Rol de DNS caído o zona dañada: revisa el servicio y el visor de eventos (Servidor DNS y Servicio de directorio).

Paso 7: otras causas que se pasan por alto

Edición de Windows: las ediciones Home no pueden unirse a un dominio. Comprueba la edición con winver.
Perfil de red público: si la red está clasificada como pública, el cortafuegos puede bloquear tráfico necesario. Cámbiala a privada mientras unes el equipo.
Varias tarjetas de red: el equipo puede estar usando una interfaz que no llega a la red del dominio. Desactiva temporalmente las que no sean necesarias o ajusta la métrica.
Cuenta con permisos: el usuario con el que se une el equipo debe tener derecho a agregar equipos al dominio (por defecto, los usuarios autenticados pueden unir hasta diez equipos). Si es el permiso el que falla, el mensaje suele ser otro, pero conviene descartarlo.
Nombre del equipo duplicado o ya existente: si hay una cuenta de equipo con el mismo nombre, la unión puede fallar. Cámbiale el nombre o elimina la cuenta antigua.

Unir el equipo con PowerShell indicando el servidor

Cuando la localización automática falla pero sabes que un controlador concreto funciona, puedes indicarlo explícitamente:

Add-Computer -DomainName 'empresa.local' -Server 'dc01.empresa.local' -Credential (Get-Credential) -OUPath 'OU=Equipos,DC=empresa,DC=local' -Restart

Si lo consigues así pero no con la interfaz gráfica, el problema está en la localización (DNS), no en la conexión con ese controlador. Una vez que el equipo esté en el dominio, aprende a gestionar sus usuarios y grupos con la guía de crear usuarios y grupos en Active Directory.

Lista de comprobación rápida

Nombre DNS completo del dominio, no el NetBIOS.
DNS del equipo apuntando solo al controlador (o DNS interno).
nslookup -type=SRV _ldap._tcp.dc._msdcs.dominio devuelve registros.
nltest /dsgetdc:dominio localiza un controlador.
Puertos 53, 88, 135, 389, 445, 464 abiertos hacia el controlador.
Hora correcta (diferencia menor de cinco minutos).
Edición Pro o superior y red correcta (no invitados).
Revisión de NetSetup.log y de dcdiag en el servidor.

Preguntas frecuentes

¿Puedo usar la dirección IP del controlador en lugar del nombre?

Para unir un equipo, Windows necesita el nombre del dominio. Usar la IP como DNS (en la tarjeta de red) sí es válido; usarla como nombre de dominio en el cuadro de unión no suele funcionar y evita Kerberos.

El equipo ya estaba en el dominio y ahora da este error al iniciar sesión

Es otro caso: si ya pertenecía al dominio, el síntoma suele ser un problema de relación de confianza o de conectividad con los controladores. Puedes iniciar sesión con credenciales en caché o con una cuenta local de recurso, y comprobar el canal seguro con Test-ComputerSecureChannel.

¿Importa que el dominio termine en .local?

Los dominios .local funcionan, pero pueden entrar en conflicto con servicios de resolución multidifusión (mDNS) en algunos equipos y con Microsoft 365. No es la causa habitual de este error, pero si los síntomas son intermitentes, revísalo.

Conclusión

Cuando Windows dice que no puede contactar con un controlador de dominio, casi nunca es un problema del controlador: es DNS. Comprueba que el equipo usa un DNS que conoce el dominio, que nslookup devuelve los registros SRV, que los puertos de Active Directory están abiertos y que la hora es correcta. Si todo eso está bien, revisa NetSetup.log y la salud del controlador con dcdiag, y no olvides que puedes indicar el servidor explícitamente con Add-Computer -Server.

No se pudo contactar con el controlador de dominio de Active Directory