Guía completa para unir equipos a Azure AD y Microsoft Entra ID

Si trabajas con Windows 10 o Windows 11 y te estás planteando unir tus equipos a Azure AD o Microsoft Entra ID, seguramente te habrás dado cuenta de que no es solo “dar a siguiente y aceptar todo”. Detrás hay decisiones de autenticación, sincronización con Active Directory local, seguridad, acceso remoto y unas cuantas cosas más que conviene tener claras para no liarla en producción.

En esta guía vamos a ver, paso a paso y sin rodeos, cómo unir equipos a Azure AD y a Azure AD Domain Services, qué opciones tienes si vienes de un Active Directory tradicional, cómo encaja Microsoft Entra Connect en todo esto y qué buenas prácticas de seguridad, alta disponibilidad y rendimiento deberías aplicar. La idea es que acabes el artículo con una visión global y práctica, tanto si solo quieres unir unos cuantos portátiles a la nube como si vas a montar una arquitectura híbrida seria.

Qué es Azure AD / Microsoft Entra ID y en qué se diferencia del AD clásico

Antes de tocar nada en producción, viene bien recordar que Azure AD (ahora Microsoft Entra ID) no es lo mismo que Active Directory Domain Services clásico. Aunque ambos gestionan identidades, funcionan de manera distinta y se usan para escenarios diferentes.

Microsoft Entra ID, en cambio, es un servicio de identidades y directorio totalmente basado en la nube. No se configura con GPOs ni se accede con LDAP; se orienta a autenticación moderna (OAuth, OpenID Connect, SAML), inicio de sesión en aplicaciones SaaS, control de acceso condicional y gestión de dispositivos para trabajo moderno y remoto.

Dentro de este ecosistema también entra en juego Azure AD Domain Services (AAD DS), que es un servicio gestionado que te ofrece funcionalidades de dominio (LDAP, Kerberos, unión a dominio) en Azure sin tener que desplegar tus propios controladores de dominio. Es especialmente útil para máquinas virtuales en Azure que necesitan unirse a un dominio, pero no quieres mantener un AD completo.

Tipos de usuarios y métodos de autenticación disponibles

En tu organización puedes tener usuarios creados directamente en Microsoft Entra ID (los famosos usuarios “en la nube”) y usuarios que se sincronizan desde tu Active Directory local mediante Microsoft Entra Connect. Tener claro esto es clave, porque condiciona la forma de autenticación y cómo los equipos se unirán al directorio.

Microsoft Entra ID admite varios métodos de autenticación, cada uno con sus pros y sus contras, y conviene elegirlos con cabeza en función de tus políticas de seguridad y tu infraestructura.

Autenticación en la nube

En este modo, la validación de las credenciales se hace directamente en Microsoft Entra ID. Es decir, el usuario se autentica en la nube, sin tener que contactar con tu red local. Dentro de la autenticación en la nube tienes dos variantes principales:

• Sincronización de hash de contraseñas (PHS): se sincroniza un hash adicional de la contraseña desde el AD local a Microsoft Entra. Los usuarios pueden iniciar sesión en la nube con la misma contraseña que usan en local, pero la autenticación real se resuelve en Microsoft Entra ID. Es la opción más sencilla y suele ser la recomendada salvo restricciones de seguridad muy fuertes.
• Autenticación de paso a través (PTA): las credenciales se validan en tu entorno local mediante agentes de PTA que se instalan en servidores on-premises. Microsoft Entra no guarda el hash de la contraseña necesario para autenticar, sino que reenvía la solicitud al agente on-prem, que la valida contra el AD local. Viene bien cuando la política de seguridad prohíbe sincronizar hashes de contraseña a la nube.

Autenticación federada

En la autenticación federada, Microsoft Entra delega la autenticación en un sistema externo de confianza, como AD FS (Active Directory Federation Services) u otros proveedores de federación. Este sistema emite los tokens de seguridad y permite integraciones avanzadas, SSO complejo o requisitos de cumplimiento muy específicos.

Esta aproximación es más compleja de implantar y mantener, pero puede encajar en organizaciones grandes que ya tengan una infraestructura de federación montada y no quieran cambiar el modelo de autenticación que llevan años usando.

Unir dispositivos a Microsoft Entra ID: conceptos básicos

Cuando hablamos de unir equipos a Azure AD o Microsoft Entra ID, nos referimos a que los dispositivos Windows 10/11 pasan a ser “dispositivos unidos a Azure AD”. Esto no es exactamente lo mismo que unirlos a un dominio clásico, aunque el efecto práctico (inicio de sesión con cuenta corporativa) se le parece bastante.

Un dispositivo unido a Azure AD permite iniciar sesión con una cuenta organizativa del inquilino de Microsoft Entra ID y aplicar sobre él directivas de acceso condicional, cumplimiento, MFA, etc. Además, se integra bien con soluciones como Intune para la gestión centralizada de la configuración y las aplicaciones.

Para que esto funcione, el servicio de registro de dispositivos de Microsoft Entra debe estar correctamente configurado y tu usuario debe tener permiso para unir dispositivos. También debes vigilar el límite de dispositivos por usuario, ya que existe un máximo configurable que no conviene ignorar.

Si quieres comprobar después si un equipo ya está unido a Azure AD, puedes ir en Windows a “Acceso a trabajo o escuela” y revisar el estado: debe aparecer el directorio de tu organización y el dispositivo como conectado al inquilino.

Permitir que los usuarios unan dispositivos a Microsoft Entra ID

Uno de los pasos que mucha gente pasa por alto es que, por defecto, no todos los usuarios pueden unir equipos a Microsoft Entra ID como les dé la gana. Esta capacidad se controla desde el portal de Azure y conviene ajustarla para que encaje con tu modelo de administración.

Para configurar quién puede unir dispositivos, debes entrar en el portal de Azure con permisos de administrador del directorio y seguir una ruta muy concreta dentro de Microsoft Entra ID hasta las opciones de dispositivos y su configuración.

El recorrido habitual es el siguiente: en el portal, entras en “Microsoft Entra ID”, luego en el apartado de Dispositivos dentro del menú de administración, y a continuación accedes a “Configuración del dispositivo”. Ahí verás la opción “Usuarios pueden unir dispositivos a Microsoft Entra…”, que es la que marca la diferencia.

Esa opción se puede poner en “Todos” o “Seleccionados”. Si eliges “Todos”, cualquier usuario del inquilino puede unir equipos a Microsoft Entra ID. Si eliges “Seleccionados”, solo los miembros (usuarios o grupos) que indiques podrán hacerlo, lo cual suele ser más razonable en entornos medianos y grandes.

Para añadir usuarios o grupos, tienes que pulsar sobre el enlace de “Seleccionado”, usar el botón de “Agregar” e ir eligiendo desde el listado los usuarios y grupos que van a tener permiso para unir dispositivos. Cuando termines, confirmas con “Seleccionar” y “Aceptar”, y no olvides pulsar “Guardar” en la pantalla de dispositivos para que el cambio se aplique de verdad.

Windows Autopilot y unión controlada por el usuario

En escenarios modernos de despliegue masivo, especialmente con portátiles que se envían directamente al usuario, Windows Autopilot es una pieza clave. Uno de sus modos más utilizados es la combinación de “unión a Microsoft Entra controlada por el usuario”, que simplifica mucho el alta inicial de los dispositivos.

En este flujo, el propio usuario final, al encender el dispositivo nuevo o reseteado, sigue un asistente que termina uniendo el equipo a Microsoft Entra y, normalmente, registrándolo en Intune para su gestión. El departamento de IT no tiene que tocar físicamente la máquina, siempre que esta haya sido registrada previamente como dispositivo Autopilot.

Para poder usar Autopilot con este tipo de unión, la condición imprescindible es que los usuarios tengan permitido unir dispositivos a Microsoft Entra ID, como hemos explicado antes. Si no, el proceso reventará a mitad de camino y habrá que rehacer la configuración.

El siguiente paso en un despliegue bien organizado sería el registro de los dispositivos como Windows Autopilot, asignarles perfiles de despliegue, configurar políticas de Intune y dejarlo todo listo para que el usuario solo tenga que encender el PC, conectarse a internet y autenticarse con su cuenta corporativa.

Integrar Active Directory local con Microsoft Entra ID

Cuando tienes un entorno con Active Directory en local y quieres aprovechar Azure AD, lo más habitual es montar una arquitectura híbrida de identidades. En esta arquitectura, tu AD on-prem sigue siendo la fuente principal de identidades, pero estas se sincronizan con Microsoft Entra ID para poder usarlas en la nube.

La pieza central de esa integración es Microsoft Entra Connect (antes Azure AD Connect), que se instala en un servidor local o en una máquina virtual y se encarga de copiar la información de usuarios, grupos y otros objetos desde el AD local hacia Microsoft Entra ID.

Con Entra Connect eliges qué dominios, unidades organizativas o grupos se van a sincronizar, qué atributos se copian a la nube y con qué frecuencia se ejecutan los ciclos de sincronización. También defines el método de autenticación (PHS, PTA, federación) y, si procede, el inicio de sesión único.

En esta arquitectura de referencia suelen intervenir varios elementos: un inquilino de Microsoft Entra que recibe los datos, uno o más dominios de AD DS locales que actúan como origen, un servidor de Microsoft Entra Connect para la sincronización y, si tu aplicación lo requiere, máquinas virtuales adicionales en Azure para aplicaciones web de n niveles que usan Entra ID como proveedor de identidad.

Topologías soportadas por Microsoft Entra Connect

Uno de los puntos fuertes de Microsoft Entra Connect es que admite varias topologías de sincronización, pensadas para adaptarse a organizaciones con uno o varios bosques, e incluso con múltiples directorios de Microsoft Entra.

La topología más sencilla es la de bosque único con un único directorio de Microsoft Entra. En este caso, uno o varios dominios dentro de un mismo bosque se sincronizan con un solo inquilino de Microsoft Entra ID. Es la opción más habitual y la que se crea por defecto con la instalación exprés.

Si tienes una empresa más compleja, es posible que trabajes con varios bosques en local. En ese escenario, se puede seguir usando un único directorio de Microsoft Entra, consolidando identidades de todos los bosques y evitando duplicados mediante filtrado y configuración adecuada. Así, cada usuario termina representado solo una vez en la nube, aunque exista en varios bosques.

Hay organizaciones que necesitan mantener bosques independientes pero compartir un mismo Microsoft Entra ID; esta configuración se conoce como varios bosques con topologías independientes. Se trata de tratar cada bosque como una entidad aislada, aunque todos sincronicen contra el mismo directorio en la nube.

Otro patrón interesante es el uso de un servidor provisional o secundario de Microsoft Entra Connect Sync, que funciona en modo de almacenamiento provisional. Este servidor importa y procesa los datos, pero no los sube a Microsoft Entra hasta que se deshabilita ese modo. Es muy útil para introducir cambios de configuración, probarlos o dar alta disponibilidad a la solución.

Configuración de filtrado y sincronización de objetos

Por defecto, Microsoft Entra Connect sincroniza solo los objetos que cumplen una serie de reglas preconfiguradas para usuarios, grupos, contactos, equipos y otros tipos de objeto. Estas reglas se pueden revisar y ajustar con el Editor de reglas de sincronización.

Los objetos de usuario, por ejemplo, deben tener un atributo sourceAnchor único y el atributo accountEnabled relleno para ser candidatos a sincronización. Además, deben contar con un sAMAccountName válido y no pueden comenzar con cadenas reservadas como “Azure AD_” o “MSOL_”.

Si no quieres sincronizar todo tu directorio local tal cual, puedes aplicar filtrado por dominios, unidades organizativas, grupos o atributos específicos. Por ejemplo, podrías excluir cuentas inactivas, OUs de pruebas o usuarios que no necesitan acceso a recursos en la nube.

El filtrado por atributos te permite crear reglas más elaboradas, del tipo “sincroniza solo objetos de este dominio que tengan este valor concreto en tal atributo”. Esto te ayuda a limpiar datos y reducir la superficie de exposición en Microsoft Entra ID.

En el caso de tener varios directorios de Microsoft Entra, es imprescindible asegurarse de que cada objeto del bosque local se sincroniza solo a un directorio, para evitar conflictos de escritura y problemas con la escritura diferida de contraseñas. Para ello se usan servidores de Entra Connect independientes y un filtrado que deje conjuntos de objetos mutuamente excluyentes.

Método de inicio de sesión y experiencia del usuario

Cuando instalas Microsoft Entra Connect con la configuración rápida, lo habitual es que se habilite la sincronización de hash de contraseñas como método de inicio de sesión por defecto. Esto permite que los usuarios usen en la nube la misma contraseña que en local, con una experiencia bastante fluida.

Sin embargo, no siempre es la mejor opción. Si tu directiva de seguridad prohíbe de forma expresa sincronizar hashes de contraseña a la nube, deberías plantearte seriamente la autenticación de paso a través (PTA), que mantiene toda la validación de contraseñas en tu entorno on-premises.

Otro factor importante es el inicio de sesión único o SSO. En muchos entornos se busca que el usuario, conectándose desde máquinas unidas al dominio y en la red corporativa, no tenga que teclear credenciales una y otra vez para acceder a recursos en la nube. Esto se puede conseguir con las opciones de SSO de Microsoft Entra Connect o mediante federación con AD FS.

Si ya tienes AD FS u otro proveedor de identidad desplegado, puede tener sentido integrarlo con Microsoft Entra ID para aprovechar esa infraestructura de autenticación y mantener una experiencia de inicio de sesión homogénea entre aplicaciones locales y SaaS.

Uso del proxy de aplicaciones de Microsoft Entra

Además de la unión de equipos y la autenticación, Microsoft Entra ID te ofrece el proxy de aplicaciones, que sirve para publicar aplicaciones web locales hacia internet sin tener que abrir puertos de entrada clásicos en el firewall.

La idea es instalar un conector de proxy de aplicación en tu red interna, que abre una conexión saliente segura hacia Microsoft Entra. Las peticiones de usuarios remotos llegan a la nube, se validan con el directorio de Entra ID y, a través de ese conector, se reenvían a la aplicación web local.

Con esto consigues reducir la superficie de ataque expuesta, centralizar el control de acceso usando políticas de Entra (incluyendo MFA y acceso condicional) y dar una experiencia más integrada a los usuarios que ya están autenticados con su identidad corporativa en la nube.

Supervisión y alta disponibilidad en Microsoft Entra Connect

Para que todo este montaje funcione a largo plazo, necesitas monitorizar el estado de la sincronización y asegurarte de que, si algo se rompe, puedes recuperarte sin perder el servicio de identidades.

Microsoft Entra Connect instala un agente de Connect Health que recoge información sobre el rendimiento y los errores de sincronización. Desde el portal de Azure, en la sección de Connect Health, puedes ver alertas, gráficas y detalles técnicos para detectar problemas a tiempo.

Además del agente para la sincronización, existe el agente de Connect Health para AD DS, que se instala dentro del dominio local para supervisar el estado de los controladores de dominio y detectar incidencias en los servicios de directorio. De forma similar, el agente de Connect Health para AD FS te ayuda a monitorizar la infraestructura de federación si la tienes desplegada.

En cuanto a alta disponibilidad, una buena práctica es desplegar una segunda instancia de Microsoft Entra Connect Sync en modo de almacenamiento provisional, que sirve como servidor de contingencia. Esta instancia mantiene su propia base de datos de sincronización, pero no escribe en Microsoft Entra hasta que desactives el modo provisional, momento en el que podría asumir el rol principal.

Si decides no usar la base de datos LocalDB por defecto y optas por un SQL Server dedicado, puedes incrementar la disponibilidad usando clústeres de SQL. Algunas características, como el mirroring clásico o AlwaysOn, no están soportadas, por lo que conviene revisar bien la documentación antes de diseñar la solución.

Seguridad, acceso condicional y protección de identidades

Seguir buenas prácticas de seguridad en Microsoft Entra ID no es negociable. Las identidades son el nuevo perímetro, así que hay que proteger los inicios de sesión y el acceso a los recursos con un enfoque de riesgo y contexto.

También puedes usar el tipo de dispositivo y su estado de cumplimiento como parte de la decisión: no es lo mismo un equipo corporativo gestionado y cifrado que un PC personal sin control. Entra ID permite tener en cuenta la plataforma (Windows, iOS, Android, etc.) y si el dispositivo está o no habilitado.

Las ediciones P2 de Microsoft Entra ID incluyen Identity Protection, que utiliza algoritmos avanzados para detectar actividades de riesgo, como inicios de sesión desde ubicaciones inusuales, direcciones IP marcadas como sospechosas o dispositivos comprometedores. Con esa información se pueden generar alertas y aplicar políticas de acceso basadas en riesgo.

Otra pieza que no conviene olvidar es la gestión de contraseñas. Las ediciones P1 y P2 permiten la escritura diferida de contraseñas, de forma que los usuarios puedan hacer restablecimiento de contraseña de autoservicio desde el portal de Azure, y que ese cambio se replique hacia el AD local. Antes de activar esto, hay que revisar bien la política de contraseñas de la organización y limitar quién puede hacer cambios y cómo.

Costes, rendimiento y operación diaria

Aunque muchas de estas capacidades vienen incluidas con las licencias adecuadas, conviene revisar el impacto en costes y planificar el dimensionamiento correcto. La calculadora de precios de Azure te puede ayudar a estimar gastos en función de número de usuarios, funcionalidades avanzadas (P1/P2), uso de proxy de aplicaciones, etc.

Desde el punto de vista del rendimiento, el servicio de Microsoft Entra ID se distribuye geográficamente usando réplicas: una réplica principal donde se hacen las escrituras y varias réplicas de solo lectura repartidas por el mundo. Los cambios se propagan de forma eventual, lo que le permite escalar muy bien, dado que la mayoría de operaciones son lecturas.

Para el servidor de sincronización, debes hacerte una idea de cuántos objetos vas a sincronizar. Si tienes menos de 100.000 objetos, en general te vale con SQL Server Express LocalDB. Si superas ese volumen, se recomienda un SQL Server de producción y una instalación personalizada de Entra Connect apuntando a esa instancia.

A nivel operativo, tendrás que combinar la administración de Microsoft Entra ID desde el portal de Azure con el mantenimiento de los servidores de Entra Connect. La consola de Entra Connect te permite ajustar la configuración de sincronización, cambiar el método de inicio de sesión, activar o desactivar el modo provisional, y revisar ciertos parámetros básicos.

Además, con herramientas como Synchronization Service Manager puedes revisar el detalle de las operaciones de sincronización, lanzar ciclos manuales y gestionar los conectores hacia los distintos dominios. El editor de reglas de sincronización se usa para personalizar transformaciones de atributos, añadir nuevos objetos a sincronizar o refinar aún más el filtrado.

Al final, unir equipos a Azure AD y montar una arquitectura híbrida con Active Directory local es mucho más que marcar una casilla en Windows; implica diseñar bien el modelo de identidades, elegir con cuidado el método de autenticación, controlar quién puede unir dispositivos, vigilar la seguridad con acceso condicional e Identity Protection y asegurarse de que la sincronización con Entra Connect está bien pensada para tu topología y capacidad. Si todo esto se hace con cabeza, el resultado es un entorno robusto, flexible y preparado para el trabajo moderno, tanto dentro de la oficina como a kilómetros de distancia.