Troubleshoot AD FS issues in Azure Active Directory and Office 365

This article discusses workflow troubleshooting for authentication issues for federated users in Azure Active Directory or Office 365.
Symptoms
  • Federated users cannot log on to Office 365 or Microsoft Azure even though managed cloud-only users who have a domainxx.onmicrosoft.com UPN suffix can log on without a problem.
  • Redirection to Active Directory Federation Services (AD FS) or STS does not occur for a federated user. Or, a “Page cannot be displayed” error is triggered.
  • You receive a certificate-related warning on a browser when you try to authenticate with AD FS. This states that certificate validation fails or that the certificate is not trusted.
  • "Unknown Auth method” error or errors stating that AuthnContext is not supported. Also, errors at the AD FS or STS level when you are redirected from Office 365.
  • AD FS throws an “Access is Denied” error.
  • AD FS throws an error stating that there's a problem accessing the site; this includes a reference ID number.
  • The user is repeatedly prompted for credentials at the AD FS level.
  • Federated users cannot authenticate from an external network or when they use an application that takes the external network route (Outlook, for example).
  • Federated users cannot log on after a token-signing certificate is changed on AD FS.
  • A "Sorry, but we're having trouble signing you in" error is triggered when a federated user signs in to Office 365 in Microsoft Azure. This error includes error codes such as 8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A, or BAD request.

Troubleshooting workflow
  1. Access https://login.microsoftonline.com, and then enter the federated user’s login name (someone@example.com). After you press Tab to remove the focus from the login box, check whether the status of the page changes to "Redirecting" and then you're redirected to your Active Directory Federation Service (AD FS) for sign-in.

    When redirection occurs, you see the following page:

    The screen shot for step 1
    1. If no redirection occurs and you are prompted to enter a password on the same page, this means that Azure Active Directory (AD) or Office 365 does not recognize the user or the domain of the user to be federated. To check whether there's a federation trust between Azure AD or Office 365 and your AD FS server, run the Get-msoldomain cmdlet from Azure AD PowerShell. If a domain is federated, its authentication property will be displayed as “Federated,” as in the following screen shot:

      Step about Federated domain
    2. If redirection occurs but you are not redirected to your AD FS server for sign-in, check whether the AD FS service name resolves to the correct IP and whether it can connect to that IP on TCP port 443.

      If the domain is displayed as "Federated," obtain information about the federation trust by running the following commands:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      Check the URI, URL, and certificate of the federation partner that's configured by Office 365 or Azure AD.
  2. After you are redirected to AD FS, the browser may throws a certificate trust-related error, and for some clients and devices it may not let you establish an SSL session with AD FS. To resolve this issue, follow these steps:
    1. Make sure that the AD FS service communication certificate that's presented to the client is the same one that's configured on AD FS.

      The screen shot about step A

      Ideally, the AD FS service communication certificate should be the same as the SSL certificate that's presented to the client when it tries to establish an SSL tunnel with the AD FS service.

      In AD FS 2.0:

      • Bind the certificate to IIS->default first site.
      • Use the AD FS snap-in to add the same certificate as the service communication certificate.

      In AD FS 2012 R2:

      • Use the AD FS snap-in or the Add-adfscertificate command to add a service communication certificate.
      • Use the Set-adfssslcertificate command to set the same certificate for SSL binding.

    2. Make sure that AD FS service communication certificate is trusted by the client.
    3. If non-SNI–capable clients are trying to establish an SSL session with AD FS or WAP 2-12 R2, the attempt may fail. In this case, consider adding a Fallback entry on the AD FS or WAP servers to support non-SNI clients. For more information, see the following blog post:
  3. You may encounter an "Unknown Auth method” error or errors stating that AuthnContext is not supported at the AD FS or STS level when you are redirected from Office 365. This is most common when Office 365 and Azure AD redirects to the AD FS or STS by using a parameter that enforces an authentication method. To enforce an authentication method, use one of the following methods:
    • For WS-Federation, use a WAUTH query string to force a preferred authentication method.
    • For SAML2.0, use the following:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    When the enforced authentication method is sent with an incorrect value, or if that authentication method is not supported on AD FS or STS, you receive an error message before you are authenticated.

    The following table shows the authentication type URIs that are recognized by AD FS for WS-Federation passive authentication.
    Method of authentication wantedwauth URI
    User name and password authenticationurn:oasis:names:tc:SAML:1.0:am:password
    SSL client authenticationurn:ietf:rfc:2246
    Windows integrated authenticationurn:federation:authentication:windows

    Supported SAML authentication context classes

    Authentication method Authentication context class URI
    User name and passwordurn:oasis:names:tc:SAML:2.0:ac:classes:Password
    Password protected transporturn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    Transport Layer Security (TLS) clienturn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
    X.509 certificateurn:oasis:names:tc:SAML:2.0:ac:classes:X509
    Integrated Windows authenticationurn:federation:authentication:windows
    Kerberosurn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

    To make sure that the authentication method is supported at AD FS level, check the following.

    AD FS 2.0

    Under /adfs/ls/web.config, make sure that the entry for the authentication type is present.

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

    AD FS 2.0: How to change the local authentication type

    AD FS 2012 R2

    Under AD FS Management, click Authentication Policies in the AD FS snap-in.

    In the Primary Authentication section, click Edit next to Global Settings. You can also right-click Authentication Policies and then select Edit Global Primary Authentication. Or, in the Actions pane, select Edit Global Primary Authentication.

    In the Edit Global Authentication Policy window, on the Primary tab, you can configure settings as part of the global authentication policy. For example, for primary authentication, you can select available authentication methods under Extranet and Intranet.

    **Make sure that the required authentication method check box is selected.
  4. If you get to your AD FS and enter you credentials but you cannot be authenticated, check for the following issues.
    1. Active Directory replication issue

      If AD replication is broken, changes made to the user or group may not be synced across domain controllers. Between domain controllers, there may be a password, UPN, GroupMembership, or Proxyaddress mismatch that affects the AD FS response (authentication and claims). You should start looking at the domain controllers on the same site as AD FS. Running a repadmin /showreps or a DCdiag /v command should reveal whether there's a problem on the domain controllers that AD FS is most likely to contact.

      You can also collect an AD replication summary to make sure that AD changes are being replicated correctly across all domain controllers. The repadmin /showrepl * /csv > showrepl.csv output is helpful for checking the replication status. For more information, see Troubleshooting Active Directory replication problems.
    2. Account locked out or disabled in Active Directory

      When an end-user is authenticated through AD FS, he or she will not receive an error message stating that the account is locked or disabled. From AD FS and Logon auditing, you should be able to determine whether authentication failed because of an incorrect password, whether the account is disabled or locked, and so forth.

      To enable AD FS and Logon auditing on the AD FS servers, follow these steps:
      1. Use local or domain policy to enable success and failure for the following policies:
        • Audit logon event, located in Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy"
        • Audit Object Access, located in Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy"
        The screen shot about the policies
      2. Disable the following policy:

        Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings

        This policy is located in Computer configuration\Windows Settings\Security setting\Local Policy\Security Option.

        The screen shot about policy

        If you want to configure this by using advanced auditing, click here.
      3. Configure AD FS for auditing:
        1. Open the AD FS 2.0 Management snap-in.
        2. In the Actions pane, click Edit Federation Service Properties.
        3. In the Federation Service Properties dialog box, click the Events tab.
        4. Select the Success audits and Failure audits check boxes.

          The sceenshot about enable AD FS auditing
        5. Run GPupdate /force on the server.
    3. Service Principal Name (SPN) is registered incorrectly

      There may be duplicate SPNs or an SPN that's registered under an account other than the AD FS service account. For an AD FS Farm setup, make sure that SPN HOST/AD FSservicename is added under the service account that's running the AD FS service. For an AD FS stand-alone setup, where the service is running under Network Service, the SPN must be under the server computer account that's hosting AD FS.

      The screen shot for AD FS service name

      Make sure that there are not duplicate SPNs for the AD FS service, as this may cause intermittent authentication failures with AD FS. To list the SPNs, run SETSPN –L <ServiceAccount>.

      The screen shot about list SPN

      Run SETSPN –A HOST/AD FSservicename ServiceAccount to add the SPN.

      Run SETSPN –X -F to check for duplicate SPNs.
    4. Duplicate UPNs in Active Directory

      A user may be able to authenticate through AD FS when they're using SAMAccountName but be unable to authenticate when using UPN. In this scenario, Active Directory may contain two users who have the same UPN. It’s possible to end up with two users who have the same UPN when users are added and modified through scripting (ADSIedit, for example).

      When UPN is used for authentication in this scenario, the user is authenticated against the duplicate user. Therefore, the credentials that are provided are not validated.

      You can use queries like the following to check whether there are multiple objects in AD that have the same values for an attribute:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Make sure that the UPN on the duplicate user is renamed, so that the authentication request with the UPN is validated against the correct objects.
    5. In a scenario, where you are using your email address as the login ID in Office 365, and you enter the same email address when you are redirected to AD FS for authentication, authentication may fail with a "NO_SUCH_USER" error in the Audit logs. To enable AD FS to find a user for authentication by using an attribute other than UPN or SAMaccountname, you must configure AD FS to support an alternate login ID. For more information, see Configuring alternate login ID.

      On AD FS 2012 R2

      1. Install Update 2919355.
      2. Update the AD FS configuration by running the following PowerShell cmdlet on any of the federation servers in your farm (if you have a WID farm, you must run this command on the primary AD FS server in your farm):

        Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>

        NoteAlternateLoginID is the LDAP name of the attribute that you want to use for login. And LookupForests is the list of forests DNS entries that your users belong to.

        To enable the alternate login ID feature, you must configure both the AlternateLoginID and LookupForests parameters with a non-null, valid value.

    6. The AD FS service account does not have read access to on the AD FS token that's signing the certificate’s private key. To add this permission, follow these steps:
      1. When you add a new Token-Signing certificate, you receive the following warning: "Ensure that the private key for the chosen certificate is accessible to the service account for this Federation Service on each server in the farm."
      2. Click Start, click Run, type mmc.exe, and then press Enter.
      3. Click File, and then click Add/Remove Snap-in.
      4. Double-click Certificates.
      5. Select the computer account in question, and then click Next.
      6. Select Local computer, and click Finish.
      7. Expand Certificates (Local Computer), expand Personal, and then select Certificates.
      8. Right-click your new token-signing certificate, select All Tasks, and then select Manage Private Keys.

        The sceenshot about step 8
      9. Add Read access for your AD FS 2.0 service account, and then click OK.
      10. Close the Certificates MMC.
    7. The Extended Protection option for Windows Authentication is enabled for the AD FS or LS virtual directory. This may cause issues with specific browsers. Sometimes you may see AD FS repeatedly prompting for credentials, and this might be related to the Extended protection setting that's enabled for Windows Authentication for the AD FS or LS application in IIS.

      The sceenshot about step 8
      When Extended Protection for authentication is enabled, authentication requests are bound to both the Service Principal Names (SPNs) of the server to which the client tries to connect and to the outer Transport Layer Security (TLS) channel over which Integrated Windows Authentication occurs. Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relays or "man in the middle" attacks. However, certain browsers do not work with the Extended protection setting; instead they repeatedly prompt for credentials and then deny access. Disabling Extended protection helps is this scenario.

      For more information, see AD FS 2.0: Continuously prompted for credentials while using Fiddler web debugger.

      For AD FS 2012 R2

      Run the following cmdlet to disable Extendedprotection:

      Set-ADFSProperties –ExtendedProtectionTokenCheck None

    8. Issuance Authorization rules in the Relying Party (RP) trust may deny access to users. On the AD FS Relying Party trust, you can configure the Issuance Authorization rules that control whether an authenticated user should be issued a token for a Relying Party. Administrators can use the claims that are issued to decide whether to deny access to a user who's a member of a group that's pulled up as a claim.

      If certain federated users cannot authenticate through AD FS, you may want to check the Issuance Authorization rules for the Office 365 RP and see whether the Permit Access to All Users rule is configured.

      The screen shot about rules
      If this rule is not configure, peruse the custom authorization rules to check whether the condition in that rule evaluates "true" for the affected user. For more information, see the following resources:
      If you can authenticate from an intranet when you access the AD FS server directly, but you cannot authenticate when you access AD FS through an AD FS proxy, check for the following issues:
      • Time sync issue on AD FS server and AD FS proxy

        Make sure that the time on the AD FS server and the time on the proxy are in sync. When the time on the AD FS server is off by more than five minutes from the time on the domain controllers, authentication failures occur. When the time on AD FS proxy is not synced with AD FS, the proxy trust is affected and broken. Therefore, a request that comes through the AD FS proxy fails.
      • Check whether the AD FS proxy Trust with the AD FS service is working correctly. Rerun the proxy configuration if you suspect that the proxy trust is broken.
  5. After your AD FS issues a token, Azure AD or Office 365 throws an error. In this situation, check for the following issues:
    • The claims that are issued by AD FS in token should match the respective attributes of the user in Azure AD. In the token for Azure AD or Office 365, the following claims are required.

      WSFED:
      UPN: The value of this claim should match the UPN of the users in Azure AD.
      ImmutableID: The value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

      To get the User attribute value in Azure AD, run the following command line: Get-MsolUser –UserPrincipalName <UPN>

      SAML 2.0:
      IDPEmail: The value of this claim should match the user principal name of the users in Azure AD.
      NAMEID: The value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

      For more information, see Use a SAML 2.0 identity provider to implement single sign-on.

      Examples:
      This issue can occur when the UPN of a synced user is changed in AD but without updating the online directory. In this scenario, you can either correct the user’s UPN in AD (to match the related user’s logon name) or run the following cmdlet to change the logon name of the related user in the Online directory:

      Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [DomainUPN-AD]

      It might also be that you are using AADsync to sync MAIL as UPN and EMPID as SourceAnchor, but the Relying Party claim rules at the AD FS level have not been updated to send MAIL as UPN and EMPID as ImmutableID.
    • There's a token-signing certificate mismatch between AD FS and Office 365.

      This is one of the most common issues. AD FS uses the token-signing certificate to sign the token that's sent to the user or application. The trust between the AD FS and Office 365 is a federated trust that's based on this token-signing certificate (for example, Office 365 verifies that the token received is signed by using a token-signing certificate of the claim provider [the AD FS service] that it trusts).

      However, if the token-signing certificate on the AD FS is changed because of Auto Certificate Rollover or by an admin's intervention (after or before certificate expiry), the details of the new certificate must be updated on the Office 365 tenant for the federated domain. This may not happen automatically; it may require an admin's intervention. When the Primary token-signing certificate on the AD FS is different from what Office 365 knows about, the token that's issued by AD FS is not trusted by Office 365. Therefore, the federated user is not allowed to log on.

      Office 365 or Azure AD will try to reach out to the AD FS service, assuming the service is reachable over the public network. We try to poll the AD FS federation metadata at regular intervals, to pull any configuration changes on AD FS, mainly the token-signing certificate info. If this process is not working, the global admin should receive a warning on the Office 365 portal about the token-signing certificate expiry and about the actions that are required to update it.

      You can use Get-MsolFederationProperty -DomainName <domain> to dump the federation property on AD FS and Office 365. Here you can compare the TokenSigningCertificate thumbprint, to check whether the Office 365 tenant configuration for your federated domain is in sync with AD FS. If you find a mismatch in the token-signing certificate configuration, run the following command to update it:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      You can also run the following tool to schedule a task on the AD FS server that will monitor for the Auto-certificate rollover of the token-signing certificate and update the Office 365 tenant automatically.

      Microsoft Office 365 Federation Metadata Update Automation Installation Tool

      Verify and manage single sign-on with AD FS
    • Issuance Transform claim rules for the Office 365 RP are not configured correctly.

      In a scenario where you have multiple TLDs (top level domains), you might have logon issues if the Supportmultipledomain switch was not used when the RP trust was created and updated. For more information, click here.
    • Make sure that token encryption is not being used by AD FS or STS when a token is issued to Azure AD or to Office 365.
  6. There are stale cached credentials in Windows Credential Manager.

    Sometimes during login in from a workstation to the portal (or when using Outlook), when the user is prompted for credentials, the credentials may be saved for the target (Office 365 or AD FS service) in the Windows Credentials Manager (Control Panel\User Accounts\Credential Manager). This helps prevent a credentials prompt for some time, but it may cause a problem after the user password has changed and the credentials manager is not updated. In that scenario, stale credentials are sent to the AD FS service, and therefore authentication fails. Removing or updating the cached credentials, in Windows Credential Manager may help.
  7. Make sure that Secure Hash Algorithm that's configured on the Relying Party Trust for Office 365 is set to SHA1.

    When the trust between the STS/AD FS and Azure AD/Office 365 is using SAML 2.0 protocol, the Secure Hash Algorithm configured for digital signature should be SHA1.
  8. If none of the preceding causes apply to your situation, create a support case with Microsoft and ask them to check whether the User account appears consistently under the Office 365 tenant. For more information, see the following resources:

    Error message from AD FS 2.0 when a federated user signs in to Office 365: "There was a problem accessing the site"

    A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
  9. Depending on which cloud service (integrated with Azure AD) you are accessing, the authentication request that's sent to AD FS may vary. For example: certain requests may include additional parameters such as Wauth or Wfresh, and these parameters may cause different behavior at the AD FS level.

    We recommend that AD FS binaries always be kept updated to include the fixes for known issues. For more information about the latest updates, see the following table.

Properties

Article ID: 3079872 - Last Review: 08/11/2015 03:36:00 - Revision: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • KB3079872
Feedback