Solución de problemas de SSO con Servicios de federación de Active Directory (AD FS) (AD FS)
Artículo
Este artículo le ayuda a resolver problemas de inicio de sesión único (SSO) con Servicios de federación de Active Directory (AD FS) (AD FS).
Seleccione una de las secciones siguientes según el tipo de problema que encuentre.
Se aplica a: Servicios de federación de Active Directory (AD FS) Número de KB original: 4034932
Solicitud de autenticación basada en formularios o NTLM
Durante la solución de problemas de inicio de sesión único (SSO) con Servicios de federación de Active Directory (AD FS) (AD FS), si los usuarios recibieron mensajes de autenticación inesperados basados en NTLM o formularios, siga los pasos de este artículo para solucionar este problema.
Comprobar la configuración de autenticación integrada de Windows
Para solucionar este problema, compruebe la configuración de autenticación integrada de Windows en el explorador cliente, la configuración de AD FS y los parámetros de solicitud de autenticación.
Comprobación del explorador cliente del usuario
Compruebe la siguiente configuración en Opciones de Internet:
En la pestaña Opciones avanzadas , asegúrese de que la opción Habilitar autenticación integrada de Windows está habilitada.
Después de Seguridad>sitios de intranet>>locales avanzados, asegúrese de que la dirección URL de AD FS está en la lista de sitios web.
Después del nivel personalizado de intranet > local de seguridad>, asegúrese de que la opción Inicio de sesión automático solo está seleccionada en zona de intranet.
Si usa Firefox, Chrome o Safari, asegúrese de que la configuración equivalente en estos exploradores está habilitada.
Comprobación de la configuración de AD FS
Comprobar la configuración windowsIntegratedFallback
Abra Windows PowerShell con la opción Ejecutar como administrador.
Para obtener la directiva de autenticación global, ejecute el comando siguiente:
Examine el valor del atributo WindowsIntegratedFallbackEnabled .
Si el valor es True, se espera la autenticación basada en formularios. Esto significa que la solicitud de autenticación procede de un explorador que no admite la autenticación integrada de Windows. Consulte la sección siguiente sobre cómo admitir el explorador.
Si el valor es False, se debe esperar la autenticación integrada de Windows.
Compruebe la configuración WIASupportedUsersAgents
Para obtener la lista de agentes de usuario admitidos, ejecute el siguiente comando:
Examine la lista de cadenas del agente de usuario que devuelve el comando.
Compruebe si la cadena del agente de usuario del explorador está en la lista. Si no es así, agregue la cadena del agente de usuario siguiendo los pasos siguientes:
Comprobación de los parámetros de solicitud de autenticación
Compruebe si la solicitud de autenticación especifica la autenticación basada en formularios como método de autenticación.
Si la solicitud de autenticación es una solicitud WS-Federation, compruebe si la solicitud incluye wauth= urn:oasis:names:tc:SAML:1.0:am:password.
Si la solicitud de autenticación es una solicitud SAML, compruebe si la solicitud incluye un elemento samlp:AuthnContextClassRef con el valor urn:oasis:names:tc:SAML:2.0:ac:classes:Password.
Compruebe si la aplicación es Microsoft Online Services para Office 365
Si la aplicación a la que desea acceder no es Microsoft Online Services, lo que experimenta se espera y controla mediante la solicitud de autenticación entrante. Trabaje con el propietario de la aplicación para cambiar el comportamiento.
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 de desuso. 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.
Si la aplicación es Microsoft Online Services, el valor PromptLoginBehavior puede controlarlo desde el objeto realm de confianza. Esta configuración controla si los inquilinos de Microsoft Entra envían prompt=login a AD FS. Para establecer la configuración PromptLoginBehavior , siga estos pasos:
Abra Windows PowerShell con la opción "Ejecutar como administrador".
Ejecute el comando siguiente para obtener la configuración de federación de dominio existente:
Los valores del parámetro PromptLoginBehavior son:
TranslateToFreshPasswordAuth: Microsoft Entra ID envía wauth y wfresh a AD FS en lugar de prompt=login. Esto conduce a una solicitud de autenticación para usar la autenticación basada en formularios.
NativeSupport: el parámetro prompt=login se envía tal como está a AD FS.
Si la solicitud de autenticación enviada al identificador de Microsoft Entra incluye el parámetro prompt=login, deshabilite la funcionalidad prompt=login ejecutando el siguiente comando:
Después de ejecutar este comando, las aplicaciones de Office 365 no incluirán el parámetro prompt=login en cada solicitud de autenticación.
Escenario que no es de Microsoft Entra
Los parámetros de solicitud como WAUTH y RequestedAuthNContext en las solicitudes de autenticación pueden tener métodos de autenticación especificados. Compruebe si otros parámetros de solicitud aplican el mensaje de autenticación inesperado. Si es así, modifique el parámetro de solicitud para usar el método de autenticación esperado.
Comprobación de si el inicio de sesión único está deshabilitado
Si el inicio de sesión único está deshabilitado, habilite y pruebe si se resuelve el problema.
Solicitud de autenticación multifactor
Para solucionar este problema, compruebe si las reglas de notificación del usuario de confianza están configuradas correctamente para la autenticación multifactor.
La autenticación multifactor se puede habilitar en un servidor de AD FS, en un usuario de confianza o en un parámetro de solicitud de autenticación. Compruebe las configuraciones para ver si están configuradas correctamente. Si se espera la autenticación multifactor, pero se le solicita repetidamente, compruebe las reglas de emisión de usuario autenticado para ver si las notificaciones de autenticación multifactor se pasan a la aplicación.
Para obtener más información sobre la autenticación multifactor en AD FS, consulte los artículos siguientes:
Comprobación de la configuración en el servidor de AD FS y el usuario de confianza
Para comprobar la configuración en el servidor de AD FS, valide las reglas de autenticación adicionales globales. Para comprobar la configuración en el usuario de confianza, valide las reglas de autenticación adicionales para la confianza del usuario de confianza de usuario autenticado.
Para comprobar la configuración en el servidor de AD FS, ejecute el siguiente comando en una ventana de Windows PowerShell.
PowerShell
Get-ADFSAdditionalAuthenticationRule
Para comprobar la configuración en el usuario de confianza, ejecute el siguiente comando:
Si los comandos no devuelven nada, no se configuran las reglas de autenticación adicionales. Omita esta sección.
Observe el conjunto de reglas de notificación configurado.
Comprobación de si la autenticación multifactor está habilitada en el conjunto de reglas de notificación
Un conjunto de reglas de notificación se compone de las secciones siguientes:
La instrucción condition: C:[Type=``…,Value=…]
La instrucción issue: => issue (Type=``…,Value=…)
Si la instrucción issue contiene la notificación siguiente, se especifica la autenticación multifactor. Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"
Estos son ejemplos que requieren la autenticación multifactor para usarse para dispositivos no unidos al área de trabajo y para el acceso a extranet respectivamente:
c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
Comprobación de las reglas de emisión de usuario de confianza
Si el usuario recibe repetidamente mensajes de autenticación multifactor después de realizar la primera autenticación, es posible que el usuario de respuesta no pase las notificaciones de autenticación multifactor a la aplicación. Para comprobar si se pasan las notificaciones de autenticación, siga estos pasos:
Ejecute el siguiente comando en Windows PowerShell:
PowerShell
Get-ADFSRelyingPartyTrust -TargetName ClaimApp
Observe el conjunto de reglas definido en los atributos IssuanceAuthorizationRules o IssuanceAuthorizationRulesFile.
El conjunto de reglas debe incluir la siguiente regla de emisión para pasar a través de las notificaciones de autenticación multifactor: C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)
Comprobación del parámetro de solicitud de autenticación
Compruebe si la solicitud de autenticación especifica la autenticación multifactor como método de autenticación.
Si la solicitud de autenticación es una solicitud WS-Federation, compruebe si la solicitud incluye wauth= http://schemas.microsoft.com/claims/multipleauthn.
Si la solicitud de autenticación es una solicitud SAML, compruebe si la solicitud incluye un elemento samlp:AuthnContextClassRef con el valor http://schemas.microsoft.com/claims/multipleauthn.
Comprobación de si el inicio de sesión único está deshabilitado
Si el inicio de sesión único está deshabilitado, habilite y pruebe si se resuelve el problema.
Los usuarios no pueden iniciar sesión en el sitio o servicio de destino
Este problema puede producirse en la página de inicio de sesión de AD FS o en el lado de la aplicación.
Si el problema se produce en la página de inicio de sesión de AD FS, recibirá un mensaje de error "Error", "El servicio HTTP 503 no está disponible" o algún otro mensaje de error. La dirección URL de la página de error muestra el nombre del servicio de AD FS, como fs.contoso.com.
Si el problema se produce en el lado de la aplicación, la dirección URL de la página de error muestra la dirección IP o el nombre del sitio del servicio de destino.
Siga los pasos descritos en la sección siguiente en función de dónde encuentre este problema.
Este problema se produce en la página de inicio de sesión de AD FS.
Para solucionar este problema, compruebe si todos los usuarios se ven afectados por el problema y si los usuarios pueden acceder a todos los usuarios de confianza.
Todos los usuarios se ven afectados por el problema y el usuario no puede acceder a ninguno de los usuarios de confianza.
Vamos a comprobar la funcionalidad de inicio de sesión interno mediante IdpInitiatedSignOn. Para ello, use la página IdpInititatedSignOn para comprobar si el servicio de AD FS está en funcionamiento y la funcionalidad de autenticación funciona correctamente. Para abrir la página IdpInitiatedSignOn, siga estos pasos:
Habilite la página IdpInitiatedSignOn ejecutando el siguiente comando en el servidor de AD FS:
Desde un equipo que está dentro de la red, visite la página siguiente: https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
Escriba las credenciales correctas de un usuario válido en la página de inicio de sesión.
El inicio de sesión se realiza correctamente
Si el inicio de sesión se realiza correctamente, compruebe si el estado del servicio de AD FS se está ejecutando.
En el servidor de AD FS, abra Administrador del servidor.
En el Administrador del servidor, haga clic en Servicios de herramientas>.
Compruebe si el estado de Servicios de federación de Active Directory (AD FS) está en ejecución.
A continuación, compruebe la funcionalidad de inicio de sesión externo mediante IdpInitiatedSignOn. Use la página IdpInititatedSignOn para comprobar rápidamente si el servicio de AD FS está en funcionamiento y la funcionalidad de autenticación funciona correctamente. Para abrir la página IdpInitiatedSignOn, siga estos pasos:
Habilite la página IdpInitiatedSignOn ejecutando el siguiente comando en el servidor de AD FS:
Si el inicio de sesión no se realiza correctamente, compruebe los servicios y componentes relacionados con AD FS.
Compruebe si el estado del servicio de AD FS se está ejecutando.
En el servidor de AD FS, abra Administrador del servidor.
En el Administrador del servidor, haga clic en Servicios de herramientas>.
Compruebe si el estado de Servicios de federación de Active Directory (AD FS) está en ejecución.
Compruebe si los puntos de conexión están habilitados. AD FS proporciona varios puntos de conexión para diferentes funcionalidades y escenarios. No todos los puntos de conexión están habilitados de forma predeterminada. Para comprobar el estado de los puntos de conexión, siga estos pasos:
En el servidor de AD FS, abra la Consola de administración de AD FS.
Expanda Puntos de conexión de servicio>.
Busque los puntos de conexión y compruebe si los estados están habilitados en la columna Habilitado .
A continuación, compruebe si Microsoft Entra Connect está instalado. Se recomienda usar Microsoft Entra Connect, lo que facilita la administración de certificados SSL.
Si Microsoft Entra Connect no está instalado, compruebe si el certificado SSL cumple los siguientes requisitos de AD FS:
El certificado procede de una entidad de certificación raíz de confianza.
AD FS requiere que los certificados SSL sean de una entidad de certificación raíz de confianza. Si se accede a AD FS desde equipos no unidos a un dominio, se recomienda usar un certificado SSL de una entidad de certificación raíz de terceros de confianza como DigiCert, VeriSign, etc. Si el certificado SSL no procede de una entidad de certificación raíz de confianza, la comunicación SSL puede interrumpirse.
El nombre del firmante del certificado es válido.
El nombre del firmante debe coincidir con el nombre del servicio de federación, no el nombre del servidor de AD FS o algún otro nombre. Para obtener el nombre del servicio de federación, ejecute el siguiente comando en el servidor de AD FS principal: Get-AdfsProperties | select hostname
El certificado no se revoca.
Comprobar la revocación de certificados. Si se revoca el certificado, los clientes no pueden confiar en la conexión SSL y los bloquearán.
Si el certificado SSL no cumple estos requisitos, intente obtener un certificado completo para la comunicación SSL. Se recomienda usar Microsoft Entra Connect, lo que facilita la administración de certificados SSL. Consulte Actualización del certificado TLS/SSL para una granja de Servicios de federación de Active Directory (AD FS) (AD FS).
Si el certificado SSL cumple estos requisitos, compruebe las siguientes configuraciones del certificado SSL.
Compruebe si el certificado SSL está instalado correctamente
El certificado SSL debe instalarse en el almacén personal del equipo local en cada servidor de federación de la granja de servidores. Para instalar el certificado, haga doble clic en . Archivo PFX del certificado y siga el asistente.
Para comprobar si el certificado está instalado en el lugar correcto, siga estos pasos:
Para enumerar los certificados que se encuentran en el almacén personal del equipo local, ejecute el siguiente comando: dir Cert:\LocalMachine\My
Compruebe si el certificado está en la lista.
Compruebe si el certificado SSL correcto está en uso
Obtenga la huella digital del certificado que está en uso para la comunicación SSL y compruebe si la huella digital coincide con la huella digital del certificado esperada.
Para obtener la huella digital del certificado que está en uso, ejecute el siguiente comando en Windows PowerShell:
PowerShell
Get-AdfsSslCertificate
Si se usa el certificado incorrecto, establezca el certificado correcto ejecutando el siguiente comando:
Compruebe si el certificado SSL está establecido como certificado de comunicación de servicio.
El certificado SSL debe establecerse como certificado de comunicación de servicio en la granja de AD FS. Esto no ocurre automáticamente. Para comprobar si se establece el certificado correcto, siga estos pasos:
En la Consola de administración de AD FS, expanda Certificados de servicio>.
Compruebe si el certificado que aparece en Comunicaciones de servicio es el certificado esperado.
Si aparece el certificado incorrecto, establezca el certificado correcto y, a continuación, conceda al servicio de AD FS el permiso De lectura al certificado. Para ello, siga estos pasos:
Establezca el certificado correcto:
Haga clic con el botón derecho en Certificados y, a continuación, haga clic en Establecer certificado de comunicación de servicio.
Seleccione el certificado correcto.
Compruebe si el servicio AD FS tiene el permiso De lectura para el certificado:
Agregue el complemento Certificados para la cuenta de equipo local a Microsoft Management Console (MMC).
Haga clic con el botón derecho en el certificado SSL y haga clic en Todas las tareas>Administrar claves privadas.
Compruebe si adfssrv aparece en Grupos y nombres de usuario con el permiso De lectura .
Si adfssrv no aparece en la lista, conceda al servicio de AD FS el permiso De lectura al certificado:
Haga clic en Agregar, en Ubicaciones, en el servidor y, a continuación, en Aceptar.
En Escriba los nombres de objeto que desea seleccionar, escriba nt service\adfssrv, haga clic en Comprobar nombres y, a continuación, haga clic en Aceptar.
Si usa AD FS con el servicio de registro de dispositivos (DRS), escriba nt service\drs en su lugar.
Conceda el permiso De lectura y, a continuación, haga clic en Aceptar.
Compruebe si el servicio de registro de dispositivos (DRS) está configurado en AD FS.
Si ha configurado AD FS con DRS, asegúrese de que el certificado SSL también está configurado correctamente para RDS. Por ejemplo, si hay dos sufijos contoso.com UPN y fabrikam.com, el certificado debe tener enterpriseregistration.contoso.com y enterpriseregistration.fabrikma.com como nombres alternativos del firmante (SAN).
Para comprobar si el certificado SSL tiene los SAN correctos, siga estos pasos:
Para enumerar todos los sufijos UPN que se usan en la organización, ejecute el siguiente comando:
PowerShell
Get-AdfsDeviceRegistratrionUpnSuffix
Compruebe si el certificado SSL tiene configurados los SAN necesarios.
Si el certificado SSL no tiene los nombres de DRS correctos como SAN, obtenga un nuevo certificado SSL que tenga los SAN correctos para DRS y después úselo como certificado SSL para AD FS.
A continuación, compruebe la configuración del certificado en los servidores WAP y los enlaces de reserva:
Compruebe si el certificado SSL correcto está establecido en todos los servidores WAP.
Asegúrese de que el certificado SSL está instalado en el almacén personal del equipo local en cada servidor WAP.
Para obtener el certificado SSL usado por WAP, ejecute el siguiente comando:
PowerShell
Get-WebApplicationProxySslCertificate
Si el certificado SSL es incorrecto, ejecute el siguiente comando para establecer el certificado SSL correcto:
Compruebe los enlaces de certificado y actualícelos si es necesario.
Para admitir casos que no son SNI, los administradores pueden especificar enlaces de reserva. Aparte del enlace federationservicename:443 estándar, busque enlaces de reserva en los siguientes identificadores de aplicación:
{5d89a20c-beab-4389-9447-324788eb944a}: este es el identificador de aplicación para AD FS.
{f955c070-e044-456c-ac00-e9e4275b3f04}: este es el identificador de aplicación para el proxy de aplicación web.
Por ejemplo, si se especifica el certificado SSL para un enlace de reserva como 0.0.0.0.0:443, asegúrese de que el enlace se actualiza según corresponda cuando se actualice el certificado SSL.
Todos los usuarios se ven afectados por el problema y el usuario puede acceder a algunos de los usuarios de confianza.
En primer lugar, vamos a obtener la información del cliente de OAuth y del usuario de confianza. Si usa un usuario de confianza convencional, siga estos pasos:
En el servidor de AD FS principal, abra Windows PowerShell con la opción Ejecutar como administrador .
Para agregar el componente AD FS 2.0 a Windows PowerShell, ejecute el siguiente comando:
PowerShell
Add-PSSnapin Microsoft.Adfs.PowerShell
Para obtener la información del usuario de confianza, ejecute el siguiente comando:
PowerShell
$rp = Get-AdfsRelyingPartyTrust RPName
Para obtener la información del cliente de OAuth, ejecute el siguiente comando:
PowerShell
$client = Get-AdfsClient ClientName
Si usa la característica Grupo de aplicaciones en Windows Server 2016, siga estos pasos:
En el servidor de AD FS principal, abra Windows PowerShell con la opción Ejecutar como administrador .
Para obtener la información del usuario de confianza, ejecute el siguiente comando: $rp = Get-AdfsWebApiApplication ResourceID
Si el cliente de OAuth es público, ejecute el comando siguiente para obtener la información del cliente:
Si el cliente es confidencial, ejecute el comando siguiente para obtener la información del cliente:
PowerShell
$client = Get-AdfsServerApplication ClientName
Ahora continúe con los siguientes métodos de solución de problemas.
Comprobación de la configuración del usuario de confianza y el cliente
El propietario de la aplicación y el cliente deben proporcionar el identificador de cliente, el identificador de cliente y el URI de redirección. Sin embargo, podría haber una discrepancia entre lo que proporciona el propietario y lo que se configura en AD FS. Por ejemplo, un error de coincidencia podría deberse a un error tipográfico. Compruebe si la configuración proporcionada por el propietario coincide con las configuradas en AD FS. Los pasos de la página anterior le permiten configurar la configuración en AD FS a través de PowerShell.
Configuración proporcionada por el propietario
Configuración configurada en AD FS
Id. de usuario de confianza
$rp. Identificador
URI de redirección de usuario de confianza
Coincidencia de prefijo o comodín de
$rp. WSFedEndpoint para un usuario de confianza de WS-Fed
$rp. SamlEndpoints para un usuario de confianza de SAML
Id. de cliente
$client. ClientId
URI de redirección de cliente
Coincidencia de prefijo de $client. RedirectUri
Si los elementos de la tabla coinciden, compruebe además si estas opciones coinciden entre lo que aparecen en la solicitud de autenticación enviada a AD FS y qué están configurados en AD FS. Intente reproducir el problema durante el cual capture un seguimiento de Fiddler en la solicitud de autenticación enviada por la aplicación a AD FS. Examine los parámetros de solicitud para realizar las comprobaciones siguientes en función del tipo de solicitud.
Solicitudes de OAuth
Una solicitud de OAuth tiene el siguiente aspecto:
Compruebe si los parámetros de solicitud coinciden con los valores configurados en AD FS.
Parámetros de solicitud
Configuración configurada en AD FS
client_id
$client. ClientId
redirect_uri
Coincidencia de prefijo de @client_RedirectUri
El parámetro "resource" debe representar un usuario de confianza válido en AD FS. Para obtener la información del usuario de confianza, ejecute uno de los siguientes comandos.
Si usa un usuario de confianza convencional, ejecute el siguiente comando: Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
Si usa la característica Grupo de aplicaciones en Windows Server 2016, ejecute el siguiente comando: Get-AdfsWebApiApplication "ValueOfTheResourceParameter"
Descodifique el valor del parámetro SAMLRequest mediante la opción "From DeflatedSAML" en el Asistente para texto fiddler. El valor descodificado tiene el siguiente aspecto:
Realice las siguientes comprobaciones dentro del valor descodificado:
Compruebe si el nombre de host en el valor de Destination coincide con el nombre de host de AD FS.
Compruebe si el valor de Issuer coincide con $rp.Identifier.
Notas adicionales de SAML:
$rp. SamlEndpoints: muestra todos los tipos de puntos de conexión de SAML. La respuesta de AD FS se envía a las direcciones URL correspondientes configuradas en los puntos de conexión. Un punto de conexión SAML puede usar enlaces de redirección, publicación o artefactos para la transmisión de mensajes. Todas estas direcciones URL se pueden configurar en AD FS.
$rp. SignedSamlRequestsRequired: si se establece el valor, es necesario firmar la solicitud SAML enviada desde el usuario de confianza. Los parámetros "SigAlg" y "Signature" deben estar presentes en la solicitud.
$rp. RequestSigningCertificate: este es el certificado de firma que se usa para generar la firma en la solicitud SAML. Asegúrese de que el certificado es válido y pida al propietario de la aplicación que coincida con el certificado.
Comprobación del certificado de cifrado
Si $rp.EncryptClaims devuelve Enabled, el cifrado de usuario de confianza está habilitado. AD FS usa el certificado de cifrado para cifrar las notificaciones. Realice las siguientes comprobaciones:
$rp. EncryptionCertificate: use este comando para obtener el certificado y comprobar si es válido.
$rp. EncryptionCertificateRevocationCheck: use este comando para comprobar si el certificado cumple los requisitos de comprobación de revocación.
Los dos métodos anteriores no funcionan
Para continuar con la solución de problemas, consulte Uso de la aplicación Dump Token.
No todos los usuarios se ven afectados por el problema y el usuario no puede acceder a ninguno de los usuarios de confianza.
En este escenario, realice las siguientes comprobaciones.
Comprobar si el usuario está deshabilitado
Compruebe el estado del usuario en Windows PowerShell o en la interfaz de usuario. Si el usuario está deshabilitado, habilite el usuario.
Comprobación del estado del usuario con Windows PowerShell
Inicie sesión en cualquiera de los controladores de dominio.
Abra Windows PowerShell.
Para comprobar el estado del usuario, ejecute el comando siguiente:
PowerShell
Get-ADUser -Identity <samaccountname of the user> | Select Enabled
Comprobación del estado del usuario en la interfaz de usuario
Inicie sesión en cualquiera de los controladores de dominio.
Abra la consola de administración de Usuarios y equipos de Active Directory.
Haga clic en el nodo Usuarios , haga clic con el botón derecho en el usuario en el panel derecho y, a continuación, haga clic en Propiedades.
Haga clic en la pestaña Account (Cuenta).
En Opciones de cuenta, compruebe si la cuenta está deshabilitada .
Si la opción está activada, desactivela.
Compruebe si las propiedades del usuario se actualizaron recientemente
Si alguna propiedad del usuario se actualiza en Active Directory, se produce un cambio en los metadatos del objeto de usuario. Compruebe el objeto de metadatos de usuario para ver qué propiedades se actualizaron recientemente. Si se encuentran cambios, asegúrese de que los servicios relacionados los recoge. Para comprobar si hubo cambios de propiedad en un usuario, siga estos pasos:
Inicie sesión en un controlador de dominio.
Abra Windows PowerShell.
Ejecute el comando siguiente para obtener los metadatos del objeto de usuario: repadmin /showobjmeta <destination DC> "user DN"
Un ejemplo del comando es: repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"
En los metadatos, examine la columna Hora y fecha de cada atributo para ver si hay alguna pista sobre un cambio. En el ejemplo siguiente, el atributo userPrincipleName toma una fecha más reciente que los demás atributos que representan un cambio en los metadatos del objeto de usuario.
Compruebe la confianza del bosque si el usuario pertenece a otro bosque.
En un entorno de AD FS de varios bosques, se requiere una confianza de bosque bidireccional entre el bosque donde se implementa AD FS y los demás bosques que usan la implementación de AD FS para la autenticación. Para comprobar si la confianza entre los bosques funciona según lo previsto, siga estos pasos:
Inicie sesión en un controlador de dominio en el bosque donde se implementa AD FS.
Abra la consola de administración de confianzas y Dominio de Active Directory.
En la consola de administración, haga clic con el botón derecho en el dominio que contiene la confianza que desea comprobar y, a continuación, haga clic en Propiedades.
Haga clic en la pestaña Trusts (Confianzas).
En Dominios de confianza de este dominio (confianzas salientes) o Dominios que confían en este dominio (confianzas entrantes), haga clic en la confianza que se va a comprobar y, a continuación, haga clic en Propiedades.
Haz clic en Validar.
En el cuadro de diálogo Servicios de dominio de Active Directory, seleccione cualquiera de las opciones.
Si selecciona No, se recomienda repetir el mismo procedimiento para el dominio mutuo.
Si selecciona Sí, proporcione una credencial de usuario administrativo para el dominio mutuo. No es necesario realizar el mismo procedimiento para el dominio mutuo.
No todos los usuarios se ven afectados por el problema y el usuario puede acceder a algunos de los usuarios de confianza.
En este escenario, compruebe si este problema se produce en un escenario de Microsoft Entra. Si es así, realice estas comprobaciones para solucionar este problema. Si no es así, consulte Uso de la aplicación Dump Token para solucionar este problema.
Compruebe si el usuario está sincronizado con el identificador de Entra de Microsoft
Si un usuario intenta iniciar sesión en microsoft Entra ID, se le redirigirá a AD FS para la autenticación de un dominio federado. Una de las posibles razones para un inicio de sesión con errores es que el usuario aún no está sincronizado con el identificador de Microsoft Entra. Es posible que vea un bucle de Microsoft Entra ID a Active Directory FS después del primer intento de autenticación en AD FS. Para determinar si el usuario está sincronizado con el identificador de Entra de Microsoft, siga estos pasos:
Descargue e instale el módulo de PowerShell de Azure AD para Windows PowerShell.
Abra Windows PowerShell con la opción "Ejecutar como administrador".
Inicie una conexión a Microsoft Entra ID mediante la ejecución del comando siguiente: Connect-MsolService
Proporcione la credencial de administrador global para la conexión.
Para obtener la lista de usuarios en el identificador de Microsoft Entra, ejecute el siguiente comando: Get-MsolUser
Compruebe si el usuario está en la lista.
Si el usuario no está en la lista, sincronice el usuario con el identificador de Microsoft Entra.
Comprobación de immutableID y UPN en la regla de notificación de emisión
Microsoft Entra ID requiere immutableID y el UPN del usuario para autenticar al usuario.
Nota
immutableID también se denomina sourceAnchor en las siguientes herramientas:
Sincronización de Azure AD
Sincronización de Azure Active Directory (DirSync)
Los administradores pueden usar Microsoft Entra Connect para la administración automática de confianza de AD FS con el identificador de Microsoft Entra. Si no administra la confianza a través de Microsoft Entra Connect, se recomienda descargar Microsoft Entra Connect Microsoft Entra Connect y habilitar la administración automática de reglas de notificación en función de la configuración de sincronización.
Para comprobar si las reglas de notificación de immutableID y UPN en AD FS coinciden con lo que usa microsoft Entra ID, siga estos pasos:
Obtenga sourceAnchor y UPN en Microsoft Entra Connect.
Abra Microsoft Entra Connect.
Haga clic en Ver configuración actual.
En la página Revisar la solución , anote los valores de SOURCE ANCHOR y USER PRINCIPAL NAME.
Compruebe los valores de immutableID (sourceAnchor) y UPN en la regla de notificación correspondiente configurada en el servidor de AD FS.
En el servidor de AD FS, abra la consola de administración de AD FS.
Haga clic en Confianzas de usuario autenticado.
Haga clic con el botón derecho en la relación de confianza del usuario de confianza con microsoft Entra ID y, a continuación, haga clic en Editar directiva de emisión de notificaciones.
Abra la regla de notificación para el identificador inmutable y el UPN.
Compruebe si las variables consultadas para los valores de immutableID y UPN son las mismas que las que aparecen en Microsoft Entra Connect.
Si hay alguna diferencia, use uno de los métodos siguientes:
Si Microsoft Entra Connect administra AD FS, restablezca la confianza del usuario de confianza mediante Microsoft Entra Connect.
Si Microsoft Entra Connect no administra AD FS, corrija las notificaciones con los atributos correctos.
Si estas comprobaciones no le ayudaron a resolver el problema, consulte Uso de la aplicación Dump Token para solucionar este problema.
Este problema se produce en el lado de la aplicación.
Si AD FS ha renovado recientemente el certificado de firma de tokens, compruebe si el asociado de federación recoge el nuevo certificado. En caso de que AD FS use un certificado de descifrado de tokens que también se ha renovado recientemente, realice también la misma comprobación. Para comprobar si el certificado de firma de tokens de AD FS actual en AD FS coincide con el del asociado de federación, siga estos pasos:
Para obtener el certificado de firma de tokens actual en AD FS, ejecute el siguiente comando:
PowerShell
Get-ADFSCertificate -CertificateTypetoken-signing
En la lista de certificados devueltos, busque el que tiene IsPrimary = TRUE y anote la huella digital.
Obtenga la huella digital del certificado de firma de tokens actual en el asociado de federación. El propietario de la aplicación debe proporcionarle esto.
Compare las huellas digitales de los dos certificados.
Realice la misma comprobación si AD FS usa un certificado de descifrado de tokens renovado, salvo que el comando para obtener el certificado de descifrado de tokens en AD FS es el siguiente:
Las huellas digitales de los dos certificados coinciden
Si las huellas digitales coinciden, asegúrese de que los asociados usan los nuevos certificados de AD FS.
Si hay errores de coincidencia de certificados, asegúrese de que los asociados usan los nuevos certificados. Los certificados se incluyen en los metadatos de federación publicados por el servidor de AD FS.
Nota
Los asociados hacen referencia a todos los asociados de la organización de recursos o de la organización de la cuenta, representados en AD FS mediante confianzas de usuario autenticado y confianzas del proveedor de notificaciones.
Los asociados pueden acceder a los metadatos de federación.
Si los asociados pueden acceder a los metadatos de federación, pida a los asociados que usen los nuevos certificados.
Los asociados no pueden acceder a los metadatos de federación.
En este caso, debe enviar manualmente a los asociados las claves públicas de los nuevos certificados. Para ello, siga estos pasos:
Exporte las claves públicas como archivos .cert o como archivos .p7b para incluir todas las cadenas de certificados.
Envíe las claves públicas a los asociados.
Pida a los asociados que usen los nuevos certificados.
Las huellas digitales de los dos certificados no coinciden
A continuación, compruebe si hay un error de coincidencia de algoritmo de firma de tokens. Para ello, siga estos pasos:
Para determinar el algoritmo utilizado por el usuario de confianza, ejecute el siguiente comando:
Pida al propietario de la aplicación el formato NameIdentifier requerido por la aplicación.
Compruebe si los dos formatos NameIdentifier coinciden.
Si los formatos no coinciden, configure la notificación NameIdentifier para usar el formato que requiere la aplicación. Para ello, siga estos pasos:
Abra la consola de administración de AD FS.
Haga clic en Confianzas de usuario autenticado, seleccione el asociado de federación adecuado y, a continuación, haga clic en Editar directiva de emisión de notificaciones en el panel Acciones .
Agregue una nueva regla si no hay ninguna regla para emitir la notificación NameIdentifier o actualizar una regla existente. Seleccione Id. de nombre para Tipo de notificación entrante y, a continuación, especifique el formato que requiere la aplicación.
Si los dos algoritmos no coinciden, actualice el algoritmo de firma usado por la confianza del usuario de confianza de usuario de confianza.
Abra la consola de administración de AD FS.
Haga clic con el botón derecho en la relación de confianza del usuario de confianza y, a continuación, haga clic en Propiedades.
En la pestaña Opciones avanzadas , seleccione el algoritmo para que coincida con lo que requiere la aplicación.
Acerca de la renovación automática de certificados
Si el certificado de firma de tokens o el certificado de descifrado de tokens son autofirmados, AutoCertificateRollover está habilitado de forma predeterminada en estos certificados y AD FS administra la renovación automática de los certificados cuando están cerca de expirar.
Para determinar si usa certificados autofirmados, siga estos pasos:
Ejecute el siguiente comando:
PowerShell
Get-ADFSCerticate -CertificateType"token-signing"
Examine los atributos de certificado.
Si los atributos Subject y Issuer comienzan por "CN=ADFS Signing...", el certificado está autofirmado y administrado por AutoCertRollover.
Para confirmar si los certificados se renuevan automáticamente, siga estos pasos:
Ejecute el siguiente comando:
PowerShell
Get-ADFSProperties | FL AutoCertificateRollover
Examine el atributo AutoCertificateRollover.
Si AutoCertificateRollover = TRUE, AD FS genera automáticamente nuevos certificados (30 días antes de la expiración de forma predeterminada) y los establece como certificados principales (25 días antes de la expiración).
Si AutoCertificateRollover = FALSE, debe reemplazar manualmente los certificados.
Comprobación de los servicios y componentes relacionados con ADFS
En este artículo se presenta cómo comprobar los servicios y componentes relacionados con ADFS. Estos pasos podrían ayudarle a solucionar problemas de inicio de sesión (SSO) con Servicios de federación de Active Directory (AD FS) (ADFS).
Comprobación de DNS
El acceso a ADFS debe apuntar directamente a uno de los servidores WAP (proxy de aplicación web) o al equilibrador de carga delante de los servidores WAP. Realice las siguientes comprobaciones:
Haga ping al nombre del servicio de federación (por ejemplo, fs.contoso.com). Confirme si la dirección IP a la que se resuelve ping es de uno de los servidores WAP o del equilibrador de carga de los servidores WAP.
Compruebe si hay un registro A para el servicio de federación en el servidor DNS. El registro A debe apuntar a uno de los servidores WAP o al equilibrador de carga de los servidores WAP.
Si WAP no se implementa en el escenario para el acceso externo, compruebe si el acceso a ADFS apunta directamente a uno de los servidores ADFS o al equilibrador de carga delante de los servidores ADFS:
Haga ping al nombre del servicio de federación (por ejemplo, fs.contoso.com). Confirme si la dirección IP que obtiene se resuelve en uno de los servidores ADFS o en el equilibrador de carga de los servidores ADFS.
Compruebe si hay un registro A para el servicio de federación en el servidor DNS. El registro A debe apuntar a uno de los servidores ADFS o al equilibrador de carga de los servidores ADFS.
Compruebe el equilibrador de carga si se usa.
Compruebe si el firewall está bloqueando el tráfico entre:
El servidor ADFS y el equilibrador de carga.
El servidor WAP (Proxy de aplicación web) y el equilibrador de carga si se usa WAP.
Si el sondeo está habilitado en el equilibrador de carga, compruebe lo siguiente:
Si ejecuta Windows Server 2012 R2, asegúrese de que está instalado el paquete acumulativo de actualizaciones de agosto de 2014.
Compruebe si el puerto 80 está habilitado en el firewall en los servidores WAP y los servidores ADFS.
Asegúrese de que el sondeo está establecido para el puerto 80 y para el punto de conexión /adfs/probe.
Comprobación de la configuración del firewall
Compruebe si el tráfico entrante a través del puerto TCP 443 está habilitado en:
el firewall entre el servidor proxy de aplicación web y la granja de servidores de federación.
el firewall entre los clientes y el servidor proxy de aplicación web.
Compruebe si el tráfico entrante a través del puerto TCP 49443 está habilitado en el firewall entre los clientes y el servidor proxy de aplicación web cuando se cumplen las condiciones siguientes:
La autenticación de cliente TLS mediante el certificado X.509 está habilitada.
Usa ADFS en Windows Server 2012 R2.
Nota
La configuración no es necesaria en el firewall entre el servidor proxy de aplicación web y los servidores de federación.
Compruebe si el punto de conexión está habilitado en el proxy.
ADFS proporciona varios puntos de conexión para diferentes funcionalidades y escenarios. No todos los puntos de conexión están habilitados de forma predeterminada. Para comprobar si el punto de conexión está habilitado en el proxy, siga estos pasos:
En el servidor de ADFS, abra la Consola de administración de ADFS.
Expanda Puntos de conexión de servicio>.
Busque el punto de conexión y compruebe si el estado está habilitado en la columna Proxy Enabled (Habilitado para proxy).
Comprobación de la relación de confianza de proxy
Si se implementa el proxy de aplicación web (WAP), la relación de confianza de proxy debe establecerse entre el servidor WAP y el servidor de AD FS. Compruebe si se establece la relación de confianza de proxy o comienza a producir un error en algún momento dado.
Nota
La información de esta página se aplica a AD FS 2012 R2 y versiones posteriores.
Información adicional
La relación de confianza de proxy se basa en el certificado de cliente. Al ejecutar el Asistente para la instalación posterior al proxy de aplicación web, el asistente genera un certificado de cliente autofirmado con las credenciales que especificó en el asistente. A continuación, el asistente inserta el certificado en la base de datos de configuración de AD FS y lo agrega al almacén de certificados AdfsTrustedDevices en el servidor de AD FS.
Para cualquier comunicación SSL, http.sys usa el siguiente orden de prioridad para que los enlaces de certificados SSL coincidan con un certificado:
Priority
Nombre
Parámetros
Descripción
1
IP
IP:port
Coincidencia exacta de IP y puerto
2
SNI
Nombre de host:puerto
Coincidencia exacta de nombre de host (la conexión debe especificar SNI)
3
CCS
Port
Invocar almacén de certificados central
4
Carácter comodín IPv6
Port
Coincidencia de caracteres comodín IPv6 (la conexión debe ser IPv6)
5
Carácter comodín de IP
Port
Coincidencia de caracteres comodín IP (la conexión puede ser IPv4 o IPv6)
AD FS 2012 R2 y versiones posteriores son independientes de Internet Information Services (IIS) y se ejecutan como un servicio sobre http.sys. hostname:port los enlaces de certificado SSL los usa AD FS. Durante la autenticación de certificados de cliente, AD FS envía una lista de confianza de certificados (CTL) basada en los certificados del almacén de AdfsTrustedDevices. Si un enlace de certificado SSL para el servidor de AD FS usa IP:port o el almacén CTL no es AdfsTrustedDevices, es posible que no se establezca la relación de confianza de proxy.
Obtención de los enlaces de certificado SSL para AD FS
En el servidor de AD FS, ejecute el siguiente comando en Windows PowerShell: netsh http show sslcert
En la lista de enlaces devueltos, busque aquellos con el identificador de aplicación de 5d89a20c-beab-4389-9447-324788eb944a. Este es un ejemplo de un enlace correcto. Anote la línea "Ctl Store Name" (Nombre del almacén de Ctl).
Output
Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Ejecutar script para detectar automáticamente problemas
Para detectar automáticamente problemas con la relación de confianza de proxy, ejecute el siguiente script. En función del problema detectado, realice la acción en consecuencia.
PowerShell
param
(
[switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1$certbindingissuedetected = $falseWhile($i -lt$httpsslcertoutput.count)
{
$ipport = $false$hostnameport = $falseif ( ( $httpsslcertoutput[$i] -match"IP:port" ) ) { $ipport = $true }
elseif ( ( $httpsslcertoutput[$i] -match"Hostname:port" ) ) { $hostnameport = $true }
## Check for IP specific certificate bindingsif ( ( $ipport -eq$true ) )
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
if ( ( $ipbindingparsed[2].trim() -ne"0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq"443") )
{
$warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning$certbindingissuedetected = $true
}
$i = $i + 14continue
}
## check that CTL Store is set for ADFS service bindingelseif ( $hostnameport -eq$true )
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
If ( ( $ipbindingparsed[2].trim() -eq$adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq"443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne"AdfsTrustedDevices" ) )
{
Write-Warning"ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"$certbindingissuedetected = $true
}
$i = $i + 14continue
}
$i++
}
If ( $certbindingissuedetected -eq$false ) { Write-Host"Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert storeWrite-Host; Write-Host"2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne$_.Subject}
If ( $certlist.count -gt0 )
{
Write-Warning"The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"$certlist | Format-List Subject
}
Else { Write-Host"Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
Param ([bool]$repair=$false)
Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
$doc = new-object Xml
$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
$connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
$command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = $command$cmd.Connection = $cli$cli.Open()
$configString = $cmd.ExecuteScalar()
$configXml = new-object XML
$configXml.LoadXml($configString)
$rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
#$ctl = dir cert:\LocalMachine\ADFSTrustedDevices$store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
$store.open("MaxAllowed")
$atLeastOneMismatch = $false$badCerts = @()
foreach($rawCertin$rawCerts)
{
$rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
$now = Get-Dateif ( ($cert.NotBefore -lt$now) -and ($cert.NotAfter -gt$now))
{
$certThumbprint = $cert.Thumbprint
$certSubject = $cert.Subject
$ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
if ($ctlMatch -eq$null)
{
$atLeastOneMismatch = $trueWrite-Warning"This cert is NOT in the CTL: $certThumbprint – $certSubject"if ($repair -eq$true)
{
write-Warning"Attempting to repair"$store.Add($cert)
Write-Warning"Repair successful"
}
else
{
Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
}
}
}
}
$store.Close()
if ($atLeastOneMismatch -eq$false)
{
Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
}
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")
Problema 1: Hay un enlace específico de IP
El enlace puede entrar en conflicto con el enlace de certificado de AD FS en el puerto 443.
El enlace IP:port tiene la prioridad más alta. Si un enlace IP:port está en los enlaces de certificado SSL de AD FS, http.sys siempre usa el certificado para el enlace para la comunicación SSL. Para solucionar este problema, use los métodos siguientes.
Quitar el enlace IP:port
Tenga en cuenta que el enlace IP:port puede volver después de quitarlo. Por ejemplo, una aplicación configurada con este enlace IP:port puede volver a crearla automáticamente en el siguiente inicio del servicio.
Usar otra dirección IP para la comunicación SSL de AD FS
Si se requiere el enlace IP:port, resuelva el FQDN del servicio ADFS en otra dirección IP que no se use en ningún enlace. De este modo, http.sys usará el enlace Hostname:port para la comunicación SSL.
Establezca AdfsTrustedDevices como almacén de CTL para el enlace IP:port.
Este es el último recurso si no puede usar los métodos anteriores. Pero es mejor comprender las condiciones siguientes antes de cambiar el almacén de CTL predeterminado a AdfsTrustedDevices:
Por qué el enlace IP:port está ahí.
Si el enlace se basa en el almacén de CTL predeterminado para la autenticación de certificados de cliente.
Problema 2: El enlace de certificados de AD FS no tiene el nombre del almacén CTL establecido en AdfsTrustedDevices
Si Microsoft Entra Connect está instalado, use Microsoft Entra Connect para establecer el nombre del almacén CTL en AdfsTrustedDevices para los enlaces de certificado SSL en todos los servidores de AD FS. Si Microsoft Entra Connect no está instalado, vuelva a generar los enlaces de certificado de AD FS ejecutando el siguiente comando en todos los servidores de AD FS.
PowerShell
Set-AdfsSslCertificate -Thumbprint Thumbprint
Problema 3: Existe un certificado que no está autofirmado en el almacén de certificados AdfsTrustedDevices
Si un certificado emitido por la ENTIDAD de certificación está en un almacén de certificados donde normalmente solo existirían certificados autofirmados, el CTL generado a partir del almacén solo contendrá el certificado emitido por la ENTIDAD de certificación. El almacén de certificados AdfsTrustedDevices es un almacén que se supone que solo tiene certificados autofirmados. Estos certificados son:
MS-Organization-Access: el certificado autofirmado que se usa para emitir certificados de unión al área de trabajo.
Confianza de proxy de ADFS: los certificados para cada servidor proxy de aplicación web.
Por lo tanto, elimine cualquier certificado emitido por la ENTIDAD de certificación del almacén de certificados AdfsTrustedDevices.
Problema 4: Instalar KB2964735 o volver a ejecutar el script con -syncproxytrustcerts
Cuando se establece una relación de confianza de proxy con un servidor de AD FS, el certificado de cliente se escribe en la base de datos de configuración de AD FS y se agrega al almacén de certificados de AdfsTrustedDevices en el servidor de AD FS. Para una implementación de granja de servidores de AD FS, se espera que el certificado de cliente se sincronice con los otros servidores de AD FS. Si la sincronización no se produce por algún motivo, una relación de confianza de proxy solo funcionará con el servidor de AD FS con el que se estableció la confianza, pero no en los demás servidores de AD FS.
Para solucionar este problema, use uno de los métodos siguientes.
Método 1
Instale la actualización documentada en KB 2964735 en todos los servidores de AD FS. Una vez instalada la actualización, se espera que se produzca automáticamente una sincronización del certificado de cliente.
Método 2
Ejecute el script con el modificador – syncproxytrustcerts para sincronizar manualmente los certificados de cliente desde la base de datos de configuración de AD FS al almacén de certificados AdfsTrustedDevices. El script debe ejecutarse en todos los servidores de AD FS de la granja de servidores.
Nota
Esta no es una solución permanente porque los certificados de cliente se renovarán periódicamente.
Problema 5: Se pasan todas las comprobaciones. Pero el problema persiste
Compruebe si hay un error de coincidencia de zona horaria o hora. Si la hora coincide, pero la zona horaria no, tampoco se establecerá la relación de confianza de proxy.
Compruebe si hay terminación SSL entre el servidor de AD FS y el servidor WAP.
Si se produce una terminación SSL en un dispositivo de red entre los servidores de AD FS y el servidor WAP, la comunicación entre AD FS y WAP se interrumpirá porque la comunicación se basa en el certificado de cliente.
Deshabilite la terminación SSL en el dispositivo de red entre los servidores AD FS y WAP.
Uso de la aplicación Dump Token
La aplicación Dump Token es útil al depurar problemas con el servicio de federación, así como validar reglas de notificación personalizadas. No es una solución oficial, sino una buena solución de depuración independiente que se recomienda para la solución de problemas.
Antes de usar la aplicación Dump Token
Antes de usar la aplicación Dump Token, debe:
Obtenga la información del usuario de confianza de la aplicación a la que desea acceder. Si se implementa la autenticación de OAuth, obtenga también la información del cliente de OAuth.
Configurar la aplicación Dump Token.
Obtención de la información del cliente de OAuth y del usuario de confianza
Si usa un usuario de confianza convencional, siga estos pasos:
En el servidor de AD FS, abra Windows PowerShell con la opción Ejecutar como administrador .
Para agregar el componente AD FS 2.0 a Windows PowerShell, ejecute el siguiente comando:
PowerShell
Add-PSSnapin Microsoft.Adfs.PowerShell
Para obtener la información del usuario de confianza, ejecute el siguiente comando:
PowerShell
$rp = Get-AdfsRelyingPartyTrust RPName
Para obtener la información del cliente de OAuth, ejecute el siguiente comando:
PowerShell
$client = Get-AdfsClient ClientName
Si usa la característica Grupo de aplicaciones en Windows Server 2016, siga estos pasos:
En el servidor de AD FS, abra Windows PowerShell con la opción Ejecutar como administrador .
Para obtener la información del usuario de confianza, ejecute el siguiente comando:
PowerShell
$rp = Get-AdfsWebApiApplication ResourceID
Si el cliente de OAuth es público, ejecute el comando siguiente para obtener la información del cliente:
Ahora continúe con los siguientes métodos de solución de problemas. Al final de cada método, vea si se resuelve el problema. Si no es así, use otro método.
Métodos de solución de problemas
Compruebe la directiva de autorización para ver si el usuario se ve afectado.
En este método, empezará por obtener los detalles de la directiva y, a continuación, usará la aplicación Dump Token para diagnosticar la directiva para ver si el usuario se ve afectado.
Obtención de los detalles de la directiva
$rp. IssuanceAuthorizationRules muestra las reglas de autorización del usuario de confianza.
En Windows Server 2016 y versiones posteriores, puede usar $rp. AccessControlPolicyName para configurar la directiva de autenticación y autorización. Si $rp. AccessControlPolicyName tiene valor, se aplica una directiva de control de acceso que rige la directiva de autorización. En ese caso, $rp. IssuanceAuthorizationRules está vacío. Use $rp. ResultantPolicy para obtener más información sobre la directiva de control de acceso.
Si $rp. ResultantPolicy no tiene los detalles de la directiva, examine las reglas de notificación reales. Para obtener las reglas de notificación, siga estos pasos:
Establezca la directiva de control de acceso en $null ejecutando el comando siguiente: Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
Para obtener la información del usuario de confianza, ejecute el siguiente comando: $rp = Get-AdfsRelyingPartyTrust RPName
Compruebe $rp.IssuanceAuthorizationRules y $rp. AdditionalAuthenticationRules.
Uso de la aplicación Dump Token para diagnosticar la directiva de autorización
Establezca la directiva de autenticación de token de volcado de memoria para que sea la misma que el usuario de confianza con errores.
Haga que el usuario abra uno de los vínculos siguientes en función de la directiva de autenticación que establezca.
Forzar la autenticación multifactor: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Inicie sesión en la página De inicio de sesión.
Lo que obtiene es el conjunto de notificaciones del usuario. Compruebe si hay algo en la directiva de autorización que deniega explícitamente o permita al usuario en función de estas notificaciones.
Compruebe si alguna notificación faltante o inesperada provoca la denegación de acceso al recurso.
Configure las reglas de notificación de la aplicación Dump Token para que sean las mismas que las reglas de notificación del usuario de confianza con errores.
Configure la directiva de autenticación de token de volcado de memoria para que sea la misma que el usuario de confianza con errores.
Haga que el usuario abra uno de los vínculos siguientes en función de la directiva de autenticación que establezca.
Forzar la autenticación multifactor: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Inicie sesión en la página De inicio de sesión.
Este es el conjunto de notificaciones que el usuario de confianza va a obtener para el usuario. Si faltan notificaciones o no son inesperadas, examine la directiva de emisión para averiguar el motivo.
Si todas las notificaciones están presentes, compruebe con el propietario de la aplicación para ver qué notificación falta o es inesperada.
Comprobación de si se requiere un estado de dispositivo
Si las reglas de autorización comprueban las notificaciones del dispositivo, compruebe si falta alguna de estas notificaciones de dispositivo en la lista de notificaciones que obtiene de la aplicación Dump Token. Las notificaciones que faltan podrían bloquear la autenticación del dispositivo. Para obtener las notificaciones de la aplicación Dump Token, siga los pasos descritos en la sección Usar la aplicación De token de volcado para diagnosticar la directiva de autorización en la directiva Comprobar autorización si el usuario se vio afectado .
A continuación se muestran las notificaciones del dispositivo. Las reglas de autorización pueden usar algunas de ellas.
Si todas las notificaciones están presentes, consulte si los valores de las notificaciones de la aplicación Dump Token coinciden con los valores necesarios en la directiva de autorización.
Obtenga información sobre cómo solucionar los errores de servicio de AD DS o la pérdida de rendimiento. Obtenga información sobre cómo recuperar objetos de seguridad eliminados y la base de datos de AD DS, y cómo solucionar problemas de autenticación híbrida.
Muestre las características de Microsoft Entra ID para modernizar las soluciones de identidad, implementar soluciones híbridas e implementar la gobernanza de identidades.
Describe cómo solucionar problemas de autenticación que pueden surgir para los usuarios federados en el identificador de Microsoft Entra u Office 365. Proporciona una lista completa de los síntomas y sus soluciones.
Describe un problema en el que un usuario federado recibe un mensaje de error de Servicios de federación de Active Directory (AD FS) (AD FS) cuando el usuario intenta iniciar sesión en un servicio en la nube de Microsoft como Microsoft 365, Azure o Microsoft Intune.
Describe que no se puede autenticar una cuenta en AD FS 2.0, que se le pedirán credenciales y que se registra el evento 111. Se proporciona una resolución.
