Solución de problemas de AD FS en Microsoft Entra ID y Office 365

2025-04-09

En este artículo se describe la solución de problemas de flujo de trabajo para problemas de autenticación para usuarios federados en el identificador de Microsoft Entra u Office 365.

Número de KB original: 3079872

Síntomas

Los usuarios federados no pueden iniciar sesión en Office 365 o Microsoft Azure aunque los usuarios administrados solo en la nube que tengan un sufijo upn de domainxx.onmicrosoft.com pueden iniciar sesión sin ningún problema.
El redireccionamiento a los Servicios de federación de Active Directory (AD FS) o STS no se produce para un usuario federado. O bien, se desencadena un error de "Página no se puede mostrar".
Recibirá una advertencia relacionada con el certificado en un explorador al intentar autenticarse con AD FS. Lo que indica que se produce un error en la validación del certificado o que el certificado no es de confianza.
Error o errores "Método de autenticación desconocido" que indican que AuthnContext no se admite. Además, los errores en el nivel de AD FS o STS cuando se le redirige desde Office 365.
AD FS produce un error "Acceso denegado".
AD FS produce un error que indica que hay un problema al acceder al sitio; que incluye un número de identificador de referencia.
Se solicita repetidamente al usuario las credenciales en el nivel de AD FS.
Los usuarios federados no se pueden autenticar desde una red externa o cuando usan una aplicación que toma la ruta de red externa (Outlook, por ejemplo).
Los usuarios federados no pueden iniciar sesión después de cambiar un certificado de firma de tokens en AD FS.
Se desencadena un error "Lo sentimos, pero tenemos problemas para iniciar sesión" cuando un usuario federado inicia sesión en Office 365 en Microsoft Azure. Este error incluye códigos de error como 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A o solicitud BAD.

Flujo de trabajo de solución de problemas

Acceda a Microsoft Office Home y escriba el nombre de inicio de sesión del usuario federado (someone@example.com). Al presionar Tab para quitar el foco de la casilla de inicio de sesión, verifique si el estado de la página cambia a Redireccionamiento y, a continuación, se le redirige al Servicio de federación de Active Directory (AD FS) para iniciar sesión.

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lee la actualización sobre obsolescencia. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulta las Preguntas más frecuentes sobre migración. Nota: versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.

Cuando se produce el redireccionamiento, verá la página siguiente:
1. Si no se produce ningún redireccionamiento y se le pide que escriba una contraseña en la misma página, lo que significa que Microsoft Entra ID u Office 365 no reconoce el usuario ni el dominio del usuario que se va a federar. Para comprobar si hay una confianza de federación entre microsoft Entra ID u Office 365 y el servidor de AD FS, ejecute el Get-MgDomain cmdlet y compruebe authenticationType.
2. Si se produce el redireccionamiento, pero no se le redirige al servidor de AD FS para el inicio de sesión, compruebe si el nombre del servicio de AD FS se resuelve en la dirección IP correcta y si puede conectarse a esa dirección IP en el puerto TCP 443.
  
  Si el dominio se muestra como Federado, obtenga información sobre la confianza de federación ejecutando los siguientes comandos:
```
Get-MgDomainFederationConfiguration -DomainId <domain_id>
```
  Nota:
  
  < > domain_id es un marcador de posición para el nombre del dominio. Por ejemplo, contoso.com.
  
  Compruebe el URI, la dirección URL y el certificado del asociado de federación configurado por Office 365 o el identificador de Entra de Microsoft.
Después de que se le redirija a AD FS, el explorador puede generar un error relacionado con la confianza del certificado y, para algunos clientes y dispositivos, puede que no le permita establecer una sesión SSL (Capa de sockets seguros) con AD FS. Para resolver el problema, siga estos pasos:
1. Asegúrese de que el certificado de comunicación del servicio de AD FS que se presenta al cliente es el mismo que está configurado en AD FS.
  
  Idealmente, el certificado de comunicación de servicio de AD FS debe ser el mismo que el certificado SSL que se presenta al cliente cuando intenta establecer un túnel SSL con el servicio AD FS.
  
  En AD FS 2.0:
  - Enlace el certificado al primer sitio predeterminado de IIS>.
  - Use el complemento de AD FS para agregar el mismo certificado que el certificado de comunicación de servicio.
  En AD FS 2012 R2:
  - Use el complemento de AD FS o el Add-adfscertificate comando para agregar un certificado de comunicación de servicio.
  - Use el Set-adfssslcertificate comando para establecer el mismo certificado para el enlace SSL.
2. Asegúrese de que el cliente confía en el certificado de comunicación del servicio de AD FS.
3. Si los clientes que no son compatibles con SNI intentan establecer una sesión SSL con AD FS o WAP 2-12 R2, puede producirse un error en el intento. En este caso, considere la posibilidad de agregar una entrada de reserva en los servidores AD FS o WAP para admitir clientes que no sean SNI. Para obtener más información, vea How to support non-SNI capable clients with Web Application Proxy and AD FS 2012 R2.How to support non-SNI capable clients with Web Application Proxy and AD FS 2012 R2.

Es posible que encuentre un error o errores de "Método de autenticación desconocido" que indique que AuthnContext no se admite en el nivel de AD FS o STS cuando se le redirige desde Office 365. Es más común cuando se redirige a AD FS o STS mediante un parámetro que aplica un método de autenticación. Para aplicar un método de autenticación, use uno de los métodos siguientes:

Para WS-Federation, use una cadena de consulta WAUTH para forzar un método de autenticación preferido.

Para SAML2.0, use lo siguiente:

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

Cuando el método de autenticación aplicado se envía con un valor incorrecto o si ese método de autenticación no se admite en AD FS o STS, recibirá un mensaje de error antes de autenticarse.

En la tabla siguiente se muestran los URI de tipo de autenticación reconocidos por AD FS para la autenticación pasiva de WS-Federation.

Método de autenticación deseado	URI de wauth
Autenticación de nombre de usuario y contraseña	urn:oasis:names:tc:SAML:1.0:am:password
Autenticación de cliente SSL	urn:ietf:rfc:2246
Autenticación integrada de Windows	urn:federation:authentication:windows

Clases de contexto de autenticación de SAML compatibles

Método de autenticación	URI de la clase de contexto de autenticación
Nombre de usuario y contraseña	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Transporte protegido por contraseña	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Cliente de Seguridad de la capa de transporte (TLS)	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Certificado X.509	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Autenticación integrada de Windows	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

Para asegurarse de que el método de autenticación se admite en el nivel de AD FS, compruebe lo siguiente.

AD FS 2.0

En /adfs/ls/web.config, asegúrese de que la entrada del tipo de autenticación está presente.

<microsoft.identityServer.web>
<localAuthenticationTypes>
 < add name="Forms" page="FormsSignIn.aspx" />  
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0: Cómo cambiar el tipo de autenticación local

AD FS 2012 R2

En Administración de AD FS, seleccione Directivas de autenticación en el complemento de AD FS.
En la sección Autenticación principal, seleccione Editar junto a Configuración global. También puede hacer clic con el botón derecho en Directivas de autenticación y, a continuación, seleccionar Editar autenticación principal global. O bien, en el panel Acciones , seleccione Editar autenticación principal global.
En la ventana Editar directiva de autenticación global, en la pestaña Principal , puede configurar las opciones como parte de la directiva de autenticación global. Por ejemplo, para la autenticación principal, puede seleccionar los métodos de autenticación disponibles en Extranet e Intranet.

Asegúrese de que la casilla del método de autenticación necesario esté activada.

Si llega a AD FS y entra sus credenciales pero no se puede autenticar, compruebe los posibles problemas siguientes.
1. Problema de replicación de Active Directory
  
  Si se interrumpe la replicación de AD, es posible que los cambios realizados en el usuario o grupo no se sincronicen entre controladores de dominio. Entre los controladores de dominio, puede haber un desajuste en la contraseña, el UPN, la membresía de grupo o la dirección de proxy que afecte la respuesta de AD FS (autenticación y afirmaciones). Deberías empezar a examinar los controladores de dominio en el mismo sitio que AD FS. La ejecución de un repadmin /showreps comando o DCdiag /v debe revelar si hay un problema en los controladores de dominio con los que es más probable que se comunique AD FS.
  
  También puede recopilar un resumen de replicación de AD para asegurarse de que los cambios de AD se replican correctamente en todos los controladores de dominio. La repadmin /showrepl * /csv > showrepl.csv salida es útil para comprobar el estado de replicación. Para más información, consulte Solución de problemas de replicación de Active Directory.
2. Cuenta bloqueada o deshabilitada en Active Directory
  
  Cuando un usuario final se autentica a través de AD FS, no recibirá un mensaje de error que indica que la cuenta está bloqueada o deshabilitada. Desde la auditoría de inicio de sesión y AD FS, debería poder determinar si se produjo un error de autenticación debido a una contraseña incorrecta, si la cuenta está deshabilitada o bloqueada, etc.
  
  Para habilitar la auditoría de inicio de sesión y AD FS en los servidores de AD FS, siga estos pasos:
  1. Use la directiva local o de dominio para habilitar el éxito y el error de las siguientes directivas:
    - Auditar evento de inicio de sesión, ubicado en Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
    - Auditar el acceso a objetos, ubicado en Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
      
      $Use la política local o de dominio para habilitar los éxitos y fracasos.$
  2. Deshabilite la siguiente directiva:
    
    Auditoría: forzar que la configuración de subcategorías de la política de auditoría (Windows Vista o posterior) sobrescriba la configuración de la categoría de política de auditoría
    
    Esta directiva se encuentra en Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.
    
    Si quiere configurarlo mediante la auditoría avanzada, consulte Configuración de equipos para solucionar problemas de AD FS 2.0.
  3. Configuración de AD FS para la auditoría:
    1. Abra el complemento de administración de AD FS 2.0.
    2. En el panel Acciones, seleccione Modificar las propiedades del Servicio de federación.
    3. En el cuadro de diálogo Propiedades del servicio de federación, seleccione la pestaña Eventos.
    4. Active las casillas Auditorías de aciertos y Auditorías de errores.
    5. Ejecute GPupdate /force en el servidor.
3. El Service Principal Name (SPN) está registrado incorrectamente
  
  Puede haber SPN duplicados o un SPN registrado en una cuenta distinta de la cuenta de servicio de AD FS. Para una configuración de la granja de AD FS, asegúrese de que el SPN HOST/AD FSservicename esté agregado en la cuenta de servicio que ejecuta el servicio AD FS. Para una configuración independiente de AD FS, donde el servicio se ejecuta en Servicio de red, el SPN debe estar en la cuenta de equipo del servidor que hospeda AD FS.
  
  Asegúrese de que no haya SPN duplicados para el servicio AD FS, ya que puede provocar errores de autenticación intermitentes con AD FS. Para enumerar los SPN, ejecute SETSPN -L <ServiceAccount>.
  
  Ejecute SETSPN -A HOST/AD FSservicename ServiceAccount para agregar el SPN.
  
  Ejecute SETSPN -X -F para comprobar si hay SPN duplicados.
4. UPN duplicados en Active Directory
  
  Es posible que un usuario pueda autenticarse a través de AD FS cuando usa SAMAccountName, pero no se puede autenticar al usar UPN. En este escenario, Active Directory puede contener dos usuarios que tengan el mismo UPN. Es posible terminar con dos usuarios que tengan el mismo UPN cuando los usuarios se agregan y modifican a través del scripting (ADSIedit, por ejemplo).
  
  Cuando se usa UPN para la autenticación en este escenario, el usuario se autentica contra el usuario duplicado. Por lo tanto, las credenciales proporcionadas no se validan.
  
  Puede usar consultas como las siguientes para comprobar si hay varios objetos en AD que tienen los mismos valores para un atributo:
```
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
```
  Asegúrese de que se renombre el UPN del usuario duplicado, de modo que la solicitud de autenticación con el UPN se valide contra los objetos correctos.
5. En un escenario en el que usa la dirección de correo electrónico como identificador de inicio de sesión en Office 365 y escribe la misma dirección de correo electrónico cuando se le redirige a AD FS para la autenticación, la autenticación puede producir un error de "NO_SUCH_USER" en los registros de auditoría. Para permitir que AD FS busque un usuario para la autenticación mediante un atributo distinto de UPN o SAMaccountname, debe configurar AD FS para admitir un identificador de inicio de sesión alternativo. Para obtener más información, consulte Configuración del identificador de inicio de sesión alternativo.
  
  En AD FS 2012 R2
  1. Instale update 2919355.
  2. Actualice la configuración de AD FS ejecutando el siguiente cmdlet de PowerShell en cualquiera de los servidores de federación de la granja de servidores (si tiene una granja WID, debe ejecutar este comando en el servidor de AD FS principal de la granja):
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
    Nota:
    
    AlternateLoginID es el nombre LDAP del atributo que quiere usar para el inicio de sesión. LookupForests es la lista de entradas DNS de bosques a la que pertenecen tus usuarios.
    
    Para habilitar la característica de identificador de inicio de sesión alternativo, debe configurar los parámetros AlternateLoginID y LookupForests con un valor válido que no sea NULL.
6. La cuenta de servicio de AD FS no tiene acceso de lectura al token de AD FS asociado a la firma con la clave privada del certificado. Para agregar este permiso, siga estos pasos:
  1. Al agregar un nuevo certificado de firma de tokens, recibirá la siguiente advertencia:
    
    Asegúrese de que la clave privada del certificado elegido sea accesible para la cuenta de servicio de este servicio de federación en cada servidor de la granja de servidores.
  2. Seleccione Iniciar, seleccione Ejecutar, escriba mmc.exe y presione Entrar.
  3. Seleccione Archivo y, a continuación, seleccione Agregar o quitar complemento.
  4. Haga doble clic en Certificados.
  5. Seleccione la cuenta de equipo en cuestión y, a continuación, seleccione Siguiente.
  6. Seleccione Equipo local y Finalizar.
  7. Expanda Certificados (equipo local), expanda Personal, y a continuación, seleccione Certificados.
  8. Haga clic con el botón derecho en el nuevo certificado de firma de tokens, seleccione Todas las tareas y, a continuación, seleccione Administrar claves privadas.
  9. Agregue Acceso de lectura para la cuenta de servicio de AD FS 2.0 y, a continuación, seleccione Aceptar.
  10. Cierre el MMC de certificados.
7. La opción Protección ampliada para la autenticación de Windows está habilitada para el directorio virtual de AD FS o LS. Puede causar problemas con exploradores específicos. A veces, puede ver que AD FS solicita repetidamente credenciales y puede estar relacionado con la configuración de protección ampliada habilitada para la autenticación de Windows para la aplicación AD FS o LS en IIS.
  
  Cuando la protección ampliada para la autenticación está habilitada, las solicitudes de autenticación se enlazan a los nombres de entidad de seguridad de servicio (SPN) del servidor al que el cliente intenta conectarse y al canal externo de seguridad de la capa de transporte (TLS) a través del cual se produce la autenticación integrada de Windows. La protección ampliada mejora la funcionalidad de autenticación de Windows existente para mitigar los ataques de retransmisión o los ataques de tipo "hombre en el medio". Sin embargo, algunos exploradores no funcionan con la configuración protección ampliada; en su lugar, solicitan repetidamente las credenciales y, a continuación, deniegan el acceso. Deshabilitar la protección ampliada ayuda en este escenario.
  
  Para obtener más información, vea AD FS 2.0: Solicitud continua de credenciales al usar Fiddler Web Debugger.
  
  Para AD FS 2012 R2
  
  Ejecute el siguiente cmdlet para deshabilitar la protección ampliada:
```
Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
8. Las reglas de autorización de emisión en la Parte Confiante (RP) pueden denegar el acceso a los usuarios. En la confianza de terceros de AD FS, puede configurar las reglas de autorización de emisión que controlan si un usuario autenticado debe recibir un token para un tercero confiable. Los administradores pueden usar las declaraciones que se emiten para decidir si denegar el acceso a un usuario que sea miembro de un grupo que se extrae como una declaración.
  
  Si determinados usuarios federados no se pueden autenticar a través de AD FS, es posible que desee comprobar las reglas de autorización de emisión para el RP de Office 365 y ver si está configurada la regla Permitir acceso a todos los usuarios.
  
  Si esta regla no está configurada, examine las reglas de autorización personalizadas para comprobar si la condición de esa regla evalúa "true" para el usuario afectado. Para obtener más información, consulte los recursos siguientes:
  Si puede autenticarse desde una intranet al acceder directamente al servidor de AD FS, pero no se puede autenticar al acceder a AD FS a través de un proxy de AD FS, compruebe los siguientes problemas:
  - Problema de sincronización de hora en el servidor de AD FS y el proxy de AD FS
    
    Asegúrese de que la hora en el servidor de AD FS y la hora del proxy están sincronizadas. Cuando la hora en el servidor de AD FS está desactivada durante más de cinco minutos desde el momento en los controladores de dominio, se producen errores de autenticación. Cuando la hora en el proxy de AD FS no está sincronizada con AD FS, la confianza del proxy se ve afectada y rompida. Por lo tanto, se produce un error en una solicitud que llega a través del proxy de AD FS.
  - Compruebe si el proxy de confianza de AD FS con el servicio de AD FS funciona correctamente. Vuelva a ejecutar la configuración del proxy si sospecha que se ha interrumpido la confianza del proxy.
Cuando AD FS emite un token, Microsoft Entra ID u Office 365 generan un error. En esta situación, compruebe los problemas siguientes:
- Las notificaciones emitidas por AD FS en el token deben coincidir con los atributos respectivos del usuario en Microsoft Entra ID. En el token de Microsoft Entra ID u Office 365, se requieren las siguientes reclamaciones.
  
  WSFED:
  UPN: El valor de esta reclamación debe coincidir con el UPN de los usuarios de Microsoft Entra ID.
  ImmutableID: el valor de esta afirmación debe coincidir con el sourceAnchor o el ImmutableID del usuario en Microsoft Entra ID.
  
  Para obtener el valor de atributo User en Microsoft Entra ID, ejecute la siguiente línea de comandos:
```
Get-MgUser -UserId <user_id_string>
```
  SAML 2.0:
  IDPEmail: el valor de esta reclamación debe coincidir con el nombre principal de usuario de los usuarios en Microsoft Entra ID.
  NAMEID: el valor de esta declaración debe coincidir con el SourceAnchor o ImmutableID del usuario en Microsoft Entra ID.
  
  Para obtener más información, consulte Uso de un proveedor de identidades (IdP) de SAML 2.0 para el inicio de sesión único.
  
  Ejemplos:
  Este problema puede producirse cuando se cambia el UPN de un usuario sincronizado en AD, pero sin actualizar el directorio en línea. En este escenario, puede corregir el UPN del usuario en AD (para que coincida con el nombre de inicio de sesión del usuario relacionado) o ejecutar el siguiente cmdlet para cambiar el nombre de inicio de sesión del usuario relacionado en el directorio En línea:
```
Update-MgUser -UserId <user_id_string> -UserPrincipalName <DomainUPN-AD>
```
  También puede ser que esté usando AADsync para sincronizar MAIL como UPN y EMPID como SourceAnchor, pero las reglas de notificaciones de parte confiable en el nivel de AD FS no se han actualizado para enviar MAIL como UPN y EMPID como ImmutableID.
- Hay una incompatibilidad del certificado para la firma de tokens entre AD FS y Office 365.
  
  Es uno de los problemas más comunes. AD FS usa el certificado de firma de tokens para firmar el token que se envía al usuario o la aplicación. La confianza entre AD FS y Office 365 es una confianza federada basada en este certificado de firma de tokens (por ejemplo, Office 365 comprueba que el token recibido está firmado mediante un certificado de firma de tokens del proveedor de notificaciones [el servicio AD FS] en el que confía).
  
  Sin embargo, si se cambia el certificado de firma de tokens en AD FS debido a la sustitución automática de certificados o a la intervención de un administrador (después o antes de que expire el certificado), los detalles del nuevo certificado deben actualizarse en el inquilino de Office 365 para el dominio federado. Es posible que no suceda automáticamente; puede requerir la intervención de un administrador. Cuando el certificado de firma de tokens principal en AD FS es diferente de lo que Office 365 conoce, el token emitido por AD FS no es de confianza para Office 365. Por lo tanto, el usuario federado no puede iniciar sesión.
  
  Office 365 o Microsoft Entra ID intentará ponerse en contacto con el servicio de AD FS, suponiendo que el servicio sea accesible a través de la red pública. Intentamos sondear los metadatos de federación de AD FS a intervalos regulares, para extraer los cambios de configuración en AD FS, principalmente la información del certificado de firma de tokens. Si este proceso no funciona, el administrador global debe recibir una advertencia en el portal de Office 365 sobre la expiración del certificado de firma de tokens y sobre las acciones necesarias para actualizarlo.
  
  Puede usar Get-MgDomainFederationConfiguration -DomainId <domain_id> para exportar la propiedad de federación en AD FS y Office 365. Aquí puede comparar la huella digital de TokenSigningCertificate para comprobar si la configuración del inquilino de Office 365 para el dominio federado está sincronizada con AD FS. Si encuentra un error de coincidencia en la configuración del certificado de firma de tokens, ejecute el siguiente comando para actualizarlo:
```
Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All
$tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id>
Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -SigningCertificate <certificate_token>
Disconnect-MgGraph
```
  Nota:
  
  < > domain_id es un marcador de posición para el nombre del dominio. Por ejemplo, contoso.com.
  
  Para obtener más información, vea Renovar certificados de federación para Microsoft 365 e Id. de Microsoft Entra.
- Las reglas de reclamaciones de transformación de emisión para el RP de Office 365 no están configuradas correctamente.
  
  En un escenario en el que tiene varios TLD (dominios de nivel superior), es posible que tenga problemas de inicio de sesión si el conmutador Supportmultipledomain no se usó cuando se creó y actualizó la relación de confianza de RP.
  
  Se recomienda usar Entra Connect para administrar las federaciones y las reglas de reclamación. Normalmente, esto configura ADFS y Entra de forma adecuada. Para obtener más información, consulte Compatibilidad con varios dominios para federar con microsoft Entra ID.
- Asegúrese de que AD FS o STS no usen el cifrado de tokens cuando se emite un token a Microsoft Entra ID o a Office 365.
Hay credenciales almacenadas en caché obsoletas en el Administrador de credenciales de Windows.

A veces, durante el inicio de sesión desde una estación de trabajo al portal (o cuando se usa Outlook), cuando se solicita al usuario las credenciales, las credenciales se pueden guardar para el destino (servicio Office 365 o AD FS) en el Administrador de credenciales de Windows (Control Panel\User Accounts\Credential Manager). Esto ayuda a evitar una solicitud de credenciales durante algún tiempo, pero puede provocar un problema después de que la contraseña de usuario haya cambiado y el administrador de credenciales no se actualice. En ese escenario, las credenciales obsoletas se envían al servicio AD FS y por eso se produce un error en la autenticación. Quitar o actualizar las credenciales almacenadas en caché, en el Administrador de credenciales de Windows puede ayudar.
Asegúrese de que el Algoritmo de Hash Seguro configurado en la confianza del tercero confiable para Office 365 esté establecido en SHA1.

Cuando la confianza entre el STS / AD FS y Microsoft Entra ID / Office 365 usa el protocolo SAML 2.0, el algoritmo hash seguro configurado para la firma digital debería ser SHA1.
Si ninguna de las causas anteriores se aplica a su situación, cree un caso de soporte técnico con Microsoft y pídales que comprueben si la cuenta de usuario aparece de forma coherente en el inquilino de Office 365. Para obtener más información, consulte Se solicita repetidamente a un usuario federado credenciales durante el inicio de sesión en Office 365, Azure o Intune.

En función del servicio en la nube (integrado con microsoft Entra ID), la solicitud de autenticación que se envía a AD FS puede variar. Por ejemplo: algunas solicitudes pueden incluir parámetros adicionales, como Wauth o Wfresh, y estos parámetros pueden provocar un comportamiento diferente en el nivel de AD FS.

Se recomienda mantener actualizados los archivos binarios de AD FS para incluir las correcciones de problemas conocidos. Para obtener más información sobre las actualizaciones más recientes, consulte la tabla siguiente.

AD FS 2.0	AD FS 2012 R2
Descripción del paquete acumulativo de actualizaciones 3 para Servicios de federación de Active Directory (AD FS) 2.0 La actualización está disponible para corregir varios problemas después de instalar la actualización de seguridad 2843638 en un servidor de AD FS	Paquete acumulativo de actualizaciones de diciembre de 2014 para Windows RT 8.1, Windows 8.1 y Windows Server 2012 R2

Referencia

Para obtener más información sobre los cmdlets de Microsoft Graph, consulte los siguientes artículos:

Compartir a través de

Solución de problemas de AD FS en Microsoft Entra ID y Office 365

Síntomas

Flujo de trabajo de solución de problemas

Referencia

Comentarios

Recursos adicionales