Microsoft sigue trabajando en un punto delicado de su estrategia de identidad híbrida: El reto de desplegar su puente de identidad entre Active Directory Domain Services (AD DS) en local y Azure Active Directory en la nube. Este puente consiste en AD FS para la federación y una sucesión de utilidades, que culminan en Azure AD Connect, para la sincronización de identidades. Azure AD Connect se ha puesto recientemente a disposición general, y hace que la experiencia de conectar su AD DS local (y otros tipos de bases de datos de identidad como SQL Server o LDAP) a Azure AD sea más fácil que sus predecesores DirSync y Azure AD Sync.
Las nuevas funciones de AD Connect
AD Connect (puede obtener más información aquí) es una utilidad de configuración que simplifica la configuración de la sincronización de identidades entre una breve lista de fuentes de identidad populares (incluidos los Servicios de dominio de Active Directory, por supuesto) y, opcionalmente, el inicio de sesión único con AD FS. Simplifica en gran medida el proceso de configuración, y también proporciona nuevas capacidades como la escritura de atributos relacionados con dispositivos desde Azure AD a AD DS.
Sin embargo, hay una nueva funcionalidad de la que no se ha hablado mucho y que, sin embargo, solicitan prácticamente todos mis clientes empresariales: la opción del servidor de preparación de Azure AD Connect. Para entender esta opción, repasemos primero la situación que está pensada para mitigar.
Cómo funciona la sincronización de identidades de Microsoft
Esta evolución de las herramientas de sincronización —DirSync, su sucesor AADSync y, por último, AD Connect— utiliza una versión simplificada del servicio de metadirectorio de Microsoft, conocido con diversos nombres: MIIS, ILM, FIM y, desde hace unos meses, Microsoft Identity Manager (MIM). Estos servicios de metadirectorio cuentan con conectores tanto para AD DS como para Azure AD, que permiten extraer atributos e incorporarlos a los espacios de los conectores. Un conjunto de reglas de sincronización determina si estos atributos se añaden a un metaverso que contiene la unión tanto de los atributos de identidad locales como de los de Azure AD. Por último, las reglas de sincronización de salida determinan qué atributos se escriben en Azure AD.
Figura 1: Arquitectura del servicio AD Connect (Imagen cortesía de Microsoft)
Para ello se necesita un servidor con los conectores configurados, las reglas definidas y un motor de base de datos (SQL Server Express o SQL Server completo) que aloje los espacios de los conectores y el metaverso. Esta base de datos en el servidor no incorpora tolerancia a fallos ni redundancia, y no se recomienda la creación de clústeres. Y si estás pensando: «Bueno, pues restauraré la base de datos a partir de las copias de seguridad que hago», eso tampoco es compatible. Básicamente, si el servidor deja de funcionar, tendrás que desinstalar y volver a instalar el servicio de sincronización o recuperar todo el servidor a partir de las copias de seguridad.
Esto no es tan grave como parece. Microsoft afirma, con razón, que, aunque la sincronización es sin duda un servicio crítico, no es un servicio especialmente urgente; el intervalo de sincronización predeterminado y recomendado es de tres horas. Esto significa que, aunque pueda tardar unas horas en restablecerse el servicio de sincronización en caso de fallo, lo más probable es que, como mucho, te pierdas un ciclo de sincronización. Sin embargo, a los departamentos de TI de las empresas no les gustan las zonas grises en cuanto al tiempo de recuperación de sus sistemas de producción. En la mayoría de las grandes empresas, si se considera que un sistema es de alta importancia, debe incorporar algún tipo de tolerancia a fallos o disponibilidad mejorada. «¿En serio?» es un comentario que he recibido más de una vez cuando una empresa se planteaba las capacidades de alta disponibilidad de DirSync o AADSync.
Funcionamiento de la opción del servidor de ensayo
La opción del servidor de prueba se desarrolló para solucionar esta deficiencia. Aunque no se trata de una verdadera alta disponibilidad, la implementación del servidor de prueba te permitirá reanudar la sincronización de identidades en pocos minutos (una vez que hayas decidido realizar la conmutación por error a dicho servidor).
Para configurar un servidor de prueba (Figura 2), hay que seguir el mismo proceso de configuración de Azure AD Connect que se realizó para el servidor AD Connect principal, con una excepción: en el último paso, hay que marcar la opción de servidor de prueba. Esto evita que los resultados de la sincronización generados en el servicio del servidor de prueba se escriban en Azure AD o se reenvíen a AD DS. Esto también significa que la reescritura de contraseñas y la sincronización de hash de contraseñas quedan desactivadas, ya que la primera requiere que los cambios se escriban en AD DS, mientras que la segunda requiere que los cambios se escriban en Azure AD.
Figura 2: Arquitectura de AD Connect con servidor de ensayo
Recuperación de un fallo de AD Connect
En caso de que se produzca un fallo en el servidor principal de AD Connect, solo tienes que volver a ejecutar el asistente de configuración de AD Connect y desmarcar la opción del servidor de ensayo (así como la de reescritura de contraseñas o la sincronización de hash, si las estás utilizando). De este modo, se habilitarán las actualizaciones en Azure AD y AD DS. ¡Por supuesto, debes asegurarte de que solo haya un servidor de AD Connect totalmente habilitado en cada momento!
La opción de servidor de prueba de AD Connect es una nueva funcionalidad que será muy bien acogida por las grandes empresas. Ofrece un tiempo de recuperación del servicio mucho más corto que sus versiones anteriores y es fácil de implementar, sin requisitos especiales de hardware ni software. Estoy seguro de que se convertirá en una práctica de implementación habitual para muchas empresas.
