[jcifs] NTLM & Empty Type 3 Message

Gibson, Steve Steve.Gibson at bhpbilliton.com
Wed Aug 29 08:41:42 GMT 2007


Hi All,
 
I've got a Web Service Application running on Tomcat 5.0.28, using jcifs
1.2.15 to provide NTLM to the Web Service, using NtlmHttpFilter.
 
When hitting the service with a Web Browser, everything works as
expected. However, when we use an ASP.NET 2.0 application running on IIS
(Win2K3 with LMCompatibilityLevel=1) that uses impersonation, we get
broken results.
 
At a high level, jcifs will report the user as being authenticated, even
though the Type 3 Message is empty. This is bad.
 
Type 3 Message
 
   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
--+-----------------------------------------------
 1|4E 54 4C 4D 53 53 50 00 03 00 00 00 01 00 01 00
 2|60 00 00 00 00 00 00 00 61 00 00 00 00 00 00 00
 3|48 00 00 00 00 00 00 00 48 00 00 00 18 00 18 00
 4|48 00 00 00 00 00 00 00 61 00 00 00 35 0A 80 02
 5|05 02 CE 0E 00 00 00 0F 43 00 4F 00 52 00 4D 00
 6|45 00 4C 00 2D 00 57 00 45 00 42 00 30 00 35 00
 7|00
 
 
Tracing further back, I found that the flags in the Type 1 message from
the ASP.NET client somewhat different to a browser.
 
After patching the null domain/username issue (Throw an SmbAuthException
if auth.username is (null | blank | whitespace) in
SmbSession.logon(UniAddress,NtlmPasswordAuthentication) ), I added some
additional tracing to get a dump of the flags on each message. Following
is what I get when hitting with IE...
 
Type 1 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000002 : Negotiate OEM
Flag 0x00000004 : Negotiate Target
Flag 0x00000200 : Negotiate NTLM
Flag 0x00008000 : Negotiate Always Sign
Flag 0x00080000 : Negotiate NTLM2
Flag 0x20000000 : Negotiate 128
Flag 0x80000000 : Negotiate 56
 
Type 2 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000004 : Negotiate Target
Flag 0x00000200 : Negotiate NTLM
Flag 0x00010000 : Target Domain
 
Type 3 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000004 : Negotiate Target
Flag 0x00000200 : Negotiate NTLM
Flag 0x00800000 : Negotiate Target Info
 
When I hit it with IIS, this is what I get...
 
Type 1 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000002 : Negotiate OEM
Flag 0x00000004 : Negotiate Target
Flag 0x00000010 : Negotiate Sign
Flag 0x00000020 : Negotiate Seal
Flag 0x00000080 : Negotiate LM Key
Flag 0x00000200 : Negotiate NTLM
Flag 0x00001000 : Negotiate OEM Domain
Flag 0x00002000 : Negotiate OEM Workstation
Flag 0x00008000 : Negotiate Always Sign
Flag 0x00080000 : Negotiate NTLM2
Flag 0x20000000 : Negotiate 128
Flag 0x40000000 : Negotiate Key Exchange
Flag 0x80000000 : Negotiate 56
 
Type 2 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000004 : Negotiate Target
Flag 0x00000200 : Negotiate NTLM
Flag 0x00010000 : Target Domain
 
Type 3 message
Flags Set
--------------------------
Flag 0x00000001 : Negotiate Unicode
Flag 0x00000004 : Negotiate Target
Flag 0x00000010 : Negotiate Sign
Flag 0x00000020 : Negotiate Seal
Flag 0x00000200 : Negotiate NTLM
Flag 0x00800000 : Negotiate Target Info
 
As can be seen, it drops NTLMV2, but seems to insist on Sign & Seal,
which as far as I can tell, is not implemented in jCIFS. BTW. The IIS
server is set to LMCompatibilityLevel 1. I have checked the "Network
security: Minimum session security for NTLM SSP based (including secure
RPC)" Group Policy on the Windoze box, and this is set to no minimum.
 
Has anyone got any ideas on how, short of implementing sign & seal, to
get around this? It looks to me like ASP.NET is forcing the Sign & Seal
even though the box is configured not to.
 
Thanks for any assistance.
 
Cheers
Steve
 


This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message.
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the jcifs mailing list