I've worked as a sysadmin at an MSP for several years, mostly maintaining existing client environments. We're now building a new on-premises Active Directory environment from scratch for a client, and I'd like to compare notes with other administrators. What policies would you consider essential in a greenfield AD deployment, or a GPO hill you would strongly defend? My own starting points include preventing Domain Admin accounts from logging into workstations and adding a separate workstation-administration account to the local Administrators group. The client evaluated cloud-managed options but specifically chose on-premises AD, so I'm focusing on making that design as secure and supportable as possible.
5 Answers
Centralized Windows Firewall and properly configured WinRM are worth doing early, especially if the environment will be managed remotely. Enable the firewall on every profile, protect all interfaces, log useful connection activity, and avoid allowing users or applications to create arbitrary local firewall exceptions. Configure WinRM narrowly for approved management hosts instead of exposing it broadly.
Separate administrative tiers from the beginning: ordinary users, workstation administrators, server administrators, and domain-level administrators should not all use the same accounts or management paths. Restrict privileged logons to approved systems, use hardened administrative workstations where practical, and limit who can join computers to the domain. This prevents a compromised workstation from becoming an easy route to higher privileges.
Start with the current Microsoft Security Baselines and use the applicable CIS or STIG guidance as a reference, but test everything before broad deployment. Keep the Default Domain Policy limited to domain-wide account and password settings, and organize the rest into purpose-specific GPOs linked to sensible OUs. Avoid building an inheritance maze or relying on blocked inheritance as a routine fix. Use delegated administration and keep Domain Admin as a break-glass account rather than a daily admin identity.
Don’t overlook the less glamorous operational policies: consistent time synchronization with the domain PDC emulator as the authoritative source, disabling Fast Startup where it interferes with management or troubleshooting, controlled printer and drive mappings, and application or browser protections such as an approved content-blocking extension. For server workloads, apply the relevant hardening baseline and only permit interactive logon for explicitly authorized groups.
My baseline would include Windows LAPS, separate privileged accounts, restrictions on where privileged accounts can log on, Microsoft Defender configuration, Windows Firewall with centralized rules and logging, BitLocker with recovery keys escrowed, and a defined update strategy for WSUS, Configuration Manager, or Windows Update for Business. Also remove unnecessary applications and prevent standard users from bypassing application controls through alternate installers or app stores. Verify that BitLocker recovery keys are actually present rather than assuming policy processing succeeded.
I also restrict which users can log on to servers and disable or tightly limit RDP. On domain controllers, disable services such as the Print Spooler unless there is a documented reason to keep them enabled.
CIS is a useful starting point, but some recommendations can be outdated or overly disruptive. Treat every baseline as a reference that needs validation against the client’s applications and operational requirements.