Last Updated on 22 agosto, 2017 by Pablo Ariel Di Loreto
Office 365 permite configurar tres modelos de identificación para el acceso a sus servicios. Estos modelos de identidad impactan en la experiencia que el usuario tenga y de las credenciales que utilizará al momento de ingresar a Exchange Online, SharePoint Online, Lync Online o inclusive otros servicios de Microsoft Online Services tales como Windows Intune.
En este artículo vamos a hacer el mejor esfuerzo por explicar los tres modelos existentes, cómo impactan en la experiencia del usuario y ventajas y desventajas de cada uno.
Tabla de Contenidos
Introducción
Objetivo y Alcance
Esta publicación tiene como objetivo mostrar qué alternativas tienen las organizaciones y administradores de IT en relación a configuraciones de Office 365 y gestión de identidades.
En este sentido, vamos a hacer una recorrida por los tres modelos existentes actualmente: Identidad en la nube [Cloud Identity], Identidad Sincronizada [Synchronized Identity] e Identidad Federada [Federated Identity].
Audiencia
Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en aprender nuevas cosas.
Comentarios y Corrección de Errores
Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.
Desarrollo
En el momento de comenzar a trabajar en un proyecto de Office 365, uno de los temas centrales en el Planeamiento es la gestión de identidades. En este sentido surgen las siguientes preguntas:
- ¿Con que usuario y password se loguearán los usuarios?
- ¿Si cambio la contraseña en mi infraestructura de Active Directory se cambia en la «nube»?
- ¿Puedo utilizar funcionalidades de SSO, de modo tal que si inciaron sesión en la infraestructura local no deban poner usuario y password en la nube?
- ¿Debo sí o sí vincular mi infraestructura local con la nube?
Para poder aclarar todo esto, vamos a explicar las tres posibilidades de identidad que existen hoy con Office 365. Cuando hablamos de posibilidades de identidad, nos referimos a cómo Office 365 gestionará quién soy y que características tengo, no donde estoy autorizado a ingresar (eso sería gestión de la autorización).
Las actuales posibilidades de Office 365 en este sentido son actualmente las que están expresadas en el siguiente gráfico:
Ilustración 1 – Opciones de Identidades de Office 365.
Por supuesto, seguramente para administradores que no están familiarizados con esto el gráfico producirá más dudas que certezas. No obstante, vamos a analizar por separado cada una de las posibilidades, contextualizarlas, y luego compararlas.
Opción 1: Identidad en la nube [Cloud Identity]
Esta opción de identidad es la que, por defecto, se habilita cuando creamos una cuenta en Office 365. En primera instancia, Office 365 tiene reservada una partición de Azure Directory Services aislada donde se alojarán los datos de nuestros usuarios, o más formalmente nuestros objetos usuario.
En este caso, la contraseña es gestionada por Azure Directory Services y no tiene relación absoluta con nuestra infraestructura on-promises. De hecho, tampoco nuestro UPN de usuario tiene relación con nuestra infraestructura on-promises, y de hecho (finalmente) debemos dar de alta los usuarios uno por uno, dado que por default nuestro espacio en Office 365 se crea sin usuarios (o con uno, que es el administrador).
Este escenario es muy comúnmente utilizado en organizaciones pequeñas y medianas que no tienen o no quieren utilizar su servicio de directorio local como autenticación, y tampoco les interesa brindarle a sus usuarios una experiencia consistente entre la contraseña utilizada en su infraestructura on-promises y la de los servicios en la nube.
Un aspecto importante, presente en las tres opciones, es que el usuario de la nube deberá tener formato de correo electrónico (UPN de usuario), y por defecto Microsoft nos proporciona uno válido públicamente como subdominio de «onmicrosoft.com». Por ejemplo, si nuestra empresa es dada de alta como «MiEmpresa», el UPN por defecto (salvo que lo cambiemos) será «MiEmpresa.onmicrosoft.com», y los usuarios iniciarán sesión con el formato «usuario@MiEmpresa.onmicrosoft.com» para ingresar a los servicios en la nube. Esto no implica, sin embargo, que la infraestructura local deba sufrir cambios en el caso que se utilice un UPN local (MiEmpresa.local por ejemplo o uno no registrado en forma pública).
Opción 2: Identidad Sincronizada [Synchronized Identity]
Esta opción es la primera que, de alguna forma, relaciona nuestro servicio de directorio local (Active Directory Domain Services) con el servicio de directorio en la nube (Azure Directory Services).
Haciendo uso de un software proporcionado por Microsoft, llamado DirSync (Directory Sinchronization, que forma parte de la familia de productos FIM), podemos sincronizar objetos (usuarios, contactos y grupos) desde nuestro Active Directory Domain Services (local) hacia la partición del servicio de directorio en la nube (Azure Directory Services).
Como consecuencia, los objetos sincronizados estarán también presentes en Office 365 y podrán ser consumidos. Adicionalmente, el DirSync nos permite sincronizar las contraseñas de los usuarios, lo cual permite a los usuarios acceder a los servicios de Microsoft Online Services que utilicen Azure Directory Services (como Office 365, InTune, CRM Online, etc) puedan utilizar la misma contraseña de autenticación de usuario que se utilizan para acceder a la red local (Active Directory Domain Services).
En realidad, no se sincroniza la contraseña, sino los Password Hashes, lo cual permite en última instancia que los usuarios puedan utilizar la misma contraseña (que está sincronizada por su hash) en la infraestructura local como en la nube.
Por supuesto, el nombre del usuario deberá ser configurado con formato UPN, de modo tal que el login se realice con la dirección de correo electrónico principal. Y este UPN, además, deberá ser válido en forma pública (no se puede utilizar un dominio .local o no registrado en forma pública).
Es importante tener en cuenta que esta característica no proporciona una solución Single Sign-On (SSO), porque no hay intercambio de Tokens entre las infraestructuras que interactúan.
Opción 3: Identidad Federada [Federated Identity]
La tercera y última opción agrega la posibilidad de que el inicio de sesión se efectivice en nuestra infraestructura local. ¿Qué significa esto? ¿Qué en la nube no tendré un espacio aislado o partición de Azure Directory Services?
No, para nada. Este espacio es aún necesario y, de hecho, se debe seguir utilizando la herramienta anteriormente mencionada: DirSync. Lo adicional aquí es que ambas infraestructuras van a interactuar a través de los servicios de federación de Active Directory, de modo tal que cuando un usuario ingresa su login y password quien valide estos datos será nuestro servicio de directorio local, no el servicio de directorio de la nube. Una vez que nuestro servicio de directorio da el «ok» sobre la Identidad del usuario, el resto sigue como en las opciones anteriores: el usuario podrá consumir los servicios de la nube.
Adicionalmente, esta opción nos permite implementar una solución Single Sign-On (SSO), de modo tal que podremos consumir varios servicios en la nube de Microsoft no solo con la identidad de nuestro servicio de directorio y realizando la autenticación en la infraestructura local, sino que también una vez que estamos logueados en un equipo unido al dominio dentro de la red interna no vamos a tener que reingresar credenciales, dado que ya estamos logueados.
Esta última opción no es extendida a todos los productos, y en el próximo apartado vamos analizar cuándo y en qué circunstancias se puede aprovechar.
Comparativo de Experiencia entre las Opciones de Identidad
En base a la información oficial proporcionada por Microsoft, a continuación presentamos una tabla comparativa donde veremos cómo se comporta cada servicio, producto o protocolo de acceso a los servicios de Office 365 en las tres opciones de identidad.
Por último, vamos a incluir una columna llamada «Veredicto», donde haremos el mayor esfuerzo para identificar objetivamente qué tipo de experiencia tendría el cliente comparativamente entre las opciones 2 y 3 (Identidad Sincronizada vs Identidad Federada).
Tengamos en cuenta un aspecto importante: el veredicto está relacionado únicamente con la experiencia del usuario final, y no con requerimientos de seguridad y auditoría. No olvidemos que en el caso de la Identidad Federada, la autenticación se realiza en nuestra infraestructura. En algunos casos puntuales, este es un aspecto decisivo al momento de elegir que opción de identidad elegir.
Sin mayor introducción, les mostramos la tabla:
Ilustración 2 – Comparativa entre diferentes opciones de identidad y experiencia al usuario final.
Conclusiones
Como hemos podido analizar, Office 365 permite configurar tres modelos de identificación para el acceso a sus servicios. Cada modelo de identidad impacta en la experiencia que el usuario tenga, principalmente en lo relacionado con que usuario y password va a utilizar (el mismo o distinto que el local de AD DS). Adicionalmente, y como hemos visto, la Identidad Federada es la única que permite experiencia en algunos métodos de acceso de tipo SSO (Single Sign-On).
Por supuesto, la Identidad Federada requiere despliegue de los servicios de Active Directory Federation Services y de Web Application Proxy para funcionar, además de ubicar a nuestro Servicio de Directorio local (Active Directory Domain Services) como punto crítico (más aún de lo que normalmente es) para el acceso a los servicios. Esto último es por una simple razón: como nuestra autenticación se realiza allí, si no está disponible ningún usuario podrá iniciar sesión ni adentro o fuera de nuestra organización.
La elección del modelo de identidad estará relacionada a la experiencia que querramos darles a nuestros usuarios, como así también a las regulaciones de seguridad informática, requerimientos de negocio y posibilidades técnicas. El conjunto de todo ello deberá ser analizado cuidadosamente, sus pros y contras, antes de tomar una decisión a la ligera.
Este artículo se ha focalizado en identificar, desde el punto de vista de experiencia de usuario, las diferentes opciones y contextualizarlas para ayudar, de alguna forma (es nuestro deseo) al análisis objetivo.
¡Muchas gracias por leernos!
Referencias y Links
- Office 365 Single Sign-On with AD FS 2.0 whitepaper: http://www.microsoft.com/en-us/download/details.aspx?id=28971
- Directory synchronization roadmap: http://technet.microsoft.com/en-us/library/hh967642.aspx
- Single sign-on roadmap: http://technet.microsoft.com/en-us/library/hh967643.aspx
- Install or upgrade the Directory Sync tool: http://technet.microsoft.com/en-us/library/jj151800.aspx
- Implement Password Synchronization: http://technet.microsoft.com/en-us/library/dn246918.aspx
- Identity and Authentication in the cloud: Office 2013 and Office 365 (Poster): http://www.microsoft.com/en-us/download/details.aspx?id=38193
Sobre el Autor
Mis lazos con la informática comenzaron en el año 1998, cuando tenía 16 años, y comencé a aprender como administrar servidores bajo la plataforma Microsoft (Windows Server, Exchange Server, IIS, y otros) y a realizar desarrollos de software con tecnologías ASP y PHP. Un tiempo más tarde comencé a trabajar ya en forma productiva en la administración de plataformas y desarrollo de software.
Desde hace varios años he tenido una intensa actividad en las comunidades profesionales, a través de eventos, webcasts, foros y publicaciones diversas. En Abril de 2014 fui reconocido como Most Valuable Professional (MVP) por parte de Microsoft, estando hoy reconocido en las especialidades "Windows and Devices for IT" y "Microsoft Azure".
En la actualidad me desarrollo como Service Delivery Manager en Algeiba (http://www.algeiba.com), una compañía que brinda soluciones y servicios tecnológicos, dirigiendo un Equipo de Trabajo de más de 20 personas. También soy el Director de TecTimes, un Portal de Tecnología que nació en el año 2012 como parte de un proyecto personal de contribución a la comunidad tecnológica en español.
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 26/03/2019 - 30 marzo, 2019
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 06/02/2019 - 12 febrero, 2019
- [Evento] Microsoft Azure | Modernización de Apps con la Nube de Azure – 20/12/2018 - 22 diciembre, 2018
Muy útil el artículo, aclara muchas dudas que tenia. Gracias!
Me salvaste un trabajo practico. Muy buen articulo.
Jajaja, gracias!