Reverse-Proxy incorrectly formatted calls to api (400 error)

[gunderwood]

Hi,

I have been trying to configure a reverse proxy for a back-end embedded IIS server. The back-end is a Power BI Report Server. The Apache server is version 2.4.43. Looking at comparable traces between a direct call that is successful and going through the reverse proxy where I am getting 400 errors there are the following differences. All the errors are api calls that are throwing the errors. Once the page hits the 400 error the BE throws an error message and stops loading.

Example 400 response: GET /reports/api/v2.0/System/ReportServerRelativeUrl HTTP/1.1" 400 - "https://..."


- “br” is added to the Accept-Encoding header
- The following headers are added:
sec-ch-ua header
sec-ch-ua-mobile header
sec-ch-ua-platform header
sec-Fetch-Site header
sec-Fetch-Mode header
sec-Fetch-Dest header

I have tried to use the "Header always unset" without success. The following modules are in the httpd.conf file.

LoadModule log_config_module ${APACHE_INSTROOT}/modules/mod_log_config.so
LoadModule status_module ${APACHE_INSTROOT}/modules/mod_status.so
LoadModule setenvif_module ${APACHE_INSTROOT}/modules/mod_setenvif.so
LoadModule version_module ${APACHE_INSTROOT}/modules/mod_version.so
LoadModule mime_module ${APACHE_INSTROOT}/modules/mod_mime.so
LoadModule unixd_module ${APACHE_INSTROOT}/modules/mod_unixd.so
LoadModule autoindex_module ${APACHE_INSTROOT}/modules/mod_autoindex.so
LoadModule alias_module ${APACHE_INSTROOT}/modules/mod_alias.so
LoadModule env_module ${APACHE_INSTROOT}/modules/mod_env.so
LoadModule socache_shmcb_module ${APACHE_INSTROOT}/modules/mod_socache_shmcb.so
LoadModule negotiation_module ${APACHE_INSTROOT}/modules/mod_negotiation.so
LoadModule include_module ${APACHE_INSTROOT}/modules/mod_include.so
LoadModule dir_module ${APACHE_INSTROOT}/modules/mod_dir.so
LoadModule headers_module ${APACHE_INSTROOT}/modules/mod_headers.so
LoadModule authz_core_module ${APACHE_INSTROOT}/modules/mod_authz_core.so
LoadModule authz_host_module ${APACHE_INSTROOT}/modules/mod_authz_host.so
LoadModule proxy_module ${APACHE_INSTROOT}/modules/mod_proxy.so
LoadModule proxy_http_module ${APACHE_INSTROOT}/modules/mod_proxy_http.so
LoadModule proxy_balancer_module ${APACHE_INSTROOT}/modules/mod_proxy_balancer.so
LoadModule lbmethod_byrequests_module ${APACHE_INSTROOT}/modules/mod_lbmethod_byrequests.so
LoadModule lbmethod_bybusyness_module ${APACHE_INSTROOT}/modules/mod_lbmethod_bybusyness.so
LoadModule slotmem_shm_module ${APACHE_INSTROOT}/modules/mod_slotmem_shm.so
LoadModule filter_module ${APACHE_INSTROOT}/modules/mod_filter.so

Any help is appreciated!

[gunderwood]

The fix was adding this snippet to our backend servers allowing both Basic and NTLM. I think we may have this beat. :-)

<Authentication>
<AuthenticationTypes>
<RSWindowsBasic>
</RSWindowsBasic>
<RSWindowsNTLM />
</AuthenticationTypes>
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

[robzilla]

That's great! :-)

[phranque]

With basic auth, however, I suppose Apache would have to request the credentials from the client when a request is made, and then forward those to the backend (I've never done this myself).

basic auth works more like this:
- when the server sees that the requested resource requires basic auth, a 401 status code is returned with the response along with a specification of the "Realm" of the resource
- when the user agent detects the HTTP Response with a 401 status code and Realm specification, it sees that as an authentication challenge and provides the visitor with a user name/password dialog box
- the user agent resends the request with authentication headers and also resends these headers after subsequent 401 responses in the same Realm

[robzilla]

Cheers phranque. I never thought to look into the specifics, but that's interesting.

[gunderwood]

Hi robzilla,

Yes the reverse proxy is currently working with basic authentication with the back-end responding with an authorization challenge (username/password). Next step is to configure Kerberos to hopefully remove the 2nd authorization challenge that has popped up after changing the default authorization method.

So with basic authentication the user must enter a 2FA challenge with username/Yubikey/Pin and then username/password.