mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-29 05:37:22 +00:00
staging problem solving
This commit is contained in:
parent
0f5d3ece63
commit
eefae2862a
@ -256,7 +256,7 @@ 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.
|
||||
@ -264,6 +264,7 @@ Compromise to an organization's data resources can cause tremendous financial lo
|
||||
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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user