[jcifs] NTLM & Empty Type 3 Message
Eric Glass
eric.glass at gmail.com
Thu Aug 30 11:26:29 GMT 2007
Here's what the Type 1 message looks like:
4e544c4d53535000 "NTLMSSP\0"
01000000 Type 1 message
b7b208e2
Flags (0xe208b2b7)
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM (0x00000200)
Negotiate Domain Supplied (0x00001000)
Negotiate Workstation Supplied (0x00002000)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
unknown (0x02000000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
0400040034000000 Supplied Domain header (length 4/offset 52)
0c000c0028000000 Supplied Workstation header (length 12/offset 40)
0502ce0e0000000f
OS version - Version 5.2 (Windows 2003 server) build 3790
434f524d454c2d5745423035
Workstation ("CORMEL-WEB05")
41504143
Domain ("APAC")
The client is supplying the domain and workstation in the Type 1,
which indicate that it is using the default credential handle (and
attempting to negotiate local authentication). This is probably
appropriate; assuming you have configured the ASP.NET application for
impersonation, it would presumably have established a context for the
authenticated end user.
What would typically occur on the server side of the handshake is:
1) The server examines the supplied workstation and domain name to
determine if the client is running locally.
2) If so, a new context is established within the server process; the
"Negotiate Local Call" flag would be set in the Type 2 message, and
the Type 2 context field would be populated with the new context
handle.
3) The client is then able to bind the server's context to the end
user's identity internally; it dereferences the context handle
provided by the server and completes the context.
4) An empty Type 3 message is sent to the server, indicating that the
context has been bound by the client.
In the jCIFS case, the following Type 2 message is produced:
4e544c4d53535000 "NTLMSSP\0"
02000000 Type 2 message
0800080030000000 Target Name header (length 8/offset 48)
05028100
Flags (0x00810205)
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Target Type Domain (0x00010000)
Negotiate Target Info (0x00800000)
436528884548cc7e Challenge
0000000000000000 Context
3200320038000000 Target Information header (length 50/offset 56)
6100700061006300
Target Name ("apac")
020008006100700061006300
Target Information - domain ("apac")
01001e0045004e005400450052005000520049005300450053004500410052004300
Target Information - server ("ENTERPRISESEARC")
00000000
Target Information - terminator
Since jCIFS cannot implement local authentication, a "vanilla" Type 2
message is returned to the client. In your case, the client is then
simply completing the handshake using the Anonymous credentials.
>From the perspective of your client, jCIFS is not running locally --
although it is physically, it cannot act the part of a local process
for the purposes of impersonation. Ultimately what you have is the
"double-hop" scenario:
http://blogs.msdn.com/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
http://support.microsoft.com/default.aspx?scid=kb;en-us;329986
Your end user is authenticating to IIS. Since they have their
password, their browser can respond to the challenge presented by IIS.
IIS is then attempting an NTLM handshake with a third party.
However, it does not know the end user's password; it has no means of
calculating the LM/NTLM responses for the Type 3 message.
Eric
On 8/29/07, Gibson, Steve <Steve.Gibson at bhpbilliton.com> wrote:
>
> 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