[jcifs] redux: authentication only?

[Larry S. Bartz]

Michael B. Allen wrote:

>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).
>

It might have worked with Mozilla, using the NTLM Authorization
Proxy Server (NTLMAPS). See:

http://freshmeat.net/releases/64676/

I run an instance of NTLMAPS on my Linux desktop, point my
Konqueror at it, and enjoy the same NT authentication Free Lunch
as the IE users. I'm running the 0.97 version of NTLMAPS under
Python 2.1.


>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;
>    }
>


That's just the feedback I was looking for. I noticed that
SmbAuthException had been added to jCIFS since the previous
"authentication only" thread, so I wondered whether it could be
leveraged in this case.


>
>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.
>


If I go ahead and logoff where you've commented that out, does
that nullify the transport and session caching? I'm thinking perhaps
my app shouldn't gobble resources of the NT systems against which
I'm authenticating. I have to be a good (unobtrusive) neighbor of
the NT systems, or their admins will freak out.


>
>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.
>


I don't plan to keep and hold an NT session concurrently with my own
app's session. My app will just hit the NT resource to authenticate, let it
go, then hit it again "fresh" when my app server requires re-authentication.


>
>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
>above.
>

I'll do it just like that. Thanks.

-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lsbartz at parnelli.indy.cr.irs.gov     | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|