Solución de problemas de SSO con Servicios de federación de Active Directory (AD FS) (AD FS)

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 un mensaje de autenticación NTLM inesperado o basado en formularios, siga los pasos de este artículo para solucionar este problema.

Comprobación de 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 del 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> localavanzados, asegúrese de que la dirección URL de AD FS está en la lista de sitios web.
  • Después de Nivel personalizado de intranet > local de seguridad>, asegúrese de que la opción Inicio de sesión automático solo en zona de intranet está seleccionada.

Si usa Firefox, Chrome o Safari, asegúrese de que la configuración equivalente de estos exploradores esté habilitada.

Comprobación de la configuración de AD FS

Compruebe la configuración WindowsIntegratedFallback
  1. Abra Windows PowerShell con la opción Ejecutar como administrador.

  2. Para obtener la directiva de autenticación global, ejecute el siguiente comando:

    Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
    
  3. 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 obtener compatibilidad con el explorador.

Si el valor es False, se debe esperar la autenticación integrada de Windows.

Compruebe la configuración WIASupportedUsersAgents
  1. Para obtener la lista de agentes de usuario admitidos, ejecute el siguiente comando:

    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  2. Examine la lista de cadenas de 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:

  1. Vaya a http://useragentstring.com/ que detecta y muestra la cadena del agente de usuario del explorador.

  2. Para obtener la lista de agentes de usuario admitidos, ejecute el siguiente comando:

    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  3. Para agregar la cadena del agente de usuario del explorador, ejecute el siguiente comando:

    $wiaStrings = $wiaStrings+"NewUAString"
    

    Ejemplo:

    $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
    
  4. Actualice la configuración WIASupportedUserAgents mediante la ejecución del siguiente comando:

    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
    

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.
  1. Si la solicitud de autenticación es una solicitud de WS-Federation, compruebe si la solicitud incluye wauth= urn:oasis:names:tc:SAML:1.0:am:password.
  2. 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.

Para obtener más información, vea Información general sobre los controladores de autenticación de las páginas de inicio de sesión de AD FS.

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 se controla mediante la solicitud de autenticación entrante. Trabaje con el propietario de la aplicación para cambiar el comportamiento.

Si la aplicación es Microsoft Online Services, lo que experimenta puede controlarse mediante la configuración PromptLoginBehavior del objeto de dominio de confianza. Esta configuración controla si los inquilinos de Azure AD envían prompt=login a AD FS. Para establecer la configuración PromptLoginBehavior , siga estos pasos:

  1. Abra Windows PowerShell con la opción "Ejecutar como administrador".

  2. Para obtener la configuración de federación de dominio existente, ejecute el siguiente comando:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  3. Establezca la opción PromptLoginBehavior ejecutando el siguiente comando:

    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
    

    Los valores del parámetro PromptLoginBehavior son:

    1. TranslateToFreshPasswordAuth: Azure AD 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.
    2. NativeSupport: el parámetro prompt=login se envía tal y como está a AD FS.
    3. Deshabilitado: no se envía nada a AD FS.

Para obtener más información sobre el comando Set-MSOLDomainFederationSettings, consulte Servicios de federación de Active Directory (AD FS) prompt=login parameter support.

Escenario de Azure Active Directory (Azure AD)

Si la solicitud de autenticación enviada a Azure AD incluye el parámetro prompt=login, deshabilite la funcionalidad prompt=login ejecutando el siguiente comando:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Después de ejecutar este comando, Office 365 aplicaciones no incluirán el parámetro prompt=login en cada solicitud de autenticación.

Escenario que no es de Azure AD

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 símbolo del sistema 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, habilítelo y pruebe si el problema se ha resuelto.

Símbolo del sistema de autenticación multifactor

Para solucionar este problema, compruebe si las reglas de notificación del usuario de confianza están establecidas 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 especificarse en un parámetro de solicitud de autenticación. Compruebe las configuraciones para ver si están establecidas correctamente. Si se espera la autenticación multifactor, pero se le solicita repetidamente, compruebe las reglas de emisión de usuario de confianza para ver si las notificaciones de autenticación multifactor se pasan a través de 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.

  1. Para comprobar la configuración en el servidor de AD FS, ejecute el siguiente comando en una ventana de Windows PowerShell.

    Get-ADFSAdditionalAuthenticationRule
    

    Para comprobar la configuración en el usuario de confianza, ejecute el siguiente comando:

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    Nota:

    Si los comandos no devuelven nada, no se configuran las reglas de autenticación adicionales. Omita esta sección.

  2. Observe el conjunto de reglas de notificación configurado.

Compruebe 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 de condición: C:[Type=``…,Value=…]
  • La instrucción issue: => issue (Type=``…,Value=…)

Si la instrucción issue contiene la siguiente notificación, 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 que se use la autenticación multifactor 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 la parte que responde 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:

  1. En Windows PowerShell, ejecute el comando siguiente:

    Get-ADFSRelyingPartyTrust -TargetName ClaimApp
    
  2. 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 de 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.

Para obtener más información, vea Información general sobre los controladores de autenticación de las páginas de inicio de sesión de AD FS.

Compruebe si la aplicación es Microsoft Online Services para Office 365

Si la aplicación a la que desea acceder es Microsoft Online Services para Office 365, compruebe la configuración de federación de dominio SupportsMFA.

  1. Para obtener la configuración de federación de dominio supportsMFA actual, ejecute el siguiente comando:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  2. Si el valor de SupportsMFA es FALSE, establézcalo en TRUE ejecutando el siguiente comando:

    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
    

Comprobación de si el inicio de sesión único está deshabilitado

Si el inicio de sesión único está deshabilitado, habilítelo y pruebe si el problema se ha resuelto.

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 la aplicación.

Si el problema se produce en la página de inicio de sesión de AD FS, recibirá un mensaje "Se produjo un 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 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 de la sección siguiente según dónde se 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 AD FS está en funcionamiento y la funcionalidad de autenticación funciona correctamente. Para abrir la página IdpInitiatedSignOn, siga estos pasos:

  1. Habilite la página IdpInitiatedSignOn ejecutando el siguiente comando en el servidor de AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Desde un equipo que se encuentra dentro de la red, visite la página siguiente:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Escriba las credenciales correctas de un usuario válido en la página de inicio de sesión.

El inicio de sesión se ha realizado correctamente.

Si el inicio de sesión se realiza correctamente, compruebe si el estado del servicio de AD FS se está ejecutando.

  1. En el servidor de AD FS, abra Administrador del servidor.
  2. En el Administrador del servidor, haga clic en Servicios de herramientas>.
  3. 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:

  1. Habilite la página IdpInitiatedSignOn ejecutando el siguiente comando en el servidor de AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Desde un equipo que está fuera de la red, visite la página siguiente:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Escriba las credenciales correctas de un usuario válido en la página de inicio de sesión.

Si el inicio de sesión no se realiza correctamente, consulte Comprobación de los componentes y servicios relacionados con AD FS y Comprobación de la relación de confianza del proxy.

Si el inicio de sesión se realiza correctamente, continúe con la solución de problemas con los pasos descritos en Todos los usuarios se ven afectados por el problema y el usuario puede acceder a algunos de los usuarios de confianza.

El inicio de sesión no se ha realizado correctamente

Si el inicio de sesión no se realiza correctamente, compruebe los servicios y los componentes relacionados con AD FS.

Compruebe si el estado del servicio de AD FS se está ejecutando.

  1. En el servidor de AD FS, abra Administrador del servidor.
  2. En el Administrador del servidor, haga clic en Servicios de herramientas>.
  3. 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:

  1. En el servidor de AD FS, abra la consola de administración de AD FS.

  2. ExpandaPuntos de conexión deservicio>.

  3. Busque los puntos de conexión y compruebe si los estados están habilitados en la columna Habilitado .

    Compruebe el estado de todos los puntos de conexión de A D F S habilitados.

A continuación, compruebe si Azure AD Connect está instalado. Se recomienda usar Azure AD Connect, lo que facilita la administración de certificados SSL.

Si Está instalado Azure AD Connect, asegúrese de usarlo para administrar y actualizar certificados SSL.

Si Azure AD 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 procedan 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 con el nombre del servidor de AD FS ni con 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

  • No se revoca el certificado.

    Compruebe si hay revocación de certificados. Si se revoca el certificado, la conexión SSL no puede ser de confianza y los clientes los bloquearán.

Si el certificado SSL no cumple estos requisitos, intente obtener un certificado calificado para la comunicación SSL. Se recomienda usar Azure AD 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:

  1. Para enumerar los certificados que se encuentran en el almacén personal del equipo local, ejecute el siguiente comando:
    dir Cert:\LocalMachine\My
  2. 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 esperado.

Para obtener la huella digital del certificado que está en uso, ejecute el siguiente comando en Windows PowerShell:

Get-AdfsSslCertificate

Si se usa el certificado incorrecto, establezca el certificado correcto ejecutando el siguiente comando:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint
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 SERVIDORES de AD FS. Esto no sucede automáticamente. Para comprobar si se ha establecido el certificado correcto, siga estos pasos:

  1. En la consola de administración de AD FS, expandaCertificadosde servicio>.
  2. 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 AD FS el permiso De lectura al certificado. Para ello, siga estos pasos:

  1. Establezca el certificado correcto:

    1. Haga clic con el botón derecho en Certificadosy, a continuación, haga clic en Establecer certificado de comunicación de servicio.
    2. Seleccione el certificado correcto.
  2. Compruebe si el servicio AD FS tiene el permiso de lectura para el certificado:

    1. Agregue el complemento Certificados para la cuenta de equipo local a Microsoft Management Console (MMC).
    2. Expanda Certificados (equipo local)>Personal>Certificados.
    3. Haga clic con el botón derecho en el certificado SSL y haga clic en Todas las tareas>Administrar claves privadas.
    4. Compruebe si adfssrv aparece en Nombres de grupo y de usuario con el permiso Leer .
  3. Si adfssrv no aparece en la lista, conceda al servicio AD FS el permiso Leer al certificado:

    1. Haga clic en Agregar, en Ubicaciones, en el servidor y, a continuación, en Aceptar.
    2. En Escriba los nombres de objeto que desea seleccionar, escriba nt service\adfssrv, haga clic en Comprobar nombresy, 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.
    3. Conceda el permiso Leer 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 de firmante (SAN).

Para comprobar si el certificado SSL tiene los SAN correctos, siga estos pasos:

  1. Para enumerar todos los sufijos UPN que se usan en la organización, ejecute el siguiente comando:

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. Compruebe si el certificado SSL tiene configurados los SAN necesarios.

  3. Si el certificado SSL no tiene los nombres DRS correctos como SAN, obtenga un nuevo certificado SSL que tenga los SAN correctos para DRS y, a continuación, ú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.

    1. Asegúrese de que el certificado SSL está instalado en el almacén personal del equipo local en cada servidor WAP.

    2. Para obtener el certificado SSL usado por WAP, ejecute el siguiente comando:

      Get-WebApplicationProxySslCertificate
      
    3. Si el certificado SSL es incorrecto, establezca el certificado SSL correcto mediante la ejecución del siguiente comando:

      Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
      
  • 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 de AD FS.
    • {f955c070-e044-456c-ac00-e9e4275b3f04}: este es el identificador de aplicación para la Application Proxy web.

    Por ejemplo, si se especifica el certificado SSL para un enlace de reserva como 0.0.0.0:443, asegúrese de que el enlace se actualiza en consecuencia cuando se actualiza 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 usuario de confianza y del cliente de OAuth. Si usa un usuario de confianza convencional, siga estos pasos:

  1. En el servidor de AD FS principal, abra Windows PowerShell con la opción Ejecutar como administrador.

  2. Para agregar el componente AD FS 2.0 a Windows PowerShell, ejecute el siguiente comando:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Para obtener la información del usuario de confianza, ejecute el siguiente comando:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Para obtener la información del cliente de OAuth, ejecute el siguiente comando:

    $client = Get-AdfsClient ClientName
    

Si usa la característica Grupo de aplicaciones en Windows Server 2016, siga estos pasos:

  1. En el servidor de AD FS principal, abra Windows PowerShell con la opción Ejecutar como administrador.

  2. Para obtener la información del usuario de confianza, ejecute el siguiente comando:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Si el cliente de OAuth es público, ejecute el siguiente comando para obtener la información del cliente:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Si el cliente es confidencial, ejecute el siguiente comando para obtener la información del cliente:

    $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 identificador de usuario de confianza, el identificador de cliente y el URI de redirección deben proporcionarlo el propietario de la aplicación y el cliente. Sin embargo, podría haber una falta de coincidencia entre lo que proporciona el propietario y lo que se configura en AD FS. Por ejemplo, una falta 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. En los pasos de la página anterior se obtiene la configuración configurada en AD FS a través de PowerShell.

Configuración proporcionada por el propietario Configuración configurada en AD FS
Identificador de usuario de confianza $rp. Identificador
URI de redireccionamiento de usuario de confianza Prefijo o coincidencia de caracteres comodín de
  • $rp. WSFedEndpoint para un usuario de confianza de WS-Fed
  • $rp. SamlEndpoints para un usuario de confianza saml
Id. de cliente $client. ClientId
URI de redireccionamiento de cliente Coincidencia de prefijo de $client. RedirectUri

Si los elementos de la tabla coinciden, compruebe además si esta configuración coincide entre lo que aparecen en la solicitud de autenticación enviada a AD FS y lo que se configura en AD FS. Intente reproducir el problema durante el cual captura 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 siguientes comprobaciones en función del tipo de solicitud.

Solicitudes de OAuth

Una solicitud de OAuth es similar a la siguiente:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Compruebe si los parámetros de solicitud coinciden con la configuración configurada en AD FS.

Parámetros de la 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"
solicitudes de WS-Fed

Una solicitud de WS-Fed es similar a la siguiente:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Compruebe si los parámetros de solicitud coinciden con la configuración configurada en AD FS:

Parámetros de la solicitud Configuración configurada en AD FS
wtrealm $rp. Identificador
wreply Coincidencia de prefijo o coincidencia de caracteres comodín de $rp. WSFedEndpoint
Solicitudes SAML

Una solicitud SAML es similar a la siguiente:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Descodificar el valor del parámetro SAMLRequest mediante la opción "From DeflatedSAML" del Asistente para texto de Fiddler. El valor descodificado es similar al siguiente:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Realice las siguientes comprobaciones dentro del valor descodificado:

  • Compruebe si el nombre de host en el valor de Destino coincide con el nombre de host de AD FS.
  • Compruebe si el valor de Issuer coincide con $rp.Identifier.

Notas adicionales para SAML:

  • $rp. SamlEndpoints: muestra todos los tipos de puntos de conexión 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 redireccionamiento, publicación o artefacto para la transmisión de mensajes. Todas estas direcciones URL se pueden configurar en AD FS.
  • $rp. SignedSamlRequestsRequired: si se establece el valor, debe firmarse 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 comprobaciones siguientes:

  • $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 token de volcado de memoria.

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 la interfaz de usuario. Si el usuario está deshabilitado, habilite el usuario.

Compruebe el estado del usuario con Windows PowerShell
  1. Inicie sesión en cualquiera de los controladores de dominio.

  2. Abra Windows PowerShell.

  3. Para comprobar el estado del usuario, ejecute el siguiente comando:

    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    

    Use el comando Get-ADUser para comprobar el estado habilitado para el usuario.

Comprobación del estado del usuario en la interfaz de usuario
  1. Inicie sesión en cualquiera de los controladores de dominio.

  2. Abra la consola de administración de Usuarios y equipos de Active Directory.

  3. 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.

  4. Haga clic en la pestaña Cuenta .

  5. En Opciones de cuenta, compruebe si La cuenta está deshabilitada .

    Compruebe si la opción Cuenta está deshabilitada está activada.

  6. Si la opción está activada, desmarcarla.

Compruebe si las propiedades de usuario se actualizaron recientemente.

Si se actualiza alguna propiedad del usuario 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 recogen. Para comprobar si se han producido cambios de propiedad en un usuario, siga estos pasos:

  1. Inicie sesión en un controlador de dominio.

  2. Abra Windows PowerShell.

  3. Para obtener los metadatos del objeto de usuario, ejecute el siguiente comando:
    repadmin /showobjmeta <destination DC> "user DN"

    Un ejemplo del comando es:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. En los metadatos, examine la columna Time/Date de cada atributo para obtener cualquier pista de un cambio. En el ejemplo siguiente, el atributo userPrincipleName toma una fecha más reciente que los demás atributos, lo que representa un cambio en los metadatos del objeto de usuario.

    Salida del comando repadmin showobjmeta.

Comprobación de 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 esperado, siga estos pasos:

  1. Inicie sesión en un controlador de dominio en el bosque donde se implementa AD FS.

  2. Abra la consola de administración Dominios y confianzas de Active Directory .

  3. 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.

  4. Haga clic en la pestaña Confianzas .

  5. En Dominios de confianza para 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.

  6. Haga 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 recíproco.

    • Si selecciona , proporcione una credencial de usuario administrativo para el dominio recíproco. No es necesario realizar el mismo procedimiento para el dominio recíproco.

      Valide la confianza entrante en el cuadro de diálogo Servicios de dominio de Active Directory.

Si estos pasos no le ayudaron a resolver el problema, continúe con la solución de problemas con los pasos descritos en No todos los usuarios se ven afectados por el problema y el usuario puede acceder a algunas de las partes de confianza .

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 Azure AD. 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.

Comprobación de si el usuario está sincronizado con Azure AD

Si un usuario intenta iniciar sesión en Azure AD, 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 error es que el usuario aún no está sincronizado con Azure AD. Es posible que vea un bucle de Azure AD a AD FS después del primer intento de autenticación en AD FS. Para determinar si el usuario está sincronizado con Azure AD, siga estos pasos:

  1. Descargue e instale el módulo de PowerShell de Azure AD para Windows PowerShell.
  2. Abra Windows PowerShell con la opción "Ejecutar como administrador".
  3. Inicie una conexión a Azure AD mediante la ejecución del siguiente comando:
    Connect-MsolService
  4. Proporcione la credencial de administrador global para la conexión.
  5. Para obtener la lista de usuarios de Azure AD, ejecute el siguiente comando:
    Get-MsolUser
  6. Compruebe si el usuario está en la lista.

Si el usuario no está en la lista, sincronice el usuario con Azure AD.

Comprobación de inmutableID y UPN en la regla de notificación de emisión

Azure AD requiere inmutableID y el UPN del usuario para autenticar al usuario.

Nota:

immutableID también se denomina sourceAnchor en las herramientas siguientes:

  • Sincronización de Azure AD
  • Sincronización de Azure Active Directory (DirSync)

Los administradores pueden usar Azure AD Connect para la administración automática de la confianza de AD FS con Azure AD. Si no administra la confianza a través de Azure AD Connect, se recomienda que lo haga descargando Azure AD Connect Azure AD Connect habilita la administración automática de reglas de notificaciones en función de la configuración de sincronización.

Para comprobar si las reglas de notificación de inmutableID y UPN en AD FS coinciden con lo que usa Azure AD, siga estos pasos:

  1. Obtenga sourceAnchor y UPN en Azure AD Connect.

    1. Abra Azure AD Connect.

    2. Haga clic en Ver configuración actual.

      Seleccione la página Ver configuración actual en la página Tareas adicionales de Azure A D Connect.

    3. En la página Revisar la solución , anote los valores de SOURCE ANCHOR y USER PRINCIPAL NAME.

      Obtenga los valores de SOURCE ANCHOR y USER PRINCIPAL NAME en la página Azure A D Connect.

  2. Compruebe los valores de immutableID (sourceAnchor) y UPN en la regla de notificación correspondiente configurada en el servidor de AD FS.

    1. En el servidor de AD FS, abra la consola de administración de AD FS.

    2. Haga clic en Confianzas de usuario de confianza.

    3. Haga clic con el botón derecho en la confianza del usuario de confianza con Azure AD y, a continuación, haga clic en Editar directiva de emisión de notificaciones.

    4. Abra la regla de notificación para el identificador inmutable y UPN.

    5. Compruebe si las variables consultadas para los valores de inmutableID y UPN son las mismas que aparecen en Azure AD Connect.

      Compruebe los valores de inmutableID y UPN en la regla de notificación correspondiente configurada en el servidor de A D F S.

  3. Si hay una diferencia, use uno de los métodos siguientes:

    • Si AD FS se administra mediante Azure AD Connect, restablezca la confianza del usuario de confianza mediante Azure AD Connect.
    • Si Azure AD 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 renovó recientemente el certificado de firma de tokens, compruebe si el asociado de federación ha recogido el nuevo certificado. En caso de que AD FS use un certificado de descifrado de tokens que también se renovó 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:

  1. Para obtener el certificado de firma de tokens actual en AD FS, ejecute el siguiente comando:

    Get-ADFSCertificate -CertificateType token-signing
    
  2. En la lista de certificados devueltos, busque el que tiene IsPrimary = TRUE y anote la huella digital.

  3. Obtenga la huella digital del certificado de firma de token actual en el asociado de federación. El propietario de la aplicación debe proporcionarle esto.

  4. Compare las huellas digitales de los dos certificados.

Realice la misma comprobación si AD FS usa un certificado de descifrado de token renovado, excepto que el comando para obtener el certificado de descifrado de tokens en AD FS es el siguiente:

Get-ADFSCertificate -CertificateType token-decrypting

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 coincidencias 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 cuenta, representados en AD FS mediante confianzas de usuario de confianza 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:

    1. Exporte las claves públicas como archivos .cert o como archivos .p7b para incluir todas las cadenas de certificados.
    2. Envíe las claves públicas a los asociados.
    3. Pida a los asociados que usen los nuevos certificados.

Las huellas digitales de los dos certificados no coinciden

A continuación, compruebe si hay una falta de coincidencia del algoritmo de firma de tokens. Para ello, siga estos pasos:

  1. Para determinar el algoritmo utilizado por el usuario de confianza, ejecute el siguiente comando:

    Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
    

    Los valores posibles son SHA1 o SHA256.

  2. Compruebe con el propietario de la aplicación el algoritmo usado en la aplicación.

  3. Compruebe si los dos algoritmos coinciden.

Si los dos algoritmos coinciden, compruebe si el formato de id. de nombre coincide con lo que requiere la aplicación.

  1. En el servidor de AD FS, volcado de las reglas de transformación de emisión mediante la ejecución del siguiente comando:

    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
    
  2. Busque la regla que emite la notificación NameIdentifier. Si dicha regla no existe, omita este paso.

    Este es un ejemplo de la regla:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Observe el formato NameIdentifier en la sintaxis siguiente:

    Properties["Property-type-URI"] = "ValueURI"

    Los formatos posibles se enumeran a continuación. El primer formato es el predeterminado.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  3. Pida al propietario de la aplicación el formato NameIdentifier requerido por la aplicación.

  4. Compruebe si los dos formatos NameIdentifier coinciden.

  5. Si los formatos no coinciden, configure la notificación NameIdentifier para usar el formato que requiere la aplicación. Para ello, siga estos pasos:

    1. Abra la consola de administración de AD FS.
    2. Haga clic en Confianzas de usuario de confianza, 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 .
    3. 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.

    Agregue una regla de notificación de transformación si no hay ninguna regla para emitir la notificación NameIdentifier o actualizar una regla existente.

Si los dos algoritmos no coinciden, actualice el algoritmo de firma usado por la confianza del usuario de confianza.

  1. Abra la consola de administración de AD FS.

  2. Haga clic con el botón derecho en la confianza del usuario de confianza y, a continuación, haga clic en Propiedades.

  3. En la pestaña Opciones avanzadas , seleccione el algoritmo para que coincida con lo que requiere la aplicación.

    Seleccione el algoritmo para que coincida con lo que requiere la aplicación en la pestaña Avanzadas del cuadro de diálogo Propiedades.

Acerca de la renovación automática de certificados

Si el certificado de firma de tokens o el certificado de descifrado de tokens están 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 a punto de expirar.

Para determinar si usa certificados autofirmados, siga estos pasos:

  1. Ejecute el comando siguiente:

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Ejecute el cmdlet Get-ADFSCerticate, Firma de token de tipo de certificado.

  2. Examine los atributos de certificado.

    Si los atributos Subject y Issuer comienzan por "CN=ADFS Signing...", autofirmado y administrado por AutoCertRollover.

Para confirmar si los certificados se renuevan automáticamente, siga estos pasos:

  1. Ejecute el comando siguiente:

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Ejecute el cmdlet Get-ADFSProperties para confirmar si los certificados se renuevan automáticamente.

  2. 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.

En este artículo se presenta cómo comprobar los componentes y servicios 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 (web Application Proxy) o al equilibrador de carga delante de los servidores WAP. Realice las comprobaciones siguientes:

  • Haga ping al nombre del servicio de federación (por ejemplo, fs.contoso.com). Confirme si la dirección IP en la que se resuelve el 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 de ADFS o al equilibrador de carga delante de los servidores de 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 de ADFS o en el equilibrador de carga de los servidores de 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 de 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 (Application Proxy 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 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 de Application Proxy web y la granja de servidores de federación.
  • el firewall entre los clientes y el servidor de Application Proxy 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 de Application Proxy web cuando se cumplen las condiciones siguientes:

  • La autenticación de cliente TLS mediante el certificado X.509 está habilitada.
  • Está usando ADFS en Windows Server 2012 R2.

Nota:

La configuración no es necesaria en el firewall entre el servidor de Application Proxy 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:

  1. En el servidor ADFS, abra la consola de administración de ADFS.

  2. ExpandaPuntos de conexión deservicio>.

  3. Busque el punto de conexión y compruebe si el estado está habilitado en la columna Proxy habilitado .

    Compruebe el estado de los puntos de conexión de A D F S que se muestra en la columna Proxy habilitado.

Comprobación de la relación de confianza del proxy

Si se implementa Application Proxy web (WAP), se debe establecer la relación de confianza de proxy entre el servidor WAP y el servidor de AD FS. Compruebe si la relación de confianza del proxy está establecida 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 de contexto

La relación de confianza de proxy se basa en el certificado de cliente. Al ejecutar el Asistente para Application Proxy web posterior a la instalación, 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:

Prioridad Nombre Parámetros Descripción
1 IP IP:port Coincidencia exacta de ip y puerto
2 Sni Hostname:port Coincidencia exacta del nombre de host (la conexión debe especificar SNI)
3 Ccs Puerto Invocación del almacén central de certificados
4 Carácter comodín de IPv6 Puerto Coincidencia de caracteres comodín IPv6 (la conexión debe ser IPv6)
5 Carácter comodín de IP Puerto Coincidencia de caracteres comodín de 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 servicio además de http.sys. LOS enlaces de certificado SSL hostname:port 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 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 del proxy.

Obtención de los enlaces de certificados 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".

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

Ejecución del script para detectar problemas automáticamente

Para detectar automáticamente problemas con la relación de confianza del proxy, ejecute el siguiente script. En función del problema detectado, realice la acción en consecuencia.

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 = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $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 + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $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 + 14
        continue
        }
    $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 store
Write-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 -gt 0 )
{
    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($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($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 = $true
          Write-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 certificados 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.

  1. 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.

  2. Uso de 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.

  3. Establecer AdfsTrustedDevices como el almacén CTL para el enlace IP:port

    Este es el último recurso si no puede usar los métodos anteriores. Pero es mejor comprender las siguientes condiciones antes de cambiar el almacén CTL predeterminado a AdfsTrustedDevices:

    • Por qué el enlace IP:port está allí.
    • Si el enlace se basa en el almacén CTL predeterminado para la autenticación de certificados de cliente.

Problema 2: El enlace de certificado de AD FS no tiene el nombre del almacén CTL establecido en AdfsTrustedDevices

Si Está instalado Azure AD Connect, use AAD Connect para establecer el nombre del almacén CTL en AdfsTrustedDevices para los enlaces de certificados SSL en todos los servidores de AD FS. Si Azure AD 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.

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 una 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: certificado autofirmado que se usa para emitir certificados de unión al área de trabajo.
  • Confianza del proxy de ADFS: los certificados para cada servidor de Application Proxy web.

Certificados para cada servidor de Application Proxy web.

Por lo tanto, elimine cualquier certificado emitido por la ENTIDAD de certificación del almacén de certificados AdfsTrustedDevices.

Problema 4: Instale KB2964735 o vuelva 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 AdfsTrustedDevices en el servidor de AD FS. Para una implementación de granja de AD FS, se espera que el certificado de cliente se sincronice con los demás servidores de AD FS. Si la sincronización no se produce por alguna razón, una relación de confianza de proxy solo funcionará en 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 de la base de datos de configuración de AD FS con el 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 una falta de coincidencia de hora o zona horaria. Si la hora coincide pero la zona horaria no lo hace, también se producirá un error en la relación de confianza del proxy.

Compruebe si hay una terminación SSL entre el servidor de AD FS y el servidor WAP.

Si la terminación SSL se produce 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 Token de volcado 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 hacer lo siguiente:

  1. 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.
  2. Configure la aplicación Token de volcado.

Obtención de la información del usuario de confianza y del cliente de OAuth

Si usa un usuario de confianza convencional, siga estos pasos:

  1. En el servidor de AD FS, abra Windows PowerShell con la opción Ejecutar como administrador.

  2. Para agregar el componente AD FS 2.0 a Windows PowerShell, ejecute el siguiente comando:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Para obtener la información del usuario de confianza, ejecute el siguiente comando:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Para obtener la información del cliente de OAuth, ejecute el siguiente comando:

    $client = Get-AdfsClient ClientName
    

Si usa la característica Grupo de aplicaciones en Windows Server 2016, siga estos pasos:

  1. En el servidor de AD FS, abra Windows PowerShell con la opción Ejecutar como administrador.

  2. Para obtener la información del usuario de confianza, ejecute el siguiente comando:

    $rp = Get-AdfsWebApiApplication ResourceID
    
  3. Si el cliente de OAuth es público, ejecute el siguiente comando para obtener la información del cliente:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Si el cliente de OAuth es confidencial, ejecute el siguiente comando para obtener la información del cliente:

    $client = Get-AdfsServerApplication ClientName
    

Configuración de la aplicación Dump Token

Para configurar la aplicación Token de volcado de memoria, ejecute los siguientes comandos en la ventana Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Ahora continúe con los siguientes métodos de solución de problemas. Al final de cada método, vea si el problema está resuelto. 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, comienza por obtener los detalles de la directiva y, a continuación, usa la aplicación Token de volcado para diagnosticar la directiva y ver si el usuario se ve afectado.

Obtener 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 autenticación y la directiva de autorización. Si $rp. AccessControlPolicyName tiene valor, existe 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 averiguar detalles sobre la directiva de control de acceso.

Si $rp. ResultantPolicy no tiene los detalles sobre la directiva, examine las reglas de notificación reales. Para obtener las reglas de notificación, siga estos pasos:

  1. Establezca la directiva de control de acceso en $null mediante la ejecución del siguiente comando:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. Para obtener la información del usuario de confianza, ejecute el siguiente comando:
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. Compruebe $rp.IssuanceAuthorizationRules y $rp. AdditionalAuthenticationRules.
Uso de la aplicación Dump Token para diagnosticar la directiva de autorización
  1. Establezca la directiva de autenticación del token de volcado para que sea la misma que la del usuario de confianza con errores.

  2. Haga que el usuario abra uno de los vínculos siguientes en función de la directiva de autenticación que establezca.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forzar la autenticación multifactor: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Inicie sesión en la página Sign-In.

Lo que obtiene es el conjunto de notificaciones del usuario. Compruebe si hay algo en la directiva de autorización que deniegue o permita explícitamente al usuario en función de estas notificaciones.

Compruebe si alguna notificación inesperada o que falte hace que se deniegue el acceso al recurso.

  1. Configure las reglas de notificación en la aplicación Token de volcado de memoria para que sean las mismas que las reglas de notificación del usuario de confianza con errores.

  2. Configure la directiva de autenticación del token de volcado para que sea la misma que la del usuario de confianza con errores.

  3. Haga que el usuario abra uno de los vínculos siguientes en función de la directiva de autenticación que establezca.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forzar la autenticación multifactor: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Inicie sesión en la página Sign-In.

Este es el conjunto de notificaciones que el usuario de confianza va a obtener para el usuario. Si faltan notificaciones o son inesperadas, examine la directiva de emisión para averiguar el motivo.

Si todas las notificaciones están presentes, consulte 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 de dispositivo, compruebe si falta alguna de estas notificaciones de dispositivo en la lista de notificaciones que obtiene de la aplicación Token de volcado. Las notificaciones que faltan podrían bloquear la autenticación del dispositivo. Para obtener las notificaciones de la aplicación Token de volcado, siga los pasos descritos en la sección Uso de la aplicación token de volcado para diagnosticar la directiva de autorización de la directiva Comprobar autorización si el usuario se ha visto afectado por el método.

A continuación se muestran las notificaciones del dispositivo. Las reglas de autorización pueden usar algunas de ellas.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
  • http://schemas.microsoft.com/2014/02/deviceusagetime
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Si falta una notificación, siga los pasos descritos en Configurar el acceso condicional local mediante dispositivos registrados para asegurarse de que el entorno está configurado para la autenticación de dispositivos.

Si todas las notificaciones están presentes, vea si los valores de las notificaciones de la aplicación Token de volcado coinciden con los valores necesarios en la directiva de autorización.