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

[Hannes Fasching]

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 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.


Thanks in advance and Kind regards,
Hannes Fasching

PS: All public/relevant IP's and domain names where replaced with text that 
should give a meaning e.g. IP of the proxy -> proxyip, IP of the client -> 
clientip, etc.
Also the Basic authentication string was replaced by '*'s














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

Re: [squid-users] Unwanted authentication requests

[Alex Rousskov]

On 9/8/22 03:13, Marek Greško wrote:

Is there some way to limit the use of basic auth only to the users on 
the second vlan and not present it to the users on the first vlan and 
vice versa?


This is not my area of expertise, but the auth_schemes directive does 
support ACLs, so you can tell Squid what schemes to use for what 
incoming traffic: http://www.squid-cache.org/Doc/config/auth_schemes/




NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -


FWIW, older Squids did not access-log many requestless TCP connections. 
Their presence in Squid v5 logs does not necessarily indicate a change 
in traffic patterns.



HTH,

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] [Troubleshoot] Squid 3.3 - Lots of 403 erros when reducing the workers number

[Xavier Lecluse]

Hello everybody,
I am new to this list so feel free to react if my request is incorrect in any 
way (missing topic, tag, )

We are using two squid proxies (Squid 3.3) behind a load balancer, to handle 
our users requests (http/https).

The "hardware" of our VMs is :
2 vCPU @ 4.0GHz
4 Go Ram
iSCSI disks


In order to address some issues with Java clients, we tried to lower the worker 
directive from 8 to 1, because of the relative low number of simultaneous 
connections on our SSquid servers (about 100rq/s)
After reducing the worker value to 1, and restarting the proxies, we observed a 
great number of 403 errors, so we decided to rollback to 8 workers.


My questions are :
- How the number of workers and these 403 errors can be correlated ?
- Is there any "recommandations" about the number of workers to use, for a 
given number of request/s ?


The inital problem is from some java clients, which are using two TCP sessions, 
one for the authentication, and another one for the HTTP(s) requests.
The fact is that the "second" session is not always opened on the same worker, 
so ot considers that the authentication step has not already been done.

Is there a way to address this issue ?

Thank you.
Xavier
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] [Troubleshoot] Squid 3.3 - Lots of 403 erros when reducing the workers number

[Alex Rousskov]

On 9/8/22 10:15, Xavier Lecluse wrote:


We are using two squid proxies (Squid 3.3)


Squid v3 is not officially supported. My answers below may apply to 
Squid v3, but they are based on Squid v5+.




In order to address some issues with Java clients, we tried to lower
the worker directive from 8 to 1, because of the relative low number
of simultaneous connections on our SSquid servers (about 100rq/s) 
After reducing the worker value to 1, and restarting the proxies, we

observed a great number of 403 errors, so we decided to rollback to 8
workers.



- How the number of workers and these 403 errors can be correlated ?


I do not know the exact correlation vector in your environment, but 
fewer workers means, among other things, smaller _aggregate_ 
authentication cache size and higher load on individual authentication 
helpers. To pinpoint the correlation, we would need to know _why_ Squid 
is generating 403 (Forbidden) errors.




- Is there any "recommandations" about the number of workers to use,
for a given number of request/s ?


Workers are primarily a performance optimization. For related tuning 
suggestions, please see 
https://wiki.squid-cache.org/Features/SmpScale#How_to_configure_SMP_Squid_for_top_performance.3F




The inital problem is from some java clients, which are using two TCP
sessions, one for the authentication, and another one for the HTTP(s)
requests. The fact is that the "second" session is not always opened
on the same worker, so ot considers that the authentication step has
not already been done.



Is there a way to address this issue ?


If (a request on) the second connection has enough information to link 
it to the first/authenticated request/connection, then it may be 
possible to configure Squid and write authentication helpers in such a 
way that the "other" worker knows that the client of the second 
connection has already authenticated. The details would depend on the 
authentication scheme and that "linking" mechanism.



HTH,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Unwanted authentication requests

[Alex Rousskov]

On 9/8/22 15:22, Marek Greško wrote:


thanks for tip. I did not know about that directive. Is it possible
to specify no method for others?


Hi Marek,

If you do not want authentication for others, adjust your 
http_access rules (that trigger authentication). The auth_schemes 
directive controls how to authenticate, not whether to authenticate.



HTH,

Alex.



Regarding the logs, I am not sure whether they were logged before,
but before I did not get the basic login requests. Well, sometimes
yes, but definitely not several a day, but one for months. Maybe it
is some firefox update problem?




--- Original Message ---
On Thursday, September 8th, 2022 at 15:19, Alex Rousskov 
 wrote:



On 9/8/22 03:13, Marek Greško wrote:


Is there some way to limit the use of basic auth only to the users on
the second vlan and not present it to the users on the first vlan and
vice versa?



This is not my area of expertise, but the auth_schemes directive does
support ACLs, so you can tell Squid what schemes to use for what
incoming traffic: http://www.squid-cache.org/Doc/config/auth_schemes/


NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -



FWIW, older Squids did not access-log many requestless TCP connections.
Their presence in Squid v5 logs does not necessarily indicate a change
in traffic patterns.


HTH,

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Scaling concurrent TCP sessions beyond ephemeral port range

[Amos Jeffries]

On 9/09/22 11:41, Praveen Ponakanti wrote:

Hi Alex,


Thanks for all the help from the squid dev group with upstreaming the 
enhancement to scale up outbound TCP sessions on Linux with the 
IP_BIND_ADDRESS_NO_PORT sockopt flag. Our canary instances have been 
doing great the last few weeks with the code patch prior to merge.



A few followup questions (not urgent) :

  * Do we know which 5.x version will include the patch? I do not see it
listed in the change log for squid-5.7.


Squid-5 is in "stable" release cycle already which means the changes 
applied to it are quite restricted.


IMO this change is more of a performance optimization than a bug fix, so 
this is being left for Squid-6 which is supposed to start releasing in a 
few months (Feb 2023).





  * We have a large number of workers (30) to help with handling a
high RPS. However, TCP session reuse does not seem to be optimal
even with server_persistent_connections enabled as a new outbound
session would have to be opened up if the request is proxied by a
kid worker that doesn’t already have a connection to that
destination. Is there something that can be done to improve this
with later versions of squid? Would be glad to help out if anyone
has some suggestions.


It sounds to me like your situation is one that this system architecture 
was designed to service: 





Cheers
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Unwanted authentication requests

[Amos Jeffries]

On 9/09/22 07:22, Marek Greško wrote:

Hello Alex,

thanks for tip. I did not know about that directive. Is it possible to specify 
no method for others? I tried none, but squid complained. Not necessarily 
needed now, but I tried to specify no method for other vlans without success. I 
left basic for others now.

Regarding the logs, I am not sure whether they were logged before, but before I 
did not get the basic login requests. Well, sometimes yes, but definitely not 
several a day, but one for months. Maybe it is some firefox update problem?


I think some change in the Browser(s) is likely the cause, assuming you 
did not alter the auth configuration and/or how http_access policies 
used authentication ACLs.


FYI, unless you specify the auth_schemes policy Alex mentioned Squid 
will always inform the client of *all* auth types you configured for 
use. Which auth scheme(s) to try is entirely a Browser/client choice.


Regarding the popup box. That is an internal Browser choice to ask the 
user to supply credentials instead of locating them by other means (eg 
SSO, machine account, or a credentials store). It has nothing to do with 
Squid.



HTH
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Scaling concurrent TCP sessions beyond ephemeral port range

[Alex Rousskov]

On 9/8/22 19:41, Praveen Ponakanti wrote:

  * We have a large number of workers (30) to help with handling a
high RPS. However, TCP session reuse does not seem to be optimal
even with server_persistent_connections enabled as a new outbound
session would have to be opened up if the request is proxied by a
kid worker that doesn’t already have a connection to that
destination. Is there something that can be done to improve this
with later versions of squid? Would be glad to help out if anyone
has some suggestions.


If your only concern is TCP, and the number of servers is large, then it 
would be possible to share open Squid-server connections among workers 
by adding code that would exchange open TCP socket descriptors using UDS 
messages, but I doubt it is worth doing (a lot of complexity but not 
enough gain). There may also be some advanced/modern kernel tricks that 
we can teach Squid to use for sharing connections, but, again, I doubt 
the complexity would be worth the benefits from such reuse.


If most TCP servers are known a priori, and there are few of them, then 
cache_peer standby=N feature for them might be useful.


If you are dealing with TLS sessions as well, then we should add a 
shared memory TLS session cache that all workers can tap into.



Cheers,

Alex.


On Tue, Jun 21, 2022 at 2:11 PM Alex Rousskov wrote:

On 6/19/22 12:48, Praveen Ponakanti wrote:

 > What is the process to have this code patch upstreamed for future
squid
 > versions?

In short, just post a quality pull request on GitHub (or find somebody
who can guide your code towards official acceptance for you). For
details, please see https://wiki.squid-cache.org/MergeProcedure



Thank you,

Alex.


 > On Fri, May 20, 2022 at 9:31 PM Amos Jeffries
mailto:squ...@treenet.co.nz>
 > wrote:
 >
 >     On 20/05/22 19:44, Praveen Ponakanti wrote:
 >      > Hi Alex,
 >      >
 >      > Thanks for going through several steps to help mitigate
src port
 >      > exhaustion. We are looking to achieve 400-500% more
 >      > concurrent connections if we could :) as there is a
 >     significant buffer
 >      > on the available CPU.
 >
 >     Then you require at least 4, maybe 5, IP addresses to handle
that many
 >     concurrent connections with Squid.
 >
 >
 > We would like to investigate going beyond the ephemeral port
range for
 > some specific destination IP:PORT addresses. For that it appears
squid
 > does not round-robin requests if we use multiple
tcp_outgoing_addresses.
 > We could use ACL’s to pick a different outbound IP based on the
clients
 > source IP, however that is not very ideal in our environment as our
 > clients aren’t always equally split by subnet. However, if we could
 > split by the client’s source port that might help achieve this. For
 > example something like:
 >
 >
 > acl pool1 clientport 0-32768
 >
 > acl pool2 clientport 32769-65536
 >
 >
 > tcp_outgoing_address 10.1.0.1 pool1
 >
 > tcp_outgoing_address 10.1.0.2 pool2
 >
 >
 > Squid's ACLs currently do not allow filtering by the client's source
 > port. We could look into a separate patch to add this
functionality to
 > squid’s ACL code if that makes sense. Or is there a better way to
 > achieve this?
 >
 >
 > Thanks
 >
 > Praveen
 >
 >
 >      > The option to use multiple tcp_outoing_addresses appears to be
 >     promising
 >      > along with some tweaks to the TCP timeouts. I guess we
could use
 >     ACLs to
 >      > pick a different outbound IP based on the requesting client's
 >     prefix. We
 >      > had not considered that option as the ephemeral ports were
no longer
 >      > available to other applications when squid uses most of
them with a
 >      > single outbound IP configured. We are also looking to
modify the
 >     code to
 >      > use the IP_BIND_ADDRESS_NO_PORT sockopt as that could help
delay
 >     port
 >      > assignment with the bind() call on the outbound TCP
sessions (to
 >      > hopefully allow access to the 4-tuple on the socket).
 >
 >     Patches welcome.
 >
 >     However, please be aware that use of the 4-tuple is often no
different
 >     from the 3-tuple since the dst-port is typically identical
for all
 >     outgoing traffic to a given dst-IP.
 >
 >
 >     Cheers
 >     Amos
 >     ___
 >     squid-users mailing list
 > squid-users@lists.squid-cache.org

 >     >
 > htt

Re: [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
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.