Identity Management on RHEL, included in the base.

RHEL Identity Management licensing is one of the structurally simplest readings on the RHEL practice. Identity Management, abbreviated IdM, is the productised distribution of the upstream FreeIPA project. It provides Kerberos, LDAP, a certificate authority, DNS, a host based access control engine, and a sudo policy store for a Linux estate. Red Hat ships IdM as a set of packages inside the standard RHEL repositories. The packages are installed with dnf or yum on a host that already carries a RHEL subscription, and that subscription is the entire licensing artifact. There is no separate IdM SKU. There is no per user directory fee. There is no replica multiplier on the line.1

The structural simplicity is the headline and the source of the buyer's confusion in equal measure. A buyer running a Microsoft directory environment is conditioned to read directory licensing as a separate cost line; the equivalent reading on the Red Hat side is that the directory functions ride inside the base operating system subscription. The cross reading with the broader RHEL practice sits in the RHEL practice and the reading of what is and is not included in the base subscription sits inside the RHEL subscription models explained note.

What the buyer pays for is the host. An IdM server is a RHEL host on which the IdM server packages have been installed. The host carries a RHEL subscription line at the standard tier for the host's processor and virtualisation reading. A second IdM server, configured as a replica for high availability, is a second RHEL host carrying a second RHEL subscription line. A third, fourth, fifth replica, scattered across regions for latency or resilience, each consume a RHEL subscription line. The directory itself, the users it contains, the certificates it signs, and the policy it serves are not separately metered.

Three counting questions recur on RHEL Identity Management readings. Each is structural, each remediates inside a renewal cycle, and each is the source of the most common findings on the IdM portion of a subscription assessment.

The first question is whether the IdM server host carries a current RHEL subscription. The pattern is unglamorous and frequent. A buyer stood up an IdM server eight years ago on a host that was, at the time, a development sandbox. The development sandbox was never moved to a production subscription tier. The IdM server is now the authoritative directory for two thousand production workloads. The reading is exposure on the host: a production critical service is running on a host whose RHEL line is either expired, downgraded, or non existent. The remediation is the attach at the next renewal and the elevation of the host to the appropriate production tier. The pattern overlaps with the broader treatment in phantom entitlements.2

The second question is whether the replica topology is reflected in the procurement register. The IdM operations team has, over the trailing years, added replicas at regional sites to reduce login latency and to provide local failover. Each replica is a full RHEL host. The procurement register frequently carries the original IdM server line but not the replica lines, because the replica build was treated as an operations project rather than a procurement event. The reading is exposure on the replica hosts. The remediation is the inventory pass against the topology and the attach of the replica lines at renewal. The cross reading with the broader treatment of replica style topologies sits in the sibling note on Satellite Capsule Server licensing, which describes the same replica counting pattern on a different RHEL based service.

The third question is the client posture. An IdM client is a RHEL host that authenticates against the IdM domain. The client is a normal RHEL host carrying a normal RHEL subscription. The directory membership does not change the subscription line; the host pays for itself as RHEL regardless of which directory it belongs to. The trap is the inverse reading: a buyer who believes the directory membership creates an obligation will sometimes overcount, treating the IdM client population as a separately metered line. It is not. The host count is the host count. The directory count is structural metadata.

IdM is not the only identity adjacent product Red Hat ships, and a buyer reading the IdM line should know where the boundary sits. Red Hat single sign on, historically known as RH SSO and now repositioned as the Red Hat build of Keycloak, is a separate productised line covering web application single sign on, OAuth, OIDC, and federation. It carries its own subscription. The cross reading with the Keycloak line sits in the sibling treatment of the Red Hat build of Keycloak licensing.3

The two products solve different problems. IdM is the domain controller for the Linux estate; Keycloak is the federation broker for web applications. A buyer running both will carry the base RHEL subscriptions for the IdM hosts and a separate Keycloak subscription for the Keycloak instances. The two lines do not substitute for each other and the buyer should resist any vendor narrative that treats them as overlapping. They overlap in the broad domain of identity; they do not overlap on the licensing line.

The boundary with Red Hat Insights and Red Hat Lightspeed for RHEL is the second place buyers get confused. Insights provides drift and compliance reporting on the host estate; Lightspeed provides the AI assisted system management overlay. Both are add ons that ride on the RHEL subscription tier rather than separate lines, and neither is part of IdM. The sibling reading on the Insights add ons sits inside the Red Hat Insights policies and drift monitoring note.

The audit reading on RHEL Identity Management walks three artifacts. The IdM server topology, the replica list, and the procurement register of RHEL subscription lines. The reading is internally consistent when every host carrying the ipa server or ipa server replica role carries a current RHEL subscription at the appropriate tier and when the topology returned by ipa server find is reflected in the procurement register.

Three inconsistencies recur. The first is the replica that the procurement register has never seen. The replica was added by the operations team in a regional rollout; the procurement team was not looped in; the host runs on an unsubscribed RHEL line. The reading is exposure for the period of operation on the unentitled host. The procurement register should walk the ipa topology in the same way it walks the data centre inventory of record. The remediation is the attach at the next renewal cycle and the retroactive treatment of the past period in any settlement reading. The discipline overlaps with the broader treatment in counting RHEL systems accurately.4

The second inconsistency is the IdM server that has been demoted to a client but whose host RHEL line was sized for the server role and never reread. The reading is overpayment on the host tier. The remediation is the resize at the next renewal cycle. The pattern is mirror image to the first and frequently appears alongside it on the same estate; replica topologies are reshaped across multi year horizons and the procurement register tracks neither direction in real time unless the practice has a quarterly review discipline. The reading sits inside the broader treatment in recoverable over entitlement cost.

The third inconsistency is the client population that has been treated as a directory licence line in the procurement register. The line does not exist. The remediation is the removal of the phantom line and the redirection of the freed budget to the host tier review. The pattern is the least expensive of the three on average but the most common single misreading on the IdM section of an assessment, because the vendor narrative on competing directory products primes the buyer to expect a directory line.

The renewal posture on RHEL Identity Management has three habits. The habits are unglamorous; the same three habits, applied honestly, retire the recurring drift on most IdM estates within a single renewal cycle.

The first habit is the topology read. A short artifact, produced once per quarter, that names every host running the ipa server or ipa server replica role, the RHEL subscription line covering it, and the tier of that line. The artifact is owned by the operations team and reviewed by the procurement team. The artifact is the audit ready record and the renewal input in one document. The discipline overlaps with the broader treatment in the 90 day subscription assessment.

The second habit is the replica add discipline. A new replica is added to the topology only after a procurement line has been opened or confirmed for the host. The discipline is operationally undemanding when written into the change control template; it is significant exposure prevention over a multi year horizon. The sibling treatment on the cloud marketplace side sits in the RHEL on AWS marketplace economics note, where the same discipline applies to ephemeral cloud hosts.

The third habit is the boundary read. At the renewal cycle, the IdM line is read alongside the Keycloak line if both are present, alongside the Insights add on if it is enabled, and alongside the broader Smart Management line if the estate runs Satellite. The reading is whether any of the adjacent lines have drifted in scope and whether the renewal is the appropriate moment to retire, expand, or hold the position. The broader treatment of renewal cycle discipline sits in renewal negotiation. The reading also bridges into the Red Hat Quay registry licensing note where the buyer with a containerised IdM client population frequently runs a Quay registry alongside.

For the parent service hub on subscription counting, see subscription assessment. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.