Did you try -r with squid_kerb_auth ?
Markus
"Nick Cairncross" <Nick.Cairncross@xxxxxxxxxxxxxxx> wrote in message
news:C7D69A71.1DC21%Nick.Cairncross@xxxxxxxxxxxxxxxxxx
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
