Microsoft
MicrosoftHi gabrielluizbh - Are you referring to using SMB as a transport protocol for Kerberos or using Kerberos for authentication of SMB?
NTLM primarily uses SMB as a transport protocol. That explains why enabling SMB signing is a great mitigation for NTLM relay attacks. Kerberos on the other hand will use TCP or UDP. I am not aware of a way to configure it to use SMB for transport.
A Service Principal Name (SPN) is required to request a Kerberos ticket. When Kerberos is used for SMB, the TSG request will typically be for CIFS/ServerName. By default a Windows server will have a HOST/Servername SPN but not a CIFS/ServerName SPN. Fortunately, the KDC will automatically map the CIFS request to HOST and issue a Kerberos service ticket CIFS/ServerName.
If you are having issues with NTLM fallback for SMB consider the following:
1. By default there is no SPN for an IP address so accessing a file share using an IP address is guaranteed to fallback to NTLM. However, it is now possible to add SPN for IP addresses (Setspn -s host/192.168.1.1 server01).
2. Using an alias name without proper configuration can result in NTLM fallback (assuming strict name checking doesn't completely block the connection). For more on that see Graeme's blog on that topic.
3. Network connectivity requirements to domain controllers is different for NTLM vs Kerberos. With NTLM, the client connects to the server, the server issues a challenge, the client returns a response to the challenge, the server sends the response a DC for validation. If the user is from another domain\forest, the authentication is passed through the trust path until it reaches a DC from the user's domain. With Kerberos, the user requests a ticket from a DC of the server's domain. If the user is from another domain\forest, it is necessary to first get a referral ticket from a DCs in its own domain. All of that to say - NTLM does not require the users to have direct network connectivity to domain controllers but Kerberos does so network connectivity can cause NTLM failback.
4. Incompatible Kerberos encryption types can result in NTLM working when Kerberos doesn't. For more on that see my blog on Kerberos Encryption selection.
5. Windows server objects automatically have a SPN for HOST/ServerName created. 3rd party computer objects (e.g. NAS appliances) may need to have the SPNs manually created.
6. Kerberos is dependent on DNS name resolution. While short name requests can work with Kerberos (\\servername\share), your best bet is to use FQDNs in the UNC path (\\servername.contoso.com\share).