Secure Windows Server Infrastructure practice questions

The client servers must have the BitLocker Drive Encryption feature disabled during the initial sync.

Why wrong: BitLocker Drive Encryption must be enabled for Network Unlock to function, as the feature is designed to protect existing BitLocker volumes. Disabling the feature would prevent the creation of the necessary key protectors. The Network Unlock protector is added as an additional protector to an already encrypted volume to facilitate automated reboots.

The WDS server must be running in 'Transport Server' mode only with no images.

Why wrong: While WDS is a prerequisite, it does not need to be in a specific 'Transport Server' mode for Network Unlock to function. The Network Unlock feature is a separate component that plugs into the WDS infrastructure. Having images or using full WDS functionality does not interfere with the ability of the server to process unlock requests.

The client servers must be joined to an Azure Active Directory domain specifically.

Why wrong: BitLocker Network Unlock is traditionally an on-premises Active Directory Domain Services feature and does not require Azure Active Directory. While modern systems can integrate with Azure, the specific mechanism for Network Unlock is tied to local network infrastructure like WDS and DHCP, rather than cloud-based identity providers for the unlocking process itself.

Account Logon

Why wrong: Account Logon events are generated when a domain controller validates a user's credentials. This tracks who is logging into the domain but does not provide any information about what those users do once they are authenticated, such as which files they access on a specific member server in the network.

Privilege Use

Why wrong: Privilege Use auditing tracks the exercise of specific user rights, such as changing the system time or taking ownership of files. While related to security, it does not track standard file access (read/write) events, which are handled by the Object Access category through the file system auditing subcategory.

Policy Change

Why wrong: Policy Change auditing tracks modifications to important security policies on the system, such as changes to user rights assignments or audit policies themselves. While it is vital for ensuring the integrity of the security configuration, it is not the correct category for monitoring user interactions with data files and folders.

Enable the Remote Desktop Protocol (RDP) Restricted Admin mode.

Why wrong: Restricted Admin mode for RDP prevents credentials from being stored on the remote host during a session, but it is a separate security feature. While it complements Credential Guard, it is not a technical requirement for enabling the virtualized container that Credential Guard uses for memory isolation.

Install the Windows Defender Application Guard feature.

Why wrong: Windows Defender Application Guard is designed to isolate untrusted web browsing sessions in a Hyper-V container. It relies on similar hardware virtualization capabilities but is an entirely distinct feature from Credential Guard. Installing it does not fulfill the core requirement for Credential Guard's underlying memory protection mechanism.

Disable the Windows Update service.

Why wrong: Disabling Windows Update significantly degrades the security posture of the server by preventing critical security patches and definitions. Credential Guard does not rely on the state of the Windows Update service; in fact, maintaining a fully patched system is essential for the overall integrity of the VBS environment.

Run the 'Set-SmbServerConfiguration' cmdlet with the -DisableOldProtocols switch.

Why wrong: The SMB configuration cmdlets relate only to the Server Message Block file-sharing protocol. They do not influence the protocols used for general network encryption or secure web traffic (HTTPS/TLS). While SMB security is important, this specific cmdlet has no effect on the TLS version used by other server applications.

Update the Windows Firewall rules to block port 443.

Why wrong: Blocking port 443 would disable HTTPS traffic entirely, which is not the goal. The objective is to restrict the encryption protocols used within the traffic, not to prevent the traffic itself. The SCHANNEL registry settings allow you to maintain connectivity while enforcing stronger, secure protocol versions for the sessions.

Use the Local Security Policy snap-in to change the 'Minimum Password Length' setting.

Why wrong: Password length policies are part of account security and have no bearing on network protocol encryption standards. Modifying password policies does not affect the TLS or SSL versions used by the server's network stack. Protocol hardening requires specific configuration changes within the SCHANNEL sub-system or through group policy settings.

Encrypted File System (EFS).

Why wrong: EFS provides file-level encryption rather than full-volume encryption. While useful for specific folders, it does not protect the entire partition or the OS files themselves. BitLocker is the preferred solution for protecting entire drives against physical theft or unauthorized offline access to the volume's data.

NTFS Permissions.

Why wrong: NTFS permissions control access to files and folders based on user identity, but they do not provide encryption. If an attacker bypasses the operating system or accesses the raw disk, NTFS permissions are ignored. Encryption is required to prevent data from being readable if the storage itself is compromised.

Windows Defender Antivirus.

Why wrong: Windows Defender is an anti-malware solution designed to detect and remove malicious software, not to encrypt disks. While it is a vital part of server security, it does not address the need for data-at-rest encryption. BitLocker must be used specifically to secure the physical storage of the data.

The Session Configuration file (.pssc)

Why wrong: The Session Configuration file is used to define the environment of the JEA endpoint, such as the identity the session runs under and which role capabilities are assigned. While it references role capabilities, it does not contain the granular list of permitted cmdlets or functions that the administrator requires for task execution.

The PowerShell Profile file (.ps1)

Why wrong: PowerShell profiles are scripts that run when a PowerShell session starts to customize the environment for the user. They are not used for security enforcement or defining JEA restrictions. Relying on profiles for security is ineffective because users can often bypass them or modify their own local profile settings during standard operation.

The Module Manifest file (.psd1)

Why wrong: Module manifests are used to describe the contents of a PowerShell module, including its version, dependencies, and exported members. While they help organize code, they do not provide the security constraints required by Just Enough Administration to restrict a user's command execution context within a specific hardened remote management session.

NTFS Permissions

Why wrong: NTFS permissions control access to files and folders on the local file system but do not protect the data while it is being transmitted over the network. While they are essential for data security, they cannot prevent a network-based attacker from intercepting or altering the communication stream between the client and the server.

Access-Based Enumeration

Why wrong: Access-Based Enumeration hides files and folders that a user does not have permission to access. This reduces the visibility of sensitive data to unauthorized users browsing the share but does nothing to secure the actual data packets against interception or modification by an attacker who is sniffing the network traffic.

Disk Quotas

Why wrong: Disk quotas are used to limit the amount of storage space a user can consume on a volume. They are a management tool for resource allocation and have no relationship to the security of network protocols or the prevention of unauthorized traffic modification. They do not provide any cryptographic protection for data in transit.

To allow administrators to browse the internet safely while performing server updates.

Why wrong: PAWs are strictly prohibited from general internet browsing to minimize the attack surface. Their purpose is the exact opposite: they provide a locked-down environment where risky activities like web browsing and checking email are disabled to prevent malware from compromising the administrative session or stealing highly sensitive credentials from memory.

To enable multiple users to share a single high-privilege account across the organization.

Why wrong: Sharing high-privilege accounts is a violation of security best practices and the principle of accountability. PAWs are intended to secure the access method of individual administrators, not to facilitate account sharing. Each administrator should use their own unique, privileged credentials on a PAW to ensure proper auditing and access control.

To automatically synchronize local administrator passwords across all domain controllers.

Why wrong: Password synchronization is typically handled by Active Directory or specialized tools like Local Administrator Password Solution (LAPS). PAWs are hardware or virtual machines used by humans to perform tasks; they are not a mechanism for managing or synchronizing account passwords across the server infrastructure or the wider domain environment.

Direct Memory Access (DMA) Protection

Why wrong: While DMA protection is important for securing a system against physical hardware attacks, it is not the primary requirement for Credential Guard's virtualization-based security. DMA protection helps prevent unauthorized devices from reading memory, but Credential Guard specifically relies on the CPU's ability to create isolated virtualized memory spaces for the LSA process.

Hyper-Threading Technology

Why wrong: Hyper-Threading is a performance feature that allows a single physical CPU core to act as two logical processors. It does not provide any security boundaries or isolation capabilities required for Credential Guard. In fact, some security experts recommend disabling it in high-security environments to mitigate certain side-channel side-channel timing attacks.

Hardware-enforced Stack Protection

Why wrong: Hardware-enforced Stack Protection is a security feature that helps prevent memory corruption attacks like buffer overflows. While it enhances overall system security, it is not the foundational technology for Credential Guard. Credential Guard's primary mechanism is virtualization-based isolation, which is distinct from the stack protection features implemented in modern processors.

The Key Protection Service

Why wrong: The Key Protection Service is responsible for releasing the transport keys required to unlock and run a Shielded VM. However, it only does so after the Attestation Service has successfully verified the host's health. While critical, it is the secondary step in the process, relying on the result of the attestation check.

The Virtualization-based Security (VBS) engine

Why wrong: Virtualization-based Security is a technology used on the Hyper-V host itself to protect sensitive processes, but it is not a component of the Host Guardian Service. VBS provides the environment for the secure kernel and Credential Guard, whereas HGS is the external service that manages the trust and keys for the fabric.

The TPM 2.0 Emulator

Why wrong: A virtual TPM (vTPM) is used within a Shielded VM to provide cryptographic capabilities to the guest OS, such as BitLocker. While it is a requirement for Shielded VMs to operate securely, it is not a component of the HGS nor is it responsible for verifying the authorization of the Hyper-V host.

Autonomous mode

Why wrong: In Autonomous mode, a downstream server shares updates with the upstream server but maintains its own independent approval process. This is useful when different departments have different update requirements, but it does not meet the requirement of strictly following the approvals made on the upstream server for centralized control.

Distributed mode

Why wrong: Distributed mode is not a standard configuration term for WSUS downstream servers. The two primary synchronization relationships are Replica and Autonomous. While WSUS can be part of a distributed architecture, 'Distributed mode' does not exist as a selectable configuration option within the WSUS console for controlling update approval behavior.

Disconnected mode

Why wrong: Disconnected mode is used for WSUS servers that do not have a direct network connection to the upstream server or the Microsoft Update servers. Updates are exported from an upstream server to media and then imported into the disconnected server. It refers to the connectivity method rather than the approval synchronization logic.

Modify the local Registry on each server to block the KB ID.

Why wrong: While modifying the registry can block certain Windows Update behaviors, it is not the recommended or efficient way to manage exclusions in Azure Update Management. Centralized management via the Azure Portal is preferred for consistency, visibility, and ease of auditing across large numbers of managed servers in a hybrid environment.

Use a Group Policy Object (GPO) to disable the Windows Update service.

Why wrong: Disabling the Windows Update service would prevent all updates from being installed, which is not the goal. The requirement is to exclude only a *specific* update while allowing others to proceed. Disabling the service entirely leaves the server vulnerable to other security threats and breaks the Azure Update Management functionality.

Uninstall the Log Analytics agent from the affected servers.

Why wrong: The Log Analytics agent (or Azure Monitor agent) is required for Azure Update Management to communicate with the on-premises servers. Uninstalling it would remove the server from Azure Update Management entirely, making it impossible to manage any updates or monitor the compliance status of that machine from the Azure console.

Every server in the cluster must be running the Windows Insider preview build.

Why wrong: gMSAs are a stable, production-ready feature available in all supported versions of Windows Server since 2012. Using Insider preview builds is not a requirement and is generally discouraged for production workloads. Standard retail or volume licensed versions of Windows Server 2022 fully support gMSAs for all application and service types.

The Domain Functional Level must be set to Windows Server 2022.

Why wrong: While the schema must be updated, the Domain Functional Level does not need to be Windows Server 2022. gMSAs only require a schema version from Windows Server 2012 or later. This allows organizations with older domain controllers to still benefit from the security and management advantages of gMSAs without upgrading every controller.

An Azure AD Connect instance must be active and syncing to the cloud.

Why wrong: gMSAs are a local Active Directory Domain Services feature and do not require any cloud connectivity or Azure AD Connect synchronization. They are designed to manage service identities within an on-premises or hybrid environment independently of cloud-based identity synchronization tools, focusing on the security of the local Windows Server infrastructure.

All target Windows Servers must have the Remote Desktop Gateway role installed.

Why wrong: One of the primary benefits of Azure Bastion is that it eliminates the need for a Remote Desktop Gateway role or any other public-facing agent on your virtual machines. The Bastion service itself handles the gateway functionality, allowing you to keep your VMs isolated from the internet while still maintaining administrative access.

A Site-to-Site VPN must be established between Azure and on-premises.

Why wrong: Azure Bastion is a standalone service that provides access through the Azure portal via a web browser. It does not require a Site-to-Site VPN or ExpressRoute to function. While those technologies are useful for general hybrid connectivity, Bastion specifically focuses on providing secure, clientless RDP/SSH access without needing a VPN.

Azure Key Vault for storing the WAC login credentials.

Why wrong: While Azure Key Vault is excellent for managing secrets, Windows Admin Center primarily uses the user's own credentials (via Kerberos or CredSSP) or stored credentials within its own local configuration. It does not use Azure Key Vault as a primary mechanism for controlling user-level access permissions to the management console itself.

NTFS permissions on the Windows Admin Center installation folder.

Why wrong: NTFS permissions on the application folders control who can modify the WAC software files on the disk, but they do not control the logical access of users connecting to the web interface. WAC security is handled at the application level through its configuration settings and the underlying Windows authentication mechanisms.

DHCP Reservations for the WAC gateway IP address.

Why wrong: DHCP reservations ensure that the WAC server always receives the same IP address from the network. While this is helpful for ensuring the management console remains reachable at a consistent URL, it provides no security or access control benefits regarding which administrators are authorized to use the tool to manage servers.

The script will fail to run because the LocalMachine policy is set to AllSigned.

Why wrong: The 'LocalMachine' scope is lower in the precedence hierarchy than the 'Process' scope. Although 'AllSigned' usually requires scripts to be digitally signed, the 'Bypass' setting at the 'Process' level overrides this restriction for the duration of the current PowerShell session, allowing any script to run regardless of its signature.

The script will prompt the user for confirmation before executing.

Why wrong: A prompt for confirmation typically occurs when the policy is set to 'RemoteSigned' and a script is downloaded from the internet without being unblocked. However, 'Bypass' explicitly suppresses all prompts and warnings. The user will not be asked for permission, and the script will proceed to execute as soon as the command is entered.

The script will only run if the administrator executes it from an elevated prompt.

Why wrong: Elevation (Running as Administrator) does not change how the execution policy is applied. If the policy blocks a script, it will be blocked regardless of whether the prompt is elevated or not. In this case, the 'Bypass' policy at the 'Process' level is what allows the execution, not the administrative status of the user.

The file will be allowed because the 'Allow Signed' rule uses a wildcard for the FileName.

Why wrong: While the 'Allow Signed' rule uses a wildcard, the presence of a specific 'Deny' rule for 'untrusted.exe' overrides it. In WDAC logic, a specific block rule is prioritized over a general allow rule. Therefore, the wildcard does not grant permission to files that are explicitly listed in the deny section of the policy.

The file will be allowed if it is digitally signed by a trusted Windows publisher.

Why wrong: Even if the file is signed by a trusted publisher, the explicit 'Deny' rule in the FileRules section will block it. WDAC evaluates deny rules first. If a match is found in the deny list, the execution is blocked immediately, and the policy does not continue to check for valid signatures or other allow conditions.

The file will be allowed but an audit event will be generated in the event log.

Why wrong: The exhibit shows a standard policy, not an audit-only policy. Unless the 'Option' for 'Audit Mode' is explicitly set in the policy header (not shown in the snippet), a match on a 'Deny' rule results in an active block. The file will not run, and the user will receive a notification that the app is blocked.

The SMB server service must be restarted for the change to take effect.

Why wrong: SMB configuration changes in Windows Server 2022 are applied dynamically by the kernel-mode SMB driver. Restarting the service is generally unnecessary for configuration properties like encryption. The connectivity issue points to a protocol mismatch or negotiation failure rather than a pending service restart requirement for the configuration update.

The server's certificate for SMB encryption has expired.

Why wrong: SMB encryption in Windows Server uses symmetric keys negotiated during the session setup, not X.509 certificates. Therefore, certificate expiration is irrelevant to SMB traffic. This is a common point of confusion with TLS-based protocols like HTTPS or LDAPS, which do rely on PKI infrastructure for session encryption.

The firewall is blocking TCP port 445.

Why wrong: The firewall blocking port 445 would prevent all SMB traffic regardless of whether encryption is enabled or disabled. Since users specifically reported issues after the configuration change to enable encryption, the connectivity problem is rooted in the protocol negotiation phase rather than a static network-level block by the firewall.

Configure a Group Policy Object to enable NTLMv2 only.

Why wrong: Group Policy settings for NTLM authentication restrict the authentication protocol used by the domain but have no impact on JEA configurations. JEA is a PowerShell-specific security feature focused on limiting command execution; it does not control authentication protocols used for network-level access to the server or domain resources.

Modify the local SAM database to include JEA roles.

Why wrong: The SAM database stores local user and group information but is not used for defining PowerShell JEA roles. JEA roles are defined through configuration files in the file system and registered via PowerShell. Modifying the SAM database does not provide the functionality required to implement restricted PowerShell administrative access.

Enable the Credential Guard feature.

Why wrong: Credential Guard is a security feature that uses VBS to protect credentials from memory attacks. While it is an excellent security measure for any Windows Server, it is not a step in the process of implementing JEA. JEA and Credential Guard serve different purposes in the overall server hardening strategy.

Audit Account Management.

Why wrong: While Audit Account Management logs changes to local user accounts, it is insufficient for tracking changes made to domain-level Active Directory objects. When dealing with domain environments, you must use the more specific Directory Service auditing categories to monitor changes made directly to the Active Directory database objects.

Audit Object Access.

Why wrong: Audit Object Access is primarily used for monitoring access to files, folders, and registry keys. While it can be used to audit access to AD objects, it is not the primary policy category for tracking modifications to directory attributes; that requires the Directory Service Changes category for proper logging.

Audit Logon/Logoff.

Why wrong: This policy category logs user authentication events, such as logins and logoffs. It does not provide information regarding modifications made to account attributes. Monitoring identity management changes requires auditing the directory services themselves, as logon/logoff events do not capture configuration changes occurring within the Active Directory object database.