[jcifs] jcifs-1.2.9 with SSN_LIMIT=1

[Michael B Allen]

On Wed, 25 Oct 2006 10:50:06 +0200
"Waldheim, Frank" <F.Waldheim at ing-diba.de> wrote:

> hi there,
> 
> we encounter a problem with jcifs-1.2.9 (without kerberos)
> accessing our windows 2003 server DCs (which require signing).
> 
> we sucessfully used jcifs with preauthentication but had a problem
> with passwords that where (or have to be) changed. 
> 
> thats why we tried the other suggested solution with SSN_LIMIT=1.
> 
> In this case even the first access fails:
>    NtlmHttpFilter: DOMCOMPANY\userid: 0xC0000005:
> jcifs.smb.SmbAuthException: Invalid access to memory location.
> 
> we investigated three issues concerning the SSN_LIMIT=1 problem
> 
> 1) SSN_LIMIT = 1 - getTransport
> 
> as already stated one year ago in:
> http://thread.gmane.org/gmane.network.samba.java/4989/focus=4989
> the mechanism of creating transports and finding them again seems to be
> broken.
> therefore a new transport is created for logon and the DC is not happy.
> 
> like stated in the patch above one can fix the logic in
> SmbTransport.java to find the 
> instance in CONNECTIONS even if SSN_LIMIT=1 by removing the first if
> clause.

I'm not sure I understand this post but the patch mentioned in that post
was applied.

Also, a new transport is *supposed* to be created for each new session
if SSN_LIMIT == 1.

SSN_LIMIT basically means "the maximum number of sessions permitted on
a transport" and that any additional sessions over that limit will use
a new transport. Therefore if SSN_LIMIT == 1 then one transport will be
created for every session.

Note: If this sounds like a horrible waste of resources it is and as
such it's not recommended.

Are you saying you found a bug? If so, can you describe it in simpler
terms? I'm not sure I'm following all the logic. What is the sequence
of events that cause a failure and what is the failure?

Mike

> so the first part of our proposal is
>   - remove the first if() - if( SSN_LIMIT != 1 )
>   
>   
> 2) SSN_LIMIT=1 and PreAuthentication - getTransport
> 
> If preauthentication is switched on (and the SSN_LIMIT ist still set to
> 1) 
> there will never be a Transport  without a session. And therefore the
> condition:
> 		conn.sessions.size() < SSN_LIMIT
> can NOT evaluate to true and a new Transport is created.
> 
> therefore:
>   - modify the test to: conn.sessions.size() <= SSN_LIMIT 
>     (which is incorrect for a config without preauth)
>   - (make SMBTransport aware of the current configuration - ugly)
> 
> 
> 3) SSN_LIMIT=1 - matches() 
> 
> when set SSN_LIMIT=1 (preauthentication turned OFF) we have
> problems with parallel client-requests.
> The basic problem seems to be: How to reuse the correct transport?
> How is a request matched to the correct transport?
> 
> 
> as shown in the sequence diagram (http://www.javachannel.de/ntlm.png)
> the communication between the NTLMFilter
> Servlet and the SMBSession is based on two actions:
> 
>  - getChallengeForDomain 
>  - doLogon 
> 
> which both require the very same transport.
> in our scope and from our understanding that means: 
> 1 Servlet thread uses 1 Transport (no reuse of transports!)
> 
> because of the fact that none of the fields used for matches() in
> SmbTransport is updated after doConnect() and the fact that every
> subsequent request for a transport by SMBSession only gives the DC
> as a key (and it has no other chance according to the current interface)
> the UniAddress is the ONLY way for the matches() method in SMBTransport 
> to find the right transport for this request.
> 
> even if all this works well we cannot see how the mechanism in matches()
> can find the RIGHT transport.
> say that the algorithm in getChallengeForDomain decided to route
> two requests to the same DC within a very short time ( one can 
> assume a stress-test situation here which will cause the round-robin
> to select the same DC within seconds even with 8 DCs configured) 
> then there will be two transports with a session to the same DC in the
> CONNECTIONS list 
> and by design the first one will be returned which apparently can be the
> wrong one.
> 
> this is a far more difficult issue as we cannot see a simple fix here.
> we propose a new method in SMBSession designed for Authentication in a
> 'working-on-behalf' environment with respect to the handshake
> of NTLM. 
> 
> that means we have to find a way to ensure some things:
>  - clearly associate a calling thread with one DC/session/transport
> triple
>  - provide a well defined key for the caller to reselect such a triple
>  - by design the ntlm authentification process has to hold a state 
>    between getChallenge and logon which has to be reflected on both
> sides;
>    the weblayer AND the jcifs-lib.
> 
> 
> for a start we implemented two alternative solutions to bring matches()
> back in business:
> 
> 1) use the encryption key which is sent back to the client during
> getChallengeForDomain as
>    a key to find the associated transport in matches().
>    reset the values in doDisconnect() to 'free' the transport for reuse.
> 
> 2) update the localport variable after doConnect() in negotiate() to
> make matches() work.
>    actively remove the Transport from the CONNECTIONS list.
> 	 
> 
> both solutions are awfully ugly. 
>    as a result the SSN_LIMIT  is completely broken, because the
> transport can never be used
>    again  by another session because nobody knows the key (neither the
> encryption key nor the localPort)
>    so a SSN_LIMIT>1 will not show another behaviour than SSN_LIMIT=1
> 
> 
> if you really read through this lengthly mail we ask you to help us to
> find a way 
> of how we can implement a fallback solution in a situation where
> preauthentication is not possible.
> 
> hope to hear from you soon
> 
> -fw
> 
> 
> 
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
> die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>  
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail
> in error) please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden.


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