Horizons Consulting

Horizons Consulting
Talk with Expert

Plan a Hybrid Identity Strategy Before Cleaning Legacy Active Directory

Hybrid identity and legacy Active Directory are tightly linked. If you start “cleaning up” legacy AD without first designing how identities will work across AD and Microsoft Entra ID, you risk breaking sign-ins, apps, and admin workflows. This guide walks step-by-step through defining hybrid identity, assessing your current AD and Entra posture, identifying legacy AD risks, and choosing the right sync model before you touch cleanup or modernization. 

Strategy before cleanup

Legacy Active Directory often contains decades of technical debt: old domains, stale users, forgotten groups, and dependencies no one remembers. At the same time, cloud adoption has introduced Microsoft Entra ID (formerly Azure AD) for SaaS, cloud apps, and modern access controls. If you delete or modify legacy objects in AD before understanding how they relate to Entra, you can break hybrid sign‑ins, group‑based access, or application authentication. 

The right order is simple: design the hybrid identity strategy first, then execute cleanup and modernization under that strategy. That means defining what hybrid identity looks like for your organization, understanding the current state of both AD and Entra, mapping risks, and selecting a sync model that will remain stable while you clean up and evolve. 

What hybrid identity is ?

Hybrid identity in Entra ID

Hybrid identity is the model in which a user has one identity that works across on‑premises and cloud resources. A single user account can authenticate and be authorized to access:
 

  • On‑premises resources such as file shares, legacy web apps, and line‑of‑business systems. 
  • Cloud resources such as Microsoft 365, SaaS apps, and custom applications are integrated with Microsoft Entra ID. 


Under a hybrid identity, account lifecycle, attributes, and group memberships are coordinated across AD and Entra. Users do not need separate, unmanaged identities in multiple directories. Instead, there is a consistent identity fabric that spans both environments. 

Common Hybrid Scenarios

You will typically see a mix of scenarios: 

 

    1. On‑premises users synced to Entra ID, signing into both local resources and cloud apps. 
    2. Cloud‑only users (for example, externals, partners, or some service accounts) are defined directly in Entra ID. 
    3. Applications that still authenticate directly against AD (Kerberos, LDAP) alongside SaaS applications integrated with Entra ID and using OpenID Connect or SAML. 

 

Understanding where each identity and each application live is mandatory before you change anything in legacy AD. Hybrid identity is not a single feature; it is the overall pattern that connects all these pieces. 

Step 1: Assess current Active Directory posture

Start with AD, because most legacy risk originates there. 

Map forests, domains, and trusts 

Document: 

  1. All forests and domains in your environment, including test or “temporary” ones that have lingered. 
  2. Trust relationships between domains and forests, including any external or forest trusts. 

This gives you the structural map. Many legacy issues come from old domains kept alive for a single application or historical reasons. Trusts can also hide dependencies; an application in one domain might rely on accounts or groups in another. 

Analyze directory health

Before you rely on AD as the anchor for hybrid identity, ensure it is healthy: 

  1. Check replication status to ensure domain controllers are consistent. 
  2. Confirm DNS health, as AD relies on DNS for service location. 
  3. Verify time synchronization, especially if Kerberos is in use. 
  4. Review FSMO role placement and stability. 


You also need to confirm backup and recovery capabilities. Ensure you have: 

  1. Recent backups of domain controllers. 
  2. Active Directory Recycle Bin is enabled where possible for object recovery. 
  3. Documented restore procedures. 


A cleanup or sync change on a brittle AD can turn a minor misconfiguration into widespread outages. 

Understand object structure

Review how your objects are organized: 

  1. OU structure: where users, groups, and computers are actually located. 
  2. Delegation: Which teams or roles can modify which OUs? 
  3. Special OUs for service accounts, admin accounts, or privileged groups. 

Messy OU structures often indicate unmanaged growth. They also impact how you scope synchronization and cleanup. For example, syncing entire domains instead of specific OUs might bring a lot of legacy clutter into Entra that you do not want. 

Highlight legacy patterns

Identify visible legacy markers, such as 

  1. Old domains that exist “just for one app.” 
  2. Retired domain controllers that were never fully removed. 
  3. Long‑unused test environments that still contain accounts referenced in scripts or apps. 

This step does not change anything yet. You are building a mental model of where legacy complexity might collide with hybrid identity.  

Step 2: Assess current Microsoft Entra ID posture

Once AD is understood, do the same for Entra ID. 

Tenant landscape 

Determine: 

  1. How many Entra ID tenants does your organization use, including lab, Dev/Test, or shadow tenants created by teams or acquired businesses? 
  2. Which tenant is considered the primary corporate tenant for production identities and applications? 

Multiple tenants complicate hybrid identity. You need clarity on which tenants will participate in hybrid scenarios, which are candidates for consolidation, and which should remain isolated. 

Identity types and sign‑in methods

For the primary tenant, classify identities: 

  1. Synced users whose source is AD. 
  2. Cloud‑only users are created directly in Entra ID. 
  3. Guest accounts representing partners or external users. 


Review sign‑in controls: 

  1. MFA adoption levels. 
  2. Conditional Access policies and their coverage. 
  3. Legacy authentication is still allowed for some protocols or apps. 

Your hybrid strategy must account for how these identities are currently secured and where there are gaps.

Application and resource usage

Inventory: 

  1. Enterprise applications integrated with Entra ID, including Microsoft 365 and third‑party SaaS. 
  2. Service principals, managed identities, and application registrations. 
  3. Group assignments are used for access to apps or resources. 

Pay special attention to apps that rely on synced AD groups or specific attributes, because cleanup in AD that touches those groups or attributes can break access in the cloud. 

Governance and security baselines

Determine whether basic governance is in place: 

  1. Defined identity ownership. 
  2. Baseline security controls (MFA, conditional access, and sign‑in risk policies). 
  3. Monitoring and alerting via centralized logging. 

If the Entra tenant is loosely governed, you may need to solidify its controls as part of the hybrid strategy. You do not want to connect a messy AD directly to an ungoverned tenant. 

Step 3: Identify legacy Active Directory risks

With both AD and Entra mapped, identify the specific risks in legacy AD that impact hybrid identity. 

Legacy accounts and groups 

Look for: 

  1. Stale user accounts 
    Disabled accounts never deleted, accounts with no logon activity for long periods. 
  2. Orphaned groups 
    Groups with no clear owner or documented purpose. 
  3. Excessive nesting  
    Complex group structures that are hard to reason about. 


These objects often end up synced to Entra ID, cluttering the cloud directory and making access control harder to manage. But deleting them prematurely can break access if they are still referenced somewhere. 

Legacy authentication and protocols

Legacy authentication patterns often include: 

  1. Applications that rely on NTLM or older, insecure protocols. 
  2. Unconstrained or misconfigured Kerberos delegation. 
  3. Service accounts with hard‑coded passwords in scripts, batch jobs, or application configuration. 

These patterns make hybrid identity more fragile, because they often bypass modern controls. You need to account for them, either by containing them or planning replacement, before you shift identity models or clean up accounts. 

Structural and governance issues

Examples: 

  1. OUs without clear owners, where anyone with broad rights can make changes. 
  2. Administrators use high‑privilege groups (like Domain Admins) for routine tasks. 
  3. Lack of documented joiner‑mover‑leaver processes. 

These issues make it hard to know which objects are safe to change. Without governance, cleanup is guesswork. 

Business and compliance impact

Not all legacy objects are equal. Some are attached to: 

  1. Systems that handle regulated data. 
  2. Critical business processes that cannot tolerate downtime. 

Map which legacy elements support highly sensitive or critical workloads. Those areas require careful planning and sometimes a slower path, even after you have a hybrid strategy. 

Step 4: Define hybrid identity principles and outcomes

Before selecting tools or configs, define what you want the steady state of hybrid identity to look like. 

Target identity model 

Decide: 

  1. Every user should have exactly one primary identity, synchronized between AD and Entra, or only in Entra for certain categories (for example, some externals). 
  2. How you will treat guests, contractors, and shared or service identities. 
  3. Whether the HR system feeds AD, Entra, or both, and how that flow is governed. 

This decision affects master data: where accounts originate, where changes are made, and how they propagate. 

Security principles

Apply a consistent set of principles: 

  1. Verify explicitly: 
    Do not rely on network location alone; enforce strong authentication and context‑based access where possible. 
  2. Use least privilege: 
    Minimize permanent admin rights, especially in legacy AD groups, and consider just‑in‑time access for privileged operations. 
  3. Assume breach:
    Design a hybrid identity as if attackers might compromise either AD or Entra, and ensure that a breach in one does not automatically grant wide privileges in the other.     

These principles should guide your decisions about which identities sync, how they are protected, and how legacy systems are isolated. 

Governance outcomes

Define goals such as: 

  1. Clear ownership for AD forests, domains, and the Entra tenant. 
  2. Documented lifecycle rules for accounts and groups (creation, modification, deprovisioning). 
  3. Consistent naming, placement, and grant patterns make it easier to identify and remove legacy clutter over time. 

With outcomes defined, you can evaluate sync options and cleanup plans against them. 

Step 5: Choose the right sync model before cleanup

With principles in place, choose your sync approach deliberately. 

Understand available sync options 

There are two main patterns: 

  1. Microsoft Entra Connect Sync: traditional, feature‑rich sync engine deployed on‑premises, supporting complex AD topologies, writeback scenarios, and rich transformation rules. 
  2. Microsoft Entra Cloud Sync: lighter‑weight, cloud‑managed sync using lightweight agents, intended for more flexible and scalable scenarios, especially multi‑forest or where you want to reduce dependency on a single on‑prem sync server. 

Your choice affects how quickly you can adjust scopes, attributes, and topologies as you modernize. 

Match sync tool to your topology

Consider: 

  1. Single forest, single tenant: often simplest to run Connect Sync initially, possibly moving to Cloud Sync later if it aligns with your roadmap. 
  2. Multi‑forest, single tenant: Cloud Sync can simplify multi‑forest scenarios by allowing multiple agents and configurations, avoiding over‑complex Connect rules. 
  3. Special cases: mergers and acquisitions, lab or dev forests, and environments that should remain isolated or only partially synced. 

You want a model that supports your current complexity but does not block future simplification. 

Decide source of authority for identities

Clarify: 

  • Which attributes are authoritative in AD and which are authoritative in Entra ID. 
  • How you will handle UPNs, email addresses, and display names to avoid collisions and confusion. 
  • How custom attributes or directory extensions will be managed. 

If you do not define this, cleanup actions might accidentally change attributes that Entra or applications depend on, causing subtle failures. 

Plan for eventual migrations

Even if you start with Connect Sync, keep in mind: 

  1. You may later move to Cloud Sync or consolidate forests.
  2. You may change which tenant is primary if there are multiple today. 

Design sync configurations with migration in mind: avoid hard‑coding assumptions that will be painful to unwind later. 

Step 6: Design high‑level sync and scope boundaries

Once you know the model, decide exactly what to sync. 

Decide what to sync 

Scope decisions include: 

  1. Which forests and domains will be included in hybrid identity. 
  2. Which OUs will be in sync scope and which will be excluded. 

For legacy cleanups, it is often better to narrow the scope so only relevant, managed objects are synced. Old test OUs or deprecated domains can be excluded while you plan their eventual retirement. 

Attribute and filtering strategy

Define: 

  1. Attribute mappings needed for applications, HR integration, and governance reporting. 
  2. Filters to exclude clearly obsolete or high‑risk objects (for example, certain service accounts) from being synced until they are properly evaluated. 

By controlling what enters Entra, you prevent legacy clutter from spreading. Cleanup can then focus first on unsynced areas while leaving the core hybrid identity intact. 

Handle special cases

Decide how you will treat: 

  1. Service accounts: some should remain on‑premises only, others might be candidates for managed identities or other modern approaches. 
  2. Break‑glass or emergency accounts: often kept on‑premises and/or in Entra, but handled with special precautions and not treated like normal users. 
  3. Test and pilot users: used to validate new sync and governance changes before full rollout. 

These special cases should have explicit rules so they do not become another source of legacy confusion. 

Step 7: Establish governance before touching legacy objects

With sync boundaries defined, put governance in place before any cleanup. 

Ownership model 

Assign: 

  1. Directory owners for each AD forest and the Entra tenant. 
  1. Application owners who can speak to group and account usage. 
  1. Clear approval flows for changing sync scope, deleting groups, or modifying key attributes. 

Without named owners, you cannot reliably know whether a group or account is still required. 

Policies for new identities and groups

Write and agree on: 

  1. Naming conventions that encode purpose and scope. 
  2. Rules about where new accounts and groups belong (which OU, which tenant, which group type). 
  3. Joiner‑mover‑leaver processes that ensure identities and access are updated as people change roles or leave. 

These policies prevent new legacy from being created while you are still cleaning up the old. 

Audit, logging, and change control

Ensure: 

  1. Changes in AD and Entra (especially group membership and attribute updates) are logged centrally. 
  2. Cleanup activities follow a change management process with documented requests, approvals, and rollbacks. 
  3. You can correlate sync changes with identity behavior (for example, sign‑in failures) when issues arise. 

Good observability lets you experiment and clean with confidence instead of fear. 

Step 8: Build a phased roadmap toward cleanup

Now that you have a hybrid identity strategy, convert it into a roadmap. 

Separate strategy from execution 

Confirm that: 

  1. Hybrid identity design, sync model, and governance decisions are documented and agreed. 
  2. Everyone understands that cleanup will follow these decisions, not precede or contradict them. 

This prevents teams from making local changes that undermine the overall strategy. 

Define cleanup waves

Plan: 

  1. A pilot wave with low‑risk OUs or business units where you can test cleanup patterns such as identifying unused groups, migrating applications to new groups, and adjusting sync filters. 
  2. Subsequent waves for more complex or high‑risk areas, using lessons learned from the pilot. 

You can also schedule parallel streams, such as: 

  1. Structural cleanup (OU and group reorganization). 
  2. Account lifecycle cleanup (stale accounts). 
  3. Application modernization (moving apps from AD to Entra‑based auth). 

Guardrails and rollback

Before executing each wave: 

  1. Confirm backups and AD Recycle Bin status. 
  2. Define exactly how you will roll back if a cleanup step breaks something (for example, reinstating deleted groups, undoing a sync rule change). 
  3. Set observation windows where changes are monitored before moving to the next step. 

Guardrails make it possible to act decisively while containing risk. 

Conclusion: Hybrid identity first, cleanup second

A legacy Active Directory environment is not just an administrative inconvenience; it is a structural risk that touches security, compliance, and productivity. But trying to clean it blindly, without a clear hybrid identity strategy, is more likely to cause outages than meaningful improvement. 

The disciplined approach is to: 

  1. Define hybrid identity in your context: one coherent identity across AD and Entra ID. 
  2. Assess AD and Entra posture so you truly understand the current state. 
  3. Identify specific legacy AD risks that affect identity and access. 
  4. Choose a sync model that fits your topology and future plans. 
  5. Establish governance so changes are controlled and observable. 
  6. Only then, execute cleanup and modernization in planned, reversible waves. 

When you respect that order, cleanup becomes an extension of a well‑defined hybrid identity architecture rather than a risky, one‑off project.