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!

Autenticación Office 365 en ADFS con múltiples dominios

¡Hola a todos! Hoy toca hablar de un proceso que puede que tengamos que afrontar tarde o temprano, e involucra Office 365, múltiples dominios validados, federación, e integración con Active Directory. Dicho así, parece más difícil de lo que en realidad es, así que… empecemos por plantear un posible escenario, y a continuación dar los pasos para resolverlo.

Imaginemos el siguiente escenario: Tenemos un tenant de Office 365 con varios dominios validados para gestionar nuestro correo electrónico y tenemos desplegado ADFS y DirSync para proporcionar servicios de sincronización y autenticación del Active Directory contra Office 365 con nuestro dominio principal. Y supongamos que nuestra empresa dispone de una gama de productos, cada uno de ellos con su propio dominio.

Y justo hoy, deciden añadir un nuevo producto a la lista… ¿Qué tenemos que hacer para preparar nuestro dominio y Office 365 para la nueva situación?

 

Primero: Agregar el nuevo dominio a Office 365 y validarlo, con el código de verificación que Office 365 nos proporciona y que hay que utilizar en el registro TXT de DNS.

addDomain

Segundo: Añadir el nuevo dominio a la lista de sufijos de UPN de nuestro AD. Para ello, debemos acudir a las herramientas administrativas, y abrir “Dominios y Confianzas de Active Directory” (Active Directory Domains and Trusts)

HerramientasAdministrativas

Una vez abierto, lo que deseamos es cambiar las propiedades de nuestro dominio, así que pulsamos con click derecho sobre el nodo raíz del árbol de dominios, y seleccionamos “Propiedades”

ADDomainsTrusts

En ese instante, podremos añadir los sufijos de UserPrincipalName que necesitemos para definir las cuentas de usuario. En este caso tenemos tres sufijos definidos: dos .com y un .net. Adicionalmente podemos añadir “nuevodominio.com”, o simplemente eliminar un sufijo que ya no sea necesario.

ADDomainsTrusts_newdomain

Podemos conformarnos con añadir “nuevodominio.com”, aunque podemos añadir todos los que deseemos. Cada dominio que añadamos aquí, pasa a formar parte de las confianzas de nuestro Active Directory, por lo que podemos utlizarlo como sufijo del UserPrincipalName para crear o modificar cuentas de usuario en nuestro AD a placer.

Tercero: Añadir el dominio elegido al servicio de federación ADFS. Para hacer esto, debemos conectarnos con office 365 mediante el cmdlet “connect-msolservice”. Una vez hemos conectado, nos encontramos ante dos casos habituales:

  • Hemos seguido las instrucciones hasta ahora y hemos agregado el dominio. Tan sólo nos falta asegurarnos de que está validado (por ejemplo con la ayuda de https://www.whatsmydns.net/ para comprobar el estado de propagación de los DNS), y una vez validado, simplemente tenemos que lanzar este cmdlet: Convert-MsolDomainToFederated -SupportMultipleDomain -DomainName nuevodominio.com
  • Si por el contrario, no hemos agregado el dominio, entonces tendremos que usar este otro cmdlet: New-MsolFederatedDomain -SupportMultipleDomain -DomainName nuevodominio.com

Además de los avisos que el proceso de conversión pueda generar, una forma de verificar si hemos tenido éxito es con el cmdlet “Get-MsolDomain”

getMSOLDomain

Una vez ejecutados los cmdlets, nos encontraremos con que la pantalla de inicio de sesión de Office365 nos redirige correctamente a nuestros servidores de ADFS para autenticar al usar un UPN con el nuevo dominio.

 

Cuarto: Ahora que ya tenemos la capacidad de definir UPNs con el nuevo dominio, hemos añadido el dominio a Office365, y ADFS está aceptando el nuevo dominio para autenticación de usuarios… la fase final es la más sencilla de todas: Agregar/modificar los usuarios que necesitemos que utilicen el nuevo UPN, y sincronizarlos con DirSync.

 

¡Y eso es todo! Como es habitual, prestad atención a la sección de Bonus, porque puede contener algunos trucos o situaciones que os podáis encontrar al realizar este proceso.

 

Bonus:

  • Si necesitamos convertir el dominio de Federado a Standard, se utiliza el cmdlet “Convert-MsolDomainToStandard -DomainName nuevodominio.com -PasswordFile pwd.txt -SkipUserConversion $false”. Este cmdlet, lo que hace es deshacer el proceso de federación, y generar un archivo de texto en el que se encuentran TODOS los usuarios que hay actualmente en Office365, proporcionando una nueva contaseña aleatoria para todos los afectados por el paso de dominio Federado a Standard.
  • Si estáis convirtiendo un usuario desde un UPN federado hacia otro UPN federado… DirSync puede dar problemas de sincronización. El motivo es que actualmente no está soportado.
  • Gracias a la magia de ADFS, podemos federar múltiples subdominios sin tener que volver a validarlos por DNS en Office 365. El motivo principal es que como ya está federado el dominio principal, es de confianza, y por tanto todo subdominio se valida y federa automáticamente. Para acelerar las cosas los podemos añadir con el cmdlet “New-MsolFederatedDomain”, desde la shell directamente.

Azure files

¡Hola a todos de nuevo!

Hoy vamos a ver una funcionalidad que incorporaron en Azure recientemente, y que era muy demandada por las empresas que querían llevar sus aplicaciones legacy a la nube. No se trata de otra cosa que Azure Files, la posibilidad de montar una unidad de red compartida, para que las máquinas virtuales principalmente puedan mapearla y acceder a sus ficheros.

Introducing Microsoft Azure File Service: http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx

Esto viene muy bien cuando nuestras aplicaciones dependen de una “Unidad (Z:)” a la hora de volcar información o acceder a la misma desde distintas máquinas.

Para poder habilitarlo vamos a tener que tirar mucho de PowerShell, ya que no es una funcionalidad que venga activada por defecto en el portal de Azure.

Empezamos creando una nueva storage account, ya que será la manera de que nos aparezca la opción de utilizar Azure Files:

clip_image001

clip_image002

Una vez creada, y para poder trabajar con PowerShell, necesitaremos descargar los módulos en preview que permiten manejar esta característica. En la documentación que os hemos puesto arriba viene el .zip incluido:

image

Cargamos el módulo que nos hemos descargado, y realizamos los pasos que nos indican para la creación de esa unidad compartida:

image

image

Una vez creada la unidad de red, podrá ser accedida vía SMB (2.1) o vía REST desde cualquier VM/Worker/Web role de Azure hospedada en la misma región que la Storage Account donde se encuentra la unidad. En la documentación oficial que os hemos dejado viene un montón de información más.

En nuestro caso si intentamos mapear la unidad desde una VM que se encuentra en una red virtual de esa región, vemos como el proceso es idéntico al que haríamos en local:

image

Y ya tendremos nuestra Unidad (Z:) para manejar ficheros de una manera mucho más sencilla 🙂

image

¡Hasta la próxima!