[jcifs] NTLMv2 / Alternative?

[Michael B Allen]

nospam.rwp at dsl.pipex.com said:
>
> Errrm, this argument maybe partially redundant now, by the looks of it
> recent versions
> may have some NTLMv2 support, however the docs aren't clear how much, so

We support LMv2 which should permit the client to operate in NTLMv2
environments. But there has been very little feedback about using it and I
believe there are problems. In particular I don't believe cross domain
authentication works.

> One thing that does disturb me though, is that jCIFS properties are still
> global properties,
> therefore it would appear to be impossible to reliably support different
> server
> configurations and associated connections at the same time.

JCIFS properties are supposed to be used only for things that static. In
fact ALL properties are static final internally so once you load a class
they're set. You should not try to change things are runtime. If you must
have separate environments (e.g. change the network interface properties)
then use a separate ClassLoader.

>  IMHO it would
> be better if
> this was the case:
>
> 1. the Config class was fleshed out with all the properties and bean
> setters and getters
> and given a getInstance() method, to get a copy of the global properties.
>
> 2. the connection classes SmbFile, SmbFileInputStream,
> SmbFileOutputStream,
> SmbNamedPipe and SmbRandomAccessFile gained extra constructors which
> accepted
> a Config object, so that each connection could use a different client
> behaviour.

This will never happen. It would be horribly inefficient to lookup
properties like that at runtime.

> If these features were implemented I could open a connection to a local
> LAN server, then
> open a different connection to a remote modem connected LAN server * and
> talk to each
> from a different IP binding e.g. I could use a machine as file copying
> bridge between the
> two networks for remote control support applications.
>
> * I could hunt for the modem IP binding address for just the modem jCIFS
> connection(s),
> but use a different local IP binding address for all the local LAN
> connections.

Kindof an exotic use-case.

Mike