If you have been involved with SharePoint long enough, you’ve come across some very strange oddities. This situation is no different. Companies that have had an I.T. department for a long period of time can often find themselves with a large amount of security groups in A.D. If not managed properly, it can get out of control quickly. Then nested security groups become an even bigger problem.
The company I currently work for has a nasty habit of never deleting user accounts from A.D. Especially if it is an I.T. user account. This is because they do not know if the account was integrated into a critical system due to some shoddy admin work or whatever the case may be.
The Situation: A particular user was trying to get into a SharePoint site to complete a form. However, they are presented with a blank page, or a “400 Bad Request”. I know the site works just fine because it is used every day by many users. I had him try Firefox and Chrome and it worked on both fronts. However, since I.E. is the “go to standard” for SharePoint, I had to resolve the issue.
This particular user has been with the company for many years. In fact, he had left the company many years prior and then returned. Since the company never deletes accounts, they simply reactivated his old account. As I explored his permissions, I found more security groups than I could count. Not to mention the nested security groups within those.
SharePoint does not like tons of security groups. Or, more accurately, the authentication protocol can’t handle it. NTLM and Basic send only authentication information. So the token they send, are significantly smaller. Whereas, Kerberos includes information such as group membership and SID history information in the request’s header. Therefore, is sending a much larger authentication token. By default, the token size is 12000 bytes. So if the token size is larger, say 14kb, it will time out and cause the error. Roughly, this will allow a user to be in about 90 security groups before issues begin randomly occurring. The solution below will increase that to approximately 900 groups.
There are a few ways to resolve this problem. Configure IIS to use NTLM, Using the ip address of the WFE server instead of Host Names or configure IIS to accept larger token headers.
Configure IIS to use NTLM: Why this is bad – If you have enabled Kerberos for SharePoint authentication, you know it’s not an easy task to complete. Like most places I have worked, companies often times use SharePoint as a document repository full of sensitive information. There is heavy traffic and they needed to have increased security that Kerberos provides. Reducing the authentication to NTLM is counterproductive and decreasing the security that you painstakingly put in place.
Using the IP address: Why this is bad – This I do not really need to go into. Using the server name never makes sense. Migration to another server, DNS failure, exposing the name of your WFE is just bad planning.
Configure IIS to accept larger tokens: The right choice – This is a simple process of reconfiguring two registry parameters. It will need to be done on each of the WFE servers.
MS KB article explains all those settings: http:/
The 2 registry keys to fix this issue are:
Default Value: 16384
Min – Max Value to set: 64 – 65534 (64kb) bytes
Sets an upper limit for each header. See MaxRequestBytes. This limit translates to approximately 32k characters for a URL.
- Default value: 16384
Min-Max value to set: 256 – 16777216 (16MB) bytes
Determines the upper limit for the total size of the Request line and the headers.
Its default setting is 16KB.
- If this value is lower than MaxFieldLength, the MaxFieldLength value is adjusted.
Once that is configured, you will also need to update server’s the ability to use the larger token handler coming into the server.
A registry parameter is available to increase the Kerberos token size. For example, increasing the token size to 65 KB allows a user to be present in more than 900 groups. Because of the associated SID information, this number may vary.
To use this parameter:
1. Start Registry Editor (Regedt32.exe).
2. Locate and click the following key in the registry:
3. If this key is not present, create the key. To do so:
a. Click the following key in the registry:
b. On the Edit menu, click Add Key.
c. Create a Parameters key.
d. Click the new Parameters key.
4. On the Edit menu, click Add Value, and then add the following registry value:
- Value name: MaxTokenSize
Data type: REG_DWORD
Value data: 65535
5. Quit Registry Editor.
The other real solution is to clean up A.D. security groups. It’s a painful process if it has been unmanaged for to long, but critical to an enterprise level environment.