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.
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, una nueva capacidad que no se ha mencionado mucho es una que prácticamente todos mis clientes empresariales piden: La opción de servidor de preparación de Azure AD Connect. Para entender esta opción, primero revisemos la situación que está diseñada para mitigar.
Cómo funciona la sincronización de identidades de Microsoft
Esta evolución de las utilidades de sincronización - DirSync, su sucesor AADSync, y finalmente AD Connect utilizan una versión recortada del servicio de metadirectorio de Microsoft, diversamente llamado MIIS, ILM, FIM, y desde hace unos meses, Microsoft Identity Manager (MIM). Estos servicios de metadirectorio tienen conectores tanto con AD DS como con Azure AD para extraer atributos en espacios de conectores. Un conjunto de reglas de sincronización determina si estos atributos se añaden a un metaverso que contiene la unión de atributos de identidad locales y atributos 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)
Esto requiere un servidor con conectores configurados, reglas definidas y un motor de base de datos (SQL Server Express o SQL Server completo) para albergar los espacios de conectores y el metaverso. No hay tolerancia a fallos ni redundancia en esta base de datos en el servidor, y no se recomienda la agrupación en clústeres. Y si estás pensando, voy a restaurar la base de datos de las copias de seguridad que tomo que no es compatible tampoco. Básicamente, si el servidor muere tienes que desinstalar y volver a instalar el servicio de sincronización o recuperar todo el servidor a partir de copias de seguridad.
Esto no es tan malo como parece. Microsoft dice, con razón, que aunque la sincronización es sin duda un servicio de misión crítica, no es un servicio particularmente sensible al tiempo; el intervalo de sincronización por defecto y recomendado es de tres horas. Esto significa que, aunque puede llevar unas horas reconstruir el servicio de sincronización en caso de fallo, como mucho se perderá un ciclo de sincronización. Sin embargo, a las empresas de TI no les gustan las zonas grises en el tiempo de recuperación de sus sistemas de producción. En la mayoría de las grandes empresas, si se considera un sistema de alta importancia, debe tener algún tipo de tolerancia a fallos o disponibilidad mejorada. ¿Hablas en serio? es un comentario que he recibido más de una vez cuando una empresa contemplaba las capacidades de alta disponibilidad de DirSync o AADSync.
Funcionamiento de la opción del servidor de ensayo
La opción del servidor de ensayo se desarrolló para solucionar este problema. Aunque no se trata de alta disponibilidad real, la implementación de un servidor de ensayo le permitirá reanudar la sincronización de identidades en pocos minutos (una vez que haya decidido conmutar por error).
Para configurar un servidor de ensayo (Figura 2), debe realizar una configuración de Azure AD Connect idéntica a la del servidor principal de AD Connect, con una excepción: En el último paso, active la opción de servidor de ensayo. Esto impide que los resultados de sincronización desarrollados en el servicio del servidor de ensayo se escriban en Azure AD o se devuelvan a AD DS. Esto también significa que la escritura de contraseñas y la sincronización de hash de contraseñas están desactivadas, ya que la primera requiere cambios escritos en AD DS, mientras que la segunda requiere cambios escritos 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 falle el servidor principal de AD Connect, sólo tiene que volver a ejecutar el asistente de configuración de AD Connect y desmarcar la opción de servidor de ensayo (y la recuperación de contraseñas o la sincronización de hash, si las utiliza). Esto habilita las actualizaciones de Azure AD y AD DS. Obviamente, debe tener cuidado de que sólo un servidor de AD Connect esté totalmente habilitado a la vez.
La opción de servidor staging en AD Connect es una nueva capacidad que será bien recibida por las grandes empresas. Proporciona un tiempo de recuperación del servicio mucho más corto que sus predecesores y es fácil de implantar, sin requisitos especiales de hardware o software. Estoy seguro de que se convertirá en una práctica de implantación estándar para muchas empresas.
