Unir una VM de Azure a Entra Domain Services: decidir primero

Tres decisiones se interponen ante una VM de Windows Server que debe usar un directorio administrado, y el comando de unión es la menor de ellas. Elija el modelo de directorio equivocado y la unión se logra mientras la aplicación sigue sin poder autenticarse. Falle en la resolución de nombres y el error aparece en un punto que parece un problema de credenciales.

Resuelva el modelo, la resolución y la cuenta antes de tocar el servidor, y luego el comando se ejecuta una vez.

Cuál de las tres uniones quiere en realidad

La unión de dispositivo registra una máquina en Microsoft Entra ID para el acceso condicional y el inicio de sesión único, y no da a la carga de trabajo ningún ticket Kerberos hacia un dominio al estilo local. La unión de dominio tradicional vincula un objeto de equipo en un directorio y le da una cuenta de máquina, directiva de grupo y autenticación de dominio. Un dominio administrado ofrece ese segundo modelo como servicio. Los nombres suenan parecidos y los resultados no.

Solo las dos últimas implican un controlador de dominio en el sentido habitual, y solo la opción administrada saca los servidores de su lista de parches.

La decisión suele depender de la aplicación y no de la preferencia. El software que quiere un enlace LDAP, una cuenta de servicio con un SPN u objetos de directiva de grupo pertenece al modelo de dominio. El software que solo necesita conocer la identidad del usuario en un dispositivo corporativo normalmente no pertenece.

La ruta DNS decide si la unión puede terminar

Una unión de dominio comienza con una búsqueda de localizador de los registros del controlador del dominio, así que la resolución de nombres debe funcionar antes de que se compruebe cualquier credencial. Apunte la VM a las direcciones de directorio del dominio administrado, ya sea mediante la configuración de DNS de la red virtual o mediante un reenviador condicional que envíe solo ese espacio de nombres hacia ellas. Un reenviador limitado al espacio de nombres suele ser la opción más segura, porque deja intacto el resto de la resolución de la VM.

Pruebe el localizador y no un nombre de host desnudo. Un ping al nombre del dominio no demuestra casi nada, mientras que una consulta SRV de los registros del controlador del dominio o bien devuelve los destinos esperados o bien falla de inmediato:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

Sustituya el nombre del dominio y las dos direcciones por los valores de la configuración de su dominio administrado; los números de aquí son ejemplos. Si la consulta devuelve respuestas de otra zona, la VM usa un solucionador que no reenvía el espacio de nombres administrado, y ninguna cantidad de reintentos de la unión lo cambiará.

Mantenga la carga de trabajo fuera de la subred que el dominio administrado reserva para sus propios recursos de servicio, y mantenga los puertos del directorio en la ruta privada. La exposición pública de esos puertos no es un atajo; es un diseño distinto con un perfil de riesgo distinto.

La elegibilidad de la cuenta se comprueba antes que la máquina

La cuenta que realiza la unión necesita permiso para crear un objeto de equipo en el contenedor de destino, y debe poder autenticarse contra el dominio administrado. Una cuenta solo en la nube creada antes de que existiera el dominio administrado puede carecer del material derivado de la contraseña que el dominio necesita, y un cambio o restablecimiento de contraseña lo regenera. Ese detalle explica una clase de fallos de unión que parecen contraseñas incorrectas cuando la contraseña es correcta. Pruebe la credencial contra el dominio antes de que se abra la ventana de mantenimiento.

Las cuentas híbridas sincronizadas tienen sus propios requisitos previos que un objeto de usuario visible no satisface por sí solo. Estar listado en el directorio no es lo mismo que poder obtener un ticket de él, así que pruebe la cuenta antes de la ventana de mantenimiento y no durante ella.

Delegue el derecho de unión de forma estrecha. Dar a cada futuro usuario de servidor la pertenencia de administrador de dominio para que ocurra una sola inscripción es una concesión permanente para un problema temporal.

La unión en sí es un solo comando

Con el modelo elegido, el DNS respondiendo y la cuenta elegible, la operación es la habitual de Windows. El indicador mantiene la contraseña fuera de los scripts y del historial del intérprete:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

El comando no reinicia la máquina por sí solo en esta forma, así que el reinicio ocurre bajo el plan de mantenimiento y con la ruta de recuperación todavía disponible. Un servidor ya unido a otro dominio necesita un plan de migración, no una segunda unión sobre la primera.

Anote el contenedor en el que aterrizó el objeto de equipo y la cuenta que lo creó. Ambos importan cuando la máquina debe volver a unirse tras una reconstrucción, y ninguno resulta evidente desde el servidor después.

Lo que la pertenencia no concede

La pertenencia al dominio no convierte a nadie en administrador local ni concede acceso al escritorio remoto o a recursos compartidos de archivos. Esos derechos se configuran por separado, y en un dominio administrado se mantienen dentro de su ámbito administrativo admitido.

La ruta de red es una dependencia continua, no un paso de configuración. Si la conexión privada desaparece, el servidor sigue funcionando con credenciales en caché hasta que algo necesite el directorio, y entonces el fallo llega en un registro de aplicación y no junto a la configuración que cambió.

La guía de Microsoft para la unión de Windows Server enumera los requisitos previos admitidos para el flujo de trabajo del dominio administrado. Léala frente a las tres decisiones anteriores y trate cualquier discrepancia como un motivo para detenerse y no como un detalle que sortear.