Yes, my Exchange server is the frontal server at the moment, and that works in ntlm
-----Message d'origine----- De : Fried Wil [mailto:wilfried.pasca...@gmail.com] Envoyé : mercredi 22 février 2012 13:56 À : squid-users@squid-cache.org Objet : Re: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook everywhere Hi Clem, Did you test CAS Server as Frontal just to test NTLM authentication less Reverse proxy ? User --> FW --> NAT@CAS Server and not User --> FW --> NAT@Reverseproxy --> CAS Server Just to test NTLM Authentication mecanism if it will be ok Thx On Wed, Feb 22, 2012 at 12:33:09PM +0100, Clem wrote: > Hi Fried, > > I know all this links !! :), but As you I've made squid to work like a charm > in front of my exchange for owa activesync and RPC too ... in basic auth, > not in NTLM auth, and I still stuck there. > > Impossible to find a solution to make a linux front-end, neither with squid > nginx apach or pound ! That's it ! I think I'll give up. > > BTW Thx ! > > -----Message d'origine----- > De : Fried Wil [mailto:wilfried.pasca...@gmail.com] > Envoyé : mercredi 22 février 2012 11:26 > À : squid-users@squid-cache.org > Objet : Re: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook > everywhere > > Hi Clem, > > I have test OWA RPC HTTPS and .. > > Apache => fail. Apache sees this as a security > leak. This is a raw explanation :-). The problem is how apache and Exchange > RPC use http 1.1 . Microsoft > let bigger package pass over http 1.1. > > Check these links : > https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 > http://forum.nginx.org/read.php?2,3511 > http://httpd.apache.org/security/vulnerabilities_20.html > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088 > > Squid as RP => OK. I have the final configuration. If u're interessted, > tell me and i'll send u the squid.conf > > Nginx => Not tested but I think it will be the same as Apache ... > > Regards, > > Wilfried > > On Wed, Feb 22, 2012 at 11:19:31AM +0100, Clem wrote: > > 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:clemf...@free.fr] > > Envoyé : jeudi 26 janvier 2012 13:12 > > À : 'squid-users@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:squ...@treenet.co.nz] > > Envoyé : jeudi 26 janvier 2012 12:24 > > À : squid-users@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: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. > > > > > > > > > > > > > > >