Directory consolidation: when two directories help and when they fail

Two directories are not automatically a problem

A second directory is not always technical debt. In 2026, many enterprises run one directory for workforce identity and another for customer, partner, or workload identity because the trust boundaries are different. The failure starts when the second directory exists because no one wanted to decide ownership, lifecycle, or source of truth.

A real pattern: a global manufacturer keeps Microsoft Entra ID for employees and contractors, and a separate OpenLDAP-backed directory for plant-floor devices and legacy MES applications. That is a strategy. Another pattern: the same company clones user records into a second directory "for performance" and then spends 18 months reconciling 7,400 duplicate accounts after an acquisition. That is failure by indecision.

The question is not "one directory or two." The question is whether the split is intentional, measurable, and reversible.

When two directories are a strategy, not a symptom

Two directories make sense when they solve a boundary that one directory cannot solve cleanly. The strongest cases in 2026 are governance, latency, regulatory separation, and lifecycle isolation.

1) Different trust domains need different controls

If you have workforce identity and customer identity in the same directory, you usually inherit the weakest common control. That creates problems for MFA policy, attribute exposure, and retention.

Example:

• Employees: Entra ID with phishing-resistant MFA, Conditional Access, and SCIM provisioning to SaaS.
• Customers: Auth0 or a custom IdP with privacy-minimized profiles, consent tracking, and region-specific retention.

This split is strategic because the data models differ. A customer profile may need only email, locale, and consent flags. A workforce profile may need manager, cost center, device posture, and role history. Forcing both into one schema often creates overexposure.

2) Edge and legacy systems still need local directory performance

Some production systems cannot tolerate round-trip identity lookups to a cloud directory. In a plant, hospital, or trading environment, 80 to 150 ms of auth latency can be unacceptable.

A common 2026 design:

• Central directory for policy and identity governance.
• Local directory replica or cache for site access.
• Sync interval: 30 to 60 seconds for critical attributes.
• Read latency target: under 10 ms on the local network.

That split is rational when the site must keep operating during WAN degradation. It becomes a failure when the local directory starts accepting writes for core identity attributes without a clear reconciliation owner.

3) M&A and divestitures need temporary separation

During a merger, you may need two directories for 6 to 18 months while legal entities, email domains, and access policies are harmonized. That is not indecision if you have a sunset plan.

A practical example:

• Day 0 to 90: federated access, no account merge.
• Day 90 to 180: duplicate detection and attribute mapping.
• Day 180 to 365: authoritative source selection by attribute domain.
• After day 365: decommission the redundant directory or keep it only for a bounded edge use case.

The key is that the second directory has a retirement date. Without one, temporary becomes permanent.

4) Regulatory separation can justify two directories

In 2026, many organizations still need data residency controls across regions, especially for healthcare, public sector, and financial services. A European employee directory and a US directory may be separate to satisfy residency and access constraints.

That is legitimate if:

• The data classes differ.
• Replication rules are explicit.
• Cross-border access is mediated through policy, not ad hoc sync jobs.

If the same person exists in both directories with different identifiers and conflicting attributes, you do not have a strategy. You have two sources of truth.

When two directories are a failure to decide

Two directories become a liability when they hide unresolved questions: who owns identity, where does truth live, and which system is authoritative for each attribute.

1) Duplicate account creation without a source-of-truth model

If HR creates a user in one directory, IT creates the same user in another, and both systems can change email or group membership, you will eventually get drift.

A common symptom is "shadow identity ops." You see:

• 3 to 5 percent duplicate identities after an acquisition.
• 12 to 20 percent of support tickets tied to access mismatches.
• 2 to 4 hours of manual work per exception during onboarding.

That is expensive. At 500 onboarding events per month, even 15 minutes of manual correction per event is 125 hours of admin time monthly.

2) Sync jobs replace governance

A directory sync tool is not an identity architecture. If your answer to every mismatch is "run the sync again," you are using automation to postpone a decision.

Typical failure pattern:

• HRIS is authoritative for name, manager, worker type.
• IAM team wants directory admins to edit department and title.
• App teams update group membership locally.
• A nightly sync overwrites half the changes and preserves the other half.

This creates brittle behavior and audit risk. The system may look stable until an incident forces a manual override.

3) Two directories with overlapping write permissions

The most dangerous setup is two directories that both accept writes for the same attributes. That produces race conditions, stale group membership, and broken deprovisioning.

Concrete example:

• Entra ID updates jobTitle from Workday.
• A local AD forest updates jobTitle from an admin script.
• A downstream app uses the local value for role assignment.
• The user retains privileged access for 17 days after role change.

That is not a directory problem alone. It is a governance failure.

The decision framework CTOs can use

You can decide whether two directories are strategic by testing five questions. If you cannot answer them in one sentence each, you do not have a clean design.

1) What is authoritative for each attribute?

Make a table. Not a policy memo.

Attribute          Authoritative system   Writable elsewhere?
-----------------  ---------------------  -------------------
Legal name         HRIS                   No
Preferred name     IdP                   Yes, but reviewed
Manager            HRIS                   No
Group membership   IAM platform          No
Email alias        Directory service      No
MFA method         IdP                   No

If the answer is "both," define which one wins and how conflicts are resolved.

2) What is the boundary between the directories?

Boundaries can be organizational, technical, or legal. Good boundaries are visible in architecture diagrams and access reviews.

[HRIS] -> [Primary IdP] -> [SaaS apps]
                   |\
                   | \-- SCIM for workforce apps
                   |
                   +--> [Local directory cache at plant site]
                           |
                           +--> OT apps, badge readers, MES

If the boundary is "historical reasons," you have a cleanup project, not a design.

3) What is the failure mode if one directory is unavailable?

A strategic two-directory model has a clear degraded mode.

Example targets:

• Local site access continues for 8 hours during WAN outage.
• Customer login remains available with 99.95 percent monthly uptime.
• Deprovisioning delay never exceeds 15 minutes for privileged accounts.

If outages cause random behavior across both directories, you are overcoupled.

4) How do you measure drift?

You need metrics, not vibes.

Useful metrics in 2026:

• Duplicate identity rate below 0.5 percent.
• Attribute mismatch rate below 1 percent across critical fields.
• Deprovisioning SLA under 15 minutes for privileged access.
• Directory sync lag under 60 seconds for high-risk attributes.
• Authentication p95 latency under 200 ms for remote users and under 20 ms for local edge users.

If you cannot report these monthly, the second directory is probably hiding work.

5) Can you retire one directory without breaking business?

A strategic split has an exit path. Test it with a migration plan.

A practical migration sequence:

1. Freeze new writes in the old directory for non-edge attributes.
2. Map authoritative attributes to the target system.
3. Move authentication to federation or pass-through.
4. Repoint apps in waves by business unit.
5. Archive the old directory and remove admin access.

If the answer is "no, because we might need it someday," that is not a strategy.

Reference architecture for intentional directory consolidation

Directory consolidation does not always mean deleting one directory. It often means consolidating authority while keeping a narrow operational replica or specialized directory.

Recommended pattern

• One primary identity authority for workforce identity.
• One policy engine for access and lifecycle.
• One optional edge replica for low-latency local access.
• One separate customer or partner directory only when privacy or schema demands it.

Practical implementation details

For Microsoft-heavy environments, a common 2026 setup is:

• Workday as HR source of truth.
• Entra ID as workforce identity provider.
• SCIM to SaaS apps.
• AD DS retained only for legacy Kerberos, GPO, or on-prem apps.
• Azure AD Connect or Cloud Sync minimized to only the attributes still required.

For Linux-heavy or mixed environments:

• FreeIPA or OpenLDAP for local auth in constrained environments.
• External IdP for SSO and policy.
• Short-lived credentials and certificate-based access for servers and services.

Example sync rule snippet:

rules:
  - attribute: employeeType
    source: Workday
    target: EntraID
    writable: false
  - attribute: groupMembership
    source: IAM
    target: AD_DS
    writable: false
  - attribute: badgeAccess
    source: PhysicalAccessSystem
    target: LocalEdgeDirectory
    writable: true
    ttl: 24h

That kind of explicit ownership prevents the second directory from becoming a dumping ground.

Common Pitfalls

The most expensive mistakes are usually not technical. They are governance shortcuts.

• Treating a sync tool as the architecture. Fix it by writing attribute authority rules before you configure replication.
• Allowing both directories to edit the same fields. Fix it by making one system read-only for shared attributes.
• Keeping a temporary directory forever. Fix it by assigning a sunset date and a migration owner.
• Using local directories for convenience, then exposing them broadly. Fix it by limiting scope to edge, legacy, or regulated workloads.
• Ignoring latency and outage behavior. Fix it by testing WAN failure, cache expiry, and deprovisioning under load.
• Failing to measure drift. Fix it by reporting duplicate rate, sync lag, and access exception volume every month.

One enterprise I reviewed had 11 directories across subsidiaries. The real issue was not the count. It was that only three had documented owners and none had a decommission plan. They spent more on identity cleanup than on the actual apps those directories supported.

How to decide this week

Start with a short, brutal audit.

1. List every directory, forest, tenant, and identity store.
2. Mark each as authoritative, replica, cache, or legacy holdover.
3. For each shared attribute, name exactly one writer.
4. Measure duplicate identities, sync lag, and deprovisioning time.
5. Assign a sunset date to every directory that is not clearly strategic.

If you cannot explain why two directories exist in one sentence, they are probably evidence of an unresolved org chart, not an identity design.

Key Takeaways

• Two directories are strategic only when they enforce a real boundary: trust, latency, regulation, or lifecycle.
• If both directories can write the same attributes, you have a governance problem, not a platform choice.
• Define one authoritative source per attribute and document it in a simple matrix.
• Track duplicate rate, sync lag, and deprovisioning SLA as monthly operating metrics.
• Keep temporary directories temporary by assigning an owner and a sunset date.
• Consolidate authority first; keep a second directory only if it solves a measurable business constraint.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.