¿Active Directory domain o Cloud domain?
Cuando hemos dado alguna charla sobre los servicios Cloud de Microsoft, nos gusta hacer una aproximación construyendo un mensaje basado en la Identidad. Si pensamos en cuál es el centro neurálgico de cualquier infraestructura On-premise, seguramente digamos Active Directory. En torno a él desplegamos una serie de servicios como pueden ser el correo electrónico, aplicaciones, bases de datos, etc.
Con la aparición de plataformas en la nube como Office 365, Azure o EMS, por ahorro de costes o funcionalidades añadidas que podemos dar a nuestros usuarios, llega el momento de mover esos servicios y “externalizarlos”. En este caso en la nube de Microsoft estamos cubiertos, ya que han seguido una aproximación muy parecida a los entornos On-premise, y tenemos como centro neurálgico a Azure Active Directory. Como hemos explicado en varias ocasiones, AAD es un Directorio como Servicio, proporcionando un almacén de credenciales y plataforma de autenticación única para cualquier producto Cloud de Microsoft. Además podemos desarrollar nuestras aplicaciones para que autentiquen arriba y disfrutar de una experiencia de Single Sign-On.
Como podéis observar en la imagen, cada vez más servicios dependen de la nube, y nuestro Active Directory se queda algo desangelado ahí abajo. Pueden existir todavía escenarios donde dependemos de una autenticación tradicional, como puede ser el login en nuestros equipos de trabajo, aplicaciones legacy que no podemos cambiar, el RADIUS de la WiFi, etc. Pero la tendencia claramente es llegar a un punto donde no necesitemos mantener ninguna infraestructura local, ni siquiera nuestro directorio de usuarios.
Con esa idea en mente se ha desarrollado Windows 10, el primer sistema operativo de Microsoft que nos permite iniciar sesión en nuestro equipo autenticando directamente en Azure Active Directory.
Una vez unido el equipo al dominio de AAD, se le aplicarán las políticas que hayamos definido. Lógicamente a día de hoy no tenemos ni de lejos las opciones con las que contamos en un entorno On-prem con las GPOs, tanto de Equipo como de Usuario, pero es un comienzo.
Además de este modo estamos registrando automáticamente el equipo como dispositivo del usuario, por lo que podremos manejarlo desde un MDM como Intune desde el minuto 1. También tendremos esa experiencia de SSO con cualquier aplicación que tengamos enlazada a nuestro AAD, pensar en Office 365…
Si lo tenemos habilitado, podremos unirnos a Azure AD incluso cuando tengamos la identidad federada:
El detalle de cómo debemos configurar nuestro Azure Active Directory para poder unirnos de esta forma, lo podéis encontrar en este fantástico post de Sergio Calderón. Fijaros en el detalle de la notación con la que aparece un usuario unido a un dominio de AAD (AzureADUsuario):
Pero entonces… si me he unido a un dominio de Azure Active Directory que tiene sus propias políticas, pero que tengo federado con un Active Directory donde configuro mis GPOs… ¿¿donde estoy?? ¿¿que me aplica??
Bueno, la respuesta es que aunque la autenticación se realice en última instancia en el AD local, ambos directorios son disjuntos.
Lo podemos ver en la información del sistema:
O más claramente, si intentamos unirnos al Active Directory local:
Por lo tanto nos toca elegir… ¿Active Directory domain o Cloud domain? ¿Vosotros qué preferís?
¡Hasta la próxima!