Windows 10 no inicia sesión en Active Directory: cómo encontrar el fallo

Comprueba si el equipo está unido al dominio y sigue el diagnóstico de DNS, VMware, Kerberos, cuentas y GPO con un caso de laboratorio.

El nombre de usuario o la contraseña no son correctos. Inténtalo de nuevo.

Ese era el mensaje de Windows 10 en una práctica de Active Directory. El cliente llegó a encontrar el controlador de dominio y en el servidor aparecía un evento Kerberos correcto. La comprobación decisiva la hicimos en el propio cliente. Seguía en WORKGROUP y PartOfDomain devolvía False.

Si estás en la misma situación, empieza por comprobar la pertenencia del equipo. Según el resultado, podrás distinguir un problema de unión al dominio de un fallo que afecta al usuario.

1. Comprueba si Windows 10 está unido al dominio

En Windows PowerShell, en el equipo cliente

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

Resultado del caso, transcrito del material del laboratorio

Name        Domain     PartOfDomain
EQUIPO0301  WORKGROUP  False
ResultadoQué comprobar a continuación
FalseEl equipo está en un grupo de trabajo. Comprueba red y DNS antes de incorporarlo a Active Directory.
True y el dominio esperadoSi falla un único usuario, revisa la cuenta y sus derechos. Si fallan varias cuentas de dominio en ese equipo, comprueba también el canal seguro.
True y otro dominioIdentifica a qué dominio pertenece el equipo y consulta al administrador antes de cambiarlo.

Descubrir un controlador, unir el equipo e iniciar sesión con una cuenta del dominio son tres operaciones distintas. El comando anterior consulta la pertenencia del equipo. Más adelante, whoami permite comprobar con qué cuenta ha iniciado sesión el usuario. Propiedades de Win32_ComputerSystem · Diagnóstico de unión al dominio

Para la unión tradicional a Active Directory necesitas una edición compatible, como Windows 10 Pro, Enterprise o Education. Windows 10 Home carece de esta función. El soporte general de Windows 10 22H2 terminó en octubre de 2025. Las comprobaciones de red y pertenencia también sirven para clientes Windows 11 compatibles. Unir un equipo a un dominio · Ciclo de vida de Windows 10

2. Comprueba la red de VMware y el DNS de Active Directory

El caso original se desarrolló con Windows Server 2022 y Windows 10 en VMware Workstation. En esta edición uso dominio03.test como nombre de ejemplo. Sustituye los nombres y direcciones por los de tu laboratorio o instalación.

ElementoConfiguración de ejemplo
Controlador de dominio y DNSW22SERVER03.dominio03.test
Dominio DNS y nombre cortodominio03.test y DOMINIO03
Red internaVMnet1 en modo Host-only, 172.16.5.0/24
Interfaz LAN del servidor172.16.5.100
Interfaz del servidor en la red NAT192.168.25.129
Cliente Windows 10EQUIPO0301, IP 172.16.5.102 y DNS 172.16.5.100
Usuario de prácticaalumno01

Comprueba que cliente y servidor comparten la red interna

En el cliente

ipconfig /all
ping 172.16.5.100
arp -a

Revisa la IP, la máscara, el adaptador activo y los servidores DNS. En VMware, abre los ajustes de las dos máquinas y confirma que ambas interfaces internas están conectadas a la misma red virtual. En el editor de redes virtuales, comprueba la subred y quién entrega las direcciones por DHCP. En el caso, VMnet1 figuraba con un rango distinto del que se había configurado en las máquinas. En modo Host-only el cliente puede comunicarse con el controlador sin salida a Internet.

Una respuesta a ping confirma conectividad ICMP. Si falla, comprueba la red virtual, el direccionamiento y si el firewall permite ICMP. En la misma subred, una entrada ARP para el controlador ayuda a verificar que se ha resuelto su dirección MAC. Editor de redes virtuales de VMware

Comprueba el registro SRV y el error 1355

En el cliente

nslookup W22SERVER03.dominio03.test 172.16.5.100
nslookup -type=SRV _ldap._tcp.dc._msdcs.dominio03.test 172.16.5.100
nltest /dsgetdc:dominio03.test /force
  1. La primera consulta debe devolver una dirección del controlador que el cliente pueda alcanzar.
  2. El registro SRV anuncia el servicio LDAP de uno o más controladores. En este laboratorio debe aparecer el nombre del servidor y el puerto 389.
  3. nltest fuerza un descubrimiento. Si devuelve 1355 o 0x54B (ERROR_NO_SUCH_DOMAIN), comprueba el nombre DNS, la red, los registros SRV y la disponibilidad del controlador.

Las consultas nslookup que indican 172.16.5.100 prueban ese servidor de forma explícita. Comprueba también en ipconfig /all que Windows está usando un DNS que conoce el dominio. Si nslookup muestra Servidor: Unknown y devuelve los registros correctos, revisa si falta el PTR del servidor. La resolución inversa y los registros del dominio se comprueban por separado. Error 1355 al unir un equipo

Si el controlador anuncia una IP que el cliente no puede alcanzar

En el laboratorio, el DNS devolvía tanto la IP interna como la IP NAT del servidor. El cliente podía llegar a 172.16.5.100. La otra dirección correspondía a un segmento distinto.

En Windows Server, un administrador puede revisar la interfaz, el servicio DNS y el registro A.

  1. En ncpa.cpl, revisa IPv4 → Opciones avanzadas → DNS de la interfaz NAT. Si esa dirección se destina exclusivamente a otra red y no debe anunciarse a los clientes, desmarca Registrar en DNS las direcciones de esta conexión.
  2. En el Administrador DNS, revisa Propiedades del servidor → Interfaces y la pestaña Servidores de nombres de la zona. Confirma qué interfaces prestan servicio a cada segmento antes de aplicar cambios.
  3. En la zona directa, identifica el registro A incorrecto y retira solo ese registro cuando hayas comprobado que ninguna red de clientes lo necesita. Si vuelve a aparecer, identifica qué servicio lo registra.

De vuelta en el cliente, abre PowerShell como administrador, vacía la caché y repite las consultas. Comprueba también el registro SRV.

ipconfig /flushdns
nslookup dominio03.test 172.16.5.100
nslookup W22SERVER03.dominio03.test 172.16.5.100

Vaciar la caché afecta al cliente. El registro que origina el problema se corrige en DNS. Microsoft Learn sobre controladores con varias interfaces

3. Interpreta el error RPC 1722 y comprueba los relojes

El código 1722 o 0x6BA indica que el servicio RPC requerido no estaba accesible. Repite primero el descubrimiento y comprueba que el nombre del controlador resuelve a la dirección correcta. Después, desde el cliente, prueba los puntos de entrada usados en el caso.

Test-NetConnection W22SERVER03.dominio03.test -Port 135
Test-NetConnection W22SERVER03.dominio03.test -Port 389
Test-NetConnection W22SERVER03.dominio03.test -Port 445

TcpTestSucceeded : True confirma una conexión TCP a ese puerto. Para diagnosticar una unión hay que considerar además los servicios que intervienen en cada etapa. El puerto 135 localiza el extremo de RPC, que puede atender la operación en otro puerto.

ServicioPuertos habituales en este diagnóstico
DNSTCP/UDP 53
KerberosTCP/UDP 88
LDAPTCP/UDP 389
SMBTCP 445
RPCTCP 135 y puertos dinámicos según configuración. En Windows moderno, el rango predeterminado es TCP 49152–65535.
Cambio de contraseña KerberosTCP/UDP 464
Hora de WindowsUDP 123

La tabla sirve para interpretar pruebas. El administrador debe consultar las reglas entre cliente y controlador según la operación y la topología. Test-NetConnection -Port comprueba TCP. Error RPC 1722 en la unión · Puertos de Active Directory

Revisa hora, zona y origen de sincronización

En el cliente y en el controlador

Get-Date -Format o
tzutil /g
w32tm /query /status

Compara la hora efectiva teniendo en cuenta el desplazamiento respecto a UTC. Dos equipos con zonas horarias distintas pueden estar sincronizados. El valor predeterminado de tolerancia de Kerberos en el dominio es cinco minutos. Si aparece Local CMOS Clock, revisa la hora y el origen configurado.

Si el cliente ya pertenece al dominio y el administrador confirma que debe recuperar la jerarquía horaria del dominio, puede hacerlo desde una consola elevada. La resincronización requiere que el origen sea alcanzable.

w32tm /config /syncfromflags:domhier /update
w32tm /resync

Cuando el problema se repite en varios clientes, revisa el origen de tiempo del dominio y el controlador con el rol PDC Emulator. Herramientas del servicio de hora · Tolerancia de reloj de Kerberos

4. Une el equipo al dominio y consulta NetSetup.log si falla

Haz la unión al dominio cuando PartOfDomain sea False y el cliente ya localice el controlador.

  1. En el cliente, abre sysdm.cpl con Windows + R.
  2. En Nombre de equipo → Cambiar, elige Dominio y escribe el nombre DNS, por ejemplo dominio03.test.
  3. Utiliza una cuenta del dominio autorizada para incorporar el equipo. También necesitas permisos administrativos en el cliente para iniciar la operación.
  4. Tras el mensaje de incorporación, reinicia el cliente. Vuelve a ejecutar el comando de pertenencia y comprueba PartOfDomain=True.
  5. En Otro usuario, utiliza DOMINIO03\alumno01 o el UPN configurado para el usuario, por ejemplo alumno01@dominio03.test. Ya dentro, ejecuta whoami y comprueba la identidad de la sesión.

Una cuenta escrita como .\Carlos se refiere al propio equipo. La cuenta autorizada para unir el cliente y la cuenta del alumno cumplen funciones distintas. En un dominio administrado, usa la delegación aprobada para las incorporaciones. Errores de autenticación al unir un equipo

Si la unión devuelve un error

En el cliente, consulta el registro que Windows escribe para esta operación.

Get-Content -LiteralPath "$env:windir\debug\NetSetup.log" -Tail 100

Busca las líneas de la hora del último intento. 0x54B orienta al descubrimiento del controlador, 0x6BA a RPC y 0xAAC a una cuenta de equipo existente cuya reutilización ha bloqueado la política. Para este último, el administrador debe revisar el objeto de equipo, su propietario y las condiciones de reutilización. Si hay un problema de permisos para crear un objeto, consulta la delegación de la unidad organizativa y la configuración del dominio. Registro de unión a dominios · Reutilización bloqueada de cuentas de equipo

5. Si el equipo ya está unido, revisa la cuenta, las GPO y el canal seguro

Si falla un usuario concreto

Comprueba la distribución de teclado en la pantalla de inicio, Bloq Mayús y el formato de cuenta. En Usuarios y equipos de Active Directory (dsa.msc), revisa si la cuenta está bloqueada, deshabilitada o caducada. Comprueba también la caducidad de la contraseña, la opción de cambiarla al siguiente inicio y las restricciones de horario o estaciones de trabajo.

Si Windows rechaza la contraseña nueva por longitud, complejidad, historial o antigüedad, revisa la política que aplica al usuario.

En el servidor o en un equipo de administración con el módulo ActiveDirectory

Get-ADDefaultDomainPasswordPolicy
Get-ADUserResultantPasswordPolicy -Identity alumno01

El segundo comando muestra la política de granularidad fina resultante cuando hay una aplicable. Si no hay una asignada, comprueba la política predeterminada del dominio. El restablecimiento, desbloqueo y los cambios de restricciones corresponden a una cuenta administrativa autorizada. Políticas de contraseñas de granularidad fina

Si la cuenta es válida, comprueba el derecho de inicio de sesión

En el cliente, secpol.msc permite consultar Directivas locales → Asignación de derechos de usuario. Para una sesión en la consola, revisa Permitir el inicio de sesión local y Denegar el inicio de sesión local. La denegación tiene prioridad. Si el acceso es por Escritorio remoto, comprueba los derechos específicos de esa modalidad.

Usa gpresult para identificar qué directivas se aplicaron. Para los resultados de usuario, ejecuta el informe en su sesión o consulta el usuario adecuado con los permisos correspondientes.

gpresult /r
gpresult /h "$env:TEMP\gpo-informe.html"

La pantalla Otro usuario permite escribir la identidad. Comprueba la pertenencia del equipo y los derechos aplicados por separado. Referencia de gpresult · Derecho de inicio de sesión local

Si fallan varias cuentas en el mismo equipo, comprueba el canal seguro

Con red, DNS y hora correctos, y con PartOfDomain=True, prueba el vínculo entre la cuenta de equipo y el dominio.

En Windows PowerShell elevado, en el cliente miembro

Test-ComputerSecureChannel -Verbose

True indica que la prueba ha funcionado. Si devuelve False o un error, conserva el detalle y revisa la comunicación con el controlador y el estado de la cuenta de equipo antes de reparar. Si indica ComputerNotInDomain, vuelve a la comprobación de pertenencia. Si se confirma un problema del canal seguro en el cliente miembro, el administrador puede repararlo con Test-ComputerSecureChannel -Repair y credenciales autorizadas. Microsoft indica que este cmdlet se usa en equipos miembro, porque en controladores de dominio puede devolver falsos positivos. Test-ComputerSecureChannel

Si fallan varios clientes, revisa los servicios y el estado del controlador. Si hay varios controladores, incluye la replicación.

En Windows Server, con permisos de diagnóstico

Get-Service DNS, Netlogon, KDC, NTDS, W32Time
dcdiag /test:DNS /v
dcdiag /test:Advertising
repadmin /replsummary

6. Usa los eventos para saber dónde se detuvo el inicio de sesión

Abre eventvwr.msc y consulta Registros de Windows → Seguridad. Filtra por Identificadores de evento y compara la hora, el usuario y el origen. La ubicación del evento depende de quién procesó la operación y de la auditoría configurada.

EventoQué buscar
4624Una sesión correcta en el equipo que la creó. El tipo 2 corresponde a inicio interactivo y el 11 a inicio interactivo con credenciales en caché.
4625Un intento fallido. Revisa Status y SubStatus, el tipo de inicio y el equipo que lo registró.
4740Bloqueo de cuenta. Útil si el problema vuelve después de desbloquearla.
4768 y 4769Solicitudes Kerberos del ticket inicial y de servicio, respectivamente. Se registran en el controlador que las atiende.
4771 y 4776Fallo de preautenticación Kerberos o validación de credenciales NTLM, respectivamente.

Un 4768 correcto indica que el controlador emitió un ticket inicial Kerberos para la cuenta. Para comprobar un inicio de sesión interactivo, busca el 4624 del cliente que corresponda al mismo usuario y al momento de la prueba. Un evento del controlador describe su parte de la operación. Evento 4768 · Evento 4624

Código en el 4625Dónde mirar
0xC0000064 o 0xC000006ANombre de usuario desconocido o contraseña incorrecta.
0xC000006F o 0xC0000070Horario o estación de trabajo restringidos.
0xC0000071 o 0xC0000193Contraseña caducada o cuenta caducada.
0xC0000072 o 0xC0000234Cuenta deshabilitada o bloqueada.
0xC000015BEl usuario carece del derecho para ese tipo de inicio.

Campos y códigos del evento 4625

7. Cómo se resolvió el caso del laboratorio

  1. El cliente devolvía 1355 al buscar el controlador. Se revisaron las redes de VMware y se recuperó la conectividad entre ambas máquinas.
  2. El DNS incluía la IP interna y la IP NAT del servidor. Se corrigieron las referencias a la dirección que el cliente no podía alcanzar y se revisó la hora.
  3. Después respondió nltest, funcionaron las comprobaciones TCP básicas y apareció un 4768 correcto. Windows seguía rechazando la sesión.
  4. Test-ComputerSecureChannel indicó que el cliente no era miembro del dominio. La consulta CIM confirmó WORKGROUP / False.
  5. El primer intento de unión usaba una cuenta local. Con una cuenta de dominio autorizada, Windows completó la incorporación. Después del reinicio, el alumno inició sesión con su cuenta del dominio.

Las salidas del caso proceden del relato original del laboratorio. Los nombres de dominio usados en los comandos son ejemplos para que puedas reproducir las comprobaciones en tu red.

Preguntas rápidas

¿Necesito Internet para iniciar sesión en Active Directory? Para un dominio local, el equipo necesita acceso a los servicios correspondientes del dominio. Una red interna aislada puede ofrecerlos.

¿Por qué puedo hacer ping al servidor y seguir recibiendo un error? El ping prueba ICMP. Usa el resultado de PartOfDomain, DNS y el evento de la operación para localizar el fallo.

¿Qué miro si tras la unión todo funciona menos el acceso de un usuario? Revisa cómo está escrita la cuenta, su estado, sus restricciones y el tipo de inicio del evento 4625. Si el evento apunta a un derecho de inicio, comprueba la GPO correspondiente.

Si el problema empieza antes de arrancar la máquina virtual, consulta la guía de VMware y el error de Device/Credential Guard.