Troubleshooting: SP-Initiated Realm Gives a 404 Error (404.15 - Query String Too Long)

Version Affected: All
 
 

Overview

When a Service Provider (SP) initiates Security Assertion Markup Language (SAML) authentication by redirect into a SecureAuth realm, the realm can return a 404 error even though browsing to the same realm directly works fine. The Internet Information Services (IIS) log shows the full error code as 404.15 — "The Request Filtering module rejected a request with a too long query string." This happens because the SP's AuthnRequest, and any other parameters it sends in the redirect, exceed a query string or URL length limit. SecureAuth has seen this triggered by several SPs, including Salesforce1 (whose SAML request is unusually large) and Azure.

This error has two independent causes, and both may need to be checked:

• See Cause 1 - The IIS Request Filtering module's own query string/URL length limit is too low.
• See Cause 2 - The .NET httpRuntime's query string/URL length limit — a separate, independent limit — is too low.

These causes are not related, so raising one limit will not fix the other if it's also too low.

 

In this article

• Cause 1: The IIS Request Filtering Limit Is Too Low
• Cause 2: The .NET httpRuntime Limit Is Too Low

Cause 1: The IIS Request Filtering Limit Is Too Low

IIS's Request Filtering module enforces its own maximum query string and URL length (system.webServer/security/requestFiltering), independent of anything in the realm's own web.config. If an SP's request exceeds this limit, IIS rejects it before it ever reaches the SecureAuth application, logging error 404.15.

To resolve this:

1. Open IIS Manager.
2. Navigate to the Default Web Site (or a specific realm, if you want to scope the change to just that realm).
3. In the Features View, click Configuration Editor.
4. Change the Section to system.webServer/security/requestFiltering.
5. Expand requestLimits and increase maxQueryString(4096) and maxUrl(8192).
   
   
    
6. Apply the changes.
7. Repeat the change on any other IdPs.

Cause 2: The .NET httpRuntime Limit Is Too Low

Separately from IIS's Request Filtering module, the httpRuntime element in the realm's own web.config enforces its own maxQueryStringLength and maxUrlLength. Even after raising the IIS-level limit in Cause 1, the same 404 error can still occur if this separate .NET-level limit hasn't also been raised.

To resolve this:

1. Open the SecureAuth Admin Console and log in, then click Go to Advanced Settings.
   
   
    
2. Click Admin Realm.
   
   
    
3. Select the realm having the issue from the realm list, then click the System Info tab.
   
   
    
4. Click Decrypt.
   
   
    
5. Open File Explorer and browse to D:\SecureAuth\SecureAuthXXX, where XXX is the number of the realm having the issue.
   
   
    
6. Open web.config in Notepad or your usual text editor.

7. Find the httpRuntime element and add or increase maxQueryStringLength to at least the value set in Cause 1, or larger:

   <httpRuntime enableVersionHeader="false" requestValidationMode="2.0" targetFramework="4.7.2" maxQueryStringLength="4096" />

    

8. If the issue isn't resolved, also add maxUrlLength

   <httpRuntime enableVersionHeader="false" requestValidationMode="2.0" targetFramework="4.7.2" maxUrlLength="8192" maxQueryStringLength="4096" />

    

9. Test that the realm is working properly again.

Special Considerations

It's best practice to keep these limits as small as possible to reduce the attack surface for injection attacks. If you can get the SP or app vendor to reduce the size of their request instead, that's the better approach.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.