On 7/10/15 21:57, Simo Sorce wrote:
>On 07/10/15 13:36, Pat Gunn wrote:
I'm trying to build a cluster of 3 IPA (staging at this point, but
eventually later I'll make a prod version)
systems (that will reside in AWS) that will manage select systems in our
infrastructure (mostly but not entirely in AWS).
The systems will be fronted (like most of our infrastructure) with a
load-balancer that manages pooling and SSL termination; we'd like
freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will
then route that to a specific one of the three servers based on pool
>Please read this before you proceed with your LB plan:
I spoke imprecisely. In our hoped-for design, our LB
will front access to the web interface for FreeIPA (to manage accounts
when needed), but the systems that will use FreeIPA for auth will be
contacting the servers directly (we care much more about the LDAP
functionality and the GUI than anything else, FWIW).
I think I at least identified the initial problem we're having - when
the auth is first posted, it succeeds, and the server sends a
Set-Cookie for ipa_session that unfortunately includes "Domain="
equivalent to the hostname. This seems unaffected by the Tomcat
convention for specifying a proxy as well as setting the host in
Apache. I could tell our LB to rewrite that cookie as it comes out of
the pool, but I'm hoping to figure out how to get FreeIPA's WebUI to
not set the Domain for that cookie or to set it to a specified value,
and to do that for only the WebUI.
I'm hoping our desired use case and existing infrastructure style
isn't incompatible with what FreeIPA is designed for. Any thoughts on
that or advice on getting that cookie sent as we like?
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project