Archivo de la etiqueta: azure active directory

Enlazar suscripción de Azure con Azure Active Directory (u Office 365, Intune, etc…)

La administración de Azure Active Directory y como esta se relaciona con las instancias de Azure AD que ya tenemos en servicios como Office 365 o Intune puede llegar a ser realmente confusa, así que en esta semana navideña me ha parecido muy oportuno dedicar un post a aclarar todo este tema.

 ¿Qué es Azure Active Directory?

Azure Active Directory (AAD) es una plataforma de identidad en la nube gestionada y hospedada por Microsoft. Un buen rango de servicios de Microsoft se apoyan directamente en Azure Active Directory como su base de usuarios y autenticación. Es por ello que si disponemos de un tenant de Office 365, Intune o CRM Online, ya estamos usando Azure Active Directory aunque no tuviéramos una constancia de ello.

Por tanto podríamos decir que todo los servicios que usen Azure Active Directory comparten la misma base de datos de usurios y el mismo proceso de autenticación, obteniéndose el consiguiente Single Sign On entre ellos.

A continuación podéis ver un esquema de cómo distintos servicios se valen de Azure Active Directory para gestionar su identidad:

image

Es importante reseñar que NO es lo mismo Azure Active Directory que Active Directory en Azure. El segundo se refiere a llevar controladores de dominio de nuestra infraestructura a máquinas virtuales de Azure para así poder desplegar servicios dependientes de los mismos en la nube, tema que nos dará para un artículo en otra ocasión.

Los siguientes servicios usan Azure Active Directory:

  • Office 365
  • Intune
  • Dynamics CRM Online
  • Azure Rights Managements System

¿Como integro el Azure Active Directory de Office 365 con mi suscripción de Azure?

A pesar de que el nombre induzca a confusión, Azure Active Directory y una suscripción de Azure son entidades separadas. Esto quiere decir que tener AAD no implica tener una suscripción de Azure, por lo que existe un procedimiento para integrarlo con tu suscripción.

  1. Iniciamos la sesión en nuestra suscripción de Azure.
  2. Vamos a New –> Active Directory –> Directory –> Custom Create
    image
  3. Seleccionamos Use existing directory.
    image
  4. El asistente nos pedirá iniciar sesión con nuestras credenciales del tenant de Azure Active Directory (que pueden ser las de nuestro administrador global de Office 365).
  5. Nuestro Azure Active Directory queda enlazado con nuestra suscripción de Azure.

Como resultado deberíamos ver algo así:

image

Directorio por defecto

Después de hacer el enlace, si este es el único directorio que tenemos, quedará establecido automáticamente como directorio por defecto. Si tuviésemos más directorios bajo administración de la misma cuenta de usuario, podríamos seleccionar cuál de ellos es el directorio por defecto de nuestra suscripción de Azure. Este concepto indica en qué directorio nuestra suscripción de Azure va a confiar para poder realizar autenticación y aprovisionar usuarios. Gráficamente se puede ver en este esquema de la Microsoft Technet:

image

Es importante también reseñar que distintas suscripción de Azure pueden confiar en el mismo AAD, pero una suscripción de Azure sólo puede confiar en un único AAD. Por tanto, en nuestra suscripción el directorio por defecto es único. Los usuarios de este directorio serán los habilitados para poder autenticar con distintos servicios SaaS de Azure, como RemoteApp.

A la vista de lo explicado, podemos entender que tampoco sería posible integrar los directorios de dos tenants distintos de Office 365 bajo una única suscripción de Azure.

Ahora puedo ver mi Azure Active Directory con cualquier suscripción de Azure, ¿está enlazado a todas?

Esta es la parte truculenta de la historia. Cuando iniciamos la sesión en manage.windowsazure.com y vemos entre la lista el servicio de Active Directory, no se nos están mostrando los AAD enlazados con la suscripción, sino aquellos para los que el usuario con el que nos hemos validado al entrar en manage.windowsazure.com tiene permiso para administrar. De esta forma, si vemos:

image

Esto viene a significar que nuestro usuario tiene permiso para administrar 2 AAD distintos que no necesariamente están enlazados con nuestra suscripción de Azure. Deberemos establecer un directorio por defecto (e insisto, sólo uno) para que pueda pasar a ser utilizado.

Espero que el articulo haya servido para aclarar dudas sobre la administración de AAD, donde la interfaz puede inducir a bastante confusión.

Enlace relacionado: How Azure subscriptions are associated with Azure AD – Microsoft Technet

Office 365 y ADFS: autenticación activa y pasiva

Si vas a implementar Office 365 en tu organización, tendrás muy presente que hay dos temas capitales sobre los que debes meditar: cómo vas a aprovisionar tus usuarios y cómo van autenticar estos. Cuando hablo con mis clientes sobre autenticación y estos desean Single Sign On, casi siempre entramos en conversaciones de federación y proveedores de identidad (IdP). Los IdP más habituales para federar con Azure Active Directory –que como sabéis es la base de identidad de Office 365- son ADFS y Shibboleth, cada uno de los cuales soporta unos determinados protocolos de autenticación basada en claims.

Las características soportadas según el protocolo de federación empleado cambias, aunque Microsoft está haciendo un importante esfuerzo por dar buen soporte a SAML 2, como se puede apreciar en esta tabla:

Característica Soportada con ADFS Soportada con SAML 2
Acceso web
Clientes IMAP Sólo Shibboleth con ECP
Clientes Exchange Active Sync Sólo Shibboleth con ECP
Clientes Outlook Anywhere Sólo Shibboleth con ECP
Cliente Lync Próximamente
Office Pro Plus Próximamente

¿Cómo funciona la autenticación federada en Office 365? – Autenticación Pasiva

Llamamos autenticación pasiva a aquella que es llevada fundamentalmente por el usuario y por tanto todos los elementos involucrados esperan a ser llamados por el mismo. Esta autenticación es la que usamos al autenticar desde un navegador web. Este esquema ilustra cómo funciona:

Office 365 - Autenticación Pasiva

  1. Entramos en el webiste correspondiente de Office 365, por ejemplo: https://portal.office.com
  2. Office 365 nos redirige a nuestro ADFS, que nos muestra una web para autenticarnos. La URL será de nuestra red, como https://adfs.contoso.com
  3. Tras autenticarnos correctamente volvemos a la web de Office 365 a la que queríamos acceder, como en este caso https://portal.office.com

Como podéis ver, todos los procesos los lleva a cabo el navegador del usuario que es redirigido al lugar correspondiente.

¿IMAP con identidad federada?

Una de las características de protección de datos de la solución de Microsoft es que Azure Active Directory (y por tanto Office 365) no almacena contraseñas de usuarios en caso de estar usando identidad federada. Toda la autenticación se lleva a cabo a través del IdP que tenemos funcionando en nuestras infraestructuras. Este hecho desconcierta mucho a nuestros clientes cuando les aseguramos que es posible usar –por ejemplo- el protocolo IMAP con identidad federada.

El Internet Message Access Protocol (IMAP) es un protocolo de acceso y almacenamiento de correo electrónico desarrollado en el año 1986 como alternativa al POP y que se convirtió en un estándar en la década de los 90, estando soportado por casi la totalidad de clientes de correo electrónico. Sin embargo, IMAP no sabe nada de IdP ni federación de identidad, utilizando sus propios mecanismos integrados de autenticación. ¿Cómo es posible entonces que entremos a nuestro correo IMAP teniendo federación de identidad y sin que Microsoft tenga nuestra contraseña en la nube? La respuesta es mediante autenticación activa.

Siempre que iniciamos sesión en Office 365 mediante un programa que no es un navegador, el mecanismo de autenticación es muy distinto:

Office 365 - Autenticación Activa

Veamos como funciona en este caso, siendo una autenticación IMAP la que está sucediendo:

  1. Usuario autentica mediante su cliente de correo (ej: Thunderbird) con Office 365. En este proceso está enviando ya el nombre de usuario y la contraseña.
  2. Office 365 se da cuenta de que no está en posesión de la contraseña e inicia una conexión con nuestros servidores de federación.
  3. Los servidores de federación autentican al usuario y así se lo comunican a Office 365.
  4. Office 365 permite la conexión al usuario, pudiendo este operar con el sistema.

Así hemos podido ver cómo Office 365 ha jugado un papel activo, conectándose con nuestros servidores de federación, en lugar de ser el propio usuario el que lleva a cabo la operación mediante su navegador.

Espero que este artículo os haya servidor para conocer con más detalle en qué consisten ambos modelos de autenticación y los pasos que estos realizan, ya que es vital para poder depurar cualquier problema que pueda producirse en el contexto de identidad y autenticación federada de usuarios con Office 365 o incluso cualquier aplicación integrada con Azure Active Directory.

Happy authentication!

Filtrado de atributos en Azure Active Directory, consideraciones a tener en cuenta

Cuando trabajamos con sincronización de Azure Active Directory (por ejemplo, para Office 365) podemos hacer el filtrado de objetos a sincronizar por unidad organizativa (OU) o bien por sus atributos.

En caso de que queramos hace el filtrado por atributo hay algunas cosas importantes que tener en cuenta:

  • El “filtrado” consiste en definir una regla para especificar qué objetos NO van a sincronizar. Todo lo que no cumpla esta regla sincronizará.
  • Sólo es válido para usuarios. Todos los grupos de distribución y seguridad del AD no se verán afectados por la regla, así como los contactos; por lo que sincronizarán independientemente de los que establezcamos. Esto se debe a que en el FIM subyacente a AAD Sync Tool estos objetos se encuentran ya filtrados mediante reglas de extensión que no son fácilmente modificables.
  • El filtrado en el FIM se establece de acuerdo a comparadores de cadenas, estando disponibles los siguientes:

    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
  • Se pueden combinar múltiples operadores con múltiples atributos, pero la regla lógica que sigue para aplicar el filtro es siempre AND. Por ejemplo: si extensionAttribute15 equivale a “estudiante” y extensionAttribute14 equivale a “nosync” entonces filtrar (no sincronizar) el objeto.

Happy syncing!