hi Henrik - answers inline...
Henrik Nordstrom wrote:
> tis 2007-05-01 klockan 22:49 +0100 skrev Gareth Edmondson:
>
>
>   
>> Now this threw up an error along the lines of having two cache_peer 
>> names the same. So we edited the hosts file in DNS setting a name to 
>> resolve to the same IP address. The line now reads:
>>
>> cache_peer sslproxy 443 parent 7 <and then all the other stuff>
>>     
>
> There is a name= option to cache_peer to solve this without having to
> fake host names..
>   
Thanks for the advice here. I read about this name= option earlier in 
the archives - but I got the impression from previous posters that it 
was in version 3 of squid and not the stable version that ships with 
Debian Etch. The stable version is 2.6.5-6.
A quick look at debian.org reveals that 3.0.PRE5-5 is there. I have not 
tried this because we have been advised to stick with the stable branch.
>> We thought this would work - but it didn't, so we edited the 
>> cache_peer_access line to say 'cache_peer_access sslproxy allow CONNECT'.
>>     
>
> You also need to deny CONNECT from the other..
>   
Okay - I think we may have done this. The lines looked something like this
cache_peer_access sslproxy allow CONNECT
cache_peer_access sslproxy deny all
cache_peer_access <original upstream name> deny CONNECT
cache_peer_access <original upstream name> allow all
I'm not sure they are in the right order.
>> Everything seems to be working. However when we try and connect to the 
>> 443 website it challenges us again for the AD username and password. 
>> Upon entering this the browser challenges us again and again and again - 
>> simply not letting us through.
>>     
>
> What does your access.log say?
>   
I shall take a look in work tomorrow.
Cheers
Gareth
Received on Tue May 01 2007 - 16:41:53 MDT
This archive was generated by hypermail pre-2.1.9 : Fri Jun 01 2007 - 12:00:04 MDT