Sean Deuby

Microsoft anunció recientemente la vista previa pública de dos nuevas capacidades importantes que harán que la integración de su Active Directory local a Azure AD sea mucho, mucho más fácil. La autenticación Passthrough (PTA) y el Seamless Single Sign-On (yo prefiero llamarlo 3SO) permitirán a tus usuarios acceder fácilmente a las aplicaciones de Azure AD, como Office 365, sin necesidad de instalar una complicada granja de Active Directory Federation Services (AD FS) en tu centro de datos ni de sincronizar los hashes 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 actuales tienen Active Directory como servicio de identidad básico, y no va a desaparecer pronto. Por lo tanto, una primera tarea básica cuando se planea utilizar cualquiera de los servicios en línea de Microsoft es integrar su Active Directory local con Azure AD para obtener dos capacidades. En primer lugar, debe conseguir que las cuentas y grupos de AD se sincronicen con Azure AD mediante Azure AD Connect. En segundo lugar, una vez que las cuentas están en Azure AD, debe elegir cómo autenticar a los usuarios allí. Me estoy centrando en los bits de autenticación de usuario en este post.

En la actualidad, Microsoft ofrece dos opciones de autenticación: AD FS, que proporciona federación de identidades (y otras funciones) para el SSO, y la sincronización de contraseñas ("PHS" en los gráficos siguientes). Esta segunda opción, conocida por los digerati como sincronización de hash de contraseña (de ahí la "H"), proporciona una capacidad de "mismo inicio de sesión" en la que el usuario debe introducir credenciales una segunda vez para iniciar sesión en Azure AD, pero son el mismo nombre de usuario y contraseña que utilizan 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):

Figura 1: Opciones de autenticación heredadas de Azure AD (Microsoft)
Figura 1: Opciones de autenticación heredadas de Azure AD (Microsoft)

En orden creciente de complejidad y valor, tenemos

  • Cuentas sólo en la nube: Las cuentas de usuario se mantienen y autentican en Azure AD. Estamos hablando de soluciones híbridas en este post, así que dejaremos este punto.
  • AAD Connect / Cuentas en la nube: Puede utilizar Azure AD Connect para sincronizar las cuentas de usuario en Azure AD para que el identificador de inicio de sesión (normalmente la dirección de correo electrónico del usuario) sea el mismo, pero los usuarios deben mantener sus propias contraseñas en el servicio en la nube. No veo a nadie haciendo esto.
  • 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 puede ver, hay una gran brecha en la complejidad del despliegue para conseguir un verdadero SSO en su organización. Las soluciones de terceros de Okta, Ping Identity, OneLogin, Centrify, OptimalIDM y otros ofrecen métodos más simples para la autenticación que se ajustan a esta brecha, y esa es una de las razones de su popularidad.

Dominio unido a Windows... y todo lo demás

Para entender lo que ofrecen estas dos nuevas soluciones en vista previa pública, es útil agrupar los casos de uso de autenticación en dos categorías: el cliente que se va a autenticar con Azure AD tiene un ticket Kerberos o no lo tiene.

El primero es el escenario clásico de autenticación corporativa de Windows, conocido como Autenticación Integrada de Windows (IWA). Un usuario que ha iniciado sesión en su estación de trabajo Windows unida a un dominio con una cuenta AD, en la red corporativa (es decir, la estación de trabajo puede encontrar un controlador de dominio) y, por lo tanto, tiene un ticket Kerberos, obtiene acceso sin problemas a los recursos AD-aware sin que se le pida que introduzca su contraseña. Este escenario existe desde que se inventó 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 de escritorio o móvil (el navegador web)
  • Un cliente basado en API, como una aplicación de Office (la aplicación móvil)

Veamos primero el escenario de la estación de trabajo unida a un dominio, y la elegante solución de Microsoft utilizando 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. Reducido a su esencia, el objetivo principal de AD FS es transformar un ticket Kerberos en un token de seguridad SAML u OAuth moderno que una parte de confianza como Azure AD pueda utilizar. Si Azure AD puede entender un ticket Kerberos - específicamente un ticket de servicio para un recurso Azure - no necesita el intermediario AD FS para hacer la traducción.

La figura 2 muestra cómo se hace esto. Azure AD se representa en su AD local como un equipo más; AD no nota la diferencia. Se añade una cuenta de equipo (AZUREADSSOACCT) a su AD, y con ella dos SPN (nombres principales de servicio) que contienen las URL necesarias para realizar la autenticación. La clave secreta Kerberos de la cuenta de equipo 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 podrían acceder a un servidor IIS en su centro de datos local.

Figura 2: SSO sin fisuras a Azure AD (Microsoft)
Figura 2: SSO sin fisuras a Azure AD (Microsoft)
  1. 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.
  2. 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.
  3. El servicio de concesión de tickets (TGS) dentro del centro de distribución de claves (KDC) del controlador de dominio crea un ticket de servicio para el recurso Azure AD y lo devuelve al cliente.
  4. El cliente presenta el ticket de servicio a Azure AD. Asumiendo que el ticket es válido, el usuario se autentica.

Tenga en cuenta que este proceso no significa que el usuario esté autorizado a acceder al recurso; sólo que ha autenticado quién es. El resultado es que a un usuario corporativo de Windows dentro de la red no se le pide que introduzca una contraseña para acceder a los recursos de Azure AD, y no se requiere AD FS. Muy ingenioso, ¿eh?

La instalación de 3SO no puede ser más sencilla: basta con marcar la casilla "Activar 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 soportadas para 3SO. Primero, debe ser un cliente que soporte Kerberos, como Windows. En segundo lugar, funciona para acceder a los recursos de Azure AD a través del navegador (por ejemplo https://outlook.office.com) o desde un cliente de Office que soporte autenticación moderna. Puedes ver la lista de clientes soportados, pero esencialmente es compatible con todos los navegadores principales (IE, Chrome, Firefox) excepto Edge, y todos los SO cliente de Microsoft soportados. Microsoft recomienda activar 3SO en todos los clientes; si el usuario se encuentra en una configuración no soportada, lo peor que le ocurrirá es que recibirá un aviso de contraseña.

¿Qué es la autenticación Passthrough?

PTA está diseñado para el caso de uso en el que el cliente no tiene un ticket Kerberos, ya sea porque el cliente Kerberos no puede llegar a un DC (por ejemplo, cuando un empleado está trabajando desde casa en su portátil corporativo) o porque el cliente no es compatible con Kerberos (por ejemplo, un navegador móvil o una aplicación que no es compatible con la autenticación moderna).

No voy a hablar aquí de cómo instalar PTA, pero esencialmente se despliegan uno o más conectores ligeros locales, muy parecidos al conector Azure AD Application Proxy, en servidores unidos a un dominio donde pueden comunicarse con un DC.

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).

Figura 3: Flujo del proceso de autenticación Passthrough (Microsoft)
Figura 3: Flujo del proceso de autenticación Passthrough (Microsoft)
  1. Azure AD solicita al usuario que se autentique, y éste introduce su dirección de correo electrónico y su contraseña.
  2. Azure AD determina que el dominio del usuario está configurado para PTA; Azure AD notifica al conector que recupera las credenciales.
  3. El conector autentica al usuario contra AD utilizando la misma API de Windows que utiliza AD FS.
  4. La respuesta se devuelve al conector.
  5. El conector reenvía la respuesta a Azure AD.
  6. 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 certificados que gestionar

¿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
  • Su política de seguridad corporativa requiere 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 salir 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, debe tener AD FS si tiene partes de confianza configuradas localmente para proporcionar SSO que no desea mover 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):

Figura 4: Opciones de autenticación de Azure AD (Microsoft)
Figura 4: Opciones de autenticación de Azure AD (Microsoft)

Las opciones originales siguen estando disponibles, pero ahora puede obtener un gran valor con muy poca complejidad adicional. Si está utilizando la sincronización de contraseñas, añadir 3SO eliminará los desafíos de contraseñas para sus usuarios corporativos dentro de la red. Si en su lugar habilita PTA junto con 3SO, tendrá prácticamente el mismo valor que AD FS para el caso de uso específico de autenticación de Azure AD.

Con la vista previa pública de 3SO y la autenticación Passthrough, Microsoft ha reducido drásticamente la barrera para adoptar una estrategia de identidad híbrida utilizando las herramientas nativas de la empresa. De hecho, estas herramientas son incluso más sencillas de usar que las ofertas de terceros que han estado aprovechando la complejidad de AD FS.

Y por si no queda claro, todo esto es gratis. Microsoft ha apostado su futuro a sus servicios en la nube Azure. La compañía quiere que la adopción de estos servicios sea lo más fácil posible, y en el mundo actual centrado en Active Directory eso significa hacer que la integración de AD con Azure AD sea rápida e indolora. Se ha tardado una eternidad en sacar a la luz estas capacidades, pero predigo que se convertirán rápidamente en el puente de identidad más popular entre la identidad Microsoft local y la identidad Microsoft en la nube.