SQL Server Connection Troubleshooting

When your SQL service (and/or reporting service) is using a bespoke domain user service account e.g. “sandbox\My_SQL_svc” then the Kerberos principal names have to be correct, or else AuthLite users won't be able to connect. 

This can occur in a typical deployment, because SQL installer doesn't attempt to set up kerberos SPNs.  In this case everything falls back to NTLM, which is OK as long as you're not using AuthLite.  But once you have AuthLite users the NTLM doesn't work as well, and it's necessary to fix the kerberos. (The same changes would be needed if you were deprecating NTLM in your environment as well.)

• This MS article discusses making sure you're using kerberos and setting up SPNs: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver16
• Also AuthLite must be installed on the machine from which you're connecting to SQL.
• Connect to the database with its FQDN (fully qualified domain name) instead of its short server name, or IP address.
• Lastly, if you are connecting to a FQDN that's a DNS alias (instead of the real server name) you need to set up SPNs for that too.