On 26/01/2012 11:55 p.m., Clem wrote:
Amos and Isenberg,

For me, ntlm is not an option, I have to make it working, cause all my
clients are in ntlm on outlook, especially the external ones. And that
worked without squid, and I want that can work with it at frond end.

I've sniffed the sequence on working ntlm auth and not working (squid) auth
(192.168.3.15 is exchange serv, 192.168.1.134 my IP on direct RPCoHTTPS, and
192.168.1.10 squid server redirecting from an external ip):

Aha. Some use yes. It seems to confirm that the supported SSL encryption types are probably the problem.

The packets you call "NORMAL" the client connects, server accepts that and hands over its certificate.

The packets you call "ANORMAL" the client connects, the server indicates a encryption change, the client accepts and sends the requst in new form. The server certificate is apaprently not involved.

You can probably drill down into those packets with "Change Cipher Spec" to see more about what is going on. Search engine is likely to be more help than me for the details you find.

Amos


-- NORMAL ---

2 0.000377    192.168.3.15          192.168.1.134         TCP      https>
26701 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
3 0.000428    192.168.1.134         192.168.3.15          TCP      26701>
https [ACK] Seq=1 Ack=1 Win=64240 Len=0
4 0.000992    192.168.1.134         192.168.3.15          TLSv1    Client
Hello
5 0.002007    192.168.3.15          192.168.1.134         TLSv1    Server
Hello, Certificate, Server Hello Done
6 0.002642    192.168.1.134         192.168.3.15          TLSv1    Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message
7 0.035230    192.168.3.15          192.168.1.134         TLSv1    Change
Cipher Spec, Encrypted Handshake Message
8 0.036034    192.168.1.134         192.168.3.15          TLSv1
Application Data

-- NORMAL END ---

-- ANORMAL (SQUID) --

2 0.000529    192.168.3.15          192.168.1.10          TCP      https>
47552 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
SACK_PERM=1
3 0.000560    192.168.1.10          192.168.3.15          TCP      47552>
https [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=81027244 TSER=0
4 0.001248    192.168.1.10          192.168.3.15          TLSv1    Client
Hello
5 0.002110    192.168.3.15          192.168.1.10          TLSv1    Server
Hello, Change Cipher Spec, Encrypted Handshake Message
6 0.002140    192.168.1.10          192.168.3.15          TCP      47552>
https [ACK] Seq=128 Ack=123 Win=5856 Len=0 TSV=81027244 TSER=23409792
7 0.002869    192.168.1.10          192.168.3.15          TLSv1    Change
Cipher Spec, Encrypted Handshake Message
8 0.003423    192.168.1.10          192.168.3.15          TLSv1
Application Data

-- ANORMAL (SQUID) END --

I hope that can help you, as I can see there is a difference when the
exchange server answer Hello, but I can't understand more ...

Regards

Clémence

-----Message d'origine-----
De : Isenberg, Holger [mailto:isenb...@e-spirit.com]
Envoyé : jeudi 26 janvier 2012 11:01
À : squid-users@squid-cache.org
Objet : RE: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook
everywhere

I'm wondering if NTLM would work at all with any non-ISA proxy for Outlook
Anywhere. After reading
http://www.sysadminlab.net/exchange/outlook-anywhere-basic-vs-ntlm-authentic
ation-explained I'll stay with Basic Auth and when using it over https I
don't see any reason for not doing. Of course when all your traffic to the
Exchange https connector goes over squid, even on the local network, then
you have a reason to use single sign-on login methods, but for that in our
local network clients can connect directy to Exchange.





Reply via email to