Inicio de sesión único y autenticación PassThrough de Azure AD Connect

En mi entrada de blog anterior hablé de la autenticación Pass-Through (PTA) de Azure AD Connect, cómo funciona y cómo se puede configurar. En esa publicación de blog no habilité el inicio de sesión único (SSO) y ese fue también el primer comentario que recibí, en uno o dos días. Habilitar SSO y cómo funciona es el tema de esta publicación de blog.

Flujo de autenticación

Ya expliqué el flujo de autenticación al usar PTA. Al acceder a un servicio en Office 365, se le redirige a Azure AD, ingresa sus credenciales y las credenciales se colocan en Azure Service Bus. El servidor de Azure AD Connect recupera estas credenciales del Service Bus y las presenta al controlador de dominio local. El resultado se devuelve al bus de servicio y se le concede el acceso o, por supuesto, se le niega el acceso cuando algo anda mal.

Entonces, ¿qué sucede si habilita SSO en el asistente de Azure AD Connect? Habilitar SSO es solo cuestión de marcar la casilla de verificación Habilitar inicio de sesión único en el asistente de Azure AD Connect:

Nota. Me salté la mayoría de los pasos de configuración ya que son idénticos a los pasos de configuración de la publicación de blog anterior.

Durante el asistente de Azure AD Connect, también debe ingresar sus credenciales de administrador local, que son necesarias para configurar su Active Directory local para habilitar SSO con PTA.

Para ser justos, no es un verdadero SSO como ocurre con la federación (a través de ADFS), pero es un inicio de sesión único (sSSO) fluido. Al habilitar SSO en el asistente de Azure AD Connect, los usuarios solo necesitan ingresar su nombre de inicio de sesión al acceder a los servicios en Office 365, por ejemplo con Outlook Web App:

Cuando se encuentra en una estación de trabajo unida a un dominio que tiene acceso a un controlador de dominio, solo tiene que seleccionar la cuenta de usuario adecuada. La contraseña se devuelve automáticamente a Azure AD y, si todo está bien, se le concede acceso a Outlook Web App.

Si no desea seleccionar o ingresar un nombre de inicio de sesión, también puede usar sugerencias de dominio. En combinación con Outlook Web App, usaría una URL como https://outlook.office.com/owa/contoso.com. Si lo hace, sus credenciales actuales (nuevamente, en una estación de trabajo unida a un dominio que tiene acceso a un controlador de dominio) se transfieren automáticamente y se le concede acceso.

Inicio de sesión único sin costuras debajo del capó

Pero, ¿cómo funciona realmente este sSSO bajo el capó?

Al habilitar SSO en el asistente de Azure AD Connect, debe ingresar su cuenta de administrador de dominio local. Esto se utiliza para crear un objeto de computadora adicional en Active Directory llamado AZUREADSSOACC.

Esta cuenta de computadora se usa para crear una clave Kerberos compartida entre su Active Directory local y Azure Active Directory, necesaria para crear la experiencia sSSO.

Durante el inicio de sesión en este escenario, se producen los siguientes 8 pasos:

1. El cliente accede a un servicio en la nube de Microsoft, por ejemplo OWA a través de https://outlook.office.com/owa.
2. La solicitud se redirige desde Office 365 a Azure Active Directory.
3. Se deniega el acceso y se devuelve un error 401 al cliente.
4. El cliente accede a un controlador de dominio local y solicita un token Kerberos.
5. Se devuelve al cliente un ticket de sesión de Kerberos.
6. El ticket de sesión se presenta en Azure Active Directory. Dado que Azure Active Directory tiene un ticket compartido con su Active Directory local, puede generar un token de Kerberos para que lo use el cliente.
7. El token Kerberos se devuelve al cliente.
8. El token Kerberos se presenta en Office 365 y se concede el acceso. El usuario ahora puede empezar a utilizar OWA.

Como puede ver, esto solo funciona para clientes unidos a un dominio que tienen acceso a un controlador de dominio local. Si no tienen acceso a un controlador de dominio local, se sigue el proceso habitual de la PTA como se muestra al principio de esta publicación de blog (y de la publicación de blog anterior).

Nota. Para que el cliente pase automáticamente las credenciales, los puntos finales de Azure AD deben estar en la zona de intranet

• https://autologon.microsoftazuread-sso.com
• https://aadg.windows.net.nsatc.net

Consejo. Utilice GPO para cambiar esto para todos los clientes de su red.

Si usa su navegador y navega a Exchange Online, aún se le pedirá que ingrese su nombre de usuario (o seleccione un nombre de usuario cuando lo usó anteriormente), pero no es necesario que ingrese su contraseña:

Si utiliza una sugerencia de dominio en su URL como https://outlook.office.com/owa/inframan.nl, la cuenta inicia sesión automáticamente. Una pequeña pero extraña nota: esto es compatible con Microsoft Internet Explorer, pero no con el navegador Microsoft Edge (al menos no en el momento de escribir este artículo, a principios de noviembre de 2017). Sin embargo, esto podría cambiar en el futuro.

Para que esto funcione con Outlook 2016 (o Outlook 2013 completamente parcheado que admita la autenticación moderna), debemos habilitar OAuth a nivel de inquilino. Para lograr esto, inicie sesión y use PowerShell remoto en Exchange Online usando los siguientes comandos:

$Cred= Get-Credential 'administrator@contoso.onmicrosoft.com'
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession -Session $Session

Y cuando inicie sesión ingrese el siguiente comando:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$TRUE

La próxima vez que inicie Outlook verá que iniciará sesión automáticamente en Exchange Online (mientras que no lo hacía cuando Oauth no estaba habilitado).

Nota. Como se describió anteriormente en esta publicación, existe una clave compartida entre la cuenta de computadora en su Active Directory local y Azure Active Directory. Se recomienda encarecidamente renovar estas claves cada 30 días. Para obtener más información, consulte las preguntas frecuentes de Microsoft sobre esto: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Resumen

Puede utilizar la autenticación Pass-Through si necesita mantener todas las contraseñas de los usuarios en las instalaciones (y, por lo tanto, no almacenarlas en la nube de Microsoft). Al utilizar la autenticación Pass-Through, también puede habilitar el inicio de sesión único o sSSO sin interrupciones. De esta manera, los clientes unidos a un dominio (que tienen acceso a un controlador de dominio) pueden usar la autenticación Kerberos para acceder a los servicios en la nube de Microsoft.

Una serie de cuestiones a tener en cuenta: no todos los clientes admiten PTA o sSSO como se describe en este artículo. Por ejemplo, Internet Explorer lo admite, pero el navegador Edge no. Outlook 2013/2016 lo admite (autenticación moderna), pero Outlook 2010 no. Además, Lync/Skype para clientes empresariales no admite esto en absoluto. Espero que esto cambie en un futuro (próximo) y, cuando lo haga, actualizaré este artículo.

Más información

Inicio de sesión único sin interrupciones en Azure Active Directory: preguntas frecuentes: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq