December 4, 2012 at 9:31 am
I have been asked to provide documentation on where SQL Server displays messages for login auditing. We set the auditing thru SSMS instance properties and I know that the messages are written to the SQL Server error log and the Windows Application log, however, the security people would like to see official documentation for every version and edition of SQL Server. I have searched the Microsoft support site, but could not find anything that listed or talked about where these messages are written to. Does anyone have any information on this?
December 4, 2012 at 9:48 am
well, for the SQL log, exactly where the logs go is configurable...when you first install the server, one of the options is to decide on the folders.
it defaults to a certain path, of course if not changed @ setup
where it is right now, you can find out via TSQL like this:
SELECT SERVERPROPERTY('ErrorLogFileName');
you can see the current setup in the facets:(See the ErrorLogPath this screenshot was from showing how to change the default paths for databases and backups);
to change it after installation, i believe is a registry edit and a stop and start of the server is required.
Lowell
December 4, 2012 at 9:48 am
Hello,
Please refer to the below link. The second sentence says "Login auditing can be configured to write to the error log on the following events".
http://msdn.microsoft.com/en-us/library/ms175850(v=sql.105).aspx
December 4, 2012 at 9:54 am
I am aware of both these thing, but this does not answer the question I asked.
December 6, 2012 at 7:24 am
Which question exactly was not answered?
Where are login audits stored?
SQL Error log, if you configure auditing successful/failed logins through the instance properties. This is the same for every version of SQL.
MS documentation stating such:
SQL 2012
http://technet.microsoft.com/en-us/library/ms175850.aspx
SQL 2008 R2
http://technet.microsoft.com/en-us/library/ms175850(v=sql.105).aspx
SQL 2008
http://technet.microsoft.com/en-us/library/ms175850(v=sql.100).aspx
SQL 2005
http://technet.microsoft.com/en-us/library/ms175850(v=sql.90).aspx
Joie Andrew
"Since 1982"
December 6, 2012 at 9:34 am
I know that, when you are auditing logins, the messages go to the SQL Error log and the Windows Application log. I have been asked to provide documentation that explicitly states that these are the locations where the messages go.
December 6, 2012 at 9:40 am
that documentation here is a little inferred ("the log" means sql error log), but "you mean like this one:
http://msdn.microsoft.com/en-us/library/ms175850(v=sql.90).aspx
How to: Configure Login Auditing (SQL Server Management Studio)
SQL Server 2005 Other Versions 1 out of 5 rated this helpful - Rate this topic
Use login auditing to monitor SQL Server Database Engine login activity.
Login auditing can be configured to write to the error log on the following events.
Failed logins
Successful logins
Both failed and successful logins
Lowell
December 11, 2012 at 12:47 am
login auditing can be done easily using below option.
Failed logins
Successful logins
Both failed and successful logins
which write to error log .
but if you select successful logins and Both failed and successful logins
it will create events in huge manner in errorlog,which might affect your performance of server
Hence select only failed login.
February 6, 2013 at 5:24 am
February 20, 2013 at 3:16 pm
We tried to do the same and couldn't find a solution in audit vault. Be interested to know how to setup this. There is just too much noise from our app and since we trust the ip it comes from - we don't want to audit that but we need to audit if it's not from the trusted ip. we are evaluating a 3rd party tools called core audit by blue core research to do this. :hehe:
February 21, 2013 at 7:46 am
I've created a pretty decent server side trace script that does a good job of auditing login info;
it definitely captures failed logins, as well as all these events:
--Audit Add DB User Event
--Audit Add Login to Server Role Event
--Audit Add Member to DB Role Event
--Audit Add Role Event
--Audit Addlogin Event
--Audit Login
--Audit Login Change Property Event
--Audit Login Failed
--Audit Login GDR Event
--Audit Logout
--Audit Schema Object GDR Event
--UserConfigurable:4
from there, i usually create a view for every trace i create so that i can easily look at the results
here's teh base of the needed SQl :
--SELECT * from sys.traces
declare @TraceIDToReview int
declare @path varchar(255)
SET @TraceIDToReview = 2 --this is the trace you want to review!
SELECT @path = path from sys.traces WHERE id = @TraceIDToReview
SELECT
TE.name As EventClassDescrip,
v.subclass_name As EventSubClassDescrip,
TE.*,
T.*
FROM ::fn_trace_gettable(@path, default) T
LEFT OUTER JOIN sys.trace_events TE ON T.EventClass = TE.trace_event_id
LEFT OUTER JOIN sys.trace_subclass_values V
ON T.EventClass = V.trace_event_id AND T.EventSubClass = V.subclass_value
Lowell
March 1, 2013 at 11:31 am
Hello Guys i think that If you want to see, at the time if someone is signed in twice and obtaining the same information look at the hosting server stocks and start information.auditing details is one operation.auditing log on is another operation between both and filtration the occasion audience you should be able to get what you want.Thanks a lot!!
March 1, 2013 at 11:43 am
saifulislam6720 (3/1/2013)
Hello Guys i think that If you want to see, at the time if someone is signed in twice and obtaining the same information look at the hosting server stocks and start information.auditing details is one operation.auditing log on is another operation between both and filtration the occasion audience you should be able to get what you want.Thanks a lot!!
the example i posted can let you see if the same login is open two or more times, but this trace does not capture WHAT they are looking at(just login/logout times, for exmapel)...you'd need to expand it to a full DML trace that also includes the Login audit events like my example above.
Lowell
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply