Why One Proxy Request Prompts While Kerberos Works for Others
Find the policy rule that assigns an unexpected proxy authentication realm to one request, even when other requests use Kerberos successfully.
Several requests use Kerberos successfully through the company proxy. One request produces a password prompt. Before replacing a keytab, check which authentication policy that particular request selected.
A gateway can choose a realm and supported schemes through policy. Two transactions reaching the same proxy from the same browser need not receive the same authentication requirements.
Consider this hypothetical trace:
| Transaction | First matching policy | Available authentication |
|---|---|---|
| Main document | Managed browsing rule | Negotiate |
| Script from another host | Earlier destination exception | Basic or NTLM |
The first successful exchange demonstrates that one selected path works. It does not show that the second transaction reached that path. A credential may be valid while the rule selecting its authentication mechanism is wrong.
Inspect the selected rule and its ordering
Correlate the challenged request's destination and time with the gateway's policy trace. Identify the realm, scheme choices, and authentication mode produced by the first applicable rule. Compare those values with a successful request from the same client.
A policy based on an IP-associated identity can also behave differently from one requiring authentication on a connection. Do not assume the absence of a fresh handshake means the same realm was chosen.
If the resource fell into an unintended exception, correct that rule or its scope and review the resulting trace. Broadening allowed authentication methods everywhere can conceal the mismatch while changing access behavior for unrelated traffic.
If the intended realm is selected and the expected exchange fails, continue into the account and Kerberos evidence. That is the point where ticket, service-name, or backend diagnostics become relevant.