samba - Oct 2024 - Could not find a suitable mechtype in NEG_TOKEN_INIT error in libsmbclient 4.19.4

Hi,

I have a libsmbclient application that uses username and passwords to
connect to a windows share to upload/download files. The client machine is
a Linux host and is not part of the domain. There is no kerberos involved.
I am currently using Alma linux 9.4, with samba version "4.19.4". The
package itself might have some patches from Alama/Fedora/redhat.
Windows is "Windows server 2016, version 1607 (OS Build 14393.4104) . I
have the below smb.conf.

# cat /etc/samba/smb.conf
# See smb.conf.example for a more detailed config file or
# read the smb.conf manpage.
# Run 'testparm' to verify the config is correct after
# you modified it.

[global]
        workgroup = SAMBA
        security = user
        passdb backend = tdbsam
        client max protocol = SMB3

  The client fails to connect to the server with the error "22: Invalid
argument". Looking through the debug logs, I find "Could not find a
suitable mechtype in NEG_TOKEN_INIT". Looking at the logs from earlier
working version it seems that "ntlmssp" submechanism is not found.

Using netbios name PS.
Using workgroup SAMBA.
parsed path: fname='smb://10.213.83.50/cifsshare'
server='10.213.83.50'
share='cifsshare' path='' options=''
SMBC_check_options(): server='10.213.83.50' share='cifsshare'
path=''
options=''
SMBC_server: server_n=[10.213.83.50] server=[10.213.83.50]
 -> server_n=[10.213.83.50] server=[10.213.83.50]
Connecting to 10.213.83.50 at port 445
socket options: SO_KEEPALIVE=0, SO_REUSEADDR=0, SO_BROADCAST=0,
TCP_NODELAY=1, TCP_KEEPCNT=9, TCP_KEEPIDLE=7200, TCP_KEEPINTVL=75,
IPTOS_LOWDELAY=0, IPTOS_THROUGHPUT=0, SO_REUSEPORT=0, SO_SNDBUF=46080,
SO_RCVBUF=87380, SO_SNDLOWAT=1, SO_RCVLOWAT=1, SO_SNDTIMEO=0,
SO_RCVTIMEO=0, TCP_QUICKACK=1, TCP_DEFER_ACCEPT=0, TCP_USER_TIMEOUT=0
cli_set_timeout: Changing connection timeout for server '10.213.83.50'
from
20000 (ms) to 20000 (ms).
cli_session_setup_spnego_send: Connect to 10.213.83.50 as
Administrator at SAMBA using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'ncalrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
Starting GENSEC mechanism spnego
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype
in NEG_TOKEN_INIT


I have turned off kerberos authentication
with "smbc_setOptionUseKerberos(nc, 0);"  Going through the release
notes,
I was not able to find anything else that could be causing this.
I was earlier using CentOS7 with samba version "4.10.16".
CentOS/Redhat has
more patches on top of that. With that version, everything works fine for
the same windows share.

Using workgroup SAMBA.
parsed path: fname='smb://10.213.83.50/cifsshare'
server='10.213.83.50'
share='cifsshare' path='' options=''
SMBC_check_options(): server='10.213.83.50' share='cifsshare'
path=''
options=''
SMBC_server: server_n=[10.213.83.50] server=[10.213.83.50]
 -> server_n=[10.213.83.50] server=[10.213.83.50]
Connecting to 10.213.83.50 at port 445
Socket options:
        SO_KEEPALIVE = 0
        SO_REUSEADDR = 0
        SO_BROADCAST = 0
        TCP_NODELAY = 1
        TCP_KEEPCNT = 9
        TCP_KEEPIDLE = 7200
        TCP_KEEPINTVL = 75
        IPTOS_LOWDELAY = 0
        IPTOS_THROUGHPUT = 0
        SO_REUSEPORT = 0
        SO_SNDBUF = 46080
        SO_RCVBUF = 174760
        SO_SNDLOWAT = 1
        SO_RCVLOWAT = 1
        SO_SNDTIMEO = 0
        SO_RCVTIMEO = 0
        TCP_QUICKACK = 1
        TCP_DEFER_ACCEPT = 0
cli_session_setup_spnego_send: Connect to 10.213.83.50 as
Administrator at SAMBA using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism ntlmssp
     negotiate: struct NEGOTIATE_MESSAGE
...

Can I get some help please in finding out what might be going on?

Regards,
Manu
ReplyForward

On Thu, 24 Oct 2024 14:22:05 +0530
Manu Shamanna via samba <samba at lists.samba.org> wrote:
> Hi,
> 
> I have a libsmbclient application that uses username and passwords to
> connect to a windows share to upload/download files. The client
> machine is a Linux host and is not part of the domain. There is no
> kerberos involved. I am currently using Alma linux 9.4, with samba
> version "4.19.4". The package itself might have some patches from
> Alama/Fedora/redhat. Windows is "Windows server 2016, version 1607
> (OS Build 14393.4104) . I have the below smb.conf.
> 
> # cat /etc/samba/smb.conf
> # See smb.conf.example for a more detailed config file or
> # read the smb.conf manpage.
> # Run 'testparm' to verify the config is correct after
> # you modified it.
> 
> [global]
>         workgroup = SAMBA
>         security = user
>         passdb backend = tdbsam
>         client max protocol = SMB3
> 
I think this all down to Samba raising the default lowest SMB protocol
to '2' at 4.11.0

As this is the client, libsmbclient will read /etc/samba/smb.conf and
anything found there will override its defaults which on 4.10.x will
have been these:

client ipc max protocol = SMB3_11
client ipc min protocol = NT1
client max protocol = SMB3_11
client min protocol = CORE

Now on 4.19.x they will be these:

client ipc max protocol = SMB3_11
client ipc min protocol = SMB2_02
client max protocol = SMB3_11
client min protocol = SMB2_02

So, setting 'client max protocol = SMB3' will have little effect.

I 'think' it is probable that your code is sending a SMBv1 request to
the Windows server and the server has SMBv1 turned off by default.

Rowland