RE: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook everywhere

Hello,

Coming back after weeks of researches, gave up with squid, tried with pound
and nginx reverse proxy, and same issue, and the point is (getting it from
numbers of hints and searches in forums):

For pound (from a user in forum):

---------- POUND ------------
I looked into this when I first started using pound. This is a rather
simplified explanation of what I discovered (and could be completely
wrong - I don't know enough about RPC or HTTP). When Outlook sends the
first HTTP request it specifies a content-length of 1GB. I think this
is so the request stays open and RPC commands get sent via this
"tunnel". Pound (being the good proxy that it is) sits and waits for
the 1GB of data to arrive and does not pass the request to the BE until
it does. Pound eventually times out waiting for the promised 1GB of
data and gives up.

Here's Microsoft's details of the protocol:
http://technet.microsoft.com/en-us/library/aa995784(EXCHG.65).aspx
http://technet.microsoft.com/en-us/library/aa996706(EXCHG.65).aspx
---------- END POUND --------------

For NGINX (in logs) :

----------- NGINX ------------

2012/02/21 17:19:31 [error] 17072#0: *6 client intended to send too large
body: 1073741824 bytes, client: x.x.x.x, server: mail.xx.fr, request:
"RPC_IN_DATA /rpc/rpcproxy.dll?localmail.fr:6002 HTTP/1.1", host:
"mail.xx.fr"

---------- END NGINX -----------

IMHO, it's exactly the same issue I had with squid and rpc over https with
NTLM ...

Hope that can help, I'm now completely stucked !

Regards

Clémence

-----Message d'origine-----
De : Clem [mailto:clemfree_at_free.fr]
Envoyé : jeudi 26 janvier 2012 13:12
À : 'squid-users_at_squid-cache.org'
Objet : RE: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook
everywhere

On se second "anormal" I've sent, the certificate is sent.
The auth works on basic, I think the certificate is OK, however it would be
rejected, isn't it ?

-- ANORMAL2 (SQUID) --

2 0.001415 192.168.3.15 192.168.1.10 TCP https >
33043 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
SACK_PERM=1
3 0.001457 192.168.1.10 192.168.3.15 TCP 33043 >
https [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=81334043 TSER=0
4 0.002583 192.168.1.10 192.168.3.15 TLSv1 Client
Hello
5 0.003850 192.168.3.15 192.168.1.10 TLSv1 Server
Hello, Certificate, Server Hello Done
6 0.003887 192.168.1.10 192.168.3.15 TCP 33043 >
https [ACK] Seq=96 Ack=933 Win=7712 Len=0 TSV=81334044 TSER=23422065
7 0.007140 192.168.1.10 192.168.3.15 TLSv1 Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message
8 0.042683 192.168.3.15 192.168.1.10 TLSv1 Change
Cipher Spec, Encrypted Handshake Message
9 0.043505 192.168.1.10 192.168.3.15 TLSv1
Application Data

-- ANORMAL2 (SQUID) END --

-----Message d'origine-----
De : Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Envoyé : jeudi 26 janvier 2012 12:24
À : squid-users_at_squid-cache.org
Objet : Re: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook
everywhere

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:isenberg_at_e-spirit.com]
> Envoyé : jeudi 26 janvier 2012 11:01
> À : squid-users_at_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.
>
>
>
>
Received on Wed Feb 22 2012 - 10:19:43 MST