Cuando Usuarios y equipos de Active Directory tarda mucho en abrirse o muestra «No responde» al consultar las propiedades de un usuario, el problema puede estar en la configuración DNS del servidor.
En este caso, la consola estaba instalada, el servicio LDAP respondía y Kerberos obtenía los tickets correctamente. Sin embargo, las consultas LDAP por nombre tardaban entre 22 y 44 segundos.
La mejora se produjo al corregir los servidores DNS configurados en las interfaces de red. Después del último cambio, la consulta respondió en 0,03 segundos y la consola volvió a funcionar con normalidad, sin reiniciar el servidor.
Entorno del ejemplo
Todos los nombres y direcciones internos de este artículo son ficticios.
| Elemento | Valor de ejemplo |
|---|---|
| Sistema operativo | Windows Server 2025 |
| Dominio de Active Directory | ad.example.test |
| Controlador de dominio | DC01.ad.example.test |
| IP del servidor DNS interno | 192.168.50.10 |
| Router | 192.168.50.1 |
| Interfaces principales | Ethernet y Wi-Fi |
| Otras interfaces | Adaptadores de VPN |
Antes de ejecutar los comandos, sustituye estos valores por los de tu entorno. Las consultas se realizan desde PowerShell; los cambios de configuración requieren permisos de administrador.
Síntomas
El comportamiento observado era el siguiente:
- Ejecutar
dsa.mscno mostraba inmediatamente la consola. - Una consola MMC vacía sí se abría.
- El complemento de Active Directory podía añadirse, pero se bloqueaba al desplegar el dominio.
- Cuando finalmente se abría, consultar las propiedades de un usuario volvía a dejarlo en «No responde».
1. Comprobar que la herramienta está instalada
La primera comprobación fue verificar la instalación de las herramientas de administración:
Get-WindowsFeature -Name RSAT-ADDS-Tools |
Format-List DisplayName, Name, InstallStateEl resultado mostraba:
InstallState : InstalledPor tanto, no era necesario reinstalar el complemento.
Para comprobar MMC por separado:
Start-Process -FilePath "$env:SystemRoot\System32\mmc.exe"La ventana vacía se abría correctamente. Esto orientaba el diagnóstico hacia la carga del complemento o la comunicación con Active Directory.
2. Revisar las interfaces y sus servidores DNS
En un servidor con varias interfaces, conviene revisar todas, incluidas Wi-Fi y VPN.
Para consultar las direcciones:
Get-NetIPAddress |
Where-Object { $_.IPAddress -notmatch '^(127\.|::1$|fe80:)' } |
Sort-Object InterfaceAlias, AddressFamily |
Format-Table InterfaceAlias, InterfaceIndex,
AddressFamily, IPAddress, AddressState -AutoSizePara consultar los servidores DNS:
Get-DnsClientServerAddress |
Format-Table InterfaceAlias, AddressFamily,
ServerAddresses -AutoSizeLa configuración relevante era:
| Interfaz | DNS IPv4 configurado |
|---|---|
| Ethernet | 8.8.8.8 y 8.8.4.4 |
| Wi-Fi | 192.168.50.1 |
Ethernet utilizaba DNS públicos y Wi-Fi consultaba al router.
Los equipos de Active Directory necesitan utilizar servidores DNS que resuelvan los registros internos del dominio. Los DNS públicos no deben configurarse como alternativa en sus adaptadores para resolver ese dominio. La resolución de Internet puede gestionarse mediante reenviadores en el servidor DNS interno.
3. Comprobar el DNS interno antes de cambiar nada
Antes de configurar las interfaces para utilizar el DNS del servidor, comprobamos que respondía y conocía los registros de Active Directory:
Resolve-DnsName `
-Name '_ldap._tcp.dc._msdcs.ad.example.test' `
-Type SRV `
-Server '192.168.50.10' `
-DnsOnlyLa respuesta identificaba al controlador de dominio y el puerto LDAP 389.
También comprobamos su localización:
nltest /dsgetdc:ad.example.test /forceSi estas pruebas fallan, no apliques los cambios de este artículo sin investigar primero el estado del DNS interno.
4. Comparar LDAP por IP y por nombre
Primero verificamos la conexión TCP al puerto LDAP:
Test-NetConnection `
-ComputerName '192.168.50.10' `
-Port 389 `
-InformationLevel DetailedEl resultado era:
TcpTestSucceeded : TrueEsto confirma la conexión al puerto, pero no garantiza que una consulta de Active Directory responda con rapidez.
Para medir una lectura LDAP por IP:
$ldap = New-Object System.DirectoryServices.DirectoryEntry(
'LDAP://192.168.50.10/RootDSE'
)
try {
$tiempo = Measure-Command {
$ldap.RefreshCache(@('defaultNamingContext'))
}
[pscustomobject]@{
DominioLDAP = [string]$ldap.Properties['defaultNamingContext'][0]
Segundos = [math]::Round($tiempo.TotalSeconds, 2)
}
}
finally {
$ldap.Dispose()
}Después repetimos la misma consulta por nombre:
$ldap = New-Object System.DirectoryServices.DirectoryEntry(
'LDAP://DC01.ad.example.test/RootDSE'
)
try {
$tiempo = Measure-Command {
$ldap.RefreshCache(@('defaultNamingContext'))
}
[pscustomobject]@{
DominioLDAP = [string]$ldap.Properties['defaultNamingContext'][0]
Segundos = [math]::Round($tiempo.TotalSeconds, 2)
}
}
finally {
$ldap.Dispose()
}La diferencia era considerable:
| Prueba | Tiempo observado |
|---|---|
| Consulta LDAP por IP | 0,05 segundos |
| Consulta LDAP por nombre completo | Entre 22 y 44 segundos |
| Consulta LDAP por nombre corto | Aproximadamente 31 segundos |
Estas pruebas no modifican objetos de Active Directory.
5. Pruebas que ayudaron a acotar el problema
La resolución del nombre mediante .NET fue inmediata:
$tiempo = Measure-Command {
[System.Net.Dns]::GetHostAddresses(
'DC01.ad.example.test'
) | Out-Host
}
$tiempo | Select-Object TotalSecondsLa obtención de un ticket Kerberos para LDAP también fue rápida:
Measure-Command {
klist get ldap/DC01.ad.example.test | Out-Host
} | Select-Object TotalSecondsEsta última prueba solicita un ticket para la sesión actual; no elimina los existentes.
Además, la consulta LDAP por nombre respondió rápidamente al indicar explícitamente ServerBind:
$ldap = New-Object System.DirectoryServices.DirectoryEntry
$ldap.Path = 'LDAP://DC01.ad.example.test/RootDSE'
$ldap.AuthenticationType = (
[System.DirectoryServices.AuthenticationTypes]::Secure -bor
[System.DirectoryServices.AuthenticationTypes]::ServerBind
)
try {
$tiempo = Measure-Command {
$ldap.RefreshCache(@('defaultNamingContext'))
}
[pscustomobject]@{
DominioLDAP = [string]$ldap.Properties['defaultNamingContext'][0]
Segundos = [math]::Round($tiempo.TotalSeconds, 2)
}
}
finally {
$ldap.Dispose()
}El resultado fue de unos 0,02 segundos.
Esto orientó el diagnóstico hacia operaciones adicionales del acceso LDAP por nombre. No demostraba por sí solo el mecanismo exacto del bloqueo, ni constituía una reparación de la consola.
6. Corregir el DNS de las interfaces
Una vez comprobado que el DNS interno respondía correctamente, configuramos Ethernet:
Set-DnsClientServerAddress `
-InterfaceAlias 'Ethernet' `
-ServerAddresses '192.168.50.10' `
-PassThruDespués de este cambio, la consola seguía presentando bloqueos.
Wi-Fi todavía utilizaba el router como DNS. Se corrigió también:
Set-DnsClientServerAddress `
-InterfaceAlias 'Wi-Fi' `
-ServerAddresses '192.168.50.10' `
-PassThruEstos comandos cambian los servidores DNS del adaptador. No cambian su dirección IP ni desactivan la interfaz.
La configuración debe adaptarse a cada infraestructura. Si existen varios servidores DNS internos que alojan el dominio, utiliza los que correspondan a tu diseño; no copies una configuración de un único servidor sin comprobarlo.
7. Validar la solución
Tras modificar el DNS de Wi-Fi, repetimos la consulta LDAP por nombre sin ServerBind.
El tiempo pasó a:
Segundos
--------
0,03Después abrimos una ventana nueva de la consola:
dsa.mscSe comprobó que:
- La consola se abría con normalidad.
- El dominio podía desplegarse.
- Las propiedades de los usuarios se mostraban sin bloqueos.
No fue necesario reiniciar el servidor, reinstalar las herramientas ni desactivar las VPN o IPv6.
Qué cambio produjo la mejora
La última modificación antes de observar la recuperación fue cambiar el DNS IPv4 de Wi-Fi, pasando del router al DNS interno del dominio. Ethernet ya se había corregido previamente.
La consulta LDAP y el funcionamiento de la consola se validaron después del cambio. Esto aporta evidencia sólida de que la configuración DNS de las interfaces estaba relacionada con el problema.
No se realizó una captura de tráfico ni se revirtió la configuración para reproducir el fallo, por lo que no se determinó el mecanismo exacto de cada espera.
Cómo revertir los cambios
Antes de modificar DNS, anota siempre la configuración original y si se recibe automáticamente o se introduce de forma manual.
En el ejemplo, si fuera necesario restaurar los valores anteriores:
Set-DnsClientServerAddress `
-InterfaceAlias 'Ethernet' `
-ServerAddresses '8.8.8.8','8.8.4.4'Set-DnsClientServerAddress `
-InterfaceAlias 'Wi-Fi' `
-ServerAddresses '192.168.50.1'Estos comandos representan una reversión, no la configuración recomendada para el controlador de dominio.
Qué revisar si te ocurre algo parecido
Si LDAP responde rápidamente por IP pero tarda mucho por nombre, revisa los servidores DNS de todas las interfaces activas. Corregir únicamente Ethernet puede dejar otra interfaz consultando un DNS que no conoce el dominio.
No elimines registros DNS ni desactives adaptadores solo porque aparezcan varias direcciones. Comprueba primero qué interfaz utiliza cada dirección y valida cada cambio por separado.
