[jcifs] redux: authentication only?

Michael B. Allen miallen at eskimo.com
Fri May 10 05:14:55 EST 2002

On Thu, 09 May 2002 12:49:22 -0500
"Larry S. Bartz" <lsbartz at parnelli.indy.cr.irs.gov> wrote:

> I dug this out of the archives:
> http://lists.samba.org/pipermail/jcifs/2001-May/001221.html
> Do practicing users of jCIFS concur with this strategy for an
> "authentication only" use case? Or has some other strategy
> emerged in the meantime, perhaps as a result of further
> development of jCIFS?

I'm not really sure how practicing users of jCIFS will concur but I
know there are a few people who have tinkered with exactly this sort of
thing. Guys?

About alternatives, the ideal mechanism uses a NETLOGON DCE/RPC
call to a domain controller. We can't do that. We don't have DCE/RPC
functionality. Someone recently implemented IE's NTLM authentication used
by IIS and it's ilk but that's different (I never saw that code BTW,
oh well, guess it didn't work with Mozilla anyway). The best option is
probably a permutation of what is described in the link you cite. There
is now an SmbAuthException that might be used in some way though. If I
take a stab at this I'd probably try a static method for SmbFile like:

    public static boolean isAuthorized( String domain,
                                    String username,
                                    String passwd ) throws SmbException {
        try {
            NbtAddress a = NbtAddress.getByName( domain, 0x1c, null ); 
            SmbTransport t = SmbTransport.getSmbTransport( a, 139 );
            SmbSession s = t.getSmbSession( username, password, domain );
            s.sessionSetup( null, null ); 
            //s.logoff(); // manage this better?
        } catch( SmbAuthException sae ) { 
            return false;
        return true;

This will find a domain controller and open a session authenticating
the user in the process. Except, the jCIFS client caches SmbTransports
and for each SmbTransport it caches SmbSessions so if you have 5 domain
controllers and getByName returns one of the 5 at random, you may not
be taking advantage of that caching until you have more than 4 or 5
users connected (at work we have like 15 domain controllers for my
domain). You might cache the NbtAddresses returned by getByName and
try to reuse them so you reuse the same SmbTransport (to a limit of
course). But this would probably not make a big difference unless you
something like a hundred users.

Another thing I would do is jack up the jcifs.smb.client.soTimeout to like
10 minutes. By default, SmbSessions are closed after only 15 seconds if
there is no activity. Keep in mind this connection would have nothing to
do with other file server oriented transports. You'd be making a separate
SmbTransport for that (unless you're accessing shared directories on a
domain controller but you're not supposed to do that :~).

I might also try to manage the session a little better so that if it
times out and the SmbSession logs off the users session becomes invalid
and forces the user to re-authenticate.

The message you cite would be better if you want to have groups of users
with different access controls because you can just tweek the access
controls on the "peer" files. But if you want auth only try the code


May The Source be with you.

More information about the jcifs mailing list