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:
Client |
Used Protocols |
Native Capabilities |
Load Balancing recommendation |
SSSD |
Kerberos, LDAP |
Capable of failover |
Use DNS for load balancing do not use a load balancer. |
UNIX |
LDAP |
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. |
Applications |
LDAP |
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) |
HTTPS |
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. |
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.
À propos de l'auteur
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit