Load Balancing FreeIPA LDAP Servers

Table of Contents

Introduction

In a multi-server FreeIPA deployment, clients typically connect to LDAP services using individual server hostnames. However, to achieve load balancing and automatic failover, you can configure a single DNS name that resolves to all your FreeIPA LDAP servers. This allows clients to connect using one consistent name, while DNS or load balancers distribute the load and handle failovers.

Purpose

The primary purpose of this technique is to provide automatic failover for clients. If one FreeIPA server becomes unavailable, clients can seamlessly connect to another server without manual reconfiguration. Additionally, by distributing connections across multiple servers, you can share the load and improve performance.

This approach can be combined with advanced DNS services like Amazon Route 53 Health Checks. Route 53 can monitor the health of each FreeIPA server and automatically route traffic only to healthy instances, ensuring high availability and reducing the impact of server failures.

Challenge

It is easy enough to set up a DNS A-record for round-robin traffic distribution to multiple servers. The challenge is that TLS certificate verification only works when you connect to the server with one of the Subject Alternative Names listed in the TLS certficiate. To enable certificate verification, we need to add our shared DNS name (e.g. ldap.example.org) to the list of Subject Alternative Names for each server certificate.

FreeIPA Configuration

To allow clients to connect using a shared DNS name like ldap.example.org, you need to add this name to FreeIPA’s configuration, including service principals and certificates.

Create a Host Entry for the Shared DNS Record

GUI

  1. Open the FreeIPA web UI and go to Identity → Hosts.
  2. Click Add.
  3. Set Host Name to ldap.example.org.
  4. Check Force and save.

CLI

$ ipa host-add --force ldap.example.org

This creates a FreeIPA host object for the shared LDAP DNS name even though it is not a real host machine.

Create the Service Principal for the Shared DNS Record

GUI

  1. Open the FreeIPA web UI and go to Identity → Services.
  2. Click Add.
  3. Set Service to ldap and Host Name to ldap.example.org.
  4. Check Force and Skip host check.
  5. Save the service principal.

CLI

$ ipa service-add --force --skip-host-check ldap/ldap.example.org

This creates the LDAP service principal for the shared DNS name.

Add IPA Servers to the Service Principal

Each FreeIPA server must be listed as a managed host for the shared LDAP service principal.

GUI

  1. Open the FreeIPA web UI and go to Identity → Services.
  2. Search for ldap/ldap.example.org and open it.
  3. In the service details, edit the Managed By or Hosts section.
  4. Add each IPA server host object, such as ipa-server1.example.org, ipa-server2.example.org, etc.
  5. Save the changes.

CLI

For each FreeIPA LDAP server, run the following command. Replace ipa-server1.example.org and ldap.example.org with the appropriate values for your environment.

$ ipa service-mod --addattr managedby=fqdn=ipa-server1.example.org,cn=computers,cn=accounts,dc=example,dc=org ldap/ldap.example.org

Repeat for each FreeIPA server, replacing ipa-server1.example.org with the actual FQDN.

Certificate Updates

Next, we update each server certificate to include the shared DNS name as an additional Subject Alternative Name.

Check the existing DNS SAN entries

For each existing LDAP server, run the following command (from anywhere) to list the existing DNS SAN entries on each certificate.

$ openssl s_client -connect ipa-server1.example.org:636 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -o 'DNS:[^,]*' | cut -d: -f2

ipa-server1.example.org

Notice that there is only one DNS SAN entry: ipa-server1.example.org. We need to add a second SAN for ldap.example.org.

Update Certificates to Include the Shared DNS Name

To use TLS for secure LDAP connections, the shared name must be present in the certificate SAN entries.

This step must be completed on each FreeIPA server, as the root user:

  1. Get the request ID for the LDAP managed certificate:
$ getcert list | grep -B 11 -A 7 'principal name: ldap/' | grep 'Request ID' | sed -n "s/Request ID '\([0-9][0-9]*\)':/\1/p"

20231120173230

This command will return the request ID for the LDAP certificate.

  1. Resubmit the certificate request to include the shared DNS name. This request must include a -D argument for every name by which the server will be accessed. At a minimum, this should include the server’s own FQDN and the shared DNS name we want to add.
$ getcert resubmit -i <request_id> -D ipa-server1.example.org -D ldap.example.org

Replace <request_id> with the request ID from getcert list and repeat for each server.

This process of resubmitting the certificate request must be done on each FreeIPA LDAP server.

  1. Monitor the certificate to see when the replacement is issued. Run the following command and watch for the issued timestamp to be updated to approximately the current date and time.
$ getcert resubmit -i <request_id>

Number of certificates and requests being tracked: 9.
Request ID '20231120173230':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-ORG',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-ORG/pwdfile.txt'
        certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-ORG',nickname='Server-Cert',token='NSS Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=example.org
        subject: CN=ipa-server1.example.org,O=example.org
        issued: 2026-10-27 17:28:22 UTC
        expires: 2029-10-28 17:28:22 UTC
        dns: ipa-server1.example.org,ldap.example.org
        principal name: ldap/ipa-server1.example.org@EXAMPLE.ORG
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        profile: caIPAserviceCert
        pre-save command:
        post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-ORG
        track: yes
        auto-renew: yes

Look at the following fields to indicate the new certificate has been issued:

  • status: should show MONITORING (not SUBMITTING or WAITING).
  • issued: should be approximately equal to the current date and time.
  • dns: should include all the SANs, including the shared DNS name.
  • There should be no ca-error fields.
  1. Restart the LDAP server to make the new certificate accessible.
$ ipactl restart

Confirm the new DNS SAN entry

After the new certificate has been deployed, run the following command again to confirm that the shared DNS name is now included in the SAN entries.

$ openssl s_client -connect ipa-server1.example.org:636 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -o 'DNS:[^,]*' | cut -d: -f2

ipa-server1.example.org
ldap.example.org

Notice that the list of SANs now contains two entries: the server’s own FQDN and our shared DNS name.

Configuring DNS for Load Balancing

With the shared name configured in FreeIPA and added as a SAN on each TLS certificate, set up DNS to resolve ldap.example.org to multiple IP addresses for load balancing.

Option 1: DNS Round-Robin

Add multiple A records for ldap.example.org, each pointing to a different FreeIPA server’s IP address. Most DNS resolvers will rotate the order of responses, distributing connections across servers.

Option 2: Using Route 53 Health Checks

For more advanced load balancing and failover:

  1. In AWS Route 53, create health checks for each FreeIPA server (monitor port 636 for LDAPS).

  2. Set up a routing policy (e.g., weighted or failover) for ldap.example.org that directs traffic to healthy servers.

This ensures automatic routing to available servers based on health status.

Conclusion

Clients can now connect to the shared name: ldap.example.org, and DNS will handle load distribution and failover.

By configuring a single DNS name for your FreeIPA LDAP servers, you enable load balancing and automatic failover, enhancing the resilience and performance of your identity management system. Integrating with health checks in Route 53 or similar services provides robust, automated traffic routing to healthy servers, minimizing downtime and manual intervention.