[squid-users] Using AD groups from negotiate_kerberos_auth in ssl-bumped connections.

[Andrey K]

Hello Alex,

> I would suggest using "clt_conn_tag" annotation for that purpose. That
> annotation was specifically added to address similar use cases.
>
> If really needed, your helper can send both "group" and "clt_conn_tag"
> annotations. The latter should be copied to subsequent requests received
> on the same client-Squid connection.

I conducted several tests and found that when the authentication helper
returns multiple groups in the 'clt_conn_tag' attributes, all of them are
available only during the initial CONNECT transaction. In subsequent
transactions, only the first group remains available.

Details:
I'm tracking 'clt_conn_tag' via logs:
   logformat my-squid %rm group=%note{group}
clt_conn_tag=%note{clt_conn_tag}
Example of the BasicAuth-helper:
  #!/bin/bash
  while read -r user pass; do
    echo "OK user=user1 group=group1 group=group2 clt_conn_tag=group1
clt_conn_tag=group2"
  done

Single curl request logs:
  CONNECT group=group1,group2 clt_conn_tag=group1,group2
  GET group=- clt_conn_tag=group1

Is this the expected behaviour?

Kind regards,
    Ankor.


чт, 5 мар. 2026 г. в 19:12, Jonathan Lee <jonathanlee571 at gmail.com>:

> Hi,
>
> I wanted to provide an overview of how the client ACL annotation and SSL
> bump logic is structured in the configuration.
>
> First, an IPv6 subnet ACL is defined to identify internal client traffic:
>
> acl splice_ipv6 src 2001:db8:abcd:1::/64
>
> This allows the proxy to recognize devices originating from the internal
> IPv6 network.
>
> Individual client devices are then defined using a combination of IP-based
> and MAC-based ACLs. Each device entry includes:
>
>    -
>
>    An IPv4 address
>    -
>
>    An IPv6 address (when applicable)
>    -
>
>    A MAC address
>
> Example:
>
> # Example Mobile Device
> acl splice_only_ip src 192.168.10.8
> acl splice_only_ip src 2001:db8:abcd:1:192:168:10:8
> acl splice_only_mac arp aa:bb:cc:dd:ee:01
>
> Using both IP and MAC matching helps ensure that rules apply only to the
> intended device.
>
> Devices are grouped based on how their encrypted traffic should be handled.
>
> Splice-only devices are allowed to pass encrypted traffic through the
> proxy without TLS interception:
>
> acl splice_only_local_group all-of splice_only_mac splice_only_ip
>
> Bump-only devices are allowed to have their TLS traffic intercepted for
> inspection:
>
> acl bump_main all-of bump_only_mac bump_only_ip
>
> Additional grouped ACL logic is used to determine when traffic should be
> spliced instead of inspected:
>
> acl splice_group any-of https_login NoBumpDNS NoSSLIntercept
> acl splice_main any-of splice_group splice_only_local_group splice_ipv6
>
> Traffic will be spliced if it matches login-related sites, domains listed
> in the no-bump configuration lists, DNS exclusions, devices specifically
> designated as splice-only, or the internal IPv6 subnet.
>
> Client annotation is used to mark active clients so that SSL bump rules
> apply only to recognized connections:
>
> acl active_use annotate_client active=true
>
> This annotation is referenced later in the SSL bump rules to ensure that
> only annotated clients proceed through the inspection logic.
>
> The SSL bump process is implemented in stages.
>
> First, the proxy performs an initial peek at the TLS handshake:
>
> ssl_bump peek step1
>
> Administrative infrastructure addresses are always excluded from
> interception to avoid certificate mismatch issues:
>
> acl no_bump_gateway dst 192.168.10.1
> acl no_bump_gateway dst 2001:db8:abcd:1::1
>
> Blocked or restricted traffic groups are terminated:
>
> ssl_bump terminate terminate_group
>
> Traffic matching splice conditions is allowed to pass through without
> interception:
>
> ssl_bump splice splice_main active_use
>
> Traffic from devices configured for inspection is then processed with SSL
> bump:
>
> ssl_bump bump bump_main active_use
>
> Finally, any traffic that does not meet the expected annotation or ACL
> conditions is terminated:
>
> acl activated note active_use true
> ssl_bump terminate !activated
>
> This ensures that only properly identified and permitted client
> connections are allowed through the proxy.
>
> The configuration also includes performance tuning settings such as SSL
> session caching, persistent client and server connections, optimized
> timeouts for large downloads, DNS timeout adjustments, and memory pool
> limits. These settings are intended to improve proxy efficiency and
> connection stability while maintaining the defined TLS handling policies.
>
> Best regards,
>
>
> Joanthan Lee
>
> On Mar 4, 2026, at 23:23, Amos Jeffries <squid3 at treenet.co.nz> wrote:
>
> On 04/03/2026 19:33, Andrey K wrote:
>
> Hello, Amos,
> Thanks for the information.
> Canyou alsotellme:
> 1. Is it possible to use a macro in the annotate_client ACL to copy HTTP
> request notes to a TCP connection? Something like:
> acl annotate_groups annotate_client groups=%{group}note
>
>
> That is not supported. Which is what I meant by these having to be
> configured manually. You need an ACL to match the group note, and another
> to set the new note, repeated for each group name you want to link between
> the transactions.
>
>
> 2. How do you think, should we process the "group" attribute at the
> connection state level as we do with the "clt_conn_tag"? I think this can
> be easily implemented in the UpdateRequestNotes() function (src/
> HttpRequest.cc) by simply copying and pasting a few lines of code:
>
>
> This is not great since group is not limited to Negotiate and NTLM
> authentication types. Other auth schemes have group only being valid on one
> HTTP transaction.
>
>
> I would suggest having a new access control directive that permits or
> denies annotations to be mapped when the CONNECT is bumped. That would
> allow any existing annotation of the CONNECT transaction to be applied as a
> connection-annotation for the bump'ed request.
>
> HTH
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20260324/e0cf96fb/attachment.htm>