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

A federated user is repeatedly prompted for his or her credentials when the user tries to authenticate to the Active Directory Federation Services (AD FS) 2.0 service endpoint during sign-in to Microsoft Office 365. When the user cancels, the user receives the following error message:

The symptom indicates an issue with Windows Integrated authentication of the AD FS 2.0 service that's used to federate on-premises Active Directory Domain Services (AD DS) identities to Office 365 identities. This issue can occur if one or more of the following conditions are true:

• An issue exists with the credentials that are used.
• Internet Information Services (IIS) authentication settings are set up incorrectly in AD FS 2.0. Or, IIS authentication settings for AD FS 2.0 Federation Services and Proxy Services don't match.
• The service principal name (SPN) that's associated with the service account that's used to run the AD FS 2.0 federation server farm is lost or corrupted.
  
  Note This occurs only when AD FS 2.0 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 2.0 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

      (http://support.microsoft.com/kb/2510193/ )

       Implications of using AD FS 2.0 to implement single sign-on in Office 365
  • A monitoring or SSL decryption application is installed or is active on the client computer
• Domain Name System (DNS) resolution of the AD FS 2.0 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 2.0 server.

Before you diagnose Kerberos issues

Before you troubleshoot further, check that the user name and password are not the cause of the issue.

• Make sure that the correct user name is used. For federated user access, the user principal name (UPN) of the user account is the only appropriate format. 
• 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:
  http://technet.microsoft.com/en-us/library/cc754395.aspx

  (http://technet.microsoft.com/en-us/library/cc754395.aspx)
• 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:
  http://technet.microsoft.com/en-us/library/cc754661.aspx

  (http://technet.microsoft.com/en-us/library/cc754661.aspx)

To resolve the Kerberos issue that limits AD FS 2.0 authentication, use one or more of the following methods, as appropriate for the situation.

Resolution 1: Reset AD FS 2.0 authentication settings to the default values

If AD FS 2.0 IIS authentication settings are incorrect, or IIS authentication settings for AD FS 2.0 Federation Services and Proxy Services don't match, one solution is to reset all IIS authentication settings to the default AD FS 2.0 settings.

On each AD FS 2.0 federation server and on each AD FS 2.0 federation server proxy, use the information in the following Microsoft TechNet article to reset the AD FS 2.0 IIS virtual applications to the default authentication settings: The default authentication settings are listed in the following table.
For more information about how to resolve this error, click the following article numbers to view the articles in the Microsoft Knowledge Base:

Resolution 2: Correct the AD FS 2.0 Federation Service farm SPN

Note Try this resolution only when AD FS 2.0 is implemented as a federation service farm. Do not try this resolution in an AD FS 2.0 stand-alone configuration.

To resolve the issue if the SPN for the AD FS 2.0 service is lost or corrupted on the AD FS 2.0 service account, follow these steps on one server in the AD FS 2.0 federation server farm:

1. Open the Services management snap-in. To do this, click Start, click All Programs, click Administrative Tools, and then click Services.
2. Double-click AD FS 2.0 Windows Service.
3. On the Log On tab, note the service account that's displayed in This Account.
4. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
5. Type SetSPN –f –q host/<AD FS service name>, and then press Enter.
   
   Note In this command, <AD FS service name> represents the fully qualified domain name (FQDN) service name of the AD FS 2.0 service endpoint. It does not represent the Windows host name of the AD FS 2.0 server.
   • If more than one entry is returned for the command, and the result is associated with a user account other than the one that was noted in step 3, remove that association. To do this, run the following command:
     SetSPN –d host/<AD FS service name><bad_username>
   • If more than one entry is returned for the command, and the SPN uses the same name as the computer name of the AD FS 2.0 server in Windows, the federation endpoint name for AD FS 2.0 is incorrect. AD FS 2.0 has to be implemented again. The FQDN of the AD FS 2.0 federation server farm must not be identical to the Windows host name of an existing server.
   • If the SPN does not already exist, run the following command:
     SetSPN –a host/<AD FS service name><username of service account>
     Note In this command, <username of service account> represents the user name that was noted in step 3.
6. After these steps are performed on all servers in the AD FS 2.0 federation server farm, right-click AD FS 2.0 Windows Service in the Services management snap-in, and then click Restart.

Resolution 3: Resolve Extended Protection for Authentication concerns

To resolve the issue if Extended Protection for Authentication detects a possible man-in-the middle attack, use one of the following methods:

• Method 1: Use Windows Internet Explorer 8 (or a later version of the program) to access Office 365 identity federated-services.
• Method 2: Publish AD FS 2.0 services to the Internet in such a way that SSL bridging, SSL offloading, or stateful packet filtering don't rewrite IP payload data. The best-practice recommendation for this purpose is to use an AD FS 2.0 Proxy Server.
• Method 3: Close or disable monitoring or SSL-decrypting applications.

If you can't use any of these methods, to work around this issue, Extended Protection for Authentication can be disabled. To do this, perform the following procedure for the following IIS virtual applications on all servers in the AD FS 2.0 federation server farm.
Warning We do not recommend that you use this procedure as a long-term solution. Disabling Extended Protection for Authentication weakens the AD FS 2.0 service security profile by not detecting certain man-in-the-middle attacks on Integrated Windows Authentication endpoints.

To disable Extended Protection for Authentication, follow these steps:

1. Access the advanced settings for Windows authentication by using the following Microsoft TechNet article:
   http://technet.microsoft.com/en-us/library/cc754628(WS.10).aspx

   (http://technet.microsoft.com/en-us/library/cc754628(WS.10).aspx)
2. Set Extended Protection to Off, and then click OK.

When the workaround is applied for third-party application functionality, you should also uninstall hotfixes on the client operating system for Extended Protection for Authentication. For more information about the hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:To re-enable Extended Protection for Authentication, perform the following procedure for the IIS virtual applications that are listed earlier on all servers in the AD FS 2.0 federation server farm. To do this, follow these steps:

1. Access the advanced settings for Windows authentication by using the following Microsoft TechNet article:
   http://technet.microsoft.com/en-us/library/cc754628(WS.10).aspx

   (http://technet.microsoft.com/en-us/library/cc754628(WS.10).aspx)
2. Set Extended Protection to Accept, and then click OK.
3. Reinstall any required hotfixes on the client operating system for Extended Protection for Authentication. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
   968389

   (http://support.microsoft.com/kb/968389/ )

   Extended Protection for Authentication

Resolution 4: Correct the CNAME DNS advertisement

Use DNS management tools to replace each DNS Alias (CNAME) record with a DNS address (A) record. Also, check or consider corporate DNS settings when a split-brain DNS configuration is implemented. For more information about how to manage DNS records, go to the following Microsoft TechNet website:

Resolution 5: Configure Internet Explorer as an AD FS 2.0 client for single sign-on (SSO)

For more information about how to configure Internet Explorer for AD FS 2.0 access, see the following article in the Microsoft Knowledge Base:

To help protect a network, AD FS 2.0 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 2.0 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 2.0. These updates are available from the following Microsoft Knowledge Base article: 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)


Windows Vista without appropriate updates


Windows XP without appropriate updates

For more information about Extended Protection for Authentication, see the following Microsoft resources:
For more information about the Set-ADFSProperties cmdlet, go to the following Microsoft website:

Video: Looping Credential Prompts When Signing In to Office 365 Using an Identity Federated Account

uuid=206faa92-f769-445d-8cd6-0c3f45a0ecc3 VideoUrl=http://aka.ms/wqsfve

Video: Federated Users are Repeatedly Prompted for Credentials and Cannot Sign In to Office 365

uuid=3add2284-c878-46f8-881c-ba6c8bb6286a VideoUrl=http://aka.ms/lifluf