SSPI handshake failed with error code 0x8009030c in the SQL Server Error log (4379916)

The following error is found in the SQL Server error log when either a SQL Server agent is connecting from the Foglight Agent Manager (FglAM) or FglAM and FMS is trying to connect to the SQL PI repository located on a SQL Server instance.

SSPI handshake failed with error code 0x8009030c
Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. 

SSPI handshake failure: This is part of the Windows authentication process. It usually fails when:

• The account is not trusted by the domain.
• The SPN (Service Principal Name) is not correctly registered.
• There’s a mismatch between the domain of the SQL Server and the domain of the service account.

Error 18452: This means the login is not associated with a trusted SQL Server connection.

1. Check Domain Trust

Ensure that the domain account is in a trusted domain relative to the SQL Server. If the SQL Server and the service account are in different domains, there must be a two-way trust between them.

2. Verify SPN Registration

Run the following command on the domain controller to check if the SPN is registered correctly:

setspn -L username

You should see entries like:

MSSQLSvc/your-sql-server-name:1433
MSSQLSvc/your-sql-server-FQDN:1433

If not, register them using:

setspn -A MSSQLSvc/your-sql-server-name:1433 username
setspn -A MSSQLSvc/your-sql-server-FQDN:1433 username

Note: You need domain admin rights to run setspn

3. Check SQL Server Configuration

• Ensure SQL Server is configured to allow Windows Authentication.
• Restart the SQL Server service after SPN changes.

4. Check Foglight Agent Configuration

• Make sure the Foglight agent is configured to use Windows Authentication with the new service account.
• If using Kerberos, ensure the agent host can request Kerberos tickets for the SQL Server.

5. Check Time Sync

Ensure that the SQL Server, domain controller, and Foglight agent host are all time-synced. Kerberos is sensitive to time differences.

How to Check if Kerberos or NTLM is Being Used

On the Foglight agent host, you can run this command in a command prompt:

klist

This shows the Kerberos tickets currently held by the system. If you see a ticket for something like:

MSSQLSvc/sqlserver.domain.com:1433

Then Kerberos is working. If there's no such ticket, it might be falling back to NTLM or failing altogether

On the SQL Server host (via DMV)

Run this query to show you the authentication scheme (KERBEROS, NTLM, or SQL) for each active session. 

SELECT 
    s.session_id,
    c.auth_scheme,
    s.login_name,
    c.client_net_address
FROM 
    sys.dm_exec_connections c
JOIN 
    sys.dm_exec_sessions s ON c.session_id = s.session_id
WHERE 
    s.is_user_process = 1;

Troubleshooting Tips

• Use the setspn tool to verify SPNs.
• Ensure the SQL Server is running under a domain account (not LocalSystem or NetworkService).
• Ensure DNS is resolving correctly (Kerberos is sensitive to name mismatches).
• Check that the Foglight agent is configured to use Windows Authentication and not SQL Auth.