[Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Andrew Lau
Hi,

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.

Any suggestions?

Andrew
.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Alexander Bokovoy

On Wed, 14 Aug 2013, Andrew Lau wrote:

Hi,

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.

Any suggestions?

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
/etc/httpd/conf/ipa.keytab:

(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
its change.

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Andrew Lau
I followed your suggestions without much luck.

Adding the kerberos keytab didn't change anything, when I try login through
the UI it just redirects me again with the same notice:
Your session has expired. Please re-login.

However if I login with the incorrect details logs will show INFO: 401
Unauthorized: kinit: Client 'a...@domain.com' not found in Kerberos database
while getting initial credentials and the UI will give me an error message.

It seems when it's logged in with the correct credentials it's still
finding itself lost. I have a feeling I'm overlooking something so simple..

Andrew


On Wed, Aug 14, 2013 at 4:23 PM, Alexander Bokovoy aboko...@redhat.comwrote:

 On Wed, 14 Aug 2013, Andrew Lau wrote:

 Hi,

 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.

 Any suggestions?

 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
 /etc/httpd/conf/ipa.keytab:

 (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
 its change.

 --
 / Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Petr Vobornik

On 08/14/2013 08:00 AM, Andrew Lau wrote:

Hi,

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.

Any suggestions?

Andrew
.


Hi,

FreeIPA RPC API, which Web UI uses, requires http referer header to 
start with 'https://ipa.server.hostname/ipa'. Given that you are using 
proxy, I assume that the referer is different and might be a cause of 
the issue.


HTH
--
Petr Vobornik

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Andrew Lau
Any suggestions or workaround, short of having to switch the IPA's hostname
to use a public domain?

Andrew


On Wed, Aug 14, 2013 at 5:36 PM, Petr Vobornik pvobo...@redhat.com wrote:

 On 08/14/2013 08:00 AM, Andrew Lau wrote:

 Hi,

 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.

 Any suggestions?

 Andrew
 .

  Hi,

 FreeIPA RPC API, which Web UI uses, requires http referer header to start
 with 'https://ipa.server.hostname**/ipa'. Given that you are using
 proxy, I assume that the referer is different and might be a cause of the
 issue.

 HTH
 --
 Petr Vobornik

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Petr Vobornik

On 08/14/2013 10:36 AM, Andrew Lau wrote:

Any suggestions or workaround, short of having to switch the IPA's hostname
to use a public domain?


IDK if anyone did that, but you can try to change the header by the proxy.

You should change it only for the request with referer: 
'https://ipa.externaldomain.com/ipa' to keep to original logic [1] in place.


That means the proxy will work as man-in-the-middle and should have 
access to certificate for the external domain. Also, external users 
should not use FreeIPA browser configuration pages because of the 
different domain.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=747710



Andrew


On Wed, Aug 14, 2013 at 5:36 PM, Petr Vobornik pvobo...@redhat.com wrote:


On 08/14/2013 08:00 AM, Andrew Lau wrote:


Hi,

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.

Any suggestions?

Andrew
.

  Hi,


FreeIPA RPC API, which Web UI uses, requires http referer header to start
with 'https://ipa.server.hostname**/ipa'. Given that you are using
proxy, I assume that the referer is different and might be a cause of the
issue.

HTH
--
Petr Vobornik






--
Petr Vobornik

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] IPA Server UI Behind Proxy

2013-08-14 Thread Simo Sorce
On Wed, 2013-08-14 at 09:23 +0300, Alexander Bokovoy wrote:
 On Wed, 14 Aug 2013, Andrew Lau wrote:
 Hi,
 
 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.
 
 Any suggestions?
 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
 /etc/httpd/conf/ipa.keytab:
 
 (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
 its change.

FWIW please disregard these complicated instructions, just run
ipa-getkeytab on the server an pass -k /etc/httpd/conf/ipa.keytab
directly.
ipa-getkeytab will properly append the fetched keys to the keytab and no
further, error prone, manual merging will be necessary.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users