[jcifs] Re: security policy requires NTLMv2
aweber at comcast.net
Fri Jan 30 16:40:29 GMT 2009
Maybe it's that your precise problem is not clear to me. A quick check of
the website shows that, barring any remaining bugs, 1.3 fully supports
If you are trying to use NTLMv2 in an SSO implementation -- especially the
way the filter works -- then Mike has made it very clear that it will
probably never work, because of how the hashes are generated when using
NTLMv2 protocol. But that is a specific "issue" with upgrading your
network, and does not imply that the latest jar does not support the
----- Original Message -----
From: "pardesh" <pardesh_dsp at yahoo.com>
To: <jcifs at lists.samba.org>
Sent: Friday, January 30, 2009 11:27 AM
Subject: [jcifs] Re: security policy requires NTLMv2
> AJ Weber <aweber <at> comcast.net> writes:
>> I may be mistaken, but I think the latest version 1.3.x supports NTLMv2.
>> Michael Allen frequents the list, so I'm sure he will respond soon with a
>> more "authoritative" answer.
>> Good Luck,
>> ----- Original Message -----
>> From: "pardesh" <pardesh_dsp <at> yahoo.com>
>> To: <jcifs <at> lists.samba.org>
>> Sent: Friday, January 30, 2009 10:57 AM
>> Subject: [jcifs] security policy requires NTLMv2
>> > Hi,
>> > We have an existing java application using jcifs 1.2.9 for windows
>> > based
>> > authentication single signon. right now our company security policies
>> > are
>> > changed and security policy requires NTLMv2. After doing a little
>> > search
>> > on
>> > this forum found that it wont support ntlmv2.
>> > we are looking for an alternative implementation(quicker) which will
>> > support
>> > ntlmv2.
>> > Thanks in advance for your inputs.
>> > Thanks,
>> > pardesh
> Thanks AJ!!
> I have tried with the latest version and it doesnt work for security
> requires NTLMv2.
> I know it will not work and looking for an alternative implementation.
> Here is the answer from mike regarding this in the previous thread:
> Extended security is the "new" way to exchange tokens to
> perform authentication which as of 1.3 is the default because it is
> required to do NTLMv2. There's still a challenge that can be extracted
> from extended security tokens but the SmbSession.getChallenge and
> getChallengeForDomain methods are for doing "man-in-the-middle" style
> authentication (used by the HTTP Filter to do SSO) which does not work
> with NTLMv2 so there's no point in "fixing" those methods to return
> the proper challenge as it would be of no use to anyone.
> Just set jcifs.lmCompatibility = 0 and
> jcifs.smb.client.useExtendedSecurity = false to use NTLMv1. Then it
> will work (unless security policy requires NTLMv2).
More information about the jcifs