Why Windows SMB client ignores supported auth mechanisms in Negotiate Response?

Question

Scenario: SMB311 Server lists NTLM as the only supported auth mechanism in Negotiate response. Windows client ignores the fact and obtains the TGS for cifs/FQDN of the server and uses Kerberos authentication in Session Setup.
Error codes such as STATUS_NOT_SUPPORTED or STATUS_INVALID_PARAMETER do not cause Windows client to fall back to NTLM.
Note that deleting server's SPN for cifs/FQDN solves the issue.
But why Windows client ignores supported auth mechanism in Negotiate Response?

Answer 1

As documented in MS-SMB2 section 3.2.4.2.3, windows client ignores the Token received from the Server and starts with Kerberos.

MS-SPNG will also be updated accordingly.

MS-AUTHSOD section “3.3.2 Using the NTLM Protocol [MS-NLMP]” also mentioned that Kerberos will be tried first:

“This example describes using NTLM Protocol [MS-NLMP] to obtain client authentication to connect to an Server Message Block (SMB2) share. When Kerberos authentication fails or is not configured, the Authentication Client tries the NTLM protocol as the next preferred authentication protocol to prove the identity of the SMB2 client to the SMB2 server. This example describes the interactions between the SMB2 client and the SMB2 server when Kerberos is not configured or is unavailable.”

Regards,

Sreekanth Nadendla

Microsoft Windows Open Specifications