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:
Used Protocols
Native Capabilities
Load Balancing recommendation
Chapter 1. Introduction to Red Hat Identity Management
Red Hat Identity Management (IdM) provides a centralized and unified way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain. IdM significantly reduces the administrative overhead of managing different services individually and using different tools on different machines.
IdM is one of the few centralized identity, policy, and authorization software solutions that support:
IdM builds on existing, native Linux tools and protocols. It has its own processes and configuration, but its underlying technologies are well-established on Linux systems and trusted by Linux administrators.
IdM servers and clients are Red Hat Enterprise Linux machines. However, even though IdM does not support Windows clients directly, it allows integration with Active Directory environment.
This guide describes using IdM in Linux environments only. For more information on integration with Active Directory, see the Windows Integration Guide.
For information on the Samba suite, which allows integrating Linux machines into Active Directory environment, see the Using Samba for Active Directory Integration chapter in the Windows Integration Guide. If you use Samba as a server, note that integrating the server into the IdM domain and authenticating users connecting to the Samba server against the IdM or a trusted Active Directory domain is not supported.
1.1.1. Examples of Benefits Brought by IdM
Without IdM: Each server is administered separately. All passwords are saved on the local machines. The IT administrator manages users on every machine, sets authentication and authorization policies separately, and maintains local passwords.
Set different access levels for users by using host-based access control, delegation, and other rules
Without IdM: Users log in to the system and are prompted for a password every single time they access a service or application. These passwords might be different, and the users have to remember which credential to use for which application.
With IdM: After users log in to the system, they can access multiple services and applications without being repeatedly asked for their credentials. This helps:
Without IdM: Windows systems are managed in an Active Directory forest, but development, production, and other teams have many Linux systems. The Linux systems are excluded from the Active Directory environment.
Separate management of Linux and Active Directory machines and enable Linux and Windows admins to control their environment directly
1.1.2. Contrasting Identity Management with a Standard LDAP Directory
A standard LDAP directory, such as Red Hat Directory Server, is a general-purpose directory: it can be customized to fit a broad range of use cases.
Schema: a flexible schema that can be customized for a vast array of entries, such as users, machines, network entities, physical equipment, or buildings.
Typically used as: a back-end directory to store data for other applications, such as business applications that provide services on the Internet.
Identity Management (IdM) has a specific purpose: managing identities as well as authentication and authorization policies that relate to these identities.
Schema: a specific schema that defines a particular set of entries relevant to its purpose, such as entries for user or machine identities.
Typically used as: the identity and authentication server to manage identities within the boundaries of an enterprise or a project.
The underlying directory server technology is the same for both Red Hat Directory Server and IdM. However, IdM is optimized to manage identities. This limits its general extensibility, but also brings certain benefits: simpler configuration, better automation of resource management, and increased efficiency in managing identities.