Active Directory Security Best Practices for 2026

Active Directory has been the authentication and authorization backbone of enterprise Windows environments for over two decades, and in that time it has also become the single most targeted system in the enterprise security landscape. Nation-state actors, ransomware groups, and opportunistic attackers all understand that fully compromising Active Directory typically means compromising everything in the organization — every server, every workstation, every application, and every piece of data. The techniques for attacking AD are well-documented, actively developed, and increasingly available as automated tooling that lowers the skill bar for exploitation. The techniques for defending it are equally well-developed but inconsistently applied.

The gap between how AD is typically configured and how it should be configured to resist modern attacks is significant in most organizations. Default configurations are functional but not hardened. Years of accumulated technical debt — service accounts with excessive permissions, stale admin accounts, GPO exceptions that were never cleaned up, delegation settings that nobody remembers enabling — create attack surfaces that sophisticated adversaries know how to find and exploit systematically. The attacks that dominated breach investigations in 2020 are still succeeding today because the underlying vulnerabilities haven't been addressed.

This guide covers the most important Active Directory security best practices for today, prioritized by impact, grounded in the current threat landscape, and designed for IT teams that are serious about hardening their most critical infrastructure. Each recommendation addresses a specific, well-documented attack vector and can be implemented with the tools and capabilities that come with Windows Server without requiring additional security product purchases.

Implement the Tiered Administration Model

Microsoft's Active Directory Administrative Tier Model is the foundational framework for protecting privileged access in an AD environment. The model separates the administrative environment into three tiers: Tier 0 covers the AD infrastructure itself — domain controllers, the AD schema, and accounts with domain-wide control; Tier 1 covers member servers and enterprise applications; Tier 2 covers workstations and end-user devices. The critical security rule is that credentials never flow downward across tiers — a Tier 0 admin account should never be used to log into a Tier 1 or Tier 2 system, and no administrative accounts of any tier should be used on regular workstations for non-administrative tasks.

The reason this matters is credential theft. Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, and similar attacks work by stealing credential material from the memory of systems where privileged accounts have been used. If a Domain Admin logs into a regular workstation to answer email or browse the web, and that workstation is compromised by a phishing payload or drive-by download, the attacker now has Domain Admin credential material on a Tier 2 system. From there, lateral movement to a domain controller is straightforward and fast. The Tier Model eliminates this attack path by ensuring that high-value credentials never touch low-security systems.

Implementing the Tier Model requires creating separate admin accounts for each tier, configuring Authentication Policy Silos or logon restriction GPOs to enforce tier boundaries (preventing Tier 0 accounts from logging into Tier 2 systems even if an attacker attempts to use them there), and changing the operational habits of your administrative team. This is a cultural and process change as much as a technical one, and it requires management support and consistent enforcement. Organizations that have fully implemented the Tier Model report dramatically improved resilience against the credential-based attacks that dominate modern breach scenarios.

Harden Domain Controllers as Tier 0 Assets

Domain controllers are the crown jewels of the Active Directory environment. They hold every credential hash in the domain and have the authority to issue authentication tickets to any resource in the organization. Compromise of a single domain controller is functionally equivalent to compromise of the entire domain — an attacker with DC-level access can create new admin accounts, extract all password hashes, forge authentication tickets, and establish persistent access that survives password resets across the entire organization. Despite this, domain controllers in many organizations are managed like any other server, subject to the same access policies, patch cadence, and monitoring levels as file servers and application servers. This false equivalence is a serious security mistake.

Domain controllers should receive hardened Group Policy baselines that implement a defense-in-depth configuration: no unnecessary services running, SMBv1 disabled, SMB signing enforced, LDAP signing and channel binding required, Kerberos armoring enabled, outbound internet access blocked at the firewall level, and NTLMv1 disabled. Microsoft's Security Compliance Toolkit and the CIS Benchmarks for Windows Server both provide downloadable GPO templates that implement these settings systematically. Apply them, test them, and treat any deviation from baseline as a configuration management finding requiring remediation.

Restrict access to domain controllers — both physical console access and administrative remote access — to the smallest possible set of personnel. Every additional person with console-level access to a DC is an additional attack surface. In virtualized environments, this extends to the hypervisor layer: accounts with administrator access to the hypervisor hosting DC virtual machines effectively have domain controller access through the hypervisor console, and must be treated with the same Tier 0 rigor as direct DC admin accounts.

Protect the KRBTGT Account

The KRBTGT account is used by the Key Distribution Center service on domain controllers to encrypt and sign all Kerberos tickets issued in the domain. It is the target of the "Golden Ticket" attack, where an attacker who has obtained the KRBTGT password hash can forge Kerberos Ticket Granting Tickets that grant access to any resource in the domain, with any privileges, with an arbitrarily extended validity period. What makes Golden Ticket attacks particularly dangerous is their persistence: forged tickets can remain usable even after user accounts are disabled or passwords are changed, because the validity of a Kerberos TGT depends on the KRBTGT account's password, not the user account's password.

The remediation is KRBTGT password rotation. Resetting the KRBTGT password invalidates all existing Kerberos tickets in the domain, forcing every user and service to re-authenticate and obtain new tickets. Best practice requires resetting the KRBTGT password at least twice per year, with the two resets separated by at least the maximum Kerberos ticket lifetime (typically 10 hours) to allow legitimate outstanding tickets to expire naturally between resets. Microsoft has published a specific PowerShell script for this process (the New-KrbtgtKeys.ps1 script) that handles sequencing correctly across multiple domain controllers and includes safeguards against accidental double-reset. Add this rotation to your security maintenance calendar as a recurring semi-annual task.

In environments where a compromise is known or suspected, KRBTGT rotation should happen immediately and twice in rapid succession to ensure all Golden Tickets are invalidated. Coordinate with application and service owners before executing — the rotation will cause authentication failures for any service with a cached TGT that expires before it can re-authenticate, which in most environments means a brief period of service disruption for any service that doesn't handle Kerberos re-authentication gracefully.

Enable Comprehensive Audit Logging and Forward to a SIEM

Visibility is the prerequisite for detection, and detection is what separates a contained incident from a full domain compromise. An Active Directory environment without comprehensive audit logging is an environment where attacks can proceed for months undetected — which is precisely the pattern seen in the breach investigations that result in the largest impacts. Enable Advanced Audit Policy settings on all domain controllers and member servers, covering: account logon events (to detect credential attacks), account management (to detect unauthorized account creation and modification), DS Access (to detect sensitive object access and replication attacks), logon/logoff events, object access, policy change events, and privilege use. The default audit settings in most Windows Server installations are insufficient for security operations purposes.

Forward these logs to a centralized Security Information and Event Management (SIEM) system in real time, to an immutable storage destination. Logs that remain only on domain controllers are logs that an attacker with DC-level access can modify or destroy to cover their tracks. Centralized, immutable log storage is the only log storage that produces reliable forensic evidence. Configure alerting for the highest-fidelity indicators of AD attack activity: multiple failed Kerberos pre-authentication attempts (AS-REP Roasting and Kerberoasting indicators), unusual replication requests between non-DC machines and domain controllers (DCSync attack indicator), bulk changes to sensitive group membership, account creation outside normal business hours, and privilege escalation events.

Manage Service Accounts With gMSAs

Traditional service accounts — standard AD user accounts used to run Windows services and scheduled tasks — are a persistent and well-known security weakness. They typically have non-expiring passwords that haven't been rotated in years, are often over-privileged because determining minimal permissions was considered too time-consuming, and represent shared secrets stored in service configuration files or the LSA secrets store where they can be extracted. When these accounts are compromised — and attackers specifically target service account credentials because they're stable, high-privilege, and poorly monitored — they provide persistent, privileged access with a long operational window before detection.

Group Managed Service Accounts (gMSAs), introduced in Windows Server 2012, solve most of these problems at the platform level. gMSAs have passwords that are automatically generated, managed, and rotated by Active Directory on a configurable schedule (default 30 days). The password is never known to any administrator and never stored in any accessible location — Windows retrieves it directly from AD when the service starts. gMSAs also support SPNs natively, eliminating duplicate SPN conflicts that plague traditional service accounts. Migrate existing traditional service accounts to gMSAs as a standing security improvement project, prioritizing the most privileged accounts first.

Conclusion

Active Directory security is not a project with a defined completion state — it is an ongoing practice that must evolve as the threat landscape and the environment both change. The recommendations in this guide represent current best practice based on the attack techniques that are actively being used against enterprise AD environments in 2026. Implementing them systematically — starting with the highest-impact items like tiered administration and KRBTGT rotation — significantly raises the cost and complexity of successfully attacking your AD environment.

Build a regular AD security review cadence into your security program. Stay current with Microsoft's security guidance and threat intelligence from the security research community. Treat AD hardening as the strategic security priority it deserves, rather than a background maintenance task. The cost of getting it wrong is not a single system compromise — it is the entirety of your organization's digital infrastructure. Start with the fundamentals, such as MFA for privileged accounts, privileged group hygiene, and audit logging, which remain effective against the majority of real-world attacks. Then build the monitoring to detect anomalies.

How ezOnboard Supports Active Directory Security

ezOnboard reduces Active Directory security risk by ensuring accounts are provisioned correctly from the start and deprovisioned immediately at departure—eliminating the stale accounts and access accumulation that attackers exploit. Role-based provisioning rules ensure new accounts are placed in the right OUs with the right group memberships, minimizing over-provisioning. Automated offboarding disables accounts in AD as part of a coordinated workflow, not as an afterthought. For IT teams working to improve their AD security posture, ezOnboard removes two of the most common gaps: lingering accounts and inconsistent provisioning.

Frequently Asked Questions

What are the highest-impact Active Directory security controls for SMBs?

The controls with the highest impact for most SMBs, in priority order, are: enforcing multi-factor authentication for all privileged accounts (Domain Admins, Enterprise Admins, and any account with elevated permissions), implementing tiered administration to separate day-to-day work accounts from privileged admin accounts, auditing and restricting membership in privileged groups (a core step in any Active Directory user account audit), enabling detailed audit logging and forwarding logs to a SIEM, and patching domain controllers on a regular cycle. These five controls address the attack patterns most commonly exploited in AD environments and deliver significant risk reduction without requiring specialized tooling beyond what Windows Server already provides.

Why is the default Domain Admins group a security risk?

The Domain Admins group is the highest-privilege group in an Active Directory domain—members can make any change to any object. Many organizations add accounts to Domain Admins liberally for convenience, then never remove them. The result is a large group of permanently privileged accounts that each represent a high-value target. Best practice is to keep Domain Admins membership extremely small (two to three accounts maximum, ideally dedicated admin-only accounts with no email or general purpose use), audit membership changes with alerts, and use just-in-time privileged access tools to grant elevated permissions temporarily when needed rather than permanently.

How should domain controller security be hardened?

Domain controllers should be treated as the most sensitive servers in the environment. Limit who can log on to them interactively; use the User Rights Assignment policies to restrict logon rights to Domain Admins and specific IT accounts only. Ensure DCs are running current, patched Windows Server versions—not end-of-life releases. Enable Windows Defender or a supported EDR solution on all DCs. Disable unnecessary services and remove roles that don't belong on a DC. Restrict RDP access to DCs by IP range and require MFA for any remote access. Conduct vulnerability scans against DCs as part of your regular security testing cycle.

What is Kerberoasting, and how do you defend against it?

Kerberoasting is an attack technique that targets service accounts with Service Principal Names (SPNs) in Active Directory. An attacker with any domain user account can request a Kerberos ticket for any SPN and then attempt to crack the ticket offline to recover the service account's password. The defense has two components: use Group Managed Service Accounts (gMSAs) for service accounts wherever possible, as gMSAs use automatically-managed, complex passwords that defeat offline cracking; and for service accounts that can't use gMSAs, ensure their passwords are at least 25 characters long and randomly generated. Monitor for Kerberoasting indicators using your SIEM.

How do you detect signs of Active Directory compromise?

Key indicators of AD compromise include: unexpected changes to privileged group memberships, new accounts added to Domain Admins outside of normal processes, replication traffic from non-DC servers (a DCSync attack indicator), unusual Kerberos ticket requests in volume or timing, logons from privileged accounts outside of normal business hours or from unusual locations, and modifications to GPOs or AD schema by non-administrator accounts. These signals require centralized log collection and either a SIEM with AD-specific detection rules or a dedicated tool like Microsoft Defender for Identity (formerly Azure ATP) to surface in near real time.