I am dealing with a customer that thinks they had sensitive data deleted over the weekend. Because the data that was accessed was confidential, it could be considered criminal activity and wants to know who did it.

Checked the Security Event Log and found its flooded with just Logon's and Logoff's.

The first problem is that everytime the Server has to access or authenticate a workstation for any sort of service, backing up, SARC, other random stuff, it creates a logon/logoff log. Its like a needle in a haystack deciding what is normal Server activity and everything else.

Asking the "Server Techs" at my work and they dont know much about Audit Policies and the appropriate way of impletementing them.

So far, we setup the Server to log any folder and file deletions for the sensitive data, but that just adds more logs.

Does anyone know a good configuration for audit policies?

I really need just the important logon/logoffs logged and not all the rest. Reaserching the net just recommends logging almost everything, I dont get it.

 

Yea we you start logging like that, it grabs everything making it a PITA to go through event logs. Might consider getting software that goes through the event logs and set it up to send you a ping when a certain event ID are logged. That way you won't have to go through all the logs.
Let me think this one through cause i think I think i might have an answer for ya. MAAAYYYBEEEE
hit me up on aim if ya'd like

 

I dont want to give any advice on policy configurations, so please do not take this as such. furthermore I take 0 responsibility for what I state below, use this info as you wish, it is part of an informal discussion and should not be relied upon to make any configuration changes. you should probably log as much as you can and filter through everything later anyhow. just an opinion though

if you are trying to distinguish between actual user logons and all the other junk in the event logs, event id 540, 672, and 673 are generally the ids that will be generated from the actual login as opposed to an event generated from using a network printer or checking your exchange acct. usually a users logon event will include the Hostname, IP, and samaccountname (msft user login name) in the event. All 3 fields must be present in the event to constitute a reliable login event imo (evt 540 will only have all 3 for an actual user login, otherwise it'll be the machine name); as far as I know those 3 event types are the only ones including these 3 field populated in a single event.

with that said. event 538 I believe will also be triggered for logons, but not exclusively, it also get triggered for other network accesses so its a bit noisy to follow. use your event id filters and timestamps to find out who logged in when.

contrary to what msft documentation may suggest there is no such thing as a logoff event, at least its incredibly unreliable, so you probably dont want to expend to much energy trying to find them.

If you are having data leakage issues, perhaps a dataleakage product is what you're after. a company named Vontu I think is the leader in the space, they are now part of Symantec.

GL

 

Well, these Servers are for Small businesses and even smaller businesses. From what I read here, and looking at event logs for 3 hours, confused on whats real, I am just activating Logon events, object access, and system events for Success or Failure.

I want to dump system events but I think that would kill the System logs, and eveything is cool but the Security Logs.

Also, let me add a little something...Before today, every Server configured by the company I started working for has been using the default Domain Controller Audit Policies. No one really cares about looking through the Security logs. Honestly, I think this is the first time a customer has requested this.

Object Policies are obiviously very important to see if people are deleting confidential files and such, and also phsyical logins with Crtl+Alt+Delete, but all the other stuff I dont think anyone cares about or will even bother looking into it.

The only other thing I can think of is when peeps get through the firewall and are non-local, how would you track that use without flooding the log events?

 

before you make any configuration changes, decide what it is you are looking for and see if its already there, if its not, then perhaps a config change is in order.

It sounds to me like you are trying to find out who logged in where at what time. the 540,672 and 673 events should show this; if those events are not present in your security log, then you should consider making a config change to enable logging of these event types. If logon event auditing is not enabled then you probably wont have these event types in your logs.

 

Dude, I understand. Just need advice for the simplest super small business Audit Policy.

Personally, I think this site dumbed it down perfectly. What do you think?

 

Problem is, the default settings logs a million of the logon events, most irrelevent. I just need the Crtl+Alt+Del local logins and those times. There are only 5 people working at this office and I have a million logon logs. So I disabled Audit Account Logon events and kept Audit Logon Events. This seemed to cut down a lot of logs, but there are still tons.

Here we go, things are looking up, but I dont care for this user logons/offs...NT AUTHORITY\SYSTEM. These System Logons are pissing me off.

 

I would test to see if with this type of configuration you still see the 540,672 and 673 events, I dont think you will. Its a simple test, just log into a machine using a domain acct and see if the event shows up in the security logs, again must be a 540,672, or 673 event type. Unfortunately you may have to deal with the large amount of useless events as well, but if you filter for these three event types you'll always have the info you are seeking. dont think there's any way around it. these policies just arent that fine grained.

 

We had somewhat of the same problem, however we are putting a full sharepoint system into place. The nice thing about sharepoint is it tracks who opens what, who makes changes, and what changes.

So the big question for you, if the file was confidential, then who has access to that group policy/permission. That should, if your admins did the permissions right, tell you who to look for on login/logout of the file.

 

Yea, I can't tell if the Doctor is just testing us or what. He says data was recovered, but none of our techs did it. No one else has backups, its hard to tell what is really going on. But thanks for the advice!

 

export and sort by event ID

 

Also, shoudlnt you be able to restore using volume shadow copy?