7

I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?

Riz
  • 6,486
  • 19
  • 66
  • 106
  • This generally happens because there's too many cookies. Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem. – Saca Jan 07 '17 at 18:35
  • Is your issue happening consistently for ALL users ONLY when MFA is turned on? If so, can you include more details about the request that works vs the request that fails? Probably including both raw requests would be very helpful (just make sure you scrub them for PII, passwords, etc). – Saca Jan 07 '17 at 18:38
  • @Saca thanks, this seemed to be the issue. if you can provide an answer, I can mark it as such. – Riz Jan 09 '17 at 21:26
  • Possible duplicate of [Azure Portal: Bad Request - Request Too Long](https://stackoverflow.com/questions/46100272/azure-portal-bad-request-request-too-long) – Saca Jun 23 '19 at 22:57

3 Answers3

4

The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.

Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.

Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.

Saca
  • 10,355
  • 1
  • 34
  • 47
  • 1
    So what you're saying is: "Don't use too much microsoft products at once." That doesn't seem to be a real solution to me. As we are using the AzureAD SSO, but we also need to login to the azure portal (on multiple environments testing, live, several clients, etc.), we also use office365, some of us use hotmail/outlook. So we're stacking up cookies by simply using multiple environments or apps. – robbe clerckx Dec 07 '17 at 09:35
  • While far from ideal, this is a valid answer, especially given system constraints. It explains what's going on and provides workarounds. Until the product is enhanced to address this (via [custom domains](https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15334317-customer-owned-domains)), this is THE answer. You shouldn't penalize a valid answer simply because you don't like it. – Saca Dec 08 '17 at 08:13
  • 3
    Ok, it does provide a workaround, that much is true. In any case I'm glad I don't have to do customer support and answer 500 e-mails/phone calls a day just to say: "Dear client, clear your cookies, you'll only be logged out everywhere, nothing to worry about." :) – robbe clerckx Dec 08 '17 at 08:36
0

Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.

I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.

Larry Aultman
  • 301
  • 2
  • 10
0

We just encountered this issue today and I wanted to add this in case it is helpful.

  1. Once you log into the Azure Portal, go to - Azure Active Directory - App Registrations - {Your application} - Manifest

  2. Scroll down until you find the property: groupMembershipClaims

  3. In our case, this was set to "All" on the application which was throwing the 400 error about the request header(s) being to large.

Solution

Changed the manifest to hold a value of "DirectoryRole, ApplicationGroup" but this could be modified to hold whatever you deem necessary for your application. "All" was producing a cookie that was very large if the user belonged to many user groups, once this change was made in Azure, I had to clear my browser cookies and re-authenticate and all worked with no issues.

Ryan Wilson
  • 10,223
  • 2
  • 21
  • 40