[jcifs] Issues with lmCompatibility and NTLMfilter

Michael B Allen mba2000 at ioplex.com
Mon Jan 22 01:51:45 GMT 2007


On Sun, 21 Jan 2007 20:10:19 -0500
Gidado-Yisa Immanuel <gidado at users.sourceforge.net> wrote:

> I installed 1.2.8 of NtlmHttpFilter into my current webapplication.  I 
> set the following parameters appropriately:
> 
>   jcifs.smb.domain
>   jcifs.smb.od

There are no such properties that I'm aware of.

> These are the results that I see:
> 
>    OS Registry Setting for  Web      User
>       lmcompatibilitylevel  Browser  Authenticates?
> 1. XP 4                     IE6      no (doesn't respond to Type2 msg)
> 2. 2K 0                     IE6      yes
> 3. XP 4 (not used by FF)    FF1.5    yes
> 
> I'm trying to resolve case (1) which represents abuot 60% of my users.  
> What I noticed in looking at the packets via wireshark for (1) and (3) 
> is that the following flags are set in the Type1 (negotiate) message:
> 
>   (1) XP/IE6   - Flags: 0xa208b207
>   (3) XP/FF1.5 - Flags: 0x00088207
> 
> So in case (1), IE6 is setting these additional flags:
> 
>   negotiate 56
>   negotiate 128
>   negotiate NTML key
> 
> Now these flags are defined in NtlmFlags.java 
> <http://jcifs.samba.org/src/src/jcifs/ntlmssp/NtlmFlags.java>, but are 
> never used throughout jcifs.  In fact, the flags segment is constructed 
> from Type2Message 
> <http://jcifs.samba.org/src/src/jcifs/ntlmssp/Type2Message.java>.getDefaultFlags() 
> which knows about 4 or 5 flags altogether.  My thinking is that with 
> lmcompatibilitylevel=4, IE wants to do NTLMv2,  but it does not see any 
> of the appropriate flags returned in the type2 message, and quits.  Will 
> returning these flags help IE to complete the negotiation and send the 
> type3 authorization?

I'm not very familiar with the NTLMSSP code but note that JCIFS does
not support NTLMv2. It does support LMv2. This has been reported to work
for some users.

> My other approach was to investigate how the challenge was constructed.  
> Perhaps IE sees the challenge and determines that it is not NTLMv2.  I 
> looked in NtlmPasswordAuthentication.java 
> <http://jcifs.samba.org/src/src/jcifs/smb/NtlmPasswordAuthentication.java> 
> at how the challenge is constructed.  Eventually (I think) this code is 
> called:
> 
>     public byte[] getUnicodeHash( byte[] challenge ) {
>         if( hashesExternal ) {
>             return unicodeHash;
>         }
>         switch (LM_COMPATIBILITY) {
>         case 0:
>         case 1:
>         case 2:
>             return getNTLMResponse( password, challenge );
>         case 3:
>         case 4:
>         case 5:
>             /*
>             if( clientChallenge == null ) {
>                 clientChallenge = new byte[8];
>                 RANDOM.nextBytes( clientChallenge );
>             }
>             return getNTLMv2Response(domain, username, password, null,
>                     challenge, clientChallenge);
>             */
>             return new byte[0];
>         default:
>             return getNTLMResponse( password, challenge );
>         }
>     }
> 
> Notice that for cases 3-5, the code is commented out (though it is not 
> commented out in getAnsiHash()).  Anyone know the reason for this?

Yes. That is because JCIFS does not support that security level.

It might also help you to read Eric Glass' NTLM documentation.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/


More information about the jcifs mailing list