In this video and the next two videos I will be looking at auditing. Auditing allows you
to track Active Directory and file access in your organization. In this video I will
look at the concepts behind auditing. How it works and what you need to know to start
using it. In the next video I will look at how to configure auditing to track changes
in Active Directory. The video after this I will look at how to configure auditing for
file and folder access. To start with, I will look at the basic concepts of how auditing
works. Let's consider an object in Windows. This could be a file or folder, user or computer
account or any other object that exists in Windows. In order to protect the object from
unauthorized access you require permissions, these are often referred to as Access control
List or ACL. If a user requires access to an object, they require permissions to that
object. In order to determine if the user has access they are looked up in an Access
Control List called Direct Access Control List or DACL. This works well for permissions
like read and write but does not work well with auditing. To understand why, consider
that access control and auditing are performed by two separate systems. If you wanted to
audit which users authenticated off a particular Domain Controller, would you require access
to the user account and information inside the user account like group membership? The
answer is no. In order to allow auditing to access an object that it may not have traditional
permissions configured for like read and write, a separate ACL is created called the System
Access Control List or SACL. You can see by having two ACL's, permissions and auditing
can be separated. In other words, a single ACL is divided into two parts, the DACL and
the SACL. To demonstrate this better, I will open the advanced security options for the
root of my domain. Notice on the permissions tab there is a list of the access permissions
for the root domain. These define permissions like read and write. On the audit tab this
defines audit entries. Unlike permissions, these define actions like success and fail.
This is another reason why you want them separated, combining these two into the one list would
overly complicate things. If I exit out of here, the next question that arises is this.
What happens when an object is configured for particular auditing event and that event
happens? For example, let's say you are auditing users logons and a user logs on. What happens
is the audit policy for that computer determines if that event is recorded in the event log.
If the audit policy for that computer is not configured to audit that event it is not recorded.
This is starting to get a little complicated so let's have a look at auditing from a different
angle. In this example, if you wanted to audit all user authentications, that is success
and failed logins, the audit policy needs to be configured to allow this. In this case
you do not need to change any SACL on the users to allow this, the default SACL in Active
Directory allow this kind of auditing. If you are auditing files and folders however,
you will need to change the SACL for the files and folders you want to audit. The audit policy
will determine which events will be recorded. The events that are recorded are then stored
in the event viewer. You can see that login events, both success and failure are being
recorded in the event viewer since the audit policy has been configured to record them.
You can see that if the audit policy has changed, login and failed events would no longer be
recorded. Having a system like this means you can easily change which events are being
audited without having to change any of the SACL's on any of the objects. Why would you
need a system like this? It should be remembered that systems like auditing put extra load
on Windows and can quickly fill the security logs depending on what you are auditing. For
these reasons, many administrators prefer to switch auditing on when required or only
audit a few events unless there is a need to audit more. Having one or few security
polices is a lot easier then changing 100 or 1000's of users when you need auditing
enabled. This covers the basics of how auditing works in Windows. In the next video I will
look at how to implement auditing in Active Directory and the video after this how to
audit file and folder access. If you want to receive more free videos from us, please
feel free to subscribe to us on YouTube. As always, thanks for watching.