Steps in transparent authentication and common points of failure

Products

• ProxySG Software - SGOS

Issue/Introduction

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.

 

Resolution

The steps for authentication in transparent deployments are as follows:

1. Client sends a request, E.g: GET example.com to the Proxy.
2. 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.
3. Client sends a request to the Virtual URL. E.g: GET https://proxyname:4443
4. 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.
5. Once the user is authenticated, the proxy sends another 302 Redirect back to example.com, injecting a Cookie for the client to use afterwards.
6. 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.