ADFS request URL too long error

  • 618 Views
  • Last Post 15 January 2017
kool posted this 11 January 2017

We occasionally see HTTP error 400 due to ADFS request headers being too long. The following article has a suggested fix:
https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-user-reported-symptoms(v=ws.10).aspx
It says to modify the http.sys registry settings on the ADFS servers (we are still running ADFS 2.x) to increase the size of the MaxFieldLength and MaxRequestBytes from their defaults of 16kb.

Has anyone else encountered this and made the registry changes? Any downside to doing this?

Upgrading to ADFS 4.0 is in the works but probably won't happen for a few months. I'm just trying to decide if it is worth making this change in the meantime. It is also unclear if this issue might persist with ADFS 4.0.

Thanks,

Eric


Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
joe posted this 11 January 2017

If you are having this problem, it may not be a reasonable solution to simply increase your max allowed headers in IIS/http.sys. The first thing I'd want to know is where all this extra cookie data is coming from.
If the issue is with the size of your SSO cookies, you might instead look to reduce the size of the issued claims on the CP side of your ADFS config. We found that the SSO cookies we got for ADFS 2 were far too large if we issued group SIDs for example. An increase in this size limit MAY fix the problem but you also have browser cookie size limits to worry about (this varies by browser but Safari is notorious for allowing much less cookie data in a request than other browsers so you typically want to engineer to it) and sometimes these things vary a lot by user if the claims data you issue is highly variable (groups again).
However, if the issue if with the dynamically generated adfs context cookies that are not properly getting deleted, you might instead try to figure out where those are coming from. This one is much more difficult to solve and won't necessarily be addressed by increasing the size limit either since some type of loop condition may be causing these to continue to generate and increasing the size on the server will just mean that the error will take slightly longer to manifest.
The size limits are there to help protect the user and the server. You really don't want the browser sending 15K of header data (mostly cookies) in every request.
My experience with ADFS v3 is that it fixed both of these issues so that's something to look forward to. I assume they did not reintroduce these issues in v4.
HTH!
Joe K.


show

gduke posted this 11 January 2017

We have ADFS 2012 R2 / v.3 using Shibboleth as an Identity Provider, in order to use our campus WebSSO to do auth for OWA. A number of users have been experiencing

perioding errors “Bad Request – Header Field Too Long.” We engaged premier support, and worked for a number of months — including maxing-out the header size limits, which didn’t appear to cause problems, but didn’t resolve the issue.

 

Eventually, we got to an escalation engineer who recognized this as a bug that affects ADFS when it uses an external IP.

 

“ ADFS failed to clear out sessionContext cookie leading to cookie bloat on the client which finally leads to IIS reaching its limits

on HTTP header size and resulting in a 400 error.”

 

The problem appears when you’re using another Identity Provider (‘shibboleth’).

 

Our case was added to a Design Change Request with other customers, but the request was eventually declined. :-/  On my short list is to deploy ADFS 2016 servers

to see the behavior changes.

 

--Geoff

 

Geoffrey Duke

802.656.1172 |

Sr Systems Administrator |

Enterprise Technology Services |

University of Vermont

 

 

 

show

barkills posted this 11 January 2017

Is there a KB documenting this bug?

 

show

gduke posted this 11 January 2017

Brian, I didn’t get a KB number. I’m happy to share the premier case number if that would be useful.  --Geoff

 

show

joe posted this 11 January 2017

As I recall, at the time we were having this problem frequently, we also had another identity provider in the mix although I cannot remember the exact details there either. I don't think it has anything to do with the IDP itself though as the cookie in question is generated by ADFS. As I recall, the context cookie is generated dynamically with a unique name (that contains a GUID) so that if it is created but not cleared, it is essentially stuck in the browser until that browser memory session gets destroyed. On many browsers, session memory survives browser restarts because session memory is stored in a separate process so this can be a real problem.
Having an HTTP capture (Fiddler or HTTPWatch) of a repro of this happening can be very helpful. The design MS used with a dynamically named cookie is kind of interesting because it allows you to have multiple logins happening at the same time with separate state/context, but ultimately it is very dangerous because the cookie may not be cleared if the login does not complete.
Joe K.


show

kool posted this 12 January 2017

Thanks gang, this has been really helpful. We, like Geoff, are using Shib as the Claims Trust Provider. There is a CTP rule to send all token groups, so this

definitely can be a large list for many users. Fortunately this does not happen a lot but this explains why clearing the browser cookie cache clears it up.

 

I do hope this is still fixed in v4 as we’d like to skip v3.

 

Thanks,

 

    Eric

 

show

gduke posted this 12 January 2017

Joe, that's exactly the condition and behavior we observed in the Fiddler traces. --Geoff


















show

ZJORZ posted this 15 January 2017

In the past we were also hit by the cookie size being too big causing the browser (IE) to break. This was due to the groupsid and the huge amount of groups for individual users. To solve that issue I designed a claims model that handles identity and especially authorization claims based upon AD groups. That worked magically and we have never seen that issue before In this case the IdP was “Active Directory” Met vriendelijke groeten / Kind regards, Jorge de Almeida PintoMVP Enterprise Mobility And Security | MCP/MCSE/MCITPMVP Profile | Blog | Facebook | Twitter Description: Description: Description: Description: Think Green 

show

Close