Hi Amos, thanks for your answer. It's a new point to look at and brings me one step further. Kind regards, Hannes Von: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> im Auftrag von Amos Jeffries <squid3@xxxxxxxxxxxxx> Gesendet: Freitag, 9. September 2022 06:45 An: squid-users@xxxxxxxxxxxxxxxxxxxxx <squid-users@xxxxxxxxxxxxxxxxxxxxx> Betreff: [EXTERNAL] Re: Exchange server authentication via squid reverse proxy not working after upgrade from squid 4.15 to 5.6 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 Get the 13 Email Threat Types eBook https://www.barracuda.com/ This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ________________________________ _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
