I reproduced the same behavior on Ubuntu 24.04 LTS and Ubuntu 26.04 LTS.

Test system 1:
- Ubuntu version: 26.04 LTS
- Samba version: 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.1
- Role: AD domain member
- security = ADS
- client-software = winbind
- ntlm auth = disabled

Test system 2:
- Ubuntu version: 24.04 LTS
- Samba version: 4.19.5-Ubuntu / 2:4.19.5+dfsg-4ubuntu9.6
- Role: AD domain member
- security = ADS
- client-software = winbind
- ntlm auth = disabled

Relevant smb.conf settings on both systems:

[global]
   security = ADS
   realm = MYREALM.LOCAL
   workgroup = MYREALM
   kerberos method = secrets and keytab
   dedicated keytab file = /etc/krb5.keytab
   winbind use default domain = no
   winbind refresh tickets = yes
   ntlm auth = disabled
   server signing = mandatory

Kerberos access works correctly on both systems.
The client receives the expected CIFS Kerberos ticket, for example:

    cifs/smb-test24.myrealm.local@MYREALM.LOCAL

Example positive Kerberos test:

    kdestroy || true
    kinit testuser@MYREALM.LOCAL

    smbclient --use-kerberos=required //smb-test24.myrealm.local/smbshare01 \
      -c 'pwd; ls'

    klist

This works as expected.

However, when I explicitly force non-Kerberos authentication on the client side, NTLMv2 still succeeds, although "ntlm auth = disabled" is set:

    kdestroy || true

    smbclient --use-kerberos=off //smb-test24.myrealm.local/smbshare01 \
      -U 'MYREALM\testuser' \
      -c 'ls'

Unexpected result:
The command successfully lists the share content.

Example output:

    Password for [MYREALM\testuser]:
      .                                   D        0  Tue Jun 16 16:04:21 2026
      ..                                  D        0  Tue Jun 16 16:04:21 2026

            20463184 blocks of size 1024. 14141156 blocks available

The Samba auth audit log confirms that NTLMv2 / NTLMSSP was used and accepted:

    Auth: [SMB2,(null)] user [MYREALM\testuser] at [Wed, 17 Jun 2026 11:25:00.658518 CEST] with [NTLMv2] status [NT_STATUS_OK] workstation [SMB-TEST24] remote host [ipv4:127.0.0.1:36540] became [MYREALM\testuser] [S-1-5-21-773280108-3970102928-2324781170-22689]. local host [ipv4:127.0.1.1:445]

    Successful AuthZ: [SMB2,NTLMSSP] user [MYREALM\testuser] [S-1-5-21-773280108-3970102928-2324781170-22689] at [Wed, 17 Jun 2026 11:25:00.661441 CEST] Remote host [ipv4:127.0.0.1:36540] local host [ipv4:127.0.1.1:445]

    Auth: [winbind,NTLM_AUTH, smbd, 35493] user [MYREALM]\[testuser] at [Wed, 17 Jun 2026 11:25:00.656296 CEST] with [NTLMv2] status [NT_STATUS_OK] workstation [SMB-TEST24] remote host [unix:] became [MYREALM]\[testuser] [S-1-5-21-773280108-3970102928-2324781170-22689]. local host [unix:]

So the behavior is reproducible on both:

- Ubuntu 26.04 LTS / Samba 4.23.6-Ubuntu
- Ubuntu 24.04 LTS / Samba 4.19.5-Ubuntu

In both cases Kerberos works correctly, but "ntlm auth = disabled" does not prevent SMB NTLMv2/NTLMSSP authentication through winbind/NTLM_AUTH.

My expectation was:
If "ntlm auth = disabled" is configured, then the following command should fail:

    smbclient --use-kerberos=off //server/share -U 'DOMAIN\user' -c 'ls'

Instead, the command succeeds and Samba logs NTLMv2 with NT_STATUS_OK.

Can you please clarify whether this is expected behavior for an ADS domain member using winbind, or whether "ntlm auth = disabled" should reject this NTLMv2/NTLMSSP authentication path?

I tested Ubuntu packages, so I am not sure whether this is upstream Samba behavior, Ubuntu packaging behavior, or a configuration issue on my side.