Búsqueda de sitios web

Implementación de Servicios de Federación de Active Directory paso a paso parte II

En el blog anterior (Implementación de los Servicios de Federación de Active Directory paso a paso) le mostré cómo instalar y configurar los Servicios de Federación de Active Directory (ADFS) en su red interna y DMZ, capaces de manejar solicitudes de autenticación de Office 365. En este blog te mostraré cómo configurar Office 365 y cómo probarlo.

Dominios federados

En un dominio administrado típico, las cuentas de usuario y los hashes de contraseñas se sincronizan con Azure Active Directory. Office 365 utiliza controladores de dominio en Azure AD para autenticar a los usuarios y otorgarles acceso a los recursos en la nube.

En un dominio federado, el usuario accede a Office 365, pero se le niega el acceso y la solicitud se redirige a Azure Active Directory. Allí, se descubre el dominio de origen (el dominio del usuario) y la solicitud se redirige al servidor ADFS según el dominio de origen. Si mi cuenta de usuario es j.wesselius@exchangelabs.nl, mi dominio de origen es exchangelabs.nl y la solicitud se redirige al servidor de federación que se creó anteriormente y que se usó para configurar el dominio en Azure Active Directory.

Hice una sesión sobre esto en IT Dev Connections en 2017 (en San Francisco). La siguiente es una diapositiva animada que se puede descargar y que muestra el flujo entre un cliente, Office 365, Azure AD y el ADFS y el controlador de dominio locales. :

Para que esto funcione, el dominio de Azure Active Directory debe convertirse en un dominio federado para que Azure AD sepa que cualquier solicitud de autenticación debe redirigirse al entorno ADFS local.

Al agregar un dominio a Azure Active Directory, se crea automáticamente como un dominio administrado. Como se dijo antes, la autenticación se realiza contra controladores de dominio en Azure AD. Puede verificar un dominio usando el comando de PowerShell Get-MsolDomain -DomainName exchangelabs.nl como se muestra en la siguiente captura de pantalla:

Para convertir esto en un dominio federado, inicie un comando de PowerShell (con privilegios elevados) e ingrese los siguientes comandos:

[PD] C:\> Connect-MsolService

[PS] C:\> Set-MsolADFSContext -Computadora ams-adfs01.labs.local

[PS] C:\> Convertir-MsolDomainToFederated -DomainName Exchangelabs.nl

Nota. Utilice el FQDN del primer servidor ADFS local con el comando Set-MsolADFSContext, no la URL de federación

Esto conectará la infraestructura local existente a Azure AD y convertirá el dominio en un dominio federado. Ahora, cuando verifique el dominio en Azure AD usando el mismo comando que antes, verá que ahora es un dominio federado:

En la Consola de administración de ADFS, tendrá una nueva confianza para usuarios de confianza (RPT) para usar con Office 365:

Para obtener más detalles en Azure AD sobre la configuración de la federación, puede usar el comando Get-MsolDomainFederationSettings que muestra más información:

Son claramente visibles Logon, Issuer y LogOffUri, que apuntan a nuestra implementación ADFS local. Se puede recuperar aún más información usando el comando Get-MsolFederationProperty como se muestra en la siguiente captura de pantalla:

Para probar la nueva configuración, navegue hasta el Portal en línea de Microsoft e inicie sesión con una cuenta con el dominio que acabamos de configurar, es decir, j.wesselius@exchangelabs.nl:

Al seleccionar esta cuenta, Azure AD determina el dominio de origen (exchangelabs.nl) y redirige a la URL local que se encuentra en la configuración de federación en Azure AD. Verás que esto sucede sobre la marcha en tu navegador:

Y unos segundos más tarde somos redirigidos a nuestro entorno ADFS local:

Claramente visible es el Nombre para mostrar del Servicio de Federación que se configuró con el primer servidor ADFS en la publicación de blog anterior.

Ingrese su contraseña y, qué maravilla, MFA también sigue funcionando (lo cual fue una agradable sorpresa para mí ?):

Otra prueba interesante es usar el Analizador de conectividad remota (https://aka.ms/exrca) que tiene una prueba de inicio de sesión único. Navegue hasta el Analizador de conectividad remota, haga clic en la pestaña Office 365 y seleccione el Inicio de sesión único de Office 365. En el botón de opción de prueba.

Ingrese nombre de usuario y contraseña, haga la prueba del código de verificación y espere los resultados. Verá algo similar a la siguiente captura de pantalla:

El intento de inicio de sesión fue exitoso, pero lo más interesante es que puede expandir todos los pasos de la prueba para ver qué sucede bajo el capó e intentar comprender cómo funciona ADFS.

Resumen

En las dos publicaciones de blog anteriores, demostré cómo instalar y configurar ADFS en su infraestructura local. Instalé solo un servidor ADFS y un proxy WAP, lo que está lejos de ser un entorno de alta disponibilidad. ¿Por qué alta disponibilidad? Sin el servidor ADFS ya no es posible iniciar sesión en ningún servicio de Office 365, por lo que una infraestructura de alta disponibilidad es un requisito para cualquier implementación de ADFS.

Pero los clientes se están trasladando a la nube para desmantelar sus soluciones locales y con ADFS estamos creando una solución local para autenticar soluciones en la nube. Pero por razones de cumplimiento, podría ser necesario autenticarse contra controladores de dominio locales (por ejemplo, sin contraseñas en la nube). Por otro lado, también puede utilizar la autenticación Pass Through (PTA, consulte mi entrada de blog Autenticación Pass Through de Azure AD Connect) para esto. PTA aún no ofrece tantas posibilidades como ADFS, pero está mejorando.

¿ADFS está preparado para el futuro? Algunas personas dicen que no lo es, pero mientras encuentre artículos como Novedades de los Servicios de Federación de Active Directory para Windows Server 2019 en el sitio web de Microsoft, no veo demasiados problemas con eso.

Más información

  • Mapa de contenido de ADFS (Wiki): https://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-content-map.aspx#Office_365
  • Implementación de su plan de diseño de AD FS: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/implementing-your-ad-fs-design-plan
  • Guía de implementación de AD FS 2016: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/ad-fs-deployment-guide
  • Guía de implementación de AD FS de Windows Server 2012 R2: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/windows-server-2012-r2-ad-fs-deployment-guide
  • Protección de los recursos en la nube con Azure Multi-Factor Authentication y AD FS: https://docs.microsoft.com/en-us/Azure/active-directory/authentication/howto-mfa-adfs
  • Cuándo utilizar una regla de reclamación de autorización: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/when-to-use-an-authorization-claim-rule
  • OWA y ECP inician sesión con AD FS a través de WAP: https://vandijk.cloud/owa-and-ecp-login-with-ad-fs-through-the-wap/
  • Personalización del inicio de sesión de usuario de AD FS: https://docs.microsoft.com/nl-nl/windows-server/identity/ad-fs/operaciones/ad-fs-user-sign-in-customization
  • Personalización avanzada de ADFS para el uso de la nube (Parte 2 de 4): https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 2 de 4/
  • Personalización avanzada de ADFS para el uso de la nube (Parte 3 de 4): https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 3 de 4/
  • Personalización avanzada de ADFS para el uso de la nube (Parte 4 de 4): https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 4 de 4/

Artículos relacionados