Direct, or Indirect, that is the Question…

In my last post I reviewed some of my observations from the RSA Security Conference. As mentioned, I enjoyed the opportunity to speak with conference attendees about Red Hat’s Identity Management (IdM) offerings. That said, I was quick to note that whether I’m out-and-about staffing an event or “back home” answering e-mails – one of the most frequently asked questions I receive goes something like this: “…I’m roughly familiar with both direct and indirect integration options… and I’ve read some of the respective ‘pros’ and ‘cons’… but I’m still not sure which approach to use… what should I do?” If you’ve ever asked a similar question – I have some good news – today’s post will help you to determine which option aligns best with your current (and future) needs.

Beyond differences in functionality, there are several factors that might affect your ultimate decision, namely:

  • Size of the deployment
  • Deployment growth expectations
  • Deployment dynamics
  • Compliance and policies
  • Organizational structure
  • Costs

The following recommendations assume that your functional use cases can be addressed by different approaches.  If this is not the case, and you have a feature that is a show stopper, then such a feature would likely eliminate some of the options from consideration.

Size of the Deployment

If you manage just a handful of systems that you need to connect to Active Directory (AD), indirect integration will most likely include some unnecessary overhead. Alternatively, at the other end of the spectrum, if you have many systems, management without central tools will be a challenge. In this latter case, we recommend using the indirect approach (leveraging IdM) as it provides centralized management capabilities for both Linux and UNIX systems.  Generally, we draw the boundary at around 30-50 systems – less than this number and indirect integration is likely not worth it – more than this number and you’ll likely benefit from the centralization of management capabilities.

Deployment Growth Expectations

If you anticipate slow growth of your environment over time then jumping into indirect integration might be premature.  If, on the other hand, you are building / designing for rapid growth, it might make sense to consider indirect integration with IdM from the beginning.

Deployment Dynamics

If you deploy systems rarely and, more often than not, they are bare metal systems, then direct integration might be the simplest and easiest solution.  If, however, your systems are virtual and/or are provisioned on-demand, then (adopting indirect integration and) having a central server that can manage these systems dynamically and “play well” with orchestration tools like Red Hat Satellite is likely your best bet.

Compliance and Policies

Policies tend to always win over other arguments and reasons… so, if your policy says that everything should be integrated into AD… then this is the way to go.  However, it does not necessarily mean that the direct solution is the only solution.  If, for example, you use trusts with IdM, the users accessing Linux systems actually do authenticate against AD.  This means that policies that exist in AD are executed and enforced during authentication.  You can check an audit trail on the AD server to get the proof of the authentication.  This also means that any of the audit software that you may have already invested in is likely still relevant.

Organizational Structure

If there is one team that manages Windows and Linux systems and expertise on the team is diverse then other factors (outside of organizational structure) should shape your choice.  On the other hand, if there are different teams (e.g. one for Windows and one for Linux), then indirect integration likely better aligns with your organizational structure and the respective skill sets of your teams.

Last But Not Least… Costs

Costs usually fall into one or more “buckets”:

  • Software costs – costs for the software licenses or subscriptions.  If you go with a third party solution and direct integration, your costs will most likely be high. With indirect integration using IdM your costs will be calculated as a cost of your subscription multiplied by number of IdM servers you plan to deploy (…and will likely be lower).
  • Deployment costs – there can be a lot in this bucket. Costs in this category might include: time you spend evaluating an approach, costs associated with the use of third party consultants and/or any other professional services you choose to employ to complete a deployment, training costs you may need for your teams, and (any other) time required to develop the means to deploy your chosen solution in an automated and controlled fashion. These costs are nearly always specific to your environment so it is hard to estimate them… but they can have a significant impact on your decision.
  • Cost to use – after the solution is deployed it will (obviously) need to be supported and maintained. You will pay for the solution with time and resources. This means that the efficiency of the chosen solution is an important factor. If an administrator can do twice as many tasks using one approach as he or she could do using the other, there is a clear cost savings right there. Often times deployment can take months… but the solution is used for years. If the solution gives you a convenient way to mange your environment, even if the initial deployment costs might be higher, you might win over time.

In review, there are several factors that may influence your decision to adopt direct or indirect integration. We (at Red Hat) believe that IdM is the way to go as it combines a lot of value with moderate costs. That said, it is always worthwhile for you to decide what is best and most convenient for your own particular environment. If you’re stuck – feel free to reach out using the comments section below or to learn more by visiting

  1. Dmitri;

    When using direct integration with AD can RHEL admins modify user attributes using command line tools? Can you point me to any documentation about this?


    1. Hello,

      When direct integration is used you can’t change anything centrally unless you are an AD admin.
      If you want a local override you can do it starting SSSD in RHEL 7.2.
      Some documentation about local sssd tools can be found here:
      Management of the overrides is in the sssd-override tool which is new but has a good man page. It is not mentioned in the docs yet. In general most SSSD documentation can be found in SSSD related man pages.


      1. Yes, this is a local per system override.
        May be I misunderstood the original question. Can you please rephrase?
        Are you asking how to change attributes in AD? There are AD tools for that.

      2. Sure. I was asking whether a Linux admin, familiar with Linux command line tools, could modify the centralized user attributes from any Linux host joined to the domain.

      3. I see, thanks for clarification. No there are no tools that we provide to manage things centrally for the direct integration in AD.
        We are at the mercy of the AD interfaces and we do not want to go there. If you deploy IPA/IdM you get the full power to manage the policies for AD users from the Linux side. This is one of the values of IdM.

  2. Hello,if I am also using IPA/IdM to manage user accounts for my applications, what’s the best approach to support user self-registration? Is there an API for the application to call into IdM to register a new user?

    1. Hello,

      If you are building an auto-registration portal around IPA it might make sense to join forces. Please take a look at There was some research work done in this area. If you are interested in contributing some code we know what needs to be done and how. We just discussed next steps to improve this area. Unfortunately we do not have time to do the work ourselves at the moment but we would be glad to support and guide you. If you are interested the next step would be to join and introduce yourself there. You can put a pointer to this post in your mail to the list. If you do not want to go whole nine yards, you can take a look at what is already done and take some inspiration there


  3. Hi, use case – rhel7 client using sssd connected to Server) as primary domain and we want to authenticate rhel7 with trusted domain AD and domain) so how to proceed

    Linux Client ==> ==> ==> user needs to authenticate the users from trusted domain – what configuration required..

    1. Hello,

      If the domains are in the same forest SSSD will do auto-discovery of domains. There are some limitations to what hierarchies can be discovered. As far as I remember the complex trees with different levels of hierarchy might have some challenges. But simple parent-child or siblings would work.

      If the domains are in two different forests you either:
      – need to deploy IdM, connect SSSD to it and make IdM trust two forests. The SSSD would be able to serve users from these two AD forests.
      – use a domain configuration of SSSD. You join SSSD into one domain and then drop a snippet of configuration into sssd.conf that describes the second domain. SSSD can be joined into one domain at a time but can access more than one. You will need to read the manuals, man pages and KB articles for the details of this approach.

      For the multi-forest situation we usually recommend the trust setup.


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