Introduction

An identity migration can bring the new AD FS proxy tier online while browser sign-ins still traverse the old Web Application Proxy. Authentication appears to reach the federation service, but external users still hit the retired proxy, one relying party works while another follows the old path, or login fails only after the previous WAP servers are turned off because federation service names, proxy trust, and published endpoints often drift separately.

Treat this as an authentication-routing problem instead of a generic sign-in failure. Start by checking which Web Application Proxy host or VIP an affected external login actually reaches during the live AD FS flow, because migrations often validate the new federation farm internally while public sign-in traffic still follows older proxy or DNS paths.

Symptoms

  • AD FS logins still redirect through the old Web Application Proxy after migration
  • External sign-ins fail only after the old WAP server or VIP is disabled
  • One application or relying party uses the new proxy path while another still uses the previous one
  • Browser redirects, certificates, or headers still show the retired proxy tier
  • Internal AD FS access works, but external federation still depends on the old edge path
  • The issue started after moving AD FS proxies, federation services, or external access infrastructure

Common Causes

  • DNS, load balancer VIPs, or firewall publishing rules still direct the federation service name to the old WAP
  • WAP trust was rebuilt on the new servers, but applications still publish through the previous proxy path
  • One relying party or external URL was updated while another still references the old endpoint
  • Certificate bindings or SSL offload settings still match the retired proxy tier
  • Automation, reverse proxy rules, or health monitors keep preferring the old WAP nodes
  • Validation confirmed the new WAP could authenticate traffic but did not verify where real external sign-ins actually landed

Step-by-Step Fix

  1. Capture one affected external sign-in and record the federation service URL, proxy host, certificate, and redirect chain it actually uses, because the runtime path determines which edge tier handles authentication.
  2. Compare that active AD FS path with the intended post-migration design, because one stale VIP or DNS record can keep all internet-facing federation tied to the retired proxy.
  3. Review federation service DNS, WAP trust, load balancer pools, published endpoints, and relying party identifiers for references to the old proxy environment, because AD FS routing depends on identity and edge publishing layers together.
  4. Check different relying parties, external URLs, and regions separately if behavior differs, because migrations often fix one application path while another still lands on the previous WAP tier.
  5. Update the authoritative DNS, proxy publishing, and AD FS integration so affected sign-ins reach the intended WAP environment, because deploying new proxy servers alone does not retarget external authentication flows.
  6. Run a controlled external login and confirm the intended proxy handles the request, headers, and certificate presentation, because a successful token issuance does not prove the right edge path served the session.
  7. Verify the old WAP environment no longer receives external federation traffic from migrated applications, because split identity paths can remain hidden while both proxy tiers stay reachable.
  8. Review certificate chains, proxy trust, and health monitor behavior if redirects still fail, because the destination can be correct while SSL or proxy registration still breaks sign-in.
  9. Document which team owns federation DNS, WAP publishing, and external sign-in validation so future AD FS cutovers verify the actual proxy path before retiring the previous edge tier.