Tutorial completo de Azure AD Connect y Microsoft Entra Connect

Azure AD Connect (ahora Microsoft Entra Connect) es la pieza clave para unir tu directorio local de Active Directory con la nube de Microsoft: Azure AD y Microsoft 365. Gracias a esta herramienta, tus usuarios pueden iniciar sesión con el mismo usuario y contraseña tanto en el entorno on‑premises como en los servicios en la nube, evitando cuentas duplicadas y reduciendo dolores de cabeza al departamento de TI.

A lo largo de este tutorial vas a ver de forma muy detallada todo el ciclo: preparación del entorno on‑premises, creación del dominio y del bosque de Active Directory, configuración de Microsoft Entra ID, instalación y configuración de Azure AD Connect, métodos de autenticación, filtrado de objetos y características avanzadas como la sincronización de hash de contraseñas, la escritura diferida o el uso de Microsoft Entra Connect Health para monitorizar la infraestructura.

¿Qué es Azure AD Connect y para qué sirve?

Azure AD Connect es la utilidad oficial de Microsoft que actúa como “puente” entre tu Active Directory local y Azure Active Directory, integrando también Microsoft 365. Permite que las identidades que ya tienes en tu dominio on‑premises se sincronicen con la nube, de modo que el usuario use las mismas credenciales en ambos mundos y, si lo deseas, disfrute de inicio de sesión único (SSO).

El cliente de Azure AD Connect se instala en un servidor miembro del dominio, y aunque técnicamente puede instalarse en un controlador de dominio, Microsoft recomienda evitarlo por seguridad y aislamiento de servicios. Este servidor será el encargado de sincronizar usuarios, grupos y otros objetos de tu AD con Azure AD a intervalos regulares.

Una vez configurado, Azure AD Connect puede utilizar diferentes modelos de autenticación: sincronización de hash de contraseñas (PHS), autenticación de paso a través (PTA), federación con AD FS o federación con proveedores como PingFederate. Además, ofrece opciones como SSO, filtrado por OU o grupos, protección frente a eliminaciones masivas y actualización automática del producto.

En escenarios en los que ya trabajas con Microsoft 365 y tienes usuarios “solo en la nube”, Azure AD Connect te permite unificar identidades: si el UPN y el correo de un usuario local coinciden con los del usuario en la nube, al sincronizar, ese usuario dejará de ser “cloud only” y pasará a ser usuario sincronizado desde AD, centralizando el gobierno de atributos en tu directorio local.

Preparación del entorno de Active Directory local

Antes de pensar en sincronizar nada con Azure, necesitas disponer de un entorno de Active Directory funcional. Si ya tienes un dominio corporativo en producción, puedes utilizarlo; si no es así, puedes levantar un laboratorio desde cero para probar todos los escenarios de identidad híbrida sin tocar tu entorno real.

La idea de este laboratorio es crear un servidor que actuará como controlador de dominio (DC) y hospedará los servicios de AD DS, DNS y las herramientas de administración. Todo ello puede montarse sobre una máquina virtual de Hyper‑V con Windows Server, utilizando scripts de PowerShell que automatizan gran parte del trabajo.

Creación de la máquina virtual para el controlador de dominio

El primer paso consiste en crear una máquina virtual que funcionará como servidor de Active Directory on‑premises. Para ello, puedes abrir PowerShell ISE como administrador en el host Hyper‑V y ejecutar un script que define nombre de la VM, switch de red, ruta del VHDX, tamaño del disco y medio de instalación (ISO de Windows Server).

En este script se crea una VM de generación 2, con memoria fija, un disco virtual nuevo y se adjunta una unidad de DVD virtual apuntando a la ISO del sistema operativo. Después se configura el firmware de la máquina para que arranque inicialmente desde el DVD y puedas realizar la instalación del sistema de forma interactiva.

Una vez creada la máquina virtual, desde el Administrador de Hyper‑V debes iniciarla, conectarte a su consola y realizar la instalación estándar de Windows Server: seleccionar idioma, introducir la clave de producto, aceptar los términos de licencia, elegir instalación personalizada y utilizar el disco recién creado. Al término de la instalación, reinicia, inicia sesión y aplica todas las actualizaciones disponibles.

Configuración inicial del servidor Windows Server

Con el sistema operativo ya implantado, hay que dejar el servidor listo para recibir el rol de Active Directory Domain Services. Esto implica asignarle un nombre coherente (por ejemplo, DC1), configurar una IP estática, definir DNS y añadir las herramientas de administración necesarias mediante características de Windows.

Mediante otro script de PowerShell puedes automatizar estas tareas: se establece la dirección IP, máscara, puerta de enlace y servidores DNS (normalmente el propio servidor y, como secundario, un DNS público como 8.8.8.8), se renombra el equipo y se instalan las RSAT de Active Directory, registrando todo en un fichero de log para auditoría.

Tras aplicar estos cambios el servidor se reinicia y quedará preparado para promoverlo a controlador de dominio de un nuevo bosque, con lo que pasarás a tener tu entorno de AD on‑premises operativo para pruebas o para integración real con la nube.

Creación del bosque y dominio de Active Directory

El siguiente paso es instalar AD DS, DNS y la Consola de Administración de Directivas de Grupo (GPMC), y después crear un nuevo bosque de Active Directory. De nuevo, PowerShell permite agilizar el proceso instalando las características necesarias y ejecutando el cmdlet Install‑ADDSForest con todos los parámetros requeridos.

En la definición del bosque indicas nombre de dominio (por ejemplo, contoso.com), nombre NetBIOS, rutas de la base de datos de AD (NTDS), de los logs y de SYSVOL, así como los niveles funcionales de dominio y bosque. También se define la contraseña del modo de restauración de servicios de directorio (DSRM), imprescindible para tareas de recuperación.

Cuando el servidor se reinicia tras la promoción, ya tienes un entorno de Windows Server AD con un dominio operativo, DNS integrado y todas las herramientas necesarias para gestionar usuarios, grupos, OU y políticas de grupo.

Creación de usuarios de prueba en Active Directory

Con el bosque funcionando, es útil disponer de cuentas de prueba para verificar la sincronización con Azure AD. A través de un script de PowerShell puedes crear, por ejemplo, el usuario “Allie McCray” con un nombre de inicio de sesión (samAccountName), contraseña inicial, nombre para mostrar y la opción de que la contraseña no caduque.

El script también puede marcar al usuario como habilitado, evitar que tenga que cambiar la contraseña en el siguiente inicio de sesión y situarlo en la ruta de contenedor adecuada (por ejemplo, CN=Users,DC=contoso,DC=com). Estos usuarios serán posteriormente sincronizados con Microsoft Entra ID mediante Azure AD Connect.

Preparación del dominio local para la sincronización

Antes de desplegar Azure AD Connect conviene revisar tu AD para asegurarte de que cumple los requisitos de Microsoft: dominios bien configurados, sufijos UPN adecuados, atributos de correo coherentes y sin datos conflictivos. Para esta tarea, Microsoft ofrece la herramienta IdFix, que ayuda a detectar objetos problemáticos.

En muchos entornos existe un dominio local del tipo mydominio.local y, por otro lado, un dominio público de correo, por ejemplo mydominio.com utilizado en Microsoft 365. Para que la sincronización sea limpia, es recomendable agregar al AD local el sufijo UPN correspondiente al dominio de correo público.

Desde “Dominios y confianzas de Active Directory” puedes abrir las propiedades y añadir el nuevo sufijo UPN (por ejemplo, mydominio.com). Posteriormente, en las propiedades de las cuentas de usuario, en la pestaña “Cuenta”, cambias el UPN de usuario para que pase de usuario@mydominio.local a usuario@mydominio.com, alineándolo así con la dirección de correo en Microsoft 365.

Aunque cambiar el UPN es altamente recomendable para facilitar posteriores logins y un eventual SSO, este cambio no modifica el método de inicio de sesión clásico DOMINIO\usuario (pre‑Windows 2000), por lo que no afecta a aplicaciones o scripts que sigan usando ese formato.

También es importante rellenar correctamente el atributo mail de las cuentas de usuario con su dirección de correo principal. Si ya tienes usuarios creados directamente en la nube, la combinación de UPN y mail coincidente entre on‑premises y Microsoft 365 permitirá que, tras la sincronización, esas cuentas se unan y el usuario cloud pase a ser una identidad sincronizada desde AD.

Alta y configuración de Microsoft Entra ID (Azure AD)

Para que el directorio local pueda sincronizarse necesitas disponer de un inquilino (tenant) de Microsoft Entra ID. Este tenant es el directorio en la nube donde se crearán las réplicas de tus usuarios, grupos y dispositivos procedentes del entorno on‑premises.

Si aún no tienes un tenant, puedes crearlo accediendo al Centro de administración de Microsoft Entra con una cuenta que posea la suscripción. Desde la sección de Información general eliges la opción de administrar inquilinos y luego crear uno nuevo, proporcionando un nombre para la organización y un dominio inicial (por ejemplo, algo.onmicrosoft.com).

Una vez finalizado el asistente, el directorio queda creado y puedes administrarlo desde el portal. Más adelante podrás asociar dominios personalizados (como contoso.com) y verificarlos para usarlos como principales en los UPN de tus usuarios sincronizados desde AD.

Creación de una cuenta administradora de identidades híbridas

En el tenant de Microsoft Entra es recomendable crear una cuenta dedicada para gestionar la parte híbrida. Esta cuenta se usará, por ejemplo, para la configuración inicial de Azure AD Connect y las tareas relacionadas con identidad.

Desde el apartado de Usuarios creas un nuevo usuario, le asignas un nombre y un nombre de usuario (UPN) y cambias su rol a “Administrador de identidad híbrida”. Durante la creación puedes ver y copiar la contraseña temporal que se le asigna.

Tras crear esta cuenta, conviene iniciar sesión en myapps.microsoft.com con ese usuario y la contraseña temporal, forzando el cambio de contraseña por una definitiva. Esta será la identidad de administración que usarás en varios de los pasos de configuración híbrida.

Instalación de Azure AD Connect (Microsoft Entra Connect)

Con el entorno local listo y el tenant en la nube preparado, ya puedes instalar Azure AD Connect en un servidor miembro del dominio local. Microsoft recomienda no usar un controlador de dominio para minimizar riesgos de seguridad y de disponibilidad.

La descarga de Azure AD Connect está disponible desde el portal de Azure Active Directory, en la sección de Azure AD Connect, o directamente desde el Centro de descargas de Microsoft. Una vez descargado el instalador, lo ejecutas en el servidor designado.

Durante el asistente de instalación se aceptan los términos de licencia y tienes dos caminos: configuración rápida o personalizada. La opción rápida configura por defecto la sincronización completa de AD utilizando el método de “sincronización de hash de contraseñas”, mientras que la personalizada permite un control mucho mayor sobre atributos, dominios, OU, métodos de autenticación y características adicionales.

En instalaciones habituales suele resultar más interesante elegir la ruta personalizada, sobre todo si necesitas limitar qué unidades organizativas se sincronizan, quieres evaluar diferentes métodos de inicio de sesión o tienes topologías de varios bosques.

Configuración del método de inicio de sesión

Uno de los puntos clave en el asistente es la elección del método de autenticación que utilizarán tus usuarios al acceder a recursos en la nube. Azure AD Connect ofrece varias opciones integradas, cada una con sus ventajas y requisitos.

1. Sincronización de hash de contraseñas (PHS): este método sincroniza con Azure AD un hash adicional de la contraseña almacenada en tu Active Directory on‑premises. El usuario inicia sesión en la nube directamente contra Azure AD, usando la misma contraseña que en el entorno local, pero solo administrada en AD. Es el modelo más simple de implantar y el más utilizado.

2. Autenticación de paso a través (PTA): en este caso, las contraseñas no se almacenan en Azure AD; cuando el usuario intenta iniciar sesión, la validación se reenvía mediante agentes instalados on‑premises que comprueban las credenciales contra el AD local. Permite aplicar restricciones de acceso locales, horarios, etc., manteniendo el control de autenticación en tu infraestructura.

3. Federación con AD FS: Azure AD delega la autenticación en un sistema de federación basado en Active Directory Federation Services. Requiere desplegar servidores AD FS y, normalmente, un proxy de aplicación web. Es más complejo de mantener, pero ofrece máximo control y compatibilidad con escenarios avanzados.

4. Federación con PingFederate: similar al caso anterior, pero usando PingFederate como solución de federación en lugar de AD FS, para organizaciones que ya disponen de esa infraestructura de identidad.

5. No configurar método de inicio de sesión: pensada para cuando ya tienes una solución de federación de terceros y no quieres que Azure AD Connect automatice nada en esta parte.

Adicionalmente puedes activar el inicio de sesión único (SSO) en combinación con PHS o PTA. Con SSO habilitado, y mediante una política de grupo (GPO), los equipos unidos al dominio pueden iniciar sesión utilizando el UPN del usuario, normalmente igual que su dirección de correo electrónico, evitando que tenga que introducir repetidamente sus credenciales al acceder a servicios como el portal de Microsoft 365.

Conexión con Microsoft 365 y el AD local

En el asistente de Azure AD Connect tendrás que proporcionar primero las credenciales de un administrador del tenant de Microsoft Entra (por ejemplo, la cuenta de administrador de identidad híbrida creada antes). Esto permite que la herramienta configure la parte en la nube y registre el servidor como origen de sincronización.

Después se solicitan credenciales de una cuenta con permisos en el AD local para crear el vínculo de sincronización con el bosque on‑premises. Una vez validadas, se añade el directorio local a la lista de orígenes de datos para sincronización.

En el siguiente paso eliges qué atributo usar como nombre de usuario principal para las cuentas en la nube. Lo habitual es usar userPrincipalName, pero en algunos escenarios puedes optar por el campo mail si lo tienes homogéneo y bien configurado. También puedes indicar si vas a continuar sin tener aún todos los dominios UPN verificados en Azure AD (útil cuando el dominio de AD es privado).

Selección de OU y filtrado de objetos

Azure AD Connect permite definir qué subconjunto de tu bosque de Active Directory se sincroniza con la nube. Puedes seleccionar dominios completos, unidades organizativas concretas o incluso filtrar por atributos para reducir el alcance.

En la práctica suele ser buena idea comenzar sincronizando solo las OU donde residen los usuarios que participan en el piloto, o utilizar un grupo de seguridad específico cuyos miembros se replicarán en Azure AD. Así reduces riesgos de sincronizar cuentas de servicio, objetos obsoletos o información que no debe abandonar el entorno on‑premises.

Conviene tener en cuenta que cambios posteriores en la estructura de OU (renombrar, mover contenedores, etc.) pueden afectar al filtrado. Una estrategia común es sincronizar todo el dominio pero restringir por pertenencia a grupos, evitando depender en exceso de la estructura organizativa.

Opciones adicionales de configuración

En las pantallas finales del asistente se ofrecen funciones complementarias, como la escritura diferida de contraseñas (password writeback), la reescritura de dispositivos, la integración con Exchange híbrido o la protección frente a eliminaciones masivas.

La escritura diferida de contraseñas permite que los usuarios cambien o restablezcan su contraseña desde la nube (por ejemplo, desde el portal de autoservicio) y que ese cambio se aplique también en el AD local, respetando la directiva de contraseñas de la organización. Para muchas empresas es una ventaja interesante de cara a soporte.

La reescritura de dispositivos hace posible que los dispositivos registrados en Microsoft Entra ID se vuelquen de nuevo al Active Directory local, lo cual facilita escenarios de acceso condicional donde necesitas tener constancia de los dispositivos en ambos lados.

La característica de evitar eliminaciones accidentales está activada por defecto y limita el número de objetos que se pueden eliminar en una misma ejecución de sincronización (por ejemplo, a 500). Si se supera ese umbral, la sincronización se bloquea para evitar borrados masivos por error, algo fundamental en entornos grandes.

Por último, la actualización automática se habilita de serie en instalaciones con configuración rápida y mantiene Azure AD Connect al día con las últimas versiones, corrigiendo errores y añadiendo compatibilidades sin que tengas que actualizar manualmente cada servidor.

Verificación de la sincronización y operación diaria

Tras completar la instalación y el asistente, Azure AD Connect puede iniciar inmediatamente una sincronización completa si así lo has indicado. El propio asistente da la opción de lanzar un ciclo inicial en cuanto termina, lo cual es recomendable para validar que todo está funcionando.

En el servidor donde instalaste Azure AD Connect puedes abrir la consola “Servicio de sincronización” desde el menú de inicio. Allí verás el historial de ejecuciones, incluyendo la sincronización inicial, posibles errores y el detalle de importación, sincronización y exportación de objetos.

En el portal de Microsoft 365 o en el de Microsoft Entra puedes revisar la lista de usuarios para comprobar que están apareciendo como “Sincronizados con Active Directory” en lugar de “Solo en la nube”. Desde ese momento, los atributos principales (nombre, apellidos, dirección de correo, etc.) se gestionan desde el AD local.

Azure AD Connect ejecuta por defecto un ciclo de sincronización cada 30 minutos, aunque siempre puedes forzar uno manualmente mediante PowerShell si necesitas que un cambio se refleje de inmediato. Es buena práctica documentar este comportamiento para que el equipo de soporte sepa qué esperar.

Escenarios avanzados: varios bosques y servidores adicionales

En organizaciones más complejas puedes encontrarte con varios bosques de Active Directory, cada uno con su propio dominio y usuarios. También puede haber bosques de recursos donde residen buzones de correo vinculados u otros servicios.

Azure AD Connect está preparado para estas topologías, permitiendo agregar múltiples bosques como orígenes de sincronización y aplicar un modelo de aprovisionamiento declarativo. Esto significa que las reglas de combinación, transformación y flujo de atributos se definen de forma declarativa y pueden ajustarse para encajar con tu diseño de identidades.

Para laboratorios más avanzados se puede crear un segundo bosque (por ejemplo, fabrikam.com) con su propio controlador de dominio (CP1), repitiendo los pasos de creación de VM, instalación de sistema, configuración de IP y DNS, promoción a DC y creación de usuarios de prueba. Así se prueban escenarios de multi‑bosque y sincronización en la nube con distintos dominios.

En entornos de producción es recomendable contar con un servidor de Azure AD Connect en espera o en modo provisional. El servidor en modo staging mantiene una copia de la configuración y realiza importación y sincronización interna, pero no exporta cambios a Azure AD. En caso de fallo del servidor principal, puedes conmutar al servidor en staging con un impacto mínimo.

Microsoft Entra Connect Health: supervisión y alertas

Para mantener bajo control la infraestructura de identidad híbrida, Microsoft ofrece Microsoft Entra Connect Health, una solución premium que monitoriza componentes clave como Azure AD Connect (sincronización), AD FS y AD DS, proporcionando alertas, métricas de rendimiento y análisis de uso.

El funcionamiento se basa en agentes que instalas en los servidores de identidad: servidores AD FS, controladores de dominio y servidores de Azure AD Connect. Estos agentes envían información de estado y rendimiento al servicio en la nube, donde puedes visualizarla en el portal específico de Connect Health.

Para comenzar necesitas disponer de licencias de Microsoft Entra ID P1 o P2 (o una prueba). Después descargas los agentes de Connect Health desde el portal y los instalas en cada servidor relevante. Una vez registrados, el servicio detecta automáticamente qué roles se están monitorizando.

En el portal de Connect Health encontrarás diferentes paneles: uno para los servicios de sincronización (Azure AD Connect), otro para los servicios de federación (AD FS) y otro para los bosques de AD DS. En cada uno puedes ver alertas activas, estado de réplica, posibles problemas de certificados, errores de autenticación y tendencias de uso.

Además de la parte técnica, Connect Health incluye opciones para configurar el acceso basado en roles (IAM) y, opcionalmente, autorizar a Microsoft a acceder a los datos de diagnóstico solo con fines de soporte. Esta opción está deshabilitada por defecto, pero puede ser útil si necesitas asistencia avanzada de Microsoft para resolver incidencias complejas.

Con todo este ecosistema configurado —AD local, Microsoft Entra ID, Azure AD Connect y Connect Health— dispones de una plataforma de identidad híbrida completa, capaz de ofrecer inicio de sesión único, gobierno centralizado de cuentas y contraseñas, alta disponibilidad y visibilidad sobre el estado de la infraestructura; una combinación que simplifica la vida al usuario final y te da a ti el control que necesitas para operar con seguridad y flexibilidad.