CCNA Windows Automation And Auditing Questions

This command uses auditpol to configure the Logon/Logoff category to audit both successful and failed events. It directly addresses the requirement to log all authentication attempts, including failed logons, by setting both success and failure auditing. This is the correct way to enable auditing for the specified category, ensuring compliance with the organization's policy.

A SACL defines which users or groups and which access types (e.g., Write, Delete) should be audited. You must set a SACL on each file or folder you want to monitor. This is done via the file's Properties -> Security -> Advanced -> Auditing tab. Without a SACL, no auditing occurs for that object, even if the audit policy is enabled.

The display lists 'Success and Failure' under the credential validation subcategory. This confirms that the security policy is set to log every authentication event, allowing for full visibility into legitimate login patterns and potential unauthorized access attempts targeting user credentials.

Advanced Audit Policy Configuration provides granular control over object access auditing. Enabling the Audit File System subcategory allows you to log file read/write events only when a system access control list (SACL) is set on the target folder. This minimizes noise by targeting the specific subcategory rather than the broad legacy policy, and it is the necessary first step before configuring the SACL on the folder itself.

Enabling Success and Failure auditing for the Account Management subcategory captures events such as user account creation (Event ID 4720) and group membership changes (Event ID 4728/4732). This directly addresses the scenario by logging both successful and failed attempts to create or modify local accounts, which is necessary to detect an attacker adding a local administrator. It also provides a balance of visibility without enabling entire categories that would generate excessive noise.

Event ID 4624 is logged on the local computer when a logon session is created. It includes the Logon Type, which indicates how the logon occurred. For interactive logons, the Logon Type is 2. By filtering 4624 events with Logon Type 2 on the domain controller, you can identify which accounts were used for interactive logons, directly answering the scenario.

This is the correct command-line utility used to query the system's current advanced audit policy. It outputs the status of all audited categories, allowing administrators to confirm that required auditing features are active across the entire system for comprehensive security coverage.

This command filters services where the StartType is 'Automatic' and the Status is not 'Running'. It directly returns the list of automatic services that are stopped or in another non-running state. The Where-Object cmdlet evaluates each service object, and the condition uses -and to combine both criteria. This is the most straightforward and accurate way to achieve the goal.

Centralizing logs is crucial because local logs can be cleared by an attacker to hide their tracks. A SIEM ensures that logs are stored securely off-host, allowing for correlation and analysis that would be impossible if limited only to local disk space.

This Group Policy setting configures the source computers to forward events to a specific collector. It specifies the collector's FQDN and the subscription manager, enabling automatic forwarding of security events. This is the correct method to centrally collect logs from many workstations without manual configuration on each machine, and it supports filtering and scalability for enterprise environments.

This event explicitly indicates that a logon session has been assigned special privileges. It is the definitive audit log entry for identifying administrative access at the moment of login, providing a clear trail for security analysts monitoring for unauthorized privilege usage.

Using separate accounts ensures that each administrator's actions are logged under their unique account. This allows auditing and traceability. Shared accounts prevent attribution. By implementing individual accounts, you can track who performed which action. This is a fundamental principle of accountability and directly solves the scenario's requirement.

GPOs provide the primary mechanism for applying security policies and configurations across a domain. They allow for granular control and automated enforcement, ensuring that hardening standards are consistently applied to all managed workstations and servers in the environment.

The AllSigned policy mandates that all scripts, including local ones, must be digitally signed by a trusted publisher. This is the recommended security posture for preventing unauthorized script execution and ensuring integrity, making it a critical hardening step for any secure environment.

This cmdlet allows an auditor to list all members of the local Administrators group. Monitoring this group is vital, as attackers often add malicious accounts or elevated service accounts to maintain control over the compromised host during the post-exploitation phase.

The EnableScriptBlockLogging registry value, when set to 1, enables script block logging. This causes PowerShell to log script blocks to the Windows Event Log, specifically Event ID 4104. This is the correct value to configure under the ScriptBlockLogging key. It is a common security control to detect malicious scripts and is often set via Group Policy or manually.