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.
+          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 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.
+          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/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,7 +62,7 @@ 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 login Event Viewer to review the results of your changes.
 -   You can set up file and folder auditing only on NTFS drives.

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. |
+| 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 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 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:**