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.