Bug 2694 - netlogon schannel key not preserved across multiple smb sessions
Summary: netlogon schannel key not preserved across multiple smb sessions
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.10
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-05-09 12:48 UTC by Neal Groothuis
Modified: 2006-04-08 23:12 UTC (History)
0 users

See Also:

packet capture (5.21 KB, application/octet-stream)
2005-06-06 14:33 UTC, Neal Groothuis
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neal Groothuis 2005-05-09 12:48:23 UTC
If a Windows domain member closes an SMB connection Samba DC, it will attempt to
reconnect, but will not reauthenticate using
NetrServerReqChallenge/NetrServerAuthenticate2.  It will instead try to use the
old session key for the NETLOGON schannel.  Samba does not appear to maintain
this between connections, which results in "domain not available" errors on the
Windows domain member that can only be resolved by rebooting.

I think the following mailing list posts may be referring to the cause of this
Comment 1 Neal Groothuis 2005-05-09 13:00:36 UTC
What I see in a packet capture:

TCP session opened to port 139.
Negotate protocol.
Session setup.
Tree connect.
DCE-RPC bind.
NetrServerAuthenticate3 (fails).
Session setup.
Tree connect.
NT Create: \lsarpc.
DCE-RPC bind.
Tree disconnect.
TCP session to port 139 closed.
TCP session to port 139 opened.
Negotiate protocol. 
Session setup.
Tree connect.
DCE-RPC bind.
NetrSamLogon, which is met with a fault (no such operation.)  

Error message seen in samba logs is "process_request_pdu:  failed to do schannel
Comment 2 Andrew Bartlett 2005-06-05 16:17:02 UTC
Just to save jra some pain later...

That is not a packet capture.  Please return with a .pcap file.

tcpdump -i eth0 -n -s 1500 -w /tmp/sniff.pcap

In this case, Samba4 gets this right, so we know the thoery about how to fix it.
(But you can play with Samba4 to confirm if you want.  Advice and assistance
available on irc.freenode.net #samba-technical)
Comment 3 Neal Groothuis 2005-06-06 14:33:31 UTC
Created attachment 1261 [details]
packet capture
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-09-29 07:52:35 UTC
should be fixed in 3.0.21.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-09-29 08:10:41 UTC
sorry.  I was misunderstood this as the client schannel implementation in Samba
and not the server.
Comment 6 Jeremy Allison 2005-09-29 08:24:13 UTC
Andrew Bartlett, I didn't think Samba4 stored the schannel key between multiple
smbd daemons ? Where do you store it ? I've known about this for a while, it
isn't a critical bug as after getting the rpc fault the client will re-establish
the key. It's more of an annoying message. It would need to be stored per client
if we were to store it.
Do you have any evidence of a client actually failing here and not reconnecting
successfully, or is it just an irritating message in the log ?
Comment 7 Neal Groothuis 2005-09-29 09:15:46 UTC
IAN Andrew Bartlett; however, the reason that I submitted this in the first
place was because our Windows XP Pro machines were not renegotiating the session
key.  They assume when they see the RPC fault that the domain controller is
unavailable, which leads to "domain unavailable" and thus no one can log in.
Comment 8 Jeremy Allison 2005-09-29 09:23:00 UTC
Ok we'll target this to be fixed for 3.0.21. Shouldn't be a difficult fix, just
a little fiddly (have to store in a new tdb in private/). Can you send me an
ethereal trace of WinXP clients failing to re-negotiate the key so I have an
example of this.
Comment 9 Neal Groothuis 2005-09-29 11:59:22 UTC
The packet capture which is already attached is such an example. 
Comment 10 Jeremy Allison 2005-09-29 12:19:11 UTC
Ok, fair enough - but I'd appreciate a little more of the trace - some frames
before and after the failed logon to see what the client is doing after the RPC
fault, and before the sessionsetup. Every time I try this here the client
retries after the fault, but we'll fix this with a persistent store for 3.0.21.
Comment 11 Gerald (Jerry) Carter (dead mail address) 2006-04-08 23:12:22 UTC
This should be fixed in the current code.