I've worked as a systems administrator at an MSP for several years, mostly maintaining and improving existing client environments. This is my first time leading a completely new on-premises Active Directory deployment for a client. We discussed cloud-managed alternatives, but the client specifically chose an on-premises domain.
For a greenfield AD environment, which Group Policies would you consider essential or non-negotiable? My starting point includes preventing Domain Admin accounts from signing into workstations and placing a separate workstation-admin account in the local Administrators group. I'm especially interested in security baselines, privilege separation, endpoint protection, patching, encryption, and policies that prevent common support and security problems.
4 Answers
My baseline would include Windows LAPS, privileged-account logon restrictions, Defender configuration, Windows Firewall on every profile, BitLocker with recovery keys escrowed, and a defined Windows Update strategy. I’d also remove unnecessary applications and prevent standard users from bypassing UAC through alternate installation paths.
For servers, restrict interactive logon and RDP to dedicated administrator groups. On domain controllers, disable services such as the Print Spooler unless there is a specific need. Centralize firewall rules and logging, and configure WinRM only if you actually need remote management.
I’d pay particular attention to workstation and server separation. Use groups to control who can log on locally or through RDP, prevent end users from adding arbitrary computers to the domain, and keep local administrator access managed through LAPS rather than a shared password.
Also establish reliable time synchronization: the PDC emulator should use approved external sources, while other domain systems synchronize through the domain hierarchy. Be deliberate about DNS, since AD reliability depends heavily on it. Disable Fast Startup if it conflicts with management, encryption, or patching workflows.
Start with the current Microsoft security baselines, then adapt them to the client instead of blindly applying every setting. CIS or government security templates can also provide a useful starting point, but test them carefully because some recommendations may be outdated or disruptive.
Keep the domain architecture clean: use sensible OUs, avoid putting everything in the Default Domain Policy, and avoid relying on blocked inheritance. Delegate only the permissions administrators actually need, and keep Domain Admin as a break-glass account rather than a daily-use identity. A tiered administration model and separate privileged workstations are worth considering too.
I’d also begin with legacy protocols disabled wherever possible, then enable a dependency only when there’s a documented business reason. Testing is important because older applications can still depend on things like NTLM.
For highly regulated environments, use the applicable security templates or STIG-style guidance as a checklist, but apply them in phases and test every change. A practical first pass would cover firewall enforcement, audit policy, Defender, BitLocker, patching, application control, restricted administrative logons, and disabling unnecessary services.
I’d also document exceptions rather than weakening the baseline globally. Printer deployment, approved applications, shared drives, and other common user resources can be handled through targeted OUs or security groups so the security policies remain consistent without creating unnecessary support tickets.
For BitLocker, don’t just assume the recovery key was written to Active Directory. Verify escrow during deployment and include a check for it in the build process; otherwise an unexpected recovery event can leave support without the key.