[jcifs] NTLM & Empty Type 3 Message
Gibson, Steve
Steve.Gibson at bhpbilliton.com
Thu Aug 30 01:17:07 GMT 2007
Sorry, also forgot to mention that the exact same code, when run from
the command line or interactive login (i.e. not IIS) works without a
problem.
-----Original Message-----
From: Gibson, Steve
Sent: Wednesday, 29 August 2007 9:00 PM
To: 'Eric Glass'
Cc: jcifs at lists.samba.org
Subject: RE: [jcifs] NTLM & Empty Type 3 Message
Hi Eric,
Thanks for the response. Yes, your synopsis of the application was
correct. Browser -> IIS -> jCIFS/Tomcat.
I've been hunting through .Net doco, and it seems that ASP.NET, by
default, requires at a minimum Encrypt And Sign. This is represented as
the Enum ProtectionLevel, and forces the client to only negotiate at a
minimum level (See
http://msdn2.microsoft.com/en-us/library/ms145042.aspx) So, if it can't
get signed & sealed, it won't authenticate.
It is possible to change this to ProtectionLevel.None, which will
permit, but not require signed & sealed. My next step is to work out how
this can be done on a SoapHttpClientProtocol object, but as a .Net
neophyte, that may take a while...
Regarding the Type 1 & Type 2 messages...
Type 1
4E 54 4C 4D 53 53 50 00 01 00 00 00 B7 B2 08 E2
04 00 04 00 34 00 00 00 0C 00 0C 00 28 00 00 00
05 02 CE 0E 00 00 00 0F 43 4F 52 4D 45 4C 2D 57
45 42 30 35 41 50 41 43
Type 2
4E 54 4C 4D 53 53 50 00 02 00 00 00 08 00 08 00 30 00 00 00 05 02 81 00
43 65 28 88 45 48 CC 7E 00 00 00 00 00 00 00 00 32 00 32 00 38 00 00 00
61 00 70 00 61 00 63 00 02 00 08 00 61 00 70 00
61 00 63 00 01 00 1E 00 45 00 4E 00 54 00 45 00
52 00 50 00 52 00 49 00 53 00 45 00 53 00 45 00
41 00 52 00 43 00 00 00 00 00
Thanks again
Cheers
Steve
-----Original Message-----
From: Eric Glass [mailto:eric.glass at gmail.com]
Sent: Wednesday, 29 August 2007 8:11 PM
To: Gibson, Steve
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] NTLM & Empty Type 3 Message
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.
>
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