Search squid archive

Re: Exchange server authentication via squid reverse proxy not working after upgrade from squid 4.15 to 5.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux