infrequent login failure - where is this user coming from?
My sql server is setup for mixed authentication. Web users all use the same login specifically for them, with the password provided in the connection string in web.config, with read/write access to one database. It's semi-secure, because after this login that is provided for them, they then have another user/password to get in past the first page. I am getting this error in the sql server log infrequently, 37 times in the last 3 months and none before that, some of these errors occur several times the same day, hours apart. I wonder if it an attack on my webpage? The user specified is the webpage user specified in the webpage connection string. Error: 18456 Severity: 14 State: 38. Login failed for user ''. Reason: Failed to open the explicitly specified database. [CLIENT: then it has carots and "local machine"] TIA and hope all have a great weekend.
Thanks NCD, I looked in the event viewer, and found IP addresses. I don't think this was what you were suggesting, but I am not skilled in tracing. I tried tracing but I used too much CPU on the production server, so I'm not trying it again any time soon. And thanks Grant and Blackhawk, it was a website for a dropped database. Problem is only I knew about this database. Thanks all! 11/19/13 I found out later that it was a bingbot that was periodically hitting this website.
That's someone trying to connect with a Windows login that doesn't have permission to the server. I see that all the time when we've messed up security on the server. It's only likely to be an attack if someone has already logged into your network. But that's what it is. You could try using extended events to track connection events to see who is attempting to connect.
Have a look in the default trace - against the login failure there will be a client process ID shown. If the connection is coming from the local machine, check in the task manager & see which process has that ID (bear in mind that it might have been recycled since it was logged ... ) I used this method to identify a specific program on a web server, that was generating multiple login failures because it was trying to connect to a mirrored copy of the database. Also used it to identify a misconfigured sharepoint service that was trying to connect to a non-existent database. Both of these gave state 38 errors. In short, default trace = full of useful information :)