A federated user is repeatedly prompted for credentials during sign-in to Office 365, Azure, or Intune

Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

PROBLEM

A federated user is repeatedly prompted for credentials when the user tries to authenticate to the Active Directory Federation Services (AD FS) service endpoint during sign-in to a Microsoft cloud service such as Office 365, Microsoft Azure, or Microsoft Intune. When the user cancels, the user receives the following error message:
Access Denied

CAUSE

The symptom indicates an issue with Windows Integrated authentication with AD FS. This issue can occur if one or more of the following conditions are true:
  • An incorrect user name or password was used.
  • Internet Information Services (IIS) authentication settings are set up incorrectly in AD FS.
  • The service principal name (SPN) that's associated with the service account that's used to run the AD FS federation server farm is lost or corrupted.

    Note This occurs only when AD FS is implemented as a federation server farm and not implemented in a stand-alone configuration.
  • One or more of the following are identified by Extended Protection for Authentication as a source of a man-in-the-middle attack:
    • Some third-party Internet browsers
    • The corporate network firewall, network load balancer, or other networking device is publishing the AD FS Federation Service to the Internet in such a way that IP payload data may potentially be rewritten. This possibly includes the following kinds of data:
      • Secure Sockets Layer (SSL) bridging
      • SSL offloading
      • Stateful packet filtering

        For more information, see the following Microsoft Knowledge Base article:
        2510193  Supported scenarios for using AD FS to set up single sign-on in Office 365, Azure, or Intune 
    • A monitoring or SSL decryption application is installed or is active on the client computer
  • Domain Name System (DNS) resolution of the AD FS service endpoint was performed through CNAME record lookup instead of through an A record lookup.
  • Windows Internet Explorer isn't configured to pass Windows Integrated authentication to the AD FS server.

Before you start troubleshooting

Check that the user name and password are not the cause of the issue.
  • Make sure that the correct user name is used and is in user principal name (UPN) format. For example, johnsmith@contoso.com.
  • Make sure that the correct password is used. To double-check that the correct password is used, you may have to reset the user password. For more information, see the following Microsoft TechNet article:
  • Make sure that the account isn't locked out, expired, or used outside designated logon hours. For more information, see the following Microsoft TechNet article:

Verify the cause

To check that Kerberos problems are causing the issue, temporarily bypass Kerberos authentication by enabling forms-based authentication on the AD FS federation server farm. To do this, follow these steps:

Step 1: Edit the web.config file on each server in the AD FS federation server farm
  1. In Windows Explorer, locate the C:\inetpub\adfs\ls\ folder, and then make a backup copy of the web.config file.
  2. Click Start, click All Programs, click Accessories, right-click Notepad, and then click Run as administrator.
  3. On the File menu, click Open. In the File Name box, type C:\inetpub\adfs\ls\web.config, and then click Open.
  4. In the web.config file, follow these steps:
    1. Locate the line that contains <authentication mode=, and then change it to <authentication mode="Forms"/>.
    2. Locate the section that begins with <localAuthenticationTypes>, and then change the section so that the <add name="Forms" entry is listed first, as follows:
      <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/" />
  5. On the File menu, click Save.
  6. At an elevated command prompt, restart IIS by using the iisreset command.
Step 2: Test AD FS functionality
  1. On a client computer that's connected and authenticated to the on-premises AD DS environment, sign in to the cloud service portal.

    Instead of a seamless authentication experience, a forms-based sign-in should be experienced. If sign-in is successful by using forms-based authentication, this confirms that a problem with Kerberos exists in the AD FS Federation Service.
  2. Revert the configuration of each server in the AD FS federation server farm to the previous authentication settings before you follow the steps in the "Resolution" section. To revert the configuration of each server in the AD FS federation server farm, follow these steps:
    1. In Windows Explorer, locate the C:\inetpub\adfs\ls\ folder, and then delete the web.config file.
    2. Move the backup of the web.config file that you created in the "Step 1: Edit the web.config file on each server in the AD FS federation server farm" section to the C:\inetpub\adfs\ls\ folder.
  3. At an elevated command prompt, restart IIS by using the iisreset command.
  4. Check that the AD FS authentication behavior reverts to the original issue.

SOLUTION

To resolve the Kerberos issue that limits AD FS authentication, use one or more of the following methods, as appropriate for the situation.
Resolution 1: Reset AD FS authentication settings to the default values
Resolution 2: Correct the AD FS federation server farm SPN
Resolution 3: Resolve Extended Protection for Authentication concerns
Resolution 4: Replace CNAME records with A records for AD FS
Resolution 5: Set up Internet Explorer as an AD FS client for single sign-on (SSO)

MORE INFORMATION

To help protect a network, AD FS uses Extended Protection for Authentication. Extended Protection for Authentication can help prevent man-in-the-middle attacks in which an attacker intercepts a client's credentials and forwards them to a server. Protection against such attacks is made possible by using Channel Binding Works (CBT). CBT can be required, allowed, or not required by the server when communications are established with clients.

The ExtendedProtectionTokenCheck AD FS setting specifies the level of extended protection for authentication that's supported by the federation server. These are the available values for this setting:
  • Require: The server is fully hardened. Extended protection is enforced.
  • Allow: This is the default setting. The server is partly hardened. Extended protection is enforced for involved systems that are changed to support this feature.
  • None: The server is vulnerable. Extended protection isn't enforced.
The following tables describe how authentication operates for three operating systems and browsers, depending on the different Extended Protection options that are available on AD FS with IIS.

Note Windows client operating systems must have specific updates that are installed to effectively use Extended Protection features. By default, the features are enabled in AD FS. These updates are available from the following Microsoft Knowledge Base article:
968389 Extended Protection for Authentication
By default, Windows 7 includes the appropriate binaries to use Extended Protection.

Windows 7 (or appropriately updated versions of Windows Vista or of Windows XP)
SettingRequireAllow (the default)None
Windows Communication
Foundation (WCF) Client (All endpoints)
WorksWorksWorks
Internet Explorer 8 and later versionsWorksWorksWorks
Firefox 3.6FailsFailsWorks
Safari 4.0.4FailsFailsWorks
Windows Vista without appropriate updates
SettingRequireAllow (the default)None
WCF Client (All endpoints)FailsWorksWorks
Internet Explorer 8 and later versionsWorksWorksWorks
Firefox 3.6FailsWorks Works
Safari 4.0.4FailsWorks Works
Windows XP without appropriate updates
SettingRequireAllow (the default)None
Internet Explorer 8 and later versionsWorksWorksWorks
Firefox 3.6FailsWorks Works
Safari 4.0.4FailsWorks Works
For more information about Extended Protection for Authentication, see the following Microsoft resources:
968389 Extended Protection for Authentication
For more information about the Set-ADFSProperties cmdlet, go to the following Microsoft website:

Still need help? Go to Microsoft Community or the Azure Active Directory Forums website.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products
Properties

Article ID: 2461628 - Last Review: Dec 16, 2016 - Revision: 1

Feedback