[jcifs] NTLM HTTP Authentication and SMB Signing

[Eric]

Paul.Holaj at dekabank.de wrote:
> Hi,
> 
> we use a Struts based web application with IE 5.5 and NTLM HTTP
> Authentication filter via JCIFS 0.8.1. 
> Our Domain Controllers were updated to Win2003Server with SMB signing
> switched on. 
> When using our application against the new DC, we get an "access denied"
> error if whe authenticate 
> more than one user (1st user succeeds, next users get 'access denied'
> error in DC response).
> 
> In the JCIFS CHANGES.TXT file I found the following passages concerning
> SMB signing:
> 
> (jcifs-0.8.0b1.)
> ...
> Only  SMBs  that  follow  authentication  need to be actually signed if
> SMB
> signing  is  enabled.  ...  However because the  NTLM  HTTP  Filter
> does  
> not send additional SMBs, signing will never actually  occur. ...
> 
> (jcifs-0.7.13)
> JCIFS  now  supports SMB signing. ...  Signing does not work with 
> NTLM HTTP authentication because  the  original  password  hashes  are  
> required to generate the MAC signing  key. ...
> 

I don't currently have an environment where I could verify this, but 
here's a scenario that might explain the observed behavior:

The first user completes the NTLM handshake on the back end and gets 
authenticated.  The server initiates signing with the session setup 
response.  We don't verify the signature from the server (since we don't 
really care, and we don't have the MAC key to actually verify it 
anyways).  The user is authenticated and goes on his merry way.

Now user number 2 comes along.  We have the challenge from the negotiate 
response already, so we send that in the Type 2.  The user sends the 
Type 3, and we try to do a session setup over the existing connection. 
However, signing has been setup on that connection already, using the 
first user's credentials.  We don't have the means to successfully 
calculate the signature for the session setup request, so the server 
sends back an error.

I can think of a couple fixes for this (if this is indeed what is 
occurring), neither of which are really all that great:

1) Don't reuse the SMB connection (i.e., do one-to-one with sessions and 
connections to the DC).  This would allow each incoming HTTP connection 
to set up a new connection with the DC, each of which would get a new 
challenge and set up signing fresh.  I think there's a config option for 
that; Mike might know off the top of his head.  I'd test this first, and 
see if it remediates the issue.

2) An ugly hack to do the initial session setup using an account with 
known credentials (i.e., authenticate with a dummy account to set up 
signing over the connection, then reuse the connection for real 
authentications later).  This is really kludgy though.

If you've got a packet capture, it would be helpful to verify this is 
what's happening.

Eric