[squid-users] Exchange server authentication via squid reverse proxy not working after upgrade from squid 4.15 to 5.6

[Amos Jeffries]

On 8/09/22 19:40, Hannes Fasching wrote:
> Hello,
> A customer have an issue that after upgrading from squid 4.15 to actual 5.6 with reverse proxy mode for an exchange server.
> The authentication is not working anymore when the integrated Windows authentication is enabled (needed for SSO). When disabled, the authentication via squid is then working.


The squid.conf you link to below does not perform any authentication. 
Squid is configured just to relay any auth headers as-is to the Exchange 
server / peer.

To clarify some details here:

* "SSO" means simply that all services on a network are supposed to 
accept the same credentials.
  - Microsoft making a big noise about this terminology is purely 
marketing hype. SSO can be performed with any auth scheme and any 
credentials - it is entirely a matter of what the service doing the 
authentication accepts as valid credentials. So this can be ignored for 
troubleshooting purposes.


* "integrated Windows authentication" means simply that the Browser is 
supposed to have access to the users Windows account to send their 
machine login credentials when auth is needed.
  - So the thing to be looking at is whether the Browser (or other 
client software) is able to access and send the user login when 
authenticating.
  - If it is sending some other credentials that is a problem. Look at 
where they are coming from and why.


* authentication _scheme_ is simply a way to deliver the credentials 
from some client to some server.
  - these are dictated by the server doing the authentication. As long 
as the client software is using a scheme the service indicated as 
available things should work correctly.
  - this is where Squid comes in.
   ** If Squid is participating in the authentication the scheme is 
limited to one where three agents can share it (eg Basic).
   ** If Squid is blindly relaying then only the client and server need 
to agree on the scheme. But Squid needs to avoid breaking the scheme 
requirements (eg NTLM/Negotiate restrict TCP connection multiplexing, 
Digest restricts server load balancing).


> The difference is that Windows with integrated authentication is trying several authentication schemes otherwise only Basic authentication is used.
> Please follow the link to see the squid.conf and the cache log file starting with the attempt when it fails and afterwards, with the time stamp 19:15, the attempt when it is working.
> 
> https://barracudacorp-my.sharepoint.com/:u:/g/personal/hfasching_barracuda_com/EZBjHnJqCaFLlArPb8a_-FwB-7FIzvK0e21ow1Qec-MVhw?e=5149sA (squid.conf)
> https://barracudacorp-my.sharepoint.com/:u:/g/personal/hfasching_barracuda_com/EcPpd3DeeoFLs4_9Dn6JWAYBbHrwenOEJ3SZ0IW8_ED1-A?e=Ff9BZc (squid_cache.log)
> 
> It would be great if you could help me finding out what is wrong with Windows integrated authentication as our customer needs the SSO feature.


What I would be looking at here is the HTTP(S) message flows and headers 
to see what type of credentials the user/client is trying to send 
through Squid to Exchange. What auth scheme they are being sent with. 
And what TCP connections ("FD") they are being sent on when leaving Squid.


What I see in the log you posted is two client connections doing the 
following:

Client connection #1:
  * sends POST with Basic auth
  * server accepts
  * sends OPTIONS with Basic auth
  * server accepts

That looks good. Check that the credentials sent were the users Windows 
login and were sent automatically. If so then "SSO" is working.


Client connection #2:
  * sends POST with Bearer auth
  * server rejects (401)
  * sends POST with no credentials
  * server rejects (401)
  * sends POST with no credentials
  * server rejects (401)

   - I think this client software is broken. It should absolutely *not* 
be sending any requests without authentication after having received 
that first 401 status. It should be trying alternative schemes, or 
alternative credentials with each scheme, or going away.


Client connection #2 (after a short delay):

  * sends POST with Negotiate/NTLMv2 client capabilities token
  * server responds per NTLMv2 (401 status)
    - I assume it also produces the nonce token though I don't see the 
header logged
  * sends POST with Negotiate/NTLMv2 proof of identity token
  * server rejects (401)

That looks like Squid is correctly relaying the NTLMv2 handshake 
messages. But the Exchange server does not like the login for some reason.
  I would at this point be checking whether the credentials used here 
were actually the users Windows login, and whether Exchange server is 
validating properly.
  I am not familiar with Exchange but this may be something to do with 
NTLMv2 credentials using Negotiate scheme instead of NTLM scheme. 
Negotiate scheme typically means Kerberos handshake expected since NTLM 
was formally deprecated by Microsoft in April 2006.


HTH
Amos