Windows Services and MS Cloud practice questions

LocalSystem account

Why it fails: LocalSystem is a highly privileged account that functions as the computer identity on the network. It possesses extensive rights, including full access to local resources and the ability to act as the machine in Active Directory, which violates the principle of least privilege required for basic database service operations.

NetworkService account

Why it fails: NetworkService provides limited local access but carries the computer's identity on the network. This makes it unsuitable for restricted environments because the service account's network activities are indistinguishable from the machine account, potentially granting excessive access to domain resources that the specific database application does not actually require.

LocalService account

Why it fails: LocalService is a built-in account with minimal local privileges and no network access. While secure, it lacks the specific identity features and managed nature required for modern service configurations that need to interact with local database subsystems while maintaining a secure, unique SID profile for auditing and security policy enforcement.

The Resource ARN is malformed.

Why it fails: The ARN format arn:aws:s3:::production-data/* is syntactically correct for an S3 bucket object policy. The failure is not related to the resource string, but rather to the restrictive condition logic applied to the incoming request's source IP address, which does not match the mandatory subnet provided in the policy.

The Action list is missing 's3:ListBucket'.

Why it fails: While 's3:ListBucket' is required to view objects in the console, its absence would not cause an access failure if the user is attempting a direct 's3:GetObject' operation. The primary failure point remains the restrictive IP conditional logic that prevents any request outside the defined range from executing.

The Effect is set to 'Allow' instead of 'Deny'.

Why it fails: An 'Allow' effect is necessary to grant permissions when a policy is evaluated. Changing this to 'Deny' would explicitly block access regardless of the IP address. The issue is not the effect type, but the fact that the condition is not satisfied by the requester's current network location.

Assign the Global Administrator role for maximum visibility.

Why it fails: Assigning Global Administrator to a service principal violates the principle of least privilege. An attacker compromising the service principal would gain full control over the tenant. Roles should be limited to the specific scope required for the pipeline to function, such as custom roles or specific RBAC assignments.

Rotate client secrets every 30 days.

Why it fails: While rotation is a best practice, relying on manual client secrets is inferior to using certificate-based authentication or Managed Identities. Furthermore, 30 days may be operationally burdensome; the primary focus should be moving away from secrets entirely rather than just increasing the frequency of their manual rotation.

Enable password writeback for the service principal.

Why it fails: Password writeback is a feature for hybrid identity synchronization, not for securing service principals. It has no functional role in protecting automated CI/CD processes and could introduce unnecessary complexity or security risks to the identity synchronization process between on-premises Active Directory and the cloud environment.

Disable Managed Identity and use a Service Principal.

Why it fails: Managed Identity is more secure than using a Service Principal with static credentials. Disabling it would force the use of secret-based authentication, which increases the attack surface due to the potential for credential exposure in code or configuration files, contradicting basic cloud security hardening principles.

Enable the 'Always On' feature for higher performance.

Why it fails: The 'Always On' feature is an operational optimization for performance and has no inherent security benefit. In some cases, it could actually increase the attack window by keeping the service active and reachable at all times, rather than allowing it to scale down during inactivity.

An attacker is performing a brute-force attack against the service account from a remote workstation.

Why it fails: Brute-force attacks typically generate Logon Type 3 (network) or Logon Type 10 (RemoteInteractive), not Logon Type 4. While an attacker could theoretically trigger batch logons, the repeated failures tied to a specific service account and service context strongly suggest a configuration issue rather than an external attack.

A scheduled task is running under the service account and is failing due to an expired password.

Why it fails: Scheduled tasks typically generate Logon Type 4 or 5, but an expired password would produce a different error code (e.g., 0xC0000071) and would not necessarily repeat as Logon Type 4. The scenario specifically ties the account to a service, so the failure is more directly related to the service's logon process rather than a scheduled task.

The service account password has been changed recently and the service has not been restarted to pick up the new credentials.

Why it fails: If the password was changed and the service was not updated, the service would fail to start and log errors in the System log (e.g., Event ID 7038), not repeated 4625 Logon Type 4 events in the Security log. The service would likely not attempt logon repeatedly; it would fail once at startup.

The scheduled task is running under the SYSTEM account, which does not have a user profile and therefore cannot access mapped network drives or UNC paths that require user credentials.

Why it fails: While SYSTEM lacks a user profile, it can still access UNC paths using the computer account credentials. The issue is not the lack of a profile but rather that the computer account may not have been granted the necessary rights on the remote server. However, the scenario states that share and NTFS permissions allow the computer account. So this option is incorrect because the problem is not about profile absence but about authentication context. The SYSTEM account can access network resources if the computer account is authorized, but here the script might be failing due to using the wrong credentials or because the remote server does not trust the computer account for delegation.

The SYSTEM account on the file server does not have network access because it authenticates as the computer account, but the share is on a different server and the computer account lacks the necessary permissions.

Why it fails: The SYSTEM account does use the computer account for network authentication, but the scenario states that the computer account has write permissions on the share. Therefore, lack of permissions cannot be the cause. The failure is due to the script running under SYSTEM, which cannot access network resources unless the computer account is granted access, but that is already granted. The real issue is that SYSTEM runs with high privileges locally but network access is restricted by default, and the script may be attempting to use the local SYSTEM token for network authentication, which fails because the computer account is not recognized as a valid security principal on the remote server for interactive logon. However, the computer account is valid, so the problem lies elsewhere.

The scheduled task is failing because the SYSTEM account does not have the 'Log on as a batch job' right, which is required for scheduled tasks to run and access network resources.

Why it fails: The 'Log on as a batch job' right is required for scheduled tasks, but the SYSTEM account typically has this right by default. Moreover, the failure is an access denied error when writing to the share, not a logon failure. If the task could not log on, it would not start at all. Therefore, this is not the cause. The issue is specifically about network access permissions, not the ability to log on as a batch job. The SYSTEM account already has the necessary logon rights, so this option is incorrect.

Event ID 4624

Why it fails: Event ID 4624 indicates a successful logon. While it can show logon activity, it does not specifically detect attempts to access the LSASS process. An attacker dumping credentials from LSASS would not necessarily generate a 4624 event for that action; they would generate a logon event when they initially access the system. To detect LSASS access, a different event ID is required. Therefore, this option is incorrect because it does not directly indicate credential dumping attempts.

Event ID 4663

Why it fails: Event ID 4663 indicates an attempt to access an object, such as a file or registry key, and is logged when object access auditing is enabled. While it could be used to monitor access to the LSASS process if SACL is configured, it is not the specific event ID designed for detecting LSASS access. The more direct event for LSASS access is 4656, which logs a handle to an object was requested. However, 4663 is for object access, not process handle requests. This option is incorrect because it is not the primary event for detecting LSASS process access.

Event ID 4688

Why it fails: Event ID 4688 logs the creation of a new process. While it can be used to detect the execution of tools like Mimikatz, it does not directly indicate access to the LSASS process. An attacker might use a process that accesses LSASS, but the 4688 event only shows the process creation, not the subsequent access to LSASS. To detect the actual credential dumping attempt, you need to monitor for handle requests to LSASS. Therefore, this option is not the best choice for detecting LSASS access.

The service account is not a member of the 'Log on as a service' right, preventing it from starting.

Why it fails: If the service account lacked the 'Log on as a service' right, the service would fail to start with a logon right error (e.g., Event ID 7041 or 7042), not repeated network logon failures with Logon Type 3. The 'Log on as a service' right is required for interactive service startup, but the scenario shows network authentication attempts, which occur after the service has started.

The service account is locked out due to multiple failed logon attempts.

Why it fails: Account lockout would produce Event ID 4740 (A user account was locked out) in addition to 4625, and the failure reason would be 'Account locked out.' The scenario does not mention lockout events, and lockout typically results from repeated bad password attempts, not from password expiration. The focus on password expiration makes lockout a less likely cause.

The service account's password has exceeded the maximum age defined in the domain's fine-grained password policy.

Why it fails: Fine-grained password policies apply only to user and group accounts, not to service accounts. Service accounts are typically user objects, but their passwords are managed by the service control manager and do not expire unless configured to do so. The scenario does not indicate a fine-grained policy is in use, and password expiration would not cause Logon Type 3 failures with lsass.exe as the process.

They enable Kerberos constrained delegation by default.

Why it fails: While gMSAs support Kerberos features, they do not enable constrained delegation by default. Delegation settings must be manually configured in Active Directory. The primary security benefit of gMSAs remains automated password management and reduced attack surface, rather than automated delegation configurations which could actually increase risk if mismanaged.

They bypass the need for an SPN registration.

Why it fails: gMSAs still require Service Principal Names (SPNs) for Kerberos authentication to function correctly in a domain environment. Failing to register the SPN would result in authentication failures, regardless of the account type used. The gMSA account structure does not alter the fundamental requirements of Kerberos-based authentication protocols.

They allow for local interactive logons on all domain controllers.

Why it fails: gMSAs are specifically designed for service logons and generally should not have interactive logon rights. Granting interactive access to service accounts creates a major security vulnerability, as it provides a pathway for an attacker to gain persistent, elevated access to domain controllers if the service account is successfully compromised.

Task Scheduler

Why it fails: Task Scheduler is designed to run automated scripts or programs at specific intervals. It is not an enterprise management tool for enforcing security policies or managing Windows service configurations across a domain, and using it for such tasks would lead to inconsistent security postures and management overhead.

Services.msc

Why it fails: Services.msc is a local management console. While it allows for manual service configuration, it lacks the capability to push settings to multiple machines or enforce consistent security policies, making it ineffective for managing large-scale server environments where consistency is required to mitigate potential security vulnerabilities.

Local Security Policy (secpol.msc)

Why it fails: Secpol.msc is a local configuration tool restricted to the machine it is run on. It does not provide the centralized management required for enterprise-wide security enforcement, leaving the environment vulnerable to configuration drift across different servers, which is a major risk factor in maintaining a secure infrastructure.

User-assigned identities do not require Entra ID authentication.

Why it fails: All Azure Managed Identities rely on Entra ID (Azure AD) for authentication. They provide an automatically managed identity in Microsoft Entra ID, allowing services to authenticate to other cloud resources without storing credentials, regardless of whether the identity is user-assigned or system-assigned.

System-assigned identities can be shared across multiple resources.

Why it fails: System-assigned identities are exclusively linked to a single Azure resource. They cannot be shared or reused across different VMs or services. This limitation is the primary distinction that necessitates the use of user-assigned identities when a shared access profile is required for a group of resources.

System-assigned identities provide more granular permission scopes.

Why it fails: Both types of identities support the same RBAC scopes. The difference between them is purely operational—lifecycle management and resource association—not the level of granularity or the type of security policies that can be applied to the identity within the Azure Resource Manager framework.

The service account lacks the 'Log on as a service' right.

Why it fails: If the account lacked the specific user right, the error code would typically reflect a privilege issue rather than an authentication failure. Error 0x8007052e specifically points to an incorrect credential or account status, which is a distinct problem from missing local security policy assignments on the host machine.

The network path to the domain controller is unreachable.

Why it fails: Connectivity issues to the domain controller would typically result in different network-related error codes or timeout errors. Since the system is reporting a specific logon failure, it indicates that the authentication request reached the domain controller but was rejected, rather than failing to reach the authentication service entirely.

The service binary is corrupted or missing.

Why it fails: A corrupted binary would typically result in a 'Service failed to start' error unrelated to logon credentials. The presence of a specific logon error code confirms that the service manager successfully located and attempted to execute the service, but failed during the authentication phase with the specified domain account.

Standalone Managed Service Account (sMSA)

Why it fails: An sMSA provides automatic password management but is limited to a single server. It cannot be shared across multiple servers, so it does not meet the requirement to minimize password reuse across multiple servers. Also, sMSAs are deprecated in favor of gMSAs for multi-server scenarios.

Virtual Service Account

Why it fails: Virtual accounts are local to the machine and cannot access network resources with domain credentials. They are managed automatically but do not support Kerberos authentication to remote resources. This fails both the network access and Kerberos requirements.

Local Service account

Why it fails: The Local Service account is a built-in account with minimal privileges on the local machine. It cannot authenticate to network resources using domain credentials and does not support Kerberos. It also cannot be used for services requiring domain access. This fails the network resource access requirement.

Use virtual accounts for each service.

Why it fails: Virtual accounts are local accounts that are automatically managed by the operating system and do not require password management. However, they are local to the server and cannot be used for domain-level services or across multiple servers. They also do not provide centralized management or password rotation via Active Directory.

Create standard domain user accounts and configure them with a long, complex password that never expires.

Why it fails: Standard domain user accounts with static passwords do not provide automatic password rotation and require manual management. They also increase the risk of credential theft because the password is stored locally in the service configuration. This approach violates the principle of least privilege and does not meet the requirement for automatic management.

Configure each service to use a standalone Managed Service Account (sMSA).

Why it fails: Standalone Managed Service Accounts (sMSAs) are supported only on the local server and cannot be used across multiple servers. They also do not support automatic password rotation when used on multiple servers. The requirement for domain-wide management and no local password storage is better met by a group Managed Service Account (gMSA).

Users will be unable to log on interactively to the workstation.

Why it fails: Interactive logon is handled by the Winlogon service and other components, not the Secondary Logon service. Disabling Secondary Logon does not prevent users from logging on normally with their primary credentials. It only affects the ability to start processes with alternate credentials.

Remote Desktop connections to the workstation will be blocked.

Why it fails: Remote Desktop connections depend on the Remote Desktop Services service (TermService) and related components. The Secondary Logon service is not required for RDP. Disabling it will not block Remote Desktop, although it may affect the ability to run applications as a different user within an RDP session.

The workstation will be unable to join a domain.

Why it fails: Domain join operations rely on the Netlogon service and other networking components. The Secondary Logon service is not involved in domain join. Disabling it will not prevent the workstation from joining a domain or from authenticating domain users.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost

Why it fails: There is no standard registry key named 'Svchost' under that path. Svchost.exe groups services, but its configuration is not stored in a dedicated registry key. Service configurations are stored under the Services key. Therefore, this location is incorrect and likely a distractor.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Why it fails: The Run key is used for programs that execute at user logon, not for services. Malicious services are not typically configured there. The analyst should look at the Services key instead. The Run key is a common persistence location for user-level malware, but it is not the correct location for service configurations.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Why it fails: This key is for programs that run at the logon of the current user. It is not used for services, which run under the System account or other service accounts. Malicious services would not be configured here, so this is not the correct location to investigate.

Use the Services MMC snap-in to set each service's recovery options to 'Take No Action' on failure.

Why it fails: Setting recovery options to 'Take No Action' means that if a service fails, it will not restart, potentially causing denial of service. This does not harden permissions or reduce attack surface; it simply changes failure behavior. While it might prevent a service from repeatedly failing, it does not restrict who can control the service.

Configure the service to log on as the Local System account to ensure it has all necessary privileges.

Why it fails: Running services as Local System grants excessive privileges, violating the principle of least privilege. This increases the attack surface because a compromised service would have full control over the system. The goal is to restrict permissions, not elevate them. Therefore, this action is counterproductive to hardening.

Grant the 'Everyone' group the right to start and stop services to simplify management.

Why it fails: Granting the 'Everyone' group start/stop rights would allow any user to control services, which is a severe security risk. This would increase the attack surface and violate the principle of least privilege. The administrator should restrict these permissions to specific administrative groups, not broaden them.

The event indicates a driver installation, which could cause a blue screen of death.

Why it fails: Event ID 7045 is specifically for service installation, not driver installation. Driver installations are typically logged with different event IDs, such as 20001 or 20003 in the System log. While a faulty driver can cause a system crash, this event does not indicate a driver. The risk here is not a blue screen but rather unauthorized code execution and persistence. Therefore, this option misidentifies the event type and the associated risk.

The service is likely a legitimate Windows update service, and the event can be ignored.

Why it fails: Legitimate Windows update services are typically installed by the operating system or trusted installers and reside in system directories like System32. A service binary in a user's temp folder is highly unusual and indicative of malware or unauthorized software. Assuming it is legitimate without further investigation could allow a persistence mechanism to remain undetected. Therefore, this option is incorrect because it dismisses a potential security incident based on an inaccurate assumption about the service's legitimacy.

The service installation is a sign of a Windows Update failure, and the system should be rolled back.

Why it fails: Windows Update failures are logged with different event IDs, such as 20, 21, or 22 in the WindowsUpdateClient log, not Event ID 7045. A service installation in a temp folder is not a typical update failure. Rolling back the system would not address the potential compromise. This option incorrectly associates the event with update issues and suggests an inappropriate response. The correct action is to investigate the service as a potential security incident.

Assign the 'Log on as a service' right to all domain users to ensure that any service can start without interruption.

Why it fails: Granting the 'Log on as a service' right to all domain users is a severe security misconfiguration. It would allow any user account to be used to run a service, increasing the risk of privilege escalation and lateral movement. Service accounts should be specifically designated and granted this right only when necessary. This option is incorrect because it broadens the attack surface and violates least privilege.

Configure all services to run under the Local System account to simplify management and ensure they have the necessary privileges.

Why it fails: Running services as Local System grants them extensive privileges on the local machine, which violates the principle of least privilege. If an attacker compromises such a service, they gain full control of the system. Instead, services should run under dedicated accounts with minimal rights. This option is incorrect because it increases the attack surface and does not protect against credential theft or privilege escalation; it actually exacerbates the risk.

Enable the 'Store passwords using reversible encryption' policy for all service accounts to allow easy recovery of passwords if needed.

Why it fails: Storing passwords with reversible encryption is a security risk because it allows passwords to be decrypted and read by anyone with access to the system. This policy is intended for legacy applications and should be avoided. Enabling it for service accounts would make credential theft easier, not harder. Therefore, this option is incorrect and would weaken security rather than harden it.

Set up a per-application MFA setting in the Enterprise Applications blade by enabling the 'Require multi-factor authentication' option for the specific application.

Why it fails: The 'Require multi-factor authentication' option in the Enterprise Applications blade is a legacy per-application MFA setting that is being deprecated. It only works for certain application types and does not provide the same level of control as Conditional Access. Moreover, it may not support SAML 2.0 applications in the same way. With Entra ID P1, Conditional Access is the recommended method. This option is incorrect because it relies on an outdated feature and may not meet the requirement.

Create a new authentication method policy that restricts MFA to only the users who need access to the application.

Why it fails: Authentication method policies in Entra ID control which authentication methods are available to users, but they do not enforce MFA for specific applications. They are used to manage methods like FIDO2 keys or Microsoft Authenticator. To enforce MFA for a specific app, a Conditional Access policy is required. This option is incorrect because it misidentifies the purpose of authentication method policies and does not achieve the goal.

Enable security defaults in Entra ID, which will automatically enforce MFA for all users and applications.

Why it fails: Security defaults are a set of baseline security settings that enforce MFA for all users, but they apply tenant-wide and cannot be scoped to a single application. Enabling security defaults would affect all applications and might disrupt other business processes. Additionally, security defaults are intended for organizations without Conditional Access, and since the company has P1 licenses, Conditional Access is the more appropriate and granular solution. This option is incorrect because it lacks the required granularity.