Integrated Proxy Authentication: Service Accounts and Impersonation
Inspect the security context behind integrated proxy authentication when the same application works interactively and fails as a web service or scheduled process.
“Use my Windows credentials” needs a subject. In a desktop program, that may be the person running it. In a service, it can be the service's account. In a web application, a visitor's successful sign-in does not automatically replace the outbound request's security context.
This explains why a browser and server-side code on the same machine can receive different results from an integrated-authentication proxy. They may be presenting different identities.
Name the identities before changing the code
- The person signed into the desktop browser.
- The account hosting the application process.
- Any impersonated identity active for the outbound operation.
- The account the proxy actually accepted or rejected.
On .NET's supported integrated-authentication paths, DefaultCredentials concerns the current security context. It is not a global alias for whoever opened a page on another machine.
If the product deliberately acts as a user, impersonation and any network delegation requirements need their own supported design. Turning on a generic use-default-credentials switch does not establish that design. Conversely, a background job intended to run as a service identity should not depend on somebody opening a browser first.
Compare the interactive and deployed launches with secrets removed: account context, proxy endpoint, advertised method and rejected identity. Avoid copying a desktop password into the application merely because it made a one-off request succeed. Configure the account the application is meant to use, then keep that ownership visible in the deployment record.