We can implement auditing using Windows PowerShell with the Get-Acl and Set-Acl cmdlets. These allow us to view and modify the auditing options of a file or folder in Windows. While this can also be done through the graphical user interface, using PowerShell allows us to script such actions, as well as some extra functionality such as copying the auditing settings from one object to another.
This post will show you how to enable and configure module, script block, and transcription logging in Windows PowerShell. Module logging allows you to specify the PowerShell modules that you want to log. Script block stores PowerShell commands that are run without the output, while transcription logging records the PowerShell commands that are run along with the full result of the command.
We can configure the audit group membership policy using group policy, allowing us to record the group of a user in a login event log entry. This is used in addition to the Audit Logon policy to expand the information provided and include the group membership information of the user accessing the system.
In this post we’ll show you how to configure the audit PNP activity policy in Windows Server 2016 via group policy.
PNP, or Plug and Play, is used so that the operating system automatically detects and configures an external device so that it’s ready to use. A common example is when you plugin a USB storage device and it “just works”. By auditing PNP activity, we can log events every time an external device is detected.
We can enable auditing of various items in Windows Server 2016 by configuring both local audit policies and advanced audit policies with group policy. We will determine the differences and usage scenarios for using local audit policies and advanced auditing policies in this post.
We can implement auditing using group policy and auditpol.exe in Windows Server 2016. This will allow us to log very specific events that take place within the operating system. We’ll demonstrate how to configure audit policies with both of these methods here.
We can create expression-based audit policies which allow us to define a custom condition for an audit policy to apply to. The conditions that we can create are quite powerful as they use claim types and resource properties, allowing us to customize exactly how the audit policy should apply.
We can create and configure Central Access Rules and policies that are automatically deployed to all file servers in our Active Directory based domain.
Central Access Rules (CARs) are used to control access to files and folders based on the resource properties that we have created.
The central access rule uses the user and device claims with resource properties to determine the permissions that should be set on particular files.
We can create and configure resource properties and lists to specify extra properties that can be used on files and folders. A resource list simply contains one or more resource properties, both are created through Active Directory Administrative Center as we’ll see in the examples.
These are needed as part of a Dynamic Access Control (DAC) solution to create and configure central access rules.
Additional properties can be set on a file or folder using resource properties. This is similar to file classification but instead works at the domain level rather than only on the file server. We can use these resource properties to configure access to the file that they are applied to.
We can configure user and device claim types in Active Directory which can be used as part of Dynamic Access Control (DAC) in a Windows based environment.
DAC was added in Windows Server 2012 to allow administrators to configure custom authorization to a file server by using conditional logic using user and device claim types. This is quite powerful, we can have permissions to a user change and update automatically based on changes to attributes to the user or device itself.