SQL Alert: 020 - SSPI handshake failure. Tracking the cause? I have done my best to find an article that answers this question but I have not had much luck.

I manage the database across three domains. One domain has the ability to access the other two, but without a trusted connection (SQL traffic through firewall using SQL credentials). I have started getting a lot of SSPI handshake failures in my logs (and as such alerts). I know that a percentage of them are my fellow developers forgetting to use SQL Auth and the server legitimately failing to authenticate.

However I also believe that there is an application out there (or an ODBC setting, authenticated excel report, etc) that is causing some of the errors. I have tracked the problem down to our RDP farm, but not to the root application/etc. 

My question is: How can I determine the application/remote-user/something that is causing the SSPI error so that I can resolve it once and for-all!
Usually when you get the SSPI notification (or from the error log ), you will see the IP address from which the app\user tried to connect. The IP may be internal or external. 

Just launch the command line and type:

NSlookup IP


(using the IP address from the log). This will give you the hostname from which the connection request came.