deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-23 22:33:41 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'public' into patch-222

Browse Source
This commit is contained in:
VARADHARAJAN K
2021-11-27 22:02:06 +05:30
committed by GitHub
parent c48ec1f381 87b4db8cb2
commit e1a89b7d3a
253 changed files with 16122 additions and 34978 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
windows/security/threat-protection/auditing/advanced-security-audit-policy-settings.md
View File

@ -18,24 +18,33 @@ ms.date: 09/06/2021
ms.technology: windows-sec
---
# Advanced security audit policy settings
# Advanced security audit policy settings (Windows 10)
This reference for IT professionals provides information about the advanced audit policy settings that are available in Windows and the audit events that they generate.
This reference for IT professionals provides information about:
- The advanced audit policy settings available in Windows
- The audit events that these settings generate.
The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as:
- A group administrator has modified settings or data on servers that contain finance information.
- An employee within a defined group has accessed an important file.
- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access.
- The correct system access control list (SACL) - as a verifiable safeguard against undetected access - is applied to either of the following:
- every file and folder
- registry key on a computer
- file share.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local computer or by using Group Policy.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for the following types of behaviors:
- That are of little or no concern to you
- That create an excessive number of log entries.
In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
Audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** are available in the following categories:
## Account Logon
Configuring policy settings in this category can help you document attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and events, which track attempts to access a particular computer, settings and events in this category focus on the account database that is used. This category includes the following subcategories:
Configuring policy settings in this category can help you document attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and events, Account Logon settings and events focus on the account database that is used. This category includes the following subcategories:
- [Audit Credential Validation](audit-credential-validation.md)
- [Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md)
@ -55,7 +64,11 @@ The security audit policy settings in this category can be used to monitor chang
## Detailed Tracking
Detailed Tracking security policy settings and audit events can be used to monitor the activities of individual applications and users on that computer, and to understand how a computer is being used. This category includes the following subcategories:
Detailed Tracking security policy settings and audit events can be used for the following purposes:
- To monitor the activities of individual applications and users on that computer
- To understand how a computer is being used.
This category includes the following subcategories:
- [Audit DPAPI Activity](audit-dpapi-activity.md)
- [Audit PNP activity](audit-pnp-activity.md)
@ -91,7 +104,7 @@ Logon/Logoff security policy settings and audit events allow you to track attemp
## Object Access
Object Access policy settings and audit events allow you to track attempts to access specific objects or types of objects on a network or computer. To audit attempts to access a file, directory, registry key, or any other object, you must enable the appropriate Object Access auditing subcategory for success and/or failure events. For example, the file system subcategory needs to be enabled to audit file operations, and the Registry subcategory needs to be enabled to audit registry accesses.
Object Access policy settings and audit events allow you to track attempts to access specific objects or types of objects on a network or computer. To audit attempts to access a file, directory, registry key, or any other object, enable the appropriate Object Access auditing subcategory for success and/or failure events. For example, the file system subcategory needs to be enabled to audit file operations; the Registry subcategory needs to be enabled to audit registry accesses.
Proving that these audit policies are in effect to an external auditor is more difficult. There is no easy way to verify that the proper SACLs are set on all inherited objects. To address this issue, see [Global Object Access Auditing](#global-object-access-auditing).
@ -114,7 +127,7 @@ This category includes the following subcategories:
## Policy Change
Policy Change audit events allow you to track changes to important security policies on a local system or network. Because policies are typically established by administrators to help secure network resources, monitoring changes or attempts to change these policies can be an important aspect of security management for a network. This category includes the following subcategories:
Policy Change audit events allow you to track changes to important security policies on a local system or network. Because policies are typically established by administrators to help secure network resources, tracking changes (or its attempts) to these policies is an important aspect of security management for a network. This category includes the following subcategories:
- [Audit Audit Policy Change](audit-audit-policy-change.md)
- [Audit Authentication Policy Change](audit-authentication-policy-change.md)
@ -133,7 +146,11 @@ Permissions on a network are granted for users or computers to complete defined
## System
System security policy settings and audit events allow you to track system-level changes to a computer that are not included in other categories and that have potential security implications. This category includes the following subcategories:
System security policy settings and audit events allow you to track the following types of system-level changes to a computer:
- Not included in other categories
- Have potential security implications.
This category includes the following subcategories:
- [Audit IPsec Driver](audit-ipsec-driver.md)
- [Audit Other System Events](audit-other-system-events.md)
@ -144,9 +161,11 @@ System security policy settings and audit events allow you to track system-level
## Global Object Access Auditing
Global Object Access Auditing policy settings allow administrators to define computer system access control lists (SACLs) per object type for the file system or for the registry. The specified SACL is then automatically applied to every object of that type.
Auditors will be able to prove that every resource in the system is protected by an audit policy by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Auditors can prove that every resource in the system is protected by an audit policy. They can do this task by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Resource SACLs are also useful for diagnostic scenarios. For example, setting the Global Object Access Auditing policy to log all the activity for a specific user and enabling the policy to track "Access denied" events for the file system or registry can help administrators quickly identify which object in a system is denying a user access.
Resource SACLs are also useful for diagnostic scenarios. For example, administrators quickly identify which object in a system is denying a user access by:
- Setting the Global Object Access Auditing policy to log all the activities for a specific user
- Enabling the policy to track "Access denied" events for the file system or registry can help
> [!NOTE]
> If a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the Global Object Access Auditing policy. This means that an audit event is generated if an activity matches the file or folder SACL or the Global Object Access Auditing policy.

24
windows/security/threat-protection/auditing/advanced-security-auditing-faq.yml
View File

@ -17,7 +17,7 @@ metadata:
ms.topic: conceptual
ms.date: 11/10/2021
ms.technology: mde
sections:
- name: Ignored
@ -25,7 +25,7 @@ sections:
- question: |
What is Windows security auditing and why might I want to use it?
answer: |
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is more narrowly defined as the features and services that enable an administrator to log and review events for specified security-related activities.
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is the features and services for an administrator to log and review events for specified security-related activities.
Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks. Monitoring these events can provide valuable information to help administrators troubleshoot and investigate security-related activities.
@ -52,16 +52,16 @@ sections:
> **Important**  Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
 
- question: |
How are audit settings merged by Group Policy?
answer: |
By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked at a lower level.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of extra settings. To accomplish this customization, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This coverage means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
| Auditing subcategory | Setting configured in an OU GPO (higher priority) | Setting configured in a domain GPO (lower priority) | Resulting policy for the target computer |
@ -80,7 +80,7 @@ sections:
The access control model that is used in Windows is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing is not completely configured unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing is not configured entirely unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
- question: |
Why are audit policies applied on a per-computer basis rather than per user?
@ -89,7 +89,7 @@ sections:
In addition, because audit policy capabilities can vary between computers running different versions of Windows, the best way to ensure that the audit policy is applied correctly is to base these settings on the computer instead of the user.
However, in cases where you want audit settings to apply only to specified groups of users, you can accomplish this by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This can audit attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
However, when you want audit settings to apply only to specified groups of users, you can accomplish this customization by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This configuration results in an audit of attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
- question: |
What are the differences in auditing functionality between versions of Windows?
@ -108,13 +108,13 @@ sections:
A failure audit event is triggered when a defined action, such as a user logon, is not completed successfully.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may simply mean that a user mistyped his or her password.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may mean that a user mistyped the password.
- question: |
How can I set an audit policy that affects all objects on a computer?
answer: |
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This requirement has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This application of SACL can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This resultant SACL from the combination means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
- question: |
How do I figure out why someone was able to access a resource?
@ -134,7 +134,7 @@ sections:
- question: |
How can I roll back security audit policies from the advanced audit policy to the basic audit policy?
answer: |
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you subsequently change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you later change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
1. Set all Advanced Audit Policy subcategories to **Not configured**.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
@ -164,7 +164,7 @@ sections:
What are the best tools to model and manage audit policies?
answer: |
The integration of advanced audit policy settings with domain Group Policy, introduced in Windows 7 and Windows Server 2008 R2, is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy Group Policy Objects for a domain can also be used to plan and deploy security audit policies.
On an individual computer, the Auditpol command-line tool can be used to complete a number of important audit policy–related management tasks.
On an individual computer, the Auditpol command-line tool can be used to complete many important audit policy–related management tasks.
In addition, there are a number of computer management products, such as the Audit Collection Services in the Microsoft System Center Operations Manager products, which can be used to collect and filter event data.

2
windows/security/threat-protection/auditing/appendix-a-security-monitoring-recommendations-for-many-audit-events.md
View File

@ -24,7 +24,7 @@ This document, the [Advanced security audit policy settings](advanced-security-a
| **High-value accounts**: You might have high-value domain or local accounts for which you need to monitor each action.<br>Examples of high-value accounts are database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts and so on. | Monitor relevant events for the **“Subject\\Security ID”** that corresponds to the high-value account or accounts. |
| **Anomalies or malicious actions**: You might have specific requirements for detecting anomalies or monitoring potential malicious actions. For example, you might need to monitor for use of an account outside of working hours. | When you monitor for anomalies or malicious actions, use the **“Subject\\Security ID”** (with other information) to monitor how or when a particular account is being used. |
| **Non-active accounts**: You might have non-active, disabled, or guest accounts, or other accounts that should never be used. | Monitor relevant events for the **“Subject\\Security ID”** that corresponds to the accounts that should never be used. |
| **Account allow list**: You might have a specific allow list of accounts that are the only ones allowed to perform actions corresponding to particular events. | Monitor the relevant events for **“Subject\\Security ID”** accounts that are outside the allow list of accounts. |
| **Account allowlist**: You might have a specific allowlist of accounts that are the only ones allowed to perform actions corresponding to particular events. | Monitor the relevant events for **“Subject\\Security ID”** accounts that are outside the allowlist of accounts. |
| **Accounts of different types**: You might want to ensure that certain actions are performed only by certain account types, for example, local or domain account, machine or user account, vendor or employee account, and so on. | Identify events that correspond to the actions you want to monitor, and for those events, review the **“Subject\\Security ID”** to see whether the account type is as expected. |
| **External accounts**: You might be monitoring accounts from another domain, or “external” accounts that are not allowed to perform certain actions (represented by certain specific events). | Monitor the specific events for the **“Subject\\Account Domain”** corresponding to accounts from another domain or “external” accounts. |
| **Restricted-use computers or devices**: You might have certain computers, machines, or devices on which certain people (accounts) should not typically perform any actions. | Monitor the target **Computer:** (or other target device) for actions performed by the **“Subject\\Security ID”** that you are concerned about. |

8
windows/security/threat-protection/auditing/apply-a-basic-audit-policy-on-a-file-or-folder.md
View File

@ -29,7 +29,7 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
1. Select and hold (or right-click) the file or folder that you want to audit, select **Properties**, and then select the **Security** tab.
2. Select **Advanced**.
3. In the **Advanced Security Settings** dialog box, select the **Auditing** tab, and then select **Continue**.
4. Do one of the following:
4. Do one of the following tasks:
- To set up auditing for a new user or group, select **Add**. Select **Select a principal**, type the name of the user or group that you want, and then select **OK**.
- To remove auditing for an existing group or user, select the group or user name, select **Remove**, select **OK**, and then skip the rest of this procedure.
- To view or change auditing for an existing group or user, select its name, and then select **Edit.**
@ -40,7 +40,7 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
6. In the **Applies to** box, select the object(s) to which the audit of events will apply. These include:
6. In the **Applies to** box, select the object(s) to which the audit of events will apply. These objects include:
- **This folder only**
- **This folder, subfolders and files**
@ -62,9 +62,9 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
> [!IMPORTANT]
> Before you set up auditing for files and folders, you must enable [object access auditing](basic-audit-object-access.md). To do this, define auditing policy settings for the object access event category. If you don't enable object access auditing, you'll receive an error message when you set up auditing for files and folders, and no files or folders will be audited.
 
## Additional considerations
## More considerations
- After you turn on object access auditing, view the security log in Event Viewer to review the results of your changes.
- After you turn on object access auditing, view the security login Event Viewer to review the results of your changes.
- You can set up file and folder auditing only on NTFS drives.
- Because the security log is limited in size, carefully select the files and folders to be audited. Also, consider the amount of disk space that you want to devote to the security log. The maximum size for the security log is defined in Event Viewer.
 

6
windows/security/threat-protection/auditing/audit-account-lockout.md
View File

@ -29,9 +29,9 @@ This subcategory failure logon attempts, when account was already locked out.
| Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments |
|-------------------|-----------------|-----------------|------------------|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Domain Controller | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Member Server | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Workstation | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Domain Controller | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Member Server | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Workstation | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
**Events List:**

2
windows/security/threat-protection/auditing/event-4625.md
View File

@ -182,7 +182,7 @@ This event generates on domain controllers, member servers, and workstations.
| 0x0 | Status OK. |
> [!NOTE]
> To see the meaning of other status or substatus codes, you might also check for status code in the Window header file ntstatus.h in Windows SDK.
> To see the meaning of other status or substatus codes, you might also check for status code in the Windows header file ntstatus.h in Windows SDK.
More information: <https://dev.windows.com/en-us/downloads>