Determine *which* database an account failed to login to?

  • 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

  • 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

  • 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!

  • 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

  • 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.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply