Tiering Admin Access in a Segmented Datacenter
Contoso runs 40 Windows Server 2022 hosts in one datacenter. Domain controllers (DC01, DC02) and two privileged access workstations (PAWs) sit in an isolated VLAN with no route to the internet. The 38 member servers sit in a second VLAN that reaches the internet through a firewall. Administrators currently sign in to member servers with Domain Admin accounts because a prior project blocked all local logons. An audit finds that two member servers were used to browse the web with Domain Admin credentials. The security team requires: domain admins can log on only to DCs and PAWs; server operators manage member servers using delegated, non-domain-admin accounts; no credential material for tier-0 accounts can be cached on member servers. Budget allows no new hardware beyond the existing two PAWs.
1. Which control most directly prevents tier-0 credentials from being cached or harvested on the 38 member servers, and how should it be enforced given the existing PAWs?
Read the worked answer
Protected Users membership plus logon-right restriction. Add the tier-0 administrative accounts to the Protected Users global security group. Protected Users blocks NTLM, CredSSP, and unconstrained delegation, disables DES/RC4 preauthentication, and - critically - prevents caching of credentials (no reversible password storage, no cached verifier for interactive logon beyond the ticket lifetime).
Enforcement must be paired with Deny log on locally / Deny log on through Remote Desktop on the member servers for the Domain Admins and other tier-0 groups, applied by GPO linked at the member-server OU. Protected Users alone does not stop an admin from attempting a logon; it only hardens what happens if they do.
Because the two PAWs already exist, place them in a dedicated tier-0 OU that does not receive the deny GPOs, so admins retain a supported path. Domain controllers are excluded automatically for domain logon by design. The firewall VLAN separation already blocks tier-0 hosts from internet egress, satisfying the no-egress requirement without new hardware.
2. How should the server operators be delegated so they can manage member servers without becoming Domain Admins, and what is the risk if they are simply added to the local Administrators group on all 38 servers by a startup script?
Read the worked answer
Delegation model. Create a global group GG_ServerOps and a domain local group DL_SrvAdmins_MemberServers, nest the global into the domain local, and use Group Policy Restricted Groups or Group Policy Preferences → Local Users and Groups to place DL_SrvAdmins_MemberServers into the local Administrators group of the member-server OU. Grant GG_ServerOps only the rights they need at the OU level (e.g., reset passwords on computer objects, read/write servicePrincipalName if required) rather than broad domain rights.
Risk of the startup script approach. A startup script that adds a group to local Administrators runs as SYSTEM on every boot; anyone who can edit the script (or its source share) gains effective local admin on all 38 servers - a single point of compromise. It also silently re-adds the group if an operator removes it during troubleshooting, defeating change control, and it produces no auditable record of who made the change. Preference items with Remove when no longer applied and item-level targeting in a GPO give the same outcome with centralized, auditable, and reversible management.
3. The audit also found that a member server had cached a domain admin's password hash. Which two additional measures would you prioritize, and why those two over the others?
Read the worked answer
Priority 1 - Credential Guard on member servers. Virtualization-based security isolates LSA secrets (NTLM hashes, Kerberos TGTs) in a protected process, so even local admin malware cannot dump them. It requires UEFI, Secure Boot, virtualization extensions, and a 64-bit OS - all satisfied by Server 2022. This directly addresses the finding.
Priority 2 - LAPS for local administrator passwords. If every member server shares the same local admin password (common when a startup script seeded it), one compromised host yields lateral movement to all 38. Windows LAPS (built into Server 2022) gives each host a unique, rotated, AD-stored password with retrieval audited.
Why these two. The finding is about cached tier-0 secrets and lateral movement. Credential Guard removes the cacheable secret; LAPS removes the shared-secret path. Alternatives - disabling NTLM domain-wide, or full Admin Tier Model with jump hosts - are valuable but either break legacy apps or require process change, so they follow once the two technical controls close the immediate exposure.