I have researched the bug 12997(CVE-2017-12150) and found
there also is a code path which ignores smb signing requirement
and falls back to anonymous.
SMBC_server_internal uses cli_session_setup_anon when login fails.
It sees NO_AUTO_ANONYMOUS_LOGON option flag but ignores for example,
client signing = mandatory in smb.conf. Is this by design?
Don't we need to see smbXcli_conn_signing_mandatory also?
Sample session on Fedora 25 follows.
$ smbd --version
# smbclient does not fall back to anonymous due to fix on do_connect.
$ smbclient -U kanda //kandaw2016/temp
Enter kanda's password:
session setup failed: NT_STATUS_LOGON_FAILURE
# testread uses SMBC_server via smbc_open.
smbc_open: File exists
Packet monitor shows that after ntlm session setup error, libsmbclient
attempts anonymous login and succeeds. It then tries tree connect to "temp"
and gets STATUS_ACCESS_DENIED from Windows server 2016.
It has restrictnullsessaccess=1 and maybe that's the cause of the error.
The point is, libsmbclient sometimes falls back to anonymous session
and messages go unsigned on wire, unless the caller sets NO_AUTO_ANONYMOUS_LOGON option.