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
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."
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)
Created attachment 1261 [details] packet capture
should be fixed in 3.0.21.
sorry. I was misunderstood this as the client schannel implementation in Samba and not the server.
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.
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.
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.
The packet capture which is already attached is such an example.
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.
This should be fixed in the current code.