Why Active Directory Isn’t an Authoritative Source for User Identities

Active Directory for User Identities

If You Still Think Active Directory Should Be Your Authoritative Source for User Identities, Then We Need to Talk…

Active Directory has been around for a long time. How long? It was released last century. The World Trade Center was standing tall, Bill Clinton was president, and many of us had friends who were prepping for society’s collapse due to Y2K. I know our mainframe friends are saying ‘whipper snappers!’  and telling us to get off their lawn, but let’s let the statement stand that Active Directory has enjoyed an incredibly long and fruitful life.

Over the course of this life, Active Directory has been used and misused to attempt to solve almost every identity related issue we have found. One scenario that I have seen surface time and again in my 22+ years of working with Active Directory and identity is the temptation to wrongfully declare it: the Authoritative Source for users/identities/user information. It is not.

I understand the temptation, but that is like declaring my wallet the authoritative source for my money. It kind of looks like it and kind of acts like it, but it’s not. My wallet contains cash (sometimes) from somewhere else, just like your employees. My wallet also contains different types of credit cards from different issuers that function sort of like cash, just like your non-employees. There are other cards in my wallet like my loyalty cards and library card that provide a certain service under very specific circumstances, just like your service accounts, automation accounts, and all the other types of ‘non-human’ accounts you have in Active Directory.

As I said earlier, I can understand the temptation and the desire to position Active Directory as an authoritative source or declare it to be the source of truth.

Some Reasons Why it’s an Error to Call Active Directory an Authoritative Source

  • Easy integration to read data from Active Directory. Reading data is very simple and supported by any serious language, product, or platform. By default, reading data doesn’t require any special permissions – any user can read the entire domain.
  • Easy integration to write data into Active Directory. While this is very simple, it does require additional access. The obvious danger is laziness and poor security hygiene lets us fall for the ‘You have to trust someone” argument and drop the account in Domain Admins rather than assigning correct abilities to the appropriate scope of the directory.
  • Easy to integrate for Active Directory authentication, whether using pass through credentials or consuming federation we want a one-stop shop.
  • Many organizations have built an enterprise security / role model using Active Directory groups. This supports the one-stop shop mindset.
  • Active Directory by nature is a distributed, redundant, and highly fault tolerant system.

What’s not to love? All of these are great features of Active Directory and they all provide reasons to integrate applications with Active Directory, so long as your company plans to keep it around long-term. Unfortunately, none of this supports Active Directory being an authoritative source. Maybe this supports Active Directory being a consolidated source of information, but that’s a very different proposal.

Just because Active Directory is easy to integrate with and provides a redundant and performant infrastructure doesn’t mean it fits the bill to be an authoritative source. Being an authoritative source for data means providing features, functions, and following processes that Active Directory is simply not able to do out of the box.

Let’s examine some short falls when considering Active Directory as an Authoritative Source for Identity Data and Users:

  • No data validation controls to ensure only acceptable values are entered in a field or attribute
  • No capability to represent an entity’s relationship with the organization
  • No native capabilities to represent multiple hierarchies and structures at once, such as reporting structure, General Ledger structure, and physical locations. These all contribute to determining a workforce member’s appropriate function and access.
  • The capabilities and configuration of Active Directory make it a highly inappropriate place to store the sensitive and confidential information required to ensure we have the positive and unique identification of a person.
  • No workflow capabilities built it to accommodate the steps and participants related to onboarding, changing, or offboarding a person or entity.
  • No ability to enforce basic business rules such as naming standards and determining a user’s manager when the current one leaves.

That’s not an exhaustive list, but it’s more than enough for our purposes. Active Directory can and should be a source of account information to other systems and applications through various integrations, but it can’t be the authoritative source for user data.

I don’t believe I have met anyone who disagrees that an HR system should be the authoritative source for employee data. I don’t understand why that is so easy to understand while the need for a separate authoritative source for all the other user types seems so difficult to grasp. In a time when Zero Trust is the word and identity is the perimeter, doesn’t it just make sense to ensure those very identities are authentic, sponsored in our environments, and contain up to date and accurate information? This continues to be the most common problem IDMWORKS finds when performing assessments and other projects related to identity lifecycle management.

The good news is that this problem has been solved!

Instead, Active Directory should rely on an Identity Governance & Administration (IGA) solution to provision and deprovision access to Active Directory, and the IGA solution should rely on a trusted authoritative source to inform it about the identities that need access.

There are folks who are experts in solving exactly this problem with exactly the right solution. In a time when we have so many difficult and complex issues, let’s stop making things harder than they should be. IDMWORKS’ experts is one of your best authorities to solve this issue in your ecosystem.

And if you’re one of the millions of organizations that have embraced growing populations of third-parties to get business done but don’t have a way to centrally track third-party users, you can also take a self-guided tour of our partner SecZetta’s third-party identity risk solution.

Author: Brian Kreh, IDMWORKS, Director of Advisory Services and CISO

This blog post was written in agreeance to our partner SecZetta’s #HotTake blog post that Active Directory Isn’t an Authoritative Source.