Hi, I just wanted to give this a bump; Is it possible to manipulate the (Kerberos-authenticated) username that gets sent to my ICAP server and strip off the @domain? E.g. Jsmith@myaddomain becomes jsmith Relevant squid lines just FYI: icap_send_client_username on icap_client_username_header X-Authenticated-User Access log shows my jsmith@myaddomain and I would LOVE to be able to just have the first part in ICAP X-Authenticated-User. Thanks again, Nick On 25/03/2010 16:18, "Nick Cairncross" <Nick.Cairncross@xxxxxxxxxxxxxxx> wrote: Amos, Thanks for your help - you are right in that the connector has the ability to receive and manipulate ICAP, and using an NTLM authenticated user allows me to do the thing I need. All was nearly lost. However, if I change to Kerberos authentication on my Squid then the connector breaks because it receives the user name as an UPN. Is it possible to send just the first part of the authenticated user (i.e. Username?) and not include the domain? I read something interesting here: http://markmail.org/message/u3yoiykwkaykreoz about using string substitutions (%U, %N etc) Is this achievable with Squid? This could be the final piece in my puzzle... Thanks, Nick On 24/03/2010 05:58, "Amos Jeffries" <squid3@xxxxxxxxxxxxx> wrote: Nick Cairncross wrote: > Hi All, > > Things seem to be going well with my Squid project so far; a combined > Mac/Windows AD environment using Kerberos authentication with fall > back of NTLM. I (hopefully) seem to be getting the hang of it! I've > been trying out the Kerberos LDAP look up tool and have a couple of > questions (I think the answers will be no..): > > - Is it possible to wrap up the matched group name(s) in the header > as it gets sent onwards to my peer? I used to use the authentication I don't think so. There is a lot of manipulation magic you can do with the ICAP or eCAP interfaces that is not possible directly in Squid though. The risk is breaking back-end services that can't handle the altered header. Since you say below about already doing so, I assume this is a non-risk for your network. > agent that came from our A/V provider. This tool ran as a service and > linked into our ISA. Once a user authenticated their group membership > was forwarded along with their username to my peer (Scansafe). The > problem is that it only does NTLM auth. It added the group > (WINNT://[group]) into the header and then a rule base at the peer > site could be set up based on group. Since I am using Kerberos I > wondered whether it's possible to send the results of the Kerb LDAP > auth? I already see the user on the peer as the Kerberos login. It > would be great if I could include the group or groups... You can do transparent login pass-thru to the peer (login=PASS). You can log Squid-3.1 into the peer with kerberos credentials. But I do not think the Kerberos details get decoded to a username/password for Squid to pass back as a pair. > > This is what I use currently: cache_peer proxy44.scansafe.net parent > 8080 7 no-query no-digest no-netdb-exchange login=* (From > http://www.hutsby.net/2008/03/apple-mac-osx-squid-and-scansafe.html) > > - Are there plans to integrate the lookup tool in future versions of > Squid? I've enjoyed learning about compiling but.. just wondering.. > No. Plans are for all network-specific adaptation to be done via external helper processes. The *CAP interfaces for add-on modules allow all the adaptation extras to be plugged in as needed in a very powerful way. Check that AV tool, it likely has an ICAP interface Squid-3 can plug into already. Amos -- Please be using Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25 Current Beta Squid 3.1.0.18 ** Please consider the environment before printing this e-mail ** The information contained in this e-mail is of a confidential nature and is intended only for the addressee. If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful. Disclosure to any party other than the addressee, whether inadvertent or otherwise, is not intended to waive privilege or confidentiality. Internet communications are not secure and therefore Conde Nast does not accept legal responsibility for the contents of this message. Any views or opinions expressed are those of the author. Company Registration details: The Conde Nast Publications Ltd Vogue House Hanover Square London W1S 1JU Registered in London No. 226900 ** Please consider the environment before printing this e-mail ** The information contained in this e-mail is of a confidential nature and is intended only for the addressee. If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful. Disclosure to any party other than the addressee, whether inadvertent or otherwise, is not intended to waive privilege or confidentiality. Internet communications are not secure and therefore Conde Nast does not accept legal responsibility for the contents of this message. Any views or opinions expressed are those of the author. Company Registration details: The Conde Nast Publications Ltd Vogue House Hanover Square London W1S 1JU Registered in London No. 226900
