I have Windows Server 2016, with SQL Server 2017, and found Windows Log Application is full of Login failed messages (as follows) :

Login failed for user 'sa'. Reason: Password did not match that for the login provided. [CLIENT: ****]

Client's IP addresses are various. I don't have any maintenance plan in SQL Server

enter image description here

What's the problem?

  • We need to access SQL Server on internet – Mohammad Dayyan Nov 28 '19 at 19:08

A login attempt was made from the IP address given. The attempt was to log in using the credential sa. A password was supplied but it was not the correct password.

sa is the default sysadmin credential in SQL Server. Errorlog spam with this message usually means 1 of 2 things.

  1. You have an application that was configured to use the sa crendential
  2. You've made yourself a honeypot and a malicious actor has gained a pipe to your database server in an attempt to log in and take it over.

If it's #1, then go to the application you're hosting at that IP address and change its webconfig.

If it's #2, then you need to blacklist that IP address - preferably by firewalling your database server off from the public internet (which you should really do anyways to be frank).

See also:


It looks like your SQL Server is exposed to Public Internet, and someone is trying to brute force (hack) password from your SA account...

I had the same situation when one of my SQL Servers was in Azure and exposed to Public Internet on port 1433

SOLUTION: You need to configure firewall properly to only let IP addresses / apps / users you trust, to access your SQL Server

If your SQL Server is in Azure, go configure Network Security Group;
If its in the On-premise data center -> configure your firewall

  • 1
    Thanks for this. I'm using AWS, and I immediately changed to the security group to white listing policy of only my ip address. The brute force attacks were immediately blocked. – Najeeb Mar 3 '20 at 11:50

What's the problem?

There is no problem in writing windows application log entries, those are the entries from actual event (failed login) when it really occurred at SQL Server.

You may want to immediately disable sa account (while you maintain another sysadmin login). Second, Firewall/network configuration to not to expose the SQL server to public network (since your mentioned Clints are various of IP address). General best practice to keep only application servers exposed to public network (if necessary) and database server to app servers, if database access really needed outside use VPN instead.

Finally, following references for best practices:


Are you using SSRS? That could be a reason if you configured sa user in Data Sources.. Try to think of any other application that is using the sa account.

  • 1
    Hint: The number you arrive at (applications using the "sa" account) really ought to be zero! /Never/ allow anyone but you (or your Team) to use "sa" credentials. Always keep the biggest and best tools for yourself because you need to clean up the mess that other people make. Using the "sa" credentials, someone else could foul up your installation so badly that even you can't get it back again - and then it would be /your/ head on the block, not theirs! – Phill W. Nov 28 '19 at 14:30

Your Answer

