fixed Acrolinx errors

windows/security/threat-protection/auditing/advanced-security-auditing-faq.yml

@@ -77,16 +77,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 |
@@ -105,7 +105,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?
@@ -114,7 +114,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?
@@ -133,13 +133,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?
@@ -159,7 +159,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.
@@ -189,7 +189,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.
           

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

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

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

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

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

@@ -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:**