On Wed, 14 Aug 2013, Andrew Lau wrote:
I've got my FreeIPA setup in an internal infrastructure, but I want to be
able to have users access the web UI externally. I tweaked the
ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a
nginx reverse proxy and port forwarding, both works if the client manually
sets the host name of the IPA server eg. ipa01.internaldomain.local in
their /etc/hosts file. However if the client tries to to use eg.
ipa.externaldomain.com with the same port forwarding or nginx proxy config,
it'll silently error. The docs briefly touches on this - but doesn't really
give much to go on.
Couple considerations here.
First, you may need to play with debug level to see what principal
mod_auth_kerb picks up when negotiation happens.
Second, using Kerberos authentication requires both sides to own
Kerberos principals for authentication process to go. Browsers select
HTTP/server.fqdn as their target service principal when connection to
the server.fqdn. Your IPA server only has HTTP/ipa01.internaldomain.local
in its keytab in /etc/httpd/conf/ipa.keytab, which means it would only
be able to respond on ipa01.internaldomain.local to Kerberos auth requests.
A way to fix this is by making HTTP/ipa.externaldomain.com service in
IPA (ipa service-add HTTP/ipa.externaldomain.com) and then use
'ipa-getkeytab' to fetch the keytab with the key for the service. Next
step would be to merge content of this keytab with
(echo rkt /tmp/external.keytab; echo wkt /etc/httpd/conf/ipa.keytab) |ktutil
Then restart httpd -- I'm not sure mod_auth_kerb re-reads the keytab on
/ Alexander Bokovoy
Freeipa-users mailing list