[jcifs] NTLM & Empty Type 3 Message
Eric Glass
eric.glass at gmail.com
Wed Sep 5 08:41:38 GMT 2007
That is a bit strange (you wouldn't normally see the supplied
domain/workstation in the Type 1 unless the client thought there was a
possibility that the server is local). But NTLM impersonation (even
in the "pure" Microsoft scenario) requires that the service be local
to IIS -- to pass credentials transparently across boxes on the server
side requires Kerberos delegation.
On 9/5/07, Gibson, Steve <Steve.Gibson at bhpbilliton.com> wrote:
>
> Hi Eric,
>
> Thanks again for the response. The only point I have is that
> jCifs/Tomcat & IIS are located on different boxes.
>
> +---------+ +-----+ +--------+
> | IE | | | | jCIFS |
> | Browser | <----> | IIS | <----> | & |
> | | | | | Tomcat |
> +---------+ +-----+ +--------+
> Client Machine Web Server App Server
>
> Given this operational scenario, I still don't understand why IIS would
> try to Negotiate Local with jCIFS.
>
> Thanks again
> Steve
>
> -----Original Message-----
> From: Eric Glass [mailto:eric.glass at gmail.com]
> Sent: Thursday, 30 August 2007 9:26 PM
> To: Gibson, Steve
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] NTLM & Empty Type 3 Message
>
> 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-pr
> oblem.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.
> >
>
>
> 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