The Active Directory Era Is Finally Over

“Life was simpler on Active Directory, at least I could manage every identity”.

I made that quote up, but there is nostalgia for a golden age of corporate IT that’s never coming back: Many enterprises still (try to) track identities in Active Directory (AD), a service that’s old enough to drink and crumbles at the scale of modern cloud computing.

It held up because the architecture is simple enough: Active Directory is an LDAP directory to store identities and a Kerberos implementation to let them authenticate, wrapped in decent UX and with continued updates.

AD accomplished the goal of identity management: A way to know all identities, who vouched for them, and where they’re valid. It answered three questions in a unified catalog:

• What identities exist? With the directory, which records every user and machine
• What vouched for the identity? With a domain controller that approves authentication based on admin credentials
• Where is the identity valid? With AD domain architecture that reflects the company’s infrastructure

Security policies are moot if you can't answer any one of them. I spent many hours keeping our Active Directory catalog accurate so it could answer these questions, because everything downstream depended on it: issuing certificates automatically with Certificate Services, applying settings at scale with Group Policies, and more.

There were always some compromises: databases with local users, Linux servers requiring workarounds (Thank you SSSD!), but most users and machines in my network had an identity in Active Directory, and I knew which didn’t.

But unifying every identity in Active Directory (or any one directory) is nearly impossible with modern cloud architecture. There’s an AD ecosystem of security products, password rotations, and sync plugins that modernizes it, but nothing can undo architecture choices from a bygone era.

Active Directory is the new mainframe: great for its time, but you’d never choose to start from scratch. Replacing it is impossible because it’s so entrenched.

Active Directory can accurately reflect human identities with a few integrations and plugins, but machine identities are nearly impossible.

Maybe that’s controversial. You can come to me with torches, pitchforks, and architectural diagrams about Kubernetes pod identity attestation in AD, but Active Directory is still a piece of infrastructure built for a bygone era.

Visibility and attestation: Unified machine identity is nearly impossible in Active Directory

Most organizations are creating grave security risks because they don’t understand modern machine identity. I once spoke to someone at a conference who told me they had recently discovered a publicly exposed Lambda function. Bad enough, but that function’s policy was iam:* meaning it could take any IAM action, including crowning any attacker the organization’s superadmin. Oh, and by the way, this was a defense organization.

If an organization with high security requirements makes these blunders, you don’t want to know what happens at other organizations. This problem isn’t specific to AD, but it is a symptom of organizations not figuring out how to correctly attest machine identity in modern software development.

To understand why no organization can account for all of its machine identities in AD, we need to understand how a machine enters a domain. A domain is an administrative boundary that shares security rules. In practice, this is usually an organization.

When a new machine joins your domain, three main events happen:

• An object is created inside the directory (often called a machine account)
• DNS is updated, certificates are issued (assuming you have AD Certificate Services autoenrollment)
• Kerberos tickets are issued so the machine can assert its identity

When that machine logs in, it authenticates to a Domain Controller (the server running Active Directory for the domain), which trusts it because the machine is in its directory. But the machine had to enter the directory first.

When Active Directory was built, that meant a human manually added it. “Machines” were physical servers that got delivered to the office, installed in the server dungeon room, and registered by a human admin.

Human approval doesn’t scale to developers creating and deprecating testing databases, Kubernetes clusters, and CI runners at will. Contemporary AD implementations deal with this by deferring authority. An admin token (sometimes hardcoded…) automatically joins new identities.

Using human credentials to join new machines is a workaround that negates the point: Admin approval implies a human can tell you about each trusted device.

No admin can know every EC2 instance, PostgreSQL database, or CI runner in the organization. This is also because when AD was built, machine identities were long-lived devices, not ephemeral cloud resources.

Active Directory was built for human approval of long-lived infrastructure, but now often auto-approves short-lived cloud resources.

Even if you built all of the complex automations to reflect every testing database and Kubernetes pod in AD with automated admin approval, it’s security theater. The unified directory would exist on paper, but lack authority.

Modern cloud infrastructure automatically asserts machine identity:

• In Kubernetes, each pod gets a service account token, which allows it to assert its identity within the cluster.
• In Azure, you can configure a machine identity in Entra ID and let Azure’s Instance Metadata Service (IMDS) automatically issue OAuth tokens when machines request them.

These two examples have modern assumptions baked in: machines need to self-serve their identities when they’re spun up. They also assume a narrow scope.

Scope: how identity perimeters have changed

The unified directory of identity management aimed to encompass every device, user, and piece of infrastructure. Authenticating to the Domain Controller would be enough to get access to everything a user/machine needs and nothing they don’t.

This is the identity perimeter: where an identity is valid. In the Active Directory era, the perimeter was as large as possible. The more complete the perimeter, the more authoritative the directory. As an example, SQL Server accepts Windows authentication (i.e. an AD identity) or SQL authentication (username and password). Active Directory admins choose Windows auth to keep the perimeter large.

Anything outside of the directory would be a “shadow identity”: a valid identity that grants access to corporate infrastructure, but isn’t accounted for in identity management (unless you consider the post-it note on my monitor identity management).

A separate username-password set creates a separate perimeter. This used to be a problem, but is now the norm. Each API key, database string, or auth token creates a separate perimeter because they’re a credential that represents an identity for just one service. As an example, GitHub automation requires personal access tokens or GitHub private keys and doesn’t work with any directory identity.

But just to make it harder, zero-trust architecture makes machines constantly authenticate to each other, which skyrockets the count of credentials and creates hundreds of perimeters.

In theory, a small perimeter shrinks the blast radius of any breach: A compromised Notion session token should only give Notion access. In practice, an attacker may find additional credentials in Notion, which lets them expand their access. Oh, and the physical security layer of firewalls and physical perimeters is gone in the cloud era, so a leaked credential works from any attacker’s laptop.

This should concern admins more than it does: many teams keep troves of sensitive plaintext credentials in .env files or hardcode them in configuration files. The response is often lackluster:

• Use SSO where it’s available for human users
• Teach the team how to securely handle plaintext machine credentials

A solution like Active Directory is nearly useless for solving these issues.

The new paradigm

Organizations can tame the complexity of machine identity in the cloud, but not as simply as one massive Active Directory list. Instead, we see two main vectors to fix this:

The first is identity federation, where one platform trusts another platform’s approval to authenticate a workload. All three major clouds support this.

Using OpenID Connect (OIDC), AWS can sign a token for an EC2 instance to access PostgreSQL in Azure. Entra federated credentials natively support this use case and would trust the EC2 workload.

This works for many use cases. If you’re exclusively on AWS and run Terraform from GitHub Actions, OIDC federation straight into IAM does the job: You get visibility, know why you trust it, and know its scope. But it’s laborious to implement each relationship, which means it relies on IAM administrators who can barely keep up with group membership requests. Moreover, if said pipeline is breached by, say, a supply chain attack (which are common nowadays), the whole perimeter is breached.

Even if your admins are bored, no cloud has native bridges between every possible tool, so federation stops as soon as any service only accepts an API key. Organizations shouldn’t accept unruly, long-standing plaintext credentials outside of security purview.

That’s why organizations adopt a brokering approach. Here, credentials live in a secrets manager like Infisical (which securely stores and then delivers secrets to workloads at runtime). This creates a meta-perimeter for all of those micro-perimeters. Infisical (or another tool) acts like a broker: Machines authenticate to it, they broker access to the credential store, and inject the credentials the identity can read into its runtime.

These two patterns can bring order to the Wild West of machine identity in the cloud era. They check the boxes Active Directory once did:

• What identities exist? You have an overview of who authenticates and what they do
• What vouched for the identity? You know where workloads originate and why they’re trusted without relying on a human to approve everything
• Where is the identity valid? Keys, tokens, and strings have a natural perimeter.

This is especially important as organizations increasingly adopt AI agents, which often need their own identities, separate security policies, and even separate security tooling. Getting machine identity right is more important than ever. If you can’t keep track of testing databases and a Stripe API key, you don’t want autonomous software that can create its own databases and send that API key to strangers online.