Windows Server 2025 / Cómo unir un cliente Windows al dominio Active Directory

Para unir CLIENT1 a un dominio de Active Directory (AD), necesita una edición de Windows compatible, DNS interno operativo, comunicación con el dominio y permisos para crear o reutilizar la cuenta del equipo. Configure CLIENT1 para utilizar DC1 como DNS, únalo a ad.example.test y reinicie después de confirmar el éxito. Compruebe por separado la pertenencia del equipo al dominio y la identidad de la sesión del usuario.

Prepare DNS y permisos de unión

Use una edición que admita la unión a un dominio AD, por ejemplo Windows 11 Pro o Enterprise; Windows Home no proporciona esta unión. Unir o registrar el dispositivo en Microsoft Entra ID es otra operación y no sustituye el procedimiento de este artículo. En la red aislada compartida deben funcionar AD y DNS de DC1, creados en la práctica de instalación del primer dominio. Para efectuar la unión necesita privilegios de administrador local en CLIENT1, además de los permisos de dominio adecuados.

• Confirme el nombre definitivo CLIENT1 y compruebe una vía de acceso con administrador local antes de cambiar la pertenencia. Mantenga acceso a la consola de la VM.
• Configure el DNS del adaptador del laboratorio como 172.24.50.10. Si utiliza DHCP, revise las opciones recibidas y asegúrese de que IP y DNS usan el modo previsto; un DNS público alternativo no sustituye el DNS interno de AD.
• Revise fecha y hora, la red virtual compartida y la comunicación con DC1. No desactive el cortafuegos para ocultar un problema de alcance o de reglas.
• Prepare una cuenta con permisos para crear el objeto de equipo en su destino o reutilizar el objeto existente, según corresponda. Los privilegios locales y los derechos sobre AD son requisitos distintos.

Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.test' -Type SRV -Server 172.24.50.10
nltest /dsgetdc:ad.example.test

En este laboratorio, la respuesta SRV debe identificar un servicio del controlador esperado, como dc1.ad.example.test, y nltest debe localizar un controlador para ad.example.test. Un registro SRV existente no prueba por sí solo que todas las comunicaciones de unión funcionen; si la primera consulta responde y la segunda falla, compruebe también el DNS configurado en CLIENT1. La detección correcta tampoco concede permisos para unirse ni prueba que una contraseña sea válida.

Ejecute las dos consultas en CLIENT1 antes de proporcionar contraseñas de dominio. La primera consulta explícitamente el DNS 172.24.50.10; la segunda intenta localizar un controlador usando la configuración del cliente. Si falla la detección, revise el adaptador, DNS, conectividad y hora antes de repetir credenciales. Los permisos de unión al dominio distinguen crear una cuenta de equipo de reutilizar una existente. Delegue solo los derechos necesarios en el contenedor o la unidad organizativa (OU) correspondiente, sin convertir por comodidad a un usuario cotidiano en administrador de dominio.

Una CLIENT1 desde Propiedades del sistema

1. En CLIENT1, ejecute sysdm.cpl y abra Nombre de equipo → Cambiar. Confirme que está modificando el cliente previsto, con acceso de administrador local.
2. En Miembro de, seleccione Dominio e introduzca ad.example.test como nombre DNS del dominio. Confirme con Aceptar.
3. Cuando se soliciten credenciales, use una identidad de dominio con los permisos necesarios, por ejemplo AD\nombreautorizado con el nombre real. La contraseña local de CLIENT1 no autoriza por sí sola la creación o reutilización del objeto en AD.
4. Compruebe el mensaje que confirma la unión correcta. Si aparece un error, deténgase y anótelo. Si finaliza correctamente, guarde el trabajo y reinicie cuando se le indique.
5. Después del reinicio, elija Otro usuario e inicie sesión con AD\nombredeusuario o nombredeusuario@ad.example.test. Sustituya nombredeusuario por una cuenta de dominio que realmente exista; conserve también las credenciales del administrador local.

El procedimiento oficial de unión al dominio describe la operación. Si todavía no creó el usuario estándar del laboratorio, compruebe primero la unión y la administración con una cuenta autorizada existente, y pruebe el inicio de sesión ordinario cuando ese usuario esté disponible. Pertenecer a Domain Admins no debe convertirse en la identidad de trabajo diaria.

Una cuenta local CLIENT1\usuario y una cuenta AD\usuario son identidades diferentes aunque compartan el mismo nombre visible. El primer inicio de sesión de dominio no reutiliza automáticamente el perfil local anterior; puede aparecer un escritorio nuevo con otras preferencias. Conserve una copia de los datos y planifique su migración con los permisos apropiados, sin borrar la carpeta del perfil previo para intentar resolver la diferencia.

Utilice PowerShell como alternativa

Como alternativa a la interfaz gráfica, abra Windows PowerShell como administrador en CLIENT1 solo si aún no lo unió al dominio. Ejecute el bloque por líneas, no como una operación ciega: Get-Credential solicita de forma interactiva una cuenta de dominio autorizada y su contraseña; Add-Computer realiza la unión y -PassThru -Verbose permite revisar el resultado. Ejecute Restart-Computer únicamente después de confirmar que la unión tuvo éxito y de guardar el trabajo. Un error de Add-Computer no implica que la línea de reinicio posterior quede automáticamente cancelada. Consulte la referencia de Add-Computer:

$joinCredential = Get-Credential
Add-Computer -DomainName 'ad.example.test' -Credential $joinCredential -PassThru -Verbose
Restart-Computer

Reiniciar no convierte una unión fallida en una correcta. Si aparece un error, conserve el mensaje y resuelva su causa antes de repetir la operación o reiniciar por este motivo. El mismo planteamiento permite incorporar FS1 como servidor miembro: conserve su IP estática 172.24.50.20 y utilice el DNS de dominio operativo 172.24.50.10. Unirse como miembro no instala AD DS ni promueve FS1 a controlador de dominio.

Compruebe pertenencia al dominio e identidad de sesión

Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain
whoami
$env:LOGONSERVER
Test-ComputerSecureChannel -Verbose

Ejecute estas comprobaciones en CLIENT1 después del reinicio, con Windows PowerShell elevado para el diagnóstico. PartOfDomain debe ser True, Domain debe ser ad.example.test y Name debe corresponder a CLIENT1. Whoami identifica la sesión actual: AD\usuario corresponde a una identidad de dominio, mientras que CLIENT1\usuario sigue siendo local aunque el equipo ya esté unido. El valor de LOGONSERVER aporta contexto de la sesión y no demuestra por sí solo que DNS, autenticación y canal seguro estén sanos.

Test-ComputerSecureChannel -Verbose debe devolver True si el canal seguro entre este equipo miembro y su dominio funciona. Sin -Repair, el comando comprueba el canal y no lo repara. Si devuelve False o un error, examine DNS, conectividad y el estado de la cuenta antes de intentar una reparación o una salida del dominio. La referencia de Test-ComputerSecureChannel limita esta prueba a clientes y servidores miembros; ejecutarla en DC1 puede producir resultados erróneos y no sustituye el diagnóstico de un controlador.

En DC1, abra Administrador del servidor → Herramientas → Usuarios y equipos de Active Directory y localice el objeto de equipo CLIENT1. Si no hubo una ubicación predefinida ni una redirección, normalmente se crea en el contenedor Computers, que no es una OU. Si se precreó en otra ubicación, búsquelo allí. Más adelante podrá moverlo a la OU Workstations del laboratorio para practicar directivas. El objeto del equipo y el del usuario tienen ubicaciones independientes; mover uno no mueve el otro.

Revise la reutilización de cuentas y la salida del dominio

La reutilización de una cuenta de equipo existente puede quedar bloqueada por las protecciones de unión. Revise el propietario, los derechos delegados, el nombre del equipo y si el dispositivo anterior sigue activo antes de cambiar el objeto. KB5020276 sobre el refuerzo de la unión al dominio explica las comprobaciones de propiedad y los procedimientos admitidos. Un error 0xaac puede señalar bloqueo de reutilización, no simplemente una contraseña errónea. En CLIENT1, examine C:\Windows\debug\NetSetup.log y las entradas de la hora exacta del intento; también puede consultar la guía de errores de red al unirse al dominio. No desactive controles, amplíe listas de confianza a todos ni elimine una cuenta de equipo en uso para forzar el resultado.

Mantenga CLIENT1 unido al dominio para las prácticas posteriores. Si necesita practicar la salida, confirme antes que dispone de un administrador local funcional y de sus credenciales. En sysdm.cpl → Nombre de equipo → Cambiar, seleccione Grupo de trabajo, indique el nombre elegido, autorice el cambio cuando se solicite y reinicie después de confirmar el resultado. Entre con el administrador local, por ejemplo CLIENT1\nombrelocal usando el nombre real. Los datos de perfiles y la limpieza del objeto en AD requieren decisiones separadas. Registre individualmente unión, inicio de sesión del usuario estándar, DNS y canal seguro, conservando el resultado y la hora de cada prueba.