Hybrid IAM Coexistence: Running On-Premise and Cloud Identity Systems in Parallel

The day you decide to move identity to the cloud, you start a coexistence period. Whether it lasts 6 months or 3 years, your organization will run two identity systems simultaneously. Applications will live in both environments. Users will expect seamless SSO regardless of where the app is hosted. And any gap in the federation chain means someone can’t do their job.

Getting hybrid IAM right is the difference between a controlled migration and a chaotic one.

Why Coexistence Is Unavoidable

You can’t migrate 200 applications overnight. The application dependency graph, change management processes, and testing requirements make a phased migration the only realistic option. During this phase:

• Some applications trust the on-premises IdP (ADFS, PingFederate, on-prem Keycloak)
• Other applications trust the cloud IdP (Entra ID, Okta, Auth0)
• Users need access to both sets of applications with a single login
• User provisioning must keep both systems synchronized
• Security policies must be enforced consistently across both environments

Architecture Pattern: Hub-and-Spoke Federation

The most common hybrid pattern establishes the cloud IdP as the primary authentication hub, with the on-premises IdP as a federated spoke:

                         ┌─────────────────┐
                         │  Cloud IdP      │
                         │  (Primary Hub)  │
                         └───┬─────────┬───┘
                             │         │
                    Federation         Direct Trust
                    Trust (SAML)       (OIDC/SAML)
                             │         │
                    ┌────────┴──┐  ┌───┴──────────┐
                    │On-Prem IdP│  │  Cloud Apps   │
                    │  (Spoke)  │  │  (SaaS, etc.) │
                    └────┬──────┘  └───────────────┘
                         │
                    Direct Trust
                    (SAML/Kerberos)
                         │
                    ┌────┴──────────┐
                    │  On-Prem Apps │
                    │  (Legacy)     │
                    └───────────────┘

How it works: Cloud apps authenticate directly against the cloud IdP. When a user needs to access an on-premises app, the cloud IdP redirects to the on-premises IdP via federation. The on-premises IdP authenticates (possibly via Kerberos for domain-joined devices) and returns a token to the cloud IdP, which issues a session.

The result: Users log in once at the cloud IdP and can access both cloud and on-prem apps.

Directory Synchronization Strategies

Strategy 1: One-Way Sync (AD → Cloud)

Active Directory ──sync agent──→ Cloud IdP
     (source)                    (replica)

The most common approach. AD remains the source of truth. A sync agent (Entra Connect, Okta AD Agent, Keycloak LDAP Federation) pushes user and group changes to the cloud IdP.

Pros: Simple, well-supported by all vendors, HR processes don’t change. Cons: Delay between AD change and cloud propagation (typically 30-60 minutes), group membership sync can be complex.

Strategy 2: Bi-Directional Sync

Active Directory ←──sync──→ Cloud IdP

Changes in either system propagate to the other. Useful when some users are managed natively in the cloud IdP (e.g., external contractors who don’t need AD accounts).

Pros: Flexibility for mixed user populations. Cons: Conflict resolution is hard — what happens when the same user is modified in both systems simultaneously? Requires careful scoping to avoid sync loops.

Strategy 3: Cloud-Mastered with AD Writeback

Cloud IdP ──writeback──→ Active Directory
  (source)                   (replica)

Reverse the direction: the cloud IdP is the source of truth, and changes write back to AD for legacy applications. This is the target state for organizations committed to cloud-first, but it requires significant process changes.

Pros: Positions you for eventual AD decommission. Cons: Requires all provisioning workflows to target the cloud IdP first, which is a major change.

SSO Configuration Patterns

Kerberos SSO for Domain-Joined Devices

Domain-joined Windows machines get transparent SSO via Kerberos. To extend this to cloud apps during coexistence:

For Entra ID: Enable Seamless SSO in Entra Connect. This creates a computer account (AZUREADSSOACC) in AD that issues Kerberos tickets for Entra ID authentication. Users on corporate network get SSO to both on-prem and cloud apps without additional prompts.

For Okta: Deploy the Okta IWA Web App on your domain. It uses IWA (Integrated Windows Authentication) to validate Kerberos tickets and issues Okta sessions.

For Keycloak (cloud): Configure SPNEGO/Kerberos authentication in Keycloak, with Keycloak’s service principal registered in AD.

Certificate-Based Authentication

If you use smart cards or client certificates:

• On-prem IdP: Probably already handles certificate auth natively
• Cloud IdP: Configure CBA (Certificate-Based Authentication) in the cloud IdP
• Both systems need to trust the same CA chain
• CRL/OCSP validation must be accessible from both environments

Conditional Access Across Environments

The challenge: enforcing consistent security policies when authentication happens at different IdPs.

During coexistence, you’ll have gaps. The cloud IdP’s conditional access is typically more sophisticated (risk-based, device-aware) but only applies to apps that authenticate against it. On-prem apps get the on-prem IdP’s simpler policy engine.

Accept this gap during migration. Trying to enforce identical policies across both systems adds complexity without proportional security benefit.

Monitoring and Troubleshooting

What to Monitor

During hybrid coexistence, authentication failures are harder to diagnose because the problem could be in either system or in the federation between them.

Set up dashboards for:

• Authentication success/failure rates — per IdP, per application
• Federation latency — time for the on-prem IdP to respond to federation requests from the cloud IdP
• Sync lag — time between AD change and cloud IdP update
• Session anomalies — users with sessions in one IdP but not the other

Common Failure Scenarios

Scenario 1: User exists in AD but not in cloud IdP

• Cause: Sync agent down or user out of sync scope
• Fix: Check sync agent health, verify user is in the correct OU/group for sync

Scenario 2: User can access cloud apps but not on-prem apps

• Cause: Federation trust expired or misconfigured
• Fix: Check SAML certificate validity on both IdPs, verify federation metadata is current

Scenario 3: Password change in AD doesn’t take effect in cloud IdP

• Cause: Password hash sync delay (typically 2-5 minutes for Entra Connect)
• Fix: Wait for sync cycle, or trigger manual sync

Scenario 4: MFA prompt on every app switch

• Cause: SSO session not shared between IdPs
• Fix: Verify federation trust is configured for SSO (not just authentication), check session cookie domains

Decommission Readiness Checklist

Before removing the on-premises IdP:

• Zero active authentication sessions in on-prem IdP logs (30-day window)
• All applications migrated and tested against cloud IdP
• All federation trusts removed or redirected
• Directory sync direction reversed (if moving to cloud-mastered)
• Emergency admin access established in cloud IdP
• Rollback plan documented (re-enable on-prem IdP within 4 hours)
• Help desk trained on cloud IdP troubleshooting
• Monitoring alerts configured for cloud IdP availability
• Compliance team sign-off on new architecture

The coexistence period is temporary by design. Keep the end goal in view — a single, authoritative identity system — and resist the temptation to make the hybrid architecture permanent. Every month of dual-system operation is a month of double the operational overhead and double the attack surface.