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.

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.

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

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 vs advanced audit policy

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

Audit policy configuration

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

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

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.

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.

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.

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

Directory Service changes event 5136


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).

Policy change

Audit Policy Change: Success, Failure

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

Audit policy change

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).

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.


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.

Subscribe to 4sysops newsletter!


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.



Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account