I am using Windows Authentication in my ASP.NET Web Api app running on IIS server. On client I am using UseDefaultCredentials = true with HttpClient and it's working fine. But when I am using transparent proxy, it's only passing the request to my Web Api, the authentication is not working.
Example: Client -> send request to / -> Auth is working fine Client -> send request to / -> pass to / -> Auth is not working
Why is that? Do I need to register HTTP/proxy.domain SPN on machine where IIS server is running? Or how to fix it please?
Web Api is running on .NET8 and clients are built in .NET Framework 4.8
I am using Windows Authentication in my ASP.NET Web Api app running on IIS server. On client I am using UseDefaultCredentials = true with HttpClient and it's working fine. But when I am using transparent proxy, it's only passing the request to my Web Api, the authentication is not working.
Example: Client -> send request to https://myapp.domain.com/ -> Auth is working fine Client -> send request to https://proxy.domain.com/ -> pass to https://myapp.domain.com/ -> Auth is not working
Why is that? Do I need to register HTTP/proxy.domain.com SPN on machine where IIS server is running? Or how to fix it please?
Web Api is running on .NET8 and clients are built in .NET Framework 4.8
Share Improve this question asked Feb 5 at 11:06 exeqexeq 531 gold badge5 silver badges16 bronze badges1 Answer
Reset to default 1Yes, you need to assign the "HTTP/proxy..." SPN to the webapp's account.
Client -> send request to https://proxy.domain.com/ -> pass to https://myapp.domain.com/ -> Auth is not working
That's not really "transparent proxy". Not in the general usage of that term (which is more often used to describe inline/intercepting proxies), but specifically also because the client is not given a URL with myapp.domain.com anymore – the client is given a URL with proxy.domain.com, a completely different entity than the webapp, making it quite the opposite of transparent. I'd just call it a regular 'reverse proxy'.
Kerberos authentication is strongly tied to the domain name of the service – kind of like TLS certificates are (e.g. if the client was told to connect to "proxy.domain.com" but received a TLS certificate for "myapp.domain.com", you know that wouldn't work well) – but even more so.
That is, if the client is told to connect to "http[s]://proxy.mydomain.com", then the client will try to obtain a Kerberos ticket for the SPN "HTTP/proxy.mydomain.com" according to the URL. And even more importantly, that ticket will only be usable (decryptable) by the service account which holds that SPN, so you cannot assign it to the proxy system (as then the ticket wouldn't be decryptable by the backend).
Instead the "HTTP" SPN for the frontend/proxy domain name must be assigned to the service account of the backend webapp server. (It does not matter which machine you run setspn on – all it does is edit an LDAP entry, so what matters is only which account the SPN will be assigned to.)