Bug 2694 - netlogon schannel key not preserved across multiple smb sessions
netlogon schannel key not preserved across multiple smb sessions
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control
3.0.10
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-09 12:48 UTC by Neal Groothuis
Modified: 2006-04-08 23:12 UTC (History)
0 users

See Also:


Attachments
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
problem:
http://lists.samba.org/archive/samba-technical/2003-November/032811.html
http://lists.samba.org/archive/samba-technical/2000-January/006586.html
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.
NT Create \NETLOGON.
DCE-RPC bind.
NetrServerReqChallenge.
NetrServerAuthenticate3 (fails).
NetrServerAuthenticate2.
Session setup.
Tree connect.
NT Create: \lsarpc.
DCE-RPC bind.
LsarOpenPolicy2.
LsarEnumerateTrustedDomains.
LsarClose.
Close.
Logoff.
Tree disconnect.
TCP session to port 139 closed.
TCP session to port 139 opened.
Negotiate protocol. 
Session setup.
Tree connect.
NT Create: \NETLOGON.
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
processing."
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 2005-09-29 07:52:35 UTC
should be fixed in 3.0.21.
Comment 5 Gerald (Jerry) Carter 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 ?
Jeremy.
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.
Thanks,
Jeremy.
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.
Jeremy.
Comment 11 Gerald (Jerry) Carter 2006-04-08 23:12:22 UTC
This should be fixed in the current code.