Hey Alex,
Here's a quick glimpse at what the cache.log is saying.
2024/10/25 11:49:18 kid1| ERROR: Negotiate Authentication validating user.
Result: {result=BH, notes={message: gss_acquire_cred() failed: No credentials
were supplied, or the credentials were unavailable or inaccessible. No
principal in keytab matches desired name; }}
current master transaction: master293
2024/10/25 11:49:18 kid1| Starting new negotiateauthenticator helpers...
current master transaction: master1444
2024/10/25 11:49:18 kid1| helperOpenServers: Starting 1/10
'negotiate_kerberos_auth' processes
current master transaction: master1444
2024/10/25 11:49:18 kid1| Starting new negotiateauthenticator helpers...
current master transaction: master1445
2024/10/25 11:49:18 kid1| helperOpenServers: Starting 1/10
'negotiate_kerberos_auth' processes
current master transaction: master1445
2024/10/25 11:49:18 kid1| ERROR: Negotiate Authentication validating user.
Result: {result=BH, notes={message: gss_acquire_cred() failed: No credentials
were supplied, or the credentials were unavailable or inaccessible. No
principal in keytab matches desired name; }}
current master transaction: master1082
-----Original Message-----
From: Alex Rousskov <rouss...@measurement-factory.com>
Sent: Thursday, October 24, 2024 4:46 PM
To: Piana, Josh <josh.pi...@hexcel.com>; squid-users@lists.squid-cache.org
Subject: Re: [squid-users] proxy_auth_regex
Caution: This email originated from outside of Hexcel. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
On 2024-10-24 16:23, Piana, Josh wrote:
> From what I can tell, squid does not receive a good username. When I check
> the access logs, I receive something like this:
> 24/Oct/2024:16:01:08 -0400.334 10.46.49.190 TCP_DENIED/407 7821
> CONNECT
> http://www.g/
> oogle.com%3A443%2F&data=05%7C02%7CJosh.Piana%40hexcel.com%7C29bbc9983f
> 2742ff81e108dcf46cd820%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63
> 8653995560620056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=W%2BZDXkp
> r6hr5wvICtWMUGsugzHqz7%2BHS7UEKX7N5CPI%3D&reserved=0 - \ HIER_NONE/-
> text/html ERR_CACHE_ACCESS_DENIED/-
Please check CONNECT request headers in packet captures or cache.log with
debug_options set to ALL,2. If client does not send any user credentials to
Squid, then Squid should request them (with a 407 CONNECT response containing
appropriate headers).
> In regards to the TLS connectors vs HTTP CONNECT requests ...
> I'm not sure if that is the case
Does the problematic test transaction arrive at http_port or https_port?
> is "proxy_auth_regex" not compatible with certain things?
Nearly every Squid configuration option is not compatible with certain things.
> How would you recommend I test plain http traffic?
I would start with
curl --verbose ... http://example.com/
or a similar request (add proxy/other options instead of "..." as needed).
Alex.
> However, I think some of my log information may be missing. I believe you
> mentioned it before, so I'll show you what I'm using for our custom log
> directive. Maybe we can fix this too? What I originally tried to do with this
> was just get "human readable" time stamps:
> logformat custom %tl.%03tu %>a %Ss/%03>Hs %<st %rm %ru %[un \ %Sh/%<a
> %mt %err_code/%err_detail
>
> In regards to the TLS connectors vs HTTP CONNECT requests, that is a great
> point. I'm not sure if that is the case, but is "proxy_auth_regex" not
> compatible with certain things? How would you recommend I test plain http
> traffic?
>
>
> -----Original Message-----
> From: Alex Rousskov <rouss...@measurement-factory.com>
> Sent: Thursday, October 24, 2024 4:13 PM
> To: Piana, Josh <josh.pi...@hexcel.com>;
> squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] proxy_auth_regex
>
> Caution: This email originated from outside of Hexcel. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
>
>
> On 2024-10-24 15:53, Piana, Josh wrote:
>> Hey Squid users,
>>
>> Running into an issue I’m trying to figure out.
>>
>> We have a few acl directives using “proxy_auth_regex –i” and when I
>> have these active, it blocks any proxy connection with an HTTP 407
>> error, according to the logs.
>>
>> Here’s an example:
>>
>> # block certain user IDs from using proxy server
>>
>> #acl block_user proxy_auth_regex -i "/etc/squid/block_user"
>>
>> #http_access deny block_user
>>
>> What’s supposed to happen with this ACL, is that any username we have
>> on that list is to be blocked from internet access. But it seems to
>> be blocking known good usernames too. I’m not sure where to go from
>> here
>
> After asking for one with a 407 response, does Squid ever receive a "good
> username" from the client? Do you see a username in client HTTP request
> headers or access.log records containing %un field?
>
> Perhaps the client refuses to authenticate its requests because Squid
> intercepts TLS client connections rather than receiving HTTP CONNECT requests
> from the client? Have you tested this with plain text traffic?
>
> Alex.
>
>
>> we would like to use these ACL’s but for right now I have these rules
>> commented out.
>>
>> Here's a few other rules we have that have the same issue:
>>
>> # executable blocking
>>
>> # reference this list for extensions to block
>>
>> acl exec_files url_regex -i "/etc/squid/exec_files"
>>
>> # ignore these usernames from being blocked
>>
>> #acl exec_users proxy_auth_regex -i "/etc/squid/exec_users"
>>
>> # combine the rules
>>
>> #http_access deny !bad_exception_urls !exec_users exec_files
>>
>> #deny_info ERR_BLOCK_TYPE exec_files
>>
>> From what you can see above, we have “acl exec_files url_regex -i
>> /etc/squid/exec_files" uncommented, but it’s not active because the
>> “http_access directive” had to be commented out because it includes
>> the other statements that include “proxy_auth_regex –i” which block
>> all internet access as well.
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> https://lis/
>> t%2F&data=05%7C02%7CJosh.Piana%40hexcel.com%7C29bbc9983f2742ff81e108d
>> cf46cd820%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63865399556062
>> 0056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=PCQLdRbIhLqZa1TDHvK
>> 3tJ4%2Ft7KciRwqiLysnAUxzcE%3D&reserved=0
>> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7CJosh.Piana%
>> 4
>> 0hexcel.com%7C7fb1087ae57b47c397a408dcf4684eaf%7C4248050df19546d5ac9c
>> 0
>> c7c52b04cae%7C0%7C0%7C638653976041876515%7CUnknown%7CTWFpbGZsb3d8eyJW
>> I
>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
>> 7
>> C%7C&sdata=D6d%2BXvUp%2FHTvsqC5oneWw%2FdYNWYkmsQUz0lKHLzRk0o%3D&reser
>> v
>> ed=0
>
> _______________________________________________
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://list/
> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7CJosh.Piana%4
> 0hexcel.com%7C29bbc9983f2742ff81e108dcf46cd820%7C4248050df19546d5ac9c0
> c7c52b04cae%7C0%7C0%7C638653995560776281%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%
> 7C%7C%7C&sdata=oAOv7ObjGY%2FIMJOAC0LdMf0eJ1wzpn6P0Q5tCNOvSTY%3D&reserv
> ed=0
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
