staging problem solving

windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md

@@ -198,8 +198,8 @@ By using Group Policy, you can apply your security audit policy to defined group
 
 -   Advanced security audit policy settings were introduced in Windows Server 2008 R2 and Windows 7. These advanced audit policies can only be applied to those operating systems and later versions by using Group Policy.
 
-    > [!IMPORTANT]  
-    > Whether you apply advanced audit policies by using Group Policy or logon scripts, don't 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 basic and advanced audit policy settings can cause unexpected results in audit reporting.
+  > [!IMPORTANT]  
+  > Whether you apply advanced audit policies by using Group Policy or logon scripts, don't 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 basic and advanced audit policy settings can cause unexpected results in audit reporting.
 
     If you use **Advanced Audit Policy Configuration** settings or 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 configuration will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
      
@@ -256,14 +256,15 @@ Compromise to an organization's data resources can cause tremendous financial lo
 
     If *success* auditing is enabled, an audit entry is generated each time any account successfully accesses a file system object that has a matching SACL. If *failure* auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL. The amount of audit data generated by the **Audit File System** policy setting can vary considerably, depending on the number of objects that you configured to be monitored.
 
-    > [!NOTE]  
+    > [!NOTE]
     > To audit user attempts to access all file system objects on a computer, use the *Global Object Access Auditing* settings [Registry (Global Object Access Auditing)](registry-global-object-access-auditing.md) or [File System (Global Object Access Auditing)](file-system-global-object-access-auditing.md).
      
 -   **Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md)**: This policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Only objects with configured SACLs generate these events and only if the attempted handle operation matches the SACL.
 
     Event volume can be high, depending on how the SACLs are configured. When used together with the **Audit File System** or **Audit Registry** policy setting, the **Audit Handle Manipulation** policy setting can provide useful "reason for access" audit data that details the precise permissions on which the audit event is based. For example, if a file is configured as a *read-only* resource but a user tries to save changes to the file, the audit event will log the event *and* the permissions that were used (or attempted to be used) to save the file changes.
-
+ 
 -   **Global Object Access Auditing**: Many organizations use security auditing to comply with regulatory requirements that govern data security and privacy. But demonstrating that strict controls are being enforced can be difficult. To address this issue, the supported versions of Windows include two **Global Object Access Auditing** policy settings, one for the registry and one for the file system. When you configure these settings, they apply a global system access control SACL on all objects of that class on a system. These settings can't be overridden or circumvented.
+
     > [!IMPORTANT]
     > The **Global Object Access Auditing** policy settings must be configured and applied in conjunction with the **Audit File System** and **Audit Registry** audit policy settings in the **Object Access** category.
      
@@ -279,7 +280,7 @@ In most cases, these attempts are legitimate, and the network needs to make data
 -   **Logon/Logoff\\[Audit Account Lockout](audit-account-lockout.md)**: Another common security scenario occurs when a user attempts to log on with an account that's been locked out. It's important to identify these events and to determine whether the attempt to use an account that was locked out is malicious.
 -   **Logon/Logoff\\[Audit Logoff](audit-logoff.md)** and **Logon/Logoff\\[Audit Logon](audit-logon.md)**: Logon and logoff events are essential to tracking user activity and detecting potential attacks. Logon events are related to the creation of logon sessions, and they occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a shared resource, events are generated on the computer that hosts the resource that was accessed. Logoff events are generated when logon sessions are terminated.
 
-    >[!NOTE]
+    > [!NOTE]
     > There's no failure event for logoff activity, because failed logoffs (such as when a system abruptly shuts down) don't generate an audit record. Logoff events aren't 100-percent reliable. For example, a computer can be turned off without a proper logoff and shut down, so a logoff event isn't generated.
      
 -   **Logon/Logoff\\[Audit Special Logon](audit-special-logon.md)**: A special logon has administrator-equivalent rights and can be used to elevate a process to a higher level. It's recommended to track these types of logons.
@@ -301,7 +302,7 @@ The following network activity policy settings enable you to monitor security-re
 - **Account Management**: Use the policy settings in this category to track attempts to create, delete, or modify user or computer accounts, security groups, or distribution groups. Monitoring these activities complements the monitoring strategies you select in the [User activity](#user-activity) and [Data and resource activity](#data-and-resource-activity) sections.
 - **Account Logon\\[Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md) and Account Logon\\[Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md)**: Audit policy settings in the **Account Logon** category monitor activities that relate to the use of domain account credentials. These policy settings complement the policy settings in the **Logon/Logoff** category. The **Audit Kerberos Authentication Service** policy setting enables you to monitor the status of and potential threats to the Kerberos service. The Audit **Kerberos Service Ticket Operations** policy setting enables you to monitor the use of Kerberos service tickets.
 
-    >[!NOTE] 
+    >[!NOTE]
     >**Account Logon** policy settings apply only to specific domain account activities, regardless of which computer is accessed. **Logon/Logoff** policy settings apply to the computer that hosts the resources that are accessed.
      
 -   **Account Logon\\[Audit Other Account Logon Events](audit-other-account-logon-events.md)**: This policy setting can be used to track various network activities, including attempts to create Remote Desktop connections, wired network connections, and wireless connections.