Subscribe to the feed

In the recent months I have been getting more and more questions about identity management (IdM) in Red Hat Enterprise Linux and best practices around load balancing. This post dives into the details and recommendations related to this subject.

IdM provides several protocols:

Kerberos - this protocol is used for the authentication and ticket acquisitions. There are actually two distinct parts of the protocol. One part is the main authentication and ticket exchange protocol, another is related to the administrative activity, things like password change.

The Kerberos protocol is not good for load balancing using traditional load balancers. The protocol is built in such a way that load balancer will be viewed as a man in the middle. There are couple ways to deal with the situation. The details are well covered in the following blog post. The summary is that it is not recommended to load balance Kerberos communication between IdM clients and IdM servers.

Kerberos’ client library has built-in timeout, retry, and failover capabilities. It also chooses the server either based on the explicit server list configured in krb5.conf on the client or by looking up server SRV record in DNS. If you are concerned about load on your servers use a DNS server that can serve different SRV records based on the load.

IdM DNS server serves Service Location (SRV) records randomly, so load balancing can be achieved in this way and it is usually sufficient. There were recent upstream improvements to respect priority order based on the server weights. So far we have not actually seen a precedent where current implementation was not sufficient so the improvement is more to match standards and general expectations.

LDAP - this protocol is used by the clients to fetch identity information but also sometimes for the authentication, especially if systems that do not have the System Security Services Daemon (SSSD) are integrated with IdM. Also, if IdM acts as an LDAP back end for an application authentication, applications can connect to IdM using an LDAP driver available in the framework the application is build with. So we have really two different cases:

  • LDAP connections from SSSD enabled clients
  • LDAP connections from legacy systems, UNIXes and applications

SSSD has built in timeout, retry, and failover capabilities similar to the ones described above for Kerberos. Adding a load balancer between SSSD and IdM does not add any value and rather complicates the environment. It should be noted that SSSD uses Kerberos based authentication for such LDAP connection by default. This makes using a load balancer even less attractive.

The LDAP connections from legacy systems, UNIXes, and applications -- usually password authentication -- can be load balanced if there a real need. The need may emerge from cases when there are a lot of chatty applications that use IdM as a back end.

But before introducing load balancer try without it and see if the load is sustained. Introduce a balancer with sticky sessions only if the tests were conducted and default configuration really does not meet the needs.

Administrative protocol of HTTPs - This protocol is used for all administrative activity driven by IdM CLI and UI as well as client registration operations invoked during the installation of an IPA client (ipa-client-install). In other words, if you do not use the CLI interface remotely, but prefer to run IdM CLI only on servers it will be used only during client registration/enrollment.

This protocol uses Kerberos for authentication and keeps the session stored on the client. In the first place the client tries to connect to the server that the client was enrolled with. This server is recorded in the client configuration as the default. If the server does not respond the client will look at the LDAP SRV records and will try those based on the return order which is currently random, until the upstream fixes make their way into a release.

While it is possible to load balance this traffic it is usually enough to require a load balancer.

This table summarizes the recommendations above:


Used Protocols

Native Capabilities

Load Balancing recommendation


Kerberos, LDAP

Capable of failover

Use DNS for load balancing do not use a load balancer.



Limited failover capabilities

Load balancing can be introduced if there is a real need. Recommendation is not to do it until proven that it is needed.



Framework dependent

Load balancing can be introduced if there is a real need. Recommendation is not to do it until proven that it is needed.

Administrative client (CLI/UI/Client installation)


No fail over

Load balancing with sticky sessions can potentially be used but it will add more complexity and fragility to the environment.

If you see challenges in this area please open as support case and we will be glad to assess the situation and consider improvements.


Using load balancers with IdM is possible, but not recommended. Make sure you consider the use case thoroughly before implementing load balancing with IdM.

For Red Hat Enterprise Linux customers, if you see a real need for introduction of load balancers in your environment please contact your technical account manager or open a support case at the design and prototyping phase of your project. We can give advice as to whether the configuration will be supported or not.

About the author


Browse by channel

automation icon


The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon


The latest on the world’s leading enterprise Linux platform

application development icon


Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech