Azure Active Directory y sus diferencias con Windows Active Directory

Para muchas personas no es clara la diferencia que existe entre Azure Active Directory y Windows Active Directory.

A primera vista se puede pensar que Azure Active Directory es el mismo Active Directory que conocemos en el mundo on-premise con la diferencia de que se encuentra en la "nube", es decir; en Microsoft Azure, pero esto en realidad no es así, y precisamente ese es el objetivo de este artículo, comprender las diferencias que existen entre los dos, iniciemos explicando lo que es el Active Directory on-premise que ya conocemos.

Windows Active Directory 

Generalmente se encuentra aislado del resto del mundo.

Si se requiere comunicación con el mundo externo se hace necesario abrir una gran cantidad de puertos para lograrlo, y posiblemente nos enfrentemos a conflictos de DNS de Internet y nuestra zona interna.

Azure Active Directory

Azure Active Directory (AAD), es un servicio basado en la web de gran escala para la administración de identidad y acceso, éste servicio se encuentra alojado en los centros de datos de Microsoft, y nos permite gestionar todo lo relacionado con identidades, acceso a aplicaciones, auditoria, reportes, autenticación multifactor, y regularmente se agregan nuevas características y posibilidades.

Aunque su nombre es similar al Active Directory que ya conocemos, AAD NO son instancias de Windows Server Active Directory en controladores de dominio ubicados en los centros de datos de Azure, Aunque tiene algunas similitudes tales como:

• Usuarios
• Grupos
• Contenido que se replica

Pero carece de otras cosas típicas de Windows Active Directory (AD), como:

• Unidades Organizativas (OUs)
• Sitios
• Unión de equipos al dominio (aunque Windows 10 permite usar una cuente en Azure para autenticarse, similar a como se hace hoy en día con las cuentas Microsoft.)
• GPOs

¿Porqué necesitamos Azure Active Directory?

Hoy en día con la explosión de la nube las cosas han cambiado, los modelos a los cuales veníamos acostumbrados se han quedado atrás y ya se consideran obsoletos, me explico un poco mejor.

Las aplicaciones in-house cada vez pierden más sentido, el mantenimiento se hace más complejo, si se hacen cambios en la aplicación, se hacía necesaria la actualización de la misma, generalmente mediante paquetes que entrega el proveedor de la misma, y en algunos casos eran enviados incluso en CDROM.

El día de hoy, muchos proveedores de aplicaciones están migrando sus servicios a la nube, para ofrecer sus productos de software como servicio (SaaS), con esto el proveedor hace los cambios que requiera la aplicación en un solo lugar, y de inmediato todos sus clientes disfrutarán del cambio de manera automática.

Veamos un ejemplo de la utilidad de AAD.

Un proveedor de una aplicación corporativa que funciona en la intranet, y en un momento dado el proveedor decide llevar su aplicación a la nube, en ese momento requiere que cada usuario de la aplicación tenga un juego de credenciales (user/password) para poder ingresar a su aplicación recién alojada en la nube.

La siguiente imagen muestra el escenario antes de que el proveedor migrará su aplicación a la nube, con el fin de ofrecer el servicio de la misma a otras empresas, ya "montado" el proveedor en al nube, pronto la aplicación on-premise que utiliza autenticación contra un AD local dejará de ser mantenida por el mismo.

                                                                 Aplicación on-premise

Una vez la aplicación fue llevada a la nube el usuario no podrá utilizar sus credenciales de red, es decir; no podrá autenticarse contra AD, en su lugar deberá tener un juego de credenciales que se almacenará probablemente en una base de datos en los servidores alojados en la nube donde se aloja ahora la aplicación, tal como se muestra en la siguiente imagen:

                                                              Aplicación en la nube (SaaS)

Lo anterior obliga a que el usuario tenga que memorizar otro juego de credenciales diferentes a las de red para ingresar a la aplicación, y lo mismo tendrá que hacer no solo con esta aplicación sino con cualquier otra que aplicación externa que el usuario necesite.

Ahora el proveedor de la aplicación toma la sabia y excelente decisión de integrar su aplicación con AAD

¿Porqué es una buena decisión?, porque el usuario podrá autenticarse en la aplicación en la nube pero utilizando las mismas credenciales de red. Con esto si el usuario se retira de la compañía, el administrador simplemente deshabilita el usuario en Active Directory local, y este cambio se replicará hacia AAD, lo cual impide que el usuario siga ingresando a la aplicación, se tendrá un manejo centralizado de las identidades y para todas las aplicaciones sin importar que la aplicación se encuentre fuera de la red corporativa.

Aplicación integrada con Azure Active Directory (AAD)

Como se puede apreciar en la imagen anterior, el usuario inicia sesión en la aplicación utilizando las mismas credenciales de la red corporativa, gracias a que dichas credenciales están siendo sincronizadas desde el AD local hacia AAD. ¿ahora tiene más sentido? en lugar de estar administrando identidades separadas para cada aplicación o servicio, se administran todas desde una sola ubicación, con esto los beneficios son grandes:

• El proveedor de la aplicación administra y actualiza la misma, adiciona mejoras, etc.
• Las credenciales son las mismas de red y son administradas por TI en Active Directory local
• Las aplicaciones están disponibles desde cualquier dispositivo (Smartphone, Tablet, PC)

En el portal de Azure, podemos encontrar cientos de aplicaciones que se integran con AAD listas para usar.

¿Se puede interactuar con AAD como se hace con AD mediante LDAP?

No es posible, LDAP no está expuesto externamente, pero para consultar, leer y escribir en AAD, se puede hacer uso del módulo de PowerShell para Azure Active Directory o utilizar la interface Graph-API basada en REST

Al tratarse AAD de un servicio web la forma de consultar cambia, mientras una típica consulta LDAP en Active Directory luce como la siguiente:

(&(objectCategory=person)(objectClass=user)(cn=Cesar Herrada)

La misma consulta en AAD utilizando Graph luce así:

GET https://graph.windows.net/azurecloud.la/Users?$filter=displayName eq 'Cesar Herrada'&api-version=2013-04-05

¿Se puede tener una réplica de Active Directory local en Azure?

No es posible tener una réplica más allá de lo que mencionamos anteriormente, es decir; la sincronización de usuarios, contraseñas y grupos.

Lo que SI podemos tener es una réplica de un controlador de dominio on-premise en Azure el cual se encuentra conectado al centro de datos local a través de una conexión VPN, en este caso Azure lo podemos ver como un sitio más de Active Directory, como si se tratase de un sitio externo, por ejemplo para escenarios de recuperación de desastres.

Del mismo modo, podemos tener una instancia de máquina virtual (VM) en Azure, y le instalamos los servicios de dominio de Active Directory para convertirla en un controlador de dominio, en este caso no tenemos conexión alguna con el sitio on-premise. Este escenario es ideal para temas de desarrollo y prueba de aplicaciones.

En resumen, tenemos las siguientes posibilidades:

Sincronización de contraseñas

Permite la sincronización de usuarios y sus contraseñas a AAD

Sincronización de Identidades con federación

Con identidad federada se requieren los servicios de federación de Active Directory, para la autenticación, la aplicación en la nube enviará la solicitud al servidor de federación, quién emitirá un token para el usuario si las credenciales son validas.

Conexión entre red local y red de Azure

En este caso tenemos la red local de nuestro centro de datos conectada a la red de Azure donde se encuentra un controlador de dominio, esto se hace a través de una VPN

Directorio independiente en Azure

En este escenario no existe conexión alguna entre el directorio local y AAD, se trata simplemente de un controlador de dominio aislado montado sobre una instancia de máquina virtual en Azure, el cual provee autenticación a cualquier aplicación en la nube que lo requiera.

¿Cómo se administra Azure Active Directory?

Algo muy común que podemos preguntarnos es cómo se administra AAD, se puede utilizar la clásica consola Equipos y Usuarios de Active Directory, la respuesta es no, la administración de los usuarios se hace desde la sección Active Directory del portal de Azure, y claramente también se puede hacer desde PowerShell utilizando el módulo destinado para ello, a continuación se muestra la administración hecha desde el portal de Azure.

E incorpora algunas  herramientas para administrar los usuarios

Pero claramente, muchas cosas se pueden seguir manejando de manera local y serán replicadas a la nube, por ejemplo el cambio de una contraseña, creación de un usuario, cambio de una descripción, pueden ser trabajados localmente en Active Directory y luego serán sincronizados.

¿Azure Active Directory maneja Kerberos, NTLM y otros protocolos?

AAD es un servicio basado en la web que admite múltiples dispositivos, múltiples plataformas, por lo cual no se basa en los mismos protocolos con los que estamos familiarizados en el mundo on-premise, en su lugar se usan protocolos basados en la web tales como: SAML 2.0, WS-Federation, OAuth, OpenID, REST Graph, entre otros.

Básicamente podemos concluir que Azure Active Directory es un servicio orientado específicamente al tema de autenticación de aplicaciones basadas en la nube, mientras que Windows Active Directory, es orientado especialmente al mundo on-premise, ya que además de el manejo de identidad y acceso permite la administración centralizada de cambios y configuraciones en una red basada en Windows.

Espero con este artículo haber aclarado algunas de las diferencias que existen entre el Active Directory local y el de la nube, y claramente también se pretende resaltar las características de AAD y entender que se trata de una pieza clave si queremos llevar o desarrollar nuestras aplicaciones en la nube.