Welcome to the second video out of three on Windows Auditing. In this video I will look
at how to configure auditing for objects in Active Directory. By the end of this video,
you will be able to determine which servers you would need to configure auditing on to
get the best results. Before I look at how to configure auditing
and what settings can be configured, the first thing to consider is where to configure auditing
and what to audit. Consider this example. When a user logs onto the domain, the Domain
Controller that they use to access the network can record this event in its event viewer.
If the user then attempts to access a file on a file server, the file server can generate
an event indicating a connection was made to the file server. If the user was to logon
to the Domain at another time, for example the next day, if there were multiple Domain
Controllers on the network, a different Domain Controller may authenticate the user and thus
the event will be recorded on that Domain Controller. When using auditing on your network,
in order to get the best results, you may need to look at the events from a number of
different servers. I will now change to my Windows Server 2008
R2 Domain Controller to look at how to configure auditing.
To configure auditing setting for the domain, I will first open Group Policy Management
from administrative tools under the start menu. In this case, I will modify the Default
Domain Policy. It should be pointed out that auditing settings can be configured anywhere
in the domain or using local group policy. The auditing settings can be found in Computer
Configuration, Polices, Windows Settings, Local Polices and then Audit Policy. There
are 9 audit settings that can be configured. If I open Audit Account Logon events I can
tick the option “Define these policy settings”. Once I tick this box I will get the choice
to audit success and failure. When choosing which settings to audit and
which not to audit, it is worth having a look at the explain tab. The explain tab will give
you a detailed description of what the setting does. It is important to understand what each
setting audits and what it does not audit before you configure it. Be careful which
settings you choose to enable, if you enable a setting that records a lot of events, this
can cause performance problems on that computer and cause the event log to fill up very quickly.
If I cancel out of here and go back to the Group Policy settings, you will notice that
none of them are configured and this would tend to suggest that no auditing is happening.
If I open the Event Viewer from the start menu and then open the security log. You will
notice that there are a number of events generated for logons, but as we have seen no auditing
settings have been configured. So how are these events been generated?
If I close out of all these Windows, I will now leave Windows and have a closer look at
the Audit Policy Settings in more detail. You will notice on the far right, In Windows
Server 2008 R2 some of the audit settings are enabled by default.
You will notice in the default settings there are only settings configured for success.
They do not have any settings that are configured for failure by default.
The first setting, Audit Account Logon events, will audit logins when the computer is considered
an authoritative for that account. For example, if you attempt to login using a domain account,
the Domain Controllers in the domain will log an audit event in its security log. This
is because the Domain Controller holds domain accounts and thus is considered an authority
for domain accounts. In contrast, if a user was to login to a workstation using a local
account stored on that computer, that computer would be considered an authority for that
user account. Thus, when you login to a workstation using a local account, an event will be logged
in the security log of that local computer if auditing is configured.
It should be remembered that a logon event can also happens in other ways. Besides login
locally and using remote desktop, a logon event can also be created when accessing a
resource on anther computer. For example, if the user attempts to access a file share,
the user will first need to logon to the file server before it can access the files. If you
login to a computer physically and obtain a desktop, this is referred to as interactive
login. This audit settings does not take into account if the login is interactive or not,
it simple records that a logon has occurred. Once the logon has occurred, that user account
is able to access other resources. The next audit setting is Audit Account Management.
This audits changes to user accounts, like creating, changing and password resets.
The next setting is Audit Directory Services. This will audit changes to Active Directory
accounts. It should be noted that not all objects in Active Directory will be audited
by default. We will see in the demonstration how to configure which objects will be audited.
The next setting is Audit Logon events. This may seem very simpler to Audit Account logon
events. There are two fundamental differences. First, regardless of where the account is
located, that is in Active Directory or locally, this event will be generated whenever a connection
is made. For example, if you attempted to access a file server using a domain user,
the file server would generate an Audit logon event when though the user is located in Active
Directory. In contrast, if Audit Account Logon event were enabled, no event would be recorded
on the file server, the event would be logged on a Domain Controller. To put it another
way, Audit Account Logon events record authentication, that is when a username and password is checked
to be valid. Audit Logon events record access after the user was authenticated, e.g. a user
accessing a file server. The second difference between the two events
is that Audit Logon events records a lot more information. Audit Account Logon records authentication
and that is it. Once a user is authenticated there is no way using Audit Logon Events to
know how long the user was logged in or what they accessed. Audit Logon events in contrast
records information like when the user disconnected from the server, logged off and account local
out. This gives you more of indication of what servers the user used and how long they
were using them. The next setting is Audit Object Access. This
will essentially audit non Active Directory objects. These include File and Folders. Since
enabling this setting can cause performance problems, this setting is disabled by default.
In the next video I will look at how to use this setting to audit file and folder access.
The next setting is Audit Policy Change. This tracks changes to policy like User Rights
Assignment, Auditing, Accounts and Trust Policy. For example, changing any of the audit settings
here will generate an audit policy change event.
This next setting is Audit Privilege Use. This setting audits when privileges are used
in the operating system. An example of privileges is taking ownership of files and folder and
changing the system time. The next setting is Audit Process Tracking.
This tracks the starting and ending of processors use by applications. This would only be enabled
in special troubleshooting scenarios due to the amount of events that it would generate.
The last setting is Audit System Events. This records events like system starts up, shutdowns,
time changes and changes to the log files. In some cases, it may not be enough to know
that a change has occurred; you may also want to know what the value was before the change.
For example, when membership for an Active Directory group is changed, you may want
to know what the membership was before the change.
With Windows Server 2008, “Active Directory Service access” has been improved to be
able to record information about what has changed. For example, if a user is removed
from a group, the event will contain information about which user was removed from the group.
Before Windows Server 2008, an event would be recorded telling you a change had been
made, but would not tell you what the data was before the change.
To enable the additional auditing in Windows Server 2008, run the following command. Once
the setting has been enabled, Windows will start recording additional information allowing
the administrator to determine what the value was before the change.
I will now change to my Windows Server 2008 R2 Domain Controller to look at how to use
this option. First of all I will open a command prompt.
From the command prompt I need to enable changes to be recorded by using the AuditPol command.
If this command is not run, auditing will be performed in the same way as previous operating
systems and this will not record previous values when changes are made.
Now that the change has been made, I will now open Active Directory Users and Computers
from the start menu. Next, I will open Users and then open the properties for Domain Admins.
From the properties, I will select the security tab and then press the button at the bottom
advanced. Next I will select the auditing tab. Notice that at the top, an entry has
been added just for Domain Admins, this is not inherited. The SACL for Domain Admins
is automatically configured to audit changes. If you want to audit a different group, you
need to ensure that SACL is configured corrected. For the other domain groups this will not
be configured by default and the administrator will need to configure it before auditing
can occur for these groups. If I edit this entry, check that write all
properties is ticked. This will ensure that auditing happens when changes to the group
occur. If I now exit out of here and go to the member’s tabs, I will now add the domain
users group to the domain admin group. This is the kind of mistake that you would want
to audit and correct quickly. Now that Domain Users group has been added
to the Domain Admins group, I will exit out of here and open the Event Viewer from the
start menu. To access the events that were recorded by auditing, I will open the security
log. If I open the event at the top, this event was audited when I made the change.
You can see at the top, the user that made the change was the ITFreeTraining Administrator.
Further down you can see that the group that the attribute that was changed was Domain
Users. At the bottom you can see that the operation that was performed was a value was
added. In this case it shows the something was added,
but what happens when a value is changed. If I exit here and open Active Directory Users
and Computers, this time I will make a change to the administrator account in the domain.
If I open the properties for the domain administrator account, I can see the phone number for the
domain administrator. In this case I will remove the last digits of the phone but leave
the first digits. This is an example of when you would want to access to the previous value
so you can undo a change that was made by mistake.
If I exit here and go back to the Event Viewer, I will need to press F5 to refresh the view
to read the new events. If I open the event at the top, notice that
at the bottom the operation is listed as deleted and the value is listed above. This may seem
a little strange because I modified the value rather than deleting it.
If I exit here and open the next event, notice that if I scroll down the value is listed
as the new value. If you think of this in terms of databases this makes sense. The old
value was deleted from the database and a new value added. Unfortunately, all the information
is not in the same event making it difficult to find. When looking through the security
logs, make sure you look at the events around the event that you are interested in, doing
this will give you a complete picture of what has happened.
Thanks for watching anther video from IT Free Training. For more free videos for this course
and others, please feel free to visit our web site or YouTube channel. See you in the
next video.