Assume we have FreeIPA server in internal network, named ipa.int.example.com. We want to provide access to its Web user interface to users outside of that internal network, and we will set up HTTP proxy webipa.example.com for that.

If the HTTP proxy is running on Fedora, we will install the necessary packages with

webipa# dnf install -y httpd mod_ssl

For production setup, we might want to get proper certificates issued, for this testing setup we will just use the autogenerated self-signed defaults.

We will configure the proxy in the _default_:443 virtual host in /etc/httpd/conf.d/ssl.conf:

SSLProxyEngine on
ProxyPass / https://ipa.int.example.com/
ProxyPassReverse / https://ipa.int.example.com/

We can then enable and start the Apache HTTP Server service:

webipa# systemctl enable httpd
webipa# systemctl restart httpd

If the FreeIPA server is on internal network, the proxy which might be in demilitarized zone might not be able to resolve its internal hostname (to get its IP address). In that case, we might need to set it up locally, for example in /etc/hosts.

We can now access the proxy on https://webipa.example.com/ and we should see our browser redirected to https://webipa.example.com/ipa/ui/ and the logon page shown.

We got the proxy working and we see the logon page which came from the FreeIPA server but when we now enter login and password and hit Login, we will see message

and we do not get logged in.

The reason for this is the HTTP cookie handling ― the FreeIPA server uses cookies for domain ipa.int.example.com and the Set-Cookie header value might be

ipa_session=d98d6801e791e116899bdd51f7d186f8; Domain=ipa.int.example.com; Path=/ipa; Expires=Sun, 05 Jun 2016 08:49:23 GMT; Secure; HttpOnly

Since the request that the browser sent was for webipa.example.com, the cookie does not domain-match and will be ignored by the browser and not sent with subsequent HTTP requests.

We can extend the configuration with directive which will map the cookie domain values:

ProxyPassReverseCookieDomain ipa.int.example.com webipa.example.com

After restarting the httpd service, we can retry the logon attempt. This time we will get error

We are certain that we have browser set up to send the HTTP referer header but that header does not reach the FreeIPA server. Why? The referer as seen by the browser is https://webipa.example.com/ipa/ui/, not https://ipa.int.example.com/ipa/ui/, and the FreeIPA server is checking for the exact hostname match.

We need another mapping in the configuration, this time for the HTTP request's Referer header:

RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa.int.example.com/

We change the referer value sent by the browser to the value that the FreeIPA server wants to see. After another httpd service restart, we are now able to log in and use FreeIPA server's Web UI.

The configuration change that needs to be done to configure HTTP proxy which will use different hostname than the real FreeIPA server can be summed up as

<VirtualHost _default_:443>
# ...
# add the following directives
SSLProxyEngine on
ProxyPass / https://ipa.int.example.com/
ProxyPassReverse / https://ipa.int.example.com/
ProxyPassReverseCookieDomain ipa.int.example.com webipa.example.com
RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa.int.example.com/
</VirtualHost>

In our example we have set up the proxy to access the FreeIPA server using its proper hostname ipa.int.example.com and using its prefered protocol HTTPS. Should we want to make the connection via HTTP, or use different hostname in the proxied request (for example IP address), we might need to do some additional changes in the FreeIPA server's configuration so that it does not attempt to "fix" the incorrect requests. Example can be found in writeup about FreeIPA behind SSL proxy.