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 <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, October 24, 2024 4:46 PM
To: Piana, Josh <Josh.Piana@xxxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: 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 <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, October 24, 2024 4:13 PM
> To: Piana, Josh <Josh.Piana@xxxxxxxxxx>;
> squid-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
