Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been asked to set up a HA LDAP architecture using Fedora Directory Server - the company currebnly uses Sun DS but wants to move away from Sun.

I want to use a network hardware loadbalancer (Cisco) so that clients can just use '' as the LDAP server name, with the real IPs of the 4 servers behind it hidden.

For plain LDAP this works well, but now I want to add LDAPS using TLS. The certificate setup process seems well documented on the Fedora site but I'm unsure how to setup LDAPS to be highly available as star certificate is not allowed I think.

Round-robin DNS won't be robust enough as it is reliant on TTL - it is still possible to have an LDAP outage.

share|improve this question
up vote 1 down vote accepted

We handle HA LDAPS on Novell eDirectory, but the problem is similar. We've managed to solve the problem with subject-alternate-names on the certificates. Subject-alternate-names are, simply, alternate Subjects you can put on a certificate in order to give it more than one name. That's how you can (in theory) have a single certificate that is valid for,, and They're fairly new, but not as new as Extended Validation certificates.

Most modern LDAP clients are smart enough to treat SAN's correctly. Also, we manage the certificate authority that minted the certificates so getting a SAN is simple for us. It isn't so simple if you're going to end up paying for a certificate, the CA's would rather you purchase multiple certificates. Unfortunately for a lot of people, some software packages can only load one certificate. This is where SAN's come in.

We use a hardware load-balancer (F5 BiP) and three LDAPS servers. When we first set it up we created certificates with just the network name of the load-balancer IP/DNS. Clients connecting directly to the LDAP servers got certificate errors, which proved to be an incentive to get people to use the load-balancer IP address like they should have been doing all along.

We've since moved to using the subject-alternate-names as it was having some negative side effects with the Novell software running on those servers. But we did get it running without SAN's for a while. Each certificate has three names on it:

  • IP Address of the load-balancer IP
  • DNS name of the load-balancer IP
  • DNS name of the direct host

This does expose the back-end hostname to those who snoop, but we don't consider this a vulnerability. Others might.

That's what we do, and it works for us.

share|improve this answer
I haven't tried this yet, will add an answer when I do. Thanks. – Nnn Jun 16 '09 at 1:46

You could do SSL-off loading on your load balancer. You can use hardware, but often you have to pay for a license for the off loading. Or you can try haproxy, which is a free loadbalancer, which supports SSL offloading (dev version)>. Another option is indeed using subject alt names in de certs, but then if you want to scale up, you need to reissue all certificates.

So I would go for the load balanced SSL offload option. Either a hardware one (you should investigate license costs), or a software one. Then make sure the LB connects over normal HTTP and put it in a network segment users cannot connect to. Maybe haproxy does not support ldap ssl off loading and you need another solution. You can also use corosync/pacemaker and use certificates.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.