Auditing SQL Server logins is done by way of writing audit information to the SQL Server Logs found under “Management->SQL Server Logs” in Management Studio.
In order to enable auditing of SQL Server logins, a simple operation needs to be performed by changing settings in the properties of the SQL Server.
Auditing levels vary. It’s possible to audit just failed logins, both failed and successful logins or just successful logins.
To enable auditing, in Management Studio right mouse click your SQL Server and choose “Properties”. Under “Select a page”, choose “Security” and the following options will be displayed.
A restart of the SQL Server service is needed for any changes to the SQL Server login auditing to take effect.
After the restart, the server will being auditing all login activity based on the setting chosen.
Please be aware that this can create very large log files in your log directory should you have a busy server with lots of connection activity and if you have enabled logging to log successful logins. Logging will also be recorded in your Windows application event log.
I wrote this post recently on how you can quickly reclaim space consumed by your sql server error logs using sp_cycle_errorlog
The resulting output found in the SQL Server logs will look similar to this
2012-06-30 10:18:19.44 Logon Login succeeded for user ‘NT ServiceMSSQL$SQLSERVER2012’. Connection made using Windows authentication. [CLIENT: ]
2012-06-30 10:18:19.57 Logon Login succeeded for user ‘NT ServiceMSSQL$SQLSERVER2012’. Connection made using Windows authentication. [CLIENT: ]
2012-06-30 10:28:14.29 Logon Error: 18456, Severity: 14, State: 8.
2012-06-30 10:28:14.29 Logon Login failed for user ‘andy’. Reason: Password did not match that for the login provided. [CLIENT:]
2012-06-30 10:43:18.98 Logon Login failed for user ‘test’. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]
Why would I audit SQL Server logins?
I typically use it to help figure out why connections to the database server are failing. If your application is having trouble connecting to your database server then this login information is great to have because it helps to tell you how far along in the authentication process the connection is.
If no entry for the user connecting is recorded then the application is not even getting as far as the database server. If output similar to the last two entries is seen then the error is detailed enough to help you easily figure out why there is a connection issue.
You may also be having some other security problem so these logs are very useful tool to the DBA to help troubleshoot problems with SQL Server security.
Wesley Mota says
Excellent job, post how to read the log files using T-SQL if I want to filter a specific user and put the information in the table.