Active Directory Best Practices

Domain Design Fundamentals

Active Directory is the backbone of most Windows-based enterprises, and getting the design right from the start saves years of remediation work. The core decision is how many domains and forests to use -- and the answer is almost always "one domain, one forest." Multi-domain setups add complexity without meaningful benefit for 95% of organizations.

For a homelab, a single domain is the right call. Don't fall into the trap of creating separate domains for "production" and "testing." Use organizational units (OUs) and security groups to separate environments instead. This keeps administration simple while still giving you the isolation you need.

Organizational Unit Strategy

OUs are the primary way to organize objects within a domain. A well-designed OU structure mirrors your organizational reality while making GPO delegation straightforward:

• Computers OU -- Split by function: Servers, Workstations, Domain Controllers, and Lab
• Users OU -- Split by department or role: Employees, Contractors, Service Accounts, Administrators
• Groups OU -- All security and distribution groups in one place for easy management
• Printers OU -- Printer objects if you're publishing them via GPO (though this is less common now)

Keep the OU structure flat. Deep nesting (more than 3-4 levels) makes it harder to find objects and complicates GPO targeting. If you find yourself creating OUs just to store objects, you're over-organizing. Use AD search and saved queries instead.

GPO Design and Management

Group Policy is where most AD environments accumulate technical debt. The key principles for clean GPO management:

• One GPO per requirement -- Don't combine disk quotas, software installation, and security settings into one GPO. Each GPO should do one thing well
• Link GPOs at the OU level -- Avoid linking to the domain root unless the policy truly applies to everything
• Use WMI filters sparingly -- They add complexity and can cause performance issues. Prefer security filtering with AD groups
• Enable GPO backup in your automation -- Back up all GPOs regularly with Backup-GPO and store them in version-controlled storage
• Document the purpose of each GPO -- An undocumented GPO is a liability. Add a comment field explaining what it does and why

GPO processing follows a strict order: Local Policy → Site → Domain → OU (top-down, last OU wins). Understanding this order is critical when troubleshooting why a policy isn't applying as expected.

Security Hardening

Active Directory is the #1 target for attackers. Hardening it is non-negotiable:

• Enable Admin Tiering -- Separate admin accounts by scope. Domain Admins for DCs only, Local Admins for workstations only. Never use a Domain Admin account for daily tasks
• Protect the Schema Admins and Enterprise Admins groups -- These are the most dangerous groups in AD. Restrict membership to exactly who needs it and audit all usage
• Enable Audit Policy -- Log logon events, object access, policy changes, and directory service access. Forward these logs to a SIEM or centralized logging server
• Implement LAPS -- Local Administrator Password Solution randomizes local admin passwords on all machines and stores them securely in AD
• Deploy AD RMS or Azure Information Protection -- For organizations that need document-level protection
• Disable NTLM -- Migrate everything to Kerberos. NTLM is a legacy protocol with known vulnerabilities
• Enable Fine-Grained Password Policies -- Use Password Settings Objects (PSOs) for service accounts and privileged users instead of the domain-wide policy

Service Account Management

Service accounts are often the weakest link in AD security. They tend to have excessive privileges, never expire, and are shared across multiple applications.

For modern environments, use Group Managed Service Accounts (gMSA). They provide automatic password management, delegated SPN management, and integration with SQL Server and IIS. Creating a gMSA is straightforward:

New-ADServiceAccount -Name "svc-webapp" -DNSHostName "svc-webapp.corp.local" -PrincipalsAllowedToRetrieveManagedPassword "WEB-SRV01$"

For non-Windows services that can't use gMSA, store credentials in a vault (HashiCorp Vault, CyberArk, or even a simple encrypted credential file) and rotate them on a schedule.

Backup and Recovery

AD is a multi-master replicated directory, so backup strategy differs from traditional servers:

• System State backup -- This is what you need to restore AD, not a full server backup. Use ntbackup or Windows Server Backup to capture System State
• Back up every DC -- Each domain controller holds a writable copy of the AD database. Back up all of them
• Test restores regularly -- A backup you haven't tested is not a backup. Practice restoring AD to a separate lab environment at least quarterly
• Use authoritative restore sparingly -- Authoritative restore overwrites replication. Use it only when you need to recover deleted objects or undo accidental changes
• Snapshot your DCs carefully -- If running DCs as VMs, use VM snapshots with VSS integration. Taking snapshots without VSS can cause USN rollback

Homelab-Specific Tips

Running AD in a homelab gives you a safe environment to practice enterprise skills:

1. Set up at least two domain controllers for high availability and replication practice
2. Implement DNS properly -- AD is tightly coupled with DNS. Misconfigured DNS is the #1 cause of AD problems
3. Practice multi-site configuration with different subnets and site links
4. Deploy a PKI lab with Active Directory Certificate Services for certificate-based authentication
5. Use PowerShell for everything -- automate OU creation, GPO deployment, and user provisioning
6. Simulate attacks with tools like BloodHound to understand how attackers move through AD