We need to follow Microsoft's lead and require a fully encrypted connection for the NETLOGON Secure channel. This is likely to address recent reports of users obtaining session keys for NTLM authentication without further encryption protection (often at this point exploiting ZeroLogon), but if only signing is used then this would be visible routinely, using NetlogonValidationSamInfo4. Samba addressed that with: commit 5fe7085e3b18a7879dcb4ac0bc14a1b8ccabb268 Author: Stefan Metzmacher <metze@samba.org> Date: Fri Aug 7 13:33:17 2015 +0200 CVE-2016-2111: s4:rpc_server/netlogon: require DCERPC_AUTH_LEVEL_PRIVACY for validation level 6 BUG: https://bugzilla.samba.org/show_bug.cgi?id=11749 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Günther Deschner <gd@samba.org> We follow because it is safer to encrypt, and safer to follow Microsoft's lead so that future protocol developments that work on this assumption are also safe.
Here is the reference to how folks are abusing NetlogonValidationSamInfo4 to obtain session keys, the same would apply to sign-only secure channel: https://dirkjanm.io/a-different-way-of-abusing-zerologon/
Looking at the code and the risks, I think the least-impact way to allow an exception to the encryption requirement is I've described in the advisory on bug 15240. That is, just use the server schannel option, which now means encrypted schannel, with exempted clients allowed as per the work done for CVE-2020-1472(ZeroLogon). We don't want endless different smb.conf parameters, as each needs to be tested and we don't have much time, and I don't expect this will be needed very often.
It has been hinted at that NetApp might be a client the only supports signing of DCE/RPC, but that no windows client will sign-only by default. This may influence our feeling on exceptions, but I still prefer the model being suggested, as ZeroLogon is reasonably well mitigated in other ways. Speaking with Microsoft, I am advised the reason for encryption is that there are a lot of otherwise just RC4 protected or unprotected protocol elements, inbound and outbound, and this provided overall protection. (The NetlogonValidationSamInfo4 would be one specific example, if a Windows client were specifically configured not to encrypt).
Opening these bugs to the public, and the core issue that triggered this is now described in a BlackHat Europe Presentation by Tom Tervoort, Principal Security Specialist at Secura.
Removing the embargo tag. There is nothing particularly special in the information in this bug in terms of security, this is a future hardening as much as anything as far as we are aware.
This is fixed with the patches for CVE-22-38023 (bug #15240)