[Freeipa-users] Services and Keytabs for load-balanced hostnames

[Petr Spacek]

On 29.9.2014 23:12, Simo Sorce wrote:
> On Mon, 29 Sep 2014 23:25:08 +0300
> Alexander Bokovoy <abokovoy at redhat.com> wrote:
>
>> On Mon, 29 Sep 2014, Mark Heslin wrote:
>>> Folks,
>>>
>>> I'm looking for the best approach to take for configuring IdM
>>> clients to access web services (HTTP)
>>> with keytabs when a front-end load-balanced hostname is in place.
>>>
>>> I have a distributed OpenShift Enterprise configuration with three
>>> broker hosts (broker1, broker2, broker3)
>>> with all three configured as IdM clients.
>>>
>>> IdM is configured with one server (idm-srv1.example.com), one
>>> replica (idm-srv2.example.com); an HTTP service
>>> has been created for each broker host:
>>>
>>>   # ipa service-add HTTP/broker1.example.com
>>>   # ipa service-add HTTP/broker2.example.com
>>>   # ipa service-add HTTP/broker3.example.com
>>>
>>> A DNS round-robin hostname called '*broker**.example.com*' has also
>>> been configured to distribute broker requests
>>> across the three brokers:
>>>
>>>   # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11
>>>   # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12
>>>   # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13
>>>
>>> Effectively, this creates a DNS A record that acts as a pseudo DNS
>>> load-balancer.
>>>
>>> To access the HTTP services, we have been creating keytabs for for
>>> the first broker host:
>>>
>>>    # ipa-getkeytab -s idm-srv1.example.com -p
>>> HTTP/*broker1*.example.com at EXAMPLE.COM
>>>                                 -k
>>> /var/www/openshift/broker/httpd/conf.d/http.keytab
>>>
>>> and copying the keytab over to the other two OpenShift broker hosts.
>>>
>>> This all works fine but in the event that *broker1* should go down,
>>> the other broker hosts will lose access
>>> to the web service. Ideally, we would like to have web services use
>>> the more generic, "load balanced"
>>> hostname (*broker.example.com*) and in turn have the keytabs use
>>> this name as well.
>>>
>>> I tried creating an HTTP service using the "load balanced" hostname
>>> (*broker.example.com*) but that appears to fail
>>> due to *broker.example.com* not being a valid host within IdM:
>>>
>>>    # ipa service-add HTTP/broker.example.com
>>>    ipa: ERROR: The host 'broker.example.com' does not exist to add a
>>> service to.
>>>
>>> In the F18 FreeIPA guide it discusses creating a combined keytab
>>> file (Section 6.5.4) using ktutil:
>>>
>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services
>>>
>>> but would that still work as intended should a broker host go down?
>>>
>>> The next section (6.5.5) mentions creating a keytab to create a
>>> service principal that can be used across multiple hosts:
>>>
>>>   # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k
>>> /etc/httpd/conf/krb5.keytab -e des-cbc-crc
>>>
>>> Which seems more in-line with my thinking and exactly what we've
>>> been doing but again, if I try to do that
>>> using the "load balanced" hostname (*broker.example.com*) it fails
>>> sicne it's not a valid host within IdM.
>>>
>>> What is the best method to doing this?
>> Make a host named broker.example.com
>> ipa host-add broker.example.com --force
>>
>> --force will make sure to create the host object even if there is no
>> such name in the DNS.
>>
>> Then create services for this host.
>>
>> You'll need to set up your balancer hosts to use the proper service
>> principal instead of allowing them to construct the principal
>> themselves based on the hostname.
>
> Even better tell them to not assume any name if the server name is NULL
> GSSAPI will try every key in the keytab. YUou can even force that
> behavior with a krb5 config hack even if the app insist setting a name
> by adding "ignore_acceptor_hostname true" in [libdefaults]

I consider this as a 'workaround'.

Even better option is to teach your client application to use DNS SRV records 
instead of plain A records. SRV records allow you to do more fancy things like 
non-equal load balancing etc.

-- 
Petr^2 Spacek