I've been helping a few teams implement Entra ID's Application Proxy for legacy on-prem applications, and we keep hitting the same snag. The proxy seems *exceptionally* sensitive to backend timeouts, even minor ones. If the on-prem app server takes a few seconds longer to respond than usual, users get kicked to the sign-in page or see a generic "can't access this application" error.
Our setup is standard: a connector group on a dedicated server, the app configured for pass-through pre-authentication. The app itself is stable, but under variable load. It seems the proxy's tolerance for backend latency or a slow TCP handshake is very low.
Has anyone else run into this and found a reliable mitigation? I'm curious about:
* Are there specific timeout settings on the proxy side we might be missing?
* Does the connector version or resource allocation (CPU/memory) play a bigger role than documented?
* Is this simply a design constraint where the backend *must* respond within a near-instantaneous window?
We're considering throwing more resources at the on-prem server, but I'd rather fix a misconfiguration than over-provision. Any insights or shared experiences would be really helpful.
— Jane
— Jane
You've described the exact behavior I've seen with a few of our on-prem ERP deployments. The "a few seconds longer" part is what caught my attention. The Application Proxy backend timeout is actually configurable up to 85 seconds by default, so a few seconds shouldn't trigger a full timeout. That suggests the issue isn't the total response-time limit, but something else.
What I've pinned down in a few cases:
* The connector's TCP keep-alive timing. Under variable load, the connector may close an idle connection to the backend, and if the app is slow to respond on the next request, the connector's retry logic can fail silently. Check the connector event logs for "EndPointNotReachable" or "ConnectionClosed" events that correlate with the user kicks.
* Resource allocation on the connector server. I've seen connectors spike CPU during authentication handshakes, especially in pass-through mode where they're forwarding Kerberos tickets. If the connector itself is throttled, it can drop connections before the backend even responds. The official docs say 4 GB RAM is enough, but I've had to double that for apps with heavy concurrent load.
* The pre-authentication setting itself. Pass-through still requires the connector to validate the token with Azure AD on each request. If the backend is responding but the token validation times out, the user sees the same generic error. This is usually a network latency issue between the connector and Azure AD, not the backend.
Before throwing more hardware at the on-prem server, I'd instrument the connector's performance counters and tail the logs during a spike. If the connector's queue depth or latency to Azure AD is the bottleneck, you may need to add a second connector in the group rather than scale up the backend.
One question: are you using Kerberos constrained delegation for the backend, or just pass-through with no SSO?
Measure twice, buy once.