I recently worked on an interesting support case that I thought I would share. The customer was experiencing an issue only with certain AD accounts where they were being denied by TMG for all outbound web traffic.

The following was the scenario:

1.) The clients were Web Proxy Clients to TMG
2.) The web traffic access rule on TMG required authentication
3.) Only users that were in a large number of AD groups were affected by this
4.) Changing the Web traffic access rule to allow All Users resolved the issue (but this was not a long term solution)

The error that the client would see was:

HTTP/1.1 414 Request-URI Too Large (The size of the request header is too large. Contact your Forefront TMG administrator. )

I used a tool called HttpWatch to capture the attempt for a user that was experiencing the problem. (Since this is HTTP traffic, Netmon would have worked as well).

The first GET request to the test website results in a 407 because Proxy Authentication is required by TMG.

HTTP/1.1 407 Proxy Authentication Required (Forefront TMG requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )

The follow up GET request to the test website results in the error.

HTTP/1.1 414 Request-URI Too Large (The size of the request header is too large. Contact your Forefront TMG administrator. )

Clicking on the Stream tab in HttpWatch lets you see the raw request and also told me that 35326 bytes were sent to the TMG Server. That is a pretty large request.

The majority of this large size comes from the Proxy Authorization header and is a Kerberos token.

The default value of Maximum Headers Length (bytes) in TMG is set to 32768. You can read about HTTP Filtering and how to configure it in the following links:

http://technet.microsoft.com/en-us/library/dd897012.aspx

http://technet.microsoft.com/en-us/library/cc441511.aspx

So based on this we knew we had to change that value to something larger to accomodate the large size of this request. We set it to 65535 by modifying the HTTP Filter on the Enterprise rule that was allowing web access for internal users. This, however, did not resolve the issue.

What we did not realize is that TMG uses the most restrictive value between the Array and the Enterprise values set in the HTTP Filter. The Enterprise rule was the one that actually showed up in Live Logging as the rule that was Denying the large request so you would naturally assume that is the one that needs to be modified. Unfortunately that is not the case. Modifying the HTTP filter at the array level to 65535 resolved the issue. Even if you do not have an Array level access rule at all, the default value will still take precedence. You will need to at least create a dummy rule that will allow you to modify the Maximum Headers Length value of the HTTP Filter.

Another workaround is for the problem clients to use NTLM. This can be achieved by changing the settings in IE to use the IP address of TMG instead of the FQDN. This should only be used as a last resort as Kerberos is much more efficient.

http://blogs.technet.com/b/isablog/archive/2008/06/26/understanding-by-design-behavior-of-isa-server-2006-using-kerberos-authentication-for-web-proxy-requests-on-isa-server-2006-with-nlb.aspx

I hope that the above blog will save you time and effort.