Microsoft - AZ-802: Administering Windows Server

Sample Questions

• Prevent the Domain Admins members from signing in to the devices in Workstations and MemberServers.
• Continue to allow the Domain Admins members to sign in to the computers in AdminWorkstations.

Explanation:

The solution must meet two requirements:

1. Prevent members of Domain Admins from signing in to computers in the Workstations and MemberServers OUs.
2. Continue allowing Domain Admins to sign in to computers in the AdminWorkstations OU.

To achieve this, configure a GPO that applies only to the Workstations and MemberServers OUs.

Configuration

Step 1: Create a GPO that restricts Domain Admin sign-ins.

Step 2: Configure the following Group Policy setting:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment

Setting: Deny log on locally

Assigned group: Domain Admins

Step 3: Link the GPO to both:

• Workstations OU
• MemberServers OU

Do not link the GPO to the AdminWorkstations OU.

This configuration prevents Domain Admins from signing in locally to standard workstations and member servers while preserving their ability to sign in to administrative workstations.

Microsoft confirms that Deny log on locally takes precedence over Allow log on locally. 

Important: Local sign-in vs. Remote Desktop

The Deny log on locally setting prevents interactive sign-ins at the computer console. It does not prevent Remote Desktop sign-ins.

If the requirement is to prevent Domain Admins from signing in through both methods, you must also configure: Deny log on through Remote Desktop Services

References:

Deny log on locally

Implementing Least-Privilege Administrative Models

Explanation:

The DC agent must be installed on every domain controller where you want Microsoft Entra Password Protection enforced. Microsoft explicitly states that the password policy is enforced only on domain controllers that have the DC agent installed.

In this scenario:

• DC1 already participates in Microsoft Entra Password Protection.
• DC2 is a newly deployed domain controller.
• Windows clients can send password changes to either DC.
• If DC2 doesn't have the DC agent, password changes processed by DC2 aren't validated against the Microsoft Entra banned password lists. This explains the inconsistent behavior.

Reference: Enforce on-premises Microsoft Entra Password Protection for Active Directory Domain Services

• Core isolation
• Force randomization for images (Mandatory ASLR)

Explanation:

Core isolation → Device security

Core isolation is part of Windows virtualization-based security (VBS) and is managed from the Device security area of Windows Security.

Force randomization for images (Mandatory ASLR) → App & browser control

Mandatory ASLR is an Exploit protection mitigation. Microsoft documents Force randomization for images (Mandatory ASLR) as one of the available Exploit protection mitigations. Exploit protection can be configured through the Windows Security app.

The navigation is:

Windows Security → App & browser control → Exploit protection → Exploit protection settings → System settings → Force randomization for images (Mandatory ASLR)

References:

Exploit protection reference

Enable exploit protection

• Minimize the impact on the other user and computer accounts in the domain.
• Minimize administrative effort.

Explanation:

In AD DS, authentication policies can control Kerberos authentication settings for selected accounts, including the ticket-granting ticket (TGT) lifetime.

An authentication policy silo lets you apply that authentication policy specifically to designated:

• user accounts
• computer accounts
• service accounts

This satisfies both requirements because the shorter or customized TGT lifetime affects only the accounts assigned to the silo, rather than all accounts in the domain.

References:

Authentication Policies and Authentication Policy Silos

Guidance about how to configure protected accounts

• On Server1, you create an Application Control policy named Policy1 that contains a rule to allow all the executables in a folder named D:\Folder1.
• You add a rule to Policy1 to trust a folder named \\Server2\Folder2.
• You deploy Policy1.

Explanation:

For App Control for Business policies, formerly Windows Defender Application Control (WDAC), Windows records policy activation events and events concerning executables, DLLs, and drivers in:

Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

Microsoft specifically states that this log includes events relating to App Control policy activation, making it the appropriate place to verify that Policy1 has been applied to Server1. 

Reference: Understanding App Control events