We couldn’t sign you in
Select the account you want to use.

Continúe con la solución de problemas para comprobar posibles problemas con el usuario de confianza.

Continuar con comprobaciones adicionales en el usuario de confianza.

Continúe la solución para comprobar el certificado SSL.

Continúe la solución para comprobar la relación de confianza de proxy entre el Proxy de la aplicación Web y AD FS.

El enlace puede entrar en conflicto con el enlace de certificado de AD FS en el puerto 443.

¿Qué problema encontrar el usuario con SSO?

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 "se produjo un error", "HTTP 503 Servicio no está disponible" o algún otro mensaje de error. La dirección URL de la página de error muestra el nombre de 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.

¿Dónde se produce este problema?

¿Afecta este problema a todos los usuarios?

¿El usuario puede acceder a cualquiera de las partes de confianza?

¿Este problema se produce en un escenario de Azure AD?

¿El usuario puede acceder a cualquiera de las partes de confianza?

Si el certificado de firma de tokens se ha renovado recientemente por AD FS, comprobar si el nuevo certificado se ha seleccionado por el socio de la federación. En caso de AD FS usa un token de descifrado de certificado que también se ha renovado recientemente, realice la misma comprobación. Para comprobar si el token de AD FS actual certificado en AD FS de firma coincida con el socio de federación, siga estos pasos:

  1. Obtener el token actual firma certificados en AD FS ejecutando el comando siguiente:
    Get-ADFSCertificate -CertificateType token-signing

  2. En la lista de certificados devuelta, encontrar aquella IsPrimary = TRUEy tome nota de la huella digital.

  3. Obtener la huella digital del actual símbolo (token) de firma en el asociado de federación. El propietario de la aplicación debe proporcionar esta.

  4. Comparar las huellas digitales de los dos certificados .

Realice la misma comprobación si AD FS usa un símbolo (token) renovado descifrado de certificado, excepto que el comando para obtener el token de descifrado de certificado en AD FS es como sigue:
Get-ADFSCertificate -CertificateType token-decrypting

Si el símbolo (token) certificado o token de descifrado certificado de firma está autofirmado, AutoCertificateRollover está habilitada 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 está utilizando certificados autofirmados, siga estos pasos:

  1. Ejecute el siguiente comando:
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. Examinar los atributos de certificado.
    Si los atributos de asunto y emisor comienza con "CN = ADFS firma...", el certificado es autofirmado y administrado por AutoCertRollover.

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

  1. Ejecute el siguiente comando:
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. Examine el atributo AutoCertificateRollover.

    • Si AutoCertificateRollover = TRUE, AD FS automáticamente genera nuevos certificados (30 días antes del vencimiento de forma predeterminada) y los establece como el principales certificados (25 días antes de la expiración).

    • Si AutoCertificateRollover = FALSE, debe reemplazar manualmente los certificados.

¿Coinciden con las huellas digitales?

Para comprobar si hay una incoherencia, siga estos pasos:

  1. Determinar el algoritmo utilizado por el usuario de confianza al ejecutar el comando siguiente: Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    Los valores posibles son SHA1 o SHA256 .

  2. Consulte con el propietario de la aplicación del algoritmo utilizado en el lado de la aplicación.

  3. Compruebe si coinciden los dos algoritmos.

¿Existe una falta de coincidencia?

¿Obtener el usuario un mensaje inesperado de NTLM o una solicitud de autenticación basada en formularios?

¿El usuario recibe un mensaje inesperado para la autenticación con varios factores? ¿O el usuario frecuentemente encuentra en el símbolo del sistema?

¿Este problema se produce en un escenario de Azure AD?

¿La solicitud de autenticación enviada a AD Azure incluye el parámetro de inicio de sesión = preguntar?

Parámetros de solicitud como WAUTH y RequestedAuthNContext en las solicitudes de autenticación pueden tener métodos de autenticación especificados. ¿El parámetro de solicitud impone la solicitud de autenticación inesperado?

Utilice los métodos siguientes para solucionar problemas.

Comprobar el estado de usuario de Windows PowerShell o la interfaz de usuario. Si el usuario está deshabilitado, permiten al usuario.

Comprobar el estado de usuario con Windows PowerShell

  1. Iniciar sesión en cualquiera de los controladores de dominio.

  2. Abrir Windows PowerShell.

  3. Comprobar el estado del usuario ejecutando el siguiente comando:
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Comprobar el estado del usuario en la interfaz de usuario

  1. Iniciar sesión en cualquiera de los controladores de dominio.

  2. Abra la consola de administración de Active Directory Users and Computers .

  3. Haga clic en el nodo usuarios , haga clic en el usuario en el panel derecho y, a continuación, haga clic en Propiedades.

  4. Haga clic en la ficha cuenta .

  5. En Opciones de cuenta, compruebe si está activada la cuenta está deshabilitada .
    The "Account is disabled" option under Account options

  6. Si la opción está activada, desactívela.

¿Se solucionó el problema?

Si cualquier propiedad del usuario se actualiza en Active Directory, produce un cambio en los metadatos del objeto de usuario. Compruebe el objeto de metadatos del usuario para ver las propiedades que se han actualizado recientemente. Si se encuentran cambios, asegúrese de que ellos son recogidos por los servicios relacionados. Para comprobar si se produjeron cambios de propiedad a un usuario, siga estos pasos:

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

  2. Abrir Windows PowerShell.

  3. Para obtener los metadatos del objeto de usuario, ejecutando 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 de fecha y hora de cada atributo para cualquier pista de un cambio. En el ejemplo siguiente, el atributo userPrincipleName toma una fecha más reciente que el resto de atributos que representa un cambio en los metadatos del objeto de usuario.
    repadmin show user metadata

¿Se solucionó el problema?

En un entorno de varios bosque AD FS, es necesaria entre el bosque donde se implementa AD FS y los otros bosques que utilizan la implementación de AD FS para la autenticación de una confianza bidireccional de bosque. Para comprobar si la confianza entre los bosques funciona como se esperaba, siga estos pasos:

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

  2. Consola de administración de Active Directory dominios y confianzas de Open .

  3. En el consola de administración de, haga clic en el dominio que contiene la confianza que desea comprobar y, a continuación, haga clic en Propiedades.

  4. Haga clic en la ficha confía .

  5. En dominios de confianza para este dominio (confianzas de salida) o dominios que confían en este dominio (confianzas de entrada), haga clic en la confianza que desea 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 que repita el mismo procedimiento para el dominio recíproco.

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

Active Directory Domain Services

  • ¿Se solucionó el problema?

La aplicación volcar Token es útil para depurar problemas con el servicio de federación como validación personalizada reglas de notificación. No es una solución oficial, pero una buena solución de depuración independiente que se recomienda para los propósitos de solución de problemas.

Antes de utilizar el volcado de símbolo (token) de la aplicación, necesitará:

  1. Obtener la información de usuario de confianza de la aplicación que desea tener acceso. Si se implementa la autenticación OAuth, obtenga la información de cliente de OAuth.

  2. Configurar el volcado de símbolo (token) de la aplicación.

Obtener la información de cliente de OAuth y usuario de confianza

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

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

  2. Agregar AD FS 2.0 componente Windows PowerShell ejecutando el comando siguiente:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Obtener la información de proveedores de confianza ejecutando el comando siguiente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Obtener la información de cliente de OAuth ejecutando el comando siguiente:
    $client = Get-AdfsClient ClientName

Si utiliza la característica de grupo de aplicaciones en Windows Server 2016, siga los siguientes pasos:

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

  2. Obtener la información de proveedores de confianza ejecutando el comando siguiente:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Si el cliente de OAuth es público, obtener del cliente información ejecutando el comando siguiente:
    $client = Get-AdfsNativeClientApplication ClientName

    Si el cliente de OAuth es confidencial, obtener del cliente información ejecutando el comando siguiente:
    $client = Get-AdfsServerApplication ClientName

Configurar la aplicación volcar Token

Para configurar el volcado de símbolo (token) de la aplicación, ejecute los comandos siguientes en la ventana de 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 se ha resuelto. Si no es así, utilice otro método.

En este método, primero debe obtener el Detalles de la directiva y a continuación, utilice la aplicación volcar Token para diagnosticar la directiva para ver si el usuario se vea afectado.

Obtener detalles de la directiva

$rp. IssuanceAuthorizationRules muestra las reglas de autorización de usuario de confianza.

En Windows Server 2016 y versiones posteriores, puede utilizar $rp. AccessControlPolicyName para configurar la directiva de autenticación y autorización. Si $rp. AccessControlPolicyName tiene el valor, es una directiva de control de acceso en el lugar que controla la directiva de autorización. En ese caso , $rp. IssuanceAuthorizationRules está vacío. Utilice $rp. ResultantPolicy para obtener detalles acerca de la directiva de control de acceso.

Si $rp. ResultantPolicy no tiene los detalles acerca de la directiva, busque en las reglas de notificación real. Para obtener las reglas de notificación, siga estos pasos:

  1. Establezca la directiva de control de acceso en $null ejecutando el comando siguiente:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null

  2. Obtener la información de proveedores de confianza ejecutando el comando siguiente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  3. Check $rp.IssuanceAuthorizationRulesy$rp. AdditionalAuthenticationRules.

Utilizar la aplicación volcar Token para diagnosticar la directiva de autorización

  1. Establecer la directiva de autenticación Token volcar a ser el mismo que el usuario de confianza del error.

  2. Que el usuario abra uno de los siguientes vínculos según establece la directiva de autenticación.

    • 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 con varios factores: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 de inicio de sesión.

Lo que se obtiene es el conjunto de las solicitudes del usuario. Vea si hay algo en la directiva de autorización que deniega explícitamente o permite que el usuario basado en estas notificaciones.

¿Se solucionó el problema?

  1. Configurar las reglas de notificación en la aplicación sea la misma que las reglas de notificación de la parte de confianza error volcar Token.

  2. Configurar la directiva de autenticación Token Dump para ser el mismo que el usuario de confianza del error.

  3. Que el usuario abra uno de los siguientes vínculos según establece la directiva de autenticación.

    • 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 con varios factores: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 de inicio de sesión.

Éste es el conjunto de notificaciones que el usuario de confianza se va a obtener el usuario. Si cualquier reclamo falta o inesperados, consulte la directiva de emisión para averiguar el motivo.

Si todas las solicitudes son presente, póngase en contacto con el propietario de la aplicación para ver qué reclamo falta o no es inesperado.

¿Se solucionó el problema?

Si comprueban las reglas de autorización para las notificaciones del dispositivo, compruebe si alguna de estas afirmaciones de dispositivos faltan en la lista de notificaciones que recibe de volcado de símbolo (token) de la aplicación. Los créditos que faltan podrían bloquear autenticación del dispositivo. Para obtener las notificaciones de volcado de símbolo (token) de la aplicación, siga los pasos descritos en la sección utilizar el Token volcar app para diagnosticar la directiva de autorización en el método de comprobar la directiva de autorización si afectara al usuario .

Las siguientes son las notificaciones de dispositivos. Las reglas de autorización que use algunos de ellos.

  • 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 hay un reclamo que faltan, siga los pasos de acceso condicional local configurar utilizando registrado dispositivos para asegurarse de que el entorno está configurado para la autenticación del dispositivo.

Si están presentes todas las reclamaciones, vea si los valores de las notificaciones de volcado de símbolo (token) de la aplicación coinciden con los valores necesarios en la directiva de autorización.

¿Se solucionó el problema?

Utilice los métodos siguientes para solucionar problemas. Al final de cada método, vea si el problema se ha resuelto. Si no es así, utilice otro método.

Si un usuario está intentando iniciar sesión en AD de Azure, se redirigirán a AD FS para la autenticación de un dominio federado. Uno de los motivos posibles para un inicio de sesión fallido es que el usuario no está sincronizado aún con Azure AD. Puede que vea un bucle de Azure AD para AD FS después de la primera autenticación intento AD FS. Para determinar si el usuario está sincronizado con Azure AD, siga estos pasos:

  1. Descargar e instale el módulo de AD PowerShell de Azure para Windows PowerShell.

  2. Abrir Windows PowerShell con la opción "Ejecutar como administrador".

  3. Iniciar una conexión a Active Directory Azure ejecutando el comando siguiente:
    Connect-MsolService

  4. Proporcionar las credenciales de administrador global para la conexión.

  5. Obtener la lista de usuarios en AD Azure ejecutando el comando siguiente:
    Get-MsolUser

  6. Compruebe si el usuario está en la lista.

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

¿Se solucionó el problema?

Azure AD requiere immutableID y UPN del usuario para autenticar al usuario.

Nota: immutableID se llama también sourceAnchor en las siguientes herramientas:

  • Azure sincronización de AD

  • Azure Active Directory sincronización (DirSync)

Los administradores de pueden utilizar Azure Connect de AD para administración automática de confianza de AD FS con Azure AD. Si no se administra la confianza a través de Azure Connect de AD, le recomendamos hacerlo de descarga Azure Connect AD. Automática de azure Connect AD permite reclamar la administración de reglas basada en la configuración de sincronización.

Para comprobar si la notificación de las reglas de immutableID y UPN en coincidencias de AD FS lo Azure AD utiliza, siga estos pasos:

  1. Obtener sourceAnchor y UPN en Azure Connect de AD.

    1. Conectar AD Azure abierto.

    2. Haga clic en configuración de vista actual.
      Azure AD Connect -View current configuration

    3. En la página Revisión de su solución , tome nota de los valores de DELIMITADOR de origen y Nombre A PRINCIPAL de usuario.
      Azure AD Connect -Review your solution

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

    1. Consola de administración en el servidor de AD FS, abra el AD FS .

    2. Haga clic en el usuario de confianza de confianzas.

    3. Haga clic en la confianza de las partes confianza con Azure AD y, a continuación, haga clic en Modificar directiva de emisión de la reclamación .

    4. Abra la regla de notificación para inmutables ID y UPN.

    5. Compruebe si las variables de consulta para obtener los valores de immutableID y UPN son los mismos que los que aparecen en Azure Connect de AD.
      Issue UPN and ImmutableID

    6. Si existe una diferencia, utilice uno de los métodos siguientes:

      • Si AD FS administra Azure Connect de AD, restablecer la confianza de fabricantes de confianza con Azure Connect de AD.

      • Si AD FS no está administrado por Azure Connect de AD, corrija las notificaciones con los atributos de la derecha.
         

¿Se solucionó el problema?

La información será utilizados en los siguientes pasos de solución de problemas.

 

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

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

  2. Agregar AD FS 2.0 componente Windows PowerShell ejecutando el comando siguiente:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Obtener la información de proveedores de confianza ejecutando el comando siguiente:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Obtener la información de cliente de OAuth ejecutando el comando siguiente:
    $client = Get-AdfsClient ClientName

Si utiliza la característica de grupo de aplicaciones en Windows Server 2016, siga los siguientes pasos:

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

  2. Obtener la información de proveedores de confianza ejecutando el comando siguiente:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Si el cliente de OAuth es público, ejecutando el siguiente comando para obtener la información del cliente:
    $client = Get-AdfsNativeClientApplication ClientName

    Si el cliente es confidencial, ejecutando 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.

El identificador de fabricantes de confianza, ID de cliente y redirección URI debe proporcionarse por el propietario de la aplicación y el cliente. Sin embargo, podría haber una falta de coincidencia entre el propietario que proporciona y lo que se configuran en AD FS. Por ejemplo, una falta de coincidencia puede deberse a un error tipográfico. Compruebe si la configuración proporcionada por la coincidencia de propietario los configurados en AD FS. Los pasos descritos en la anterior página Obtén la configuración de AD FS mediante PowerShell.

Configuración proporcionada por el propietario

Configuración de AD FS

Id. de entidad de confiar

$rp.Identifier

Confiar en el URI de redireccionamiento de fiesta

Una 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

El URI de redireccionamiento del cliente

Una coincidencia de prefijo de $client. RedirectUri

Si coincide con los elementos de la tabla, además comprobar si estos valores coinciden con lo que aparecen en la solicitud de autenticación enviada a AD FS y lo que se configuran en AD FS. Intente reproducir el problema durante el cual capturar una traza de Fiddler en la solicitud de autenticación enviada por la aplicación de AD FS. Examine los parámetros de solicitud para realizar las siguientes comprobaciones según el tipo de solicitud.

Solicitudes de OAuth

Una solicitud de OAuth tiene el siguiente aspecto:

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 de AD FS.

Parámetros de la petición

Configuración de AD FS

client_id

$client.ClientId

redirect_uri

Una coincidencia de prefijo de @client_RedirectUri

El parámetro "recurso" debe representar un usuario de confianza válido en AD FS. Obtener la información de proveedores de confianza al ejecutar uno de los siguientes comandos.

  • Si utiliza un usuario de confianza convencional, ejecute el siguiente comando:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • Si utiliza la característica de grupo de aplicaciones en Windows Server 2016, ejecute el siguiente comando:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

Solicitudes de WS-Fed

Una solicitud de WS-Fed tiene el siguiente aspecto:

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 de AD FS:

Parámetros de la petición

Configuración de AD FS

wtrealm

$rp.Identifier

wreply

Una coincidencia de prefijo o comodín de $rp. WSFedEndpoint

Solicitudes SAML

Una solicitud SAML tiene el siguiente aspecto:

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 "De DeflatedSAML" en el Asistente para texto de Fiddler. El valor descodificado tiene el siguiente aspecto:

<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 de valor descodificado:

  • Comprobar si el nombre de host en el valor de destino coincide con el nombre de host de AD FS.

  • Comprobar si coincide con el valor del emisor$rp.Identifier.

Notas adicionales para SAML

  • $rp. SamlEndpoints: Muestra todos los tipos de extremos SAML. La respuesta de AD FS se envía a las direcciones URL correspondientes configuradas en los extremos. Un extremo SAML puede utilizar enlaces de redirección, post o artefacto para la transmisión de mensajes. Todas estas direcciones URL pueden configurarse en AD FS.

  • $rp. SignedSamlRequestsRequired: Si se establece el valor, SAML enviará la solicitud de las necesidades de las partes confianza para ser firmado. Los parámetros "SigAlg" y "Firma" deben estar presentes en la solicitud.

  • $rp. RequestSigningCertificate: Éste es el certificado de firma utilizado 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 para que coincida con el certificado.

¿Se solucionó el problema?

If$rp.EncryptClaimsDevuelve "Enabled", cifrado de las partes de confianza está habilitada. AD FS usa el certificado de cifrado para cifrar las notificaciones. Realice las siguientes comprobaciones:

  • $rp. EncryptionCertificate: Utilice este comando para obtener el certificado y comprobar si es válido.

  • $rp. EncryptionCertificateRevocationCheck: Utilice este comando para comprobar si el certificado cumple la revocación comprobar los requisitos.

¿Se solucionó el problema?

Si hay errores de coincidencia de certificado, asegúrese de que los socios de los nuevos certificados. Los certificados se incluyen en los metadatos de federación publicado por el servidor de AD FS.

Nota: Consulte los socios toda sus organización o cuenta organización asociados de recurso, representados en su AD FS por confianza confianzas de fabricante y proveedor de reclamaciones.

Los socios pueden tener acceso a los metadatos de federación

Si los socios pueden tener acceso a los metadatos de federación, pida a los socios para utilizar los nuevos certificados.

Los socios no pueden acceder a los metadatos de federación

En este caso, deberán enviar manualmente los socios las claves públicas de los nuevos certificados. Para ello, siga estos pasos:

  1. Exportar las claves públicas como archivos .cert, o como archivos. p7b para incluir las cadenas de certificados completa.

  2. Enviar las claves públicas a los socios.

  3. Pregunte a los socios para utilizar los nuevos certificados.

¿Se solucionó el problema?

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

  2. Haga clic en la confianza de fabricantes de confianza y, a continuación, haga clic en Propiedades.

  3. En la ficha Avanzadas , seleccione el algoritmo para hacer coincidir la aplicación requiere.
    Relying party trust-Hash algorithm

Se resuelve el problema ?

  1. En el servidor de AD FS, volcar las reglas de transformación de emisión ejecutando el siguiente comando:
    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

  2. Localice la regla que emite la reclamación NameIdentifier. Si no existe dicha regla, omita este paso.
    Aquí 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 para el formato de NameIdentifier requerido por la aplicación.

  4. Compruebe si coinciden los dos formatos de NameIdentifier.

  5. Si los formatos no coinciden, configure la notificación NameIdentifier para utilizar 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 Confiar confía en proveedores, seleccione al socio de federación apropiado y, a continuación, haga clic en Editar directiva de emisión de reclamaciones en el panel de acciones .

    3. Agregar una nueva regla si no hay ninguna regla para emitir la notificación NameIdentifier o actualizar una regla existente. Seleccione Nombre de identificador para el tipo de notificación entrantey, a continuación, especifique el formato que requiere la aplicación.
      Configure claim rule

¿Se solucionó el problema?

Nota: también puede utilizar Fiddler para solucionar el problema. La idea es la misma.

La aplicación volcar Token es útil para depurar problemas con el servicio de federación como validación personalizada reglas de notificación. No es una solución oficial, pero una buena solución de depuración independiente que se recomienda para los propósitos de solución de problemas. Para utilizar el volcado de símbolo (token) de la aplicación, siga estos pasos:

  1. Configurar la aplicación volcar Token ejecutando los comandos siguientes:
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"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

  2. Replicar la configuración de falta de confianza partido copia las normas de emisión desde el usuario de confianza a DumpToken. Para ello, ejecute el siguiente comando:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

  3. Que el usuario abra uno de los siguientes vínculos según establece la directiva de autenticación.

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Forzar la autenticación con varios factores:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Obtener las notificaciones que el usuario inicie sesión en la página de autenticación.

  5. Salida en el volcado de Token, expanda la sección XML sin formato de símbolo (token) y, a continuación, Revise la declaración de atributo comprobando las siguientes cadenas para ver si coinciden con lo que se configura en la directiva de emisión de la reclamación :

    • SAML:NameIdentifier: muestra el formato NameIdentifier.

    • SAML:AttributeStatement: muestra cada par de tipo y valor de notificación para el token.

    • SAML:AuthenticationStatement: muestra el método de autenticación y autenticación instantánea.

¿Se solucionó el problema?

Utilice 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 de IdpInitiatedSignOn, siga estos pasos:

  1. Habilitar la página IdpInitiatedSignOn ejecutando el comando siguiente en el servidor de AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Desde un equipo que está dentro de la red, visite la siguiente página:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. En la página de inicio de sesión, escriba las credenciales correctas de un usuario válido.

¿Es el signo de éxito?

Para solucionar el problema, compruebe los siguientes componentes y servicios.

Acceso a AD FS debe señalar directamente a uno de los servidores de AD FS o el equilibrador de carga delante de los servidores de AD FS. Realice las siguientes comprobaciones:

  • Haga ping al nombre del servicio de federación (p. ej. fs.contoso.com). Confirme si la dirección IP que se resuelve en uno de los servidores de AD FS o el equilibrador de carga de los servidores de AD FS.

  • Comprueba si hay un registro para el servicio de federación en el servidor DNS. El registro debe señalar a uno de los servidores de AD FS o al equilibrador de carga de los servidores de AD FS.

¿Se solucionó el problema?

  • Comprobar si firewall está bloqueando el tráfico entre:

    • El servidor de AD FS y el equilibrador de carga.

    • El WAP (Proxy de aplicaciones Web) server y el equilibrador de carga si se utiliza WAP.

  • Si está habilitado el sondeo en el equilibrador de carga, compruebe lo siguiente:

    • Si está ejecutando Windows Server R2 de 2012, asegúrese de que el Paquete acumulativo de agosto de 2014 está instalado.

    • Comprobar si el puerto 80 está habilitado en el servidor de seguridad en los servidores WAP y los servidores de AD FS.

    • Asegúrese de que dicho sondeo se establece para el puerto 80 y de la sonda/adfs/extremo.

¿Se solucionó el problema?

  1. En el servidor de AD FS, abra el Administrador de servidor.

  2. En el Administrador de servidor, haga clic en Herramientas > Servicios.

  3. Compruebe si el estado de Los servicios de federación de Active Directory está funcionando.

¿Se solucionó el problema?

AD FS proporciona varios extremos para escenarios y funcionalidades diferentes. No todos los extremos están habilitados de forma predeterminada. Para comprobar el estado de los extremos, siga estos pasos:

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

  2. Expanda el servicio > extremos.

  3. Busque los extremos y compruebe si están habilitados los Estados en la columna habilitada .
    ADFS Endpoints status

¿Se solucionó el problema?

Recomendamos que utilice Azure Connect de AD que facilita la administración de certificados SSL.

¿Está instalado Azure Connect de AD en su entorno?

Si está instalado Azure Connect de AD, asegúrese de que utiliza para administrar y actualizar los certificados SSL.

¿Se solucionó el problema?

El certificado SSL debe cumplir los siguientes requisitos:

  • El certificado procede de una entidad emisora de certificados raíz de confianza.
    AD FS requiere que son certificados SSL de una entidad emisora de certificados raíz de confianza. Si se tiene acceso a AD FS desde equipos unidos sin dominio, recomendamos que use un certificado SSL de una entidad emisora de certificados raíz de terceros de confianza como DigiCert, VeriSign, etcetera. Si no es el certificado SSL de una entidad emisora de certificados raíz de confianza, puede interrumpir la comunicación SSL.

  • El nombre del sujeto del certificado es válido.
    El nombre de sujeto debe coincidir con el nombre de 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 comando siguiente en el servidor principal de AD FS:
    Get-AdfsProperties | select hostname

  • No se ha revocado el certificado.
    Comprobación de revocación de certificados. Si el certificado se revoca, conexión SSL no es de confianza y se bloqueará a los clientes.

¿El certificado SSL que cumple estos requisitos?

Para solucionar el problema, obtenga un certificado reconocido para la comunicación SSL.

¿Se ha resuelto el problema después de utilizar un certificado SSL completo?

Compruebe las siguientes configuraciones del certificado SSL.

El certificado SSL debe estar instalado en el almacén Personal del equipo local en cada servidor de federación en su conjunto. Para instalar el certificado, haga doble clic en el. Archivo PFX del certificado y siga el asistente.

Para comprobar si el certificado se instala en el lugar correcto, siga estos pasos:

  1. Lista de los certificados que se encuentran en el almacén Personal del equipo local ejecutando el comando siguiente:
    dir Cert:\LocalMachine\My

  2. Comprobar si el certificado está en la lista.

¿Se solucionó el problema?

Obtener la huella digital del certificado que se utiliza para la comunicación SSL y compruebe si la huella digital coincide con la huella digital de certificado esperado.

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

Get-AdfsSslCertificate

Si se utiliza el certificado erróneo, establecer el certificado correcto ejecutando el comando siguiente:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

¿Se solucionó el problema?

El certificado SSL debe configurarse como el certificado de comunicación del servicio en su granja de AD FS. Esto no ocurre automáticamente. Para comprobar si se ha establecido el certificado correcto, siga estos pasos:

  1. En la consola de administración de AD FS, expanda servicio > certificados.

  2. Comprobar si el certificado aparece bajo comunicaciones de servicio es el esperado.

Si aparece el certificado erróneo, establecer el certificado correcto y, a continuación, conceda que permiso de lectura para el certificado de servicio de la AD FS. Para ello, siga estos pasos:

  1. Establecer el certificado correcto:

    1. Haga clic en certificadosy, a continuación, haga clic en Establecer certificado de comunicación del servicio.

    2. Seleccionar el certificado correcto.

  2. Compruebe si el servicio de AD FS tiene permiso de lectura para el certificado:

    1. Agregue el complemento certificados para la cuenta de equipo local en Microsoft Management Console (MMC).

    2. Expanda certificados (equipo Local) > Personal > certificados.

    3. Haga clic en el certificado SSL, haga clic en Todas las tareas > Administrar claves privadas.

    4. Compruebe si adfssrv aparece bajo nombres de usuario y de grupo con el permiso de lectura .

  3. Si no aparece adfssrv, conceda que permiso de lectura para el certificado de servicio de la AD FS:

    1. Haga clic en Agregar, haga clic en ubicaciones, haga clic en el servidor y, a continuación, haga clic 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 utiliza AD FS con el servicio de registro de dispositivo (DRS), escriba service\drs de nt .

    3. Conceder el permiso de lectura y, a continuación, haga clic en Aceptar.

¿Se solucionó el problema?

¿DRS está configurado en AD FS?

Si ha configurado AD FS con DRS, asegúrese de que el certificado SSL está configurado correctamente para el objeto RDS. Por ejemplo, si hay dos contoso.com de sufijos UPN y fabrikam.com, el certificado debe tener enterpriseregistration.contoso.com y enterpriseregistration.fabrikma.com como los nombres alternativos de asunto (SAN).

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

  1. Enumerar todos los sufijos UPN que se utiliza en la organización ejecutando el comando siguiente:
    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Comprobar si el certificado SSL tiene los SANs configurado.

¿El certificado SSL tiene los nombres correctos de DRS como SANs?

Para resolver este problema, obtenga un nuevo certificado SSL que tiene la correctos SANs para DRS y utilizarlo como el certificado SSL de AD FS.

¿Se solucionó el problema?

Comprobar si se ha establecido el certificado SSL correcto 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. Obtenga el certificado SSL utiliza WAP ejecutando el comando siguiente:
    Get-WebApplicationProxySslCertificate

  3. Si el certificado SSL es incorrecto, establecer el certificado SSL correcto ejecutando el comando siguiente:
    Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Comprobar los enlaces de certificado y actualizarlos si es necesario

Para admitir casos no SNI, los administradores pueden especificar enlaces de reserva. Que no sea el estándar federationservicename:443 de enlace, busque enlaces de reserva en los identificadores de aplicación siguientes:

  • {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 el Proxy de la aplicación Web.

Por ejemplo, si se especifica el certificado SSL para un enlace de respaldo como 0.0.0.0:443, asegúrese de que el enlace se actualiza en consecuencia cuando se actualiza el certificado SSL.

¿Se solucionó el problema?

  1. En el servidor de AD FS, abra el Administrador de servidor.

  2. En el Administrador de servidor, haga clic en Herramientas > Servicios.

  3. Compruebe si el estado de Los servicios de federación de Active Directory está funcionando.

¿Se solucionó el problema?

Utilice la página IdpInititatedSignOn para comprobar rápidamente si el servicio de AD FS y de ejecución y la funcionalidad de autenticación funciona correctamente. Para abrir la página de IdpInitiatedSignOn, siga estos pasos:

  1. Habilitar la página IdpInitiatedSignOn ejecutando el comando siguiente en el servidor de AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Desde un equipo que está fuera de la red, visite la siguiente página:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. En la página de inicio de sesión, escriba las credenciales correctas de un usuario válido.

¿Es el signo de éxito?

Para solucionar el problema, compruebe los siguientes componentes y servicios.

Acceso a AD FS debe señalar directamente a uno de los servidores WAP (Proxy de aplicaciones de Web) o el equilibrador de carga delante de los servidores WAP. Realice las siguientes comprobaciones:

  • Haga ping al nombre del servicio de federación (p. ej. fs.contoso.com). Confirme si la dirección IP que se resuelve el Ping es de uno de los servidores WAP o del equilibrador de carga de los servidores WAP.

  • Comprueba si hay un registro para el servicio de federación en el servidor DNS. El registro debe señalar a uno de los servidores WAP o al equilibrador de carga de los servidores WAP.

Si WAP no está implementada en el escenario para el acceso externo, compruebe si unpuntos de ccessing AD FS directamente a uno de los servidores de AD FS o el equilibrador de carga delante de los servidores AD FS:

  • Haga ping al nombre del servicio de federación (p. ej. fs.contoso.com). Confirme si la dirección IP que se resuelve en uno de los servidores de AD FS o el equilibrador de carga de los servidores de AD FS.

  • Compruebe si hay un registro para el servicio de federación en el servidor DNS. El registro debe señalar a uno de los servidores de AD FS o al equilibrador de carga de los servidores de AD FS.

¿Se solucionó el problema?

  • Comprobar si firewall está bloqueando el tráfico entre:

    • El servidor de AD FS y el equilibrador de carga.

    • El WAP (Proxy de aplicaciones Web) server y el equilibrador de carga si se utiliza WAP.

  • Si está habilitado el sondeo en el equilibrador de carga, compruebe lo siguiente:

    • Si está ejecutando Windows Server R2 de 2012, asegúrese de que el Paquete acumulativo de agosto de 2014 está instalado.

    • Comprobar si el puerto 80 está habilitado en el servidor de seguridad en el servidor WAP y los servidores de AD FS.

    • Asegúrese de que dicho sondeo se establece para el puerto 80 y el /adfs/probe de extremo.

¿Se solucionó el problema?

  1. Compruebe si está habilitado el tráfico entrante a través del puerto TCP 443 en:

    • tél firewall entre el servidor Proxy de la aplicación Web y el conjunto de servidores de federación.

    • el servidor de seguridad entre los clientes y el servidor Proxy de la aplicación Web.

  2. Compruebe si el tráfico entrante a través del puerto TCP 49443 está habilitado en el servidor de seguridad entre los clientes y el servidor Proxy de la aplicación Web cuando se cumplen las condiciones siguientes:

    • Está habilitada la autenticación de cliente TLS con certificados X.509.

    • Utiliza AD FS en Windows Server R2 de 2012.

      Nota: No es necesaria la configuración del servidor de seguridad entre el servidor Proxy de la aplicación Web y los servidores de federación.

¿Se solucionó el problema?

 

¿Se solucionó el problema?

AD FS proporciona varios extremos para escenarios y funcionalidades diferentes. No todos los extremos están habilitados de forma predeterminada. Para comprobar si el extremo está habilitado en el servidor proxy, siga estos pasos:

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

  2. Expanda el servicio > extremos.

  3. Localice el extremo y compruebe si el estado está habilitado en la columna Proxy habilitado .
    ADFS endpoints proxy status

 

¿Se solucionó el problema?

Nota: Información en esta página se aplica a AD FS 2012 R2 y versiones posteriores.

Si se implementa el Proxy de aplicación Web (WAP), 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 de proxy está establecida o empieza a fallar en algún momento en el tiempo.

Información general

La relación de confianza de proxy está basado el certificado de cliente. Al ejecutar el Asistente para después de la instalación de Proxy de aplicación Web, el asistente genera un certificado autofirmado cliente con las credenciales especificadas 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 las comunicaciones SSL, http.sys utiliza el siguiente orden de prioridad para enlaces de certificado SSL para que coincida con un certificado:

Prioridad

Nombre

Parámetros

Descripción

1

IP

IP:port

Coincidencia exacta IP y puerto

2

SNI

Hostname:port

Coincidencia exacta del nombre de host (conexión debe especificar SNI)

3

CCS

Puerto

Almacén de certificados de la Central de invocación

4

Comodín de IPv6

Puerto

Coincidencia de caracteres comodín de IPv6 (conexión debe ser IPv6)

5

Comodín IP

Puerto

Coincidencia de caracteres comodín IP (la conexión puede ser IPv4 o IPv6)

AD FS 2012 R2 y posterior son independientes de los servicios de Internet Information Server (IIS) y se ejecuta como un servicio en la parte superior http.sys. enlaces de certificado SSL hostname: Port son usados por 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 en el 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 está AdfsTrustedDevices, no se podrán establecer relaciones de confianza de proxy.

Obtener los enlaces de certificado SSL de 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 aquellas con el identificador de aplicación de 5d89a20c-beab-4389-9447-324788eb944a. Aquí es un ejemplo de un enlace saludable. Tenga en cuenta los elementos en negrita.

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

Solución de problemas

Para detectar automáticamente los problemas con la relación de confianza de proxy, ejecute el siguiente script. Según el problema detectado, actuar en consecuencia al final de la página.

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.")

¿Cuál es el problema detectado?

El enlace de IP: Port tiene la máxima prioridad. Si un enlace IP: Port es en los enlaces de certificado SSL de AD FS, http.sys siempre utiliza el certificado para el enlace para la comunicación SSL. Para resolver este problema, utilice los métodos siguientes.

Método 1: Quitar el enlace de IP: Port

Tenga en cuenta que el enlace de IP: Port puede venir después de que lo quitó. Por ejemplo, una aplicación configurada con este enlace IP: Port automáticamente puede recrear en el siguiente inicio del servicio.

Método 2: Utilizar otra dirección IP para la comunicación SSL de AD FS

Si el enlace de IP: Port es necesario, puede resolver el FQDN del servicio de ADFS a otra dirección IP que no se utiliza en los enlaces. De este modo, http.sys utilice el enlace nombrehost: puerto para la comunicación SSL.

Método 3: Conjunto AdfsTrustedDevices como almacén de CTL para el enlace de IP: Port

Éste es el último recurso si no puede utilizar los métodos anteriores. Pero es aconsejable comprender las siguientes condiciones antes de cambiar el valor predeterminado almacenar CTL a AdfsTrustedDevices:

  • Enlace IP: ¿por qué el puerto existe.

  • Si el enlace se basa en el valor predeterminado almacenar CTL para la autenticación de certificado de cliente.

¿Se solucionó el problema?

Si está instalado Azure Connect de AD, utilice DAA conectar para establecer el nombre del almacén de CTL en AdfsTrustedDevices para los enlaces de certificado SSL en todos los servidores de AD FS. Si Azure Connect de AD no está instalado, vuelva a generar los enlaces de certificado AD FS ejecutando el comando siguiente en todos los servidores de AD FS.
Set-AdfsSslCertificate -Thumbprint Thumbprint

¿Se solucionó el problema?

Si es una entidad de certificación que emitió el certificado en un almacén de certificados donde normalmente existiría sólo los certificados autofirmados, la CTL generado desde el almacén sólo contendría la CA que emitió el certificado. El almacén de certificados AdfsTrustedDevices es tal un almacén que se supone que contiene sólo los certificados autofirmados. Estos certificados son:

  • MS Access organización: El certificado autofirmado utilizado para emitir certificados de combinación de lugar de trabajo.

  • Proxy ADFS de confianza: Los certificados para cada servidor Proxy de la aplicación Web.

AdfsTrustedDevices certificates

Por tanto, puede eliminar cualquier certificado de entidad emisora de certificados emitidos desde el almacén de certificados AdfsTrustedDevices.

¿Se solucionó el problema?

Cuando se establece una relación de confianza de proxy con un servidor de AD FS, el certificado de cliente se escriben en la base de datos de configuración de AD FS y agregado al almacén de certificados AdfsTrustedDevices en el servidor de AD FS. Para una implementación de granja de servidores de AD FS, se espera el certificado de cliente para sincronizar con los demás servidores de AD FS. Si la sincronización no sucede por alguna razón, una relación de confianza de proxy sólo funcionará en el servidor de AD FS con que se ha establecido la confianza, pero no contra los demás servidores de AD FS.

Para resolver este problema, utilice uno de los métodos siguientes.

Método 1

En todos los servidores de AD FS, instale la actualización que se documenta en KB 2964735 . Después de instalar la actualización, se espera que una sincronización de certificado de cliente se producen automáticamente.

Método 2

Ejecute el script con el syncproxytrustcerts modificador – sincronizar manualmente los certificados de cliente desde la base de datos de configuración de AD FS para el almacén de certificados AdfsTrustedDevices. La secuencia de comandos debe ejecutarse en todos los servidores de AD FS en la granja.

Tenga en cuenta que esto no es una solución permanente porque los certificados de cliente se renueva de forma regular.

¿Se solucionó el problema?

Compruebe si hay un desajuste de hora o la zona horaria. Si coincide con tiempo pero el tiempo no zona, relación de confianza de proxy también fallará a establecerse.

¿Se solucionó el problema?

Si ocurre terminación SSL en un dispositivo de red entre servidores de AD FS y el servidor WAP, comunicación entre AD FS y WAP interrumpirá porque la comunicación se basa en el certificado de cliente.

Deshabilitar la terminación SSL en el dispositivo de red entre los servidores AD FS y WAP.

¿Se solucionó el problema?

Compruebe la configuración de la autenticación integrada de Windows en el explorador del cliente, la configuración de AD FS y parámetros de la solicitud de autenticación.

Compruebe el explorador del cliente del usuario

Comprobar la configuración en Opciones de Internet siguiente:

  • En la ficha Avanzadas , asegúrese de que está habilitada la opción de Habilitar la autenticación integrada de Windows .

  • Después de seguridad > intranet Local > sitios > Opciones avanzadas, asegúrese de que la URL de AD FS está en la lista de sitios Web.

  • Siguiente seguridad > intranet Local > Nivel personalizado, asegúrese de que está activada la opción de Inicio de sesión automático sólo en la zona de Intranet .

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

Compruebe la configuración de AD FS

Compruebe la configuración de WindowsIntegratedFallback

  1. Abrir Windows PowerShell con la ejecución como opción de administrador.

  2. Para obtener la directiva de autenticación global, ejecutando el siguiente comando:
    Get-ADFSGlobalAuthenticationPolicy

  3. Examine el valor del atributo WindowsIntegratedFallbackEnbaled.

Se espera que Si el valor es True, 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. Vea la siguiente sección acerca de cómo obtener el explorador compatible.

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

Compruebe la configuración de WIASupportedUsersAgents

  1. Obtener la lista de agentes de usuario admitido por ejecutando el comando siguiente:
    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  2. Examine la lista de cadenas de agente de usuario que devuelve el comando.

Compruebe si la cadena de agente de usuario del explorador en la lista. Si no es así, agregue la cadena de agente de usuario siguiendo los siguientes pasos:

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

  2. Obtener la lista de agentes de usuario admitido por ejecutando el comando siguiente:
    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  3. Agregue la cadena de agente de usuario del explorador ejecutando el comando siguiente:
    $wiaStrings = $wiaStrings+"NewUAString"
    Ejemplo:$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

  4. Actualizar la configuración de WIASupportedUserAgents ejecutando el comando siguiente:
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Compruebe los parámetros de la 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 un solicitud de WS-Federation, compruebe si la solicitud incluye wauth = urn: oasis: nombres: tc: SAML:1.0:am:password.

  2. Si la solicitud de autenticación es una solicitud SAML, compruebe si la solicitud incluye un samlp:AuthnContextClassRef elemento con el valor urn: oasis: nombres: tc: SAML:2.0:ac:classes:Password.

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

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

Si la aplicación que desea tener acceso no es de Microsoft Online Services, se espera que lo experimenta y controlado por la solicitud de autenticación entrantes . Trabajar con el propietario de la aplicación para cambiar el comportamiento.

Si la aplicación de Microsoft Online Services, lo que experimenta puede ser controlada por el PromptLoginBehavior la configuración del objeto de confianza de territorio. Esta configuración controla si los inquilinos AD Azure envían prompt = inicio de sesión en AD FS. Para establecer el PromptLoginBehavior configuraciónsiga estos pasos:

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

  2. Para obtener la configuración de la federación de dominio existente, ejecutando el siguiente comando:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  3. Establezca la configuración de PromptLoginBehavior ejecutando el comando siguiente:
    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

    Los valores para el parámetro PromptLoginBehavior son:

    1. TranslateToFreshPasswordAuth: AD Azure envía AD FS en lugar del símbolo del sistema wauth y wfresh = inicio de sesión. Esto conduce a una la solicitud de autenticación que utilice la autenticación basada en formularios.

    2. NativeSupport: el parámetro de inicio de sesión = símbolo del sistema se envía como consiste en AD FS.

    3. Deshabilitado: nada se envía a AD FS.

Para obtener más información acerca del comando Set-MSOLDomainFederationSettings, consulte solicitar los servicios de federación de Active Directory = la compatibilidad de parámetros de inicio de sesión.

¿Se solucionó el problema?

Autenticación con varios factores puede ser habilitada en un servidor de AD FS en un usuario de confianza, o especificada en un parámetro de la solicitud de autenticación. Compruebe las configuraciones para ver si están correctamente establecidas. Si la autenticación multifactor está esperada, pero se're piden repetidamente, compruebe las normas de emisión partido confiar para ver si las solicitudes de autenticación con varios factores se pasan a la aplicación.

Para obtener más información acerca de la autenticación multifactor en AD FS, consulte los artículos siguientes:

Compruebe 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, validar las reglas globales de autenticación adicionales. Para comprobar la configuración en el usuario de confianza, validar las reglas de autenticación adicionales para la confianza de fabricantes 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 devuelven nothing, no se configuran las reglas de autenticación adicionales. Omitir esta sección.

  2. Observe que la regla de notificación configurado.

Compruebe si está habilitada la autenticación con varios factores en el conjunto de reglas de notificación

Un conjunto de reglas de notificación se compone de las siguientes secciones:

  • La instrucción condicional:C:[Type=…,Value=…]

  • La instrucción de problema:=> issue (Type=…,Value=…)

Si la instrucción del asunto contiene la siguiente afirmación, se especifica la autenticación con varios factores.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Éstos son ejemplos que requieren la autenticación con varios factores que se utilizará para dispositivos combinados no-workplace y acceso a la 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")

Compruebe las reglas de emisión partido confianza

Si el usuario recibe repetidamente mensajes de autenticación con varios factores después realizan la primera autenticación, es posible que la parte de la respuesta no pasa a través de las solicitudes de autenticación con varios factores a la aplicación. Para comprobar si se pasan las solicitudes de autenticación, siga estos pasos:

  1. Ejecute el siguiente comando en Windows PowerShell:
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp

  2. Observe que la regla establece 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 solicitudes de autenticación con varios factores:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Compruebe el parámetro de la solicitud de autenticación

Compruebe si la solicitud de autenticación especifica la autenticación de varios factor como el método de autenticación

  • Si la solicitud de autenticación es un 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 samlp:AuthnContextClassRef elemento con el valor http://schemas.microsoft.com/claims/multipleauthn.

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

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

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

  1. Para obtener la configuración actual de federación del dominio SupportsMFA, ejecutando el siguiente comando:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  2. Si el valor de SupportsMFA es FALSE, establezca en TRUE ejecutando el comando siguiente:
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

¿Se solucionó el problema?

Deshabilitar la capacidad de inicio de sesión = símbolo del sistema ejecutando el comando siguiente:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

¿Se solucionó el problema?

Modificar el parámetro de solicitud para utilizar el método de autenticación esperado.

¿Se solucionó el problema?

Si SSO está deshabilitado, habilítelo.

¿Se solucionó el problema?

¡Felicidades! Se ha resuelto el problema SSO.

Sentimos que el problema persiste. Le agradecería que rellene la encuesta con los detalles de su problema.

¿Cómo funciona esta guía?

Resuelve de sesión único (SSO) problemas con los servicios de federación de Active Directory (AD FS).

¿Quiénes está destinado?

Los administradores que ayudan a diagnostican problemas de SSO para sus usuarios.

¿Cómo funciona?

Vamos a empezar pidiendo el problema que se enfrentan los usuarios. Después veremos a través de una serie de pasos que son específicos a su situación.

Tiempo estimado de finalización:

30 y 45 minutos.

¿Necesita más ayuda?

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Unirse a Microsoft Insider

¿Le ha sido útil esta información?

¿Cuál es tu grado de satisfacción con la calidad del lenguaje?
¿Qué ha afectado a tu experiencia?

¡Gracias por sus comentarios!

×