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 freeipa.org.