Re: 2.6stable5 icap client - reqmod problems with webwasher 5.x and 6

From: Jeremy Hall <jehall@dont-contact.us>
Date: Tue, 21 Nov 2006 19:25:51 -0500

There are commercial vendors that can use the auth scheme. They want
X-Authenticated-User and X-Authenticated-Groups. I don't know what the
correct syntax for the X-Authenticated-Groups should be, but if that
header is NOT present, the product queries the ldap database to get the
groups itself. Not very efficient, I know. If I knew what the
X-Authenticated-Groups header was supposed to look like, I would come up
with something.

_J

>>> "Westerhold, Axel" <Axel.Westerhold@dts.de> 11/21/06 3:42 PM >>>
Nop, it won't ! Actually there are several reasons it won't

1.) Webwasher expects a group or a username to be used within a
webwasher
defined LDAP query. That way I do not need the auth_scheme

2.) the auth_sheme as proposed is short of fullfilling the needed
abstaction

Let's assume your AD is based on root dc=test,dc=intra. Users can be
based
on ou=admin_users or ou=normal_users. So the needed URI would either
be

LDAP://<server>/cn=%u,ou=%o,dc=%d,dc=intra

None of the infos you can get from a SMB/NTLM/ADS auth will supply the
needed OU (%o) info for your auth sheme. Actually this is a rather
simple
setup. Actually I know of more then one customer to spread it's
userbase
throughout several OU's.

As there is a rather small base of commercially available ICAP
implementations and none of those I know of actually use the auth-sheme
we
can still think about writing our own ICAP Server. In this case such a
server would rather need an new auth sheme like

AD://user:%u,domain:%d

This would work in any LDAP query like

Ldapsearch -X -h <server> -b %d,dc=intra samaccountname=%u

Regards,
Axel

Am 21.11.2006 20:46 Uhr schrieb "Jeremy Hall" unter
<jehall@central.unicor.gov>:

> Does it work for your setup?
>
> _J
>
>>>> "Westerhold, Axel" <Axel.Westerhold@dts.de> 11/21/06 1:32 PM >>>
> Hi Jeremy,
>
> That definately more then I need to do :-) ! I will just have to get
> rid of
> the domain but your approach might be better for the future.
>
> Axel
>
>
>
> Am 21.11.2006 19:26 Uhr schrieb "Jeremy Hall" unter
> <jehall@central.unicor.gov>:
>
>> Hello,
>>
>> Here is the icap patch I am working on. It might not fully work,
>> probably won't break much tho. It's not ready for merging, and the
>> debug statements are wrong (shouldn't be prio 1) but I'm trying to
> work
>> out the kinks before readying it for merge.
>>
>> _J
>>
>>>>> "Westerhold, Axel" <Axel.Westerhold@dts.de> 11/21/06 12:54 PM
>>>
>> Hi All,
>>
>> I will have a look at the squid3 but I will need to modify it a
> little
>> bit
>> so that I can split the Domain Part of the Username to make the
>> webwasher
>> happy on ist AD samaccount queries. From what I can see it should
be
>> easy
>> enough to get this done inlcuding a way to enable/disable this
> feature
>> (like
>> the one I did for 2.x).
>>
>> Also, I just shipped a 2.6 ICAP Patched Squid in a cluster setup
to
> a
>> customer with 1000 Users. This Pilot Installation will get me a
good
>> feeling
>> how stable 2.6 works.
>>
>> Regards,
>> Axel
>>
>>
>> Am 20.11.2006 22:57 Uhr schrieb "Tsantilas Christos" unter
>> <chtsanti@users.sourceforge.net>:
>>
>>> Hi all,
>>> The reported problems exists and are not webwasher related, exists
>> for
>>> every icap server.
>>>
>>> Axel's solutions causes crashes to squid in some cases. I think it
>>> happens when http client closes the connection before the
> connection
>> to
>>> the icap server closed. I am not sure it needs more debugging.
>>> I am planning to give some more time...
>>>
>>> However, the squid3 with icap client is more stable than squid-26
>> with
>>> icap patch. I think the squid3 has only 2-3 bugs before the
> release.
>>> My opinion is that it does not make sense for someone to spend
time
>> in
>>> squid26 icap client, it is good for testing and development but
> only
>>> that .....
>>>
>>> Regards,
>>> Christos
>>>
>>> Westerhold, Axel wrote:
>>>> Well,
>>>>
>>>> as I have a customer waiting for a fix I will just go with my
>> modification
>>>> and will try to pin down the real fault when I have some free
time
>>>> available. Setting the major version the way I do should not have
> a
>> real
>>>> impact at least I can't see one right now on my test system.
>>>>
>>>> Regards,
>>>> Axel
>>>>
>>>>
>>>>
>>>
Received on Tue Nov 21 2006 - 17:26:21 MST

This archive was generated by hypermail pre-2.1.9 : Wed Nov 29 2006 - 12:00:05 MST