Cómo unirse a dominios de Active Directory o Azure AD: guía total

 

Unir equipos a un dominio, ya sea de Active Directory local o de Azure (Microsoft Entra ID), es la base para centralizar identidades, aplicar directivas y habilitar Single Sign-On. En esta guía reunimos en un único recurso todo lo que necesitas: opciones de unión en Windows 10/11, identidad híbrida con Microsoft Entra Connect, Azure AD Domain Services, despliegues de AD FS en Azure, seguridad con acceso condicional y monitorización, además de recomendaciones operativas y de costes.

El objetivo es que puedas elegir la mejor vía (AD DS clásico, Azure AD/Entra ID, Azure AD DS o federación AD FS), entender cómo se conectan entre sí y ejecutar los pasos correctos con buenas prácticas. También verás cómo preparar UPN y DNS para sincronizaciones con Microsoft 365, cómo escalar y dar alta disponibilidad a la sincronización, y qué comprobar si algo falla, sin dejarte en el tintero configuraciones típicas de red en Azure.

Opciones de unión a dominio en Windows 10 y 11

Hoy conviven cuatro escenarios principales: unión a AD DS local, unión a Azure AD (Microsoft Entra ID), dispositivos híbridos (Hybrid Azure AD Join) y unión a dominios administrados con Azure AD Domain Services. Cada uno resuelve necesidades distintas de gestión de identidad, compatibilidad de aplicaciones o trabajo remoto.

Unirse a Azure AD desde Windows 10/11 es directo desde el propio equipo: Configuración > Cuentas > Acceder al trabajo o a la escuela > Conectar > Unir este dispositivo a Azure Active Directory, iniciar sesión con credenciales de Microsoft Entra ID, reiniciar y volver a entrar con el usuario corporativo.

Tras el primer inicio, se suele requerir configurar MFA y Windows Hello (PIN) para reforzar la seguridad y facilitar inicios de sesión rápidos. A partir de ese momento, el PIN se solicitará en cada logon, cumpliendo con la autenticación en dos pasos que exigen muchas organizaciones.

Si vas a desplegar un agente de acceso como Sophos ZTNA, recuerda que los servidores de aplicaciones (RDP, CIFS, SSH, etc.) deben pertenecer al mismo dominio que el agente. Primero une el equipo a Azure AD y, a continuación, instala el agente para que herede la identidad correcta y las rutas de acceso.

Arquitectura de identidad con Microsoft Entra ID (Azure AD)

Microsoft Entra ID es el servicio de identidad y directorio en la nube que centraliza aplicaciones, usuarios y dispositivos, y se integra con AD DS local mediante sincronización. Una referencia típica incluye: inquilino de Entra ID, subred web con VMs de aplicación, AD DS on-premises, un servidor con Microsoft Entra Connect para sincronizar, y VMs de aplicaciones con separación por capas.

Casos de uso frecuentes: publicar apps web en Azure para usuarios remotos, habilitar autoservicio (por ejemplo restablecimiento de contraseña, con licencias P1/P2) y operar sin conectividad VPN/ExpressRoute entre on-prem y Azure Virtual Network si así lo requiere el diseño.

En cuanto a disponibilidad, Microsoft Entra se distribuye globalmente con conmutación por error automática entre centros de datos, garantizando acceso a los datos del directorio en múltiples ubicaciones geográficas. Este diseño minimiza interrupciones y soporta cargas de trabajo distribuidas.

Identidad híbrida con Microsoft Entra Connect: sincronización y SSO

Microsoft Entra Connect sincroniza identidades de AD DS con Entra ID y permite elegir el método de autenticación: sincronización de hash de contraseñas (por defecto), Pass-through Authentication o federación con AD FS u otro IdP. La elección depende de políticas de seguridad, experiencia SSO deseada y componentes ya desplegados.

• Topologías admitidas de sincronización: un solo bosque a un inquilino; múltiples bosques a un único inquilino (con consolidación de identidades); múltiples bosques independientes; múltiples directorios Entra (con servidores de sincronización filtrando conjuntos de objetos excluyentes), y un servidor en modo Staging para alta disponibilidad, pruebas o migraciones.
• Buenas prácticas al desplegar Entra Connect: definir qué sincronizar, dominios incluidos y periodicidad; filtrar (por grupos, dominios, OU o atributos) para evitar sincronizar cuentas inactivas; y, si hay muchos objetos, valorar SQL Server completo en lugar de LocalDB y ajustar capacidad.
• Alta disponibilidad: usar un segundo servidor en modo Staging para asumir el rol activo si es necesario; si no usas LocalDB, considera clústeres de SQL para la base de datos (no se admiten mirroring ni AlwaysOn para Entra Connect), y planifica recuperación ante desastres.

Configuración del método de autenticación del usuario

Sincronización de hash de contraseña: opción por defecto, sencilla y suficiente para muchas organizaciones; el usuario se autentica con la misma contraseña local, pero en la nube solo viaja un hash seguro.

Pass-through Authentication: si tu política prohíbe sincronizar hashes a la nube, los agentes validan la contraseña en AD local sin almacenar el hash en Entra ID, manteniendo SSO.

Federación con AD FS u otro proveedor: si ya cuentas con AD FS o un IdP no Microsoft, puedes delegar autenticación y SSO a esa infraestructura, manteniendo control y personalizaciones avanzadas.

Sincronización de objetos y reglas

La configuración predeterminada de Entra Connect aplica reglas a objetos de Usuario, Contacto, Grupo, Computer, etc., exigiendo atributos como sourceAnchor o sAMAccountName, y evitando prefijos reservados (por ejemplo Azure AD_ o MSOL_). Para modificar reglas, utiliza el Editor de Reglas de Sincronización instalado con la herramienta.

Además del filtrado por dominio/OU, puedes implementar filtros personalizados más complejos para reducir el conjunto sincronizado a lo relevante. Así mejoras rendimiento, seguridad y costes de administración.

Supervisión y salud del entorno de identidad

Microsoft Entra Connect Health proporciona agentes para monitorizar la sincronización, AD DS y AD FS, y expone paneles en Azure Portal para revisar estado y rendimiento. Es clave para detectar incidentes antes de que afecten a usuarios.

En cuanto a protección, Identity Protection (P2) aplica ML y heurística para detectar anomalías de inicio de sesión y eventos de riesgo (ubicaciones inusuales, IPs sospechosas, dispositivos comprometidos), generando alertas e informes accionables.

Complementa con acceso condicional para disparar MFA en ubicaciones no confiables, restringir por plataforma/estado de dispositivo y usar pertenencia a grupos estáticos o dinámicos en las decisiones de acceso. Así elevas significativamente la postura de seguridad.

Implementación de AD FS en Azure: diseño, red y alta disponibilidad

Para organizaciones que optan por federación, desplegar AD FS en Azure facilita alta disponibilidad y escalado, con redundancia geográfica y administración sencilla desde Azure Portal. La topología recomendada separa AD FS y WAP, usa DMZ para WAP y balanceadores (interno para AD FS y público para WAP).

• Red y seguridad: crea una red virtual con dos subredes (INT y DMZ), aplica NSG por subred con reglas como: permitir HTTPS 443 desde DMZ a INT (por ejemplo 10.0.1.0/24 > 10.0.0.0/24, prioridad 1010), denegar salidas a Internet excepto lo necesario (por ejemplo deny 80 outbound prioridad 100), y abrir solo lo imprescindible en DMZ para tráfico entrante.
• Conectividad on-prem: si necesitas alcanzar controladores de dominio locales, usa S2S VPN, P2S o ExpressRoute (recomendado cuando buscas fiabilidad, latencia y seguridad elevadas).
• Conjuntos de disponibilidad: usa al menos dos VMs por rol (AD FS y WAP) en availability sets; deja valores por defecto (2 fault domains, 5 update domains) para mantenimiento sin interrupciones.
• Balanceo interno (ILB) para AD FS: configura IP estática, backend pool con servidores AD FS y una sonda de salud HTTP a /adfs/probe en puerto 80; publica 443 a backend 443 y crea el registro DNS interno del servicio de federación apuntando al ILB.

WAP, balanceador público y pruebas de AD FS

Los servidores Web Application Proxy no se unen al dominio y residen en DMZ, publicando AD FS hacia Internet a través de un Load Balancer público en 443 con sonda /adfs/probe. Asigna etiqueta DNS a la IP pública para resoluciones amigables.

• Actualiza DNS: crea un A interno para el servicio de federación (p. ej. fs.empresa.com) al ILB, y entradas hosts en WAP si necesitas resolver internamente la IP del ILB con el FQDN federado.
• Certificados: usa un certificado de servidor con CN/SAN adecuados (servicio de federación, enterpriseregistration, comodín si aplica) y expórtalo en PFX para instalarlo en AD FS y WAP.
• Prueba: habilita la página IdP Initiated con PowerShell Set-AdfsProperties -EnableIdPInitiatedSignOnPage $true y valida navegando a https://tu-adfs/adfs/ls/IdpInitiatedSignon.aspx.

Plantilla de despliegue de AD FS y parámetros típicos

Hay plantillas que orquestan seis máquinas (dos DC, dos AD FS y dos WAP) y aceptan parámetros para región, cuentas de almacenamiento, red virtual (existente o nueva), subredes INT/DMZ, IPs estáticas de VMs y del ILB, tamaños de VM y credenciales administrativas. Entre los parámetros figuran: Location, StorageAccountType, VirtualNetworkUsage/Name/AddressRange, nombres y rangos de subredes, NIC IPs por VM, ADFSLoadBalancerPrivateIPAddress, prefijos de nombres de cada rol, tamaños de VM y credenciales.

Esta aproximación acelera implantaciones coherentes y repetibles, a la vez que documenta la configuración de red y seguridad. Ajusta siempre los rangos para evitar solapamientos con redes existentes.

Azure AD Domain Services: unir una VM a un dominio administrado

Azure AD Domain Services (AADD DS) ofrece unión a dominio, LDAP y Kerberos/NTLM administrados en Azure, sin levantar controladores de dominio propios. Útil cuando necesitas compatibilidad de aplicaciones heredadas con autenticación de dominio dentro de Azure.

• Requisitos: suscripción activa, inquilino Entra ID (solo nube o sincronizado), dominio administrado habilitado, cuenta de usuario en el dominio administrado (con hash de contraseña sincronizado o SSPR), y Azure Bastion para acceso RDP sin IPs públicas.
• Proceso: crea una VM Windows Server en una subred capaz de comunicar con la subred del dominio administrado (mejor en subred separada), con puertos remotos cerrados a Internet (usa Bastion), y únete al dominio desde Propiedades del sistema especificando el FQDN (por ejemplo aaddscontoso.com).
• Credenciales: usa formato UPN recomendado (usuario@dominio.onmicrosoft.com o personalizado), o SAMAccountName si aplica; la cuenta debe pertenecer al dominio administrado o al inquilino Entra ID.
• Solución de problemas: si no pide credenciales, el fallo suele ser de conectividad/DNS: verifica emparejamiento de redes, haz ping al FQDN o a las IPs del dominio administrado y vacía caché DNS con ipconfig /flushdns.

Si da error tras introducir credenciales, comprueba pertenencia de la cuenta al dominio administrado, que la sincronización de contraseñas esté habilitada y que haya transcurrido tiempo suficiente tras un cambio de contraseña para que el hash se replique. Para desasociar, regresa a WORKGROUP y luego elimina la VM si no seguirás con el tutorial.

Preparar AD local y sincronizar con Microsoft 365/Azure AD

Si ya usas Microsoft 365, sincronizar AD local con Entra ID unifica credenciales en nube y on-prem, con opciones híbridas muy extendidas. Asegura que los sufijos UPN locales sean enrutables (no .local/.test) y coincidan con tus dominios verificados en Microsoft 365/Entra ID.

Agrega un sufijo UPN en Dominios y confianzas de Active Directory y actualiza usuarios en ADUC o vía PowerShell para cambiar de @domain.local a @domain.com de forma masiva, por ejemplo con: $LocalUsers = Get-ADUser -Filter "UserPrincipalName -like '*domain.local'" -Properties userPrincipalName -ResultSetSize $null y $LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@domain.local","@domain.com"); $_ | Set-ADUser -UserPrincipalName $newUpn}.

Para Office 365, revisa proxyAddresses (SMTP en mayúsculas para la principal) en el Editor de atributos de cada usuario/grupo, habilitando la vista de funciones avanzadas en ADUC para editar correctamente la colección de alias.

Instala Azure AD Connect: descarga oficial, escoge instalación Personalizada, define método de inicio de sesión (PHS, PTA o federación), conecta con la cuenta de administrador global en Entra ID/M365, añade el bosque AD, selecciona userPrincipalName como atributo de inicio de sesión y filtra dominios/OU si procede.

Funciones opcionales: password writeback (P1/P2), cambios de reglas, y programador; marca “Iniciar la sincronización al finalizar” o lánzala manualmente cuando convenga.

Operación de la sincronización: comandos útiles y migración de configuración

El módulo ADSync de PowerShell permite consultar el programador y forzar ciclos: Import-Module ADSync, Get-ADSyncScheduler, Start-ADSyncSyncCycle -PolicyType Delta o Initial, y ajustar intervalo con Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:10:00.

La configuración de Azure AD Connect se guarda en JSON bajo %ProgramData%\AADConnect; puedes exportarla/importarla para clonar despliegues y también usar el script MigrateSettings.ps1 (carpeta Tools) para migrar de un servidor a otro.

Recuerda que la sincronización no es un sistema de backup: algunos atributos solo existen en nube (por ejemplo licencias), y si se eliminan allí no se recuperan sincronizando. Para copia de seguridad de AD local y datos de Microsoft 365, recurre a soluciones dedicadas.

Requisitos y red: Windows Server 2012/2016/2019 con GUI para instalar Entra Connect, .NET 4.5.1+, PowerShell 3.0+, TLS 1.2 habilitado y salida TCP 80/443 a servicios de Microsoft; Essentials/Core no compatibles para el servidor de la herramienta.

Acceso condicional, seguridad y gobierno

Complementa el inicio de sesión con directivas de acceso condicional para orígenes inesperados, plataformas no conformes o dispositivos deshabilitados, y apoyate en grupos (incluidos los dinámicos) para segmentar acceso. Así aplicas Zero Trust con fricción mínima.

Identity Protection (P2) añade directivas base en riesgo que reaccionan ante señales de inicio de sesión anómalas, y los informes de Entra ayudan a diagnosticar y auditar actividades relevantes.

Conecta los agentes de Connect Health para monitorizar sincronización, AD DS y AD FS, ofreciendo métricas y estado en Azure Portal, siendo uno de los pilares de la gestión eficiente.

Rendimiento, costes y operabilidad (Well-Architected)

• Rendimiento: Entra ID se apoya en réplica principal y réplicas secundarias de solo lectura, con consistencia final y escalado efectivo, al ser mayormente operaciones de lectura; en Entra Connect dimensiona SQL si superas aproximadamente 100.000 objetos.
• Costes: usa la calculadora de Azure para estimar; optimiza limitando sincronización a lo necesario y seleccionando métodos de autenticación que reduzcan infraestructura (por ejemplo, sin AD FS si no es imprescindible).
• Fiabilidad: considera un segundo servidor de Entra Connect en Staging para failover, planifica recuperación ante desastres y cuida las bases de datos: evita tecnologías no soportadas como mirroring o AlwaysOn para la base de datos de sincronización.
• Operabilidad: las herramientas de Entra Connect (Consola, Synchronization Service Manager y Editor de reglas) permiten mantener y ajustar la sincronización con control y diagnósticos precisos, imprescindibles en entornos complejos o con reglas personalizadas.

Integración con Citrix y SAML (SSO con Azure AD)

Para publicar escritorios o aplicaciones con Citrix y SSO mediante Azure AD, integra Citrix Gateway y StoreFront usando SAML 2.0 como IdP Azure AD, para que los usuarios con Azure AD-joined tengan inicio sencillo desde myapps.microsoft.com. En Azure AD, crea una app empresarial, configura SAML con identificador y URL de respuesta como /cgi/samlauth, descarga el certificado de firma y copia las URLs de inicio y cierre de sesión, asignando la app a los usuarios y usando la URL de SSO en accesos directos.

En Citrix Gateway, importa el certificado, configura la política SAML, añade el IdP de Azure con metadatos y vincula con StoreFront (ideal en HTTPS), verificando que la autenticación funcione correctamente y que las políticas de confianza y STA estén adecuadas. Si usas AD FS como IdP intermediario, recuerda el registro CNAME para federación (por ejemplo, enterpriseregistration.<sufijoUPN>) para resolver el flujo en la unión a Azure AD, asegurando también la instalación del certificado raíz correspondiente en los equipos.

Sobre plataformas: consulta recursos como Reddit con precaución, ya que sus recomendaciones no son oficiales, y siempre contrastarlas con documentación técnica formal antes de aplicar cambios.

Este recorrido, desde lo básico a lo avanzado, cubre desde sencillas uniones a Azure AD hasta arquitecturas híbridas con alta disponibilidad, federación y SSO para aplicaciones modernas y tradicionales, con controles de seguridad sofisticados y buena operativa. Al planificar bien UPN y DNS, filtrar adecuadamente las sincronizaciones y aplicar medidas de seguridad como MFA y acceso condicional, la gestión de identidades en Windows 10/11 y cargas en Azure será eficiente, escalable y sencilla de mantener.