Политики аудита изменений в Active Directory

Любой администратор Active Directory рано или поздно сталкивается с необходимостью аудита изменения в Active Directory, и этот вопрос может встать тем острее, чем больше и сложнее структура Active Directory и чем больше список лиц, кому делегированы права управления в том или ином сайте или контейнере AD. В сферу интересов администратора (или специалиста по ИБ) могут попасть такие вопросы как:

• кто создал/ удалил пользователя или группу AD
• кто включил / заблокировал пользователя
• с какого адреса был изменен / сброшен пароль пользователя домена
• кто создал / отредактировал групповую политику и т.д.

В ОС семейства Windows существуют встроенные средства аудита изменений в различных объектах, которые, как и многие другие параметры Windows, имеют возможности управления с помощью групповых политики.

Разберем на конкретном примере методику включения аудит изменений параметров пользователей и членства в группах Active Directory (согласно данной методики можно включить отслеживание и других категорий событий).

Содержание:

• Расширенные политики аудита Windows
• Настройка аудита изменений учетных записей и групп Active Directory
• Основные недостатки встроенной системы аудита Windows

A Windows system’s audit policy determines which type of
information about the system you’ll find in the Security log. Windows uses nine audit policy categories and 50 audit policy subcategories
to give you more-granular control over which information is logged.

By default, if you define a value for a policy in one of
the top-level categories—either in the computer’s Local Security Policy or in
an applicable GPO—then that top-level policy will usually override any
configurations that you make at the subcategory level. Under Windows’ default behavior,
subcategory policies take effect only when you leave the related
top-level category undefined in the Local Security Policy and in all applicable
GPOs. If a category policy is defined, then all subcategory policies under that
policy will be defined. We stress usually and default behavior
because the new Group Policy Object Editor (GPE)
Audit: Force audit policy
subcategory settings (Windows Vista or later) to override audit policy category
settings
setting (under Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options) reverses that behavior. If you enable
this setting, then your subcategory configurations will override how the
applied Group Policy sets the top-level policies.

The ability to audit events in your environment is crucial for the discovery and investigation of security incidents. Therefore, it is important to know the best practice for configuring the Windows Server 2016/2019 audit policy.

Contents

1. Security log configuration
2. Audit policy vs advanced audit policy
3. Account logon
4. Account management
5. Detailed tracking
6. DS access
7. Logon/Logoff
8. Object access
9. Policy change
10. Privilege use
11. System
12. Conclusion

• Author
• Recent Posts

Collecting events generated in your environment is required not only for maintaining security, but also to meet compliance standards, especially for large enterprises or public companies that need to adopt CIS or similar standards.

If malicious activity occurs, proper security logs help you to detect the activity and identify its source. Without the logs, you will most likely never know that something happened, or it will be discovered after it is too late.

For example, if you have an employee who copies sensitive corporate data to a USB stick and gives it to your competition, but the action is not logged or stopped by a data loss prevention system (DLP), it will be impossible to identify the user and prove the incident occurred. But if you have a proper event recorded, with username and filenames, it will be hard for user to deny such activity.

Основные недостатки встроенной системы аудита Windows

Однако у штатных средств просмотра и анализа логов в Windows есть определенные недостатки.

Естественно, консоль Event Viewer предоставляет лишь базовые возможности просмотра и поиска информации о тех или иных событиях в системе и не предполагает возможностей сложной обработки, группировки и агрегации информации. По сути эта задача целиком зависит от способностей и уровня подготовки системного администратора или инженера ИБ, который с помощью различных скриптов (например, powershell илл vbs) или офисных средств может разработать собственную систему импорта и поиска по журналам.

Также не стоит забывать, что с помощью встроенных средств Windows сложно объединить журналы с различных контроллеров домена (можно, конечно, воспользоваться возможностью перенаправления логов в Windows, но этот инструмент также недостаточно гибкий), поэтому поиск нужного события придется осуществлять на всех контроллерах домена (в рамках больших сетей это очень накладно).

Кроме того, при организации системы аудита изменений в AD с помощью штатных средств Windows нужно учесть, что в журнал системы пишется огромное количество событий (зачастую ненужных) и это приводит к его быстрому заполнению и перезатиранию. Чтобы иметь возможность работы с архивом событий, необходимо увеличить максимальный размер журнала и запретить перезапись, а также разработать стратегию импорта и очистки журналов.

Именно по этим причинам, для аудита изменений в AD в крупных и распределенных системах предпочтительно использовать программные комплексы сторонних разработчиков. В последнее время на слуху, например, такие продукты, как NetWrix Active Directory Change Reporter или ChangeAuditor for Active Directory.

Logon/Logoff

Audit Account Lockout: Success, Failure

Records events for accounts that were locked due to bad password attempts.

Audit Group Membership: Success

Records the groups in which a user was a member at the time of logon. For domain accounts, the event is logged on domain controllers; for local accounts, it is logged on the local computer.

Audit Logoff: Success

Audit Logon: Success, Failure

These two options report user logon or logoff from the system. An event is logged on a local computer if the access is interactive or on a remote computer if the access is over a network (access to a shared folder).

Audit Other Logon/Logoff Events: Success, Failure

Audits events such as Remote Desktop session reconnect, workstation lock and unlock, etc.

Audit Special Logon: Success

Records logon events with administrator-equivalent privileges.

Object access

Audit Other Object Access Events: Success, Failure

Audits events related to COM+ objects and Task Scheduler jobs (job created, updated, or deleted).

Audit Removable Storage: Success, Failure

Audits access to removable drives, as mentioned in the example at the beginning of this post (data being copied to USB and given to the competition).

Detailed tracking

Audit PNP Activity: Success

Event is recorded when a plug-and-play device (such as a USB stick) is detected by the system. Email or other notification can be sent to IT staff to alert unapproved devices usage.

Audit Process Creation: Success

Audits when a new process is created, such as a user starting Wireshark to capture network traffic.

Privilege use

Audit Sensitive Privilege Use: Success, Failure

Creates a log event when a user (or a service account) uses any of the following sensitive privileges:

• Acts as part of the operating system
• Backs up files and directories
• Creates a token object
• Debugs programs
• Enables computer and user accounts to be trusted for delegation
• Generates security audits
• Impersonates a client after authentication
• Loads and unloads device drivers
• Manages auditing and security log
• Modifies firmware environment values
• Replaces a process-level token
• Restores files and directories
• Takes ownership of files or other objects

Note that this kind of configuration will create a high volume of events. However, it might be really useful to discover malicious activity.

System

Audit IPsec Driver: Success, Failure

Reports multiple events generated by IPsec driver activity, such as integrity checks, incorrect security parameter index (SPI), and so on.

Audit Other System Events: Success, Failure

Captures all kinds of events related to the Windows Firewall service.

Audit Security State Change: Success

Captures events related to the system security state, such as Windows startup, shutdown, or system time change.

Audit Security System Extension: Success, Failure

Includes events such as service installation in the system or loading of a security package by the Local Security Authority.

Audit System Integrity: Success, Failure

Captures events related to system integrity, such as an invalid hash value of a system image file. This might indicate corruption or an unauthorized change to the file.

Bottom Line

To prevent a lot of unwanted noise
events from being dumped into your Security log you must configure audit policy
at the subcategory level.

Event Viewer is much improved compared to the version back in
Windows Server 2003. You can now analyze the merged data from multiple logs in
one view and take advantage of much more flexible filtering. Although Event
Viewer provides new features for automatic archival and attachment of actions
to events, it is no replacement for a real log-management system. Anyone with
more than a few systems or the need for a high-integrity audit trail should
consider the latter.

Security Log Integrity

The Security log is fairly secure. To erase events or
otherwise tamper with the Security log or audit policy, you need physical
access to the target system, Administrator authority to that system, or Write
access to a GPO that applies to that system.

Larger IT departments should implement separation of duty
between operations and security-monitoring staff. To protect the integrity of
Security logs from rogue administrators, you must export events from the
Security log, as frequently as possible, to a separate server that is both
physically and logically out of reach of the local server’s administrator and
other operations staff. Security-monitoring staff then can monitor the security
activity that the servers report and can review the activity of operations
staff, as needed.

Subscriptions

You can use subscriptions to forward events from another
computer to a collector system. This method is no match for log-management
software but can be useful if you need to watch for only a few events. Windows
Event Collector and subscriptions can be set up using the Wevtutil program.
Subscriptions can also be set up in Event Viewer.

A Powerful New Utility: Wevtutil

Microsoft introduced Wevtutil in Windows
Server 2008. This utility allows control over nearly every aspect of the event
logs. You can also use Wevtutil to reveal the event-log schema. As with many
tools, Wevtutil doesn’t come with enough documentation, but don’t be afraid to
dive in.

You will likely be surprised by just how many logs exist.
To enumerate logs, use the wevtutil el command; to enumerate publishers, use wevtutil ep. To learn about the Security
log, try this command:

wevtutil gp Microsoft-Windows-Security-Auditing /ge:true
/gm:true /f:xml > junk.xml

You’ll get a ton of information about the log and every
possible event. (Keep in mind that not every event works like it was designed
to do.) You can also use this tool can to run queries, export logs, archive logs,
modify the configuration of logging, and clear the Security log. You’ll find
Wevtutil much easier to use and more powerful than the unsupported LogParser,
which was needed for Windows Server 2003.

Subscribe to 4sysops newsletter!

Event Viewer Filter

The filter in the new Event Viewer is also a big
improvement as shown in the screenshot below. In the action pane on the right of Event Viewer, click Filter current event log to access the filter. For the
Security log, the only event source available is
Microsoft Windows security
auditing
. You must choose this source in the Event sources drop-down box
before you can see and choose which subcategories (called task categories in
this GUI) to filter.

You can use a filtered view to save a subset of event logs
for further analysis. You can save a filtered view for later use as a custom
view.

DS access

The two settings below are valid only for domain controllers and record any access or changes to objects having a system access control list (SACL) in Active Directory.

Audit Directory Service Access: Success, Failure

Audit Directory Service Changes: Success, Failure

Event 5136 shows my modification to the Domain Admins group (Object) when my account, named leos (Attribute), was added (Operation).

Directory Service changes event 5136

Настройка аудита изменений учетных записей и групп Active Directory

В данном случае, нас интересует категория Account Management, позволяющая включить аудит изменений в группах Audit Security Group Management) и аудит учетных записей пользователей (политика Audit User Account Management). Активируем данные политики аудита, задав отслеживание только успешных изменений (Success).

Осталось прилинковать данную политику к контейнеру, содержащему учетные записи контроллеров домена (по умолчанию это OU Domain Controllers) и применить эту политику (выждав 90 минут или выполнив команду gpupdate /force).

После применения данной политики информация обо всех изменения в учетных записях пользователей и членстве в группах будет фиксировать на контроллерах домена в журнале Security. На скриншоте ниже отображено событие, фиксирующие момент удаления пользователя из групп Active Directory (в событии можно увидеть кто, когда и кого удалил из группы).

По умолчанию журнал отображает все события безопасности, попавшие в лог. Чтобы упростить поиск нужного события, журнал можно отфильтровать по конкретному Event ID. В том случае, если нас интересуюсь только события, например, качающиеся сброса пароля пользователя в домене, необходимо включить фильтр по id 4724.

Ниже приведен список некоторых ID событий, которые могут понадобиться для поиска и фильтрации событий в журнале Security практике:
ID событий, в контексте изменений в группах AD:

4727 : A security-enabled global group was created.
4728 : A member was added to a security-enabled global group.
4729 : A member was removed from a security-enabled global group.
4730 : A security-enabled global group was deleted.
4731 : A security-enabled local group was created.
4732 : A member was added to a security-enabled local group.
4733 : A member was removed from a security-enabled local group.
4734 : A security-enabled local group was deleted.
4735 : A security-enabled local group was changed.
4737 : A security-enabled global group was changed.
4754 : A security-enabled universal group was created.
4755 : A security-enabled universal group was changed.
4756 : A member was added to a security-enabled universal group.
4757 : A member was removed from a security-enabled universal group.
4758 : A security-enabled universal group was deleted.
4764 : A group’s type was changed.

ID событий, в контексте изменений в учетных записей пользователей в AD:

4720 : A user account was created.

4722 : A user account was enabled.
4723 : An attempt was made to change an account’s password.
4724 : An attempt was made to reset an account’s password.
4725 : A user account was disabled.
4726 : A user account was deleted.
4738 : A user account was changed.
4740 : A user account was locked out.
4765 : SID History was added to an account.
4766 : An attempt to add SID History to an account failed.
4767 : A user account was unlocked.
4780 : The ACL was set on accounts which are members of administrators groups.
4781 : The name of an account was changed:
4794 : An attempt was made to set the Directory Services Restore Mode.
5376 : Credential Manager credentials were backed up.
5377 : Credential Manager credentials were restored from a backup.

Account logon

Audit Credential Validation: Success, Failure

Allows you to audit events generated by validation tests on user account logon credentials. For domain accounts, the event is generated on the domain controller. Causes a high volume of events.

Using Event Viewer to Configure the Security Log

Aside from using Event Viewer to view security events, you
use it to configure the maximum size of the Security log. Right-click Security
in the left pane, then select Properties to open the Log Properties
dialog box shown below.

Windows will not grow the log beyond the size you specify. Nowadays you can set log sizes very large – even in gigabytes.

No matter which maximum size you configure, the log will
eventually reach it. You can configure Windows to do one of three things at
that point. Don’t choose the Do not overwrite events (Clear logs manually)option; if you do, Windows will just stop
logging events when the log reaches its maximum size. (Although you can use the
CrashOnAuditFail option to configure Windows to crash when logging stops, we
don’t recommend this approach for most commercial scenarios. See http://support.microsoft.com/kb/823659 for details
about CrashOnAuditFail.)
The Archive the log when full, do not overwrite
events
option is also useful, perhaps for a small group of servers, but you
will need to attend to it periodically so that the logs don’t fill the storage
location to capacity. However, this feature is no substitute for a full log-management
solution that moves logs to separate and secured archive.

That leaves the
Overwrite events as needed (oldest
events first)
option, which we select for nearly every project. (This is
where log-management applications come into play: You’ll need one if you want
to store a large quantity of events from multiple servers. You can learn about
good log-management applications during the sponsor presentations in our
monthly Security log webinars, which you can find at www.ultimatewindowssecurity.com/securitylog.)

Note that the Log Properties dialog box also displays the
log file’s location and current size, as well as various dates and times that
are associated with the log. From this dialog box, you can also clear the log.
When you clear the Security log, Windows immediately logs event ID 1102.
Although this event falls under the Audit system events category,
Windows always logs the event, regardless of your audit policy. When you clear
the log, Event Viewer gives you the option of saving a copy first.

You can use Event Viewer to dump the Security log to a
file, either in the process of clearing the log or independently. Right-click Security
in the left pane and select Save As to choose the format in which to
save the log. If you specify event file (EVTX) format, Event Viewer will save a
copy of the log in the same EVTX format that the live log uses. If you use this
format, you’ll need to use a tool that supports EVTX files, such as LogParser
or the Event Viewer itself. You can also specify comma-separate value (CSV) or
tab-delimited (TXT) format.

Note that when you save the Security log, Windows requires
you to save it to a local volume of the server. You can subsequently copy the
file elsewhere on the network, but the dump application programming interface API
that Event Viewer uses can save the log only to a local volume. By default,
Event Viewer stores the Security log as %systemroot%\System32\Winevt\Logs\Security.evtx,
but you can change the location by editing the registry.
Microsoft usually warns against editing the registry
and encourages you to back up the system first.

That being said,
here’s the procedure:

1. Open a registry editor
2. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security subkey
3. Set the File value to any path name on the local system. (The File value is data type REG_EXPAND_SZ, so you can include environment variables in the path name.)

Why would you want to change the location of the log file?
Perhaps you want to offload the file I/O that is associated with the Security
log to a different volume.

Event Viewer occasionally will report that the Security
log is corrupt and will refuse to display it. Usually, all you need to do to
make the problem go away is close and re-open Event Viewer.

Account management

Account management settings allow administrators to track changes and events to detect malicious, authorized, or accidental activities.

Audit Application Group Management: Success, Failure

Audit Distribution Group Management: Success, Failure

Audit Security Group Management: Success, Failure

These settings enable corresponding group management activities, such as security group creation, adding or removing users, and so forth.

Audit Computer Account Management: Success, Failure

Audit User Account Management: Success, Failure

Audit computer and user account management, such as user account creation, password reset attempts, account was disabled, and SID history changes.

Using Event Viewer to View Events

The preceding audit policies allow you to fire up the
Windows auditing function. But when Windows starts sending events to the
Security log, you need a way to view them. The only built-in tool for accessing
the Security log is the MMC Event Viewer snap-in as seen below.

By default, Event Viewer
displays the local computer’s event logs, but you can easily use the console to
view the logs of other computers on the network. (You must have Manage
auditing and security log
and Access this computer from the network user rights on the target system.) To view
another computer’s logs, right-click the root in the left pane, and select
Connect
to another computer
.

On the preview pane’s General tab, Event Viewer shows more
information about each event; select the Details tab to see all of the
information. You might also want to open the event’s Properties for a different
view of the information as shown below.

You’ll see standard fields (called System fields) and a Details field in the upper
scroll box of the Properties General tab. System fields in the lower section of
the tab display the event ID, the date and time that the event occurred,
whether the event is a Success or Failure (look in the Keywords field), the
event’s source, and the event’s category (in the Task Category field).

All events in the Security log list the source as
Security, with the exception of events That have to do with the logging
mechanism itself (the source for those tasks is Eventlog). Security events fall
into 50 task categories, which correspond to the 50 audit policy subcategories.
The User field isn’t typically of much value because many events simply list N/A.

Select the Details tab for a different view of the
information. This is where you’ll find the valuable information about the
event. You can choose a “friendly” view or you can see the data in
XML format as displayed below.

When you view an event’s details, you are actually seeing
two types of information that have been merged. Each event ID has a static
description that contains defined placeholders; dynamic strings of information
that are connected with a particular instance of the event are merged into
these placeholders. Take a look at the information for an instance of event ID
4624. This is the output that you’ll see when you use the Details
tab’s Copy button. The information appears twice, first in the “friendly”
format and then in XML format. Note that the fields offer a combination of
static information that appears in every event and dynamic information that is
inserted as the event is constructed.

Microsoft attempts to explain some of these event fields, but for a much more detailed
(and clear) explanation, see our wiki.

The EventData section appears toward the end of this
output. You need to understand how this section works because it is in this
section that the important event details reside. In the case of event ID 4624,
you must look at string 6 to determine the name of the user who logged on
(LAB2008$). String 9 tells you the type of logon that was attempted (type 3—a
network logon). These dynamic strings are also important when you have a
Security log–management solution or want to use a utility, such as Microsoft
LogParser, to analyze the log. Many of the typical alerts that such solutions
let you define require criteria that are based in part on one or more strings
from an event’s description. In most cases, filtering based on event ID alone
isn’t sufficient. When designing a report that is based on the Security log,
you’ll often find that you need to parse one of the report columns from a
string in the event’s description. If you are shopping for a Security
log–management product, make sure that it provides the flexibility to create
alert criteria and reports that are based on specific string numbers within the
description.

Searching for Events

The Find feature provides a useful way to correlate
events. In the action pane on the right of Event Viewer, click
Find to access this feature. For example, you can search for a logon ID to find
when a user logged on, the audited objects that the user accessed, and when the
user logged off as shown below. If the filter or Find functions are slow, try
limiting the time period that is specified in the Logged drop-down box to
reduce the number of events that must be processed.

Policy change

Audit Policy Change: Success, Failure

Reports changes to system audit policy changes, such as enabling DS access auditing.

Audit policy change

Audit Authentication Policy Change: Success

Audits changes such as domain trust creation, modification, or removal, as well as granting user rights to allow logon locally, via Remote Desktop Services or as a batch job.

Audit Authorization Policy Change: Success

Audits changes not covered in the Authentication Policy Change, mentioned above, such as changes to the Encrypted File System policy or SeCreateTokenPrivilege (create a token object).

Расширенные политики аудита Windows

Создадим новый объект GPO (групповую политику) с именем «Audit Changes in AD». Перейдите в раздел редактирования и разверните ветку Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, который можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security Settings\Advanced Audit Policy Configuration сгруппированы в 10 категориях:

• Account Logon – аудит проверки учетных данных, службы проверки подлинности Kerberos, операций с билетами Kerberos и других события входа
• Account Management – отслеживание изменений в учетных записей пользователей и компьютеров, а также информации о группах AD и членстве в них
• Detailed Tracking – аудит активности индивидуальных приложений (RPC, DPAPI)
• DS Access – расширенный аудит изменений в объектах службы Active Directory Domain Services (AD DS)
• Logon/Logoff – аудит интерактивных и сетевых попыток входа на компьютеры и сервера домена, а также блокировок учетных записей
• Object Access – аудит доступа к различным объектам (ядру, файловой системе и общим папкам, реестру, службам сертификации и т.д.)
• Policy Change – аудит изменений в групповых политиках
• Privilege Use — аудит прав доступа к различным категориям данных
• System – изменения в настройках компьютеров, потенциально критичных с точки зрения безопасности
• Global Object AccessAuditing – позволяют администратору создать собственное списки ACL, отслеживающие изменения в реестре и файловой системой на всех интересующих объектах

Естественно, чтобы не перегружать систему лишней работой, а журналы ненужной информацией, рекомендуется использовать лишь минимально необходимый набор аудирумых параметров.

Audit policy vs advanced audit policy

Configuration of the audit policy was the only option available prior to Windows Server 2008 R2.

Audit policy configuration

The capabilities of the audit policy were limited, so Microsoft introduced the advanced audit policy. The advanced audit policy enables more granularity with regard to the events that should be collected. There are 10 categories with more than 50 options to configure.

Advanced Audit Policy configuration

The rule of thumb here is only to configure the advanced audit policy, as configuring both can lead to unexpected events.

Let’s take a look at each category and the best practice for its configuration. The convention is:

Name of the setting: recommended value

Top-Level Auditing

For the moment, let’s suppose that you have disabled the
Audit:
Force audit policy subcategory settings (Windows Vista or later) to override
audit policy category settings
option, and let’s examine the nine top-level
audit policy settings one by one. We’ll delve into the granular subcategory
settings later.

Audit Account Logon Events

Microsoft should have named the
Audit account logon
events
policy Audit authentication events. On DCs, this policy
tracks all attempts to log on with a domain user account, regardless of the
attempt’s origination. On a workstation or member server, the policy records
any logon attempt that uses a local account that is stored in the computer’s
Security Account Manager (SAM).

The policy has four
subcategories:

• Credential Validation
• Kerberos Authentication Service
• Kerberos Service Ticket Operations
• Other Account Logon Events

We’ll discuss this policy and its subcategories in detail
in Chapter 4.

Audit Logon Events

The Audit logon events audit policy actually
controls the Logon/Logoff category. The policy’s main objective is to record
all attempts to use either a domain account or a local account to log on to or
off of the local computer. On DCs, this policy records attempts to access the
DC only. The policy does not, for example, track a user who uses a domain
account to log on at a workstation. (In that case, the user isn’t logging on to
the DC; the DC is simply authenticating the user.) In such an instance, a
network logon event (event ID 4624) would appear in the DC’s Security log
because to apply Group Policy for the user, the workstation must log on as the
user to the DC. But to track all domain account authentication, you should use the
Audit account logon events policy.

The policy has nine subcategories:

• Logon
• Logoff
• Account Lockout
• IPsec Main Mode
• IPsec Quick Mode
• IPsec Extended Mode
• Special Logon
• Other Logon/Logoff Events
• Network Policy Server

As you can see, some of these subcategories have nothing
to do with logons or logoffs. We’ll discuss this policy and its subcategories in
detail in Chapter 5.

Audit Process Tracking

The Audit process tracking policy records events in
the Detailed Tracking category. This policy’s primary purpose is to track each
program that is executed by either the system or by end users. You can even
determine how long the program was open. You can tie this policy, the
Audit
logon events
policy, and Audit object access policy together by
using the Logon ID, Process ID, and Handle ID fields within various event
descriptions, thereby painting a detailed picture of a user’s activities.

The policy has four
subcategories:

• Process Creation
• Process Termination
• DPAPI Activity
• RPC Events

We’ll discuss this policy and its subcategories in detail
in Chapter 6.

Audit Object Access

The Audit object access policy handles auditing
access to all objects that reside outside of AD. The first use you might think
of for this policy is file and folder auditing. You can also use the policy to
audit access to any type of Windows object, including registry keys, printers,
and services.

Furthermore, to audit access to an object such as a
crucial file, you must enable more than just this policy; you must also enable
auditing for the specific objects that you want to track. To configure an
object’s audit policy:

1. Open the object’s Properties dialog box.
2. Select the Security tab
3. Click Advanced.
4. Select the Auditing tab as shown below

However, be warned: This policy can bog down servers.
Audit only crucial objects and audit only for crucial access (e.g., Write
access).

The policy has 11
subcategories:

• File System
• Registry
• Kernel Object
• SAM
• Certification Services
• Application Generated
• Handle Manipulation
• File Share
• Filtering Platform Packet Drop
• Filtering Platform Connection
• Other Object Access Events

We’ll discuss this policy and its subcategories in detail
in Chapter 7.

Audit Account Management

The Audit account management policy, which you can
use to monitor changes to user accounts and groups, is valuable for auditing
the activity of administrators and Help desk staff. This policy logs password
resets, newly created accounts, and changes to group membership; one of the Account
Management category’s subcategories, Other Account Management Events, logs
changes to lockout and password policy. On DCs, the policy logs changes to
domain users, domain groups, and computer accounts. On member servers, the
policy logs changes to local users and groups.

The policy has six subcategories:

• User Account Management
• Computer Account Management
• Security Group Management
• Distribution Group Management
• Application Group Management
• Other Account Management Events

We’ll discuss this policy and its subcategories in detail
in Chapter 8.

Audit Directory Service Access

The primary purpose of the
Audit directory service
access
policy is to provide a low-level audit trail of changes to objects in
AD. By using this policy, you can identify exactly which fields of a user
account, or any other AD object, were accessed.

The policy tracks the same activity as does the
Audit
account management
policy, but at a much lower level. The information that
Audit
account management
provides is better used for monitoring the maintenance
of user accounts and groups. Using the Audit directory service access policy
is the only way to track changes to OUs and GPOs—an important task for
change-control purposes.

The policy has four subcategories:

• Directory Service Access
• Directory Service Changes
• Directory Service Replication
• Detailed Directory Services Replication

We’ll discuss this policy and its subcategories in detail
in Chapter 9.

Audit Privilege Use

The Audit privilege use policy tracks the exercise
of user rights. Microsoft uses the terms privilege, right, and permission
inconsistently. In this policy’s case, privilege refers to the user
rights that you find in the Local Security Policy (under Security Settings\Local
Policies\User Right Assignment). This policy generates a lot of noise; we
usually recommend that you leave it disabled.

The policy has three subcategories:

• Sensitive Privilege Use
• Non Sensitive Privilege Use
• Other Privilege Use Events

We’ll discuss this policy and its subcategories in detail
in Chapter 10.

Audit Policy Change

The primary purpose of the Audit policy change policy
is to notify you of changes to important security policies on the local system.
Such changes include changes to the system’s audit policy or, if the local
system is a DC, changes to trust relationships.

The policy has six subcategories (one of which has the
same name as the top-level policy):

• Audit Policy Change
• Authentication Policy Change
• Authorization Policy Change
• MPSSVC Rule Level Policy Change
• Filtering Platform Policy Change
• Other Policy Change Events

We’ll discuss this policy and its subcategories in detail
in Chapter 11.

Audit System Events

The Audit system events
policy logs several miscellaneous security events. The policy has five
subcategories:

• Security State Change
• Security System Extension
• Security Integrity Events
• IPsec Driver Events
• Other System Events

We’ll discuss this policy and its subcategories in detail
in Chapter 12.

Attach Task

The ability to attach a task to
an event is a handy feature in Windows.
The
simplest method is to select the desired event in Event Viewer and then click
the Attach Task To This Event option in the actions pane. This action starts
the Create Basic Task wizard. The wizard asks you to name the task and prompts
you to define the program, email message, or display message that you want to occur when that event ID is
logged. After you complete the wizard, you can view the event, its properties,
and its history by opening the MMC Task Scheduler snap-in, which you can fine
on the Start Menu under All Programs\Accessories\System Tools.

Often, though, you’ll need to be a little more specific
with your trigger criteria than simply specifying an event ID. The good news? Any
criteria that you can specify in a custom view filter, including advanced XML
filters, can also be specified in an event trigger. The bad news? You can’t use
Event Viewer to create the trigger—you must use Task Scheduler instead:

1. Open Task Scheduler
2. Click Create Task
3. On the General tab, specify the name and description of the event, as well as which account the task should execute under

Audit Policy Categories

Each Windows system on your network
has nine audit policy categories and 50 policy subcategories, which you can
enable or disable. (Windows NT has only seven categories; Windows 2003 has nine
categories but no subcategories.) Look at the Local Security Policy. You will
see policy settings for only the main categories:

• Audit account logon events
• Audit logon events
• Audit account management
• Audit directory service access
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events

An event in the Windows Security log has a keyword
for either Audit Success or Audit Failure. When you enable an audit policy
(each of which corresponds to a top-level audit category), you can enable the
policy to log Success events, Failure events, or both, depending on the policy.
All nine audit policies generate Success events, but only some policies
generate Failure events.

Don’t fall
for the recommendation to enable only Failure events for each category. A
common misconception is that a Failure-only audit policy will alert you to all
suspicious events. In reality, many of the most important events in the
Security log—events such as changes to critical user accounts and groups,
account lockouts, and changes to security settings—are Success events.

To view a system’s audit policy settings, you can open the
MMC Local Security Policy console on the system and drill down to Security
Settings\Local Policies\Audit Policy as shown below.

When you
open an audit policy, you may or may not be able to modify it, depending on
whether the policy has been defined in a GPO that has been applied to the local
system. In the example below, only Audit process tracking
can be changed. The other policies have been set by a group policy. If the
computer is a member of an AD domain, then the computer automatically applies
appropriate GPOs from the domain. Any policy that is defined in a GPO overrides
policies that are defined in the system’s Local Security Policy object and
becomes the effective setting.

Windows always displays the effective settings
in the MMC Local Security Policy console. (If you can modify a setting, then
you know that the policy hasn’t been defined in any applicable GPOs that are
defined in AD. When set by Group Policy, a scroll icon appears next to the
setting.) We recommend that you use the Local Security Policy console only to view
a system’s audit policy—not to configure it.

As with all security settings, the best practice is to use
Group Policy to centrally manage your audit policy. Using local settings can be
risky: A group policy could override the local policy settings. Microsoft warns
you of this behavior on each policy’s Local Security Setting tab shown below.

Security log configuration

A properly configured audit policy will generate quite a lot of events, especially on servers such as domain controllers or file servers that are frequently accessed. Audit events are written to the Windows Security log. The default maximum log size, which is 128 MB, can only store a few hours’ worth of data on a frequently used server. Be sure to configure the maximum size large enough to give you at least few days’ worth of events. Ideally, the best practice is to forward specific events to systems such as SCOM, SysLog, or other SIEM tools.

Another item to configure is the retention method. The default option, if not defined by GPO, is Overwrite events as needed. With this configuration, you can be sure that events are always recorded and the log will not run out of space. On the other hand, if you do not forward events, they will be lost once overwritten.

Retention methods for the security log

With the other two options, you need to make sure the log can store a specific number of days or manually take care of the clearing.

Audit Policy Subcategories

What about subcategory settings? The big advantage of
using subcategories is the ability to limit the number of events that result
from the related category, thus reducing (though not eliminating) unnecessary
noise.

You can control these policies in Group Policy under Advanced Audit Policy Configuration.

You can
also use Auditpol to determine which subcategories are being audited. If you
are performing a baseline of a system, Auditpol gives you the ability to see
what is really happening. Take a look at an example of what you will see when
you use the auditpol /get /category:* command.

But by default, subcategory settings will take effect only
if the top-level policy is undefined. However, you can reverse this behavior by
enabling the Audit: Force audit policy subcategory settings (Windows Vista
or later) to override audit policy category settings security option as shown below.

Note that the default installation of this option is
actually Not defined rather than Disabled, as the option’s Explain tab
states. We strongly recommend that you set this option to be either Enabled or Disabled,
for consistent auditing across your enterprise. If this option is enabled and
you set a policy subcategory, then no category policy will override it. The
subcategory setting will take over on Windows
systems. (Subcategories cannot be set on earlier Windows versions, so only
policy categories are effective on legacy systems.) If this option is enabled but
you haven’t specifically configured any subcategory settings for a policy,
those subcategories will follow the main category policy. This complex
hierarchy of setting priorities can yield unintended results.

Don’t rely on the Local Security Policy console or GPMC
alone to determine what is being audited. The Auditpol command will tell you
exactly what’s happening. Just make sure that Group Policy has already been
applied when you use Auditpol. (Group Policy might take some time to replicate
and to be applied after a change).

Conclusion

Over the years, Microsoft has integrated really powerful auditing capabilities into Windows Server systems. As you can see, it is possible to audit pretty much everything. Please be aware that, as always with security, you need to find a working balance for your environment. If you configure the audit policy as mentioned in this article, but your security log maximum size is only 256 MB with no event forwarding, you will find yourself just a couple of hours of logs, which is pretty much useless.

Похожее:

Почему не применяется групповая политика, решаем за минуту “net user” Command Tutorial 5 Ways to See All User Accounts Existing on Windows 10 Аудит успехов это