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...
> 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
> fine..? Will it not cause issues to the local clients on site1, who must keep using
> 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
So, I created a new DNS zone for the remote site (site2.example.com
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
Next problem was: ipa-client-install failed to authenticate to site1
IPA over LDAP, because it was trying to access it using
(and not via
). I solved it by adding principal alias to
Next problem was: libcurl was complaing about mismatch between
certificate subject and the URL. Again, that's because it was browsing
, 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,
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:
would need to have aliases
would need to have aliases
HTTP/name1.example.com would need to have aliases
- 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
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
as a Kerberos principal alias to existing host or
service principal (ipa host-add-principal/service-add-principal), but
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
The third part is a minor thing in terms of fixing it:
. 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