5.3 AD FS Migration & Connect Health

Why leave AD FS for cloud authentication

Active Directory Federation Services (AD FS) was the classic way to provide SSO from on-premises AD to Microsoft 365 and other claims-aware apps. It still works—and SC-300 still expects you to understand it—but Microsoft’s modernization guidance for most organizations is Microsoft Entra ID cloud authentication with password hash synchronization and/or pass-through authentication, plus Conditional Access, not a perpetual AD FS farm for first-party Microsoft workloads.

Pain points AD FS introduces that exam stems exploit:

Migration value proposition: simpler auth path, better integration with Identity Protection, Conditional Access, passwordless methods, and reduced certificate-driven outages.

Managed versus federated domains

In Microsoft Entra ID, a custom domain’s authentication type is critical:

Migration’s technical climax is often converting a federated domain to managed after cloud auth prerequisites are healthy. Until conversion, federation may still handle password sign-ins even if PHS is already running in the background.

Migration roadmap (exam-ready sequence)

Use this ordered plan when a stem asks “how should the company migrate from AD FS?”

1. Discover and inventory

• List relying party trusts: Microsoft 365 / Entra, third-party SaaS, custom apps.
• Note claims rules that Entra Conditional Access or app provisioning cannot replace without redesign.
• Identify certificate auth, third-party MFA adapters, or legacy protocols still bound to AD FS.
• Confirm hybrid sync is healthy (Connect Sync or Cloud Sync) and UPNs are aligned.

2. Enable cloud authentication prerequisites

• Enable password hash synchronization (strongly preferred as primary or backup).
• Or deploy PTA agents (multiple) if policy requires live AD validation.
• Optionally enable seamless SSO for domain-joined UX.
• Validate test accounts can authenticate when forced through cloud auth paths in a pilot.

3. Staged rollout / selective password hash sync concepts

Microsoft provides staged rollout of cloud authentication so you do not flip an entire federated domain on day one.

Conceptual behavior:

• Domain may remain federated globally.
• Selected users or groups are directed to cloud authentication (PHS or PTA) for supported apps while others still use AD FS.
• You expand the pilot cohort as success metrics pass.
• After confidence is high, convert the domain to managed and retire AD FS for those workloads.

Selective password hash synchronization language on exams may refer to controlling who gets hashes synchronized or which populations participate early in cloud auth—always read the stem. In practice, combine:

• Sync scoping (OU/group) so only intended users exist/sync as expected.
• Staged rollout groups for authentication path piloting.
• Communication plans for password change timing and helpdesk scripts.

4. Convert domain and decommission carefully

• Convert federated domain to managed when pilots succeed.
• Keep AD FS online temporarily for any non-Entra relying parties still depending on it.
• Migrate remaining apps to Entra ID (SAML/OIDC enterprise apps) or other IdPs.
• Only then decommission AD FS farms and proxies; revoke unused certificates; update DNS/public endpoints.

Do not decommission AD FS the same afternoon you enable PHS without staged validation—classic exam fail.

Decision matrix: stay federated or migrate

Microsoft Entra Connect Health overview

Microsoft Entra Connect Health is the monitoring solution for hybrid identity infrastructure. Administrators use it to see whether sync and federation components are healthy before users report outages.

Primary workloads monitored (exam focus):

1. Microsoft Entra Connect Sync — sync errors, export failures, latency, dual-export risks, service status.
2. AD FS — farm health, authentication failures, proxy trust issues, performance, certificate-related problems.
3. Related agents/services depending on what is deployed in the environment (Connect Health agents installed on monitored servers).

High-level architecture:

• Install Connect Health agents on Connect Sync servers, AD FS servers, and Web Application Proxy servers as applicable.
• Agents upload health telemetry to Microsoft.
• Admins view dashboards, trends, and alerts in the Microsoft Entra admin center (Connect Health blades).
• Requires appropriate licensing (historically Entra ID P1 features for full Connect Health scenarios—exam may treat it as the correct monitoring product regardless of SKU deep dives).

What admins watch in Connect Health

During AD FS migration, Connect Health is doubly valuable: it proves the old farm’s failure modes and confirms the hybrid sync backbone remains green while staged rollout expands.

Health alerts and operational use cases

Alerts are the exam’s practical angle—why bother installing agents?

Common reasons admins rely on Connect Health alerts:

1. Silent sync failure — Connect server disk full or service stopped; cloud identities drift from AD for hours before anyone notices.
2. Certificate expiration approaching — AD FS token-signing or SSL issues historically cause sudden org-wide Microsoft 365 failures; health insights help catch farm problems earlier.
3. Sudden spike in AD FS auth failures — bad password spray, misconfigured relying party, or network path failure.
4. Export errors on high-value objects — executives or break-glass accounts failing to update.
5. Duplicate or topology warnings — risky Connect configurations (for example, unexpected server behaviors) that need immediate admin attention.

Response pattern for SC-300 troubleshooting stems:

1. Check Microsoft Entra sign-in logs for user-level auth errors.
2. Check Connect Health for infrastructure-level hybrid failures.
3. Check local Synchronization Service Manager / Cloud Sync provisioning logs for object errors.
4. Fix root cause (agent down, DC unreachable, cert expired, OU filter mistake); do not “reset MFA for everyone” as a first step.

Migration + health: end-to-end scenario

Contoso runs AD FS for contoso.com, suffers annual cert outages, and wants Conditional Access consistency.

Recommended storyline:

1. Ensure Entra Connect Sync (or Cloud Sync) is healthy; view status in Connect Health.
2. Enable PHS; confirm hashes appear/sync errors are zero for pilot OUs.
3. Create staged rollout group Cloud-Auth-Pilot; add identity team; validate Microsoft 365 sign-in uses cloud auth.
4. Expand pilot; monitor sign-in logs and Connect Health AD FS metrics (traffic should drop for pilot users).
5. Convert contoso.com from federated to managed.
6. Migrate leftover relying parties; decommission AD FS; keep Connect Health on sync servers ongoing.

If at step 3 pilot users fail, do not convert the domain. Roll back pilot membership, fix PTA agents or PHS issues, retest.

Common exam traps

• Converting the domain to managed before enabling PHS/PTA.
• Decommissioning AD FS while third-party apps still federate exclusively to it.
• Using Azure Monitor alone as the “best” AD FS hybrid identity health product when the stem points to Connect Health.
• Assuming staged rollout requires rewriting every user’s UPN.
• Treating Connect Health as a replacement for Conditional Access or PIM.
• Forgetting multiple PTA agents when migrating to PTA instead of PHS.

Quick recall table

Hybrid identity operations end where governance begins: a managed domain with healthy sync, modern authentication methods, and monitored infrastructure. For SC-300, migration is a planned staged process, and Connect Health is the operator’s windshield for Connect Sync and AD FS—not an optional nice-to-have.