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

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • 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

    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 and maxUrl.

      IIS Configuration Editor showing the system.webServer/security/requestFiltering section, with requestLimits expanded to show maxQueryString set to 4096 and maxUrl set to 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.

      SecureAuth Admin Console user menu showing the Admin name, a Go to Advanced Settings link, and a Log Out link.
       
    2. Click Admin Realm.

      SecureAuth Admin Console top navigation bar showing the Admin Realm and Access Control tabs.
       
    3. Select the realm having the issue from the realm list, then click the System Info tab.

      SecureAuth Admin Console realm tab bar with Post Authentication, API, Logs, System Info (highlighted), and Logout.
       
    4. Click Decrypt.

      System Info panel showing the SecureAuth Version field and a Decrypt button.
       
    5. Open File Explorer and browse to D:\SecureAuth\SecureAuthXXX, where XXX is the number of the realm having the issue.

      Windows File Explorer showing a realm folder's contents, including TrustedSite.aspx, User.aspx, User.aspx.vb, user_xrds.aspx, web.config, and web-admin-ui.
       
    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.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.