On ti, 30 heinä 2019, Dmitry Perets via FreeIPA-users wrote:
The progress so far...
>
> 1. We create two A records for the same IPA hostname, let's say
> "ipa.site1.example.com". But then not sure if it will work fine...
Technically,
> two IPs for the same name means load-balancing, right? So will I have intermittent
> connectivity issues, because it will return inside and outside IP interchangebly?
>
Bad idea... Indeed, clients get load-balanced responses with the two
IPA IPs, and hence, half of the time they can't communicate with it...
> 2. We create a new DNS name, e.g. "ipa-outside-site1.example.com", for the
> outside IP, and manually add it to the @ entry of "example.com", so that
> wannabe-replica on the remote site can use that FQDN as its master IPA. Will this
work
> fine..? Will it not cause issues to the local clients on site1, who must keep using
IPA
> with inside IP? Will it not cause issues on IPA server itself for some reason?
OK, so with this one I managed to get a bit further... I am now just
trying to enroll remote host with the IPA server over the "outside"
interface (once I am good with this, I could try promoting it to
replica...)
So, I created a new DNS zone for the remote site (
site2.example.com). I
created there SRV entries for "_kerberos._udp" and "_ldap._tcp",
pointing to the outside DNS name of my IPA server:
"ipa-outside-site1.example.com). Then I set the nameserver to this
outside IP and run "ipa-client-install". Since it looks for the above
SRV records first, discovery is successful. So I can continue with
client installation.
Next problem was: ipa-client-install failed to authenticate to site1
IPA over LDAP, because it was trying to access it using
ldap://ipa-outside-site1.example.com (and not via
ldap://ipa.site1.example.com). I solved it by adding principal alias to
the
ldap/ipa.site1.example.com service.
Next problem was: libcurl was complaing about mismatch between
certificate subject and the URL. Again, that's because it was browsing
to
ipa-outside-site1.example.com, but IPA cert has
"ipa.site1.example.com" in subject. OK, so I fixed it by adding
principal alias to http/ipa.site1.example.com and then reissuing
certificate for IPA HTTP, adding a new DNS name to subjectAltName. This
solved the warning.
But then my next problem was (and is):
RPC failed at server. Missing or invalid HTTP Referer,
https://ipa-outside-site1.example.com/ipa/xml
I understand why - because ipa-client-install puts the above referer,
but IPA server expects only
https://ipa.site1.example.com... How can I
solve this? How can I add another "alias referer" to be accepted..?
Basically, I need to convince all the components of the IPA server that
they have two perfectly valid DNS names, with different IPs...
As you noticed, we do
not support this scenario.
In order to support it, we would need:
- decide what is the 'primary' hostname and maintain other names as
aliases for all Kerberos principals associated with the host:
host/name1.example.com would need to have aliases
host/name2.example.com, host/name3.example.com...
ldap/name1.example.com would need to have aliases
ldap/name2.example.com, ldap/name3.example.com...
HTTP/name1.example.com would need to have aliases
HTTP/name2.example.com, HTTP/name3.example.com...
- allow adding
name2.example.com, name3.example.com... as dNS SAN
entries into certificates issued for services on
name1.example.com.
- keep the list of alternative hostnames to validate access to IPA API.
This is not possible at installation time right now. I'm not sure
whether the second part will be possible without having
nameX.example.com all created as separate host objects and setting
managedBy attribute for them to
name1.example.com
The latter will then break the first part: it is possible to add
host/nameX.example.com as a Kerberos principal alias to existing host or
service principal (ipa host-add-principal/service-add-principal), but
adding
nameX.example.com as a separate host object would interfere with
that because you cannot then add an alias to
host/name1.example.com
named as
host/nameX.example.com.
We don't really want to have separate Kerberos principals for
*/nameX.example.com because that would mean using separate keys for
them. We definitely want to have them as aliases (a.k.a. SPNs in Active
Directory) that share the same key. The latter is only possible when
they aren't separate objects.
And all of it then needed to be added to the installer as a special
logic.
The third part is a minor thing in terms of fixing it:
https://github.com/abbra/freeipa/pull/9/files. But I don't want to
submit it without fixing all the other pieces.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland