Active Directory (AD) Domain Controller Build Best Practices

Do not use Domain.local, since “.local” is not routable
Use an Internet routable domain name, such Domain.com or Domain.net
Best practice is to use the same name as your public domain name
Do not use dashes (-) or underscores (_) in the DC server names
Allows to get a public SSL/TLS certificate
Allows to setup Entra ID Connect Sync to sync on-prem domain object to the cloud

DC names should follow a standard naming convention, such as “DC01”, “DC02”, etc
Name should be 15 or less characters long to comply with NetBIOS
Do not use dashes (-) or underscores (_) in the DC server names

DCs should not be shut down to operate efficiently; shutting down DCs breaks replication and authentication from workstations and other services
For testing purposes, a single DC is sufficient holding all FSMO roles
DC should be backed up regularly and backups tested
DCs should be on recent, supported versions (Server 2019, 2022, or 2025)

With a single DC in a domain, the DC should point their primary DNS to themselves
With two DCs in a domain, DC01 should point to DC02 as primary, and itself as secondary
With multiple DCs, follow the same strategy as above, pointing the DC to itself last
Do not use loopback IP addresses in DNS settings (i.e 127.0.0.1)
Do not use public DNS servers in DCs Network Interface Card (NIC) settings (i.e. 8.8.8.8)

Domain Administrators should not be standard users with elevated rights
If you John Smith has a user account “John.Smith” they should have a “John.Smith-Admin” account that has elevated Domain Admin role and is not used by the user regularly
Domain Admin accounts should be monitored for suspicious activity (MDR, SIEM, IDS, etc)
Domain Admin accounts should have complex passwords, different from other passwords; passwords should not be shared with others
Domain Admin accounts should have MFA where possible
Domain Admin accounts should be unique to each admin for proper auditing; no re-sharing accounts between multiple users for auditing and non-repudiation purposes

There are three common scenarios:

Single DC: Set an external time source if it’s the single DC (by default it’s the PDC Emulator role holder).
Multiple DCs at one site: If there are multiple DCs at one site, set an external time source on the PDC Emulator ONLY (other DCs and computers will get time from it).
*Multiple DCs at several sites: If there are multiple DCs across sites, set an external time source on one DC per site.

You can use commands to set external sources (in Administrative mode):

Set external time sources: w32tm /config /syncfromflags:manual /manualpeerlist:”0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org”
Restart time service: net stop w32time && net start w32time
Update time config: w32tm /config /update
Resync: w32tm /resync

Verify configuration: w32tm /query /configuration

Create group policies for everything possible, to automate user onboarding, workstation setups, etc.

Network Printers Deployment
Network Shares/Drives Deployment
Domain Password Policy
Windows Firewall
Loopback Policy
Enable Remote Desktop
Create Desktop/Web Shortcuts
Browser Restrictions (Edge, Chrome, Firefox)
- Block password saving
- Cloud sync account sign-in
- Insecure settings
Windows 10/11