[jcifs] NTLM & Empty Type 3 Message
Eric Glass
eric.glass at gmail.com
Wed Aug 29 10:10:36 GMT 2007
The sign and seal flags should be okay; they are superfluous for the
purposes of authentication (just indicates that the context
established provides support for signing and sealing messages; if you
aren't actually attempting to do such, i.e. in RPCs or similar, it
shouldn't matter if the flags are there).
The type 3 message you have below represents an Anonymous bind:
http://davenport.sourceforge.net/ntlm.html#theAnonymousResponse
Dissected as:
4e544c4d53535000 "NTLMSSP\0"
03000000 Type 3 message
0100010060000000 LM/LMv2 response header; length 1/offset 96
0000000061000000 NTLM/NTLMv2 response header; length 0/offset 97
0000000048000000 Target name header; length 0/offset 72
0000000048000000 User name header; length 0/offset 72
1800180048000000 Workstation name header; length 24/offset 72
0000000061000000 Session key header; length 0/offset 97
350a8002
Flags (0x02800a35)
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Anonymous (0x00000800)
Negotiate Target Info (0x00800000)
unknown (0x02000000)
0502ce0e0000000f
OS version - Version 5.2 (Windows 2003 server) build 3790
43004f0052004d0045004c002d0057004500420030003500
Workstation ("CORMEL-WEB05")
00
LM/LMv2 response data (0x00)
It sounds like you're doing something like the following:
1) Web server, running IIS, authenticates the end user via Integrated
Windows Authentication.
2) ASP.NET application (backend of #1) is configured for impersonation.
3) Web service running on Tomcat, also executing on the web server, is
fronted by the jCIFS filter.
4) The application in #2 is calling the web service in #3 as a client.
The expectation being that the filter gets an NTLM handshake with the
end user's credentials.
If you can post the Type 1 and Type 2 messages going along with the
Type 3 above I can dissect those as well (would be interesting to look
at), but my guess is the following is happening:
1) End user is authenticated by IIS.
2) ASP.NET client calls into the web service, attempting to establish
Local Authentication; this is how impersonation would likely be
negotiated for NTLM:
http://davenport.sourceforge.net/ntlm.html#localAuthentication
3) The jCIFS filter does not indicate support for local
authentication, so the ASP.NET client falls back to Anonymous
authentication.
I don't think you would be able to leverage jCIFS in this
architecture; establishing Local Authentication would require that
jCIFS have access to the internal Windows NTLMSSP implementation.
Eric
On 8/29/07, Gibson, Steve <Steve.Gibson at bhpbilliton.com> wrote:
>
>
> 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.
>
More information about the jcifs
mailing list