Welcome back to the last video of the 3 videos on Windows Auditing. In this video I will
look at how to audit file and folder access in Windows. This kind of auditing allows the
administrator to track who has been accessing or attempting to access any file in Windows.
Without further ado, I will change to my Windows 8 computer to look at how to configure File
and Folder auditing. To configure auditing, I will first open Windows
Explorer and navigate to the file that I want to audit. You should only enable the files
and folders that you require, you will notice that once auditing is enabled, even just for
this one file, a lot of events are generated in the Event Viewer.
To enable auditing for any file or folder, right click it and select properties. Next
select the security tab and press the button at the bottom, advanced. Once the advanced
settings are open, select the auditing tab. I am currently logged in as an administrator,
but to access the auditing options I will first need to press the continue button to
enable the administrator to make changes. The next step is to press the add button at
the bottom. At the top of the screen click the option, select a principal. This essentially
means enter in the user, computer or group that you want to audit. In this case, I will
enter in everyone. The next setting that you can configure is
the type of auditing that you want. The settings are success, fail or all for both.
The next option is to configure the permissions that you want to audit. You can choose the
basic permissions or the option, “show advanced permissions” if you want additional options.
At the bottom is the option add condition. This is a new feature in Windows 8 and Windows
2012. It allows you to target the auditing a bit better. For example, in this case I
have selected everyone, but I will add the domain administrator as a condition telling
auditing not to audit this user. Conditions are a great addition to auditing which allow
the administrator to target auditing to their needs. This helps reduce the number of events
that are logged in the event viewer. Next I need to make changes to local Group
Policy so this computer will start auditing events for changes to this file. To do this,
I will close the properties of the file and then move my mouse to the top right to open
charms and select the search option. In the search option I will enter in GPEdit.MSC
to open local Group Policy. In local Group Policy, I will navigate through Computer Configuration,
Windows Settings, Security Settings, Local Polices and then Audit Policy.
The setting that I need to enable is Audit Object access. It does seem like a strange
name for file auditing; however when you consider that Windows considers everything to be an
object this makes sense. In this case, I will enable auditing for success
and failure. Once I configure the settings and exit from here, I will next need to make
sure Group Policy has been applied. To do this, I will go back into charms and then
search for the command prompt. In this case, I need the command prompt to
have administrator rights so I will right click on the icon to get additional options
and then select the option at the bottom to run as administrator.
From the command prompt, I will run GPUpdate with the force switch. This will ensure that
the latest Group Policy has been downloaded and applied. The two steps for auditing have
now been complete. That is, the SCAL has been configured and the Group Policy is configured.
Now, when the file is accessed, events will be recorded in the security log in the Event
Viewer. Before I attempt to access the file, I will
first open the Event Viewer to demonstrate an important point about how many events this
kind of auditing creates. To see the Events I will open the security
log. You will notice that once the security log is opened and I wait a few seconds, a
message will appear at the top saying new events are available. To see these events
I will refresh the view by pressing F5. Now that the event viewer is showing the latest
event, I will take note of the time and now go back to Windows Explorer and open the file
that I am auditing. This file states the next training course
will be free, so let’s change that to 1 million dollars. Of course all our training
courses are free, but if someone was to change our courses so they were not free any more,
we would want to know who did this so we could fire them straight away.
If I now go back to the Event Viewer, I will take note of the time of the event at the
top of the Event Viewer and press F5 to refresh the view. When I scroll down, you will notice
how many events were recorded in the short time I was opening the file and while I was
scrolling down new events have been recorded in the event viewer.
If I open the first event that was generated, you will see that it is about a handle that
was created in the operating system. Handles are used to access files and resources in
Windows, this does not have anything to do with the access of our file however.
The next event has to do with Windows Explorer. The next event relates to the file; however,
notice at the top the event says that a handle was requested. This basically is saying the
file was opened. The next event you can see is another event
that has been generated for the file. At the top you can see the event generated was an
attempt made to access an object. This demonstrates one of the problems with auditing of files
and folders. This event does not tell the administrator if the file is being read or
being written to. Also, to keep the Event Log from become to full, any additional event
of this type from the same file will be ignored and not saved in the event viewer. Unless
the file is closed and opened again, no more events of this type will be recorded. Software
like notepad will open and close the file when it reads or writes to the file. Other
software may keep the file open for long periods making it difficult to tell what the user
was doing with the file during that time. One work around for this is to only audit
the permissions you are interested in. For example, I can go back in the security settings
for the file and change the auditing settings. One trick you can do is set auditing only
for the write permission. When you set only the write permission in
auditing, what happens is that an auditing event is only generated when the user attempts
to write to the file. The event will still appear in the event viewer as an attempt was
made to access an object but you will know when you see this event, the attempt was a
write attempt because this is the only kind of access that is being audited. When auditing
files and folders, have a good think about what you are trying to achieve so that you
can capture the right results. This concludes the 3rd video on auditing.
This video and the others are all part of the free Active Directory course from ITFreeTraining.
For the latest videos please subscribe to us on YouTube or visit our web site.
Thanks for watching.