You’re browsing a website in your organisation and some internal users are getting an ‘error 400’ error. There doesn’t seem to be any commonality between people that are and aren’t getting the problem. This one can be quite frustrating and not easy to troubleshoot. You sometimes can work out that it’s typically users that’s been with a company for a while but not always. What I’ve found to be the culprit in most cases is an easy fix.
Where there is a large number of Active Directory groups you may come across this issue before. Hence why it’s normally happening with people with the company for a while, because of their longevity they’ve been added to lots of groups over the years and not been removed. It could also be new users like personal assistants or secretaries because they belong to a lot of groups, or even more likely, IT staff that are in a lot of groups as well as their equivalent development/UAT/testing groups. It can depend a lot on the environment you work in.
327825 Problems with Kerberos authentication when a user belongs to many groups
The Fix:
An easy fix is to add the two entries below to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters on your IIS server and reboot.
| Name | Value Type | Value Data |
| MaxFieldLength | DWORD | 65534 |
| MaxRequestBytes | DWORD | 16777216 |
This does allow http.sys to use more memory though and performance should be monitored, especially in large user environments as well as any security precautions that should be considered.
Another way around error 400 when it’s caused by group membership, is to limit the groups that each user has. You may already know the pain though and how difficult this can be in large organisations. Especially where there are multiple IT departments or groups that have access to Active Directory changes.