Getting authentication popups when authenticating on a child and a parent (upstream/downstream) proxy

Products

• ProxySG Software - SGOS

Issue/Introduction

You have proxy chaining configured so requests go from the client to the downstream/child proxy, get authenticated there and are subsequently forwarded to the upstream/parent proxy to be authenticated again. With this deployment you notice that clients either fail authentication or are getting authentication pop-ups.

Resolution

A few words about NTLM authentication first:

- NTLM authentication consists of 3 rounds of authentication, called Negotiate, Challenge, and Authentication. This is the design of NTLM.

- NTLM does not transmit passwords over the network. Instead, it uses a hash of the username and password and if the DC confirms this hash, then authentication succeeds. This is important to remember as we'll see later.

 

Now let's look at what happens in this scenario:

- A client sends a request to the proxy

- Proxy responds with 407 Authentication required

- Client sends the Type1 message (NTLMSSP_NEGOTIATE)

- Proxy responds with 407 and the Type2 challenge (NTLMSSP_CHALLENGE)

- Client sends the Type3 message (NTLMSSP_AUTH)

So far there are no problems and the user is now authenticated on the downstream/child proxy.

 

Now the request gets forwarded to the upstream/parent proxy.

Here you expect the same to take place. But here's what actually happens:

- Child proxy sends a request to parent proxy

- Parent proxy responds with a 407 Authentication required

- The child proxy does not know the password of the user (for this reason see the beginning of this paragraph) and so the child returns the authentication request from upstream back to the client.

- The client now gets confused because it thinks that it has already successfully authenticated (which it did, on the child proxy). Since it now receives another authentication request, it will assume that its initial authentication failed and will prompt the user for details. This is where the popup originates. It's not a proxy limitation, it's the client that assumes that, since after sending the Type3 message it gets another 407, authentication has failed and will then produce a popup asking the user for credentials.

 

Generally, it does not make sense to authenticate the user twice. There are however many scenarios where, for example for log analysis purposes, the upstream proxy must know who the user is that comes in via the child proxy. In order to facilitate this, you can configure the child proxy to add an "X-Forwarded-For" header to the requests it sends upstream. The upstream proxy can then parse this header. We can do this because the child proxy does know the username (but not the password). Setting this X-Forwarded-For header can be achieved in two ways:

1. CLI

2. VPM