Troubleshoot single sign-on (SSO) issues with Active Directory Federation Services (AD FS)

Applies to: Windows Server 2016 StandardWindows Server 2012 DatacenterWindows Server 2012 Standard More

What does this guide do?

Resolves single sign-on (SSO) issues with Active Directory Federation Services (AD FS).

Who is it for?

Administrators who help diagnose SSO issues for their users.

How does it work?

We’ll begin by asking you the issue your users are facing. Then we’ll take you through a series of troubleshooting steps that are specific to your situation.

Estimated time of completion:

30-45 minutes.

What issue does the user encounter with SSO?

What issue does the user encounter with SSO?

This issue can occur at the AD FS sign-in page or at the application side.

If the issue occurs at the AD FS sign-in page, you receive an "An error occurred", "HTTP 503 Service is unavailable” or some other error message. The URL of the error page shows the AD FS service name such as fs.contoso.com.

If the issue occurs at the application side, the URL of the error page shows the IP address or the site name of the target service.

Where do you encounter this issue?

Does this issue impact all the users?

Can the user access any of the relying parties?

Does this issue occur in an Azure AD scenario?

Can the user access any of the relying parties?

If the token signing certificate was renewed recently by AD FS, check if the new certificate is picked up by the federation partner. In case AD FS uses a token decrypting certificate that was also renewed recently, do the same check as well. To check if the current AD FS token signing certificate on AD FS matches the one on the federation partner, follow these steps:

  1. Get the current token signing certificate on AD FS by running the following command:
    Get-ADFSCertificate -CertificateType token-signing
  2. In the list of certificates returned, find the one with IsPrimary = TRUE, and make a note of the thumbprint.
  3. Get the thumbprint of the current token signing certificate on the federation partner. The application owner needs to provide you this.
  4. Compare the thumbprints of the two certificates.

Do the same check if AD FS uses a renewed token decrypting certificate, except that the command to get the token decrypting certificate on AD FS is as follows:
Get-ADFSCertificate -CertificateType token-decrypting

Do the thumbprints match?

To check if there is a mismatch, follow these steps:

  1. Determine the algorithm used by the relying party by running the following command:Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    The possible values are SHA1 or SHA256.
  2. Check with the application owner for the algorithm used on the application side.
  3. Check if the two algorithms match.

Does a mismatch exist?

Does the user get an unexpected NTLM prompt or a forms-based authentication prompt?

Does the user get an unexpected prompt for multi-factor authentication? Or does the user repeatedly get the prompt?

Does this issue occur in an Azure AD scenario?

Does the authentication request sent to Azure AD include the prompt=login parameter?

Request parameters like WAUTH and RequestedAuthNContext in authentication requests can have authentication methods specified. Is the request parameter enforcing the unexpected authentication prompt?

Use the following methods for troubleshooting.

Check the user status in Windows PowerShell or the UI. If the user is disabled, enable the user.

Check the user status with Windows PowerShell

  1. Log in to any of the domain controllers.
  2. Open Windows PowerShell.
  3. Check the user status by running the following command:
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Check the user status in the UI

  1. Log in to any of the domain controllers.
  2. Open the Active Directory Users and Computers management console.
  3. Click the Users node, right-click the user in the right pane, and then click Properties.
  4. Click the Account tab.
  5. Under Account options, verify if Account is disabled is checked.
    The
  6. If the option is checked, uncheck it.

Is the problem solved?

If any property of the user is updated in the Active Directory, it results in a change in the metadata of the user object. Check the user metadata object to see which properties were updated recently. If changes are found, make sure that they are picked up by the related services. To check if there were property changes to a user, following these steps:

  1. Log in to a domain controller.
  2. Open Windows PowerShell.
  3. Get the metadata of the user object by running the following command:
    repadmin /showobjmeta <destination DC> "user DN"

    An example of the command is:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"
  4. In the metadata, examine the Time/Date column for each attribute for any clue to a change. In the following example, the userPrincipleName attribute takes a newer date than the other attributes which represents a change to the user object metadata.
    repadmin show user metadata

Is the problem solved?

In a multi-forest AD FS environment, a two-way forest trust is required between the forest where AD FS is deployed and the other forests which utilize the AD FS deployment for authentication. To verify if the trust between the forests is working as expected, follow these steps:

  1. Log in to a domain controller in the forest where AD FS is deployed.
  2. Open the Active Directory Domains and Trusts management console.
  3. In the management console, right-click the domain that contains the trust that you want to verify, and then click Properties.
  4. Click the Trusts tab.
  5. Under Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be verified, and then click Properties.
  6. Click Validate.
    In the Active Directory Domain Services dialog box, select either of the options.
    • If you select No, we recommend that you repeat the same procedure for the reciprocal domain.
    • If you select Yes, provide an administrative user credential for the reciprocal domain. There is no need to perform the same procedure for the reciprocal domain.

Active Directory Domain Services

  • Is the problem solved?

The Dump Token app is helpful when debugging problems with your federation service as well as validating custom claim rules. It is not an official solution but a good independent debugging solution that is recommended for the troubleshooting purposes.

Now continue with the following troubleshooting methods. At the end of each method, see if the problem is solved. If not, use another method.

In this method, you start by getting the policy details, and then use the Dump Token app to diagnose the policy to see if the user is impacted.

Get the policy details

$rp.IssuanceAuthorizationRules shows the authorization rules of the relying party.

In Windows Server 2016 and later versions, you can use $rp. AccessControlPolicyName to configure authentication and authorization policy. If $rp. AccessControlPolicyName has value, an access control policy is in place which governs the authorization policy. In that case, $rp.IssuanceAuthorizationRules is empty. Use $rp.ResultantPolicy to find out details about the access control policy.

If $rp.ResultantPolicy doesn’t have the details about the policy, look into the actual claim rules. To get the claim rules, follow these steps:

  1. Set the access control policy to $null by running the following command:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. Get the relying party information by running the following command:
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. Check $rp.IssuanceAuthorizationRules and $rp. AdditionalAuthenticationRules.

Use the Dump Token app to diagnose the authorization policy

  1. Set the Dump Token authentication policy to be the same as the failing relying party.
  2. Have the user open one of the following links depending on the authentication policy you set.
    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Force multi-factor authentication: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Log in on the Sign-In page.

What you get is the set of claims of the user. See if there is anything in the authorization policy that explicitly denies or allows the user based on these claims.

Is the problem solved?

  1. Configure the claim rules in the Dump Token app to be the same as the claim rules of the failing relying party.
  2. Configure the Dump Token authentication policy to be the same as the failing relying party.
  3. Have the user open one of the following links depending on the authentication policy you set.
    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Force multi-factor authentication: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Log in on the Sign-In page.

This is the set of claims the relying party is going to get for the user. If any claims are missing or unexpected, look at the issuance policy to find out the reason.

If all the claims are present, check with the application owner to see which claim is missing or unexpected.

Is the problem solved?

If the authorization rules check for device claims, verify if any of these device claims are missing in the list of claims you get from the Dump Token app. The missing claims could block device authentication. To get the claims from the Dump Token app, follow the steps in the Use the Dump Token app to diagnose the authorization policy section in the Check authorization policy if the user was impacted method.

The following are the device claims. The authorization rules may use some of them.

  • 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

If there is a missing claim, follow the steps in Configure On-Premises Conditional Access using registered devices to make sure the environment is setup for device authentication.

If all the claims are present, see if the values of the claims from the Dump Token app match the values required in the authorization policy.

Is the problem solved?

Use the following methods for troubleshooting. At the end of each method, see if the problem is solved. If not, use another method.

Continue with the troubleshooting to check potential issues with the relying party.

If a user is trying to log in to Azure AD, they will be redirected to AD FS for authentication for a federated domain. One of the possible reasons for a failed login is that the user is not yet synced to Azure AD. You might see a loop from Azure AD to AD FS after the first authentication attempt at AD FS. To determine whether the user is synced to Azure AD, follow these steps:

  1. Download and install the Azure AD PowerShell module for Windows PowerShell.
  2. Open Windows PowerShell with the "Run as administrator" option.
  3. Initiate a connection to Azure AD by running the following command:
    Connect-MsolService
  4. Provide the global administrator credential for the connection.
  5. Get the list of users in the Azure AD by running the following command:
    Get-MsolUser
  6. Verify if the user is in the list.

If the user is not in the list, sync the user to Azure AD.

Is the problem solved?

Azure AD requires immutableID and the user’s UPN to authenticate the user.

Note immutableID is also called sourceAnchor in the following tools:

  • Azure AD Sync
  • Azure Active Directory Sync (DirSync)

Administrators can use Azure AD Connect for automatic management of AD FS trust with Azure AD. If you are not managing the trust via Azure AD Connect, we recommend that you do so by downloading Azure AD Connect. Azure AD Connect enables automatic claim rules management based on sync settings.

To check if the claim rules for immutableID and UPN in AD FS matches what Azure AD uses, follow these steps:

  1. Get sourceAnchor and UPN in Azure AD Connect.
    1. Open Azure AD Connect.
    2. Click View current configuration.
      Azure AD Connect -View current configuration
    3. On the Review Your Solution page, make a note of the values of SOURCE ANCHOR and USER PRINCIPAL NAME.
      Azure AD Connect -Review your solution
  2. Verify the values of immutableID (sourceAnchor) and UPN in the corresponding claim rule configured in the AD FS server.

    1. On the AD FS server, open the AD FS management console.

    2. Click Relying Party Trusts.

    3. Right-click the relying party trust with Azure AD, and then click Edit Claim Issuance Policy.

    4. Open the claim rule for immutable ID and UPN.

    5. Verify if the variables queried for values of immutableID and UPN are the same as those appear in Azure AD Connect.

      Issue UPN and ImmutableID

    6. If there is a difference, use one of the methods below:

      • If AD FS is managed by Azure AD Connect, reset the relying party trust by using Azure AD Connect.

      • If AD FS is not managed by Azure AD Connect, correct the claims with the right attributes.
         

Is the problem solved?

The information will be used in the subsequent troubleshooting steps.

Now continue with the following troubleshooting methods.

Continue with additional checks on the relying party.

The relying party identifier, client ID and redirect URI should be provided by the owner of the application and the client. However, there could still be a mismatch between what the owner provides and what are configured in AD FS. For example, a mismatch could be caused by a typo. Check if the settings provided by the owner match those configured in AD FS. The steps in the previous page get you the settings configured in AD FS via PowerShell.

Settings provided by the owner Settings configured in AD FS
Relying party ID $rp.Identifier
Relying party redirect URI

A prefix or wildcard match of

  • $rp.WSFedEndpoint for a WS-Fed relying party
  • $rp.SamlEndpoints for a SAML relying party
Client ID $client.ClientId
Client redirect URI A prefix match of $client.RedirectUri

If items in the table matches, additionally check if these settings match between what they appear in the authentication request sent to AD FS and what are configured in AD FS. Try reproducing the issue during which you capture a Fiddler trace on the authentication request sent by the application to AD FS. Examine the request parameters to do the following checks depending on the request type.

OAuth requests

An OAuth request looks like the following:

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

Check if the request parameters match the settings configured in AD FS.

Request parameters Settings configured in AD FS
client_id $client.ClientId
redirect_uri A prefix match of @client_RedirectUri

The "resource" parameter should represent a valid relying party in AD FS. Get the relying party information by running one of the following commands.

  • If you use a conventional relying party, run the following command:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
  • If you use the Application Group feature in Windows Server 2016, run the following command:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed requests

A WS-Fed request looks like the following:

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

Check if the request parameters match the settings configured in AD FS:

Request parameters Settings configured in AD FS
wtrealm $rp.Identifier
wreply A prefix match or wildcard match of $rp.WSFedEndpoint

SAML requests

A SAML request looks like the following:

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

Decode the value of the SAMLRequest parameter by using the "From DeflatedSAML" option in the Fiddler Text Wizard. The decoded value looks like the following:

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

Do the following checks within the decoded value:

  • Check if the host name in the value of Destination matches the AD FS host name.
  • Check if the value of Issuer matches $rp.Identifier.

Additional notes for SAML

  • $rp.SamlEndpoints: Shows all types of SAML endpoints. The response from AD FS is sent to the corresponding URLs configured in the endpoints. A SAML endpoint can use redirect, post or artifact bindings for message transmission. All these URLs can be configured in AD FS.
  • $rp.SignedSamlRequestsRequired: If the value is set, the SAML request sent from the relying party needs to be signed. The "SigAlg" and "Signature" parameters need to be present in the request.
  • $rp.RequestSigningCertificate: This is the signing certificate used to generate the signature on the SAML request. Make sure that the certificate is valid and ask the application owner to match the certificate.

Is the problem solved?

If $rp.EncryptClaims returns "Enabled", relying party encryption is enabled. AD FS uses the encryption certificate to encrypt the claims. Do the following checks:

  • $rp.EncryptionCertificate: Use this command to get the certificate and check if it is valid.
  • $rp. EncryptionCertificateRevocationCheck: Use this command to check if the certificate meets the revocation check requirements.

Is the problem solved?

If there are certificate mismatches, ensure that the partners are using the new certificates. Certificates are included in the federation metadata published by the AD FS server.

Note The partners refer to all your resource organization or account organization partners, represented in your AD FS by relying party trusts and claims provider trusts.

The partners can access the federation metadata

If the partners can access the federation metadata, ask the partners to use the new certificates.

The partners can’t access the federation metadata

In this case, you must manually send the partners the public keys of the new certificates. To do this, follow these steps:

  1. Export the public keys as .cert files, or as .p7b files to include the entire certificate chains.
  2. Send the public keys to the partners.
  3. Ask the partners to use the new certificates.

Is the problem solved?

  1. Open the AD FS management console.
  2. Right-click the relying party trust, and then click Properties.
  3. On the Advanced tab, select the algorithm to match what the application requires.
    Relying party trust-Hash algorithm

Is the problem solved?

  1. On the AD FS server, dump the issuance transform rules by running the following command:
    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
  2. Locate the rule that issues the NameIdentifier claim. If such a rule doesn’t exist, skip this step.
    Here is an example of the rule:

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

    Notice the NameIdentifier format in the following syntax:
    Properties["Property-type-URI"] = "ValueURI"

    The possible formats are listed below. The first format is the default.
    • 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. Ask the application owner for the NameIdentifier format required by the application.
  4. Verify if the two NameIdentifier formats match.
  5. If the formats don’t match, configure the NameIdentifier claim to use the format that the application requires. To do this, follow these steps:
    1. Open the AD FS management console.
    2. Click Relying Party Trusts, select the appropriate federation partner, and then click Edit Claims Issuance Policy in the Actions pane.
    3. Add a new rule if there is no rule to issue the NameIdentifier claim, or update an existing rule. Select Name ID for Incoming claim type, and then specify the format that the application requires.
      Configure claim rule

Is the problem solved?

Note: You can also use Fiddler to troubleshoot the problem. The idea is the same.

The Dump Token app is helpful when debugging problems with your federation service as well as validating custom claim rules. It is not an official solution but a good independent debugging solution that is recommended for the troubleshooting purposes. To use the Dump Token app, follow these steps:

  1. Set up the Dump Token app by running the following commands:
    $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. Replicate the failing relying party configuration by copy the issuance rules from the relying party to DumpToken. To do this, run the following command:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules
  3. Have the user open one of the following links depending on the authentication policy you set.
    • WS-Fed: https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML: https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Force multi-factor authentication: https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Get the claims by having the user log in on the authentication page.
  5. In the Dump Token output, expand the Raw Token XML section, and then review the Attribute statement by checking the following strings to see if they match what is configured in the claim issuance policy:
    • saml:NameIdentifier: This shows the NameIdentifier format.
    • saml:AttributeStatement: This shows each claim type/value pair for the token.
    • saml:AuthenticationStatement: This shows the authentication method and authentication instant.

Is the problem solved?

Use the IdpInititatedSignOn page to verify if the AD FS service is up and running and the authentication functionality is working correctly. To open the IdpInitiatedSignOn page, follow these steps:

  1. Enable the IdpInitiatedSignOn page by running the following command on the AD FS server:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
  2. From a computer that is inside your network, visit the following page:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx
  3. Enter the correct credentials of a valid user on the sign-in page.

Is the sign-in successful?

To troubleshoot the issue, check the following components and services.

Continue troubleshooting to check the SSL certificate.

Accessing AD FS should point directly to one of the AD FS servers or the load balancer in front of the AD FS servers. Do the following checks:

  • Ping the federation service name (e.g. fs.contoso.com). Confirm if the IP address that you get resolves to one of the AD FS servers or the load balancer of the AD FS servers.
  • Check if there is an A record for the federation service in the DNS server. The A record should point to one of the AD FS servers or to the load balancer of the AD FS servers.

Is the problem solved?

  • Check if firewall is blocking traffic between:
    • The AD FS server and the load balancer.
    • The WAP (Web Application Proxy) server and the load balancer if WAP is used.
  • If probe is enabled on the load balancer, check the following:
    • If you are running Windows Server 2012 R2, ensure that the August 2014 update rollup is installed.
    • Check if port 80 is enabled in the firewall on the WAP servers and AD FS servers.
    • Ensure that probe is set for port 80 and for the endpoint /adfs/probe.

Is the problem solved?

  1. On the AD FS server, open Server Manager.
  2. In the Server Manager, click Tools > Services.
  3. Check if the Status of Active Directory Federation Services is Running.

Is the problem solved?

AD FS provides various endpoints for different functionalities and scenarios. Not all endpoints are enabled by default. To check the status of the endpoints, following these steps:

  1. On the AD FS server, open the AD FS Management Console.
  2. Expand Service > Endpoints.
  3. Locate the endpoints and verify if the statuses are enabled on the Enabled column.
    ADFS Endpoints status

Is the problem solved?

We recommend that you use Azure AD Connect which makes SSL certificate management easier.

Is Azure AD Connect installed in your environment?

If Azure AD Connect is installed, ensure that you use it to manage and update SSL certificates.

Is the problem solved?

The SSL certificate must meet the following requirements:

  • The certificate is from a trusted root certification authority.
    AD FS requires that SSL certificates are from a trusted root certification authority. If AD FS is accessed from non-domain joined computers, we recommend that you use an SSL certificate from a trusted third-party root certification authority like DigiCert, VeriSign, etc. If the SSL certificate is not from a trusted root certification authority, SSL communication can break.
  • The subject name of the certificate is valid.
    The subject name should match the federation service name, not the AD FS server name or some other name. To get the federation service name, run the following command on the primary AD FS server:

    Get-AdfsProperties | select hostname
  • The certificate is not revoked.
    Check for certificate revocation. If the certificate is revoked, SSL connection can’t be trusted and will be blocked by clients.

Does the SSL certificate meet these requirements?

To solve your problem, get a qualified certificate for SSL communication.

Is the problem solved after you use a qualified SSL certificate?

Check the following configurations of the SSL certificate.

The SSL certificate should be installed to the Personal store for the local computer on each federation server in your farm. To install the certificate, double click the .PFX file of the certificate and follow the wizard.

To verify if the certificate is installed to the correct place, follow these steps:

  1. List the certificates that are in the Personal store for the local computer by running the following command:
    dir Cert:\LocalMachine\My
  2. Check if the certificate is in the list.

Is the problem solved?

Get the thumbprint of the certificate that is in use for SSL communication and verify if the thumbprint matches the expected certificate thumbprint.

To get the thumbprint of the certificate that is in use, run the following command in Windows PowerShell:

Get-AdfsSslCertificate

If the wrong certificate is used, set the correct certificate by running the following command:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Is the problem solved?

The SSL certificate needs to be set as the service communication certificate in your AD FS farm. This does not happen automatically. To check if the correct certificate is set, follow these steps:

  1. In the AD FS Management Console, expand Service > Certificates.
  2. Verify if the certificate listed under Service communications is the expected certificate.

If the wrong certificate is listed, set the correct certificate, and then grant the AD FS service the Read permission to the certificate. To do this, follow these steps:

  1. Set the correct certificate:
    1. Right-click Certificates, and then click Set Service Communication Certificate.
    2. Select the correct certificate.
  2. Verify if the AD FS service has the Read permission to the certificate:
    1. Add the Certificates snap-in for the local computer account to the Microsoft Management Console (MMC).
    2. Expand Certificates (Local Computer) > Personal > Certificates.
    3. Right-click the SSL certificate, click All Tasks > Manage Private Keys.
    4. Verify if adfssrv is listed under Group and user names with the Read permission.
  3. If adfssrv is not listed, grant the AD FS service the Read permission to the certificate:
    1. Click Add, click Locations, click the server, and then click OK.
    2. Under Enter the object names to select, enter nt service\adfssrv, click Check Names, and then click OK.
      If you are using AD FS with Device Registration Service (DRS), enter nt service\drs instead.
    3. Grant the Read permission, and then click OK.

Is the problem solved?

Is DRS configured in AD FS?

If you’ve configured AD FS with DRS, make sure that the SSL certificate is also properly configured for RDS. For example, if there are two UPN suffixes contoso.com and fabrikam.com, the certificate must have enterpriseregistration.contoso.com and enterpriseregistration.fabrikma.com as the Subject Alternative Names (SANs).

To check if the SSL certificate has the correct SANs, follow these steps:

  1. List all the UPN suffixes being used in the organization by running the following command:
    Get-AdfsDeviceRegistratrionUpnSuffix
  2. Verify if the SSL certificate has the required SANs configured.

Does the SSL certificate have the correct DRS names as SANs?

To solve this issue, get a new SSL certificate that has the correct SANs for DRS, and then use it as the SSL certificate for AD FS.

Is the problem solved?

Check if the correct SSL certificate is set on all WAP servers

  1. Make sure that the SSL certificate is installed in the Personal store for the local computer on each WAP server.
  2. Get the SSL certificate used by WAP by running the following command:
    Get-WebApplicationProxySslCertificate
  3. If the SSL certificate is wrong, set the correct SSL certificate by running the following command:
    Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Check the certificate bindings and update them if necessary

To support non-SNI cases, administrators may specify fallback bindings. Other than the standard federationservicename:443 binding, look for fallback bindings under the following application IDs:

  • {5d89a20c-beab-4389-9447-324788eb944a}
    This is the application ID for AD FS.
  • {f955c070-e044-456c-ac00-e9e4275b3f04}
    This is the application ID for Web Application Proxy.

For example, if the SSL certificate is specified for a fallback binding like 0.0.0.0:443, make sure that the binding is updated accordingly when the SSL certificate gets updated.

Is the problem solved?

  1. On the AD FS server, open Server Manager.
  2. In the Server Manager, click Tools > Services.
  3. Check if the Status of Active Directory Federation Services is Running.

Is the problem solved?

Use the IdpInititatedSignOn page to quickly verify if the AD FS service is up and running and the authentication functionality is working correctly. To open the IdpInitiatedSignOn page, follow these steps:

  1. Enable the IdpInitiatedSignOn page by running the following command on the AD FS server:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
  2. From a computer that is outside of your network, visit the following page:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx
  3. Enter the correct credentials of a valid user on the sign-in page.

Is the sign-in successful?

To troubleshoot the issue, check the following components and services.

Continue troubleshooting to check the proxy trust relationship between Web Application Proxy and AD FS.

Accessing AD FS should point directly to one of the WAP (Web Application Proxy) servers or the load balancer in front of the WAP servers. Do the following checks:

  • Ping the federation service name (e.g. fs.contoso.com). Confirm if the IP address the Ping resolves to is of one of the WAP servers or of the load balancer of the WAP servers.
  • Check if there is an A record for the federation service in the DNS server. The A record should point to one of the WAP servers or to the load balancer of the WAP servers.

If WAP is not implemented in your scenario for external access, check if accessing AD FS points directly to one of the AD FS servers or the load balancer in front of the AD FS servers:

  • Ping the federation service name (e.g. fs.contoso.com). Confirm if the IP address that you get resolves to one of the AD FS servers or the load balancer of the AD FS servers.
  • Check if there is an A record for the federation service in the DNS server. The A record should point to one of the AD FS servers or to the load balancer of the AD FS servers.

Is the problem solved?

  • Check if firewall is blocking traffic between:
    • The AD FS server and the load balancer.
    • The WAP (Web Application Proxy) server and the load balancer if WAP is used.
  • If probe is enabled on the load balancer, check the following:
    • If you are running Windows Server 2012 R2, ensure that the August 2014 update rollup is installed.
    • Check if port 80 is enabled in the firewall on the WAP server and AD FS servers.
    • Ensure that probe is set for port 80 and the endpoint /adfs/probe.

Is the problem solved?

  1. Check if inbound traffic through TCP port 443 is enabled on:
    • the firewall between the Web Application Proxy server and the federation server farm.
    • the firewall between the clients and the Web Application Proxy server.
  2. Check if inbound traffic through TCP port 49443 is enabled on the firewall between the clients and the Web Application Proxy server when the following conditions are true:
    • TLS client authentication using X.509 certificate is enabled.
    • You are using AD FS on Windows Server 2012 R2.

      Note The configuration is not required on the firewall between the Web Application Proxy server and the federation servers.

Is the problem solved?

 

Is the problem solved?

AD FS provides various endpoints for different functionalities and scenarios. Not all endpoints are enabled by default. To check the whether the endpoint is enabled on the proxy, following these steps:

  1. On the AD FS server, open the AD FS Management Console.
  2. Expand Service > Endpoints.
  3. Locate the endpoint and verify if the status is enabled on the Proxy Enabled column.
    ADFS endpoints proxy status

 

Is the problem solved?

Note Information on this page applies to AD FS 2012 R2 and later.

If Web Application Proxy (WAP) is deployed, the proxy trust relationship must be established between the WAP server and the AD FS server. Check if the proxy trust relationship is established or starts to fail at some point in time.

Troubleshooting

To automatically detect problems with the proxy trust relationship, run the following script. Based on the problem detected, take the action accordingly at the end of the page.

What’s the problem detected?

The binding may conflict with the AD FS certificate binding on port 443.

The IP:port binding takes the highest precedence. If an IP:port binding is in the AD FS SSL certificate bindings, http.sys always uses the certificate for the binding for SSL communication. To solve this problem, use the following methods.

Method 1: Remove the IP:port binding

Be aware that the IP:port binding may come back after you removed it. For example, an application configured with this IP:port binding may automatically recreate it on the next service start-up.

Method 2: Use another IP address for AD FS SSL communication

If the IP:port binding is required, resolve the ADFS service FQDN to another IP address that is not used in any bindings. That way, http.sys will use the Hostname:port binding for SSL communication.

Method 3: Set AdfsTrustedDevices as the CTL Store for the IP:port binding

This is the last resort if you can’t use the methods above. But it is better to understand the following conditions before you change the default CTL store to AdfsTrustedDevices:

  • Why the IP:port binding is there.
  • If the binding relies on the default CTL store for client certificate authentication.

Is the problem solved?

If Azure AD Connect is installed, use AAD Connect to set CTL Store Name to AdfsTrustedDevices for the SSL certificate bindings on all AD FS servers. If Azure AD Connect is not installed, regenerate the AD FS certificate bindings by running the following command on all AD FS servers.
Set-AdfsSslCertificate -Thumbprint Thumbprint

Is the problem solved?

If a CA issued certificate is in a certificate store where only self-signed certificates would normally exist, the CTL generated from the store would only contain the CA issued certificate. The AdfsTrustedDevices certificate store is such a store that is supposed to have only self-signed certificates. These certificates are:

  • MS-Organization-Access: The self-signed certificate used for issuing workplace join certificates.
  • ADFS Proxy Trust: The certificates for each Web Application Proxy server.

AdfsTrustedDevices certificates

Therefore, delete any CA issued certificate from the AdfsTrustedDevices certificate store.

Is the problem solved?

When a proxy trust relationship is established with an AD FS server, the client certificate is written to the AD FS configuration database and added to the AdfsTrustedDevices certificate store on the AD FS server. For an AD FS farm deployment, the client certificate is expected to be synced to the other AD FS servers. If the sync doesn’t happen for some reason, a proxy trust relationship will only work against the AD FS server the trust was established with, but not against the other AD FS servers.

To solve this problem, use one of the following methods.

Method 1

Install the update documented in KB 2964735 on all AD FS servers. After the update is installed, a sync of the client certificate is expected to happen automatically.

Method 2

Run the script with the – syncproxytrustcerts switch to manually sync the client certificates from the AD FS configuration database to the AdfsTrustedDevices certificate store. The script should be run on all the AD FS servers in the farm.

Note that this is not a permanent solution because the client certificates will be renewed on a regular basis.

Is the problem solved?

Check if there is a time or time zone mismatch. If time matches but the time zone doesn’t, proxy trust relationship will also fail to be established.

Is the problem solved?

If SSL termination is happening on a network device between AD FS servers and the WAP server, communication between AD FS and WAP will break because the communication is based on client certificate.

Disable SSL termination on the network device between the AD FS and WAP servers.

Is the problem solved?

Check Windows Integrated Authentication settings in the client browser, AD FS settings and authentication request parameters.

Check the client browser of the user

Check the following settings in Internet Options:

  • On the Advanced tab, make sure that the Enable Integrated Windows Authentication setting is enabled.
  • Following Security > Local intranet > Sites > Advanced, make sure that the AD FS URL is in the list of websites.
  • Following Security > Local intranet > Custom level, make sure that the Automatic logon only in Intranet Zone setting is selected.

If you use Firefox, Chrome or Safari, make sure the equivalent settings in these browsers are enabled.

Check the AD FS settings

Check the WindowsIntegratedFallback setting

  1. Open Windows PowerShell with the Run as administrator option.
  2. Get the global authentication policy by running the following command:
    Get-ADFSGlobalAuthenticationPolicy
  3. Examine the value of the WindowsIntegratedFallbackEnbaled attribute.

If the value is True, forms-based authentication is expected. This means that the authentication request comes from a browser that doesn’t support Windows Integrated Authentication. See the next section about how to get your browser supported.

If the value is False, Windows Integrated Authentication should be expected.

Check the WIASupportedUsersAgents setting

  1. Get the list of supported user agents by running the following command:
    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
  2. Examine the list of user agent strings that the command returns.

Verify if the user agent string of your browser is in the list. If not, add the user agent string by following the steps below:

  1. Go to http://useragentstring.com/ that detects and shows you the user agent string of your browser.
  2. Get the list of supported user agents by running the following command:
    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
  3. Add the user agent string of your browser by running the following command:
    $wiaStrings = $wiaStrings+"NewUAString"
    Example: $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
  4. Update the WIASupportedUserAgents setting by running the following command:
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Check the authentication request parameters

Check if the authentication request specifies forms-based authentication as the authentication method

  1. If the authentication request is a WS-Federation request, check if the request includes wauth= urn:oasis:names:tc:SAML:1.0:am:password.
  2. If the authentication request is a SAML request, check if the request includes a samlp:AuthnContextClassRef element with value urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

For more information, see Overview of authentication handlers of AD FS sign-in pages.

Check if the application is Microsoft Online Services for Office 365

If the application that you want to access is not Microsoft Online Services, what you experience is expected and controlled by the incoming authentication request. Work with the application owner to change the behavior.

If the application is Microsoft Online Services, what you experience may be controlled by the PromptLoginBehavior setting from the trusted realm object. This setting controls whether Azure AD tenants send prompt=login to AD FS. To set the PromptLoginBehavior setting, follow these steps:

  1. Open Windows PowerShell with the "Run as administrator" option.
  2. Get the existing domain federation setting by running the following command:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
  3. Set the PromptLoginBehavior setting by running the following command:
    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

    The values for the PromptLoginBehavior parameter are:
    1. TranslateToFreshPasswordAuth: Azure AD sends wauth and wfresh to AD FS instead of prompt=login. This leads to an authentication request to use forms-based authentication.
    2. NativeSupport: The prompt=login parameter is sent as is to AD FS.
    3. Disabled: Nothing is sent to AD FS.

To learn more about the Set-MSOLDomainFederationSettings command, see Active Directory Federation Services prompt=login parameter support.

Is the problem solved?

Multi-factor authentication can be enabled at an AD FS server, at a relying party, or specified in an authentication request parameter. Check the configurations to see if they are correctly set. If multi-factor authentication is expected but youre repeatedly prompted for it, check the relying party issuance rules to see if multi-factor authentication claims are passed through to the application.

For more information about multi-factor authentication in AD FS, see the following articles:

Check the configuration on the AD FS server and the relying party

To check the configuration on the AD FS server, validate the global additional authentication rules. To check the configuration on the relying party, validate the additional authentication rules for the relying party trust.

  1. To check the configuration on the AD FS server, run the following command in a Windows PowerShell window.
    Get-ADFSAdditionalAuthenticationRule

    To check the configuration on the relying party, run the following command:
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    Note If the commands return nothing, the additional authentication rules are not configured. Skip this section.
  2. Observe the claim rule set configured.

Verify if multi-factor authentication is enabled in the claim rule set

A claim rule set is composed of the following sections:

  • The condition statement: C:[Type=,Value=]
  • The issue statement: => issue (Type=,Value=)

If the issue statement contains the following claim, multi-factor authentication is specified.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Here are examples that require multi-factor authentication to be used for non-workplace joined devices and for extranet access respectively:

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

Check the relying party issuance rules

If the user repeatedly receives multi-factor authentication prompts after they perform the first authentication, it is possible that the replying party is not passing through the multi-factor authentication claims to the application. To check if the authentication claims are passed through, follow these steps:

  1. Run the following command in Windows PowerShell:
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp
  2. Observe the rule set defined in the IssuanceAuthorizationRules or IssuanceAuthorizationRulesFile attributes.

The rule set should include the following issuance rule to pass through the multi-factor authentication claims:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Check the authentication request parameter

Check if the authentication request specifies multi-factor authentication as the authentication method

  • If the authentication request is a WS-Federation request, check if the request includes wauth= http://schemas.microsoft.com/claims/multipleauthn.
  • If the authentication request is a SAML request, check if the request includes a samlp:AuthnContextClassRef element with value http://schemas.microsoft.com/claims/multipleauthn.

For more information, see Overview of authentication handlers of AD FS sign-in pages.

Check if the application is Microsoft Online Services for Office 365

If the application that you want to access is Microsoft Online Services for Office 365, check the SupportsMFA domain federation setting.

  1. Get the current SupportsMFA domain federation setting by running the following command:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
  2. If the SupportsMFA setting is FALSE, set it to TRUE by running the following command:
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

Is the problem solved?

Disable the prompt=login capability by running the following command:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

After you run this command, Office 365 applications won’t include the prompt=login parameter in each authentication request.

Is the problem solved?

Modify the request parameter to use the expected authentication method.

Is the problem solved?

If SSO is disabled, enable it.

Is the problem solved?

Congratulations! The SSO issue has been solved.

We are sorry that the problem persists. We'd appreciate it if you fill in the survey with details of your issue.