[Samba] NT_STATUS_WRONG_PASSWORD with multiple concurrent connects from same IP Address.

[Jeremy Allison]

On Wed, Apr 13, 2005 at 08:13:34AM +1000, Andrew Bartlett wrote:
> On Tue, 2005-04-12 at 12:56 -0400, David Girard wrote: 
> > OK, I have applied the "use spnego=no" and it seems to have resolved the problem...
> > 
> > Could you describe what this setting is doing?...I haven't been able
> > to find any reference to this setting other than your previous posts
> > telling people to use it...
> 
> Samba 3.0 introduced the ability to support 'extended security', where
> instead of the traditional NTLM challenge/response system being based on
> a challenge in the NegProt packet, we would install break out to a
> generalised authentications system, based on multiple round trips.
> 
> Session setup and authentication are fairly well described in CRH's
> book: http://www.ubiqx.org/cifs/SMB.html#SMB.8
> 
> When we are using extended security, there are multiple legs to the
> session setup part of this problem.  As the client sends the first of
> the 4 packets in this system ('negotiate'), we should enclose a vuid
> 'cookie' with the 'challenge'.  When the client returns with the 'auth'
> packet, we can line up the challenge we sent, and correctly finish the
> state machine.
> 
> If as in Samba3, we do not include a vuid (we send 0) to connect to the
> correct state machine, we would logically link a 'challenge' with an
> 'auth' to which there is no relation.  This then results in
> WRONG_PASSWORD, as the cryptography is wrong.
> 
> The RAW-CONTEXT test from Samba4 should demonstrate this nicely.
> 
> > I need to understand if there are security or performance implications
> > to this setting.
> 
> In particular, it will not be possible to use kerberos in any form to
> this server and NTLM2 will not be negotiated so clients will send the LM
> password on the wire..  Performance and reliability with the not-
> recommended security=server will also suffer.
> 
> The reason we have not fixed this in the past is that session setups are
> usually a 'rare' event (compared with others), and we just have not seen
> (or considered) this race in the past.

Yes that's true. I'm thinking of adding the vuid token behaviour into
Samba3 so we return something at the first sesssionsetup reply. However
we expect the subsequent packets to be continuous (we expect the next
packet to be the second part of the sessionsetup sequence, not a new
sessionsetup request). We could fix this with the out-of-order processing
we use for deferring opens, but it's nowhere near as transparent as it
is with Samba4.

Jeremy.