Desmitificando entornos híbridos con Office 365

Comenzando con esta línea de “desmitificar” Office 365, hace un tiempo escribí varios artículos enfocados específicamente en el profesional de TI haciendo la transición de conocimiento a “la nube”.

Esto por cuestiones de proyectos y otros emprendimientos fue quedando de lado y ahora lo estoy retomando con una nueva serie de artículos.

Para quienes recién comienzan con este tema hay varios conceptos importantes a repasar que se incluyen en el artículo de Introducción a Office 365.

En este artículo vemos:

• Qué es un Tenant de Office 365?
• Identidades en Office 365 (solo nube, sincronizada y federada)
• Planes básicos de Office 365

Luego de este artículo y dado que el foco inicial del sitio era Exchange On Premises, tenía sentido dedicar un artículo a su versión en nube, es decir Exchange Online.

El artículo se denomina “Qué es Exchange Online?” (sorprendente el nombre, lo sé :-) ) y tocamos los siguientes temas:

• Qué es Exchange Online y relación con Azure AD
• Planes específicos de Exchange Online
• Exchange Online Protection (EOP)
• Opciones de implementación
• Conviene migrar a Exchange Online?

En este punto ya tendríamos una buena idea de qué incluye Office 365, Exchange Online, opciones de implementación y si es conveniente hacer la transición.

Luego tenemos otra cuestión relacionada, Qué es una implementación híbrida de Exchange?.

En este artículo vemos lo siguiente:

• Qué es una implementación híbrida?
• Beneficios de una implementación híbrida
• Componentes principales en una implementación híbrida
• En qué tipo de organización es conveniente configurar Exchange híbrido?
• Escenario de organización típica antes y después de configurar un híbrido
• Proceso macro de configuración híbrida

Ya teniendo más claro el tema, profundizamos un poco más en un concepto para nada menor como es el de “autodiscover”.

En este caso tenemos el artículo de “Autodiscover con Exchange Híbrido”, en este vemos:

• Para qué usar Autodiscover?
• Qué pasa cuando una organización tiene buzones On Premises y en Exchange Online?
• A dónde se debe apuntar el registro DNS de Autodiscover?
• Qué pasa en el caso de que se migren todos los buzones a la nube? Se debe modificar el registro DNS de Autodiscover?

A esta altura desde el punto de vista de conceptual y pensando en el profesional de TI que tiene que hacer frente a diversas situaciones, se podría decir que ya tendría información suficiente como para tener una idea sobre lo que implica la transición, si tiene sentido para la organización o cliente y consideraciones básicas.

Por otro lado y si bien no se encuentra exclusivamente relacionado con temas de infraestructura, tenemos herramientas de colaboración que extienden las posibilidades actuales de un entorno 100% On Premises. Esto sería lo que podríamos decir más visible para los usuarios, en el sentido de que es fácil ver “qué ganan” con esta transición, cosa difícil de equiparar incluso en el mejor de los escenarios On Premises.

En este punto entramos en el tema de Grupos de Office 365, lo que en primer instancia no suena muy atractivo, pero estos no son los grupos convencionales a los que estábamos acostumbrados antes de todo este tema.

En el artículo de “Colaboración con Grupos de Office 365” vemos lo siguiente:

• Qué son los Grupos de Office 365?
• Qué incluye un Grupo de Office 365?
• Colaboración básica
• Selección de herramientas (Planner y Teams entre otros)

Bien, hasta acá llegamos con la introducción, un poco larga quizás pero la idea es hacer una nivelación de conocimientos antes de avanzar con lo que se viene.

En este sentido y partiendo de la base de qué ya tenemos claro los conceptos manejados en los artículos listados anteriormente, comenzamos con esta serie (si, recién estamos comenzando :-), veamos a donde nos lleva… ).

La idea es la siguiente, cada día son más las organizaciones que están migrando a Office 365 o haciendo la integración, de hecho al día de hoy se me ocurren pocos clientes que continúan 100% On Premises, la mayoría ya están en un estado híbrido. Entiendo que puede ser complejo adaptar el pensamiento a esta situación, conozco muchos técnicos y consultores que únicamente se centran en temas On Premises, de hecho me llevo un buen tiempo adaptarme a esto (con mucha resistencia de por medio), pero la realidad es que es necesario aprender a trabajar en este tipo de entornos para mantenerse relevante en la industria (esto independientemente de si la organización para la que uno trabaja actualmente tiene planes o no de migrar).

Esto ya no es el futuro sino que es lo que se maneja en el mercado y para muchas empresas pasar completamente a la nube tampoco es algo viable, pero implementar un híbrido puede ofrecer múltiples beneficios si lo hacemos de forma estratégica.

Así que sin mucho más comenzamos con el tema de esta primer parte de la serie.

Autenticación y sincronización de directorio en entornos Híbridos

La implementación de un entorno híbrido implica entre otras cosas la sincronización del directorio, la idea es que las identidades On Premises (por ejemplo en Active Directory) sean sincronizadas con Azure Active Directory.

Si bien las herramientas utilizadas para la sincronización han ido evolucionando (incluso el nombre, en algunos lugares todavía se escucha que hagan referencia a Dirsync cuando en realidad esta herramienta ya no existe), actualmente usamos Azure AD Connect.

Entonces, para sincronizar las identidades On Premises usamos Azure AD Connect, la configuración específica de este componente la vemos en el Taller intensivo de migración Híbrida, en esta parte quiero tratar algunos aspectos básicos de diseño, incluyendo las distintas variantes para manejar la autenticación de estas identidades (a tener en cuenta que “identidades” no solo abarca usuarios, por eso el término «identidades»).

Dentro de las opciones para el manejo de autenticación tenemos las siguientes:

• Sincronización de directorio y contraseñas (PHS: Password Hash Synchronization)
• Sincronización de directorio con autenticación Pass-Through (PTA: Pass Through Autentication)
• Sincronización de directorio con Federación (ADFS: Active Directory Federation Services)

Por fuera de esto hay alternativas de terceros pero en principio estarían orientadas a situaciones muy especificas con requerimientos muy particulares.

Lo que vamos a encontrar en el mercado es una de estas 3 opciones y los conceptos básicos se mencionan en el artículo de Introducción a Office 365.

En cualquiera de los casos las identidades se manejan desde el directorio On Premises para luego ser sincronizadas con Azure AD.

El directorio On Premises (en general Active Directory y de ahora en más así lo voy a tratar) es la fuente autoritativa de estos cambios por lo que salvo por el caso de atributos muy específicos y exclusivos a Azure (o casos particulares como por ejemplo SSRP: Self Service Password Reset), el resto se maneja desde herramientas On Premises (si se intenta hacer con herramientas en la nube, o aparecen las opciones en gris o devuelve un error).

Entonces, en el caso de identidades sincronizadas, el origen autoritativo es Active Directory, lo que entre otras cosas simplifica la administración y habilita la posibilidad ya sea de SSO (Single Sign On) o una experiencia similar lo que se traduce en que el usuario use la misma contraseña para acceder recursos On Premises así como recursos en la nube.

En cuanto al modelo de autenticación a seleccionar, esto al final va a depender de los requerimientos de la organización, pero de ser posible la idea es ir por la opción más simple. En complemento es posible una combinación o utilizar por ejemplo PHS como mecanismo secundario. De esta forma se podría usar PTA o ADFS y si esto falla hacer ajustes para pasar a usar PHS como mecanismo primario ya teniendo las contraseñas sincronizadas.

Sincronización de hash de contraseñas (PHS)

Este es el caso más común de encontrar y el más simple de manejar.

Este modelo ofrece varias ventajas, comenzando por el hecho de que la autenticación para acceder a recursos de Azure AD / Office 365 no depende de la infraestructura On Premises.

Esto significa que incluso con Active Directory caído o el servidor de sincronización fuera de servicio (Azure AD Connect), mientras el usuario tenga acceso a Internet puede autenticarse y acceder a los recursos en nube, por ejemplo su buzón en Exchange Online, Teams, etc.

Esto es así porque si bien el usuario maneja una única identidad y contraseña, técnicamente hay 2 identidades y 2 contraseñas, el tema es que están sincronizadas.

Supongamos que el usuario cambia la contraseña en Active Directory y el servidor con AD Connect queda fuera de servicio antes de sincronizar este cambio. En este caso:

• El usuario puede acceder a los recursos On Premises con la nueva contraseña
• El usuario puede acceder a los recursos en Office 365 con la contraseña anterior

Esta situación persistiría hasta que el servidor con AD Connect reanude el correcto funcionamiento.

Por otro lado este modelo tiene también algunas desventajas ya que hay controles que en principio no podríamos aplicar como por ejemplo restricciones de inicio de sesión en base a horario.

Autenticación Pass-Through (PTA)

En este caso las identidades son sincronizadas con la nube y opcionalmente también las contraseñas.

La diferencia respecto al modelo anterior es que los usuarios no se autentican usando la contraseña sincronizada sino que depende de la infraestructura On Premises lo que aparte de Active Directory y AD Connect, también incluiría un agente dedicado a esto.

La idea es que la validación suceda On Premises, si el agente se encuentra fuera de servicio esto no sería posible y en consecuencia el usuario no podría acceder a los recursos en la nube. Esto implica que como mínimo sea necesario incluir un agente adicional aparte del incluido en el servidor donde se instale Azure AD Connect.

La ventaja en este caso es que hay cuestiones que son más inmediatas, por ejemplo el usuario si cambia la contraseña no es necesario que esta sea sincronizada para que surta efecto porque la validación desde un principio es realizada On Premises.

Otro beneficio de este modelo es la posibilidad de aplicar restricciones sobre las cuentas (como por ejemplo de hora) o de cualquier otro tipo, porque como se mencionó la validación es On Premises.

Autenticación con Active Directory Federation Services (ADFS)

En este modelo también usamos Azure AD Connect y aparte entran en juego varios roles más orientados a soportar la federación.

Esto en principio implica 4 servidores por cuestiones de que la autenticación en este caso sea realiza On Premises (sea un recurso On Premises o en nube), si los servidores dedicados a la federación se encuentran fuera de servicio no sería posible acceder a los recursos en Office 365.

Estos 4 servidores estarían divididos en:

• 2 para la DMZ publicando ADFS hacia Internet usando WAP (Web Application Proxy)
• 2 servidores con ADFS instalados en la red interna

Las ventajas de ADFS incluyen la posibilidad de aplicar restricciones sobre las cuentas como en el caso con PTA y aparte el uso de políticas específicas a ADFS.

El problema principal con este modelo es la cantidad de dependencias y la complejidad. No solo implica más recursos a nivel de hardware, también requiere conocimientos específicos para administrar el servicio.

En otra época (antes de que existiera PTA y otras características complementarias que voy a tratar más adelante en esta serie como Seamless Single Sign On) podía ser muy válido ir por esta opción pero la realidad es que en este momento salvo que ya exista una infraestructura de ADFS montada para otros servicios (lo que implica que ya se cuenta con el hardware y conocimiento sobre ADFS) difícilmente esta sea la opción más conveniente.

Qué considerar antes de seleccionar un modelo de autenticación y qué se encuentra más en clientes?

Para seleccionar el modelo de autenticación más adecuado, primero es necesario conocer a fondo los requerimientos de la organización, en principio habrían varias cuestiones:

• Cuáles son los planes? Mantener un híbrido o migrar completamente a la nube?. Esta podría ser la situación de una pequeña empresa, rara vez aplicaría a una empresa mediana o grande.
• Se cuenta con una infraestructura en Alta Disponibilidad y Contingencia?. En este sentido la duda sería la siguiente, sabemos que en el caso de PTA o ADFS se depende de que Active Directory este funcionando + el agente de PTA en el caso de usar Pass-Through o + servidores de ADFS funcionando (estos podrían estar en Azure por ejemplo).
• Se cuenta con disponibilidad de recursos de hardware para implementar servidores adicionales por ejemplo para ADFS?
• Se cuenta con staff con los conocimientos necesario para implementar y mantener una infraestructura de ADFS?
• Existe un requerimiento específico que no pueda ser alcanzado usando PTA o PHS?

Si pienso en proyectos de integración o migración realizados en los últimos años, podría decir que aproximadamente el 90% ha sido con sincronización de contraseñas (PHS) complementando con Seamless Single Sign On (esto permite que usuarios conectados a equipos dentro del dominio puedan autenticarse directamente sin necesidad de ingresar credenciales). Esto último también funciona con PTA.

En definitiva, lo ideal sería ir por PHS con Seamless SSO, en caso de no poder ir por esta opción, PTA (con Seamless SSO) y por último ADFS o alternativas de terceros.

---

Con esto llegamos al final de la primer parte de esta serie de artículos, para no perderte ninguna novedad podes registrarte sin costo a los boletines del sitio y/o seguirnos en nuestra página de Facebook.