Aumento de la resistencia de la autenticación para aplicaciones federadas implementadas en sitios con usuarios colocados

Un escenario en el que muchas organizaciones que crean resistencia en su arquitectura de administración de identidades y acceso deben adaptarse es la continuidad del acceso a las aplicaciones durante la desconexión temporal del sitio. La organización puede tener uno o varios sitios físicos en los que se implementan sus aplicaciones. Algunos de sus usuarios están colocados en esos sitios y necesitan poder acceder a las aplicaciones locales. Por ejemplo, es posible que los empleados de una fábrica o de una tienda necesiten poder iniciar sesión en aplicaciones empresariales desarrolladas internamente que administran operaciones en ese sitio.

Históricamente, las organizaciones podían usar Active Directory Domain Services, implementar controladores de dominio en cada sitio para que los usuarios pudieran autenticarse en un controlador de dominio local. Autenticar a los usuarios a través de Microsoft Entra y conectar aplicaciones a Microsoft Entra ID a través de protocolos de federación como SAML aporta ventajas, incluida la autenticación multifactor y el acceso condicional basado en riesgos. Cuando las aplicaciones están federadas a Microsoft Entra, los usuarios se autentican en Microsoft Entra y, a continuación, Microsoft Entra proporciona tokens que llevan notificaciones e indican su estado de autenticación a las aplicaciones. Sin embargo, si hay una interrupción en la conectividad de red entre el sitio e Internet, los usuarios y las aplicaciones no pueden acceder a los puntos de conexión de la nube de Microsoft Entra. Con esa interrupción en la conectividad, no se pueden emitir más tokens de Microsoft Entra a las aplicaciones a través de esa ruta hasta que se repare la interrupción. Los usuarios ya autenticados en la aplicación y pueden conectarse a la aplicación pueden seguir usando la aplicación durante un tiempo. Sin embargo, si la aplicación requiere que el usuario vuelva a autenticarse y la interrupción aún no se haya reparado, el usuario no podrá obtener un nuevo token de acceso de Microsoft Entra. Además, hasta que se repare la interrupción, cualquier usuario que no se hubiera conectado previamente a la aplicación puede que también no pueda usar la aplicación.

Un enfoque para resolver este problema y asegurarse de que los tokens se pueden emitir a las aplicaciones federadas incluso durante la desconexión temporal del sitio es:

• Mantenimiento de un controlador de dominio de Active Directory en cada sitio
• Asegúrese de que los usuarios de un sitio pueden autenticarse en Active Directory o bien Microsoft Entra y que las mismas reclamaciones están disponibles en ambos proveedores de identidad.
• Configurar aplicaciones para confiar en Microsoft Entra como proveedor de identidades durante las operaciones normales, pero durante un evento de desconexión, confíe en Active Directory como proveedor de identidades.

Sin embargo, para algunas aplicaciones federadas empaquetadas previamente, es posible que la aplicación se haya diseñado para funcionar con un único proveedor de identidades a la vez y es posible que no sea factible configurar las aplicaciones para que tengan varios proveedores de identidades de confianza. Incluso para las organizaciones con aplicaciones desarrolladas internamente diseñadas para un único proveedor de identidades, puede requerir un esfuerzo de ingeniería significativo para implementar un proceso que cambie muchas aplicaciones con diferentes modelos de configuración.

Un enfoque alternativo, descrito en este tutorial, es agregar un servicio de token de seguridad (STS) de usuario de confianza, como AD FS a la topología. En esta topología,

• Mantenimiento de un controlador de dominio de Active Directory en cada sitio
• Asegurarse de que los usuarios de un sitio pueden autenticarse en Active Directory o Microsoft Entra
• Configuración de aplicaciones para confiar en el servicio de token de seguridad de usuario de confianza local (STS)
• Configure el STS de la parte confiable para confiar en Microsoft Entra como proveedor de identidades durante las operaciones normales, pero durante un evento de desconexión, confíe en Active Directory como proveedor de identidades.

En este tutorial se muestra cómo configurar Microsoft Entra para una aplicación de federación mediante un STS de parte confiable. En las operaciones normales, los usuarios se autenticarán en Microsoft Entra y Microsoft Entra emitirá tokens para la aplicación. Y en una situación de desconexión del sitio, los usuarios pueden autenticarse con Active Directory y obtener tokens para esa aplicación con afirmaciones similares a las proporcionadas por Microsoft Entra. Aunque las características de Microsoft Entra, incluida la autenticación multifactor o el acceso condicional basado en riesgos, no estarán disponibles para las aplicaciones durante el tiempo de desconexión, los usuarios seguirán siendo capaces de autenticarse para acceder a esas aplicaciones.

Importante

Esta guía está pensada para organizaciones que ya están familiarizadas con la implementación de controladores de dominio en varios sitios y el uso de tecnología de federación, como AD FS, para proporcionar a los usuarios de Active Directory acceso a aplicaciones basadas en notificaciones. La arquitectura y la implementación de Active Directory, AD FS y las tecnologías relacionadas para alta disponibilidad y resistencia a las interrupciones de red es una inversión considerable. Antes de comenzar el recorrido descrito en este artículo, determine la topología de implementación de AD FS. Si no ha implementado un dominio de AD para alta disponibilidad o ha comprobado que el entorno de producción puede admitir una implementación de AD FS, seleccione un enfoque alternativo para la resistencia.

Se recomienda usar un entorno que no sea de producción para probar los pasos descritos en este artículo, antes de configurar una aplicación o conmutación por error en un inquilino de producción.

Prerrequisitos

Este tutorial se basa en un inquilino de Microsoft Entra y en un dominio de Active Directory. Antes de comenzar, asegúrese de tener uno de los siguientes roles en Microsoft Entra: Cloud Application Administrator, Application Administrator. También necesitará permisos para administrar AD.

Deberá asegurarse de que en cada sitio hay suficientes componentes de infraestructura para admitir las aplicaciones sin depender de las conexiones a Internet u otros sitios. En este tutorial se muestra la configuración de:

• Una o varias aplicaciones, cada una de las cuales implementa un protocolo de federación como SAML con el patrón de inicio de sesión iniciado por el usuario de confianza. Para más información, consulte Protocolo SAML de inicio de sesión único. En este tutorial se muestra una configuración en la que, si tiene más de una aplicación, se puede autenticar el mismo conjunto de usuarios y está autorizado para todas las aplicaciones. La configuración de diferentes conjuntos de usuarios para cada aplicación está fuera del ámbito de este tutorial.
• Un componente de identidad que se puede configurar para que funcione como un STS de usuario de confianza, como los servicios de federación de Active Directory. Este tutorial asume el uso de Windows Server 2025. Como procedimiento recomendado de seguridad, coloque los servidores de Federación de Servicios de Federación de Active Directory detrás de un firewall y conéctelos a la red corporativa para evitar la exposición desde Internet. Esta práctica es importante porque los servidores de federación tienen autorización completa para conceder tokens de seguridad. Por lo tanto, deben tener la misma protección que un controlador de dominio. Si un servidor de federación está en peligro, un usuario malintencionado tiene la capacidad de emitir tokens de acceso completos a todas las aplicaciones web protegidas por los Servicios de federación de Active Directory. Para obtener más información, consulte dónde colocar un servidor de federación.
• Un controlador de dominio de Active Directory. En un entorno de producción, necesitará varios controladores de dominio, configurados para alta disponibilidad.

Las aplicaciones pueden tener otros requisitos más allá de estos requisitos de identidad, como los requisitos para la retención de registros, DNS/DHCP u otros servicios de red e infraestructura, que están fuera del ámbito de este tutorial.

Garantizar identidades y atributos de usuario coherentes en Active Directory e id. de Microsoft Entra

Las aplicaciones esperarán recibir las mismas reclamaciones para los usuarios en el token de federación de un STS de parte confiable, independientemente del proveedor de identidad configurado. Para que el STS de la parte dependiente proporcione las mismas reclamaciones que se esperan de Microsoft Entra ID, incluso cuando Microsoft Entra ID no sea accesible, debe existir un origen de identidades de usuario y sus atributos locales en el sitio que el STS de la parte dependiente pueda utilizar para generar las reclamaciones. AD FS admite Windows Server Active Directory como origen de identidad y esos atributos de usuario de Active Directory como fuente de reclamaciones.

Una manera de mantener la coherencia es definir un proceso de administración de identidades que cree y actualice a los usuarios en AD y, a continuación, sincronice esos usuarios de AD a Microsoft Entra. Compruebe que el entorno de AD y los agentes de Microsoft Entra asociados están listos para transportar a los usuarios hacia y fuera de AD con el esquema necesario para las aplicaciones.

Si ya ha configurado los usuarios para que se sincronicen desde Active Directory a Microsoft Entra, continúe en la sección siguiente.

1. Habilite la Papelera de reciclaje de Active Directory. La función de la papelera de reciclaje es necesaria para que los flujos de trabajo del ciclo de vida de Microsoft Entra puedan eliminar usuarios de AD. Para obtener más información, consulte Habilitación y administración de la papelera de reciclaje de Active Directory mediante el Centro de administración de Active Directory.

2. Amplíe el esquema de Active Directory, si es necesario. Para cada atributo de usuario requerido por Microsoft Entra y las aplicaciones que aún no forman parte del esquema de usuario de Active Directory, debe seleccionar un atributo de extensión de usuario predefinido. O bien, debe extender el esquema de Windows Server AD para que tenga un lugar para que AD contenga ese atributo. Este requisito también incluye atributos utilizados para la automatización, como la fecha de contratación y la fecha de baja de un trabajador.

   Por ejemplo, algunas organizaciones pueden usar los atributos extensionAttribute1 y extensionAttribute2 contener estas propiedades. Si decide usar los atributos de extensión integrados, asegúrese de que esos atributos aún no están en uso por ninguna otra aplicación basada en LDAP o por otras aplicaciones integradas con el id. de Microsoft Entra. Algunas organizaciones han creado nuevos atributos de AD con nombres específicos de sus requisitos, como contosoWorkerId. Sin embargo, la extensión del esquema con nuevos atributos tiene implicaciones significativas en la administración de dominios de Windows Server. Para obtener más información, consulte extensión del esquema.

3. Incorpore a los usuarios sus atributos de orígenes autoritativos. Si aún no lo ha hecho, configure Microsoft Entra para aprovisionar trabajadores de Workday, SuccessFactors u otros orígenes de RR. HH . como usuarios de AD. Puede asignar las propiedades de los registros de trabajo a los atributos de usuario en el esquema de AD.

4. Configurar la sincronización entre Microsoft Entra y Active Directory. Configure la sincronización de Microsoft Entra Connect o la sincronización en la nube de Microsoft Entra para sincronizar esos usuarios de AD con Microsoft Entra. Implemente también el agente de aprovisionamiento para llevar a cabo tareas relacionadas con las cuentas de usuario dentro del flujo de trabajo del ciclo de vida, como eliminar usuarios del Active Directory.

5. Amplíe el esquema de Id. de Microsoft Entra y configure las asignaciones del esquema de Active Directory al esquema de usuario de Id. de Microsoft Entra. Si usa Microsoft Entra Connect Sync, siga los pasos descritos en Microsoft Entra Connect Sync: Extensiones de directorio para ampliar el esquema de usuario de Id. de Microsoft Entra con atributos. Configure las asignaciones de Sincronización de Microsoft Entra Connect para los atributos de AD en los atributos de Microsoft Entra ID.

   Si usa Microsoft Entra Cloud Sync, siga los pasos descritos en Extensiones de directorio de Microsoft Entra Cloud Sync y asignación de atributos personalizados para ampliar el esquema de usuario de Id. de Microsoft Entra con cualquier otro atributo necesario. Configure las asignaciones de Microsoft Entra Cloud Sync para los atributos de AD a los atributos de Microsoft Entra. Asegúrese de que está sincronizando los atributos necesarios para los flujos de trabajo del ciclo de vida.

6. Cree un flujo de trabajo de salida que bloquee los inicios de sesión. En Flujos de trabajo del ciclo de vida de Microsoft Entra, configure un flujo de trabajo de salida con una Disable user account tarea que bloquee a los usuarios para que no inicien sesión en las instalaciones. Este flujo de trabajo se puede ejecutar a petición. Si no configuró el aprovisionamiento de entrada desde los orígenes de registro para impedir que los trabajadores inicien sesión después de su fecha de salida programada, configure un flujo de trabajo de baja con esa tarea para que se ejecute en las fechas de salida programadas de esos trabajadores. Para obtener más información, consulte Administración de usuarios sincronizados desde el entorno local.

7. Cree un flujo de trabajo de leaver para eliminar cuentas de usuario. En los flujos de trabajo del ciclo de vida de Microsoft Entra, configure un flujo de trabajo de salida con una tarea Delete user para eliminar a un usuario de Active Directory. Programe este flujo de trabajo para que se ejecute durante algún período de tiempo, como 30 o 90 días, después de la fecha de salida programada del trabajador.

Para obtener más información sobre cómo configurar flujos de entrada de RR. HH. para aplicaciones con varios atributos, consulte Planear la implementación de Microsoft Entra para el aprovisionamiento de usuarios.

Proporcionar una opción de autenticación para los usuarios de Active Directory

Al configurar el aprovisionamiento de entrada desde un origen de RR. HH. en AD, Microsoft Entra crea usuarios en AD, tanto para los trabajadores existentes que anteriormente no tenían cuentas de usuario de AD como para los nuevos trabajadores que se unieron más adelante. Esos usuarios deberán poder autenticarse en AD mientras están desconectados y también podrán autenticarse en microsoft Entra ID durante las operaciones normales. Deberá planear la emisión de credenciales para los empleados que necesitan acceder a aplicaciones que pueden utilizar con AD.

Si las únicas aplicaciones conectadas a AD están configuradas para lograr resistencia, una manera de tener autenticación coherente es crear usuarios en AD y, a continuación, activar la sincronización de hash de contraseñas para aquellos usuarios que se sincronizan entre AD y Microsoft Entra. Asegúrese de que los usuarios tienen contraseñas establecidas en AD y saben su contraseña en AD. Aunque pueden tener requisitos de autenticación multifactor durante las operaciones normales, durante un evento de red desconectado, podrían autenticarse en el dominio de Active Directory con sus contraseñas.

Otra opción es usar la autenticación basada en certificados (CBA) de Microsoft Entra, que permite a Microsoft Entra autenticar a los usuarios mediante certificados X.509 emitidos por una infraestructura de clave pública empresarial (PKI). AD también admite la autenticación de certificados y algunas organizaciones han emitido tarjetas inteligentes, tarjetas inteligentes virtuales o certificados de software a sus usuarios. Si los usuarios interactuarán con aplicaciones de dispositivos que admiten Windows Hello para empresas, considere también la posibilidad de inscribir usuarios en Windows Hello para empresas para una autenticación más sólida.

Implementar un STS de entidad de confianza

Si aún no lo ha hecho, implemente AD FS o una tecnología de identidad similar en uno o varios servidores de Windows en un sitio. Este AD FS se configurará para que funcione como un STS de parte confiable, por lo que no puede ser la misma instalación que otro AD FS configurado como proveedor de identidades para proporcionar reclamaciones a Microsoft Entra.

Nota:

Si ya usa AD FS como proveedor de identidades para Microsoft Entra, este STS de parte confiable debería ser una instalación distinta en servidores que pertenezcan a un dominio independiente. Separar las implementaciones de AD FS por rol ayudará a evitar una dependencia circular entre Microsoft Entra y AD FS.

Nota:

En esta guía no se explica cómo implementar AD para alta disponibilidad o cómo implementar una granja de servidores de federación u otras consideraciones sobre la alta disponibilidad en el entorno de Windows Server.

Si usa la autenticación basada en certificados, también deberá configurar AD FS para autenticar a los usuarios con certificados. Para obtener más información, consulte Configuración de la compatibilidad de AD FS con la autenticación de certificados de usuario.

Proteger STS de entidad de confianza

Las aplicaciones confiarán en el STS de entidad de confianza para otorgar tokens que indiquen que los usuarios se han autenticado. Para esto se necesita que se asegure de que el STS, los servidores que lo hospedan y los controladores de dominio principales u otros recursos, cumplan con los mismos estándares de seguridad que la infraestructura de identidad en su entorno.

Para obtener más información, consulte Procedimientos recomendados para proteger los servicios de federación de Active Directory.

Conectar aplicaciones federadas al STS de entidad de confianza

Deberá identificar qué aplicaciones de un sitio están autorizadas para estar conectadas al STS de entidad de confianza, en lugar de conectarse directamente a Microsoft Entra. Debe ser el conjunto mínimo necesario para mantener las operaciones durante una pérdida de conectividad. Entre las consideraciones se incluyen las siguientes:

• Las aplicaciones que dependen únicamente de un SDK de la Biblioteca de autenticación de Microsoft (MSAL) para la emisión de tokens no se pueden conectar a un STS de usuario de confianza.
• Las aplicaciones que se han codificado previamente con un único punto de conexión de metadatos de federación o un certificado de emisor pueden requerir cambios adicionales para eliminar esa dependencia antes de integrarse con un STS de parte confiable.
• Las aplicaciones que son capaces de admitir varios proveedores de identidades pueden querer conservar la conexión existente a Microsoft Entra.
• Las aplicaciones asociadas a un STS de parte confiable se representarán como una sola aplicación en Microsoft Entra, por lo que esas aplicaciones tendrán que tener los mismos usuarios, directivas de CA, reclamaciones proporcionadas y otras configuraciones aplicables a ellas. Si dos aplicaciones dependen de Microsoft Entra para limitar la emisión de tokens a diferentes poblaciones de usuarios o tienen requisitos de CA diferentes, no se pueden conectar a la misma STS de usuario de confianza.

Configurar Microsoft Entra como proveedor de identidades para el STS de entidad de confianza.

Siga los pasos descritos en el tutorial Habilitar inicio de sesión único de una aplicación empresarial con un servicio de token de seguridad de entidad de confianza. En ese tutorial, creará una representación de la aplicación en Microsoft Entra, configurará el inicio de sesión único para esa aplicación desde Microsoft Entra al STS del usuario de confianza y configurará el inicio de sesión único desde el STS del usuario de confianza en la aplicación. Al realizar ese tutorial, se validará que, durante las operaciones normales, los tokens con declaraciones pueden fluir desde Microsoft Entra a través del STS de la parte de confianza hacia la aplicación.

Nota:

Se usa una sola representación de aplicación en Microsoft Entra para cada STS de usuario de confianza, independientemente del número de aplicaciones conectadas a ese STS de usuario de confianza. Si tiene varias aplicaciones conectadas a un solo STS de entidad de confianza, se compartirá una aplicación común en Microsoft Entra y, como consecuencia de ello, debe tener los mismos usuarios, directivas de CA, notificaciones proporcionadas y otros ajustes en Microsoft Entra.

Configuración de AD como origen LDAP en el STS de usuario de confianza

A continuación, configure en el STS del usuario de confianza que Active Directory es un origen de notificaciones para las notificaciones necesarias para las aplicaciones. Los pasos siguientes se ilustran usando AD FS, pero se podría usar otro STS de parte confiable en su lugar.

1. Inicie sesión como administrador en un servidor donde se implemente AD FS.
2. Inicie AD FS Management.
3. En el AD FS menú, seleccione Claims Provider Trusts.
4. Asegúrese de que haya dos proveedores de declaraciones, Microsoft Entra y Active Directory, y que ambos estén habilitados. El Active Directory proveedor de reclamaciones está presente de forma predeterminada.
5. Seleccionar Active Directory and Seleccionar Edit Claim Rules.
6. Confirme que hay reglas para los atributos LDAP necesarios como declaraciones de las aplicaciones en su entorno.
7. En el AD FS menú, seleccione Relying Party Trusts.
8. Seleccione la aplicación de destino y seleccione Edit Claim Issuance Policy.
9. Confirme que las reglas para las reclamaciones enviadas a las aplicaciones proporcionan todas las reclamaciones necesarias. Para obtener más información, consulte Procesar o Filtrar una reclamación entrante.

Preparación de un usuario de prueba de AD para estar listo para iniciar sesión en una aplicación a través de Microsoft Entra

Al probar la configuración, debe asignar un usuario de prueba designado que se creó en Active Directory a un rol de una aplicación en Microsoft Entra. Esta selección de un usuario de AD validará que el usuario puede iniciar sesión en la aplicación a través de Microsoft Entra y el servicio de token de seguridad (STS) de la parte de confianza.

1. Identifique un usuario de prueba en Active Directory. Asegúrese de que conoce la contraseña de ese usuario para que pueda autenticarse como ese usuario en Active Directory y Microsoft Entra.

2. Si creó recientemente el usuario en AD, espere a que finalice la sincronización de AD a Microsoft Entra ID.

   Si usa Microsoft Entra Cloud Sync, puede supervisar la steadyStateLastAchievedTime propiedad del estado de sincronización recuperando el trabajo de sincronización de la entidad de servicio que representa Microsoft Entra Cloud Sync. Si no tiene el identificador de la entidad de servicio, consulte Visualización del esquema de sincronización.

3. Inicie sesión en el Centro de administración de Microsoft Entra siendo al menos un Administrador de aplicaciones en la nube.

4. Vaya a Entra ID>Aplicaciones empresariales>Todas las aplicaciones.

5. Escriba el nombre de la aplicación existente en el cuadro de búsqueda y seleccione la aplicación en los resultados de búsqueda.

6. En la sección Administrar del menú izquierdo, seleccione Propiedades.

7. Asegúrese de que el valor de Habilitado para que los usuarios inicien sesión esté establecido en Sí.

8. Asegúrese de que el valor de Asignación necesario esté establecido en Sí.

9. Si ha realizado algún cambio, seleccione Guardar.

10. En la sección Administrar del menú izquierdo, seleccione Usuarios y grupos.

11. Seleccione Agregar usuario o grupo.

12. Seleccione Ninguno seleccionado.

13. En el cuadro de búsqueda, escriba el nombre del usuario de prueba y, a continuación, elija el usuario y seleccione Seleccionar.

14. Seleccione Asignar para asignar el usuario al rol de usuario predeterminado de la aplicación.

15. En la sección Seguridad del menú izquierdo, seleccione Acceso condicional.

16. Selecciona What if.

17. Seleccione No hay usuario o entidad de servicio seleccionada, seleccione Ningún usuario seleccionado y seleccione el usuario asignado previamente a la aplicación.

18. Seleccione Cualquier aplicación en la nube y seleccione la aplicación empresarial.

19. Selecciona What if. Valide que las directivas que se aplicarán permitan al usuario iniciar sesión en la aplicación.

Establezca el proveedor de declaraciones para cada aplicación a Microsoft Entra.

Una vez configurada una aplicación en Microsoft Entra y la parte confiable STS, los usuarios pueden iniciar sesión en ella. Los usuarios comenzarán autenticándose en Microsoft Entra, y su parte de confianza STS, como AD FS, transformará un token proporcionado por Microsoft Entra en el formato y las reclamaciones que requiere su aplicación. Además, los usuarios podrán iniciar sesión autenticándose en AD y recibir un token proporcionado por AD FS con atributos similares.

En esta sección, configurará el STS del usuario de confianza para ofrecer a Microsoft Entra como proveedor de identidades para cada aplicación durante las operaciones normales. Los pasos siguientes se ilustran usando AD FS, pero se podría usar otro STS de parte confiable en su lugar.

1. Inicie PowerShell en un servidor windows en el que está instalado AD FS.
2. Obtenga la lista de aplicaciones mediante el comando Get-AdfsRelyingPartyTrust | ft Name,ClaimsProviderName.
3. Obtenga la lista de proveedores de reclamaciones mediante el comando Get-AdfsClaimsProviderTrust | ft Name. Debe haber dos nombres, uno para Active Directory y el otro para Microsoft Entra.
4. Configura que Microsoft Entra sea el único proveedor de declaraciones para cada aplicación mediante el comando Set-AdfsRelyingPartyTrust. Por ejemplo, si la aplicación se denomina appname, escriba Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Microsoft Entra". Repita esto para cada aplicación. Para obtener más información, consulte Configuración de una lista de proveedores de identidades por usuario de confianza.

Valide el inicio de sesión único durante las operaciones normales

En esta sección, validará que los usuarios pueden autenticarse sin problemas en Microsoft Entra e iniciar sesión en una aplicación durante las operaciones normales.

1. En una sesión de exploración privada del explorador web, conéctese a una aplicación e inicie el proceso de inicio de sesión. La aplicación redirige el explorador web a la parte de confianza STS AD FS, y AD FS determina los proveedores de identidades que pueden proporcionar declaraciones adecuadas.
2. En función de la configuración de la sección anterior, AD FS seleccionará el proveedor de identidades de Microsoft Entra. AD FS redirige el explorador web al punto de conexión de inicio de sesión de Microsoft Entra, https://login.microsoftonline.com si usa el servicio global Microsoft Entra ID.
3. Inicie sesión en Microsoft Entra con la identidad del usuario de prueba, configurado anteriormente en la sección preparación de un usuario de prueba de AD para que esté listo para iniciar sesión en una aplicación. A continuación, Microsoft Entra localiza la aplicación empresarial basada en el identificador de entidad y redirige el explorador web a AD FS en su punto de conexión de dirección URL de respuesta, con el explorador web que transporta el token SAML.
4. AD FS valida que el token SAML fue emitido por Microsoft Entra, luego extrae y transforma las reclamaciones del token SAML, y redirige el navegador web a la aplicación. Confirme que la aplicación ha recibido las notificaciones necesarias de Microsoft Entra a través de este proceso.

Validar el inicio de sesión único después de cambiar el proveedor de reclamaciones de confianza de la aplicación a Active Directory

En esta sección, validará que, al cambiar el proveedor de identidades de una aplicación a Active Directory, los usuarios todavía pueden autenticarse e iniciar sesión en la aplicación.

1. Inicie PowerShell en un servidor windows en el que está instalado AD FS.
2. En la sesión de PowerShell, configure para que Active Directory sea ahora el único proveedor de declaraciones de la aplicación, reemplazando a Microsoft Entra, mediante el comando Set-AdfsRelyingPartyTrust. Por ejemplo, si la aplicación se denomina appname, escriba Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Active Directory".
3. Para borrar cualquier estado de inicio de sesión en el explorador, cierre cualquier sesión de exploración privada del explorador web abierta anteriormente.
4. En una nueva sesión de exploración privada del explorador web, conéctese a esa aplicación e inicie el proceso de inicio de sesión. La aplicación redirige el navegador web a AD FS, y AD FS determina los proveedores de identidades que pueden proporcionar declaraciones apropiadas.
5. En función de la configuración del paso 2, AD FS seleccionará Active Directory.
6. Inicie sesión en AD FS con la identidad de Active Directory del usuario de prueba. AD FS autenticará al usuario en Active Directory.
7. AD FS transforma los atributos LDAP del usuario en notificaciones y redirige el explorador web a la aplicación. Confirme que la aplicación ha recibido las notificaciones necesarias de Active Directory a través de este proceso.
8. En la sesión de PowerShell, configure que Microsoft Entra vuelva a ser el proveedor de declaraciones de la aplicación, utilizando el comando Set-AdfsRelyingPartyTrust y proporcione el valor del parámetro -ClaimsProviderName. También puede permitir todos los proveedores de reclamaciones con un comando como Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName @().

Configuración de quién puede iniciar sesión en la aplicación

A continuación, deberá configurar quién puede iniciar sesión en cada aplicación. AD FS y Microsoft Entra tienen diferentes mecanismos para determinar el ámbito de la emisión de tokens en sus directivas, por lo que es posible que tenga que realizar cambios en ambos.

1. Anteriormente ha asignado un usuario de prueba en Microsoft Entra a una función de una aplicación; por lo tanto, puede que desee quitar la asignación de funciones del usuario de prueba ahora.
2. Si tiene varias aplicaciones conectadas al mismo STS de usuario de confianza, en Microsoft Entra, es posible que solo pueda tener un único objeto de aplicación que represente todas esas aplicaciones. Para las asignaciones de roles, puede usar características como grupos dinámicos o administración de derechos para asignar usuarios a un rol de aplicación. Si el usuario tiene pertenencia al rol de aplicación, podrá recibir un token de Microsoft Entra.
3. Además, AD FS también aplica directivas de control de acceso asignadas a las aplicaciones. Cualquier directiva que seleccione para la aplicación debe ser evaluada por AD FS para los tokens de Microsoft Entra y para los usuarios que se autentican en AD. Como los tokens de Microsoft Entra no pasan a través de Active Directory, no puede usar la directiva de control de acceso Permitir grupo específico, ya que eso denegaría los tokens de Microsoft Entra. Si desea controlar el acceso en AD FS para la emisión de tokens desde AD, deberá usar una directiva diferente en su lugar. Para obtener más información sobre las directivas de control de acceso, vea Directivas de control de acceso en AD FS.

Configurar una tarea para realizar una recuperación automática frente a errores en AD y Microsoft Entra.

A continuación, deberá configurar un monitor para la conectividad desde el sitio. Este monitor activará un cambio automático en el proveedor de identidad para cada aplicación de AD FS de Microsoft Entra a Active Directory cuando se detecte una desconexión, invocando el comando Set-AdfsRelyingPartyTrust para esa aplicación. Opcionalmente, es posible que desee configurar un monitor para restablecer la configuración de AD FS cuando se detecte que la conectividad ha sido restaurada.

Para un entorno sencillo, puede implementar un monitor mediante un script de PowerShell y el programador de tareas integrado. Para una implementación escalada horizontalmente, la implementación de un monitor depende del sistema de automatización de TI en uso en su organización y está fuera del ámbito de este artículo.

Configurar una tarea programada de ejemplo para que AD FS realice un proceso de recuperación frente a errores en AD

1. Cree un script que detecte un error de conexión de red desde el sitio e invoque Set-AdfsRelyingPartyTrust para cambiar el proveedor de identidades. Puede encontrar un ejemplo de un script en https://github.com/microsoft/Entra-reporting/blob/main/PowerShell/sample-changeover-multiple-apps.ps1. Tenga en cuenta que si descarga un script, deberá usar el Explorador de archivos para desbloquear el script antes de poder ejecutarlo en PowerShell.
2. Copie el script en un servidor de Windows Server con AD FS.
3. Edite el script para que coincida con la configuración de AD FS y la lista de aplicaciones configuradas en AD FS en ese sitio.
4. Inicie PowerShell en un servidor windows en el que está instalado AD FS.
5. Registre un origen para que el script pueda escribir en el registro de eventos de la aplicación. Por ejemplo, si el script se denomina AD FS changeover script, escriba el comando New-EventLog -LogName Application -Source "AD FS changeover script".
6. Inicie el Visor de eventos y vaya al registro recién creado.
7. Pruebe el script ejecutándolo en PowerShell para asegurarse de que funciona correctamente desde una sesión interactiva.
8. Inicie el Programador de tareas y vea la biblioteca del programador de tareas.
9. Si aún no tiene una carpeta para las tareas de Task Scheduler, cree una carpeta.
10. Seleccione la carpeta de las tareas y, a continuación, seleccione Crear tarea.
11. Rellene la configuración de la pestaña General de la tarea.
12. Cambie a la pestaña Desencadenadores . Seleccione Nuevo y proporcione una programación de periodicidad para la tarea, en consonancia con las instrucciones de red y riesgos de su organización.
13. Cambie a la pestaña Acciones . Seleccione Nuevo y seleccione una acción para Iniciar un programa. Especifique powershell.exe como programa y especifique los argumentos necesarios para invocar el script de PowerShell. Por ejemplo: -NonInteractive -WindowStyle Hidden -File c:\scripts\ad_fs_changeover_script.ps1. A continuación, seleccione Aceptar para cerrar la ventana de acción y Aceptar para cerrar la ventana de tareas. Para obtener más información, vea acerca de powershell.exe.
14. Seleccione Ejecutar, espere un minuto y, a continuación, seleccione Actualizar. Asegúrese de que el script se inició y se completó correctamente y compruebe el Visor de eventos para ver si se registraron errores.

Configuración de la invalidación de sesión (opcional)

Las aplicaciones también pueden tener sesiones de usuario derivadas del usuario que se hayan autenticado. Por ejemplo, una aplicación basada en explorador puede autenticar a un usuario y, a continuación, almacenar una cookie del explorador que indica que el usuario se ha autenticado. Es posible que desee que las aplicaciones se basen en los proveedores de identidades desconectados durante un período lo más corto posible. Por ejemplo, si un usuario no había usado una aplicación antes y, a continuación, la primera vez que el usuario intentó conectarse a una aplicación era cuando el sitio estaba desconectado, windows Server AD realizó la autenticación. Después de esa autenticación, es posible que la aplicación haya almacenado una cookie de sesión para que el usuario pueda seguir interactuando con la aplicación sin necesidad de volver a autenticarse. Sin embargo, una vez que se vuelve a conectar el sitio, es posible que desee que Microsoft Entra vuelva a autenticar al usuario para que se puedan aplicar las directivas de Microsoft Entra, como el acceso condicional. Esto requerirá invalidar cualquier estado de sesión para los usuarios derivados de Windows Server AD, como informar a la aplicación de no permitir el estado de sesión generado durante un período de tiempo determinado. El modo en que se proporciona a la aplicación variará según las aplicaciones.

Configuración completa

Después de probar la configuración de inicio de sesión inicial, deberá asegurarse de que el STS de usuario de confianza permanece actualizado a medida que se agregan nuevos certificados a Microsoft Entra. Algunas partes confiables STS pueden tener un proceso integrado para supervisar los metadatos de federación del proveedor de identidad.

Para obtener más información sobre cómo configurar AD FS para alta disponibilidad, consulte cómo implementar una granja de servidores de federación.

Pasos siguientes

• ¿Qué es la administración de aplicaciones en microsoft Entra ID?
• Controlar el acceso a las aplicaciones de su entorno
• Habilitar el inicio de sesión único para una aplicación empresarial con un servicio de token de seguridad de la parte confiable