Microsoft ha anunciado recientemente la versión preliminar pública de dos importantes novedades que facilitarán muchísimo la integración de tu Active Directory local con Azure AD. La autenticación de paso (PTA) y el inicio de sesión único sin interrupciones (que yo prefiero llamar 3SO) permitirán a tus usuarios acceder fácilmente a aplicaciones de Azure AD, como Office 365, sin necesidad de instalar una complicada granja de Servicios de federación de Active Directory (AD FS) en tu centro de datos ni de sincronizar los hash de las contraseñas de los usuarios con Azure AD.
O en este caso de 3SO, instalando nada extra en absoluto.
Opciones de autenticación híbrida hasta ahora (y sus limitaciones)
La gran mayoría de las empresas cuentan hoy en día con Active Directory como servicio de identidad fundamental, y no parece que vaya a desaparecer a corto plazo. Por lo tanto, una primera tarea básica a la hora de planificar el uso de cualquiera de los servicios en línea de Microsoft es integrar tu Active Directory local con Azure AD para obtener dos funcionalidades. En primer lugar, debes sincronizar las cuentas y los grupos de AD con Azure AD mediante Azure AD Connect. En segundo lugar, una vez que las cuentas estén en Azure AD, hay que elegir cómo autenticar a los usuarios en ese entorno. En esta entrada me centraré en los aspectos relacionados con la autenticación de usuarios.
Hoy en día, Microsoft ofrece dos opciones de autenticación: AD FS, que proporciona federación de identidades (y otras funciones) para el inicio de sesión único (SSO), y la sincronización de contraseñas («PHS» en los gráficos siguientes). Esta segunda opción, conocida entre los expertos en tecnología como sincronización de hash de contraseñas (de ahí la «H»), ofrece una función de «inicio de sesión único» en la que el usuario debe introducir sus credenciales por segunda vez para iniciar sesión en Azure AD, pero se trata del mismo nombre de usuario y contraseña que utiliza para Active Directory.
El director del programa de autenticación Passthrough de Microsoft, Ross Adams, representa las diferencias entre estas soluciones en este ingenioso gráfico de ventajas y desventajas (Figura 1):
En orden creciente de complejidad y valor, tenemos
- Cuentas exclusivamente en la nube: las cuentas de usuario se gestionan y autentican en Azure AD. En esta entrada hablamos de soluciones híbridas, así que no vamos a entrar en este tema.
- AAD Connect / Cuentas en la nube: Puedes utilizar Azure AD Connect para sincronizar cuentas de usuario con Azure AD, de modo que el nombre de usuario (normalmente la dirección de correo electrónico del usuario) sea el mismo, pero los usuarios deben gestionar sus propias contraseñas en el servicio en la nube. No veo que nadie lo haga.
- AAD Connect + PHS: Al activar la función opcional de sincronización de hash de contraseñas en Azure AD Connect, los hashes de contraseñas de usuario almacenados en su Active Directory local se sincronizarán en Azure AD, permitiendo así el mismo inicio de sesión.
- AAD Connect + AD FS: La solución más completa y compleja por un buen margen, esta combinación proporcionará SSO a Azure AD, autenticando contra las cuentas de su Active Directory local.
Como puedes ver, existe una gran brecha en cuanto a la complejidad de implementación para incorporar un auténtico SSO en tu organización. Las soluciones de terceros de Okta, Ping Identity, OneLogin, Centrify, OptimalIDM y otras ofrecen métodos de autenticación más sencillos que cubren esa brecha, y esa es una de las razones de su popularidad.
Dominio unido a Windows... y todo lo demás
Para comprender qué ofrecen estas dos nuevas soluciones, que se encuentran en fase de vista previa pública, resulta útil agrupar los casos de uso de la autenticación en dos categorías: o bien el cliente que debe ser autenticado por Azure AD dispone de un ticket de Kerberos, o bien no lo tiene.
El primero es el clásico escenario de autenticación corporativa de Windows, conocido como «Autenticación integrada de Windows» (IWA). Un usuario que haya iniciado sesión en su estación de trabajo de Windows, integrada en el dominio, con una cuenta de AD, en la red corporativa (es decir, la estación de trabajo puede encontrar un controlador de dominio) y que, por lo tanto, disponga de un ticket de Kerberos, obtiene acceso sin interrupciones a los recursos compatibles con AD sin que se le solicite introducir su contraseña. Este escenario existe desde que se creó Active Directory.
El segundo cubo representa los demás escenarios de autenticación que han evolucionado desde entonces:
- Una estación de trabajo unida a un dominio que intenta autenticarse desde fuera de la red (el portátil).
- Un cliente basado en navegador, ya sea en un ordenador de sobremesa o en un dispositivo móvil (el navegador web)
- Un cliente basado en API, como una aplicación de Office (la aplicación móvil)
Veamos primero el caso de una estación de trabajo integrada en un dominio y la elegante solución de Microsoft que utiliza 3SO.
¿Qué es el inicio de sesión único sin fisuras?
3SO está diseñado para trabajar con el primer cubo: el PC unido al dominio en la red corporativa. La elegancia de la solución 3SO puede resumirse en pocas palabras: Azure AD ahora puede soportar la autenticación Kerberos.
Eso es todo. En esencia, el objetivo principal de AD FS es transformar un ticket de Kerberos en un token de seguridad moderno de tipo SAML u OAuth que pueda utilizar una parte confiable, como Azure AD. Si Azure AD es capaz de interpretar un ticket de Kerberos —concretamente, un ticket de servicio para un recurso de Azure—, no es necesario que AD FS actúe como intermediario para realizar la conversión.
La figura 2 muestra cómo se lleva a cabo este proceso. Azure AD se representa en tu AD local como un ordenador más; AD no distingue la diferencia. Se añade una cuenta de equipo (AZUREADSSOACCT) a su AD, y con ella dos SPN (nombres de entidad de servicio) que contienen las URL necesarias para llevar a cabo la autenticación. La clave secreta de Kerberos para la cuenta de la estación de trabajo se comparte de forma segura con Azure AD. A partir de este momento, los clientes utilizan IWA para acceder a los recursos de Azure del mismo modo que accederían a un servidor IIS en su centro de datos local.
- Un usuario intenta acceder a un recurso de Azure AD como Office 365. Azure AD reta al usuario a proporcionar un ticket de servicio Kerberos.
- El cliente presenta su TGT (ticket-granting ticket) y el SPN del servidor de destino (una URL de Azure AD en este caso) a su controlador de dominio.
- El servicio de concesión de tickets (TGS) del centro de distribución de claves (KDC) del controlador de dominio crea un ticket de servicio para el recurso de Azure AD y lo devuelve al cliente.
- El cliente presenta el ticket de servicio a Azure AD. Asumiendo que el ticket es válido, el usuario se autentica.
Ten en cuenta que este proceso no implica que el usuario esté autorizado a acceder al recurso, sino simplemente que ha demostrado su identidad. El resultado es que a un usuario corporativo de Windows que se encuentre dentro de la red no se le solicita que introduzca una contraseña para acceder a los recursos de Azure AD, y no es necesario utilizar AD FS. Muy ingenioso, ¿verdad?
La instalación de 3SO no puede ser más sencilla: solo hay que marcar la casilla «Habilitar inicio de sesión único» en la configuración personalizada de la última versión de AD Connect.
Clientes admitidos
Hay un par de configuraciones compatibles con 3SO. En primer lugar, debe tratarse de un cliente compatible con Kerberos, como Windows. En segundo lugar, funciona para acceder a recursos de Azure AD a través del navegador (por ejemplo , https://outlook.office.com) o desde un cliente de Office que admita la autenticación moderna. Puedes consultar la lista de clientes compatibles, pero, en esencia, es compatible con todos los navegadores principales (IE, Chrome, Firefox), excepto Edge, y con todos los sistemas operativos cliente de Microsoft compatibles. Microsoft recomienda habilitar 3SO para todos los clientes; si el usuario se encuentra en una configuración no compatible, lo peor que puede pasar es que se le solicite introducir una contraseña.
¿Qué es la autenticación Passthrough?
PTA está diseñado para aquellos casos en los que el cliente no dispone de un ticket de Kerberos, ya sea porque el cliente de Kerberos no puede conectarse a un servidor de dominio (por ejemplo, cuando un empleado trabaja desde casa con su portátil de la empresa) o porque el cliente no es compatible con Kerberos (por ejemplo, un navegador móvil o una aplicación que no admite la autenticación moderna).
No voy a explicar aquí cómo instalar PTA, pero, básicamente, se implementan uno o varios conectores ligeros locales —muy similares al conector de Azure AD Application Proxy— en servidores que formen parte de un dominio, desde donde puedan comunicarse con un controlador de dominio.
A alto nivel, el proceso de autenticación PTA es muy parecido al proceso de autenticación AD FS: Azure AD reconoce que la solicitud de autenticación se delega a un Active Directory local a través de un proxy. Para AD FS, actúa como proxy. Para PTA, los conectores actúan como proxy (Figura 3).
- Azure AD solicita al usuario que se autentique, y éste introduce su dirección de correo electrónico y su contraseña.
- Azure AD determina que el dominio del usuario está configurado para PTA; Azure AD lo notifica al conector, que recupera las credenciales.
- El conector autentica al usuario contra AD utilizando la misma API de Windows que utiliza AD FS.
- La respuesta se devuelve al conector.
- El conector reenvía la respuesta a Azure AD.
- Azure AD emite un token para el usuario.
Puede ver que esto tiene muchas ventajas sobre AD FS:
- Los conectores pueden instalarse en servidores o DC existentes unidos a un dominio.
- Cuando se instalan varios conectores (recomendado), PTA equilibra automáticamente la carga entre ellos.
- Todas las conexiones de Azure son salientes y no hay puntos finales no autenticados expuestos a Internet.
- Es muy sencillo de gestionar desde el portal de Azure y no hay que gestionar ningún certificado
¿Cuándo querría seguir utilizando AD FS?
No se equivoque; AD FS no ha sido en absoluto dejado de lado. PTA es una flecha muy especializada para un único objetivo: permite a Azure AD autenticar usuarios de Active Directory contra su AD corporativo, punto. Sigue necesitando AD FS si
- Desea utilizar tarjetas inteligentes para la autenticación
- Desea utilizar proveedores de AMF de terceros
- La política de seguridad de tu empresa exige que las contraseñas permanezcan siempre en las instalaciones (a diferencia de AD FS, en PTA la contraseña del usuario se introduce en Azure AD antes de que pase a las instalaciones).
- Puede utilizar las reglas de autenticación adicionales de AD FS para imponer el acceso condicional
- Utiliza el acceso condicional de Windows 10 local basado en el dispositivo
Y, por supuesto, debes disponer de AD FS si tienes partes confiables configuradas localmente para proporcionar el inicio de sesión único (SSO) y no deseas trasladarlas a Azure AD.
AD FS 2016 también ofrece nuevas funciones, como la compatibilidad integrada con Azure MFA; si tiene una implementación de AD FS existente, analice muy detenidamente sus necesidades futuras y lo que AD FS puede hacer antes de plantearse arrancarlo como medida de ahorro de costes.
Opciones de autenticación híbrida
Microsoft ofrece ahora un conjunto mucho más completo de opciones de autenticación híbrida (Figura 4):
Las opciones originales siguen estando disponibles, pero ahora puedes obtener un gran valor añadido con muy poca complejidad adicional. Si utilizas la sincronización de contraseñas, añadir 3SO eliminará los problemas relacionados con las contraseñas para los usuarios corporativos de tu red. Si, por el contrario, habilitas PTA junto con 3SO, obtendrás prácticamente el mismo valor que con AD FS para ese caso de uso específico de autenticación de Azure AD.
Con la versión preliminar pública de 3SO y la autenticación de paso, Microsoft ha reducido drásticamente las barreras para adoptar una estrategia de identidad híbrida utilizando las herramientas nativas de la empresa. De hecho, estas herramientas son incluso más fáciles de usar que las soluciones de terceros que se han aprovechado de la complejidad de AD FS.
Y por si no ha quedado claro, todo esto es gratuito. Microsoft ha apostado su futuro por sus servicios en la nube de Azure. La empresa quiere facilitar al máximo la adopción de estos servicios y, en el mundo actual centrado en Active Directory, eso significa que la integración de AD con Azure AD sea rápida y sencilla. Ha llevado una eternidad sacar a la luz estas capacidades, pero preveo que se convertirán rápidamente en el puente de identidades más popular entre la identidad de Microsoft local y la identidad de Microsoft en la nube.
