[jcifs] 1.3.x filter authentication problem

Michael B Allen ioplex at gmail.com
Wed Feb 11 16:29:58 GMT 2009

On Wed, Feb 11, 2009 at 8:02 AM, Hannes B. <raintrain at gmx.at> wrote:
> per Thread:
> Not the best solution: Tomcat with two filters with different jcifs configurations. The filters have the same thread!

First, the Filter is being removed from JCIFS. It seems I cannot state
that enough. I just want to make that clear if you didn't see any of
the other posts about this the last few months or the recently updated
FAQ and NTLM HTTP Filter documentation.

However, it should be very possible to use JCIFS with two different
configurations within a web application server like Tomcat. In this
case, the Map of non-default properties would be set on the Thread
through a callback like PrivilegedExceptionAction in


In fact, if the Subject is inherited by new Threads, it might be nice
to actually store the map in the Subject as a credential (or as part
of the credential used by JCIFS) so that the configuration is
inherited. But I would have to test this. I'm not sure if Subjects are
inherited. This is a JCIFS 2.0 thing. I can't think about it now.
Maybe in a year or two I'll start to think about it.

> It would be great if the jcifs library allows instance oriented configurations.

Note that considering that all JCIFS properties are semantically
global and static I don't think it's that "great". Meaning between two
instances of JCIFS, there should be no properties that would really
need to be different. The only reason this came up is because of the
issue with the HTTP Filter not supporting NTLMv2. But again, that is
due to a fundamental problem with how the Filter works and therefore
it is of no concern since it is being removed.


> -------- Original-Nachricht --------
>> Datum: Tue, 10 Feb 2009 08:30:12 -0000
>> Von: John.Baker at barclayscapital.com
>> An: jcifs at lists.samba.org
>> Betreff: RE: [jcifs] 1.3.x filter authentication problem
>> My question was unrelated to the filter - it was a general question
>> about configuration of jcifs.
>> I don't understand why there would be any threading issues with a
>> separate Properties object per instance of a jcifs object, unless there
>> are more statics lurking in the code.
>> So, the answer is to be able to pass Properties objects into the
>> constructors of key objects (like SmbFile).  Or bind configurations to
>> Threads (less nice but entirely do-able).
>> And then the HttpFilter can remain in Jcifs, and perhaps we can put some
>> work into new filters (for Kerberos, given they seem to be floating
>> around as ext packages).
>> > -----Original Message-----
>> > From:
>> > jcifs-bounces+john.baker=barclayscapital.com at lists.samba.org
>> > [mailto:jcifs-bounces+john.baker=barclayscapital.com at lists.sam
>> > ba.org] On Behalf Of Michael B Allen
>> > Sent: 09 February 2009 18:15
>> > To: Caldarale, Charles R
>> > Cc: jcifs at lists.samba.org
>> > Subject: Re: [jcifs] 1.3.x filter authentication problem
>> >
>> > On Mon, Feb 9, 2009 at 11:36 AM, Caldarale, Charles R
>> > <Chuck.Caldarale at unisys.com> wrote:
>> > >> Subject: RE: [jcifs] 1.3.x filter authentication problem
>> > >
>> > > (Sorry for the previous message - fumble fingers on the keyboard.)
>> > >
>> > >> How does one create two instances of Jcifs, with different
>> > >> configurations, within one VM?
>> > >
>> > > You will need a separate classloader for each instance of
>> > jCIFS.  If you're running inside Tomcat, each webapp uses a
>> > separate classloader already; just put the jCIFS jar in the
>> > WEB-INF/lib directory of each webapp.  Do not put the jar in
>> > Tomcat's shared directory.
>> >
>> > Note that doesn't really help with the static properties
>> > issue since the only way to set some properties reliably is
>> > with through commandline using -Djcifs.properties=file.prp.
>> >
>> > Just like the Windows CIFS client and smbclient, the
>> > configuration in JCIFS is global and static. For example, on
>> > Windows the LmCompatibilityLevel is in the registry and
>> > extended security is basically hard coded into the client.
>> > These are not things that can be changed at runtime. Meaning
>> > they're global and static.
>> >
>> > The heart of the problem in this thread is that servlet
>> > containers set things at runtime using init-params but the
>> > Filter doesn't support
>> > NTLMv2 so the new 1.3 default values of
>> > jcifs.smb.client.useExtendedSecurity=true and
>> > jcifs.smb.lmCompatibility=3 are wrong for the Filter.
>> > Strangely I would think this should still work since the
>> > properties aren't actually set the JCIFS classes are first
>> > loaded. But it looks like Tomcat at least is maybe loading
>> > some JCIFS classes before it actually reads the init-params
>> > so some init-params are basically ignored.
>> >
>> > Fortunately this issue is largely specific to the combination
>> > of the Filter not supporting NTLMv2 and how some servlet
>> > containers load classes. So none of this really matters much
>> > since the Filter is effectively deprecated.
>> >
>> > But it doesn't mean that we can't make the JCIFS
>> > configuration more flexible in the future. It would be nice
>> > to be able to supply different configurations. But if the
>> > config is not global and static the issue is "where do you
>> > put it?". My thought is that we can hang it on the current
>> > thread or stick it in the JAAS Subject so that it get's
>> > inherited (are Subjects inherited when creating new
>> > Threads?). But of course that's a fairly radical change and
>> > requires touching code in many places so it is not going to
>> > happen soon.
>> >
>> > Note that some people have suggested that this could be
>> > "fixed" by simply making the properties non-static. That
>> > would not be thread-safe. Meaning thread 1 could set property
>> > a, then thread 2 could set property a and then thread 1 could
>> > act on property a with the wrong value and get the wrong
>> > result or a mysterious error.
>> >
>> > In hindsight I should have removed the Filter in 1.3 so that
>> > people would be forced to use 1.2 which has exactly the same
>> > Filter code with the right default values for
>> > useExtendedSecurity and lmCompatibility.
>> >
>> > Mike
>> >
>> > --
>> > Michael B Allen
>> > Java Active Directory Integration
>> > http://www.ioplex.com/
>> >
>> _______________________________________________
>> This e-mail may contain information that is confidential, privileged or
>> otherwise protected from disclosure. If you are not an intended recipient of
>> this e-mail, do not duplicate or redistribute it by any means. Please
>> delete it and any attachments and notify the sender that you have received it in
>> error. Unless specifically indicated, this e-mail is not an offer to buy
>> or sell or a solicitation to buy or sell any securities, investment products
>> or other financial product or service, an official confirmation of any
>> transaction, or an official statement of Barclays. Any views or opinions
>> presented are solely those of the author and do not necessarily represent those
>> of Barclays. This e-mail is subject to terms available at the following
>> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent
>> to the foregoing.  Barclays Capital is the investment banking division of
>> Barclays Bank PLC, a company registered in England (number 1026167) with its
>> registered office at 1 Churchill Place, London, E14 5HP.  This email may
>> relate to or be sent from other members of the Barclays Group.
>> _______________________________________________

Michael B Allen
Java Active Directory Integration

More information about the jcifs mailing list