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
