[jcifs] JCIFS Pops up dialog box for Authenticating certain users

[Michael B Allen]

On 7/14/08, Asaf Mesika <asaf.mesika at gmail.com> wrote:
>
>
>
> On Thu, Jul 10, 2008 at 5:22 AM, Michael B Allen <ioplex at gmail.com> wrote:
> >
> > On 7/9/08, Ti Lian Hwang <lian_hwang.ti at fairprice.com.sg>
> wrote:
> > >
> > > Sorry, I gotta keep refering to this ...
> > >
> > >
> http://lists.samba.org/archive/jcifs/2008-January/007602.html
> > >
> > > which has worked for me ever since.
> >
> > That's not a "fix" for anything. It just disables reusing transports.
> > Setting jcifs.smb.client.ssnLimit = 1 would work equally well
> > (although we recently fixed a bug that caused an NPE when setting that
> > property to 1). But without transport reuse every authentication has
> > to build up and tear down a socket which completely obliterates
> > scalability and that is the greatest strength of the JCIFS NTLM HTTP
> > Filter.
> >
> > The only known issue regarding the filter is the "hiccup bug" where
> > transports shutdown in the middle of the NTLM exchange thereby
> > invalidating any in-flight nonces. This is likely to be the issue that
> > you are seeing. It's just a bad interaction between the stateful
> > NTLMSSP and stateless HTTP protocols. The proposed fix for this issue
> > is discussed here:
> >
> >
> http://lists.samba.org/archive/jcifs/2008-June/008019.html
> >
> > However this fix will likely never be incorporated. Is is more likely
> > that the NTLM HTTP Filter in general will be dropped with the release
> > of JCIFS 2.0 (assuming a 2.0 ever happens) because the Filter has
> > nothing to do with the CIFS protocol and, more important, the
> > man-in-the-middle hack the Filter uses will not work with NTLMv2 which
> > is gaining popularity (and it's at the center of the "hiccup" bug).
> >
> What is "The man-in-middle" hack you are referring to?
> Why NTLMv2 will prevent the filter from working?

Hi Asaf,

The way the current NTLMv1 HTTP Filter works is it maps each HTTP
request/response to and from an SMB request/response with the DC. So
when the HTTP client requests a challenge, JCIFS creates an SMB
transport with the DC and returns the NTLM challenge associated with
SMB NTLM authentication on that transport. The client computes hashes
and sends them to the web server as the type-3 message, the hashes are
extracted and used to perform a standard SMB NTLM authentication over
the corresponding transport. This is effectively a "man-in-the-middle"
attack.

A proper NTLM filter would use something called
pass-through-authentication. When the HTTP client requests a challenge
the web server would generate a random one itself. The client uses the
challege and sends hashes in the type-3 message as usual. Now the web
server takes the hashes and the corresponding challenge and sends them
to the DC in a NETLOGON NetrSamLogon DCERPC over SMB call to be
verified.

Knowing the above a few important points are to be made:

1) NTLMv2 cannot work using the "man-in-the-middle" hack because the
client computes the NTLMv2 hashes with "target information". That
target information will ultimately involve the web server hostname
which means the NetrSamLogon verification with the DC would fail if we
tried to send the hashes targeted for the web server to the DC.

2) With a proper pass-through-authentication solution there is no
"hiccup bug" because the challenge is no longer specific to the
transport. If the transport get's closed while there are type-2
messages in-flight it doesn't matter. We just open a new transpo and
do the verify as usual.

3) The NetrSamLogon call is not a simple matter of compiling some IDL
with midlc like we do with many other DCERPC calls. There are special
integrity and confidentiality requirements that JCIFS currently does
not support. However there may be other alternative methods for
validating the NTLMv2 hashes. Heimdal's libntlm uses a krb5-digest
technique. I'm not sure how it works precisely but I have been ensured
that it does. It might be possible to do the same thing with Sun's
Kerberos impl (not using JGSS of course - you would have to use the
sun.* packages directly).

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/