FreeIPA behind HTTP proxy with different hostname
Table of Contents
The FreeIPA server provides Web user interface to its administrators and users. When the interface needs to be accessible across DMZ or in general from different network, the HTTP proxy might have different hostname than the FreeIPA server itself. Then the HTTP proxy needs a couple of special configuration tweaks to satisfy FreeIPA's requirements.
Assume we have FreeIPA server in internal network, named
We want to provide access to its Web user interface to users
outside of that internal network, and we will set up HTTP proxy
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
virtual host in
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
We can now access the proxy on
https://webipa.example.com/ and we should see our
browser redirected to
and the logon page shown.
Attempting to log in
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, we will see message
and we do not get logged in.
The reason for this is the HTTP cookie handling ― the FreeIPA
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
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
service, we can retry the logon attempt. This time we will get
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://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
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>
Accessing the server via HTTP or via different name
In our example we have set up the proxy to access the FreeIPA
server using its proper hostname
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.