[Samba] "Attempt to bind using schannel without successful serverauth2" in 3.0.20 logs

[Jeremy Allison]

On Sun, Sep 11, 2005 at 12:37:30AM -0400, Chris wrote:
> On Saturday 10 September 2005 03:55 pm, Jeremy Allison wrote:
> > On Sat, Sep 10, 2005 at 11:30:53AM -0400, Chris wrote:
> > > Samba logs show many of these:
> > >
> > > [2005/09/10 10:15:56, 0]
> > > rpc_server/srv_pipe.c:api_pipe_bind_req(981) Attempt to bind using
> > > schannel without successful serverauth2 [2005/09/10 10:26:04, 0]
> > > rpc_server/srv_pipe.c:api_pipe_bind_req(981) Attempt to bind using
> > > schannel without successful serverauth2 [2005/09/10 11:26:01, 0]
> > > rpc_server/srv_pipe.c:api_pipe_bind_req(981) Attempt to bind using
> > > schannel without successful serverauth2
> > >
> > > This is on a 3.0.20 (with patches) PDC.
> > >
> > > Anyhone know what can cause this message?
> > > Is it just informative or does something need to be fixed?
> >
> > Right now it's informative - I'd like to see the traffic
> > that is causing it though. Can you get me an ethereal trace
> > please ?
> 
> Jeremy,
> 
> Attached is an ethereal trace, I believe a few of the errors are in 
> there but I'm new to using the tool (actually was a tethereal caprture) 
> and there was little traffic going on at the time. Let me know if you 
> need anything else.

Very interesting capture, thanks. The interesting frames are
around frame 137. It's a new session setup between 192.168.1.8 and 192.168.1.4,
followed by a pipe open of \NETLOGON, followed by a schannel setup bind
request from what appears to be a completely TCP new connection set up
at frames 134-136 (SYN, SYN-ACK, ACK).

The previous TCP connection (between machines 192.168.1.8 and 192.168.1.4)
was dropped at frames 46 and 47 (the FIN and the FIN-ACK). The server
192.168.1.4 seems to be dropping the connection here after 60
seconds of inactivity, probably because the client has released all resources.

The client (having received the bind failure) then correctly re-sets
up with a auth2 request response negotiation. Looks like in the
Windows world the client expects the schannel state setup to be
persistent per-machine across connections. It doesn't seem to
hurt the client if it isn't though, as it just re-authenticates
the connection.

I'm starting to think the correct fix is just to raise the debug
level of the message in smbd so that people don't get worried by
it - it seems to be part of normal operation and I really don't
want to have to create a persistent cache across smbd's for this
state :-).

The other interesting test would be to set the server deadtime to
zero (the default) - what do you have it set to in your smb.conf ?

Thanks,

	Jeremy.