Securing the Digital World

Yin and Yang: Two Views on IAM - Active Directory Automation, Success or Failure?

Jun 12, 2017 | by Chris Williams |

By Steve Mowll and Chris Williams

Point: Effective identity management strategies are business-based, and should rise above technical limitations.

Steve Mowll, Identity Architect, RSA

True point, but in order to have effective strategies, they must be directed towards a desired outcome. Let's take a look at this idea using Active Directory (AD) projects as an example.

Here's a question: If you spent a year and have full AD automation with your identity and access management (IAM) program, have you been successful? Your answer to that question depends on how you answer the following questions...although if you spent $5M, I do hope your project team received gold-plated laptops as part of the deal!

How many access requests are raised for AD-related changes? And what percentage are they of your overall access requests?

It is important to understand how much you automated, but it needs to be put into context beyond time and money. One customer I worked with saved three man years with AD automation, but it was only 4% of their total access requests. In another, they saved one man year, but AD requests were 78% of all requests. That adds up to a lot more time saved in comparison.

Do you have a strategy backed up with business buy-in, standards and best practice guidelines to use AD for centralized authentication and authorization?

A number of companies use AD for centralization, but not in a formal or strategic way. Formalizing this approach, or a set of standard approaches, of application authentication and authorization will give you more success and a higher return on your investment.

Do you have case studies, metrics and KPIs to show how you made the business more agile and efficient?

If you don't have metrics to show measurable success, then you are going to find it hard to prove you have been successful. In many IT projects, we fixate on the fact that we completed a task, but lose sight of what we gained by doing it.

Do you have processes in place to define what AD groups do? What access they enable? What is their business context and ownership?

The more you understand the business context of the access you have, the more successful you will be. Giving business users the capability to request an AD group and have it automatically provisioned is okay, but only if the business user understands what the group does and can easily find it. Again, this can be measured to show your achievement or where improvements can be made.

A project's success or failure comes down to whether you achieved the business benefit you expected or not. This is only understood if you have defined expected outcomes at the beginning. I am still amazed at the number of projects where clear and measurable goals and objectives were not defined and agreed upon upfront.


Chris Williams, Advisory Architect, RSA Identity

Good points, Steve, but, let's start with two assumptions:

  1. We embrace identity projects because we need to satisfy compulsory mandates.
  2. We need to provide competitive protective services in order to deliver against customer or industry expectations.

Assumptions agreed, as conscientious IT security practitioners, we like to address projects with the goal of making sustainable and efficient solutions, which leads us to utilize previous work and investments (time and money). To shorten design and build cycles, we apply collective wisdom, leveraging existing data sources whenever possible. Hence, in the realm of "people/organization/productivity" data sources, we frequently turn to a combination of HR and directory data-stores (think Active Directory, or AD, here).

However, there are difficulties in adopting an AD-based IAM environment, such as internal network access restrictions, device/form-factor support, control objective translation, limited (or, perhaps too liberal) access controls and groups, and so on. You can still pummel your way through these challenges and attain a set of metrics that prove value (time vs. cost vs. capabilities) by leveraging the data and infrastructure that already exists - but only if you keep Steve's points-of-concern in mind.

If you want to overcome the common pitfalls of an AD-based environment, you may want to take a step back and look at the design through the optics of the consumer (user of the service), customer (the ones that actually pay for the service), or the regulator (the actual article or standard dictating requirements).

This shift in perspective can help to determine what the appropriate strategies should be when defining an IAM program. Here are a few basic rules that could save you from becoming another $5M statistic:

  • Live in the box! Always exploit any native capability (whether it is the AD environment or software) that is provided to you. If you don't have to create it, change it, or maintain it, then why add that cost to your budget?
  • Minimize complexity. I know...this from a guy who works in security. The truth is, not everything has to be automated. I've found that most organizations have some complicated manual process that is actually efficient, effective, and elegant. So, why change it if you don't have to? The caveat here is that these processes are often rare and require a good deal of thought to determine if they should remain manual.
  • Read and understand the documents (e.g., regulations, mandates, and acts). One of the largest contributors for employing overly complex and costly automation stems from the well-intentioned desire to satisfy framework controls, which may not be specifically required...or rationally achievable. Be selective, be prudent, be thorough, but still be economical.
  • Remove the "cool" factor. Yes, this last tip is pretty straightforward. Just because we can do something we can geek-out on doesn't mean we should do it. Like I said, simple...Make it easy for your users and that's cool in its own right.
So, where do we go from here?

As always, we move forward, capitalizing on what we learned from previous AD-based projects. We keep our focus on the user experience and the delicate balance with security. And whenever possible, we should always take a pause - step back - and ask ourselves the same questions that Steve raised. And if we don't have a resounding and strong response, we need to change our models, designs, and preconceptions in order to deliver a cost-effective and customer-friendly solution.

Need some inspiration?

If you think it might be time to take a fresh look at your current identity and access management strategy, download our eBook - Reimagine Your Identity Strategy. It will help you to begin evaluating your current approach, understand what you need to be successful and make sure you have the right technology to help you reach your goals.