<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Max (Weijun) Wang wrote:
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<pre wrap="">On Feb 4, 2010, at 4:15 PM, Natalie Li wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">public final class Client {
/**
* Creates an NTLM Client instance.
* @param version the NTLM version to use, which can be:
* <ol>
* <li>1: Original NTLM v1
* <li>1lm: Original NTLM v1, LM only
* <li>1ntlm: Original NTLM v1, NTLM only
* <li>1+: NTLM v1 with Client Challenge
* <li>2: NTLM v2
* <li>2lm: NTLM v2, LM only
* <li>2ntlm: NTLM v2, NTLM only
* </ol>
* If null, "1+" will be used.
</pre>
</blockquote>
<pre wrap="">I'm not familiar with the Java syntax so could you please elaborate on how you come up with the param version?
You can find the following 2 fields in NTLMSSP Type 3 message:
LmChallengeResponse
NtChallengeResponse
So, the Type 3 message could contain the following challenge responses:
NTLM
LM and NTLM
LMv2 and NTLMv2
</pre>
</blockquote>
<pre wrap=""><!---->
I observe that when the client only provides LM, the authentication still goes fine.</pre>
</blockquote>
Typically, a client provides both LmChallengeResponse and
NtChallengeResponse to the server, if the provided LmChallengeResponse
matches the LM, LMv2 challenge responses generated by the server or the
provided NtChallengeResponse matches the NTLM, or NTLMv2 generated by
the server, authentication succeeds if LMCompatibiity level is set to
0. What challenge responses are accepted by Windows server depends
upon the LMCompatibilityLevel setting. <br>
<pre wrap="">Values:
0 accept all
1 accept all
2 accept all
3 accept all
4 refuse LM
5 refuse LM & NTLM</pre>
<br>
<br>
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<pre wrap=""> The same for v2 messages. This is why I allow the client to choose whatever it want to send.
</pre>
</blockquote>
I'd stick with the following combination. But your choice.<br>
<pre wrap="">Values:
0 Send LM & NTLM responses
1 Send LM & NTLM - use NTLMv2 session security if negotiated
2 Send NTLM response only
3 Send NTLMv2 response only
4 Send NTLMv2 response only
5 Send NTLMv2 response only</pre>
<br>
<br>
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<pre wrap="">By "1+", I mean the NTLM2 response described at --
<a class="moz-txt-link-freetext"
href="http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse">http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse</a>
Altogether, the client can choose 7 styles.
</pre>
</blockquote>
See above.<br>
<br>
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> public byte[] type3(byte[] type2, byte[] nonce) throws NTLMException;
</pre>
</blockquote>
<pre wrap="">I'm missing the context. What's the purpose of the nonce when generating the type 3 message?
</pre>
</blockquote>
<pre wrap=""><!---->
The class does not deal with random bytes generation inside, so the caller needs to provide the nonce.
</pre>
</blockquote>
I was not asking why the nonce is passed to the API. I'm asking the
usage of the nonce in the function. Just looking at the function
signature, it doesn't provide me enough context as to how the nonce is
used.<br>
<br>
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">1. As described by the MSDN article, when LMCompatibilityLevel is set to a
high value on the server, certain low value request is not supported
</pre>
</blockquote>
<pre wrap="">This statement isn't clear (See below).
</pre>
</blockquote>
<pre wrap=""><!---->
Not clear, I'll use your words below on NTLMv2.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">2. There's no protocol for the server to tell the client to use a higher
version, so you must manually setup this config on the client side
</pre>
</blockquote>
<pre wrap="">The use of NTLM or NTLMv2 authentication is not negotiated between the client and server. Hence, authentication might fail if the server mandates NTLMv2 authentication while the client uses NTLM authentication.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, this is what I say "manually setup this config on the client side".
</pre>
</blockquote>
Regards,<br>
<br>
Natalie<br>
<br>
<blockquote cite="mid:368683B5-F491-406A-A810-540826D950E0@Sun.COM"
type="cite">
<pre wrap="">Thanks
Max
</pre>
<blockquote type="cite">
<pre wrap="">Natalie
Max (Weijun) Wang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All
Please take a review on this draft before I send it for CCC:
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eweijun/spec/NTLMSASL.0.1">http://cr.openjdk.java.net/~weijun/spec/NTLMSASL.0.1</a>
The spec includes a raw NTLM API defined in com.sun.* namespace and describes the newly added SASL mech.
Thanks
Max
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>