From peljasz at yahoo.co.uk Wed Aug 28 14:48:05 2019 Content-Type: multipart/mixed; boundary="===============9071397965406258150==" MIME-Version: 1.0 From: lejeczek To: freeipa-users at lists.fedorahosted.org Subject: [Freeipa-users] Re: sub domain/zone on separate network segment Date: Wed, 28 Aug 2019 15:47:35 +0100 Message-ID: <5165ddf3-bf23-c096-8a0e-33f04640e1cb@yahoo.co.uk> In-Reply-To: 6AF11831-840C-4E8B-9FFF-270583867B90@uidzero.se --===============9071397965406258150== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 th= ey > 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:=C2=A0 Problem with the SSL CA cert (path? ac= cess > rights?) > =C2=A0 > 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 no= des > 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. > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.= org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code= -of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users= (a)lists.fedorahosted.org --===============9071397965406258150== Content-Type: application/pgp-keys MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pEpkey.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUVOQkZ4QTIrb0JDQURORXRq aldKMDdXdEhQSWF6NzNvS2dhWFdPQmlQTURwWWlGcWZ3cXVKZVU0dzRNa2IzCitodXpBZm1NUnZw YVd5b2MwSGVJbmt3ZDBJRWVIZFZGamVMdVJVSFFOQ0l1amp3bFRuSStFZS9CbUNZUmY0RDgKak1q dlp2TmNIaDFRTE9uMlVVNmROc1FNbEYxMFlxWlByd1hXOVg3VEE2N0lzVEM4bjU4a09JMzlndi80 RDVhZwpOYmhVcmcyYzhPWkQ4NW1pWFcxSVhzazNlN3dpcU54UW1oS2JUM2NibVBwSmZHZi9STjFV Uklhdm5oa0xzNFJRCmJMK1VGejJ0OGZ2WDVpNzJ6TVFZYkNqSmt2a2F0Rkp1QWJ6YlVuMFpSTUZr SkpRSG9rT1JTekpJczFudjVrUEMKQmlrU25iajRBSTVmY3VFanBUSnluUVJqOXYyejJlNFFRb2hC QUJFQkFBRzBIbXhsYW1WamVtVnJJRHh3Wld4cQpZWE42UUhsaGFHOXZMbU52TG5WclBva0JWQVFU QVFnQVBoWWhCSk1GbnlRZTd1SFFkcHFGOUZXUmlyOGhJazY2CkJRSmNRTnZxQWhzREJRa0I0VE9B QlFzSkNBY0NCaFVLQ1FnTEFnUVdBZ01CQWg0QkFoZUFBQW9KRUZXUmlyOGgKSWs2NkJ4VUlBSWZm bFNWQ2NYanFRbFFndVZaR0Y4Vys5V2hnV2pYQSswdDFvOGhDVGxLNmVqcGVVM3cyMTZ4eApWSm5Z bFR2MVE5b0luZExUMHM3UTJqNU8zM296UUZNQUU5SlNkbk9jNVg2VHhESDZqazdZNUV0Y252cmlY eVQvCnp3SWZDVGpVV1NWeWVzak5aZGlkNis3R3Fkb1BzTGpnZ3JGR2x5UnZOZnRXeHZ0NnloaEtK ZmJacWZtVmwwZ2cKdzJROVFWd1liTmYycVA4bHljWjhRNGVNQXA2NVRkQXRsNUlrL1hqZGpnSjha RTFYb1pvU1hUV1FZVmRmSnJtYgpnWWs1NWE0WjdQTTdMS3haSzRPc0xEczhTcHFzYlV3VlNXOFFL dDVueGQ2ZXNwdnViZ1J1dENyc2M4RENuRmI0CjRIOHhFWmdJd1FLemhPdC91bGYrUUVQMm9wNFcw L3U1QVEwRVhFRGI2Z0VJQUsycDE5eGtDT2VoeE93T05sS2wKL2JNbzRCb3Y0d2ZTdzhDSW11VjVB QlY4MGFjU2FoS2Y1aFg5cVB5eE5sN0pLYVdVKzVnbnRBM20ralVFYm9icwptUkR2a3dpM1NMTGg5 Zklxbjh5djdKdEVLemd4U2hXdE9vUHNpbEQxWXR6N0QzSFlab2Y0bXJyWUk2RlFyUjNJCmVZWVZr eUZLT0xjRTFxNzB2eXVFR3N4Qzk2bEYrbjdhandrNzhuWFl2U3luSzhsNXBtRWIxREwxdVFuYkxV Z2EKMEtYbVZ4Q1ZtcWJ2QTMxbmNUOFdWcmZrNGYxVFZRVENwb2FLT1RCb1NNekZUUUxoZ2lPQjRL Tms2V2orczZ2UQpoOTZoYm1paVpaWUFEYlpoNzNIRG9rV29BelY2amYzVUdlSVBsYXZrQnVWVzNP SFVnZ1I2UEIwSk0wSE1vbzV6Cngva0FFUUVBQVlrQlBBUVlBUWdBSmhZaEJKTUZueVFlN3VIUWRw cUY5RldSaXI4aElrNjZCUUpjUU52cUFoc00KQlFrQjRUT0FBQW9KRUZXUmlyOGhJazY2RWw0SC8y NS9vc1h0bmppRnd3ajVQcWI0VEVIbE1oK0p6ZTB6TFpNTApKK2xJL0srMDd1OURoUTladHd4eVpa bFRSSU5aRG9xUVluTW9iNHRXWFV0SG5ncXdHblNQL1pKa21TMlVxdW9iCjc2YUV5WW0wZnlFZXE2 N2orbzE1bzJhdGpDQWNmV3ZiTXhyYTAvYzJKVHpQMHdNS1RTdGJzTVpyVEZSRk0xd0UKRGZmUjlI QTlqSVcrdzJKZ3J1OS9hd2Q5SFgrMHEvVWNNUVEyait2ZnhqbTM0NWxFUUhjZWVVZ1R3ZjNUemRY ZwpGcGREMy9UMkhZSFdrQm04VFpHZGdaRFpCK2tqOElNS01TQTcyajI4RjFVaWxIUXVGZmRBRDdN OVVYVndpTUZaCjNUZmV4anY5T1BhNHdFREM5WjlZY1lPcG9pbWdOUkFXMlpLN0psQWdJYmtlam9S RkhwZz0KPUlpRmkKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo= --===============9071397965406258150==--