On 7/10/15 21:57, Simo Sorce wrote: >On 07/10/15 13:36, Pat Gunn wrote:
Hi, 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 settings). >Please read this before you proceed with your LB plan: >http://ssimo.org/blog/id_019.html > >HTH, >Simo. Hi, 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: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project