Tuesday, February 25, 2014

Important accepts to fix SharePoint 2013 "HTTP 400 - Bad Request (Request Header too long)" error



After we upgraded SharePoint from 2010 to 2013, many end users reported the following three errors.


  • "HTTP 400 - Bad Request (Request Header too long)" when access SharePoint 2013 sites
  • SharePoint 2013 files opening in Read only mode and unable to edit
  • Open with explore error out


Although this was originally reported only users overseas not in USA, it does not seems to be a network issue and happens immediately after SharePoint 2010 to 2013 upgrade. After looking through the Microsoft  KB articles, we understand this is mainly caused by the following three combinations.


  1. Kerberos enabled for SharePoint 2013 authentication
  2. Window server 2012 for all SharePoint 2013 servers
  3. Many group memberships for the user


Kerberos uses the Privilege Attribute Certificate (PAC) field of the Kerberos packet to transport Active Directory Group membership. Starting with Windows Server 2012, this also applies to the Active Directory Claims information (Dynamic Access Control) field. If there are many group memberships for the user, and if there are many claims for the user or the device that is being used, these fields can occupy lots of space in the packet. If a user is a member of more than 120 groups, the buffer that is determined by the MaxTokenSize value is not large enough. Therefore, users cannot authenticate, and they may receive error messages listed above. You could use different tools to debug the issues.

The procedures to fix this issue is quick simple as described in Microsoft KB article.

For Internet Information Services (IIS) 6.0 and later, the MaxFieldLength and MaxRequestBytes registry keys are located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.  Configure them as shown in the following table: 
Name 
 Value Type
 Value Data
 MaxFieldLength
 DWORD
 (4/3 * T bytes) + 200 
 MaxRequestBytes
 DWORD
 (4/3 * T bytes) + 200

Alternatively you may set the registry keys to their maximum values shown below. The Administrator should consider all potential security ramifications if he makes any changes to the registry settings:   
Name 
 Value Type
Value Data 
 MaxFieldLength
 DWORD
 65534
 MaxRequestBytes
 DWORD
 16777216

Most people just adjust MaxFieldLength and MaxRequestBytes on SharePoint WFEs without changing other servers that might not resolve all the issues. Please refer the Microsoft note to resolve this issue. Here are some important accepts to resolve the issues.

Important To resolve this problem, you must set the MaxTokenSize registry value for all the computers that are involved in the Kerberos authentication process. This includes the SQL Server clients. (That is, the registry key has to be set on each computer that is involved in the request/response flow. Therefore, if there is a SQL Server client on which a web application relies, or if the user’s token has to be passed to a backend SQL Server database, the registry key has to be set on the SQL Server client computer, the SQL Server database computer, and also the client computer that is running Internet Explorer, the web server running that is running IIS, and so on.)
  
Important After MaxFieldLength and MaxRequestBytes registry changes, servers need a bounce to pick up the new changes AND rebuild the distributed cache.



Important Some people also tried the following procedure as workaround for IE but it is not a permanent solution and should not be encouraged. This will not work for Chrome either.
  • Launch Internet Explorer 
  • Click on Tools menu and select Internet Options
  • Click on Advanced Tab 
  • Under Security option, uncheck “Enable Integrated Windows Authentication”
  • Click Apply and close the browser.
Important As best practice, it's critical to clean up the group memberships for the user to reduce the HTTP header size. Some clean ups include but not limited to the following actions.
  • Reduce/consolidate group membership
  • Clean up SID History
  • Limit the number of users that are configured to use "trusted for delegation". The account that are configured  to use "trusted    for delegation" the buffer requirements for each SID may double. 
Important Keep in mind there is a hard limit of 1,015 groups a user can be a member of. If a user tries to log into a computer by using a local or domain account and they are a member of more than 1,015 groups they will get this Logon Message: The system cannot log you on due to the following error: During a logon attempt, the user’s security context accumulated too many security IDs. Please try again or consult your system administrator. Please refer the article for details.

Monday, February 24, 2014

SharePoint 2013 "Sorry, something went wrong. An unexpected error has occurred" when users Sign Out



After we upgraded from 2010 to 2013, we found internal users are not able to consistently login to the two web applications with the mixed authentications. Different internal users hitting different web applications on different Web Front servers at different time might get the different results as we described in previous blog.

In additional, users are getting the same error when click “Sign Out”. The error is in the following screenshot that is identical to one of the errors we described before.



The exception from the ULS log is also same as we reported in previous blog.


Unexpected       System.ArgumentException: Exception of type 'System.ArgumentException' was thrown.  Parameter name: encodedValue    at Microsoft.SharePoint.Administration.Claims.SPClaimEncodingManager.DecodeClaimFromFormsSuffix(String encodedValue)     at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(IClaimsIdentity claimsIdentity, String encodedIdentityClaimSuffix)     at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedIdentityClaimSuffix)     at Microsoft.SharePoint.Utilities.SPUtility.GetFullUserKeyFromLoginName(String loginName)     at Microsoft.SharePoint.ApplicationRuntime.SPHeaderManager.AddIsapiHeaders(HttpContext context, String encodedUrl, NameValueCollection headers)     at Microsoft.SharePoint.Application...     


The procedure to reproduce this is simple.
  1. SharePoint 2013 farm have at least two web applications with mixed
    authentications. One FBA with LDAP and another window with AD.
  2. Login to the site using window user account
  3. Click "Sign Out" and you might get the error
  4. Try to login the site again and you might still get the same error
The strange behave is users will stuck on this page even try to refresh to login to the site. Although I have provided a workaround, we still need to find permanent solution from Microsoft.