The Samba-Bugzilla – Bug 2694
netlogon schannel key not preserved across multiple smb sessions
Last modified: 2006-04-08 23:12:22 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
What I see in a packet capture:
TCP session opened to port 139.
NT Create \NETLOGON.
NT Create: \lsarpc.
TCP session to port 139 closed.
TCP session to port 139 opened.
NT Create: \NETLOGON.
NetrSamLogon, which is met with a fault (no such operation.)
Error message seen in samba logs is "process_request_pdu: failed to do schannel
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]
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 ?
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.
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.
This should be fixed in the current code.