During an NTLM handshake, I've never seen a server mentioning another scheme.
As seen in message #4, the NTLM header still contains data, so there should not
be WWW-Authenticate: Negotiate header.
That said, this is only my experience. I tried to find any words on this from
an RFC but failed.
-Max
On Oct 10, 2011, at 7:48 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
> Max [to'ed],
>
> Does this look familiar? Is it wrong for the server to be returning
> "WWW-Authenticate: Negotiate" during NTLM handshake?
>
> -Chris.
>
> On 08/10/2011 14:41, Mario Ivankovits wrote:
>> Hi net-devs,
>>
>> I hope you do not mind that I post to this list, but I hope I can
>> provide enough in-depth information about the problem to justify the
>> post here.
>>
>> Accessing a “normal” ntlm protected resource – a simple index.html in an
>> protected directory on an IIS 7.5 server - the ntlm authentication works
>> fine.
>>
>> However, trying to access the Microsoft Exchange 2010 webservice failes
>> with “401 Unauthorized”.
>>
>> I used this few lines to debug the connection/authentication process
>>
>> URL url = new URL("https://exchange/ews/Services.wsdl";);
>>
>> byte[] buf = new byte[10240];
>>
>> int read = url.openStream().read(buf);
>>
>> System.err.println(new String(buf, 0, read));
>>
>> This snipped works fine in java 1.6, but failes with an IOException
>> (http status 401) in java 1.7.
>>
>> I found an interesting difference when accessing the “normal” web-page
>> and the exchange webservice.
>>
>> When accessing the web-page, the server answers “WWW-Authenticate:
>> Negotiate” just after the first 401 response which triggers the
>> authentication process then. In contrast, when accessing the Exchange
>> webservice the “WWW-Authenticate: Negotiate” is sent during the
>> negotiation process too, which then triggers the inNegotiate flag in
>> sun.net.www.protocol.http.HttpURLConnection in getInputStream and let
>> the negotiation process fail.
>>
>> If I hack the response values and change any subsequent Negotiate to
>> e.g. NegotiateXX, then the inNegotiate flag will not change and the
>> authentication process will finish and authentication finally works.
>>
>> Here is the request/response cycle which fail then:
>>
>> #1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
>> Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
>> image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
>>
>> #2: {null: HTTP/1.1 401 Unauthorized}{Server:
>> Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate:
>> NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39
>> GMT}{Content-Length: 0}
>>
>> #3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
>> Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
>> image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{Authorization:
>> NTLM MY_NTLM_DATA}
>>
>> #4: {null: HTTP/1.1 401 Unauthorized}{Server:
>> Microsoft-IIS/7.5}{WWW-Authenticate: NTLM
>> SERVER_NTLM_DATA}{WWW-Authenticate: Negotiate}{X-Powered-By:
>> ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39 GMT}{Content-Length: 0}
>>
>> Exception in thread "main" java.io.IOException: Server returned HTTP
>> response code: 401 for URL: https://exchange/ews/Services.wsdl
>>
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1612)
>>
>> at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
>>
>> at java.net.URL.openStream(URL.java:1035)
>>
>> Does this make sense to you?
>>
>> It seems to me the “inNegotiate” handling needs a review as it does not
>> work in all cases.
>>
>> I hope my informations are of any help to fix this issue.
>>
>> Ciao,
>>
>> Mario
>>
