Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. Enterprise single sign-on users in Office 365 can't sign in to Skype for Business Online from inside their corporate network

Enterprise single sign-on users in Office 365 can't sign in to Skype for Business Online from inside their corporate network

View products that this article applies to.

PROBLEM

Consider the following scenario:
  • An Office 365 for enterprises, Office 365 for education, or Office 365 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 Skype for Business Online (formerly 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 Skype for Business Online by using Lync 2013 from inside their corporate network. The issue doesn't apply to users on Microsoft Lync 2010, users who aren't on Skype for Business Online, or users who connect from outside their corporate network.

↑ Back to the top

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

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

↑ Back to the top

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

↑ Back to the top


Still need help? Go to Microsoft Community.

↑ Back to the top

Keywords: vkbportal231, vkbportal237, vkbportal300, o15, yespartner, o365022013, o365, o365e, o365m, lynconline, uacrossref, kbcrossrefol, kbgraphxlink, vkbportal339, diy, kbgraphic, sbo, kb, o365a

↑ Back to the top

Article Info
Article ID : 2839539
Revision : 4
Created on : 8/20/2020
Published on : 8/21/2020
Exists online : False
Views : 239