Securing Active Directory: The 10 Most Important Measures

Why Active Directory is the primary attack target

In most mid-market companies, there is one system that stands above all others: Active Directory. It manages user accounts, controls group memberships, regulates access to file shares, applications, and email, and authenticates every login on every Windows machine in the network. Whoever gains control of Active Directory has control of the entire organization.

This is exactly what makes AD the preferred target for attackers. Ransomware groups like LockBit, BlackCat, and Conti have perfected their attack chains over years, and in nearly every one, compromising Active Directory plays the central role. The typical sequence: phishing link, access to a workstation PC, lateral movement through the network until Domain Admin rights are obtained.

Microsoft has found that in over 80 percent of successful ransomware attacks, Active Directory was compromised. The BSI confirms this finding.

The problem is not that Active Directory is inherently insecure. The problem is that most AD environments in mid-market companies have grown over years without anyone systematically thinking about security. Accounts are never cleaned up, groups are confusingly nested, local admin passwords are identical everywhere, and service accounts run with Domain Admin rights.

The following ten measures change that. They are ordered by priority and tailored specifically to companies with around 100 employees -- environments with one domain, one or two domain controllers, and a small IT department.

Measure 1: Implement tiered administration

Tiered administration is the foundation of every AD hardening effort. The concept is simple: you separate the management of your IT environment into three tiers and ensure that credentials from a higher tier are never used at a lower tier.

Tier 0 encompasses the domain controllers and everything that directly controls Active Directory. This includes Domain Admins, Enterprise Admins, Schema Admins, and the systems that use these accounts.

Tier 1 encompasses the server infrastructure: file servers, database servers, application servers, Exchange, SharePoint. Admin accounts at this level have access to business data but not to the domain controllers.

Tier 2 encompasses the workstations and endpoint devices of employees. Helpdesk accounts that resolve workstation issues have no access to servers or domain controllers.

The central rule is: a Tier 0 account never logs into a Tier 1 or Tier 2 system. A Tier 1 account never logs into a workstation. This separation prevents an attacker who compromises a workstation from directly obtaining credentials that can take over domain controllers.

In practice, this means: your IT admin gets at least two, ideally three separate accounts. A normal account for email and everyday work (Tier 2), a server admin account for managing servers (Tier 1), and a Domain Admin account for Active Directory tasks (Tier 0). The Domain Admin account is used exclusively on domain controllers or through dedicated Privileged Access Workstations (PAWs).

For a company with 100 employees, this is not excessive complexity. A hardened machine used exclusively for AD administration is enough for the start. A clean authorization concept is the foundation for consistent implementation of tiered administration. What matters is the separation of accounts and the discipline to maintain it.

Implementation: Create separate OU structures for the three tiers and implement logon restrictions via GPO. The technical mechanism is "User Rights Assignment" under "Deny log on locally" and "Deny log on through Remote Desktop Services."

Measure 2: Implement LAPS

LAPS stands for Local Administrator Password Solution and solves one of the oldest and most common security problems in Windows environments: identical local admin passwords on all machines.

The classic mistake looks like this: when setting up the company image, a local administrator password is set -- say "Company2019!" This password is rolled out to every client and every server. It never changes. Everyone in the IT department knows it, and it is probably also in an Excel spreadsheet on a network share.

The problem: if an attacker reads this password from a single machine (e.g., via Mimikatz or another credential-dumping tool), they have local admin access to every machine in the network. Lateral movement becomes trivial.

LAPS solves this by setting a unique, randomly generated local admin password for each machine and storing it in Active Directory. Only authorized administrators can read the passwords from AD, and the passwords are automatically rotated.

Microsoft has now integrated LAPS as "Windows LAPS" directly into Windows 11 and Windows Server 2025. For older systems, the classic "Legacy LAPS" is available as a free download. The basic principle is the same for both: a GPO client extension generates the password, writes it encrypted to an AD attribute of the computer object, and sets an expiration date.

Implementation: Install the LAPS schema extension (for Legacy LAPS) or enable Windows LAPS via GPO. Define the password length (at least 20 characters), complexity, and rotation interval (30 days is a good starting value). Test on a small group of machines before rolling out. The entire rollout takes an afternoon for 100 workstations.

Measure 3: Prevent Kerberoasting

Kerberoasting is an attack technique that exploits a fundamental design aspect of Kerberos: when a user requests a service ticket for a service, that ticket is encrypted with the password hash of the associated service account. An attacker with a normal user account can request service tickets for all service accounts and then attempt to crack the passwords offline. The dangerous part: requesting the ticket requires no special privileges, and the brute-force attack happens offline -- without failed attempts that would trigger an account lockout.

Service accounts with a Service Principal Name (SPN) and a weak password like "Summer2020!" are cracked in minutes. If that service account is also a member of the Domain Admins group (which happens alarmingly often), the attacker hits the jackpot.

The countermeasures are clear and implementable:

Strong passwords for service accounts. Every service account with an SPN needs a randomly generated password of at least 30 characters. At this length, offline brute force is practically hopeless.

Use Group Managed Service Accounts (gMSA). gMSAs are AD-managed service accounts whose 240-character password is automatically rotated every 30 days. No human knows or manages this password. Wherever a service supports gMSA, you should migrate to it. Most modern applications, including SQL Server, IIS, and SCCM, can work with gMSAs.

Remove unnecessary SPNs. Regularly check which accounts have a registered SPN. Accounts that no longer provide a service should have their SPN removed. This reduces the attack surface.

Enforce AES encryption. Ensure service accounts use AES-256 encryption for Kerberos tickets (the attribute msDS-SupportedEncryptionTypes). RC4-encrypted tickets can be cracked significantly faster than AES-encrypted ones.

Monitoring. Monitor Event ID 4769 (Kerberos Service Ticket Requests) with encryption type 0x17 (RC4). A sudden spike in RC4-based ticket requests is a strong indicator of a Kerberoasting attack.

Measure 4: Use the Protected Users group

The security group "Protected Users" has existed since Windows Server 2012 R2 and is one of the most underrated security features in Active Directory. Members of this group automatically receive a set of protections that significantly hinder credential theft attacks.

Specifically, the following happens when an account is a member of Protected Users:

• No NTLM. The account cannot authenticate via NTLM, only via Kerberos. This prevents Pass-the-Hash attacks based on NTLM hashes.
• No DES or RC4 for Kerberos. Only AES keys are used, making Kerberoasting harder.
• No delegation. The account cannot be delegated, neither constrained nor unconstrained. This prevents token impersonation attacks.
• Ticket lifetime limited to 4 hours. Kerberos tickets (TGT) expire faster, shrinking the window for attackers.
• No credential caching. Password hashes are not cached in the machine's memory. Mimikatz finds nothing usable there.

For which accounts should you enable Protected Users? For all highly privileged accounts: Domain Admins, Enterprise Admins, Schema Admins, and all accounts with administrative access to domain controllers or other Tier 0 systems.

Caution with service accounts: Service accounts that rely on NTLM or delegation will no longer work as Protected Users. Test carefully before adding a service account to the group. For interactive admin accounts, however, there is rarely a reason not to use Protected Users.

Implementation: Open "Active Directory Users and Computers," navigate to the "Users" container, find the "Protected Users" group, and add your highly privileged accounts. The protections take effect immediately after the next login. This literally takes five minutes, and the security gain is enormous.

Measure 5: Enable Credential Guard

Windows Credential Guard uses Virtualization-Based Security (VBS) to store credentials in an isolated area of the system that even an attacker with local admin rights cannot access. In plain terms: even if an attacker runs Mimikatz on a machine with Credential Guard, they get no NTLM hashes and no Kerberos tickets from memory.

This is fundamental protection against one of the most common attack techniques. Without Credential Guard, an attacker with local admin access can dump the LSASS process and extract all credentials stored there. If a Domain Admin has logged into that machine (a violation of tiered administration, see Measure 1), the attacker has their credentials.

Credential Guard eliminates this attack vector. Credentials are stored in an isolated virtual machine that the regular operating system cannot access.

Prerequisites: UEFI firmware with Secure Boot, TPM 2.0, and Windows 10/11 Enterprise or Education (or Windows Server 2016+). On Windows 11 22H2 and newer, Credential Guard is enabled by default.

Implementation: Enable Credential Guard via Group Policy under "Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security." Set the option "Credential Guard Configuration" to "Enabled with UEFI lock." The UEFI lock ensures an attacker cannot simply disable Credential Guard via GPO.

Compatibility note: Older applications that use NTLM v1 or CredSSP in certain configurations may have issues. Test on a pilot group before rolling out the GPO company-wide.

Measure 6: Understand and secure AdminSDHolder and SDProp

AdminSDHolder is a container object in Active Directory whose access control list (ACL) is automatically propagated to all privileged accounts and groups. The process called SDProp (Security Descriptor Propagator) runs every 60 minutes on the PDC Emulator and overwrites the ACLs of all protected objects with the ACL of the AdminSDHolder container.

This sounds technical, but the security relevance is high: if an attacker can manipulate the AdminSDHolder container's ACL, they indirectly gain control over all privileged accounts in the domain. Within 60 minutes, their manipulated permissions propagate to all Domain Admins, Enterprise Admins, and other protected groups.

What you should do:

First, check the current ACL of the AdminSDHolder container. Only Domain Admins and Enterprise Admins should have write permissions there. Remove any other permission that does not belong.

Second, monitor changes to the AdminSDHolder container. Any modification to this object's ACL is a potential attack indicator. Configure an audit log for changes to this specific object (enable object auditing in the AdminSDHolder container's SACL).

Third, understand the list of protected groups. SDProp protects by default: Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Server Operators, Print Operators, Backup Operators, and the Replicator group. If members of these groups suddenly have unusual permissions that cannot be explained by GPOs, AdminSDHolder may have been manipulated.

Implementation: Open ADSI Edit, navigate to the object CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com, and review the security properties. Document the target ACL and compare it regularly with the actual state. In a 100-employee environment, this takes half an hour once a quarter.

Measure 7: GPO hardening

Group Policies are the central configuration tool in Windows environments, and they can be used just as effectively for hardening as they can be abused for attacks. An attacker with write permissions on a GPO can distribute malware to all computers, create local admin accounts, or disable security settings in one stroke.

Securing GPOs encompasses two dimensions: the permissions on the GPO objects themselves and the security-relevant settings distributed through GPOs.

Securing GPO permissions:

Only Domain Admins should be able to create, edit, and link GPOs. Check with BloodHound or manually through the GPMC (Group Policy Management Console) who has write permissions on your GPOs. In mature environments, you regularly find accounts that were authorized years ago and no longer perform GPO management.

Especially critical are the "Default Domain Policy" and the "Default Domain Controllers Policy" GPOs. Manipulation of these GPOs affects the entire domain.

Security-relevant GPO settings:

Deploy at least the following hardening measures through Group Policies:

Implementation: Create a dedicated "Security Baseline" GPO linked to the entire domain. Use the Microsoft Security Baselines (free in the Security Compliance Toolkit) as a template. Adapt the settings to your environment and test them in a staging OU before deploying to production.

Measure 8: Monitor critical Event IDs

All previous measures aim at prevention. Monitoring aims to detect attacks that occur despite all prevention. The challenge is not too little logging but too much. Without targeted filtering, every signal drowns in the noise.

The following Event IDs should be actively monitored:

Attacks on privileged accounts:

Kerberos attacks:

Account manipulation:

Implementation: Enable the advanced audit policies (Advanced Audit Policy Configuration) via GPO on domain controllers. Configure event forwarding to a central log system (Windows Event Forwarding or a SIEM agent). Define an alert rule with specific escalation for each of the listed Event IDs.

Measure 9: Secure service accounts

Service accounts are the silent vulnerability of many AD environments. They run unattended, their passwords are rarely or never changed, and they frequently have excessive permissions because nobody checked exactly what rights the service actually needs during setup.

In a typical 100-employee environment, you easily find 10 to 30 service accounts: for SQL Server, the backup agent, the monitoring service, the ERP software, the print server, the SCCM agent, and various smaller tools. A review regularly reveals that several of these accounts are members of the Domain Admins group (because there were permission issues during setup and someone took the quick path), their passwords have not been changed since the setup years ago, and nobody knows exactly which services still use them.

Step 1: Inventory. Identify all service accounts in your domain. The PowerShell command Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, MemberOf delivers a list of all accounts with SPNs, last password date, and group memberships.

Step 2: Minimize permissions. Remove every service account from the Domain Admins group. Assign instead the minimum rights the service actually needs. In most cases, a local group on the target server or a dedicated OU-based delegation is sufficient.

Step 3: Migrate to gMSA. Wherever a service supports gMSA, migrate to a Group Managed Service Account. The automatic password rotation eliminates the risk of forgotten, never-changed passwords.

Step 4: Password policy for remaining service accounts. For service accounts that cannot use gMSA: password length at least 30 characters, randomly generated, rotation at least annually. Document every password change and the process required (which services must be restarted, which configurations must be updated).

Step 5: Prohibit interactive logon. Service accounts must log on as a service, not interactively. Set "Deny log on locally" and "Deny log on through Remote Desktop Services" for all service accounts via GPO. This prevents an attacker from using a compromised service account for interactive logins.

Measure 10: AD backup and recovery

All previous measures aim to prevent or detect an Active Directory compromise early. But what if the worst case happens? What if an attacker actually gains Domain Admin rights, manipulates the AD database, or encrypts your domain controllers?

Without a functional AD backup, the answer is simple and painful: you rebuild the entire IT environment from scratch. This takes weeks, sometimes months, and is every IT department's nightmare.

An AD backup must be more than a filesystem backup of the domain controllers. The AD database (NTDS.dit) must be backed up consistently -- in the state of a specific point in time, not as a collection of individually backed-up files. Windows Server Backup with the "System State" option backs up the AD database, the SYSVOL share, the registry, and the certificate services database in a consistent state.

Backup strategy for AD:

Back up the system state at least daily. The retention period must cover the tombstone lifetime of your domain (default 180 days, minimum 60 days). A backup older than the tombstone lifetime cannot be used for authoritative restoration.

Store at least one backup copy offline or on a system that is not domain-joined. The reason: if an attacker has compromised the domain, they also have access to all domain-joined backup systems. A backup on a domain-joined backup server is worthless in this scenario because the attacker can delete or encrypt it.

Document and test the recovery procedure:

A backup you have never tested is not a backup. It is a hope. Document the recovery procedure step by step: how do I restore a domain controller from backup? How do I perform an authoritative restoration when the AD database has been manipulated? How do I restore SYSVOL?

Test the recovery at least annually in an isolated test environment. This reveals not only whether the backup works technically but also how long the recovery takes. This information is essential for your business impact analysis and recovery plan.

Forest recovery as worst case: If the entire forest structure has been compromised, you need an AD Forest Recovery. The process is complex: shut down all domain controllers, restore one DC from backup, clean up metadata, reset the KRBTGT password twice, then promote the remaining DCs again. Plan a documented runbook for this scenario.

Prioritization for 100-employee companies

Not all ten measures need to be implemented simultaneously. For a company with around 100 employees, one domain, and a small IT department, the following prioritization is recommended:

Immediately (weeks 1-2)

1. Implement LAPS -- quick to implement, immediate impact, low complexity.
2. Protected Users for all admin accounts -- five minutes of effort, enormous security gain.
3. Remove service accounts from Domain Admins -- requires review, but every day with a service account in Domain Admins is a day of unnecessary risk.

Short-term (months 1-2)

4. Tiered administration -- conceptually more demanding but the foundation for everything else.
5. GPO hardening -- use Microsoft Security Baselines as a starting point.
6. Monitor critical Event IDs -- even without a SIEM, you can start with Windows Event Forwarding and PowerShell scripts.

Medium-term (months 3-6)

7. Enable Credential Guard -- requires compatibility testing but is worth it.
8. Kerberoasting protection -- gMSA migration and password hardening for service accounts.
9. Secure AdminSDHolder -- one-time review plus regular monitoring.
10. Test AD backup and recovery -- if you are not doing system state backups yet, start immediately. Plan the recovery test as a project.

How the measures work together

The ten measures do not work in isolation -- they interlock. Tiered administration prevents admin credentials from landing on endpoint devices. If they do land there (because someone bypasses the rules), Credential Guard prevents extraction. If Credential Guard is not active (on older systems), Protected Users at least prevents caching of NTLM hashes. If the attacker still obtains credentials, LAPS limits the damage to a single machine rather than the entire network. And monitoring detects the suspicious activities that each of these steps leaves behind.

This defense in depth is the principle guiding every serious security architecture. No single measure is perfect, but the combination makes it so difficult for an attacker that they seek an easier target.

For your ISMS, this means: document each measure as its own control, define the target state and responsibility, and review progress in the management review. In ISMS Lite, the ten AD hardening measures can be created as controls with implementation status and responsible parties and mapped directly to ISO 27001 requirements. This makes AD hardening an integral part of your information security management system.

Further reading

• Creating an authorization concept: Roles, permissions, and approval workflow
• The 10 biggest security risks for mid-market companies and how to address them
• Implementing MFA: Multi-factor authentication in the enterprise
• Ransomware attack: Immediate response and recovery

The ten measures in this article give you a concrete roadmap. Start with the quick wins, build the more complex measures step by step, and document every step. Your auditor will thank you -- and in an emergency, you will be glad you did not wait.