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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://ipa2.private.freeipa/ipa/config/ca.crt">here</a>.</p> </body></html>
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>
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 freeipa-users@lists.fedorahosted.org 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
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://ipa2.private.freeipa/ipa/config/ca.crt">here</a>.</p> </body></html>
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>
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 freeipa-users@lists.fedorahosted.org 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://ipa2.private.freeipa/ipa/config/ca.crt">here</a>.</p> </body></html> 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 => 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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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@lists.fedorahoste...
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 freeipa-users@lists.fedorahosted.org 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://ipa2.private.freeipa/ipa/config/ca.crt">here</a>.</p> </body></html> 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 => 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.
You might search the archive for answers, IIRC others have tried this in the past. What you are doing is multi-homing. Remember that IPA is name-sensitive. Each NIC has its own name but a host can have only one.
Don't confuse this with subnets, zones or anything else. From the IPA perspective you are trying to have one host have multiple names (which isn't in itself that unusual).
You could experiment with adding SAN for the certs and Kerberos principal aliases, but this isn't really a configuration that the IPA team tests.
rob
On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users freeipa-users@lists.fedorahosted.org 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 freeipa-users@lists.fedorahosted.org wrote:
hi guys Would a subdomain on a separate subnet (from which nodes do nothave
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 recordsrequired
and those point to IPAs "secondary" IPs and when I installclients 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <ahref="http://ipa2.private.freeipa/ipa/config/ca.crt%22%3Ehere</a>.</p>
</body></html> 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'sdoable
and I'm only missing something? If that is how IPA currently works(or rather doesn't) then isthis
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 => 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 that the ipa server has the same name just a different IP when coming from this network. If it has a different DNS name then cert work is needed. Another option to consider is to have a directory server on that subnet.
I realise now that I might be rambling so I better summarize, what does DNS records for the ipa server look like on that subnet?
Br M
On Wed, Aug 28, 2019 at 5:08 PM Markus Larsson via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users freeipa-users@lists.fedorahosted.org 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 freeipa-users@lists.fedorahosted.org wrote:
hi guys Would a subdomain on a separate subnet (from which nodes do nothave
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 recordsrequired
and those point to IPAs "secondary" IPs and when I installclients 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <ahref="http://ipa2.private.freeipa/ipa/config/ca.crt%22%3Ehere</a>.</p>
</body></html> 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'sdoable
and I'm only missing something? If that is how IPA currently works(or rather doesn't) then isthis
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 => 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 that the ipa server has the same name just a different IP when coming from this 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 differently.
Another option to consider is to have a directory server on that subnet.
I realise now that I might be rambling so I better summarize, what does DNS records for the ipa server look like on that subnet?
Br M _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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@lists.fedorahoste...
On 28 August 2019 17:12:43 CEST, "François Cami via FreeIPA-users" freeipa-users@lists.fedorahosted.org wrote:
On Wed, Aug 28, 2019 at 5:08 PM Markus Larsson via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users
freeipa-users@lists.fedorahosted.org 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 freeipa-users@lists.fedorahosted.org wrote:
hi guys Would a subdomain on a separate subnet (from which nodes donot
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 recordsrequired
and those point to IPAs "secondary" IPs and when I installclients 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <ahref="http://ipa2.private.freeipa/ipa/config/ca.crt%22%3Ehere</a>.</p>
</body></html> 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? Orit's
doable
and I'm only missing something? If that is how IPA currently works(or rather doesn't) then isthis
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
=>
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
that the ipa server has the same name just a different IP when coming from this network.
That's split horizon DNS.
Correct. Which will be needed if he/she doesn't want to add alternate names to the certs. While split horizon can be problematic it is sometimes needed. Then again adding SAN to the certs is probably better.
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 differently.
Well OP said the machines that would be joined would be on a different network and in a different subnet.
Another option to consider is to have a directory server on that
subnet.
I realise now that I might be rambling so I better summarize, what
does DNS records for the ipa server look like on that subnet?
Br M _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@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@lists.fedorahoste... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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@lists.fedorahoste...
François Cami via FreeIPA-users wrote:
On Wed, Aug 28, 2019 at 5:08 PM Markus Larsson via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users freeipa-users@lists.fedorahosted.org 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 freeipa-users@lists.fedorahosted.org wrote:
hi guys Would a subdomain on a separate subnet (from which nodes do nothave
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 recordsrequired
and those point to IPAs "secondary" IPs and when I installclients 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <ahref="http://ipa2.private.freeipa/ipa/config/ca.crt%22%3Ehere</a>.</p>
</body></html> 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'sdoable
and I'm only missing something? If that is how IPA currently works(or rather doesn't) then isthis
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 => 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 that the ipa server has the same name just a different IP when coming from this 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 differently.
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
On 28/08/2019 16:33, Rob Crittenden via FreeIPA-users wrote:
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.
@devel A-team (I'm serious) - I realize that in a number of places you guys said that dns "views" are not going to be implemented.
But at least what I'm trying to do - 10.10.0.0/24 top level IPA (same one box) IPA subdomain 10.10.1.0/24 - and I'm sure many already have and others will keep on asking, as I'm assure that when any admin reads this: https://www.freeipa.org/page/DNS and:
"... It is perfectly fine to configure certain DNS zones to respond only to clients in certain subnets or to apply other kinds of access control. For internal names you can use arbitrary sub-domain in a DNS sub-tree you own, e.g. int.example.com..."
first which comes to mind is most likely - to try what I'm trying now.
So, it would be fantastycznie! if future IPAs accounted and provided for this scenario.
many thanks, L.
freeipa-users@lists.fedorahosted.org
-
François Cami -
lejeczek -
Markus Larsson -
Rob Crittenden