Consolidate with Confidence: Reduce Risk and Enhance Performance Across your AD Environment

Let’s get started. My name is Wade Ellery. I’m an IAM Strategist at Radiant Logic. Today I’m going to talk to you about consolidating with confidence—reducing risk and enhancing performance across your AD environment. This is specifically focused on consolidating multiple AD domains across your environment to increase security, visibility, and integration capabilities.

When you visualize your AD environment, does it look like a scattered bunch of security concerns and domains, all on different systems, running in different places, all managed separately and mostly manually, each configured a little differently? It can look like a mess where you can’t see across the organization. You don’t really know what you have, and you’re afraid to change anything because, right now, it’s at least working.

Does it feel like chaos? Does it feel like your auditor is on your shoulder asking for accountability that you can’t give them? People are asking for access to resources in different domains that you can’t provide. People look to you to solve all their problems, but the environment is so chaotic and unsupported from a business perspective that it’s a real challenge to make everything fit.

Would you rather have it look like this: one big consolidated view where you have everything at your fingertips, and you can see across the whole organization as if it were one harmonious model working together? Imagine focused views where you can zoom in on particular areas of concern—“let me see all the finance applications and systems running across my whole multi‑domain model”—and individual views of each domain that you can dive into when you need specific details from a particular area. We’re not suggesting you collapse everything into one single AD domain; that’s usually not feasible. What we’re talking about is giving you consolidation and visibility and the ability to see and manage your environment as one, which you probably don’t have today.

You want it to operate like a symphony. You want the conductor at the front to be able to see everyone. You want everyone playing from the same sheet of music, using the same onboarding processes, the same auditing processes, the same conventions for security and backup. They’re all operating as a team, although individually they still operate in their own niche. The violins play one part, the cellos another, the clarinets another. Together it’s a symphony; separately they operate independently. You want a model where you can have both: domains that still exist for good local reasons, but with a layer that lets you manage everything as a single orchestra. Let’s see how we can get you there.

Why consolidate Active Directory? One reason is that Microsoft essentially told you to. When Microsoft started moving everyone to Azure AD—or Entra ID, as it’s now known—or when you talk to Okta, they all want your identities in one place, one common format, one common schema. That way they can simply import everything into their IDaaS directory in the cloud. These platforms are not good at understanding that you exist in three different domains and need one unified account with information from all three places. They want you to eliminate that complexity and get to a flat structure before you come to them. That drove a lot of panicked AD consolidation work—multimillion‑dollar, multiyear projects—and many of those failed because the challenges are real.

Enterprise‑level applications like Cerner, Epic, or your financial systems need to be accessed across the organization, but you have people in different domains. Those systems expect everyone in one place. You can’t provide that easily when you have multiple AD domains. You may also need to sunset acquired AD infrastructures from mergers. You join with another company; they have an AD forest; you have an AD forest. You need to collapse their forest and absorb their identities into yours, but their applications, structure, and schema extensions are incompatible with yours. You can’t just absorb their users and dump their system; you need a way to morph and migrate in an orderly manner.

You may have untrusted AD domains across the organization and find you can’t collaborate. Consider a federal agency with 168 districts across the US, each with its own domain. Executives move between districts and try to work, but they don’t have access in other districts because their primary identity is back in their home domain, and they can’t feasibly set up trust with 168 districts. They need a consolidated model for authentication, authorization, access, and audit, while still allowing each district to run autonomously and maintain a local AD domain for its own internal needs.

You also want to reduce costs and increase efficiency. We’re all told to do more with less, and this is an area where consolidation and smarter architecture can help. You want to reduce risk through visibility and observability. Visibility is the ability to see what’s happening across your organization—one pane of glass, a 360‑degree view across siloed AD domains. Observability goes deeper: actually looking inside those domains to see what’s happening. Who is being provisioned or deprovisioned? Who moved? Who gained authorization to a resource through a new group membership that didn’t come through a formal provisioning process? How do you catch risk and vulnerabilities in real time by watching these environments? You also want to increase compliance across the organization—rolling up from many independent domains at a department, agency, or state level into a coherent compliance and reporting posture.

In theory, maybe you’re doing this because you have unlimited funds, unlimited resources, and unlimited time—so why not? In reality, no one has all three, which is why many organizations never complete full AD consolidation. Traditional collapsing of AD environments is expensive, difficult, and often fails. So what can we do differently?

First, look at why you have separate AD domains. Historically, equipment was expensive, bandwidth limited, and distances large. It made sense to create local domains. Twenty years ago, I worked for a company with a domain login in New York while I sat in a West Coast office. I could log into my desktop, go get coffee, chat about the weekend, and 15 minutes later my “join the domain” operation would finally complete because traffic moved over very slow channels. Local domains for authentication and authorization made things workable, but they also siloed identity across the infrastructure. That’s a real challenge today.

The question is: is this still an issue? Yes. There are still many multi‑domain environments and even mainframes, despite predictions years ago that they’d disappear. I’m often surprised by how many customers and prospects still struggle with multiple untrusted AD domains as an albatross around their neck.

Why not just “smush” everything together into one AD domain? Because, although it’s all Active Directory from Microsoft, it’s not all the same. Different schemas exist in different directories. One organization may have extended the schema for an application’s attributes; another may populate “employeeNumber” while a third uses “employeeID” for similar data. Date formats and group naming conventions differ. One domain’s structure may be completely flat; another highly hierarchical with many OUs. This is not conducive to brute‑force consolidation; you can’t just pour everything into one domain without losing a huge amount of functionality.

You also have different onboarding processes, different local functions, and different constraints. In a hospital, for example, some domains exist mainly to manage shared workstations and medical equipment. You can’t push all of that into a global cloud directory and expect local systems to operate smoothly—they need local, specific configuration. On top of that, you have overlapping identities. “J. Smith” in two domains might be different people, while “JSmith” and “SmithJ” in two other domains might be the same person. If you merge everything without correlation logic, who wins? Who gets two accounts? It’s like apples: they’re all apples, but different varieties. All AD domains are AD, but with different flavors and textures. You can’t just mash them together.

What about setting up a web of trusts between domains? Anyone who has managed AD will tell you that trust is a last resort—cumbersome, difficult, fragile, and full of its own challenges. It’s not consolidation; it’s not simplification; and it still doesn’t give you comprehensive visibility or observability across the organization. You end up with a fragmented world that you still have to address differently.

If you look at your environment, you probably see multiple different structures even at the OU level. You may also have LDAP directories that aren’t AD schema at all—like inetOrgPerson‑based directories—that still hold important information. Simply brute‑forcing everything together doesn’t work. Wiping everything out and starting over would require those mythical unlimited time, resources, and money.

So how do we solve this? Yes, we can solve it. We’ve done it repeatedly for large corporations and government entities. The approach is federating identity through virtualization. This is different from federating access. When you do SSO to SaaS apps through Ping, Entra, or Okta, you’re federating access: putting application endpoints in one place so users sign on there. Here, we’re federating identity. We bring all identity data into one place through virtualization.

Virtualization gives you that magical, malleable middle layer that lets you transform, translate, normalize, remodel, and reshape disparate AD data into common formats and structures that can be shared, managed, audited, and used for authorization across your organization. Some vendors will suggest “just copy everything into our cloud directory and you’re fine,” but that’s the same problem as collapsing into a single AD domain. Their directories have a single schema and structure and are often hard to extend. You’ll be forcing square pegs and round pegs into triangular holes.

If you do that, you sacrifice functionality. On‑premise LDAP applications can’t authenticate against cloud IDaaS platforms directly. Policy‑based access control and zero‑trust decision points often can’t query that cloud identity data in the performance profile you need. IGA and PAM platforms can’t easily reach that data either. You create more silos.

Do you need an IDaaS platform in a modern environment? Yes—and you probably already have one. Office 365 brought Entra; Okta’s marketing may have brought Okta. That’s fine. But you should use Radiant Logic to consolidate your on‑prem AD data into normalized views and then provision those into your IDaaS platform. Your IDaaS directory then contains exactly the information you want to share—no more, no less—in the format and structure you choose. You then virtualize the IDaaS data back down into Radiant, where it’s added into the global profile so you have visibility both on‑prem and in the cloud.

IDaaS directories lack the flexibility, schema breadth, and richness to meet all your needs by themselves. You still need Radiant Logic.

What are your options? The simplest thing: if you have two domains, Radiant Logic can virtually create a new common root called “sources,” stack both domains under that, and expose that as an endpoint. Any application coming to the common root can traverse the tree and query both domains to find users, authenticate them, and get group information. This works well if every domain has a separate set of users and there’s no overlap. If you exist in more than one domain, the app will typically stop at the first match, so it won’t automatically combine your profiles. But for certain scenarios, that common‑root approach is fine.

Radiant then lets you go further. You can reorganize your views, build flat lists for SSO systems that can’t walk trees, and create harmonized hierarchies when you’ve done business reorganizations or acquisitions. Using Radiant’s tools, you can logically recreate new hierarchies based on existing attributes—country, department, project, and so on—and populate virtual trees accordingly. You can keep multiple views simultaneously: hierarchical for some systems, flat for others.

Change handling is real‑time. Instead of waiting hours for AD Sync or MIM to propagate changes, Radiant listens for AD changes at the millisecond level. A group join, termination, disable action, or account creation is detected immediately, brought up into Radiant’s layer, cached on disk, and made available in your virtual views. Models are pre‑built, so there’s no per‑request recomputation, and the infrastructure is designed to support hundreds of thousands of queries per second across millions of accounts.

Radiant also addresses group complexity. Active Directory often relies on groups for authorization. Different domains may use group names differently—“Sales” in one domain might mean direct sales, while in another it means partner sales. You may want to consolidate groups or at least present a harmonized view for access management. Radiant can lift group structures into a common root, remap group names and scopes, and handle nested group flattening. Nested groups are especially important because many consuming platforms can’t fully unravel deep nesting. Radiant can unwind nested groups into explicit membership lists when provisioning into IDaaS or IGA platforms, so those systems see exactly who is in which group.

Radiant also enables correlated identity views: you can merge identity information from multiple directories (and other sources) into unified profiles that include attributes and memberships from all relevant sources. If someone exists in several directories, Radiant can combine their records into a single logical identity for consuming systems, while still preserving the original context and IDs where needed.

The big picture: Radiant takes all your AD forests, plus additional data—training systems, clearance systems, security platforms, LDAP directories, databases, SaaS apps, HR systems, anything with well‑documented APIs or SCIM—and ingests them into a platform‑ and schema‑agnostic integration layer. There, identity is correlated, modeled, and managed. That unified identity layer is stored in a highly available, high‑performance directory infrastructure (HDAP) that supports massive scale and rich queries.

Radiant then publishes this modeled identity out as LDAP endpoints, REST APIs, SCIM endpoints, and other interfaces. Access‑management platforms (on‑prem and IDaaS), IGA platforms, PAM platforms like CyberArk and BeyondTrust, and runtime authorization or zero‑trust engines can all consume the same, clean, normalized identity data. That means your policy decision points no longer have to chase identity attributes across seven systems in real time. They can call Radiant, see a single coherent identity, and make a decision based on accurate, up‑to‑date data.

This is why Radiant Logic is a foundation for zero trust. It brings all identity data from your many sources into a unified, correlated model and shares that model back out to all the consumers of identity. Everyone is “playing the same symphony,” even if each system is focused on its own part. And yes, this is real; customers are doing this now, from large manufacturers to large enterprises with millions of identities, to federal agencies with hundreds of independent domains.