The purpose of this article is to provide a brief description of the things that take place in order for a client request to be authenticated in a common IWA scenario using a transparent deployment, as well as describe what can be happening when one of the steps is not happening as intended.
The steps for authentication in transparent deployments are as follows:
Client sends a request, E.g: GET example.com to the Proxy.
Proxy replies with a 302 Redirect to the Virtual URL configured in the authentication realm. If the proxy does not reply with this, it is possible that the authentication rule did not match.
Authentication happens here (NTLM/Kerberos) with the Active Directory. If the proxy doesn't send a proper response, it may mean that the client is unable to resolve Virtual URL to the proxy's IP or that the Proxy service for authentication is not set up correctly, or that the client's don't trust in the certificate provided by the proxy. Refer to article TECH245512 for more on these configurations.
Once the user is authenticated, the proxy sends another 302 Redirect back to example.com, injecting a Cookie for the client to use afterwards.
Client sends a request to the original site, this time with the Cookie attached to it (if using an authentication mode that uses the Cookie such as Origin-Cookie-Redirect). If the client does not send the request with a cookie, it's likely that the browser had problems saving the cookie that was injected by the proxy. This is usually solved by changing the mode to Origin-IP-Redirect.
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.