Identity Management or Red Hat Directory Server – Which One Should I Use?

In the identity management server space Red Hat has two offerings: Identity Management (IdM) in Red Hat Enterprise Linux and Red Hat Directory Server (RHDS). This article is dedicated to helping you understand why there are two solutions and how to chose the best one for your environment.

Before diving in too deep it might be wise to more formally define IdM and RHDS. IdM is a domain controller, its main purpose is to manage identities within the enterprise. It is a component of Red Hat Enterprise Linux and is made available at no extra charge (i.e. it’s included with all Red Hat Enterprise Linux server subscriptions). RHDS, on the other hand, is a fully functional directory server. It is a tool for building your business applications and, unlike IdM, it is its own product and has its own price tag.

You might be asking yourself – can I use a generic directory server like RHDS as a central server for enterprise identities? If yes, would I want to? The answer: yes, you most certainly can use RHDS as a central server for enterprise identities. In fact, this is exactly what many companies have been doing for years (…long before IdM was “born”). That said, IdM has a lot of features and capabilities that are either completely absent in the pure DS solution or require a lot of custom development. This makes IdM interesting but different. Also, IdM is implemented following best practices that have emerged from experience with DS based deployments. Because of this IdM does some things differently as compared to DS based custom solutions. These differences can make moving from a DS solution to an IdM based solution a bit harder even if the benefits of IdM are acknowledged. For deployments that have a directory server and are not ready to change from the DS approach to IdM – RHDS is a good option.

Management of enterprise identities aside, another major area where identity management is of great importance is business applications. For example, let’s pretend your company provides an online service that customers pay for. For applications of this nature you usually need a place to store customer account information and authentication credentials. Traditionally, Directory Servers were the best technology for this task. Choosing RHDS as a back-end for your business application is thus a logical choice.

Could IdM be used in such cases (i.e. for identity management of business applications)? Probably… but maybe not. Business applications usually require a lot of customization of the directory server structure called schema. While changing schema for a DS is normal / fully expected, changing schema for IdM should be done carefully and following the specific rules. Why the caution? The reason is that IdM includes different components that are expected to work together. These components make a series of assumptions about data structures… so changes to IdM schema might inadvertently cause one or more of these components to fail. IdM was built with flexibility in mind and is not totally locked down. One can safely make changes to the IdM schema but only following specific rules as described/outlined in the FreeIPA project.

The considerations above lead to the following summary:

  • Use IdM if you want to explore the power of the centralized identity management within your enterprise.
  • Use RHDS if you are building a business application and need an LDAP back-end or if you have been using a directory server to manage your enterprise identities and are not yet ready to switch to a different technology.

Stay tuned as I plan to explore certificates in my next entry. Until then – feel free to reach out using the comments section below.

  1. Great high-level overview, Dmitri! Thank you for sharing. You’ve mentioned that the schema modification for IdM product might be safe and since this is Enterprise-related blog I would ask you whether such changes supported with Red Hat Support services?

    1. The answer is: it depends. The recommended approach is to engage professional services or work in community for the extensions to be accepted. The main problem is upgrades. If we do not know about the extensions they might be wiped out. To prevent it we need to know about these extensions. Thus some kind of conversation needs to happen and the best course of action picked based on the requirements.

  2. I am looking for IdM solution for external users basically for consumers in B2C scenario for news publishing portal. targeting for 1 million users and 3K concurrent users. Single factor authentication & SSO across public websites. Identity provision and basic management.
    I believe there is no need of full suite of Idm capabilities.
    I have shortlisted RHDS and RedHat Idm, Please suggest which one will be better.
    Any help is appreciated.

    1. How do you envision SSO? If you plan SAML/OIDC IdP and then hook services to it as service providers then probably building your portal on top of RHDS will be a better option. In fact it is the primary use case for RHDS nowadays. IdM will be valuable if you want to use Kerberos based SSO but it seems that it would not be the case based on your description. So my vote would be for RHDS in this scenario.
      As a side note consider using Keycloak as the IdP.

  3. Great Article!!!

    Please let me know who can cover up Audit more . Last time i checked the audit part of IDM is still under development. So RHDS will be able to cover that part. How effective RHDS can work on a cloud platform?

    Thanks in advance.

    1. Thank you.

      At some point we decided that audit is more than IdM. Now world has Splunk, Zabbix, Elastic, Solr and bunch of other solutions. There is no plan to add audit to IdM any more but there are plans to make IdM more “auditable” so that it can be easier troubleshooted. Red Hat is looking into some logging related solutions that it can offer to serve Red Hat stack but also inter-operate with company-wide solutions like listed above.
      RHDS is not going to cover audit part at all. If you are asking how RHDS runs in the cloud the answer is well and it is supported.

  4. Which is reliable ? 389 Directory Server or RedHat Identity Management

    we want our users to access Linux with their AD credentials. We tried with FreeIPA in our test server but it wasn’t authenticating the already existing AD user. Kindly help

  5. Hi Dmitri, I found this very helpful, but I’m wondering if you can answer me this one question that I’m having a hard time finding. I’m typically a Windows Admin, and I’m learning Linux Admin (Jumping Ship) I uderstand that Idm is a Domain controller, to which I’ve played around, but why is it that for user management it’s not a full out Directory Server. Where I can create several branches of OU’s, it looks like it can only be groups. If IDM uses 389-DS for user management. and I’ve seen 389 it looks like it uses the typical directory structure. Then why not implement it into IDM?

    1. Hello,

      When we designed IdM we looked at different options. At that time it was already clear that having OUs and Groups at the same time is quite redundant. We considered OUs but decided against them due to performance impact and complexity they bring. It was an architectural decision to have a flat tree and enable grouping via groups, rather than OUs.
      There are several design decisions like this in IdM. This is why it is not free form directory. You can use it as a directory if you follow the rules like this one.
      In general the IdM guidelines are:
      – Use LDAP to read if you need to read things out of directory from the LDAP enabled applications or LDAP clients, otherwise use CLI/API.
      – For normal clients use SSSD. If you have other cases where SSSD is not available there are options. Please check the docs.
      – Use CLI/UI/API to do modifications with the exception of the user provisioning that can be done via LDAP and should land in staging area.
      – If you need to add attributes to the exiting objects you can (see IPA Config tab in the UI). You can define an auxiliary class and register it.
      – If you want to use IdM as a back end for a completely different set of data you are responsible for creation of the schema and tools to manage this data. It is possible. But in this case we recommend working closer with FreeIPA community. Maybe management of this data will be attractive to other deployments so it might make sense to collaborate around it.

      Hope this helps.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s