6

I'm trying to ask this question in a way that's answerable, but part of the issue is knowing the implications of my current situation and if there's an issue or technical debt which'll bite me further on.

I've setup a few IPA servers in a master & replicas setup.

server1: dns A record (and fqdn hostname): srv1.mydomain.com

server2: dns A record (and fqdn hostname): srv2.mydomain.com

server3: dns A record (and fqdn hostname): srv3.mydomain.com

the servers have a cname of auth-a, auth-b, auth-c, respectively and use a self signed cert as per a normal IPA install.

This worked fine for months for ssh connections, and sssd and so on. The issue arrived when trying to hook in applications which only allow one ldap server to be specified. There are SRV dns records setup for failover, but in an attempt to get these apps to work i also put in a dns round robin record.

The catch is this round robin only works for normal ldap lookups, not ldap ssl. I can make ssl work however if i disable checking on the ssl cert.

So... the questions !

a) realistically, how bad is it to disable checking of the cert on an internal service ? This ldap server is going to be queried from the LAN, always. I believe i'm opened up to a possible MITM attack, but i'm not certain of how worried i need to be of that. I mean, right now my other option is not using ssl, and that's scary sauce. To perform the MITM attack they'd already need be on my network and have control of the DNS, no ? Any advice which could quantify that concern into real terms would be helpful.

b) as i understand it to actually fix this i'd need to give the RR dns entry as a subject alt name on the self signed cert of the server(s). That means re-keying the server, right ? which in the case of IPA means rejoining every client to IPA for the new cert. That's a non-starter i think.

c) given the current situation and outcome of (a) and (b), what would you recommend as the best course of action to allow apps which only allow one ldap server to be specified (and don't use SRV dns records in any way) to fail-over to the other server should one go down, and still allow ldap over ssl giving my certificates ?

Sirex
  • 5,447
  • 2
  • 32
  • 54

3 Answers3

4

You should issue new certificates with subjectAlternitiveNames and point the dns record for that name at a load balancer.

  • A) Turning off certificate checking does open you up to MITM. The advantage is that an encrypted channel can't be passively eaves dropped. It's more work to MITM an encrypted channel, but it's not much more. If you're not high value and don't operate across Wireless or open internet (as opposed to a VPN link), then turning off the certificate checking isn't very risky, but don't to it. Doing things the right way is just about as easy.
  • B) Yes, the servers will need an subjectAlternitiveName or (and don't do this) a wildcard subjectName. However, FreeIPA does its own PublicKeyInfrastucture (PKI), which is to say you have your own self-signed Certificate Authority (CA), rather than a collect of self-signed certificates. This means that you only need to generate and replace the certificates for the FreeIPA servers (the ones used by LDAP). The CA certificate used for signing (that's the cert that's deployed across all your machines) stays the same, so there's no need to touch any other machines. Also, you don't need the servers private keys, just the public certificates.
  • C) See the top, A and B are justification.
84104
  • 12,698
  • 6
  • 43
  • 75
  • This is pretty encouraging, esp not needing to touch the clients. Now that i think of it, it throws one more dumb question; If i'm going to be needing a load balencer function and i don't want that to be a single point of failure, is it madness to cluster that (haproxy i assume) between two of the ipa servers themselves ? – Sirex Oct 17 '13 at 18:54
  • well after a few hours fiddling i got pretty stuck: https://fedorahosted.org/freeipa/ticket/3977 -- it seems ipa isnt smart enough to tell dogtag what it needs to signa cert with alt names, and i know *way* too little about dogtag to know how to do it directly. – Sirex Oct 17 '13 at 23:04
  • freeipa 4.0 should now have the ability to do this as of the above mentioned feature enhancement being resolved. – Sirex Jun 26 '14 at 01:15
3

Round robin dns is not necessarily going to give more availability in the case of server failure unless you're pulling the A/AAAA record from dns as the client will randomly try to connect to one of the servers, including the failed one. If the application doesn't attempt to reconnect, or is unlucky and gets the same record enough times in a row that it fails. Adding a load balancer in front adds extra complexity but does mean this possibility is lessened. If you're happy with the round robin for load sharing then I'd look at whether entering a subjectaltname in the certificate would satisfy the clients to ldaps, or failing that a wildcard might be suitable. Preventing man in the middles could also be achieved by running your own internal PKI and deploying this as a trusted CA in your client machines. This has the added advantage of being a central place you can see expiring or expired certificates rather than having to manage this on each host/service that has its own certificate.

Richard Salts
  • 755
  • 3
  • 17
  • good info. think I'm at least thinking down the right path... The option to add a subjectaltname would mean re-enrolling the clients, right? To do the load balancer, wouldn't I need a new cert anyhow? Not sure how the client asking a load balencer dns entry and getting back a cert with a cn of one of the servers wouldn't be an issue? – Sirex Oct 16 '13 at 07:32
1

If all you are after is HA, I would do something a bit simplistic, but useful:

Set up an HA cluster for IPA (to avoid trouble - just run it in a VM, where the libvirt service is the protected process) and use that IPA instance for all those limited apps, while the other IPAs tend to user auth. IPA works great on KVM, I've run quite a few instances with zero issues over years

dyasny
  • 18,482
  • 6
  • 48
  • 63