Very interesting article that describes exactly the https sequences for an ntlm auth : http://www.benjaminathawes.com/blog/Lists/Posts/Post.aspx?ID=14 -----Message d'origine----- De : Clem [mailto:clemfree@xxxxxxx] Envoyé : vendredi 2 mars 2012 14:33 À : squid-users@xxxxxxxxxxxxxxx Objet : RE: https analyze, squid rpc proxy to rpc proxy ii6 exchange2007 with ntlm If I go to https://www.owasp.org/index.php/Authentication_In_IIS or http://www.innovation.ch/personal/ronald/ntlm.html NTLM Handshake When a client needs to authenticate itself to a proxy or server using the NTLM scheme then the following 4-way handshake takes place (only parts of the request and status line and the relevant headers are shown here; "C" is the client, "S" the server): 1: C --> S GET ... 2: C <-- S 401 Unauthorized WWW-Authenticate: NTLM 3: C --> S GET ... Authorization: NTLM <base64-encoded type-1-message> 4: C <-- S 401 Unauthorized WWW-Authenticate: NTLM <base64-encoded type-2-message> 5: C --> S GET ... Authorization: NTLM <base64-encoded type-3-message> 6: C <-- S 200 Ok I can see there us 3 auth/authorization before le 200 OK, squid seems to send only 1 and stop -----Message d'origine----- De : Clem [mailto:clemfree@xxxxxxx] Envoyé : vendredi 2 mars 2012 14:29 À : squid-users@xxxxxxxxxxxxxxx Objet : https analyze, squid rpc proxy to rpc proxy ii6 exchange2007 with ntlm Hello, What I can see : ........ USER with outlook PROXY RPC enabled with NTLM auth -> PROXY RPC IIS6/Exchange 2007 Outlook sends credentials, the proxy handles them and open exchange mailbox. ........ USER with outlook PROXY RPC enabled with NTLM auth -> SQUID PROXY -> PROXY RPC IIS6/Exchange 2007 The user sends credentials via squid, squid can't forward them exactly to the Exchange/IIS6 RPC Proxy and the proxy denies In the https analyzer I can see the NTLM request header is very short when we use squid and when we don't use it this header is very long ... Like this NTLM TlRMTVNTUAADAAAAGAAYAJgAAABkAWQBsAAAABoAGgBYAAAAEAAQAHIAAAAWABYAggAAAAAAAAAU AgAABYKIogYBsR0AAAAPOq4/lcuCWEXBWP01xOfE7UUAVQBSAE8AUwBJAFQATgBFAFYARQBSAFMA YQAuAHcAYQBxAHUAZQB0AEEALQBXAEEAUQBVAEUAVAAtAEgAUAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA4lx3+SYlVeSBpzbj9B93OAQEAAAAAAABuLvLQdfjMAYEqGS4sEy38AAAAAAIAGgBFAFUA UgBPAFMASQBUAE4ARQBWAEUAUgBTAAEAFgBFAFUAUgBPAFMASQBUAE0AQQBJAEwABAAgAGUAdQBy AG8AcwBpAHQAbgBlAHYAZQByAHMALgBmAHIAAwA4AGUAdQByAG8AcwBpAHQAbQBhAGkAbAAuAGUA dQByAG8AcwBpAHQAbgBlAHYAZQByAHMALgBmAHIABQAgAGUAdQByA[.....] For direct connection And whith squid : NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== Like it's stucked, I dunno The analyzer tells me that : WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11. Still stucked there ... Regards Clem
