From rcritten at redhat.com Wed Aug 28 15:34:09 2019 Content-Type: multipart/mixed; boundary="===============3075082251796336767==" MIME-Version: 1.0 From: Rob Crittenden To: freeipa-users at lists.fedorahosted.org Subject: [Freeipa-users] Re: sub domain/zone on separate network segment Date: Wed, 28 Aug 2019 11:33:22 -0400 Message-ID: In-Reply-To: CAGdKLmVi7YwjmewFYEsLARbM=0GfH6m79SeiKTBp3xAAX7M04Q@mail.gmail.com --===============3075082251796336767== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Fran=C3=A7ois Cami via FreeIPA-users wrote: > On Wed, Aug 28, 2019 at 5:08 PM Markus Larsson via FreeIPA-users > wrote: >> >> >> >> On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users wrote: >>> On 28/08/2019 15:15, Markus Larsson via FreeIPA-users wrote: >>>> I might be wrong here but it sure looks like the cert is being >>>> rejected because the name on service doesn't match the cert. >>>> I'm not at a place where I could check but it looks like that to me. >>>> >>>> BR >>>> Markus >>>> >>>> >>>> On 28 August 2019 16:11:17 CEST, lejeczek via FreeIPA-users >>>> wrote: >>>> >>>> hi guys >>>> >>>> Would a subdomain on a separate subnet (from which nodes do not >>> have >>>> access to IPA's IPs) to which IPA is connect via "secondary" >>> ifaces, >>>> have clients successfully install and connect? >>>> >>>> I've crafted a sub domain/zone with, I think, all the records >>> required >>>> and those point to IPAs "secondary" IPs and when I install >>> clients they >>>> fail: >>>> >>>> ... >>>> >>>> Do you want to download the CA cert from >>>> http://ipa2.subdomain.private.freeipa/ipa/config/ca.crt? >>>> (this is INSECURE) [no]: yes >>>> Downloading the CA certificate via HTTP, this is INSECURE >>>> Successfully retrieved CA cert >>>> Joining realm failed: libcurl failed to execute the HTTP POST >>>> transaction, explaining: Problem with the SSL CA cert (path? >>> access >>>> rights?) >>>> >>>> Installation failed. Rolling back changes. >>>> ... >>>> >>>> Still the same client: >>>> >>>> $ curl http://ipa2.subdomain.private.freeipa/ipa/config/ca.crt >>>> >>>> >>>> 301 Moved Permanently >>>> >>>>

Moved Permanently

>>>>

The document has moved >>> >>> href=3D"http://ipa2.private.freeipa/ipa/config/ca.crt">here.

>>>> >>>> >>>> That host in returned URL above is where IPA top domain lives, >>> but nodes >>>> on the subnet cannot access there. >>>> >>>> This fails by design and what I'm trying will not work? Or it's >>> doable >>>> and I'm only missing something? >>>> >>>> If that is how IPA currently works(or rather doesn't) then is >>> this >>>> something that may get included/fixed in the future? >>>> >>>> many thanks, L> >>>> >>>> >>> Would it mean that each new subzone needs to have a bunch of >>> services(on >>> top of DNS) created for stuff as basic as nodes/clients want to >>> use/join >>> that subzone? >>> >>> My case may be bit different from a regular - IPA top level domain =3D> >>> subdomain but only with one simple fact that subdomain is on the subnet >>> which has no connection to IPA top level domain subnet (other than IPA >>> servers are connected to both subnets directly) - but would this one >>> thing be such a big impediment? >>> >>> I thought that what I'm doing is not that unusual and many have done it >>> before and that IPA is prepared for this scenario. >>> >>> p.s. I'm on Centos' 4.6.4 version. >>> >>> thanks, L. >>> >> >> Now that say that I'm probably mistaken. The certs should work given tha= t the ipa server has the same name just a different IP when coming from thi= s network. > = > That's split horizon DNS. > = >> If it has a different DNS name then cert work is needed. > = > The OP said "sub domain/zone" so the IPA servers would be named different= ly. In addition I believe that API requests will be rejected due to mismatching Referer headers. I believe Alexander has a WIP patch on that somewhere. rob --===============3075082251796336767==--