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.
- Kerberos enabled for SharePoint 2013 authentication
- Window server 2012 for all SharePoint 2013 servers
- 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.
