What are the signs that an AD FS proxy configuration is not working correctly across a non-standard HTTPS path?

How to recognise an AD FS proxy problem on a non-standard HTTPS path

The strongest clue is that the break appears only when traffic traverses the proxy path, not when clients reach federation components by a simpler route. That usually points to path rewriting, host header handling, certificate binding, or an upstream gateway that is not preserving the AD FS expectations for discovery and authentication flow.

Watch for symptoms that line up with a path-aware routing failure rather than a generic sign-in outage. If federation metadata cannot be retrieved reliably, the endpoint may be reachable but not addressable in the way AD FS expects. If the client gets a certificate warning before any authentication prompt, the proxy or gateway is likely terminating TLS differently than intended.

AD FS troubleshooting is much easier when you separate transport from federation behaviour. A request that reaches the proxy can still fail later at claims processing, SOAP exchange, or relying party redirect if the non-standard path is not mapped consistently end to end. That is why these issues often look intermittent or browser-specific even though the root cause is structural.

What the failure pattern usually tells you about the proxy

When authentication succeeds up to the point where credentials are submitted, then fails immediately afterwards, the front door is probably working and the problem is deeper in the federation chain. In practice, that often means the proxy is forwarding to the wrong internal listener, the binding is mismatched, or the backend URL seen by AD FS does not match the externally published path.

SOAP requests that never complete are another useful indicator because they suggest the proxy is not just breaking sign-in pages, but also the protocol traffic AD FS uses to continue the transaction. If packet inspection after decryption does not reveal the expected clear-text sequence, the issue is often in the proxy, the upstream gateway, or the SSL offload arrangement rather than in user credentials themselves.

If you need a structured reference for hardening and operating AD FS safely, NHIMG’s AD FS Security Guide is the most direct companion for understanding the surrounding federation components and their operational dependencies.

How to narrow the fault domain without chasing the wrong layer

Start by confirming whether the problem reproduces on the direct path and only fails on the non-standard path. If it does, the issue is almost certainly in proxy mapping, certificate presentation, or upstream routing, not in the relying party application. That distinction matters because AD FS failures often cascade into misleading browser or login errors that hide the actual choke point.

Next, compare what the proxy presents externally with what AD FS expects internally. A path mismatch, incorrect redirect target, or missing header preservation can break metadata retrieval and post-login callbacks even when the service appears healthy. The same is true if a load balancer or gateway rewrites the URL in a way that the federation flow cannot reconcile.

When a wider federation change is already under way, it helps to compare the path issue with broader migration behaviour. NHIMG’s Identity Platform Migration guide is useful because it highlights coexistence, cutover, and decommissioning mistakes that often surface first as federation path failures.

Practitioner Guidance

What to verify: Validate the published external URL, the backend listener, and the certificate bound to the proxy or gateway as one chain, not as separate checks. If any one of those values differs between the client path and the internal AD FS path, assume the transaction will fail somewhere after the initial connection.

Decision rule: If the symptom appears only after credentials are entered, prioritise federation-path and binding checks before looking at identity store issues. If the symptom appears before any authentication prompt, prioritise TLS, routing, and metadata reachability first.

Practitioner takeaway: Treat non-standard AD FS paths as an end-to-end publishing problem, not a simple IIS or certificate problem, because the first visible error is often far downstream from the real misalignment.

Related resources from NHI Mgmt Group

• HTTPS
• Configuration
• How should teams handle AD FS federation when firewall policy blocks standard HTTPS between a DMZ proxy and the internal network?
• What are the signs that IP-based access restrictions are not working correctly behind a proxy?