Identity management and load balancing in Red Hat Enterprise Linux

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:

Summary

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.