DetailPage-MSS-KB

Microsoft small business knowledge base

Article ID: 2839539 - Last Review: June 26, 2014 - Revision: 13.0

PROBLEM

Consider the following scenario:
  • A Microsoft Office 365 for enterprises, Microsoft Office 365 for education, or Microsoft Office 365 for midsize business customer sets up single sign-on (SSO) in Active Directory Federation Services (AD FS) 2.0.
  • Federated users who connect from inside their corporate network can't sign in to Lync Online from Lync 2013, and they receive the following error message:
    Cannot sign in because the server is temporarily unavailable.
Note This issue only applies to Enterprise SSO users who sign in to Microsoft Lync Online by using Microsoft Lync 2013 from inside their corporate network. The issue doesn't apply to users on Microsoft Lync 2010, users who aren't on Lync Online, or users who connect from outside their corporate network.

SOLUTION

Important Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration   (http://support.microsoft.com/kb/322756/ ) in case problems occur.

Because there are many possible causes, it's best to work through all the following solutions, and then verify the configuration.
  1. When you deploy an AD FS 2.0 Federation Server farm, you must specify a domain-based service account that needs a registered SPN to enable Kerberos authentication to function correctly. For more info, see the following TechNet wiki:
    AD FS 2.0: How to Configure the SPN (servicePrincipalName) for the Service Account (http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-configure-the-spn-serviceprincipalname-for-the-service-account.aspx)
    The reasons that you may have to set the SPN manually on the AD FS 2.0 service account are as follows:
    • SPN registration failed during initial configuration of the farm.
    • The Federation Service name was changed.
    • The service account was changed.
  2. Make sure that the AD FS 2.0 service is running under the domain-based service account that was mentioned in the previous step. For example, in the following image, TRLABV3 is the internal host name, and ADFSSvc is the service account:

    Collapse this imageExpand this image
    Screen shot of the AD FS 2.0 Windows Service Properties, showing the domain-based account

  3. Configure the AD FS 2.0 server to accept request headers that are larger than 40 kilobytes (KB). You may have to do this when the user is a member of many Active Directory Domain Services (AD DS) user groups. When a user is a member of many AD DS groups, the size of the Kerberos authentication token for the user increases.

    The HTTP request that the user sends to the Internet Information Services (IIS) server contains the Kerberos token in the WWW-Authenticate header. Therefore, the header size increases as the number of groups increases. If the HTTP header or packet size increases beyond the limits that are configured in IIS, IIS may reject the request and send an error as the response. For more info, see the following Microsoft Knowledge Base article:
    2020943  (http://support.microsoft.com/kb/2020943/ ) "HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS)
    To work around this issue, use one of the following methods:
    1. Decrease the number of AD DS user groups that the user is a member of.
    2. Change the MaxFieldLength and the MaxRequestBytes registry values on the server that's running IIS so that the user’s request headers aren't considered too long. These two registry values are located under the following registry subkey:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  4. If you've deployed multiple AD FS 2.0 servers in a farm and have them load balanced, the Lync 2013 client may be unable to direct the request to the AD FS 2.0 server. Adding an entry for the AD FS 2.0 server to the Hosts file on the client that points directly to the AD FS 2.0 server will bypass the virtual IP of the load balancer.
  5. If the previous solutions didn't resolve the problem and downgrading to Lync 2010 isn't an option, follow these steps to work around the problem.

    Note If a local administrator account doesn't already exist on the computer, you'll have to create one for this solution to work.
    1. Browse to the Lync 2013 executable in Windows Explorer:
       C:\Program Files\Microsoft Office 15\root\office15
    2. Hold down the Shift key, and then right-click Lync.exe.
    3. Click Run as different user.
    4. Enter the credentials for a local administrator account on the computer, and then press Enter.

MORE INFORMATION

This issue typically occurs because of a misconfiguration in AD FS 2.0. Other services such as Microsoft Exchange Online may work correctly despite this configuration. The usual causes are listed here:
  • The ServicePrincipalName (SPN) isn't configured correctly. The reasons for this include the following:
    • SPN registration failed during initial configuration of the farm.
    • The Federation Service name was changed.
    • The service account was changed.
  • The AD FS 2.0 service isn't running under the correct service account.
  • The request header from Lync 2013 is rejected by IIS and the AD FS 2.0 server because the header is too large. This issue can occur because the user account is a member of too many AD DS user groups.
  • The AD FS 2.0 server farm is load balanced, and the request isn't reaching the AD FS 2.0 server.
For more help with deploying AD FS 2.0 for use with SSO in Office 365, see the following TechNet website:
Plan for and deploy AD FS for use with single sign-on (http://technet.microsoft.com/en-us/library/jj151794.aspx)
In the case when the user is a member of too many AD DS groups, the following entry is entered in the Microsoft Online Services Sign-In Assistant trace logs (these logs are usually located in C:\ MSOSSPTrace):
##TestHook: URL-

https://<ADFSServer>/adfs/services/trust/2005/windowstransport@transport.cpp_245

.....

.....

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Still need help? Go to the Office 365 Community (http://community.office365.com/) website.

Applies to
  • Microsoft Lync Online
Keywords: 
o365022013 o365 o365e o365a o365m kbgraphxlink kbgraphic KB2839539
Share
Additional support options
Ask The Microsoft Small Business Support Community
Contact Microsoft Small Business Support
Find Microsoft Small Business Support Certified Partner
Find a Microsoft Store For In-Person Small Business Support