Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Determine *which* database an account failed to login to? Expand / Collapse
Author
Message
Posted Thursday, September 26, 2013 8:03 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 11:00 AM
Points: 979, Visits: 5,090
Is there a way to determine, when an account attempts to open a DB and fails, which DB it was trying to open?

Possibly via a server-side trace?

For example, this morning I had an account attempt to open a DB and fail with the "Failed to open the explicitly specified database" error. There's no indication in the SQL logs of a DB going into recovery, the server did not reboot, and there were no backup / maintenance jobs running at the time this happened that might have caused a problem.

Every time this happens (not that frequently, but enough,) our security software catches the "Login failed for user..." bit, and I get someone over asking what might have happened.

Thanks,
Jason
Post #1498865
Posted Thursday, September 26, 2013 4:23 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 8:33 AM
Points: 153, Visits: 977
jasona.work (9/26/2013)
Is there a way to determine, when an account attempts to open a DB and fails, which DB it was trying to open?

Possibly via a server-side trace?
...



If you are on >= SQL 2008 Enterprise you can use the Auditing feature.
In SQL 2012 the Server level part is even available in standard edition.
That would in my eyes be the easiest way plus have the least overhead.

A SQL Trace is possible, too if you don't have that option. There you would use the "Audit Login Failed" event.

It shoul all be in the Errorlog as well though. So if it is really missing completely, there might be something else going on..


Andreas

---------------------------------------------------
MVP SQL Server
Microsoft Certified Master SQL Server 2008
Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.insidesql.org/blogs/andreaswolter
www.andreas-wolter.com
Post #1499101
Posted Friday, September 27, 2013 11:49 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 11:00 AM
Points: 979, Visits: 5,090
Andreas.Wolter (9/26/2013)
jasona.work (9/26/2013)
Is there a way to determine, when an account attempts to open a DB and fails, which DB it was trying to open?

Possibly via a server-side trace?
...



If you are on >= SQL 2008 Enterprise you can use the Auditing feature.
In SQL 2012 the Server level part is even available in standard edition.
That would in my eyes be the easiest way plus have the least overhead.

A SQL Trace is possible, too if you don't have that option. There you would use the "Audit Login Failed" event.

It shoul all be in the Errorlog as well though. So if it is really missing completely, there might be something else going on..


Hmm. I like the idea of the audit feature, would this be the "C2 audit tracing?" If so, there was a note from a previous DBA that they did not enable this due to performance implications.

There is a trace running, which does capture login failed events (as does the login auditing,) which did not show a DB name. So I'm now wondering if perhaps someone typoed the DB name in a connection string and was trying to connect to a non-existent, never existed DB (rather than DBName they put in dbame)

Thanks!
Post #1499529
Posted Friday, September 27, 2013 11:56 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 8:33 AM
Points: 153, Visits: 977

Hmm. I like the idea of the audit feature, would this be the "C2 audit tracing?" If so, there was a note from a previous DBA that they did not enable this due to performance implications.

There is a trace running, which does capture login failed events (as does the login auditing,) which did not show a DB name. So I'm now wondering if perhaps someone typoed the DB name in a connection string and was trying to connect to a non-existent, never existed DB (rather than DBName they put in dbame)


Nope, its just "Auditing" - look in the "Security" node in SSMS
http://technet.microsoft.com/en-us/library/dd392015%28v=sql.100%29.aspx


I have seen the problem with the Database name not being logged. I found out which one it was by checking recently dropped databases...


Andreas

---------------------------------------------------
MVP SQL Server
Microsoft Certified Master SQL Server 2008
Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.insidesql.org/blogs/andreaswolter
www.andreas-wolter.com
Post #1499532
Posted Monday, September 30, 2013 12:03 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 9:08 AM
Points: 550, Visits: 1,610
When this was happening to me a trace did show the connection string that was failing containing the name a database that had been previously dropped, but there was still a client out there tying to connect. It was then a simple matter to to look at the machine owning the IP and disable the client software.
Post #1500146
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse